On Mon, 2024-09-30 at 01:47 +0000, Delphine_CC_Chiu/WYHQ/Wiwynn wrote: > > > -----Original Message----- > > From: Andrew Jeffery <andrew@xxxxxxxxxxxxxxxxxxxx> > > Sent: Monday, September 30, 2024 7:44 AM > > To: Patrick Williams <patrick@xxxxxxxxx>; Delphine_CC_Chiu/WYHQ/Wiwynn > > <Delphine_CC_Chiu@xxxxxxxxxx> > > Cc: Rob Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>; > > Conor Dooley <conor+dt@xxxxxxxxxx>; Joel Stanley <joel@xxxxxxxxx>; Ricky CX > > Wu <ricky.cx.wu.wiwynn@xxxxxxxxx>; devicetree@xxxxxxxxxxxxxxx; > > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-aspeed@xxxxxxxxxxxxxxxx; > > linux-kernel@xxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxx/__;!!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
