On 2/26/25 22:31, Krzysztof Kozlowski wrote:
On 26/02/2025 22:26, Krzysztof Kozlowski wrote:
On 26/02/2025 16:30, Alexandre TORGUE wrote:
On 2/26/25 16:08, Krzysztof Kozlowski wrote:
On 26/02/2025 10:33, Alexandre TORGUE wrote:
+ hdp: pinctrl@44090000 {
+ compatible = "st,stm32mp-hdp";
So here again - you have stm32mp251 SoC, but use entirely different
compatible.
Ok so I will use "st,stm32mp15-hdp"
This means this is stm32mp15 SoC. I do not see such SoC on list of your
SoCs in bindings. What's more, there are no bindings for other SoC
components for stm32mp15!
Yes stm32mp15 is not a "real SoC". I agree that at the beginning of the
STM32 story we didn't have a clear rule/view to correctly naming our
compatible. We tried to improve the situation to avoid compatible like
"st,stm32", "st,stm32mp" or "st,stm32mp1". So we introduced
"st,stm32mp13", "st,stm32mp15" or "st,stm32mp25" for new drivers. So yes
it represents a SoC family and not a real SoC. We haven't had much
negative feedback it.
But, if it's not clean to do it in this way, lets define SoC compatible
for any new driver.
Compatibles are for hardware.
For the HDP case it is: "st,stm32mp157" and used for STM32MP13,
STM32MP15 end STM32MP25 SoC families (if driver is the same for all
those SoCs).
No, it's three compatibles, because you have three SoCs. BTW, writing
bindings (and online resources and previous reviews and my talks) are
saying that, so we do not ask for anything new here, anything different.
At least not new when looking at last 5 years, because 10 years ago many
rules were relaxed...
So adding 3 times the same IP in 3 different SoCs implies to have 3
Yes. Always, as requested by writing bindings.
different compatibles. So each time we use this same IP in a new SoC, we
have to add a new compatible. My (wrong) understanding was: as we have
Yes, as requested by writing bindings and followed up by all recent
platforms having decent/active upstream support. See qcom, nxp, renesas
for example.
the same IP (same hardware) in each SoC we have the same compatible (and
You do not have same hardware. You have same IP, or almost same because
they are almost never same, implemented in different hardware.
IP integration differences (clocks, interrupts) are handled by DT
properties.
Which binding doc/guide suggested such way? Countless reviews from DT
maintainers were saying opposite.
I was not precise: IP integration differences are of course handles as
DT properties, but I wanted to say that it does not solve the problem
that IP integration means you might have differences in this device and
you should have different quirks.
Yes I agree. We'll take care of it for future development. Maybe, It
would be nice to apply this rule in our current drivers/DT already
upstream ?
And the example in this patchset: entirely different pin functions is a
proof. This device behaves/operates/integrates differently, thus
different compatible.
Yes, discussing with Clement, it is clear that we need 3 different
compatibles.
Best regards,
Krzysztof
