[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ebca21afb0a2c3aef82432446838c02127f44620.camel@mediatek.com>
Date: Fri, 9 Jan 2026 06:20:27 +0000
From: Peter Wang (王信友) <peter.wang@...iatek.com>
To: "chu.stanley@...il.com" <chu.stanley@...il.com>, "robh@...nel.org"
<robh@...nel.org>, Chunfeng Yun (云春峰)
<Chunfeng.Yun@...iatek.com>, "kishon@...nel.org" <kishon@...nel.org>,
"James.Bottomley@...senpartnership.com"
<James.Bottomley@...senpartnership.com>, "bvanassche@....org"
<bvanassche@....org>, AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>,
Chaotian Jing (井朝天)
<Chaotian.Jing@...iatek.com>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
"lgirdwood@...il.com" <lgirdwood@...il.com>,
"nicolas.frattaroli@...labora.com" <nicolas.frattaroli@...labora.com>,
"vkoul@...nel.org" <vkoul@...nel.org>, "krzk+dt@...nel.org"
<krzk+dt@...nel.org>, "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
"neil.armstrong@...aro.org" <neil.armstrong@...aro.org>,
"matthias.bgg@...il.com" <matthias.bgg@...il.com>, "avri.altman@....com"
<avri.altman@....com>, "broonie@...nel.org" <broonie@...nel.org>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>
CC: "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-phy@...ts.infradead.org"
<linux-phy@...ts.infradead.org>, "linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>, Louis-Alexis Eyraud
<louisalexis.eyraud@...labora.com>, "kernel@...labora.com"
<kernel@...labora.com>
Subject: Re: [PATCH v4 12/25] scsi: ufs: mediatek: Remove vendor kernel quirks
cruft
On Thu, 2026-01-08 at 10:28 +0100, Nicolas Frattaroli wrote:
> By "one software supporting multiple hardware configurations", do you
> mean one device tree? Because if so, I don't think that's a good
> idea.
Yes.
> Device tree is meant to describe non-enumerable hardware.
I agree.
>
> Even if you want to make it easier for your customers to ship one
> image
> for several SKUs, there's better ways to do this than having drivers
> fix up individual DT nodes. The platform firmware like u-boot can
> choose
> a DT based on differences it can probe. E.g. on Radxa ROCK 5B/5B+
> boards,
> we have u-boot choose between the 5B and 5B+ DT based on whether
> LPDDR5
> is present, as 5B does not have LPDDR5, so as long as u-boot is told
> it's
> either a ROCK 5B or ROCK 5B+, it can figure out which one
> specifically based
> on that. Similarly, for whichever boards this is for, there may be
> differences that can be probed to disambiguate between several SKUs
> of the
> board as long as it's known it must be at least one of those SKUs.
We will adopt this approach. Thank you for your suggestion.
Powered by blists - more mailing lists