Hi Heiko, Johan,
On 2021/6/7 下午5:04, Heiko Stübner wrote:
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?
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
I agree with you. If the maintainer doesn't have any comments, I will use
"rockchip,spi" as compatible names for the subsequent rk platform.
Compatibility strings are supposed to be SoC orientated.
So generic ones like in the manufacturer tree can't be used here.
Johan ist right :-) .
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.
Rockchip SPI and SFC controller can use a generic compatible string,
because there is a version
register inside the IP, and all the feature update will have a new IP
version, so the driver is
used for the SPI/SFC IP in all SoCs, we don't need to care which SoC is
using this driver.
If we have to use the compatible string "rockchip,rk3066-spi" and each
for a new soc, then we
have to update the driver compatible id list and document for each soc
which is totally not need
and not correct to do it.
The example "iommu" is different, because there is no version register
inside the IP and the IP
can not identify itself, which need a software define "-vX".
Thanks,
- Kever
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
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
