linux-kernel - Re: [PATCH] phy: marvell: remove LED config override

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160610205211.GA14243@archie.localdomain>
Date:	Fri, 10 Jun 2016 22:52:11 +0200
From:	Clemens Gruber <clemens.gruber@...ruber.com>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	netdev@...r.kernel.org, Florian Fainelli <f.fainelli@...il.com>,
	linux-kernel@...r.kernel.org,
	"David S . Miller" <davem@...emloft.net>,
	Sergei Poselenov <sposelenov@...raft.com>
Subject: Re: [PATCH] phy: marvell: remove LED config override

Hi Andrew,

On Fri, Jun 10, 2016 at 08:38:57PM +0200, Andrew Lunn wrote:
> On Fri, Jun 10, 2016 at 07:42:52PM +0200, Clemens Gruber wrote:
> > Configuring the PHY LED registers for the Marvell 88E1510 and others is
> > not possible, because regardless of the values in marvell,reg-init, it
> > is later overridden in m88e1121_config_aneg with a non-standard default.
> > 
> > This became visible after we moved the call of marvell_of_reg_init in
> > commit 79be1a1c9090 ("phy: marvell: Fix and unify reg-init behavior").
> > Moving it to _config_init was necessary due to the PHY state machine
> > getting stuck if the PHY interrupts were not enabled early on.
> > As that default LED configuration is set in _config_aneg, it overrides
> > the marvell,reg-init configuration from the device tree.
> > 
> > This patch removes this override and allows the user to again set the
> > PHY LED configuration through marvell,reg-init or if that does not
> > exist, keep the original defaults as documented in the datasheet.
> 
> That override code exists for a reason. I don't like just removing it
> without understanding why it is there. Sergei Poselenov added it as
> part of the 1121 support. Maybe he knows why it is there?

Maybe because he needed that special LED configuration (LED[0] .. Link,
LED[1] .. Activity) on his board?
On my board it's LED[0] as Activity and LED[1] as Link LED.

We could move that 0x30 LED configuration to .config_init instead of
.config_aneg, so that if nobody configures it with marvell,reg-init, the
behavior does not change. I'd have to create a new .config_init function
for the 1121, 1318 and 1510.

Would you prefer that?

(I thought it would be good to be consistent with the defaults mentioned
in the datasheet, but being backwards-compatible is probably more
important, you are right)

Regards,
Clemens