devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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, &reg);
>> +		while (ptr != NULL) {
>> +			ptr = of_prop_next_u32(prop, ptr, &reg);

oops, bad rebase fixup, this should have been deleted.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

  parent reply	other threads:[~2014-02-17 13:53 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
2014-02-17 13:53     ` Ben Dooks [this message]
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=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 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).