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
