On Mon, Jun 06, 2022 at 09:29:59AM +0200, Krzysztof Kozlowski wrote: > On 05/06/2022 16:54, Krzysztof Kozlowski wrote: > > On 03/06/2022 13:22, Marty E. Plummer wrote: > >> On Thu, Jun 02, 2022 at 08:37:43AM +0200, Krzysztof Kozlowski wrote: > >>> On 01/06/2022 20:24, Marty E. Plummer wrote: > >>> > >>>>>> Either or. Whatever makes the workload easier is what I'm looking for. > >>>>> > >>>>> Sorry, you need to be more specific. Apply is not a job for you, for the > >>>>> patch submitter. > >>>>> > >>>>> Then you miss here important piece - which is the first patch. DTS goes > >>>>> always via separate branch (or even tree) from driver changes. That's > >>>>> why bindings are always separate first patches. > >>>>> > >>>> So, add a 4: arch/arm/boot/dts/soc.dtsi and 5: arch/arm/boot/dts/board.dts > >>>> to the above list, or should those be the same patch as well? > >>> > >>> For me does not matter, sub architecture maintainer might have preference. > >>> > >> Fair enough. That being said, for the dt-bindings patch, is it > >> permissible to include #define CLOCK_FOO 1337 and so on for clocks which > >> haven't been wired up in the driver yet? As in, you know they're there, > >> and are important enough to model, but you haven't gotten to that point > >> yet? > > > > What would be the benefit to include them now? I imagine that if you > > plan to add such clocks to the driver in next week or something, and you > > need to use them in DTS, then it's fine. If that's not the case, > > probably there is little sense in defining them upfront... > > Actually I see one more benefit - since IDs should be incremented by > one, you can define all of them upfront thus having some > logical/alphabetical order/grouping. If you extend the bindings header > with new IDs later, they must go to the end of the list, thus maybe > ordering will not be that nice. > > If you want, go ahead with all IDs. Just remeber that these must be IDs, > not register values or some programming offsets. > Yeah, this was my intent. There are a number of non-standard, proprietary IP blocks on this soc who's 'organized clock number' come 'in between' the more standard bits, depending on how you decide to organize them (based on their parent clocks, based on the order they appear in the crg register block, whatever). I *do* intend on hopefully putting together drivers for these as well, though that's a long-term stretch goal. > Best regards, > Krzysztof
