netdev - Re: [PATCH V2] net: phy: tja11xx: Add TJA11xx PHY driver

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] [day] [month] [year] [list]

Date:   Sun, 23 Dec 2018 10:12:46 +0100
From:   Marek Vasut <marex@...x.de>
To:     Heiner Kallweit <hkallweit1@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, f.fainelli@...il.com
Subject: Re: [PATCH V2] net: phy: tja11xx: Add TJA11xx PHY driver

On 12/22/18 6:24 PM, Heiner Kallweit wrote:
> On 22.12.2018 00:22, Marek Vasut wrote:
>> On 12/15/2018 06:38 PM, Heiner Kallweit wrote:
>>> On 15.12.2018 18:01, Andrew Lunn wrote:
>>>>> +static struct tja11xx_phy_stats tja11xx_hw_stats[] = {
>>>>> +	{ "phy_symbol_error_count", 20, 0, 0xffff },
>>>>> +	{ "phy_overtemp_error", 21, 1, BIT(1) },
>>>>> +	{ "phy_undervolt_error", 21, 3, BIT(3) },
>>>>> +	{ "phy_polarity_detect", 25, 6, BIT(6) },
>>>>> +	{ "phy_open_detect", 25, 7, BIT(7) },
>>>>> +	{ "phy_short_detect", 25, 8, BIT(8) },
>>>>
>>>> Hi Marek
>>>>
>>>> You have a number of one bit counters here, which is pretty unusual.
>>>> The names also don't really suggest they are counters.
>>>>
>>> Apart from few counters the values seem to be flags. I just think
>>> it could be done in a little bit more readable form, e.g. instead of
>>> { "phy_short_detect", 25, 8, BIT(8) } use
>>> { "phy_short_detect", 25, BIT(8) } and in tja11xx_get_stats() then
>>> use FIELD_GET (see linux/bitfield.h).
>>
>> This doesn't work with the counters, it only works with flags. The array
>> contains both.
>>
> Maybe we have a misunderstanding here, but FIELD_GET would work also
> with the counters. FIELD_GET calculates the field offset, so you don't
> need to specify it. Let's say you would have an entry in your array like
> this: { "phy_xxx_error_count", 20, 4, 0xfff0 }
> 
> Then you would do:
> #define XXX_ERROR_CNT_MASK GENMASK(15, 4)
> { "phy_xxx_error_count", 20, XXX_ERROR_CNT_MASK }
> and access the value by
> val = FIELD_GET(XXX_ERROR_CNT_MASK, reg)

Ah, let's try that then.

>>> The idea of HWMON attributes sounds good to me because it allows
>>> to use the flags to trigger actions in a structured way. And I
>>> assume in case of e.g. "PHY undervolt" some monitoring system
>>> would like to be informed (especially because we talk about
>>> automotive here).
>>
>> I added HWMON_T_CRIT_ALARM and HWMON_I_LCRIT_ALARM for
>> phy_overtemp_error and phy_undervolt_error respectively.
>> Are there any other hwmon attributes I can use to replace the flags in
>> the tja11xx_hw_stats array ?
>>
> I think that's it.

OK

-- 
Best regards,
Marek Vasut