From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@ozlabs.org, Olof Johansson <olof@lixom.net>,
linux-ide@vger.kernel.org, paulus@samba.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] pasemi: electra IDE/pata_platform glue
Date: Sun, 13 May 2007 12:20:10 +1000 [thread overview]
Message-ID: <1179022810.32247.54.camel@localhost.localdomain> (raw)
In-Reply-To: <200705130248.22844.arnd@arndb.de>
On Sun, 2007-05-13 at 02:48 +0200, Arnd Bergmann wrote:
> On Sunday 13 May 2007, Alan Cox wrote:
> > > Why not provide a proper pata_of.c driver based on ata_generic? That
> > > will help the next person that has a builtin ata controller and wants
> > > to get it running as an of_device.
> >
> > Easier to use pata_platform I would think ? Just create the OF device and
> > bind it to pata_platform.
>
> Not sure I understand what you mean. pata_platform expects a platform_device,
> which cannot be cast from an of_device.
Note that in the long run, we might have less problem with that sort of
thing.
First, every device now has an OF node optionally attached to it (since
I introduced dev_sysdata). This of_device doesn't really bring much more
than OF type/name/compatible properties based probing.
Then, the plans I have in mind for the future of that stuff are around
the idea of registering "constructors" based on bus matches and device
matches respectively.
The kernel will then walk the whole OF device-tree at boot, and will
instanciate devices using those constructors, passing them the struct
device of whatever was the parent.
Thus we could easily have platforms registers constructors for specific
devices that build a platform device off an OF node. We can have a
generic constructor that builds the PCI devices, etc... and we can have
bus constructors to generate of_device's for things where they are
useful, like plb4/5 on 4xx etc...
On top of that, I want to add some resource management to of_device and
maybe kill things like ebus, vio, etc... device if possible (that is if
the only difference to the base OF device can be resolved at
construction time).
Anyway, still only thoughts but that gives you an idea to where I'm
heading.
Ben.
next prev parent reply other threads:[~2007-05-13 2:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-12 14:50 [PATCH] pasemi: electra IDE/pata_platform glue Olof Johansson
2007-05-12 23:11 ` Arnd Bergmann
2007-05-12 23:58 ` Alan Cox
2007-05-13 0:48 ` Arnd Bergmann
2007-05-13 2:20 ` Benjamin Herrenschmidt [this message]
2007-05-13 6:19 ` Olof Johansson
2007-05-13 8:01 ` Benjamin Herrenschmidt
2007-05-13 11:17 ` Segher Boessenkool
2007-05-13 13:39 ` Alan Cox
2007-05-13 21:18 ` Olof Johansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1179022810.32247.54.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=linux-ide@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=olof@lixom.net \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).