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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 17 Feb 2017 12:32:05 +0100
From:   Arnd Bergmann <>
To:     Andreas Färber <>
Cc:     Linux ARM <>,,,,
        Will Deacon <>,
        Linux Kernel Mailing List <>,
        Catalin Marinas <>
Subject: Re: [PATCH 04/11] ARM64: Prepare Actions Semi S900

On Fri, Feb 17, 2017 at 1:34 AM, Andreas Färber <> wrote:
> Am 16.02.2017 um 14:43 schrieb Arnd Bergmann:
>> On Wednesday, February 15, 2017 5:55:21 PM CET Andreas Färber wrote:
>>> +config ARCH_OWL
>>> +       bool "Actions Semi S900 SoC Family"
>>> +       help
>>> +         This enables support for the Actions Semiconductor S900 SoC family.
>>> +
>> There seem to be a couple of other SoCs in the same family, so
>> maybe use a more generic name than S900 in the one-line
>> Kconfig description.
> Good point. I only tested with `make oldconfig`, so using "Owl" should
> tidy the sort order in `make menuconfig` while at it. (I believe there
> were more inconsistent examples, such as Armada 3700 vs. MVEBU...)
> Note that I have not come across any explanation for "OWL" as an
> acronym, so I'm guessing it's the bird and therefore capitalizing it.
> Apart from S900, shows V series S900VR and S700 as well
> as GT series GT7 Cortex-A53 based SoCs. My guess[*] is these could all
> be handled as ARCH_OWL, adding further differentiation below if
> necessary; but Bubblegum-96 seemed the only available arm64 board for
> testing so far, so any comments from Actions will be appreciated.
> [*] The S500 vendor device tree was actually using ATM series models for
> various nodes, so I'm inferring that the product series are closely
> enough related.
> However, if you would prefer ARCH_ACTIONS I wouldn't mind either - we
> just need to keep it consistent across arm and arm64.

ARCH_ACTIONS seems best to me. We tend to go for the broader names
per company these days even when things are not closely related. This
avoids having to rename things when a new line of products comes up
that shares a subset of the components but doesn't fit under the old name.


Powered by blists - more mailing lists