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: <87bmvo9bi1.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
Date:   Tue, 03 Jan 2017 14:41:58 -0500
From:   Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To:     Florian Fainelli <f.fainelli@...il.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

Hi Florian,

Florian Fainelli <f.fainelli@...il.com> writes:

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

I see what you mean. Indeed the drivers could register their own HWMON
device until we figure any many chips have an embedded temperature
sensor in their core.

What about sending the patch 2/3 on its own?

Thanks,

        Vivien