linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: daniel@caiaq.de (Daniel Mack)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/20] mtd: pxa3xx_nand: refuse the flash definition get from platform
Date: Mon, 24 May 2010 17:44:29 +0200	[thread overview]
Message-ID: <20100524154429.GM30801@buzzloop.caiaq.de> (raw)
In-Reply-To: <AANLkTil1mq5FBePSexz80DyT80DGqshqyJEi6Pfp0kV7@mail.gmail.com>

On Mon, May 24, 2010 at 09:40:57PM +0800, Lei Wen wrote:
> On Mon, May 24, 2010 at 9:21 PM, Mike Rapoport <mike@compulab.co.il> wrote:
> > Currently pxa3xx-nand has three operational modes:
> > - use NAND parameters supplied by the platform
> > - use presets configured by the bootloader chain
> > - use built-in NAND parameters, marked as deprecated in favor of the first
> > two
> > You remove the first two modes completely and require that each and every
> > NAND chip used on pxa3xx based platform will be added to the driver. This
> > way you make the driver less robust and harder to use for platform
> > developers, not mentioning you're breaking the existing platforms.
> > In my opinion, the driver *may* support built-in definitions for certain
> > NAND flashes and *must* support configuration of the NAND parameters by the
> > platform code and bootloader.
> >
> 
> Hi Mike,
> 
> Well... I would submit another patch set which would reserve a way
> that platform could pass its parameter setting.
> Like specify the certain type of nand chip parameter for each chip
> select. Is that ok for you?
> 
> For bootloader pass parameter method, I think this way should be
> dropped... For there is attributed which we could not tell from
> registers...

No, please don't drop this, as critical procedures in production lines
depend on this. Think about replacing a certain type of NAND chip in the
middle of a production. You would probably need to update the bootloader
for that in order to make the PXA boot from NAND. That's bad enough.

In the current system, you're done by just providing a bootloader which
sets up the NAND correctly. If you deprecate that way, the kernel would
also need an update, for actually no good reason, as all necessary
settings have already been cared for earlier. While that's not the end
of the world, it's still extra work that can be avoided.

I still haven't got your point for removing this feature. Why not leave
it in?

Daniel

  reply	other threads:[~2010-05-24 15:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-14  6:11 [PATCH 01/20] mtd: pxa3xx_nand: refuse the flash definition get from platform Haojian Zhuang
2010-05-14 11:09 ` Marc Kleine-Budde
2010-05-24  7:31 ` Mike Rapoport
2010-05-24  8:27   ` Lei Wen
2010-05-24 11:00     ` Mike Rapoport
2010-05-24 11:53       ` Lei Wen
2010-05-24 12:11         ` Marek Vasut
2010-05-24 12:31           ` Lei Wen
2010-05-24 13:05             ` Marek Vasut
2010-05-24 13:18               ` Lei Wen
2010-05-24 13:21         ` Mike Rapoport
2010-05-24 13:40           ` Lei Wen
2010-05-24 15:44             ` Daniel Mack [this message]
2010-05-25 10:21             ` Mike Rapoport
2010-05-25 12:18               ` Marek Vasut
2010-05-25 13:01               ` Lei Wen
2010-05-25 13:21                 ` Eric Miao
2010-05-26 13:35                   ` Lei Wen
2010-05-26  9:57                 ` Mike Rapoport
2010-05-26 13:42                   ` Lei Wen

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=20100524154429.GM30801@buzzloop.caiaq.de \
    --to=daniel@caiaq.de \
    --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 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).