Date   

Re: [PATCH 5.10.y-cip 32/39] dt-bindings: Drop redundant minItems/maxItems

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 31 March 2022 11:22
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [PATCH 5.10.y-cip 32/39] dt-bindings: Drop redundant
minItems/maxItems

Hi!

This condition is partially checked with the meta-schema already, but
only if both 'minItems' and 'maxItems' are equal to the 'items' length.
An improved meta-schema is pending.
Do we have the improved meta-scheme in 5.10.X? Are we actually running the
dts schema checks?
Right 5.10.x will use older schemas. Let me know your thoughts If you want me to drop this patch.

I guess it is not a big deal either way.
Im hoping you are ok with this change.

Cheers,
Prabhakar

Best regards,
Pavel

+++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
@@ -74,7 +74,6 @@ properties:

clock-names:
minItems: 1
- maxItems: 2
items:
- const: core
- const: cd
@@ -106,7 +105,6 @@ properties:

pinctrl-names:
minItems: 1
- maxItems: 2
items:
- const: default
- const: state_uhs
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 21/39] mmc: renesas_sdhi: do hard reset if possible

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 31 March 2022 11:20
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [PATCH 5.10.y-cip 21/39] mmc: renesas_sdhi: do hard reset if
possible

Hi!

commit b4d86f37eacb724690d0d300576b82806bc743d5 upstream.

All recent SDHI instances can be reset via the reset controller. If
one is found, use it instead of the open coded reset. This is to get a
future-proof sane reset state.
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -1086,6 +1097,10 @@ int renesas_sdhi_probe(struct platform_device
*pdev,
if (ret)
goto efree;

+ priv->rstc = devm_reset_control_get_optional_exclusive(&pdev->dev,
NULL);
+ if (IS_ERR(priv->rstc))
+ return PTR_ERR(priv->rstc);
+
I believe this needs to goto to appropriate error path, not return
directly.
Yes you are right this needs to land into appropriate error path.

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 15/39] mmc: renesas_sdhi: Add a condition of cmd/data timeout for retune

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 31 March 2022 11:19
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [PATCH 5.10.y-cip 15/39] mmc: renesas_sdhi: Add a condition
of cmd/data timeout for retune

Hi!

commit ed2fab9a8229cc70fe03032e48d0ec375df6013e upstream.

According to the datasheet, this controller needs retune when cmd or
data timeout happens. So, add a condition into .check_retune().
@@ -790,11 +792,19 @@ static bool renesas_sdhi_check_scc_error(struct
tmio_mmc_host *host)
if (mmc_doing_tune(host->mmc))
return false;

+ if (((mrq->cmd->error == -ETIMEDOUT) ||
+ (mrq->data && mrq->data->error == -ETIMEDOUT)) &&
+ ((host->mmc->caps & MMC_CAP_NONREMOVABLE) ||
+ (host->ops.get_cd && host->ops.get_cd(host->mmc))))
+ ret |= true;
I'd preffer simple "ret = true" here.
Agreed.

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 13/39] mmc: renesas_internal_dmac: add pre_req and post_req support

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 31 March 2022 11:16
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [PATCH 5.10.y-cip 13/39] mmc: renesas_internal_dmac: add
pre_req and post_req support

Hi!

commit 69e7d76afdb54243df957351804c0f1afca46d0f upstream.

Add pre_req and post_req support to improve performance.

Inspired by a patch in the BSP by Masaharu Hayakawa.
+/*
+ * renesas_sdhi_internal_dmac_map() will be called with two difference
"two different"?
Agreed.

+ /* This DMAC cannot handle if buffer is not 128-bytes alignment */
"aligned"?
Ditto.

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 09/39] mmc: renesas_sdhi: sort includes

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 31 March 2022 11:15
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [PATCH 5.10.y-cip 09/39] mmc: renesas_sdhi: sort includes

Hi!

From: Wolfram Sang <wsa+renesas@...>

commit ab07a1356043f07142ba351253904ef8c42ecd4f upstream.

Better prevent double includes.
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -18,22 +18,22 @@
*
*/

-#include <linux/kernel.h>
#include <linux/clk.h>
-#include <linux/slab.h>
-#include <linux/module.h>
-#include <linux/of_device.h>
-#include <linux/platform_device.h>
-#include <linux/pm_domain.h>
+#include <linux/delay.h>
+#include <linux/kernel.h>
+#include <linux/mfd/tmio.h>
#include <linux/mmc/host.h>
#include <linux/mmc/mmc.h>
#include <linux/mmc/slot-gpio.h>
-#include <linux/mfd/tmio.h>
-#include <linux/sh_dma.h>
-#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
#include <linux/pinctrl/consumer.h>
#include <linux/pinctrl/pinctrl-state.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
#include <linux/regulator/consumer.h>
+#include <linux/sh_dma.h>
+#include <linux/slab.h>
#include <linux/sys_soc.h>

#include "renesas_sdhi.h"
In these cases we usually sort be include length, first ("reverse xmass
tree").
My understating was most subsystems prefer alphabetical.

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 04/39] mmc: renesas_sdhi: clear TAPEN when resetting, too

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 31 March 2022 11:14
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [PATCH 5.10.y-cip 04/39] mmc: renesas_sdhi: clear TAPEN when
resetting, too

Hi!

From: Wolfram Sang <wsa+renesas@...>

commit 183edc060e6969a3afe83f663b534f6324fb7e3a upstream.

We want to clear TAPEN in a software reset, too, to have a completely
known state. Especially when we doing the initial reset during boot to
clear previous firmware states.
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -558,7 +558,7 @@ static void renesas_sdhi_reset(struct tmio_mmc_host
*host)
struct renesas_sdhi *priv = host_to_priv(host);

if (priv->scc_ctl) {
- renesas_sdhi_reset_scc(host, priv);
+ renesas_sdhi_disable_scc(host->mmc);
renesas_sdhi_reset_hs400_mode(host, priv);
priv->needs_adjust_hs400 = false;
Having half of functions receive host, priv pointers and the other half
receiving host->mmc pointer is not very nice. Is there some logic behind
that / is it possible to somehow fix?
That's because renesas_sdhi_disable_scc() needed only host->mmc pointer.

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 00/39] Add SD/eMMC support for Renesas RZ/G2L SoC

Nobuhiro Iwamatsu
 

Hi all,

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: Thursday, March 31, 2022 9:49 PM
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: Pavel Machek <pavel@...>; cip-dev@...; iwamatsu
nobuhiro(岩松 信洋 □SWC◯ACT)
<nobuhiro1.iwamatsu@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [PATCH 5.10.y-cip 00/39] Add SD/eMMC support for Renesas
RZ/G2L SoC

Hi!

This patch series adds support for SD/eMMC on Renesas RZ/G2L SoC
and enables this interfaces on Renesas RZ/G2L SMARC EVK.

All the patches have been cherry picked from v5.17 release.
I tried to apply the patches on top of 5.10.106-cip4, and could not.
Can you double check series applies properly?
I did cross check my base branch and it is 5.10.106-cip4. For some weird
reason patches 01 to 09 are missing in patchwork. (I can see the patches are in
my inbox though and pretty sure you too have it as have received feedback on
patch 04 and 09).

Do you want me to resend the series hoping patches appear on
patchwork?
I took patches from emails list, not from patchwork, so that should not be it.

Let me try again:

git log
commit 8bb6e30b765989a3c0924158316d689e16317cd1 (HEAD ->
linux-5.10.y-cip, tag: v5.10.106-cip4, origin/l\
inux-5.10.y-cip)
Author: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>
Date: Tue Mar 29 08:32:48 2022 +0900

CIP: Bump version suffix to -cip4 after merge from stable
pavel@duo:~/cip/10$ ./git-am /tmp/delme.zz

pavel@duo:~/cip/10$ ./git-am /tmp/delme.zt
Applying: mmc: renesas_sdhi: probe into TMIO after SCC parameters have
been setup
Applying: mmc: renesas_sdhi: populate SCC pointer at the proper place
Applying: mmc: renesas_sdhi: simplify reset routine a little
error: patch failed: drivers/mmc/host/renesas_sdhi_core.c:569
error: drivers/mmc/host/renesas_sdhi_core.c: patch does not apply Patch
failed at 0003 mmc: renesas_sdhi: simplify reset routine a little
hint: Use 'git am --show-current-patch' to see the failed patch When you have
resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
pavel@duo:~/cip/10$ git am --skip
Applying: mmc: renesas_sdhi: clear TAPEN when resetting, too
error: patch failed: drivers/mmc/host/renesas_sdhi_core.c:558
error: drivers/mmc/host/renesas_sdhi_core.c: patch does not apply Patch
failed at 0004 mmc: renesas_sdhi: clear TAPEN when resetting, too
hint: Use 'git am --show-current-patch' to see the failed patch When you have
resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
pavel@duo:~/cip/10$
pavel@duo:~/cip/10$ git am --skip
Applying: mmc: renesas_sdhi: merge the SCC reset functions
Applying: mmc: renesas_sdhi: remove superfluous SCLKEN
error: patch failed: drivers/mmc/host/renesas_sdhi_core.c:556
error: drivers/mmc/host/renesas_sdhi_core.c: patch does not apply Patch
failed at 0006 mmc: renesas_sdhi: remove superfluous SCLKEN
hint: Use 'git am --show-current-patch' to see the failed patch When you have
resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
pavel@duo:~/cip/10$
I have the same issue.
It seems that patchwork has not been able to catch all the patches.
https://patchwork.kernel.org/project/cip-dev/list/?series=627598
And CIP-dev ML is in the same situation.
https://lore.kernel.org/cip-dev/20220331124910.GA16062@duo.ucw.cz/T/#m5be9be981a6acb372766fc280b7fb27eb5a27527
1 to 10, 18, 23, 26, 27, 32 do not exist.

Best regards,
Nobuhiro


Re: [PATCH 5.10.y-cip 00/39] Add SD/eMMC support for Renesas RZ/G2L SoC

Pavel Machek
 

Hi!

This patch series adds support for SD/eMMC on Renesas RZ/G2L SoC and
enables this interfaces on Renesas RZ/G2L SMARC EVK.

All the patches have been cherry picked from v5.17 release.
I tried to apply the patches on top of 5.10.106-cip4, and could not. Can
you double check series applies properly?
I did cross check my base branch and it is 5.10.106-cip4. For some weird reason patches 01 to 09 are missing in patchwork. (I can see the patches are in my inbox though and pretty sure you too have it as have received feedback on patch 04 and 09).

Do you want me to resend the series hoping patches appear on
patchwork?
I took patches from emails list, not from patchwork, so that should
not be it.

Let me try again:

git log
commit 8bb6e30b765989a3c0924158316d689e16317cd1 (HEAD -> linux-5.10.y-cip, tag: v5.10.106-cip4, origin/l\
inux-5.10.y-cip)
Author: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>
Date: Tue Mar 29 08:32:48 2022 +0900

CIP: Bump version suffix to -cip4 after merge from stable
pavel@duo:~/cip/10$ ./git-am /tmp/delme.zz

pavel@duo:~/cip/10$ ./git-am /tmp/delme.zt
Applying: mmc: renesas_sdhi: probe into TMIO after SCC parameters have been setup
Applying: mmc: renesas_sdhi: populate SCC pointer at the proper place
Applying: mmc: renesas_sdhi: simplify reset routine a little
error: patch failed: drivers/mmc/host/renesas_sdhi_core.c:569
error: drivers/mmc/host/renesas_sdhi_core.c: patch does not apply
Patch failed at 0003 mmc: renesas_sdhi: simplify reset routine a little
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
pavel@duo:~/cip/10$ git am --skip
Applying: mmc: renesas_sdhi: clear TAPEN when resetting, too
error: patch failed: drivers/mmc/host/renesas_sdhi_core.c:558
error: drivers/mmc/host/renesas_sdhi_core.c: patch does not apply
Patch failed at 0004 mmc: renesas_sdhi: clear TAPEN when resetting, too
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
pavel@duo:~/cip/10$
pavel@duo:~/cip/10$ git am --skip
Applying: mmc: renesas_sdhi: merge the SCC reset functions
Applying: mmc: renesas_sdhi: remove superfluous SCLKEN
error: patch failed: drivers/mmc/host/renesas_sdhi_core.c:556
error: drivers/mmc/host/renesas_sdhi_core.c: patch does not apply
Patch failed at 0006 mmc: renesas_sdhi: remove superfluous SCLKEN
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
pavel@duo:~/cip/10$

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 00/39] Add SD/eMMC support for Renesas RZ/G2L SoC

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 31 March 2022 10:28
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [PATCH 5.10.y-cip 00/39] Add SD/eMMC support for Renesas
RZ/G2L SoC

Hi!

This patch series adds support for SD/eMMC on Renesas RZ/G2L SoC and
enables this interfaces on Renesas RZ/G2L SMARC EVK.

All the patches have been cherry picked from v5.17 release.
I tried to apply the patches on top of 5.10.106-cip4, and could not. Can
you double check series applies properly?
I did cross check my base branch and it is 5.10.106-cip4. For some weird reason patches 01 to 09 are missing in patchwork. (I can see the patches are in my inbox though and pretty sure you too have it as have received feedback on patch 04 and 09).

Do you want me to resend the series hoping patches appear on patchwork?

Cheers,
Prabhakar

8bb6e30b765989a3c0924158316d689e16317cd1
CIP: Bump version suffix to -cip4 after merge from stable commit
66f600a7a5460b6acab5272ac9f54f842927a50d
Merge tag 'v5.10.106' into linux-5.10.y-cip

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 32/39] dt-bindings: Drop redundant minItems/maxItems

Pavel Machek
 

Hi!

This condition is partially checked with the meta-schema already, but
only if both 'minItems' and 'maxItems' are equal to the 'items' length.
An improved meta-schema is pending.
Do we have the improved meta-scheme in 5.10.X? Are we actually running
the dts schema checks?

I guess it is not a big deal either way.

Best regards,
Pavel

+++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
@@ -74,7 +74,6 @@ properties:

clock-names:
minItems: 1
- maxItems: 2
items:
- const: core
- const: cd
@@ -106,7 +105,6 @@ properties:

pinctrl-names:
minItems: 1
- maxItems: 2
items:
- const: default
- const: state_uhs
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 21/39] mmc: renesas_sdhi: do hard reset if possible

Pavel Machek
 

Hi!

commit b4d86f37eacb724690d0d300576b82806bc743d5 upstream.

All recent SDHI instances can be reset via the reset controller. If one
is found, use it instead of the open coded reset. This is to get a
future-proof sane reset state.
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -1086,6 +1097,10 @@ int renesas_sdhi_probe(struct platform_device *pdev,
if (ret)
goto efree;

+ priv->rstc = devm_reset_control_get_optional_exclusive(&pdev->dev, NULL);
+ if (IS_ERR(priv->rstc))
+ return PTR_ERR(priv->rstc);
+
I believe this needs to goto to appropriate error path, not return
directly.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 15/39] mmc: renesas_sdhi: Add a condition of cmd/data timeout for retune

Pavel Machek
 

Hi!

commit ed2fab9a8229cc70fe03032e48d0ec375df6013e upstream.

According to the datasheet, this controller needs retune when
cmd or data timeout happens. So, add a condition into
.check_retune().
@@ -790,11 +792,19 @@ static bool renesas_sdhi_check_scc_error(struct tmio_mmc_host *host)
if (mmc_doing_tune(host->mmc))
return false;

+ if (((mrq->cmd->error == -ETIMEDOUT) ||
+ (mrq->data && mrq->data->error == -ETIMEDOUT)) &&
+ ((host->mmc->caps & MMC_CAP_NONREMOVABLE) ||
+ (host->ops.get_cd && host->ops.get_cd(host->mmc))))
+ ret |= true;
I'd preffer simple "ret = true" here.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 13/39] mmc: renesas_internal_dmac: add pre_req and post_req support

Pavel Machek
 

Hi!

commit 69e7d76afdb54243df957351804c0f1afca46d0f upstream.

Add pre_req and post_req support to improve performance.

Inspired by a patch in the BSP by Masaharu Hayakawa.
+/*
+ * renesas_sdhi_internal_dmac_map() will be called with two difference
"two different"?

+ /* This DMAC cannot handle if buffer is not 128-bytes alignment */
"aligned"?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 09/39] mmc: renesas_sdhi: sort includes

Pavel Machek
 

Hi!

From: Wolfram Sang <wsa+renesas@...>

commit ab07a1356043f07142ba351253904ef8c42ecd4f upstream.

Better prevent double includes.
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -18,22 +18,22 @@
*
*/

-#include <linux/kernel.h>
#include <linux/clk.h>
-#include <linux/slab.h>
-#include <linux/module.h>
-#include <linux/of_device.h>
-#include <linux/platform_device.h>
-#include <linux/pm_domain.h>
+#include <linux/delay.h>
+#include <linux/kernel.h>
+#include <linux/mfd/tmio.h>
#include <linux/mmc/host.h>
#include <linux/mmc/mmc.h>
#include <linux/mmc/slot-gpio.h>
-#include <linux/mfd/tmio.h>
-#include <linux/sh_dma.h>
-#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
#include <linux/pinctrl/consumer.h>
#include <linux/pinctrl/pinctrl-state.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
#include <linux/regulator/consumer.h>
+#include <linux/sh_dma.h>
+#include <linux/slab.h>
#include <linux/sys_soc.h>

#include "renesas_sdhi.h"
In these cases we usually sort be include length, first ("reverse
xmass tree").

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 04/39] mmc: renesas_sdhi: clear TAPEN when resetting, too

Pavel Machek
 

Hi!

From: Wolfram Sang <wsa+renesas@...>

commit 183edc060e6969a3afe83f663b534f6324fb7e3a upstream.

We want to clear TAPEN in a software reset, too, to have a completely
known state. Especially when we doing the initial reset during boot to
clear previous firmware states.
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -558,7 +558,7 @@ static void renesas_sdhi_reset(struct tmio_mmc_host *host)
struct renesas_sdhi *priv = host_to_priv(host);

if (priv->scc_ctl) {
- renesas_sdhi_reset_scc(host, priv);
+ renesas_sdhi_disable_scc(host->mmc);
renesas_sdhi_reset_hs400_mode(host, priv);
priv->needs_adjust_hs400 = false;
Having half of functions receive host, priv pointers and the other
half receiving host->mmc pointer is not very nice. Is there some logic
behind that / is it possible to somehow fix?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 00/39] Add SD/eMMC support for Renesas RZ/G2L SoC

Pavel Machek
 

Hi!

This patch series adds support for SD/eMMC on Renesas RZ/G2L SoC and
enables this interfaces on Renesas RZ/G2L SMARC EVK.

All the patches have been cherry picked from v5.17 release.
I tried to apply the patches on top of 5.10.106-cip4, and could
not. Can you double check series applies properly?

8bb6e30b765989a3c0924158316d689e16317cd1
CIP: Bump version suffix to -cip4 after merge from stable
commit 66f600a7a5460b6acab5272ac9f54f842927a50d
Merge tag 'v5.10.106' into linux-5.10.y-cip

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 5.10.y-cip 00/39] Add SD/eMMC support for Renesas RZ/G2L SoC

Pavel Machek
 

Hi!

This patch series adds support for SD/eMMC on Renesas RZ/G2L SoC and
enables this interfaces on Renesas RZ/G2L SMARC EVK.

All the patches have been cherry picked from v5.17 release.
Thanks for the series.

Review did not find anything that would prevent merge, so I'll proceed
with testing. If it tests okay and there are no other comments, I'll
likely apply the patches.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


CIP IRC weekly meeting today on libera.chat

Pavel Machek
 

Hi!

Kindly be reminded to attend the weekly meeting through IRC to discuss
technical topics with CIP kernel today. Our channel is the following:

irc:irc.libera.chat:6667/cip

The IRC meeting is scheduled to UTC (GMT) 13:00. Note that DST status
changed in Europe.

Last meeting minutes:
https://ircbot.wl.linuxfoundation.org/meetings/cip/2022/03/cip.2022-03-24-13.00.log.html

* Action items
1. Resolve/filter irrelevant failures of KernelCI for 4.4-cip -
patersonc & alicefm
* Kernel maintenance updates
* Kernel testing
* AOB

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


New CVE entries this week

Masami Ichikawa
 

Hi !

It's this week's CVE report.

This week reported 6 new CVEs and 4 updated CVEs.

* New CVEs

CVE-2022-0168: smb2_ioctl_query_info NULL Pointer Dereference

CVSS v3 score is not provided

A local DoS issue was found in smb2_ioctl_query_info() . A local user
with privileged (CAP_SYS_ADMIN) can crash the system.
The smb2_ioctl_query_info() was introduced by commit f5b05d6 ("cifs:
add IOCTL for QUERY_INFO passthrough to userspace") which was merged
in 4.20-rc1.

Fixed status

Not fixed yet.

CVE-2022-1055: net: sched: fix use-after-free in tc_new_tfilter()

CVSS v3 score is 6.3 MEDIUM

An UFA bug was found in tc_new_tfilter().
This issue was introduced by commit 470502d ("net: sched: unlock rules
update API") which was merged in 5.1-rc1.
The mainline and stable kernels were fixed.

Fixed status

mainline: [04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5]
stable/5.10: [e7be56926397cf9d992be8913f74a76152f8f08d]
stable/5.15: [f36cacd6c933183c1a8827d5987cf2cfc0a44c76]
stable/5.16: [95e34f61b58a152656cbe8d6e19843cc343fb089]
stable/5.4: [b1d17e920dfcd4b56fa2edced5710c191f7e50b5]

CVE-2022-1048: race condition in snd_pcm_hw_free leading to use-after-free

CVSS v3 score is not provided

An UFA bug was found in the ALSA pcm module. This bug can be the cause
of system crash or privilege escalation by a local user.

Applying patches to 4.4, it needs to be modified.

Fixed status

mainline: [92ee3c60ec9fe64404dc035e7c41277d74aa26cb,
dca947d4d26dbf925a64a6cfb2ddbc035e831a3d,
3c3201f8c7bb77eb53b08a3ca8d9a4ddc500b4c0,
69534c48ba8ce552ce383b3dfdb271ffe51820c3]
stable/5.10: [0f6947f5f5208f6ebd4d76a82a4757e2839a23f8,
8527c8f052fb42091c6569cb928e472376a4a889,
a38440f006974e693f92a1ea10f819eccc4dcc37,
b560d670c87d7d40b3cf6949246fa4c7aa65a00a]
stable/5.15: [33061d0fba51d2bf70a2ef9645f703c33fe8e438,
47711ff10c7e126702cfa725f6d86ef529d15a5f,
cb6a39c5ebd0a125c420c5a10999813daaece019,
51fce708ab8986a9879ee5da946a2cc120f1036d]
stable/5.16: [0090c13cbbdffd7da079ac56f80373a9a1be0bf8,
4d1b0ace2d56dc27cc4921eda7fae57f77f03eb5,
e1ff3a347ed1531eec40a24c47eab15f0efbf835,
a21d2f323b5a978dedf9ff1d50f101f85e39b3f2]
stable/5.17: [1bbf82d9f961414d6c76a08f7f843ea068e0ab7b,
dd2f8c684da3e226e5ec7a81c89ff5fd4a957a03,
e9d05532252ec41d000021d3cf40f3a2084fd5f9,
5ed8f8e3c4e59d0396b9ccf2e639711e24295bb6]

CVE-2022-1015: OOB access bug in netfilter

CVSS v3 score is not provided

This issue leads to local privilege escalation.
This root cause was introduced by commit 49499c3 ("netfilter:
nf_tables: switch registers to 32 bit addressing") which merged in
4.1-rc.
However, it is exploitable by commit 345023b ("netfilter: nftables:
add nft_parse_register_store() and use it") which merged in
5.12-rc1-dontuse.
Therefore, earlier than 5.12 kernels have an OOB bug but they wouldn't
exploit via this bug.

Fixed status

mainline: [6e1acfa387b9ff82cfc7db8cc3b6959221a95851]
stable/5.15: [1bd57dea456149619f3b80d67eee012122325af8]
stable/5.16: [2c8ebdaa7c9755b85d90c07530210e83665bad9a]
stable/5.17: [afdc3f4b81f0ec9f97f0910476af4620a2481a6d]

CVE-2022-1016: kernel information leak bug in netfilter

CVSS v3 score is not provided

There is an uninitialized stack in the nft_do_chain routine that can
lead to kernel information leak.
This bug was introduced by commit 9651851 ("netfilter: add nftables")
that was merged in 3.13-rc1.

For 4.4

Applying commit 4c905f has a merge conflict but is easy to fix.

Fixed status

mainline: [4c905f6740a365464e91467aa50916555b28213d]
stable/4.14: [a3cc32863b175168283cb0a5fde08de6a1e27df9]
stable/4.19: [88791b79a1eb2ba94e95d039243e28433583a67b]
stable/4.9: [4d28522acd1c4415c85f6b33463713a268f68965]
stable/5.10: [2c74374c2e88c7b7992bf808d9f9391f7452f9d9]
stable/5.15: [fafb904156fbb8f1dd34970cd5223e00b47c33be]
stable/5.16: [64f24c76dd0ce53d0fa3a0bfb9aeea507c769485]
stable/5.17: [dd03640529204ef4b8189fbdea08217d8d98271f]
stable/5.4: [06f0ff82c70241a766a811ae1acf07d6e2734dcb]

CVE-2022-27950: memory leak bug in drivers/hid/hid-elo.c

CVSS v3 score is not provided

A memory leak bug was found in elo_probe() in drivers/hid/hid-elo.c
when hid_parse() fails.
This bug was introduced by commit fbf4272 ("HID: elo: update the
reference count of the usb device structure") which was merged in
5.15-rc1. This bug exists between 5.15 to 5.16.11.

Fixed status

mainline: [817b8b9c5396d2b2d92311b46719aad5d3339dbe]
stable/5.15: [de0d102d0c8c681fc9a3263d842fb35f7cf662f4]
stable/5.16: [80dad7483e3940dc9d9d55f8b34d1f4ba85a505e]

* Updated CVEs

CVE-2021-4197: cgroup: Use open-time creds and namespace for migration
perm checks

stable/5.10 was updated this week.

Fixed status

mainline: [1756d7994ad85c2479af6ae5a9750b92324685af,
0d2b5955b36250a9428c832664f2079cbf723bec,
e57457641613fef0d147ede8bd6a3047df588b95]
stable/5.10: [f28364fe384feffbe7d44b095ef4571285465c47,
824a950c3f1118eb06b1877c49ed1b2eca8e236d]
stable/5.15: [c6ebc35298848accb5e50c37fdb2490cf4690c92,
50273128d640e8d21a13aec5f4bbce4802f17d7d,
43fa0b3639c5fd48c96b19d645d0c7ff2327651a]

CVE-2022-27666, CVE-2022-0886: esp: Fix possible buffer overflow in
ESP transformation

stable/4.14, stable/4.19, and stable/5.4 kernels were fixed this week.
All kernels are fixed.

Fixed status

mainline: [ebe48d368e97d007bfeb76fcb065d6cfc4c96645]
stable/4.14: [2c8abafd6c72ef04bc972f40332c76c1dd04446d]
stable/4.19: [ce89087966651ad41e103770efc5ce2742046284]
stable/5.10: [9248694dac20eda06e22d8503364dc9d03df4e2f]
stable/5.15: [4aaabbffc3b0658ce80eebdde9bafa20a3f932e0]
stable/5.16: [9afe83f62aac348db1facb28bfc106109a06e44d]
stable/5.4: [fee4dfbda68ba10f3bbcf51c861d6aa32f08f9e4]

CVE-2022-26490: nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION

stable kernels are fixed this week.

Fixed status

mainline: [4fbcc1a4cb20fe26ad0225679c536c80f1648221]
stable/4.14: [d908d2776464a8021a1f63eba6e7417fbe7653c9]
stable/4.19: [0043b74987acb44f1ade537aad901695511cfebe]
stable/4.9: [c1184fa07428fb81371d5863e09795f0d06d35cf]
stable/5.10: [25c23fe40e6e1ef8e6d503c52b4f518b2e520ab7]
stable/5.15: [a34c47b1ab07153a047476de83581dc822287f39]
stable/5.16: [0646efbb6e100a3f93eba3b6a10a7f4c28dd1478]
stable/5.4: [0aef7184630b599493a0dcad4eec6d42b3e68e91]

Currently tracking CVEs

CVE-2021-31615: Unencrypted Bluetooth Low Energy baseband links in
Bluetooth Core Specifications 4.0 through 5.2

There is no fix information.

CVE-2020-26556: kernel: malleable commitment Bluetooth Mesh Provisioning

No fix information.

CVE-2020-26557: kernel: predictable Authvalue in Bluetooth Mesh
Provisioning Leads to MITM

No fix information.

CVE-2020-26559: kernel: Authvalue leak in Bluetooth Mesh Provisioning

No fix information.

CVE-2020-26560: kernel: impersonation attack in Bluetooth Mesh Provisioning

No fix information.

Regards,
--
Masami Ichikawa
Cybertrust Japan Co., Ltd.

Email :masami.ichikawa@...
:masami.ichikawa@...


[PATCH 5.10.y-cip 39/39] arm64: dts: renesas: rzg2l-smarc: Enable microSD on SMARC platform

Lad Prabhakar
 

From: Biju Das <biju.das.jz@...>

commit 34cdc0edfe8f6d660e3c4c47d10f5506d08f09e1 upstream.

This patch enables microSD card slot connected to SDHI1 on RZ/G2L SMARC
platform.

Signed-off-by: Biju Das <biju.das.jz@...>
Link: https://lore.kernel.org/r/20211010142520.21976-3-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
[PL: Manually applied the changes]
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi | 62 ++++++++++++++++++++
1 file changed, 62 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi b/arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi
index 70aca5d0306d..0cd7da8af1d4 100644
--- a/arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi
@@ -31,6 +31,16 @@
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
};
+
+ vccq_sdhi1: regulator-vccq-sdhi1 {
+ compatible = "regulator-gpio";
+ regulator-name = "SDHI1 VccQ";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&pinctrl RZG2L_GPIO(39, 1) GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <3300000 1>, <1800000 0>;
+ };
};

&canfd {
@@ -149,6 +159,45 @@
<RZG2L_PORT_PINMUX(48, 4, 1)>; /* RTS# */
};

+ sd1-pwr-en-hog {
+ gpio-hog;
+ gpios = <RZG2L_GPIO(39, 2) GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "sd1_pwr_en";
+ };
+
+ sdhi1_pins: sd1 {
+ sd1_data {
+ pins = "SD1_DATA0", "SD1_DATA1", "SD1_DATA2", "SD1_DATA3";
+ power-source = <3300>;
+ };
+
+ sd1_ctrl {
+ pins = "SD1_CLK", "SD1_CMD";
+ power-source = <3300>;
+ };
+
+ sd1_mux {
+ pinmux = <RZG2L_PORT_PINMUX(19, 0, 1)>; /* SD1_CD */
+ };
+ };
+
+ sdhi1_pins_uhs: sd1_uhs {
+ sd1_data_uhs {
+ pins = "SD1_DATA0", "SD1_DATA1", "SD1_DATA2", "SD1_DATA3";
+ power-source = <1800>;
+ };
+
+ sd1_ctrl_uhs {
+ pins = "SD1_CLK", "SD1_CMD";
+ power-source = <1800>;
+ };
+
+ sd1_mux_uhs {
+ pinmux = <RZG2L_PORT_PINMUX(19, 0, 1)>; /* SD1_CD */
+ };
+ };
+
usb0_pins: usb0 {
pinmux = <RZG2L_PORT_PINMUX(4, 0, 1)>, /* VBUS */
<RZG2L_PORT_PINMUX(5, 0, 1)>, /* OVC */
@@ -184,6 +233,19 @@
};
#endif

+&sdhi1 {
+ pinctrl-0 = <&sdhi1_pins>;
+ pinctrl-1 = <&sdhi1_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <&reg_3p3v>;
+ vqmmc-supply = <&vccq_sdhi1>;
+ bus-width = <4>;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+
&usb2_phy0 {
pinctrl-0 = <&usb0_pins>;
pinctrl-names = "default";
--
2.17.1

1361 - 1380 of 9267