soundwire: suppress expected unattach warnings during codec reset

[PATCH 0/2] soundwire: suppress expected unattach warnings during codec reset

Posted by Cole Leavitt 1 month, 2 weeks ago

On systems with CS35L56 SoundWire codecs (e.g. Lenovo ThinkPad P16
Gen3), every boot produces misleading dev_warn() messages:

  cs35l56 sdw:0:2:01fa:3556:01:0: Slave 2 state check1: UNATTACHED, status was 1
  cs35l56 sdw:0:2:01fa:3556:01:1: Slave 1 state check1: UNATTACHED, status was 1

These fire when the CS35L56 driver triggers a system reset after
firmware download, which physically detaches the codec from the bus.
This is expected and handled gracefully -- the driver waits for
re-enumeration and the codec recovers within milliseconds.

The warnings were added in commit d1b328557058 ("soundwire: bus: add
dev_warn() messages to track UNATTACHED devices") to debug genuine
attachment failures. They remain valuable for unexpected detachments,
but firing on every boot for normal codec operation degrades their
diagnostic value.

This series adds a simple boolean flag (unattach_pending) to struct
sdw_slave that codec drivers can set before triggering an expected
detach. When set, the bus layer emits dev_dbg() instead of dev_warn()
and auto-clears the flag.

Note: There is also a separate set of UNATTACHED warnings during
initial multi-device enumeration, caused by the known PING frame race
documented in cadence_master.c. That is a different problem with
different constraints and is not addressed here.

Cole Leavitt (2):
  soundwire: bus: downgrade expected unattach warnings to dev_dbg
  ASoC: cs35l56: set unattach_pending before SoundWire system reset

 drivers/soundwire/bus.c       | 9 +++++++--
 include/linux/soundwire/sdw.h | 1 +
 sound/soc/codecs/cs35l56.c    | 4 ++++
 3 files changed, 12 insertions(+), 2 deletions(-)

-- 
2.52.0

Re: [PATCH 0/2] soundwire: suppress expected unattach warnings during codec reset

Posted by Vinod Koul 3 weeks, 3 days ago

On Tue, 17 Feb 2026 16:35:31 -0700, Cole Leavitt wrote:
> On systems with CS35L56 SoundWire codecs (e.g. Lenovo ThinkPad P16
> Gen3), every boot produces misleading dev_warn() messages:
> 
>   cs35l56 sdw:0:2:01fa:3556:01:0: Slave 2 state check1: UNATTACHED, status was 1
>   cs35l56 sdw:0:2:01fa:3556:01:1: Slave 1 state check1: UNATTACHED, status was 1
> 
> These fire when the CS35L56 driver triggers a system reset after
> firmware download, which physically detaches the codec from the bus.
> This is expected and handled gracefully -- the driver waits for
> re-enumeration and the codec recovers within milliseconds.
> 
> [...]

Applied, thanks!

[1/1] soundwire: bus: demote UNATTACHED state warnings to dev_dbg()
      commit: 2c96956fe764f8224f9ec93b2a9160a578949a7a

Best regards,
-- 
~Vinod

Re: [PATCH 0/2] soundwire: suppress expected unattach warnings during codec reset

Posted by Richard Fitzgerald 1 month, 1 week ago

On 17/2/26 23:35, Cole Leavitt wrote:
> On systems with CS35L56 SoundWire codecs (e.g. Lenovo ThinkPad P16
> Gen3), every boot produces misleading dev_warn() messages:
> 
>    cs35l56 sdw:0:2:01fa:3556:01:0: Slave 2 state check1: UNATTACHED, status was 1
>    cs35l56 sdw:0:2:01fa:3556:01:1: Slave 1 state check1: UNATTACHED, status was 1
>

Is this really a problem?
They are warns, not errors. Nothing in that message says that this is
an error, or that it's unexpected. The message is accurate.

> These fire when the CS35L56 driver triggers a system reset after
> firmware download, which physically detaches the codec from the bus.
> This is expected and handled gracefully -- the driver waits for
> re-enumeration and the codec recovers within milliseconds.
> 
> The warnings were added in commit d1b328557058 ("soundwire: bus: add
> dev_warn() messages to track UNATTACHED devices") to debug genuine
> attachment failures. They remain valuable for unexpected detachments,
> but firing on every boot for normal codec operation degrades their
> diagnostic value.
> 
> This series adds a simple boolean flag (unattach_pending) to struct
> sdw_slave that codec drivers can set before triggering an expected
> detach. When set, the bus layer emits dev_dbg() instead of dev_warn()
> and auto-clears the flag.
> 
> Note: There is also a separate set of UNATTACHED warnings during
> initial multi-device enumeration, caused by the known PING frame race
> documented in cadence_master.c. That is a different problem with
> different constraints and is not addressed here.
> 
> Cole Leavitt (2):
>    soundwire: bus: downgrade expected unattach warnings to dev_dbg
>    ASoC: cs35l56: set unattach_pending before SoundWire system reset
> 
>   drivers/soundwire/bus.c       | 9 +++++++--
>   include/linux/soundwire/sdw.h | 1 +
>   sound/soc/codecs/cs35l56.c    | 4 ++++
>   3 files changed, 12 insertions(+), 2 deletions(-)
>

Re: [PATCH 0/2] soundwire: suppress expected unattach warnings during codec reset

Posted by Pierre-Louis Bossart 1 month, 1 week ago

On 2/18/26 11:14, Richard Fitzgerald wrote:
> On 17/2/26 23:35, Cole Leavitt wrote:
>> On systems with CS35L56 SoundWire codecs (e.g. Lenovo ThinkPad P16
>> Gen3), every boot produces misleading dev_warn() messages:
>>
>>    cs35l56 sdw:0:2:01fa:3556:01:0: Slave 2 state check1: UNATTACHED, status was 1
>>    cs35l56 sdw:0:2:01fa:3556:01:1: Slave 1 state check1: UNATTACHED, status was 1
>>
> 
> Is this really a problem?
> They are warns, not errors. Nothing in that message says that this is
> an error, or that it's unexpected. The message is accurate.

I would just demote the dev_warn() to dev_dbg(). 
If you look at the original commit, we were chasing weird cases where we have dyndng enabled anyways.
Also IIRC the problem with 2 devices on the same link was fixed by Richard, wasn't it?
That would make the dev_warn() even less useful.

Re: [PATCH 0/2] soundwire: suppress expected unattach warnings during codec reset

Posted by Richard Fitzgerald 1 month, 1 week ago

On 18/2/26 10:50, Pierre-Louis Bossart wrote:
> On 2/18/26 11:14, Richard Fitzgerald wrote:
>> On 17/2/26 23:35, Cole Leavitt wrote:
>>> On systems with CS35L56 SoundWire codecs (e.g. Lenovo ThinkPad P16
>>> Gen3), every boot produces misleading dev_warn() messages:
>>>
>>>     cs35l56 sdw:0:2:01fa:3556:01:0: Slave 2 state check1: UNATTACHED, status was 1
>>>     cs35l56 sdw:0:2:01fa:3556:01:1: Slave 1 state check1: UNATTACHED, status was 1
>>>
>>
>> Is this really a problem?
>> They are warns, not errors. Nothing in that message says that this is
>> an error, or that it's unexpected. The message is accurate.
> 
> I would just demote the dev_warn() to dev_dbg().
> If you look at the original commit, we were chasing weird cases where we have dyndng enabled anyways.
> Also IIRC the problem with 2 devices on the same link was fixed by Richard, wasn't it?
> That would make the dev_warn() even less useful.
> 
Oh, does it date all the way back to that multiple device problem?
If that's the one I'm thinking of, as I recall it was Simon Trimmer
who fixed that.

Re: [PATCH 0/2] soundwire: suppress expected unattach warnings during codec reset

Posted by Charles Keepax 1 month, 1 week ago

On Wed, Feb 18, 2026 at 11:50:55AM +0100, Pierre-Louis Bossart wrote:
> On 2/18/26 11:14, Richard Fitzgerald wrote:
> > On 17/2/26 23:35, Cole Leavitt wrote:
> >> On systems with CS35L56 SoundWire codecs (e.g. Lenovo ThinkPad P16
> >> Gen3), every boot produces misleading dev_warn() messages:
> >>
> >>    cs35l56 sdw:0:2:01fa:3556:01:0: Slave 2 state check1: UNATTACHED, status was 1
> >>    cs35l56 sdw:0:2:01fa:3556:01:1: Slave 1 state check1: UNATTACHED, status was 1
> >>
> > 
> > Is this really a problem?
> > They are warns, not errors. Nothing in that message says that this is
> > an error, or that it's unexpected. The message is accurate.
> 
> I would just demote the dev_warn() to dev_dbg(). 
> If you look at the original commit, we were chasing weird cases where we have dyndng enabled anyways.
> Also IIRC the problem with 2 devices on the same link was fixed by Richard, wasn't it?
> That would make the dev_warn() even less useful.

I would vote for either this or just leave it as is, doesn't seem
worth the additional complexity to avoid it dynamically.

Thanks,
Charles