netdev - Re: [PATCH net-next 0/2] Move hwmon support out of switch and into 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]

Date:   Wed, 11 Jan 2017 09:55:49 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH net-next 0/2] Move hwmon support out of switch and into
 PHYs.

On 01/11/2017 09:37 AM, Andrew Lunn wrote:
> On Wed, Jan 11, 2017 at 12:06:11PM -0500, Vivien Didelot wrote:
>> Hi Andrew,
>>
>> Andrew Lunn <andrew@...n.ch> writes:
>>
>>> Marvell Ethernet switches contain temperature sensors. They are inside
>>> the embedded PHYs. Move the code into the PHY driver, so that discrete
>>> PHY drivers also export there temperature sensor.
>>
>> This message is not correct. The Marvell Ethernet switches contain only
>> one temperature sensor for the entire chip (please adjust the cover
>> letter and commit messages when you respin.)
> 
> Agreed.
> 
>> The temperature and threshold are accessed through the embedded PHY
>> registers of any port, as long as the port is not disabled.
> 
> This is not correct. Each PHY has its own threshold registers. They
> can be different, even if they are applied to one shared sensor.  One
> PHY can be in alarm state, while others are not, due to different
> thresholds.
> 
>> Even unlikely to be used, an interrupt can be generated when the
>> temperature exceeds a certain threshold. It should be enabled on only
>> one port at a time since there is only one temperature sensor.
> 
> Actually, since each PHY can have a different threshold, it would in
> theory be possible to have different PHYs generating interrupts at
> different thresholds.
> 
> However, at the moment, there is no code to enable interrupts for
> temperature alarms. I also don't see any need to add such code, since
> there is nowhere in HWMON to actively report such an alarm condition.

Are not the *_alarm attributes specifically designed to report such
things? See Documentation/hwmon/sysfs-interface

> 
> There is potentially an issue sometime down the road, if we were to
> enable the temperature threshold interrupt. It is not clear what
> happens if two PHYs have the same threshold conditions and this
> threshold is crossed. Do all PHYs trigger an interrupt? Does only one?
> Do none? I would prefer investigating and solving such issues if and
> when it is decided to enable the interrupt.
> 
>> To sum up briefly, the temperature chip is physically inside the switch
>> chip, but its access is via the embedded PHYs of the switch.
> 
> There is one temperature sensor in the chip, which each embedded PHY
> shares for reporting the current temperature. It appears that
> everything but the sensor is duplicated in each embedded PHY.

If that is the case, should we have a way to make the HWMON attributes
be associated with the switch device while still calling into the PHY
driver to do the actual temperature readings and such? Right now, it
sounds like we will have a duplication of HWMON attributes created for
every port of the switch that is connecting to the Marvell PHY driver.
-- 
Florian