[PATCH v3 8/9] media: chips-media: wave6: Add Wave6 control driver

[Nas Chung]

Hi, Krzysztof.

>-----Original Message-----
>From: Krzysztof Kozlowski <krzk at kernel.org>
>Sent: Monday, September 1, 2025 7:44 PM
>To: Nas Chung <nas.chung at chipsnmedia.com>; mchehab at kernel.org;
>hverkuil at xs4all.nl; robh at kernel.org; krzk+dt at kernel.org;
>conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de
>Cc: linux-media at vger.kernel.org; devicetree at vger.kernel.org; linux-
>kernel at vger.kernel.org; linux-imx at nxp.com; linux-arm-
>kernel at lists.infradead.org; jackson.lee <jackson.lee at chipsnmedia.com>;
>lafley.kim <lafley.kim at chipsnmedia.com>; Ming Qian <ming.qian at oss.nxp.com>
>Subject: Re: [PATCH v3 8/9] media: chips-media: wave6: Add Wave6 control
>driver
>
>On 01/09/2025 10:13, Nas Chung wrote:
>> Hi, Krzysztof.
>>
>> Thanks for the feedback.
>>
>>> -----Original Message-----
>>> From: Krzysztof Kozlowski <krzk at kernel.org>
>>> Sent: Friday, August 29, 2025 11:06 PM
>>> To: Nas Chung <nas.chung at chipsnmedia.com>; mchehab at kernel.org;
>>> hverkuil at xs4all.nl; robh at kernel.org; krzk+dt at kernel.org;
>>> conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de
>>> Cc: linux-media at vger.kernel.org; devicetree at vger.kernel.org; linux-
>>> kernel at vger.kernel.org; linux-imx at nxp.com; linux-arm-
>>> kernel at lists.infradead.org; jackson.lee <jackson.lee at chipsnmedia.com>;
>>> lafley.kim <lafley.kim at chipsnmedia.com>; Ming Qian
><ming.qian at oss.nxp.com>
>>> Subject: Re: [PATCH v3 8/9] media: chips-media: wave6: Add Wave6 control
>>> driver
>>>
>>> On 29/08/2025 10:46, Nas Chung wrote:
>>>> +
>>>> +static void wave6_vpu_load_firmware(const struct firmware *fw, void
>>> *context)
>>>> +{
>>>> +	struct wave6_vpu_device *vpu = context;
>>>> +
>>>> +	guard(mutex)(&vpu->lock);
>>>
>>> Why? How could this be called in parallel, before the probe?
>>
>> This callback is called asynchronously via
>firmware_request_nowait_nowarn().
>> In practice, I observed a case where the callback was executing
>> while the device's release() function was being called.
>
>Indeed. Now I wonder how does it protect from concurrent remove()?

The callback checks the fw_available flag and returns immediately if false.
This flag is cleared in the remove() path under the lock.

Thanks,
Nas.

>
>Best regards,
>Krzysztof