[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1405291139000.1285-100000@iolanthe.rowland.org>
Date: Thu, 29 May 2014 11:44:14 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Nikita Yushchenko <nyushchenko@....rtsoft.ru>
cc: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
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
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
--
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/
Powered by blists - more mailing lists