Re: Platform drivers vs device drivers

[Kristoffer E. <kri...@gm...>]

Thanks for explaining, will take the time to look through the documentation
you suggested. I see your point.

2007/5/30, Paul Mundt <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.
>