netdev - Re: [PATCH net-next v3 07/19] net: axienet: Re-initialize MDIO registers properly after reset

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] [day] [month] [year] [list]

Date:   Tue, 4 Jun 2019 16:39:05 -0600
From:   Robert Hancock <hancock@...systems.ca>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, anirudh@...inx.com, John.Linn@...inx.com
Subject: Re: [PATCH net-next v3 07/19] net: axienet: Re-initialize MDIO
 registers properly after reset

On 2019-06-04 4:18 p.m., Andrew Lunn wrote:
>> -	axienet_iow(lp, XAE_MDIO_MC_OFFSET,
>> -		    (mdio_mcreg & (~XAE_MDIO_MC_MDIOEN_MASK)));
>> +	mutex_lock(&lp->mii_bus->mdio_lock);
>> +	axienet_mdio_disable(lp);
> 
> I wonder if it would look better structured if the lock was in
> axienet_mdio_disable() and the unlock in axienet_mdio_enable(lp)?
> 
> As you said, you are trying to refactor all the MDIO code it mdio.c.

Acquiring a lock and not releasing it in a disable() method would seem a
little bit evil.. not sure if there is another way to handle that
better. The code in _mdio.c doesn't do anything with the mdio_lock so
it's not going to conflict between the code in the two files at least.

-- 
Robert Hancock
Senior Software Developer
SED Systems, a division of Calian Ltd.
Email: hancock@...systems.ca