Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Jiasheng Jiang]

On Fri, Jan 28, 2022 at 10:26:51PM +0800, Paul Mulders wrote:
> I guess this breaks all MT7622 SoCs since it'll prematurely exit
> init_clks (and subsequently init_scp) completely once devm_clk_get
> fails to get a reference to the mm clock producer (which happens to be
> the first one tried). This is because MT7623 has a GPU (so no mm
> clock) and MT7622 doesn't, and as a result the other clock producer
> pointers never get initialized (and other stuff in init_scp after
> returning from the error never happens).
>
> The patch seems fundamentally flawed, I guess it was either not tested
> at all, or only tested on a MT7623. The initialization functions seem
> designed with the idea that it's ok if some clocks aren't present, so
> stopping the initialization when one of them isn't present seems
> wrong. (For example, there is also a MT7622B variant of the MT7622
> which probably also lacks some clocks MT7622(A) does have).

I don't think the patch for init_clks() is flawed.
At most it is incompleted.
What it did is like fixing a potential error in the tool platform
providing service for the upper application, like what you said,
MT7623 and MT7622.
We should not keep the error in the platform because of the upper
application.
And it seems like it is MT7622 that is flawed.
The better way is to fix both the bug in init_clks() and its caller,
MT7622.

Sincerely thanks,
Jiang

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Jiasheng Jiang]

On Fri, Jan 28, 2022 at 10:26:51PM +0800, Paul Mulders wrote:
> I guess this breaks all MT7622 SoCs since it'll prematurely exit
> init_clks (and subsequently init_scp) completely once devm_clk_get
> fails to get a reference to the mm clock producer (which happens to be
> the first one tried). This is because MT7623 has a GPU (so no mm
> clock) and MT7622 doesn't, and as a result the other clock producer
> pointers never get initialized (and other stuff in init_scp after
> returning from the error never happens).
>
> The patch seems fundamentally flawed, I guess it was either not tested
> at all, or only tested on a MT7623. The initialization functions seem
> designed with the idea that it's ok if some clocks aren't present, so
> stopping the initialization when one of them isn't present seems
> wrong. (For example, there is also a MT7622B variant of the MT7622
> which probably also lacks some clocks MT7622(A) does have).

I don't think the patch for init_clks() is flawed.
At most it is incompleted.
What it did is like fixing a potential error in the tool platform
providing service for the upper application, like what you said,
MT7623 and MT7622.
We should not keep the error in the platform because of the upper
application.
And it seems like it is MT7622 that is flawed.
The better way is to fix both the bug in init_clks() and its caller,
MT7622.

Sincerely thanks,
Jiang


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Daniel Golle]

On Sun, Jan 30, 2022 at 10:43:35AM +0800, Jiasheng Jiang wrote:
> On Fri, Jan 28, 2022 at 10:26:51PM +0800, Paul Mulders wrote:
> > I guess this breaks all MT7622 SoCs since it'll prematurely exit
> > init_clks (and subsequently init_scp) completely once devm_clk_get
> > fails to get a reference to the mm clock producer (which happens to be
> > the first one tried). This is because MT7623 has a GPU (so no mm
> > clock) and MT7622 doesn't, and as a result the other clock producer
> > pointers never get initialized (and other stuff in init_scp after
> > returning from the error never happens).
> >
> > The patch seems fundamentally flawed, I guess it was either not tested
> > at all, or only tested on a MT7623. The initialization functions seem
> > designed with the idea that it's ok if some clocks aren't present, so
> > stopping the initialization when one of them isn't present seems
> > wrong. (For example, there is also a MT7622B variant of the MT7622
> > which probably also lacks some clocks MT7622(A) does have).
> 
> I don't think the patch for init_clks() is flawed.
> At most it is incompleted.
> What it did is like fixing a potential error in the tool platform
> providing service for the upper application, like what you said,
> MT7623 and MT7622.
> We should not keep the error in the platform because of the upper
> application.
> And it seems like it is MT7622 that is flawed.
> The better way is to fix both the bug in init_clks() and its caller,
> MT7622.

I agree that further cleaning is needed here.
Yet the commit in it's current form very obviously breaks at least the
MT7622 platform if no further fixes are applied.

Imho the whole approach of this driver to hard-code the names of all
clocks it could try to grab in a string-array accompanied by an enum
is flawed.

The correct approach would likely be to add the clocks actually present
to the device tree of each SoC and then grab only those.

I can see that mt2701.dtsi and mt7623.dtsi both have some clocks
defined for scpsys, mt7622.dtsi however lacks them.
I didn't check other MediaTek SoCs which also use scpsys.

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Daniel Golle]

On Sun, Jan 30, 2022 at 10:43:35AM +0800, Jiasheng Jiang wrote:
> On Fri, Jan 28, 2022 at 10:26:51PM +0800, Paul Mulders wrote:
> > I guess this breaks all MT7622 SoCs since it'll prematurely exit
> > init_clks (and subsequently init_scp) completely once devm_clk_get
> > fails to get a reference to the mm clock producer (which happens to be
> > the first one tried). This is because MT7623 has a GPU (so no mm
> > clock) and MT7622 doesn't, and as a result the other clock producer
> > pointers never get initialized (and other stuff in init_scp after
> > returning from the error never happens).
> >
> > The patch seems fundamentally flawed, I guess it was either not tested
> > at all, or only tested on a MT7623. The initialization functions seem
> > designed with the idea that it's ok if some clocks aren't present, so
> > stopping the initialization when one of them isn't present seems
> > wrong. (For example, there is also a MT7622B variant of the MT7622
> > which probably also lacks some clocks MT7622(A) does have).
> 
> I don't think the patch for init_clks() is flawed.
> At most it is incompleted.
> What it did is like fixing a potential error in the tool platform
> providing service for the upper application, like what you said,
> MT7623 and MT7622.
> We should not keep the error in the platform because of the upper
> application.
> And it seems like it is MT7622 that is flawed.
> The better way is to fix both the bug in init_clks() and its caller,
> MT7622.

I agree that further cleaning is needed here.
Yet the commit in it's current form very obviously breaks at least the
MT7622 platform if no further fixes are applied.

Imho the whole approach of this driver to hard-code the names of all
clocks it could try to grab in a string-array accompanied by an enum
is flawed.

The correct approach would likely be to add the clocks actually present
to the device tree of each SoC and then grab only those.

I can see that mt2701.dtsi and mt7623.dtsi both have some clocks
defined for scpsys, mt7622.dtsi however lacks them.
I didn't check other MediaTek SoCs which also use scpsys.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Daniel Golle]

On Sun, Jan 30, 2022 at 10:43:35AM +0800, Jiasheng Jiang wrote:
> On Fri, Jan 28, 2022 at 10:26:51PM +0800, Paul Mulders wrote:
> > I guess this breaks all MT7622 SoCs since it'll prematurely exit
> > init_clks (and subsequently init_scp) completely once devm_clk_get
> > fails to get a reference to the mm clock producer (which happens to be
> > the first one tried). This is because MT7623 has a GPU (so no mm
> > clock) and MT7622 doesn't, and as a result the other clock producer
> > pointers never get initialized (and other stuff in init_scp after
> > returning from the error never happens).
> >
> > The patch seems fundamentally flawed, I guess it was either not tested
> > at all, or only tested on a MT7623. The initialization functions seem
> > designed with the idea that it's ok if some clocks aren't present, so
> > stopping the initialization when one of them isn't present seems
> > wrong. (For example, there is also a MT7622B variant of the MT7622
> > which probably also lacks some clocks MT7622(A) does have).
> 
> I don't think the patch for init_clks() is flawed.
> At most it is incompleted.
> What it did is like fixing a potential error in the tool platform
> providing service for the upper application, like what you said,
> MT7623 and MT7622.
> We should not keep the error in the platform because of the upper
> application.
> And it seems like it is MT7622 that is flawed.
> The better way is to fix both the bug in init_clks() and its caller,
> MT7622.

I agree that further cleaning is needed here.
Yet the commit in it's current form very obviously breaks at least the
MT7622 platform if no further fixes are applied.

Imho the whole approach of this driver to hard-code the names of all
clocks it could try to grab in a string-array accompanied by an enum
is flawed.

The correct approach would likely be to add the clocks actually present
to the device tree of each SoC and then grab only those.

I can see that mt2701.dtsi and mt7623.dtsi both have some clocks
defined for scpsys, mt7622.dtsi however lacks them.
I didn't check other MediaTek SoCs which also use scpsys.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Aw: Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Frank Wunderlich]

> Gesendet: Dienstag, 01. Februar 2022 um 23:19 Uhr
> Von: "Daniel Golle" <daniel@makrotopia.org>
> An: "Jiasheng Jiang" <jiasheng@iscas.ac.cn>
> Cc: justinkb@gmail.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, lgirdwood@gmail.com, broonie@kernel.org, linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
> Betreff: Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer
>
> On Sun, Jan 30, 2022 at 10:43:35AM +0800, Jiasheng Jiang wrote:
> > On Fri, Jan 28, 2022 at 10:26:51PM +0800, Paul Mulders wrote:
> > > I guess this breaks all MT7622 SoCs since it'll prematurely exit
> > > init_clks (and subsequently init_scp) completely once devm_clk_get
> > > fails to get a reference to the mm clock producer (which happens to be
> > > the first one tried). This is because MT7623 has a GPU (so no mm
> > > clock) and MT7622 doesn't, and as a result the other clock producer
> > > pointers never get initialized (and other stuff in init_scp after
> > > returning from the error never happens).
> > >
> > > The patch seems fundamentally flawed, I guess it was either not tested
> > > at all, or only tested on a MT7623. The initialization functions seem
> > > designed with the idea that it's ok if some clocks aren't present, so
> > > stopping the initialization when one of them isn't present seems
> > > wrong. (For example, there is also a MT7622B variant of the MT7622
> > > which probably also lacks some clocks MT7622(A) does have).
> >
> > I don't think the patch for init_clks() is flawed.
> > At most it is incompleted.
> > What it did is like fixing a potential error in the tool platform
> > providing service for the upper application, like what you said,
> > MT7623 and MT7622.
> > We should not keep the error in the platform because of the upper
> > application.
> > And it seems like it is MT7622 that is flawed.
> > The better way is to fix both the bug in init_clks() and its caller,
> > MT7622.
>
> I agree that further cleaning is needed here.
> Yet the commit in it's current form very obviously breaks at least the
> MT7622 platform if no further fixes are applied.
>
> Imho the whole approach of this driver to hard-code the names of all
> clocks it could try to grab in a string-array accompanied by an enum
> is flawed.
>
> The correct approach would likely be to add the clocks actually present
> to the device tree of each SoC and then grab only those.
>
> I can see that mt2701.dtsi and mt7623.dtsi both have some clocks
> defined for scpsys, mt7622.dtsi however lacks them.
> I didn't check other MediaTek SoCs which also use scpsys.

re-add me to discussion :)

have not yet tested mt7623 without the revert i applied for mt7622. will do this later

regards Frank

Aw: Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Frank Wunderlich]

> Gesendet: Dienstag, 01. Februar 2022 um 23:19 Uhr
> Von: "Daniel Golle" <daniel@makrotopia.org>
> An: "Jiasheng Jiang" <jiasheng@iscas.ac.cn>
> Cc: justinkb@gmail.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, lgirdwood@gmail.com, broonie@kernel.org, linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
> Betreff: Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer
>
> On Sun, Jan 30, 2022 at 10:43:35AM +0800, Jiasheng Jiang wrote:
> > On Fri, Jan 28, 2022 at 10:26:51PM +0800, Paul Mulders wrote:
> > > I guess this breaks all MT7622 SoCs since it'll prematurely exit
> > > init_clks (and subsequently init_scp) completely once devm_clk_get
> > > fails to get a reference to the mm clock producer (which happens to be
> > > the first one tried). This is because MT7623 has a GPU (so no mm
> > > clock) and MT7622 doesn't, and as a result the other clock producer
> > > pointers never get initialized (and other stuff in init_scp after
> > > returning from the error never happens).
> > >
> > > The patch seems fundamentally flawed, I guess it was either not tested
> > > at all, or only tested on a MT7623. The initialization functions seem
> > > designed with the idea that it's ok if some clocks aren't present, so
> > > stopping the initialization when one of them isn't present seems
> > > wrong. (For example, there is also a MT7622B variant of the MT7622
> > > which probably also lacks some clocks MT7622(A) does have).
> >
> > I don't think the patch for init_clks() is flawed.
> > At most it is incompleted.
> > What it did is like fixing a potential error in the tool platform
> > providing service for the upper application, like what you said,
> > MT7623 and MT7622.
> > We should not keep the error in the platform because of the upper
> > application.
> > And it seems like it is MT7622 that is flawed.
> > The better way is to fix both the bug in init_clks() and its caller,
> > MT7622.
>
> I agree that further cleaning is needed here.
> Yet the commit in it's current form very obviously breaks at least the
> MT7622 platform if no further fixes are applied.
>
> Imho the whole approach of this driver to hard-code the names of all
> clocks it could try to grab in a string-array accompanied by an enum
> is flawed.
>
> The correct approach would likely be to add the clocks actually present
> to the device tree of each SoC and then grab only those.
>
> I can see that mt2701.dtsi and mt7623.dtsi both have some clocks
> defined for scpsys, mt7622.dtsi however lacks them.
> I didn't check other MediaTek SoCs which also use scpsys.

re-add me to discussion :)

have not yet tested mt7623 without the revert i applied for mt7622. will do this later

regards Frank

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Aw: Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Frank Wunderlich]

> Gesendet: Dienstag, 01. Februar 2022 um 23:19 Uhr
> Von: "Daniel Golle" <daniel@makrotopia.org>
> An: "Jiasheng Jiang" <jiasheng@iscas.ac.cn>
> Cc: justinkb@gmail.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, lgirdwood@gmail.com, broonie@kernel.org, linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
> Betreff: Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer
>
> On Sun, Jan 30, 2022 at 10:43:35AM +0800, Jiasheng Jiang wrote:
> > On Fri, Jan 28, 2022 at 10:26:51PM +0800, Paul Mulders wrote:
> > > I guess this breaks all MT7622 SoCs since it'll prematurely exit
> > > init_clks (and subsequently init_scp) completely once devm_clk_get
> > > fails to get a reference to the mm clock producer (which happens to be
> > > the first one tried). This is because MT7623 has a GPU (so no mm
> > > clock) and MT7622 doesn't, and as a result the other clock producer
> > > pointers never get initialized (and other stuff in init_scp after
> > > returning from the error never happens).
> > >
> > > The patch seems fundamentally flawed, I guess it was either not tested
> > > at all, or only tested on a MT7623. The initialization functions seem
> > > designed with the idea that it's ok if some clocks aren't present, so
> > > stopping the initialization when one of them isn't present seems
> > > wrong. (For example, there is also a MT7622B variant of the MT7622
> > > which probably also lacks some clocks MT7622(A) does have).
> >
> > I don't think the patch for init_clks() is flawed.
> > At most it is incompleted.
> > What it did is like fixing a potential error in the tool platform
> > providing service for the upper application, like what you said,
> > MT7623 and MT7622.
> > We should not keep the error in the platform because of the upper
> > application.
> > And it seems like it is MT7622 that is flawed.
> > The better way is to fix both the bug in init_clks() and its caller,
> > MT7622.
>
> I agree that further cleaning is needed here.
> Yet the commit in it's current form very obviously breaks at least the
> MT7622 platform if no further fixes are applied.
>
> Imho the whole approach of this driver to hard-code the names of all
> clocks it could try to grab in a string-array accompanied by an enum
> is flawed.
>
> The correct approach would likely be to add the clocks actually present
> to the device tree of each SoC and then grab only those.
>
> I can see that mt2701.dtsi and mt7623.dtsi both have some clocks
> defined for scpsys, mt7622.dtsi however lacks them.
> I didn't check other MediaTek SoCs which also use scpsys.

re-add me to discussion :)

have not yet tested mt7623 without the revert i applied for mt7622. will do this later

regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Guenter Roeck]

On Fri, Jan 28, 2022 at 10:51:20AM +0100, Frank Wunderlich wrote:
> Hi,
> 
> this commit is merged in 5.17-rc1 and breaks scpsys on mt7622/bananapi R64
> 
> mtk-scpsys: probe of 10006000.power-controller failed with error -2
> 
> at least ethernet is affected (i guess usb,sata,btif,... too, but not checked), as gmacs do not get probed as depency of it
> 
> after reverting this commit it is working again.
> 
> have not yet digged deeper into it why it is failing, but maybe author has an idea
> 

I created a revert of the problematic patch with some explanation.

https://lore.kernel.org/lkml/20220205014755.699603-1-linux@roeck-us.net/

Sorry that I didn't reference this discussion; I only noticed it after
I wrote the revert. The revert and my analysis is based on the impact
of this patch on affected Chromebooks.

The revert is queued for v4.19.y and later stable releases because
the patch discussed here made it into all those releases and breaks
pretty much all Mediatek based systems using the affected driver.

Guenter

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Guenter Roeck]

On Fri, Jan 28, 2022 at 10:51:20AM +0100, Frank Wunderlich wrote:
> Hi,
> 
> this commit is merged in 5.17-rc1 and breaks scpsys on mt7622/bananapi R64
> 
> mtk-scpsys: probe of 10006000.power-controller failed with error -2
> 
> at least ethernet is affected (i guess usb,sata,btif,... too, but not checked), as gmacs do not get probed as depency of it
> 
> after reverting this commit it is working again.
> 
> have not yet digged deeper into it why it is failing, but maybe author has an idea
> 

I created a revert of the problematic patch with some explanation.

https://lore.kernel.org/lkml/20220205014755.699603-1-linux@roeck-us.net/

Sorry that I didn't reference this discussion; I only noticed it after
I wrote the revert. The revert and my analysis is based on the impact
of this patch on affected Chromebooks.

The revert is queued for v4.19.y and later stable releases because
the patch discussed here made it into all those releases and breaks
pretty much all Mediatek based systems using the affected driver.

Guenter

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Guenter Roeck]

On Fri, Jan 28, 2022 at 10:51:20AM +0100, Frank Wunderlich wrote:
> Hi,
> 
> this commit is merged in 5.17-rc1 and breaks scpsys on mt7622/bananapi R64
> 
> mtk-scpsys: probe of 10006000.power-controller failed with error -2
> 
> at least ethernet is affected (i guess usb,sata,btif,... too, but not checked), as gmacs do not get probed as depency of it
> 
> after reverting this commit it is working again.
> 
> have not yet digged deeper into it why it is failing, but maybe author has an idea
> 

I created a revert of the problematic patch with some explanation.

https://lore.kernel.org/lkml/20220205014755.699603-1-linux@roeck-us.net/

Sorry that I didn't reference this discussion; I only noticed it after
I wrote the revert. The revert and my analysis is based on the impact
of this patch on affected Chromebooks.

The revert is queued for v4.19.y and later stable releases because
the patch discussed here made it into all those releases and breaks
pretty much all Mediatek based systems using the affected driver.

Guenter

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Paul Mulders]

Correction: the "(so no mm block)" should be after "and MT7622
doesn't", not before.

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Paul Mulders]

Correction: the "(so no mm block)" should be after "and MT7622
doesn't", not before.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Paul Mulders]

I guess this breaks all MT7622 SoCs since it'll prematurely exit
init_clks (and subsequently init_scp) completely once devm_clk_get
fails to get a reference to the mm clock producer (which happens to be
the first one tried). This is because MT7623 has a GPU (so no mm
clock) and MT7622 doesn't, and as a result the other clock producer
pointers never get initialized (and other stuff in init_scp after
returning from the error never happens).

The patch seems fundamentally flawed, I guess it was either not tested
at all, or only tested on a MT7623. The initialization functions seem
designed with the idea that it's ok if some clocks aren't present, so
stopping the initialization when one of them isn't present seems
wrong. (For example, there is also a MT7622B variant of the MT7622
which probably also lacks some clocks MT7622(A) does have).

Re: BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Paul Mulders]

I guess this breaks all MT7622 SoCs since it'll prematurely exit
init_clks (and subsequently init_scp) completely once devm_clk_get
fails to get a reference to the mm clock producer (which happens to be
the first one tried). This is because MT7623 has a GPU (so no mm
clock) and MT7622 doesn't, and as a result the other clock producer
pointers never get initialized (and other stuff in init_scp after
returning from the error never happens).

The patch seems fundamentally flawed, I guess it was either not tested
at all, or only tested on a MT7623. The initialization functions seem
designed with the idea that it's ok if some clocks aren't present, so
stopping the initialization when one of them isn't present seems
wrong. (For example, there is also a MT7622B variant of the MT7622
which probably also lacks some clocks MT7622(A) does have).

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Frank Wunderlich]

Hi,

this commit is merged in 5.17-rc1 and breaks scpsys on mt7622/bananapi R64

mtk-scpsys: probe of 10006000.power-controller failed with error -2

at least ethernet is affected (i guess usb,sata,btif,... too, but not checked), as gmacs do not get probed as depency of it

after reverting this commit it is working again.

have not yet digged deeper into it why it is failing, but maybe author has an idea

regards Frank

> Gesendet: Mittwoch, 22. Dezember 2021 um 02:51 Uhr
> Von: "Jiasheng Jiang" <jiasheng@iscas.ac.cn>
> An: matthias.bgg@gmail.com, lgirdwood@gmail.com, broonie@kernel.org
> Cc: linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, "Jiasheng Jiang" <jiasheng@iscas.ac.cn>
> Betreff: [PATCH v2] isoc: mediatek: Check for error clk pointer
>
> On Wed, Dec 22, 2021 at 01:57:15AM +0800, Mark Brown wrote:
> >> +	for (i = CLK_NONE + 1; i < CLK_MAX; i++) {
> >>  		clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
> >> +		if (IS_ERR(clk[i]))
> >> +			return PTR_ERR(clk[i]);
> >
> > This now pays attention to the error code here which is good but...
> >
> >> -	init_clks(pdev, clk);
> >> +	ret = init_clks(pdev, clk);
> >> +	if (ret)
> >> +		return ERR_PTR(-ENOMEM);
> >
> > ...then discards it here with a random most likely inappropriate error
> > code.
>
> Yes, you are right and now the return code depending on the
> init_clks().
>
> Fixes: 6078c651947a ("soc: mediatek: Refine scpsys to support multiple platform")
> Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
> ---
> Changelog:
>
> v1 -> v2
>
> *Change 1. Change the return code.
> ---
>  drivers/soc/mediatek/mtk-scpsys.c | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index ca75b14931ec..670cc82d17dc 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -411,12 +411,17 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
>  	return ret;
>  }
>
> -static void init_clks(struct platform_device *pdev, struct clk **clk)
> +static int init_clks(struct platform_device *pdev, struct clk **clk)
>  {
>  	int i;
>
> -	for (i = CLK_NONE + 1; i < CLK_MAX; i++)
> +	for (i = CLK_NONE + 1; i < CLK_MAX; i++) {
>  		clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
> +		if (IS_ERR(clk[i]))
> +			return PTR_ERR(clk[i]);
> +	}
> +
> +	return 0;
>  }
>
>  static struct scp *init_scp(struct platform_device *pdev,
> @@ -426,7 +431,7 @@ static struct scp *init_scp(struct platform_device *pdev,
>  {
>  	struct genpd_onecell_data *pd_data;
>  	struct resource *res;
> -	int i, j;
> +	int i, j, ret;
>  	struct scp *scp;
>  	struct clk *clk[CLK_MAX];
>
> @@ -481,7 +486,9 @@ static struct scp *init_scp(struct platform_device *pdev,
>
>  	pd_data->num_domains = num;
>
> -	init_clks(pdev, clk);
> +	ret = init_clks(pdev, clk);
> +	if (ret)
> +		return ERR_PTR(ret);
>
>  	for (i = 0; i < num; i++) {
>  		struct scp_domain *scpd = &scp->domains[i];
> --
> 2.25.1
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>

BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Frank Wunderlich]

Hi,

this commit is merged in 5.17-rc1 and breaks scpsys on mt7622/bananapi R64

mtk-scpsys: probe of 10006000.power-controller failed with error -2

at least ethernet is affected (i guess usb,sata,btif,... too, but not checked), as gmacs do not get probed as depency of it

after reverting this commit it is working again.

have not yet digged deeper into it why it is failing, but maybe author has an idea

regards Frank

> Gesendet: Mittwoch, 22. Dezember 2021 um 02:51 Uhr
> Von: "Jiasheng Jiang" <jiasheng@iscas.ac.cn>
> An: matthias.bgg@gmail.com, lgirdwood@gmail.com, broonie@kernel.org
> Cc: linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, "Jiasheng Jiang" <jiasheng@iscas.ac.cn>
> Betreff: [PATCH v2] isoc: mediatek: Check for error clk pointer
>
> On Wed, Dec 22, 2021 at 01:57:15AM +0800, Mark Brown wrote:
> >> +	for (i = CLK_NONE + 1; i < CLK_MAX; i++) {
> >>  		clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
> >> +		if (IS_ERR(clk[i]))
> >> +			return PTR_ERR(clk[i]);
> >
> > This now pays attention to the error code here which is good but...
> >
> >> -	init_clks(pdev, clk);
> >> +	ret = init_clks(pdev, clk);
> >> +	if (ret)
> >> +		return ERR_PTR(-ENOMEM);
> >
> > ...then discards it here with a random most likely inappropriate error
> > code.
>
> Yes, you are right and now the return code depending on the
> init_clks().
>
> Fixes: 6078c651947a ("soc: mediatek: Refine scpsys to support multiple platform")
> Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
> ---
> Changelog:
>
> v1 -> v2
>
> *Change 1. Change the return code.
> ---
>  drivers/soc/mediatek/mtk-scpsys.c | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index ca75b14931ec..670cc82d17dc 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -411,12 +411,17 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
>  	return ret;
>  }
>
> -static void init_clks(struct platform_device *pdev, struct clk **clk)
> +static int init_clks(struct platform_device *pdev, struct clk **clk)
>  {
>  	int i;
>
> -	for (i = CLK_NONE + 1; i < CLK_MAX; i++)
> +	for (i = CLK_NONE + 1; i < CLK_MAX; i++) {
>  		clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
> +		if (IS_ERR(clk[i]))
> +			return PTR_ERR(clk[i]);
> +	}
> +
> +	return 0;
>  }
>
>  static struct scp *init_scp(struct platform_device *pdev,
> @@ -426,7 +431,7 @@ static struct scp *init_scp(struct platform_device *pdev,
>  {
>  	struct genpd_onecell_data *pd_data;
>  	struct resource *res;
> -	int i, j;
> +	int i, j, ret;
>  	struct scp *scp;
>  	struct clk *clk[CLK_MAX];
>
> @@ -481,7 +486,9 @@ static struct scp *init_scp(struct platform_device *pdev,
>
>  	pd_data->num_domains = num;
>
> -	init_clks(pdev, clk);
> +	ret = init_clks(pdev, clk);
> +	if (ret)
> +		return ERR_PTR(ret);
>
>  	for (i = 0; i < num; i++) {
>  		struct scp_domain *scpd = &scp->domains[i];
> --
> 2.25.1
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

BUG: [PATCH v2] isoc: mediatek: Check for error clk pointer

[Frank Wunderlich]

Hi,

this commit is merged in 5.17-rc1 and breaks scpsys on mt7622/bananapi R64

mtk-scpsys: probe of 10006000.power-controller failed with error -2

at least ethernet is affected (i guess usb,sata,btif,... too, but not checked), as gmacs do not get probed as depency of it

after reverting this commit it is working again.

have not yet digged deeper into it why it is failing, but maybe author has an idea

regards Frank

> Gesendet: Mittwoch, 22. Dezember 2021 um 02:51 Uhr
> Von: "Jiasheng Jiang" <jiasheng@iscas.ac.cn>
> An: matthias.bgg@gmail.com, lgirdwood@gmail.com, broonie@kernel.org
> Cc: linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, "Jiasheng Jiang" <jiasheng@iscas.ac.cn>
> Betreff: [PATCH v2] isoc: mediatek: Check for error clk pointer
>
> On Wed, Dec 22, 2021 at 01:57:15AM +0800, Mark Brown wrote:
> >> +	for (i = CLK_NONE + 1; i < CLK_MAX; i++) {
> >>  		clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
> >> +		if (IS_ERR(clk[i]))
> >> +			return PTR_ERR(clk[i]);
> >
> > This now pays attention to the error code here which is good but...
> >
> >> -	init_clks(pdev, clk);
> >> +	ret = init_clks(pdev, clk);
> >> +	if (ret)
> >> +		return ERR_PTR(-ENOMEM);
> >
> > ...then discards it here with a random most likely inappropriate error
> > code.
>
> Yes, you are right and now the return code depending on the
> init_clks().
>
> Fixes: 6078c651947a ("soc: mediatek: Refine scpsys to support multiple platform")
> Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
> ---
> Changelog:
>
> v1 -> v2
>
> *Change 1. Change the return code.
> ---
>  drivers/soc/mediatek/mtk-scpsys.c | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index ca75b14931ec..670cc82d17dc 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -411,12 +411,17 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
>  	return ret;
>  }
>
> -static void init_clks(struct platform_device *pdev, struct clk **clk)
> +static int init_clks(struct platform_device *pdev, struct clk **clk)
>  {
>  	int i;
>
> -	for (i = CLK_NONE + 1; i < CLK_MAX; i++)
> +	for (i = CLK_NONE + 1; i < CLK_MAX; i++) {
>  		clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
> +		if (IS_ERR(clk[i]))
> +			return PTR_ERR(clk[i]);
> +	}
> +
> +	return 0;
>  }
>
>  static struct scp *init_scp(struct platform_device *pdev,
> @@ -426,7 +431,7 @@ static struct scp *init_scp(struct platform_device *pdev,
>  {
>  	struct genpd_onecell_data *pd_data;
>  	struct resource *res;
> -	int i, j;
> +	int i, j, ret;
>  	struct scp *scp;
>  	struct clk *clk[CLK_MAX];
>
> @@ -481,7 +486,9 @@ static struct scp *init_scp(struct platform_device *pdev,
>
>  	pd_data->num_domains = num;
>
> -	init_clks(pdev, clk);
> +	ret = init_clks(pdev, clk);
> +	if (ret)
> +		return ERR_PTR(ret);
>
>  	for (i = 0; i < num; i++) {
>  		struct scp_domain *scpd = &scp->domains[i];
> --
> 2.25.1
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel