[prev in list] [next in list] [prev in thread] [next in thread]
List: linuxsh-dev
Subject: Re: Platform drivers vs device drivers
From: "Kristoffer Ericson" <kristoffer.ericson () gmail ! com>
Date: 2007-05-30 12:24:53
Message-ID: 3ec861a70705300524k1dcd6d02jf2cac389efbc8a53 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks for explaining, will take the time to look through the documentation
you suggested. I see your point.
2007/5/30, Paul Mundt <lethal@linux-sh.org>:
>
> 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.
>
[Attachment #5 (text/html)]
Thanks for explaining, will take the time to look through the documentation you \
suggested. I see your point.<br><br> <div><span class="gmail_quote">2007/5/30, Paul \
Mundt <<a href="mailto:lethal@linux-sh.org">lethal@linux-sh.org</a>>:</span> \
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; \
BORDER-LEFT: #ccc 1px solid">On Tue, May 29, 2007 at 12:32:02AM -0700, Kristoffer \
Ericson wrote:<br>> From what I gather platform devices are devices that are \
expected to <br>> exist on a specific hardware. For example all hp jornada 680 \
devices<br>> contain an onboard keyboard which usually is a good thing to \
have.<br>><br>This sentence is fairly vague, so I'm not entirely sure what \
you're <br>confused about. The driver model supports busses with drivers that \
attach<br>to that bus, and then 'devices' that attach to that driver. The \
platform<br>bus itself is just a stupid bus for devices that are generally directly \
<br>connected and have a minimal level of intelligence associated with them.<br>ie, \
if it doesn't hang off of any other bus (or it's directly on \
SH-bus),<br>it's a platform device.<br><br>A board or CPU will simply register \
'devices' for everything that it <br>has which have matching platform \
drivers. The platform device data itself<br>is __initdata, and will be freed up once \
we've booted and the drivers<br>have had a chance to claim the resources \
they're interested in. Whether <br>the driver manages to 'find' the \
device or not, depends on whether you<br>have that driver enabled or not (unclaimed \
devices are discarded, so it's<br>always safe to just register the entire \
set).<br><br>There are some documents on <a href="http://lwn.net">lwn.net</a> \
regarding the basics of the driver<br>model, perhaps that would be a good place to \
start reading.<br><br>> If this is correct then my next question is, wouldn't \
it be desirable<br> > for the hp680 keyboard to be hardcoded in any kernel \
targetting a hp680<br>> (instead of being an optional kernel \
config)?<br>><br>Why on earth would you want to hardcode anything? The very idea \
behind<br>the driver model is so we do not have to do stupid things like that. \
<br>There's absolutely _nothing_ special about the hp680 keyboard, and \
there<br>are other boards which can use it as well (with a bit of \
reasonable<br>abstraction). Restricting a driver to a board is nonsensical, this \
isn't <br>2.4 any more.<br><br>> I can't see any benefit of being able to \
compile a kernel for that<br>> platform without keyboard support.<br><br>Then \
enable it in the defconfig. However, do not give in to this 'select' \
<br>brain-damage either, turning on subsystems unconditionally is evil.<br>People \
will configure what they want, the defconfig is simply a pointer<br>to what should \
result in a functional system out of the box.<br></blockquote> </div><br>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linuxsh-dev mailing list
linuxsh-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic