| Message ID | 20201104113932.30702-1-a.fatoum@pengutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1] dt-bindings: arm: stm32: lxa, stm32mp157c-mc1: add extra SiP compatible | expand |
On Wed, Nov 04, 2020 at 12:39:31PM +0100, Ahmad Fatoum wrote: > The Linux Automation MC-1 is built around a SIP with CPU, RAM, PMIC, > Oscillator and EEPROM. Add a further compatible identifying the SiP, > so boot firmware can match against it to apply fixups if necessary. > > To avoid intermittent dtbs_check breakage in the sole upstream device > tree that uses that SiP, patch it here as well. > > Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> > --- > I know that bindings and device tree patches should be separate. Does > this apply here as well? Should I split the dts change into a follow-up > commit? Yes. > Is it ok that dtbs_check will report an intermittent breakage? If the binding comes first, it won't break. But generally, 'dtbs_check' being warning free is not yet a requirement. That will probably first have to be per platform. > --- > Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 8 +++++++- > arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts | 2 +- > 2 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml > index 009b424e456e..9127094f0208 100644 > --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml > +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml > @@ -40,7 +40,6 @@ properties: > - items: > - enum: > - arrow,stm32mp157a-avenger96 # Avenger96 > - - lxa,stm32mp157c-mc1 > - shiratech,stm32mp157a-iot-box # IoT Box > - shiratech,stm32mp157a-stinger96 # Stinger96 > - st,stm32mp157c-ed1 > @@ -52,6 +51,13 @@ properties: > - const: st,stm32mp157c-ev1 > - const: st,stm32mp157c-ed1 > - const: st,stm32mp157 > + - description: Octavo OSD32MP15x System-in-Package based boards > + items: > + - enum: > + - lxa,stm32mp157c-mc1 # Linux Automation MC-1 > + - const: oct,stm32mp15xx-osd32 'oct' is not docuemnted in vendor-prefixes.yaml. > + - enum: > + - st,stm32mp157 > - description: Odyssey STM32MP1 SoM based Boards > items: > - enum: > diff --git a/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts b/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts > index 1e5333fd437f..cda8e871f999 100644 > --- a/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts > +++ b/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts > @@ -15,7 +15,7 @@ > > / { > model = "Linux Automation MC-1 board"; > - compatible = "lxa,stm32mp157c-mc1", "st,stm32mp157"; > + compatible = "lxa,stm32mp157c-mc1", "oct,stm32mp15xx-osd32", "st,stm32mp157"; > > aliases { > ethernet0 = ðernet0; > -- > 2.28.0 >
Hello Rob, On 11/9/20 5:37 PM, Rob Herring wrote: > On Wed, Nov 04, 2020 at 12:39:31PM +0100, Ahmad Fatoum wrote: >> I know that bindings and device tree patches should be separate. Does >> this apply here as well? Should I split the dts change into a follow-up >> commit? > > Yes. > >> Is it ok that dtbs_check will report an intermittent breakage? > > If the binding comes first, it won't break. > > But generally, 'dtbs_check' being warning free is not yet a requirement. > That will probably first have to be per platform. here the old binding is deleted, so between the patches, there will be a dtbs_check warning, which is why I asked. I've now split it up with binding first. >> + - const: oct,stm32mp15xx-osd32 > > 'oct' is not docuemnted in vendor-prefixes.yaml. Huh, I only checked whether it's in use, not if it's documented. I just sent out a v2 with your points addressed. Thanks for review, Ahmad
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 009b424e456e..9127094f0208 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -40,7 +40,6 @@ properties: - items: - enum: - arrow,stm32mp157a-avenger96 # Avenger96 - - lxa,stm32mp157c-mc1 - shiratech,stm32mp157a-iot-box # IoT Box - shiratech,stm32mp157a-stinger96 # Stinger96 - st,stm32mp157c-ed1 @@ -52,6 +51,13 @@ properties: - const: st,stm32mp157c-ev1 - const: st,stm32mp157c-ed1 - const: st,stm32mp157 + - description: Octavo OSD32MP15x System-in-Package based boards + items: + - enum: + - lxa,stm32mp157c-mc1 # Linux Automation MC-1 + - const: oct,stm32mp15xx-osd32 + - enum: + - st,stm32mp157 - description: Odyssey STM32MP1 SoM based Boards items: - enum: diff --git a/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts b/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts index 1e5333fd437f..cda8e871f999 100644 --- a/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts +++ b/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts @@ -15,7 +15,7 @@ / { model = "Linux Automation MC-1 board"; - compatible = "lxa,stm32mp157c-mc1", "st,stm32mp157"; + compatible = "lxa,stm32mp157c-mc1", "oct,stm32mp15xx-osd32", "st,stm32mp157"; aliases { ethernet0 = ðernet0;
The Linux Automation MC-1 is built around a SIP with CPU, RAM, PMIC, Oscillator and EEPROM. Add a further compatible identifying the SiP, so boot firmware can match against it to apply fixups if necessary. To avoid intermittent dtbs_check breakage in the sole upstream device tree that uses that SiP, patch it here as well. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> --- I know that bindings and device tree patches should be separate. Does this apply here as well? Should I split the dts change into a follow-up commit? Is it ok that dtbs_check will report an intermittent breakage? --- Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 8 +++++++- arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts | 2 +- 2 files changed, 8 insertions(+), 2 deletions(-)