From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Michal Suchanek <hramrach@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Petros Angelatos <petrosagg@gmail.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] New NAND chip IDs
Date: Tue, 28 Jul 2015 17:10:13 +0200 [thread overview]
Message-ID: <20150728171013.58cbc608@bbrezillon> (raw)
In-Reply-To: <55B79696.40906@redhat.com>
Hi Hans,
On Tue, 28 Jul 2015 16:49:58 +0200
Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 07/28/2015 04:29 PM, Michal Suchanek wrote:
> > Hello,
> >
> > the NAND chips on Cubietech boards are not known to Linux.
> >
> > I used Petros Angelatos' patch from sunxi experimental tree for one chip and
> > added another chip.
> >
> > I hope it's ok to send both patches to avoid merge conflict.
>
> I do not think that these patches are a good idea, this will lead to an
> ever growing manual maintained list of ids, and that is not maintainable
> IMHO.
>
> For Samsung chips we only need the ecc strength and size the rest is already
> detected on the fly, and I've a patch in my personal tree to get the
> ecc strengt and size from the nand without needing to have an entry per
> chip:
>
> https://github.com/jwrdegoede/linux-sunxi/commit/53b335d33232753b7aa70298009158baadf5a6bf
>
> This is IMHO a much better solution.
Hm, IMHO it's not: the nand ids table also store information about
supported NAND timings, and maybe we'll have to add new things (like
the read-retry implementation to use for a specific chip).
Moreover, this information can be automatically deduced from the NAND
id, and we try to keep discoverable info out of the DT.
I agree that keeping a list of full IDs is not ideal, but it's far
better than having to duplicate this information in all the board DTs
using a given NAND chip.
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-07-28 15:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 14:29 [PATCH 0/2] New NAND chip IDs Michal Suchanek
2015-07-28 14:38 ` [PATCH 1/2] mtd: nand: add Samsung's K9GBG08U0B to nand_ids table Michal Suchanek
2015-07-28 14:38 ` [PATCH 2/2] mtd: nand: add Samsung K9GBG08U0A chip id Michal Suchanek
2015-07-28 14:49 ` [PATCH 0/2] New NAND chip IDs Hans de Goede
2015-07-28 15:10 ` Boris Brezillon [this message]
2015-07-28 15:13 ` Boris Brezillon
2015-07-28 15:16 ` Hans de Goede
2015-07-28 15:19 ` Boris Brezillon
2015-07-28 15:30 ` Boris Brezillon
2015-07-28 15:32 ` Hans de Goede
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=20150728171013.58cbc608@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=hdegoede@redhat.com \
--cc=hramrach@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=petrosagg@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.