This series adds a driver for a 7-segment LED display.
I think I've addressed all of Andy's feedback in this round. I haven't
heard from the ARM maintainers on any of the previous rounds. At Andy's
request I've dropped the USB LED change as it's not related. I can
submit the dts change separately if required, I've mostly been including
it so there is an in-tree user of the driver I'm adding.
Chris Packham (3):
auxdisplay: Add 7-segment LED display driver
dt-bindings: auxdisplay: Add bindings for generic 7-segment LED
ARM: dts: marvell: Add 7-segment LED display on x530
.../bindings/auxdisplay/gpio-7-segment.yaml | 55 +++++++++
.../boot/dts/marvell/armada-385-atl-x530.dts | 13 +-
drivers/auxdisplay/Kconfig | 11 ++
drivers/auxdisplay/Makefile | 1 +
drivers/auxdisplay/seg-led-gpio.c | 112 ++++++++++++++++++
5 files changed, 191 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/auxdisplay/gpio-7-segment.yaml
create mode 100644 drivers/auxdisplay/seg-led-gpio.c
--
2.43.2
Add a driver for a 7-segment LED display. At the moment only one
character is supported but it should be possible to expand this to
support more characters and/or 14-segment displays in the future.
Signed-off-by: Chris Packham <[email protected]>
---
Notes:
Changes in v5:
- Add depends on GPIOLIB || COMPILE_TEST
- Validate that we get enough GPIOs
Changes in v4:
- Fix one more usage of 7 segment
- Move ASCII art diagram to DT binding
- Include map_to_7segment.h for map_to_seg7()
- Use initialiser for values in seg_led_update
Changes in v3:
- "7 segment" -> "7-Segment" in Kconfig help text
- Update after feedback from Andy
- Use compatible = "gpio-7-segment" as suggested by Rob
Changes in v2:
- Rebased on top of auxdisplay/for-next dropping unnecessary code for 7
segment maps.
- Update for new linedisp_register() API
- Include headers based on actual usage
- Allow building as module
- Use compatible = "generic-gpio-7seg" to keep checkpatch.pl happy
drivers/auxdisplay/Kconfig | 11 +++
drivers/auxdisplay/Makefile | 1 +
drivers/auxdisplay/seg-led-gpio.c | 112 ++++++++++++++++++++++++++++++
3 files changed, 124 insertions(+)
create mode 100644 drivers/auxdisplay/seg-led-gpio.c
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index d4be0a3695ce..151d95f96b11 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -211,6 +211,17 @@ config ARM_CHARLCD
line and the Linux version on the second line, but that's
still useful.
+config SEG_LED_GPIO
+ tristate "Generic 7-segment LED display"
+ depends on GPIOLIB || COMPILE_TEST
+ select LINEDISP
+ help
+ This driver supports a generic 7-segment LED display made up
+ of GPIO pins connected to the individual segments.
+
+ This driver can also be built as a module. If so, the module
+ will be called seg-led-gpio.
+
menuconfig PARPORT_PANEL
tristate "Parallel port LCD/Keypad Panel support"
depends on PARPORT
diff --git a/drivers/auxdisplay/Makefile b/drivers/auxdisplay/Makefile
index a725010ca651..4a8ea41b0550 100644
--- a/drivers/auxdisplay/Makefile
+++ b/drivers/auxdisplay/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_PARPORT_PANEL) += panel.o
obj-$(CONFIG_LCD2S) += lcd2s.o
obj-$(CONFIG_LINEDISP) += line-display.o
obj-$(CONFIG_MAX6959) += max6959.o
+obj-$(CONFIG_SEG_LED_GPIO) += seg-led-gpio.o
diff --git a/drivers/auxdisplay/seg-led-gpio.c b/drivers/auxdisplay/seg-led-gpio.c
new file mode 100644
index 000000000000..ebf6028a1dfa
--- /dev/null
+++ b/drivers/auxdisplay/seg-led-gpio.c
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for a 7-segment LED display
+ *
+ * The decimal point LED present on some devices is currently not
+ * supported.
+ *
+ * Copyright (C) Allied Telesis Labs
+ */
+
+#include <linux/bitmap.h>
+#include <linux/container_of.h>
+#include <linux/errno.h>
+#include <linux/gpio/consumer.h>
+#include <linux/map_to_7segment.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/workqueue.h>
+
+#include "line-display.h"
+
+struct seg_led_priv {
+ struct linedisp linedisp;
+ struct delayed_work work;
+ struct gpio_descs *segment_gpios;
+};
+
+static void seg_led_update(struct work_struct *work)
+{
+ struct seg_led_priv *priv = container_of(work, struct seg_led_priv, work.work);
+ struct linedisp *linedisp = &priv->linedisp;
+ struct linedisp_map *map = linedisp->map;
+ DECLARE_BITMAP(values, 8) = { 0 };
+
+ bitmap_set_value8(values, map_to_seg7(&map->map.seg7, linedisp->buf[0]), 0);
+
+ gpiod_set_array_value_cansleep(priv->segment_gpios->ndescs, priv->segment_gpios->desc,
+ priv->segment_gpios->info, values);
+}
+
+static int seg_led_linedisp_get_map_type(struct linedisp *linedisp)
+{
+ struct seg_led_priv *priv = container_of(linedisp, struct seg_led_priv, linedisp);
+
+ INIT_DELAYED_WORK(&priv->work, seg_led_update);
+ return LINEDISP_MAP_SEG7;
+}
+
+static void seg_led_linedisp_update(struct linedisp *linedisp)
+{
+ struct seg_led_priv *priv = container_of(linedisp, struct seg_led_priv, linedisp);
+
+ schedule_delayed_work(&priv->work, 0);
+}
+
+static const struct linedisp_ops seg_led_linedisp_ops = {
+ .get_map_type = seg_led_linedisp_get_map_type,
+ .update = seg_led_linedisp_update,
+};
+
+static int seg_led_probe(struct platform_device *pdev)
+{
+ struct seg_led_priv *priv;
+ struct device *dev = &pdev->dev;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+
+ priv->segment_gpios = devm_gpiod_get_array(dev, "segment", GPIOD_OUT_LOW);
+ if (IS_ERR(priv->segment_gpios))
+ return PTR_ERR(priv->segment_gpios);
+
+ if (priv->segment_gpios->ndescs < 7)
+ return -EINVAL;
+
+ return linedisp_register(&priv->linedisp, dev, 1, &seg_led_linedisp_ops);
+}
+
+static int seg_led_remove(struct platform_device *pdev)
+{
+ struct seg_led_priv *priv = platform_get_drvdata(pdev);
+
+ cancel_delayed_work_sync(&priv->work);
+ linedisp_unregister(&priv->linedisp);
+
+ return 0;
+}
+
+static const struct of_device_id seg_led_of_match[] = {
+ { .compatible = "gpio-7-segment"},
+ {}
+};
+MODULE_DEVICE_TABLE(of, seg_led_of_match);
+
+static struct platform_driver seg_led_driver = {
+ .probe = seg_led_probe,
+ .remove = seg_led_remove,
+ .driver = {
+ .name = "seg-led-gpio",
+ .of_match_table = seg_led_of_match,
+ },
+};
+module_platform_driver(seg_led_driver);
+
+MODULE_AUTHOR("Chris Packham <[email protected]>");
+MODULE_DESCRIPTION("7 segment LED driver");
+MODULE_LICENSE("GPL");
--
2.43.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 <[email protected]>
---
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 Thu, Mar 07, 2024 at 12:50:18PM +1300, Chris Packham wrote:
> This series adds a driver for a 7-segment LED display.
>
> I think I've addressed all of Andy's feedback in this round. I haven't
> heard from the ARM maintainers on any of the previous rounds. At Andy's
> request I've dropped the USB LED change as it's not related. I can
> submit the dts change separately if required, I've mostly been including
> it so there is an in-tree user of the driver I'm adding.
All LGTM, I need a Geert's Ack/Rb on the first one and DT maintainer on
the second. The third one I have no clue by heart who, but somebody related
should also give a tag.
--
With Best Regards,
Andy Shevchenko
Hi Chris,
On Thu, Mar 7, 2024 at 12:50 AM Chris Packham
<[email protected]> wrote:
> Add a driver for a 7-segment LED display. At the moment only one
> character is supported but it should be possible to expand this to
> support more characters and/or 14-segment displays in the future.
>
> Signed-off-by: Chris Packham <[email protected]>
> ---
>
> Notes:
> Changes in v5:
> - Add depends on GPIOLIB || COMPILE_TEST
> - Validate that we get enough GPIOs
Thanks for the update!
> --- /dev/null
> +++ b/drivers/auxdisplay/seg-led-gpio.c
> +static void seg_led_update(struct work_struct *work)
> +{
> + struct seg_led_priv *priv = container_of(work, struct seg_led_priv, work.work);
> + struct linedisp *linedisp = &priv->linedisp;
> + struct linedisp_map *map = linedisp->map;
> + DECLARE_BITMAP(values, 8) = { 0 };
> +
> + bitmap_set_value8(values, map_to_seg7(&map->map.seg7, linedisp->buf[0]), 0);
> +
> + gpiod_set_array_value_cansleep(priv->segment_gpios->ndescs, priv->segment_gpios->desc,
> + priv->segment_gpios->info, values);
This may still cause an out-of-bounds access of values if ndescs > 8.
> +}
> +static int seg_led_probe(struct platform_device *pdev)
> +{
> + struct seg_led_priv *priv;
> + struct device *dev = &pdev->dev;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> +
> + priv->segment_gpios = devm_gpiod_get_array(dev, "segment", GPIOD_OUT_LOW);
> + if (IS_ERR(priv->segment_gpios))
> + return PTR_ERR(priv->segment_gpios);
> +
> + if (priv->segment_gpios->ndescs < 7)
|| priv->segment_gpios->ndescs > 8
> + return -EINVAL;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Mar 07, 2024 at 02:13:23PM +0100, Geert Uytterhoeven wrote:
> On Thu, Mar 7, 2024 at 12:50 AM Chris Packham
> <[email protected]> wrote:
..
> > + DECLARE_BITMAP(values, 8) = { 0 };
While doing next version, drop this '0', as we have in another terminator
the same approach (i.o.w. for the sake of consistency).
..
> > + gpiod_set_array_value_cansleep(priv->segment_gpios->ndescs, priv->segment_gpios->desc,
> > + priv->segment_gpios->info, values);
>
> This may still cause an out-of-bounds access of values if ndescs > 8.
Not really. It will be only for ndescs >= 32 (on 32-bit) or 64
(on 64-bit accordingly).
But good catch, we better to narrow the range down.
--
With Best Regards,
Andy Shevchenko
Chris Packham <[email protected]> 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 <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
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
>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT
<[email protected]> wrote:
>
> Chris Packham <[email protected]> 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 <[email protected]>
>
> Acked-by: Gregory CLEMENT <[email protected]>
>
> 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.
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 8, 2024, at 10:56, Andy Shevchenko wrote:
> On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT
> <[email protected]> wrote:
>>
>> Chris Packham <[email protected]> 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 <[email protected]>
>>
>> Acked-by: Gregory CLEMENT <[email protected]>
>>
>> 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 <[email protected]> wrote:
> On Fri, Mar 8, 2024, at 10:56, Andy Shevchenko wrote:
> > On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT
> > <[email protected]> wrote:
> >> Chris Packham <[email protected]> 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 <[email protected]>
> >>
> >> Acked-by: Gregory CLEMENT <[email protected]>
> >>
> >> 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.
--
With Best Regards,
Andy Shevchenko
On 8/03/24 23:34, Andy Shevchenko wrote:
> On Fri, Mar 8, 2024 at 12:19 PM Arnd Bergmann <[email protected]> wrote:
>> On Fri, Mar 8, 2024, at 10:56, Andy Shevchenko wrote:
>>> On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT
>>> <[email protected]> wrote:
>>>> Chris Packham <[email protected]> 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 <[email protected]>
>>>> Acked-by: Gregory CLEMENT <[email protected]>
>>>>
>>>> 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 <[email protected]> wrote:
>>> On Fri, Mar 8, 2024, at 10:56, Andy Shevchenko wrote:
>>>> On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT <[email protected]> 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 <[email protected]> wrote:
>>>> On Fri, Mar 8, 2024, at 10:56, Andy Shevchenko wrote:
>>>>> On Fri, Mar 8, 2024 at 9:36 AM Gregory CLEMENT <[email protected]> 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.