The NVM configuration files used by WCN3988 and WCN3990/1/8 have two
sets of configuration tags that are enclosed by a type-length header of
type four which the current parser fails to account for.
Instead the driver happily parses random data as if it were valid tags,
something which can lead to the configuration data being corrupted if it
ever encounters the words 0x0011 or 0x001b.
As is clear from commit b63882549b2b ("Bluetooth: btqca: Fix the NVM
baudrate tag offcet for wcn3991") the intention has always been to
process the configuration data also for WCN3991 and WCN3998 which
encodes the baud rate at a different offset.
Fix the parser so that it can handle the WCN3xxx configuration files,
which has an enclosing type-length header of type four and two sets of
TLV tags enclosed by a type-length header of type two and three,
respectively.
Note that only the first set, which contains the tags the driver is
currently looking for, will be parsed for now.
With the parser fixed, the software in-band sleep bit will now be set
for WCN3991 and WCN3998 (as it is for later controllers) and the default
baud rate 3200000 may be updated by the driver also for WCN3xxx
controllers.
Notably the deep-sleep feature bit is already set by default in all
configuration files in linux-firmware.
Fixes: 4219d4686875 ("Bluetooth: btqca: Add wcn3990 firmware download support.")
Cc: stable(a)vger.kernel.org # 4.19
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org>
---
drivers/bluetooth/btqca.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index 6743b0a79d7a..f6c9f89a6311 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -281,6 +281,7 @@ static int qca_tlv_check_data(struct hci_dev *hdev,
struct tlv_type_patch *tlv_patch;
struct tlv_type_nvm *tlv_nvm;
uint8_t nvm_baud_rate = config->user_baud_rate;
+ u8 type;
config->dnld_mode = QCA_SKIP_EVT_NONE;
config->dnld_type = QCA_SKIP_EVT_NONE;
@@ -346,11 +347,30 @@ static int qca_tlv_check_data(struct hci_dev *hdev,
tlv = (struct tlv_type_hdr *)fw_data;
type_len = le32_to_cpu(tlv->type_len);
- length = (type_len >> 8) & 0x00ffffff;
+ length = type_len >> 8;
+ type = type_len & 0xff;
- BT_DBG("TLV Type\t\t : 0x%x", type_len & 0x000000ff);
+ /* Some NVM files have more than one set of tags, only parse
+ * the first set when it has type 2 for now. When there is
+ * more than one set there is an enclosing header of type 4.
+ */
+ if (type == 4) {
+ if (fw_size < 2 * sizeof(struct tlv_type_hdr))
+ return -EINVAL;
+
+ tlv++;
+
+ type_len = le32_to_cpu(tlv->type_len);
+ length = type_len >> 8;
+ type = type_len & 0xff;
+ }
+
+ BT_DBG("TLV Type\t\t : 0x%x", type);
BT_DBG("Length\t\t : %d bytes", length);
+ if (type != 2)
+ break;
+
if (fw_size < length + (tlv->data - fw_data))
return -EINVAL;
--
2.43.2
On 4/28/24 13:24, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block
>
> to the 4.19-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> arm64-dts-mediatek-mt7622-drop-reset-names-from-ther.patch
> and it can be found in the queue-4.19 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
>
>
>
> commit 9628765c4a0eefa9474ef4a0698691a10395a469
> Author: Rafał Miłecki <rafal(a)milecki.pl>
> Date: Sun Mar 17 23:10:50 2024 +0100
>
> arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block
>
> [ Upstream commit ecb5b0034f5bcc35003b4b965cf50c6e98316e79 ]
>
> Binding doesn't specify "reset-names" property and Linux driver also
> doesn't use it.
>
I think that's an open discussion item if fixes to DTS checks are valid
stable backports. From my point of view there is no bug so it shouldn't
be in stable.
Regards,
Matthias
> Fix following validation error:
> arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: thermal@1100b000: Unevaluated properties are not allowed ('reset-names' was unexpected)
> from schema $id: http://devicetree.org/schemas/thermal/mediatek,thermal.yaml#
>
> Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device nodes")
> Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>
> Link: https://lore.kernel.org/r/20240317221050.18595-5-zajec5@gmail.com
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> index 76297dac2d459..f8df34ac1e64d 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> @@ -459,7 +459,6 @@ thermal: thermal@1100b000 {
> <&pericfg CLK_PERI_AUXADC_PD>;
> clock-names = "therm", "auxadc";
> resets = <&pericfg MT7622_PERI_THERM_SW_RST>;
> - reset-names = "therm";
> mediatek,auxadc = <&auxadc>;
> mediatek,apmixedsys = <&apmixedsys>;
> nvmem-cells = <&thermal_calibration>;
On 4/28/24 13:24, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> arm64: dts: mediatek: mt7622: fix ethernet controller "compatible"
>
> to the 4.19-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> arm64-dts-mediatek-mt7622-fix-ethernet-controller-co.patch
> and it can be found in the queue-4.19 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
>
>
>
> commit b6f34784d92ba280c8a4f42e22fee3c41cd09c3f
> Author: Rafał Miłecki <rafal(a)milecki.pl>
> Date: Sun Mar 17 23:10:49 2024 +0100
>
> arm64: dts: mediatek: mt7622: fix ethernet controller "compatible"
>
> [ Upstream commit 208add29ce5b7291f6c466e4dfd9cbf61c72888e ]
>
> Fix following validation error:
> arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: ethernet@1b100000: compatible: ['mediatek,mt7622-eth', 'mediatek,mt2701-eth', 'syscon'] is too long
> from schema $id: http://devicetree.org/schemas/net/mediatek,net.yaml#
> (and other complains about wrong clocks).
>
DTS validation fix, not a real bug. From my point of view it shouldn't
be in stable. I won't go on in the list, I would like to hear from
others how serious they see it. With my distro hat on, this kind of
stable fixes are not helpfull to make a code base stable (as there is no
stability issue).
Matthias
> Fixes: 5f599b3a0bb8 ("arm64: dts: mt7622: add ethernet device nodes")
> Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>
> Link: https://lore.kernel.org/r/20240317221050.18595-4-zajec5@gmail.com
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> index 5c12e9dad9167..76297dac2d459 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> @@ -846,9 +846,7 @@ hsdma: dma-controller@1b007000 {
> };
>
> eth: ethernet@1b100000 {
> - compatible = "mediatek,mt7622-eth",
> - "mediatek,mt2701-eth",
> - "syscon";
> + compatible = "mediatek,mt7622-eth";
> reg = <0 0x1b100000 0 0x20000>;
> interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_LOW>,
> <GIC_SPI 224 IRQ_TYPE_LEVEL_LOW>,
From: Amir Goldstein <amir73il(a)gmail.com>
commit 37f32f52643869131ec01bb69bdf9f404f6109fb upstream.
On failure to parse parameters in ovl_parse_param_lowerdir(), it is
necessary to update ctx->nr with the correct nr before using
ovl_reset_lowerdirs() to release l->name.
Reported-and-tested-by: syzbot+26eedf3631650972f17c(a)syzkaller.appspotmail.com
Fixes: c835110b588a ("ovl: remove unused code in lowerdir param parsing")
Co-authored-by: Edward Adam Davis <eadavis(a)qq.com>
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Jingbo Xu <jefflexu(a)linux.alibaba.com>
---
Commit c835110b588a ("ovl: remove unused code in lowerdir param
parsing") was back ported to 6.6.y as a "Stable-dep-of" of commit
2824083db76c ("ovl: Always reject mounting over case-insensitive
directories"), while omitting the fix for commit c835110b588a itself.
Maybe that is because by the time commit 37f32f526438 (the fix) is merged
into master branch, commit c835110b588a has not been back ported to 6.6.y
yet.
This causes ltp test warning on vfat (EBUSY when umounting) [1]:
tst_test.c:1701: TINFO: === Testing on vfat ===
tst_test.c:1117: TINFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
tst_test.c:1131: TINFO: Mounting /dev/loop0 to /tmp/ltp-XeGbUgDq5N/LTP_fankzf5WQ/mntpoint fstyp=vfat flags=0
fanotify13.c:152: TINFO: Test #0.1: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:157: TCONF: overlayfs not supported on vfat
fanotify13.c:152: TINFO: Test #1.1: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:157: TCONF: overlayfs not supported on vfat
fanotify13.c:152: TINFO: Test #2.1: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:157: TCONF: overlayfs not supported on vfat
fanotify13.c:152: TINFO: Test #3.1: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:157: TCONF: overlayfs not supported on vfat
fanotify13.c:152: TINFO: Test #4.1: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:157: TCONF: overlayfs not supported on vfat
fanotify13.c:152: TINFO: Test #5.1: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:157: TCONF: overlayfs not supported on vfat
tst_device.c:408: TINFO: umount('mntpoint') failed with EBUSY, try 1...
tst_device.c:412: TINFO: Likely gvfsd-trash is probing newly mounted fs, kill it to speed up tests.
tst_device.c:408: TINFO: umount('mntpoint') failed with EBUSY, try 2...
tst_device.c:408: TINFO: umount('mntpoint') failed with EBUSY, try 3...
tst_device.c:408: TINFO: umount('mntpoint') failed with EBUSY, try 4...
Reproduce:
/opt/ltp/runltp -f syscalls -s fanotify13
The original fix is applied to 6.6.y without conflict.
[1] https://lists.linux.it/pipermail/ltp/2023-November/036189.html
---
fs/overlayfs/params.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c
index ad3593a41fb5..488f920f79d2 100644
--- a/fs/overlayfs/params.c
+++ b/fs/overlayfs/params.c
@@ -438,7 +438,7 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc)
struct ovl_fs_context *ctx = fc->fs_private;
struct ovl_fs_context_layer *l;
char *dup = NULL, *iter;
- ssize_t nr_lower = 0, nr = 0, nr_data = 0;
+ ssize_t nr_lower, nr;
bool data_layer = false;
/*
@@ -490,6 +490,7 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc)
iter = dup;
l = ctx->lower;
for (nr = 0; nr < nr_lower; nr++, l++) {
+ ctx->nr++;
memset(l, 0, sizeof(*l));
err = ovl_mount_dir(iter, &l->path);
@@ -506,10 +507,10 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc)
goto out_put;
if (data_layer)
- nr_data++;
+ ctx->nr_data++;
/* Calling strchr() again would overrun. */
- if ((nr + 1) == nr_lower)
+ if (ctx->nr == nr_lower)
break;
err = -EINVAL;
@@ -519,7 +520,7 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc)
* This is a regular layer so we require that
* there are no data layers.
*/
- if ((ctx->nr_data + nr_data) > 0) {
+ if (ctx->nr_data > 0) {
pr_err("regular lower layers cannot follow data lower layers");
goto out_put;
}
@@ -532,8 +533,6 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc)
data_layer = true;
iter++;
}
- ctx->nr = nr_lower;
- ctx->nr_data += nr_data;
kfree(dup);
return 0;
--
2.19.1.6.gb485710b
A debugfs directory entry is create early during probe(). This entry is
not removed on error path leading to some "already present" issues in
case of EPROBE_DEFER.
Create this entry later in the probe() code to avoid the need to change
many 'return' in 'goto' and add the removal in the already present error
path.
Fixes: 942814840127 ("net: lan966x: Add VCAP debugFS support")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Herve Codina <herve.codina(a)bootlin.com>
---
drivers/net/ethernet/microchip/lan966x/lan966x_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
index 2635ef8958c8..61d88207eed4 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
@@ -1087,8 +1087,6 @@ static int lan966x_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, lan966x);
lan966x->dev = &pdev->dev;
- lan966x->debugfs_root = debugfs_create_dir("lan966x", NULL);
-
if (!device_get_mac_address(&pdev->dev, mac_addr)) {
ether_addr_copy(lan966x->base_mac, mac_addr);
} else {
@@ -1179,6 +1177,8 @@ static int lan966x_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, -ENODEV,
"no ethernet-ports child found\n");
+ lan966x->debugfs_root = debugfs_create_dir("lan966x", NULL);
+
/* init switch */
lan966x_init(lan966x);
lan966x_stats_init(lan966x);
@@ -1257,6 +1257,8 @@ static int lan966x_probe(struct platform_device *pdev)
destroy_workqueue(lan966x->stats_queue);
mutex_destroy(&lan966x->stats_lock);
+ debugfs_remove_recursive(lan966x->debugfs_root);
+
return err;
}
--
2.44.0
From: Ard Biesheuvel <ardb(a)kernel.org>
On x86, the ordinary, position dependent 'small' and 'kernel' code models only
support placement of the executable in 32-bit addressable memory, due to
the use of 32-bit signed immediates to generate references to global
variables. For the kernel, this implies that all global variables must
reside in the top 2 GiB of the kernel virtual address space, where the
implicit address bits 63:32 are equal to sign bit 31.
This means the kernel code model is not suitable for other bare metal
executables such as the kexec purgatory, which can be placed arbitrarily
in the physical address space, where its address may no longer be
representable as a sign extended 32-bit quantity. For this reason,
commit
e16c2983fba0 ("x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors")
switched to the 'large' code model, which uses 64-bit immediates for all
symbol references, including function calls, in order to avoid relying
on any assumptions regarding proximity of symbols in the final
executable.
The large code model is rarely used, clunky and the least likely to
operate in a similar fashion when comparing GCC and Clang, so it is best
avoided. This is especially true now that Clang 18 has started to emit
executable code in two separate sections (.text and .ltext), which
triggers an issue in the kexec loading code at runtime.
Instead, use the position independent small code model, which makes no
assumptions about placement but only about proximity, where all
referenced symbols must be within -/+ 2 GiB, i.e., in range for a
RIP-relative reference. Use hidden visibility to suppress the use of a
GOT, which carries absolute addresses that are not covered by static ELF
relocations, and is therefore incompatible with the kexec loader's
relocation logic.
Cc: Nathan Chancellor <nathan(a)kernel.org>
Cc: Nick Desaulniers <ndesaulniers(a)google.com>
Cc: Bill Wendling <morbo(a)google.com>
Cc: Justin Stitt <justinstitt(a)google.com>
Cc: Song Liu <song(a)kernel.org>
Cc: Ricardo Ribalda <ribalda(a)kernel.org>
Cc: Fangrui Song <maskray(a)google.com>
Cc: Arthur Eubanks <aeubanks(a)google.com>
Link: https://lore.kernel.org/all/20240417-x86-fix-kexec-with-llvm-18-v1-0-538312…
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org>
---
arch/x86/purgatory/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index bc31863c5ee6..a18591f6e6d9 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -42,7 +42,8 @@ KCOV_INSTRUMENT := n
# make up the standalone purgatory.ro
PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
-PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss -g0
+PURGATORY_CFLAGS := -mcmodel=small -ffreestanding -fno-zero-initialized-in-bss -g0
+PURGATORY_CFLAGS += -fpic -fvisibility=hidden
PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN) -DDISABLE_BRANCH_PROFILING
PURGATORY_CFLAGS += -fno-stack-protector
--
2.44.0.769.g3c40516874-goog
From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com>
When using a high speed clock with a low baud rate, the 4x prescaler is
automatically selected if required. In that case, sc16is7xx_set_baud()
properly configures the chip registers, but returns an incorrect baud
rate by not taking into account the prescaler value. This incorrect baud
rate is then fed to uart_update_timeout().
For example, with an input clock of 80MHz, and a selected baud rate of 50,
sc16is7xx_set_baud() will return 200 instead of 50.
Fix this by first changing the prescaler variable to hold the selected
prescaler value instead of the MCR bitfield. Then properly take into
account the selected prescaler value in the return value computation.
Also add better documentation about the divisor value computation.
Fixes: dfeae619d781 ("serial: sc16is7xx")
Cc: stable(a)vger.kernel.org
Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com>
---
drivers/tty/serial/sc16is7xx.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 03cf30e20b75..dcd6c5615401 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -555,16 +555,28 @@ static bool sc16is7xx_regmap_noinc(struct device *dev, unsigned int reg)
return reg == SC16IS7XX_RHR_REG;
}
+/*
+ * Configure programmable baud rate generator (divisor) according to the
+ * desired baud rate.
+ *
+ * From the datasheet, the divisor is computed according to:
+ *
+ * XTAL1 input frequency
+ * -----------------------
+ * prescaler
+ * divisor = ---------------------------
+ * baud-rate x sampling-rate
+ */
static int sc16is7xx_set_baud(struct uart_port *port, int baud)
{
struct sc16is7xx_one *one = to_sc16is7xx_one(port, port);
u8 lcr;
- u8 prescaler = 0;
+ int prescaler = 1;
unsigned long clk = port->uartclk, div = clk / 16 / baud;
if (div >= BIT(16)) {
- prescaler = SC16IS7XX_MCR_CLKSEL_BIT;
- div /= 4;
+ prescaler = 4;
+ div /= prescaler;
}
/* Enable enhanced features */
@@ -574,9 +586,10 @@ static int sc16is7xx_set_baud(struct uart_port *port, int baud)
SC16IS7XX_EFR_ENABLE_BIT);
sc16is7xx_efr_unlock(port);
+ /* If bit MCR_CLKSEL is set, the divide by 4 prescaler is activated. */
sc16is7xx_port_update(port, SC16IS7XX_MCR_REG,
SC16IS7XX_MCR_CLKSEL_BIT,
- prescaler);
+ prescaler == 1 ? 0 : SC16IS7XX_MCR_CLKSEL_BIT);
/* Backup LCR and access special register set (DLL/DLH) */
lcr = sc16is7xx_port_read(port, SC16IS7XX_LCR_REG);
@@ -592,7 +605,7 @@ static int sc16is7xx_set_baud(struct uart_port *port, int baud)
/* Restore LCR and access to general register set */
sc16is7xx_port_write(port, SC16IS7XX_LCR_REG, lcr);
- return DIV_ROUND_CLOSEST(clk / 16, div);
+ return DIV_ROUND_CLOSEST((clk / prescaler) / 16, div);
}
static void sc16is7xx_handle_rx(struct uart_port *port, unsigned int rxlen,
base-commit: 660a708098569a66a47d0abdad998e29e1259de6
--
2.39.2