lkml.org 
[lkml]   [2019]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/2] reset: Add Broadcom STB RESCAL reset controller
From
Date
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

\
 
 \ /
  Last update: 2019-12-12 11:03    [W:0.059 / U:2.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site