From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Ben Dooks <ben.dooks@codethink.co.uk>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>
Subject: Re: [PATCH] net: add init-regs for of_phy support
Date: Wed, 19 Feb 2014 18:15:03 +0100 [thread overview]
Message-ID: <19899452.nJCbJf89OP@avalon> (raw)
In-Reply-To: <20140217141222.GB19308@e106331-lin.cambridge.arm.com>
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
next prev parent reply other threads:[~2014-02-19 17:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 13:08 RFC: add init-regs for phy nodes Ben Dooks
2014-02-17 13:08 ` [PATCH] net: add init-regs for of_phy support Ben Dooks
2014-02-17 13:44 ` Mark Rutland
2014-02-17 13:50 ` Ben Dooks
2014-02-17 14:12 ` Mark Rutland
2014-02-19 17:15 ` Laurent Pinchart [this message]
2014-02-17 13:53 ` Ben Dooks
2014-02-17 17:33 ` Florian Fainelli
2014-02-17 17:44 ` Ben Dooks
2014-02-17 17:53 ` Florian Fainelli
2014-02-17 18:04 ` Mark Rutland
2014-02-17 19:11 ` David Miller
2014-02-17 21:33 ` Sergei Shtylyov
2014-02-17 20:48 ` Florian Fainelli
2014-02-17 22:08 ` Sergei Shtylyov
2014-02-17 21:15 ` Florian Fainelli
2014-02-18 8:16 ` Ben Dooks
2014-02-18 11:54 ` Mark Rutland
2014-02-18 17:00 ` Sergei Shtylyov
2014-02-18 17:13 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19899452.nJCbJf89OP@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=ben.dooks@codethink.co.uk \
--cc=devicetree@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).