06:59 <abelvesa_> krzk: sorry for the late reply. Correct me if I'm wrong, but I think there might be cases where a driver will make use of _END/_NUM and then someone adding new clock binding IDs in the header and forget to update the _END/_NUM in the driver.

06:59 <krzk> abelvesa_: sure, but that's irrelevant to the question here, to the bindings. Bindings have nothing to do with such mistakes

07:00 <krzk> abelvesa_: you can also add comments or checks for that, if you want to address such risk

07:00 <abelvesa_> krzk: right, but kinda makes the reviewing harder

07:01 <krzk> again, not a comment to keep something in the bindings

07:01 <abelvesa_> always checking if the driver _END/_NUM has been updated

07:01 <krzk> this is real issue, but not a reason to add to the bindings something which is not supposed to be a binding and ABI

07:01 <abelvesa_> krzk: I see

07:03 <abelvesa_> krzk: I think what I will do is I will drop the _END/_NUM alltogether. If it's not in the bindings then the drivers shouldn't need it.

07:03 <abelvesa_> krzk: need to check if it can be done for all i.MX clocks drivers first

07:04 <krzk> abelvesa_: yeah, the bes tif the driver could use size determined automatically during build time

07:05 <geertu> abelvesa_: Just use the last entry instead of the _END entry in the driver? If new entries are added, the driver must be updated anyway to make use of them. And testing the new additions should fail if the previously used end marker was not updated?

07:06 <abelvesa_> geertu: yes, that's what I was thinking as well

07:06 <geertu> If your driver does an OOB array access if DT specifies an invalid entry, you have other problems to fix...

07:06 <abelvesa_> will do that

07:07 <abelvesa_> geertu: usually the clocks do not get dropped, especially from the bindings header

07:07 <abelvesa_> as it breaks the abi

07:08 <geertu> abelvesa_: Sorry, I don't understand where this dropping comment comes from?

07:09 <abelvesa_> geertu: the DT will only use an invalid entry if the bindings header has dropped a clock ID

07:10 <geertu> abelvesa_: Or when using a new DTB with an old kernel. Or when using a literal number in the DT ;-)

07:11 <abelvesa_> geertu: yes, but those we never considered valid scenarios anyway, right ? :)

07:14 <geertu> abelvesa_: They should not cause OOB.

08:46 <arnd> abelvesa_: I'm pretty sure on imx, stm32 or zynq there are tons of boards with vendor-provided dtb that are expected to just work with upstream kernels and not get upstreamed. On other platforms the bindings the bindings were never complete enough to allow that

08:47 <LeSpocky> fwiw, I know at least a hand full of at91 based boards with not-upstreamed vendor dtb, which just work with mainline kernel

09:28 <krzk> arnd: LeSpocky: oh cool, I will store above quotes because people all the time question my "out of tree users" of bindings/ABI etc.

10:12 <LeSpocky> ^^

10:16 <LeSpocky> getting a new board to run is basically just creating a new dts, include the soc dtsi, add a few nodes and you're done, I mean that was the idea behind device tree, wasn't it?

10:39 <krzk> LeSpocky: Idea is to upstream things. People, including me, do not care about stuff not being in the upstream. DTS and bindings create here an exception, but I would not call that exception as "idea behind". It's just acceptable exception.

10:40 <krzk> So you want to be sure we won't break your boards? Upstream them. Or participate in discussions, set a lei/lore filter etc. Otherwise it is just best effort from our side.

10:53 <LeSpocky> krzk: think we are talking about different things here, but in general agreed