public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Engraf <david.engraf@netcom.eu>
To: Greg KH <gregkh@suse.de>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	linux-pci@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org,
	linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured
Date: Fri, 03 Aug 2007 08:52:54 +0200	[thread overview]
Message-ID: <46B2D0C6.5010409@netcom.eu> (raw)
In-Reply-To: <20070802164329.GD28721@suse.de>

Greg KH schrieb:
> On Thu, Aug 02, 2007 at 10:32:21AM -0400, Alan Stern wrote:
>   
>> On Thu, 2 Aug 2007, David Engraf wrote:
>>
>>     
>>> This would be solution too, but what if someone uses the uhci controller
>>> and don't want the
>>> ehci. So a single Kconfig flag wouldn't be enough, we have to add 3
>>> flags for uchi, ohci and
>>> ehci. I think this maybe a little bit difficult when configuring the kernel.
>>> The best solution would be when we could use the CONFIG_USB_xxxx_HCD
>>> flag, but it
>>> seems that some hardware has problems when we disable the handoff and
>>> let the BIOS
>>> control the usb controller. Do you know any of this hardware?
>>>       
>> The email messages are hidden in the depths of the linux-usb-devel 
>> archives.  Maybe you can find them by checking the Git history for 
>> drivers/usb/host/pci-quirks.c, finding the dates for patches that 
>> affected the handoff code, and then searching through the archives near 
>> those dates.
>>
>> IIRC the problems arose on some MIPS machines.  And I don't think the 
>> problem involved letting the firmware manage the USB controller; I 
>> think the problem came when the controller driver tried to do the 
>> handoff later on.
>>     
>
> It wasn't just MIPS.  IBM has a very popular blade system that has huge
> issues with this, and I think there are some other IBM systems based on
> the same BIOS that also do bad things if we don't grab the USB
> controller away from the BIOS as soon as possible (nasty interrupt and
> other messes happen...)
>
> thanks,
>
> greg k-h
>   
So we have hardware which has problems when we are not doing the
handoff, and hardware which has
problems when we are  doing the handoff...
What is the best way to solve the problem? Maybe a kernel parameter, a
config flag or an automatic
hardware dependent check of the system?
In fact it is hard to find a solution which works for both as long as
the hardware has this bugs.


Thanks


David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel: 	+49 6131 6305 0
Fax: 	+49 6131 6305 40
Email: 	david.engraf@netcom.eu

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto


  reply	other threads:[~2007-08-03  6:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-31  8:31 [PATCH] USB BIOS early handoff only when the we the driver is configured David Engraf
2007-07-31 15:04 ` [linux-usb-devel] " Alan Stern
     [not found]   ` <46B03078.5040305@netcom.eu>
2007-08-01  7:21     ` David Engraf
2007-08-01 20:23       ` Greg KH
2007-08-02  7:07         ` David Engraf
2007-08-01 14:40     ` Alan Stern
2007-08-02  7:14       ` David Engraf
2007-08-02 14:32         ` Alan Stern
2007-08-02 16:43           ` Greg KH
2007-08-03  6:52             ` David Engraf [this message]
2007-08-03 15:03               ` Alan Stern
2007-08-07  8:44                 ` David Engraf
2007-08-07 14:37                   ` Alan Stern
2007-08-03 22:24             ` Grant Grundler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46B2D0C6.5010409@netcom.eu \
    --to=david.engraf@netcom.eu \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox