Arduino Imola/Monza - catchall PR - #1858
Open
Martino Facchin (facchinm) wants to merge 14 commits into
Open
Martino Facchin (facchinm) wants to merge 14 commits into
Martino Facchin (facchinm) wants to merge 14 commits into
Conversation
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
The chip requires 32 bit frame, with 16-24 bits of valid data left aligned TODO: check that the output format is correct Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Limitiations of Qualcomm DSP make it very hard to left justify (chip's default) Change-Id: I9ec695bf8dee36d7061499d6d8f060d7361eabf8
Completes ASoC: codecs: pm4125: fix array-out-of-bounds by adding extra checks. This avoids a race condition crash on dapm_power_widgets(), where for_each_card_dapms(card, d) returns a corrupted pointer Change-Id: Ie95312c9cb3fb7ee83dc3f1bffbdb1f2881f1026 Signed-off-by: Martino Facchin <m.facchin@arduino.cc>
On Elite DSP architecuture q6routing setup depends on some of the pcm dais to be probed to setup the routing. For some reason if the devicetree entires are incorrectly ordered, specially in overlays, this could result in failures like below q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: ASoC: Failed to add route MM_DL1(*) -> [MultiMedia1] -> HDMI Mixer q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: ASoC: Failed to add route MM_DL2(*) -> [MultiMedia2] -> HDMI Mixer q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: ASoC: Failed to add route MM_DL3(*) -> [MultiMedia3] -> HDMI Mixer q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: ASoC: Failed to add route MM_DL4(*) -> [MultiMedia4] -> HDMI Mixer q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: ASoC: Failed to add route MM_DL5(*) -> [MultiMedia5] -> HDMI Mixer q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: ASoC: Failed to add route MM_DL6(*) -> [MultiMedia6] -> HDMI Mixer q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: ASoC: Failed to add route MM_DL7(*) -> [MultiMedia7] -> HDMI Mixer q6routing ab00000.remoteproc:glink-edge:apr:service@8:routing: ASoC: Failed to add route MM_DL8(*) -> [MultiMedia8] -> HDMI Mixer Fix this by setting up the pcm dais first and then the backend dais after. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
If there is no DP or eDP link, we shoudl still able to handle USB-C operation, such as host/device detection. Change-Id: Iad533b2a012072d19bd07d03eb4b572b4893e9f5 Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Change-Id: I3f9a130d6709a71fa93a6ff2ff3a77847b16912b
hci_uart_close() closes the serdev port if HCI_QUIRK_NON_PERSISTENT_SETUP is set (for example, for the WCN399x family). A failed hci_dev_open_sync() following a successful qca_setup() calls hdev->close() but not hdev->shutdown(), so the port is closed while power->vregs_on is left true. qca_serdev_remove() then passes its power->vregs_on test and calls qca_power_off(), which writes to the closed port unconditionally. Seen on a WCN3988 by unbinding the driver after a controller failure. The trace below is from a 7.0.0 based kernel, where qca_power_off() was still named qca_power_shutdown(): Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Call trace: tty_set_termios+0x50/0x238 (P) ttyport_set_baudrate+0x84/0xc0 serdev_device_set_baudrate+0x24/0x40 qca_power_shutdown+0x158/0x1fc [hci_uart] qca_serdev_remove+0x54/0x68 [hci_uart] serdev_drv_remove+0x1c/0x2c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xc0 Check HCI_UART_PROTO_READY, which hci_uart_close() clears in the same place it closes the port, before writing to it. The regulator disable is left unconditional so the controller is still powered down. The dangling serport->tty that turns this into a use-after-free is addressed in a separate patch. Fixes: fa9ad87 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Signed-off-by: Ibrahim Abdelkader <iabdelka@qti.qualcomm.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Both error paths in ttyport_open(), and ttyport_close(), release the tty with tty_release_struct() and leave serport->tty pointing at freed memory. The serdev core itself never dereferences it afterwards. However, a buggy driver could easily trigger a use-after-free by calling a ttyport operation on a port that is not open, or by calling close() twice. While those drivers should be fixed, clearing the pointer, makes them fail deterministically instead of touching freed memory. Note that a driver which currently double closes gets away with it only by chance, depending on whether the freed tty has been reused. After this change such a driver oopses immediately instead, which is the intended outcome, but it may surface latent bugs elsewhere. Signed-off-by: Ibrahim Abdelkader <iabdelka@qti.qualcomm.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Reviewed-by: Markus Probst <markus.probst@posteo.de>
hci_send_cmd_sync() returns -EINVAL when skb_clone() fails for sent_cmd, which describes an invalid argument rather than an allocation failure. Return -ENOMEM instead. The only caller, hci_cmd_work(), tests the result for zero, so there is no functional change. Signed-off-by: Ibrahim Abdelkader <iabdelka@qti.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
…uest A synchronous HCI command that never receives a response leaves HCI_CMD_PENDING set: hci_req_cmd_complete() is the only place that clears it, and it only runs when a response matching the last command sent arrives. hci_send_cmd_sync() populates hdev->req_skb only when the flag transitions from clear to set, while hci_dev_open_sync() and hci_dev_close_sync() drop req_skb without clearing the flag. After a timeout followed by either, the two disagree: the flag claims a request is outstanding while req_skb is NULL. Subsequent synchronous commands are then sent with no req_skb, so hci_event_packet() has nothing to match an arriving event against, and the caller times out even though the controller answered. Commands answered by Command Complete recover on their own, since hci_req_cmd_complete() clears the flag as a side effect. Drivers using __hci_cmd_sync_ev() with a custom event do not, because a vendor event never reaches that path. On a WCN3988 (hci_qca over UART) this makes a controller firmware hang unrecoverable: the driver injects a hardware error and re-runs qca_setup(), qca_read_soc_version() waits for HCI_EV_VENDOR, the reply arrives within 4 ms and is discarded, and every retry fails the same way. The adapter is left down until the driver is unbound and rebound, or power is removed. Clear the flag wherever the last request is dropped, restoring the invariant that req_skb is non-NULL exactly when HCI_CMD_PENDING is set. Verified on hardware by forcing a command timeout: without this change setup fails on every attempt, with it setup succeeds on the first. Fixes: 2615fd9 ("Bluetooth: hci_sync: Fix overwriting request callback") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Abdelkader <iabdelka@qti.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR includes all the fixes needed to get HDMI audio working on UNO Q (Imola). On top, the bluetooth patches from Ibrahim Abdelkader (@iabdalkader) already submitted to the mailing list .
Feel free to rework / retitle / tag according to the repo conventions