[0/4] nvmem: meson: efuse updates

Message

Jerome Brunet Oct. 30, 2018, 10:22 a.m. UTC

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(-)

Comments

Srinivas Kandagatla Nov. 12, 2018, 1:08 p.m. UTC | #1

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

Jerome Brunet Nov. 12, 2018, 1:28 p.m. UTC | #2

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

Srinivas Kandagatla Nov. 12, 2018, 1:34 p.m. UTC | #3

On 12/11/18 13:28, [e-mail] 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
>