Re: [PATCH v2 1/6] dt-bindings: vendor-prefixes: add Axera

[Krzysztof Kozlowski]

On 07/09/2026 09:12, 冷红林 wrote:
> On 9/3/2026 8:39 PM, Krzysztof Kozlowski wrote:
>> On Tue, Sep 01, 2026 at 05:19:28PM +0800, Leng Honglin wrote:
>>> Add the Axera Semiconductor vendor prefix for devicetree bindings.
>>>
>>> For more information, visit the official Axera Semiconductor website:
>>> Chinese site: https://www.axera-tech.com/
>>> English site: https://www.axera-tech.com/en
>>>
>>> Signed-off-by: Leng Honglin <lenghonglin@xxxxxxxxxxxxxx>
>>> ---
>>>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
>>> index 396044f368e7..1dbafe682724 100644
>>> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
>>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
>>> @@ -219,6 +219,8 @@ patternProperties:
>>>      description: Shanghai Awinic Technology Co., Ltd.
>>>    "^axentia,.*":
>>>      description: Axentia Technologies AB
>>> +  "^axera,.*":
>>
>> So how did you implement own comment?
>>
>> Best regards,
>> Krzysztof
> 
> Hi Krzysztof,
> 
> I sincerely apologize for the confusion. In my previous reply, I did
> promise to change the prefix to "axera-tech" to align with our domain
> name. I should have explained my change of mind in the v2 patch notes.
> 
> When I started making the changes internally for v2, I realized that
> our existing BSPs, bootloaders, and a large amount of downstream
> codebase already heavily rely on the "axera,*" prefix for compatible
> strings. Changing it to "axera-tech" now would cause massive breakage
> and compatibility issues across our existing ecosystem.

Did this existing downstream codebase receive DT maintainers ack or review?

I checked and it seems it is first time you ask:
https://lore.kernel.org/all/?q=dfn%3Avendor-prefixes.yaml+axera

Whatever you have downstream is Axera's fault. You should have come
earlier. Otherwise everyone will produce whatever stuff (including total
junk) in downstream and then say that it is an effort to align to
upstream. And I saw this argument more than once.


> 
> Because of this historical legacy, I looked for similar cases in the
> upstream bindings and noticed that there are accepted precedents where
> the prefix reflects the core brand rather than the full domain (for
> example, "^cix,.*" for cixtech.com).

Indeed cix should use cixtech.


> 
> Would it be acceptable to keep "axera" as the prefix to preserve
> compatibility with our existing deployed systems, even though our
> domain is axera-tech.com?
> 
> If this is strictly not allowed, we will have to figure out a
> migration path internally, but preserving "axera" would be highly
> preferable for our ecosystem. I am very sorry again for not clarifying
> this earlier.

Axera is fine, I don't see conflicts with other possible vendors, but
the problem is that if I agree now, next months someone will use this as
an argument for their patchset that "cix" and "axera" were allowed, so
they also deserve exception because they never cared to ask upstream
before. So obviously based on your earlier reason, of using past mistake
or exception, I should not really agree on that one. Therefore fine by
me, but please get an Ack from different DT maintainer.



Best regards,
Krzysztof