[PATCH 0/4] nvmem: meson: efuse updates

[PATCH 0/4] nvmem: meson: efuse updates

[Jerome Brunet]

The first change of this patchset just adds add error message in case
of failure. If there is problem with the secure monitor, the
SM_EFUSE_USER_MAX call will be first one to fail so it is better if it
give us a clue to help debugging, instead af silently failing.

Next this series adds the peripheral clock missing in this driver.
Like many other device in amlogic's SoC, the efuse requires a
peripheral clock to operate. ATM, the clock controller has
CLK_IGNORE_UNUSED on this clock and we have been lucky enough that the
bootloader left the clock enabled

At some point, we would like to remove those CLK_IGNORE_UNUSED, so if a
driver needs a clock, it needs to properly claim it.

Srinivas, Kevin,
The dts change needs to land before the actual driver change, to avoid
breaking the efuse on our users. If there an agreement on this series,
Kevin could you provide a tag to Srinivas ?

Cheers
Jerome

Jerome Brunet (4):
  nvmem: meson-efuse: add error message on user_max failure.
  nvmem: meson-efuse: bindings: add peripheral clock
  arm64: dts: meson-gx: add efuse pclk
  nvmem: meson-efuse: add peripheral clock

 .../bindings/nvmem/amlogic-efuse.txt          |  3 ++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi   |  4 +++
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi    |  4 +++
 drivers/nvmem/meson-efuse.c                   | 29 ++++++++++++++++++-
 4 files changed, 39 insertions(+), 1 deletion(-)

-- 
2.17.2

[PATCH 1/4] nvmem: meson-efuse: add error message on user_max failure.

[Jerome Brunet]

Add an explicit error message when SM_EFUSE_USER_MAX command fails

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 drivers/nvmem/meson-efuse.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/meson-efuse.c b/drivers/nvmem/meson-efuse.c
index d769840d1e18..40b9df1d030d 100644
--- a/drivers/nvmem/meson-efuse.c
+++ b/drivers/nvmem/meson-efuse.c
@@ -48,8 +48,10 @@ static int meson_efuse_probe(struct platform_device *pdev)
 	struct nvmem_config *econfig;
 	unsigned int size;
 
-	if (meson_sm_call(SM_EFUSE_USER_MAX, &size, 0, 0, 0, 0, 0) < 0)
+	if (meson_sm_call(SM_EFUSE_USER_MAX, &size, 0, 0, 0, 0, 0) < 0) {
+		dev_err(dev, "failed to get max user");
 		return -EINVAL;
+	}
 
 	econfig = devm_kzalloc(dev, sizeof(*econfig), GFP_KERNEL);
 	if (!econfig)
-- 
2.17.2

Re: [PATCH 1/4] nvmem: meson-efuse: add error message on user_max failure.

[Srinivas Kandagatla]

On 30/10/18 10:22, Jerome Brunet wrote:
> Add an explicit error message when SM_EFUSE_USER_MAX command fails
> 
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
>   drivers/nvmem/meson-efuse.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)

Applied to nvmem for-next branch!

thanks,
srini

[PATCH 2/4] nvmem: meson-efuse: bindings: add peripheral clock

[Jerome Brunet]

The efuse found in gx SoC requires a peripheral clock to properly operate.
We have been able to work without it until now because the clock was on by
default, and left on by the CCF. Soon, it will not be the case anymore, so
the device needs to claim the clock it needs

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
index e3298e18de26..2e0723ab3384 100644
--- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
+++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
@@ -2,6 +2,8 @@
 
 Required properties:
 - compatible: should be "amlogic,meson-gxbb-efuse"
+- clocks: phandle to the efuse peripheral clock provided by the
+	  clock controller.
 
 = Data cells =
 Are child nodes of eFuse, bindings of which as described in
@@ -11,6 +13,7 @@ Example:
 
 	efuse: efuse {
 		compatible = "amlogic,meson-gxbb-efuse";
+		clocks = <&clkc CLKID_EFUSE>;
 		#address-cells = <1>;
 		#size-cells = <1>;
 
-- 
2.17.2

Re: [PATCH 2/4] nvmem: meson-efuse: bindings: add peripheral clock

[Srinivas Kandagatla]

On 30/10/18 10:22, Jerome Brunet wrote:
> The efuse found in gx SoC requires a peripheral clock to properly operate.
> We have been able to work without it until now because the clock was on by
> default, and left on by the CCF. Soon, it will not be the case anymore, so
> the device needs to claim the clock it needs
> 
> Signed-off-by: Jerome Brunet<jbrunet@baylibre.com>
> ---
>   Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 3 +++
>   1 file changed, 3 insertions(+)

Applied, thanks,

--
Srini

[PATCH 3/4] arm64: dts: meson-gx: add efuse pclk

[Jerome Brunet]

Add the required peripheral clock for the efuse device.

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 1ade7e486828..524f533e41d4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -282,6 +282,10 @@
 	compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc";
 };
 
+&efuse {
+	clocks = <&clkc CLKID_EFUSE>;
+};
+
 &ethmac {
 	clocks = <&clkc CLKID_ETH>,
 		 <&clkc CLKID_FCLK_DIV2>,
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 8f0bb3c44bd6..8ccab9a1ebcc 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -75,6 +75,10 @@
 	};
 };
 
+&efuse {
+	clocks = <&clkc CLKID_EFUSE>;
+};
+
 &ethmac {
 	reg = <0x0 0xc9410000 0x0 0x10000
 	       0x0 0xc8834540 0x0 0x4>;
-- 
2.17.2

[PATCH 4/4] nvmem: meson-efuse: add peripheral clock

[Jerome Brunet]

Get and enable the peripheral clock required by the efuse device.
The driver has been handle to work without it so far because the
clock was left enabled by default but it won't be the case soon.

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
 drivers/nvmem/meson-efuse.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/nvmem/meson-efuse.c b/drivers/nvmem/meson-efuse.c
index 40b9df1d030d..99372768446b 100644
--- a/drivers/nvmem/meson-efuse.c
+++ b/drivers/nvmem/meson-efuse.c
@@ -14,6 +14,7 @@
  * more details.
  */
 
+#include <linux/clk.h>
 #include <linux/module.h>
 #include <linux/nvmem-provider.h>
 #include <linux/of.h>
@@ -46,7 +47,31 @@ static int meson_efuse_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct nvmem_device *nvmem;
 	struct nvmem_config *econfig;
+	struct clk *clk;
 	unsigned int size;
+	int ret;
+
+	clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to get efuse gate");
+		return ret;
+	}
+
+	ret = clk_prepare_enable(clk);
+	if (ret) {
+		dev_err(dev, "failed to enable gate");
+		return ret;
+	}
+
+	ret = devm_add_action_or_reset(dev,
+				       (void(*)(void *))clk_disable_unprepare,
+				       clk);
+	if (ret) {
+		dev_err(dev, "failed to add disable callback");
+		return ret;
+	}
 
 	if (meson_sm_call(SM_EFUSE_USER_MAX, &size, 0, 0, 0, 0, 0) < 0) {
 		dev_err(dev, "failed to get max user");
-- 
2.17.2

Re: [PATCH 4/4] nvmem: meson-efuse: add peripheral clock

[Srinivas Kandagatla]

On 30/10/18 10:22, Jerome Brunet wrote:
> Get and enable the peripheral clock required by the efuse device.
> The driver has been handle to work without it so far because the
> clock was left enabled by default but it won't be the case soon.
> 
> Signed-off-by: Jerome Brunet<jbrunet@baylibre.com>
> ---
>   drivers/nvmem/meson-efuse.c | 25 +++++++++++++++++++++++++
>   1 file changed, 25 insertions(+)

Applied, thanks,

--
Srini

Re: [PATCH 0/4] nvmem: meson: efuse updates

[Srinivas Kandagatla]

On 30/10/18 10:22, Jerome Brunet wrote:
> The first change of this patchset just adds add error message in case
> of failure. If there is problem with the secure monitor, the
> SM_EFUSE_USER_MAX call will be first one to fail so it is better if it
> give us a clue to help debugging, instead af silently failing.
> 
> Next this series adds the peripheral clock missing in this driver.
> Like many other device in amlogic's SoC, the efuse requires a
> peripheral clock to operate. ATM, the clock controller has
> CLK_IGNORE_UNUSED on this clock and we have been lucky enough that the
> bootloader left the clock enabled
> 
> At some point, we would like to remove those CLK_IGNORE_UNUSED, so if a
> driver needs a clock, it needs to properly claim it.
> 
> Srinivas, Kevin,
> The dts change needs to land before the actual driver change, to avoid
> breaking the efuse on our users. If there an agreement on this series,
> Kevin could you provide a tag to Srinivas ?

These are not fixes to any bugs/regressions, so its new material which 
can only go in next dev cycle!

I guess that should also address the patch sequencing issue!

Also I need ack from dt-maintaners on clk bindings to pick patch 2 and 4.

thanks,
srini

> 
> Cheers
> Jerome

Re: [PATCH 0/4] nvmem: meson: efuse updates

[jbrunet]

On Mon, 2018-11-12 at 13:08 +0000, Srinivas Kandagatla wrote:
> 
> On 30/10/18 10:22, Jerome Brunet wrote:
> > The first change of this patchset just adds add error message in case
> > of failure. If there is problem with the secure monitor, the
> > SM_EFUSE_USER_MAX call will be first one to fail so it is better if it
> > give us a clue to help debugging, instead af silently failing.
> > 
> > Next this series adds the peripheral clock missing in this driver.
> > Like many other device in amlogic's SoC, the efuse requires a
> > peripheral clock to operate. ATM, the clock controller has
> > CLK_IGNORE_UNUSED on this clock and we have been lucky enough that the
> > bootloader left the clock enabled
> > 
> > At some point, we would like to remove those CLK_IGNORE_UNUSED, so if a
> > driver needs a clock, it needs to properly claim it.
> > 
> > Srinivas, Kevin,
> > The dts change needs to land before the actual driver change, to avoid
> > breaking the efuse on our users. If there an agreement on this series,
> > Kevin could you provide a tag to Srinivas ?
> 
> These are not fixes to any bugs/regressions, so its new material which 
> can only go in next dev cycle!
> 

It is not fixing a regression, indeed. It fixing a problem in the driver
itself, I think I described this above.

I don't expect this to go a fixes for 4.20. I was targeting next.

> I guess that should also address the patch sequencing issue!

Same issue still applies. If there is an agreement on this series, Patch 3
must land before patch 4 to avoid any problems for our users. I mentionning it
because patch 3 is supposed to go through Kevin's tree, while the rest go
through yours

> 
> Also I need ack from dt-maintaners on clk bindings to pick patch 2 and 4.

I understand for patch 2, but don't really get it for patch 4 ?

> 
> thanks,
> srini
> 
> > Cheers
> > Jerome

Re: [PATCH 0/4] nvmem: meson: efuse updates

[Srinivas Kandagatla]

On 12/11/18 13:28, jbrunet@baylibre.com wrote:
>> Also I need ack from dt-maintaners on clk bindings to pick patch 2 and 4.
> I understand for patch 2, but don't really get it for patch 4 ?
Patch 2 is bindings which what I need ack from DT maintainers.
Patch 4 is driver changes related to patch 2, am okay with the changes!

So it makes sense for patch 2 & 4 to go together.
Once I get ack for 2, I can take 2 & 4 both.

thanks,
srini
>