Re: Removal of pci_find_* in 2.5

[Eric W. Biederman]

Patrick Mochel <[e-mail]> writes:

> On 16 Jul 2002, Eric W. Biederman wrote:
> 
> > Greg KH <[e-mail]> writes:
> > 
> > > 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.

A clarification here.  I am thinking of drivers/mtd/maps/ich2rom.c, or
drivers/mtd/maps/amd766rom.c.  (Should be in 2.4.19).  What the driver
do is find a pci bridge device behind which rom chips are usually
found, and then it probes for a rom chip, behind the bridge.  

Despite being LPC/ISA, there is a moderately standard way of getting a
chip id from a rom chip (see drivers/mtd/chips/jedec_probe.c).  Armed
with the chip id I dynamically select the chip driver.  

In practice my driver really is a driver for a subset of the bridge
chip, allowing access to the rom chip.  Besides giving a clue which
addresses to probe the map driver also enables writes to the rom chip.

chip at address xxx for yyy bytes behind zzz.  The challenging part is
what structure the driver should really take.  And for that I am
asking for advice, or at least some ideas.

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

Well I want to keep the reminders coming of weird things that are
actually supportable right now, and to ask for help in finding better
ways to construct the drivers.  If I could just do firmware my job
would be so much easier :)

Eric