linux-kernel - Re: [PATCH] Documentation: dt: bindings: TI WiLink modules

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 27 Jun 2013 08:39:40 -0500
From:	Nishanth Menon <nm@...com>
To:	Luciano Coelho <coelho@...com>
Cc:	grant.likely@...aro.org, rob.herring@...xeda.com,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>,
	linux-wireless@...r.kernel.org, Tony Lindgren <tony@...mide.com>,
	linux-omap <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] Documentation: dt: bindings: TI WiLink modules

On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho <coelho@...com> wrote:
> On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
>> On 06/27/2013 08:19 AM, Luciano Coelho wrote:
>> > On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
>> >> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho <coelho@...com> wrote:
>> >>> For the actual DTS files, I could add a wilink.dtsi with enumerations
>> >>> for these values so they could be used in the node definitions.  But I'm
>> >>> not sure it's going to be that valuable in the end.
>> >> The  way GPIO HIGH was defined might help to provide guidance I think :)
>> >
>> > Where? As far as I can see, the GPIO flags are defined in a bitmap.
>>
>> include/dt-bindings/gpio/gpio.h
>
> Thanks! I don't see these macros used anywhere, though.
umm... I'd think you have'nt looked deep enough / lists :)

>
>> And corresponding kernel header:
>> include/linux/of_gpio.h
>
> This seems to be a completely different thing.  This is the header that
> contains the helper functions to get GPIO-related device tree nodes,
> isn't it?
That is true, but it also contains the flag for level which needs to
be in sync with the gpio.h dts header.
>> just a hint. not saying frequencies were defined in header. for systems
>> that define frequencies - example cpufreq OPPs, clock node usage, we do
>> not use indexing to frequency, instead, that is the responsibility of
>> driver to convert frequency back to required index.
>> git grep frequency Documentation/devicetree/bindings gives you how the
>> precedence looks like.
>>
>> Personally, if given a choice, I'd go with actual frequencies rather
>> than indexes.
>
> If I do that, I need to add also a separate flag to define whether the
> XTAL clock is used or not.  For instance, we have 26MHz and 26MHz
> crystal; and 38.4MHz and 38.4MHz crystal...
Yes, you would have to. at the same time, it is easy for module maker
to provide dtsi corresponding to exact h/w representation on his
module using wilink chip without being worried about weird index value
whose meaning is hidden in binding
On the flip side, It also allows driver to reject frequencies /
configurations that are not supported by the corresponding chip.

As I said, just my 2 cents. Personally, I'd like dts files to be as
readable as c files without having to dig through bindings document.

Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/