Re: [PATCH 2/2] reset: Add Broadcom STB RESCAL reset controller

[Philipp Zabel]

On Wed, 2019-12-11 at 10:12 -0800, Florian Fainelli wrote:
> 
> On 12/11/2019 1:48 AM, Philipp Zabel wrote:
> > > +#define BRCM_RESCAL_START	0
> > > +#define	BRCM_RESCAL_START_BIT	BIT(0)
> > > +#define BRCM_RESCAL_CTRL	4
> > > +#define BRCM_RESCAL_STATUS	8
> > > +#define BRCM_RESCAL_STATUS_BIT	BIT(0)
> > 
> > Is there any reason the start bit is indented but the status bit is not?
> 
> This is a convention we have tried to adopt to denote the definition
> from a register word address/offset versus the definition for bits
> within that register word.

That's fine, consider indenting BRCM_RESCAL_STATUS_BIT as well, then.

[...]
> > > +	reg = readl(base + BRCM_RESCAL_START);
> > > +	writel(reg | BRCM_RESCAL_START_BIT, base + BRCM_RESCAL_START);
> > > +	reg = readl(base + BRCM_RESCAL_START);
> > > +	if (!(reg & BRCM_RESCAL_START_BIT)) {
> > > +		dev_err(data->dev, "failed to start sata/pcie rescal\n");

Is this something that can actually happen?

[...]
> > > +	reg = readl(base + BRCM_RESCAL_START);
> > > +	writel(reg ^ BRCM_RESCAL_START_BIT, base + BRCM_RESCAL_START);
> > 
> > Please use &= ~BRCM_RESCAL_START_BIT instead.
> 
> I think the idea was to avoid unconditionally clearing it, but based on
> the documentation, I don't see this being harmful, Jim?

Unless the bit is self-clearing, I can't see how this XOR could ever set
the bit instead of clearing it.
And even if it would, I don't understand how that can be indented.
Wouldn't that restart the reset/calibration sequence?

> > > +	reg = readl(base + BRCM_RESCAL_START);
> > > +	dev_dbg(data->dev, "sata/pcie rescal success\n");
> > > +
> > > +	return 0;
> > > +}
> > 
> > This whole function looks a lot like it doesn't just deassert a reset
> > line, but actually issues a complete reset procedure of some kind. Do
> > you have some insight on what actually happens in the hardware when the
> > start bit is triggered? I suspect this should be implemented with the
> > .reset operation.
> 
> This hardware block is controlling the reset and calibration process of
> the SATA/PCIe combo PHY analog front end, but is not technically part of
> the PCIe or SATA PHY proper, it stands on its own, both functionally and
> from a register space perspective. The motivation for modelling this as
> a reset controller is that it does a reset (and a calibration) and this
> is a shared reset line among 2/3 instances of another block. If you
> think we should model this differently, please let us know.

Thank you for the explanation. I agree the "reset and calibration
sequence" property is close enough to a pure reset sequence to warrant
describing this as as reset controller.
The correct way would be to use the .reset callback though, if you can
have the drivers use reset_control_reset().

regards
Philipp