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: <1a6df254-a6fa-46bd-b28c-1c123e9689c4@bootlin.com>
Date: Thu, 29 Feb 2024 08:28:51 +0100
From: Bastien Curutchet <bastien.curutchet@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Pavel Machek <pavel@....cz>,
 Lee Jones <lee@...nel.org>, Richard Cochran <richardcochran@...il.com>,
 Heiner Kallweit <hkallweit1@...il.com>, Russell King
 <linux@...linux.org.uk>, linux-kernel@...r.kernel.org,
 netdev@...r.kernel.org, devicetree@...r.kernel.org,
 linux-leds@...r.kernel.org, Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 herve.codina@...tlin.com, maxime.chevallier@...tlin.com,
 christophercordahi@...ometrics.ca
Subject: Re: [PATCH v2 3/6] net: phy: DP83640: Add LED handling

Hi

On 2/28/24 16:04, Andrew Lunn wrote:
>> +static int dp83640_led_brightness_set(struct phy_device *phydev, u8 index,
>> +				      enum led_brightness brightness)
>> +{
>> +	int val;
>> +
>> +	if (index > DP83640_SPDLED_IDX)
>> +		return -EINVAL;
>> +
>> +	phy_write(phydev, PAGESEL, 0);
>> +
>> +	val = phy_read(phydev, LEDCR) & ~DP83640_LED_DIS(index);
>> +	val |= DP83640_LED_DRV(index);
>> +	if (brightness)
>> +		val |= DP83640_LED_VAL(index);
>> +	else
>> +		val &= ~DP83640_LED_VAL(index);
>> +	phy_write(phydev, LEDCR, val);
> I don't understand this driver too well, but should this be using
> ext_read() and ext_write().
>
> I'm also woundering if it would be good to implement the .read_page
> and .write_page members in phy_driver and then use phy_write_paged()
> and phy_write_paged() and phy_modify_paged(), which should do better
> locking.
I don't feel comfortable implementing .read_page and write_page members 
as I have
only one PHY on my board so I'll not be able to test all the broadcast 
thing.

If that's OK with you, I'll use the ext_read() and ext_write()


Best regards,

Bastien


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ