On 7/18/23 16:04, Krzysztof Kozlowski wrote:
On 18/07/2023 16:01, Michal Simek wrote:
On 7/18/23 15:20, Krzysztof Kozlowski wrote:
On 18/07/2023 15:11, Michal Simek wrote:
That numbers in DT are virtual no matter if you use ID from 0 to max or random
values it is up to code to handle them. Checking nr_pins against ID is done in
core but it is up to drivers.
No, you confuse "virtual" and "ID". IDs are not virtual. IDs are real
and have representation in Linux driver. You do not need to define
anything virtual in the bindings.
Not sure how you define ID itself. But HW doesn't know ID. HW knows only
register which you can use to perform the reset. It is not really 128bit
register where every bit targets to different IP.
And this is SW-firmware interface like SCMI reset driver.
Firmware is saying that ID 0 is QSPI, ID 1 is MMC.
Their Linux driver is asking for nr_reset via firmware call which can be
different for different SOC and that's fine and I have no problem with it.
But only SCMI server is dictating that ID 0 is QSPI and ID 1 is MMC. Different
SCMI server implementation can map it differently.
Sure, and all this points to: no need for bindings.
In our case that IDs are coming from firmware and driver itself is just matching
them.
So they are the same as if coming from hardware - no need for IDs.
It is hard to say what hardware here exactly is. From my perspective and I am
not advocating not using IDs from 0 to max, it is just a number.
If my firmware knows that QSPI reset is 0xc10402dU then I will just pass it to
reach my goal which is reset QSPI IP.
If you think that we should use IDs from 0 to max NR I am happy to pass this
message to PM team and we should extend any SW to do translation between.
When we talk about IDs and bindings, we mean IDs meaningful to Linux.
Whatever is ignored by Linux and passed to anyone else - hardware or
firmware - is not a ID anymore from bindings point of view. It's just
some value.
Please correct me if I am wrong. Description about ID should be removed from
commit message because it is not necessary. And
include/dt-bindings/reset/xlnx-versal-net-resets.h
should be added when we merge also DT for versal-net SOC.
No, the binding header is needed only if driver is using it. Adding DTS
will not change that - still no kernel driver users. No benefits of such
binding. If there are no users and no benefits - don't make it a binding.
But header in board folder should be fine like these.
arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
arch/arm64/boot/dts/mediatek/mt8516-pinfunc.h
arch/arm64/boot/dts/mediatek/mt8167-pinfunc.h
arch/arm64/boot/dts/mediatek/mt8173-pinfunc.h
arch/arm64/boot/dts/exynos/exynos-pinctrl.h
arch/arm64/boot/dts/freescale/imx8mq-pinfunc.h
arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h
arch/arm64/boot/dts/freescale/imx8mn-pinfunc.h
arch/arm64/boot/dts/freescale/imx93-pinfunc.h
arch/arm64/boot/dts/freescale/imx8ulp-pinfunc.h
arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
arch/arm64/boot/dts/tesla/fsd-pinctrl.h
Thanks,
Michal
