From: Artem Bityutskiy <dedekind1@gmail.com>
To: Huang Shijie <b32955@freescale.com>
Cc: linux@arm.linux.org.uk, David.Woodhouse@intel.com,
linux-mtd@lists.infradead.org,
Florian Fainelli <ffainelli@freebox.fr>,
shijie8@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V3 3/6] MTD : add the database for the NANDs
Date: Thu, 31 Mar 2011 13:10:48 +0300 [thread overview]
Message-ID: <1301566248.2828.40.camel@localhost> (raw)
In-Reply-To: <4D92F277.7060607@freescale.com>
Hi,
On Wed, 2011-03-30 at 17:05 +0800, Huang Shijie wrote:
> > On Wednesday 30 March 2011 10:40:10 Huang Shijie wrote:
> >> This is a new database for the NANDs which is searched by the id_bytes.
> > drivers/mtd//nand/nand_base.c will be able to detect all of your chips listed
> > below based on the ids present in drivers/mtd/nand/nand_ids.c
> >
> yes.
>
> But I will use the new database to replace the old one.
>
> I will submit new patches to modify the generic code if my driver is
> accepted.
Sorry, but this is not how the opensource community works. The common
practice everywhere in the kernel is that if the generic code/framework
is too limiting, you first change the framework, then start using it. We
do not do things like - I'll first create my custom solution, and then I
promise I will change the framework.
Again, this is not just MTD, this is everywhere in the kernel. This is
how linux goes forward - we force people to improve common code and
accept their drivers, and everyone benefits form this. Yes, this is more
work for you, of course, sorry :-)
> > If you have new chips to support in the future, you should add them in
> > drivers/mtd/nand/nand_ids.c and not keep this file.
> >
> The data structure nand_flash_dev{} does not contain enough information.
> So I want to the nand_device_info{} to replace it in future.
Just add this information, if it is of generic nature (like SLC/MLC
flag, required ECC strength, etc).
> > I still do not understand why this would be needed, is it because the generic
> > code does not provide enough informations for your driver?
> >
> yes.
>
> IMHO, the generic code is somehow trapped in a wrong way. :(
Fix this please :-)
> Paring the id bytes is not sufficient to get all the information you
> need which is faced by me.
Fix this too :-)
> What's more, I think the paring code is ugly, see the nand_get_flash_type().
You are welcome to fix this. There is _a lot_ of ugly code in MTD
because no one loves it. Give it some love :-)
> Why not create a new database which contains all the necessary
> information for a nand, and can be easy
> find by the id bytes as the keyword?
You can create this database by extending/improving/cleaning up the
existing code base with a nice series of patches.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
WARNING: multiple messages have this Message-ID (diff)
From: dedekind1@gmail.com (Artem Bityutskiy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 3/6] MTD : add the database for the NANDs
Date: Thu, 31 Mar 2011 13:10:48 +0300 [thread overview]
Message-ID: <1301566248.2828.40.camel@localhost> (raw)
In-Reply-To: <4D92F277.7060607@freescale.com>
Hi,
On Wed, 2011-03-30 at 17:05 +0800, Huang Shijie wrote:
> > On Wednesday 30 March 2011 10:40:10 Huang Shijie wrote:
> >> This is a new database for the NANDs which is searched by the id_bytes.
> > drivers/mtd//nand/nand_base.c will be able to detect all of your chips listed
> > below based on the ids present in drivers/mtd/nand/nand_ids.c
> >
> yes.
>
> But I will use the new database to replace the old one.
>
> I will submit new patches to modify the generic code if my driver is
> accepted.
Sorry, but this is not how the opensource community works. The common
practice everywhere in the kernel is that if the generic code/framework
is too limiting, you first change the framework, then start using it. We
do not do things like - I'll first create my custom solution, and then I
promise I will change the framework.
Again, this is not just MTD, this is everywhere in the kernel. This is
how linux goes forward - we force people to improve common code and
accept their drivers, and everyone benefits form this. Yes, this is more
work for you, of course, sorry :-)
> > If you have new chips to support in the future, you should add them in
> > drivers/mtd/nand/nand_ids.c and not keep this file.
> >
> The data structure nand_flash_dev{} does not contain enough information.
> So I want to the nand_device_info{} to replace it in future.
Just add this information, if it is of generic nature (like SLC/MLC
flag, required ECC strength, etc).
> > I still do not understand why this would be needed, is it because the generic
> > code does not provide enough informations for your driver?
> >
> yes.
>
> IMHO, the generic code is somehow trapped in a wrong way. :(
Fix this please :-)
> Paring the id bytes is not sufficient to get all the information you
> need which is faced by me.
Fix this too :-)
> What's more, I think the paring code is ugly, see the nand_get_flash_type().
You are welcome to fix this. There is _a lot_ of ugly code in MTD
because no one loves it. Give it some love :-)
> Why not create a new database which contains all the necessary
> information for a nand, and can be easy
> find by the id bytes as the keyword?
You can create this database by extending/improving/cleaning up the
existing code base with a nice series of patches.
--
Best Regards,
Artem Bityutskiy (????? ????????)
next prev parent reply other threads:[~2011-03-31 10:10 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-30 8:40 [PATCH V3 0/6] add the GPMI controller driver for IMX23/IMX28 Huang Shijie
2011-03-30 8:40 ` Huang Shijie
2011-03-30 8:40 ` [PATCH V3 1/6] ARM: add GPMI support for imx23/imx28 Huang Shijie
2011-03-30 8:40 ` Huang Shijie
2011-03-30 8:40 ` [PATCH V3 2/6] dmaengine: change the flags of request_irq() Huang Shijie
2011-03-30 8:40 ` Huang Shijie
2011-03-30 9:03 ` Lothar Waßmann
2011-03-30 9:03 ` Lothar Waßmann
2011-03-30 9:13 ` Shawn Guo
2011-03-30 9:13 ` Shawn Guo
2011-03-30 9:15 ` Lothar Waßmann
2011-03-30 9:15 ` Lothar Waßmann
2011-03-30 9:44 ` Huang Shijie
2011-03-30 9:44 ` Huang Shijie
2011-03-31 7:02 ` [PATCH V3 2/6] dmaengine: add interrupt check for GPMI controller Huang Shijie
2011-03-31 7:02 ` Huang Shijie
2011-03-31 8:02 ` Lothar Waßmann
2011-03-31 8:02 ` Lothar Waßmann
2011-03-31 8:50 ` Huang Shijie
2011-03-31 8:50 ` Huang Shijie
2011-03-31 8:50 ` Lothar Waßmann
2011-03-31 8:50 ` Lothar Waßmann
2011-03-31 9:08 ` Huang Shijie
2011-03-31 9:08 ` Huang Shijie
2011-03-31 9:34 ` Lothar Waßmann
2011-03-31 9:34 ` Lothar Waßmann
2011-04-01 3:47 ` Shawn Guo
2011-04-01 3:47 ` Shawn Guo
2011-04-01 4:36 ` Huang Shijie
2011-04-01 4:36 ` Huang Shijie
2011-03-30 8:40 ` [PATCH V3 3/6] MTD : add the database for the NANDs Huang Shijie
2011-03-30 8:40 ` Huang Shijie
2011-03-30 8:46 ` Florian Fainelli
2011-03-30 8:46 ` Florian Fainelli
2011-03-30 9:05 ` Huang Shijie
2011-03-30 9:05 ` Huang Shijie
2011-03-30 9:23 ` Florian Fainelli
2011-03-30 9:23 ` Florian Fainelli
2011-03-30 9:54 ` Huang Shijie
2011-03-30 9:54 ` Huang Shijie
2011-03-31 10:10 ` Artem Bityutskiy [this message]
2011-03-31 10:10 ` Artem Bityutskiy
2011-03-31 14:17 ` Huang Shijie
2011-03-31 14:17 ` Huang Shijie
2011-09-14 15:44 ` Brian Norris
2011-09-14 15:44 ` Brian Norris
2011-09-15 2:21 ` Huang Shijie
2011-09-15 2:21 ` Huang Shijie
2011-09-16 8:11 ` Angus CLARK
2011-11-21 22:18 ` Brian Norris
2011-12-06 12:06 ` Angus CLARK
2011-11-24 3:11 ` Huang Shijie
2011-11-24 3:11 ` Huang Shijie
2011-03-30 8:40 ` [PATCH V3 4/6] MTD : add the common code for GPMI controller driver Huang Shijie
2011-07-08 16:46 ` Huang Shijie
2011-03-30 8:40 ` [PATCH V3 5/6] MTD: add support for imx23 and imx28 Huang Shijie
2011-03-30 8:40 ` Huang Shijie
2011-03-30 8:40 ` [PATCH V3 6/6] MTD : add GPMI driver in the config and Makefile Huang Shijie
2011-03-30 8:40 ` Huang Shijie
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=1301566248.2828.40.camel@localhost \
--to=dedekind1@gmail.com \
--cc=David.Woodhouse@intel.com \
--cc=b32955@freescale.com \
--cc=ffainelli@freebox.fr \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=shijie8@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.