linux-kernel - Re: [PATCH] usb: pci-quirks: do not access OHCI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5387450C.7030207@dev.rtsoft.ru>
Date:	Thu, 29 May 2014 18:32:44 +0400
From:	Nikita Yushchenko <nyushchenko@....rtsoft.ru>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Mathias Nyman <mathias.nyman@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	lugovskoy@....rtsoft.ru
Subject: 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@...escale-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/