linux-kernel - Re: [PATCH 1/8] spi: dt-bindings: Introduce spi-cs-setup-ns property

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: <28da9e33-57e8-7ac1-7e6c-13c297a945d6@gmail.com>
Date:   Mon, 2 Jan 2023 11:37:40 +0200
From:   Tudor Ambarus <tudor.ambarus@...il.com>
To:     Mark Brown <broonie@...nel.org>, Michael Walle <michael@...le.cc>
Cc:     tudor.ambarus@...rochip.com, alexandre.belloni@...tlin.com,
        claudiu.beznea@...rochip.com, devicetree@...r.kernel.org,
        krzysztof.kozlowski+dt@...aro.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mtd@...ts.infradead.org, linux-spi@...r.kernel.org,
        nicolas.ferre@...rochip.com, robh+dt@...nel.org
Subject: Re: [PATCH 1/8] spi: dt-bindings: Introduce spi-cs-setup-ns property

Hi,

On 18.11.2022 17:30, Mark Brown wrote:
> On Fri, Nov 18, 2022 at 03:14:58PM +0100, Michael Walle wrote:
>> From: Tudor Ambarus <tudor.ambarus@...rochip.com>
> 
>>> +  spi-cs-setup-ns:
>>> +    description:
>>> +      Delay in nanosecods to be introduced by the controller after CS is
>>> +      asserted.
> 
>> Does this need a type as the spi-cs-setup-ns is apparently just 16bit? At
>> least the driver uses it that way.
> 
>> But IMHO this should just be a normal uint32 value to be consistent with
>> all the other properties. Also the max value with 16bit will be 'just'
>> 65us.
> 
> Making it 32 bit does seem safer.  I've applied the series

Thanks. There are few implications to consider before making this prop a
u32, and I'd like to check them with you.

struct spi_delay will have to be updated to have a u32 value, now it's a
u16. This means that we'll have to update spi_delay_to_ns() to either
return a s64 or to add a u64 *delay parameter to the function so that we
can still handle the conversions from usecs and the error codes in the
SPI_DELAY_UNIT_SCK case. Then all its callers have to be updated to
consider the u64 delay.

I don't know what to say, I'm in between. 65us delays are improbable,
but I'm fine to update this as well. Let me know your preference.

Thanks,
ta