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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54354C7D.7090104@collabora.co.uk>
Date:	Wed, 08 Oct 2014 16:38:53 +0200
From:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
To:	Mark Brown <broonie@...nel.org>
CC:	Doug Anderson <dianders@...omium.org>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Olof Johansson <olof@...om.net>,
	Chris Zhong <zyw@...k-chips.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Abhilash Kesavan <kesavan.abhilash@...il.com>,
	linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH 1/5] regulator: of: Add regulator-initial-mode parse support

Hello Mark,

Thanks for the feedback.

On 10/08/2014 04:25 PM, Mark Brown wrote:
> On Wed, Oct 08, 2014 at 03:44:03PM +0200, Javier Martinez Canillas wrote:
> 
>> But currently there isn't a way to do the same with DeviceTrees. Argubly
>> the operating modes are Linux-specific so that information should not be
>> in the DT which should be used to only describe hardware. But regulators
>> having different operating modes is also a hardware property since many
>> PMICs have support to set different modes for their regulators.
> 
> That doesn't mean that the definition of those modes is something we can
> sensibly provide in generic code, especially in a completely
> undocumented fashion (perhaps you've done that later in the patch series
> but bisection also applies to reviewability).
> 

Yes, patch #3 updates the regulator DT binding doc and documents what each
regulator mode is supposed to be. Basically is just a short description of
what is already documented in linux/regulator/consumer.h [0].

If what is enough for you I can reorganize the patch-set so that patch is
the first one.

As a general question, now that the convention is for DT binding docs to go
in a separate patch, should the DT documentation be added before or after
that code using these bindings is added?

That is something that is not explained in
Documentation/devicetree/bindings/submitting-patches.txt.

Best regards,
Javier

[0]: http://lxr.free-electrons.com/source/include/linux/regulator/consumer.h#L40
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ