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. Best regards, Krzysztof
