netdev - Re: [PATCH net-next 0/3] net: dsa: restore HWMON support in dsa2

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: <0a504cad-2f2c-fc6a-9965-5ae87be9dac4@gmail.com>
Date:   Tue, 3 Jan 2017 11:29:48 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel@...oirfairelinux.com,
        "David S. Miller" <davem@...emloft.net>, cphealy@...il.com
Subject: Re: [PATCH net-next 0/3] net: dsa: restore HWMON support in dsa2

On 01/03/2017 11:24 AM, Vivien Didelot wrote:
> Hi Andrew,
> 
> Andrew Lunn <andrew@...n.ch> writes:
> 
>> On Tue, Jan 03, 2017 at 01:15:35PM -0500, Vivien Didelot wrote:
>>> The current HWMON support in DSA in embedded in the legacy code.
>>> Extract it to its own file and register it in the newer DSA code.
>>
>> I would really prefer not to do this.
>>
>> The temperature sensor is in the embedded PHYs of the switch. Many of
>> Marvell discrete PHYs also have the same temperature sensor. The
>> correct thing to do is move this code into drivers/net/phy/marvell.c.
> 
> I agree that the temperature code in the mv88e6xxx driver must be moved
> to the Marvell PHY driver.
> 
> However I still think this patchset is still valuable because at least
> it isolates the HWMON code in DSA which is good, and I think some chips
> do have temperature sensors in their cores, not in their PHYs. So the
> new DSA code should benefit from the HWMON support instead of
> considering this a regression for its users.

Well, I agree with the regression part, but an argument could
definitively be made that HWMON did not belong in the DSA layer in the
first place, unless we were able to find some commonality between
devices which AFAICT, we could not yet.

I don't have a strong preference, but it seems like the HWMON
functionality should have been part of the switch and/or PHY driver all
along.
-- 
Florian