netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200421193055.GI933345@lunn.ch>
Date:   Tue, 21 Apr 2020 21:30:55 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Michael Walle <michael@...le.cc>
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

> 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.

There is a somewhat similar problem with Marvell Ethernet switches and
their internal PHYs. The PHYs are the same as the discrete PHYs, and
the usual Marvell PHY driver is used. But there is only one
temperature sensor for the whole switch, and it is mapped into all the
PHYs. So we end up creating multiple hwmon devices for the one
temperature sensor, one per PHY.

You could take the same approach here. Each PHY exposes a hwmon
device?

Looking at
static struct device *
__hwmon_device_register(struct device *dev, const char *name, void *drvdata,
                        const struct hwmon_chip_info *chip,
                        const struct attribute_group **groups)

I think it is O.K. to pass dev as NULL. You don't have to associate it
to a device. So you could create the hwmon device as part of package
initialisation and put it into shared->priv.

	Andrew