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:   Mon, 5 Sep 2016 14:12:47 +0200
From:   Rafał Miłecki <zajec5@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>, linux-clk@...r.kernel.org,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        Rafał Miłecki <rafal@...ecki.pl>,
        Mark Rutland <mark.rutland@....com>,
        Eric Anholt <eric@...olt.net>,
        Jon Mason <jonmason@...adcom.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Stephen Warren <swarren@...dotorg.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V5] clk: bcm: Add driver for BCM53573 ILP clock

On 31 August 2016 at 18:16, Rob Herring <robh@...nel.org> wrote:
> On Thu, Aug 25, 2016 at 02:42:52PM +0200, Rafał Miłecki wrote:
>> On 23 August 2016 at 21:55, Rob Herring <robh@...nel.org> wrote:
>> > On Tue, Aug 23, 2016 at 08:25:59AM +0200, Rafał Miłecki wrote:
>> >> From: Rafał Miłecki <rafal@...ecki.pl>
>> >>
>> >> This clock is present on BCM53573 devices (including BCM47189) that use
>> >> Cortex-A7. ILP is a part of PMU (Power Management Unit) and so it should
>> >> be defined as one of its subnodes (subdevices). For more details see
>> >> Documentation entry.
>> >>
>> >> Unfortunately there isn't a set of registers related to ILP clock only.
>> >> We use registers 0x66c, 0x674 and 0x6dc and between them there are e.g.
>> >> "retention*" and "control_ext" regs. This is why this driver maps all
>> >> 0x1000 B of space.
>> >
>> > Then describe the block as a syscon which has several functions of
>> > which clocks are one.
>>
>> This isn't clear to me, sorry, could you describe it? Would you like
>> me to update commit message or documentation? Is code fine as is?
>
> Let me put it another way, when you need to use the other registers, how
> do you plan to describe them in DT? We don't really want a node per
> register, nor do I want to get binding docs one by one as you add each
> function. Instead describe the block with all the misc functions as a
> whole. What would you call that block? Still ILP or something else?
>
> Also, you if you do have multiple drivers all needing to access this
> single block, then that is when you need syscon and regmap.

I got this now, thanks for your patience.

One last question: what is preferred register reference:
1) Parent-child (of_get_parent + syscon_node_to_regmap)
or
2) DT property (syscon_regmap_lookup_by_phandle(dt, "foo"))

-- 
Rafał

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ