| Message ID | 20201120085637.7299-3-m.szyprowski@samsung.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 75681980c4e3d89c55b5b8f20b8f4c1aace601be |
| Headers | show |
| Series | Fix USB2 PHY operation on Exynos542x | expand |
On Fri, Nov 20, 2020 at 09:56:37AM +0100, Marek Szyprowski wrote: > USB2.0 PHY in Exynos5420 differs from Exynos5250 variant a bit, so use the > recently introduced dedicated compatible for Exynos5420. > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> > --- > arch/arm/boot/dts/exynos54xx.dtsi | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi > index fe9d34c23374..2ddb7a5f12b3 100644 > --- a/arch/arm/boot/dts/exynos54xx.dtsi > +++ b/arch/arm/boot/dts/exynos54xx.dtsi > @@ -188,7 +188,7 @@ > compatible = "samsung,exynos4210-ehci"; > reg = <0x12110000 0x100>; > interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; > - phys = <&usb2_phy 1>; > + phys = <&usb2_phy 0>; > phy-names = "host"; > }; > > @@ -196,12 +196,12 @@ > compatible = "samsung,exynos4210-ohci"; > reg = <0x12120000 0x100>; > interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; > - phys = <&usb2_phy 1>; > + phys = <&usb2_phy 0>; > phy-names = "host"; > }; > > usb2_phy: phy@12130000 { > - compatible = "samsung,exynos5250-usb2-phy"; > + compatible = "samsung,exynos5420-usb2-phy"; The DTS change will wait till PHY driver adjustements get merged... or if the difference is not critical, maybe using both compatibles (5420 and 5250) would have sense? Best regards, Krzysztof
Hi Krzysztof, On 20.11.2020 12:05, Krzysztof Kozlowski wrote: > On Fri, Nov 20, 2020 at 09:56:37AM +0100, Marek Szyprowski wrote: >> USB2.0 PHY in Exynos5420 differs from Exynos5250 variant a bit, so use the >> recently introduced dedicated compatible for Exynos5420. >> >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> >> --- >> arch/arm/boot/dts/exynos54xx.dtsi | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi >> index fe9d34c23374..2ddb7a5f12b3 100644 >> --- a/arch/arm/boot/dts/exynos54xx.dtsi >> +++ b/arch/arm/boot/dts/exynos54xx.dtsi >> @@ -188,7 +188,7 @@ >> compatible = "samsung,exynos4210-ehci"; >> reg = <0x12110000 0x100>; >> interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; >> - phys = <&usb2_phy 1>; >> + phys = <&usb2_phy 0>; >> phy-names = "host"; >> }; >> >> @@ -196,12 +196,12 @@ >> compatible = "samsung,exynos4210-ohci"; >> reg = <0x12120000 0x100>; >> interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; >> - phys = <&usb2_phy 1>; >> + phys = <&usb2_phy 0>; >> phy-names = "host"; >> }; >> >> usb2_phy: phy@12130000 { >> - compatible = "samsung,exynos5250-usb2-phy"; >> + compatible = "samsung,exynos5420-usb2-phy"; > The DTS change will wait till PHY driver adjustements get merged... or > if the difference is not critical, maybe using both compatibles (5420 > and 5250) would have sense? It won't work easily with both compatibles, because in the 5420 variant I've also changed the PHY indices (5420 has no device and second hsic phy). IMHO the dts change can wait for the next release. Best regards
On Fri, Nov 20, 2020 at 12:07:44PM +0100, Marek Szyprowski wrote: > Hi Krzysztof, > > On 20.11.2020 12:05, Krzysztof Kozlowski wrote: > > On Fri, Nov 20, 2020 at 09:56:37AM +0100, Marek Szyprowski wrote: > >> USB2.0 PHY in Exynos5420 differs from Exynos5250 variant a bit, so use the > >> recently introduced dedicated compatible for Exynos5420. > >> > >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> > >> --- > >> arch/arm/boot/dts/exynos54xx.dtsi | 6 +++--- > >> 1 file changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi > >> index fe9d34c23374..2ddb7a5f12b3 100644 > >> --- a/arch/arm/boot/dts/exynos54xx.dtsi > >> +++ b/arch/arm/boot/dts/exynos54xx.dtsi > >> @@ -188,7 +188,7 @@ > >> compatible = "samsung,exynos4210-ehci"; > >> reg = <0x12110000 0x100>; > >> interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; > >> - phys = <&usb2_phy 1>; > >> + phys = <&usb2_phy 0>; > >> phy-names = "host"; > >> }; > >> > >> @@ -196,12 +196,12 @@ > >> compatible = "samsung,exynos4210-ohci"; > >> reg = <0x12120000 0x100>; > >> interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; > >> - phys = <&usb2_phy 1>; > >> + phys = <&usb2_phy 0>; > >> phy-names = "host"; > >> }; > >> > >> usb2_phy: phy@12130000 { > >> - compatible = "samsung,exynos5250-usb2-phy"; > >> + compatible = "samsung,exynos5420-usb2-phy"; > > The DTS change will wait till PHY driver adjustements get merged... or > > if the difference is not critical, maybe using both compatibles (5420 > > and 5250) would have sense? > > It won't work easily with both compatibles, because in the 5420 variant > I've also changed the PHY indices (5420 has no device and second hsic > phy). IMHO the dts change can wait for the next release. Thanks, applied. Best regards, Krzysztof
On Fri, Nov 20, 2020 at 12:10 PM Marek Szyprowski <m.szyprowski@samsung.com> wrote: > On 20.11.2020 12:05, Krzysztof Kozlowski wrote: > > On Fri, Nov 20, 2020 at 09:56:37AM +0100, Marek Szyprowski wrote: > >> USB2.0 PHY in Exynos5420 differs from Exynos5250 variant a bit, so use the > >> recently introduced dedicated compatible for Exynos5420. > >> > >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> > >> --- > >> arch/arm/boot/dts/exynos54xx.dtsi | 6 +++--- > >> 1 file changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi > >> index fe9d34c23374..2ddb7a5f12b3 100644 > >> --- a/arch/arm/boot/dts/exynos54xx.dtsi > >> +++ b/arch/arm/boot/dts/exynos54xx.dtsi > >> @@ -188,7 +188,7 @@ > >> compatible = "samsung,exynos4210-ehci"; > >> reg = <0x12110000 0x100>; > >> interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; > >> - phys = <&usb2_phy 1>; > >> + phys = <&usb2_phy 0>; > >> phy-names = "host"; > >> }; > >> > >> @@ -196,12 +196,12 @@ > >> compatible = "samsung,exynos4210-ohci"; > >> reg = <0x12120000 0x100>; > >> interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; > >> - phys = <&usb2_phy 1>; > >> + phys = <&usb2_phy 0>; > >> phy-names = "host"; > >> }; > >> > >> usb2_phy: phy@12130000 { > >> - compatible = "samsung,exynos5250-usb2-phy"; > >> + compatible = "samsung,exynos5420-usb2-phy"; > > The DTS change will wait till PHY driver adjustements get merged... or > > if the difference is not critical, maybe using both compatibles (5420 > > and 5250) would have sense? > > It won't work easily with both compatibles, because in the 5420 variant > I've also changed the PHY indices (5420 has no device and second hsic > phy). IMHO the dts change can wait for the next release. I see this made it into the pull request now, but I had not been aware of the change earlier, and I'm slightly annoyed to have received it this way: - This is clearly an incompatible change to the dtb, and you all noticed that because it would cause a bisection problem. As a general rule, if a dts change does not work across bisection, we should not merge it at all, because it causes problems for anyone with external dts or dtb files. - It would likely have been possible to define the new binding in a backward-compatible way. I don't see a reason why the index values in the binding had to change here, other than a slight inconvenience for the driver. - If the change was really unavoidable, I would have expected a long explanation about why it had to be done in both the commit message and in the tag description for the pull request. I've dropped the pull request for now, maybe this can still be sorted out with another driver change that makes the new compatible string backward-compatible. Arnd
On Tue, Jan 26, 2021 at 11:44:26PM +0100, Arnd Bergmann wrote: > On Fri, Nov 20, 2020 at 12:10 PM Marek Szyprowski > <m.szyprowski@samsung.com> wrote: > > On 20.11.2020 12:05, Krzysztof Kozlowski wrote: > > > On Fri, Nov 20, 2020 at 09:56:37AM +0100, Marek Szyprowski wrote: > > >> USB2.0 PHY in Exynos5420 differs from Exynos5250 variant a bit, so use the > > >> recently introduced dedicated compatible for Exynos5420. > > >> > > >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> > > >> --- > > >> arch/arm/boot/dts/exynos54xx.dtsi | 6 +++--- > > >> 1 file changed, 3 insertions(+), 3 deletions(-) > > >> > > >> diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi > > >> index fe9d34c23374..2ddb7a5f12b3 100644 > > >> --- a/arch/arm/boot/dts/exynos54xx.dtsi > > >> +++ b/arch/arm/boot/dts/exynos54xx.dtsi > > >> @@ -188,7 +188,7 @@ > > >> compatible = "samsung,exynos4210-ehci"; > > >> reg = <0x12110000 0x100>; > > >> interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; > > >> - phys = <&usb2_phy 1>; > > >> + phys = <&usb2_phy 0>; > > >> phy-names = "host"; > > >> }; > > >> > > >> @@ -196,12 +196,12 @@ > > >> compatible = "samsung,exynos4210-ohci"; > > >> reg = <0x12120000 0x100>; > > >> interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; > > >> - phys = <&usb2_phy 1>; > > >> + phys = <&usb2_phy 0>; > > >> phy-names = "host"; > > >> }; > > >> > > >> usb2_phy: phy@12130000 { > > >> - compatible = "samsung,exynos5250-usb2-phy"; > > >> + compatible = "samsung,exynos5420-usb2-phy"; > > > The DTS change will wait till PHY driver adjustements get merged... or > > > if the difference is not critical, maybe using both compatibles (5420 > > > and 5250) would have sense? > > > > It won't work easily with both compatibles, because in the 5420 variant > > I've also changed the PHY indices (5420 has no device and second hsic > > phy). IMHO the dts change can wait for the next release. > > I see this made it into the pull request now, but I had not been aware > of the change earlier, and I'm slightly annoyed to have received it this > way: > > - This is clearly an incompatible change to the dtb, and you all > noticed that because it would cause a bisection problem. As > a general rule, if a dts change does not work across bisection, > we should not merge it at all, because it causes problems for > anyone with external dts or dtb files. Hi Arnd, No, it does not create a bisection problem. The driver change adding new compatible is already in v5.11-rc1. > > - It would likely have been possible to define the new binding in > a backward-compatible way. I don't see a reason why the index > values in the binding had to change here, other than a slight > inconvenience for the driver. It does not matter since it's a new compatible and old one is not affected. Nothing got broken before this patch, nothing got broken after applying it via samsung-soc. No backwards compatibility is affected. > > - If the change was really unavoidable, I would have expected > a long explanation about why it had to be done in both the > commit message and in the tag description for the pull > request. > > I've dropped the pull request for now, maybe this can still > be sorted out with another driver change that makes the > new compatible string backward-compatible. It's a different hardware. New hardware does not have to be compatible with old hardware. However old DTB is still doing fine (although with the original issue not fixed). Best regards, Krzysztof
On Wed, Jan 27, 2021 at 8:59 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > On Tue, Jan 26, 2021 at 11:44:26PM +0100, Arnd Bergmann wrote: > > On Fri, Nov 20, 2020 at 12:10 PM Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > > It won't work easily with both compatibles, because in the 5420 variant > > > I've also changed the PHY indices (5420 has no device and second hsic > > > phy). IMHO the dts change can wait for the next release. > > > > I see this made it into the pull request now, but I had not been aware > > of the change earlier, and I'm slightly annoyed to have received it this > > way: > > > > - This is clearly an incompatible change to the dtb, and you all > > noticed that because it would cause a bisection problem. As > > a general rule, if a dts change does not work across bisection, > > we should not merge it at all, because it causes problems for > > anyone with external dts or dtb files. > > Hi Arnd, > > No, it does not create a bisection problem. The driver change adding new > compatible is already in v5.11-rc1. What I meant is that you knew there would be a bisection problem if you had not delayed this patch. > > - It would likely have been possible to define the new binding in > > a backward-compatible way. I don't see a reason why the index > > values in the binding had to change here, other than a slight > > inconvenience for the driver. > > It does not matter since it's a new compatible and old one is not > affected. Nothing got broken before this patch, nothing got broken after > applying it via samsung-soc. No backwards compatibility is affected. > > > - If the change was really unavoidable, I would have expected > > a long explanation about why it had to be done in both the > > commit message and in the tag description for the pull > > request. > > > > I've dropped the pull request for now, maybe this can still > > be sorted out with another driver change that makes the > > new compatible string backward-compatible. > > It's a different hardware. New hardware does not have to be compatible > with old hardware. However old DTB is still doing fine (although with > the original issue not fixed). There are around ten boards including this file, and most (maybe all) of them are not newly added machines, so there is a good chance that there are existing users. You are right that you took care that the combination of an old dtb with a new kernel would not be any worse than before, and that is good. What is however missing is the consideration of the reverse: If anyone wants to dual-boot between old and new kernels, they are stuck with the old dtb and is missing the bugfix along with any additional changes that may get added in the future. The same is true if there are any non-Linux operating systems running on these. For instance, FreeBSD runs on Peach Pit, and if they were using the old dtb from Linux (I have not checked if they were compatible before this change), then booting with the latest dtb from Linux will require the same changes to their driver to avoid a regression. I can live with an explanation of "we've looked at all the alternatives and decided to break old kernels with new dtbs in this particular case because ...", but I don't like the idea of silently changing dts in a way that breaks using them with anything but the latest kernel and arguing that it's not even worth debating. Arnd
On Sat, Jan 30, 2021 at 03:14:22PM +0100, Arnd Bergmann wrote: > On Wed, Jan 27, 2021 at 8:59 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On Tue, Jan 26, 2021 at 11:44:26PM +0100, Arnd Bergmann wrote: > > > On Fri, Nov 20, 2020 at 12:10 PM Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > > > > It won't work easily with both compatibles, because in the 5420 variant > > > > I've also changed the PHY indices (5420 has no device and second hsic > > > > phy). IMHO the dts change can wait for the next release. > > > > > > I see this made it into the pull request now, but I had not been aware > > > of the change earlier, and I'm slightly annoyed to have received it this > > > way: > > > > > > - This is clearly an incompatible change to the dtb, and you all > > > noticed that because it would cause a bisection problem. As > > > a general rule, if a dts change does not work across bisection, > > > we should not merge it at all, because it causes problems for > > > anyone with external dts or dtb files. > > > > Hi Arnd, > > > > No, it does not create a bisection problem. The driver change adding new > > compatible is already in v5.11-rc1. > > What I meant is that you knew there would be a bisection problem > if you had not delayed this patch. Of course, there are tons of such examples and delaying a patch for DTS is perfectly safe, sane and regular way to deal with it. > > > > - It would likely have been possible to define the new binding in > > > a backward-compatible way. I don't see a reason why the index > > > values in the binding had to change here, other than a slight > > > inconvenience for the driver. > > > > It does not matter since it's a new compatible and old one is not > > affected. Nothing got broken before this patch, nothing got broken after > > applying it via samsung-soc. No backwards compatibility is affected. > > > > > - If the change was really unavoidable, I would have expected > > > a long explanation about why it had to be done in both the > > > commit message and in the tag description for the pull > > > request. > > > > > > I've dropped the pull request for now, maybe this can still > > > be sorted out with another driver change that makes the > > > new compatible string backward-compatible. > > > > It's a different hardware. New hardware does not have to be compatible > > with old hardware. However old DTB is still doing fine (although with > > the original issue not fixed). > > There are around ten boards including this file, and most (maybe all) > of them are not newly added machines, so there is a good chance > that there are existing users. You are right that you took care that > the combination of an old dtb with a new kernel would not be any > worse than before, and that is good. What is however missing is > the consideration of the reverse: If anyone wants to dual-boot between > old and new kernels, they are stuck with the old dtb and is missing > the bugfix along with any additional changes that may get added > in the future. First of all, out of tree is not our concern. Let me quote DT guru, Rob: "If it's not upstream, it doesn't exist." https://lore.kernel.org/lkml/20201028152303.GA4041470@bogus/T/#m602ef29cade6f9ed49efd52159210d2a6813eec9 Second of all, out of tree DTB (so old DTB in your meaning) will work perfectly fine (the same) and nothing is broken. So why I would need to care about something which "does not exist" while I also do not break it? > The same is true if there are any non-Linux operating systems running > on these. For instance, FreeBSD runs on Peach Pit, and if they > were using the old dtb from Linux (I have not checked if they > were compatible before this change), then booting with the latest > dtb from Linux will require the same changes to their driver to avoid > a regression. If anyone takes kernel DTS and applies to his project, and then he takes blindly the latter changes to DTS (but without earlier changes to bindings! so he picks up only selective choice), then it's his responsibility to be up to date. I am sorry, but I cannot take care about any ridiculous and irresponsible idea in the world. Seriously, do you expect us to think about out of tree unkown users of an intree DTS when that *user does not follow bindings*? It's the first time I hear it. > I can live with an explanation of "we've looked at all the alternatives > and decided to break old kernels with new dtbs in this particular > case because ...", but I don't like the idea of silently changing dts > in a way that breaks using them with anything but the latest kernel > and arguing that it's not even worth debating. There is no single need for intree kernel DTS to be backwards compatible with old kernel. There is no single rule for it, either (because it's not ABI). Best regards, Krzysztof
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi index fe9d34c23374..2ddb7a5f12b3 100644 --- a/arch/arm/boot/dts/exynos54xx.dtsi +++ b/arch/arm/boot/dts/exynos54xx.dtsi @@ -188,7 +188,7 @@ compatible = "samsung,exynos4210-ehci"; reg = <0x12110000 0x100>; interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; - phys = <&usb2_phy 1>; + phys = <&usb2_phy 0>; phy-names = "host"; }; @@ -196,12 +196,12 @@ compatible = "samsung,exynos4210-ohci"; reg = <0x12120000 0x100>; interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; - phys = <&usb2_phy 1>; + phys = <&usb2_phy 0>; phy-names = "host"; }; usb2_phy: phy@12130000 { - compatible = "samsung,exynos5250-usb2-phy"; + compatible = "samsung,exynos5420-usb2-phy"; reg = <0x12130000 0x100>; #phy-cells = <1>; };
USB2.0 PHY in Exynos5420 differs from Exynos5250 variant a bit, so use the recently introduced dedicated compatible for Exynos5420. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> --- arch/arm/boot/dts/exynos54xx.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)