Re: Platform drivers vs device drivers

[Paul M. <le...@li...>]

On Tue, May 29, 2007 at 12:32:02AM -0700, Kristoffer Ericson wrote:
> From what I gather platform devices are devices that are expected to
> exist on a specific hardware. For example all hp jornada 680 devices
> contain an onboard keyboard which usually is a good thing to have.
> 
This sentence is fairly vague, so I'm not entirely sure what you're
confused about. The driver model supports busses with drivers that attach
to that bus, and then 'devices' that attach to that driver. The platform
bus itself is just a stupid bus for devices that are generally directly
connected and have a minimal level of intelligence associated with them.
ie, if it doesn't hang off of any other bus (or it's directly on SH-bus),
it's a platform device.

A board or CPU will simply register 'devices' for everything that it
has which have matching platform drivers. The platform device data itself
is __initdata, and will be freed up once we've booted and the drivers
have had a chance to claim the resources they're interested in. Whether
the driver manages to 'find' the device or not, depends on whether you
have that driver enabled or not (unclaimed devices are discarded, so it's
always safe to just register the entire set).

There are some documents on lwn.net regarding the basics of the driver
model, perhaps that would be a good place to start reading.

> If this is correct then my next question is, wouldn't it be desirable
> for the hp680 keyboard to be hardcoded in any kernel targetting a hp680
> (instead of being an optional kernel config)?
> 
Why on earth would you want to hardcode anything? The very idea behind
the driver model is so we do not have to do stupid things like that.
There's absolutely _nothing_ special about the hp680 keyboard, and there
are other boards which can use it as well (with a bit of reasonable
abstraction). Restricting a driver to a board is nonsensical, this isn't
2.4 any more.

> I can't see any benefit of being able to compile a kernel for that
> platform without keyboard support.

Then enable it in the defconfig. However, do not give in to this 'select'
brain-damage either, turning on subsystems unconditionally is evil.
People will configure what they want, the defconfig is simply a pointer
to what should result in a functional system out of the box.