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]

Message-ID: <87vatljzlo.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
Date:   Wed, 11 Jan 2017 12:06:11 -0500
From:   Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To:     Andrew Lunn <andrew@...n.ch>, David Miller <davem@...emloft.net>
Cc:     netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH net-next 0/2] Move hwmon support out of switch and into PHYs.

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

The temperature and threshold are accessed through the embedded PHY
registers of any port, as long as the port is not disabled.

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.

To sum up briefly, the temperature chip is physically inside the switch
chip, but its access is via the embedded PHYs of the switch.

I'd prefer to see the temperature code in the PHY driver as well, but I
prefer we make sure that privileging the data access over the physical
representation is the correct thing to do before moving code around.

Thanks,

        Vivien