public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Brownell <david-b@pacbell.net>
Cc: linux-usb-devel@lists.sourceforge.net,
	Paul Mackerras <paulus@samba.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] Re: Commit "[PATCH] USB: Always do usb-handoff" breaks my powerbook
Date: Tue, 01 Nov 2005 13:41:43 +1100	[thread overview]
Message-ID: <1130812903.29054.408.camel@gaston> (raw)
In-Reply-To: <200510311741.56638.david-b@pacbell.net>


> No PCI quirk code has ever called pci_enable_device() AFAICT.

Most PCI quirks only do config space accesses

> Of course the _need_ to do such a thing might be another PPC-specific
> (or OpenFirmware-specific?) PCI thing ... we've hit other cases where
> PPC breaks things that work on other PCI systems (and vice versa).

"ppc" doens't do anything fancy that other archs don't do too, please
stop with your "ppc specific" thing all over the place.

It is illegal, whatever the platform is, to tap a PCI device MMIO like
that without calling pci_enable_device(), requesting resources etc... or
at the very least, testing if MMIO decoding is enabled on the chip.
Period. It has nothing to do with PPC and all to do with correctness.

> If quirk code can't rely on BARs, then the PCI system needs some
> basic overhauls ... yes?  I mean, how could quirk code ever work
> if it can't access the relevant chip registers??

Most quirk only ever use config space. BARs are _not_ guaranteed to be
set at quirk time. In fact, those devices are left disabled on purpose,
thus you should at least test if MMIO access is enabled, and if not,
avoid touching the device at all.

> > I'm not sure it's legal to do pci_enable_device() from within a pci
> > quirk anyway. I really wonder what that code is doing in the quirks, I
> > don't think it's the right place, but I may be wrong.
> 
> Erm, what "code is doing" what, that you mean ??

What _That_ code is doing in the quirks... shouldn't it be in the
{U,O,E}HCI drivers instead ?

> > What is the logic supposed to be there ?
> 
> Which logic?  The fundamental thing those USB handoff functions do
> is make sure that BIOS code lets go of the host controllers.  The
> main reason it'd be using a controller is because of USB keyboards,
> mice, or maybe boot disks.  Secondarily, that code needs to make
> sure the controller is really quiesced before Linux starts using it.

So you rant about "ppc specific" whatever while the entire point of this
code is to workaround x86 specific BIOS junk ...

Ben.



  reply	other threads:[~2005-11-01  2:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-31  5:23 Commit "[PATCH] USB: Always do usb-handoff" breaks my powerbook Paul Mackerras
2005-11-01  0:16 ` Benjamin Herrenschmidt
2005-11-01  1:41   ` [linux-usb-devel] " David Brownell
2005-11-01  2:41     ` Benjamin Herrenschmidt [this message]
2005-11-01  3:09       ` David Brownell
2005-11-01  3:30         ` Benjamin Herrenschmidt
2005-11-01  4:17           ` David Brownell
2005-11-01  4:52             ` Paul Mackerras
2005-11-01  5:08               ` Benjamin Herrenschmidt
2005-11-01  9:28           ` Alan Cox
2005-11-01 13:40             ` Glenn Maynard
2005-11-01 21:09             ` Benjamin Herrenschmidt
2005-11-01  3:39         ` Dmitry Torokhov
2005-11-01  4:06         ` Kyle Moffett
2005-11-01  4:39           ` David Brownell
  -- strict thread matches above, loose matches on Subject: below --
2005-11-02  4:21 Aleksey Gorelov

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=1130812903.29054.408.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=paulus@samba.org \
    --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