Re: [PATCH v5 4/6] partitions/efi: Support GPT entry lookup at a non-standard location

[Dmitry Osipenko]

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.