From: Ben Dooks <ben.dooks@codethink.co.uk>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "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: Mon, 17 Feb 2014 13:53:26 +0000 [thread overview]
Message-ID: <53021456.4020404@codethink.co.uk> (raw)
In-Reply-To: <20140217134448.GA19308@e106331-lin.cambridge.arm.com>
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 think allocating a compatible string and handling it in the kernel is
> better than having arbitrary register poke values in the dt.
>> + prop = of_find_property(of_node, "init-regs", &len);
>> + if (prop) {
>> + if (len % (sizeof(__be32) * 3)) {
>> + dev_err(dev, "init-regs not multiple of 3 entries\n");
>> + return -EINVAL;
>> + }
>> +
>> + ptr = of_prop_next_u32(prop, ptr, ®);
>> + while (ptr != NULL) {
>> + ptr = of_prop_next_u32(prop, ptr, ®);
oops, bad rebase fixup, this should have been deleted.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
next prev parent reply other threads:[~2014-02-17 13:53 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
2014-02-19 17:15 ` Laurent Pinchart
2014-02-17 13:53 ` Ben Dooks [this message]
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=53021456.4020404@codethink.co.uk \
--to=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.