From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
Sean Anderson <seanga2@gmail.com>, Bin Meng <bmeng.cn@gmail.com>,
U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [PATCH v2 3/3] RFC: doc: Add documentation about devicetree usage
Date: Fri, 10 Sep 2021 10:00:27 -0400 [thread overview]
Message-ID: <20210910140027.GM12964@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ0W1BmMj2Fy9qrNBpi=MBVdXtyMm1U0r2_hf9vzeaFfOg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
On Fri, Sep 03, 2021 at 02:53:46AM -0600, Simon Glass wrote:
> Hi,
>
> On Mon, 30 Aug 2021 at 08:48, Tom Rini <trini@konsulko.com> wrote:
[snip]
> > We should, when applicable, submit our bindings upstream just like any
> > other project. We also want to make sure that when we do so, we hold
> > ourselves to a high standard.
>
> I wonder if should just try just try that again, just to see what
> happens. I vaguely remember the UART clock thing from many years ago,
> being told that we should just probe the whole clock driver and then
> have a debug UART...
>
> But it really isn't up to Linux to refuse to accept U-Boot bindings,
> IMO. U-Boot has much right to u-boot, as Linux does to linux,
A bit late, but yes, between then and now I believe things have changed
and there is a more broad acceptance that just because the primary
repository for device trees and bindings is the linux kernel does not
mean that only the linux kernel needs to be considered. So we really do
need to pick something, polish it up, and then subject ourselves to
review.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2021-09-10 14:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-28 16:46 [PATCH v2 0/3] doc: Clarify how U-Boot makes use of devicetree Simon Glass
2021-08-28 16:46 ` [PATCH v2 1/3] doc: Tidy up the bindings for the config/ node Simon Glass
2021-08-30 14:45 ` Marcel Ziswiler
2021-08-28 16:46 ` [PATCH v2 2/3] doc: Complete the list of available runtime-config options Simon Glass
2021-08-30 14:53 ` Marcel Ziswiler
2021-08-28 16:46 ` [PATCH v2 3/3] RFC: doc: Add documentation about devicetree usage Simon Glass
2021-08-30 12:46 ` Ilias Apalodimas
2021-08-30 14:30 ` Heinrich Schuchardt
2021-08-30 14:48 ` Tom Rini
2021-08-30 15:14 ` Heinrich Schuchardt
2021-08-30 16:15 ` Tom Rini
2021-09-03 8:53 ` Simon Glass
2021-09-03 8:53 ` Simon Glass
2021-09-10 14:00 ` Tom Rini [this message]
2021-10-22 3:05 ` Simon Glass
2021-08-30 14:53 ` Marcel Ziswiler
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=20210910140027.GM12964@bill-the-cat \
--to=trini@konsulko.com \
--cc=bmeng.cn@gmail.com \
--cc=ilias.apalodimas@linaro.org \
--cc=mark.kettenis@xs4all.nl \
--cc=seanga2@gmail.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox