Re: [PATCH v2 4/5] mtd: nand: omap2: Use devm_kzalloc

[Ezequiel Garcia <ezequiel.garcia@free-electrons.com>]

On Fri, Oct 25, 2013 at 11:09:14AM +0000, Gupta, Pekon wrote:
> > From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
> > 
> > Hm.. well the problem with that patch is that it's in the middle of an
> > unrelated series. As I already told you, I think you should have pushed
> > that as a one-patch fix. Have you seen that suggestion?
> > 
> Yes, I know.. actually the original patch series, when it started somewhere
> April (or before) is very different from the version v11 now :-).
> This devm_ update was added in middle of v6-v7 version change
> (Most of the changes since first version of this patchset is captured in 
> Cover-letter).
> 
> 

Well, in order to *avoid* having a patchset flowing for 5 months and 11
revisions you coudl try to keep series small. You could have that single
fix merged if you send it alone. Not sure why you insist in *not* doing
that.

> > On the other side, you're fixing too many things in that single patch,
> > for my taste. Maybe I'm not the smarter developer, but going through
> > that patch is not easy to catch if there's no mistake done.
> > 
> > Usually if it's possible to split a patch (maintaining consistency) it makes
> > the reviewing process easier.
> > If you'd rather send this devm_xxx change yourself that's fine by me,
> > 
> Ahh nothing like that.. Brian had already reviewed these couple of times

Ah, good. In that case you should add "Reviewed-by" if Brian already
reviewed it. IMHO, the patch could be cleaner and the commit message
could be better.

> And it was only [Patch 04/10] which was last one remaining..

Yes, and because you added *another* patch to the series you keep
spinning patchset versions.

> I just said it because this might show up in merge conflict .. or rejects..
> 
> > but *please* split the patch in two and write proper commit messages.
> > 
> > Anyway: this is just a silly change, the important one is the other
> > nand_scan_ident() fix. Could you help me review that?
> > 
> > I'm interested in knowing how will that work with 8-bit and 16-bit devices.
> > --
> Yes, I'm just preparing the scenario where BUSWIDTH_AUTO would fail..
> unless you do GPMC driver changes also.. same issue was found by
> Matthieu CASTET (matthieu.castet@parrot.com)
> (please see my other mail)
> 

OK, let's try to focus in that patch alone, I'd like to move forward.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html