* [PATCH] usb: host: ohci-platform: Disable ohci for rk3288
@ 2020-07-02 9:05 Jagan Teki
2020-07-02 13:26 ` Alan Stern
2020-07-02 14:38 ` Robin Murphy
0 siblings, 2 replies; 5+ messages in thread
From: Jagan Teki @ 2020-07-02 9:05 UTC (permalink / raw)
To: Alan Stern, Greg Kroah-Hartman, Heiko Stuebner, Rob Herring,
mylene.josserand
Cc: Suniel Mahesh, Michael Trimarchi, linux-usb, linux-rockchip,
linux-kernel, linux-amarula, Jagan Teki, William Wu
rk3288 has usb host0 ohci controller but doesn't actually work
on real hardware but it works with new revision chip rk3288w.
So, disable ohci for rk3288.
For rk3288w chips the compatible update code is handled by bootloader.
Cc: William Wu <william.wu@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Note:
- U-Boot patch for compatible update
https://patchwork.ozlabs.org/project/uboot/patch/20200702084820.35942-1-jagan@amarulasolutions.com/
drivers/usb/host/ohci-platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 7addfc2cbadc..24655ed6a7e0 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -96,7 +96,7 @@ static int ohci_platform_probe(struct platform_device *dev)
struct ohci_hcd *ohci;
int err, irq, clk = 0;
- if (usb_disabled())
+ if (usb_disabled() || of_machine_is_compatible("rockchip,rk3288"))
return -ENODEV;
/*
--
2.25.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] usb: host: ohci-platform: Disable ohci for rk3288
2020-07-02 9:05 [PATCH] usb: host: ohci-platform: Disable ohci for rk3288 Jagan Teki
@ 2020-07-02 13:26 ` Alan Stern
2020-07-02 14:38 ` Robin Murphy
1 sibling, 0 replies; 5+ messages in thread
From: Alan Stern @ 2020-07-02 13:26 UTC (permalink / raw)
To: Jagan Teki
Cc: Greg Kroah-Hartman, Heiko Stuebner, Rob Herring,
mylene.josserand, Suniel Mahesh, Michael Trimarchi, linux-usb,
linux-rockchip, linux-kernel, linux-amarula, William Wu
On Thu, Jul 02, 2020 at 02:35:04PM +0530, Jagan Teki wrote:
> rk3288 has usb host0 ohci controller but doesn't actually work
> on real hardware but it works with new revision chip rk3288w.
>
> So, disable ohci for rk3288.
>
> For rk3288w chips the compatible update code is handled by bootloader.
>
> Cc: William Wu <william.wu@rock-chips.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Note:
> - U-Boot patch for compatible update
> https://patchwork.ozlabs.org/project/uboot/patch/20200702084820.35942-1-jagan@amarulasolutions.com/
>
> drivers/usb/host/ohci-platform.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> index 7addfc2cbadc..24655ed6a7e0 100644
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -96,7 +96,7 @@ static int ohci_platform_probe(struct platform_device *dev)
> struct ohci_hcd *ohci;
> int err, irq, clk = 0;
>
> - if (usb_disabled())
> + if (usb_disabled() || of_machine_is_compatible("rockchip,rk3288"))
> return -ENODEV;
>
> /*
> --
> 2.25.1
Acked-by: Alan Stern <stern@rowland.harvard.edu>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] usb: host: ohci-platform: Disable ohci for rk3288
2020-07-02 9:05 [PATCH] usb: host: ohci-platform: Disable ohci for rk3288 Jagan Teki
2020-07-02 13:26 ` Alan Stern
@ 2020-07-02 14:38 ` Robin Murphy
2020-07-03 11:39 ` Jagan Teki
1 sibling, 1 reply; 5+ messages in thread
From: Robin Murphy @ 2020-07-02 14:38 UTC (permalink / raw)
To: Jagan Teki, Alan Stern, Greg Kroah-Hartman, Heiko Stuebner,
Rob Herring, mylene.josserand
Cc: linux-usb, linux-kernel, linux-rockchip, Suniel Mahesh,
William Wu, Michael Trimarchi, linux-amarula
On 2020-07-02 10:05, Jagan Teki wrote:
> rk3288 has usb host0 ohci controller but doesn't actually work
> on real hardware but it works with new revision chip rk3288w.
>
> So, disable ohci for rk3288.
>
> For rk3288w chips the compatible update code is handled by bootloader.
>
> Cc: William Wu <william.wu@rock-chips.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Note:
> - U-Boot patch for compatible update
> https://patchwork.ozlabs.org/project/uboot/patch/20200702084820.35942-1-jagan@amarulasolutions.com/
>
> drivers/usb/host/ohci-platform.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> index 7addfc2cbadc..24655ed6a7e0 100644
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -96,7 +96,7 @@ static int ohci_platform_probe(struct platform_device *dev)
> struct ohci_hcd *ohci;
> int err, irq, clk = 0;
>
> - if (usb_disabled())
> + if (usb_disabled() || of_machine_is_compatible("rockchip,rk3288"))
This seems unnecessary to me - if we've even started probing a driver
for a broken piece of hardware to the point that we need magic checks to
bail out again, then something is already fundamentally wrong.
Old boards only sold with the original SoC variant have no reason to
enable the OHCI (since it never worked originally), thus will never
execute this check.
New boards designed around the W variant to make use of the OHCI can
freely enable it either way.
The only relative-edge-case where it might matter is older board designs
still in production which have shipped with both SoC variants. Enabling
OHCI can't be *necessary* given that it's still broken on a lot of
deployed boards, so at best it must be an opportunistic nice-to-have.
Since we're already having to rely on the bootloader to patch up the
devicetree for other low-level differences in this case, it should be
part of that responsibility for it to only enable the OHCI on the
appropriate SoC variant too. Statically enabling it in the DTS for a
board where it may well not work is just bad.
As soon as a DTB with a broken piece of hardware enabled gets passed to
an OS, then the damage is already done. A driver patch in a future
version of Linux that magically knows better and ignores it isn't going
to help a user booting an older kernel image, or some other OS entirely.
Robin.
> return -ENODEV;
>
> /*
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] usb: host: ohci-platform: Disable ohci for rk3288
2020-07-02 14:38 ` Robin Murphy
@ 2020-07-03 11:39 ` Jagan Teki
2020-07-03 17:08 ` Robin Murphy
0 siblings, 1 reply; 5+ messages in thread
From: Jagan Teki @ 2020-07-03 11:39 UTC (permalink / raw)
To: Robin Murphy
Cc: Alan Stern, Greg Kroah-Hartman, Heiko Stuebner, Rob Herring,
Mylène Josserand, linux-usb, linux-kernel,
open list:ARM/Rockchip SoC...,
Suniel Mahesh, William Wu, Michael Trimarchi, linux-amarula,
Kever Yang
On Thu, Jul 2, 2020 at 8:08 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2020-07-02 10:05, Jagan Teki wrote:
> > rk3288 has usb host0 ohci controller but doesn't actually work
> > on real hardware but it works with new revision chip rk3288w.
> >
> > So, disable ohci for rk3288.
> >
> > For rk3288w chips the compatible update code is handled by bootloader.
> >
> > Cc: William Wu <william.wu@rock-chips.com>
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > Note:
> > - U-Boot patch for compatible update
> > https://patchwork.ozlabs.org/project/uboot/patch/20200702084820.35942-1-jagan@amarulasolutions.com/
> >
> > drivers/usb/host/ohci-platform.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> > index 7addfc2cbadc..24655ed6a7e0 100644
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -96,7 +96,7 @@ static int ohci_platform_probe(struct platform_device *dev)
> > struct ohci_hcd *ohci;
> > int err, irq, clk = 0;
> >
> > - if (usb_disabled())
> > + if (usb_disabled() || of_machine_is_compatible("rockchip,rk3288"))
>
> This seems unnecessary to me - if we've even started probing a driver
> for a broken piece of hardware to the point that we need magic checks to
> bail out again, then something is already fundamentally wrong.
>
> Old boards only sold with the original SoC variant have no reason to
> enable the OHCI (since it never worked originally), thus will never
> execute this check.
>
> New boards designed around the W variant to make use of the OHCI can
> freely enable it either way.
>
> The only relative-edge-case where it might matter is older board designs
> still in production which have shipped with both SoC variants. Enabling
> OHCI can't be *necessary* given that it's still broken on a lot of
> deployed boards, so at best it must be an opportunistic nice-to-have.
> Since we're already having to rely on the bootloader to patch up the
> devicetree for other low-level differences in this case, it should be
> part of that responsibility for it to only enable the OHCI on the
> appropriate SoC variant too. Statically enabling it in the DTS for a
> board where it may well not work is just bad.
You mean enable OHCI by identifying revision W with dts status "okay"?
doesn't it complex for the bootloader to update all effecting changes?
Jagan.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] usb: host: ohci-platform: Disable ohci for rk3288
2020-07-03 11:39 ` Jagan Teki
@ 2020-07-03 17:08 ` Robin Murphy
0 siblings, 0 replies; 5+ messages in thread
From: Robin Murphy @ 2020-07-03 17:08 UTC (permalink / raw)
To: Jagan Teki
Cc: Alan Stern, Greg Kroah-Hartman, Heiko Stuebner, Rob Herring,
Mylène Josserand, linux-usb, linux-kernel,
open list:ARM/Rockchip SoC...,
Suniel Mahesh, William Wu, Michael Trimarchi, linux-amarula,
Kever Yang
On 2020-07-03 12:39, Jagan Teki wrote:
> On Thu, Jul 2, 2020 at 8:08 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2020-07-02 10:05, Jagan Teki wrote:
>>> rk3288 has usb host0 ohci controller but doesn't actually work
>>> on real hardware but it works with new revision chip rk3288w.
>>>
>>> So, disable ohci for rk3288.
>>>
>>> For rk3288w chips the compatible update code is handled by bootloader.
>>>
>>> Cc: William Wu <william.wu@rock-chips.com>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>> Note:
>>> - U-Boot patch for compatible update
>>> https://patchwork.ozlabs.org/project/uboot/patch/20200702084820.35942-1-jagan@amarulasolutions.com/
>>>
>>> drivers/usb/host/ohci-platform.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
>>> index 7addfc2cbadc..24655ed6a7e0 100644
>>> --- a/drivers/usb/host/ohci-platform.c
>>> +++ b/drivers/usb/host/ohci-platform.c
>>> @@ -96,7 +96,7 @@ static int ohci_platform_probe(struct platform_device *dev)
>>> struct ohci_hcd *ohci;
>>> int err, irq, clk = 0;
>>>
>>> - if (usb_disabled())
>>> + if (usb_disabled() || of_machine_is_compatible("rockchip,rk3288"))
>>
>> This seems unnecessary to me - if we've even started probing a driver
>> for a broken piece of hardware to the point that we need magic checks to
>> bail out again, then something is already fundamentally wrong.
>>
>> Old boards only sold with the original SoC variant have no reason to
>> enable the OHCI (since it never worked originally), thus will never
>> execute this check.
>>
>> New boards designed around the W variant to make use of the OHCI can
>> freely enable it either way.
>>
>> The only relative-edge-case where it might matter is older board designs
>> still in production which have shipped with both SoC variants. Enabling
>> OHCI can't be *necessary* given that it's still broken on a lot of
>> deployed boards, so at best it must be an opportunistic nice-to-have.
>> Since we're already having to rely on the bootloader to patch up the
>> devicetree for other low-level differences in this case, it should be
>> part of that responsibility for it to only enable the OHCI on the
>> appropriate SoC variant too. Statically enabling it in the DTS for a
>> board where it may well not work is just bad.
>
> You mean enable OHCI by identifying revision W with dts status "okay"?
> doesn't it complex for the bootloader to update all effecting changes?
Well, on boards which may have either SoC it's already got to detect the
difference and make at least a couple of other DT adjustments; a handful
more lines to check for a specific node and flip its status wouldn't be
too horrendous (although I suppose you'd also want to check whether the
EHCI is enabled first, to guess at whether the port's even wired up at all).
Or alternatively, as I said, simply don't bother doing anything - boards
that only use RK3288W can enable OHCI in their DTS, and other boards
that have been not using it for however many years can continue not
using it even if it might technically be available on newer production runs.
Robin.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-07-03 17:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-02 9:05 [PATCH] usb: host: ohci-platform: Disable ohci for rk3288 Jagan Teki
2020-07-02 13:26 ` Alan Stern
2020-07-02 14:38 ` Robin Murphy
2020-07-03 11:39 ` Jagan Teki
2020-07-03 17:08 ` Robin Murphy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).