Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [EXTERNAL] Re: [PATCH 2/2] spi: cadence-quadspi: Fix check
 condition for DTR ops
To:     Mark Brown <broonie@kernel.org>
CC:     <linux-spi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        Pratyush Yadav <p.yadav@ti.com>,
        Vignesh Raghavendra <vigneshr@ti.com>
References: <20210713125743.1540-1-a-nandan@ti.com>
 <20210713125743.1540-3-a-nandan@ti.com> <20210713183903.GH4098@sirena.org.uk>
From:   "Nandan, Apurva" <a-nandan@ti.com>
Message-ID: <bea11e83-2c26-57b5-1a42-8ce852dc26ba@ti.com>
Date:   Wed, 14 Jul 2021 18:24:28 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210713183903.GH4098@sirena.org.uk>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 14-Jul-21 12:09 AM, Mark Brown wrote:
> On Tue, Jul 13, 2021 at 12:57:42PM +0000, Apurva Nandan wrote:
> 
>> +	f_pdata->dtr = op->cmd.dtr &&
>> +		       (op->addr.dtr || !op->addr.nbytes) &&
>> +		       (op->data.dtr || !op->data.nbytes);
> 
> I'm not sure anyone reading this code is going to figure out what it's
> doing without thinking about it, the combination of writing the bytes
> check with a !, putting it after the check for .dtr and not having any
> comments is a bit obscure.  Something like
> 
> 	(op->addr.nbytes && op.addr.dtr)
> 
> might be a bit clearer, or a comment explicitly spelling it out.
> 

Okay, I will add a comment explaining it, as other logic (with &&) won't
deliver the behavior we expect.

The logic it implements is: for an op to be dtr, if any phase has
non-zero bytes, it must have dtr field set as true. So, it does p
implies q: p->q = (!p || q) i.e. if phase has non-zero bytes (p) then
check its dtr field (q). If all phases are empty, then follow what
op.cmd.dtr says.

Regards,
Apurva Nandan