Re: [alsa-devel] [PATCH 3/3] mfd: twl: move header file out of I2C realm
On Sun, 13 Aug 2017, Wolfram Sang wrote:
On Thu, Jul 06, 2017 at 08:03:52AM +0100, Lee Jones wrote:
On Thu, 06 Jul 2017, Thierry Reding wrote:
On Mon, May 22, 2017 at 12:02:10AM +0200, Wolfram Sang wrote:
include/linux/i2c is not for client devices. Move the header file to a more appropriate location.
Signed-off-by: Wolfram Sang wsa@the-dreams.de
arch/arm/mach-omap2/common.h | 2 +- arch/arm/mach-omap2/omap_twl.c | 2 +- drivers/gpio/gpio-twl4030.c | 2 +- drivers/iio/adc/twl4030-madc.c | 2 +- drivers/iio/adc/twl6030-gpadc.c | 2 +- drivers/input/keyboard/twl4030_keypad.c | 2 +- drivers/input/misc/twl4030-pwrbutton.c | 2 +- drivers/input/misc/twl4030-vibra.c | 2 +- drivers/mfd/twl-core.c | 6 +++--- drivers/mfd/twl4030-audio.c | 2 +- drivers/mfd/twl4030-irq.c | 2 +- drivers/mfd/twl4030-power.c | 2 +- drivers/mfd/twl6030-irq.c | 2 +- drivers/phy/phy-twl4030-usb.c | 2 +- drivers/power/supply/twl4030_charger.c | 2 +- drivers/pwm/pwm-twl-led.c | 2 +- drivers/pwm/pwm-twl.c | 2 +- drivers/regulator/twl-regulator.c | 2 +- drivers/regulator/twl6030-regulator.c | 2 +- drivers/rtc/rtc-twl.c | 2 +- drivers/usb/phy/phy-twl6030-usb.c | 2 +- drivers/video/backlight/pandora_bl.c | 2 +- drivers/watchdog/twl4030_wdt.c | 2 +- include/linux/{i2c => mfd}/twl.h | 0 sound/soc/codecs/twl4030.c | 2 +- 25 files changed, 26 insertions(+), 26 deletions(-) rename include/linux/{i2c => mfd}/twl.h (100%)
I didn't see this get applied yet, so just in case anyone was waiting for me (this is trivial, so I don't think there's a need):
You're not the last. :)
Given the triviality of the change for non-MFD subsystems, can we apply this for 4.14?
I can't apply anything without Acks for *all* of the subsystems above.
As you well know, it is the submitters responsibility to obtain them.
My suggestion would be to collect the Acks you've received up until this point and identify which SS's are still lacking in change log section of a RESEND.
Given the triviality of the change for non-MFD subsystems, can we apply this for 4.14?
I can't apply anything without Acks for *all* of the subsystems above.
Well, there are cases when you can. Those should be exceptions and well justified, of course.
My suggestion would be to collect the Acks you've received up until this point and identify which SS's are still lacking in change log section of a RESEND.
I agree, though, that I can try a second round to get the acks.
* Wolfram Sang wsa@the-dreams.de [170814 01:43]:
Given the triviality of the change for non-MFD subsystems, can we apply this for 4.14?
I can't apply anything without Acks for *all* of the subsystems above.
Well, there are cases when you can. Those should be exceptions and well justified, of course.
My suggestion would be to collect the Acks you've received up until this point and identify which SS's are still lacking in change log section of a RESEND.
I agree, though, that I can try a second round to get the acks.
As long as it's been compile tested with omap2plus_defconfig:
Acked-by: Tony Lindgren tony@atomide.com
On 14/08/17 17:22, Tony Lindgren wrote:
- Wolfram Sang wsa@the-dreams.de [170814 01:43]:
Given the triviality of the change for non-MFD subsystems, can we apply this for 4.14?
I can't apply anything without Acks for *all* of the subsystems above.
Well, there are cases when you can. Those should be exceptions and well justified, of course.
My suggestion would be to collect the Acks you've received up until this point and identify which SS's are still lacking in change log section of a RESEND.
I agree, though, that I can try a second round to get the acks.
As long as it's been compile tested with omap2plus_defconfig:
Acked-by: Tony Lindgren tony@atomide.com
Don't recall if I sent an ack before but I do remember the patch... so from a backlight PoV: Acked-by: Daniel Thompson daniel.thompson@linaro.org
participants (4)
-
Daniel Thompson -
Lee Jones -
Tony Lindgren -
Wolfram Sang