RE: [PATCH] reset: axs10x: Implement assert and deassert callbacks

[Vitor Soares]

Hi Eugeniy,

From: Eugeniy Paltsev <paltsev@xxxxxxxxxxxx>
Date: Fri, Apr 12, 2019 at 14:22:33

> Hi Vitor,
> 
> On Mon, 2019-04-08 at 13:25 +0000, Vitor Soares wrote:
> > Hi Eugeniy,
> > 
> > From: Eugeniy Paltsev <paltsev@xxxxxxxxxxxx>
> > Date: Mon, Apr 08, 2019 at 12:40:00
> > 
> > > Hi Vitor,
> > > 
> > > On Mon, 2019-04-08 at 12:31 +0200, Vitor Soares wrote:
> > > > Some custom IP-block connected to ARC AXS10x board need assert and
> > > > deassert functions to control reset signal of selected peripherals.
> > > > 
> > > > This patch improve AXS10x reset driver by adding assert and deassert
> > > > callbacks.
> > > 
> > > 
> > > In the AXS10x reset driver only 'reset' callback is intentionally 
> > > > implemented.
> > > 
> > > AXS10x is FPGA based boards and with our default firmware AXS10x reset 
> > > > register is implemented as self-deasserted.
> > 
> > I have another reset block connect through AXI.
> > 
> > > Do you have somehow modified AXS10x firmware where reset register is not 
> > > > self-deasserted?
> > > 
> > > In that case "simple-reset" driver will be suitable for you, I guess.
> > 
> > I will try it.
> > 
> > > Otherwise this implementation is incorrect - there should be no 'assert' for 
> > > > reset controller with self-deasserted logic.
> > 
> > So the assert and reset callback are mutually exclusive?
> 
> Not actually.
> 
> Adding 'assert' callback is incorrect for exclusive reset controls in
> case of self-deasserted reset controller.
> It will cause reset_control_assert() to return success for exclusive
> reset controls, even though the .assert op failed to leave the reset
> line asserted after the function returns.
> 

Sorry I'm not understanding. Can you please explain?

What I see in reset_control_assert() when not shared is return -ENOTSUPP.

> 
> [snap]
> > 
> > Best regards,
> > Vitor Soares
> > 
> -- 
>  Eugeniy Paltsev

Thanks for your feedback.


Best regards,
Vitor Soares