[PATCH 1/3] dt-bindings: spi: add SpacemiT K1 SPI support
Yixun Lan
dlan at gentoo.org
Wed Sep 17 17:16:32 PDT 2025
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 at 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;
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.
>
> 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
--
Yixun Lan (dlan)
More information about the linux-riscv
mailing list