* [PATCH AUTOSEL 6.6 04/59] selftests/futex: Define SYS_futex on 32-bit architectures with 64-bit time_t
[not found] <20250804003413.3622950-1-sashal@kernel.org>
@ 2025-08-04 0:33 ` Sasha Levin
2025-08-04 0:33 ` [PATCH AUTOSEL 6.6 28/59] pwm: sifive: Fix PWM algorithm and clarify inverted compare behavior Sasha Levin
1 sibling, 0 replies; 4+ messages in thread
From: Sasha Levin @ 2025-08-04 0:33 UTC (permalink / raw)
To: patches, stable
Cc: Cynthia Huang, Ben Zong-You Xie, Thomas Gleixner,
Muhammad Usama Anjum, Sasha Levin, paul.walmsley, palmer, aou,
linux-riscv
From: Cynthia Huang <cynthia@andestech.com>
[ Upstream commit 04850819c65c8242072818655d4341e70ae998b5 ]
The kernel does not provide sys_futex() on 32-bit architectures that do not
support 32-bit time representations, such as riscv32.
As a result, glibc cannot define SYS_futex, causing compilation failures in
tests that rely on this syscall. Define SYS_futex as SYS_futex_time64 in
such cases to ensure successful compilation and compatibility.
Signed-off-by: Cynthia Huang <cynthia@andestech.com>
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Link: https://lore.kernel.org/all/20250710103630.3156130-1-ben717@andestech.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit should be backported to stable kernel trees for the
following reasons:
1. **Fixes a real compilation failure bug**: The commit addresses a
build failure in kernel selftests on 32-bit architectures with 64-bit
time_t, specifically riscv32. This prevents the futex selftests from
compiling on these architectures, which is a functional bug that
affects testing infrastructure.
2. **Simple and contained fix**: The change is minimal - it only adds a
conditional preprocessor definition that maps `SYS_futex` to
`SYS_futex_time64` when the former is not defined but the latter is.
The fix is:
```c
#if !defined(SYS_futex) && defined(SYS_futex_time64)
#define SYS_futex SYS_futex_time64
#endif
```
3. **No risk of regression**: The change is guarded by preprocessor
conditionals that only activate when `SYS_futex` is not defined AND
`SYS_futex_time64` is defined. This means it has zero impact on
architectures where `SYS_futex` is already defined, ensuring no
regressions on existing systems.
4. **Affects kernel testing infrastructure**: While this is in the
selftests directory and not core kernel code, having working
selftests is critical for kernel stability and quality assurance. The
futex selftests are important for validating futex functionality
across different architectures.
5. **Addresses Y2038 compatibility**: This fix is part of the broader
Y2038 compatibility effort where 32-bit architectures are
transitioning to 64-bit time_t. As more 32-bit architectures adopt
64-bit time_t, this fix becomes increasingly important.
6. **Clear problem and solution**: The commit message clearly explains
the issue (glibc cannot define SYS_futex on certain architectures)
and provides a clean solution that maintains compatibility.
The fix follows stable kernel rules by being a minimal change that fixes
an important bug without introducing new features or architectural
changes. It's confined to the testing infrastructure and has clear
boundaries with no side effects beyond enabling compilation of the futex
selftests on affected architectures.
tools/testing/selftests/futex/include/futextest.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/tools/testing/selftests/futex/include/futextest.h b/tools/testing/selftests/futex/include/futextest.h
index ddbcfc9b7bac..7a5fd1d5355e 100644
--- a/tools/testing/selftests/futex/include/futextest.h
+++ b/tools/testing/selftests/futex/include/futextest.h
@@ -47,6 +47,17 @@ typedef volatile u_int32_t futex_t;
FUTEX_PRIVATE_FLAG)
#endif
+/*
+ * SYS_futex is expected from system C library, in glibc some 32-bit
+ * architectures (e.g. RV32) are using 64-bit time_t, therefore it doesn't have
+ * SYS_futex defined but just SYS_futex_time64. Define SYS_futex as
+ * SYS_futex_time64 in this situation to ensure the compilation and the
+ * compatibility.
+ */
+#if !defined(SYS_futex) && defined(SYS_futex_time64)
+#define SYS_futex SYS_futex_time64
+#endif
+
/**
* futex() - SYS_futex syscall wrapper
* @uaddr: address of first futex
--
2.39.5
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 4+ messages in thread* [PATCH AUTOSEL 6.6 28/59] pwm: sifive: Fix PWM algorithm and clarify inverted compare behavior
[not found] <20250804003413.3622950-1-sashal@kernel.org>
2025-08-04 0:33 ` [PATCH AUTOSEL 6.6 04/59] selftests/futex: Define SYS_futex on 32-bit architectures with 64-bit time_t Sasha Levin
@ 2025-08-04 0:33 ` Sasha Levin
2025-08-04 10:45 ` Uwe Kleine-König
1 sibling, 1 reply; 4+ messages in thread
From: Sasha Levin @ 2025-08-04 0:33 UTC (permalink / raw)
To: patches, stable
Cc: Nylon Chen, Zong Li, Vincent Chen, Uwe Kleine-König,
Sasha Levin, paul.walmsley, samuel.holland, linux-pwm,
linux-riscv
From: Nylon Chen <nylon.chen@sifive.com>
[ Upstream commit 7dbc4432ea6bf9d709391eb57f1e9fb44e99845a ]
The `frac` variable represents the pulse inactive time, and the result
of this algorithm is the pulse active time. Therefore, we must reverse
the result.
Although the SiFive Reference Manual states "pwms >= pwmcmpX -> HIGH",
the hardware behavior is inverted due to a fixed XNOR with 0. As a result,
the pwmcmp register actually defines the low (inactive) portion of the pulse.
The reference is SiFive FU740-C000 Manual[0]
Link: https://sifive.cdn.prismic.io/sifive/1a82e600-1f93-4f41-b2d8-86ed8b16acba_fu740-c000-manual-v1p6.pdf [0]
Co-developed-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Zong Li <zong.li@sifive.com>
Co-developed-by: Vincent Chen <vincent.chen@sifive.com>
Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
Signed-off-by: Nylon Chen <nylon.chen@sifive.com>
Link: https://lore.kernel.org/r/20250529035341.51736-3-nylon.chen@sifive.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit should be backported to stable kernel trees. Here's my
extensive analysis:
## Critical Bug Fix Analysis
1. **The commit fixes a significant functional bug** - The PWM algorithm
was fundamentally broken:
- The `frac` variable was incorrectly used (lines 158-161 in
original, now 168-171)
- The driver was writing the duty cycle value directly to PWMCMP
register (line 193), but the hardware actually expects the
**inactive** (low) time
- This results in inverted PWM output behavior where users get the
opposite duty cycle from what they request
2. **Hardware behavior discrepancy** - The commit reveals and fixes a
critical mismatch between documentation and actual hardware:
- The documentation states "pwms >= pwmcmpX -> HIGH"
- But the hardware has a hard-tied XNOR with 0 that inverts this
behavior
- The driver now correctly compensates for this hardware quirk
3. **User-visible impact**:
- **In `pwm_sifive_get_state()`**: The driver now correctly inverts
the value read from hardware (lines 115->122-126)
- **In `pwm_sifive_apply()`**: The driver now inverts the duty cycle
before writing to hardware (lines 162->171)
- **Polarity change**: Changed from `PWM_POLARITY_INVERSED` to
`PWM_POLARITY_NORMAL` (lines 126->137, 142->152)
- **Documentation fix**: Updated comment from "cannot generate 100%
duty" to "cannot generate 0% duty" (lines 11->27, 160->170)
4. **The fix is relatively small and contained**:
- Changes are isolated to the PWM algorithm logic
- No architectural changes or new features
- Simple mathematical inversion: `duty = (1U << PWM_SIFIVE_CMPWIDTH)
- 1 - inactive`
5. **No risky side effects**:
- The change is straightforward and mathematically correct
- Doesn't affect other subsystems
- Maintains the same register interface
6. **Affects all SiFive PWM users**:
- Any system using SiFive FU540 or FU740 SoCs would have incorrect
PWM output
- This includes various RISC-V development boards and embedded
systems
- Users would get inverted duty cycles, potentially breaking motor
controls, LED dimming, etc.
7. **Clear documentation reference**:
- The commit references the official SiFive FU740-C000 Manual
- Provides clear explanation of the hardware behavior mismatch
The bug causes PWM outputs to be inverted from user expectations, which
is a significant functional issue that would affect any system relying
on proper PWM behavior for motor control, LED dimming, or other PWM-
dependent functionality. The fix is clean, minimal, and addresses a
clear hardware/software mismatch that exists in production systems.
drivers/pwm/pwm-sifive.c | 39 +++++++++++++++++++++++++++++++--------
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index eabddb7c7820..2e6253c671df 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -4,11 +4,28 @@
* For SiFive's PWM IP block documentation please refer Chapter 14 of
* Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf
*
+ * PWM output inversion: According to the SiFive Reference manual
+ * the output of each comparator is high whenever the value of pwms is
+ * greater than or equal to the corresponding pwmcmpX[Reference Manual].
+ *
+ * Figure 29 in the same manual shows that the pwmcmpXcenter bit is
+ * hard-tied to 0 (XNOR), which effectively inverts the comparison so that
+ * the output goes HIGH when `pwms < pwmcmpX`.
+ *
+ * In other words, each pwmcmp register actually defines the **inactive**
+ * (low) period of the pulse, not the active time exactly opposite to what
+ * the documentation text implies.
+ *
+ * To compensate, this driver always **inverts** the duty value when reading
+ * or writing pwmcmp registers , so that users interact with a conventional
+ * **active-high** PWM interface.
+ *
+ *
* Limitations:
* - When changing both duty cycle and period, we cannot prevent in
* software that the output might produce a period with mixed
* settings (new period length and old duty cycle).
- * - The hardware cannot generate a 100% duty cycle.
+ * - The hardware cannot generate a 0% duty cycle.
* - The hardware generates only inverted output.
*/
#include <linux/clk.h>
@@ -110,9 +127,14 @@ static int pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state)
{
struct pwm_sifive_ddata *ddata = pwm_sifive_chip_to_ddata(chip);
- u32 duty, val;
+ u32 duty, val, inactive;
- duty = readl(ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
+ inactive = readl(ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
+ /*
+ * PWM hardware uses 'inactive' counts in pwmcmp, so invert to get actual duty.
+ * Here, 'inactive' is the low time and we compute duty as max_count - inactive.
+ */
+ duty = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - inactive;
state->enabled = duty > 0;
@@ -123,7 +145,7 @@ static int pwm_sifive_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
state->period = ddata->real_period;
state->duty_cycle =
(u64)duty * ddata->real_period >> PWM_SIFIVE_CMPWIDTH;
- state->polarity = PWM_POLARITY_INVERSED;
+ state->polarity = PWM_POLARITY_NORMAL;
return 0;
}
@@ -137,9 +159,9 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
unsigned long long num;
bool enabled;
int ret = 0;
- u32 frac;
+ u32 frac, inactive;
- if (state->polarity != PWM_POLARITY_INVERSED)
+ if (state->polarity != PWM_POLARITY_NORMAL)
return -EINVAL;
cur_state = pwm->state;
@@ -157,8 +179,9 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
*/
num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
- /* The hardware cannot generate a 100% duty cycle */
+ /* The hardware cannot generate a 0% duty cycle */
frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
+ inactive = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
mutex_lock(&ddata->lock);
if (state->period != ddata->approx_period) {
@@ -190,7 +213,7 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
}
}
- writel(frac, ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
+ writel(inactive, ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
if (!state->enabled)
clk_disable(ddata->clk);
--
2.39.5
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 4+ messages in thread