public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Belay <ambx1@neo.rr.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, Matt_Domsch@dell.com,
	linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [RFC] PCI: clean up the dynamic pci id logic
Date: Fri, 1 Jul 2005 15:52:32 -0400	[thread overview]
Message-ID: <20050701195232.GB3742@neo.rr.com> (raw)
In-Reply-To: <20050630091812.GA25285@kroah.com>

On Thu, Jun 30, 2005 at 02:18:12AM -0700, Greg KH wrote:
> Hi,
> 
> The dynamic pci id logic has been bothering me for a while, and now that
> I started to look into how to move some of this to the driver core, I
> thought it was time to clean it all up.
> 
> So here's a patch against 2.6.13-rc1 that does so.  It ends up making
> the code smaller, and easier to follow, and fixes a few bugs at the same
> time (dynamic ids were not being matched everywhere, and so could be
> missed on some call paths for new devices, semaphore not needed to be
> grabbed when adding a new id and calling the driver core, etc.)
> 
> Matt, any objection to this patch?
> 
> I also renamed the function pci_match_device() to pci_match_id() as
> that's what it really does, but maybe I should just put it back to be
> compatible.  Nah...
> 

Hi Greg,

I was wondering why we need dynamic id support in the driver core.  Is there
an issue where the bind/unbind mechanism requires this feature?  I was hoping
bind/unbind would replace it.

I understand that there are PCI drivers that use .driver_data and read from
their ID table (e.g. pci_serial), but we don't really want the user modifying
these IDs because they're often attached to some device specific tables.

It was my understanding that the *probe function should be responsible for
accepting any device, and then gracefully fail if it knows it will be unable
to support it.  For some drivers this could include failing if it's missing
from the ID table.  If the driver developer requires the driver to match to
an unknown pool of devices, then the *probe function could be made more
advanced.

Thanks,
Adam

  reply	other threads:[~2005-07-01 19:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-30  9:18 [RFC] PCI: clean up the dynamic pci id logic Greg KH
2005-07-01 19:52 ` Adam Belay [this message]
2005-07-01 21:31   ` Greg KH
2005-07-01 23:37     ` Adam Belay

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=20050701195232.GB3742@neo.rr.com \
    --to=ambx1@neo.rr.com \
    --cc=Matt_Domsch@dell.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    /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