[U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Pantelis Antoniou]

Hi Ian,

> On Aug 13, 2015, at 22:04 , Ian Lepore <ian at freebsd.org> wrote:
> 
> On Thu, 2015-08-13 at 14:13 -0400, Tom Rini wrote:
>> On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:
>>> On 08/13/2015 09:59 AM, Simon Glass wrote:
>>>> Hi Linus,
>>>> 
>>>> On 11 August 2015 at 07:00, Linus Walleij <linus.walleij at linaro.org> wrote:
>>>>> On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass <sjg at chromium.org> wrote:
>>>>> 
>>>>>> This binding differs from that of Linux. Update it and change existing
>>>>>> users.
>>>>>> 
>>>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>>> (...)
>>>>>> 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?
>>> 
>>> 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.
>> 
> 
> 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.
> 

As one that had to suffer under an alternative OS’s definition of what DT
is, and how bindings work (VxWorks) I would like to have some concrete
example about any cases like that.

In my experience the mismatch may come from exactly two things:

1) From the lack of involvement in the DT process that’s going on devicetree.
True, there’s a very big Linux bias but the maintainers are reasonable
and they are open on any kind of collaboration in that area.

2) From the completely half-assed way that internally DT has been implemented
in other OSes besides Linux. I am still scared by the VxWorks stuff, but
things are not much better in u-boot either. You just can’t slap in
libfdt in there and expect all the modern bindings to work (like clock tree,
pinmuxing, etc.) I would hope we’ll get things better in u-boot and I would
certainly like to coordinate with FreeBSD or whoever to get something
done with a reasonable API (and license) that anyone can use.

Due to this, DT bindings end up OS specific which is rather insane if you
think about it.

> 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.
> 

I would like to point out that picking i2c eeproms as an example is
rather disingenuous. i2c eeproms until recently were in the land of
drivers/misc where all the oddballs are located.

I’m very happy to point out that Linux does now have (in -next) an 
EEPROM (nvmem) framework that _is_ sane.

http://www.gossamer-threads.com/lists/linux/kernel/2224053?page=last

I even have ported the ubiquitous at24 driver to it and I’m happy
to report that it is painless port.

https://github.com/pantoniou/linux-beagle-track-mainline/commit/e02880fb68295cb61db71c94800b04c1656b10ba
 
> 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.
> 

Why not make it easier then?

> -- Ian
> 
> 

Regards

— Pantelis