netdev - Re: [RFC PATCH] dt-binding: net: sfp binding documentation

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] [day] [month] [year] [list]

Message-ID: <CAL_JsqJpNAFiKDpFxMX4ScAktp6gVs7oAjpAG++bkF6DnyU=Zw@mail.gmail.com>
Date:   Wed, 23 Aug 2017 11:18:38 -0500
From:   Rob Herring <robh+dt@...nel.org>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Baruch Siach <baruch@...s.co.il>,
        Mark Rutland <mark.rutland@....com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [RFC PATCH] dt-binding: net: sfp binding documentation

On Wed, Aug 23, 2017 at 8:57 AM, Russell King - ARM Linux
<linux@...linux.org.uk> wrote:
> On Mon, Aug 21, 2017 at 02:12:42PM -0500, Rob Herring wrote:
>> On Mon, Aug 21, 2017 at 10:06 AM, Baruch Siach <baruch@...s.co.il> wrote:
>> > Hi Russell,
>> >
>> > On Mon, Aug 21, 2017 at 01:53:17PM +0100, Russell King - ARM Linux wrote:
>> >> On Sun, Aug 20, 2017 at 01:28:06PM +0300, Baruch Siach wrote:
>> >> > Add device-tree binding documentation SFP transceivers. Support for SFP
>> >> > transceivers has been recently introduced (drivers/net/phy/sfp.c).
>> >> >
>> >> > Signed-off-by: Baruch Siach <baruch@...s.co.il>
>> >> > ---
>> >> >
>> >> > The SFP driver is on net-next.
>> >> >
>> >> > Not sure about the rate-select-gpio property name. The SFP+ standard
>> >> > (not supported yet) uses two signals, RS0 and RS1. RS0 is compatible
>> >> > with the SFP rate select signal, while RS1 controls the Tx rate.
>> >>
>> >> SFP+ is usable with this, but the platforms I have do not wire the
>> >> rate select pins on the SFP+ sockets to GPIOs, but hard-wire them.
>> >
>> > So maybe naming this signal 'rate-select0-gpio' would make it more future
>> > (SPF+) proof? Or 'rate-select-rx-gpio'?
>>
>> Just extend it by making it an array of 2 gpios.
>
> What do you do if you have only one rate select wired up and it doesn't
> correspond with the first?

Seems unlikely, but possible I guess. In that case, 2 properties is
probably better. Otherwise, you'd have to put in -1 or 0 for the first
phandle.

Rob