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 17:15:03 +0000 [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
WARNING: multiple messages have this Message-ID (diff)
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: 31+ 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:08 ` Ben Dooks
2014-02-17 13:44 ` Mark Rutland
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-19 17:15 ` Laurent Pinchart
2014-02-17 13:53 ` Ben Dooks
2014-02-17 17:33 ` Florian Fainelli
2014-02-17 17:33 ` Florian Fainelli
2014-02-17 17:44 ` Ben Dooks
2014-02-17 17:53 ` Florian Fainelli
2014-02-17 17:53 ` Florian Fainelli
2014-02-17 18:04 ` Mark Rutland
2014-02-17 19:11 ` David Miller
2014-02-17 19:11 ` David Miller
2014-02-17 20:33 ` Sergei Shtylyov
2014-02-17 21:33 ` Sergei Shtylyov
2014-02-17 20:48 ` Florian Fainelli
2014-02-17 20:48 ` Florian Fainelli
2014-02-17 21:08 ` Sergei Shtylyov
2014-02-17 22:08 ` Sergei Shtylyov
2014-02-17 21:15 ` Florian Fainelli
2014-02-17 21:15 ` Florian Fainelli
2014-02-18 8:16 ` Ben Dooks
2014-02-18 11:54 ` Mark Rutland
2014-02-18 16:00 ` Sergei Shtylyov
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.