Hi Ian,
> On Aug 13, 2015, at 22:04 , Ian Lepore <ian@xxxxxxxxxxx> 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@xxxxxxxxxx> wrote:
>>>>> On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass <sjg@xxxxxxxxxxxx> wrote:
>>>>>
>>>>>> This binding differs from that of Linux. Update it and change existing
>>>>>> users.
>>>>>>
>>>>>> Signed-off-by: Simon Glass <sjg@xxxxxxxxxxxx>
>>>>> (...)
>>>>>> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
