On 5/16/20 5:11 PM, Dmitry Osipenko wrote:
> 16.05.2020 19:58, Randy Dunlap пишет:
>> On 5/16/20 9:50 AM, Dmitry Osipenko wrote:
>>> 16.05.2020 18:51, Randy Dunlap пишет:
>>>> On 5/16/20 8:36 AM, Dmitry Osipenko wrote:
>>>>> diff --git a/block/partitions/efi.c b/block/partitions/efi.c
>>>>> index b64bfdd4326c..3af4660bc11f 100644
>>>>> --- a/block/partitions/efi.c
>>>>> +++ b/block/partitions/efi.c
>>>>> @@ -621,6 +621,14 @@ static int find_valid_gpt(struct parsed_partitions 
>>>>> *state, gpt_header **gpt,
>>>>>          if (!good_agpt && force_gpt)
>>>>>                  good_agpt = is_gpt_valid(state, lastlba, &agpt, &aptes);
>>>>>  
>>>>> + /* The force_gpt_sector is used by NVIDIA Tegra partition parser in
>>>>> +  * order to convey a non-standard location of the GPT entry for lookup.
>>>>> +  * By default force_gpt_sector is set to 0 and has no effect.
>>>>> +  */
>>>>
>>>> Please fix the multi-line comment format as described in
>>>> Documentation/process/coding-style.rst.
>>>>
>>>>> + if (!good_agpt && force_gpt && state->force_gpt_sector)
>>>>> +         good_agpt = is_gpt_valid(state, state->force_gpt_sector,
>>>>> +                                  &agpt, &aptes);
>>>>> +
>>>>>          /* The obviously unsuccessful case */
>>>>>          if (!good_pgpt && !good_agpt)
>>>>>                  goto fail;
>>>>
>>>> thanks.
>>>>
>>>
>>> Hello Randy,
>>>
>>> I know that it's not a proper kernel-style formatting, but that's the
>>> style used by the whole efi.c source code and I wanted to maintain the
>>> same style, for consistency. Of course I can change to a proper style if
>>> it's more desirable than the consistency. Thank you for the comment!
>>>
>>
>> too bad. Sorry to hear that.
>> It should have been "fixed" much earlier.
>> It's probably too late now.
> 
> Actually, I now see that there is a mix of different comment styles in
> the efi.c code. So it should be fine to use the proper style, I'll
> change it in v6.
> 
> I don't think it's too late, it's never late to make a correction :)
> There are some other coding style problems in the efi.c that won't hurt
> to fix, I may take a look at fixing them later on.
> 

OK, great. Thanks.

-- 
~Randy

Reply via email to