From: Anatoliy Klymenko <anatoliy.klymenko(a)amd.com>
Use RG16 buffer format for fbdev emulation. Fbdev backend is being used
by Mali 400 userspace driver which expects 16 bit RGB pixel color format.
This change should not affect console or other fbdev applications as we
still have plenty of colors left.
Cc: Bill Mills <bill.mills(a)linaro.org>
Cc: Ilias Apalodimas <ilias.apalodimas(a)linaro.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko(a)amd.com>
Signed-off-by: Mikko Rapeli <mikko.rapeli(a)linaro.org>
---
drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index 2bee0a2275ede..ccc35cacd10cb 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -525,7 +525,7 @@ int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
goto err_poll_fini;
/* Initialize fbdev generic emulation. */
- drm_client_setup_with_fourcc(drm, DRM_FORMAT_RGB888);
+ drm_client_setup_with_fourcc(drm, DRM_FORMAT_RGB565);
return 0;
--
2.34.1
From: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com>
A KASAN tag mismatch, possibly causing a kernel panic, can be observed
on systems with a tag-based KASAN enabled and with multiple NUMA nodes.
It was reported on arm64 and reproduced on x86. It can be explained in
the following points:
1. There can be more than one virtual memory chunk.
2. Chunk's base address has a tag.
3. The base address points at the first chunk and thus inherits
the tag of the first chunk.
4. The subsequent chunks will be accessed with the tag from the
first chunk.
5. Thus, the subsequent chunks need to have their tag set to
match that of the first chunk.
Refactor code by reusing __kasan_unpoison_vmalloc in a new helper in
preparation for the actual fix.
Changelog v1 (after splitting of from the KASAN series):
- Rewrite first paragraph of the patch message to point at the user
impact of the issue.
- Move helper to common.c so it can be compiled in all KASAN modes.
Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS")
Cc: <stable(a)vger.kernel.org> # 6.1+
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com>
---
Changelog v3:
- Redo the patch after applying Andrey's comments to align the code more
with what's already in include/linux/kasan.h
Changelog v2:
- Redo the whole patch so it's an actual refactor.
include/linux/kasan.h | 15 +++++++++++++++
mm/kasan/common.c | 17 +++++++++++++++++
mm/vmalloc.c | 4 +---
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 6d7972bb390c..cde493cb7702 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -615,6 +615,16 @@ static __always_inline void kasan_poison_vmalloc(const void *start,
__kasan_poison_vmalloc(start, size);
}
+void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
+ kasan_vmalloc_flags_t flags);
+static __always_inline void
+kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
+ kasan_vmalloc_flags_t flags)
+{
+ if (kasan_enabled())
+ __kasan_unpoison_vmap_areas(vms, nr_vms, flags);
+}
+
#else /* CONFIG_KASAN_VMALLOC */
static inline void kasan_populate_early_vm_area_shadow(void *start,
@@ -639,6 +649,11 @@ static inline void *kasan_unpoison_vmalloc(const void *start,
static inline void kasan_poison_vmalloc(const void *start, unsigned long size)
{ }
+static __always_inline void
+kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
+ kasan_vmalloc_flags_t flags)
+{ }
+
#endif /* CONFIG_KASAN_VMALLOC */
#if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index d4c14359feaf..1ed6289d471a 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -28,6 +28,7 @@
#include <linux/string.h>
#include <linux/types.h>
#include <linux/bug.h>
+#include <linux/vmalloc.h>
#include "kasan.h"
#include "../slab.h"
@@ -582,3 +583,19 @@ bool __kasan_check_byte(const void *address, unsigned long ip)
}
return true;
}
+
+#ifdef CONFIG_KASAN_VMALLOC
+void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
+ kasan_vmalloc_flags_t flags)
+{
+ unsigned long size;
+ void *addr;
+ int area;
+
+ for (area = 0 ; area < nr_vms ; area++) {
+ size = vms[area]->size;
+ addr = vms[area]->addr;
+ vms[area]->addr = __kasan_unpoison_vmalloc(addr, size, flags);
+ }
+}
+#endif
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 22a73a087135..33e705ccafba 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -4872,9 +4872,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
* With hardware tag-based KASAN, marking is skipped for
* non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc().
*/
- for (area = 0; area < nr_vms; area++)
- vms[area]->addr = kasan_unpoison_vmalloc(vms[area]->addr,
- vms[area]->size, KASAN_VMALLOC_PROT_NORMAL);
+ kasan_unpoison_vmap_areas(vms, nr_vms, KASAN_VMALLOC_PROT_NORMAL);
kfree(vas);
return vms;
--
2.52.0
From: Vladimir Oltean <vladimir.oltean(a)nxp.com>
[ Upstream commit 5f2b28b79d2d1946ee36ad8b3dc0066f73c90481 ]
There are actually 2 problems:
- deleting the last element doesn't require the memmove of elements
[i + 1, end) over it. Actually, element i+1 is out of bounds.
- The memmove itself should move size - i - 1 elements, because the last
element is out of bounds.
The out-of-bounds element still remains out of bounds after being
accessed, so the problem is only that we touch it, not that it becomes
in active use. But I suppose it can lead to issues if the out-of-bounds
element is part of an unmapped page.
Fixes: 6666cebc5e30 ("net: dsa: sja1105: Add support for VLAN operations")
Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com>
Reviewed-by: Simon Horman <horms(a)kernel.org>
Link: https://patch.msgid.link/20250318115716.2124395-4-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
Signed-off-by: Chen Yu <xnguchen(a)sina.cn>
---
drivers/net/dsa/sja1105/sja1105_static_config.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/sja1105/sja1105_static_config.c b/drivers/net/dsa/sja1105/sja1105_static_config.c
index baba204ad62f..2ac91fe2a79b 100644
--- a/drivers/net/dsa/sja1105/sja1105_static_config.c
+++ b/drivers/net/dsa/sja1105/sja1105_static_config.c
@@ -1921,8 +1921,10 @@ int sja1105_table_delete_entry(struct sja1105_table *table, int i)
if (i > table->entry_count)
return -ERANGE;
- memmove(entries + i * entry_size, entries + (i + 1) * entry_size,
- (table->entry_count - i) * entry_size);
+ if (i + 1 < table->entry_count) {
+ memmove(entries + i * entry_size, entries + (i + 1) * entry_size,
+ (table->entry_count - i - 1) * entry_size);
+ }
table->entry_count--;
--
2.17.1
From: "Mario Limonciello (AMD)" <superm1(a)kernel.org>
[ Upstream commit 9fc6290117259a8dbf8247cb54559df62fd1550f ]
PCI device 0x115A is similar to pspv5, except it doesn't have platform
access mailbox support.
Signed-off-by: Mario Limonciello (AMD) <superm1(a)kernel.org>
Acked-by: Tom Lendacky <thomas.lendacky(a)amd.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Comprehensive Analysis
### 1. COMMIT MESSAGE ANALYSIS
**Subject:** `crypto: ccp - Add support for PCI device 0x115A`
**Key Information:**
- PCI device 0x115A is a new AMD security processor variant
- The commit message states it's "similar to pspv5, except it doesn't
have platform access mailbox support"
- Signed off by Mario Limonciello (AMD engineer) and Tom Lendacky (AMD)
- Merged by Herbert Xu (crypto maintainer)
**Tags Present:**
- `Signed-off-by`: 3 (proper sign-off chain)
- `Acked-by`: Tom Lendacky (driver maintainer acknowledgment)
- **NO** `Cc: stable(a)vger.kernel.org` tag
- **NO** `Fixes:` tag (this is expected - it's not fixing a bug, it's
enabling hardware)
### 2. CODE CHANGE ANALYSIS
The commit adds:
**A) New `pspv7` structure (~10 lines):**
```c
static const struct psp_vdata pspv7 = {
.tee = &teev2,
.cmdresp_reg = 0x10944,
.cmdbuff_addr_lo_reg = 0x10948,
.cmdbuff_addr_hi_reg = 0x1094c,
.bootloader_info_reg = 0x109ec,
.feature_reg = 0x109fc,
.inten_reg = 0x10510,
.intsts_reg = 0x10514,
};
```
This is **identical to pspv5** except it omits the `.platform_access =
&pa_v2` field. This is the explicit difference mentioned in the commit
message.
**B) New `dev_vdata[9]` entry (~6 lines):**
```c
{ /* 9 */
.bar = 2,
#ifdef CONFIG_CRYPTO_DEV_SP_PSP
.psp_vdata = &pspv7,
#endif
},
```
**C) New PCI device ID entry (1 line):**
```c
{ PCI_VDEVICE(AMD, 0x115A), (kernel_ulong_t)&dev_vdata[9] },
```
### 3. CLASSIFICATION
**This is a NEW DEVICE ID addition** - one of the explicitly allowed
exceptions for stable kernel backports.
The commit:
- Does NOT add new features or APIs
- Does NOT change existing behavior
- Only enables existing PSP driver functionality on new hardware
- Uses established patterns already in the driver
### 4. SCOPE AND RISK ASSESSMENT
**Change size:** ~17 lines total
- Small, contained data-only change
- No logic changes whatsoever
- Follows identical patterns used by existing pspv1-pspv6 structures
**Risk assessment: VERY LOW**
- The driver already handles NULL `platform_access` - verified in `psp-
dev.c`:
```c
if (psp->vdata->platform_access) {
ret = platform_access_dev_init(psp);
...
}
```
- Several existing structures (pspv1, pspv4, pspv6) already omit
`platform_access`
- The `teev2` structure referenced already exists since v6.5
- All register offsets are identical to pspv5
### 5. USER IMPACT
**Who is affected:**
- Users with AMD PCI device 0x115A (new AMD security processor variant)
- Without this patch, this hardware is completely non-functional
**Severity:** HIGH for affected users - enables critical security
hardware (TPM-like functionality)
### 6. STABILITY INDICATORS
**Positive signals:**
- Acked by Tom Lendacky (the original driver author and AMD maintainer)
- Follows exact same pattern as 10+ previous device ID additions in this
driver
- Same author (Mario Limonciello) has successfully added similar devices
before (0x17E0, 0x156E, etc.)
### 7. DEPENDENCY CHECK
**Required in stable tree:**
- `teev2` structure - added in v6.5 (commit 4aa0931be8f0a)
- Verified present in v6.6 and later
**Recent related commits:**
- 52e8ae868a824: "Add missing bootloader info reg for pspv5" (May 2025)
- 72942d6538564: "Add missing tee info reg for teev2" (May 2025)
The pspv7 structure in this commit already includes the
`bootloader_info_reg` correctly, so it was created after these fixes.
### 8. COMPARISON WITH SIMILAR COMMITS
This commit follows the exact same pattern as:
- `bb4185e595e47`: "Add support for PCI device 0x156E" - Added pspv6 +
dev_vdata[8] + PCI ID
- `4aa0931be8f0a`: "Add support for PCI device 0x17E0" - Added
pspv5/teev2 + dev_vdata[7] + PCI ID
- `6cb345939b8cc`: "Add support for PCI device 0x1134" - Added PCI ID
only
- `63935e2ee1f2a`: "Add support for PCI device 0x17D8" - Added PCI ID
only
These similar device ID additions are routinely considered for stable
trees.
---
## Final Assessment
**Should this be backported?**
**YES**, for the following reasons:
1. **Falls under the NEW DEVICE ID exception** - explicitly allowed per
stable kernel rules for enabling real hardware
2. **Trivial, data-only change** - ~17 lines, no logic changes
3. **Uses existing, proven infrastructure** - teev2 exists, NULL
platform_access handling exists
4. **Follows established patterns** - identical to 10+ previous similar
commits in this driver
5. **Zero risk of regression** - only affects users with the specific
0x115A device
6. **Enables real hardware** - without this, users with this AMD
security processor cannot use it at all
7. **Properly reviewed** - Acked by AMD maintainer, merged by crypto
subsystem maintainer
**Concerns:**
- Requires stable tree to have v6.6+ (for teev2 structure)
- May need the bootloader_info_reg fixes backported first for
consistency (commits 52e8ae868a824 and 72942d6538564)
The change is obviously correct, well-tested (used same patterns as
existing code), and enables hardware support that users need. This is
exactly the type of device ID addition that stable trees accept.
**YES**
drivers/crypto/ccp/sp-pci.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index e7bb803912a6d..8891ceee1d7d0 100644
--- a/drivers/crypto/ccp/sp-pci.c
+++ b/drivers/crypto/ccp/sp-pci.c
@@ -459,6 +459,17 @@ static const struct psp_vdata pspv6 = {
.intsts_reg = 0x10514, /* P2CMSG_INTSTS */
};
+static const struct psp_vdata pspv7 = {
+ .tee = &teev2,
+ .cmdresp_reg = 0x10944, /* C2PMSG_17 */
+ .cmdbuff_addr_lo_reg = 0x10948, /* C2PMSG_18 */
+ .cmdbuff_addr_hi_reg = 0x1094c, /* C2PMSG_19 */
+ .bootloader_info_reg = 0x109ec, /* C2PMSG_59 */
+ .feature_reg = 0x109fc, /* C2PMSG_63 */
+ .inten_reg = 0x10510, /* P2CMSG_INTEN */
+ .intsts_reg = 0x10514, /* P2CMSG_INTSTS */
+};
+
#endif
static const struct sp_dev_vdata dev_vdata[] = {
@@ -525,6 +536,13 @@ static const struct sp_dev_vdata dev_vdata[] = {
.psp_vdata = &pspv6,
#endif
},
+ { /* 9 */
+ .bar = 2,
+#ifdef CONFIG_CRYPTO_DEV_SP_PSP
+ .psp_vdata = &pspv7,
+#endif
+ },
+
};
static const struct pci_device_id sp_pci_table[] = {
{ PCI_VDEVICE(AMD, 0x1537), (kernel_ulong_t)&dev_vdata[0] },
@@ -539,6 +557,7 @@ static const struct pci_device_id sp_pci_table[] = {
{ PCI_VDEVICE(AMD, 0x17E0), (kernel_ulong_t)&dev_vdata[7] },
{ PCI_VDEVICE(AMD, 0x156E), (kernel_ulong_t)&dev_vdata[8] },
{ PCI_VDEVICE(AMD, 0x17D8), (kernel_ulong_t)&dev_vdata[8] },
+ { PCI_VDEVICE(AMD, 0x115A), (kernel_ulong_t)&dev_vdata[9] },
/* Last entry must be zero */
{ 0, }
};
--
2.51.0
The documentation states that on machines supporting only global
fan mode control, the pwmX_enable attributes should only be created
for the first fan channel (pwm1_enable, aka channel 0).
Fix the off-by-one error caused by the fact that fan channels have
a zero-based index.
Cc: stable(a)vger.kernel.org
Fixes: 1c1658058c99 ("hwmon: (dell-smm) Add support for automatic fan mode")
Signed-off-by: Armin Wolf <W_Armin(a)gmx.de>
---
drivers/hwmon/dell-smm-hwmon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index 683baf361c4c..a34753fc2973 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -861,9 +861,9 @@ static umode_t dell_smm_is_visible(const void *drvdata, enum hwmon_sensor_types
if (auto_fan) {
/*
* The setting affects all fans, so only create a
- * single attribute.
+ * single attribute for the first fan channel.
*/
- if (channel != 1)
+ if (channel != 0)
return 0;
/*
--
2.39.5
