[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25c30964-6bd3-c7eb-640a-ba1f513b7675@linaro.org>
Date: Thu, 1 Jun 2023 17:30:23 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: zhuyinbo <zhuyinbo@...ngson.cn>,
Conor Dooley <conor.dooley@...rochip.com>
Cc: Mark Brown <broonie@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-spi@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Jianmin Lv <lvjianmin@...ngson.cn>,
wanghongliang@...ngson.cn, Liu Peibao <liupeibao@...ngson.cn>,
loongson-kernel@...ts.loongnix.cn
Subject: Re: [PATCH v11 1/2] dt-bindings: spi: add loongson spi
On 01/06/2023 11:51, zhuyinbo wrote:
>>> Yes, it is make sense as it can reduce the workload of the community.
>>> For the Loongson platform, the versions of spi peripherals are almost
>>> the same, except for a few or individual SoCs. And we have also
>>> discussed compatible internally, and we tend to define it this way.
>>
>> So you have chosen different path than what's clearly recommended by
>> community, existing experience and documentation:
>>
>> https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L42
>>
>> Family names are not accepted as specific compatibles. Whenever they
>> were accepted, it lead to problems. All the time.
>
>
> Thank you for your documentation and advice and the Loongson platform
> have loongson-2h (ls2h), loongson-2k (ls2k), loongson-2p (ls2p) or other
> series SoC, which loongson-2 seems to be the family name you mentioned
> and the "loongson,ls2k-spi" should be a speific compatible name.
>
>>
>> https://lore.kernel.org/all/20220822181701.GA89665-robh@kernel.org/
>> https://lore.kernel.org/all/78651e07-6b3e-4243-8e1f-fcd1dfb3ffe1@www.fastmail.com/
>> https://lore.kernel.org/all/288f56ba9cfad46354203b7698babe91@walle.cc/
>> https://lore.kernel.org/all/106e443a-e765-51fe-b556-e4e7e2aa771c@linaro.org/
>> and many many more discussions.
>>
>> You should choose carefully, because we will keep NAK-ing adding
>> properties to circumvent missing compatibles.
>
>
> I have read the documention and patch link that you mentioned and it
> seems to advice that We don't have wildcard names in the compatible
> string and use wildcard names that will cause issue. and the compatible
> "loongson,ls2k-spi" that wasn't a wildcard names, and if the loongson-2k
> spi controller hardware upgraded or changed the I will use
> "loongson,ls2k-spi-version" as a compatible, such as,
> "loongson,ls2k-spi-v1.1", "loongson,ls2k-spi-v1.1a" or other.
Versions? Why? They received a lot of comments in the past, let me just
paste to avoid repeating the same:
https://lore.kernel.org/all/20220926231238.GA3132756-robh@kernel.org/
(and many more discussions on devicetree mailing list)
>
>>>
>>>> Or am I misunderstanding and all ls2k SoCs do work with this driver and
>>>> you were talking about other, future products?
>>>
>>> Actually, in 2k500 has one special type spi was only one cs and their's
>>> register definition was different from common type spi thus this driver
>>> doesn't support but this driver can support another common type spi in
>>> 2k500. for this special type spi I will add support as needed in the
>>> future.
>>
>> Bindings are for hardware, not driver. What does your driver support or
>> does not, matters less.
>
>
> okay, I got it, and the loongson spi bindings was for loongson spi
> controller hardware. if the spi controller hardware not changed in
> different ls2k SoC and the spi compatible should be same thus loongson
> spi compatible seems to be adhere to the bindings aggrement.
Specific compatible - yes. Unspecific - not, because you disregard the
clear message in the guideline.
Best regards,
Krzysztof
Powered by blists - more mailing lists