| Message ID | 1294745619-7142-1-git-send-email-dbaryshkov@gmail.com |
|---|---|
| State | New, archived |
| Headers | show |
On Tuesday 11 January 2011 12:33:35 Dmitry Eremin-Solenikov wrote: > Move mtdconcat to be an integral part of the mtd core. It's a tiny bit > of code, which bears 'say Y if you don't know what to do' note in the > Kconfig. OTOH there are several ugly ifdefs depending on the MTD_CONCAT. > So, making MTD_CONCAT support mandatory will allow us to clean up code a > lot. > > Kconfig entry is changed to be a bool defaulting to Y, so all code > pieces depending on it, will have MTD_CONCAT Kconfig symbol and > CONFIG_MTD_CONCAT define. This will be removed in one of next patches. Whole patch series looks good. Thanks. I'm not sure if it makes more sense to squash the MTD patches into one patch. Either way I'm fine with it, so: Acked-by: Stefan Roese <sr@denx.de> for the whole patch series. Cheers, Stefan
Hello, On Wed, Jan 12, 2011 at 4:25 PM, Stefan Roese <sr@denx.de> wrote: > On Tuesday 11 January 2011 12:33:35 Dmitry Eremin-Solenikov wrote: >> Move mtdconcat to be an integral part of the mtd core. It's a tiny bit >> of code, which bears 'say Y if you don't know what to do' note in the >> Kconfig. OTOH there are several ugly ifdefs depending on the MTD_CONCAT. >> So, making MTD_CONCAT support mandatory will allow us to clean up code a >> lot. >> >> Kconfig entry is changed to be a bool defaulting to Y, so all code >> pieces depending on it, will have MTD_CONCAT Kconfig symbol and >> CONFIG_MTD_CONCAT define. This will be removed in one of next patches. > > Whole patch series looks good. Thanks. I'm not sure if it makes more sense to > squash the MTD patches into one patch. Either way I'm fine with it, so: > > Acked-by: Stefan Roese <sr@denx.de> > > for the whole patch series. What about this series? Will it find it's way to kernel or should I do some more steps?
On Tue, 2011-02-15 at 17:07 +0300, Dmitry Eremin-Solenikov wrote: > Hello, > > On Wed, Jan 12, 2011 at 4:25 PM, Stefan Roese <sr@denx.de> wrote: > > On Tuesday 11 January 2011 12:33:35 Dmitry Eremin-Solenikov wrote: > >> Move mtdconcat to be an integral part of the mtd core. It's a tiny bit > >> of code, which bears 'say Y if you don't know what to do' note in the > >> Kconfig. OTOH there are several ugly ifdefs depending on the MTD_CONCAT. > >> So, making MTD_CONCAT support mandatory will allow us to clean up code a > >> lot. > >> > >> Kconfig entry is changed to be a bool defaulting to Y, so all code > >> pieces depending on it, will have MTD_CONCAT Kconfig symbol and > >> CONFIG_MTD_CONCAT define. This will be removed in one of next patches. > > > > Whole patch series looks good. Thanks. I'm not sure if it makes more sense to > > squash the MTD patches into one patch. Either way I'm fine with it, so: > > > > Acked-by: Stefan Roese <sr@denx.de> > > > > for the whole patch series. > > What about this series? Will it find it's way to kernel or should I do > some more steps? They still sit in my l2-mtd-2.6.git tree. You are not expected to do anything, David should look at them an pick them (or reject with an e-mail explaining the reasons) later. Usually he does this closer to the merge window.
On 2/25/11, Artem Bityutskiy <dedekind1@gmail.com> wrote: > On Tue, 2011-02-15 at 17:07 +0300, Dmitry Eremin-Solenikov wrote: >> What about this series? Will it find it's way to kernel or should I do >> some more steps? > > They still sit in my l2-mtd-2.6.git tree. You are not expected to do > anything, David should look at them an pick them (or reject with an > e-mail explaining the reasons) later. Usually he does this closer to the > merge window. Fine, thank you for the explanation. I was just asking because I did not know the process behind MTD subsystem. BTW: I've heard the idea about making MTD partitions also a mandatory functionality of MTD subsystem. If I make such patches, will stand a chance to be accepted, or it's still better to keep MTD parts an option?
On Fri, 2011-02-25 at 13:05 +0300, Dmitry Eremin-Solenikov wrote: > On 2/25/11, Artem Bityutskiy <dedekind1@gmail.com> wrote: > > On Tue, 2011-02-15 at 17:07 +0300, Dmitry Eremin-Solenikov wrote: > >> What about this series? Will it find it's way to kernel or should I do > >> some more steps? > > > > They still sit in my l2-mtd-2.6.git tree. You are not expected to do > > anything, David should look at them an pick them (or reject with an > > e-mail explaining the reasons) later. Usually he does this closer to the > > merge window. > > Fine, thank you for the explanation. I was just asking because I did not > know the process behind MTD subsystem. It should probably be documented. But how it works is that there is David who is the maintainer. But he is very busy. And there is me who helps him. I collect patches in my l2 tree. I review those I can and put my signed-off-by or some other tag. I do not review all patches, and those I did not review do not have my signed-off-by. Then at some point David takes a look at my tree and takes patches from there. If there are patches he dislikes, he usually replies with a comment and does not take the patch. So, in your case, the patches are still waiting for his attention. In the worst case, he picks patches from my tree when the merge window opens. > BTW: I've heard the idea about making MTD partitions also a mandatory > functionality of MTD subsystem. If I make such patches, will stand a chance > to be accepted, or it's still better to keep MTD parts an option? In my humble opinion which I think was supported by other people - yes, the config option is useless and only contributes to mess. I personally believe we need to kill this. And I just asked David, he does not mind.
On Fri, 2011-02-25 at 13:05 +0300, Dmitry Eremin-Solenikov wrote: > On 2/25/11, Artem Bityutskiy <dedekind1@gmail.com> wrote: > > On Tue, 2011-02-15 at 17:07 +0300, Dmitry Eremin-Solenikov wrote: > >> What about this series? Will it find it's way to kernel or should I do > >> some more steps? > > > > They still sit in my l2-mtd-2.6.git tree. You are not expected to do > > anything, David should look at them an pick them (or reject with an > > e-mail explaining the reasons) later. Usually he does this closer to the > > merge window. > > Fine, thank you for the explanation. I was just asking because I did not > know the process behind MTD subsystem. > > BTW: I've heard the idea about making MTD partitions also a mandatory > functionality of MTD subsystem. If I make such patches, will stand a chance > to be accepted, or it's still better to keep MTD parts an option? Yeah, it is obvious that CONFIG_MTD_PARTITIONS is a problem: [dedekind@eru linux-2.6 (master)]$ grep -r CONFIG_MTD_PARTITIONS drivers/mtd/* | wc -l 128 If you could clean this up, that would be great!
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 1e2cbf5..38ca5f2 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -34,7 +34,8 @@ config MTD_TESTS various checks and verifications when loaded. config MTD_CONCAT - tristate "MTD concatenating support" + bool + default y help Support for concatenating several MTD devices into a single (virtual) one. This allows you to have -for example- a JFFS(2) diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 760abc5..a166b71 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -4,10 +4,9 @@ # Core functionality. obj-$(CONFIG_MTD) += mtd.o -mtd-y := mtdcore.o mtdsuper.o +mtd-y := mtdcore.o mtdsuper.o mtdconcat.o mtd-$(CONFIG_MTD_PARTITIONS) += mtdpart.o -obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
Move mtdconcat to be an integral part of the mtd core. It's a tiny bit of code, which bears 'say Y if you don't know what to do' note in the Kconfig. OTOH there are several ugly ifdefs depending on the MTD_CONCAT. So, making MTD_CONCAT support mandatory will allow us to clean up code a lot. Kconfig entry is changed to be a bool defaulting to Y, so all code pieces depending on it, will have MTD_CONCAT Kconfig symbol and CONFIG_MTD_CONCAT define. This will be removed in one of next patches. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Artem Bityutskiy <dedekind1@gmail.com> Cc: Stefan Roese <sr@denx.de> --- drivers/mtd/Kconfig | 3 ++- drivers/mtd/Makefile | 3 +-- 2 files changed, 3 insertions(+), 3 deletions(-)