All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Olof Johansson <olof@lixom.net>,
	Ludovic Desroches <ludovic.desroches@atmel.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] at91: platform data for atmel-mci (for 3.5)
Date: Wed, 20 Jun 2012 09:45:34 +0200	[thread overview]
Message-ID: <4FE17F9E.3090009@atmel.com> (raw)
In-Reply-To: <CAOesGMi+2-xEv5+s0xEX7UzoC500q87zrXV4bHynQyzXE8Virw@mail.gmail.com>

On 06/18/2012 03:49 PM, Olof Johansson :
> Hi,
> 
> On Wed, Jun 13, 2012 at 9:48 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> On 06/04/2012 05:48 PM, Nicolas Ferre :
>>> On 05/31/2012 11:04 PM, Olof Johansson :
>>>> Hi Nicolas,
>>>>
>>>> On Thu, May 31, 2012 at 12:50 AM, Nicolas Ferre <nicolas.ferre@atmel.com
>>>> <mailto:nicolas.ferre@atmel.com>> wrote:
>>>>
>>>>     On 05/24/2012 05:12 PM, Nicolas Ferre :
>>>>     > Hi Arnd, hi Olof,
>>>>
>>>>     Ping?
>>>>
>>>>     (or maybe you will have a look at this after the merge window...)
>>>>
>>>>
>>>> So, I looked at this branch yesterday but I wasn't entirely happy with
>>>> the number of ifdefs it adds.
>>>
>>> Unfortunately, this is the usual shape of any devices/boards files on
>>> AT91. This amount will be reduced when we remove the old driver and when
>>> we move newer/popular devices to Device Tree...
>>>
>>>> If the idea is to deprecate the old driver, wouldn't it make more sense
>>>> to just cut everyone over instead of having both sets of setup in the
>>>> kernel?
>>>
>>> Well, the old driver has existed since a very long time and I think that
>>> people are used to it on oldest platforms. This is why we put in place a
>>> overlapping period. This way we hope that the transition will be smoother.
>>> On the other hand, the old code will be removed in 3.7 so the
>>> overlapping period will not be so long.
>>> I hope that it will allow people to track bugs if some are remaining and
>>> switch to newer driver easily.
>>
>> Olof, Arnd,
>>
>> So, do you have made up your mind about this pull request?
> 
> Sorry for the delays in handling this, I should have been quicker at replying.
> 
> That said, the driver is staged for removal in 3.7, and this patch is
> 3.6 material at this time. But I think it makes sense to cut every
> in-tree board over completely one release before the driver is
> removed, and thus not keep the old platform data around for them.
> 
> That way the out-of-tree users still have a one-release grace period,
> but everyone with an in-tree board (and the reference platforms) will
> move over sooner. I think I would prefer that over having all these
> ifdefs in the tree, even if it's just for one release.
> 
> I could be convinced otherwise if there's a good reason though. Either
> way, 3.6 is the way to go.

Fair enough, we will prepare a patch to remove the old platform data
combined with this patch. We will integrate in an "at91-3.6-soc"
series/branch that we will submit to you soon.

Thanks, best regards,
-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] at91: platform data for atmel-mci (for 3.5)
Date: Wed, 20 Jun 2012 09:45:34 +0200	[thread overview]
Message-ID: <4FE17F9E.3090009@atmel.com> (raw)
In-Reply-To: <CAOesGMi+2-xEv5+s0xEX7UzoC500q87zrXV4bHynQyzXE8Virw@mail.gmail.com>

On 06/18/2012 03:49 PM, Olof Johansson :
> Hi,
> 
> On Wed, Jun 13, 2012 at 9:48 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> On 06/04/2012 05:48 PM, Nicolas Ferre :
>>> On 05/31/2012 11:04 PM, Olof Johansson :
>>>> Hi Nicolas,
>>>>
>>>> On Thu, May 31, 2012 at 12:50 AM, Nicolas Ferre <nicolas.ferre@atmel.com
>>>> <mailto:nicolas.ferre@atmel.com>> wrote:
>>>>
>>>>     On 05/24/2012 05:12 PM, Nicolas Ferre :
>>>>     > Hi Arnd, hi Olof,
>>>>
>>>>     Ping?
>>>>
>>>>     (or maybe you will have a look at this after the merge window...)
>>>>
>>>>
>>>> So, I looked at this branch yesterday but I wasn't entirely happy with
>>>> the number of ifdefs it adds.
>>>
>>> Unfortunately, this is the usual shape of any devices/boards files on
>>> AT91. This amount will be reduced when we remove the old driver and when
>>> we move newer/popular devices to Device Tree...
>>>
>>>> If the idea is to deprecate the old driver, wouldn't it make more sense
>>>> to just cut everyone over instead of having both sets of setup in the
>>>> kernel?
>>>
>>> Well, the old driver has existed since a very long time and I think that
>>> people are used to it on oldest platforms. This is why we put in place a
>>> overlapping period. This way we hope that the transition will be smoother.
>>> On the other hand, the old code will be removed in 3.7 so the
>>> overlapping period will not be so long.
>>> I hope that it will allow people to track bugs if some are remaining and
>>> switch to newer driver easily.
>>
>> Olof, Arnd,
>>
>> So, do you have made up your mind about this pull request?
> 
> Sorry for the delays in handling this, I should have been quicker at replying.
> 
> That said, the driver is staged for removal in 3.7, and this patch is
> 3.6 material at this time. But I think it makes sense to cut every
> in-tree board over completely one release before the driver is
> removed, and thus not keep the old platform data around for them.
> 
> That way the out-of-tree users still have a one-release grace period,
> but everyone with an in-tree board (and the reference platforms) will
> move over sooner. I think I would prefer that over having all these
> ifdefs in the tree, even if it's just for one release.
> 
> I could be convinced otherwise if there's a good reason though. Either
> way, 3.6 is the way to go.

Fair enough, we will prepare a patch to remove the old platform data
combined with this patch. We will integrate in an "at91-3.6-soc"
series/branch that we will submit to you soon.

Thanks, best regards,
-- 
Nicolas Ferre

  reply	other threads:[~2012-06-20  7:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-24 15:12 [GIT PULL] at91: platform data for atmel-mci (for 3.5) Nicolas Ferre
2012-05-24 15:12 ` Nicolas Ferre
2012-05-31  7:50 ` Nicolas Ferre
2012-05-31  7:50   ` Nicolas Ferre
2012-05-31 21:04   ` Olof Johansson
2012-06-04 15:48     ` Nicolas Ferre
2012-06-04 15:48       ` Nicolas Ferre
2012-06-13 16:48       ` Nicolas Ferre
2012-06-13 16:48         ` Nicolas Ferre
2012-06-18 13:49         ` Olof Johansson
2012-06-18 13:49           ` Olof Johansson
2012-06-20  7:45           ` Nicolas Ferre [this message]
2012-06-20  7:45             ` Nicolas Ferre
2012-07-25 20:06   ` Arnd Bergmann
2012-07-25 20:06     ` Arnd Bergmann
2012-07-26  8:35     ` ludovic.desroches
2012-08-07 13:05       ` Nicolas Ferre
2012-08-10  7:46     ` Nicolas Ferre
2012-08-10  7:46       ` Nicolas Ferre

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=4FE17F9E.3090009@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludovic.desroches@atmel.com \
    --cc=olof@lixom.net \
    --cc=plagnioj@jcrosoft.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.