linux-kernel - Re: [RFC] [PATCH] Device Tree on ARM platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1243496847.3171.150.camel@pasglop>
Date:	Thu, 28 May 2009 17:47:27 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Jon Smirl <jonsmirl@...il.com>,
	Scott Wood <scottwood@...escale.com>,
	Peter Korsgaard <jacmet@...site.dk>,
	Robert Schwebel <r.schwebel@...gutronix.de>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	Timur Tabi <timur@...escale.com>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

> That's a damned good question - platform devices have been around since
> the dawn of the device model, so the real question which needs to be
> asked is: what was the reason that of_platform_device created rather
> than unifying it with the already provided platform_device ?
> 
> BTW, I can find no such struct "of_platform_device" in include/linux.
> Is it specific to each and every OF implementation?

It's just of_device... of_platform_driver and of_device.

The reason it's there is historical in fact (I created it :-) Mostly
because it predates having the archdata field in struct device which
allows to convey the pointer to the OF tree node to the driver.

Nowadays, I wouldn't necessarily need it.

An interesting example that I may have to implement for powerpc here
is amba as it looks like there may be some folks bridging AXI to
some ppc stuff.

Here, what I would do is define a simple binding that describes how to
represent amba based devices in the tree (mostly having a description
of the bridge itself) and then a file in drivers/amba that contains
code that will instanciate the -existing- amba_device objects as they
are found in the tree.

I can provide the addresses and IRQ routing straight off the tree.

>>From there, I have two options to get the ID off them. I can leave the
code as-is in drivers/amba/bus.c to do MMIOs to read it... 

Or I can decide to be fancy and define a property in the DT to carry
that ID and add the ability to the amba core to, when the amba device
has a DT node and that property is present, to avoid that MMIO operation
and create the right ID directly (which can be faster though that
doesn't necessary represent much, it's just an example).

Among other things, we have the ability on ppc64 and sparc64 (and this
code will soon be moved to some generic place for the benefit of others)
to create the entire PCI tree from the DT, by creating the pci_dev's and
populating them from the info in the DT rather than probing config
space. We keep a hook to allow the platform to indicate on a per-bus
basis whether to use the DT or do a hard probe.

This has been very useful in a few circumstances. It was initially done
to avoid doing config space accesses to some weirdo bridges when running
under a hypervisor on IBM machines or other strange things that
hypervisor can invent such as PCI devices with no function 0 :-)

It also proved that it speeds up the PCI discovery significantly.

But it also helps a lot with one important thing: It avoids BAR sizing
on all the devices that are fully described in the tree. That means that
the devices (or entire busses) are no longer taken offline for a little
while during boot... which happens with IRQs enabled, and can be a
killer if your PIC itself is behind one of these devices and you get the
interrupt at the wrong time.

That's just examples of what you -can- do with the DT. We made its usage
mandatory for all platforms on powerpc but you obviously wouldn't want
to do that on ARM. However, it's probably worth providing the optional
infrastructure to use it, and see how it goes with people doing so, it
might end up being a really good thing.

To finish, it's like any tool... its benefits (or lack of) all depends
how it's used.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/