mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Greg KH <greg@kroah.com>, Linus Torvalds <torvalds@osdl.org>,
	Andrew Morton <akpm@zip.com.au>,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	parisc-linux@parisc-linux.org
Subject: Re: [PATCH] Sort generic PCI fixups after specific ones
Date: Fri, 24 Sep 2004 02:33:57 +0400	[thread overview]
Message-ID: <20040924023357.A2526@jurassic.park.msu.ru> (raw)
In-Reply-To: <20040923173151.GX16153@parcelfarce.linux.theplanet.co.uk>; from matthew@wil.cx on Thu, Sep 23, 2004 at 06:31:51PM +0100

On Thu, Sep 23, 2004 at 06:31:51PM +0100, Matthew Wilcox wrote:
> Not really.  There's two types of fixup (well, four if you multiply by
> the header vs later possibility).  There's the incredibly specific ("this
> device from this manufacturer forgets to set something properly") and
> the incredibly general ("if this is a cardbus / IDE device, then ...").
> This patch simply distinguishes between the two.  Obviously the general
> ones run after the specific ones -- there's specific devices that forget
> to set their class code, for example.

This is way not obvious. Example: some architecture requires to put
_all_ PCI IDE devices in native mode (obviously with a general fixup),
but what if some specific chips need additional "native mode only"
workarounds? Your logic won't work then.

I believe we do need third level of fixups, specifically for devices like
IDE which can change the PCI header contents (class code, BAR layout etc.)
depending on some magic bits in their registers.
Such "early" or "pre-header" fixups should be called right after the device
discovery, before probing the BARs. Apparently pci_setup_device()
is a proper place for that.

Ivan.

  reply	other threads:[~2004-09-23 22:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-22 21:43 Matthew Wilcox
2004-09-23 16:03 ` [parisc-linux] " Joel Soete
2004-09-23 17:20 ` Greg KH
2004-09-23 17:31   ` Matthew Wilcox
2004-09-23 22:33     ` Ivan Kokshaysky [this message]
2004-09-30 17:41       ` Matthew Wilcox
2004-10-01 15:13         ` [parisc-linux] " Joel Soete
2004-10-01 21:48         ` Ivan Kokshaysky
2004-10-05 15:29           ` Matthew Wilcox

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=20040924023357.A2526@jurassic.park.msu.ru \
    --to=ink@jurassic.park.msu.ru \
    --cc=akpm@zip.com.au \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=matthew@wil.cx \
    --cc=parisc-linux@parisc-linux.org \
    --cc=torvalds@osdl.org \
    /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

all inboxes | Powered by JetHome®