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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 Dec 2019 11:01:04 +0100
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Florian Fainelli <f.fainelli@...il.com>,
        linux-kernel@...r.kernel.org
Cc:     Jim Quinlan <jim2101024@...il.com>,
        Jim Quinlan <im2101024@...il.com>,
        Rob Herring <robh@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" 
        <bcm-kernel-feedback-list@...adcom.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/2] reset: Add Broadcom STB RESCAL reset controller

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