kernel/linux.git/drivers/soundwire/bus.c, branch linux-6.1.y

soundwire: fix enumeration completion

2023-08-03T08:24:15+00:00

commit c40d6b3249b11d60e09d81530588f56233d9aa44 upstream. The soundwire subsystem uses two completion structures that allow drivers to wait for soundwire device to become enumerated on the bus and initialised by their drivers, respectively. The code implementing the signalling is currently broken as it does not signal all current and future waiters and also uses the wrong reinitialisation function, which can potentially lead to memory corruption if there are still waiters on the queue. Not signalling future waiters specifically breaks sound card probe deferrals as codec drivers can not tell that the soundwire device is already attached when being reprobed. Some codec runtime PM implementations suffer from similar problems as waiting for enumeration during resume can also timeout despite the device already having been enumerated. Fixes: fb9469e54fa7 ("soundwire: bus: fix race condition with enumeration_complete signaling") Fixes: a90def068127 ("soundwire: bus: fix race condition with initialization_complete signaling") Cc: stable@vger.kernel.org # 5.7 Cc: Pierre-Louis Bossart Cc: Rander Wang Signed-off-by: Johan Hovold Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230705123018.30903-2-johan+linaro@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

soundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflow

2023-05-24T16:32:42+00:00

[ Upstream commit e9537962519e88969f5f69cd0571eb4f6984403c ] This reverts commit 443a98e649b4 ("soundwire: bus: use pm_runtime_resume_and_get()") Change calls to pm_runtime_resume_and_get() back to pm_runtime_get_sync(). This fixes a usage count underrun caused by doing a pm_runtime_put() even though pm_runtime_resume_and_get() returned an error. The three affected functions ignore -EACCES error from trying to get pm_runtime, and carry on, including a put at the end of the function. But pm_runtime_resume_and_get() does not increment the usage count if it returns an error. So in the -EACCES case you must not call pm_runtime_put(). The documentation for pm_runtime_get_sync() says: "Consider using pm_runtime_resume_and_get() ... as this is likely to result in cleaner code." In this case I don't think it results in cleaner code because the pm_runtime_put() at the end of the function would have to be conditional on the return value from pm_runtime_resume_and_get() at the top of the function. pm_runtime_get_sync() doesn't have this problem because it always increments the count, so always needs a put. The code can just flow through and do the pm_runtime_put() unconditionally. Signed-off-by: Richard Fitzgerald Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230406134640.8582-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

Merge tag 'soundwire-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire

2022-10-07T23:13:55+00:00

Pull soundwire updates from Vinod Koul: "Updates for Intel, Cadence and Qualcomm drivers: - another round of Intel driver cleanup to prepare for future code reorg which is expected in next cycle (Pierre-Louis Bossart) - bus unattach notifications processing during re-enumeration along with Cadence driver updates for this (Richard Fitzgerald) - Qualcomm driver updates to handle device0 status (Srinivas Kandagatla)" * tag 'soundwire-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: (42 commits) soundwire: intel: add helper to stop bus soundwire: intel: introduce helpers to start bus soundwire: intel: introduce intel_shim_check_wake() helper soundwire: intel: simplify read ops assignment soundwire: intel: remove intel_init() wrapper soundwire: intel: move shim initialization before power up/down soundwire: intel: remove clock_stop parameter in intel_shim_init() soundwire: intel: move all PDI initialization under intel_register_dai() soundwire: intel: move DAI registration and debugfs init earlier soundwire: intel: simplify flow and use devm_ for DAI registration soundwire: intel: fix error handling on dai registration issues soundwire: cadence: Simplify error paths in cdns_xfer_msg() soundwire: cadence: Fix error check in cdns_xfer_msg() soundwire: cadence: Write to correct address for each FIFO chunk soundwire: bus: Fix wrong port number in sdw_handle_slave_alerts() soundwire: qcom: do not send status of device 0 during alert soundwire: qcom: update status from device id 1 soundwire: cadence: Don't overwrite msg->buf during write commands soundwire: bus: Don't exit early if no device IDs were programmed soundwire: cadence: Fix lost ATTACHED interrupts when enumerating ...

soundwire: bus: Fix wrong port number in sdw_handle_slave_alerts()

2022-09-20T05:05:39+00:00

for_each_set_bit() gives the bit-number counting from 0 (LSbit==0). When processing INTSTAT2, bit 0 is DP4 so the port number is (bit + 4). Likewise for INTSTAT3 bit 0 is DP11 so port number is (bit + 11). Signed-off-by: Richard Fitzgerald Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220917140256.689678-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul

soundwire: bus: Don't exit early if no device IDs were programmed

2022-09-20T04:59:31+00:00

Only exit sdw_handle_slave_status() right after calling sdw_program_device_num() if it actually programmed an ID into at least one device. sdw_handle_slave_status() should protect itself against phantom device #0 ATTACHED indications. In that case there is no actual device still on #0. The early exit relies on there being a status change to ATTACHED on the reprogrammed device to trigger another call to sdw_handle_slave_status() which will then handle the status of all peripherals. If no device was actually programmed with an ID there won't be a new ATTACHED indication. This can lead to the status of other peripherals not being handled. The status passed to sdw_handle_slave_status() is obviously always from a point of time in the past, and may indicate accumulated unhandled events (depending how the bus manager operates). It's possible that a device ID is reprogrammed but the last PING status captured state just before that, when it was still reporting on ID #0. Then sdw_handle_slave_status() is called with this PING info, just before a new PING status is available showing it now on its new ID. So sdw_handle_slave_status() will receive a phantom report of a device on #0, but it will not find one. Signed-off-by: Richard Fitzgerald Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220914160248.1047627-6-rf@opensource.cirrus.com Signed-off-by: Vinod Koul

soundwire: bus: Don't re-enumerate before status is UNATTACHED

2022-09-20T04:59:31+00:00

Don't re-enumerate a peripheral on #0 until we have seen and handled an UNATTACHED notification for that peripheral. Without this, it is possible for the UNATTACHED status to be missed and so the slave->status remains at ATTACHED. If slave->status never changes to UNATTACHED the child driver will never be notified of the UNATTACH, and the code in sdw_handle_slave_status() will skip the second part of enumeration because the slave->status has not changed. This scenario can happen because PINGs are handled in a workqueue function which is working from a snapshot of an old PING, and there is no guarantee when this function will run. A peripheral could report attached in the PING being handled by sdw_handle_slave_status(), but has since reverted to device #0 and is then found in the loop in sdw_program_device_num(). Previously the code would not have updated slave->status to UNATTACHED because it had not yet handled a PING where that peripheral had UNATTACHED. This situation happens fairly frequently with multiple peripherals on a bus that are intentionally reset (for example after downloading firmware). Signed-off-by: Richard Fitzgerald Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220914160248.1047627-4-rf@opensource.cirrus.com Signed-off-by: Vinod Koul

soundwire: bus: Don't lose unattach notifications

2022-09-20T04:59:31+00:00

Ensure that if sdw_handle_slave_status() sees a peripheral has dropped off the bus it reports it to the client driver. If there are any devices reporting on address 0 it bails out after programming the device IDs. So it never reaches the second loop that calls sdw_update_slave_status(). If the missing device is one that is now showing as unenumerated it has been given a device ID so will report as attached next time sdw_handle_slave_status() runs. With the previous code the client driver would only see another ATTACHED notification because the UNATTACHED state was lost when sdw_handle_slave_status() bailed out after programming the device ID. This shows up most when the peripheral has to be reset after downloading updated firmware and there are multiple of these peripherals on the bus. They will all return to unenumerated state after the reset, and then there is a mix of unattached, attached and unenumerated PING states from the peripherals, as each is reset and they reboot. Signed-off-by: Richard Fitzgerald Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220914160248.1047627-3-rf@opensource.cirrus.com Signed-off-by: Vinod Koul

soundwire: bus: allow device number to be unique at system level

2022-08-30T04:46:41+00:00

The SoundWire specification allows the device number to be allocated at will. When a system includes multiple SoundWire links, the device number scope is limited to the link to which the device is attached. However, for integration/debug it can be convenient to have a unique device number across the system. This patch adds a 'dev_num_ida_min' field at the bus level, which when set will be used to allocate an IDA. The allocation happens when a hardware device reports as ATTACHED. If any error happens during the enumeration, the allocated IDA is not freed - the device number will be reused if/when the device re-joins the bus. The IDA is only freed when the Linux device is unregistered. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20220823045004.2670658-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul

soundwire: bus: rename sdw_ida as sdw_bus_ida

2022-08-30T04:46:41+00:00

To avoid confusions with follow-up patches using a IDA mechanism for peripheral 'device number' allocation, rename sdw_ida as sdw_bus_ida. Pure rename, no functionality change. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20220823045004.2670658-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul

soundwire: bus: remove use of func in dev_dbg

2022-08-23T17:01:16+00:00

The module and function information can be added with 'modprobe foo dyndbg=+pmf' Suggested-by: Greg KH Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20220823050158.2671245-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul

kernel/linux.git/drivers/soundwire/bus.c, branch linux-6.1.y

soundwire: fix enumeration completion

soundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflow

Merge tag 'soundwire-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire

soundwire: bus: Fix wrong port number in sdw_handle_slave_alerts()

soundwire: bus: Don't exit early if no device IDs were programmed

soundwire: bus: Don't re-enumerate before status is UNATTACHED

soundwire: bus: Don't lose unattach notifications

soundwire: bus: allow device number to be unique at system level

soundwire: bus: rename sdw_ida as sdw_bus_ida

soundwire: bus: remove use of __func__ in dev_dbg

soundwire: bus: remove use of func in dev_dbg