linux-kernel - Re: [PATCH 1/4][V2] drivers: spi: core: Add optional delay between cs

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]

Date:   Thu, 18 Jul 2019 13:36:54 +0000
From:   "Ardelean, Alexandru" <alexandru.Ardelean@...log.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "jic23@...nel.org" <jic23@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Hennerich, Michael" <Michael.Hennerich@...log.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>
Subject: Re: [PATCH 1/4][V2] drivers: spi: core: Add optional delay between
 cs_change transfers

On Thu, 2019-07-18 at 13:50 +0100, Mark Brown wrote:
> On Wed, Jul 17, 2019 at 02:51:06PM +0300, Alexandru Ardelean wrote:
> > Some devices like the ADIS16460 IMU require a stall period between
> > transfers, i.e. between when the CS is de-asserted and re-asserted. The
> > default value of 10us is not enough. This change makes the delay
> > configurable for when the next CS change goes active.
> 
> To repeat my previous feedback:
> 
> > This looks like cs_change_delay.

Ack.
Will use `cs_change_delay`.
I have no strong preference regarding the name.

> 
> Please use subject lines matching the style for the subsystem.  This
> makes it easier for people to identify relevant patches.

Ack.
Will look for SPI subsystem specific subject lines and use them.

> 
> Please don't ignore review comments, people are generally making them
> for a reason and are likely to have the same concerns if issues remain
> unaddressed.  Having to repeat the same comments can get repetitive and
> make people question the value of time spent reviewing.  If you disagree
> with the review comments that's fine but you need to reply and discuss
> your concerns so that the reviewer can understand your decisions.

[ the following part should not be considered in a disrespectful tone ; the intent is nowhere near that, but text-
communication has a design-flaw where a disrespectful tone may be interpreted [where there isn't one] ]

My intent wasn't to ignore the review comment.
Sorry if it came out like that.

I assumed a patch re-spin was preferred vs a verbal discussion.
Some people prefer patch re-spins as a basis for discussion.
Various people have various preferences.

Also, I wasn't sure how soon I'd get a reply back on this, since various people/maintainers have various reply-times.
And I also [sometimes] have longer reply-back-times [which doesn't help either].
And I wasn't sure if `cs_change_delay` was fully intentional/ad-literam, or whether it was a feedback of the sorts
"along-the-lines of `cs_change_delay`".

While looking at `struct spi_transfer` the other "delay" fields seem to be: `word_delay_usecs` & `delay_usecs`, which is
why I assumed `cs_change_delay_usecs` was preferred [though I will admit, it is a long var-name].

And the conclusion [from my side] is: maybe I rushed this a bit and maybe it annoyed you.
Not my intention, and it'll take me a bit to adjust to your style.

Moving forward.

1. I will use `cs_change_delay` as field name 
2. I will use SPI subsystem subject line; I will admit I forget this stuff periodically

Is there anything else I should consider?
Or anything else to discuss?

I'm open to elements I may have forgotten/omitted unintentionally.

Thanks
Alex