From: Alex Elder <elder@riscstar.com>
To: Yixun Lan <dlan@gentoo.org>
Cc: broonie@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, linux-spi@vger.kernel.org,
devicetree@vger.kernel.org, paul.walmsley@sifive.com,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
p.zabel@pengutronix.de, spacemit@lists.linux.dev,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: spi: add SpacemiT K1 SPI support
Date: Wed, 17 Sep 2025 21:59:35 -0500 [thread overview]
Message-ID: <f7e12797-ea17-4e92-bd25-cc562c66d2a7@riscstar.com> (raw)
In-Reply-To: <20250918001632-GYA1270371@gentoo.org>
On 9/17/25 7:16 PM, Yixun Lan wrote:
> Hi Alex,
>
> On 18:40 Wed 17 Sep , Alex Elder wrote:
>> On 9/17/25 6:15 PM, Yixun Lan wrote:
>>> Hi Alex,
>>>
>>> On 17:07 Wed 17 Sep , Alex Elder wrote:
>>>> Add support for the SPI controller implemented by the SpacemiT K1 SoC.
>>>>
>>>> Signed-off-by: Alex Elder <elder@riscstar.com>
>>>> ---
>>>> .../bindings/spi/spacemit,k1-spi.yaml | 94 +++++++++++++++++++
>>>> 1 file changed, 94 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml b/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml
>>>> new file mode 100644
>>>> index 0000000000000..5abd4fe268da9
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml
> ..
>>>> +
>>>> + spacemit,k1-ssp-id:
>>>> + description: SPI controller number
>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> could you explain a little bit why this vendor specific property should
>>> be introduced? I took a look at the code, and didn't get the reason
>>> behind.. or what's the problem of simply using "pdev->id"?
>>
>> This property was carried over from the vendor code. It is
> inherit from vendor code isn't a valid reason
>
>> optional, and if it isn't specified, the platform device ID (-1)
>> will be used. It's just intended to provide a well-defined ID
>> for a particular SPI controller.
>>
> while looking at the code, it seems you can use alias to map specific id
> to the spi controller, it even can do non-linear map, something like
> spi0 = &spi3;
I've never used this before, but yes, it looks like it's exactly
what I want. I'll just get rid of the "spacemit,k1-ssp-id" DT
property entirely. Easy.
> plese check of_alias_get_id()
>
> note, I haven't actually verified on board, just look through the code
>
>>> we should really be careful to introduce vendor specific property..
>>
>> If there were a standard way of doing this I'd love to use it.
Looks like you have told me the standard way of doing this.
Thank you.
-Alex
>>
>> And if it isn't necessary, please just explain to me why. I
>> have no problem removing it.
>>
> on the opposite, please have explicit good reason to introduce vendor
> speifici property, and if there is generic way, then we shouldn't do it
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Alex Elder <elder@riscstar.com>
To: Yixun Lan <dlan@gentoo.org>
Cc: broonie@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, linux-spi@vger.kernel.org,
devicetree@vger.kernel.org, paul.walmsley@sifive.com,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
p.zabel@pengutronix.de, spacemit@lists.linux.dev,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: spi: add SpacemiT K1 SPI support
Date: Wed, 17 Sep 2025 21:59:35 -0500 [thread overview]
Message-ID: <f7e12797-ea17-4e92-bd25-cc562c66d2a7@riscstar.com> (raw)
In-Reply-To: <20250918001632-GYA1270371@gentoo.org>
On 9/17/25 7:16 PM, Yixun Lan wrote:
> Hi Alex,
>
> On 18:40 Wed 17 Sep , Alex Elder wrote:
>> On 9/17/25 6:15 PM, Yixun Lan wrote:
>>> Hi Alex,
>>>
>>> On 17:07 Wed 17 Sep , Alex Elder wrote:
>>>> Add support for the SPI controller implemented by the SpacemiT K1 SoC.
>>>>
>>>> Signed-off-by: Alex Elder <elder@riscstar.com>
>>>> ---
>>>> .../bindings/spi/spacemit,k1-spi.yaml | 94 +++++++++++++++++++
>>>> 1 file changed, 94 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml b/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml
>>>> new file mode 100644
>>>> index 0000000000000..5abd4fe268da9
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml
> ..
>>>> +
>>>> + spacemit,k1-ssp-id:
>>>> + description: SPI controller number
>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> could you explain a little bit why this vendor specific property should
>>> be introduced? I took a look at the code, and didn't get the reason
>>> behind.. or what's the problem of simply using "pdev->id"?
>>
>> This property was carried over from the vendor code. It is
> inherit from vendor code isn't a valid reason
>
>> optional, and if it isn't specified, the platform device ID (-1)
>> will be used. It's just intended to provide a well-defined ID
>> for a particular SPI controller.
>>
> while looking at the code, it seems you can use alias to map specific id
> to the spi controller, it even can do non-linear map, something like
> spi0 = &spi3;
I've never used this before, but yes, it looks like it's exactly
what I want. I'll just get rid of the "spacemit,k1-ssp-id" DT
property entirely. Easy.
> plese check of_alias_get_id()
>
> note, I haven't actually verified on board, just look through the code
>
>>> we should really be careful to introduce vendor specific property..
>>
>> If there were a standard way of doing this I'd love to use it.
Looks like you have told me the standard way of doing this.
Thank you.
-Alex
>>
>> And if it isn't necessary, please just explain to me why. I
>> have no problem removing it.
>>
> on the opposite, please have explicit good reason to introduce vendor
> speifici property, and if there is generic way, then we shouldn't do it
>
next prev parent reply other threads:[~2025-09-18 2:59 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 22:07 [PATCH 0/3] spi: support the SpacemiT K1 SPI controller Alex Elder
2025-09-17 22:07 ` Alex Elder
2025-09-17 22:07 ` [PATCH 1/3] dt-bindings: spi: add SpacemiT K1 SPI support Alex Elder
2025-09-17 22:07 ` Alex Elder
2025-09-17 23:15 ` Yixun Lan
2025-09-17 23:15 ` Yixun Lan
2025-09-17 23:40 ` Alex Elder
2025-09-17 23:40 ` Alex Elder
2025-09-18 0:16 ` Yixun Lan
2025-09-18 0:16 ` Yixun Lan
2025-09-18 2:59 ` Alex Elder [this message]
2025-09-18 2:59 ` Alex Elder
2025-09-18 7:43 ` Troy Mitchell
2025-09-18 7:43 ` Troy Mitchell
2025-09-18 12:00 ` Alex Elder
2025-09-18 12:00 ` Alex Elder
2025-09-18 19:57 ` Rob Herring
2025-09-18 19:57 ` Rob Herring
2025-09-18 20:02 ` Alex Elder
2025-09-18 20:02 ` Alex Elder
2025-10-06 8:10 ` Krzysztof Kozlowski
2025-10-06 8:10 ` Krzysztof Kozlowski
2025-09-17 22:07 ` [PATCH 2/3] spi: spacemit: introduce SpacemiT K1 SPI controller driver Alex Elder
2025-09-17 22:07 ` Alex Elder
2025-09-18 7:47 ` Troy Mitchell
2025-09-18 7:47 ` Troy Mitchell
2025-09-18 12:00 ` Alex Elder
2025-09-18 12:00 ` Alex Elder
2025-09-18 12:41 ` Yixun Lan
2025-09-18 12:41 ` Yixun Lan
2025-09-18 13:45 ` Alex Elder
2025-09-18 13:45 ` Alex Elder
2025-09-18 14:39 ` Yixun Lan
2025-09-18 14:39 ` Yixun Lan
2025-09-18 14:47 ` Alex Elder
2025-09-18 14:47 ` Alex Elder
2025-09-18 14:56 ` Yixun Lan
2025-09-18 14:56 ` Yixun Lan
2025-09-18 15:44 ` Alex Elder
2025-09-18 15:44 ` Alex Elder
2025-09-18 15:58 ` Alex Elder
2025-09-18 15:58 ` Alex Elder
2025-09-18 16:22 ` Alex Elder
2025-09-18 16:22 ` Alex Elder
2025-09-17 22:07 ` [PATCH 3/3] riscv: dts: spacemit: define a SPI controller node Alex Elder
2025-09-17 22:07 ` Alex Elder
2025-09-18 13:32 ` Yixun Lan
2025-09-18 13:32 ` Yixun Lan
2025-09-18 13:51 ` Alex Elder
2025-09-18 13:51 ` Alex Elder
2025-09-18 14:06 ` Yixun Lan
2025-09-18 14:06 ` Yixun Lan
2025-09-18 14:20 ` Alex Elder
2025-09-18 14:20 ` Alex Elder
2025-09-18 15:04 ` Yixun Lan
2025-09-18 15:04 ` Yixun Lan
2025-09-18 14:33 ` Yao Zi
2025-09-18 14:33 ` Yao Zi
2025-09-18 16:22 ` Alex Elder
2025-09-18 16:22 ` Alex Elder
2025-09-19 15:25 ` Alex Elder
2025-09-19 15:25 ` Alex Elder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7e12797-ea17-4e92-bd25-cc562c66d2a7@riscstar.com \
--to=elder@riscstar.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlan@gentoo.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh@kernel.org \
--cc=spacemit@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.