[PATCH v2 06/11] dt-bindings: timer: Add Sophgo sg2042 clint

Krzysztof Kozlowski krzysztof.kozlowski at linaro.org
Wed Sep 20 06:09:16 PDT 2023


On 20/09/2023 14:58, Conor Dooley wrote:
> On Wed, Sep 20, 2023 at 08:40:07PM +0800, Inochi Amaoto wrote:
>>> On 20/09/2023 14:15, Inochi Amaoto wrote:
>>>>> On 20/09/2023 08:39, Chen Wang wrote:
>>>>>> From: Inochi Amaoto <inochiama at outlook.com>
>>>>>>
>>>>>> Add two new compatible string formatted like `C9xx-clint-xxx` to identify
>>>>>> the timer and ipi device separately, and do not allow c900-clint as the
>>>>>
>>>>> Why?
>>>>>
>>>>
>>>> If use the same compatible, SBI will process this twice in both ipi and
>>>> timer, use different compatible will allow SBI to treat these as different.
>>>> AFAIK, the aclint in SBI use the same concepts, which make hard to use the
>>>> second register range. I have explained in another response.
>>>
>>> What is a SBI? Linux driver? If so, why some intermediate Linux driver
>>> choice should affect bindings?
>>> Best regards,
>>> Krzysztof
>>>
>>
>> SBI (Supervisor Binary Interface) is defined by riscv, which is an interface
>> between the Supervisor Execution Environment (SEE) and the supervisor. The
>> detailed documentation can be found in [1].
>>
>> The implement of SBI needs fdt info of the platform, which is provided by
>> kernel. So we need a dt-bindings for these devices, and these will be
>> processed by SBI.
>>
>> [1] https://github.com/riscv-non-isa/riscv-sbi-doc
> 
> Yeah, this is the unfortunate problem of half-baked bindings (IMO)
> ending up in OpenSBI (which likely means they also ended up in QEMU).
> This T-Head stuff is coming across our (metaphorical) desks, so we are
> obviously going to try to do things correctly. I may end up speaking to
> Anup later today, if I do I will point him at this thread (if he hasn't
> seen it already).

If the OpenSBI started to work with some half-baked-bindings before
proper review, it's their loss. If we do not push back on such stuff,
how our review can ever matter?

Anyway, firmware/SBI/whatever parsing compatible twice is not really a
reason to model same thing with two different compatibles. Assuming of
course this is the same thing.

Best regards,
Krzysztof




More information about the linux-riscv mailing list