Re: [PATCH] ASoC: tas2783-sdw: do not treat read-only Controls as writable

On Thu, Aug 13, 2026 at 08:53:10PM +0100, Mark Brown wrote:
> > +	case SDW_SDCA_CTL(FUNC_NUM_SMART_AMP, TAS2783_SDCA_ENT_XU22, 0x14, 0):

> 0x14 is SDCA_CTL_XU_FDL_STATUS and AFAICT sdca_fdl_process() might write
> to it.  Not sure if that's reachable with this device or not...

You are right, and the entry is gone.  I took the Control for a status
the device owns; it is a handshake, and sdca_fdl_process() writes the
host response back into it with response | (status &
~SDCA_CTL_XU_FDLH_MASK).  _regmap_write() answers -EIO for a register
writeable_reg refuses, so the driver would have failed at the first
response.

Not reachable today, as far as I can see: the driver registers no SDCA
interrupts and never calls into sdca_fdl.c.  It downloads its firmware
itself, request_firmware_nowait() plus its own container format in
tas2783_fw_ready(), and the BIOS on the machines I have describes no
Smart Amp SDCA function at all, so nothing populates the interrupt that
would drive the state machine.  But the Function does implement the FDL
Controls - the driver's defaults list 0x10 and 0x12 through 0x16 - so a
driver that later gains the state machine would walk into it, and the
list is not worth that.

The Control is still not cached in 2/2, on its own grounds: the device
sets its bits on its own schedule and sdca_fdl_process() reads the
Control to see them, so an answer from the cache would hide the device
half of the handshake.  Writable and volatile.

v2 of the two patches is posted as a series, since the second depends on
the first:

  https://lore.kernel.org/linux-sound/[email protected]/

Thanks for catching it.

Andrey