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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 3 Mar 2021 11:16:47 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Álvaro Fernández Rojas <noltari@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>
Cc:     Matt Mackall <mpm@...enic.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Rob Herring <robh+dt@...nel.org>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Mark Brown <broonie@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Nícolas F. R. A. Prado 
        <nfraprado@...tonmail.com>,
        Rikard Falkeborn <rikard.falkeborn@...il.com>,
        Stefan Wahren <stefan.wahren@...e.com>,
        linux-crypto@...r.kernel.org,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, linux-rpi-kernel@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/2] hwrng: bcm2835: add reset support

On 3/3/21 6:06 AM, Álvaro Fernández Rojas wrote:
> Hi Philipp,
> 
>> El 3 mar 2021, a las 14:52, Philipp Zabel <p.zabel@...gutronix.de> escribió:
>>
>> Hi Álvaro,
>>
>> On Wed, 2021-02-24 at 09:22 +0100, Álvaro Fernández Rojas wrote:
>> [...]
>>> @@ -115,6 +121,8 @@ static void bcm2835_rng_cleanup(struct hwrng *rng)
>>> 	/* disable rng hardware */
>>> 	rng_writel(priv, 0, RNG_CTRL);
>>>
>>> +	reset_control_rearm(priv->reset);
>>> +
>>> 	if (!IS_ERR(priv->clk))
>>> 		clk_disable_unprepare(priv->clk);
>>> }
>>> @@ -159,6 +167,10 @@ static int bcm2835_rng_probe(struct platform_device *pdev)
>>> 	if (PTR_ERR(priv->clk) == -EPROBE_DEFER)
>>> 		return -EPROBE_DEFER;
>>>
>>> +	priv->reset = devm_reset_control_get_optional_exclusive(dev, NULL);
>>> +	if (IS_ERR(priv->reset))
>>> +		return PTR_ERR(priv->reset);
>>> +
>>> 	priv->rng.name = pdev->name;
>>> 	priv->rng.init = bcm2835_rng_init;
>>> 	priv->rng.read = bcm2835_rng_read;
>>
>> That doesn't seem right. reset_control_rearm() doesn't do anything if
>> the reset control is exclusive. Either the reset control should be
>> requested as shared, or the _rearm should be removed.
> 
> In only added reset_control_rearm() because Florian requested it…
> I think it’s not needed, so we can use v3, since it was the only change between v3 and v4...

Not the first time I am confused by the reset API not sure if I will
ever get it one day, so apologies for suggesting something incorrect here.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ