Matt Sealey wrote:
I'm all for it being legacy and optional but marking ethernet ports as
network, and serial ports as serial, is a wonderfully good idea especially
if they were used in ANY firmware environment to bring up the console,
drag in the boot files, or provide a framebuffer display.
Nobody is saying that device_type should not be used in real OF when an
appropriate method interface exists. What we're saying is that flat
device trees, which are incapable of providing a method interface,
should not lie and claim that they have one.
As for "ANY firmware environment", I'd suggest that any new method
interfaces, where backwards compatibility isn't an issue, use some
relevant compatible rather than device_type, so that multiple supported
interfaces can be listed. What do you have against vendor namespaces
(don't make the device binding guess which firmware type it's on) and
multiple interfaces per node?
quoted
matches the stated device_type. However, flattened trees clearly
can't provide the method interface, and so shouldn't declare the
device_type.
Even if they are used in the firmware environment for console, booting
or probing? :D
Define "they", "used", and "firmware environment". Obviously u-boot may
use the serial port for its console, but there's no method interface
defined by the device tree, nor is there any firmware resident at all
after starting the kernel.
quoted
In practice, we do suggest including device_type in certain, limited,
circumstances precisely because there are a whole bunch of buggy
drivers out there which match (at least partly) on device_type.
> We don't want to break these gratuitously,
Oh that's rich. If you were that concerned you'd rip the device_type
out and fix all the drivers in a huge patch, like everyone else does
when they change the ABI.
This isn't internal ABI, it's an external interface with firmware.
quoted
driver matching. Hence the current policy.
I might say that the policy on device trees has changed by the month
for the last 2 years and ePAPR didn't fix down a single concern that
wasn't already documented in the original IEEE 1275 specification.
It fixes three primary concerns:
1. The 1275 documentation is scattered in many places, some of which are
not easily accessible to the general public (just look at the i2c mess).
2. 1275 did not appear to be actively maintained and updated.
3. It standardized the flattened device tree interface, which did not
exist in 1275.
-Scott
Scott Wood wrote:
Matt Sealey wrote:
Nobody is saying that device_type should not be used in real OF when an
appropriate method interface exists. What we're saying is that flat
device trees, which are incapable of providing a method interface,
should not lie and claim that they have one.
As for "ANY firmware environment", I'd suggest that any new method
interfaces, where backwards compatibility isn't an issue, use some
relevant compatible rather than device_type, so that multiple supported
interfaces can be listed. What do you have against vendor namespaces
(don't make the device binding guess which firmware type it's on) and
multiple interfaces per node?
I say ANY firmware environment because at the end of the day what methods
the OF implements, or even if the firmware (like a U-Boot modification)
"lies" about it being device_type serial or device_type network, Linux
completely f**ks over the client interface at the first opportunity it
gets and does not call ANY appreciable method anyway.
So, it is not a lie to say it's a certain device_type, and I really
do focus here on the between-the-lines reading of the OF spec where
devices which ARE useful for booting, console and probing (for instance
marking detected disks as "block", ethernet as "network", serial
consoles as "serial" and displays and keyboards are present in the
tree if they are present on the machine) is more relevant here than
the Open Firmware client interface methods which Linux is steadfastly
resolved never to use anyway.
Other operating systems might be a little less pleased about the lack
of methods but we've been pushing them to ignore the CI for a long,
long time as it causes way too many problems with differences in MMU
mapping (even in virtual-mode) when booting the system, to try and
access a disk through the client interface or use a polled ethernet
driver which has to go through an egregious context switch to load
significant amounts of data.
So let's just take the basic premise of the device_type and not the
literal truth of it (hey, the world wasn't created in 7 days
after all, who'd have thunk?) and use it to the advantage of the
Linux kernel instead of ditching it as legacy.
Define "they", "used", and "firmware environment". Obviously u-boot may
use the serial port for its console, but there's no method interface
defined by the device tree, nor is there any firmware resident at all
after starting the kernel.
However it is a serial port, and when it boots it says "input: serial"
and "output: serial" - or it could be netconsole or so. Or even screen
and keyboard! These are put into /chosen/stdin and /chosen/stdout when
the system is booted with the device tree.
Should a platform be extremely specific and check compatible properties
for every kind of serial port it could ever support (including PCI, ISA/LPC,
and otherwise connected GPIO implementations or crazy designs) just so
that it can carry over the firmware choices reported in the device tree
to the booting system, or should it simply be looking for those generic
device classes?
A simple way to check what is in use and what basic sort of peripheral it
is, without knowing the ultimate specifics of the device (since you would
not be in a driver, early_init is too early of course in the examples, but
I could probably think of a bunch of othe reasons you'd want to check some
of the /chosen nodes or make a quick check if the device was purposed by
the firmware for some reason)
It fixes three primary concerns:
1. The 1275 documentation is scattered in many places, some of which are
not easily accessible to the general public (just look at the i2c mess).
To be honest I didn't know i2c had ever been defined at all, so I see
your point there.
2. 1275 did not appear to be actively maintained and updated.
But, it did not suddenly break in the last 14 years, did it?
This simply exposes the endemic problem of Linux developers subscribing
to the Not Invented Here philosophy and making subtle yet intrusive
changes to suit themselves and brighten their name in lights while, in
the end, ignoring their own statements to whit the benefits and reasons
why they wanted to change something.
I am still kind of sore that the policy swung from "the firmware is
responsible" to "we will accept any crazy patch for prom_init.c which
will fix up a device even though there is an easy way to fix it from
the firmware side and not clutter Linux, and even though the patch
doesn't ACTUALLY work" and many other 180's in the history of the
device tree specifications and the support Linux implements.
ePAPR doesn't resolve a single thing we didn't already know, and
considering it was written by the IBM and Freescale engineers who
implemented and maintain the support and the firmware.. I wonder
how much thought went into it besides how to format it as a PDF.
Don't get me started on how useless and ineffectual Power.org
technical subcommittees are.. there is no reason why PAPR and
ePAPR couldn't have been the same specification. When you start
thinking about U-Boot with RTAS or the IBM Hypervisor this is
going to kick you in the backside.
3. It standardized the flattened device tree interface, which did not
exist in 1275.
This is about all it did but it is not like we've not been using
flattened device trees for the past 2 or so years *anyway*. They did
always work. The real sore points here are device bindings and
a grand total of nothing changed between OF and now with that.
The assertion in ePAPR that device_type is deprecated and ignored
because ePAPR doesn't support FCode is naive at best.
To be honest I've lost the will to actually contribute to the
discussion because it's just reminding me of why we got a refund
from Power.org and why we stopped submitting patches to mainline.
Thanks for your input, Mitch, at least. It was very helpful.
--
Matt Sealey [off-list ref]
Genesi, Manager, Developer Relations
Matt Sealey wrote:
I say ANY firmware environment because at the end
of the day what methods the OF implements, or even if the firmware
(like a U-Boot modification) "lies" about it being device_type serial
or device_type network, Linux completely f**ks over the client
interface at the first opportunity it gets and does not call ANY
appreciable method anyway.
That's Linux's choice; what does that have to do with how the firmware
expresses the functionality it provides?
So, it is not a lie to say it's a certain device_type,
It's not a lie because Linux doesn't care that it's a lie?
and I really do focus here on the between-the-lines reading of the OF
spec where devices which ARE useful for booting, console and probing
(for instance marking detected disks as "block", ethernet as
"network", serial consoles as "serial" and displays and keyboards are
present in the tree if they are present on the machine) is more
relevant here than the Open Firmware client interface methods which
Linux is steadfastly resolved never to use anyway.
If you're not going to use the method interface, then what *do* you use
device_type for?
So let's just take the basic premise of the device_type and not the
literal truth of it (hey, the world wasn't created in 7 days after
all, who'd have thunk?) and use it to the advantage of the Linux
kernel instead of ditching it as legacy.
What advantage would that be?
quoted
Define "they", "used", and "firmware environment". Obviously
u-boot may use the serial port for its console, but there's no
method interface defined by the device tree, nor is there any
firmware resident at all after starting the kernel.
However it is a serial port, and when it boots it says "input:
serial" and "output: serial" - or it could be netconsole or so. Or
even screen and keyboard! These are put into /chosen/stdin and
/chosen/stdout when the system is booted with the device tree.
And how, exactly, do /chosen/stdin and /chosen/stdout depend on device_type?
Should a platform be extremely specific and check compatible
properties for every kind of serial port it could ever support
Of course it should check compatible -- how else would it know how to
drive the thing?
(including PCI, ISA/LPC, and otherwise connected GPIO implementations
or crazy designs) just so that it can carry over the firmware choices
reported in the device tree to the booting system, or should it
simply be looking for those generic device classes?
And what do you propose it do with a generic "serial" in the absence of
a method interface? Just assume it's ns16550?
A simple way to check what is in use and what basic sort of
peripheral it is, without knowing the ultimate specifics of the
device (since you would not be in a driver, early_init is too early
of course in the examples, but I could probably think of a bunch of
othe reasons you'd want to check some of the /chosen nodes or make a
quick check if the device was purposed by the firmware for some
reason)
-EPARSE
quoted
2. 1275 did not appear to be actively maintained and updated.
But, it did not suddenly break in the last 14 years, did it?
New hardware came along that is not described. Details that fall out of
the use of flat trees are not addressed (no ihandles, phandles as
properties, etc).
ePAPR doesn't resolve a single thing we didn't already know,
The primary intent was to codify existing practice.
Don't
get me started on how useless and ineffectual Power.org technical
subcommittees are.. there is no reason why PAPR and ePAPR couldn't
have been the same specification. When you start thinking about
U-Boot with RTAS or the IBM Hypervisor this is going to kick you in
the backside.
Agreed; that's more of a political issue than a technical one.
quoted
3. It standardized the flattened device tree interface, which did
not exist in 1275.
This is about all it did but it is not like we've not been using
flattened device trees for the past 2 or so years *anyway*.
...in Linux and u-boot. ePAPR gives us a self-contained document that
we can point other firmware and OS developers to.
They did
always work. The real sore points here are device bindings and a
grand total of nothing changed between OF and now with that.
The assertion in ePAPR that device_type is deprecated and ignored
because ePAPR doesn't support FCode is naive at best.
It's deprecated *in the context of flat device trees*. Anything not
using flat device trees is out-of-scope with respect to ePAPR.
-Scott
Scott Wood wrote:
quoted
They did always work. The real sore points here are device bindings and a
grand total of nothing changed between OF and now with that.
The assertion in ePAPR that device_type is deprecated and ignored
because ePAPR doesn't support FCode is naive at best.
It's deprecated *in the context of flat device trees*. Anything not
using flat device trees is out-of-scope with respect to ePAPR.
Isn't the beauty of a device tree that every firmware no matter what
type can present it in whatever form it chooses, but still be describing
the same hardware in the same way?
Designing a tree for OF and one for U-Boot should be an absolutely
identical process, internal firmware methodologies notwithstanding
be it pure Forth in Firmworks, C API in Codegen, or output of dtc
for U-Boot, the exact same tree should be output, device_type and
all, within reason. I don't think "it's not real Open Firmware" is
a valid reason. Not as valid as "our firmware doesn't support this
hardware yet so we can't probe or initialize, only describe the bus",
for example (USB on Efika is filled out, USB on U-Boot for Lite5200B
is not).
I'm curious, is it the remit of the ePAPR TSC to publish and act as
a registration authority for device tree bindings for specific SoCs
or is that devolved to the SoC maker itself (be they a member of
Power.org or not) and, more prudent, two other questions; where are
Freescale and IBM publishing these if it is their responsibility,
are things like the mysterious i2c binding going to be published
under this TSC?
--
Matt Sealey [off-list ref]
Genesi, Manager, Developer Relations
Matt Sealey wrote:
Scott Wood wrote:
quoted
It's deprecated *in the context of flat device trees*. Anything not
using flat device trees is out-of-scope with respect to ePAPR.
Isn't the beauty of a device tree that every firmware no matter what
type can present it in whatever form it chooses, but still be describing
the same hardware in the same way?
When run-time services are not involved, yes. device_type was used by
1275 in the context of run-time services, which we don't have, so we
didn't copy that property over (except for memory and cpu, to avoid
gratuitous divergence).
I'm curious, is it the remit of the ePAPR TSC to publish and act as
a registration authority for device tree bindings for specific SoCs
or is that devolved to the SoC maker itself (be they a member of
Power.org or not) and, more prudent, two other questions; where are
Freescale and IBM publishing these if it is their responsibility,
are things like the mysterious i2c binding going to be published
under this TSC?
There has been talk about setting up such a repository, but I'm not sure
what the status of it is.
-Scott