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

[Andrew Jeffery]

On Tue, 2024-11-05 at 18:53 +0000, Conor Dooley wrote:
> 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 have to manage that in tension with my concern of people simply not
upstreaming their devicetrees in response. I'd prefer to have them
merged upstream than to encourage more forks in this corner of the
world. If people would like to take the initiative and do the binding
conversions, corrections and devicetree fixes themselves, I'll
definitely review them.

> 
> > 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!

I think where things stand currently is a bit fuzzier than anyone would
like. The nodes are not incorrect to the point of being non-functional
with respect to their intent, but clearly they're not so correct that
they do not have room for improvement.

Andrew