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]
Date:   Sat, 23 Dec 2017 21:06:26 -0800
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Jassi Brar <jassisinghbrar@...il.com>
Cc:     Georgi Djakov <georgi.djakov@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Michael Turquette <mturquette@...libre.com>,
        Rob Herring <robh@...nel.org>, linux-clk@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm@...r.kernel.org,
        Devicetree List <devicetree@...r.kernel.org>
Subject: Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for
 clock controller

On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:

> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@...aro.org> wrote:
> > There is a clock controller functionality provided by the APCS hardware
> > block of msm8916 devices. The device-tree would represent an APCS node
> > with both mailbox and clock provider properties.
> >
> The spec might depict a 'clock' box and 'mailbox' box inside the
> bigger APCS box. However, from the code I see in this patchset, they
> are orthogonal and can & should be represented as independent DT
> nodes.

The APCS consists of a number of different hardware blocks, one of them
being the "APCS global" block, which is what this node and drivers
relate to. On 8916 this contains both the IPC register and clock
control. But it's still just one block according to the hardware
specification.

As such DT should describe the one hardware block by one node IMHO. The
fact that we in Linux split this into two different drivers is an
unrelated implementation detail.

Regards,
Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ