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]
Message-ID: <20170111173741.GB13033@lunn.ch>
Date:   Wed, 11 Jan 2017 18:37:41 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH net-next 0/2] Move hwmon support out of switch and into
 PHYs.

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.

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.

       Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ