Re: [PATCH v2 22/30] scsi: aacraid: Merge adapter setup with resolve luns

[Nikola Pajkovsky]

Raghava Aditya Renukunta <raghavaaditya.renuku...@microsemi.com> writes:

> Hi Nikola,
>
>> -Original Message-
>> From: Nikola Pajkovsky [mailto:npajkov...@suse.cz]
>> Sent: Wednesday, January 3, 2018 2:02 AM
>> To: Raghava Aditya Renukunta
>> <raghavaaditya.renuku...@microsemi.com>
>> Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; linux-
>> s...@vger.kernel.org; Scott Benesh <scott.ben...@microsemi.com>; Tom
>> White <tom.wh...@microsemi.com>; dl-esc-Aacraid Linux Driver
>> <aacr...@microsemi.com>; Guilherme G . Piccoli
>> <gpicc...@linux.vnet.ibm.com>; Bart Van Assche
>> <bart.vanass...@wdc.com>
>> Subject: Re: [PATCH v2 22/30] scsi: aacraid: Merge adapter setup with resolve
>> luns
>> 
>> EXTERNAL EMAIL
>> 
>> 
>> Raghava Aditya Renukunta <raghavaaditya.renuku...@microsemi.com>
>> writes:
>> 
>> > The device hotplug events are processed only after retrieving the updated
>> > lun information from the fw. Does not make sense to keep them separate.
>> >
>> > Merge both the hotplug handling and safw adapter setup code into single
>> > function.
>> >
>> > Signed-off-by: Raghava Aditya Renukunta
>> <raghavaaditya.renuku...@microsemi.com>
>> 
>> According to subsequent commit
>> 
>>   [PATCH v2 23/30] scsi: aacraid: Block concurrent hotplug event handling
>> 
>> this commit is racy, because 23/30 adds ->scan_mutex. Shouldn't be these
>> commits squashed?
>
> I tried to make the patches as logically distinct as possible, maybe I
> got a bit too ambitious and I expected the patches to go thru as a set so
> I don’t think it would make any difference. What do you think?

It does make difference, when you start cherry-picking patches to
downstream kernel. However, I don't have strong opinion here, so it can
stay as is.

-- 
Nikola

RE: [PATCH v2 22/30] scsi: aacraid: Merge adapter setup with resolve luns

[Raghava Aditya Renukunta]

Hi Nikola,

> -Original Message-
> From: Nikola Pajkovsky [mailto:npajkov...@suse.cz]
> Sent: Wednesday, January 3, 2018 2:02 AM
> To: Raghava Aditya Renukunta
> <raghavaaditya.renuku...@microsemi.com>
> Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; linux-
> s...@vger.kernel.org; Scott Benesh <scott.ben...@microsemi.com>; Tom
> White <tom.wh...@microsemi.com>; dl-esc-Aacraid Linux Driver
> <aacr...@microsemi.com>; Guilherme G . Piccoli
> <gpicc...@linux.vnet.ibm.com>; Bart Van Assche
> <bart.vanass...@wdc.com>
> Subject: Re: [PATCH v2 22/30] scsi: aacraid: Merge adapter setup with resolve
> luns
> 
> EXTERNAL EMAIL
> 
> 
> Raghava Aditya Renukunta <raghavaaditya.renuku...@microsemi.com>
> writes:
> 
> > The device hotplug events are processed only after retrieving the updated
> > lun information from the fw. Does not make sense to keep them separate.
> >
> > Merge both the hotplug handling and safw adapter setup code into single
> > function.
> >
> > Signed-off-by: Raghava Aditya Renukunta
> <raghavaaditya.renuku...@microsemi.com>
> 
> According to subsequent commit
> 
>   [PATCH v2 23/30] scsi: aacraid: Block concurrent hotplug event handling
> 
> this commit is racy, because 23/30 adds ->scan_mutex. Shouldn't be these
> commits squashed?

I tried to make the patches as logically distinct as possible, maybe I got a 
bit too ambitious and I expected the patches to go thru as a set so I don’t 
think it would make any difference. What do you think? 

Thanks
Raghava Aditya

> --
> Nikola

Re: [PATCH v2 22/30] scsi: aacraid: Merge adapter setup with resolve luns

[Nikola Pajkovsky]

Raghava Aditya Renukunta  writes:

> The device hotplug events are processed only after retrieving the updated
> lun information from the fw. Does not make sense to keep them separate.
>
> Merge both the hotplug handling and safw adapter setup code into single
> function.
>
> Signed-off-by: Raghava Aditya Renukunta 
> 

According to subsequent commit

  [PATCH v2 23/30] scsi: aacraid: Block concurrent hotplug event handling

this commit is racy, because 23/30 adds ->scan_mutex. Shouldn't be these
commits squashed?

--
Nikola