[PATCH v1] ARM: dts: aspeed: yosemite4: Add i2c-mux for CPLD IOE on Spider Board

[Andrew Jeffery]

On Mon, 2024-09-30 at 01:47 +0000, Delphine_CC_Chiu/WYHQ/Wiwynn wrote:
> 
> > -----Original Message-----
> > From: Andrew Jeffery <andrew at codeconstruct.com.au>
> > Sent: Monday, September 30, 2024 7:44 AM
> > To: Patrick Williams <patrick at stwcx.xyz>; Delphine_CC_Chiu/WYHQ/Wiwynn
> > <Delphine_CC_Chiu at wiwynn.com>
> > Cc: Rob Herring <robh at kernel.org>; Krzysztof Kozlowski <krzk+dt at kernel.org>;
> > Conor Dooley <conor+dt at kernel.org>; Joel Stanley <joel at jms.id.au>; Ricky CX
> > Wu <ricky.cx.wu.wiwynn at gmail.com>; devicetree at vger.kernel.org;
> > linux-arm-kernel at lists.infradead.org; linux-aspeed at lists.ozlabs.org;
> > linux-kernel at vger.kernel.org
> > Subject: Re: [PATCH v1] ARM: dts: aspeed: yosemite4: Add i2c-mux for CPLD
> > IOE on Spider Board
> > 
> >  [External Sender]
> > 
> >  [External Sender]
> > 
> > Hi Ricky, Patrick,
> > 
> > On Fri, 2024-09-27 at 22:33 -0400, Patrick Williams wrote:
> > > On Fri, Sep 27, 2024 at 09:24:11AM +0000,
> > Delphine_CC_Chiu/WYHQ/Wiwynn wrote:
> > > 
> > > > Would like to ask should I base on the openbmc/linux repo to create
> > > > the remaining patches that have context dependencies and add the
> > > > lore link of the those patches that I've sent in the cover letter?
> > > 
> > > I believe you're trying to get the patches applied onto the upstream
> > > tree, so no you should not base on the openbmc/linux repo.  That repo
> > > is a 6.6 branch.  You need to base the commits on torvalds/linux.
> > > 
> > 
> > In my previous email[1] I requested:
> > 
> > > Please assess the remaining yosemite4 devicetree patches (those you
> > > haven't received a thank-you email for) and send an appropriately
> > > constructed series so they can all be applied together, based on the
> > > tree here:
> > > 
> > > https://urldefense.com/v3/__https://github.com/amboar/linux/tree/for/b
> > > 
> > mc/dt__;!!J63qqgXj!N56Dq0KcUR0NerePsoY0JUBCDvFG_F3KyRF0D4qNdu_Ozc
> > SGVPC
> > > SBOJk6u28AWPfgDRWsLE1B__-_ZNVKYv-zhc_6PY$
> > 
> > So I'm not sure why there's confusion and speculation as to which tree should
> > be used :( Note that the for/bmc/dt branch above is currently based on
> > v6.12-rc1.
> > 
> > [1]:
> > https://urldefense.com/v3/__https://lore.kernel.org/all/fbdc9efe87a1bed9fea7
> > d0abaf955aa1a3dc24ac.camel at codeconstruct.com.au/__;!!J63qqgXj!N56Dq0
> > KcUR0NerePsoY0JUBCDvFG_F3KyRF0D4qNdu_OzcSGVPCSBOJk6u28AWPfgDRW
> > sLE1B__-_ZNVKYv-uNCc7qE$
> > 
> > Anyway, I asked that because I have already applied one of the
> > Yosemite4 patches there, and developing the remaining patches against any
> > other tree will again cause conflicts (due to the lack of that patch).
> > 
> > More broadly though, Patrick is right: If you're sending your patches upstream,
> > it is required that you develop and test your patches against an appropriate
> > upstream tree. Usually this is the most recent -rc1 tag, unless there are reasons
> > otherwise (such as conflicts). The OpenBMC kernel fork is not an appropriate
> > tree on which to base work you intend to send upstream.
> > 
> > Thanks,
> > 
> > Andrew
> 
> Hi Andrew,
> 
> Sorry for my misunderstanding.

No worries, hopefully we can get it sorted out. I realise the sentiment
of my responses below is quite direct, but I'm trying to cut through
the confusion. Please bear with me.

> So I should combine the remaining yosemite4 device tree patches as a single serial
> 

Specifically, any patches that have dependencies on each other. In this
case, patches that share diff context need to be in a single series so
they don't generate conflicts when I try to apply them.

>  based on torvalds/linux
> 

No. In _this specific instance_, please base the series on

https://github.com/amboar/linux/tree/for/bmc/dt

If you look, you will find this is itself already based on v6.12-rc1,
and contains ASPEED devicetree patches both yourself and others have
sent that are intended to appear in v6.13.

I need you to do this because I've _already_ applied one yosemite4
patch there which is generating conflicts with your other yosemite4
patches.

_However_, in almost all other cases, you should base your series on
the latest -rc1.

>  and test on openbmc/linux
> 

No. If you're sending the patches upstream you must test them as
applied to the relevant upstream tree. In _this_ case, it's the
for/bmc/dt branch I've linked above.

>  then send the serial patches to torvalds/linux.

You send them to the lists as you have done here, yes.

> And you will help to fix the conflicts
> 

No. I'm asking you to fix the conflicts that your patches are
generating. I don't want to be in the business of resolving other
people's conflicts and risking incorrect results. The conflict
resolutions should be tested to the usual expectations.

>  when you apply the serial patches to openbmc/linux.

I'm doing two separate-but-related roles:

1. Upstream patch collector for BMC-related devicetrees
2. OpenBMC kernel janitor

The first role is how I'm interacting with you in this thread. At the
moment I'm helping Joel out: recently he's been taking the patches I've
collected in the for/bmc/dt branch I linked above and has sent a PR to
Arnd for integration into torvalds/linux via the SoC tree.

However, in the process of collecting your patches in role 1 I also
happen to switch to role 2, where I backport your upstream patches to
OpenBMC's v6.6-based (LTS) tree _if_ applying the patch/series directly
to that tree does not cause conflicts. If there are conflicts, then I
expect you to also send a backport patch that accounts for the
conflicts to _only_ the openbmc list (and not the upstream lists and
maintainers also on Cc here).

So in neither case should you expect me to be resolving conflicts for
you. The resolution still needs testing as noted above, and I'm rarely
in a position to do that myself.

I hope that helps.

Andrew