Patrick Mochel <mochel@osdl.org> writes:
> On 16 Jul 2002, Eric W. Biederman wrote:
>
> > Greg KH <greg@kroah.com> 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.
>From the firmware side it is easy to tell the kernel there is a rom
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:23 EST