William writes: Counter fixes for 7.2 A fix for microchip-tcb-capture to read the devicetree "reg" cell into a u32 variable to match the expected data type. * tag 'counter-fixes-for-7.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter: counter: microchip-tcb-capture: Fix DT channel validation
mchp_tc_probe() reads the devicetree "reg" cell - a u32, per the API
contract of of_property_read_u32_index() - into a signed int, so the
bounds check "channel > 2" fails to reject cell values at or above
0x80000000: reinterpreted as a negative int, they compare below 2 and
pass validation.
A malformed devicetree can therefore drive a negative channel into the
ATMEL_TC_REG() offset arithmetic, making the driver access syscon
regmap offsets outside the TC block's register window, and into the
"t%d_clk" clock-name formatting, where it truncates clk_name (sized
for "t0_clk".."t2_clk").
Declare channel as u32, matching the API contract; the unsigned
comparison then rejects everything except channels 0..2. Adjust the
format specifier to %u accordingly, which also resolves the W=1
warning that exposed the gap:
microchip-tcb-capture.c:520:56: warning: '%d' directive output may
be truncated writing between 1 and 11 bytes into a region of size
6 [-Wformat-truncation=]
note: directive argument in the range [-2147483648, 2]
No behavior change for well-formed devicetrees: channels 0..2 take
identical paths before and after.
Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
Assisted-by: Claude:claude-fable-5 [gcc W=1]
Signed-off-by: Babanpreet Singh <bbnpreetsingh@gmail.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Link: https://lore.kernel.org/r/20260714042910.7-1-bbnpreetsingh@gmail.com
Signed-off-by: William Breathitt Gray <wbg@kernel.org>
Replace the #include of <linux/mod_devicetable.h> by the more specific <linux/device-id/*.h> where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
William writes: Counter updates for 7.2 Manual mutex lock logic is replaced by lock guards in intel-qep. Additionally, devm_mutex_init() is now used in ftm-quaddec, interrupt-cnt, and intel-qep to handle mutex cleanup automatically. * tag 'counter-updates-for-7.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter: counter: intel-qep: Use devm_mutex_init() counter: interrupt-cnt: use devm_mutex_init() counter: ftm-quaddec: use devm_mutex_init() counter: intel-qep: Replace manual mutex logic with lock guards
intel_qep_probe() calls mutex_init() but lacks the pairing mutex_destroy() calls. Convert to devm_mutex_init() which handles cleanup automatically. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Reviewed-by: Stepan Ionichev <sozdayvek@gmail.com> Link: https://lore.kernel.org/r/20260520111813.3934-1-ilpo.jarvinen@linux.intel.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
interrupt_cnt_probe() calls mutex_init() but neither this driver nor the counter core issues a matching mutex_destroy() on unbind, so the lock debug state is leaked. Switch to devm_mutex_init() so the mutex is torn down in the same devm scope it was set up in. Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Link: https://lore.kernel.org/r/20260523184418.7586-1-sozdayvek@gmail.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
ftm_quaddec_probe() calls mutex_init() but neither the cleanup action nor a remove callback issues a matching mutex_destroy(), so the lock debug state is leaked on driver unbind. Switch to devm_mutex_init() so the mutex is torn down in the same devm scope it was set up in. Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com> Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com> Link: https://lore.kernel.org/r/20260523184351.7567-1-sozdayvek@gmail.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
Use guard() for handling mutex lock instead of locking and unlocking mutex explicitly. This improves readability by eliminating the need for gotos and by clearly indicating mutex will be locked only when execution is in guard scope. Signed-off-by: Joao Paulo Menezes Linaris <jplinaris@usp.br> Co-developed-by: Guilherme Dias <guilhermeabreu200105@usp.br> Signed-off-by: Guilherme Dias <guilhermeabreu200105@usp.br> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20260512173058.14858-1-jplinaris@usp.br Signed-off-by: William Breathitt Gray <wbg@kernel.org>
After device_initialize(), the lifetime of the embedded struct device
is expected to be managed through the device core reference counting.
In counter_alloc(), if dev_set_name() fails after device_initialize(),
the error path removes the chrdev, frees the ID, and frees the backing
allocation directly instead of releasing the device reference with
put_device(). This bypasses the normal device lifetime rules and may
leave the reference count of the embedded struct device unbalanced,
resulting in a refcount leak.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fix this by using put_device() in the dev_set_name() failure path and
let counter_device_release() handle the final cleanup.
Fixes: 4da08477ea1f ("counter: Set counter device name")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://lore.kernel.org/r/20260413134604.2861772-1-lgs201920130244@gmail.com
Signed-off-by: William Breathitt Gray <wbg@kernel.org>
We need the char/misc/iio/comedi fixes in here as well for testing Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>