Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
On Thu, 29 May 2014, Nikita Yushchenko wrote: > >> I've checked these... all values read as 0x - which does not > >> look correct > > > > You could have the platform setup code read one of those hardware > > registers, such as FMINTERVAL. If it obtains 0x, 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 0x, deregister the device from the PCI bus. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 0x - which does not >> look correct > > You could have the platform setup code read one of those hardware > registers, such as FMINTERVAL. If it obtains 0x, 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 0x - which does not > look correct You could have the platform setup code read one of those hardware registers, such as FMINTERVAL. If it obtains 0x, don't register the OHCI controller as a platform device. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
>>> 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 :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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 :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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 0x - which does not look correct You could have the platform setup code read one of those hardware registers, such as FMINTERVAL. If it obtains 0x, don't register the OHCI controller as a platform device. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 0x - which does not look correct You could have the platform setup code read one of those hardware registers, such as FMINTERVAL. If it obtains 0x, 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
On Thu, 29 May 2014, Nikita Yushchenko wrote: I've checked these... all values read as 0x - which does not look correct You could have the platform setup code read one of those hardware registers, such as FMINTERVAL. If it obtains 0x, 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 0x, deregister the device from the PCI bus. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
> 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 0x - which does not look correct readl(base + OHCI_CONTROL) several lines before returns 0x Read of HcRevision register (base + 0x0) at the same point returns 0x0110. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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:
> [] 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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:
[] 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 0x - which does not look correct readl(base + OHCI_CONTROL) several lines before returns 0x Read of HcRevision register (base + 0x0) at the same point returns 0x0110. 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 --- drivers/usb/host/pci-quirks.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 nyushche...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 nyushche...@dev.rtsoft.ru --- drivers/usb/host/pci-quirks.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 nyushche...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw
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 nyushche...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
