linux-kernel - Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP

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: <e9e27355-a3d1-4ae2-aa6a-da47c6bced1f@linux.dev>
Date: Tue, 10 Feb 2026 18:04:26 +0100
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>
To: "Holalu Yogendra, Niranjan" <niranjan.hy@...com>,
 "linux-sound@...r.kernel.org" <linux-sound@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "yung-chuan.liao@...ux.intel.com" <yung-chuan.liao@...ux.intel.com>
Cc: "broonie@...nel.org" <broonie@...nel.org>,
 "ckeepax@...nsource.cirrus.com" <ckeepax@...nsource.cirrus.com>,
 "shumingf@...ltek.com" <shumingf@...ltek.com>,
 "lgirdwood@...il.com" <lgirdwood@...il.com>,
 "ranjani.sridharan@...ux.intel.com" <ranjani.sridharan@...ux.intel.com>,
 "cezary.rojewski@...el.com" <cezary.rojewski@...el.com>,
 "peter.ujfalusi@...ux.intel.com" <peter.ujfalusi@...ux.intel.com>,
 "kai.vehmanen@...ux.intel.com" <kai.vehmanen@...ux.intel.com>,
 "vkoul@...nel.org" <vkoul@...nel.org>, "Ding, Shenghao"
 <shenghao-ding@...com>, "Xu, Baojun" <baojun.xu@...com>,
 "Kasargod, Sandeep" <sandeepk@...com>,
 Richard Fitzgerald <rf@...nsource.cirrus.com>
Subject: Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for
 Simplified_CP_SM

On 2/10/26 12:08, Holalu Yogendra, Niranjan wrote:
>> On 2/9/26 20:13, Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev> wrote:
>> Subject: Re: [PATCH v1 RESEND] SoundWire: Allow Prepare
>> command for Simplified_CP_SM
>>
>> On 2/9/26 08: 09, Niranjan H Y wrote: 
>>> In TI device implementations, we've found that some devices with
>>> Simplified_CP_SM still benefit from receiving the Prepare command.
>> It would also be good to clarify when the device is actually prepared after the
>> bits are set, if the implementation cannot guarantee that the prepared status is
>> reached by the end of the frame where the write occurs, then it's definitively
>> NOT a Simplified_CP_SM.
>>
>> What happens is the simple_ch_prep_sm bit is not set for those devices, and
>> the regular state machine is used instead? Is anything broken?
> 
> We need to use the same BIOS between Windows and Linux. The BIOS configures
> the device as Simplified_CP_SM. The device also expects the Prepare bits to be
> set. If the device is configured as generic CP_SM, the status "Port Ready" 
> bits will not be updated and we end up with port prepare fail errors.

Are you referring to the DPN_IntStat::PortReady bit? IOW do the errors during prepare happen because the interrupt is not generated?

If that is the case, then you should be aware of the thread "soundwire: stream: Prepare ports in parallel to reduce stream start latency", where it was agreed that the use of the PortReady interrupt is broken. We do need to move to a different code where we have a polling loop on the DPN_PrepareStatus::NotFinished bits.

So is the problem in the interrupt generation, or is the problem with the 'Not Finished' bits?

> So, setting the device to simplified CP_SM and ignoring the "port ready" bits is the
> best option we have.
> 
> The TI's HW is implemented referring to the "Figure 141 Channel Prepare State 
> Machine" for Simplified_CP_SM of the spec. where Prepare0 OR Prepare1 are shown in the
> image interpreting it as setting prepare/de-prepare bits.

right, but are the 'Not Finished' bits updated after the write when the transition to the prepared state is complete?
If that works then an alternate solution to this patch would be to quirk all TI devices to use the regular state machine, and use the polling loop as suggested by Richard Fitzgerald.

>>> +	} else {
>>> +		/* Some device return error for the prepare command,
>>> +		 * ignore the error for Simplified CP_SM
>>
>> that comment is misleading anyways, it's not 'some device' it's ALL the
>> conformant devices that will return Command_Ignored when trying to write
>> read-only bits. You haven't described what the TI devices would return in this
>> case.
> TI device doesn't return any error code while setting the  prepare bits command while
> in Simplified_CP_SM mode. It accepts the write to the register without complaint.
> 
> I agree that the comment could  be updated. We should indicate that we're 
> deliberately sending writes to what should be write-ignored bits for compatibility 
> reasons, while ensuring any potential errors from fully spec-compliant devices are 
> handled gracefully.
I think it's worth exploring what happens if the PortReady interrupt is not used. If that's broken as well, then your solution would work but needs more/better comments indeed.