arm: rpi: Enable USB and Ethernet driver model Raspberry Pi

This binding differs from that of Linux. Update it and change existing users.

Changes in v3:
- Rename binding file to pl01x.txt

Quoted 2 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

Is that meant to imply that this patch fixes the copy of the binding doc in U-Boot so it does match the kernel's copy?

Quoted 2 lines

Changes in v3:
- Rename binding file to pl01x.txt

The file is named pl011.txt in the kernel. Shouldn't U-Boot's copy be named the same?

Quoted 3 lines

arch/arm/dts/stv0991.dts +0 -0

arch/arm/dts/stv0991.dts line 21

Quoted 5 lines

      uart0: serial@0x80406000 {
              compatible = "arm,pl011", "arm,primecell";
              reg = <0x80406000 0x1000>;

arch/arm/dts/stv0991.dts +1 -1

-             clock = <2700000>;
+             clock-frequency = <2700000>;

I don't see either "clock" or "clock-frequency" mentioned in the Linux binding doc.

doc/device-tree-bindings/serial/pl01x.txt line 4

Quoted 6 lines

doc/device-tree-bindings/serial/pl01x.txt +1 -1

 
 Required properties:
-- compatible: must be "arm,primecell", "arm,pl011" or "arm,pl010"
+- compatible: must be "arm,primecell", "arm,pl011"

It'd be worth mentioning which version of Linux this binding doc came from; that text has changed in linux-next since v4.1 which is what I assume you're importing.

Quoted 7 lines

drivers/serial/serial_pl01x.c +0 -0

@@ -365,13 +365,15 @@ static int pl01x_serial_ofdata_to_platdata(struct udevice *dev)
      struct pl01x_serial_platdata *plat = dev_get_platdata(dev);
      fdt_addr_t addr;
 

drivers/serial/serial_pl01x.c static int pl01x_serial_ofdata_to_platdata(struct udevice *dev) · line 370

Quoted 4 lines

drivers/serial/serial_pl01x.c +1 -1

-     addr = fdtdec_get_addr(gd->fdt_blob, dev->of_offset, "reg");
+     addr = dev_get_addr(dev);
      if (addr == FDT_ADDR_T_NONE)
              return -EINVAL;

That looks like an unrelated change.

HI Stephen,

Quoted 7 lines · Stephen Warren

Quoted 2 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

Is that meant to imply that this patch fixes the copy of the binding doc in U-Boot so it does match the kernel's copy?

Quoted 5 lines

Quoted 2 lines

Changes in v3:
- Rename binding file to pl01x.txt

The file is named pl011.txt in the kernel. Shouldn't U-Boot's copy be named the same?

In the previous discussion a reviewed asked for this change, since it covers both drivers.

This binding differs from that of Linux. Update it and change existing users.

Signed-off-by Simon Glass <[email protected]>

 doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---

Quoted 4 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

Signed-off-by Simon Glass <[email protected]>

(...)

Quoted 1 line

 doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---

So why does U-Boot have its own copy of any bindings at all?

This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)

Can't we just have the bindings in the Linux kernel tree please?

Hi Linus,

Quoted 9 lines · Linus Walleij

Quoted 4 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

Signed-off-by Simon Glass <[email protected]>

(...)

Quoted 1 line

  doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---

Quoted 7 lines

So why does U-Boot have its own copy of any bindings at all?

This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)

Can't we just have the bindings in the Linux kernel tree please?

Is there any plan to move them out of Linux and put them in a separate place?

We should make an effort to sync the device tree files with Linux periodically.

I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.

However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?

Quoted 28 lines · Simon Glass

Hi Linus,

Quoted 9 lines · Linus Walleij

Quoted 4 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

Signed-off-by Simon Glass <[email protected]>

(...)

Quoted 1 line

 doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---

Quoted 7 lines

So why does U-Boot have its own copy of any bindings at all?

This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)

Can't we just have the bindings in the Linux kernel tree please?

Is there any plan to move them out of Linux and put them in a separate place?

We should make an effort to sync the device tree files with Linux periodically.

I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.

Quoted 4 lines

However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?

DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)

Quoted 29 lines · Stephen Warren

Quoted 28 lines · Simon Glass

Hi Linus,

Quoted 9 lines · Linus Walleij

Quoted 4 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

Signed-off-by Simon Glass <[email protected]>

(...)

Quoted 1 line

 doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---

Quoted 7 lines

So why does U-Boot have its own copy of any bindings at all?

This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)

Can't we just have the bindings in the Linux kernel tree please?

Is there any plan to move them out of Linux and put them in a separate place?

We should make an effort to sync the device tree files with Linux periodically.

I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.

Quoted 8 lines

Quoted 4 lines

However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?

DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)

This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.

Quoted 39 lines · Tom Rini

Quoted 29 lines · Stephen Warren

Quoted 28 lines · Simon Glass

Hi Linus,

Quoted 9 lines · Linus Walleij

Quoted 4 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

Signed-off-by Simon Glass <[email protected]>

(...)

Quoted 1 line

  doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---

Quoted 7 lines

So why does U-Boot have its own copy of any bindings at all?

This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)

Can't we just have the bindings in the Linux kernel tree please?

Is there any plan to move them out of Linux and put them in a separate place?

We should make an effort to sync the device tree files with Linux periodically.

I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.

Quoted 8 lines

Quoted 4 lines

However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?

DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)

Quoted 6 lines

This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.

As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.

The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.

A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.

So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.

All in all, it's not impossible for another OS to work with the DT information that begins its life in Linux, but it's not really easy.

Quoted 13 lines · Ian Lepore

As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.

The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.

Quoted 4 lines

A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything

Quoted 6 lines

claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.

Quoted 6 lines

So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.

All in all, it's not impossible for another OS to work with the DT information that begins its life in Linux, but it's not really easy.

In fairness, that's got nothing to do with Linux, but it's a general decision re: the level of detail to put into DT. There's always a discussion about which level of detail to represent in DT when new bindings are created.

The type of an I2C device completely defines all of its properties; the model name/... is enough to fully describe its behaviour. That's a good reason to put just that information into DT, to avoid redundancy.

In some cases, bindings have tended towards placing just the compatible value into the DT (e.g. your example). This does require drivers to be able to look up that information from the compatible value.

That case tends to be more common since what's really important about DT is cleanly representing the resource interactions between devices; let the drivers know all the details of the device's internals, and let DT describe any point where the device/driver has to interact with the system or other devices/drivers around it.

As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.

The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.

A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.

So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.

All in all, it's not impossible for another OS to work with the DT information that begins its life in Linux, but it's not really easy.

Quoted 39 lines · Tom Rini

Quoted 29 lines · Stephen Warren

Quoted 28 lines · Simon Glass

Hi Linus,

Quoted 9 lines · Linus Walleij

Quoted 4 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

Signed-off-by Simon Glass <[email protected]>

(...)

Quoted 1 line

 doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---

Quoted 7 lines

So why does U-Boot have its own copy of any bindings at all?

This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)

Can't we just have the bindings in the Linux kernel tree please?

Is there any plan to move them out of Linux and put them in a separate place?

We should make an effort to sync the device tree files with Linux periodically.

I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.

Quoted 8 lines

Quoted 4 lines

However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?

DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)

Quoted 6 lines

This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.

As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.

The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.

A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.

So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.

Quoted 3 lines · Ian Lepore

Quoted 2 lines · Tom Rini

On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:

Quoted 8 lines

Quoted 7 lines

This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.

Quoted 5 lines

As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.

Sadly, we see little non-Linux participation on DT lists. We've tried to separate core (devicetree-spec) and driver lists, but pretty much everything still goes to one list and it is a fire hose. I'm open for ideas on how to get more non-Linux participation.

Quoted 10 lines

A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.

Think of compatible as a PID/VID pair like USB or PCI. It is simply a unique identifier. You don't get any more information with PCI or non-class USB devices. DT was originally only solving the problem of finding the non-probeable h/w. It's grown to be a lot more with today's SOCs.

The more we put into DT the more chance it can be wrong and then we have to work around not h/w quirks, but DT quirks.

That said we can always add to the bindings. It would have to be worded something like "optional, but required for new dts's". You would have to have a new DTB if the OS is dependent on the new properties.

Quoted 3 lines

So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.

Don't you already have these drivers w/o using DT? If you did, you would have this information already in the drivers. It wouldn't be a question of the binding being Linux specific, but rather can we move more of the data out of drivers and into DT. That is fundamentally a different issue than is a binding Linux specific.

Quoted 3 lines · Ian Lepore

Quoted 2 lines · Tom Rini

Quoted 1 line · Stephen Warren

Quoted 28 lines

Quoted 10 lines

A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard- coded in tables in the driver source.

Think of compatible as a PID/VID pair like USB or PCI. It is simply a unique identifier. You don't get any more information with PCI or non-class USB devices. DT was originally only solving the problem of finding the non-probeable h/w. It's grown to be a lot more with today's SOCs.

The more we put into DT the more chance it can be wrong and then we have to work around not h/w quirks, but DT quirks.

That said we can always add to the bindings. It would have to be worded something like "optional, but required for new dts's". You would have to have a new DTB if the OS is dependent on the new properties.

Quoted 3 lines

So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded

Quoted 7 lines

in source.

Don't you already have these drivers w/o using DT? If you did, you would have this information already in the drivers. It wouldn't be a question of the binding being Linux specific, but rather can we move more of the data out of drivers and into DT. That is fundamentally a different issue than is a binding Linux specific.

This last paragraph most eloquently illustrates the point I was trying to make:
From the point of view of someone who only knows about the existing linux driver and how it is written, the current DT data is perfect. It's exactly what that existing driver needs to know, and from that position you can argue that it is thus the ONLY thing any driver written by anyone would need to know. That assumes that everyone wants to just clone the linux drivers (or in our case, because of licensing, rewrite the drivers in a completely linux- compatible way that somehow isn't simply copying them in violation of the GPL).

Quoted 10 lines · Rob Herring

Ian:

Quoted 3 lines

So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.

Don't you already have these drivers w/o using DT? If you did, you would have this information already in the drivers. It wouldn't be a question of the binding being Linux specific, but rather can we move more of the data out of drivers and into DT. That is fundamentally a different issue than is a binding Linux specific.

This last paragraph most eloquently illustrates the point I was trying to make: From the point of view of someone who only knows about the existing linux driver and how it is written, the current DT data is perfect. It's exactly what that existing driver needs to know, and from that position you can argue that it is thus the ONLY thing any driver written by anyone would need to know. That assumes that everyone wants to just clone the linux drivers (or in our case, because of licensing, rewrite the drivers in a completely linux-compatible way that somehow isn't simply copying them in violation of the GPL).

Quoted 39 lines · Tom Rini

Quoted 29 lines · Stephen Warren

Quoted 28 lines · Simon Glass

Hi Linus,

Quoted 9 lines · Linus Walleij

Quoted 4 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

Signed-off-by Simon Glass <[email protected]>

(...)

Quoted 1 line

doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---

Quoted 7 lines

So why does U-Boot have its own copy of any bindings at all?

This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)

Can't we just have the bindings in the Linux kernel tree please?

Is there any plan to move them out of Linux and put them in a separate place?

We should make an effort to sync the device tree files with Linux periodically.

I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.

Quoted 8 lines

Quoted 4 lines

However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?

DT isn't supposed to contain "U-Boot things", but "an OS-agnostic description of the hardware". So, I imagine the solution is not to attempt to do that:-)

Quoted 6 lines

This always makes me ask if the FreeBSD folks or VxWorks folks have adopted the "Linux" bindings or if the DT files continue to be "OS-agnostic" and "only functional with Linux". It was a while ago last I looked but it made my head hurt a little doing a quick translation for an SoC that I was familiar with.

As the FreeBSD person who got our first SoC (imx6, only partially supported) converted to use the Linux DT files rather than our own homebrew mess we started with, I would say that my opinion of the existing DT information is that it is an extension of Linux device drivers written in a different language.

The information available is in no way independent of the Linux device drivers, it is exactly the information those drivers need. It is often not the information needed in another OS with independently written drivers. And especially it is not ordered and structured in a way that works well with the device enumeration and instantiation models used by another OS.

A great case in point would be i2c eeproms. What a perfect opportunity DT would be to describe everything about the eeprom parts (total capacity, page read/write size, whether the page address bits extend into the bus-slave address bits, etc). It seems to me that anything claiming to be an independent description of the hardware would have to include such things. Instead, all the bindings define is the compatible string. That's crazy. Why? Well, when I went and looked at the Linux eeprom drivers it became clear why: that's all they need to know, because everything else is hard-coded in tables in the driver source.

So if I want to write a FreeBSD i2c eeprom driver that uses DT data, what are my choices? I have exactly one: make my driver essentially a clone of the Linux driver, with all the same data hard-coded in source.

All in all, it's not impossible for another OS to work with the DT information that begins its life in Linux, but it's not really easy.

-- Ian

Hi Linus,

Quoted 16 lines · Linus Walleij

Quoted 4 lines · Simon Glass

This binding differs from that of Linux. Update it and change existing users.

Signed-off-by Simon Glass <[email protected]>

(...)

Quoted 1 line

 doc/device-tree-bindings/serial/pl01x.txt | 55 ++++++++++++++++++++++++++++---

So why does U-Boot have its own copy of any bindings at all?

This is forking the ontology of who gets to define bindings I fear. It's a bit like have two bibles both claiming to be the word of god. (OK maybe a hyperbolic statement, but you see what I mean.)

Can't we just have the bindings in the Linux kernel tree please?

Is there any plan to move them out of Linux and put them in a separate place?

We should make an effort to sync the device tree files with Linux periodically.

I quite like having the bindings in U-Boot since it makes people think about what they are adding. Are you worried that the bindings in U-Boot might evolve separately? Certainly there has been some of that.

However I recently sent a series to add a few things for Raspberry Pi ("arm: rpi: Device tree modifications for U-Boot") and I don't yet see a willingness to add what some see as 'U-Boot things' to the binding. How do we address that?

This shows a proper progress display and the total amount of data transferred. Enable it for Raspberry Pi.

Quoted 2 lines · Simon Glass

This shows a proper progress display and the total amount of data transferred. Enable it for Raspberry Pi.

Acked-by Stephen Warren <[email protected]>

This updates the device tree from the kernel version to something suitable for U-Boot:

- Add stdout-path alias for console
- Mark the /soc node to be available pre-relocation so that the early serial console works (we need the 'ranges' property to be available)

Quoted 6 lines · Simon Glass

This updates the device tree from the kernel version to something suitable for U-Boot:

- Add stdout-path alias for console
- Mark the /soc node to be available pre-relocation so that the early serial console works (we need the 'ranges' property to be available)

If you can get these changes into the kernel's copy of the DT, then this patch is fine. If not, I don't think we should take this patch. The very definition of DT is a SW-stack-agnostic data structure. Modifying it on a per-SW-stack basis means we aren't doing DT, but rather something that looks like DT but isn't. In that case, we shouldn't call it DT.

Hi Stephen,

Quoted 8 lines · Stephen Warren

Quoted 6 lines · Simon Glass

This updates the device tree from the kernel version to something suitable for U-Boot:

- Add stdout-path alias for console
- Mark the /soc node to be available pre-relocation so that the early serial console works (we need the 'ranges' property to be available)

Quoted 5 lines

If you can get these changes into the kernel's copy of the DT, then this patch is fine. If not, I don't think we should take this patch. The very definition of DT is a SW-stack-agnostic data structure. Modifying it on a per-SW-stack basis means we aren't doing DT, but rather something that looks like DT but isn't. In that case, we shouldn't call it DT.

The "u-boot," prefix is intended to indicate that it is U-Boot-specific. Linux has "linux," and 800+ uses of it in the ARM device tree source files.

I can certainly send this patch to Linux. Given your comment above, will you take it?

Quoted 21 lines · Simon Glass

Hi Stephen,

Quoted 8 lines · Stephen Warren

Quoted 6 lines · Simon Glass

This updates the device tree from the kernel version to something suitable for U-Boot:

- Add stdout-path alias for console
- Mark the /soc node to be available pre-relocation so that the early serial console works (we need the 'ranges' property to be available)

Quoted 5 lines

If you can get these changes into the kernel's copy of the DT, then this patch is fine. If not, I don't think we should take this patch. The very definition of DT is a SW-stack-agnostic data structure. Modifying it on a per-SW-stack basis means we aren't doing DT, but rather something that looks like DT but isn't. In that case, we shouldn't call it DT.

The "u-boot," prefix is intended to indicate that it is U-Boot-specific. Linux has "linux," and 800+ uses of it in the ARM device tree source files.

Quoted 2 lines

I can certainly send this patch to Linux. Given your comment above, will you take it?

Review of that change would have to be by the DT bindings maintainers on the DT mailing list. Lee Jones (or perhaps Eric Anholt) owns applying any RPi patches within Linux.

Enable device tree control so that we can use driver model fully and avoid using platform data.

Quoted 2 lines · Simon Glass

Enable device tree control so that we can use driver model fully and avoid using platform data.

I'm still not convinced about this change.

Re: the commit message about: What about the driver model is not being fully used without DT?

Overall: What advantage does using DT have to either a developer or an end-user?

I don't believe this patch fixes and bugs or enables any new features for an end-user.

From the maintainer perspective: It seems to me that it's far simpler to have a tiny struct for each device in the C code than to pull in a whole slew of DT parsing cruft just to work out the same struct at run-time. As such, this patch can only make it harder to maintain the code since there's more of it, and it's more complex.

I just don't see the advantage of switching to DT for U-Boot control.

Hi Stephen,

Quoted 4 lines · Stephen Warren

Quoted 2 lines · Simon Glass

Enable device tree control so that we can use driver model fully and avoid using platform data.

Quoted 4 lines

I'm still not convinced about this change.

Re: the commit message about: What about the driver model is not being fully used without DT?

Device tree control?

Quoted 12 lines

Overall: What advantage does using DT have to either a developer or an end-user?

I don't believe this patch fixes and bugs or enables any new features for an end-user.

From the maintainer perspective: It seems to me that it's far simpler to have a tiny struct for each device in the C code than to pull in a whole slew of DT parsing cruft just to work out the same struct at run-time. As such, this patch can only make it harder to maintain the code since there's more of it, and it's more complex.

Quoted 1 line

I just don't see the advantage of switching to DT for U-Boot control.

It allows us to share configuration with the kernel (same device tree file). This should be more familiar to people coming from there than our own configuration system. It's nice to have all the configuration in one place. We can then avoid using platform data in U-Boot unless it is necessary.

I really don't like the idea of filling up the code with platform data when that approach has already been rejected by Linux.

Quoted 7 lines · Simon Glass

Hi Stephen,

Quoted 4 lines · Stephen Warren

Quoted 2 lines · Simon Glass

Enable device tree control so that we can use driver model fully and avoid using platform data.

Quoted 6 lines

Quoted 4 lines

I'm still not convinced about this change.

Re: the commit message about: What about the driver model is not being fully used without DT?

Device tree control?

I am not convince about that argument. It seems rather self-fulfilling, and irrelevant to me.

The fact that a feature exists shouldn't necessarily mean that it absolutely must be used in all cases. There needs to be some benefit from using the feature. What stability, performance, ... benefit does DT give to a maintainer or user?

On a system that sources device information from ACPI, must DT still be used because DM has that feature and without using it, DM isn't being fully used?

I would strongly hope that DM is not tied to any particular source of device information. A device model should be generic. The actions of enumerating what devices exist (via C structures, DT, ACPI, ...) should be completely independent from the process that then manages all of those devices once they're enumerating/instantiated.

Quoted 13 lines

Quoted 13 lines

Overall: What advantage does using DT have to either a developer or an end-user?

I don't believe this patch fixes and bugs or enables any new features for an end-user.

From the maintainer perspective: It seems to me that it's far simpler to have a tiny struct for each device in the C code than to pull in a whole slew of DT parsing cruft just to work out the same struct at run-time. As such, this patch can only make it harder to maintain the code since there's more of it, and it's more complex.

Quoted 7 lines

Quoted 1 line

I just don't see the advantage of switching to DT for U-Boot control.

It allows us to share configuration with the kernel (same device tree file). This should be more familiar to people coming from there than our own configuration system. It's nice to have all the configuration in one place. We can then avoid using platform data in U-Boot unless it is necessary.

But at the cost of extra complexity in the U-Boot code that I don't think is warranted. Equally, U-Boot's DT support is built on some assumptions about DT structure and parsing rules that are inaccurate (e.g. not honoring #address-cells, not parsing the DT in a hierarchical manner thus not ensuring correct driver "probe" ordering, missing features such as clock frameworks with pushback on supporting the standard clock bindings rather than implementing U-Boot-specific properties, etc.). It's not quite DT, but almost. It's quite unlikely that any Linux DT will "just work". Once it doesn't always just work, the advantage of similarity with kernel DTs is lost. As someone who's ported U-Boot to various Tegra and RPi SoCs/boards, I honestly don't think that using DT rather the C structures would have saved me any time, and likely has caused me to spend more time debugging and fixing DT issues in U-Boot.

Quoted 3 lines

I really don't like the idea of filling up the code with platform data when that approach has already been rejected by Linux.

The Linux situation is entirely different from U-Boot.

Linux distros want to distribute a single generic Linux kernel binary (and indeed generic install media, etc.) that runs on arbitrary systems without having to worry about system-specific details. Ideally, the distro can ship a single OS image which will work on arbitrary systems, provided the system vendor ships the DT as part of the firmware and provides it to the kernel. Of course, that hasn't actually happened yet since the DTs are still in the kernel source tree and DT ABI isn't anywhere near universal.

A bootloader or firmware is by definition system-specific. There's no concept of a single image working across *arbitrary* systems. (Of course, some U-Boot builds run on a small number of boards via runtime detection, but by no means is any U-Boot binary entirely generic). There's no need for it to be generic, since system vendors or enterprising users build and install the firmware for a specific known board/system.

As such, any arguments about Linux having chosen to use DT are likely irrelevant to whether a firmware or bootloader should use it.