[PATCH] usb: dwc2: change compatible st, stm32mp1-hsotg to st, stm32mp15-hsotg
The Linux kernel v5.7-rc1 introduced the compatible "st,stm32mp15-hsotg".
See Linux kernel commit d49850110434 ("dt-bindings: usb: dwc2: add support for STM32MP15 SoCs USB OTG HS and FS")
This patch updates the supported compatible in DWC2 driver, removes the add-on done in U-Boot dtsi and keeps the compatible defined in SOC dtsi arch/arm/dts/stm32mp151.dtsi:
usbotg_hs: usb-otg@49000000 { compatible = "st,stm32mp15-hsotg", "snps,dwc2"; reg = <0x49000000 0x10000>; ... };
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com ---
arch/arm/dts/stm32mp15-u-boot.dtsi | 3 --- drivers/usb/gadget/dwc2_udc_otg.c | 2 +- 2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp15-u-boot.dtsi b/arch/arm/dts/stm32mp15-u-boot.dtsi index d0aa5eabe5..43a7909978 100644 --- a/arch/arm/dts/stm32mp15-u-boot.dtsi +++ b/arch/arm/dts/stm32mp15-u-boot.dtsi @@ -228,6 +228,3 @@ resets = <&rcc UART8_R>; };
-&usbotg_hs { - compatible = "st,stm32mp1-hsotg", "snps,dwc2"; -}; diff --git a/drivers/usb/gadget/dwc2_udc_otg.c b/drivers/usb/gadget/dwc2_udc_otg.c index e3871e381e..ecac80fc11 100644 --- a/drivers/usb/gadget/dwc2_udc_otg.c +++ b/drivers/usb/gadget/dwc2_udc_otg.c @@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev) static const struct udevice_id dwc2_udc_otg_ids[] = { { .compatible = "snps,dwc2" }, { .compatible = "brcm,bcm2835-usb" }, - { .compatible = "st,stm32mp1-hsotg", + { .compatible = "st,stm32mp15-hsotg", .data = (ulong)dwc2_set_stm32mp1_hsotg_params }, {}, };
On 2/9/21 11:14 AM, Patrick Delaunay wrote: Hi,
[...]
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c b/drivers/usb/gadget/dwc2_udc_otg.c index e3871e381e..ecac80fc11 100644 --- a/drivers/usb/gadget/dwc2_udc_otg.c +++ b/drivers/usb/gadget/dwc2_udc_otg.c @@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev) static const struct udevice_id dwc2_udc_otg_ids[] = { { .compatible = "snps,dwc2" }, { .compatible = "brcm,bcm2835-usb" },
- { .compatible = "st,stm32mp1-hsotg",
- { .compatible = "st,stm32mp15-hsotg", .data = (ulong)dwc2_set_stm32mp1_hsotg_params },
I have to point out the obvious, DT is ABI, this breaks ABI. However, do we care about out-of-tree DTs here ?
On 2/9/21 11:39 AM, Marek Vasut wrote:
On 2/9/21 11:14 AM, Patrick Delaunay wrote: Hi,
[...]
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c b/drivers/usb/gadget/dwc2_udc_otg.c index e3871e381e..ecac80fc11 100644 --- a/drivers/usb/gadget/dwc2_udc_otg.c +++ b/drivers/usb/gadget/dwc2_udc_otg.c @@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev) static const struct udevice_id dwc2_udc_otg_ids[] = { { .compatible = "snps,dwc2" }, { .compatible = "brcm,bcm2835-usb" }, - { .compatible = "st,stm32mp1-hsotg", + { .compatible = "st,stm32mp15-hsotg", .data = (ulong)dwc2_set_stm32mp1_hsotg_params },
I have to point out the obvious, DT is ABI, this breaks ABI. However, do we care about out-of-tree DTs here ?
I know that the binding backward compatibility and "binary compatible" the is a key element of DT
for the Linux kernel (for example the latest kernel image should work with a old device tree).
I don't see the same requirement for U-Boot as external DT (with EXT_DTB option) is not common .
So today I assume that U-Boot use only in-tree DT for stm32mp15 platforms until we have a
100% upstream level of the stm32mp1 platform with binding aligned with Linux kernel bindings
(for example we have some other pending issue for USBPHYC binding).
But if backward compatibility is really blocking for U-Boot user, I can change my mind.
PS: I correct a issue here, because I upstream the stm32mp downstream binding for dwc2,
but this compatible had be modified before accepted by Linux kernel DT maintaineers
=> today USB in Linux kernel can't work with the DT used by U-Boot
Regards
Patrick
On Tue, Feb 09, 2021 at 08:51:26PM +0100, Patrick DELAUNAY wrote:
On 2/9/21 11:39 AM, Marek Vasut wrote:
On 2/9/21 11:14 AM, Patrick Delaunay wrote: Hi,
[...]
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c b/drivers/usb/gadget/dwc2_udc_otg.c index e3871e381e..ecac80fc11 100644 --- a/drivers/usb/gadget/dwc2_udc_otg.c +++ b/drivers/usb/gadget/dwc2_udc_otg.c @@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev) static const struct udevice_id dwc2_udc_otg_ids[] = { { .compatible = "snps,dwc2" }, { .compatible = "brcm,bcm2835-usb" }, - { .compatible = "st,stm32mp1-hsotg", + { .compatible = "st,stm32mp15-hsotg", .data = (ulong)dwc2_set_stm32mp1_hsotg_params },
I have to point out the obvious, DT is ABI, this breaks ABI. However, do we care about out-of-tree DTs here ?
I know that the binding backward compatibility and "binary compatible" the is a key element of DT
for the Linux kernel (for example the latest kernel image should work with a old device tree).
The way we use DTs in U-Boot we don't enforce ABI because we allow for DTS and bindings to come in before they're fully stabilized in linux-next/similar and then it's required to re-sync them once they are final.
Hi,
On 10.02.21 20:59, Tom Rini wrote:
On Tue, Feb 09, 2021 at 08:51:26PM +0100, Patrick DELAUNAY wrote:
On 2/9/21 11:39 AM, Marek Vasut wrote:
On 2/9/21 11:14 AM, Patrick Delaunay wrote: Hi,
[...]
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c b/drivers/usb/gadget/dwc2_udc_otg.c index e3871e381e..ecac80fc11 100644 --- a/drivers/usb/gadget/dwc2_udc_otg.c +++ b/drivers/usb/gadget/dwc2_udc_otg.c @@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev) static const struct udevice_id dwc2_udc_otg_ids[] = { { .compatible = "snps,dwc2" }, { .compatible = "brcm,bcm2835-usb" }, - { .compatible = "st,stm32mp1-hsotg", + { .compatible = "st,stm32mp15-hsotg", .data = (ulong)dwc2_set_stm32mp1_hsotg_params },
I have to point out the obvious, DT is ABI, this breaks ABI. However, do we care about out-of-tree DTs here ?
I know that the binding backward compatibility and "binary compatible" the is a key element of DT
for the Linux kernel (for example the latest kernel image should work with a old device tree).
The way we use DTs in U-Boot we don't enforce ABI because we allow for DTS and bindings to come in before they're fully stabilized in linux-next/similar and then it's required to re-sync them once they are final.
I think platforms like the STM32MP1 should be handled specially, because they support having an external device tree passed from the FSBL at runtime. See https://github.com/trini/u-boot/blob/master/arch/arm/mach-stm32mp/boot_param...
@Patrick, wouldn't this change break booting newer U-Boot with older TF-A in some configurations? Or is this reusing-fsbl-fdt feature unused?
Cheers, Ahmad
Uboot-stm32 mailing list Uboot-stm32@st-md-mailman.stormreply.com https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
On Thu, Feb 11, 2021 at 12:14:51PM +0100, Ahmad Fatoum wrote:
Hi,
On 10.02.21 20:59, Tom Rini wrote:
On Tue, Feb 09, 2021 at 08:51:26PM +0100, Patrick DELAUNAY wrote:
On 2/9/21 11:39 AM, Marek Vasut wrote:
On 2/9/21 11:14 AM, Patrick Delaunay wrote: Hi,
[...]
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c b/drivers/usb/gadget/dwc2_udc_otg.c index e3871e381e..ecac80fc11 100644 --- a/drivers/usb/gadget/dwc2_udc_otg.c +++ b/drivers/usb/gadget/dwc2_udc_otg.c @@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev) static const struct udevice_id dwc2_udc_otg_ids[] = { { .compatible = "snps,dwc2" }, { .compatible = "brcm,bcm2835-usb" }, - { .compatible = "st,stm32mp1-hsotg", + { .compatible = "st,stm32mp15-hsotg", .data = (ulong)dwc2_set_stm32mp1_hsotg_params },
I have to point out the obvious, DT is ABI, this breaks ABI. However, do we care about out-of-tree DTs here ?
I know that the binding backward compatibility and "binary compatible" the is a key element of DT
for the Linux kernel (for example the latest kernel image should work with a old device tree).
The way we use DTs in U-Boot we don't enforce ABI because we allow for DTS and bindings to come in before they're fully stabilized in linux-next/similar and then it's required to re-sync them once they are final.
I think platforms like the STM32MP1 should be handled specially, because they support having an external device tree passed from the FSBL at runtime. See https://github.com/trini/u-boot/blob/master/arch/arm/mach-stm32mp/boot_param...
@Patrick, wouldn't this change break booting newer U-Boot with older TF-A in some configurations? Or is this reusing-fsbl-fdt feature unused?
The long stated policy of U-Boot is to allow non-final bindings to be used until they're finalized in Linux in order to address the "chicken and egg" problem, since it's already a terrible idea to go to production with a Linux kernel that's using non-final bindings. Any older TF-A that doesn't work with this newer binding should be on a developer board and they can just upgrade. Linux says "DT is ABI" and allows the ABI to break when there's a bug in the DT. We don't say "DT is ABI" we say "we use the Linux kernel binding".
On 11.02.21 14:02, Tom Rini wrote:
On Thu, Feb 11, 2021 at 12:14:51PM +0100, Ahmad Fatoum wrote:
I think platforms like the STM32MP1 should be handled specially, because they support having an external device tree passed from the FSBL at runtime. See https://github.com/trini/u-boot/blob/master/arch/arm/mach-stm32mp/boot_param...
@Patrick, wouldn't this change break booting newer U-Boot with older TF-A in some configurations? Or is this reusing-fsbl-fdt feature unused?
The long stated policy of U-Boot is to allow non-final bindings to be used until they're finalized in Linux in order to address the "chicken and egg" problem, since it's already a terrible idea to go to production with a Linux kernel that's using non-final bindings. Any older TF-A that doesn't work with this newer binding should be on a developer board and they can just upgrade. Linux says "DT is ABI" and allows the ABI to break when there's a bug in the DT. We don't say "DT is ABI" we say "we use the Linux kernel binding".
I see. Thanks for the clarification.
I am still curious what configurations use the TF-A-provided device tree for U-Boot. Patrick?
Hi Ahmad,
On 2/11/21 12:14 PM, Ahmad Fatoum wrote:
Hi,
On 10.02.21 20:59, Tom Rini wrote:
On Tue, Feb 09, 2021 at 08:51:26PM +0100, Patrick DELAUNAY wrote:
On 2/9/21 11:39 AM, Marek Vasut wrote:
On 2/9/21 11:14 AM, Patrick Delaunay wrote: Hi,
[...]
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c b/drivers/usb/gadget/dwc2_udc_otg.c index e3871e381e..ecac80fc11 100644 --- a/drivers/usb/gadget/dwc2_udc_otg.c +++ b/drivers/usb/gadget/dwc2_udc_otg.c @@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev) static const struct udevice_id dwc2_udc_otg_ids[] = { { .compatible = "snps,dwc2" }, { .compatible = "brcm,bcm2835-usb" }, - { .compatible = "st,stm32mp1-hsotg", + { .compatible = "st,stm32mp15-hsotg", .data = (ulong)dwc2_set_stm32mp1_hsotg_params },
I have to point out the obvious, DT is ABI, this breaks ABI. However, do we care about out-of-tree DTs here ?
I know that the binding backward compatibility and "binary compatible" the is a key element of DT
for the Linux kernel (for example the latest kernel image should work with a old device tree).
The way we use DTs in U-Boot we don't enforce ABI because we allow for DTS and bindings to come in before they're fully stabilized in linux-next/similar and then it's required to re-sync them once they are final.
I think platforms like the STM32MP1 should be handled specially, because they support having an external device tree passed from the FSBL at runtime. See https://github.com/trini/u-boot/blob/master/arch/arm/mach-stm32mp/boot_param...
@Patrick, wouldn't this change break booting newer U-Boot with older TF-A in some configurations? Or is this reusing-fsbl-fdt feature unused?
Cheers, Ahmad
I introduce this patch to prepare the FIP support in STM32MP15x TF-A
but it is not yet ready today in downstream or in upstream (STOpenLinux v2.1).
In this FIP use-case, the DT provided by TF-A to U-Boot is the "u-boot.dtb"
generated by U-Boot compilation (including the required "u-boot,dm-pre-reloc"
add-on).
The files "u-boot-nodtb.bin" and "u-boot.dtb" are provided to TF-A makefile
when the FIP is create; I hope these files are aligned as resulting of the
U-Boot compilation.
And update of existing FIP is possible with command:
PC $> fiptool update --nt-fw u-boot-nodtb.bin --hw-config u-boot.dtb fip.bin
Here I hope the DT and U-Boot binary are updated at the same time
to avoid any dependency issue (even if it is not mandatory).
But as this FIP feature is not yet used, I don't break the current or the FIP STM32MP1
configurations, except if I miss something, as the 2 U-Boot files in FIP
are updated at the same time.
Regards,
Patrick
Hello Patrick,
On 19.02.21 14:30, Patrick DELAUNAY wrote:
Hi Ahmad,
On 2/11/21 12:14 PM, Ahmad Fatoum wrote:
Hi,
On 10.02.21 20:59, Tom Rini wrote:
On Tue, Feb 09, 2021 at 08:51:26PM +0100, Patrick DELAUNAY wrote:
On 2/9/21 11:39 AM, Marek Vasut wrote:
On 2/9/21 11:14 AM, Patrick Delaunay wrote: Hi,
[...]
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c b/drivers/usb/gadget/dwc2_udc_otg.c index e3871e381e..ecac80fc11 100644 --- a/drivers/usb/gadget/dwc2_udc_otg.c +++ b/drivers/usb/gadget/dwc2_udc_otg.c @@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev) static const struct udevice_id dwc2_udc_otg_ids[] = { { .compatible = "snps,dwc2" }, { .compatible = "brcm,bcm2835-usb" }, - { .compatible = "st,stm32mp1-hsotg", + { .compatible = "st,stm32mp15-hsotg", .data = (ulong)dwc2_set_stm32mp1_hsotg_params },
I have to point out the obvious, DT is ABI, this breaks ABI. However, do we care about out-of-tree DTs here ?
I know that the binding backward compatibility and "binary compatible" the is a key element of DT
for the Linux kernel (for example the latest kernel image should work with a old device tree).
The way we use DTs in U-Boot we don't enforce ABI because we allow for DTS and bindings to come in before they're fully stabilized in linux-next/similar and then it's required to re-sync them once they are final.
I think platforms like the STM32MP1 should be handled specially, because they support having an external device tree passed from the FSBL at runtime. See https://github.com/trini/u-boot/blob/master/arch/arm/mach-stm32mp/boot_param...
@Patrick, wouldn't this change break booting newer U-Boot with older TF-A in some configurations? Or is this reusing-fsbl-fdt feature unused?
Cheers, Ahmad
I introduce this patch to prepare the FIP support in STM32MP15x TF-A
but it is not yet ready today in downstream or in upstream (STOpenLinux v2.1).
In this FIP use-case, the DT provided by TF-A to U-Boot is the "u-boot.dtb"
generated by U-Boot compilation (including the required "u-boot,dm-pre-reloc"
add-on).
The files "u-boot-nodtb.bin" and "u-boot.dtb" are provided to TF-A makefile
when the FIP is create; I hope these files are aligned as resulting of the
U-Boot compilation.
And update of existing FIP is possible with command:
PC $> fiptool update --nt-fw u-boot-nodtb.bin --hw-config u-boot.dtb fip.bin
Here I hope the DT and U-Boot binary are updated at the same time
to avoid any dependency issue (even if it is not mandatory).
But as this FIP feature is not yet used, I don't break the current or the FIP STM32MP1
configurations, except if I miss something, as the 2 U-Boot files in FIP
are updated at the same time.
I think too it should cause no problem then. Thanks for the explanation!
Cheers, Ahmad
Regards,
Patrick
On 2/9/21 8:51 PM, Patrick DELAUNAY wrote:
On 2/9/21 11:39 AM, Marek Vasut wrote:
On 2/9/21 11:14 AM, Patrick Delaunay wrote: Hi,
[...]
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c b/drivers/usb/gadget/dwc2_udc_otg.c index e3871e381e..ecac80fc11 100644 --- a/drivers/usb/gadget/dwc2_udc_otg.c +++ b/drivers/usb/gadget/dwc2_udc_otg.c @@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev) static const struct udevice_id dwc2_udc_otg_ids[] = { { .compatible = "snps,dwc2" }, { .compatible = "brcm,bcm2835-usb" }, - { .compatible = "st,stm32mp1-hsotg", + { .compatible = "st,stm32mp15-hsotg", .data = (ulong)dwc2_set_stm32mp1_hsotg_params },
I have to point out the obvious, DT is ABI, this breaks ABI. However, do we care about out-of-tree DTs here ?
I know that the binding backward compatibility and "binary compatible" the is a key element of DT
for the Linux kernel (for example the latest kernel image should work with a old device tree).
I don't see the same requirement for U-Boot as external DT (with EXT_DTB option) is not common .
So today I assume that U-Boot use only in-tree DT for stm32mp15 platforms until we have a
100% upstream level of the stm32mp1 platform with binding aligned with Linux kernel bindings
(for example we have some other pending issue for USBPHYC binding).
But if backward compatibility is really blocking for U-Boot user, I can change my mind.
PS: I correct a issue here, because I upstream the stm32mp downstream binding for dwc2,
but this compatible had be modified before accepted by Linux kernel DT maintaineers
=> today USB in Linux kernel can't work with the DT used by U-Boot
All right, applied, thanks.
participants (5)
-
Ahmad Fatoum -
Marek Vasut -
Patrick DELAUNAY -
Patrick Delaunay
-
Tom Rini