On Sat, Aug 25, 2012 at 5:02 AM, Shmulik Ladkani <shmulik.ladk...@gmail.com> wrote: > Hi Huang, > > On Sat, 25 Aug 2012 10:26:07 -0400 Huang Shijie <shij...@gmail.com> wrote: >> diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c >> index 4558e0f..fc960a3 100644 >> --- a/drivers/mtd/cmdlinepart.c >> +++ b/drivers/mtd/cmdlinepart.c >> @@ -344,7 +344,8 @@ static int parse_cmdline_partitions(struct mtd_info >> *master, >> "%s: partitioning exceeds flash >> size, truncating\n", >> part->mtd_id); >> part->parts[i].size = master->size - >> offset; >> - part->num_parts = i; >> + part->num_parts = i + 1; >> + break; > > Your analysis seems right, but let me offer an alternative approach. > > I would simply: > > - part->num_parts = i; your code does not wors in such kernel command line(also with the 1GB nand chip): #gpmi-nand:100m(root),100m(kernel),1g(rootfs),1g(user),-(rest)
For you see, we must keep the code robust enough. It should passes all the possible kernel command lines. > > (and not replace it with anything). > > The specified cmdline partitions might not be ordered (according to > start offset), so next partition specified after the truncated one might > define a partition at the beginning of the device, which is okay > (regardless the truncation of current partition). could you please give me an example of this specified cmdline? I can test it. Best Regards Huang Shijie > > Your patch skips the definitions of next partitions, which can be legit. > > I agree specifying "unsorted" partitions is not commonly used (and it > might make no sense when using the "remaining" syntax), but it is legit > to define all partitions _explicitly_ with their size@offset in an > unordered fashion. > > Regards, > Shmulik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/