linux-kernel - Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

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: <04e3986b-bbeb-50ad-30e0-fb74bb534aa6@ti.com>
Date:   Tue, 25 Jul 2017 13:14:26 -0500
From:   Franklin S Cooper Jr <fcooper@...com>
To:     Oliver Hartkopp <socketcan@...tkopp.net>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <netdev@...r.kernel.org>, <linux-can@...r.kernel.org>,
        <wg@...ndegger.com>, <mkl@...gutronix.de>, <robh+dt@...nel.org>,
        <quentin.schulz@...e-electrons.com>,
        <dev.kurt@...dijck-laurijssen.be>, <andrew@...n.ch>,
        <sergei.shtylyov@...entembedded.com>
Subject: Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN
 fixed transceiver bindings



On 07/25/2017 11:32 AM, Oliver Hartkopp wrote:
> 
>> + max-data-speed:    a positive non 0 value that determines the max
>> data rate
>> +            that can be used in CAN-FD mode. A value of -1 implies
>> +            CAN-FD is not supported by the transceiver.
>> +
>> +Examples:
> 
> (..)
> 
>> +    fixed-transceiver {
>> +        max-data-speed = <(-1)>;
> 
> Looks ugly IMHO.
> 
> Why didn't you stay on '0' for 'not supported'??

Unless a driver specifically calls of_can_transceiver_fixed
priv->max_trans_data_speed will be by default 0. Therefore, all drivers
that support CAN-FD will claim that the transceiver indicates that it
isn't supported. So one option was to update every single driver to set
this property by default which I started to do but it end up becoming a
massive patch and it was risky in case I missed a driver which would of
resulted in major regressions. Its also problematic for new drivers that
miss this property or the many out of tree CAN drivers. The other option
was to create another variable to track to see if
of_can_transceiver_fixed was called but I didn't think that was the
better solution. So using signed values in DT is a bit ugly due to
syntax but was valid and I made sure I documented it so its clear.
> 
> Regards,
> Oliver
>