public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Adam Belay <ambx1@neo.rr.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 14:31:09 -0700	[thread overview]
Message-ID: <20050701213109.GA1834@kroah.com> (raw)
In-Reply-To: <20050701195232.GB3742@neo.rr.com>

On Fri, Jul 01, 2005 at 03:52:32PM -0400, Adam Belay wrote:
> 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.

No, bind/unbind (well bind, unbind doesn't care) only will work if the
driver's probe function can accept the device.  Without dynamic ids,
it's not possible to have a driver bind to a device that it does not
know about.

I want to put the sysfs file, and a common callback in the driver core,
to make it easier for busses to support dynamic ids.  That's why I am
suggesting we add it there.  But I'll play with implementing it and see
if it's really worth it or not.

Either way, this patch fixes up the pci code to make the dynamic ids for
it, much more readable and smaller.

> 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.

True, if you look at the current pci dynamic id stuff, we don't set the
driver_data field at all.  Some USB drivers use this field too.

> 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.

For this to happen, we would have to rewrite all drivers :(  Right now
they assume that the MODULE_TABLE must have matched, in order for the
probe() call to be called.  

Remember, probe() of most busses pass in a valid id structure too...

> If the driver developer requires the driver to match to an unknown
> pool of devices, then the *probe function could be made more advanced.

If the bus/driver core supports dynamic ids, then the individual drivers
don't have to be changed at all :)

thanks,

greg k-h

  reply	other threads:[~2005-07-01 21:35 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
2005-07-01 21:31   ` Greg KH [this message]
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=20050701213109.GA1834@kroah.com \
    --to=greg@kroah.com \
    --cc=Matt_Domsch@dell.com \
    --cc=ambx1@neo.rr.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