03/10/23 15:39, Anastasia Belova пишет:
>
> 14/09/23 12:45, Anastasia Belova пишет:
>> count_bitmap_extents was deleted in version 5.11, but
>> there is possible mistake in versions 5.6-5.10.
>>
>> Region size should be calculated by subtracting
>> the end from the beginning.
> Do I understand correctly that bytes should decrease and
> (rs - re) is always negative and should be replaced by (re - rs)?
>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>
>> Fixes: dfb79ddb130e ("btrfs: track discardable extents for async discard")
>> Signed-off-by: Anastasia Belova<abelova(a)astralinux.ru>
>> ---
>> fs/btrfs/free-space-cache.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
>> index 4989c60b1df9..a34e266a0969 100644
>> --- a/fs/btrfs/free-space-cache.c
>> +++ b/fs/btrfs/free-space-cache.c
>> @@ -1930,7 +1930,7 @@ static int count_bitmap_extents(struct btrfs_free_space_ctl *ctl,
>>
>> bitmap_for_each_set_region(bitmap_info->bitmap, rs, re, 0,
>> BITS_PER_BITMAP) {
>> - bytes -= (rs - re) * ctl->unit;
>> + bytes -= (re - rs) * ctl->unit;
>> count++;
>>
>> if (!bytes)
> Anastasia
Sorry for sending html accidentally
Hello SoC maintainers,
As suggested by Arnd in [1], I am sending an update to the MAINTAINERS
file, adding myself to the MediaTek SoC maintainers, and some urgent
bugfixes for MediaTek devicetrees.
mt6358 PMIC
- Bogus property dropped
mt7622/mt7986a
- Fix dtbs_check for t-phy nodes
mt8195:
- Fix early boot failure when DSU PMU enabled
- Fix memory layout for demo board
Regards,
Angelo
---
AngeloGioacchino Del Regno (1):
MAINTAINERS: Add Angelo as MediaTek SoC co-maintainer
Eugen Hristev (1):
arm64: dts: mediatek: fix t-phy unit name
Macpaul Lin (2):
arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB
arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regions
Nícolas F. R. A. Prado (1):
arm64: dts: mediatek: mt8195: Set DSU PMU status to fail
MAINTAINERS | 2 +-
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 2 +-
arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 2 +-
arch/arm64/boot/dts/mediatek/mt8195-demo.dts | 39 ++++++++++++++++++++++------
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 1 +
5 files changed, 35 insertions(+), 11 deletions(-)
---
base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d
change-id: 20231003-mediatek-fixes-v6-7-341b5cfdc07a
Best regards,
--
AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>
In BMC environments with concurrent access to multiple registers, certain
registers occasionally yield a value of 0 even after 3 retries due to
hardware errata. As a fix, we have extended the retry count from 3 to 30.
The same errata applies to the mpt3sas driver, and a similar patch has
been accepted. Please find more details in the mpt3sas patch reference
link.
Link: https://lore.kernel.org/r/20230829090020.5417-2-ranjan.kumar@broadcom.com
Fixes: 272652fcbf1a ("scsi: megaraid_sas: add retry logic in megasas_readl")
Cc: stable(a)vger.kernel.org
Signed-off-by: Chandrakanth patil <chandrakanth.patil(a)broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com>
---
drivers/scsi/megaraid/megaraid_sas_base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
index e1aa667dae66..3d4f13da1ae8 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -263,13 +263,13 @@ u32 megasas_readl(struct megasas_instance *instance,
* Fusion registers could intermittently return all zeroes.
* This behavior is transient in nature and subsequent reads will
* return valid value. As a workaround in driver, retry readl for
- * upto three times until a non-zero value is read.
+ * up to thirty times until a non-zero value is read.
*/
if (instance->adapter_type == AERO_SERIES) {
do {
ret_val = readl(addr);
i++;
- } while (ret_val == 0 && i < 3);
+ } while (ret_val == 0 && i < 30);
return ret_val;
} else {
return readl(addr);
--
2.39.3
For an unknown TX CQE error type (probably from a newer hardware),
still free the SKB, update the queue tail, etc., otherwise the
accounting will be wrong.
Also, TX errors can be triggered by injecting corrupted packets, so
replace the WARN_ONCE to ratelimited error logging.
Cc: stable(a)vger.kernel.org
Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com>
Reviewed-by: Simon Horman <horms(a)kernel.org>
---
drivers/net/ethernet/microsoft/mana/mana_en.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index 4a16ebff3d1d..5cdcf7561b38 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -1317,19 +1317,23 @@ static void mana_poll_tx_cq(struct mana_cq *cq)
case CQE_TX_VPORT_IDX_OUT_OF_RANGE:
case CQE_TX_VPORT_DISABLED:
case CQE_TX_VLAN_TAGGING_VIOLATION:
- WARN_ONCE(1, "TX: CQE error %d: ignored.\n",
- cqe_oob->cqe_hdr.cqe_type);
+ if (net_ratelimit())
+ netdev_err(ndev, "TX: CQE error %d\n",
+ cqe_oob->cqe_hdr.cqe_type);
+
apc->eth_stats.tx_cqe_err++;
break;
default:
- /* If the CQE type is unexpected, log an error, assert,
- * and go through the error path.
+ /* If the CQE type is unknown, log an error,
+ * and still free the SKB, update tail, etc.
*/
- WARN_ONCE(1, "TX: Unexpected CQE type %d: HW BUG?\n",
- cqe_oob->cqe_hdr.cqe_type);
+ if (net_ratelimit())
+ netdev_err(ndev, "TX: unknown CQE type %d\n",
+ cqe_oob->cqe_hdr.cqe_type);
+
apc->eth_stats.tx_cqe_unknown_type++;
- return;
+ break;
}
if (WARN_ON_ONCE(txq->gdma_txq_id != completions[i].wq_num))
--
2.25.1
From: Fabiano Rosas <farosas(a)suse.de>
Our linker script for optionroms specifies only the placement of the
.text section, leaving the linker free to place the remaining sections
at arbitrary places in the file.
Since at least binutils 2.39, the .note.gnu.build-id section is now
being placed at the start of the file, which causes label addresses to
be shifted. For linuxboot_dma.bin that means that the PnP header
(among others) will not be found when determining the type of ROM at
optionrom_setup():
(0x1c is the label _pnph, where the magic "PnP" is)
$ xxd /usr/share/qemu/linuxboot_dma.bin | grep "PnP"
00000010: 0000 0000 0000 0000 0000 1c00 2450 6e50 ............$PnP
$ xxd pc-bios/optionrom/linuxboot_dma.bin | grep "PnP"
00000010: 0000 0000 0000 0000 0000 4c00 2450 6e50 ............$PnP
^bad
Using a freshly built linuxboot_dma.bin ROM results in a broken boot:
SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org)
Booting from Hard Disk...
Boot failed: could not read the boot disk
Booting from Floppy...
Boot failed: could not read the boot disk
No bootable device.
We're not using the build-id section, so pass the --build-id=none
option to the linker to remove it entirely.
Note: In theory, this same issue could happen with any other
section. The ideal solution would be to have all unused sections
discarded in the linker script. However that would be a larger change,
specially for the pvh rom which uses the .bss and COMMON sections so
I'm addressing only the immediate issue here.
Reported-by: Vasiliy Ulyanov <vulyanov(a)suse.de>
Signed-off-by: Fabiano Rosas <farosas(a)suse.de>
Reviewed-by: Thomas Huth <thuth(a)redhat.com>
Message-ID: <20230926192502.15986-1-farosas(a)suse.de>
Cc: stable(a)vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
pc-bios/optionrom/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
index b1fff0ba6c8..30d07026c79 100644
--- a/pc-bios/optionrom/Makefile
+++ b/pc-bios/optionrom/Makefile
@@ -36,7 +36,7 @@ config-cc.mak: Makefile
$(call cc-option,-Wno-array-bounds)) 3> config-cc.mak
-include config-cc.mak
-override LDFLAGS = -nostdlib -Wl,-T,$(SRC_DIR)/flat.lds
+override LDFLAGS = -nostdlib -Wl,--build-id=none,-T,$(SRC_DIR)/flat.lds
pvh.img: pvh.o pvh_main.o
--
2.41.0
Attn: stable(a)vger.kernel.org
Date: 03-10-2023
Subject: Letter of Intent (LOI) (03-10-2023)
This is a Letter of Intent concerning my Board of investors intent to fund some of your available investment projects.
If this is of any interest to you then kindly advise.
Yours Faithfully,
Ahmad R. Deeb
Head of Investment Team