| Message ID | 20240306235021.976083-4-chris.packham@alliedtelesis.co.nz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | auxdisplay: 7-segment LED display | expand |
Chris Packham <chris.packham@alliedtelesis.co.nz> writes: > The Allied Telesis x530 products have a 7-segment LED display which is > used for node identification when the devices are stacked. Represent > this as a gpio-7-segment device. > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Normally, this patch should be taken in mvebu and then merged by arm-soc. However, I haven't seen any other patch touching this file (so no risk of merge conflict) and I think it's too late for me to make a new pull request to arm-soc. So I'm not against it being taken with the rest of the patches. However, I think it would be a good idea to see what Arnd thinks about it. Gregory > --- > > Notes: > Changes in v5: > - group GPIO specifiers > Changes in v4: > - Use correct compatible name in commit message > Changes in v3: > - Use compatible = "gpio-7-segment" as suggested by Rob > Changes in v2: > - Use compatible = "generic-gpio-7seg" to keep checkpatch.pl happy > > arch/arm/boot/dts/marvell/armada-385-atl-x530.dts | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/marvell/armada-385-atl-x530.dts b/arch/arm/boot/dts/marvell/armada-385-atl-x530.dts > index 5a9ab8410b7b..2fb7304039be 100644 > --- a/arch/arm/boot/dts/marvell/armada-385-atl-x530.dts > +++ b/arch/arm/boot/dts/marvell/armada-385-atl-x530.dts > @@ -43,6 +43,17 @@ uart0: serial@12000 { > }; > }; > }; > + > + led-7seg { > + compatible = "gpio-7-segment"; > + segment-gpios = <&led_7seg_gpio 0 GPIO_ACTIVE_LOW>, > + <&led_7seg_gpio 1 GPIO_ACTIVE_LOW>, > + <&led_7seg_gpio 2 GPIO_ACTIVE_LOW>, > + <&led_7seg_gpio 3 GPIO_ACTIVE_LOW>, > + <&led_7seg_gpio 4 GPIO_ACTIVE_LOW>, > + <&led_7seg_gpio 5 GPIO_ACTIVE_LOW>, > + <&led_7seg_gpio 6 GPIO_ACTIVE_LOW>; > + }; > }; > > &pciec { > @@ -149,7 +160,7 @@ i2c@3 { > #size-cells = <0>; > reg = <3>; > > - gpio@20 { > + led_7seg_gpio: gpio@20 { > compatible = "nxp,pca9554"; > gpio-controller; > #gpio-cells = <2>; > -- > 2.43.2 >
On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT <gregory.clement@bootlin.com> wrote: > > Chris Packham <chris.packham@alliedtelesis.co.nz> writes: > > > The Allied Telesis x530 products have a 7-segment LED display which is > > used for node identification when the devices are stacked. Represent > > this as a gpio-7-segment device. > > > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > > Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> > > Normally, this patch should be taken in mvebu and then merged by > arm-soc. However, I haven't seen any other patch touching this file (so > no risk of merge conflict) and I think it's too late for me to make a > new pull request to arm-soc. So I'm not against it being taken with the > rest of the patches. However, I think it would be a good idea to see > what Arnd thinks about it. Arnd wasn't Cc'ed, now I added him.
On Fri, Mar 8, 2024, at 10:56, Andy Shevchenko wrote: > On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT > <gregory.clement@bootlin.com> wrote: >> >> Chris Packham <chris.packham@alliedtelesis.co.nz> writes: >> >> > The Allied Telesis x530 products have a 7-segment LED display which is >> > used for node identification when the devices are stacked. Represent >> > this as a gpio-7-segment device. >> > >> > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >> >> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> >> >> Normally, this patch should be taken in mvebu and then merged by >> arm-soc. However, I haven't seen any other patch touching this file (so >> no risk of merge conflict) and I think it's too late for me to make a >> new pull request to arm-soc. So I'm not against it being taken with the >> rest of the patches. However, I think it would be a good idea to see >> what Arnd thinks about it. > > Arnd wasn't Cc'ed, now I added him. I already have a 'late' branch for stuff that for some reason was too late be part of the normal pull requests but should still make it into 6.9. If this one is important, I don't mind taking it. On the other hand, from the patch description this one doesn't seem that urgent, so I don't see much harm in delaying it to v6.10, and using the normal process for it. Arnd
On Fri, Mar 8, 2024 at 12:19 PM Arnd Bergmann <arnd@kernel.org> wrote: > On Fri, Mar 8, 2024, at 10:56, Andy Shevchenko wrote: > > On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT > > <gregory.clement@bootlin.com> wrote: > >> Chris Packham <chris.packham@alliedtelesis.co.nz> writes: > >> > >> > The Allied Telesis x530 products have a 7-segment LED display which is > >> > used for node identification when the devices are stacked. Represent > >> > this as a gpio-7-segment device. > >> > > >> > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > >> > >> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> > >> > >> Normally, this patch should be taken in mvebu and then merged by > >> arm-soc. However, I haven't seen any other patch touching this file (so > >> no risk of merge conflict) and I think it's too late for me to make a > >> new pull request to arm-soc. So I'm not against it being taken with the > >> rest of the patches. However, I think it would be a good idea to see > >> what Arnd thinks about it. > > > > Arnd wasn't Cc'ed, now I added him. > > I already have a 'late' branch for stuff that for some reason > was too late be part of the normal pull requests but should > still make it into 6.9. If this one is important, I don't > mind taking it. > > On the other hand, from the patch description this one doesn't > seem that urgent, so I don't see much harm in delaying it > to v6.10, and using the normal process for it. Thanks, I will defer this one then. Chris, please handle this one after v6.9-rc1 is out. The first two I'm going to take today.
On 8/03/24 23:34, Andy Shevchenko wrote: > On Fri, Mar 8, 2024 at 12:19 PM Arnd Bergmann <arnd@kernel.org> wrote: >> On Fri, Mar 8, 2024, at 10:56, Andy Shevchenko wrote: >>> On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT >>> <gregory.clement@bootlin.com> wrote: >>>> Chris Packham <chris.packham@alliedtelesis.co.nz> writes: >>>> >>>>> The Allied Telesis x530 products have a 7-segment LED display which is >>>>> used for node identification when the devices are stacked. Represent >>>>> this as a gpio-7-segment device. >>>>> >>>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >>>> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> >>>> >>>> Normally, this patch should be taken in mvebu and then merged by >>>> arm-soc. However, I haven't seen any other patch touching this file (so >>>> no risk of merge conflict) and I think it's too late for me to make a >>>> new pull request to arm-soc. So I'm not against it being taken with the >>>> rest of the patches. However, I think it would be a good idea to see >>>> what Arnd thinks about it. >>> Arnd wasn't Cc'ed, now I added him. >> I already have a 'late' branch for stuff that for some reason >> was too late be part of the normal pull requests but should >> still make it into 6.9. If this one is important, I don't >> mind taking it. >> >> On the other hand, from the patch description this one doesn't >> seem that urgent, so I don't see much harm in delaying it >> to v6.10, and using the normal process for it. > Thanks, I will defer this one then. > Chris, please handle this one after v6.9-rc1 is out. The first two I'm > going to take today. > No problem. I can send the dts changes separately. FYI ./scripts/get_maintainer.pl -f arch/arm/boot/dts/marvell isn't picking up Arnd should it?
On Sun, Mar 10, 2024, at 21:22, Chris Packham wrote: > On 8/03/24 23:34, Andy Shevchenko wrote: >> On Fri, Mar 8, 2024 at 12:19 PM Arnd Bergmann <arnd@kernel.org> wrote: >>> On Fri, Mar 8, 2024, at 10:56, Andy Shevchenko wrote: >>>> On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT <gregory.clement@bootlin.com> wrote: >>>>> >>>>> Normally, this patch should be taken in mvebu and then merged by >>>>> arm-soc. However, I haven't seen any other patch touching this file (so >>>>> no risk of merge conflict) and I think it's too late for me to make a >>>>> new pull request to arm-soc. So I'm not against it being taken with the >>>>> rest of the patches. However, I think it would be a good idea to see >>>>> what Arnd thinks about it. > > FYI ./scripts/get_maintainer.pl -f arch/arm/boot/dts/marvell isn't > picking up Arnd should it? No, as Gregory writes, the intended way for platform specific patches is to go through the maintainer for that platform, in this case him, who then sends pull requests to me. Since it was late in the merge window, he suggested skipping this step as an exception, which is something we can always do if there is an important reason, just like you skip can all maintainers and go directly to Linus if necessary, but the maintainers file only documents the normal case. Arnd
On 11/03/24 19:02, Arnd Bergmann wrote: > On Sun, Mar 10, 2024, at 21:22, Chris Packham wrote: >> On 8/03/24 23:34, Andy Shevchenko wrote: >>> On Fri, Mar 8, 2024 at 12:19 PM Arnd Bergmann <arnd@kernel.org> wrote: >>>> On Fri, Mar 8, 2024, at 10:56, Andy Shevchenko wrote: >>>>> On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT <gregory.clement@bootlin.com> wrote: >>>>>> Normally, this patch should be taken in mvebu and then merged by >>>>>> arm-soc. However, I haven't seen any other patch touching this file (so >>>>>> no risk of merge conflict) and I think it's too late for me to make a >>>>>> new pull request to arm-soc. So I'm not against it being taken with the >>>>>> rest of the patches. However, I think it would be a good idea to see >>>>>> what Arnd thinks about it. >> FYI ./scripts/get_maintainer.pl -f arch/arm/boot/dts/marvell isn't >> picking up Arnd should it? > No, as Gregory writes, the intended way for platform specific > patches is to go through the maintainer for that platform, > in this case him, who then sends pull requests to me. > > Since it was late in the merge window, he suggested skipping > this step as an exception, which is something we can always do > if there is an important reason, just like you skip can all > maintainers and go directly to Linus if necessary, but the > maintainers file only documents the normal case. OK thanks for the clarification. I don't think there is any reason to rush this. I'll send a new series for this DTS change and one other that I have for the x530 via Gregory and it can come through for either 6.9 or 6.10.
diff --git a/arch/arm/boot/dts/marvell/armada-385-atl-x530.dts b/arch/arm/boot/dts/marvell/armada-385-atl-x530.dts index 5a9ab8410b7b..2fb7304039be 100644 --- a/arch/arm/boot/dts/marvell/armada-385-atl-x530.dts +++ b/arch/arm/boot/dts/marvell/armada-385-atl-x530.dts @@ -43,6 +43,17 @@ uart0: serial@12000 { }; }; }; + + led-7seg { + compatible = "gpio-7-segment"; + segment-gpios = <&led_7seg_gpio 0 GPIO_ACTIVE_LOW>, + <&led_7seg_gpio 1 GPIO_ACTIVE_LOW>, + <&led_7seg_gpio 2 GPIO_ACTIVE_LOW>, + <&led_7seg_gpio 3 GPIO_ACTIVE_LOW>, + <&led_7seg_gpio 4 GPIO_ACTIVE_LOW>, + <&led_7seg_gpio 5 GPIO_ACTIVE_LOW>, + <&led_7seg_gpio 6 GPIO_ACTIVE_LOW>; + }; }; &pciec { @@ -149,7 +160,7 @@ i2c@3 { #size-cells = <0>; reg = <3>; - gpio@20 { + led_7seg_gpio: gpio@20 { compatible = "nxp,pca9554"; gpio-controller; #gpio-cells = <2>;
The Allied Telesis x530 products have a 7-segment LED display which is used for node identification when the devices are stacked. Represent this as a gpio-7-segment device. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> --- Notes: Changes in v5: - group GPIO specifiers Changes in v4: - Use correct compatible name in commit message Changes in v3: - Use compatible = "gpio-7-segment" as suggested by Rob Changes in v2: - Use compatible = "generic-gpio-7seg" to keep checkpatch.pl happy arch/arm/boot/dts/marvell/armada-385-atl-x530.dts | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)