From: Ondrej Ille <ondrej.ille(a)gmail.com>
The Secondary Sample Point Source field has been
set to an incorrect value by some mistake in the
past
0b01 - SSP_SRC_NO_SSP - SSP is not used.
for data bitrates above 1 MBit/s. The correct/default
value already used for lower bitrates is
0b00 - SSP_SRC_MEAS_N_OFFSET - SSP position = TRV_DELAY
(Measured Transmitter delay) + SSP_OFFSET.
The related configuration register structure is described
in section 3.1.46 SSP_CFG of the CTU CAN FD
IP CORE Datasheet.
The analysis leading to the proper configuration
is described in section 2.8.3 Secondary sampling point
of the datasheet.
The change has been tested on AMD/Xilinx Zynq
with the next CTU CN FD IP core versions:
- 2.6 aka master in the "integration with Zynq-7000 system" test
6.12.43-rt12+ #1 SMP PREEMPT_RT kernel with CTU CAN FD git
driver (change already included in the driver repo)
- older 2.5 snapshot with mainline kernels with this patch
applied locally in the multiple CAN latency tester nightly runs
6.18.0-rc4-rt3-dut #1 SMP PREEMPT_RT
6.19.0-rc3-dut
The logs, the datasheet and sources are available at
https://canbus.pages.fel.cvut.cz/
Signed-off-by: Ondrej Ille <ondrej.ille(a)gmail.com>
Signed-off-by: Pavel Pisa <pisa(a)fel.cvut.cz>
Link: https://patch.msgid.link/20260105111620.16580-1-pisa@fel.cvut.cz
Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.")
Cc: stable(a)vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
---
drivers/net/can/ctucanfd/ctucanfd_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/ctucanfd/ctucanfd_base.c b/drivers/net/can/ctucanfd/ctucanfd_base.c
index 1e6b9e3dc2fe..0ea1ff28dfce 100644
--- a/drivers/net/can/ctucanfd/ctucanfd_base.c
+++ b/drivers/net/can/ctucanfd/ctucanfd_base.c
@@ -310,7 +310,7 @@ static int ctucan_set_secondary_sample_point(struct net_device *ndev)
}
ssp_cfg = FIELD_PREP(REG_TRV_DELAY_SSP_OFFSET, ssp_offset);
- ssp_cfg |= FIELD_PREP(REG_TRV_DELAY_SSP_SRC, 0x1);
+ ssp_cfg |= FIELD_PREP(REG_TRV_DELAY_SSP_SRC, 0x0);
}
ctucan_write32(priv, CTUCANFD_TRV_DELAY, ssp_cfg);
--
2.51.0
Hello,
New build issue found on stable-rc/linux-5.10.y:
---
use of undeclared identifier '__free_device_node'; did you mean '__free_device_del'? in drivers/soc/imx/gpc.o (drivers/soc/imx/gpc.c) [logspec:kbuild,kbuild.compiler.error]
---
- dashboard: https://d.kernelci.org/i/maestro:998dfbb422b4d80c9d4f6176e9c36655d3481e74
- giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
- commit HEAD: c4fc4bf97778e67ad01a3ca95dd8fbb05f226590
Please include the KernelCI tag when submitting a fix:
Reported-by: kernelci.org bot <bot(a)kernelci.org>
Log excerpt:
=====================================================
drivers/soc/imx/gpc.c:408:31: error: use of undeclared identifier '__free_device_node'; did you mean '__free_device_del'?
408 | struct device_node *pgc_node __free(device_node)
| ^~~~~~~~~~~~~~~~~~~
./include/linux/cleanup.h:40:33: note: expanded from macro '__free'
40 | #define __free(_name) __cleanup(__free_##_name)
| ^~~~~~~~~~~~~~
<scratch space>:216:1: note: expanded from here
216 | __free_device_node
| ^~~~~~~~~~~~~~~~~~
./include/linux/device.h:834:1: note: '__free_device_del' declared here
834 | DEFINE_FREE(device_del, struct device *, if (_T) device_del(_T))
| ^
./include/linux/cleanup.h:38:21: note: expanded from macro 'DEFINE_FREE'
38 | static inline void __free_##_name(void *p) { _type _T = *(_type *)p; _free; }
| ^
<scratch space>:165:1: note: expanded from here
165 | __free_device_del
| ^
1 error generated.
=====================================================
# Builds where the incident occurred:
## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm):
- compiler: clang-21
- config: https://files.kernelci.org/kbuild-clang-21-arm-allmodconfig-6960eee4cbfd84c…
- dashboard: https://d.kernelci.org/build/maestro:6960eee4cbfd84c3cde53db8
## multi_v7_defconfig on (arm):
- compiler: clang-21
- config: https://files.kernelci.org/kbuild-clang-21-arm-6960eee4cbfd84c3cde53db5/.co…
- dashboard: https://d.kernelci.org/build/maestro:6960eee4cbfd84c3cde53db5
#kernelci issue maestro:998dfbb422b4d80c9d4f6176e9c36655d3481e74
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci(a)lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
Hello,
New build issue found on stable-rc/linux-5.15.y:
---
implicit declaration of function '__access_ok' [-Werror,-Wimplicit-function-declaration] in mm/maccess.o (mm/maccess.c) [logspec:kbuild,kbuild.compiler.error]
---
- dashboard: https://d.kernelci.org/i/maestro:87a3df1c8cb729c6fac33d91be47dcd67f9ee3ca
- giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
- commit HEAD: 0d9534c7d771ce08f816b189a8634517e0ccdb07
Please include the KernelCI tag when submitting a fix:
Reported-by: kernelci.org bot <bot(a)kernelci.org>
Log excerpt:
=====================================================
mm/maccess.c:227:7: error: implicit declaration of function '__access_ok' [-Werror,-Wimplicit-function-declaration]
227 | if (!__access_ok(src, size))
| ^
1 error generated.
=====================================================
# Builds where the incident occurred:
## defconfig+allmodconfig on (arm64):
- compiler: clang-21
- config: https://files.kernelci.org/kbuild-clang-21-arm64-allmodconfig-6960ef5ecbfd8…
- dashboard: https://d.kernelci.org/build/maestro:6960ef5ecbfd84c3cde53e57
#kernelci issue maestro:87a3df1c8cb729c6fac33d91be47dcd67f9ee3ca
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci(a)lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
Do not crash when a report has no fields.
Fake USB gadgets can send their own HID report descriptors and can define report
structures without valid fields. This can be used to crash the kernel over USB.
Cc: stable(a)vger.kernel.org
Signed-off-by: Günther Noack <gnoack(a)google.com>
---
drivers/hid/hid-logitech-hidpp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 9ced0e4d46ae..919ba9f50292 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4316,6 +4316,9 @@ static int hidpp_get_report_length(struct hid_device *hdev, int id)
if (!report)
return 0;
+ if (!report->maxfield)
+ return 0;
+
return report->field[0]->report_count + 1;
}
--
2.52.0.457.g6b5491de43-goog
The vdd_mpu regulator maximum voltage was previously limited to 1.2985V,
which prevented the CPU from reaching the 1GHz operating point. This
limitation was put in place because voltage changes were not working
correctly, causing the board to stall when attempting higher frequencies.
Increase the maximum voltage to 1.3515V to allow the full 1GHz OPP to be
used.
Add a TPS65219 PMIC driver fixes that properly implement the LOCK register
handling, to make voltage transitions work reliably.
Changes in v5:
- Add a error message.
- Link to v4: https://lore.kernel.org/r/20251112-fix_tps65219-v4-0-696a0f55d5d8@bootlin.c…
Changes in v4:
- Move the registers unlock in the probe instead of a custom regmap write
operation.
- Link to v3: https://lore.kernel.org/r/20251112-fix_tps65219-v3-0-e49bab4c01ce@bootlin.c…
Changes in v3:
- Remove an unused variable
- Link to v2: https://lore.kernel.org/r/20251106-fix_tps65219-v2-0-a7d608c4272f@bootlin.c…
Changes in v2:
- Setup a custom regmap_bus only for the TPS65214 instead of checking
the chip_id every time reg_write is called.
- Add the am335x-bonegreen-eco devicetree change in the same patch
series.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent(a)bootlin.com>
---
Kory Maincent (TI.com) (2):
mfd: tps65219: Implement LOCK register handling for TPS65214
ARM: dts: am335x-bonegreen-eco: Enable 1GHz OPP by increasing vdd_mpu voltage
arch/arm/boot/dts/ti/omap/am335x-bonegreen-eco.dts | 2 +-
drivers/mfd/tps65219.c | 9 +++++++++
include/linux/mfd/tps65219.h | 2 ++
3 files changed, 12 insertions(+), 1 deletion(-)
---
base-commit: 2bb202416d33347102b12bbd1db4837fb6685617
change-id: 20251106-fix_tps65219-dd62141d22cf
Best regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com