--- /dev/null
+From 6a32425f953b955b4ff82f339d01df0b713caa5d Mon Sep 17 00:00:00 2001
+From: Artemii Karasev <karasev@ispras.ru>
+Date: Tue, 7 Feb 2023 18:20:26 +0500
+Subject: ALSA: emux: Avoid potential array out-of-bound in snd_emux_xg_control()
+
+From: Artemii Karasev <karasev@ispras.ru>
+
+commit 6a32425f953b955b4ff82f339d01df0b713caa5d upstream.
+
+snd_emux_xg_control() can be called with an argument 'param' greater
+than size of 'control' array. It may lead to accessing 'control'
+array at a wrong index.
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Signed-off-by: Artemii Karasev <karasev@ispras.ru>
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230207132026.2870-1-karasev@ispras.ru
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/synth/emux/emux_nrpn.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/sound/synth/emux/emux_nrpn.c
++++ b/sound/synth/emux/emux_nrpn.c
+@@ -349,6 +349,9 @@ int
+ snd_emux_xg_control(struct snd_emux_port *port, struct snd_midi_channel *chan,
+ int param)
+ {
++ if (param >= ARRAY_SIZE(chan->control))
++ return -EINVAL;
++
+ return send_converted_effect(xg_effects, ARRAY_SIZE(xg_effects),
+ port, chan, param,
+ chan->control[param],
--- /dev/null
+From 88d18b8896bd98e636b632f805b7e84e61458255 Mon Sep 17 00:00:00 2001
+From: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
+Date: Tue, 7 Feb 2023 15:37:20 -0300
+Subject: ALSA: hda/realtek: Add Positivo N14KP6-TG
+
+From: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
+
+commit 88d18b8896bd98e636b632f805b7e84e61458255 upstream.
+
+Positivo N14KP6-TG (1c6c:1251)
+require quirk for enabling headset-mic
+
+Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230207183720.2519-1-edson.drosdeck@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -9261,6 +9261,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
+ SND_PCI_QUIRK(0x1c06, 0x2013, "Lemote A1802", ALC269_FIXUP_LEMOTE_A1802),
+ SND_PCI_QUIRK(0x1c06, 0x2015, "Lemote A190X", ALC269_FIXUP_LEMOTE_A190X),
++ SND_PCI_QUIRK(0x1c6c, 0x1251, "Positivo N14KP6-TG", ALC288_FIXUP_DELL1_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1d05, 0x1132, "TongFang PHxTxX1", ALC256_FIXUP_SET_COEF_DEFAULTS),
+ SND_PCI_QUIRK(0x1d05, 0x1096, "TongFang GMxMRxx", ALC269_FIXUP_NO_SHUTUP),
+ SND_PCI_QUIRK(0x1d05, 0x1100, "TongFang GKxNRxx", ALC269_FIXUP_NO_SHUTUP),
--- /dev/null
+From bd401fd730cbcb0717bbc5438f15084db10f9259 Mon Sep 17 00:00:00 2001
+From: Guillaume Pinot <texitoi@texitoi.eu>
+Date: Sun, 29 Jan 2023 18:13:38 +0100
+Subject: ALSA: hda/realtek: Fix the speaker output on Samsung Galaxy Book2 Pro 360
+
+From: Guillaume Pinot <texitoi@texitoi.eu>
+
+commit bd401fd730cbcb0717bbc5438f15084db10f9259 upstream.
+
+Samsung Galaxy Book2 Pro 360 (13" 2022 NP930QED-KA1FR) with codec SSID
+144d:ca03 requires the same workaround for enabling the speaker amp
+like other Samsung models with ALC298 codec.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Guillaume Pinot <texitoi@texitoi.eu>
+Link: https://lore.kernel.org/r/20230129171338.17249-1-texitoi@texitoi.eu
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -9090,6 +9090,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x144d, 0xc812, "Samsung Notebook Pen S (NT950SBE-X58)", ALC298_FIXUP_SAMSUNG_AMP),
+ SND_PCI_QUIRK(0x144d, 0xc830, "Samsung Galaxy Book Ion (NT950XCJ-X716A)", ALC298_FIXUP_SAMSUNG_AMP),
+ SND_PCI_QUIRK(0x144d, 0xc832, "Samsung Galaxy Book Flex Alpha (NP730QCJ)", ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
++ SND_PCI_QUIRK(0x144d, 0xca03, "Samsung Galaxy Book2 Pro 360 (NP930QED)", ALC298_FIXUP_SAMSUNG_AMP),
+ SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807", ALC283_FIXUP_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1462, 0xb120, "MSI Cubi MS-B120", ALC283_FIXUP_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1462, 0xb171, "Cubi N 8GL (MS-B171)", ALC283_FIXUP_HEADSET_MIC),
--- /dev/null
+From 4ae5e1e97c44f4654516c1d41591a462ed62fa7b Mon Sep 17 00:00:00 2001
+From: Devid Antonio Filoni <devid.filoni@egluetechnologies.com>
+Date: Fri, 25 Nov 2022 18:04:18 +0100
+Subject: can: j1939: do not wait 250 ms if the same addr was already claimed
+
+From: Devid Antonio Filoni <devid.filoni@egluetechnologies.com>
+
+commit 4ae5e1e97c44f4654516c1d41591a462ed62fa7b upstream.
+
+The ISO 11783-5 standard, in "4.5.2 - Address claim requirements", states:
+ d) No CF shall begin, or resume, transmission on the network until 250
+ ms after it has successfully claimed an address except when
+ responding to a request for address-claimed.
+
+But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim
+prioritization" show that the CF begins the transmission after 250 ms
+from the first AC (address-claimed) message even if it sends another AC
+message during that time window to resolve the address contention with
+another CF.
+
+As stated in "4.4.2.3 - Address-claimed message":
+ In order to successfully claim an address, the CF sending an address
+ claimed message shall not receive a contending claim from another CF
+ for at least 250 ms.
+
+As stated in "4.4.3.2 - NAME management (NM) message":
+ 1) A commanding CF can
+ d) request that a CF with a specified NAME transmit the address-
+ claimed message with its current NAME.
+ 2) A target CF shall
+ d) send an address-claimed message in response to a request for a
+ matching NAME
+
+Taking the above arguments into account, the 250 ms wait is requested
+only during network initialization.
+
+Do not restart the timer on AC message if both the NAME and the address
+match and so if the address has already been claimed (timer has expired)
+or the AC message has been sent to resolve the contention with another
+CF (timer is still running).
+
+Signed-off-by: Devid Antonio Filoni <devid.filoni@egluetechnologies.com>
+Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Link: https://lore.kernel.org/all/20221125170418.34575-1-devid.filoni@egluetechnologies.com
+Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/can/j1939/address-claim.c | 40 ++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 40 insertions(+)
+
+--- a/net/can/j1939/address-claim.c
++++ b/net/can/j1939/address-claim.c
+@@ -165,6 +165,46 @@ static void j1939_ac_process(struct j193
+ * leaving this function.
+ */
+ ecu = j1939_ecu_get_by_name_locked(priv, name);
++
++ if (ecu && ecu->addr == skcb->addr.sa) {
++ /* The ISO 11783-5 standard, in "4.5.2 - Address claim
++ * requirements", states:
++ * d) No CF shall begin, or resume, transmission on the
++ * network until 250 ms after it has successfully claimed
++ * an address except when responding to a request for
++ * address-claimed.
++ *
++ * But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim
++ * prioritization" show that the CF begins the transmission
++ * after 250 ms from the first AC (address-claimed) message
++ * even if it sends another AC message during that time window
++ * to resolve the address contention with another CF.
++ *
++ * As stated in "4.4.2.3 - Address-claimed message":
++ * In order to successfully claim an address, the CF sending
++ * an address claimed message shall not receive a contending
++ * claim from another CF for at least 250 ms.
++ *
++ * As stated in "4.4.3.2 - NAME management (NM) message":
++ * 1) A commanding CF can
++ * d) request that a CF with a specified NAME transmit
++ * the address-claimed message with its current NAME.
++ * 2) A target CF shall
++ * d) send an address-claimed message in response to a
++ * request for a matching NAME
++ *
++ * Taking the above arguments into account, the 250 ms wait is
++ * requested only during network initialization.
++ *
++ * Do not restart the timer on AC message if both the NAME and
++ * the address match and so if the address has already been
++ * claimed (timer has expired) or the AC message has been sent
++ * to resolve the contention with another CF (timer is still
++ * running).
++ */
++ goto out_ecu_put;
++ }
++
+ if (!ecu && j1939_address_is_unicast(skcb->addr.sa))
+ ecu = j1939_ecu_create_locked(priv, name);
+
--- /dev/null
+From f6933c01e42d2fc83b9133ed755609e4aac6eadd Mon Sep 17 00:00:00 2001
+From: Mark Brown <broonie@kernel.org>
+Date: Sat, 28 Jan 2023 17:47:50 +0000
+Subject: of/address: Return an error when no valid dma-ranges are found
+
+From: Mark Brown <broonie@kernel.org>
+
+commit f6933c01e42d2fc83b9133ed755609e4aac6eadd upstream.
+
+Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
+converted the parsing of dma-range properties to use code shared with the
+PCI range parser. The intent was to introduce no functional changes however
+in the case where we fail to translate the first resource instead of
+returning -EINVAL the new code we return 0. Restore the previous behaviour
+by returning an error if we find no valid ranges, the original code only
+handled the first range but subsequently support for parsing all supplied
+ranges was added.
+
+This avoids confusing code using the parsed ranges which doesn't expect to
+successfully parse ranges but have only a list terminator returned, this
+fixes breakage with so far as I can tell all DMA for on SoC devices on the
+Socionext Synquacer platform which has a firmware supplied DT. A bisect
+identified the original conversion as triggering the issues there.
+
+Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: Luca Di Stefano <luca.distefano@linaro.org>
+Cc: 993612@bugs.debian.org
+Cc: stable@kernel.org
+Link: https://lore.kernel.org/r/20230126-synquacer-boot-v2-1-cb80fd23c4e2@kernel.org
+Signed-off-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/of/address.c | 21 +++++++++++++++------
+ 1 file changed, 15 insertions(+), 6 deletions(-)
+
+--- a/drivers/of/address.c
++++ b/drivers/of/address.c
+@@ -990,8 +990,19 @@ int of_dma_get_range(struct device_node
+ }
+
+ of_dma_range_parser_init(&parser, node);
+- for_each_of_range(&parser, &range)
++ for_each_of_range(&parser, &range) {
++ if (range.cpu_addr == OF_BAD_ADDR) {
++ pr_err("translation of DMA address(%llx) to CPU address failed node(%pOF)\n",
++ range.bus_addr, node);
++ continue;
++ }
+ num_ranges++;
++ }
++
++ if (!num_ranges) {
++ ret = -EINVAL;
++ goto out;
++ }
+
+ r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
+ if (!r) {
+@@ -1000,18 +1011,16 @@ int of_dma_get_range(struct device_node
+ }
+
+ /*
+- * Record all info in the generic DMA ranges array for struct device.
++ * Record all info in the generic DMA ranges array for struct device,
++ * returning an error if we don't find any parsable ranges.
+ */
+ *map = r;
+ of_dma_range_parser_init(&parser, node);
+ for_each_of_range(&parser, &range) {
+ pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+ range.bus_addr, range.cpu_addr, range.size);
+- if (range.cpu_addr == OF_BAD_ADDR) {
+- pr_err("translation of DMA address(%llx) to CPU address failed node(%pOF)\n",
+- range.bus_addr, node);
++ if (range.cpu_addr == OF_BAD_ADDR)
+ continue;
+- }
+ r->cpu_start = range.cpu_addr;
+ r->dma_start = range.bus_addr;
+ r->size = range.size;
migrate-hugetlb-check-for-hugetlb-shared-pmd-in-node.patch
btrfs-limit-device-extents-to-the-device-size.patch
btrfs-zlib-zero-initialize-zlib-workspace.patch
+alsa-hda-realtek-add-positivo-n14kp6-tg.patch
+alsa-emux-avoid-potential-array-out-of-bound-in-snd_emux_xg_control.patch
+alsa-hda-realtek-fix-the-speaker-output-on-samsung-galaxy-book2-pro-360.patch
+tracing-fix-poll-and-select-do-not-work-on-per_cpu-trace_pipe-and-trace_pipe_raw.patch
+of-address-return-an-error-when-no-valid-dma-ranges-are-found.patch
+can-j1939-do-not-wait-250-ms-if-the-same-addr-was-already-claimed.patch
--- /dev/null
+From 3e46d910d8acf94e5360126593b68bf4fee4c4a1 Mon Sep 17 00:00:00 2001
+From: Shiju Jose <shiju.jose@huawei.com>
+Date: Thu, 2 Feb 2023 18:23:09 +0000
+Subject: tracing: Fix poll() and select() do not work on per_cpu trace_pipe and trace_pipe_raw
+
+From: Shiju Jose <shiju.jose@huawei.com>
+
+commit 3e46d910d8acf94e5360126593b68bf4fee4c4a1 upstream.
+
+poll() and select() on per_cpu trace_pipe and trace_pipe_raw do not work
+since kernel 6.1-rc6. This issue is seen after the commit
+42fb0a1e84ff525ebe560e2baf9451ab69127e2b ("tracing/ring-buffer: Have
+polling block on watermark").
+
+This issue is firstly detected and reported, when testing the CXL error
+events in the rasdaemon and also erified using the test application for poll()
+and select().
+
+This issue occurs for the per_cpu case, when calling the ring_buffer_poll_wait(),
+in kernel/trace/ring_buffer.c, with the buffer_percent > 0 and then wait until the
+percentage of pages are available. The default value set for the buffer_percent is 50
+in the kernel/trace/trace.c.
+
+As a fix, allow userspace application could set buffer_percent as 0 through
+the buffer_percent_fops, so that the task will wake up as soon as data is added
+to any of the specific cpu buffer.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20230202182309.742-2-shiju.jose@huawei.com
+
+Cc: <mhiramat@kernel.org>
+Cc: <mchehab@kernel.org>
+Cc: <linux-edac@vger.kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 42fb0a1e84ff5 ("tracing/ring-buffer: Have polling block on watermark")
+Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -8569,9 +8569,6 @@ buffer_percent_write(struct file *filp,
+ if (val > 100)
+ return -EINVAL;
+
+- if (!val)
+- val = 1;
+-
+ tr->buffer_percent = val;
+
+ (*ppos)++;
projects / thirdparty / kernel / stable-queue.git / commitdiff
