All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Ian Lepore <ian-h+KGxgPPiopAfugRpC6u6w@public.gmane.org>,
	Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
	"linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Joe Hershberger <joe.hershberger-acOepvfBmUk@public.gmane.org>,
	Benjamin Herrenschmidt
	<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
	U-Boot Mailing List
	<u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Geert Uytterhoeven
	<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Subject: Re: [U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART
Date: Fri, 14 Aug 2015 12:22:31 +0200	[thread overview]
Message-ID: <CACRpkdY1G0zgQ0mw3VP_rA89+kcaipCfJqoPpieVDTBjbeDa1Q@mail.gmail.com> (raw)
In-Reply-To: <1439492679.242.35.camel-h+KGxgPPiopAfugRpC6u6w@public.gmane.org>

On Thu, Aug 13, 2015 at 9:04 PM, Ian Lepore <ian-h+KGxgPPiopAfugRpC6u6w@public.gmane.org> wrote:

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

This is the first time I hear a story like this, tell us more!

This is exactly the kind of stuff we want to see posted on
devicetree-u79uwXL29TaiAVqoAR/hOA@public.gmane.org

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

I have complained before that since the bindings are often merged
through the Linux kernel tree subsystem maintainers, they
ultimately decide on bindings. Unsurprisingly, they are as unlikely
to notice linuxisms as the Windows people designing ACPI
are unlikely to notice Windowsisms. But atleast we know we
are flawed and want to improve.

The best way to improve is to have people from other OSes on
the devicetree mailinglist and review the bindings there from
other-OS point of view.

> 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 bet Wolfram and other I2C people can comment on this, state
and future directions. Wolfram is known to care deeply about the
problem with DT contracts.

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

Let's maker this better.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Linus Walleij <linus.walleij@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART
Date: Fri, 14 Aug 2015 12:22:31 +0200	[thread overview]
Message-ID: <CACRpkdY1G0zgQ0mw3VP_rA89+kcaipCfJqoPpieVDTBjbeDa1Q@mail.gmail.com> (raw)
In-Reply-To: <1439492679.242.35.camel@freebsd.org>

On Thu, Aug 13, 2015 at 9:04 PM, Ian Lepore <ian@freebsd.org> wrote:

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

This is the first time I hear a story like this, tell us more!

This is exactly the kind of stuff we want to see posted on
devicetree at vger.kernel.org.

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

I have complained before that since the bindings are often merged
through the Linux kernel tree subsystem maintainers, they
ultimately decide on bindings. Unsurprisingly, they are as unlikely
to notice linuxisms as the Windows people designing ACPI
are unlikely to notice Windowsisms. But atleast we know we
are flawed and want to improve.

The best way to improve is to have people from other OSes on
the devicetree mailinglist and review the bindings there from
other-OS point of view.

> 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 bet Wolfram and other I2C people can comment on this, state
and future directions. Wolfram is known to care deeply about the
problem with DT contracts.

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

Let's maker this better.

Yours,
Linus Walleij

  parent reply	other threads:[~2015-08-14 10:22 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07 13:42 [PATCH v3 00/11] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi Simon Glass
2015-08-07 13:42 ` [U-Boot] " Simon Glass
     [not found] ` <1438954951-13329-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2015-08-07 13:42   ` [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART Simon Glass
2015-08-07 13:42     ` [U-Boot] " Simon Glass
2015-08-11  3:57     ` Stephen Warren
2015-08-11  3:57       ` [U-Boot] " Stephen Warren
     [not found]       ` <55C972BA.5050706-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2015-08-11  4:11         ` Simon Glass
2015-08-11  4:11           ` [U-Boot] " Simon Glass
     [not found]           ` <CAPnjgZ2XdOPGMfAPHGy4c7vuc+exrirXkZ5DF+wHKGmAPg8ZjA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-11  4:24             ` Stephen Warren
2015-08-11  4:24               ` [U-Boot] " Stephen Warren
     [not found]     ` <1438954951-13329-2-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2015-08-11 13:00       ` Linus Walleij
2015-08-11 13:00         ` [U-Boot] " Linus Walleij
     [not found]         ` <CACRpkdZa2O1MqCVT8q2P0u0ciXK+6HFbQQGXB_-chimg=FbzQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-13 15:59           ` Simon Glass
2015-08-13 15:59             ` [U-Boot] " Simon Glass
     [not found]             ` <CAPnjgZ3V1KS7POEhsvj63OSB29MUtyaZGBoFR8JGPnaN=-fXVw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-13 16:02               ` Stephen Warren
2015-08-13 16:02                 ` [U-Boot] " Stephen Warren
2015-08-13 18:13                 ` Tom Rini
2015-08-13 18:13                   ` [U-Boot] " Tom Rini
2015-08-13 19:04                   ` Ian Lepore
2015-08-13 19:04                     ` Ian Lepore
     [not found]                     ` <1439492679.242.35.camel-h+KGxgPPiopAfugRpC6u6w@public.gmane.org>
2015-08-13 19:37                       ` Stephen Warren
2015-08-13 19:37                         ` Stephen Warren
     [not found]                         ` <55CCF20C.9000104-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2015-08-14  7:43                           ` Geert Uytterhoeven
2015-08-14  7:43                             ` Geert Uytterhoeven
2015-08-14 10:22                       ` Linus Walleij [this message]
2015-08-14 10:22                         ` Linus Walleij
2015-08-14 14:27                       ` Rob Herring
2015-08-14 14:27                         ` Rob Herring
     [not found]                         ` <CAL_JsqL8tcECpdwCxatd6ULS8z0UU160OXr8S0ZGTTRRrUaeSQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-14 17:45                           ` Ian Lepore
2015-08-14 17:45                             ` Ian Lepore
     [not found]                             ` <1439574356.242.60.camel-h+KGxgPPiopAfugRpC6u6w@public.gmane.org>
2015-08-14 18:42                               ` Stephen Warren
2015-08-14 18:42                                 ` Stephen Warren
2015-08-17  7:46                               ` Linus Walleij
2015-08-17  7:46                                 ` Linus Walleij
2015-08-14 19:32                     ` Pantelis Antoniou
2015-08-14 19:32                       ` [U-Boot] " Pantelis Antoniou
2015-08-13 22:24               ` Rob Herring
2015-08-13 22:24                 ` [U-Boot] " Rob Herring
2015-08-07 13:42 ` [U-Boot] [PATCH v3 02/11] arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info Simon Glass
2015-08-11  3:58   ` Stephen Warren
2016-05-23 15:39     ` Simon Glass
2015-08-07 13:42 ` [U-Boot] [PATCH v3 03/11] arm: rpi: Bring in kernel device tree files Simon Glass
2015-08-07 13:42 ` [U-Boot] [PATCH v3 04/11] arm: rpi: Device tree modifications for U-Boot Simon Glass
2015-08-11  4:00   ` Stephen Warren
2015-08-11  4:17     ` Simon Glass
2015-08-11  4:25       ` Stephen Warren
2015-08-12 13:28         ` Simon Glass
2015-08-07 13:42 ` [U-Boot] [PATCH v3 05/11] arm: rpi: Add device tree files for Raspberry Pi 2 Simon Glass
2015-08-07 13:42 ` [U-Boot] [PATCH v3 06/11] arm: rpi: Enable device tree control for Rasberry Pi Simon Glass
2015-08-11  3:47   ` Stephen Warren
2015-08-14 19:20     ` Simon Glass
2015-08-15  3:32       ` Stephen Warren
2015-08-15 13:59         ` Simon Glass
2015-08-07 13:42 ` [U-Boot] [PATCH v3 07/11] arm: rpi: Enable device tree control for Rasberry Pi 2 Simon Glass
2015-08-07 13:42 ` [U-Boot] [PATCH v3 08/11] arm: rpi: Drop the UART console platform data Simon Glass
2015-08-07 13:42 ` [U-Boot] [PATCH v3 09/11] arm: rpi: Drop the GPIO " Simon Glass
2015-08-07 13:42 ` [U-Boot] [PATCH v3 10/11] arm: rpi: Move to driver model for USB Simon Glass
2015-08-07 13:42 ` [U-Boot] [PATCH v3 11/11] arm: rpi: Use driver model for Ethernet Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACRpkdY1G0zgQ0mw3VP_rA89+kcaipCfJqoPpieVDTBjbeDa1Q@mail.gmail.com \
    --to=linus.walleij-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=ian-h+KGxgPPiopAfugRpC6u6w@public.gmane.org \
    --cc=joe.hershberger-acOepvfBmUk@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org \
    --cc=u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.