All of lore.kernel.org
 help / color / mirror / Atom feed
From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: mvebu: Add RN104 SATA LEDs driven via NXP PCA9554 I2C to GPIO muxer
Date: Mon, 11 Nov 2013 21:22:24 +0100	[thread overview]
Message-ID: <52813C80.70800@gmail.com> (raw)
In-Reply-To: <8738n2hfci.fsf@natisbad.org>

On 11/11/2013 09:07 PM, Arnaud Ebalard wrote:
> Hi Sebastian,
>
> Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> writes:
>
>>> @@ -154,6 +161,30 @@
>>>    			gpios = <&gpio2 0 1>;    /* GPIO 64 Active Low */
>>>    			linux,default-trigger = "keep";
>>>    		};
>>> +
>>> +		sata1_led {
>>> +			label = "rn104:blue:sata1";
>>> +			gpios = <&pca9554 0 1>;  /* Active Low */
>>
>> Same comment as for ReadyNAS 2120 patch:
>>
>> #include <dt-bindings/gpio/gpio.h> and use GPIO_ACTIVE_HIGH/LOW.
>
> Unlike RN2120 .dts for which I was able to change all the high/low
> values for macros in a single move, if I do the changes here for this
> specific patch, the .dts file for the RN104 will contain both values and
> macros.
>
> What about the following options?:
>
>   - send a preliminary patch to change all the values for macros in RN104
>     .dts file once -rc1 is here and then resubmit the PCA9554 patch with
>     macros?
>   - have the patch applied as is and then convert the whole RN104 .dts w/
>     another patch.

I'd say, respin this with gpio.h and go for a round of cleanup later.

> Anyway, once RN2120 is accepted, I intend to spend some time doing some
> housekeeping on other readynas .dts file based on the comments you made
> recently (macros, reg, addressing, phy info, etc), and also some minor
> points (whitespaces).

Great!

Sebastian

WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Arnaud Ebalard <arno-LkuqDEemtHBg9hUCZPvPmw@public.gmane.org>
Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
	Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>,
	Gregory Clement
	<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] ARM: mvebu: Add RN104 SATA LEDs driven via NXP PCA9554 I2C to GPIO muxer
Date: Mon, 11 Nov 2013 21:22:24 +0100	[thread overview]
Message-ID: <52813C80.70800@gmail.com> (raw)
In-Reply-To: <8738n2hfci.fsf-LkuqDEemtHBg9hUCZPvPmw@public.gmane.org>

On 11/11/2013 09:07 PM, Arnaud Ebalard wrote:
> Hi Sebastian,
>
> Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>>> @@ -154,6 +161,30 @@
>>>    			gpios = <&gpio2 0 1>;    /* GPIO 64 Active Low */
>>>    			linux,default-trigger = "keep";
>>>    		};
>>> +
>>> +		sata1_led {
>>> +			label = "rn104:blue:sata1";
>>> +			gpios = <&pca9554 0 1>;  /* Active Low */
>>
>> Same comment as for ReadyNAS 2120 patch:
>>
>> #include <dt-bindings/gpio/gpio.h> and use GPIO_ACTIVE_HIGH/LOW.
>
> Unlike RN2120 .dts for which I was able to change all the high/low
> values for macros in a single move, if I do the changes here for this
> specific patch, the .dts file for the RN104 will contain both values and
> macros.
>
> What about the following options?:
>
>   - send a preliminary patch to change all the values for macros in RN104
>     .dts file once -rc1 is here and then resubmit the PCA9554 patch with
>     macros?
>   - have the patch applied as is and then convert the whole RN104 .dts w/
>     another patch.

I'd say, respin this with gpio.h and go for a round of cleanup later.

> Anyway, once RN2120 is accepted, I intend to spend some time doing some
> housekeeping on other readynas .dts file based on the comments you made
> recently (macros, reg, addressing, phy info, etc), and also some minor
> points (whitespaces).

Great!

Sebastian


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

  reply	other threads:[~2013-11-11 20:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-09 21:07 [PATCH] ARM: mvebu: Add RN104 SATA LEDs driven via NXP PCA9554 I2C to GPIO muxer Arnaud Ebalard
2013-11-09 21:07 ` Arnaud Ebalard
2013-11-09 23:59 ` Sebastian Hesselbarth
2013-11-09 23:59   ` Sebastian Hesselbarth
2013-11-10  0:50   ` Arnaud Ebalard
2013-11-10  0:50     ` Arnaud Ebalard
2013-11-11 20:07   ` Arnaud Ebalard
2013-11-11 20:07     ` Arnaud Ebalard
2013-11-11 20:22     ` Sebastian Hesselbarth [this message]
2013-11-11 20:22       ` Sebastian Hesselbarth

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=52813C80.70800@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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.