All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petko Manolov <petko.manolov@konsulko.com>
To: Fabio Estevam <festevam@gmail.com>
Cc: u-boot@lists.u-boot-project.org, trini@konsulko.com, uboot-imx@nxp.com
Subject: Re: [PATCH v1 1/1] arm: draeger: Dräger M48 on NXP i.MX6(Q) and Intel/Altera SoCFPGA Cyclone V devicetree.
Date: Sun, 23 Aug 2026 18:00:41 +0300	[thread overview]
Message-ID: <20260823150041.GE17052@cabron.k.g> (raw)
In-Reply-To: <CAOMZO5AfFXrpN3RMPuYw4vM=AHOWBj6hnaXdG8W=KhSsWj5big@mail.gmail.com>

On 26-08-21 16:33:20, Fabio Estevam wrote:
> Hi Petko,
> 
> On Thu, Aug 20, 2026 at 3:19 AM Petko Manolov
> <petko.manolov@konsulko.com> wrote:
> 
> > Unfortunately this board runs QNX, not Linux, so upstreaming them doesn't make
> > sense.
> 
> I don't think the OS running on the board changes this requirement.
> 
> Devicetree describes the hardware, not Linux, and DTs from the Linux tree are
> also consumed by other projects, including U-Boot. In U-Boot, we have been
> moving towards using the upstream Linux devicetree sources rather than
> maintaining independent copies of board DTs.

I have hard time believing the respective Linux maintainters would like to waste
time and energy upstreaming the DTs of a board that's never meant to run Linux
in the first place.  Will see... :)

> There is also an important review aspect here. The Linux devicetree
> maintainers and the subsystem/SoC maintainers review the hardware description
> and its bindings, including dt-schema validation. Simply running the
> validation tools locally is useful, but it is not a replacement for that
> review.
> 
> For the i.MX6 part in particular, this is a well-supported platform upstream,
> so I don't see a reason why the M48 hardware description could not be
> submitted to the Linux devicetree tree even if the product itself boots QNX.

OK

> My suggestion is still to split this work and submit the i. MX6 and SoCFPGA
> DTs to the respective Linux maintainers first.MX6 and SoCFPGA DTs to the
> respective Linux maintainers first. Once they have been accepted upstream,
> U-Boot can consume those DTs from the upstream Linux tree and keep only the
> U-Boot-specific additions in the *-u-boot.dtsi files.

_If_ these patches get accepted.  Have there been such precedents in the past?

> > Can i use some sort of DT validation tool that pass kernel's requirements?
> 
> Yes, the kernel provides dt_binding_check and dtbs_check targets for
> validating DT bindings and DTs against dt-schema. You should run these before
> submission, but passing them alone does not replace upstream DT review.

Yeah, these should be run against the DTs anyway.

Does it make sense to start submitting the arch part of the i.MX6 patches to
u-boot while i'm busy with the DTs?


thanks,
Petko

  reply	other threads:[~2026-08-23 15:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19 15:30 [PATCH v1 0/1] arm: draeger: Add devicetrees for Draeger's M48 board Petko Manolov
2026-08-19 15:30 ` [PATCH v1 1/1] arm: draeger: Dräger M48 on NXP i.MX6(Q) and Intel/Altera SoCFPGA Cyclone V devicetree Petko Manolov
2026-08-19 16:43   ` Fabio Estevam
2026-08-20  6:19     ` Petko Manolov
2026-08-21 19:33       ` Fabio Estevam
2026-08-23 15:00         ` Petko Manolov [this message]
2026-08-24 23:25           ` Fabio Estevam

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=20260823150041.GE17052@cabron.k.g \
    --to=petko.manolov@konsulko.com \
    --cc=festevam@gmail.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.u-boot-project.org \
    --cc=uboot-imx@nxp.com \
    /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.