All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jeffery <andrew@codeconstruct.com.au>
To: Patrick Williams <patrick@stwcx.xyz>
Cc: openbmc@lists.ozlabs.org, Joel Stanley <joel@jms.id.au>,
	Peter Yin <peteryin.openbmc@gmail.com>
Subject: Re: [PATCH u-boot, v2019.04-aspeed-openbmc v1 1/1] ARM: dts: Aspeed: Add Facebook common dts
Date: Fri, 17 May 2024 09:06:54 +0930	[thread overview]
Message-ID: <242c8e796123208e3a3d133a292b8409a03c0e89.camel@codeconstruct.com.au> (raw)
In-Reply-To: <ZkVxdHBLOG2BeRui@heinlein.vulture-banana.ts.net>

On Wed, 2024-05-15 at 21:37 -0500, Patrick Williams wrote:
> On Thu, May 16, 2024 at 10:30:30AM +0930, Andrew Jeffery wrote:
> > On Wed, 2024-05-15 at 17:41 +0800, Peter Yin wrote:
> > > Hi Andrew,
> > >      Thank you for your reply, Do you mean something like this?
> > > compatible = "facebook,harma-bmc", "facebook,minerva-bmc", "aspeed,ast2600";
> > > 
> > 
> > Right. It removes the nebulous "common" concept that might be upset by
> > future changes.
> 
> I agree that just "common" is probably not appropriate because this
> device tree only covers ast2600-based platforms.
> 
> We are trying to design our BMC hardware such that at a u-boot level,
> the same device tree can be used for most of our platforms.
> 

Seems sensible, but does this common design point have a name?
Otherwise it feels like a "coincidently similar" relationship, which
seems a bit ill-defined. Better to enumerate the specific platforms in
that case.

>   This is
> partially so we can avoid having to add new changes for u-boot for every
> new platform.

Not having to write new drivers or define drastically different
devicetrees feels like a useful goal. I don't feel tacking on a new
compatible here is particularly onerous (not that it even matters in
practice if you select only this specific devicetree in the u-boot
build).

Just wondering if we can avoid nebulous concepts, and rather keep
things concrete.

> 
> Should we do something like "facebook,ast2600-standard"?
> 

I guess I'm trying to guard-rail the discussion from the position of
the compatible strings should be documented in the DT schemas. Is this
something that would pass review upstream?

Andrew

  reply	other threads:[~2024-05-16 23:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-13 14:49 [PATCH u-boot, v2019.04-aspeed-openbmc v1 1/1] ARM: dts: Aspeed: Add Facebook common dts Peter Yin
2024-05-13 23:52 ` Andrew Jeffery
2024-05-15  9:41   ` Peter Yin
2024-05-16  1:00     ` Andrew Jeffery
2024-05-16  2:37       ` Patrick Williams
2024-05-16 23:36         ` Andrew Jeffery [this message]
2024-05-17  1:19           ` Patrick Williams
2024-05-17  1:30             ` Andrew Jeffery
2024-05-17  1:59               ` Patrick Williams

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=242c8e796123208e3a3d133a292b8409a03c0e89.camel@codeconstruct.com.au \
    --to=andrew@codeconstruct.com.au \
    --cc=joel@jms.id.au \
    --cc=openbmc@lists.ozlabs.org \
    --cc=patrick@stwcx.xyz \
    --cc=peteryin.openbmc@gmail.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.