Re: [PATCH v2 7/8] auxdisplay: Add Titanmec TM16xx 7-segment display controllers driver

[Andy Shevchenko]

On Mon, Jun 30, 2025 at 01:39:25PM +0200, Krzysztof Kozlowski wrote:
> On 30/06/2025 11:54, Andy Shevchenko wrote:
> > On Mon, Jun 30, 2025 at 11:27:21AM +0200, Krzysztof Kozlowski wrote:
> >> On 30/06/2025 09:27, Andy Shevchenko wrote:
> >>> On Mon, Jun 30, 2025 at 08:12:16AM +0200, Krzysztof Kozlowski wrote:
> >>>> On 29/06/2025 15:18, Jean-François Lessard wrote:

...

> >>>>> +	display->leds =
> >>>>> +		devm_kcalloc(dev, display->num_leds, sizeof(*display->leds), GFP_KERNEL);
> >>>>
> >>>> Wrong wrapping. Use kernel style, not clang style.
> >>>>
> >>>>
> >>>>> +	if (!display->leds)
> >>>>> +		return -ENOMEM;
> >>>
> >>> Just wondering how .clang-format is official? Note some of the maintainers even
> >>
> >> First time I hear above clang style is preferred. Where is it expected?
> > 
> > Documented here:
> > https://www.kernel.org/doc/html/latest/process/coding-style.html#you-ve-made-a-mess-of-it
> 
> I mean, which maintainers prefer such style of wrapping. Above I know,
> but it does not solve the discussion we have here - above line wrapping
> preferred by clang and opposite to most of the kernel code.

IIRC Dan Williams (as you might have deduced already from the links).

> > For example, discussed here
> > https://lore.kernel.org/lkml/CAPcyv4ij3s+9uO0f9aLHGj3=ACG7hAjZ0Rf=tyFmpt3+uQyymw@xxxxxxxxxxxxxx/
> 
> Heh, I read it and two emails earlier and still could not get they
> prefer to wrap at assignment instead of standard checkpatch-preferred
> wrapping at arguments.
> 
> > or here
> > https://lore.kernel.org/lkml/64dbeffcf243a_47b5729487@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.notmuch/
> 
> This is line length, so not the problem discussed here.

Ah, okay.

> > or
> > ...
> > 
> >> I assume clang-format is half-working and should not be used blindly,
> >> but fixed to match actual kernel coding style.
> > 
> > That sounds like the case, at least in accordance with Miguel.
> > 
> >>> prefer (ugly in some cases in my opinion) style because it's generated by the
> >>> clang-format.

-- 
With Best Regards,
Andy Shevchenko