linux-kernel - Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

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: <CAL_JsqLu7=66jEuaezesEuoPsBBhRAT0UQcLVNOLVwkEvQacRA@mail.gmail.com>
Date:	Tue, 29 Dec 2015 16:15:09 -0600
From:	Rob Herring <robh@...nel.org>
To:	Michael Turquette <mturquette@...libre.com>,
	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>
Cc:	Eric Anholt <eric@...olt.net>,
	linux-clk <linux-clk@...r.kernel.org>,
	"Stephen Boyd <sboyd@...eaurora.org>, Emilio Lopez
	<emilio@...pez.com.ar>, Hans de Goede <hdegoede@...hat.com>, linux-clk
	<linux-clk@...r.kernel.org>, linux-arm-kernel" 
	<linux-arm-kernel@...ts.infradead.org>,
	linux-rpi-kernel@...ts.infradead.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Lee Jones <lee@...nel.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary
 peripheral clock gates.

+Arnd and Olof

On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette
<mturquette@...libre.com> wrote:
> Quoting Eric Anholt (2015-12-24 15:45:15)
>> Michael Turquette <mturquette@...libre.com> writes:
>>
>> > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring <robh@...nel.org> wrote:
>> >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote:
>> >>> These will be used for enabling UART1, SPI1, and SPI2.
>> >>>
>> >>> Signed-off-by: Eric Anholt <eric@...olt.net>
>> >>> ---
>> >>>
>> >>> v2: Make the binding cover both the IRQ and clock enable registers.
>> >>>
>> >>>  .../bindings/clock/brcm,bcm2835-aux-clock.txt      | 31 ++++++++++++++++++++++
>> >>>  include/dt-bindings/clock/bcm2835-aux.h            | 17 ++++++++++++
>> >>>  2 files changed, 48 insertions(+)
>> >>>  create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
>> >>>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>> >>
>> >> Acked-by: Rob Herring <robh@...nel.org>
>> >
>> > Applied to clk-next.
>> >
>> > Next time if you put the header into the clk driver patch then we can
>> > send the binding description through the DT tree and take the header
>> > and C file through the clk tree in one patch.
>>
>> I would *love* to do that, but I've previously been told that having the
>> bindings patch reference a header file not present as of the bindings
>> patch is not acceptable and made to change it.
>
> Ugh, that is annoying. I would think that having code compile properly
> would trump the desire to have all of the documentation merged as one
> patch.

What about compiling the dts?

> On the other hand, I've been asked to not take binding descriptions
> through the clk tree. That is a policy that I'm happy to comply with,
> but it is at odds with the recommendation for the header and the binding
> description to be merged together.

By who? Any bindings in a series I always expect the subsystem
maintainers to take the whole series. That doesn't solve the problem
though as there is still a dependency between a subsystem tree and
arm-soc typically.

> DT folks, what is the right way to do this? An immutable, shared branch
> just for a single header file solves the problem, but also feels very
> cumbersome for such a trivial issue.

Arnd and Olof have been complaining about this problem which is worse
when it is a binding, driver and dts.

I'm open to maintaining a branch for this purpose if that helps. That
or staggering merging of bindings and drivers/dts are the only ideas
I've come up with.

> How about allowing binding descriptions to be merged without the header
> file, so long as it is merged through another tree?

I think that is wrong if we have the goal to separate bindings from
the kernel and the bindings should stand on their own. However, if it
greatly simplifies things, i'd be okay with that.

Rob
--
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/