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