| Message ID | 1451086812-3729-1-git-send-email-pali.rohar@gmail.com |
|---|---|
| State | New |
| Headers | show |
On Sat 2015-12-26 00:40:12, Pali Rohár wrote: > This patch adds adp1653 device into n900 DT structure. DT support in > adp1653 driver is there since v4.2-rc1 version. > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz>
On Saturday 26 December 2015 00:40:12 Pali Rohár wrote: > This patch adds adp1653 device into n900 DT structure. DT support in > adp1653 driver is there since v4.2-rc1 version. > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > --- > arch/arm/boot/dts/omap3-n900.dts | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/arm/boot/dts/omap3-n900.dts > b/arch/arm/boot/dts/omap3-n900.dts index 5f5e0f3..ba93642 100644 > --- a/arch/arm/boot/dts/omap3-n900.dts > +++ b/arch/arm/boot/dts/omap3-n900.dts > @@ -522,6 +522,21 @@ > amstaos,cover-comp-gain = <16>; > }; > > + adp1653: led-controller@30 { > + compatible = "adi,adp1653"; > + reg = <0x30>; > + enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */ > + > + flash { > + flash-timeout-us = <500000>; > + flash-max-microamp = <320000>; > + led-max-microamp = <50000>; > + }; > + indicator { > + led-max-microamp = <17500>; > + }; > + }; > + > lp5523: lp5523@32 { > compatible = "national,lp5523"; > reg = <0x32>; Tony, can you take this patch?
On Saturday 26 December 2015 00:40:12 Pali Rohár wrote: > This patch adds adp1653 device into n900 DT structure. DT support in > adp1653 driver is there since v4.2-rc1 version. > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > --- > arch/arm/boot/dts/omap3-n900.dts | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts > index 5f5e0f3..ba93642 100644 > --- a/arch/arm/boot/dts/omap3-n900.dts > +++ b/arch/arm/boot/dts/omap3-n900.dts > @@ -522,6 +522,21 @@ > amstaos,cover-comp-gain = <16>; > }; > > + adp1653: led-controller@30 { > + compatible = "adi,adp1653"; > + reg = <0x30>; > + enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */ > + > + flash { > + flash-timeout-us = <500000>; > + flash-max-microamp = <320000>; > + led-max-microamp = <50000>; > + }; > + indicator { > + led-max-microamp = <17500>; > + }; > + }; > + > lp5523: lp5523@32 { > compatible = "national,lp5523"; > reg = <0x32>; PING, who can take this patch? I still do not see it in linus tree nor in others like arm-soc...
The merge window is open, which is when development code that was merged in good time prior to the merge window is sent upstream to Linus. Linux maintainers may choose not to merge new code into their tree to avoid disrupting the utility of linux-next until the merge window has closed. linux-next is an integration tree to help find merge conflicts, it exists to assist with the merge windows, not as a general test ground. Thus, linux-next must only contain code for either the current open merge window, or if the merge window is closed, the next merge window. On Thu, Jan 21, 2016 at 10:12:41AM +0100, Pali Rohár wrote: > On Saturday 26 December 2015 00:40:12 Pali Rohár wrote: > > This patch adds adp1653 device into n900 DT structure. DT support in > > adp1653 driver is there since v4.2-rc1 version. > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > --- > > arch/arm/boot/dts/omap3-n900.dts | 15 +++++++++++++++ > > 1 file changed, 15 insertions(+) > > > > diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts > > index 5f5e0f3..ba93642 100644 > > --- a/arch/arm/boot/dts/omap3-n900.dts > > +++ b/arch/arm/boot/dts/omap3-n900.dts > > @@ -522,6 +522,21 @@ > > amstaos,cover-comp-gain = <16>; > > }; > > > > + adp1653: led-controller@30 { > > + compatible = "adi,adp1653"; > > + reg = <0x30>; > > + enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */ > > + > > + flash { > > + flash-timeout-us = <500000>; > > + flash-max-microamp = <320000>; > > + led-max-microamp = <50000>; > > + }; > > + indicator { > > + led-max-microamp = <17500>; > > + }; > > + }; > > + > > lp5523: lp5523@32 { > > compatible = "national,lp5523"; > > reg = <0x32>; > > PING, who can take this patch? > > I still do not see it in linus tree nor in others like arm-soc... > > -- > Pali Rohár > pali.rohar@gmail.com
Ok, but for whole month I do not see any response that somebody take this patch into some queue or tree. Which could means that patch was either ignored or is living somewhere and could be lost. On Thursday 21 January 2016 09:29:10 Russell King - ARM Linux wrote: > The merge window is open, which is when development code that was merged > in good time prior to the merge window is sent upstream to Linus. Linux > maintainers may choose not to merge new code into their tree to avoid > disrupting the utility of linux-next until the merge window has closed. > > linux-next is an integration tree to help find merge conflicts, it > exists to assist with the merge windows, not as a general test ground. > Thus, linux-next must only contain code for either the current open > merge window, or if the merge window is closed, the next merge window. > > On Thu, Jan 21, 2016 at 10:12:41AM +0100, Pali Rohár wrote: > > On Saturday 26 December 2015 00:40:12 Pali Rohár wrote: > > > This patch adds adp1653 device into n900 DT structure. DT support in > > > adp1653 driver is there since v4.2-rc1 version. > > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > > --- > > > arch/arm/boot/dts/omap3-n900.dts | 15 +++++++++++++++ > > > 1 file changed, 15 insertions(+) > > > > > > diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts > > > index 5f5e0f3..ba93642 100644 > > > --- a/arch/arm/boot/dts/omap3-n900.dts > > > +++ b/arch/arm/boot/dts/omap3-n900.dts > > > @@ -522,6 +522,21 @@ > > > amstaos,cover-comp-gain = <16>; > > > }; > > > > > > + adp1653: led-controller@30 { > > > + compatible = "adi,adp1653"; > > > + reg = <0x30>; > > > + enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */ > > > + > > > + flash { > > > + flash-timeout-us = <500000>; > > > + flash-max-microamp = <320000>; > > > + led-max-microamp = <50000>; > > > + }; > > > + indicator { > > > + led-max-microamp = <17500>; > > > + }; > > > + }; > > > + > > > lp5523: lp5523@32 { > > > compatible = "national,lp5523"; > > > reg = <0x32>; > > > > PING, who can take this patch? > > > > I still do not see it in linus tree nor in others like arm-soc... > > > > -- > > Pali Rohár > > pali.rohar@gmail.com >
On Thu, Jan 21, 2016 at 10:50:04AM +0100, Pali Rohár wrote: > Ok, but for whole month I do not see any response that somebody take > this patch into some queue or tree. Which could means that patch was > either ignored or is living somewhere and could be lost. You sent it the day after Christmas day, when people were most likely on their Christmas break doing family stuff, and there was only one week after the traditional Christmas/New year break before the merge window opened. So, discounting Christmas and the merge window, your patch has only been around for one week - a week where maintainers would have been stabilising their tree(s) in preparation for the merge window opening. Please be patient; the merge window closes this Sunday, and I suspect "normal service" will be resumed shortly thereafter.
On Thu 2016-01-21 09:29:10, Russell King - ARM Linux wrote: > The merge window is open, which is when development code that was merged > in good time prior to the merge window is sent upstream to Linus. Linux > maintainers may choose not to merge new code into their tree to avoid > disrupting the utility of linux-next until the merge window has > closed. Support for new hardware is normally allowed after -rc1. Pavel
* Pavel Machek <pavel@ucw.cz> [160121 02:19]: > On Thu 2016-01-21 09:29:10, Russell King - ARM Linux wrote: > > The merge window is open, which is when development code that was merged > > in good time prior to the merge window is sent upstream to Linus. Linux > > maintainers may choose not to merge new code into their tree to avoid > > disrupting the utility of linux-next until the merge window has > > closed. > > Support for new hardware is normally allowed after -rc1. Yeah most maintainers avoid looking at new code until -rc1. Or until regresssions are out of the way. So patience please. Fixes are welcome any time though. Regards, Tony
On Thu, Jan 21, 2016 at 08:38:57AM -0800, Tony Lindgren wrote: > * Pavel Machek <pavel@ucw.cz> [160121 02:19]: > > On Thu 2016-01-21 09:29:10, Russell King - ARM Linux wrote: > > > The merge window is open, which is when development code that was merged > > > in good time prior to the merge window is sent upstream to Linus. Linux > > > maintainers may choose not to merge new code into their tree to avoid > > > disrupting the utility of linux-next until the merge window has > > > closed. > > > > Support for new hardware is normally allowed after -rc1. > > Yeah most maintainers avoid looking at new code until -rc1. Or until > regresssions are out of the way. So patience please. Fixes are > welcome any time though. Indeed. However, unlike Pavel's comment, many maintainers choose not to merge code for new hardware until the merge window - it's very rare that support for new hardware is merged during the -rc phase. If it were otherwise, I would've been able to get the Hummingboard 2 DTS patches in, or the etnaviv team would've been able to get the Etnaviv GPU DRM driver in during the 4.4-rc cycle, or the Dove PMU driver, or... etc. Practically, new code waits for merge windows, because no one wants to de-stabilise the progression of the -rc series with new code, and Linus wants to see -rc merges fairly quiet and be mostly bug fixes so he can feel good about a final release around -rc6 to -rc7 time.
On Thursday 21 January 2016 16:54:08 Russell King - ARM Linux wrote: > On Thu, Jan 21, 2016 at 08:38:57AM -0800, Tony Lindgren wrote: > > * Pavel Machek <pavel@ucw.cz> [160121 02:19]: > > > On Thu 2016-01-21 09:29:10, Russell King - ARM Linux wrote: > > > > The merge window is open, which is when development code that was merged > > > > in good time prior to the merge window is sent upstream to Linus. Linux > > > > maintainers may choose not to merge new code into their tree to avoid > > > > disrupting the utility of linux-next until the merge window has > > > > closed. > > > > > > Support for new hardware is normally allowed after -rc1. > > > > Yeah most maintainers avoid looking at new code until -rc1. Or until > > regresssions are out of the way. So patience please. Fixes are > > welcome any time though. > > Indeed. However, unlike Pavel's comment, many maintainers choose not > to merge code for new hardware until the merge window - it's very rare > that support for new hardware is merged during the -rc phase. > > If it were otherwise, I would've been able to get the Hummingboard 2 > DTS patches in, or the etnaviv team would've been able to get the > Etnaviv GPU DRM driver in during the 4.4-rc cycle, or the Dove PMU > driver, or... etc. > > Practically, new code waits for merge windows, because no one wants > to de-stabilise the progression of the -rc series with new code, and > Linus wants to see -rc merges fairly quiet and be mostly bug fixes > so he can feel good about a final release around -rc6 to -rc7 time. > In my opinion this patch is not support for new hardware. It just add missing DT definition for one specific board for HW which was added to linux kernel in v4.2-rc1 version. For me it looks like that needed DT definition was forgotten...
On Wed, Jan 27, 2016 at 11:02:37AM +0100, Pali Rohár wrote: > In my opinion this patch is not support for new hardware. It just add > missing DT definition for one specific board for HW which was added to > linux kernel in v4.2-rc1 version. For me it looks like that needed DT > definition was forgotten... Opinions differ, but ultimately it's up to whoever is responsible for accepting the patch, and in the case of ARM SoC based patches, the arm-soc maintainers. The arm-soc maintainers close their trees for development changes a few weeks before hand (a patch of mine which was acked etc by 7th December never made the 4.5 merge window either, and the alleged reason I've been told is because arm-soc was already closed by then).
* Russell King - ARM Linux <linux@arm.linux.org.uk> [160127 03:19]: > On Wed, Jan 27, 2016 at 11:02:37AM +0100, Pali Rohár wrote: > > In my opinion this patch is not support for new hardware. It just add > > missing DT definition for one specific board for HW which was added to > > linux kernel in v4.2-rc1 version. For me it looks like that needed DT > > definition was forgotten... > > Opinions differ, but ultimately it's up to whoever is responsible for > accepting the patch, and in the case of ARM SoC based patches, the > arm-soc maintainers. Yeah. Sorry for long delay as discussed. I'm applying the $subject patch finally into omap-for-v4.6/dt today. We still have at least two fixes left to go that both affect also n900. But at least I can now sanely test adding new stuff with a WIP fix for the PM runtime regression. > The arm-soc maintainers close their trees for development changes a > few weeks before hand (a patch of mine which was acked etc by 7th > December never made the 4.5 merge window either, and the alleged > reason I've been told is because arm-soc was already closed by then). Heh I too have some pending clock framework patches from December that I did not repost yet as the maintainers notified that they rather not take new stuff any longer for v4.5 before the holidays. Regards, Tony
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts index 5f5e0f3..ba93642 100644 --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -522,6 +522,21 @@ amstaos,cover-comp-gain = <16>; }; + adp1653: led-controller@30 { + compatible = "adi,adp1653"; + reg = <0x30>; + enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */ + + flash { + flash-timeout-us = <500000>; + flash-max-microamp = <320000>; + led-max-microamp = <50000>; + }; + indicator { + led-max-microamp = <17500>; + }; + }; + lp5523: lp5523@32 { compatible = "national,lp5523"; reg = <0x32>;
This patch adds adp1653 device into n900 DT structure. DT support in adp1653 driver is there since v4.2-rc1 version. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> --- arch/arm/boot/dts/omap3-n900.dts | 15 +++++++++++++++ 1 file changed, 15 insertions(+)