netdev - Re: [PATCH] net: add init-regs for of

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:	Wed, 19 Feb 2014 18:15:03 +0100
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Ben Dooks <ben.dooks@...ethink.co.uk>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>
Subject: Re: [PATCH] net: add init-regs for of_phy support

Hi Ben,

On Monday 17 February 2014 14:12:22 Mark Rutland wrote:
> On Mon, Feb 17, 2014 at 01:50:28PM +0000, Ben Dooks wrote:
> > On 17/02/14 13:44, Mark Rutland wrote:
> > > On Mon, Feb 17, 2014 at 01:08:04PM +0000, Ben Dooks wrote:
> > >> Add new init-regs field for of_phy nodes and make sure these
> > >> get applied when the phy is configured.
> > >> 
> > >> This allows any phy node in an fdt to initialise registers
> > >> that may not be set as standard by the driver at initialisation
> > >> time, such as LED controls.
> > > 
> > > Why not have a driver for the particular PHY? If it's not standard we
> > > don't need to pretend it is. If it has some extensions then the standard
> > > compatible string can be a fallback entry in the compatible list.
> > 
> > I was trying to provide some useful and reasonably generic code
> > to setup PHYs without having to add specific arguments to each of
> > them.
> > 
> > I could have added something like ksz8041,led-mode1 = <1> and
> > updated the micrel driver.
> 
> Perhaps. It depends on precisely what the property is describing.
> 
> I think describing the hardware and letting Linux figure out what to do
> is better than giving it a set of opaque instructions for it to blindly
> follow.

I second that, I think a LED mode property would be better in this case.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html