linux-kernel - Re: [RFC PATCH net-next 1/3] net: phy: add concept of shared storage for PHYs

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:   Tue, 21 Apr 2020 21:08:40 +0200
From:   Michael Walle <michael@...le.cc>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S . Miller" <davem@...emloft.net>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [RFC PATCH net-next 1/3] net: phy: add concept of shared storage
 for PHYs

Am 2020-04-21 17:50, schrieb Andrew Lunn:
> On Tue, Apr 21, 2020 at 05:25:19PM +0200, Michael Walle wrote:
>> Am 2020-04-21 01:26, schrieb Michael Walle:
>> > +
>> > +/* Represents a shared structure between different phydev's in the same
>> > + * package, for example a quad PHY. See phy_package_join() and
>> > + * phy_package_leave().
>> > + */
>> > +struct phy_package_shared {
>> > +	int addr;
>> > +	refcount_t refcnt;
>> > +	unsigned long flags;
>> > +
>> > +	/* private data pointer */
>> > +	/* note that this pointer is shared between different phydevs and
>> > +	 * the user has to take care of appropriate locking.
>> > +	 */
>> > +	void *priv;
>> 
>> btw. how should a driver actually use this? I mean, it can allocate
>> memory if its still NULL but when will it be freed again. Do we need
>> a callback? Is there something better than a callback?
> 
> Good point. phy_package_join() should take a size_t and do the
> allocation. phy_package_leave() would then free it.
> 
> But since we don't have a user at the moment, maybe leave it out.

Speaking of it. Does anyone have an idea how I could create the hwmon
device without the PHY device? At the moment it is attached to the
first PHY device and is removed when the PHY is removed, although
there might be still other PHYs in this package. Its unlikely to
happen though, but if someone has a good idea how to handle that,
I'd give it a try.

-michael