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: <87773927e37c4d70862c5f047431c7b0@ti.com>
Date: Tue, 10 Feb 2026 11:08:16 +0000
From: "Holalu Yogendra, Niranjan" <niranjan.hy@...com>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>,
	"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/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.

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.

> > +	} 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.

Regards
Niranjan