Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ec632e64-2d9c-3f71-4fe7-e1c6acb81393@quicinc.com>
Date:   Thu, 29 Dec 2022 23:10:36 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [RFC PATCH 04/14] sound: usb: card: Introduce USB SND vendor op
 callbacks
Content-Language: en-US
To:     Takashi Iwai <tiwai@suse.de>, Oliver Neukum <oneukum@suse.com>
CC:     <srinivas.kandagatla@linaro.org>, <mathias.nyman@intel.com>,
        <perex@perex.cz>, <broonie@kernel.org>, <lgirdwood@gmail.com>,
        <andersson@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
        <gregkh@linuxfoundation.org>, <Thinh.Nguyen@synopsys.com>,
        <bgoswami@quicinc.com>, <tiwai@suse.com>, <robh+dt@kernel.org>,
        <agross@kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-arm-msm@vger.kernel.org>, <alsa-devel@alsa-project.org>,
        <devicetree@vger.kernel.org>, <linux-usb@vger.kernel.org>,
        <quic_jackp@quicinc.com>, <quic_plai@quicinc.com>
References: <20221223233200.26089-1-quic_wcheng@quicinc.com>
 <20221223233200.26089-5-quic_wcheng@quicinc.com>
 <80f92635-6d14-8ff3-17ac-de2e5b977947@suse.com> <87lemqxpet.wl-tiwai@suse.de>
From:   Wesley Cheng <quic_wcheng@quicinc.com>
In-Reply-To: <87lemqxpet.wl-tiwai@suse.de>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,

On 12/29/2022 6:20 AM, Takashi Iwai wrote:
> On Thu, 29 Dec 2022 14:49:21 +0100,
> Oliver Neukum wrote:
>>
>>
>>
>> On 24.12.22 00:31, Wesley Cheng wrote:
>>> Allow for different vendors to be notified on USB SND connect/disconnect
>>> seqeunces.  This allows for vendor USB SND modules to properly initialize
>>> and populate internal structures with references to the USB SND chip
>>> device.
>>
>> Hi,
>>
>> this raises a design question. If the system is suspending or, worse,
>> hibernating, how do you make sure the offloader and the device are
>> suspended in the correct order?
>> And what happens if you need to go into reset_resume() when resuming?

It may depend on how the offloading is implemented, but we do have a 
mechanism to force the audio stream off from the qc_usb_audio_offload. 
Regardless of if the UDEV is suspended first, or the USB backend, as 
long as we ensure that the offloading is disabled before entering 
suspend, I think that should be sufficient.  I would need to add some 
suspend handling in the offload driver to issue the command to stop the 
offloading.

As for the resume path, is there a concern if either device is resumed 
first?  The only scenario where maybe it could cause some mishandling is 
if the USB backend is resumed before the offload driver is 
connected/resumed.  This means that the userspace ALSA would have access 
to the platform sound card, and could potentially attempt to route audio 
streams to it.  I think in worst case, if we were going through a 
reset_resume() we would end up rejecting that request coming from the 
audio DSP to enable the stream.  However, userspace entities would be 
resumed/unfrozen last, so not sure if that would ever be a problem.

The reset_resume() path is fine.  Bus reset is going to cause a 
disconnect() callback in the offload driver, in which we already have 
the proper handling for ensuring the offload path is halted, and we 
reject any incoming stream start requests.

Thanks
Wesley Cheng