netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring
Date: Thu, 23 Oct 2014 11:43:22 -0700	[thread overview]
Message-ID: <20141023184322.GA24281@roeck-us.net> (raw)
In-Reply-To: <20141023180357.GG25190@lunn.ch>

On Thu, Oct 23, 2014 at 08:03:57PM +0200, Andrew Lunn wrote:
> > No, I am not saying that. The hwmon device's parent device will tell,
> > which is how it works for all other hwmon devices.
> 
> O.K, so parent is important.
> 
> > Not really. Again, the parent device provides that information. libsensors,
> > which is the preferred way of accessing sensors information from user space,
> > provides the parent device instance as part of the logical sensor device
> > name. In this case, the names will end up being dsa-isa-0000, dsa-isa-0001,
> > and so on. With your added tags it would be dsa.0.0-isa-0000, dsa.0.1-isa-0001,
> > and so on. I don't see how this would add any value.
> 
> isa is the name of the ethernet device? Why is it not eth0? Most

isa is just an internal name made up by libsensors, and pretty much just
indicates something like "neither i2c nor spi". It is mostly historic,
but nowadays almost part of the ABI. It is made up by user space,
based on the parent device type, not by the kernel.

> Marvell SoCs used in WiFi Access Points have multiple ethernet
> interfaces, so i would hope the parent actually identifies which
> ethernet interface it is hanging off.
> 
> Now consider the example in
> 
> http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/net/dsa/dsa.txt
> 
> We have two switches hanging off one ethernet interface. What will the > naming look like in this case?
> 
Ah, that is a good question. You are right, the parent will be the same
for both of those switches but should be unique. Hmm ...

> The Marvell DSA tagging scheme allows you to have 16 switches hanging
> off one ethernet interface. How is the naming going to work then,
> especially if there is a mixture of switch chips, some with
> temperature sensors, and some without?
> 
The ones without sensor would not create a hwmon device, so that should
not be an issue. You are right, the other use cases are more tricky.

> What would really help is if each switch has a device in the linux
> device model. The hwmon parent would then be the switch device. The
> EEPROM would then hang off the switch device, not an interface on the
> switch device, etc.

Good point. Unfortunately that is not the case.

You have convinced me that 'dsa' as hwmon attribute name is insufficient,
so let's see what we have.

- the parent network device in dst->master_netdev
- the dsa device in 'parent'
- the host device in host_dev
- the switch index in 'index'

First question is what should be the parent device. We have three to
choose from. Should it be the parent network device or the dsa device ?
The dsa device seems like a better choice to me, but I am open to
suggestions. A problem with choosing the network device as parent
may be that this device could by itself have a temperature sensor
(some Intel and broadcom Ethernet chips have that), which could
cause confusion.

Second is what to choose for the hwmon device 'name' attribute.
'dsa' is not sufficient, but what to choose instead ? dsa.X or dsa_X,
where X is the switch index ? At this point I am open to suggestions.
Note that we can not use the name returned from the switch probe
functions as it may contain spaces and other invalid characters.
Including the ethernet device name (eg as in eth0_dsa_0) may also be
problematic if it can contain '-', which is illegal for hwmon devices.

Thanks,
Guenter

  reply	other threads:[~2014-10-23 18:43 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-23  4:03 [PATCH 00/14] net: dsa: Fixes and enhancements Guenter Roeck
2014-10-23  4:03 ` [PATCH 01/14] net: dsa: Don't set skb->protocol on outgoing tagged packets Guenter Roeck
2014-10-23  4:03 ` [PATCH 02/14] net: dsa: Report known silicon revisions for Marvell 88E6060 Guenter Roeck
2014-10-23 12:51   ` Sergei Shtylyov
2014-10-23 13:20     ` Guenter Roeck
2014-10-23 16:00       ` Sergei Shtylyov
2014-10-23  4:03 ` [PATCH 03/14] net: dsa: Report known silicon revisions for Marvell 88E6131 Guenter Roeck
2014-10-23  4:03 ` [PATCH 04/14] net: dsa: Add support for Marvell 88E6352 Guenter Roeck
2014-10-23  4:03 ` [PATCH 05/14] net: dsa/mv88e6352: Add support for MV88E6176 Guenter Roeck
2014-10-23  4:03 ` [PATCH 06/14] net: dsa: Add support for hardware monitoring Guenter Roeck
2014-10-23  4:37   ` Florian Fainelli
2014-10-23  5:06     ` Guenter Roeck
2014-10-23  8:24       ` Richard Cochran
2014-10-23 13:27         ` Guenter Roeck
2014-10-23 13:47       ` Andrew Lunn
2014-10-23 16:27         ` Guenter Roeck
2014-10-23 16:54           ` Andrew Lunn
2014-10-23 17:38             ` Guenter Roeck
2014-10-23 18:03               ` Andrew Lunn
2014-10-23 18:43                 ` Guenter Roeck [this message]
2014-10-23 19:55                   ` Andrew Lunn
2014-10-24 13:53                     ` Guenter Roeck
2014-10-24 16:19                     ` Guenter Roeck
2014-10-25 14:01                       ` Andrew Lunn
2014-10-25 17:23                         ` Florian Fainelli
2014-10-25 18:00                           ` Andrew Lunn
2014-10-26 15:57                             ` Guenter Roeck
2014-10-25 17:26                         ` Florian Fainelli
2014-10-25 19:44                         ` Guenter Roeck
2014-10-24  5:03       ` David Miller
2014-10-24  5:40         ` Guenter Roeck
2014-10-24  6:10           ` David Miller
2014-10-24 12:52           ` Florian Fainelli
2014-10-24  6:09             ` Guenter Roeck
2014-10-23  4:03 ` [PATCH 07/14] net: dsa/mv88e6352: Report chip temperature Guenter Roeck
2014-10-23  4:03 ` [PATCH 08/14] net: dsa/mv88e6123_61_65: " Guenter Roeck
2014-10-23  4:03 ` [PATCH 09/14] net: dsa: Add support for switch EEPROM access Guenter Roeck
2014-10-23  4:03 ` [PATCH 10/14] net: dsa/mv88e6352: Implement EEPROM access functions Guenter Roeck
2014-10-23 13:54   ` Andrew Lunn
2014-10-23 16:40     ` Guenter Roeck
2014-10-23 18:41       ` [PATCH 10/14] net: dsa/mv88e6352: Implement EEPROM accessfunctions Chris Healy
2014-10-23 18:55         ` Florian Fainelli
2014-10-24  3:59           ` Guenter Roeck
2014-10-23  4:03 ` [PATCH 11/14] net: dsa: Add support for reading switch registers with ethtool Guenter Roeck
2014-10-23  4:40   ` Florian Fainelli
2014-10-23  5:21     ` Guenter Roeck
2014-10-23  4:03 ` [PATCH 12/14] net: dsa/mv88e6123_61_65: Add support for reading switch registers Guenter Roeck
2014-10-23  4:03 ` [PATCH 13/14] net: dsa/mv88e6352: " Guenter Roeck
2014-10-23  4:03 ` [PATCH 14/14] net: dsa: Provide additional RMON statistics Guenter Roeck
2014-10-23  4:45 ` [PATCH 00/14] net: dsa: Fixes and enhancements Florian Fainelli
2014-10-23  5:22   ` Guenter Roeck

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=20141023184322.GA24281@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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).