Re: [PATCH] dt-bindings: vendor-prefixes: add kfr prefix

[Krzysztof Kozlowski <krzk@kernel.org>]

On 14/11/2025 10:23, Gilles BULOZ wrote:
> Le 14/11/2025 à 09:40, Krzysztof Kozlowski a écrit :
> 
>> [Vous ne recevez pas souvent de courriers de krzk@kernel.org. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>>
>> On 14/11/2025 08:53, Gilles BULOZ wrote:
>>> Add kfr vendor prefix for Kontron France, which is a single-board
>>> computer (SBC) manufacturer.
>> There is no user for this.
> 
> Hi Krzysztof,
> 
> Yes, there's no user for vendor "kfr" in kernel tree, but Kontron has
> produced some ARM boards (VM6103,VX3106,VX6124,VX3124) on which we
> ported uboot and added some entries in device tree for board specific
> devices (CPLD) using vendor "kfr". We also provide a Linux BSP for these
> boards with drivers using compatible = kfr,<cpldchip>.
> My patch was just to reserve this vendor officially so that no other

You have entire commit msg to explain unusual things. Your commit msg
must explain WHY you are doing it so we know WHY we would want to accept
that patch. If you do not want to convince me why I want this patch
then... I don't want that patch (please watch Greg's talk titled that way).

Anyway, you cannot "reserve" prefix. You must reference here the
upstream user, if it is not obvious.

Plus I am pretty sure Kontron already has prefix and there is no point
for another one. How many companies Samsung has? 10? 20? How many prefixes?


> company will use it.
> Am I wrong with this way to proceed ?
> 
> Best regards
> 
> Gilles
> 
>>
>> <form letter>
>> Please use scripts/get_maintainers.pl to get a list of necessary people
>> and lists to CC (and consider --no-git-fallback argument, so you will
>> not CC people just because they made one commit years ago). It might
>> happen, that command when run on an older kernel, gives you outdated
>> entries. Therefore please be sure you base your patches on recent Linux
>> kernel.
>>
>> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
>> people, so fix your workflow. Tools might also fail if you work on some
>> ancient tree (don't, instead use mainline) or work on fork of kernel
>> (don't, instead use mainline). Just use b4 and everything should be
>> fine, although remember about `b4 prep --auto-to-cc` if you added new
>> patches to the patchset.

And this part you ignored or accepted?

Best regards,
Krzysztof