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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 18 Sep 2017 22:49:44 +0930
From:   Joel Stanley <>
To:     Andrew Jeffery <>
Cc:     Lee Jones <>, Rob Herring <>,
        Mark Rutland <>,
        Michael Turquette <>,
        Stephen Boyd <>,
        devicetree <>,
        Linux Kernel Mailing List <>,,
        Benjamin Herrenschmidt <>,
        Jeremy Kerr <>,
        Rick Altherr <>,
        Ryan Chen <>
Subject: Re: [PATCH 2/2] clk: Add Aspeed G5 clock driver

On Fri, Sep 15, 2017 at 1:12 PM, Andrew Jeffery <> wrote:
> On Wed, 2017-08-23 at 15:39 +0930, Joel Stanley wrote:
>> This driver supports the ast2500 and derivative BMC SoCs from Aspeed.
>> All of the important clocks are supported, with most non-essential ones
>> also implemented where information is available. I am working with
>> Aspeed to clear up some of the missing information, including the
>> missing parent-sibling relationships.
>> We need to know the rate of the apb clock in order to correctly program
>> the clocksource driver, so the apb and it's parents are created in the
>> The rest of the clocks are created at normal driver probe time. I
>> followed the Gemini driver's lead with using the regmap where I could,
>> but also having a pointer to the base address for use with the common
>> clock callbacks.
>> > Signed-off-by: Joel Stanley <>
>> ---
>>  drivers/clk/Kconfig                      |  12 +
>>  drivers/clk/Makefile                     |   1 +
>>  drivers/clk/clk-aspeed.c                 | 547 +++++++++++++++++++++++++++++++
> The patch subject suggests the implementation is specific to the G5
> series SoC, but the name of the driver is generic. How similar are the
> G4 and G5 clock devices? Is the intent to expand the implementation to
> also cover the G4 series, or should this be renamed to something more
> specific?

The intent is to cover the G4 platforms with the same driver. I sent
this version along early to get feedback on the structure.

As it turns out, it was simple to get the G4 going with the same code.
I'll send a v2 in the next day or so.



Powered by blists - more mailing lists