Re: PATCH: move cardbus container to "pci" devclass

First, CardBus is not PCI.  It is a derivative of PCI that has its
own, weird rules for configuring cards.  Our current implementation
doesn't follow all the weird rules, since most cardbus hardware is the
same silicon as pci hardware.  However, for attachment and such there
likely needs to be a distinction.

In message: <20030625160525.46bcef88.eaja_at_erols.com>
            Eric Jacobs <eaja_at_erols.com> writes:
: I have made a patch for -CURRENT and 5.1-RELEASE that hopefully
: improves the support for Cardbus devices by changing the "cardbus"
: driver to implement the "pci" devclass rather than the "cardbus"
: devclass, and to make their unit numbers correspond with the
: PCI secondary bus numbers that their bridges are assigned.

I both like and dislike this patch.  It has advantages and
disadvantages :-)

: This has a number of advantages:
: 
:  - User mode tools that interface with the /dev/pci interface
:    such as pciconf and lspci (from ports) are now able to access
:    Cardbus devices without modifications.

This is cool.  There are other ways that this could be done.

:  - PCI drivers no longer need an additional driver declaration
:    in order to support cardbus, e.g., in
: 
: ./pci/if_xl.c:DRIVER_MODULE(xl, cardbus, xl_driver, xl_devclass, 0, 0);
: ./pci/if_xl.c:DRIVER_MODULE(xl, pci, xl_driver, xl_devclass, 0, 0);
: 
:    only the second line is required. (The first is harmless though.)

I'm not sure this is a good idea.  Cardbus is supposed to be
configured in a different way than pci.  The fact that we're able to
get away with just looking at the vendor/subvendor fields means we're
lucky.  That violates the spec.  Also, I've added the cardbus line
whenever I've verified that the hardware exists in cardbus form and
when I have some modest reason to expect it to work.

:  - Because the unit numbers in the "pci" devclass now represent
:    the PCI bus numbers in use in the system, we now have a good
:    way of assigning bus numbers to the Cardbus bridges in lieu
:    of the PCI BIOS doing so, which is not something we can expect
:    all BIOSes to do. (The old code incremented a static counter
:    starting from 2 by 3 every time this condition occurred,
:    which wasn't correct because there could already be a pci2
:    in the system, and the counter would eventually recycle.)

This is also cool.  The current kludge we have is ugly, and has the
problems you describe.

: And a couple of potential drawbacks:
: 
:  - Drivers that need to behave differently for Cardbus devices
:    can't do so by declaring another driver_t specifically for
:    cardbus. (No driver that I'm aware of does this, however;
:    they all use the same driver_t.)

None currently do, but some might need to in the future.  While this
could be supported with kobj returning errors in the raw pci case and
no errors in the cardbus case, I think that would make for some icky
attachment code.  I'm torn on this issue a little.

:  - Users that are accustomed to newbus nameunits containing
:    descriptive information about devices may prefer to see,
:    for example, "cardbus0" rather than "pci2".

This is a very useful distinction.  It makes it a lot easier to say
'do this when a cardbus card attaches, but do that when a non-cardbus
card attaches'.  devd exposes this to the user now, and i'd prefer to
keep this distinction.  i don't mind if it is called cardbus2 rather
than cardbus0 when the cardbus has a bus number of 2.  I have a laptop
that has a rl0 on pci0 and a rl1 on cardbus0.  I'd like to continue to
have devd able to do different thing to each one based on their
location, not on the rl number.

:    Note that
:    using newbus in this way defeats a good deal of its
:    potential for object-oriented design.

I don't understand this comment at all.

: The patches are at
: 
: http://users.erols.com/eaja/cardbus51.diff
: http://users.erols.com/eaja/cardbuscurrent.diff
: 
: Any comments?

I think that these are patches that I can work with.  However, it
assumes that the bus number and the pci unit number are the same.
This may be true on some machines, but definitely isn't true on all
machines.  We also need to reserve, like windows does, at least one
additional bus per slot to deal with cards that have bridges on them
(there are a few, including nasty things like cardbus to pci bridges
so you can have 5 pci slots on your laptop).

Warner