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

Commit Message

Delphine CC Chiu Sept. 26, 2024, 2:41 a.m. UTC

From: Ricky CX Wu <[e-mail]>

Add I2C mux for CPLD IOE on Spider Board.

Signed-off-by: Ricky CX Wu <[e-mail]>
Signed-off-by: Delphine CC Chiu <[e-mail]>
---
 .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 67 +++++++++++++++++++
 1 file changed, 67 insertions(+)

Comments

Andrew Jeffery Sept. 27, 2024, 5:57 a.m. UTC | #1

On Thu, 2024-09-26 at 10:41 +0800, Delphine CC Chiu wrote:
> From: Ricky CX Wu <[e-mail]>
> 
> Add I2C mux for CPLD IOE on Spider Board.
> 
> Signed-off-by: Ricky CX Wu <[e-mail]>
> Signed-off-by: Delphine CC Chiu <[e-mail]>
> ---
>  .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 67 +++++++++++++++++++
>  1 file changed, 67 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> index 98477792aa00..ea1a9c765483 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> @@ -17,6 +17,9 @@ aliases {
>  		serial6 = &uart7;
>  		serial7 = &uart8;
>  		serial8 = &uart9;
> +
> +		i2c28 = &imux28;
> +		i2c29 = &imux29;
>  	};
>  

Have you tried to apply all of your individual yosemite4 patches
together in one branch? I have, and unfortunately I can't apply them
all, because they generate conflicts with each other.

If your patches have context dependencies you need to send them as a
single series and not separate patches that cannot be properly
combined.

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://github.com/amboar/linux/tree/for/bmc/dt

Please also indicate in the cover letter (with links to lore) which
remaining patches are truly independent that still need to be applied.

Thanks,

Andrew

Delphine CC Chiu Sept. 27, 2024, 9:24 a.m. UTC | #2

> -----Original Message-----
> From: Andrew Jeffery <[e-mail]>
> Sent: Friday, September 27, 2024 1:57 PM
> To: Delphine_CC_Chiu/WYHQ/Wiwynn <[e-mail]>;
> [e-mail]; Rob Herring <[e-mail]>; Krzysztof Kozlowski
> <[e-mail]>; Conor Dooley <[e-mail]>; Joel Stanley
> <[e-mail]>
> Cc: Ricky CX Wu <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [PATCH v1] ARM: dts: aspeed: yosemite4: Add i2c-mux for CPLD
> IOE on Spider Board
> 
>  [External Sender]
> 
>  [External Sender]
> 
> On Thu, 2024-09-26 at 10:41 +0800, Delphine CC Chiu wrote:
> > From: Ricky CX Wu <[e-mail]>
> >
> > Add I2C mux for CPLD IOE on Spider Board.
> >
> > Signed-off-by: Ricky CX Wu <[e-mail]>
> > Signed-off-by: Delphine CC Chiu <[e-mail]>
> > ---
> >  .../aspeed/aspeed-bmc-facebook-yosemite4.dts  | 67
> > +++++++++++++++++++
> >  1 file changed, 67 insertions(+)
> >
> > diff --git
> > a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> > b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> > index 98477792aa00..ea1a9c765483 100644
> > --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> > @@ -17,6 +17,9 @@ aliases {
> >               serial6 = &uart7;
> >               serial7 = &uart8;
> >               serial8 = &uart9;
> > +
> > +             i2c28 = &imux28;
> > +             i2c29 = &imux29;
> >       };
> >
> 
> Have you tried to apply all of your individual yosemite4 patches together in
> one branch? I have, and unfortunately I can't apply them all, because they
> generate conflicts with each other.
> 
> If your patches have context dependencies you need to send them as a single
> series and not separate patches that cannot be properly combined.
> 
> 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/bmc/d
> t__;!!J63qqgXj!KnZT-wO8ksK53BvGiFMdhhNgCnQ98FQLMdHeyYOSGsPw2KG1
> MNeJjvsZz4zuX7YegeuLfSsa9q9ZEBriDYsTTu8LjuM$
> 
> Please also indicate in the cover letter (with links to lore) which remaining
> patches are truly independent that still need to be applied.
> 
> Thanks,
> 
> Andrew
Hi Andrew

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?

Ricky

Patrick Williams Sept. 28, 2024, 2:33 a.m. UTC | #3

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.

Andrew Jeffery Sept. 29, 2024, 11:44 p.m. UTC | #4

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://github.com/amboar/linux/tree/for/bmc/dt

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://lore.kernel.org/all/[e-mail]/

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

Delphine CC Chiu Sept. 30, 2024, 1:47 a.m. UTC | #5

> -----Original Message-----
> From: Andrew Jeffery <[e-mail]>
> Sent: Monday, September 30, 2024 7:44 AM
> To: Patrick Williams <[e-mail]>; Delphine_CC_Chiu/WYHQ/Wiwynn
> <[e-mail]>
> Cc: Rob Herring <[e-mail]>; Krzysztof Kozlowski <[e-mail]>;
> Conor Dooley <[e-mail]>; Joel Stanley <[e-mail]>; Ricky CX
> Wu <[e-mail]>; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> 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
> [e-mail]/__;!!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.
So I should combine the remaining yosemite4 device tree patches as a single serial based on torvalds/linux and test on openbmc/linux then send the serial patches to torvalds/linux.
And you will help to fix the conflicts when you apply the serial patches to openbmc/linux.
Do I understand it correctly?

Andrew Jeffery Sept. 30, 2024, 2:36 a.m. UTC | #6

On Mon, 2024-09-30 at 01:47 +0000, Delphine_CC_Chiu/WYHQ/Wiwynn wrote:
> 
> > -----Original Message-----
> > From: Andrew Jeffery <[e-mail]>
> > Sent: Monday, September 30, 2024 7:44 AM
> > To: Patrick Williams <[e-mail]>; Delphine_CC_Chiu/WYHQ/Wiwynn
> > <[e-mail]>
> > Cc: Rob Herring <[e-mail]>; Krzysztof Kozlowski <[e-mail]>;
> > Conor Dooley <[e-mail]>; Joel Stanley <[e-mail]>; Ricky CX
> > Wu <[e-mail]>; [e-mail];
> > [e-mail]; [e-mail];
> > [e-mail]
> > 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
> > [e-mail]/__;!!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

Delphine CC Chiu Sept. 30, 2024, 5:55 a.m. UTC | #7

> -----Original Message-----
> From: Andrew Jeffery <[e-mail]>
> Sent: Monday, September 30, 2024 10:37 AM
> To: Delphine_CC_Chiu/WYHQ/Wiwynn <[e-mail]>;
> Patrick Williams <[e-mail]>
> Cc: Rob Herring <[e-mail]>; Krzysztof Kozlowski <[e-mail]>;
> Conor Dooley <[e-mail]>; Joel Stanley <[e-mail]>; Ricky CX
> Wu <[e-mail]>; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [PATCH v1] ARM: dts: aspeed: yosemite4: Add i2c-mux for CPLD
> IOE on Spider Board
> 
>  [External Sender]
> 
>  [External Sender]
> 
> On Mon, 2024-09-30 at 01:47 +0000, Delphine_CC_Chiu/WYHQ/Wiwynn
> wrote:
> >
> > > -----Original Message-----
> > > From: Andrew Jeffery <[e-mail]>
> > > Sent: Monday, September 30, 2024 7:44 AM
> > > To: Patrick Williams <[e-mail]>;
> > > Delphine_CC_Chiu/WYHQ/Wiwynn <[e-mail]>
> > > Cc: Rob Herring <[e-mail]>; Krzysztof Kozlowski
> > > <[e-mail]>; Conor Dooley <[e-mail]>; Joel
> > > Stanley <[e-mail]>; Ricky CX Wu
> > > <[e-mail]>; [e-mail];
> > > [e-mail]; [e-mail];
> > > [e-mail]
> > > 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/f
> > > > or/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/fbdc9efe87a1
> > > bed9fea7
> > >
> [e-mail]/__;!!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.
> 
Sure. Thank you for all your help!

> > 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.
> 
Understood.

> >  based on torvalds/linux
> >
> 
> No. In _this specific instance_, please base the series on
> 
> https://urldefense.com/v3/__https://github.com/amboar/linux/tree/for/bmc/d
> t__;!!J63qqgXj!O6de7qi9vrhod1xS-7osXngZvytCR3QfbV1zDPM2oUFbQxqCxG1y
> BlrbsSwJkNvPFcovNQzmHtHtCo41H529xCRTe7w$
> 
> 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.
> 
Understood, I'll provide the serial of patches to torvalds/linux base on the repo you provided.
> >  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.
> 
Understood.
> >  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

Thanks for your information.
I really appreciate for your help!
I wasn't sure which linux repo should I base to send the patches before so that
I had some questions about the conflicts fixing.

I understand the rule now after reading the information you provided, and I will
provide the serial patches later.

I have one more question that if I need to add the DTS based on the patches that
have been applied but haven't been merged in torvalds/linux.
Should I also based on the branch "for/bmc/dt" from amboar/linux to create the
patch?

Regards,
Ricky

Andrew Jeffery Sept. 30, 2024, 6:02 a.m. UTC | #8

On Mon, 2024-09-30 at 05:55 +0000, Delphine_CC_Chiu/WYHQ/Wiwynn wrote:
> 
> I have one more question that if I need to add the DTS based on the patches that
> have been applied but haven't been merged in torvalds/linux.
> Should I also based on the branch "for/bmc/dt" from amboar/linux to create the
> patch?
> 

You can do that, yes. We can at least then be sure your work won't
generate conflicts when I try to apply it (unless you've
inappropriately split your series).

Cheers,

Andrew

Delphine CC Chiu Sept. 30, 2024, 6:08 a.m. UTC | #9

> -----Original Message-----
> From: Andrew Jeffery <[e-mail]>
> Sent: Monday, September 30, 2024 2:02 PM
> To: Delphine_CC_Chiu/WYHQ/Wiwynn <[e-mail]>;
> Patrick Williams <[e-mail]>
> Cc: Rob Herring <[e-mail]>; Krzysztof Kozlowski <[e-mail]>;
> Conor Dooley <[e-mail]>; Joel Stanley <[e-mail]>; Ricky CX
> Wu <[e-mail]>; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [PATCH v1] ARM: dts: aspeed: yosemite4: Add i2c-mux for CPLD
> IOE on Spider Board
> 
>  [External Sender]
> 
>  [External Sender]
> 
> On Mon, 2024-09-30 at 05:55 +0000, Delphine_CC_Chiu/WYHQ/Wiwynn
> wrote:
> >
> > I have one more question that if I need to add the DTS based on the
> > patches that have been applied but haven't been merged in torvalds/linux.
> > Should I also based on the branch "for/bmc/dt" from amboar/linux to
> > create the patch?
> >
> 
> You can do that, yes. We can at least then be sure your work won't generate
> conflicts when I try to apply it (unless you've inappropriately split your series).
> 
> Cheers,
> 
> Andrew

Got it!
Thanks for your help.

Regards,
Ricky

Patch

diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 98477792aa00..ea1a9c765483 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -17,6 +17,9 @@  aliases {
 		serial6 = &uart7;
 		serial7 = &uart8;
 		serial8 = &uart9;
+
+		i2c28 = &imux28;
+		i2c29 = &imux29;
 	};
 
 	chosen {
@@ -277,8 +280,72 @@  i2c-mux@71 {
 };
 
 &i2c10 {
+	#address-cells = <1>;
+	#size-cells = <0>;
 	status = "okay";
 	bus-frequency = <400000>;
+	i2c-mux@74 {
+		compatible = "nxp,pca9544";
+		reg = <0x74>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		i2c-mux-idle-disconnect;
+
+		imux28: i2c@0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			gpio@20 {
+				compatible = "nxp,pca9506";
+				reg = <0x20>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio@21 {
+				compatible = "nxp,pca9506";
+				reg = <0x21>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio@22 {
+				compatible = "nxp,pca9506";
+				reg = <0x22>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio@23 {
+				compatible = "nxp,pca9506";
+				reg = <0x23>;
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			gpio@24 {
+				compatible = "nxp,pca9506";
+				reg = <0x24>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				gpio-line-names = "","","","",
+						  "NIC0_MAIN_PWR_EN",
+						  "NIC1_MAIN_PWR_EN",
+						  "NIC2_MAIN_PWR_EN",
+						  "NIC3_MAIN_PWR_EN",
+						  "","","","","","","","",
+						  "","","","","","","","",
+						  "","","","","","","","";
+			};
+		};
+
+		imux29: i2c@1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
 };
 
 &i2c11 {