We switched from (wrongly) using the page count to an independent
shared count. Now, shared page tables have a refcount of 1 (excluding
speculative references) and instead use ptdesc->pt_share_count to
identify sharing.
We didn't convert hugetlb_pmd_shared(), so right now, we would never
detect a shared PMD table as such, because sharing/unsharing no longer
touches the refcount of a PMD table.
Page migration, like mbind() or migrate_pages() would allow for migrating
folios mapped into such shared PMD tables, even though the folios are
not exclusive. In smaps we would account them as "private" although they
are "shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the
pagemap interface.
Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().
Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count")
Reviewed-by: Rik van Riel <riel(a)surriel.com>
Reviewed-by: Lance Yang <lance.yang(a)linux.dev>
Tested-by: Lance Yang <lance.yang(a)linux.dev>
Reviewed-by: Harry Yoo <harry.yoo(a)oracle.com>
Tested-by: Laurence Oberman <loberman(a)redhat.com>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com>
Acked-by: Oscar Salvador <osalvador(a)suse.de>
Cc: <stable(a)vger.kernel.org>
Cc: Liu Shixin <liushixin2(a)huawei.com>
Signed-off-by: David Hildenbrand (Red Hat) <david(a)kernel.org>
---
include/linux/hugetlb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 019a1c5281e4e..03c8725efa289 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -1326,7 +1326,7 @@ static inline __init void hugetlb_cma_reserve(int order)
#ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING
static inline bool hugetlb_pmd_shared(pte_t *pte)
{
- return page_count(virt_to_page(pte)) > 1;
+ return ptdesc_pmd_is_shared(virt_to_ptdesc(pte));
}
#else
static inline bool hugetlb_pmd_shared(pte_t *pte)
--
2.52.0
From: Sam James <sam(a)gentoo.org>
[ Upstream commit 9aeed9041929812a10a6d693af050846942a1d16 ]
Similar in nature to ab107276607af90b13a5994997e19b7b9731e251. glibc-2.42
drops the legacy termio struct, but the ioctls.h header still defines some
TC* constants in terms of termio (via sizeof). Hardcode the values instead.
This fixes building Python for example, which falls over like:
./Modules/termios.c:1119:16: error: invalid application of 'sizeof' to incomplete type 'struct termio'
Link: https://bugs.gentoo.org/961769
Link: https://bugs.gentoo.org/962600
Signed-off-by: Sam James <sam(a)gentoo.org>
Reviewed-by: Magnus Lindholm <linmag7(a)gmail.com>
Link: https://lore.kernel.org/r/6ebd3451908785cad53b50ca6bc46cfe9d6bc03c.17649224…
Signed-off-by: Magnus Lindholm <linmag7(a)gmail.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis Summary
### 1. COMMIT MESSAGE ANALYSIS
This commit addresses a **userspace build failure** caused by glibc-2.42
removing the legacy `struct termio` definition. The kernel's uapi header
`arch/alpha/include/uapi/asm/ioctls.h` uses `sizeof(struct termio)` in
macro expansions, which fails when that struct is undefined.
**Key signals:**
- Links to two real bug reports (Gentoo bugs #961769 and #962600)
- References a prior fix (ab107276607af) for powerpc with the exact same
issue
- Has `Reviewed-by:` tag
- Demonstrates real-world impact: Python build failure
### 2. CODE CHANGE ANALYSIS
**What the change does:**
```c
// Before: Uses sizeof(struct termio) in macro expansion
#define TCGETA _IOR('t', 23, struct termio)
// After: Pre-computed constant
#define TCGETA 0x40127417
```
**Verification of the hardcoded values:**
Looking at `arch/alpha/include/uapi/asm/ioctl.h`, the ioctl encoding on
alpha is:
- `_IOC_SIZESHIFT` = 16, `_IOC_DIRSHIFT` = 29
- `_IOC_READ` = 2, `_IOC_WRITE` = 4
For `TCGETA = _IOR('t', 23, struct termio)`:
- dir=2, type=0x74, nr=0x17, size=18(0x12)
- Result: `(2<<29)|(0x74<<8)|(0x17)|(0x12<<16)` = **0x40127417** ✓
The hardcoded values are mathematically correct.
### 3. CLASSIFICATION
**Category: BUILD FIX**
This falls under the **build fixes** exception category - it's critical
for users who need to build userspace software with modern glibc. Other
architectures (powerpc, sh, xtensa) already have identical fixes in the
tree.
### 4. SCOPE AND RISK ASSESSMENT
- **Lines changed:** 4
- **Files touched:** 1 (alpha-specific uapi header)
- **Risk: EXTREMELY LOW**
- No runtime behavior change - only affects compilation
- The ioctl numbers are identical (pre-computed vs macro-computed)
- Pattern already established in other architectures
### 5. USER IMPACT
- **Affected users:** Anyone on alpha using glibc 2.42+ (e.g., Gentoo
users)
- **Severity:** Critical for affected users - cannot build Python, and
potentially many other programs that use termios
- **Scope:** Limited to alpha architecture, but complete blocker for
those users
### 6. STABILITY INDICATORS
- Has `Reviewed-by:` tag
- Same pattern accepted for powerpc (commit ab107276607af)
- Documented with actual bug reports showing real users affected
- No runtime changes - purely compile-time fix
### 7. DEPENDENCY CHECK
- **No dependencies** - standalone fix
- The affected file exists in all stable trees (uapi header)
- Clean application expected
### Final Assessment
**Pros:**
- Fixes a real, documented build breakage with modern glibc
- Extremely small and localized (4 lines, 1 file)
- Zero runtime risk - mathematically equivalent values
- Established precedent with powerpc fix
- Has review tag and bug report links
**Cons:**
- No explicit `Cc: stable(a)vger.kernel.org` tag
- Alpha is a niche architecture
**Verdict:** This is textbook stable material. It's a build fix that:
1. Is obviously correct (values are mathematically equivalent)
2. Fixes a real bug (complete build failure)
3. Is small and contained (4 lines)
4. Has no runtime risk whatsoever
5. Follows established precedent from other architectures
The lack of a stable tag is not disqualifying - many valid stable
patches don't have it. Build compatibility with modern toolchains is
exactly what stable trees need to maintain.
**YES**
arch/alpha/include/uapi/asm/ioctls.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/alpha/include/uapi/asm/ioctls.h b/arch/alpha/include/uapi/asm/ioctls.h
index 971311605288f..a09d04b49cc65 100644
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -23,10 +23,10 @@
#define TCSETSW _IOW('t', 21, struct termios)
#define TCSETSF _IOW('t', 22, struct termios)
-#define TCGETA _IOR('t', 23, struct termio)
-#define TCSETA _IOW('t', 24, struct termio)
-#define TCSETAW _IOW('t', 25, struct termio)
-#define TCSETAF _IOW('t', 28, struct termio)
+#define TCGETA 0x40127417
+#define TCSETA 0x80127418
+#define TCSETAW 0x80127419
+#define TCSETAF 0x8012741c
#define TCSBRK _IO('t', 29)
#define TCXONC _IO('t', 30)
--
2.51.0
The Dell XPS 13 9350 and XPS 16 9640 both have an upside-down mounted
OV02C10 sensor. This rotation of 180° is reported in neither the SSDB nor
the _PLD for the sensor (both report a rotation of 0°).
Add a DMI quirk mechanism for upside-down sensors and add 2 initial entries
to the DMI quirk list for these 2 laptops.
Note the OV02C10 driver was originally developed on a XPS 16 9640 which
resulted in inverted vflip + hflip settings making it look like the sensor
was upright on the XPS 16 9640 and upside down elsewhere this has been
fixed in commit 69fe27173396 ("media: ov02c10: Fix default vertical flip").
This makes this commit a regression fix since now the video is upside down
on these Dell XPS models where it was not before.
Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip")
Cc: stable(a)vger.kernel.org
Reviewed-by: Bryan O'Donoghue <bod(a)kernel.org>
Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com>
---
Changes in v2:
- Fix fixes tag to use the correct commit hash
- Drop || COMPILE_TEST from Kconfig to fix compile errors when ACPI is disabled
---
drivers/media/pci/intel/Kconfig | 2 +-
drivers/media/pci/intel/ipu-bridge.c | 29 ++++++++++++++++++++++++++++
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/intel/Kconfig b/drivers/media/pci/intel/Kconfig
index d9fcddce028b..3f14ca110d06 100644
--- a/drivers/media/pci/intel/Kconfig
+++ b/drivers/media/pci/intel/Kconfig
@@ -6,7 +6,7 @@ source "drivers/media/pci/intel/ivsc/Kconfig"
config IPU_BRIDGE
tristate "Intel IPU Bridge"
- depends on ACPI || COMPILE_TEST
+ depends on ACPI
depends on I2C
help
The IPU bridge is a helper library for Intel IPU drivers to
diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index 58ea01d40c0d..6463b2a47d78 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -5,6 +5,7 @@
#include <acpi/acpi_bus.h>
#include <linux/cleanup.h>
#include <linux/device.h>
+#include <linux/dmi.h>
#include <linux/i2c.h>
#include <linux/mei_cl_bus.h>
#include <linux/platform_device.h>
@@ -99,6 +100,28 @@ static const struct ipu_sensor_config ipu_supported_sensors[] = {
IPU_SENSOR_CONFIG("XMCC0003", 1, 321468000),
};
+/*
+ * DMI matches for laptops which have their sensor mounted upside-down
+ * without reporting a rotation of 180° in neither the SSDB nor the _PLD.
+ */
+static const struct dmi_system_id upside_down_sensor_dmi_ids[] = {
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS 13 9350"),
+ },
+ .driver_data = "OVTI02C1",
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS 16 9640"),
+ },
+ .driver_data = "OVTI02C1",
+ },
+ {} /* Terminating entry */
+};
+
static const struct ipu_property_names prop_names = {
.clock_frequency = "clock-frequency",
.rotation = "rotation",
@@ -249,6 +272,12 @@ static int ipu_bridge_read_acpi_buffer(struct acpi_device *adev, char *id,
static u32 ipu_bridge_parse_rotation(struct acpi_device *adev,
struct ipu_sensor_ssdb *ssdb)
{
+ const struct dmi_system_id *dmi_id;
+
+ dmi_id = dmi_first_match(upside_down_sensor_dmi_ids);
+ if (dmi_id && acpi_dev_hid_match(adev, dmi_id->driver_data))
+ return 180;
+
switch (ssdb->degree) {
case IPU_SENSOR_ROTATION_NORMAL:
return 0;
--
2.52.0
During sensor calibration I noticed that with the hflip control set to
false/disabled the image was mirrored.
The horizontal flip control is inverted and needs to be set to 1 to not
flip. This is something which seems to be common with various recent
Omnivision sensors, the ov01a10 and ov08x40 also have an inverted
mirror control.
Invert the hflip control to fix the sensor mirroring by default.
Fixes: b7cd2ba3f692 ("media: ov02c10: Support hflip and vflip")
Cc: stable(a)vger.kernel.org
Cc: Sebastian Reichel <sre(a)kernel.org>
Reviewed-by: Bryan O'Donoghue <bod(a)kernel.org>
Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com>
---
drivers/media/i2c/ov02c10.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c
index 384c2f0b1608..f912ae142040 100644
--- a/drivers/media/i2c/ov02c10.c
+++ b/drivers/media/i2c/ov02c10.c
@@ -170,7 +170,7 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = {
{0x3816, 0x01},
{0x3817, 0x01},
- {0x3820, 0xa0},
+ {0x3820, 0xa8},
{0x3821, 0x00},
{0x3822, 0x80},
{0x3823, 0x08},
@@ -462,9 +462,9 @@ static int ov02c10_set_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_HFLIP:
cci_write(ov02c10->regmap, OV02C10_ISP_X_WIN_CONTROL,
- ctrl->val ? 1 : 2, &ret);
+ ctrl->val ? 2 : 1, &ret);
cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
- BIT(3), ov02c10->hflip->val << 3, &ret);
+ BIT(3), ctrl->val ? 0 : BIT(3), &ret);
break;
case V4L2_CID_VFLIP:
--
2.52.0
The ov02c10 is capable of having its (crop) window shifted around with 1
pixel precision while streaming.
This allows changing the x/y window coordinates when changing flipping to
preserve the bayer-pattern.
__v4l2_ctrl_handler_setup() will now write the window coordinates at 0x3810
and 0x3812 so these can be dropped from sensor_1928x1092_30fps_setting.
Since the bayer-pattern is now unchanged, the V4L2_CTRL_FLAG_MODIFY_LAYOUT
flag can be dropped from the flip controls.
Note the original use of the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag was
incomplete, besides setting the flag the driver should also have reported
a different mbus code when getting the source pad's format depending on
the hflip / vflip settings see the ov2680.c driver for example.
Fixes: b7cd2ba3f692 ("media: ov02c10: Support hflip and vflip")
Cc: stable(a)vger.kernel.org
Cc: Sebastian Reichel <sre(a)kernel.org>
Reviewed-by: Bryan O'Donoghue <bod(a)kernel.org>
Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com>
---
drivers/media/i2c/ov02c10.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c
index 6369841de88b..384c2f0b1608 100644
--- a/drivers/media/i2c/ov02c10.c
+++ b/drivers/media/i2c/ov02c10.c
@@ -165,10 +165,6 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = {
{0x3809, 0x88},
{0x380a, 0x04},
{0x380b, 0x44},
- {0x3810, 0x00},
- {0x3811, 0x02},
- {0x3812, 0x00},
- {0x3813, 0x01},
{0x3814, 0x01},
{0x3815, 0x01},
{0x3816, 0x01},
@@ -465,11 +461,15 @@ static int ov02c10_set_ctrl(struct v4l2_ctrl *ctrl)
break;
case V4L2_CID_HFLIP:
+ cci_write(ov02c10->regmap, OV02C10_ISP_X_WIN_CONTROL,
+ ctrl->val ? 1 : 2, &ret);
cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
BIT(3), ov02c10->hflip->val << 3, &ret);
break;
case V4L2_CID_VFLIP:
+ cci_write(ov02c10->regmap, OV02C10_ISP_Y_WIN_CONTROL,
+ ctrl->val ? 2 : 1, &ret);
cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL,
BIT(4), ov02c10->vflip->val << 4, &ret);
break;
@@ -551,13 +551,9 @@ static int ov02c10_init_controls(struct ov02c10 *ov02c10)
ov02c10->hflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops,
V4L2_CID_HFLIP, 0, 1, 1, 0);
- if (ov02c10->hflip)
- ov02c10->hflip->flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT;
ov02c10->vflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops,
V4L2_CID_VFLIP, 0, 1, 1, 0);
- if (ov02c10->vflip)
- ov02c10->vflip->flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT;
v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &ov02c10_ctrl_ops,
V4L2_CID_TEST_PATTERN,
--
2.52.0
From: "Chia-Lin Kao (AceLan)" <acelan.kao(a)canonical.com>
[ Upstream commit b169e1733cadb614e87f69d7a5ae1b186c50d313 ]
Dell Pro Rugged 10/12 tablets has a reliable VGBS method.
If VGBS is not called on boot, the on-screen keyboard won't appear if the
device is booted without a keyboard.
Call VGBS on boot on thess devices to get the initial state of
SW_TABLET_MODE in a reliable way.
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao(a)canonical.com>
Reviewed-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com>
Link: https://patch.msgid.link/20251127070407.656463-1-acelan.kao@canonical.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Summary Analysis
### What This Commit Does
This commit adds two Dell tablet models (Dell Pro Rugged 10 Tablet
RA00260 and Dell Pro Rugged 12 Tablet RA02260) to the
`dmi_vgbs_allow_list` DMI quirk table. When a device matches this list,
the driver calls the VGBS ACPI method at probe time to properly detect
the initial SW_TABLET_MODE state.
### The Bug Being Fixed
Without this quirk, on these Dell tablets:
- The VGBS method isn't called at boot
- The kernel doesn't know the device is in tablet mode
- The on-screen keyboard won't appear if the device is booted without a
physical keyboard attached
- This makes the device difficult/impossible to use in tablet-only mode
### Classification: Hardware Quirk/Workaround
This falls squarely into the **QUIRKS and WORKAROUNDS** category which
is explicitly allowed for stable backporting:
- It's a DMI-based allowlist entry for specific hardware models
- The pattern is identical to existing entries (HP Spectre, Microsoft
Surface Go, HP Dragonfly G2)
- The mechanism has been stable since Linux 5.10
### Risk Assessment
**Risk Level: EXTREMELY LOW**
- **Lines changed**: ~12 lines (just two DMI match entries)
- **Files touched**: 1 file
- **Scope**: Only affects Dell Pro Rugged 10/12 tablets
- **Cannot regress other hardware**: DMI matching is device-specific
- **Pattern proven**: Same structure as existing entries that have
worked for years
### Stability Indicators
- **Reviewed-by:** Hans de Goede (well-known x86 platform maintainer)
- **Reviewed-by:** Ilpo Järvinen (Intel platform maintainer)
- The `dmi_vgbs_allow_list` infrastructure has existed since v5.10-rc1
(commit 537b0dd4729e7)
### Stable Tree Criteria Assessment
| Criterion | Status |
|-----------|--------|
| Obviously correct | ✅ Yes - trivial data addition |
| Fixes real bug | ✅ Yes - on-screen keyboard not working |
| Small and contained | ✅ Yes - ~12 lines in 1 file |
| No new features | ✅ Yes - enables existing functionality |
| Applies cleanly | ✅ Yes - simple addition to allowlist |
### Concerns
1. **No explicit "Cc: stable" tag** - However, DMI quirk additions are
commonly appropriate for stable even without explicit tags
2. **No "Fixes:" tag** - This is adding new device support rather than
fixing a regression in existing code
### Verdict
This commit is appropriate for stable backporting because:
1. It's a minimal, surgical hardware quirk that only affects two
specific Dell tablet models
2. It fixes a real usability issue for affected users (tablet becomes
difficult to use without keyboard)
3. Zero risk of regression for any other hardware
4. The pattern exactly matches existing stable entries
5. The infrastructure has been stable since v5.10, available in all
current LTS kernels
6. Well-reviewed by experienced platform maintainers
The lack of explicit stable tags is not disqualifying - this is a
textbook example of a hardware quirk addition that should go to stable
trees to enable proper device functionality.
**YES**
drivers/platform/x86/intel/hid.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/platform/x86/intel/hid.c b/drivers/platform/x86/intel/hid.c
index 9c07a7faf18fe..560cc063198e1 100644
--- a/drivers/platform/x86/intel/hid.c
+++ b/drivers/platform/x86/intel/hid.c
@@ -177,6 +177,18 @@ static const struct dmi_system_id dmi_vgbs_allow_list[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "HP Elite Dragonfly G2 Notebook PC"),
},
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Dell Pro Rugged 10 Tablet RA00260"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Dell Pro Rugged 12 Tablet RA02260"),
+ },
+ },
{ }
};
--
2.51.0
From: Jens Reidel <adrian(a)mainlining.org>
[ Upstream commit e3c13e0caa8ceb7dec1a7c4fcfd9dbef56a69fbe ]
Set CLK_OPS_PARENT_ENABLE to ensure the parent gets prepared and enabled
when switching to it, fixing an "rcg didn't update its configuration"
warning.
Signed-off-by: Jens Reidel <adrian(a)mainlining.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250919-sm7150-dispcc-fixes-v1-3-308ad47c5fce@ma…
Signed-off-by: Bjorn Andersson <andersson(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
### 3. Technical Understanding
The `CLK_OPS_PARENT_ENABLE` flag (BIT(12) in clk-provider.h) ensures
that "parents need enable during gate/ungate, set rate and re-parent."
Without this flag, when the pixel clock source tries to switch to a new
parent clock, the parent might not be enabled, causing the RCG (Root
Clock Generator) to fail to update its configuration.
This is a well-known pattern in Qualcomm clock drivers - pixel clocks
dynamically switch parents during display panel initialization, and the
parent must be running for the configuration switch to complete.
### 4. Scope and Risk Assessment
- **Lines changed**: 1 line (adding a single flag)
- **Files touched**: 1 file
- **Complexity**: Very low
- **Risk**: Very low - this is an established pattern used across many
Qualcomm dispcc/gcc drivers
### 5. User Impact
- Affects SM7150-based devices (mobile phones)
- The warning indicates clock configuration issues that could affect
display initialization
- Limited scope - only SM7150 platform users
### 6. Stable Tree Applicability
- Driver was added in **v6.11** (commit 3829c412197e1)
- Only applicable to v6.11.y, v6.12.y, and newer stable trees
- NOT applicable to LTS kernels: 6.6.y, 6.1.y, 5.15.y (driver doesn't
exist)
### 7. Key Observations
**Against backporting:**
1. **No "Cc: stable(a)vger.kernel.org" tag** - The maintainers did not
request stable backport
2. **No "Fixes:" tag** - Doesn't reference the original commit where the
bug was introduced
3. **Very new driver** - SM7150 dispcc was added in v6.11, limiting
stable applicability
4. **Not a critical issue** - A warning message, not a crash, panic, or
data corruption
5. **Mobile SoC** - Users running stable kernels rarely use cutting-edge
mobile phone support
**For backporting:**
1. Valid bug fix with proven pattern
2. Extremely small and low-risk change
3. Has proper review from Qualcomm clock maintainers
drivers/clk/qcom/dispcc-sm7150.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/dispcc-sm7150.c b/drivers/clk/qcom/dispcc-sm7150.c
index bdfff246ed3fe..ddc7230b8aea7 100644
--- a/drivers/clk/qcom/dispcc-sm7150.c
+++ b/drivers/clk/qcom/dispcc-sm7150.c
@@ -356,7 +356,7 @@ static struct clk_rcg2 dispcc_mdss_pclk0_clk_src = {
.name = "dispcc_mdss_pclk0_clk_src",
.parent_data = dispcc_parent_data_4,
.num_parents = ARRAY_SIZE(dispcc_parent_data_4),
- .flags = CLK_SET_RATE_PARENT,
+ .flags = CLK_SET_RATE_PARENT | CLK_OPS_PARENT_ENABLE,
.ops = &clk_pixel_ops,
},
};
--
2.51.0