tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

RFC: device flavours

Hi all,

I'm looking for comments about what I call "device flavours".  The best
example of the kind of situation it tries to be an answer for is the
multiplicity of drivers one can find around the source tree for PCI-ISA
bridges (mostly on x86).  An even older idea of mine is to finally see
legacy devices listed in the ACPI tables attached to the PCI-ISA bridge
where they logically belong, and device flavours can be used for that,

Here's an exerpt of the dmesg output I get on my EeeBox, with two
flavours defined, ichlpc (to replace ichlpcib(4)) and acpiib (to let
legacy devices attach there;  I've only let npx(4) attach though for the
sake of the test):

pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x27b9 (rev. 0x02)
timecounter: Timecounter "pcib0/ichlpc" frequency 3579545 Hz quality 1000
pcib0/ichlpc: 24-bit timer
pcib0/ichlpc: TCO (watchdog) timer configured.
gpio5 at pcib0: 64 pins
pcib0/acpiib: ACPI node SBRG
npx1 at pcib0 (COPR, PNP0C04): io 0xf0-0xff irq 13
npx1: reported by CPUID; using exception 16
SIOR (PNP0C02) at pcib0 not configured
RMSC (PNP0C02) at pcib0 not configured
OMSC (PNP0C02) at pcib0 not configured

A device flavour is essentially an incomplete device driver.  That means
it will never be active unless a driver has already attached to a
device.  But the main point is that a flavour can be created without the
main driver being aware of it;  additionally, a flavour gets its own
device_t and thus can interact on its own with any subsystem that uses
device_t, mostly pmf(9).  (And, as you can see in the example,
aprint_*_dev functions.)

On the config(5) side, a device flavour is defined as something that
attaches to an interface attribute.  The reason for that is of course
that there is no need for it to assume the name of the main driver to
function properly.

So, in my files.* I have defined the following:

flavour acpiib at pci: acpinodebus
file    dev/acpi/acpiib.c               acpiib

flavour ichlpc at pci:  acpipmtimer, sysmon_wdog, fwhichbus, hpetichbus, gpiobus
file    arch/x86/pci/ichlpc.c           ichlpc

And then in my kernel config file I added the following:

flavours ichlpc, acpiib
npx*    at pcib?
gpio*   at gpiobus?

(The last two lines are there only to explain the attachments in the

At run time, I am only going to describe what happens at attachment
time, because I haven't done anything about detach yet.  When a device
is *found* (i.e., once its device_t has been created and linked) using
the interface attribute "pci", the match functions of all flavours of
the pci interface attribute are called, and for each that returns
non-zero, a device_t object is created using the name "device/flavour"
and add to the "parent" device_t's list of flavours.

Then when what is really a sibling driver is attached, a call is made
the the flavour's callback.  In my proof-of-concept code I added a call
right before the main driver is attached, and another one right after,
because there might be situations where either is needed (and typically
for a flavour that enumerates children, it might prefer doing it before
the main driver gets a chance to do it).

For reference, my current patch:

Again, it is a proof of concept;  detaching is not handled, so the
kernel will fail to reboot, and there is no locking whatsoever, so Bad
Things could happen.

There are other situations in which I think device flavours could bring
clarity and also better modularisation.  For instance, support for CPU
features on x86 like EST or PowerNow, or even ACPI P-states could be
done that way, and it is more module-friendly because it wouldn't
require the main CPU driver to explicitely call those feature-drivers.

I've been wondering about simply allowing more than one driver to attach
to a device, and while this might be a lot simpler as far as config(1)
and even autoconf(9) are concerned, it raises other issues, like how to
deal with device_t's.  One thing I'd like to get input on anyway is how
to actually deal with pmf(9).  I haven't looked at it at all yet, but I
don't really expect miracles for my current patch.

Quentin Garnier - -
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgpQ0HqQ8ZCMG.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index