lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <82917652-8be2-75f5-f3fc-814ee7c3f51d@ti.com> Date: Tue, 3 Apr 2018 11:13:07 +0530 From: Sekhar Nori <nsekhar@...com> To: David Lechner <david@...hnology.com>, <linux-clk@...r.kernel.org>, <devicetree@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org> CC: Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...eaurora.org>, Rob Herring <robh+dt@...nel.org>, Mark Rutland <mark.rutland@....com>, Kevin Hilman <khilman@...nel.org>, Bartosz Golaszewski <bgolaszewski@...libre.com>, Adam Ford <aford173@...il.com>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v8 42/42] ARM: dts: da850: Add clocks On Monday 02 April 2018 09:45 PM, David Lechner wrote: > On 04/02/2018 06:12 AM, Sekhar Nori wrote: >> On Friday 16 March 2018 10:50 PM, David Lechner wrote: >>> On 03/15/2018 09:52 PM, David Lechner wrote: >>>> This adds clock provider nodes for da850 and wires them up to all of >>>> the >>>> devices. >>>> >>>> Signed-off-by: David Lechner <david@...hnology.com> >>>> --- >>> >>> ... >>> >>> This is the mcasp0: mcasp@...000 node... >>> >>>> @@ -560,6 +720,7 @@ >>>> dmas = <&edma0 1 1>, >>>> <&edma0 0 1>; >>>> dma-names = "tx", "rx"; >>>> + clocks = <&psc1 7>; >>> >>> After some testing, it looks like it needs to be: >>> >>> + power-domains = <&psc1 7>; >>> >>> instead of >>> >>> + clocks = <&psc1 7>; >> >> We should probably have both clocks and power-domains properties for all >> PSC clocks. This way, the driver can change without a corresponding DT >> update dependency. >> >> Thanks, >> Sekhar >> > > That's fine with me. I just didn't know how people felt about using > properties > that are not documented. Good point. How to ease documentation for generic properties like these was discussed in the past, but there is no guidance in Documentation/devicetree/bindings that I can see. So, in the interest of reduced controversy, its probably better to do what you already have and only populate properties already documented in the bindings. Thanks, Sekhar
Powered by blists - more mailing lists