Hi All, On Tue, 3 May 2022 11:37:31 +0200 Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > Hi Krzysztof, > > On Tue, May 3, 2022 at 11:29 AM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > On 03/05/2022 08:51, Geert Uytterhoeven wrote: > > >>>> This should not be a reason why a property is or is not required. Either > > >>>> this is required for device operation or not. If it is required, should > > >>>> be in the bindings. Otherwise what are you going to do in the future? > > >>>> Add a required property breaking the ABI? > > >>> > > >>> The problem is that there are no bindings for the reset controller > > >>> (actually the reset controller feature of the system-controller) yet. > > >>> Yeah, we can just add #reset-cells = <1> to the system-controller > > >>> device node, but we cannot add the actual resets properties to the > > >>> consumers, until the actual cell values are defined. > > >> > > >> Sounds like you should implement providers first. Or just live with the > > >> warning as a reminder to implement the reset provider? > > > > > > I'd go for the latter. The upstream r9a06g032.dtsi is still under active > > > development. Until very recently, the only device supported was the > > > serial console. > > > > For clocks we use in such cases fixed-clock placeholders or empty > > phandles. Maybe something like that would work here as well? > > I don't think that works for resets. > Besides, the driver doesn't need or use the reset anyway. > Finally, related to the "resets" property, what should I do ? (a) Keep the property as not required an change the commit log (b) Set the property as required and live with a warning (Rob's suggestion) Regards, Hervé -- Hervé Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com