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: <61f24d16-5095-76e4-845e-2434029fe1f0@suse.de>
Date:   Mon, 30 Apr 2018 12:45:20 +0200
From:   Andreas Färber <afaerber@...e.de>
To:     Thierry Reding <thierry.reding@...il.com>,
        Wesley Terpstra <wesley@...ive.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Noralf Trønnes <noralf@...nnes.org>,
        David Lechner <david@...hnology.com>,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        SZ Lin <sz.lin@...a.com>, linux-pwm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: added new pwm-sifive driver
 documentation

Am 30.04.2018 um 10:19 schrieb Thierry Reding:
> On Sun, Apr 29, 2018 at 02:08:07PM -0700, Wesley Terpstra wrote:
>> On Sun, Apr 29, 2018 at 2:01 PM, Andreas Färber <afaerber@...e.de> wrote:
>>> "pwm0" sounds like a zero-indexed instance of some pwm block. If 0 is
>>> the version here, I'd suggest to make it "pwm-0" for example - you might
>>> want to take a look at the Xilinx bindings, which use a strict x.yy suffix.
>>
>> That's fine. I'll change it to pwm-0.00 in the next patch series.
> 
> This should match the version that you use. If you're internal
> versioning uses single digits, or a single version number, then I think
> there's no need to use 0.00, because that would just be confusing.
> However I think it'd be good to make sure it is discernible as a version
> number. Perhaps something like sifive,pwm-v0. That seems to be a fairly
> common scheme.

Yes. My point was not to adopt another vendor's versioning scheme but to
adopt _some_ consistent scheme and document it, e.g., in a sifive.txt
similar to xilinx.txt:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/xilinx.txt

It should be made clear what in the compatible string the version is
(thus my proposal of using a dash as separator), and there you may want
to document how to map between IP/documentation and compatibles for any
new bindings.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ