| Message ID | 20230405160258.46998-1-cniedermaier@dh-electronics.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | [1/2] dt-bindings: arm: fsl: Add Marantec maveo box as a DHCOR i.MX6ULL SoM based board | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | success | |
| robh/dtbs-check | warning | build log |
| robh/dt-meta-schema | success |
On 4/5/23 18:02, Christoph Niedermaier wrote: [...] > +/ { > + model = "DH electronics i.MX6ULL DHCOR on maveo box"; > + compatible = "dh,imx6ull-dhcor-maveo-box", "dh,imx6ull-dhcor-som", > + "fsl,imx6ull"; > + > + aliases { > + /delete-property/ mmc0; /* Avoid double definitions */ > + /delete-property/ mmc1; > + mmc2 = &usdhc2; /* eMMC should be mmc2 */ Why not mmc0 ? Use root=PARTUUID= when booting to avoid any dependency on root=/dev/mmcblk2pN enumeration. > + spi0 = &ecspi4; > + spi3 = &ecspi1; > + }; [...] > +&iomuxc { > + pinctrl-0 = <&pinctrl_hog_maveo_box>; > + pinctrl-names = "default"; > + > + pinctrl_hog_maveo_box: hog-maveo-box-grp { > + fsl,pins = < > + MX6UL_PAD_GPIO1_IO05__GPIO1_IO05 0x400120b0 /* BUTTON_USER */ > + MX6UL_PAD_GPIO1_IO08__GPIO1_IO08 0x400120b0 /* BUTTON_RESET */ > + MX6UL_PAD_CSI_PIXCLK__GPIO4_IO18 0x400120b0 /* LED_G */ > + MX6UL_PAD_CSI_DATA02__GPIO4_IO23 0x400120b0 /* LED_B */ Should the "SION(1 << 30): Software Input On Field." bit really be set on GPIOs which are OUTPUT (like LEDs) ? [...]
On 4/5/23 18:02, Christoph Niedermaier wrote: > Add Marantec maveo box. The system is used to get a smart conntection > to a door drive. The core of this system is a soldered i.MX6ULL DHCOR > SoM from DH electronics. > > Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> > --- > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > Cc: Shawn Guo <shawnguo@kernel.org> > CC: Li Yang <leoyang.li@nxp.com> > Cc: Marek Vasut <marex@denx.de> > Cc: Fabio Estevam <festevam@denx.de> > Cc: NXP Linux Team <linux-imx@nxp.com> > Cc: kernel@dh-electronics.com > Cc: devicetree@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > To: linux-arm-kernel@lists.infradead.org > --- > Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml > index b175f2b1bd30..c95254c57571 100644 > --- a/Documentation/devicetree/bindings/arm/fsl.yaml > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml > @@ -717,6 +717,12 @@ properties: > - const: dh,imx6ull-dhcor-som > - const: fsl,imx6ull > > + - description: i.MX6ULL DHCOR SoM based Boards > + items: > + - const: dh,imx6ull-dhcor-maveo-box This should be using Marantec vendor prefix, not "dh," prefix I think ? You should add that to Documentation/devicetree/bindings/vendor-prefixes.yaml first, and then use it here.
From: Marek Vasut [mailto:marex@denx.de] Sent: Wednesday, April 5, 2023 6:26 PM > On 4/5/23 18:02, Christoph Niedermaier wrote: >> Add Marantec maveo box. The system is used to get a smart conntection >> to a door drive. The core of this system is a soldered i.MX6ULL DHCOR >> SoM from DH electronics. >> >> Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> >> --- >> Cc: Rob Herring <robh+dt@kernel.org> >> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> >> Cc: Shawn Guo <shawnguo@kernel.org> >> CC: Li Yang <leoyang.li@nxp.com> >> Cc: Marek Vasut <marex@denx.de> >> Cc: Fabio Estevam <festevam@denx.de> >> Cc: NXP Linux Team <linux-imx@nxp.com> >> Cc: kernel@dh-electronics.com >> Cc: devicetree@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> To: linux-arm-kernel@lists.infradead.org >> --- >> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml >> index b175f2b1bd30..c95254c57571 100644 >> --- a/Documentation/devicetree/bindings/arm/fsl.yaml >> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml >> @@ -717,6 +717,12 @@ properties: >> - const: dh,imx6ull-dhcor-som >> - const: fsl,imx6ull >> >> + - description: i.MX6ULL DHCOR SoM based Boards >> + items: >> + - const: dh,imx6ull-dhcor-maveo-box > > This should be using Marantec vendor prefix, not "dh," prefix I think ? > > You should add that to > Documentation/devicetree/bindings/vendor-prefixes.yaml first, and then > use it here. I will change it in version 2.
From: Marek Vasut [mailto:marex@denx.de] Sent: Wednesday, April 5, 2023 6:25 PM > On 4/5/23 18:02, Christoph Niedermaier wrote: > > [...] > >> +/ { >> + model = "DH electronics i.MX6ULL DHCOR on maveo box"; >> + compatible = "dh,imx6ull-dhcor-maveo-box", "dh,imx6ull-dhcor-som", >> + "fsl,imx6ull"; >> + >> + aliases { >> + /delete-property/ mmc0; /* Avoid double definitions */ >> + /delete-property/ mmc1; >> + mmc2 = &usdhc2; /* eMMC should be mmc2 */ > > Why not mmc0 ? > > Use root=PARTUUID= when booting to avoid any dependency on > root=/dev/mmcblk2pN enumeration. This is due to software interchangeability with the DHCOM i.MX6ULL, where the eMMC is always mmc2. > >> + spi0 = &ecspi4; >> + spi3 = &ecspi1; >> + }; > > [...] > >> +&iomuxc { >> + pinctrl-0 = <&pinctrl_hog_maveo_box>; >> + pinctrl-names = "default"; >> + >> + pinctrl_hog_maveo_box: hog-maveo-box-grp { >> + fsl,pins = < >> + MX6UL_PAD_GPIO1_IO05__GPIO1_IO05 0x400120b0 /* BUTTON_USER */ >> + MX6UL_PAD_GPIO1_IO08__GPIO1_IO08 0x400120b0 /* BUTTON_RESET */ >> + MX6UL_PAD_CSI_PIXCLK__GPIO4_IO18 0x400120b0 /* LED_G */ >> + MX6UL_PAD_CSI_DATA02__GPIO4_IO23 0x400120b0 /* LED_B */ > > Should the "SION(1 << 30): Software Input On Field." bit really be set > on GPIOs which are OUTPUT (like LEDs) ? I think for INPUT it doesn't matter, but for OUTPUT I then have a feedback. Regards Christoph
On 4/5/23 20:24, Christoph Niedermaier wrote: > From: Marek Vasut [mailto:marex@denx.de] > Sent: Wednesday, April 5, 2023 6:25 PM >> On 4/5/23 18:02, Christoph Niedermaier wrote: >> >> [...] >> >>> +/ { >>> + model = "DH electronics i.MX6ULL DHCOR on maveo box"; >>> + compatible = "dh,imx6ull-dhcor-maveo-box", "dh,imx6ull-dhcor-som", >>> + "fsl,imx6ull"; >>> + >>> + aliases { >>> + /delete-property/ mmc0; /* Avoid double definitions */ >>> + /delete-property/ mmc1; >>> + mmc2 = &usdhc2; /* eMMC should be mmc2 */ >> >> Why not mmc0 ? >> >> Use root=PARTUUID= when booting to avoid any dependency on >> root=/dev/mmcblk2pN enumeration. > > This is due to software interchangeability with the DHCOM > i.MX6ULL, where the eMMC is always mmc2. +CC Ulf , I vaguely recall some discussion about this enumeration and I am not sure one can really depend on that.
From: Marek Vasut [mailto:marex@denx.de] Sent: Wednesday, April 5, 2023 8:47 PM > On 4/5/23 20:24, Christoph Niedermaier wrote: >> From: Marek Vasut [mailto:marex@denx.de] >> Sent: Wednesday, April 5, 2023 6:25 PM >>> On 4/5/23 18:02, Christoph Niedermaier wrote: >>> >>> [...] >>> >>>> +/ { >>>> + model = "DH electronics i.MX6ULL DHCOR on maveo box"; >>>> + compatible = "dh,imx6ull-dhcor-maveo-box", "dh,imx6ull-dhcor-som", >>>> + "fsl,imx6ull"; >>>> + >>>> + aliases { >>>> + /delete-property/ mmc0; /* Avoid double definitions */ >>>> + /delete-property/ mmc1; >>>> + mmc2 = &usdhc2; /* eMMC should be mmc2 */ >>> >>> Why not mmc0 ? >>> >>> Use root=PARTUUID= when booting to avoid any dependency on >>> root=/dev/mmcblk2pN enumeration. >> >> This is due to software interchangeability with the DHCOM >> i.MX6ULL, where the eMMC is always mmc2. > > +CC Ulf , I vaguely recall some discussion about this enumeration and I > am not sure one can really depend on that. That why I think it good to have a defined number for mmcblk devices on an embedded system. An excerpt from [1]: Alternative solutions like PARTUUIDs do not cover the case where multiple mmcblk devices contain the same image. This is a common issue on devices that can boot both from eMMC (for regular boot) and SD cards (as a temporary boot medium for development). When a firmware image is installed to eMMC after a test boot via SD card, there will be no reliable way to refer to a specific device using (PART)UUIDs oder LABELs [1] https://patchwork.kernel.org/project/linux-mmc/patch/20200825134441.17537-2-matthias.schiffer@ew.tq-group.com/ So far I have never had a problem with numbering mmcblk devices via aliases. Regards Christoph
On 4/6/23 10:37, Christoph Niedermaier wrote: > From: Marek Vasut [mailto:marex@denx.de] > Sent: Wednesday, April 5, 2023 8:47 PM >> On 4/5/23 20:24, Christoph Niedermaier wrote: >>> From: Marek Vasut [mailto:marex@denx.de] >>> Sent: Wednesday, April 5, 2023 6:25 PM >>>> On 4/5/23 18:02, Christoph Niedermaier wrote: >>>> >>>> [...] >>>> >>>>> +/ { >>>>> + model = "DH electronics i.MX6ULL DHCOR on maveo box"; >>>>> + compatible = "dh,imx6ull-dhcor-maveo-box", "dh,imx6ull-dhcor-som", >>>>> + "fsl,imx6ull"; >>>>> + >>>>> + aliases { >>>>> + /delete-property/ mmc0; /* Avoid double definitions */ >>>>> + /delete-property/ mmc1; >>>>> + mmc2 = &usdhc2; /* eMMC should be mmc2 */ >>>> >>>> Why not mmc0 ? >>>> >>>> Use root=PARTUUID= when booting to avoid any dependency on >>>> root=/dev/mmcblk2pN enumeration. >>> >>> This is due to software interchangeability with the DHCOM >>> i.MX6ULL, where the eMMC is always mmc2. >> >> +CC Ulf , I vaguely recall some discussion about this enumeration and I >> am not sure one can really depend on that. > > That why I think it good to have a defined number for mmcblk devices > on an embedded system. An excerpt from [1]: I might be misremembering this, but could it be that, if any non-OF SDMMC controller probes early and hogs the /dev/mmcblk2 before the OF ones have a chance to probe, then the OF ones would fail to probe ? > Alternative solutions like PARTUUIDs do not cover the case where multiple > mmcblk devices contain the same image. I agree, this is indeed a downside of PARTUUID . > This is a common issue on devices > that can boot both from eMMC (for regular boot) and SD cards (as a > temporary boot medium for development). When a firmware image is > installed to eMMC after a test boot via SD card, there will be no > reliable way to refer to a specific device using (PART)UUIDs oder > LABELs This can be solved by the installer updating the PARTUUID on the eMMC however. > [1] https://patchwork.kernel.org/project/linux-mmc/patch/20200825134441.17537-2-matthias.schiffer@ew.tq-group.com/ > > So far I have never had a problem with numbering mmcblk devices via aliases. Based on the above, I don't think either the aliases or PARTUUID is a perfect solution, but the aliases should be fine for mx6ull at least? So I think we can conclude this discussion thread ?
From: Marek Vasut [mailto:marex@denx.de] Sent: Thursday, April 6, 2023 4:10 PM > On 4/6/23 10:37, Christoph Niedermaier wrote: >> From: Marek Vasut [mailto:marex@denx.de] >> Sent: Wednesday, April 5, 2023 8:47 PM >>> On 4/5/23 20:24, Christoph Niedermaier wrote: >>>> From: Marek Vasut [mailto:marex@denx.de] >>>> Sent: Wednesday, April 5, 2023 6:25 PM >>>>> On 4/5/23 18:02, Christoph Niedermaier wrote: >>>>> >>>>> [...] >>>>> >>>>>> +/ { >>>>>> + model = "DH electronics i.MX6ULL DHCOR on maveo box"; >>>>>> + compatible = "dh,imx6ull-dhcor-maveo-box", "dh,imx6ull-dhcor-som", >>>>>> + "fsl,imx6ull"; >>>>>> + >>>>>> + aliases { >>>>>> + /delete-property/ mmc0; /* Avoid double definitions */ >>>>>> + /delete-property/ mmc1; >>>>>> + mmc2 = &usdhc2; /* eMMC should be mmc2 */ >>>>> >>>>> Why not mmc0 ? >>>>> >>>>> Use root=PARTUUID= when booting to avoid any dependency on >>>>> root=/dev/mmcblk2pN enumeration. >>>> >>>> This is due to software interchangeability with the DHCOM >>>> i.MX6ULL, where the eMMC is always mmc2. >>> >>> +CC Ulf , I vaguely recall some discussion about this enumeration and I >>> am not sure one can really depend on that. >> >> That why I think it good to have a defined number for mmcblk devices >> on an embedded system. An excerpt from [1]: > > I might be misremembering this, but could it be that, if any non-OF > SDMMC controller probes early and hogs the /dev/mmcblk2 before the OF > ones have a chance to probe, then the OF ones would fail to probe ? > >> Alternative solutions like PARTUUIDs do not cover the case where multiple >> mmcblk devices contain the same image. > > I agree, this is indeed a downside of PARTUUID . > >> This is a common issue on devices >> that can boot both from eMMC (for regular boot) and SD cards (as a >> temporary boot medium for development). When a firmware image is >> installed to eMMC after a test boot via SD card, there will be no >> reliable way to refer to a specific device using (PART)UUIDs oder >> LABELs > > This can be solved by the installer updating the PARTUUID on the eMMC > however. > >> [1] https://patchwork.kernel.org/project/linux-mmc/patch/20200825134441.17537-2-matthias.schiffer@ew.tq-group.com/ >> >> So far I have never had a problem with numbering mmcblk devices via aliases. > > Based on the above, I don't think either the aliases or PARTUUID is a > perfect solution, but the aliases should be fine for mx6ull at least? > So I think we can conclude this discussion thread ? Yes, I will send a new version with the changes on the first patch. Regards Christoph
On 4/6/23 17:44, Christoph Niedermaier wrote: > From: Marek Vasut [mailto:marex@denx.de] > Sent: Thursday, April 6, 2023 4:10 PM >> On 4/6/23 10:37, Christoph Niedermaier wrote: >>> From: Marek Vasut [mailto:marex@denx.de] >>> Sent: Wednesday, April 5, 2023 8:47 PM >>>> On 4/5/23 20:24, Christoph Niedermaier wrote: >>>>> From: Marek Vasut [mailto:marex@denx.de] >>>>> Sent: Wednesday, April 5, 2023 6:25 PM >>>>>> On 4/5/23 18:02, Christoph Niedermaier wrote: >>>>>> >>>>>> [...] >>>>>> >>>>>>> +/ { >>>>>>> + model = "DH electronics i.MX6ULL DHCOR on maveo box"; >>>>>>> + compatible = "dh,imx6ull-dhcor-maveo-box", "dh,imx6ull-dhcor-som", >>>>>>> + "fsl,imx6ull"; >>>>>>> + >>>>>>> + aliases { >>>>>>> + /delete-property/ mmc0; /* Avoid double definitions */ >>>>>>> + /delete-property/ mmc1; >>>>>>> + mmc2 = &usdhc2; /* eMMC should be mmc2 */ >>>>>> >>>>>> Why not mmc0 ? >>>>>> >>>>>> Use root=PARTUUID= when booting to avoid any dependency on >>>>>> root=/dev/mmcblk2pN enumeration. >>>>> >>>>> This is due to software interchangeability with the DHCOM >>>>> i.MX6ULL, where the eMMC is always mmc2. >>>> >>>> +CC Ulf , I vaguely recall some discussion about this enumeration and I >>>> am not sure one can really depend on that. >>> >>> That why I think it good to have a defined number for mmcblk devices >>> on an embedded system. An excerpt from [1]: >> >> I might be misremembering this, but could it be that, if any non-OF >> SDMMC controller probes early and hogs the /dev/mmcblk2 before the OF >> ones have a chance to probe, then the OF ones would fail to probe ? >> >>> Alternative solutions like PARTUUIDs do not cover the case where multiple >>> mmcblk devices contain the same image. >> >> I agree, this is indeed a downside of PARTUUID . >> >>> This is a common issue on devices >>> that can boot both from eMMC (for regular boot) and SD cards (as a >>> temporary boot medium for development). When a firmware image is >>> installed to eMMC after a test boot via SD card, there will be no >>> reliable way to refer to a specific device using (PART)UUIDs oder >>> LABELs >> >> This can be solved by the installer updating the PARTUUID on the eMMC >> however. >> >>> [1] https://patchwork.kernel.org/project/linux-mmc/patch/20200825134441.17537-2-matthias.schiffer@ew.tq-group.com/ >>> >>> So far I have never had a problem with numbering mmcblk devices via aliases. >> >> Based on the above, I don't think either the aliases or PARTUUID is a >> perfect solution, but the aliases should be fine for mx6ull at least? >> So I think we can conclude this discussion thread ? > > Yes, I will send a new version with the changes on the first patch. Thank you
On 05/04/2023 20:24, Christoph Niedermaier wrote: > From: Marek Vasut [mailto:marex@denx.de] > Sent: Wednesday, April 5, 2023 6:25 PM >> On 4/5/23 18:02, Christoph Niedermaier wrote: >> >> [...] >> >>> +/ { >>> + model = "DH electronics i.MX6ULL DHCOR on maveo box"; >>> + compatible = "dh,imx6ull-dhcor-maveo-box", "dh,imx6ull-dhcor-som", >>> + "fsl,imx6ull"; >>> + >>> + aliases { >>> + /delete-property/ mmc0; /* Avoid double definitions */ >>> + /delete-property/ mmc1; >>> + mmc2 = &usdhc2; /* eMMC should be mmc2 */ >> >> Why not mmc0 ? >> >> Use root=PARTUUID= when booting to avoid any dependency on >> root=/dev/mmcblk2pN enumeration. > > This is due to software interchangeability with the DHCOM > i.MX6ULL, where the eMMC is always mmc2. That's not the reason to have aliases. The number should match numbering in your datasheet/schematics/user-guide, not what your software wants. Use PARTUUID for SW dependencies. Best regards, Krzysztof
On 4/6/23 18:36, Krzysztof Kozlowski wrote: > On 05/04/2023 20:24, Christoph Niedermaier wrote: >> From: Marek Vasut [mailto:marex@denx.de] >> Sent: Wednesday, April 5, 2023 6:25 PM >>> On 4/5/23 18:02, Christoph Niedermaier wrote: >>> >>> [...] >>> >>>> +/ { >>>> + model = "DH electronics i.MX6ULL DHCOR on maveo box"; >>>> + compatible = "dh,imx6ull-dhcor-maveo-box", "dh,imx6ull-dhcor-som", >>>> + "fsl,imx6ull"; >>>> + >>>> + aliases { >>>> + /delete-property/ mmc0; /* Avoid double definitions */ >>>> + /delete-property/ mmc1; >>>> + mmc2 = &usdhc2; /* eMMC should be mmc2 */ >>> >>> Why not mmc0 ? >>> >>> Use root=PARTUUID= when booting to avoid any dependency on >>> root=/dev/mmcblk2pN enumeration. >> >> This is due to software interchangeability with the DHCOM >> i.MX6ULL, where the eMMC is always mmc2. > > That's not the reason to have aliases. The number should match numbering > in your datasheet/schematics/user-guide, not what your software wants. > > Use PARTUUID for SW dependencies. Regarding the PARTUUID, Christoph raised a valid concern I think. These machines can come with A/B update scheme, where the PARTUUID could become identical between two partitions. Or, you can write the same image to both eMMC and SD card. I don't think PARTUUID is the silver bullet solution, but I agree the enumeration is a great solution either.
On 06/04/2023 19:32, Marek Vasut wrote: > On 4/6/23 18:36, Krzysztof Kozlowski wrote: >> On 05/04/2023 20:24, Christoph Niedermaier wrote: >>> From: Marek Vasut [mailto:marex@denx.de] >>> Sent: Wednesday, April 5, 2023 6:25 PM >>>> On 4/5/23 18:02, Christoph Niedermaier wrote: >>>> >>>> [...] >>>> >>>>> +/ { >>>>> + model = "DH electronics i.MX6ULL DHCOR on maveo box"; >>>>> + compatible = "dh,imx6ull-dhcor-maveo-box", "dh,imx6ull-dhcor-som", >>>>> + "fsl,imx6ull"; >>>>> + >>>>> + aliases { >>>>> + /delete-property/ mmc0; /* Avoid double definitions */ >>>>> + /delete-property/ mmc1; >>>>> + mmc2 = &usdhc2; /* eMMC should be mmc2 */ >>>> >>>> Why not mmc0 ? >>>> >>>> Use root=PARTUUID= when booting to avoid any dependency on >>>> root=/dev/mmcblk2pN enumeration. >>> >>> This is due to software interchangeability with the DHCOM >>> i.MX6ULL, where the eMMC is always mmc2. >> >> That's not the reason to have aliases. The number should match numbering >> in your datasheet/schematics/user-guide, not what your software wants. >> >> Use PARTUUID for SW dependencies. > > Regarding the PARTUUID, Christoph raised a valid concern I think. These > machines can come with A/B update scheme, where the PARTUUID could > become identical between two partitions. Or, you can write the same > image to both eMMC and SD card. I don't think PARTUUID is the silver > bullet solution, but I agree the enumeration is a great solution either. If you remove other aliases it means it comes only with emmc, right? One storage. Then any A/B means you have two partitions. Two partitions will have different PARTUUID as partition number is there. You can also use PARTLABEL=root_a (root_b). That's BTW easy way to switch between A/B partitions. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index b175f2b1bd30..c95254c57571 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -717,6 +717,12 @@ properties: - const: dh,imx6ull-dhcor-som - const: fsl,imx6ull + - description: i.MX6ULL DHCOR SoM based Boards + items: + - const: dh,imx6ull-dhcor-maveo-box + - const: dh,imx6ull-dhcor-som + - const: fsl,imx6ull + - description: i.MX6ULL PHYTEC phyBOARD-Segin items: - enum:
Add Marantec maveo box. The system is used to get a smart conntection to a door drive. The core of this system is a soldered i.MX6ULL DHCOR SoM from DH electronics. Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> --- Cc: Rob Herring <robh+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Shawn Guo <shawnguo@kernel.org> CC: Li Yang <leoyang.li@nxp.com> Cc: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@denx.de> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: kernel@dh-electronics.com Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org To: linux-arm-kernel@lists.infradead.org --- Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++ 1 file changed, 6 insertions(+)