All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	Andrew Victor <linux@maxim.org.za>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org,
	Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ATMEL, AVR32: inline nand partition table access
Date: Mon, 06 Jun 2011 10:05:42 +0200	[thread overview]
Message-ID: <4DEC8A56.1030707@atmel.com> (raw)
In-Reply-To: <BANLkTi=s4kGg5NKrzNs1nu8S00Ue_Zv8vQ@mail.gmail.com>

Le 01/06/2011 16:54, Dmitry Eremin-Solenikov :
> On 6/1/11, Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> wrote:
>> On Sun, 2011-05-29 at 17:49 +0400, Dmitry Eremin-Solenikov wrote:
>>> Currently atmel_nand driver used by AT91 and AVR32 calls a special
>>> callback
>>> which return nand partition table and number of partitions. However in all
>>> boards this callback returns just static data. So drop this callback and
>>> make atmel_nand use partition table provided statically via platform_data.
>>>
>>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>
>> Thanks for this update, always nice seeing code being optimized. I
>> really can't recall why it was made like this in the first place...
>>
>> For the AVR32 related parts:
>>
>> Acked-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
>>
>> <snipp diff>
>>
>> Will this go through the linux-mtd tree (since it spans two archs) or
>> should it go through an arch tree?
> 
> On one hand, I'd prefer for this to go through the linux-mtd, if noone objects,
> as I'd also like to submit several (a pile) patches cleaning up mtd
> partitioning, which would depend on this.
> 
> OTOH, I think there will be a cleanup of AT91 platform, which would bring
> lot's of conflicts with this patch, if it goes through linux-mtd.


I am in favor for a mainline inclusion through linux-mtd tree.

On the AT91 side, we will have to take this inclusion into account to
avoid merge conflicts... But as long as this cleanup is not ready yet, I
prefer to go forward this way.

For that purpose, that would be good to see this patch in linux-next.

Thanks to all of you, bye,
-- 
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: [PATCH] ATMEL, AVR32: inline nand partition table access
Date: Mon, 06 Jun 2011 10:05:42 +0200	[thread overview]
Message-ID: <4DEC8A56.1030707@atmel.com> (raw)
In-Reply-To: <BANLkTi=s4kGg5NKrzNs1nu8S00Ue_Zv8vQ@mail.gmail.com>

Le 01/06/2011 16:54, Dmitry Eremin-Solenikov :
> On 6/1/11, Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> wrote:
>> On Sun, 2011-05-29 at 17:49 +0400, Dmitry Eremin-Solenikov wrote:
>>> Currently atmel_nand driver used by AT91 and AVR32 calls a special
>>> callback
>>> which return nand partition table and number of partitions. However in all
>>> boards this callback returns just static data. So drop this callback and
>>> make atmel_nand use partition table provided statically via platform_data.
>>>
>>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>
>> Thanks for this update, always nice seeing code being optimized. I
>> really can't recall why it was made like this in the first place...
>>
>> For the AVR32 related parts:
>>
>> Acked-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
>>
>> <snipp diff>
>>
>> Will this go through the linux-mtd tree (since it spans two archs) or
>> should it go through an arch tree?
> 
> On one hand, I'd prefer for this to go through the linux-mtd, if noone objects,
> as I'd also like to submit several (a pile) patches cleaning up mtd
> partitioning, which would depend on this.
> 
> OTOH, I think there will be a cleanup of AT91 platform, which would bring
> lot's of conflicts with this patch, if it goes through linux-mtd.


I am in favor for a mainline inclusion through linux-mtd tree.

On the AT91 side, we will have to take this inclusion into account to
avoid merge conflicts... But as long as this cleanup is not ready yet, I
prefer to go forward this way.

For that purpose, that would be good to see this patch in linux-next.

Thanks to all of you, bye,
-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	Andrew Victor <linux@maxim.org.za>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	David Woodhouse <dwmw2@infradead.org>
Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] ATMEL, AVR32: inline nand partition table access
Date: Mon, 06 Jun 2011 10:05:42 +0200	[thread overview]
Message-ID: <4DEC8A56.1030707@atmel.com> (raw)
In-Reply-To: <BANLkTi=s4kGg5NKrzNs1nu8S00Ue_Zv8vQ@mail.gmail.com>

Le 01/06/2011 16:54, Dmitry Eremin-Solenikov :
> On 6/1/11, Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> wrote:
>> On Sun, 2011-05-29 at 17:49 +0400, Dmitry Eremin-Solenikov wrote:
>>> Currently atmel_nand driver used by AT91 and AVR32 calls a special
>>> callback
>>> which return nand partition table and number of partitions. However in all
>>> boards this callback returns just static data. So drop this callback and
>>> make atmel_nand use partition table provided statically via platform_data.
>>>
>>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>
>> Thanks for this update, always nice seeing code being optimized. I
>> really can't recall why it was made like this in the first place...
>>
>> For the AVR32 related parts:
>>
>> Acked-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
>>
>> <snipp diff>
>>
>> Will this go through the linux-mtd tree (since it spans two archs) or
>> should it go through an arch tree?
> 
> On one hand, I'd prefer for this to go through the linux-mtd, if noone objects,
> as I'd also like to submit several (a pile) patches cleaning up mtd
> partitioning, which would depend on this.
> 
> OTOH, I think there will be a cleanup of AT91 platform, which would bring
> lot's of conflicts with this patch, if it goes through linux-mtd.


I am in favor for a mainline inclusion through linux-mtd tree.

On the AT91 side, we will have to take this inclusion into account to
avoid merge conflicts... But as long as this cleanup is not ready yet, I
prefer to go forward this way.

For that purpose, that would be good to see this patch in linux-next.

Thanks to all of you, bye,
-- 
Nicolas Ferre


  parent reply	other threads:[~2011-06-06  8:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-29 13:49 [PATCH] ATMEL, AVR32: inline nand partition table access Dmitry Eremin-Solenikov
2011-07-08 17:33 ` Dmitry Eremin-Solenikov
2011-05-29 13:49 ` Dmitry Eremin-Solenikov
2011-06-01 13:31 ` Nicolas Ferre
2011-06-01 13:31   ` Nicolas Ferre
2011-06-01 13:31   ` Nicolas Ferre
2011-06-01 13:32 ` Hans-Christian Egtvedt
2011-06-01 13:32   ` Hans-Christian Egtvedt
2011-06-01 13:32   ` Hans-Christian Egtvedt
2011-06-01 14:54   ` Dmitry Eremin-Solenikov
2011-06-01 14:54     ` Dmitry Eremin-Solenikov
2011-06-01 14:54     ` Dmitry Eremin-Solenikov
2011-06-01 15:01     ` Artem Bityutskiy
2011-06-01 15:01       ` Artem Bityutskiy
2011-06-01 15:01       ` Artem Bityutskiy
2011-06-06  5:49     ` Hans-Christian Egtvedt
2011-06-06  5:49       ` Hans-Christian Egtvedt
2011-06-06  5:49       ` Hans-Christian Egtvedt
2011-06-06  8:05     ` Nicolas Ferre [this message]
2011-06-06  8:05       ` Nicolas Ferre
2011-06-06  8:05       ` Nicolas Ferre
2011-06-16 13:48       ` Jean-Christophe PLAGNIOL-VILLARD
2011-06-16 13:48         ` Jean-Christophe PLAGNIOL-VILLARD
2011-06-16 13:48         ` Jean-Christophe PLAGNIOL-VILLARD

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=4DEC8A56.1030707@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --cc=dbaryshkov@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=hans-christian.egtvedt@atmel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux@maxim.org.za \
    --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.