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]
Message-ID: <b687d9b9-ea38-151e-3311-9e8efdf337a2@sedsystems.ca>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ