[PATCH v6 1/2] dt-bindings: arm: aspeed: add IBM SBP1 board

Conor Dooley conor at kernel.org
Wed Nov 6 05:53:13 AEDT 2024


On Tue, Nov 05, 2024 at 10:39:34AM +1030, Andrew Jeffery wrote:
> Hi Conor,
> 
> On Mon, 2024-11-04 at 18:49 +0000, Conor Dooley wrote:
> > On Mon, Nov 04, 2024 at 08:39:21AM -0600, Rob Herring (Arm) wrote:
> > > 
> > > On Mon, 04 Nov 2024 14:52:14 +0530, Naresh Solanki wrote:
> > > > Document the new compatibles used on IBM SBP1.
> > > > 
> > > > Signed-off-by: Naresh Solanki <naresh.solanki at 9elements.com>
> > > > Acked-by: Conor Dooley <conor.dooley at microchip.com>
> > > > ---
> > > > Changes in V4:
> > > > - Retain Acked-by from v2.
> > > > - Fix alphabetic order
> > > > ---
> > > >  Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > 
> > > 
> > > My bot found new DTB warnings on the .dts files added or changed in
> > > this
> > > series.
> > > 
> > > Some warnings may be from an existing SoC .dtsi. Or perhaps the
> > > warnings
> > > are fixed by another series. Ultimately, it is up to the platform
> > > maintainer whether these warnings are acceptable or not. No need to
> > > reply
> > > unless the platform maintainer has comments.
> > > 
> > > If you already ran DT checks and didn't see these error(s), then
> > > make sure dt-schema is up to date:
> > > 
> > >   pip3 install dtschema --upgrade
> > > 
> > > 
> > > New warnings running 'make CHECK_DTBS=y aspeed/aspeed-bmc-ibm-
> > > sbp1.dtb' for
> > > 20241104092220.2268805-1-naresh.solanki at 9elements.com:
> > 
> > Really? This many warnings on a v6?
> > 
> 
> I understand that it's surprising and disappointing, however these
> warnings are from the Aspeed DTSIs and not directly from the proposed
> DTS. Many are an artefact of history, and I'm (slowly) working to clean
> them up. Recently I haven't had any time to dedicate to that effort,
> and as I'm somewhat responsible for the state of things, I'm not
> prepared to block other people's patches and push my own
> responsibilities onto them.

Ah, you see that's where I would say "no new warnings" and get the
submitter to fix them ;) And were I the submitter, I'd want to resolve
the warnings rather than run into issues down the road when things get
"fixed"/documented. But I guess that's why I have the schmucks task of
reviewing bindings innit..

> I've been replying to those proposing new Aspeed-based devicetrees to
> separate the warnings they're introducing from the warnings that
> already exist, and requiring them to fix the issues they're responsible
> for. I hope that I'll have time to continue to improve the situation,
> as this is obviously a tedious task for me too. 

Well, it is your platform and if you're confident that these nodes are
correct despite the warnings, who am I to stop you!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20241105/50a6a37d/attachment.sig>


More information about the Linux-aspeed mailing list