All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Romain Perier <romain.perier@collabora.com>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	linux-clk@vger.kernel.org,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Kumar Gala <galak@codeaurora.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 3/4] nvmem: rockchip: add support for RK3368
Date: Mon, 28 Aug 2017 14:42:23 +0200	[thread overview]
Message-ID: <2766234.AhINhDhIBZ@diego> (raw)
In-Reply-To: <20170828121604.15968-4-romain.perier@collabora.com>

Hi Romain,

Am Montag, 28. August 2017, 14:16:03 CEST schrieb Romain Perier:
> This adds the necessary functions and data for handling support on RK3368
> SoCs.

Would need a lot more explanation regarding the special use for
SMC calls for efuse access.


> Signed-off-by: Romain Perier <romain.perier@collabora.com>
> ---
>  .../devicetree/bindings/nvmem/rockchip-efuse.txt   |  1 +
>  drivers/nvmem/rockchip-efuse.c                     | 80
> ++++++++++++++++++++++ 2 files changed, 81 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt
> b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt index
> 1ff02afdc55a..60bec4782806 100644
> --- a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt
> +++ b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt
> @@ -6,6 +6,7 @@ Required properties:
>    - "rockchip,rk3188-efuse" - for RK3188 SoCs.
>    - "rockchip,rk3228-efuse" - for RK3228 SoCs.
>    - "rockchip,rk3288-efuse" - for RK3288 SoCs.
> +  - "rockchip,rk3368-efuse" - for RK3368 SoCs.
>    - "rockchip,rk3399-efuse" - for RK3399 SoCs.
>  - reg: Should contain the registers location and exact eFuse size
>  - clocks: Should be the clock id of eFuse
> diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c
> index 63e3eb55f3ac..4e11f251035f 100644
> --- a/drivers/nvmem/rockchip-efuse.c
> +++ b/drivers/nvmem/rockchip-efuse.c
> @@ -14,6 +14,7 @@
>   * more details.
>   */
> 
> +#include <linux/arm-smccc.h>
>  #include <linux/clk.h>
>  #include <linux/delay.h>
>  #include <linux/device.h>
> @@ -46,9 +47,17 @@
>  #define REG_EFUSE_CTRL		0x0000
>  #define REG_EFUSE_DOUT		0x0004
> 
> +/* SMC function IDs for SiP Service queries */
> +#define ROCKCHIP_SIP_ACCESS_REG	0x82000002
> +
> +/* SIP access registers: read or write */
> +#define ROCKCHIP_SIP_SECURE_REG_RD	0x0
> +#define ROCKCHIP_SIP_SECURE_REG_WR	0x1
> +

Going through SMC calls does _not_ look right.

For one even the newest rk3399 can handle its efuse using
regular means, so the rk3368 being  somehow special feels strange.

And even if that is a sanctioned approach, the smc calls are not
part of the upstream arm-trusted-firmware at this moment
and we definitly don't want to codify private unreviewed
interfaces between the mainline kernel and firmware.

See empty smc calls for rk3368 on [0] and used smc-calls on the rk3399
in [1] and I also didn't see any open pull request for something like this.


Heiko

[0] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/rockchip/rk3368/plat_sip_calls.c
[1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/rockchip/rk3399/plat_sip_calls.c


WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stübner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] nvmem: rockchip: add support for RK3368
Date: Mon, 28 Aug 2017 14:42:23 +0200	[thread overview]
Message-ID: <2766234.AhINhDhIBZ@diego> (raw)
In-Reply-To: <20170828121604.15968-4-romain.perier@collabora.com>

Hi Romain,

Am Montag, 28. August 2017, 14:16:03 CEST schrieb Romain Perier:
> This adds the necessary functions and data for handling support on RK3368
> SoCs.

Would need a lot more explanation regarding the special use for
SMC calls for efuse access.


> Signed-off-by: Romain Perier <romain.perier@collabora.com>
> ---
>  .../devicetree/bindings/nvmem/rockchip-efuse.txt   |  1 +
>  drivers/nvmem/rockchip-efuse.c                     | 80
> ++++++++++++++++++++++ 2 files changed, 81 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt
> b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt index
> 1ff02afdc55a..60bec4782806 100644
> --- a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt
> +++ b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt
> @@ -6,6 +6,7 @@ Required properties:
>    - "rockchip,rk3188-efuse" - for RK3188 SoCs.
>    - "rockchip,rk3228-efuse" - for RK3228 SoCs.
>    - "rockchip,rk3288-efuse" - for RK3288 SoCs.
> +  - "rockchip,rk3368-efuse" - for RK3368 SoCs.
>    - "rockchip,rk3399-efuse" - for RK3399 SoCs.
>  - reg: Should contain the registers location and exact eFuse size
>  - clocks: Should be the clock id of eFuse
> diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c
> index 63e3eb55f3ac..4e11f251035f 100644
> --- a/drivers/nvmem/rockchip-efuse.c
> +++ b/drivers/nvmem/rockchip-efuse.c
> @@ -14,6 +14,7 @@
>   * more details.
>   */
> 
> +#include <linux/arm-smccc.h>
>  #include <linux/clk.h>
>  #include <linux/delay.h>
>  #include <linux/device.h>
> @@ -46,9 +47,17 @@
>  #define REG_EFUSE_CTRL		0x0000
>  #define REG_EFUSE_DOUT		0x0004
> 
> +/* SMC function IDs for SiP Service queries */
> +#define ROCKCHIP_SIP_ACCESS_REG	0x82000002
> +
> +/* SIP access registers: read or write */
> +#define ROCKCHIP_SIP_SECURE_REG_RD	0x0
> +#define ROCKCHIP_SIP_SECURE_REG_WR	0x1
> +

Going through SMC calls does _not_ look right.

For one even the newest rk3399 can handle its efuse using
regular means, so the rk3368 being  somehow special feels strange.

And even if that is a sanctioned approach, the smc calls are not
part of the upstream arm-trusted-firmware at this moment
and we definitly don't want to codify private unreviewed
interfaces between the mainline kernel and firmware.

See empty smc calls for rk3368 on [0] and used smc-calls on the rk3399
in [1] and I also didn't see any open pull request for something like this.


Heiko

[0] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/rockchip/rk3368/plat_sip_calls.c
[1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/rockchip/rk3399/plat_sip_calls.c

  reply	other threads:[~2017-08-28 12:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-28 12:16 [PATCH 0/4] rockchip: Add efuse support for RK3368 SoCs Romain Perier
2017-08-28 12:16 ` Romain Perier
2017-08-28 12:16 ` Romain Perier
     [not found] ` <20170828121604.15968-1-romain.perier-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2017-08-28 12:16   ` [PATCH 1/4] clk: rockchip: add clock id for PCLK_EFUSE256 of " Romain Perier
2017-08-28 12:16     ` Romain Perier
2017-08-28 12:16     ` Romain Perier
2017-08-28 12:16   ` [PATCH 2/4] clk: rockchip: export clock pclk_efuse_256 for " Romain Perier
2017-08-28 12:16     ` Romain Perier
2017-08-28 12:16     ` Romain Perier
2017-08-28 12:16   ` [PATCH 4/4] arm64: dts: rockchip: add efuse " Romain Perier
2017-08-28 12:16     ` Romain Perier
2017-08-28 12:16     ` Romain Perier
2017-08-28 12:16 ` [PATCH 3/4] nvmem: rockchip: add support for RK3368 Romain Perier
2017-08-28 12:16   ` Romain Perier
2017-08-28 12:42   ` Heiko Stübner [this message]
2017-08-28 12:42     ` Heiko Stübner
     [not found]   ` <20170828121604.15968-4-romain.perier-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2017-08-28 15:12     ` [3/4] " Philipp Tomsich
2017-08-28 15:12       ` Philipp Tomsich
2017-08-28 15:12       ` Philipp Tomsich
2017-09-01 14:32   ` [PATCH 3/4] " Rob Herring
2017-09-01 14:32     ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2766234.AhINhDhIBZ@diego \
    --to=heiko@sntech.de \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=romain.perier@collabora.com \
    --cc=sboyd@codeaurora.org \
    --cc=srinivas.kandagatla@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.