ASoC: SDCA: Update text of FIXME

A couple of attempts to correct this FIXME have been sent upstream but
the situation is not quite a simple as the FIXME implies. Update the
FIXME to include a better description of the situation.

Link: https://lore.kernel.org/linux-sound/20260408085607.3813488-1-shumingf@realtek.com/
Link: https://lore.kernel.org/linux-sound/20260324-sdca-function-status-init-irq-v1-1-bba49417a4e0@gmail.com/
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260410104500.163337-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

diff --git a/sound/soc/sdca/sdca_interrupts.c b/sound/soc/sdca/sdca_interrupts.c
index 3d7eb19967243a52b7bfd7df8954fa492689dda1..6e10b4e660d96bc3a98bbbbc9d804eac21fadb2b 100644 (file)
--- a/sound/soc/sdca/sdca_interrupts.c
+++ b/sound/soc/sdca/sdca_interrupts.c
@@ -119,7 +119,17 @@ static irqreturn_t function_status_handler(int irq, void *data)
        for_each_set_bit(mask, &status, BITS_PER_BYTE) {
                switch (BIT(mask)) {
                case SDCA_CTL_ENTITY_0_FUNCTION_NEEDS_INITIALIZATION:
-                       //FIXME: Add init writes
+/*
+ * FIXME: Should this do init writes?
+ *
+ * Currently init writes/cache sync are done from the suspend/resume
+ * infrastructure. It is unclear in what situations one would receive this
+ * IRQ outside of that flow. Presumably it would be something like the chip
+ * crashing. In that case however doing the init writes and a cache sync might
+ * not be sufficient, for example if the failure was during audio playback
+ * there could be ordering constraints on the register writes to restore the
+ * state that are not handled by a simple cache sync.
+ */
                        break;
                case SDCA_CTL_ENTITY_0_FUNCTION_FAULT:
                        dev_err(dev, "function fault\n");