On Tue 16 May 2023 at 11:00, Neil Armstrong <neil.armstrong@xxxxxxxxxx> wrote: > On 16/05/2023 10:44, Arnd Bergmann wrote: >> On Mon, May 15, 2023, at 18:22, neil.armstrong@xxxxxxxxxx wrote: >>> On 15/05/2023 18:15, Krzysztof Kozlowski wrote: >>>> On 15/05/2023 18:13, Krzysztof Kozlowski wrote: >>>> >>>> Also one more argument maybe not relevant here but for other cases - >>>> this makes literally impossible to include the clock ID in DTS in the >>>> same kernel revision, because you must not merge driver branch to DTS >>>> branch. SoC folks were complaining about this many times. >>> >>> Actually we handle this very simply by having such patches merged in a immutable >>> branch merged in the clock and DT pull-requests, it worked perfectly so far >>> and neither Stephen or Arnd complained about that. >> It's usually benign if you just add a new clk at the end of the binding >> header, as that doesn't touch the internal header file in the same >> commit. I'm certainly happier about drivers that just use numbers from >> a datasheet instead of having to come up with numbers to stick in a binding >> because the hardware is entirely irregular, but there is usually no point >> trying to complain about bad hardware to the driver authors -- I unsterstand >> you are just trying to make things work. >> I agree with Krzysztof that using the same identifiers in the local >> header and in the binding is just making your life harder for no >> reason, and if you are the only ones doing it this way, it would >> help to change it. Maybe just add a namespace prefix to all the internal >> macros so the next time you move one into the documented bindings you >> can do it with the same immutable branch hack but not include the >> driver changes in the dt branch. > > Ack, I'll try to find a simple intermediate solution to avoid this situation. I'd in favor of keeping things simple and just put all the IDs in the bindings. We have been doodling with the idea for while, I think now is the time > > Thanks, > Neil > >> Arnd
