Re: [PATCH V2 0/4] [SCSI] ufs: Adds glue drivers to ufshcd

[vinayak holikatti]

On Mon, Jul 16, 2012 at 9:52 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Monday 16 July 2012, James Bottomley wrote:
>> On Fri, 2012-07-13 at 15:45 +0000, Arnd Bergmann wrote:
>> > On Friday 13 July 2012, Vinayak Holikatti wrote:
>> > > This patch set adds following features
>> > >  - Seprates PCI specific code from ufshcd.c to make it as core
>> > >  - Adds PCI glue driver ufshcd-pci.c
>> > >  - Adds Platform glue driver ufshcd-pltfrm.c
>> > >  - Update correct transfer size in Command UPIU
>> >
>> > Acked-by: Arnd Bergmann <arnd@xxxxxxxx>
>>
>> I need a maintainer ack for this to go upstream.
>>
>> Also, looking at this, I think this patch series isn't bisectable:
>> Patch 1 removes PCI support and patch 2 adds it back in a different
>> form.  However, any PCI based UFS system would stop working if the
>> bisect landed at patch 1.  I think you can fix this just by combining
>> patches 1 and 2.
>
> I suggested to split the patch in two in a private review that we
> did on the linaro mailing list. I gave my Ack because the split
> was done, but I failed to notice that it was done differently
> from what I suggested in
>
> On Monday 02 July 2012, Arnd Bergmann wrote:
>> I would recommend that you split this patch into two separate
>> changesets, where you do all the changes to existing code in the
>> first patch, and only move but don't change code in the second one
>> that creates the new file.
>
> I agree that breaking bisectibility by ripping out the PCI code
> first is not good. The version 2 is not actually easier to review
> at all than the first version, it just splits the changes by
> file, which is pointless.
I will roll out another patch series which will address the current issue.
Firstly will modify existing code with PCI code and then in the second
move the code to new file ufshcd-pci.c
>
>         Arnd
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/