linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Kumar Gala <galak@gate.crashing.org>
Cc: linuxppc64-dev <linuxppc64-dev@ozlabs.org>, linuxppc-dev@ozlabs.org
Subject: Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
Date: Tue, 20 Dec 2005 19:58:36 +0100	[thread overview]
Message-ID: <200512201958.37850.arnd@arndb.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0512201106280.22417-100000@gate.crashing.org>

On Dinsdag 20 Dezember 2005 18:26, Kumar Gala wrote:
> 
> > AFAICS, that requires at least two things:
> > - The device needs to be created when the bus is probed, i.e.
> >   of_device_register can not be called from inside the driver
> >   module_init() function.
> > 
> 
> This is already handled by the platform device in the kernel.

Ok, i was a bit misinformed about how platform devices currently work,
for some reason I thought that there was only a single entry point
for register_device and register_driver, which is untrue.
Sorry for the confusion here.

> I still dont see what a new bus type get us.  I'm going to have to have 
> specific code to parse and build and register my devices.  If that could 
> ends up registering a platform device or a newflatOF device I dont see any 
> real difference.

After looking into it a bit more, I found that we already have
two different types of platform devices here: the standard struct
platform_device and the of_platform_device that is currently used
only on powermac and (maybe surprisingly) is not based on a
platform_device at all but on of_device.

Using the basic platform_device has the big advantage that you
can't access the device_node information (unless we implement the
device::firmware_data infrastructure for powerpc, which looks 
increasingly appealing).

> > The alternative would be to represent all of the device tree
> > in /sys/devices, but IMHO that should better be part of
> > /sys/firmware with symlinks to the linux internal device tree
> > representation.
> 
> Today I have:
>   /sys/devices/platform/
>                         fsl-gianfar.1
>                         fsl-i2c.1
>                         fsl-i2c.2
>                         fsl-sec2.1
>                         fsl-usb2-dr.1
>                         fsl-usb2-mph.1
>                         serial8250
>                         serial8250.0

The problem I see with these is that currently they are all created
by platform specific code or driver specific code that knows exactly
that these devices exist on the hardware.

When moving to the device tree, you need some criteria to decide
which devices to add and which not. One way to do this would be
to only add devices that are a direct child of an SOC bus. If you
would simply add every single device_node as a platform_device,
you end up with a huge number of entries in /sys/devices/platform/
that are either unused completely or already represented elsewhere
like /sys/devices/pci*/*.

One idea I just had (forgive me if that is bullshit, it's getting late
here) is to really do the /sys/firmware stuff by embedding a kobject
in every device_node. The existing bus types that already know about
device_node (pci, vio, macio, of_platform, ...) get converted to
use that (e.g. pci stores the device_node in pci_dev:dev:firmware_data
instead of pci_dev:sysdata) and create the appropriate symlink in sysfs.
When an of_platform_driver registers, we can still give it all devices
because we can create the of_platform_device on the fly by doing the
match on the device_node first.

	Arnd <><

      reply	other threads:[~2005-12-20 18:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-05 21:06 RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware Jon Loeliger
2005-12-06 18:59 ` Michael Neuling
2005-12-06 20:08   ` RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmwa re Jon Loeliger
2005-12-06 19:48 ` RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware Arnd Bergmann
2005-12-07  0:17   ` David Gibson
2005-12-07 16:54     ` Kumar Gala
2005-12-17 21:59   ` Benjamin Herrenschmidt
2005-12-18  6:35     ` Segher Boessenkool
2005-12-18  7:18       ` Benjamin Herrenschmidt
2005-12-19 20:49     ` Kumar Gala
2005-12-20 10:18       ` Arnd Bergmann
2005-12-20 17:26         ` Kumar Gala
2005-12-20 18:58           ` Arnd Bergmann [this message]

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=200512201958.37850.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=galak@gate.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc64-dev@ozlabs.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).