netdev - Re: [PATCH V3] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <9cdb0386-8d9b-63b4-f8c5-cd2569515bb7@denx.de>
Date:   Sun, 23 Dec 2018 11:21:11 +0100
From:   Marek Vasut <marex@...x.de>
To:     Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH V3] net: phy: tja11xx: Add TJA11xx PHY driver

On 12/23/18 10:41 AM, Heiner Kallweit wrote:
> On 23.12.2018 10:16, Marek Vasut wrote:
>> On 12/22/18 6:39 PM, Heiner Kallweit wrote:
>>> On 22.12.2018 00:35, Marek Vasut wrote:
>>>> Add driver for the NXP TJA1100 and TJA1101 PHYs. These PHYs are special
>>>> BroadRReach 100BaseT1 PHYs used in automotive.
>>>>
>>>> Signed-off-by: Marek Vasut <marex@...x.de>
>>>> Cc: Andrew Lunn <andrew@...n.ch>
>>>> Cc: Florian Fainelli <f.fainelli@...il.com>
>>>> Cc: Heiner Kallweit <hkallweit1@...il.com>
>>>> ---
>>>> V2: - Use phy_modify(), phy_{set,clear}_bits()
>>>>     - Drop enable argument of tja11xx_enable_link_control()
>>>>     - Use PHY_BASIC_T1_FEATURES and dont modify supported/advertised
>>>>       features in config_init callback
>>>>     - Use genphy_soft_reset() instead of opencoding the reset sequence.
>>>>     - Drop the aneg parts, since the PHY datasheet claims it does not
>>>>       support aneg
>>>> V3: - Replace clr with mask
>>>>     - Add hwmon support
>>>>     - Check commstat in tja11xx_read_status() only if link is up
>>>>     - Use PHY_ID_MATCH_MODEL()
>>>> ---
>>>>  drivers/net/phy/Kconfig       |   6 +
>>>>  drivers/net/phy/Makefile      |   1 +
>>>>  drivers/net/phy/nxp-tja11xx.c | 424 ++++++++++++++++++++++++++++++++++
>>>>  3 files changed, 431 insertions(+)
>>>>  create mode 100644 drivers/net/phy/nxp-tja11xx.c
>>>>
>>> [...]
>>>> +
>>>> +struct tja11xx_phy_stats {
>>>> +	const char	*string;
>>>> +	u8		reg;
>>>> +	u8		off;
>>>> +	u16		mask;
>>>> +};
>>>> +
>>> As written in my other mail, you could think of using
>>> FIELD_GET() again. Things like
>>> ... n, BIT(n), 
>>> ... m, BIT(m), 
>>> are simply redundant.
>>
>> Done
>>
>>>> +static struct tja11xx_phy_stats tja11xx_hw_stats[] = {
>>>> +	{ "phy_symbol_error_count", 20, 0, 0xffff },
>>>> +	{ "phy_polarity_detect", 25, 6, BIT(6) },
>>>> +	{ "phy_open_detect", 25, 7, BIT(7) },
>>>> +	{ "phy_short_detect", 25, 8, BIT(8) },
>>>> +	{ "phy_rem_rcvr_count", 26, 0, 0xff },
>>>> +	{ "phy_loc_rcvr_count", 26, 8, 0xff },
>>>
>>> Shouldn't mask in the last line be 0xff00 ?
>>> In the relevant code you do: val = (reg & mask) >> off
>>
>> Yes, fixed, thanks
>>
>>>> +static int tja11xx_probe(struct phy_device *phydev)
>>>> +{
>>>> +	struct device *dev = &phydev->mdio.dev;
>>>> +	struct tja11xx_priv *priv;
>>>> +	int i;
>>>> +
>>>> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>>>> +	if (!priv)
>>>> +		return -ENOMEM;
>>>> +
>>>> +	priv->hwmon_name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
>>>> +	if (!priv->hwmon_name)
>>>> +		return -ENODEV;
>>>
>>> Do you really need to make a copy of the device name?
>>> Why not simply priv->hwmon_name = dev_name(dev) ?
>>
>> Fine by me, but then maybe I don't quite understand why the other
>> drivers duplicate the name, eg. the sfp.c one.
>>
> It's a question of object lifetime. If the original object can go away
> before your object, then you need to make a copy of the name.
> However in our case I don't think priv can live longer than dev.
> 
>>> And if devm_kstrdup fails, then most likely you have an out-of-memory
>>> error, so why not return -ENOMEM as usual?
>>
>> Fixed
>>
>>>> +
>>>> +	for (i = 0; priv->hwmon_name[i]; i++)
>>>> +		if (hwmon_is_bad_char(priv->hwmon_name[i]))
>>>> +			priv->hwmon_name[i] = '_';
>>>> +
>>>> +	priv->hwmon_dev =
>>>> +		devm_hwmon_device_register_with_info(dev, priv->hwmon_name,
>>>> +						     phydev,
>>>> +						     &tja11xx_hwmon_chip_info,
>>>> +						     NULL);
>>>> +
>>> Prerequisite for this call is that HWMON is configured in the kernel and
>>> it's reachable. Something like "IS_REACHABLE(CONFIG_HWMON)" would be
>>> needed. You can see driver rtc-ds1307 for an example.
>>
>> The driver depends on HWMON, so that should be sufficient ?
>>
> Missed that, that's sufficient. Just something to think about:
> Often HWMON is seen as an optional add-on feature. The driver itself would
> work perfectly fine also w/o HWMON. In this case you don't want the hard
> dependency. So it's up to you whether you want to allow that the driver is
> used on systems w/o HWMON support.

Given that the HWMON indicates that the automotive device either
overheated or suffered undervolt, I presume it'd be safer not to make it
optional ?

-- 
Best regards,
Marek Vasut