[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0hqzs1GaJ+qs=8DHhe-zK4QSNGJiKn1B9qsp0jcK3pSuQ@mail.gmail.com>
Date: Fri, 31 Jan 2020 11:11:28 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Geert Uytterhoeven <geert+renesas@...der.be>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Gilad Ben-Yossef <gilad@...yossef.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S . Miller" <davem@...emloft.net>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
Felipe Balbi <balbi@...nel.org>,
Alan Stern <stern@...land.harvard.edu>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Mathias Nyman <mathias.nyman@...el.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Chunfeng Yun <chunfeng.yun@...iatek.com>,
Bin Liu <b-liu@...com>, linux-crypto@...r.kernel.org,
Linux PM <linux-pm@...r.kernel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
"open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:"
<linux-usb@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] crypto: ccree - fix debugfs register access while suspended
On Fri, Jan 24, 2020 at 2:30 PM Geert Uytterhoeven
<geert+renesas@...der.be> wrote:
>
> Reading the debugfs files under /sys/kernel/debug/ccree/ can be done by
> the user at any time. On R-Car SoCs, the CCREE device is power-managed
> using a moduile clock, and if this clock is not running, bogus register
> values may be read.
>
> Fix this by filling in the debugfs_regset32.dev field, so debugfs will
> make sure the device is resumed while its registers are being read.
>
> This fixes the bogus values (0x00000260) in the register dumps on R-Car
> H3 ES1.0:
>
> -e6601000.crypto/regs:HOST_IRR = 0x00000260
> -e6601000.crypto/regs:HOST_POWER_DOWN_EN = 0x00000260
> +e6601000.crypto/regs:HOST_IRR = 0x00000038
> +e6601000.crypto/regs:HOST_POWER_DOWN_EN = 0x00000038
> e6601000.crypto/regs:AXIM_MON_ERR = 0x00000000
> e6601000.crypto/regs:DSCRPTR_QUEUE_CONTENT = 0x000002aa
> -e6601000.crypto/regs:HOST_IMR = 0x00000260
> +e6601000.crypto/regs:HOST_IMR = 0x017ffeff
> e6601000.crypto/regs:AXIM_CFG = 0x001f0007
> e6601000.crypto/regs:AXIM_CACHE_PARAMS = 0x00000000
> -e6601000.crypto/regs:GPR_HOST = 0x00000260
> +e6601000.crypto/regs:GPR_HOST = 0x017ffeff
> e6601000.crypto/regs:AXIM_MON_COMP = 0x00000000
> -e6601000.crypto/version:SIGNATURE = 0x00000260
> -e6601000.crypto/version:VERSION = 0x00000260
> +e6601000.crypto/version:SIGNATURE = 0xdcc63000
> +e6601000.crypto/version:VERSION = 0xaf400001
>
> Note that this behavior is system-dependent, and the issue does not show
> up on all R-Car Gen3 SoCs and boards. Even when the device is
> suspended, the module clock may be left enabled, if configured by the
> firmware for Secure Mode, or when controlled by the Real-Time Core.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
LGTM:
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> ---
> drivers/crypto/ccree/cc_debugfs.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/crypto/ccree/cc_debugfs.c b/drivers/crypto/ccree/cc_debugfs.c
> index 5669997386988055..35f3a2137502bd96 100644
> --- a/drivers/crypto/ccree/cc_debugfs.c
> +++ b/drivers/crypto/ccree/cc_debugfs.c
> @@ -81,6 +81,7 @@ int cc_debugfs_init(struct cc_drvdata *drvdata)
> regset->regs = debug_regs;
> regset->nregs = ARRAY_SIZE(debug_regs);
> regset->base = drvdata->cc_base;
> + regset->dev = dev;
>
> ctx->dir = debugfs_create_dir(drvdata->plat_dev->name, cc_debugfs_dir);
>
> @@ -102,6 +103,7 @@ int cc_debugfs_init(struct cc_drvdata *drvdata)
> verset->nregs = ARRAY_SIZE(pid_cid_regs);
> }
> verset->base = drvdata->cc_base;
> + verset->dev = dev;
>
> debugfs_create_regset32("version", 0400, ctx->dir, verset);
>
> --
> 2.17.1
>
Powered by blists - more mailing lists