kernel/linux.git/drivers/opp/debugfs.c, branch v6.19.11

saner replacement for debugfs_rename()

2025-01-15T12:14:37+00:00

Existing primitive has several problems: 1) calling conventions are clumsy - it returns a dentry reference that is either identical to its second argument or is an ERR_PTR(-E...); in both cases no refcount changes happen. Inconvenient for users and bug-prone; it would be better to have it return 0 on success and -E... on failure. 2) it allows cross-directory moves; however, no such caller have ever materialized and considering the way debugfs is used, it's unlikely to happen in the future. What's more, any such caller would have fun issues to deal with wrt interplay with recursive removal. It also makes the calling conventions clumsier... 3) tautological rename fails; the callers have no race-free way to deal with that. 4) new name must have been formed by the caller; quite a few callers have it done by sprintf/kasprintf/etc., ending up with considerable boilerplate. Proposed replacement: int debugfs_change_name(dentry, fmt, ...). All callers convert to that easily, and it's simpler internally. IMO debugfs_rename() should go; if we ever get a real-world use case for cross-directory moves in debugfs, we can always look into the right way to handle that. Signed-off-by: Al Viro Link: https://lore.kernel.org/r/20250112080705.141166-21-viro@zeniv.linux.org.uk Signed-off-by: Greg Kroah-Hartman

OPP: debugfs: Fix warning around icc_get_name()

2024-03-11T05:09:24+00:00

If the kernel isn't built with interconnect support, icc_get_name() returns NULL and we get following warning: drivers/opp/debugfs.c: In function 'bw_name_read': drivers/opp/debugfs.c:43:42: error: '%.62s' directive argument is null [-Werror=format-overflow=] i = scnprintf(buf, sizeof(buf), "%.62s\n", icc_get_name(path)); Fix it. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202402141313.81ltVF5g-lkp@intel.com/ Fixes: 0430b1d5704b0 ("opp: Expose bandwidth information via debugfs") Signed-off-by: Viresh Kumar Reviewed-by: Dhruva Gole

OPP: debugfs: Fix warning with W=1 builds

2024-03-11T05:09:24+00:00

We currently get the following warning: debugfs.c:105:54: error: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 8 [-Werror=format-truncation=] snprintf(name, sizeof(name), "supply-%d", i); ^~ debugfs.c:105:46: note: directive argument in the range [-2147483644, 2147483646] snprintf(name, sizeof(name), "supply-%d", i); ^~~~~~~~~~~ debugfs.c:105:17: note: 'snprintf' output between 9 and 19 bytes into a destination of size 15 snprintf(name, sizeof(name), "supply-%d", i); Fix this and other potential issues it by allocating larger arrays. Use the exact string format to allocate the arrays without getting into these issues again. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202402141313.81ltVF5g-lkp@intel.com/ Signed-off-by: Viresh Kumar Reviewed-by: Dhruva Gole

OPP: debugfs: Fix warning with W=1 builds

2023-10-06T07:07:34+00:00

We currently get the following warning: debugfs.c: In function ‘opp_debug_create_one’: debugfs.c:63:42: warning: ‘%.1d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 2 [-Wformat-truncation=] snprintf(name, sizeof(name), "icc-path-%.1d", i); ^~~~ debugfs.c:63:32: note: directive argument in the range [0, 2147483647] snprintf(name, sizeof(name), "icc-path-%.1d", i); ^~~~~~~~~~~~~~~ debugfs.c:63:3: note: ‘snprintf’ output between 11 and 20 bytes into a destination of size 11 snprintf(name, sizeof(name), "icc-path-%.1d", i); Fix it by increasing size of the `name` array. Signed-off-by: Viresh Kumar

OPP: Simplify the over-designed pstate <-> level dance

2023-06-19T04:20:09+00:00

While adding support for "performance states" in the OPP and genpd core, it was decided to set the `pstate` field via genpd's pm_genpd_opp_to_performance_state() helper, to allow platforms to set `pstate` even if they don't have a corresponding `level` field in the DT OPP tables (More details are present in commit 6e41766a6a50 ("PM / Domain: Implement of_genpd_opp_to_performance_state()")). Revisiting that five years later clearly suggests that it was over-designed as all current users are eventually using the `level` value only. The previous commit already added necessary checks to make sure pstate is only used for genpd tables. Lets now simplify this a little, and use `level` directly and remove `pstate` field altogether. Suggested-by: Ulf Hansson Signed-off-by: Viresh Kumar Reviewed-by: Ulf Hansson

OPP: pstate is only valid for genpd OPP tables

2023-06-19T04:20:02+00:00

It is not very clear right now that the `pstate` field is only valid for genpd OPP tables and not consumer tables. And there is no checking for the same at various places. Add checks in place to verify that and make it clear to the reader. Signed-off-by: Viresh Kumar Reviewed-by: Ulf Hansson Reviewed-by: Bjorn Andersson Tested-by: Bjorn Andersson

OPP: fix error checking in opp_migrate_dentry()

2023-02-08T05:10:59+00:00

Since commit ff9fb72bc077 ("debugfs: return error values, not NULL") changed return value of debugfs_rename() in error cases from %NULL to %ERR_PTR(-ERROR), we should also check error values instead of NULL. Fixes: ff9fb72bc077 ("debugfs: return error values, not NULL") Signed-off-by: Qi Zheng Signed-off-by: Viresh Kumar

OPP: Allow multiple clocks for a device

2022-07-12T15:05:20+00:00

This patch adds support to allow multiple clocks for a device. The design is pretty much similar to how this is done for regulators, and platforms can supply their own version of the config_clks() callback if they have multiple clocks for their device. The core manages the calls via opp_table->config_clks() eventually. We have kept both "clk" and "clks" fields in the OPP table structure and the reason is provided as a comment in _opp_set_clknames(). The same isn't done for "rates" though and we use rates[0] at most of the places now. Co-developed-by: Krzysztof Kozlowski Signed-off-by: Krzysztof Kozlowski Tested-by: Jon Hunter Tested-by: Dmitry Osipenko Tested-by: Manivannan Sadhasivam Signed-off-by: Viresh Kumar

opp: use list iterator only inside the loop

2022-04-11T03:01:43+00:00

To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate dedicated pointer variable [1]. In this case, use a new variable 'iter' as the list iterator, while use the old variable 'new_dev' as a dedicated pointer to point to the found entry. And BUG_ON(!new_dev);. [1]: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ Signed-off-by: Xiaomeng Tong Signed-off-by: Viresh Kumar

OPP: Add "opp-microwatt" supporting code

2022-03-03T04:05:04+00:00

Add new property to the OPP: power value. The OPP entry in the DT can have "opp-microwatt". Add the needed code to handle this new property in the existing infrastructure. Signed-off-by: Lukasz Luba Signed-off-by: Viresh Kumar