January 2025 - Linux-stable-mirror

[PATCH V2] cpufreq: s3c64xx: Fix compilation warning

by Viresh Kumar

The driver generates following warning when regulator support isn't enabled in the kernel. Fix it. drivers/cpufreq/s3c64xx-cpufreq.c: In function 's3c64xx_cpufreq_set_target': >> drivers/cpufreq/s3c64xx-cpufreq.c:55:22: warning: variable 'old_freq' set but not used [-Wunused-but-set-variable] 55 | unsigned int old_freq, new_freq; | ^~~~~~~~ >> drivers/cpufreq/s3c64xx-cpufreq.c:54:30: warning: variable 'dvfs' set but not used [-Wunused-but-set-variable] 54 | struct s3c64xx_dvfs *dvfs; | ^~~~ Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501191803.CtfT7b2o-lkp@intel.com/ Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- V2: Move s3c64xx_dvfs_table too inside ifdef. drivers/cpufreq/s3c64xx-cpufreq.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c index c6bdfc308e99..9cef71528076 100644 --- a/drivers/cpufreq/s3c64xx-cpufreq.c +++ b/drivers/cpufreq/s3c64xx-cpufreq.c @@ -24,6 +24,7 @@ struct s3c64xx_dvfs { unsigned int vddarm_max; }; +#ifdef CONFIG_REGULATOR static struct s3c64xx_dvfs s3c64xx_dvfs_table[] = { [0] = { 1000000, 1150000 }, [1] = { 1050000, 1150000 }, @@ -31,6 +32,7 @@ static struct s3c64xx_dvfs s3c64xx_dvfs_table[] = { [3] = { 1200000, 1350000 }, [4] = { 1300000, 1350000 }, }; +#endif static struct cpufreq_frequency_table s3c64xx_freq_table[] = { { 0, 0, 66000 }, @@ -51,15 +53,16 @@ static struct cpufreq_frequency_table s3c64xx_freq_table[] = { static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index) { - struct s3c64xx_dvfs *dvfs; - unsigned int old_freq, new_freq; + unsigned int new_freq = s3c64xx_freq_table[index].frequency; int ret; +#ifdef CONFIG_REGULATOR + struct s3c64xx_dvfs *dvfs; + unsigned int old_freq; + old_freq = clk_get_rate(policy->clk) / 1000; - new_freq = s3c64xx_freq_table[index].frequency; dvfs = &s3c64xx_dvfs_table[s3c64xx_freq_table[index].driver_data]; -#ifdef CONFIG_REGULATOR if (vddarm && new_freq > old_freq) { ret = regulator_set_voltage(vddarm, dvfs->vddarm_min, -- 2.31.1.272.g89b43f80a514

9 months, 1 week

2
2
0 0

[PATCH 6.1.y] ext4: filesystems without casefold feature cannot be mounted with siphash

by Rajani kantha

From: Lizhi Xu <lizhi.xu(a)windriver.com> [ upstream commit 985b67cd86392310d9e9326de941c22fc9340eec ] When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting. Reported-by: syzbot+340581ba9dceb7e06fb3(a)syzkaller.appspotmail.com Signed-off-by: Lizhi Xu <lizhi.xu(a)windriver.com> Link: https://patch.msgid.link/20240605012335.44086-1-lizhi.xu@windriver.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Rajani Kantha <rajanikantha(a)engineer.com> --- fs/ext4/super.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 0b2591c07166..2e9c14e2370f 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3546,6 +3546,13 @@ int ext4_feature_set_ok(struct super_block *sb, int readonly) return 0; } #endif + if (EXT4_SB(sb)->s_es->s_def_hash_version == DX_HASH_SIPHASH && + !ext4_has_feature_casefold(sb)) { + ext4_msg(sb, KERN_ERR, + "Filesystem without casefold feature cannot be " + "mounted with siphash"); + return 0; + } if (readonly) return 1; -- 2.35.3

9 months, 1 week

1
0
0 0

[PATCH v2] atm/fore200e: Fix possible data race in fore200e_open()

by Gui-Dong Han

Protect access to fore200e->available_cell_rate with rate_mtx lock to prevent potential data race. In this case, since the update depends on a prior read, a data race could lead to a wrong fore200e.available_cell_rate value. The field fore200e.available_cell_rate is generally protected by the lock fore200e.rate_mtx when accessed. In all other read and write cases, this field is consistently protected by the lock, except for this case and during initialization. This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <2045gemini(a)gmail.com> --- v2: * Added a description of the data race hazard in fore200e_open(), as suggested by Jakub Kicinski and Simon Horman. --- drivers/atm/fore200e.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c index 4fea1149e003..f62e38571440 100644 --- a/drivers/atm/fore200e.c +++ b/drivers/atm/fore200e.c @@ -1374,7 +1374,9 @@ fore200e_open(struct atm_vcc *vcc) vcc->dev_data = NULL; + mutex_lock(&fore200e->rate_mtx); fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; + mutex_unlock(&fore200e->rate_mtx); kfree(fore200e_vcc); return -EINVAL; -- 2.25.1

9 months, 1 week

3
3
0 0

urgent request for a quote

by manuel.rodrigues＠ene-kolla.pt

Hello, My name is wioleta. we would like to know if you export to Poland, as We have active projects that require most products as seen on your website. If yes, please kindly keep us informed upon your feedback so we can send our preferred listing for quote. For further information or have any questions, please do not hesitate to write us. Sten Arnlund Purchase Manager wioleta.raimer(a)invpolamd.com a: Vedwalterdige by 2, Holmerskulle, 432 68 Poland.

9 months, 1 week

1
0
0 0

[PATCH] posix-clock: Explicitly handle compat ioctls

by Thomas Weißschuh

Pointer arguments passed to ioctls need to pass through compat_ptr() to work correctly on s390; as explained in Documentation/driver-api/ioctl.rst. Plumb the compat_ioctl callback through 'struct posix_clock_operations' and handle the different ioctls cmds in the new ptp_compat_ioctl(). Using compat_ptr_ioctl is not possible. For the commands PTP_ENABLE_PPS/PTP_ENABLE_PPS2 on s390 it would corrupt the argument 0x80000000, aka BIT(31) to zero. Fixes: 0606f422b453 ("posix clocks: Introduce dynamic clocks") Fixes: d94ba80ebbea ("ptp: Added a brand new class driver for ptp clocks.") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- drivers/ptp/ptp_chardev.c | 18 ++++++++++++++++++ drivers/ptp/ptp_clock.c | 1 + drivers/ptp/ptp_private.h | 7 +++++++ include/linux/posix-clock.h | 3 +++ kernel/time/posix-clock.c | 4 ++-- 5 files changed, 31 insertions(+), 2 deletions(-) diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c index ea96a14d72d141a4b255563b66bac8ed568b45e9..704af620c1173c12ee26b3b6c7982693e3c4c21f 100644 --- a/drivers/ptp/ptp_chardev.c +++ b/drivers/ptp/ptp_chardev.c @@ -4,6 +4,7 @@ * * Copyright (C) 2010 OMICRON electronics GmbH */ +#include <linux/compat.h> #include <linux/module.h> #include <linux/posix-clock.h> #include <linux/poll.h> @@ -507,6 +508,23 @@ long ptp_ioctl(struct posix_clock_context *pccontext, unsigned int cmd, return err; } +#ifdef CONFIG_COMPAT +long ptp_compat_ioctl(struct posix_clock_context *pccontext, unsigned int cmd, + unsigned long arg) +{ + switch (cmd) { + case PTP_ENABLE_PPS: + case PTP_ENABLE_PPS2: + /* These take in scalar arg, do not convert */ + break; + default: + arg = (unsigned long)compat_ptr(arg); + } + + return ptp_ioctl(pccontext, cmd, arg); +} +#endif + __poll_t ptp_poll(struct posix_clock_context *pccontext, struct file *fp, poll_table *wait) { diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c index 77a36e7bddd54e8f45eab317e687f033f57cc5bc..dec84b81cedfd13bcf8c97be6c3c27d73cd671f6 100644 --- a/drivers/ptp/ptp_clock.c +++ b/drivers/ptp/ptp_clock.c @@ -180,6 +180,7 @@ static struct posix_clock_operations ptp_clock_ops = { .clock_getres = ptp_clock_getres, .clock_settime = ptp_clock_settime, .ioctl = ptp_ioctl, + .compat_ioctl = ptp_compat_ioctl, .open = ptp_open, .release = ptp_release, .poll = ptp_poll, diff --git a/drivers/ptp/ptp_private.h b/drivers/ptp/ptp_private.h index 18934e28469ee6e3bf9c9e6d1a1adb82808d88e6..13999a7af47a7b67ae8dc549351fbafef2ae402f 100644 --- a/drivers/ptp/ptp_private.h +++ b/drivers/ptp/ptp_private.h @@ -133,6 +133,13 @@ int ptp_set_pinfunc(struct ptp_clock *ptp, unsigned int pin, long ptp_ioctl(struct posix_clock_context *pccontext, unsigned int cmd, unsigned long arg); +#ifdef CONFIG_COMPAT +long ptp_compat_ioctl(struct posix_clock_context *pccontext, unsigned int cmd, + unsigned long arg); +#else +#define ptp_compat_ioctl NULL +#endif + int ptp_open(struct posix_clock_context *pccontext, fmode_t fmode); int ptp_release(struct posix_clock_context *pccontext); diff --git a/include/linux/posix-clock.h b/include/linux/posix-clock.h index ef8619f489203eeb369ae580fc4d4b2439c94ae9..8bdc7aec5f7979c42752a233077620818d15acdd 100644 --- a/include/linux/posix-clock.h +++ b/include/linux/posix-clock.h @@ -54,6 +54,9 @@ struct posix_clock_operations { long (*ioctl)(struct posix_clock_context *pccontext, unsigned int cmd, unsigned long arg); + long (*compat_ioctl)(struct posix_clock_context *pccontext, unsigned int cmd, + unsigned long arg); + int (*open)(struct posix_clock_context *pccontext, fmode_t f_mode); __poll_t (*poll)(struct posix_clock_context *pccontext, struct file *file, diff --git a/kernel/time/posix-clock.c b/kernel/time/posix-clock.c index 1af0bb2cc45c0aab843f77eb156992de469c8fb9..63184d92ef139c3fb9254745619ebca120fecce6 100644 --- a/kernel/time/posix-clock.c +++ b/kernel/time/posix-clock.c @@ -101,8 +101,8 @@ static long posix_clock_compat_ioctl(struct file *fp, if (!clk) return -ENODEV; - if (clk->ops.ioctl) - err = clk->ops.ioctl(pccontext, cmd, arg); + if (clk->ops.compat_ioctl) + err = clk->ops.compat_ioctl(pccontext, cmd, arg); put_posix_clock(clk); --- base-commit: 0bc21e701a6ffacfdde7f04f87d664d82e8a13bf change-id: 20250103-posix-clock-compat_ioctl-96fbac549146 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

9 months, 1 week

5
9
0 0

[PATCH 6.1.y] ssb: Fix potential NULL pointer dereference in ssb_device_uevent()

by Imkanmod Khan

From: Rand Deeb <rand.sec96(a)gmail.com> [ Upstream commit 789c17185fb0f39560496c2beab9b57ce1d0cbe7 ] The ssb_device_uevent() function first attempts to convert the 'dev' pointer to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before performing the NULL check, potentially leading to a NULL pointer dereference if 'dev' is NULL. To fix this issue, move the NULL check before dereferencing the 'dev' pointer, ensuring that the pointer is valid before attempting to use it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rand Deeb <rand.sec96(a)gmail.com> Signed-off-by: Kalle Valo <kvalo(a)kernel.org> Link: https://msgid.link/20240306123028.164155-1-rand.sec96@gmail.com Signed-off-by: Imkanmod Khan <imkanmodkhan(a)gmail.com> --- drivers/ssb/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c index d52e91258e98..aae50a5dfb57 100644 --- a/drivers/ssb/main.c +++ b/drivers/ssb/main.c @@ -341,11 +341,13 @@ static int ssb_bus_match(struct device *dev, struct device_driver *drv) static int ssb_device_uevent(struct device *dev, struct kobj_uevent_env *env) { - struct ssb_device *ssb_dev = dev_to_ssb_dev(dev); + struct ssb_device *ssb_dev; if (!dev) return -ENODEV; + ssb_dev = dev_to_ssb_dev(dev); + return add_uevent_var(env, "MODALIAS=ssb:v%04Xid%04Xrev%02X", ssb_dev->id.vendor, ssb_dev->id.coreid, -- 2.25.1

9 months, 1 week

2
1
0 0

[PATCH 5.15.y] platform/chrome: cros_ec_typec: Check for EC driver

by Laura Nao

From: Akihiko Odaki <akihiko.odaki(a)gmail.com> [ upstream commit 7464ff8bf2d762251b9537863db0e1caf9b0e402 ] The EC driver may not be initialized when cros_typec_probe is called, particulary when CONFIG_CROS_EC_CHARDEV=m. Signed-off-by: Akihiko Odaki <akihiko.odaki(a)gmail.com> Reviewed-by: Guenter Roeck <groeck(a)chromium.org> Link: https://lore.kernel.org/r/20220404041101.6276-1-akihiko.odaki@gmail.com Signed-off-by: Prashant Malani <pmalani(a)chromium.org> Signed-off-by: Laura Nao <laura.nao(a)collabora.com> --- This solves the kernel NULL pointer dereference exception detected by KernelCI on many x86_64 Chromebooks - see e.g.: https://staging.dashboard.kernelci.org:9000/test/maestro%3A6790c13e09f33884… drivers/platform/chrome/cros_ec_typec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c index 2b8bef0d7ee5..c065963b9a42 100644 --- a/drivers/platform/chrome/cros_ec_typec.c +++ b/drivers/platform/chrome/cros_ec_typec.c @@ -1123,6 +1123,9 @@ static int cros_typec_probe(struct platform_device *pdev) } ec_dev = dev_get_drvdata(&typec->ec->ec->dev); + if (!ec_dev) + return -EPROBE_DEFER; + typec->typec_cmd_supported = !!cros_ec_check_features(ec_dev, EC_FEATURE_TYPEC_CMD); typec->needs_mux_ack = !!cros_ec_check_features(ec_dev, EC_FEATURE_TYPEC_MUX_REQUIRE_AP_ACK); -- 2.30.2

9 months, 1 week

2
1
0 0

[PATCH 1/3] drm/xe: Fix and re-enable xe_print_blob_ascii85()

by José Roberto de Souza

From: Lucas De Marchi <lucas.demarchi(a)intel.com> Commit 70fb86a85dc9 ("drm/xe: Revert some changes that break a mesa debug tool") partially reverted some changes to workaround breakage caused to mesa tools. However, in doing so it also broke fetching the GuC log via debugfs since xe_print_blob_ascii85() simply bails out. The fix is to avoid the extra newlines: the devcoredump interface is line-oriented and adding random newlines in the middle breaks it. If a tool is able to parse it by looking at the data and checking for chars that are out of the ascii85 space, it can still do so. A format change that breaks the line-oriented output on devcoredump however needs better coordination with existing tools. Reviewed-by: José Roberto de Souza <jose.souza(a)intel.com> Cc: John Harrison <John.C.Harrison(a)Intel.com> Cc: Julia Filipchuk <julia.filipchuk(a)intel.com> Cc: José Roberto de Souza <jose.souza(a)intel.com> Cc: stable(a)vger.kernel.org Fixes: 70fb86a85dc9 ("drm/xe: Revert some changes that break a mesa debug tool") Fixes: ec1455ce7e35 ("drm/xe/devcoredump: Add ASCII85 dump helper function") Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- drivers/gpu/drm/xe/xe_devcoredump.c | 30 +++++++++-------------------- drivers/gpu/drm/xe/xe_devcoredump.h | 2 +- drivers/gpu/drm/xe/xe_guc_ct.c | 3 ++- drivers/gpu/drm/xe/xe_guc_log.c | 4 +++- 4 files changed, 15 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c index 81dc7795c0651..1c86e6456d60f 100644 --- a/drivers/gpu/drm/xe/xe_devcoredump.c +++ b/drivers/gpu/drm/xe/xe_devcoredump.c @@ -395,42 +395,30 @@ int xe_devcoredump_init(struct xe_device *xe) /** * xe_print_blob_ascii85 - print a BLOB to some useful location in ASCII85 * - * The output is split to multiple lines because some print targets, e.g. dmesg - * cannot handle arbitrarily long lines. Note also that printing to dmesg in - * piece-meal fashion is not possible, each separate call to drm_puts() has a - * line-feed automatically added! Therefore, the entire output line must be - * constructed in a local buffer first, then printed in one atomic output call. + * The output is split to multiple print calls because some print targets, e.g. + * dmesg cannot handle arbitrarily long lines. These targets may add newline + * between calls. * * There is also a scheduler yield call to prevent the 'task has been stuck for * 120s' kernel hang check feature from firing when printing to a slow target * such as dmesg over a serial port. * - * TODO: Add compression prior to the ASCII85 encoding to shrink huge buffers down. - * * @p: the printer object to output to * @prefix: optional prefix to add to output string * @blob: the Binary Large OBject to dump out * @offset: offset in bytes to skip from the front of the BLOB, must be a multiple of sizeof(u32) * @size: the size in bytes of the BLOB, must be a multiple of sizeof(u32) */ -void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, +void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, char suffix, const void *blob, size_t offset, size_t size) { const u32 *blob32 = (const u32 *)blob; char buff[ASCII85_BUFSZ], *line_buff; size_t line_pos = 0; - /* - * Splitting blobs across multiple lines is not compatible with the mesa - * debug decoder tool. Note that even dropping the explicit '\n' below - * doesn't help because the GuC log is so big some underlying implementation - * still splits the lines at 512K characters. So just bail completely for - * the moment. - */ - return; - #define DMESG_MAX_LINE_LEN 800 -#define MIN_SPACE (ASCII85_BUFSZ + 2) /* 85 + "\n\0" */ + /* Always leave space for the suffix char and the \0 */ +#define MIN_SPACE (ASCII85_BUFSZ + 2) /* 85 + "<suffix>\0" */ if (size & 3) drm_printf(p, "Size not word aligned: %zu", size); @@ -462,7 +450,6 @@ void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, line_pos += strlen(line_buff + line_pos); if ((line_pos + MIN_SPACE) >= DMESG_MAX_LINE_LEN) { - line_buff[line_pos++] = '\n'; line_buff[line_pos++] = 0; drm_puts(p, line_buff); @@ -474,10 +461,11 @@ void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, } } + if (suffix) + line_buff[line_pos++] = suffix; + if (line_pos) { - line_buff[line_pos++] = '\n'; line_buff[line_pos++] = 0; - drm_puts(p, line_buff); } diff --git a/drivers/gpu/drm/xe/xe_devcoredump.h b/drivers/gpu/drm/xe/xe_devcoredump.h index 6a17e6d601022..5391a80a4d1ba 100644 --- a/drivers/gpu/drm/xe/xe_devcoredump.h +++ b/drivers/gpu/drm/xe/xe_devcoredump.h @@ -29,7 +29,7 @@ static inline int xe_devcoredump_init(struct xe_device *xe) } #endif -void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, +void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, char suffix, const void *blob, size_t offset, size_t size); #endif diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c index 8b65c5e959cc2..50c8076b51585 100644 --- a/drivers/gpu/drm/xe/xe_guc_ct.c +++ b/drivers/gpu/drm/xe/xe_guc_ct.c @@ -1724,7 +1724,8 @@ void xe_guc_ct_snapshot_print(struct xe_guc_ct_snapshot *snapshot, snapshot->g2h_outstanding); if (snapshot->ctb) - xe_print_blob_ascii85(p, "CTB data", snapshot->ctb, 0, snapshot->ctb_size); + xe_print_blob_ascii85(p, "CTB data", '\n', + snapshot->ctb, 0, snapshot->ctb_size); } else { drm_puts(p, "CT disabled\n"); } diff --git a/drivers/gpu/drm/xe/xe_guc_log.c b/drivers/gpu/drm/xe/xe_guc_log.c index 80151ff6a71f8..44482ea919924 100644 --- a/drivers/gpu/drm/xe/xe_guc_log.c +++ b/drivers/gpu/drm/xe/xe_guc_log.c @@ -207,8 +207,10 @@ void xe_guc_log_snapshot_print(struct xe_guc_log_snapshot *snapshot, struct drm_ remain = snapshot->size; for (i = 0; i < snapshot->num_chunks; i++) { size_t size = min(GUC_LOG_CHUNK_SIZE, remain); + const char *prefix = i ? NULL : "Log data"; + char suffix = i == snapshot->num_chunks - 1 ? '\n' : 0; - xe_print_blob_ascii85(p, i ? NULL : "Log data", snapshot->copy[i], 0, size); + xe_print_blob_ascii85(p, prefix, suffix, snapshot->copy[i], 0, size); remain -= size; } } -- 2.48.1

9 months, 1 week

3
2
0 0

[PATCH 2/2] drm/xe: Fix and re-enable xe_print_blob_ascii85()

by Lucas De Marchi

Commit 70fb86a85dc9 ("drm/xe: Revert some changes that break a mesa debug tool") partially reverted some changes to workaround breakage caused to mesa tools. However, in doing so it also broke fetching the GuC log via debugfs since xe_print_blob_ascii85() simply bails out. The fix is to avoid the extra newlines: the devcoredump interface is line-oriented and adding random newlines in the middle breaks it. If a tool is able to parse it by looking at the data and checking for chars that are out of the ascii85 space, it can still do so. A format change that breaks the line-oriented output on devcoredump however needs better coordination with existing tools. Cc: John Harrison <John.C.Harrison(a)Intel.com> Cc: Julia Filipchuk <julia.filipchuk(a)intel.com> Cc: José Roberto de Souza <jose.souza(a)intel.com> Cc: stable(a)vger.kernel.org Fixes: 70fb86a85dc9 ("drm/xe: Revert some changes that break a mesa debug tool") Fixes: ec1455ce7e35 ("drm/xe/devcoredump: Add ASCII85 dump helper function") Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- drivers/gpu/drm/xe/xe_devcoredump.c | 30 +++++++++-------------------- drivers/gpu/drm/xe/xe_devcoredump.h | 2 +- drivers/gpu/drm/xe/xe_guc_ct.c | 3 ++- drivers/gpu/drm/xe/xe_guc_log.c | 4 +++- 4 files changed, 15 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c index a7946a76777e7..d9b71bb690860 100644 --- a/drivers/gpu/drm/xe/xe_devcoredump.c +++ b/drivers/gpu/drm/xe/xe_devcoredump.c @@ -391,42 +391,30 @@ int xe_devcoredump_init(struct xe_device *xe) /** * xe_print_blob_ascii85 - print a BLOB to some useful location in ASCII85 * - * The output is split to multiple lines because some print targets, e.g. dmesg - * cannot handle arbitrarily long lines. Note also that printing to dmesg in - * piece-meal fashion is not possible, each separate call to drm_puts() has a - * line-feed automatically added! Therefore, the entire output line must be - * constructed in a local buffer first, then printed in one atomic output call. + * The output is split to multiple print calls because some print targets, e.g. + * dmesg cannot handle arbitrarily long lines. These targets may add newline + * between calls. * * There is also a scheduler yield call to prevent the 'task has been stuck for * 120s' kernel hang check feature from firing when printing to a slow target * such as dmesg over a serial port. * - * TODO: Add compression prior to the ASCII85 encoding to shrink huge buffers down. - * * @p: the printer object to output to * @prefix: optional prefix to add to output string * @blob: the Binary Large OBject to dump out * @offset: offset in bytes to skip from the front of the BLOB, must be a multiple of sizeof(u32) * @size: the size in bytes of the BLOB, must be a multiple of sizeof(u32) */ -void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, +void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, char suffix, const void *blob, size_t offset, size_t size) { const u32 *blob32 = (const u32 *)blob; char buff[ASCII85_BUFSZ], *line_buff; size_t line_pos = 0; - /* - * Splitting blobs across multiple lines is not compatible with the mesa - * debug decoder tool. Note that even dropping the explicit '\n' below - * doesn't help because the GuC log is so big some underlying implementation - * still splits the lines at 512K characters. So just bail completely for - * the moment. - */ - return; - #define DMESG_MAX_LINE_LEN 800 -#define MIN_SPACE (ASCII85_BUFSZ + 2) /* 85 + "\n\0" */ + /* Always leave space for the suffix char and the \0 */ +#define MIN_SPACE (ASCII85_BUFSZ + 2) /* 85 + "<suffix>\0" */ if (size & 3) drm_printf(p, "Size not word aligned: %zu", size); @@ -458,7 +446,6 @@ void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, line_pos += strlen(line_buff + line_pos); if ((line_pos + MIN_SPACE) >= DMESG_MAX_LINE_LEN) { - line_buff[line_pos++] = '\n'; line_buff[line_pos++] = 0; drm_puts(p, line_buff); @@ -470,10 +457,11 @@ void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, } } + if (suffix) + line_buff[line_pos++] = suffix; + if (line_pos) { - line_buff[line_pos++] = '\n'; line_buff[line_pos++] = 0; - drm_puts(p, line_buff); } diff --git a/drivers/gpu/drm/xe/xe_devcoredump.h b/drivers/gpu/drm/xe/xe_devcoredump.h index 6a17e6d601022..5391a80a4d1ba 100644 --- a/drivers/gpu/drm/xe/xe_devcoredump.h +++ b/drivers/gpu/drm/xe/xe_devcoredump.h @@ -29,7 +29,7 @@ static inline int xe_devcoredump_init(struct xe_device *xe) } #endif -void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, +void xe_print_blob_ascii85(struct drm_printer *p, const char *prefix, char suffix, const void *blob, size_t offset, size_t size); #endif diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c index 8b65c5e959cc2..50c8076b51585 100644 --- a/drivers/gpu/drm/xe/xe_guc_ct.c +++ b/drivers/gpu/drm/xe/xe_guc_ct.c @@ -1724,7 +1724,8 @@ void xe_guc_ct_snapshot_print(struct xe_guc_ct_snapshot *snapshot, snapshot->g2h_outstanding); if (snapshot->ctb) - xe_print_blob_ascii85(p, "CTB data", snapshot->ctb, 0, snapshot->ctb_size); + xe_print_blob_ascii85(p, "CTB data", '\n', + snapshot->ctb, 0, snapshot->ctb_size); } else { drm_puts(p, "CT disabled\n"); } diff --git a/drivers/gpu/drm/xe/xe_guc_log.c b/drivers/gpu/drm/xe/xe_guc_log.c index 80151ff6a71f8..44482ea919924 100644 --- a/drivers/gpu/drm/xe/xe_guc_log.c +++ b/drivers/gpu/drm/xe/xe_guc_log.c @@ -207,8 +207,10 @@ void xe_guc_log_snapshot_print(struct xe_guc_log_snapshot *snapshot, struct drm_ remain = snapshot->size; for (i = 0; i < snapshot->num_chunks; i++) { size_t size = min(GUC_LOG_CHUNK_SIZE, remain); + const char *prefix = i ? NULL : "Log data"; + char suffix = i == snapshot->num_chunks - 1 ? '\n' : 0; - xe_print_blob_ascii85(p, i ? NULL : "Log data", snapshot->copy[i], 0, size); + xe_print_blob_ascii85(p, prefix, suffix, snapshot->copy[i], 0, size); remain -= size; } } -- 2.48.0

9 months, 1 week

3
4
0 0

[PATCH] pwm: Ensure callbacks exist before calling them

by Uwe Kleine-König

If one of the waveform functions is called for a chip that only supports .apply(), we want that an error code is returned and not a NULL pointer exception. Fixes: 6c5126c6406d ("pwm: Provide new consumer API functions for waveforms") Cc: stable(a)vger.kernel.org Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)baylibre.com> --- Hello, assuming nobody spots a problem I will send this patch to Linus next week for inclusion in -rc1. Best regards Uwe drivers/pwm/core.c | 13 +++++++++++-- include/linux/pwm.h | 17 +++++++++++++++++ 2 files changed, 28 insertions(+), 2 deletions(-) diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c index 9c733877e98e..1a36ee3cab91 100644 --- a/drivers/pwm/core.c +++ b/drivers/pwm/core.c @@ -242,6 +242,9 @@ int pwm_round_waveform_might_sleep(struct pwm_device *pwm, struct pwm_waveform * BUG_ON(WFHWSIZE < ops->sizeof_wfhw); + if (!pwmchip_supports_waveform(chip)) + return -EOPNOTSUPP; + if (!pwm_wf_valid(wf)) return -EINVAL; @@ -294,6 +297,9 @@ int pwm_get_waveform_might_sleep(struct pwm_device *pwm, struct pwm_waveform *wf BUG_ON(WFHWSIZE < ops->sizeof_wfhw); + if (!pwmchip_supports_waveform(chip) || !ops->read_waveform) + return -EOPNOTSUPP; + guard(pwmchip)(chip); if (!chip->operational) @@ -320,6 +326,9 @@ static int __pwm_set_waveform(struct pwm_device *pwm, BUG_ON(WFHWSIZE < ops->sizeof_wfhw); + if (!pwmchip_supports_waveform(chip)) + return -EOPNOTSUPP; + if (!pwm_wf_valid(wf)) return -EINVAL; @@ -592,7 +601,7 @@ static int __pwm_apply(struct pwm_device *pwm, const struct pwm_state *state) state->usage_power == pwm->state.usage_power) return 0; - if (ops->write_waveform) { + if (pwmchip_supports_waveform(chip)) { struct pwm_waveform wf; char wfhw[WFHWSIZE]; @@ -746,7 +755,7 @@ int pwm_get_state_hw(struct pwm_device *pwm, struct pwm_state *state) if (!chip->operational) return -ENODEV; - if (ops->read_waveform) { + if (pwmchip_supports_waveform(chip) && ops->read_waveform) { char wfhw[WFHWSIZE]; struct pwm_waveform wf; diff --git a/include/linux/pwm.h b/include/linux/pwm.h index 78827f312407..b8d78009e779 100644 --- a/include/linux/pwm.h +++ b/include/linux/pwm.h @@ -347,6 +347,23 @@ struct pwm_chip { struct pwm_device pwms[] __counted_by(npwm); }; +/** + * pwmchip_supports_waveform() - checks if the given chip supports waveform callbacks + * @chip: The pwm_chip to test + * + * Returns true iff the pwm chip support the waveform functions like + * pwm_set_waveform_might_sleep() and pwm_round_waveform_might_sleep() + */ +static inline bool pwmchip_supports_waveform(struct pwm_chip *chip) +{ + /* + * only check for .write_waveform(). If that is available, + * .round_waveform_tohw() and .round_waveform_fromhw() asserted to be + * available, too, in pwmchip_add(). + */ + return chip->ops->write_waveform != NULL; +} + static inline struct device *pwmchip_parent(const struct pwm_chip *chip) { return chip->dev.parent; base-commit: e8c59791ebb60790c74b2c3ab520f04a8a57219a prerequisite-patch-id: f5f481d393ddd1fd20a685c86cd4e93dd40d26c7 -- 2.47.1

9 months, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025