linux-kernel - RE: [PATCH 7/9] soundwire: intel/cadence: merge Soundwire interrupt handlers/threads

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: <MN2PR11MB4080CF23D00A3AF817AC1E7CFF6D0@MN2PR11MB4080.namprd11.prod.outlook.com>
Date:   Thu, 2 Jul 2020 07:35:16 +0000
From:   "Liao, Bard" <bard.liao@...el.com>
To:     Vinod Koul <vkoul@...nel.org>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
CC:     Bard Liao <yung-chuan.liao@...ux.intel.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "tiwai@...e.de" <tiwai@...e.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ranjani.sridharan@...ux.intel.com" 
        <ranjani.sridharan@...ux.intel.com>,
        "hui.wang@...onical.com" <hui.wang@...onical.com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "srinivas.kandagatla@...aro.org" <srinivas.kandagatla@...aro.org>,
        "jank@...ence.com" <jank@...ence.com>,
        "Lin, Mengdong" <mengdong.lin@...el.com>,
        "Blauciak, Slawomir" <slawomir.blauciak@...el.com>,
        "Kale, Sanyog R" <sanyog.r.kale@...el.com>,
        "rander.wang@...ux.intel.com" <rander.wang@...ux.intel.com>
Subject: RE: [PATCH 7/9] soundwire: intel/cadence: merge Soundwire interrupt
 handlers/threads

> -----Original Message-----
> From: Vinod Koul <vkoul@...nel.org>
> Sent: Wednesday, July 1, 2020 1:42 PM
> To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
> Cc: Bard Liao <yung-chuan.liao@...ux.intel.com>; alsa-devel@...a-project.org;
> tiwai@...e.de; gregkh@...uxfoundation.org; linux-kernel@...r.kernel.org;
> ranjani.sridharan@...ux.intel.com; hui.wang@...onical.com;
> broonie@...nel.org; srinivas.kandagatla@...aro.org; jank@...ence.com; Lin,
> Mengdong <mengdong.lin@...el.com>; Blauciak, Slawomir
> <slawomir.blauciak@...el.com>; Kale, Sanyog R <sanyog.r.kale@...el.com>;
> rander.wang@...ux.intel.com; Liao, Bard <bard.liao@...el.com>
> Subject: Re: [PATCH 7/9] soundwire: intel/cadence: merge Soundwire interrupt
> handlers/threads
> 
> On 30-06-20, 11:46, Pierre-Louis Bossart wrote:
> 
> > > Is this called from irq context or irq thread or something else?
> >
> > from IRQ thread, hence the name, see pointers above.
> >
> > The key part is that we could only make the hardware work as intended by
> > using a single thread for all interrupt sources, and that patch is just the
> > generalization of what was implemented for HDaudio in mid-2019 after
> months
> > of lost interrupts and IPC errors. See below the code from
> > sound/soc/sof/intel/hda.c for interrupt handling.
> 
> Sounds good. Now that you are already in irq thread, does it make sense
> to spawn a worker thread for this and handle it there? Why not do in the
> irq thread itself. Using a thread kind of defeats the whole point behind
> concept of irq threads

Not sure If you are talking about cdns_update_slave_status_work().
The reason we need to spawn a worker thread in sdw_cdns_irq() is
that we will do sdw transfer which will generate an interrupt when
a slave interrupt is triggered. And the handler will not be invoked if the
previous handler is not return yet. 
Please see the scenario below for better explanation.
1. Slave interrupt arrives
	2.1 Try to read Slave register and waiting for the transfer response
	2.2 Get the transfer response interrupt and finish the sdw transfer.
3. Finish the Slave interrupt handling.

Interrupts are triggered in step 1 and 2.2, but step 2.2's handler will not be
invoked if step 1's handler is not return yet.
What we do is to spawn a worker thread to do step 2 and return from step 1.
So the handler can be invoked when the transfer response interrupt arrives.

> 
> --
> ~Vinod