linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Michael Walle <michael@walle.cc>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S . Miller" <davem@davemloft.net>,
	Vladimir Oltean <vladimir.oltean@nxp.com>
Subject: Re: [RFC PATCH net-next 1/3] net: phy: add concept of shared storage for PHYs
Date: Tue, 21 Apr 2020 21:30:55 +0200	[thread overview]
Message-ID: <20200421193055.GI933345@lunn.ch> (raw)
In-Reply-To: <47bdeaf298a09f20ad6631db13df37d2@walle.cc>

> 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

  reply	other threads:[~2020-04-21 19:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-20 23:26 [RFC PATCH net-next 1/3] net: phy: add concept of shared storage for PHYs Michael Walle
2020-04-20 23:26 ` [RFC PATCH net-next 2/3] net: phy: bcm54140: use phy_package_shared Michael Walle
2020-04-20 23:26 ` [RFC PATCH net-next 3/3] net: phy: mscc: " Michael Walle
2020-04-23 12:27   ` Vladimir Oltean
2020-04-21 14:34 ` [RFC PATCH net-next 1/3] net: phy: add concept of shared storage for PHYs Andrew Lunn
2020-04-21 14:43   ` Russell King - ARM Linux admin
2020-04-21 14:52     ` Andrew Lunn
2020-04-21 15:20       ` Michael Walle
2020-04-21 15:25 ` Michael Walle
2020-04-21 15:50   ` Andrew Lunn
2020-04-21 19:08     ` Michael Walle
2020-04-21 19:30       ` Andrew Lunn [this message]
2020-04-21 19:38         ` Russell King - ARM Linux admin
2020-04-21 21:19         ` Michael Walle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200421193055.GI933345@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=michael@walle.cc \
    --cc=netdev@vger.kernel.org \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).