Am Montag, 7. Juni 2021, 10:15:30 CEST schrieb Johan Jonker:With consulting to my colleague,we plane to:
Hi Jon,
On 6/7/21 8:34 AM, Jon Lin wrote:
The description below will be used for rv1126.dtsi or rk3568.dtsi inThis list is sort alphabetically.
the future
Signed-off-by: Jon Lin <jon.lin@xxxxxxxxxxxxxx>
---
Changes in v4:
- Adjust the order patches
- Simply commit massage like redundancy "application" content
Changes in v3:
- Fix compile error which is find by Sascha in [v2,2/8]
Documentation/devicetree/bindings/spi/spi-rockchip.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
index 1e6cf29e6388..2d7957f9ae0a 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
@@ -27,12 +27,14 @@ properties:
- items:
- enum:
- rockchip,px30-spi
+ - rockchip,rv1126-spi
Move "rockchip,rv1126-spi" below "rockchip,rk3568-spi"
- rockchip,rk3188-spi
- rockchip,rk3288-spi
- rockchip,rk3308-spi
- rockchip,rk3328-spi
- rockchip,rk3368-spi
- rockchip,rk3399-spi
+ - rockchip,rk3568-spi
- const: rockchip,rk3066-spi===
reg:
Your comment in [PATCH v3 3/8]:
Adding "rockchip,rv1126-spi" to rockchip_spi_dt_match[] is strictly not
needed when using "rockchip,rk3066-spi" as fall back string.
Could a maintainer advise?
After the explain from you and Johan, I found that the idea "rockchip,spi" was immature.Johan ist right :-) .Compatibility strings are supposed to be SoC orientated.I agree with you. If the maintainer doesn't have any comments, I will use
Maybe this bug of mine should revert too?? Or is it legacy?
spi: rockchip: add compatible string for px30 rk3308 rk3328
https://lore.kernel.org/r/20200309151004.7780-1-jbx6244@xxxxxxxxx
"rockchip,spi" as compatible names for the subsequent rk platform.
So generic ones like in the manufacturer tree can't be used here.
rockchip,spi won't work at all, especially as these controllers always change
over time. [0]
Best example is the iommu. We started with "rockchip,iommu" thinking this
won't change over time, but with the rk3568 we get a new slightly different
iommu.
The vendor-kernel then introduces somewhat random "-vX" additions to
distinguish them, but often they do seem to be very software-centric.
Meaning, hardware-designers moved stuff around and software-developers
then invented the versioning to differentiate between versions.
The devicetree is supposed to describe the hardware though, so going with
the relevant soc-specific compatible gives us the necessary hardware-centric
differentiation.
Also this allows to catch later issues with specific soc implementations ;-)
Like 6 monts down the road we discover some special behaviour on the
rk3568 and devicetree is supposed to be stable.
So having the relevant compatibles in place allows us to just add driver
fixes and have those apply on the rk3568 if that is need at some point.
Heiko