[PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

This access causes hang on Freescale P2020DS board (that has OHCI
provided by ULI 1533 chip).

Since preserving OHCI_FMINTERVAL was originally done only for NVIDIA
hardware and only later (in c6187597) was turned unconditional, and
c6187597 commit message again mentions only NVIDIA, I think it should be
safe to disable preserving OHCI_FMINTERVAL if device vendor is ULI.

Signed-off-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
---
 drivers/usb/host/pci-quirks.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 00661d3..5acbd5b 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -571,7 +571,7 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
 {
 	void __iomem *base;
 	u32 control;
-	u32 fminterval;
+	u32 uninitialized_var(fminterval);
 	int cnt;
 
 	if (!mmio_resource_enabled(pdev, 0))
@@ -619,7 +619,8 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
 	}
 
 	/* software reset of the controller, preserving HcFmInterval */
-	fminterval = readl(base + OHCI_FMINTERVAL);
+	if (pdev->vendor != PCI_VENDOR_ID_AL)
+		fminterval = readl(base + OHCI_FMINTERVAL);
 	writel(OHCI_HCR, base + OHCI_CMDSTATUS);
 
 	/* reset requires max 10 us delay */
@@ -628,7 +629,8 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
 			break;
 		udelay(1);
 	}
-	writel(fminterval, base + OHCI_FMINTERVAL);
+	if (pdev->vendor != PCI_VENDOR_ID_AL)
+		writel(fminterval, base + OHCI_FMINTERVAL);
 
 	/* Now the controller is safely in SUSPEND and nothing can wake it up */
 	iounmap(base);
-- 
1.7.10.4

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Alan Stern]

On Tue, 27 May 2014, Nikita Yushchenko wrote:

> This access causes hang on Freescale P2020DS board (that has OHCI
> provided by ULI 1533 chip).

Which access, the read or the write?

> Since preserving OHCI_FMINTERVAL was originally done only for NVIDIA
> hardware and only later (in c6187597) was turned unconditional, and

Correction: Preserving OHCI_FMINTERVAL was originally done for all 
controllers that needed to be reset.  It just so happened that NVIDIA 
was the only one that got reset.  In c6187597 the reset became 
unconditional, so fminterval was preserved for all hardware.

> c6187597 commit message again mentions only NVIDIA, I think it should be
> safe to disable preserving OHCI_FMINTERVAL if device vendor is ULI.
> 
> Signed-off-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>

It looks like you haven't read ohci_shutdown() and ohci_run() in 
drivers/usb/host/ohci-hcd.c.  They both access the fminterval register, 
and this patch doesn't change them.

So I don't see why this patch should make any difference to the 
system's operation.

Alan Stern

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

27.05.2014 19:08, Alan Stern пишет:
> On Tue, 27 May 2014, Nikita Yushchenko wrote:
> 
>> This access causes hang on Freescale P2020DS board (that has OHCI
>> provided by ULI 1533 chip).
> 
> Which access, the read or the write?

things are a bit more complex.

If inserting printk's as below


--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -619,16 +619,23 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
        }

        /* software reset of the controller, preserving HcFmInterval */
+       printk("A1\n");
        fminterval = readl(base + OHCI_FMINTERVAL);
+       printk("A2\n");
        writel(OHCI_HCR, base + OHCI_CMDSTATUS);
+       printk("A3\n");

        /* reset requires max 10 us delay */
        for (cnt = 30; cnt > 0; --cnt) {        /* ... allow extra time */
+               printk("A4\n");
                if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
                        break;
+               printk("A5\n");
                udelay(1);
        }
+       printk("A6\n");
        writel(fminterval, base + OHCI_FMINTERVAL);
+       printk("A7\n");

        /* Now the controller is safely in SUSPEND and nothing can wake it up */
        iounmap(base);

attempt to boot (using arch/powerpc/configs/mpc85xx_smp_defconfig and deb
file built by "make p2020ds.dtb" from the same kernel tree) results in

...
A1
random: nonblocking pool is initialized
irq 26: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc6-dirty #5
Call Trace:
[effe5ed0] [c000726c] show_stack+0x48/0x15c (unreliable)
[effe5f10] [c05eece4] dump_stack+0x78/0xa0
[effe5f20] [c0087acc] __report_bad_irq+0x38/0x100
[effe5f40] [c0088060] note_interrupt+0x224/0x280
[effe5f70] [c008563c] handle_irq_event_percpu+0xc8/0x178
[effe5fa0] [c0085730] handle_irq_event+0x44/0x74
[effe5fc0] [c0088f88] handle_fasteoi_irq+0xd4/0x1d0
[effe5fd0] [c0084d20] generic_handle_irq+0x30/0x50
[effe5fe0] [c00048d0] __do_irq+0x2c/0x70
[effe5ff0] [c000d9a0] call_do_irq+0x24/0x3c
[ef047d10] [c00049a0] do_IRQ+0x8c/0xf8
[ef047d30] [c000f598] ret_from_except+0x0/0x18
--- Exception: 501 at quirk_usb_early_handoff+0x794/0x85c
    LR = quirk_usb_early_handoff+0x788/0x85c
[ef047e30] [c02bd66c] pci_fixup_device+0xe0/0x19c
[ef047e60] [c07d4e1c] pci_apply_final_quirks+0x60/0x13c
[ef047e90] [c0002494] do_one_initcall+0x158/0x19c
[ef047f00] [c07ba928] kernel_init_freeable+0x130/0x1e4
[ef047f30] [c0002a78] kernel_init+0x14/0x10c
[ef047f40] [c000f014] ret_from_kernel_thread+0x5c/0x64
handlers:
[<c001cc78>] fsl_pci_pme_handle
Disabling IRQ #26
A2
A3
A4
A5
A4
A5
A4
A5
A4
A5
A4

and hang.

with my patch applied, board just boots ok and works.


> It looks like you haven't read ohci_shutdown() and ohci_run() in 
> drivers/usb/host/ohci-hcd.c.  They both access the fminterval register, 
> and this patch doesn't change them.
> 
> So I don't see why this patch should make any difference to the 
> system's operation.

I think problem is caused by access to OHCI regs from PCI quirks - before
driver was initialized. ULI1553 southbridge chip could be in strange state
at this point.

Nikita

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Alan Stern]

On Wed, 28 May 2014, Nikita Yushchenko wrote:

> 27.05.2014 19:08, Alan Stern пишет:
> > On Tue, 27 May 2014, Nikita Yushchenko wrote:
> > 
> >> This access causes hang on Freescale P2020DS board (that has OHCI
> >> provided by ULI 1533 chip).
> > 
> > Which access, the read or the write?
> 
> things are a bit more complex.
> 
> If inserting printk's as below
> 
> 
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -619,16 +619,23 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
>         }
> 
>         /* software reset of the controller, preserving HcFmInterval */
> +       printk("A1\n");
>         fminterval = readl(base + OHCI_FMINTERVAL);
> +       printk("A2\n");

It would help to print the value of fminterval.

>         writel(OHCI_HCR, base + OHCI_CMDSTATUS);
> +       printk("A3\n");
> 
>         /* reset requires max 10 us delay */
>         for (cnt = 30; cnt > 0; --cnt) {        /* ... allow extra time */
> +               printk("A4\n");
>                 if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
>                         break;

And here to print the value obtained by the readl().

> +               printk("A5\n");
>                 udelay(1);
>         }
> +       printk("A6\n");
>         writel(fminterval, base + OHCI_FMINTERVAL);
> +       printk("A7\n");
> 
>         /* Now the controller is safely in SUSPEND and nothing can wake it up */
>         iounmap(base);
> 
> attempt to boot (using arch/powerpc/configs/mpc85xx_smp_defconfig and deb
> file built by "make p2020ds.dtb" from the same kernel tree) results in
> 
> ...
> A1
> random: nonblocking pool is initialized
> irq 26: nobody cared (try booting with the "irqpoll" option)
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc6-dirty #5
> Call Trace:
> [effe5ed0] [c000726c] show_stack+0x48/0x15c (unreliable)
> [effe5f10] [c05eece4] dump_stack+0x78/0xa0
> [effe5f20] [c0087acc] __report_bad_irq+0x38/0x100
> [effe5f40] [c0088060] note_interrupt+0x224/0x280
> [effe5f70] [c008563c] handle_irq_event_percpu+0xc8/0x178
> [effe5fa0] [c0085730] handle_irq_event+0x44/0x74
> [effe5fc0] [c0088f88] handle_fasteoi_irq+0xd4/0x1d0
> [effe5fd0] [c0084d20] generic_handle_irq+0x30/0x50
> [effe5fe0] [c00048d0] __do_irq+0x2c/0x70
> [effe5ff0] [c000d9a0] call_do_irq+0x24/0x3c
> [ef047d10] [c00049a0] do_IRQ+0x8c/0xf8
> [ef047d30] [c000f598] ret_from_except+0x0/0x18
> --- Exception: 501 at quirk_usb_early_handoff+0x794/0x85c
>     LR = quirk_usb_early_handoff+0x788/0x85c

That exception looks very suspicious.  Do you know what it means?

> [ef047e30] [c02bd66c] pci_fixup_device+0xe0/0x19c
> [ef047e60] [c07d4e1c] pci_apply_final_quirks+0x60/0x13c
> [ef047e90] [c0002494] do_one_initcall+0x158/0x19c
> [ef047f00] [c07ba928] kernel_init_freeable+0x130/0x1e4
> [ef047f30] [c0002a78] kernel_init+0x14/0x10c
> [ef047f40] [c000f014] ret_from_kernel_thread+0x5c/0x64
> handlers:
> [<c001cc78>] fsl_pci_pme_handle
> Disabling IRQ #26

It looks like this IRQ 26 stuff has no connection with OHCI, right?

> A2
> A3
> A4
> A5
> A4
> A5
> A4
> A5
> A4
> A5
> A4
> 
> and hang.

Meaning that it stops completely, not that it goes into an infinite 
loop?

> with my patch applied, board just boots ok and works.
> 
> 
> > It looks like you haven't read ohci_shutdown() and ohci_run() in 
> > drivers/usb/host/ohci-hcd.c.  They both access the fminterval register, 
> > and this patch doesn't change them.
> > 
> > So I don't see why this patch should make any difference to the 
> > system's operation.
> 
> I think problem is caused by access to OHCI regs from PCI quirks - before
> driver was initialized. ULI1553 southbridge chip could be in strange state
> at this point.

If that is the cause, we ought to be able to see it from the values
printed out by the debugging statements.  And if that is so, it's a
serious problem.  The southbridge chip really should be working at this
point, because the quirk_usb_handoff_* routines need to be able to
communicate with the host controllers.

Alan Stern

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

> It would help to print the value of fminterval.
> And here to print the value obtained by the readl().

I've checked these... all values read as 0xffffffff - which does not
look correct

readl(base + OHCI_CONTROL) several lines before returns 0x00000000
Read of HcRevision register (base + 0x0) at the same point returns
0x00000110.

If I comment out access to OHCI_FMINTERVAL, then, after writing OHCI_HCR
to CMDSTATUS, read of OHCI_CMDSTATUS immediately returns zero, and
routine succeeds.

>> irq 26: nobody cared (try booting with the "irqpoll" option)
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc6-dirty #5
>> Call Trace:
>> [effe5ed0] [c000726c] show_stack+0x48/0x15c (unreliable)
>> [effe5f10] [c05eece4] dump_stack+0x78/0xa0
>> [effe5f20] [c0087acc] __report_bad_irq+0x38/0x100
>> [effe5f40] [c0088060] note_interrupt+0x224/0x280
>> [effe5f70] [c008563c] handle_irq_event_percpu+0xc8/0x178
>> [effe5fa0] [c0085730] handle_irq_event+0x44/0x74
>> [effe5fc0] [c0088f88] handle_fasteoi_irq+0xd4/0x1d0
>> [effe5fd0] [c0084d20] generic_handle_irq+0x30/0x50
>> [effe5fe0] [c00048d0] __do_irq+0x2c/0x70
>> [effe5ff0] [c000d9a0] call_do_irq+0x24/0x3c
>> [ef047d10] [c00049a0] do_IRQ+0x8c/0xf8
>> [ef047d30] [c000f598] ret_from_except+0x0/0x18
>> --- Exception: 501 at quirk_usb_early_handoff+0x794/0x85c
>>     LR = quirk_usb_early_handoff+0x788/0x85c
> 
> That exception looks very suspicious.  Do you know what it means?

This is just what powerpc backtraces show for hardware interrupt.
I.e. hardware interrupt happened at quirk_usb_early_handoff+0x794/0x85c

> 
> It looks like this IRQ 26 stuff has no connection with OHCI, right?

26 is a virtual number, assigned by irq_of_parse_and_map() call.
Physically it is MPIC internal IRQ 9, which is PCI Express port 2 IRQ.
(ULI1553 southbridge is connected to PCI Express port 2).
This is not interrupt from PCI/PCIe device, but interrupt from
controller itself. However, per code in fsl_pci_pme_handle(), none of
bits in status register are set (otherwise it won't return IRQ_NONE, and
kernel won't claim that "nobody cared"). Looks bogus.

>> A2
>> A3
>> A4
>> A5
>> A4
>> A5
>> A4
>> A5
>> A4
>> A5
>> A4
>>
>> and hang.
> 
> Meaning that it stops completely, not that it goes into an infinite 
> loop?

Yes, it hangs.


>> I think problem is caused by access to OHCI regs from PCI quirks - before
>> driver was initialized. ULI1553 southbridge chip could be in strange state
>> at this point.
> 
> If that is the cause, we ought to be able to see it from the values
> printed out by the debugging statements.  And if that is so, it's a
> serious problem.  The southbridge chip really should be working at this
> point, because the quirk_usb_handoff_* routines need to be able to
> communicate with the host controllers.

In this case, communication looks possible.
However, read of OHCI_FMINTERVAL register somehow breaks it.

Nikita

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

>>> I think problem is caused by access to OHCI regs from PCI quirks - before
>>> driver was initialized. ULI1553 southbridge chip could be in strange state
>>> at this point.
>>
>> If that is the cause, we ought to be able to see it from the values
>> printed out by the debugging statements.  And if that is so, it's a
>> serious problem.  The southbridge chip really should be working at this
>> point, because the quirk_usb_handoff_* routines need to be able to
>> communicate with the host controllers.
> 
> In this case, communication looks possible.
> However, read of OHCI_FMINTERVAL register somehow breaks it.

I realized that source of the problem is elsewhere.

P2020DS board's USB connectors are not connected to ULI1553 USB.
These are connected to P2020 SOC's USB, handled by fsl-ehci driver (even
for USB 1.1 devices)
As for ULI1553 USB - it is not wired.
But - due to hardware misfeature - ULI1553 USB is not hardware-masked,
and with mainline kernel it visible on the bus:

root@freescale-p2020ds:~# lspci
0000:00:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 10)
0001:02:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 10)
0001:03:00.0 PCI bridge: ULi Electronics Inc. M5249 HTT to PCI Bridge
0001:04:1c.0 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)
0001:04:1c.1 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)
0001:04:1c.2 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)
0001:04:1c.3 USB controller: ULi Electronics Inc. USB 2.0 Controller (rev 01)
0001:04:1e.0 ISA bridge: ULi Electronics Inc. M1575 South Bridge
0001:04:1e.1 Bridge: ULi Electronics Inc. M7101 Power Management Controller [PMU]
0001:04:1f.0 IDE interface: ULi Electronics Inc. M5229 IDE (rev c8)
0001:04:1f.1 IDE interface: ULi Electronics Inc. ULi M5288 SATA (rev 10)
0002:05:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 10)

I forgot about that when checking our local tree for mainlineable commits.
Sorry.

I don't know how linux usb subsystem should behave against such
"half-existing" hardware. Perhaps hanging is not the best idea...
but maybe it should be fixed elsewhere, e.g. by masking non-wired
devices in platform PCI setup. Perhaps controlled by some device-tree
key.

Nikita

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[One Thousand Gnomes]

> I don't know how linux usb subsystem should behave against such
> "half-existing" hardware. Perhaps hanging is not the best idea...
> but maybe it should be fixed elsewhere, e.g. by masking non-wired
> devices in platform PCI setup. Perhaps controlled by some device-tree
> key.

Does it have a unique svid/sdid set for the platform - if so you could
just blacklist that combination of vid/did/svid/sdid.

Alan

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

29.05.2014 18:42, One Thousand Gnomes пишет:
>> I don't know how linux usb subsystem should behave against such
>> "half-existing" hardware. Perhaps hanging is not the best idea...
>> but maybe it should be fixed elsewhere, e.g. by masking non-wired
>> devices in platform PCI setup. Perhaps controlled by some device-tree
>> key.
> 
> Does it have a unique svid/sdid set for the platform - if so you could
> just blacklist that combination of vid/did/svid/sdid.

Unfortunately vid/did/svid/sdid come from ULI 1553 southbridge chip,
that is used by other hardware as well. AFAIK it is still being
manufactured, and could appear in PCs or laptops.

Nikita

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

29.05.2014 19:33, Nikita Yushchenko пишет:
> 29.05.2014 18:42, One Thousand Gnomes пишет:
>>> I don't know how linux usb subsystem should behave against such
>>> "half-existing" hardware. Perhaps hanging is not the best idea...
>>> but maybe it should be fixed elsewhere, e.g. by masking non-wired
>>> devices in platform PCI setup. Perhaps controlled by some device-tree
>>> key.
>>
>> Does it have a unique svid/sdid set for the platform - if so you could
>> just blacklist that combination of vid/did/svid/sdid.
> 
> Unfortunately vid/did/svid/sdid come from ULI 1553 southbridge chip,
> that is used by other hardware as well. AFAIK it is still being
> manufactured, and could appear in PCs or laptops.

Sorry I mistyped in entire thread... Chip is ULI M1575.

Nikita

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Alan Stern]

On Thu, 29 May 2014, Nikita Yushchenko wrote:

> 29.05.2014 18:42, One Thousand Gnomes пишет:
> >> I don't know how linux usb subsystem should behave against such
> >> "half-existing" hardware. Perhaps hanging is not the best idea...
> >> but maybe it should be fixed elsewhere, e.g. by masking non-wired
> >> devices in platform PCI setup. Perhaps controlled by some device-tree
> >> key.
> > 
> > Does it have a unique svid/sdid set for the platform - if so you could
> > just blacklist that combination of vid/did/svid/sdid.
> 
> Unfortunately vid/did/svid/sdid come from ULI 1553 southbridge chip,
> that is used by other hardware as well. AFAIK it is still being
> manufactured, and could appear in PCs or laptops.

> > It would help to print the value of fminterval.
> > And here to print the value obtained by the readl().
>
> I've checked these... all values read as 0xffffffff - which does not
> look correct

You could have the platform setup code read one of those hardware
registers, such as FMINTERVAL.  If it obtains 0xffffffff, don't
register the OHCI controller as a platform device.

Alan Stern

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

29.05.2014 19:44, Alan Stern пишет:
> On Thu, 29 May 2014, Nikita Yushchenko wrote:
> 
>> 29.05.2014 18:42, One Thousand Gnomes пишет:
>>>> I don't know how linux usb subsystem should behave against such
>>>> "half-existing" hardware. Perhaps hanging is not the best idea...
>>>> but maybe it should be fixed elsewhere, e.g. by masking non-wired
>>>> devices in platform PCI setup. Perhaps controlled by some device-tree
>>>> key.
>>>
>>> Does it have a unique svid/sdid set for the platform - if so you could
>>> just blacklist that combination of vid/did/svid/sdid.
>>
>> Unfortunately vid/did/svid/sdid come from ULI 1553 southbridge chip,
>> that is used by other hardware as well. AFAIK it is still being
>> manufactured, and could appear in PCs or laptops.
> 
>>> It would help to print the value of fminterval.
>>> And here to print the value obtained by the readl().
>>
>> I've checked these... all values read as 0xffffffff - which does not
>> look correct
> 
> You could have the platform setup code read one of those hardware
> registers, such as FMINTERVAL.  If it obtains 0xffffffff, don't
> register the OHCI controller as a platform device.

It is not a platform_device, it is PCI device that is found via bus scan.

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Alan Stern]

On Thu, 29 May 2014, Nikita Yushchenko wrote:

> >> I've checked these... all values read as 0xffffffff - which does not
> >> look correct
> > 
> > You could have the platform setup code read one of those hardware
> > registers, such as FMINTERVAL.  If it obtains 0xffffffff, don't
> > register the OHCI controller as a platform device.
> 
> It is not a platform_device, it is PCI device that is found via bus scan.

Yes, of course, I got it mixed up.

Well, the quirk_usb_handoff_ohci() routine could do something like 
this.  If the FMINTERVAL value is 0xffffffff, deregister the device 
from the PCI bus.

Alan Stern

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Sergei Shtylyov]

Hello.

On 05/27/2014 08:56 AM, Nikita Yushchenko wrote:

> This access causes hang on Freescale P2020DS board (that has OHCI
> provided by ULI 1533 chip).

> Since preserving OHCI_FMINTERVAL was originally done only for NVIDIA
> hardware and only later (in c6187597) was turned unconditional, and
> c6187597 commit message again mentions only NVIDIA, I think it should be

    Please also specify that commit's summary line in parens.

> safe to disable preserving OHCI_FMINTERVAL if device vendor is ULI.

> Signed-off-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
> ---
>   drivers/usb/host/pci-quirks.c |    8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)

WBR, Sergei

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

27.05.2014 20:39, Sergei Shtylyov пишет:
> Hello.
> 
> On 05/27/2014 08:56 AM, Nikita Yushchenko wrote:
> 
>> This access causes hang on Freescale P2020DS board (that has OHCI
>> provided by ULI 1533 chip).
> 
>> Since preserving OHCI_FMINTERVAL was originally done only for NVIDIA
>> hardware and only later (in c6187597) was turned unconditional, and
>> c6187597 commit message again mentions only NVIDIA, I think it should be
> 
>    Please also specify that commit's summary line in parens.

Sorry but can't get what you mean. Could you please be a bit more verbose?

Nikita

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Sergei Shtylyov]

Hello.

On 28-05-2014 11:21, Nikita Yushchenko wrote:

>>> This access causes hang on Freescale P2020DS board (that has OHCI
>>> provided by ULI 1533 chip).

>>> Since preserving OHCI_FMINTERVAL was originally done only for NVIDIA
>>> hardware and only later (in c6187597) was turned unconditional, and
>>> c6187597 commit message again mentions only NVIDIA, I think it should be

>>     Please also specify that commit's summary line in parens.

> Sorry but can't get what you mean. Could you please be a bit more verbose?

    Commit c6187597 (OHCI: final fix for NVIDIA problems (I hope)).

> Nikita

WBR, Sergei

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Greg Kroah-Hartman]

On Tue, May 27, 2014 at 08:56:42AM +0400, Nikita Yushchenko wrote:
> This access causes hang on Freescale P2020DS board (that has OHCI
> provided by ULI 1533 chip).
> 
> Since preserving OHCI_FMINTERVAL was originally done only for NVIDIA
> hardware and only later (in c6187597) was turned unconditional, and
> c6187597 commit message again mentions only NVIDIA, I think it should be
> safe to disable preserving OHCI_FMINTERVAL if device vendor is ULI.

Have you tested this?

> Signed-off-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
> ---
>  drivers/usb/host/pci-quirks.c |    8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 00661d3..5acbd5b 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -571,7 +571,7 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
>  {
>  	void __iomem *base;
>  	u32 control;
> -	u32 fminterval;
> +	u32 uninitialized_var(fminterval);

Why is this change needed?  Sounds like a compiler bug to me :)

thanks,

greg k-h

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

28.05.2014 03:27, Greg Kroah-Hartman пишет:
> On Tue, May 27, 2014 at 08:56:42AM +0400, Nikita Yushchenko wrote:
>> This access causes hang on Freescale P2020DS board (that has OHCI
>> provided by ULI 1533 chip).
>>
>> Since preserving OHCI_FMINTERVAL was originally done only for NVIDIA
>> hardware and only later (in c6187597) was turned unconditional, and
>> c6187597 commit message again mentions only NVIDIA, I think it should be
>> safe to disable preserving OHCI_FMINTERVAL if device vendor is ULI.
> 
> Have you tested this?

With this applied, board boots ok.
With this not applied, board hangs on boot.

As for OHCI functionality - this was tested by other people here, but with
older kernel. Will retest myself with 3.15-rc as soon as get physical access
to board.

>> -	u32 fminterval;
>> +	u32 uninitialized_var(fminterval);
> 
> Why is this change needed?  Sounds like a compiler bug to me :)

  CC      drivers/usb/host/pci-quirks.o
In file included from include/linux/io.h:22:0,
                 from include/linux/pci.h:31,
                 from drivers/usb/host/pci-quirks.c:14:
drivers/usb/host/pci-quirks.c: In function 'quirk_usb_early_handoff':
/home/cge7/nikita/kernel-u/arch/powerpc/include/asm/io.h:180:1: warning: 'fminterval' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/usb/host/pci-quirks.c:574:6: note: 'fminterval' was declared here

gcc version 4.7.0 (MontaVista Linux G++ 4.7-140519214821)


Nikita