From: Gregory CLEMENT <gregory.clement@free-electrons.com>
To: Jason Cooper <jason@lakedaemon.net>
Cc: Simon Guinot <simon.guinot@sequanux.org>,
Andrew Lunn <andrew@lunn.ch>, Bryan Wu <cooloney@gmail.com>,
Richard Purdie <rpurdie@rpsys.net>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
linux-arm-kernel@lists.infradead.org, linux-leds@vger.kernel.org,
Vincent Donnefort <vdonnefort@gmail.com>
Subject: Re: [PATCH 0/3] Add DT support for netxbig LEDs
Date: Mon, 30 Mar 2015 16:20:41 +0200 [thread overview]
Message-ID: <55195BB9.4020409@free-electrons.com> (raw)
In-Reply-To: <20150330134605.GC8688@io.lakedaemon.net>
On 30/03/2015 15:46, Jason Cooper wrote:
> On Mon, Mar 30, 2015 at 03:29:41PM +0200, Gregory CLEMENT wrote:
>> Hi Simon,
>> [...]
>>
>>>>> Hi Gregory, Andrew and Jason,
>>>>>
>>>>> This patch set seems stuck. I believe that Bryan is probably too busy to
>>>>> handle it...
>>>>>
>>>>> Is that possible to merge it via the mvebu tree ? Since only some LaCie
>>>>> boards are impacted, I think it could make sense.
>>>>
>>>> Hi Simon
>>>>
>>>> Hard one. I also have a driver stuck in led limbo.
>>>>
>>>> Last time we took a fix via mvebu, it all went messy at the last
>>>> minute. We made it very clear to Bryon we planned to take a patch via
>>>> mvebu, we had queued it via mvebu, we had sent a pull request to
>>>> arm-soc, all with no reply from Bryon. Only at the last minute did he
>>>> jump in, pull it himself and send it to Linus. That caused Olof all
>>>> sorts of problems with his tree.
>>>
>>> It's also good to keep in mind the workflow of driver maintainers who push
>>> directly to Linus. They send PRs during the merge window, and don't
>>> necessarily spend too much time in -next. Which means, if they have good
>>> filters running on lkml, they just sit down a week or so before the merge
>>> window and apply everything they have pending.
>>>
>>> For those of us who are feeding arm-soc, and are accustomed to getting things
>>> in early, this can be nerve-wracking.
>>>
>>> Brian has demonstrated that he does pick things up and get them merged. We
>>> just need to make sure that what he picks up is well tested and reviewed when
>>> he gets to it. Since there won't be time for another revision before the merge
>>> window. But hey, that's what -rc's are for. :-P
>>>
>>
>> At least what I can do is creating a led branch and merged it in the mvebu/for-next
>> branch. It will allow us to be more confident for the merge window.
>
> How would we know when to remove it? We have no reliable communication with Brian.
We will remove it when we will received an acked-by from him.
The purpose of it was to be able to do a pull request as soon as we know
that either Bryan will take it or let us take the full series.
In the mean time if Bryan also applied the patch in is leds/for-next branch
it should not be a problem as the patch will be the same.
Thanks,
Gregory
>
> thx,
>
> Jason.
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: gregory.clement@free-electrons.com (Gregory CLEMENT)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] Add DT support for netxbig LEDs
Date: Mon, 30 Mar 2015 16:20:41 +0200 [thread overview]
Message-ID: <55195BB9.4020409@free-electrons.com> (raw)
In-Reply-To: <20150330134605.GC8688@io.lakedaemon.net>
On 30/03/2015 15:46, Jason Cooper wrote:
> On Mon, Mar 30, 2015 at 03:29:41PM +0200, Gregory CLEMENT wrote:
>> Hi Simon,
>> [...]
>>
>>>>> Hi Gregory, Andrew and Jason,
>>>>>
>>>>> This patch set seems stuck. I believe that Bryan is probably too busy to
>>>>> handle it...
>>>>>
>>>>> Is that possible to merge it via the mvebu tree ? Since only some LaCie
>>>>> boards are impacted, I think it could make sense.
>>>>
>>>> Hi Simon
>>>>
>>>> Hard one. I also have a driver stuck in led limbo.
>>>>
>>>> Last time we took a fix via mvebu, it all went messy at the last
>>>> minute. We made it very clear to Bryon we planned to take a patch via
>>>> mvebu, we had queued it via mvebu, we had sent a pull request to
>>>> arm-soc, all with no reply from Bryon. Only at the last minute did he
>>>> jump in, pull it himself and send it to Linus. That caused Olof all
>>>> sorts of problems with his tree.
>>>
>>> It's also good to keep in mind the workflow of driver maintainers who push
>>> directly to Linus. They send PRs during the merge window, and don't
>>> necessarily spend too much time in -next. Which means, if they have good
>>> filters running on lkml, they just sit down a week or so before the merge
>>> window and apply everything they have pending.
>>>
>>> For those of us who are feeding arm-soc, and are accustomed to getting things
>>> in early, this can be nerve-wracking.
>>>
>>> Brian has demonstrated that he does pick things up and get them merged. We
>>> just need to make sure that what he picks up is well tested and reviewed when
>>> he gets to it. Since there won't be time for another revision before the merge
>>> window. But hey, that's what -rc's are for. :-P
>>>
>>
>> At least what I can do is creating a led branch and merged it in the mvebu/for-next
>> branch. It will allow us to be more confident for the merge window.
>
> How would we know when to remove it? We have no reliable communication with Brian.
We will remove it when we will received an acked-by from him.
The purpose of it was to be able to do a pull request as soon as we know
that either Bryan will take it or let us take the full series.
In the mean time if Bryan also applied the patch in is leds/for-next branch
it should not be a problem as the patch will be the same.
Thanks,
Gregory
>
> thx,
>
> Jason.
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2015-03-30 14:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 15:04 [PATCH 0/3] Add DT support for netxbig LEDs Simon Guinot
2015-02-23 15:04 ` Simon Guinot
2015-02-23 15:04 ` [PATCH 1/3] leds: netxbig: add device tree binding Simon Guinot
2015-02-23 15:04 ` Simon Guinot
2015-02-23 15:04 ` [PATCH 2/3] ARM: Kirkwood: add LED DT entries for netxbig boards Simon Guinot
2015-02-23 15:04 ` Simon Guinot
2015-02-23 15:04 ` [PATCH 3/3] ARM: mvebu: remove static LED setup " Simon Guinot
2015-02-23 15:04 ` Simon Guinot
2015-03-09 9:41 ` [PATCH 0/3] Add DT support for netxbig LEDs Simon Guinot
2015-03-09 9:41 ` Simon Guinot
2015-03-16 16:01 ` Gregory CLEMENT
2015-03-16 16:01 ` Gregory CLEMENT
2015-03-30 8:30 ` Simon Guinot
2015-03-30 8:30 ` Simon Guinot
2015-03-30 12:30 ` Andrew Lunn
2015-03-30 12:30 ` Andrew Lunn
2015-03-30 13:22 ` Jason Cooper
2015-03-30 13:22 ` Jason Cooper
2015-03-30 13:29 ` Gregory CLEMENT
2015-03-30 13:29 ` Gregory CLEMENT
2015-03-30 13:46 ` Jason Cooper
2015-03-30 13:46 ` Jason Cooper
2015-03-30 14:20 ` Gregory CLEMENT [this message]
2015-03-30 14:20 ` Gregory CLEMENT
2015-03-23 10:31 ` Simon Guinot
2015-03-23 10:31 ` Simon Guinot
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=55195BB9.4020409@free-electrons.com \
--to=gregory.clement@free-electrons.com \
--cc=andrew@lunn.ch \
--cc=cooloney@gmail.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-leds@vger.kernel.org \
--cc=rpurdie@rpsys.net \
--cc=sebastian.hesselbarth@gmail.com \
--cc=simon.guinot@sequanux.org \
--cc=vdonnefort@gmail.com \
/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.