[lkml]   [2002]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Removal of pci_find_* in 2.5

On 16 Jul 2002, Eric W. Biederman wrote:

> Greg KH <> writes:
> > On Sun, Jul 14, 2002 at 02:07:01PM -0600, Eric W. Biederman wrote:
> > >
> > > The driver is a mtd map driver. It knows there is a rom chip behind
> > > a pci->isa bridge. And it needs to find the pci->isa bridge to
> > > properly set it up to access the rom chip (enable writes and the
> > > like).
> > >
> > > It isn't a driver for the pci->isa bridge, (I'm not even certain we
> > > have a good model for that). So it does not use pci_register_driver.
> > >
> > > If you can give me a good proposal for how to accomplish that kind of
> > > functionality I would be happy to use the appropriate
> > > xxx_register_driver.
> >
> > I don't think there is a good way for you to convert over to
> > _register_driver(), that's the main reason I'm keeping the pci_find_*
> > functions around, they are quite useful for lots of situations.
> >
> > It doesn't sound like you are worrying about your device working in a
> > pci hotplug system, and you would probably be willing do any pci device
> > conversion work to the new driver model yourself, right? :)
> Assuming I can actually fit in better with the new driver model. As
> far as hot-plug. It is an abuse but I regularly hot-swap my rom chips
> in my development system.

No, but you do do firmware, and you have a desire to tell the kernel about
which devices are in the system from the firmware. The code path once you
discover the device is exactly the same as if you were to actually plug
in the device, or probe for it natively.

Though making legacy drivers hotpluggable seems absurd, the capability is
actually a requirement for supporting many firmwares.

> I am probably looking at this from the wrong angle but my problem with
> current code base seems to be that I can only have one driver per pci
> device.

Don't most people? :)

> In any case I would like to have code that fits in nicely with the
> new driver system. I can take about one change in kernel API. For
> the most part the drivers are trivial, and having non-trivial
> maintenance for trivial code is less than ideal.

We don't want to make things difficult. It's a PITA right now, since the
documentation is lacking and not all the infrastructure is in place to
really start plowing ahead. But, it will get better..


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.045 / U:1.116 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site