Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v9 2/2] spi: cadence-quadpsi: Add support for the Cadence
 QSPI controller
To:     Mark Brown <broonie@kernel.org>
Cc:     linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org,
        vigneshr@ti.com, mark.rutland@arm.com, robh+dt@kernel.org,
        devicetree@vger.kernel.org, dan.carpenter@oracle.com,
        cheol.yong.kim@intel.com, qi-ming.wu@intel.com
References: <20200214114618.29704-1-vadivel.muruganx.ramuthevar@linux.intel.com>
 <20200214114618.29704-3-vadivel.muruganx.ramuthevar@linux.intel.com>
 <20200214130952.GI4827@sirena.org.uk>
 <3530edcd-eb67-8ea5-0fce-89c83400441c@linux.intel.com>
 <20200217170901.GS9304@sirena.org.uk>
From:   "Ramuthevar, Vadivel MuruganX" 
        <vadivel.muruganx.ramuthevar@linux.intel.com>
Message-ID: <debe614e-e5fe-edd4-8890-1b993d605f85@linux.intel.com>
Date:   Tue, 18 Feb 2020 11:17:11 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20200217170901.GS9304@sirena.org.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Mark,

On 18/2/2020 1:09 AM, Mark Brown wrote:
> On Mon, Feb 17, 2020 at 05:18:10PM +0800, Ramuthevar, Vadivel MuruganX wrote:
>> On 14/2/2020 9:09 PM, Mark Brown wrote:
>>> This will unconditionally handle the interrupt regardless of if the
>>> hardware was actually flagging an interrupt which will break shared
>>> interrupts and the fault handling code in genirq.
>> Yes, you're correct, it doesn't check unconditionally, will update the
>> INT flag in the INT_STATUS register after successful completion of
>> read/write operation.
>> but in this case it is dedicated to qspi-interrupt,not shared with any other
>> HW/SW interrupts.
> Currently, on the system you're looking at.  Given that this is already
> a widely reused IP there's no guarantee that this will always be the
> case, and like I say even without sharing it also defeats the fault
> handling code.
Got it, Thanks! a lot
will take care of it, even though it is not present in the system 
current,? to avoid future conflicts.
Flagging and check to be added? to avoid? if the interrupt raises from 
shared? devices.

Regards
Vadivel