[PATCH] perf: ftrace: Add filter support for option -F/--funcs
Same as 'perf probe -F', this patch adds filter support for the ftrace
subcommand option '-F, --funcs <[FILTER]>'.
Here is an example that only lists functions which start with 'vfs_':
$ sudo perf ftrace -F vfs_*
vfs_fadvise
vfs_fallocate
vfs_truncate
vfs_open
vfs_setpos
vfs_llseek
vfs_readf
vfs_writef
...
Suggested-by: Arnaldo Carvalho de Melo
Signed-off-by: Changbin Du
---
tools/perf/Documentation/perf-ftrace.txt | 3 +-
tools/perf/builtin-ftrace.c | 84 ++--
2 files changed, 80 insertions(+), 7 deletions(-)
diff --git a/tools/perf/Documentation/perf-ftrace.txt
b/tools/perf/Documentation/perf-ftrace.txt
index 78358af9a1c4..1e91121bac0f 100644
--- a/tools/perf/Documentation/perf-ftrace.txt
+++ b/tools/perf/Documentation/perf-ftrace.txt
@@ -33,7 +33,8 @@ OPTIONS
-F::
--funcs::
-List all available functions to trace.
+List available functions to trace. It accepts a pattern to
+only list interested functions.
-p::
--pid=::
diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
index 1d44bc2f63d8..9366fad591dc 100644
--- a/tools/perf/builtin-ftrace.c
+++ b/tools/perf/builtin-ftrace.c
@@ -25,6 +25,7 @@
#include "target.h"
#include "cpumap.h"
#include "thread_map.h"
+#include "strfilter.h"
#include "util/cap.h"
#include "util/config.h"
#include "util/units.h"
@@ -36,7 +37,6 @@ struct perf_ftrace {
struct evlist *evlist;
struct target target;
const char *tracer;
- boollist_avail_functions;
struct list_headfilters;
struct list_headnotrace;
struct list_headgraph_funcs;
@@ -181,6 +181,40 @@ static int read_tracing_file_to_stdout(const char *name)
return ret;
}
+static int read_tracing_file_by_line(const char *name,
+void (*cb)(char *str, void *arg),
+void *cb_arg)
+{
+ char *line = NULL;
+ size_t len = 0;
+ char *file;
+ FILE *fp;
+
+ file = get_tracing_file(name);
+ if (!file) {
+ pr_debug("cannot get tracing file: %s\n", name);
+ return -1;
+ }
+
+ fp = fopen(file, "r");
+ if (fp == NULL) {
+ pr_debug("cannot open tracing file: %s\n", name);
+ put_tracing_file(file);
+ return -1;
+ }
+
+ while (getline(, , fp) != -1) {
+ cb(line, cb_arg);
+ }
+
+ if (line)
+ free(line);
+
+ fclose(fp);
+ put_tracing_file(file);
+ return 0;
+}
+
static int write_tracing_file_int(const char *name, int value)
{
char buf[16];
@@ -557,9 +591,6 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, int
argc, const char **argv)
signal(SIGCHLD, sig_handler);
signal(SIGPIPE, sig_handler);
- if (ftrace->list_avail_functions)
- return
read_tracing_file_to_stdout("available_filter_functions");
-
if (reset_tracing_files(ftrace) < 0) {
pr_err("failed to reset ftrace\n");
goto out;
@@ -683,6 +714,46 @@ static int perf_ftrace_config(const char *var, const char
*value, void *cb)
return -1;
}
+static void list_function_cb(char *str, void *arg)
+{
+ struct strfilter *filter = (struct strfilter *)arg;
+
+ if (strfilter__compare(filter, str))
+ printf("%s", str);
+}
+
+static int opt_list_avail_functions(const struct option *opt __maybe_unused,
+ const char *str, int unset)
+{
+ struct strfilter *filter;
+ const char *err = NULL;
+ int ret;
+
+ if (unset || !str)
+ return -1;
+
+ filter = strfilter__new(str, );
+ if (!filter)
+ return err ? -EINVAL : -ENOMEM;
+
+ ret = strfilter__or(filter, str, );
+ if (ret == -EINVAL) {
+ pr_err("Filter parse error at %td.\n", err - str + 1);
+ pr_err("Source: \"%s\"\n", str);
+ pr_err(" %*c\n", (int)(err - str + 1), '^');
+ strfilter__delete(filter);
+ return ret;
+ }
+
+ ret = read_tracing_file_by_line("available_filter_functions",
+ list_function_cb, filter);
+ strfilter__delete(filter);
+ if (ret < 0)
+ return ret;
+
+ exit(0);
+}
+
static int parse_filter_func(const struct option *opt, const char *str,
int unset __maybe_unused)
{
@@ -817,8 +888,9 @@ int cmd_ftrace(int argc, const char **argv)
const struct option ftrace_options[] = {
OPT_STRING('t', "tracer", , "tracer",
"Tracer to use: function_graph(default) or function"),
- OPT_BOOLEAN('F', "funcs", _avail_functions,
- "Show available functions to filter"),
+
Re: [PATCH V3 0/4] opp: general cleanups
On 8/20/2020 1:26 PM, Viresh Kumar wrote: Hi, Here is another version of the cleanups I sent earlier. Rajendra: Please see if these work fine now. I gave these a quick spin, and they don';t result in the crash I earlier observed Tested-by: Rajendra Nayak V3: - Dropped v2 1/4 as it is already merged. - New patch 4/4 added. - Reordered the first two patches here (Stephen) - disable regulator only if present Viresh Kumar (4): opp: Rename regulator_enabled and use it as status of all resources opp: Track device's resources configuration status opp: Split out _opp_set_rate_zero() opp: Remove _dev_pm_opp_find_and_remove_table() wrapper drivers/opp/core.c | 103 + drivers/opp/cpu.c | 2 +- drivers/opp/of.c | 2 +- drivers/opp/opp.h | 5 +-- 4 files changed, 52 insertions(+), 60 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: Why KASAN doesn't detect this stack oob fault?
On Sun, Aug 23, 2020 at 11:04:34AM +0800, richard clark wrote:
> Hi guys,
>
> I ins a kmod with below code in a KASAN enabled kernel (
> 5.7.0,
> CONFIG_KASAN=y
> CONFIG_KASAN_GENERIC=y
> CONFIG_KASAN_OUTLINE=y):
>
> static int kmod_init(void)
> {
> int i;
> int arr[4];
>
> for (i = 0; i < 20; i++) {
> arr[i] = i;
> printk("arr[%d] = %d\n", i, arr[i]);
> }
> return 0;
> }
>
> The output is after insmod:
>
> [ 1511.800683] arr[0] = 0
> [ 1511.800685] arr[1] = 1
> [ 1511.800686] arr[2] = 2
> [ 1511.800687] arr[3] = 3
> [ 1511.800688] arr[4] = 4
> [ 1511.800690] arr[5] = 5
> [ 1511.800691] arr[6] = 6
> [ 1511.800692] arr[7] = 7
> [ 1511.800693] arr[8] = 8
> [ 1511.800694] arr[9] = 9
> [ 1511.800695] arr[10] = 10
> [ 1511.800696] arr[11] = 11
> [ 1511.800697] arr[12] = 12
> [ 1511.800699] arr[13] = 13
> [ 1511.800700] arr[14] = 14
> [ 1511.800701] arr[15] = 15
> [ 1511.800702] arr[16] = 16
> [ 1511.800704] arr[17] = 17
> [ 1511.800705] arr[18] = 18
> [ 1511.800706] arr[19] = 19
>
> The kernel is not tainted and the gcc version is 7.5 used to build the kernel.
> The question is:
> 1. Why the stack out-of-bound can work?
> 2. Why the KASAN doesn't detect this?
Have you verified in the output code that the compiler didn't optimize
the stack access away since it doesn't need it ?
Just to make sure, do it in two distinct loops so that there are more
chances for the stack to be really used:
static int kmod_init(void)
{
int i;
int arr[4];
for (i = 0; i < 20; i++)
arr[i] = i;
for (i = 0; i < 20; i++)
printk("arr[%d] = %d\n", i, arr[i]);
return 0;
}
Willy
Re: [PATCH iproute2 v5 0/2] iplink: hsr: add support for creating PRP device
On Mon, 17 Aug 2020 17:17:35 -0400 Murali Karicheri wrote: > This series enhances the iproute2 iplink module to add support > for creating PRP device similar to HSR. The kernel part of this > is already merged to v5.9 master > > v4 - addressed comment from Stephen Hemminger >- Sending this with a iproute2 prefix so that this can > be merged to v5.9 iprout2 if possible. > v3 of the series is rebased to iproute2-next/master at > git://git.kernel.org/pub/scm/network/iproute2/iproute2-next > and send as v4. > > Please apply this if looks good. > > > Murali Karicheri (2): > iplink: hsr: add support for creating PRP device similar to HSR > ip: iplink: prp: update man page for new parameter > > ip/iplink_hsr.c | 17 +++-- > man/man8/ip-link.8.in | 9 - > 2 files changed, 23 insertions(+), 3 deletions(-) Applied. Than ks for updating
[PATCH] lib: radix-tree: delete duplicated words
Drop the repeated word "be". Signed-off-by: Randy Dunlap Cc: Andrew Morton Cc: Matthew Wilcox --- lib/radix-tree.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200730.orig/lib/radix-tree.c +++ linux-next-20200730/lib/radix-tree.c @@ -325,7 +325,7 @@ static __must_check int __radix_tree_pre int ret = -ENOMEM; /* -* Nodes preloaded by one cgroup can be be used by another cgroup, so +* Nodes preloaded by one cgroup can be used by another cgroup, so * they should never be accounted to any particular memory cgroup. */ gfp_mask &= ~__GFP_ACCOUNT;
[PATCH] lib: syscall: delete duplicated words
Drop the repeated word "the". Signed-off-by: Randy Dunlap Cc: Andrew Morton Cc: Steven Rostedt --- lib/syscall.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200730.orig/lib/syscall.c +++ linux-next-20200730/lib/syscall.c @@ -44,7 +44,7 @@ static int collect_syscall(struct task_s * .data.instruction_pointer - filled with user PC * * If @target is blocked in a system call, returns zero with @info.data.nr - * set to the the call's number and @info.data.args filled in with its + * set to the call's number and @info.data.args filled in with its * arguments. Registers not used for system call arguments may not be available * and it is not kosher to use user_regset calls while the system * call is still in progress. Note we may get this result if @target
[PATCH] lib: dynamic_queue_limits: delete duplicated words + fix typo
Drop the repeated word "the". Fix spelling of "excess". Signed-off-by: Randy Dunlap Cc: Andrew Morton Cc: "David S. Miller" Cc: Jakub Kicinski --- lib/dynamic_queue_limits.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20200730.orig/lib/dynamic_queue_limits.c +++ linux-next-20200730/lib/dynamic_queue_limits.c @@ -60,8 +60,8 @@ void dql_completed(struct dql *dql, unsi * A decrease is only considered if the queue has been busy in * the whole interval (the check above). * -* If there is slack, the amount of execess data queued above -* the the amount needed to prevent starvation, the queue limit +* If there is slack, the amount of excess data queued above +* the amount needed to prevent starvation, the queue limit * can be decreased. To avoid hysteresis we consider the * minimum amount of slack found over several iterations of the * completion routine.
[PATCH] lib: pldmfw: delete duplicated words
Drop the repeated word "header". Signed-off-by: Randy Dunlap Cc: Jacob Keller Cc: "David S. Miller" Cc: Jakub Kicinski --- lib/pldmfw/pldmfw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200730.orig/lib/pldmfw/pldmfw.c +++ linux-next-20200730/lib/pldmfw/pldmfw.c @@ -517,7 +517,7 @@ static int pldm_verify_header_crc(struct u32 calculated_crc; size_t length; - /* Calculate the 32-bit CRC of the header header contents up to but + /* Calculate the 32-bit CRC of the header contents up to but * not including the checksum. Note that the Linux crc32_le function * does not perform an expected final XOR. */
[PATCH] lib: earlycpio: delete duplicated words
Drop the repeated word "the".
Signed-off-by: Randy Dunlap
Cc: Andrew Morton
Cc: H. Peter Anvin
---
lib/earlycpio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200730.orig/lib/earlycpio.c
+++ linux-next-20200730/lib/earlycpio.c
@@ -42,7 +42,7 @@ enum cpio_fields {
/**
* cpio_data find_cpio_data - Search for files in an uncompressed cpio
* @path: The directory to search for, including a slash at the end
- * @data: Pointer to the the cpio archive or a header inside
+ * @data: Pointer to the cpio archive or a header inside
* @len:Remaining length of the cpio based on data pointer
* @nextoff:When a matching file is found, this is the offset from the
* beginning of the cpio to the beginning of the next file, not
the
[PATCH] lib: decompress_bunzip2: delete duplicated words
Drop the repeated word "how". Signed-off-by: Randy Dunlap Cc: Andrew Morton Cc: Herbert Xu Cc: Lasse Collin --- lib/decompress_bunzip2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200730.orig/lib/decompress_bunzip2.c +++ linux-next-20200730/lib/decompress_bunzip2.c @@ -390,7 +390,7 @@ static int INIT get_next_block(struct bu j = (bd->inbufBits >> bd->inbufBitCount)& ((1 << hufGroup->maxLen)-1); got_huff_bits: - /* Figure how how many bits are in next symbol and + /* Figure how many bits are in next symbol and * unget extras */ i = hufGroup->minLen; while (j > limit[i])
[PATCH] lib: test_sysctl: delete duplicated words
Drop the repeated word "the". Signed-off-by: Randy Dunlap Cc: Andrew Morton Cc: Shuah Khan Cc: Shuah Khan --- lib/test_sysctl.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200730.orig/lib/test_sysctl.c +++ linux-next-20200730/lib/test_sysctl.c @@ -16,7 +16,7 @@ */ /* - * This module provides an interface to the the proc sysctl interfaces. This + * This module provides an interface to the proc sysctl interfaces. This * driver requires CONFIG_PROC_SYSCTL. It will not normally be loaded by the * system unless explicitly requested by name. You can also build this driver * into your kernel.
[PATCH] lib: libcrc32c: delete duplicated words
Drop the repeated word "the".
Signed-off-by: Randy Dunlap
Cc: Clay Haapala
Cc: Andrew Morton
Cc: Herbert Xu
---
lib/libcrc32c.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200730.orig/lib/libcrc32c.c
+++ linux-next-20200730/lib/libcrc32c.c
@@ -12,7 +12,7 @@
* pages ={},
* month ={June},
*}
- * Used by the iSCSI driver, possibly others, and derived from the
+ * Used by the iSCSI driver, possibly others, and derived from
* the iscsi-crc.c module of the linux-iscsi driver at
* http://linux-iscsi.sourceforge.net.
*
[PATCH] lib: bitmap: delete duplicated words
Drop the repeated word "an". Signed-off-by: Randy Dunlap Cc: Andrew Morton --- lib/bitmap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200730.orig/lib/bitmap.c +++ linux-next-20200730/lib/bitmap.c @@ -23,7 +23,7 @@ /** * DOC: bitmap introduction * - * bitmaps provide an array of bits, implemented using an an + * bitmaps provide an array of bits, implemented using an * array of unsigned longs. The number of valid bits in a * given bitmap does _not_ need to be an exact multiple of * BITS_PER_LONG.
[PATCH] lib: devres: delete duplicated words
Drop the repeated word "the". Signed-off-by: Randy Dunlap Cc: Andrew Morton Cc: Arnd Bergmann Cc: Greg Kroah-Hartman --- lib/devres.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200730.orig/lib/devres.c +++ linux-next-20200730/lib/devres.c @@ -217,7 +217,7 @@ void __iomem *devm_ioremap_resource_wc(s * Please Note: This is not a one-to-one replacement for of_iomap() because the * of_iomap() function does not track whether the region is already mapped. If * two drivers try to map the same memory, the of_iomap() function will succeed - * but the the devm_of_iomap() function will return -EBUSY. + * but the devm_of_iomap() function will return -EBUSY. * */ void __iomem *devm_of_iomap(struct device *dev, struct device_node *node, int index,
Re: [PATCH v3 2/2] ARM: dts: vfxxx: Add syscon compatible with OCOTP
On Fri, Aug 21, 2020 at 02:21:02PM -0700, Chris Healy wrote:
> From: Chris Healy
>
> Add syscon compatibility with Vybrid OCOTP node. This is required to
> access the UID.
>
> Fixes: fa8d20c8dbb77 ("ARM: dts: vfxxx: Add node corresponding to OCOTP")
> Cc: sta...@vger.kernel.org
> Reviewed-by: Fabio Estevam
> Reviewed-by: Stefan Agner
> Signed-off-by: Chris Healy
Applied, thanks.
Re: [PATCH v3 1/2] dt-bindings: nvmem: Add syscon to Vybrid OCOTP driver
On Fri, Aug 21, 2020 at 02:21:01PM -0700, Chris Healy wrote:
> From: Chris Healy
>
> Add syscon compatibility with Vybrid OCOTP driver binding. This is
> required to access the UID.
>
> Fixes: fa8d20c8dbb77 ("ARM: dts: vfxxx: Add node corresponding to OCOTP")
The bindings doc was not added by this commit though.
> Cc: sta...@vger.kernel.org
> Signed-off-by: Chris Healy
> ---
> Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> index 56ed481c3e26..5db39f399568 100644
> --- a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> +++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> @@ -11,7 +11,7 @@ Required Properties:
> Example for Vybrid VF5xx/VF6xx:
>
> ocotp: ocotp@400a5000 {
> - compatible = "fsl,vf610-ocotp";
> + compatible = "fsl,vf610-ocotp", "syscon";
It's not only about fixing example. More important one is "compatible"
property of the bindings.
Shawn
> #address-cells = <1>;
> #size-cells = <1>;
> reg = <0x400a5000 0xCF0>;
> --
> 2.26.2
>
Why KASAN doesn't detect this stack oob fault?
Hi guys,
I ins a kmod with below code in a KASAN enabled kernel (
5.7.0,
CONFIG_KASAN=y
CONFIG_KASAN_GENERIC=y
CONFIG_KASAN_OUTLINE=y):
static int kmod_init(void)
{
int i;
int arr[4];
for (i = 0; i < 20; i++) {
arr[i] = i;
printk("arr[%d] = %d\n", i, arr[i]);
}
return 0;
}
The output is after insmod:
[ 1511.800683] arr[0] = 0
[ 1511.800685] arr[1] = 1
[ 1511.800686] arr[2] = 2
[ 1511.800687] arr[3] = 3
[ 1511.800688] arr[4] = 4
[ 1511.800690] arr[5] = 5
[ 1511.800691] arr[6] = 6
[ 1511.800692] arr[7] = 7
[ 1511.800693] arr[8] = 8
[ 1511.800694] arr[9] = 9
[ 1511.800695] arr[10] = 10
[ 1511.800696] arr[11] = 11
[ 1511.800697] arr[12] = 12
[ 1511.800699] arr[13] = 13
[ 1511.800700] arr[14] = 14
[ 1511.800701] arr[15] = 15
[ 1511.800702] arr[16] = 16
[ 1511.800704] arr[17] = 17
[ 1511.800705] arr[18] = 18
[ 1511.800706] arr[19] = 19
The kernel is not tainted and the gcc version is 7.5 used to build the kernel.
The question is:
1. Why the stack out-of-bound can work?
2. Why the KASAN doesn't detect this?
[PATCH] rcu-tasks: Fix compilation warning with !CONFIG_TASKS_RCU and CONFIG_TINY_RCU
Commit 8344496e8b49 ("rcu-tasks: Conditionally compile
show_rcu_tasks_gp_kthreads()") introduced conditional compilation of
several functions, but forgot one occurrence of
show_rcu_tasks_classic_gp_kthread() that causes the compiler to warn of
an unused static function. Fix it.
Fixes: 8344496e8b49 ("rcu-tasks: Conditionally compile
show_rcu_tasks_gp_kthreads()")
Signed-off-by: Laurent Pinchart
---
kernel/rcu/tasks.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
index 835e2df8590a..bddf3968c1eb 100644
--- a/kernel/rcu/tasks.h
+++ b/kernel/rcu/tasks.h
@@ -590,7 +590,9 @@ void exit_tasks_rcu_finish(void)
__releases(_rcu_exit_srcu)
}
#else /* #ifdef CONFIG_TASKS_RCU */
+#ifndef CONFIG_TINY_RCU
static void show_rcu_tasks_classic_gp_kthread(void) { }
+#endif /* #ifndef CONFIG_TINY_RCU */
void exit_tasks_rcu_start(void) { }
void exit_tasks_rcu_finish(void) { exit_tasks_rcu_finish_trace(current); }
#endif /* #else #ifdef CONFIG_TASKS_RCU */
--
Regards,
Laurent Pinchart
Re: [PATCH v6 1/3] arm64: dts: Add a device tree for the Librem 5 phone
On Fri, Aug 21, 2020 at 02:17:53PM +0200, Martin Kepplinger wrote:
> From: "Angus Ainslie (Purism)"
>
> Add a devicetree description for the Librem 5 phone. 4 hardware revisions
> have been available. Some revisions include changes that need different
> software to be run. So far, r3 ("Dogwood") is one such example, see:
>
> "Aspen" r0 not supported (very few devices exist)
> "Birch" r1 supported by r2
> "Chestnut" r2 added by this patch
> "Dogwood" r3 added by this patch
> "Evergreen" r4 tba / most likely supported by r3
>
> See https://puri.sm/products/librem-5/ for more information.
>
> This boots to a working console with working WWAN modem, wifi usdhc,
> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Angus Ainslie (Purism)
> Signed-off-by: Guido Günther
> Reviewed-by: Daniel Baluta (for the audio part)
> Reviewed-by: Fabio Estevam
Applied all, thanks.
Re: [PATCH v2 3/4] arm64: defconfig: re-sync DRM related defconfig bits
On Thu, Aug 20, 2020 at 10:50:58AM +0200, Guido Günther wrote: > This moves the CONFIG_DRM_SIMPLE_BRIDGE entry around making further > updates simpler. > > Signed-off-by: Guido Günther Patch #3 and #4 do not apply to my branch. Shawn
Re: [PATCH v2 2/4] arm64: dts: imx8mq-librem5-devkit: Enable the LCD panel
On Thu, Aug 20, 2020 at 10:50:57AM +0200, Guido Günther wrote: > Enable LCD panel output by adding nodes for the NWL DSI host controller, > the Rocktech panel and the eLCDIF display controller. > > Signed-off-by: Guido Günther > Reviewed-by: Fabio Estevam Applied, thanks.
Re: [PATCH 2/8] drm/lima: Unconditionally call dev_pm_opp_of_remove_table()
Looks good for me, patch is:
Reviewed-by: Qiang Yu
Regards,
Qiang
On Thu, Aug 20, 2020 at 6:44 PM Viresh Kumar wrote:
>
> dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> find the OPP table with error -ENODEV (i.e. OPP table not present for
> the device). And we can call dev_pm_opp_of_remove_table()
> unconditionally here.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/gpu/drm/lima/lima_devfreq.c | 6 +-
> drivers/gpu/drm/lima/lima_devfreq.h | 1 -
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
> b/drivers/gpu/drm/lima/lima_devfreq.c
> index bbe02817721b..cd290d866a04 100644
> --- a/drivers/gpu/drm/lima/lima_devfreq.c
> +++ b/drivers/gpu/drm/lima/lima_devfreq.c
> @@ -105,10 +105,7 @@ void lima_devfreq_fini(struct lima_device *ldev)
> devfreq->devfreq = NULL;
> }
>
> - if (devfreq->opp_of_table_added) {
> - dev_pm_opp_of_remove_table(ldev->dev);
> - devfreq->opp_of_table_added = false;
> - }
> + dev_pm_opp_of_remove_table(ldev->dev);
>
> if (devfreq->regulators_opp_table) {
> dev_pm_opp_put_regulators(devfreq->regulators_opp_table);
> @@ -162,7 +159,6 @@ int lima_devfreq_init(struct lima_device *ldev)
> ret = dev_pm_opp_of_add_table(dev);
> if (ret)
> goto err_fini;
> - ldevfreq->opp_of_table_added = true;
>
> lima_devfreq_reset(ldevfreq);
>
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.h
> b/drivers/gpu/drm/lima/lima_devfreq.h
> index 5eed2975a375..2d9b3008ce77 100644
> --- a/drivers/gpu/drm/lima/lima_devfreq.h
> +++ b/drivers/gpu/drm/lima/lima_devfreq.h
> @@ -18,7 +18,6 @@ struct lima_devfreq {
> struct opp_table *clkname_opp_table;
> struct opp_table *regulators_opp_table;
> struct thermal_cooling_device *cooling;
> - bool opp_of_table_added;
>
> ktime_t busy_time;
> ktime_t idle_time;
> --
> 2.25.0.rc1.19.g042ed3e048af
>
Re: [PATCH v2 1/4] arm64: dts: imx8mq: Add NWL MIPI DSI controller
On Thu, Aug 20, 2020 at 10:50:56AM +0200, Guido Günther wrote: > Add a node for the Northwest Logic MIPI DSI IP core, "disabled" by > default. This also adds the necessary port to LCDIF. > > Signed-off-by: Guido Günther > Reviewed-by: Fabio Estevam Applied, thanks.
Re: [RFC PATCH 0/8] memcg: Enable fine-grained per process memory control
On 8/18/20 6:17 AM, Chris Down wrote: pet...@infradead.org writes: But then how can it run-away like Waiman suggested? Probably because he's not running with that commit at all. We and others use this to prevent runaway allocation on a huge range of production and desktop use cases and it works just fine. /me goes look... and finds MEMCG_MAX_HIGH_DELAY_JIFFIES. That's a fail... :-( I'd ask that you understand a bit more about the tradeoffs and intentions of the patch before rushing in to declare its failure, considering it works just fine :-) Clamping the maximal time allows the application to take some action to remediate the situation, while still being slowed down significantly. 2 seconds per allocation batch is still absolutely plenty for any use case I've come across. If you have evidence it isn't, then present that instead of vague notions of "wrongness". Sorry for the late reply. I ran some test on the latest kernel and and it seems to work as expected. I was running the test on an older kernel that doesn't have this patch and I was not aware of it before hand. Sorry for the confusion. Cheers, Longman
[PATCH v2] ARM: dts: imx7d-zii-rmu2: fix rgmii phy-mode for ksz9031 phy
From: Chris Healy
Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the
KSZ9031 PHY") the networking is broken on the imx7d-zii-rmu2 board.
The end result is that network receive behaviour is marginal with lots of
RX CRC errors experienced and NFS frequently failing.
Quoting the explanation from Andrew Lunn in commit 0672d22a19244
("ARM: dts: imx: Fix the AR803X phy-mode"):
"The problem here is, all the DTs were broken since day 0. However,
because the PHY driver was also broken, nobody noticed and it
worked. Now that the PHY driver has been fixed, all the bugs in the
DTs now become an issue"
Fix it by switching to phy-mode = "rgmii-id".
Fixes: bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031
PHY")
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/imx7d-zii-rmu2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7d-zii-rmu2.dts
b/arch/arm/boot/dts/imx7d-zii-rmu2.dts
index e5e20b07f184..7cb6153fc650 100644
--- a/arch/arm/boot/dts/imx7d-zii-rmu2.dts
+++ b/arch/arm/boot/dts/imx7d-zii-rmu2.dts
@@ -58,7 +58,7 @@ {
< IMX7D_ENET1_TIME_ROOT_CLK>;
assigned-clock-parents = < IMX7D_PLL_ENET_MAIN_100M_CLK>;
assigned-clock-rates = <0>, <1>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-handle = <_phy>;
status = "okay";
--
2.26.2
[GIT] Networking
Nothing earth shattering here, lots of small fixes (f.e. missing RCU protection, bad ref counting, missing memset(), etc.) all over the place: 1) Use get_file_rcu() in task_file iterator, from Yonghong Song. 2) There are two ways to set remote source MAC addresses in macvlan driver, but only one of which validates things properly. Fix this. From Alvin Šipraga. 3) Missing of_node_put() in gianfar probing, from Sumera Priyadarsini. 4) Preserve device wanted feature bits across multiple netlink ethtool requests, from Maxim Mikityanskiy. 5) Fix rcu_sched stall in task and task_file bpf iterators, from Yonghong Song. 6) Avoid reset after device destroy in ena driver, from Shay Agroskin. 7) Missing memset() in netlink policy export reallocation path, from Johannes Berg. 8) Fix info leak in __smc_diag_dump(), from Peilin Ye. 9) Decapsulate ECN properly for ipv6 in ipv4 tunnels, from Mark Tomlinson. 10) Fix number of data stream negotiation in SCTP, from David Laight. 11) Fix double free in connection tracker action module, from Alaa Hleihel. 12) Don't allow empty NHA_GROUP attributes, from Nikolay Aleksandrov. Please pull, thanks a lot! The following changes since commit 06a4ec1d9dc652e17ee3ac2ceb6c7cf6c2b75cdd: Merge tag 'pstore-v5.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux (2020-08-17 17:15:23 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git for you to fetch changes up to eeaac3634ee0e3f35548be35275efeca888e9b23: net: nexthop: don't allow empty NHA_GROUP (2020-08-22 12:39:55 -0700) Alaa Hleihel (1): net/sched: act_ct: Fix skb double-free in tcf_ct_handle_fragments() error flow Alvin Šipraga (1): macvlan: validate setting of multiple remote source MAC addresses Andrii Nakryiko (2): libbpf: Fix build on ppc64le architecture bpf: xdp: Fix XDP mode when no mode flags specified Colin Ian King (2): net: mscc: ocelot: remove duplicate "the the" phrase in Kconfig text net: ipv4: remove duplicate "the the" phrase in Kconfig text David Laight (1): net: sctp: Fix negotiation of the number of data streams. David S. Miller (6): Merge branch 'sfc-more-EF100-fixes' Merge branch 'cxgb4-Fix-ethtool-selftest-flits-calculation' Merge branch 'ethtool-netlink-bug-fixes' Merge branch 'Bug-fixes-for-ENA-ethernet-driver' Merge branch 'hv_netvsc-Some-fixes-for-the-select_queue' Merge git://git.kernel.org/.../bpf/bpf Edward Cree (5): sfc: really check hash is valid before using it sfc: take correct lock in ef100_reset() sfc: null out channel->rps_flow_id after freeing it sfc: don't free_irq()s if they were never requested sfc: fix build warnings on 32-bit Ganji Aravind (2): cxgb4: Fix work request size calculation for loopback test cxgb4: Fix race between loopback and normal Tx path Geert Uytterhoeven (1): dt-bindings: net: renesas, ether: Improve schema validation Haiyang Zhang (2): hv_netvsc: Remove "unlikely" from netvsc_select_queue hv_netvsc: Fix the queue_mapping in netvsc_vf_xmit() Jiri Olsa (1): tools/resolve_btfids: Fix sections with wrong alignment Jiri Wiesner (1): bonding: fix active-backup failover for current ARP slave Johannes Berg (1): netlink: fix state reallocation in policy export Kaige Li (1): net: phy: mscc: Fix a couple of spelling mistakes "spcified" -> "specified" Mark Tomlinson (1): gre6: Fix reception with IP6_TNL_F_RCV_DSCP_COPY Maxim Mikityanskiy (3): ethtool: Fix preserving of wanted feature bits in netlink interface ethtool: Account for hw_features in netlink interface ethtool: Don't omit the netlink reply if no features were changed Miaohe Lin (1): net: handle the return value of pskb_carve_frag_list() correctly Min Li (1): ptp: ptp_clockmatrix: use i2c_master_send for i2c write Nikolay Aleksandrov (1): net: nexthop: don't allow empty NHA_GROUP Peilin Ye (1): net/smc: Prevent kernel-infoleak in __smc_diag_dump() Sebastian Andrzej Siewior (1): net: atlantic: Use readx_poll_timeout() for large timeout Shay Agroskin (3): net: ena: Prevent reset after device destruction net: ena: Change WARN_ON expression in ena_del_napi_in_range() net: ena: Make missed_tx stat incremental Sumera Priyadarsini (1): net: gianfar: Add of_node_put() before goto statement Tobias Klauser (1): bpf: Fix two typos in uapi/linux/bpf.h Toke Høiland-Jørgensen (1): libbpf: Fix map index used in error message Tom Rix (1): net: dsa: b53: check for timeout Veronika Kabatova (1): selftests/bpf: Remove test_align leftovers Wang Hai (1): net: gemini: Fix missing free_netdev() in error path of gemini_ethernet_port_probe() Xin Long (2): ipv6:
Re: [PATCH V3] ARM: dts: imx6q-logicpd: Fix broken PWM
On Wed, Aug 19, 2020 at 02:59:44PM -0500, Adam Ford wrote:
> The DTC doesn't like the default PWM settings, because it's expecting
> three cells. This patch reduces adds the extra entry of 0 to the PWM
> reference.
>
> Fixes: fa28d8212ede ("ARM: dts: imx: default to #pwm-cells = <3> in the SoC
> dtsi files")
>
> Reviewed-by: Fabio Estevam
> Signed-off-by: Adam Ford
Applied, thanks.
Re: IOPRIO_CLASS_RT without CAP_SYS_ADMIN?
On 8/22/20 7:58 PM, Bart Van Assche wrote: > On 2020-08-20 17:35, Khazhismel Kumykov wrote: >> It'd be nice to allow a process to send RT requests without granting >> it the wide capabilities of CAP_SYS_ADMIN, and we already have a >> capability which seems to almost fit this priority idea - >> CAP_SYS_NICE? Would this fit there? >> >> Being capable of setting IO priorities on per request or per thread >> basis (be it async submission or w/ thread ioprio_set) is useful >> especially when the userspace has its own prioritization/scheduling >> before hitting the kernel, allowing us to signal to the kernel how to >> order certain IOs, and it'd be nice to separate this from ADMIN for >> non-root processes, in a way that's less error prone than e.g. having >> a trusted launcher ionice the process and then drop priorities for >> everything but prio requests. > > Hi Khazhy, > > In include/uapi/linux/capability.h I found the following: > > /* Allow raising priority and setting priority on other (different >UID) processes */ > /* Allow use of FIFO and round-robin (realtime) scheduling on own >processes and setting the scheduling algorithm used by another >process. */ > /* Allow setting cpu affinity on other processes */ > #define CAP_SYS_NICE 23 > > If it is acceptable that every process that has permission to submit > IOPRIO_CLASS_RT I/O also has permission to modify the priority of > other processes then extending CAP_SYS_NICE is an option. Another > possibility is to extend the block cgroup controller such that the > capability to submit IOPRIO_CLASS_RT I/O can be enabled through the > cgroup interface. There may be other approaches. I'm not sure what > the best approach is. I think CAP_SYS_NICE fits pretty nicely, and I was actually planning on using that for the io_uring SQPOLL side as well. So there is/will be some precedent for tying it into IO related things, too. For this use case, I think it's perfect. -- Jens Axboe
Re: [PATCH] clk: imx: vf610: Add CRC clock
On Mon, Aug 17, 2020 at 05:12:54PM +0200, Krzysztof Kozlowski wrote: > Add the clock for CRC block allowing it to be enabled by consumers. > > Signed-off-by: Krzysztof Kozlowski Applied, thanks.
Re: [PATCH v2 4/4] arm64: dts: imx8mm-var-som-symphony: Add Variscite Symphony board with VAR-SOM-MX8MM
On Mon, Aug 17, 2020 at 09:01:20AM +0200, Krzysztof Kozlowski wrote:
> Add a DTS for Variscite Symphony evaluation kit with VAR-SOM-MX8MM
> System on Module.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. Remove duplicated "leds" node,
> 2. Fix heartbeat to active low,
> 3. Add nxp,ptn5150 extcon.
> ---
> arch/arm64/boot/dts/freescale/Makefile| 1 +
> .../dts/freescale/imx8mm-var-som-symphony.dts | 248 ++
> 2 files changed, 249 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile
> b/arch/arm64/boot/dts/freescale/Makefile
> index a39f0a1723e0..dcfb8750cd78 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -29,6 +29,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
>
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
> b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
> new file mode 100644
> index ..2d3c30ac5e04
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
> @@ -0,0 +1,248 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2020 Krzysztof Kozlowski
> + */
> +
> +/dts-v1/;
> +
> +#include "imx8mm-var-som.dtsi"
> +
> +/ {
> + model = "Variscite VAR-SOM-MX8MM Symphony evaluation board";
> + compatible = "variscite,var-som-mx8mm-symphony",
> "variscite,var-som-mx8mm", "fsl,imx8mm";
> +
> + reg_usdhc2_vmmc: regulator-1 {
regulator-usdhc2-vmmc
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <_reg_usdhc2_vmmc>;
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 19 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + reg_usb_otg2_vbus: regulator-2 {
regulator-usb-otg2-vbus
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <_reg_usb_otg2_vbus>;
> + regulator-name = "usb_otg2_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = < 1 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + back {
> + label = "Back";
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + home {
> + label = "Home";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + menu {
> + label = "Menu";
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + heartbeat {
> + label = "Heartbeat";
> + gpios = < 0 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> +
> + {
> + reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
> +};
> +
> + {
> + clock-frequency = <40>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c2>;
> + status = "okay";
> +
> + pca9534: gpio@20 {
> + compatible = "nxp,pca9534";
> + reg = <0x20>;
> + gpio-controller;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pca9534>;
> + interrupt-parent = <>;
> + interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
> + #gpio-cells = <2>;
> + wakeup-source;
> +
> + /* USB 3.0 OTG (usbotg1) / SATA port switch, set to USB 3.0 */
> + usb3-sata-sel-hog {
> + gpio-hog;
> + gpios = <4 GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "usb3_sata_sel";
> + };
> +
> + som-vselect-hog {
> + gpio-hog;
> + gpios = <6 GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "som_vselect";
> + };
> +
> + enet-sel-hog {
> + gpio-hog;
> + gpios = <7 GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "enet_sel";
> + };
Re: IOPRIO_CLASS_RT without CAP_SYS_ADMIN?
On 2020-08-20 17:35, Khazhismel Kumykov wrote: > It'd be nice to allow a process to send RT requests without granting > it the wide capabilities of CAP_SYS_ADMIN, and we already have a > capability which seems to almost fit this priority idea - > CAP_SYS_NICE? Would this fit there? > > Being capable of setting IO priorities on per request or per thread > basis (be it async submission or w/ thread ioprio_set) is useful > especially when the userspace has its own prioritization/scheduling > before hitting the kernel, allowing us to signal to the kernel how to > order certain IOs, and it'd be nice to separate this from ADMIN for > non-root processes, in a way that's less error prone than e.g. having > a trusted launcher ionice the process and then drop priorities for > everything but prio requests. Hi Khazhy, In include/uapi/linux/capability.h I found the following: /* Allow raising priority and setting priority on other (different UID) processes */ /* Allow use of FIFO and round-robin (realtime) scheduling on own processes and setting the scheduling algorithm used by another process. */ /* Allow setting cpu affinity on other processes */ #define CAP_SYS_NICE 23 If it is acceptable that every process that has permission to submit IOPRIO_CLASS_RT I/O also has permission to modify the priority of other processes then extending CAP_SYS_NICE is an option. Another possibility is to extend the block cgroup controller such that the capability to submit IOPRIO_CLASS_RT I/O can be enabled through the cgroup interface. There may be other approaches. I'm not sure what the best approach is. Bart.
Re: [PATCH v2 3/4] arm64: dts: imx8mm-var-som: Add Variscite VAR-SOM-MX8MM System on Module
On Mon, Aug 17, 2020 at 09:01:19AM +0200, Krzysztof Kozlowski wrote:
> Add DTSI of Variscite VAR-SOM-MX8MM System on Module in a basic version,
> delivered with Variscite Symphony Evaluation kit. This version comes
> with:
> - 2 GB of RAM,
> - 16 GB eMMC,
> - Gigabit Ethernet PHY,
> - 802.11 ac/a/b/g/n WiFi with 4.2 Bluetooth (Cypress CYW43353),
> - CAN bus,
> - Audio codec (not yet configured in DTSI).
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. None
> ---
> .../boot/dts/freescale/imx8mm-var-som.dtsi| 579 ++
> 1 file changed, 579 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
> new file mode 100644
> index ..c5b8f6db19b0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
> @@ -0,0 +1,579 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2019 NXP
> + * Copyright (C) 2020 Krzysztof Kozlowski
> + */
> +
> +#include "imx8mm.dtsi"
> +
> +/ {
> + model = "Variscite VAR-SOM-MX8MM module";
> + compatible = "variscite,var-som-mx8mm", "fsl,imx8mm";
> +
> + chosen {
> + stdout-path =
> + };
> +
> + memory@4000 {
> + device_type = "memory";
> + reg = <0x0 0x4000 0 0x8000>;
> + };
> +
> + reg_eth_phy: regulator-0 {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <_reg_eth_phy>;
> + regulator-name = "eth_phy_pwr";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 9 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +};
> +
> +_0 {
> + cpu-supply = <_reg>;
> +};
> +
> +_1 {
> + cpu-supply = <_reg>;
> +};
> +
> +_2 {
> + cpu-supply = <_reg>;
> +};
> +
> +_3 {
> + cpu-supply = <_reg>;
> +};
> +
> + {
> + operating-points-v2 = <_opp_table>;
> +
> + ddrc_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-25M {
> + opp-hz = /bits/ 64 <2500>;
> + };
> +
> + opp-100M {
> + opp-hz = /bits/ 64 <1>;
> + };
> +
> + opp-750M {
> + opp-hz = /bits/ 64 <75000>;
> + };
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_ecspi1>;
> + cs-gpios = < 14 GPIO_ACTIVE_HIGH>,
> +< 0 GPIO_ACTIVE_HIGH>;
> + fsl,spi-num-chipselects = <2>;
This property is not supported any more.
> + /delete-property/ dmas;
> + /delete-property/ dma-names;
> + status = "okay";
> +
> + /* Resistive touch controller */
> + touchscreen@0 {
> + reg = <0>;
> + compatible = "ti,ads7846";
> + pinctrl-names = "default";
> + pinctrl-0 = <_restouch>;
> + interrupt-parent = <>;
> + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> +
> + spi-max-frequency = <150>;
> + pendown-gpio = < 3 GPIO_ACTIVE_LOW>;
> +
> + ti,x-min = /bits/ 16 <125>;
> + touchscreen-size-x = /bits/ 16 <4008>;
> + ti,y-min = /bits/ 16 <282>;
> + touchscreen-size-y = /bits/ 16 <3864>;
> + ti,x-plate-ohms = /bits/ 16 <180>;
> + touchscreen-max-pressure = /bits/ 16 <255>;
> + touchscreen-average-samples = /bits/ 16 <10>;
> + ti,debounce-tol = /bits/ 16 <3>;
> + ti,debounce-rep = /bits/ 16 <1>;
> + ti,settle-delay-usec = /bits/ 16 <150>;
> + ti,keep-vref-on;
> + wakeup-source;
> + };
> +
> + can: can@1 {
> + /* TODO: binding not documented, patches on the LKML */
Do not submit stuff that haven't landed.
> + compatible = "microchip,mcp2517fd";
> + reg = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_can>;
> + interrupt-parent = <>;
> + interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
> + spi-max-frequency = <2000>;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_fec1>;
> + phy-mode = "rgmii";
> + phy-handle = <>;
> + phy-supply = <_eth_phy>;
> + phy-reset-gpios = < 9 GPIO_ACTIVE_LOW>;
> + phy-reset-duration = <100>;
> + phy-reset-post-delay = <100>;
These properties are deprecated. Check out bindings/net/fsl-fec.txt.
> + fsl,magic-packet;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy: ethernet-phy@4 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg =
[PATCH v5 1/4] drm/mediatek: Move tz_disabled from mtk_hdmi_phy to mtk_hdmi driver
From: CK Hu
tz_disabled is used to control mtk_hdmi output signal, but this variable
is stored in mtk_hdmi_phy and mtk_hdmi_phy does not use it. So move
tz_disabled to mtk_hdmi where it's used.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 19 ---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h | 1 -
.../gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c| 1 -
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index f2e9b429960b..d44348c7ecbe 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -145,11 +145,16 @@ struct hdmi_audio_param {
struct hdmi_codec_params codec_params;
};
+struct mtk_hdmi_conf {
+ bool tz_disabled;
+};
+
struct mtk_hdmi {
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
struct drm_connector conn;
struct device *dev;
+ const struct mtk_hdmi_conf *conf;
struct phy *phy;
struct device *cec_dev;
struct i2c_adapter *ddc_adpt;
@@ -234,7 +239,6 @@ static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi,
bool black)
static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
{
struct arm_smccc_res res;
- struct mtk_hdmi_phy *hdmi_phy = phy_get_drvdata(hdmi->phy);
/*
* MT8173 HDMI hardware has an output control bit to enable/disable HDMI
@@ -242,7 +246,7 @@ static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi
*hdmi, bool enable)
* The ARM trusted firmware provides an API for the HDMI driver to set
* this control bit to enable HDMI output in supervisor mode.
*/
- if (hdmi_phy->conf && hdmi_phy->conf->tz_disabled)
+ if (hdmi->conf && hdmi->conf->tz_disabled)
regmap_update_bits(hdmi->sys_regmap,
hdmi->sys_offset + HDMI_SYS_CFG20,
0x80008005, enable ? 0x8005 : 0x8000);
@@ -1723,6 +1727,7 @@ static int mtk_drm_hdmi_probe(struct platform_device
*pdev)
return -ENOMEM;
hdmi->dev = dev;
+ hdmi->conf = of_device_get_match_data(dev);
ret = mtk_hdmi_dt_parse_pdata(hdmi, pdev);
if (ret)
@@ -1803,8 +1808,16 @@ static int mtk_hdmi_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_hdmi_pm_ops,
mtk_hdmi_suspend, mtk_hdmi_resume);
+static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = {
+ .tz_disabled = true,
+};
+
static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
- { .compatible = "mediatek,mt8173-hdmi", },
+ { .compatible = "mediatek,mt2701-hdmi",
+ .data = _hdmi_conf_mt2701,
+ },
+ { .compatible = "mediatek,mt8173-hdmi",
+ },
{}
};
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index 2d8b3182470d..fc1c2efd1128 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -20,7 +20,6 @@
struct mtk_hdmi_phy;
struct mtk_hdmi_phy_conf {
- bool tz_disabled;
unsigned long flags;
const struct clk_ops *hdmi_phy_clk_ops;
void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index d3cc4022e988..99fe05cd3598 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -237,7 +237,6 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
}
struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
- .tz_disabled = true,
.flags = CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
--
2.17.1
[PATCH v5 0/4] Move Mediatek HDMI PHY driver from DRM folder to PHY folder
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Changes in v5:
- Fixup indent in Kconfig.
- Refine config help message.
- Refine Makefile.
Changes in v4:
- Rebase onto 5.9-rc1
- Remove mtk_hdmi_conf_mt8173.
Changes in v3:
- Modify [PATCH v2 3/4] prefix.
Changes in v2:
- include module.h in mtk_hdmi.c
CK Hu (3):
drm/mediatek: Move tz_disabled from mtk_hdmi_phy to mtk_hdmi driver
drm/mediatek: Separate mtk_hdmi_phy to an independent module
phy: mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek
folder
Chun-Kuang Hu (1):
MAINTAINERS: add files for Mediatek DRM drivers
MAINTAINERS | 1 +
drivers/gpu/drm/mediatek/Kconfig | 2 +-
drivers/gpu/drm/mediatek/Makefile | 5 +
drivers/gpu/drm/mediatek/mtk_hdmi.c | 21 +++
drivers/gpu/drm/mediatek/mtk_hdmi.h | 1 -
drivers/phy/mediatek/Kconfig | 7 +++
drivers/phy/mediatek/Makefile | 5 +
.../mediatek/phy-mtk-hdmi-mt2701.c} | 3 +--
.../mediatek/phy-mtk-hdmi-mt8173.c} | 2 +-
.../mediatek/phy-mtk-hdmi.c} | 3 ++-
.../mediatek/phy-mtk-hdmi.h} | 2 --
11 files changed, 36 insertions(+), 16 deletions(-)
rename drivers/{gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi-mt2701.c} (99%)
rename drivers/{gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi-mt8173.c} (99%)
rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi.c} (98%)
rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.h =>
phy/mediatek/phy-mtk-hdmi.h} (95%)
--
2.17.1
[PATCH v5 4/4] MAINTAINERS: add files for Mediatek DRM drivers
Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers' information. Signed-off-by: Chun-Kuang Hu Reviewed-by: Matthias Brugger --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index deaafb617361..191bacf02209 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5793,6 +5793,7 @@ L:dri-de...@lists.freedesktop.org S: Supported F: Documentation/devicetree/bindings/display/mediatek/ F: drivers/gpu/drm/mediatek/ +F: drivers/phy/mediatek/phy-mtk-hdmi* DRM DRIVERS FOR NVIDIA TEGRA M: Thierry Reding -- 2.17.1
[PATCH v5 2/4] drm/mediatek: Separate mtk_hdmi_phy to an independent module
From: CK Hu
mtk_hdmi_phy is a part of mtk_hdmi module, but phy driver should be an
independent module rather than be part of drm module, so separate the phy
driver to an independent module.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Kconfig| 9 -
drivers/gpu/drm/mediatek/Makefile | 11 +++
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
drivers/gpu/drm/mediatek/mtk_hdmi.h | 1 -
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c | 1 +
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h | 1 -
6 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index aa74aac3cbcc..6363f2c1cdbc 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -24,6 +24,13 @@ config DRM_MEDIATEK_HDMI
tristate "DRM HDMI Support for Mediatek SoCs"
depends on DRM_MEDIATEK
select SND_SOC_HDMI_CODEC if SND_SOC
- select GENERIC_PHY
+ select PHY_MTK_HDMI
help
DRM/KMS HDMI driver for Mediatek SoCs
+
+config PHY_MTK_HDMI
+ tristate "MediaTek HDMI-PHY Driver"
+ depends on ARCH_MEDIATEK && OF
+ select GENERIC_PHY
+ help
+ Support HDMI PHY for Mediatek SoCs.
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index b7a82ed5788f..fcbef23aa6ce 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -19,9 +19,12 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
mediatek-drm-hdmi-objs := mtk_cec.o \
mtk_hdmi.o \
- mtk_hdmi_ddc.o \
- mtk_mt2701_hdmi_phy.o \
- mtk_mt8173_hdmi_phy.o \
- mtk_hdmi_phy.o
+ mtk_hdmi_ddc.o
obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
+
+phy-mtk-hdmi-drv-objs := mtk_hdmi_phy.o \
+mtk_mt2701_hdmi_phy.o \
+mtk_mt8173_hdmi_phy.o
+
+obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index d44348c7ecbe..0ed7b0b1a022 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1832,7 +1833,6 @@ static struct platform_driver mtk_hdmi_driver = {
};
static struct platform_driver * const mtk_hdmi_drivers[] = {
- _hdmi_phy_driver,
_hdmi_ddc_driver,
_cec_driver,
_hdmi_driver,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.h
b/drivers/gpu/drm/mediatek/mtk_hdmi.h
index bb3653de6bd1..472bf141c92b 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.h
@@ -5,7 +5,6 @@
*/
#ifndef _MTK_HDMI_CTRL_H
#define _MTK_HDMI_CTRL_H
-#include "mtk_hdmi_phy.h"
struct platform_driver;
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 5223498502c4..fe022acddbef 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -205,6 +205,7 @@ struct platform_driver mtk_hdmi_phy_driver = {
.of_match_table = mtk_hdmi_phy_match,
},
};
+module_platform_driver(mtk_hdmi_phy_driver);
MODULE_DESCRIPTION("MediaTek HDMI PHY Driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index fc1c2efd1128..b13e1d5f8e78 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -49,7 +49,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
u32 val, u32 mask);
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
-extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
--
2.17.1
[PATCH v5 3/4] phy: mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek folder
From: CK Hu
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Kconfig | 7 ---
drivers/gpu/drm/mediatek/Makefile | 6 --
drivers/phy/mediatek/Kconfig | 7 +++
drivers/phy/mediatek/Makefile | 5 +
.../mediatek/phy-mtk-hdmi-mt2701.c}| 2 +-
.../mediatek/phy-mtk-hdmi-mt8173.c}| 2 +-
.../mtk_hdmi_phy.c => phy/mediatek/phy-mtk-hdmi.c} | 2 +-
.../mtk_hdmi_phy.h => phy/mediatek/phy-mtk-hdmi.h} | 0
8 files changed, 15 insertions(+), 16 deletions(-)
rename drivers/{gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi-mt2701.c} (99%)
rename drivers/{gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi-mt8173.c} (99%)
rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi.c} (99%)
rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.h =>
phy/mediatek/phy-mtk-hdmi.h} (100%)
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index 6363f2c1cdbc..65cd03a4be29 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -27,10 +27,3 @@ config DRM_MEDIATEK_HDMI
select PHY_MTK_HDMI
help
DRM/KMS HDMI driver for Mediatek SoCs
-
-config PHY_MTK_HDMI
- tristate "MediaTek HDMI-PHY Driver"
- depends on ARCH_MEDIATEK && OF
- select GENERIC_PHY
- help
- Support HDMI PHY for Mediatek SoCs.
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index fcbef23aa6ce..77b0fd86063d 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -22,9 +22,3 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
mtk_hdmi_ddc.o
obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
-
-phy-mtk-hdmi-drv-objs := mtk_hdmi_phy.o \
-mtk_mt2701_hdmi_phy.o \
-mtk_mt8173_hdmi_phy.o
-
-obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index dee757c957f2..50c5e9306e19 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -35,3 +35,10 @@ config PHY_MTK_XSPHY
Enable this to support the SuperSpeedPlus XS-PHY transceiver for
USB3.1 GEN2 controllers on MediaTek chips. The driver supports
multiple USB2.0, USB3.1 GEN2 ports.
+
+config PHY_MTK_HDMI
+ tristate "MediaTek HDMI-PHY Driver"
+ depends on ARCH_MEDIATEK && OF
+ select GENERIC_PHY
+ help
+ Support HDMI PHY for Mediatek SoCs.
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index 08a8e6a97b1e..6325e38709ed 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -6,3 +6,8 @@
obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o
obj-$(CONFIG_PHY_MTK_XSPHY)+= phy-mtk-xsphy.o
+
+phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
+phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
+phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8173.o
+obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
similarity index 99%
rename from drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
rename to drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
index 99fe05cd3598..a6cb1dea3d0c 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
@@ -4,7 +4,7 @@
* Author: Chunhui Dai
*/
-#include "mtk_hdmi_phy.h"
+#include "phy-mtk-hdmi.h"
#define HDMI_CON0 0x00
#define RG_HDMITX_DRV_IBIAS0
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
similarity index 99%
rename from drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
rename to drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
index 827b93786fac..6cdfdf5a698a 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
@@ -4,7 +4,7 @@
* Author: Jie Qiu
*/
-#include "mtk_hdmi_phy.h"
+#include "phy-mtk-hdmi.h"
#define HDMI_CON0 0x00
#define RG_HDMITX_PLL_EN BIT(31)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/phy/mediatek/phy-mtk-hdmi.c
similarity index 99%
rename from drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
rename to drivers/phy/mediatek/phy-mtk-hdmi.c
index fe022acddbef..8fc83f01a720 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++
Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD
On Sat, Aug 15, 2020 at 09:33:36PM +0200, Andreas Kemnade wrote:
> This adds a devicetree for the Tolino Shine 2 HD Ebook reader. It is based
> on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL
> SoC.
>
> Expected to work:
> - Buttons
> - Wifi
> - Touchscreen
> - LED
> - uSD
> - USB
> - RTC
>
> Not working due to missing drivers:
> - Backlight (requires NTXEC driver)
> - EPD
>
> Not working due to unknown reasons:
> - deep sleep (echo standby >/sys/power/state works),
> wakeup fails when imx_gpc_pre_suspend(true) was called.
>
> Signed-off-by: Andreas Kemnade
> ---
> Reason for RFC: The suspend trouble might be caused by bad devicetree.
> But as the devicetree is already useful I decided to submit it.
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 582 +++
> 2 files changed, 583 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e6a1cac0bfc7..c65fa3852246 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -581,6 +581,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6qp-zii-rdu2.dtb
> dtb-$(CONFIG_SOC_IMX6SL) += \
> imx6sl-evk.dtb \
> + imx6sl-tolino-shine2hd.dtb \
> imx6sl-tolino-shine3.dtb \
> imx6sl-warp.dtb
> dtb-$(CONFIG_SOC_IMX6SLL) += \
> diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> new file mode 100644
> index ..7b28e19a1d98
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> @@ -0,0 +1,582 @@
> +// SPDX-License-Identifier: (GPL-2.0)
> +/*
> + * Device tree for the Tolino Shine 2 HD ebook reader
> + *
> + * Name on mainboard is: 37NB-E60QF0+4A2
> + * Serials start with: E60QF2
> + *
> + * Copyright 2020 Andreas Kemnade
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include "imx6sl.dtsi"
> +
> +/ {
> + model = "Tolino Shine 2 HD";
> + compatible = "kobo,tolino-shine2hd", "fsl,imx6sl";
> +
> + chosen {
> + stdout-path =
> + };
> +
> + gpio_keys: gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_keys>;
> +
> + cover {
> + label = "Cover";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + linux,input-type = ;
> + wakeup-source;
> + };
> +
> + fl {
> + label = "Frontlight";
> + gpios = < 26 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + home {
> + label = "Home";
> + gpios = < 25 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + power {
> + label = "Power";
> + gpios = < 8 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + wakeup-source;
> + };
> + };
> +
> + leds: leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_led>;
> +
> + on {
> + label = "tolinoshine2hd:white:on";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "timer";
> + };
> + };
> +
> + memory@8000 {
> + device_type = "memory";
> + reg = <0x8000 0x2000>;
> + };
> +
> + reg_wifi: regulator-wifi {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <_wifi_power>;
> + regulator-name = "SD3_SPWR";
> + regulator-min-microvolt = <300>;
> + regulator-max-microvolt = <300>;
> + gpio = < 29 GPIO_ACTIVE_HIGH>;
Missing enable-active-high?
> + };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <_wifi_reset>;
> + post-power-on-delay-ms = <20>;
> + reset-gpios = < 0 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> + {
> + pinctrl-names = "default","sleep";
> + pinctrl-0 = <_i2c1>;
> + pinctrl-1 = <_i2c1_sleep>;
> + status = "okay";
> +
> + /* TODO: embedded controller at 0x43 (driver missing) */
> +
> +};
> +
> + {
> + pinctrl-names = "default","sleep";
> + pinctrl-0 = <_i2c2>;
> + pinctrl-1 = <_i2c2_sleep>;
> + clock-frequency = <10>;
> + status = "okay";
> +
> + zforce: touchscreen@50 {
> + compatible = "neonode,zforce";
> + pinctrl-names = "default";
> + pinctrl-0 = <_zforce>;
> + reg = <0x50>;
> +
Re: [PATCH] arm64: dts: imx8mp: Update pinfunc header file
On Fri, Aug 14, 2020 at 05:27:19PM +0800, Anson Huang wrote: > Update some pins' name and adjust pin options to i.MX8MP pinfunc > header file according to latest reference manual. > > Signed-off-by: Anson Huang Will this break any existing DTs? Shawn > --- > arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h | 360 > - > 1 file changed, 114 insertions(+), 246 deletions(-) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h > b/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h > index 319ab34..0fef066 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h > +++ b/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h > @@ -11,384 +11,318 @@ > * > */ > #define MX8MP_IOMUXC_GPIO1_IO00__GPIO1_IO00 0x014 > 0x274 0x000 0x0 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO00__CCMSRCGPCMIX_ENET_PHY_REF_CLK_ROOT 0x014 > 0x274 0x000 0x1 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO00__MEDIAMIX_ISP_FL_TRIG_0 0x014 > 0x274 0x5D4 0x3 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO00__ANAMIX_REF_CLK_32K 0x014 > 0x274 0x000 0x5 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO00__CCMSRCGPCMIX_EXT_CLK1 0x014 > 0x274 0x000 0x6 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO00__SJC_FAIL0x014 > 0x274 0x000 0x7 0x0 > +#define MX8MP_IOMUXC_GPIO1_IO00__CCM_ENET_PHY_REF_CLK_ROOT 0x014 > 0x274 0x000 0x1 0x0 > +#define MX8MP_IOMUXC_GPIO1_IO00__ISP_FL_TRIG_0 0x014 > 0x274 0x5D4 0x3 0x0 > +#define MX8MP_IOMUXC_GPIO1_IO00__CCM_EXT_CLK10x014 > 0x274 0x000 0x6 0x0 > #define MX8MP_IOMUXC_GPIO1_IO01__GPIO1_IO01 0x018 > 0x278 0x000 0x0 0x0 > #define MX8MP_IOMUXC_GPIO1_IO01__PWM1_OUT0x018 > 0x278 0x000 0x1 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO01__MEDIAMIX_ISP_SHUTTER_TRIG_0 0x018 > 0x278 0x5DC 0x3 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO01__ANAMIX_REF_CLK_24M 0x018 > 0x278 0x000 0x5 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO01__CCMSRCGPCMIX_EXT_CLK2 0x018 > 0x278 0x000 0x6 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO01__SJC_ACTIVE 0x018 > 0x278 0x000 0x7 0x0 > +#define MX8MP_IOMUXC_GPIO1_IO01__ISP_SHUTTER_TRIG_0 0x018 > 0x278 0x5DC 0x3 0x0 > +#define MX8MP_IOMUXC_GPIO1_IO01__CCM_EXT_CLK20x018 > 0x278 0x000 0x6 0x0 > #define MX8MP_IOMUXC_GPIO1_IO02__GPIO1_IO02 0x01C > 0x27C 0x000 0x0 0x0 > #define MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_B0x01C > 0x27C 0x000 0x1 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO02__MEDIAMIX_ISP_FLASH_TRIG_0 0x01C > 0x27C 0x000 0x3 0x0 > +#define MX8MP_IOMUXC_GPIO1_IO02__ISP_FLASH_TRIG_00x01C > 0x27C 0x000 0x3 0x0 > #define MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_ANY 0x01C > 0x27C 0x000 0x5 0x0 > #define MX8MP_IOMUXC_GPIO1_IO02__SJC_DE_B0x01C > 0x27C 0x000 0x7 0x0 > #define MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x020 > 0x280 0x000 0x0 0x0 > #define MX8MP_IOMUXC_GPIO1_IO03__USDHC1_VSELECT 0x020 > 0x280 0x000 0x1 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO03__MEDIAMIX_ISP_PRELIGHT_TRIG_00x020 > 0x280 0x000 0x3 0x0 > +#define MX8MP_IOMUXC_GPIO1_IO03__ISP_PRELIGHT_TRIG_0 0x020 > 0x280 0x000 0x3 0x0 > #define MX8MP_IOMUXC_GPIO1_IO03__SDMA1_EXT_EVENT00 0x020 > 0x280 0x000 0x5 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO03__ANAMIX_XTAL_OK 0x020 > 0x280 0x000 0x6 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO03__SJC_DONE0x020 > 0x280 0x000 0x7 0x0 > #define MX8MP_IOMUXC_GPIO1_IO04__GPIO1_IO04 0x024 > 0x284 0x000 0x0 0x0 > #define MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x024 > 0x284 0x000 0x1 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO04__MEDIAMIX_ISP_SHUTTER_OPEN_0 0x024 > 0x284 0x000 0x3 0x0 > +#define MX8MP_IOMUXC_GPIO1_IO04__ISP_SHUTTER_OPEN_0 0x024 > 0x284 0x000 0x3 0x0 > #define MX8MP_IOMUXC_GPIO1_IO04__SDMA1_EXT_EVENT01 0x024 > 0x284 0x000 0x5 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO04__ANAMIX_XTAL_OK_LV 0x024 > 0x284 0x000 0x6 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO04__USDHC1_TEST_TRIG0x024 > 0x284 0x000 0x7 0x0 > #define MX8MP_IOMUXC_GPIO1_IO05__GPIO1_IO05 0x028 > 0x288 0x000 0x0 0x0 > #define MX8MP_IOMUXC_GPIO1_IO05__M7_NMI 0x028 > 0x288 0x000 0x1 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO05__MEDIAMIX_ISP_FL_TRIG_1 0x028 > 0x288 0x5D8 0x3 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO05__CCMSRCGPCMIX_PMIC_READY 0x028 > 0x288 0x554 0x5 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO05__CCMSRCGPCMIX_INT_BOOT 0x028 > 0x288 0x000 0x6 0x0 > -#define MX8MP_IOMUXC_GPIO1_IO05__USDHC2_TEST_TRIG
[PATCH 1/2] media: uvcvideo: Ensure all probed info is returned to v4l2
bFrameIndex and bFormatIndex can be negotiated by the camera during
probing, resulting in the camera choosing a different format than
expected. v4l2 can already accommodate such changes, but the code was
not updating the proper fields.
Without such a change, v4l2 would potentially interpret the payload
incorrectly, causing corrupted output. This was happening on the
Elgato HD60 S+, which currently always renegotiates to format 1.
As an aside, the Elgato firmware is buggy and should not be renegotating,
but it is still a valid thing for the camera to do. Both macOS and Windows
will properly probe and read uncorrupted images from this camera.
With this change, both qv4l2 and chromium can now read uncorrupted video
from the Elgato HD60 S+.
Signed-off-by: Adam Goode
---
drivers/media/usb/uvc/uvc_v4l2.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index 0335e69b70ab..7f14096cb44d 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -247,11 +247,37 @@ static int uvc_v4l2_try_format(struct uvc_streaming
*stream,
if (ret < 0)
goto done;
+ /* After the probe, update fmt with the values returned from
+* negotiation with the device.
+*/
+ for (i = 0; i < stream->nformats; ++i) {
+ if (probe->bFormatIndex == stream->format[i].index) {
+ format = >format[i];
+ break;
+ }
+ }
+ if (i == stream->nformats) {
+ uvc_trace(UVC_TRACE_FORMAT, "Unknown bFormatIndex %u.\n",
+ probe->bFormatIndex);
+ return -EINVAL;
+ }
+ for (i = 0; i < format->nframes; ++i) {
+ if (probe->bFrameIndex == format->frame[i].bFrameIndex) {
+ frame = >frame[i];
+ break;
+ }
+ }
+ if (i == format->nframes) {
+ uvc_trace(UVC_TRACE_FORMAT, "Unknown bFrameIndex %u.\n",
+ probe->bFrameIndex);
+ return -EINVAL;
+ }
fmt->fmt.pix.width = frame->wWidth;
fmt->fmt.pix.height = frame->wHeight;
fmt->fmt.pix.field = V4L2_FIELD_NONE;
fmt->fmt.pix.bytesperline = uvc_v4l2_get_bytesperline(format, frame);
fmt->fmt.pix.sizeimage = probe->dwMaxVideoFrameSize;
+ fmt->fmt.pix.pixelformat = format->fcc;
fmt->fmt.pix.colorspace = format->colorspace;
if (uvc_format != NULL)
--
2.28.0.297.g1956fa8f8d-goog
[PATCH 2/2] media: uvcvideo: Convey full ycbcr colorspace information to v4l2
The Color Matching Descriptor has been present in USB cameras since
the original version of UVC, but it has never been fully used
in Linux.
This change informs V4L2 of all of the critical colorspace parameters:
colorspace (called "color primaries" in UVC), transfer function
(called "transfer characteristics" in UVC), ycbcr encoding (called
"matrix coefficients" in UVC), and quantization, which is always
LIMITED for UVC, see section 2.26 in USB_Video_FAQ_1.5.pdf.
The quantization is the most important improvement for this patch,
because V4L2 will otherwise interpret MJPEG as FULL range. Web browsers
such as Chrome and Firefox already ignore V4L2's quantization for USB
devices and use the correct LIMITED value, but other programs such
as qv4l2 will incorrectly interpret the output of MJPEG from USB
cameras without this change.
Signed-off-by: Adam Goode
---
drivers/media/usb/uvc/uvc_driver.c | 52 +++---
drivers/media/usb/uvc/uvc_v4l2.c | 6
drivers/media/usb/uvc/uvcvideo.h | 5 ++-
3 files changed, 58 insertions(+), 5 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 431d86e1c94b..c0c81b089b7d 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -248,10 +248,10 @@ static struct uvc_format_desc *uvc_format_by_guid(const
u8 guid[16])
return NULL;
}
-static u32 uvc_colorspace(const u8 primaries)
+static enum v4l2_colorspace uvc_colorspace(const u8 primaries)
{
- static const u8 colorprimaries[] = {
- 0,
+ static const enum v4l2_colorspace colorprimaries[] = {
+ V4L2_COLORSPACE_DEFAULT, /* Unspecified */
V4L2_COLORSPACE_SRGB,
V4L2_COLORSPACE_470_SYSTEM_M,
V4L2_COLORSPACE_470_SYSTEM_BG,
@@ -262,7 +262,43 @@ static u32 uvc_colorspace(const u8 primaries)
if (primaries < ARRAY_SIZE(colorprimaries))
return colorprimaries[primaries];
- return 0;
+ return V4L2_COLORSPACE_DEFAULT; /* Reserved */
+}
+
+static enum v4l2_xfer_func uvc_xfer_func(const u8 transfer_characteristics)
+{
+ static const enum v4l2_xfer_func xfer_funcs[] = {
+ V4L2_XFER_FUNC_DEFAULT, /* Unspecified */
+ V4L2_XFER_FUNC_709,
+ V4L2_XFER_FUNC_709, /* BT.470-2 M */
+ V4L2_XFER_FUNC_709, /* BT.470-2 B, G */
+ V4L2_XFER_FUNC_709, /* SMPTE 170M */
+ V4L2_XFER_FUNC_SMPTE240M,
+ V4L2_XFER_FUNC_NONE, /* Linear (V = Lc) */
+ V4L2_XFER_FUNC_SRGB,
+ };
+
+ if (transfer_characteristics < ARRAY_SIZE(xfer_funcs))
+ return xfer_funcs[transfer_characteristics];
+
+ return V4L2_XFER_FUNC_DEFAULT; /* Reserved */
+}
+
+static enum v4l2_ycbcr_encoding uvc_ycbcr_enc(const u8 matrix_coefficients)
+{
+ static const enum v4l2_ycbcr_encoding ycbcr_encs[] = {
+ V4L2_YCBCR_ENC_DEFAULT, /* Unspecified */
+ V4L2_YCBCR_ENC_709,
+ V4L2_YCBCR_ENC_601, /* FCC */
+ V4L2_YCBCR_ENC_601, /* BT.470-2 B, G */
+ V4L2_YCBCR_ENC_601, /* SMPTE 170M */
+ V4L2_YCBCR_ENC_SMPTE240M,
+ };
+
+ if (matrix_coefficients < ARRAY_SIZE(ycbcr_encs))
+ return ycbcr_encs[matrix_coefficients];
+
+ return V4L2_YCBCR_ENC_DEFAULT; /* Reserved */
}
/* Simplify a fraction using a simple continued fraction decomposition. The
@@ -704,6 +740,14 @@ static int uvc_parse_format(struct uvc_device *dev,
}
format->colorspace = uvc_colorspace(buffer[3]);
+ format->xfer_func = uvc_xfer_func(buffer[4]);
+ format->ycbcr_enc = uvc_ycbcr_enc(buffer[5]);
+ /* All USB YCbCr encodings use LIMITED range as of UVC 1.5.
+* This is true even for MJPEG, which V4L2 otherwise assumes to
+* be FULL.
+* See section 2.26 in USB_Video_FAQ_1.5.pdf.
+*/
+ format->quantization = V4L2_QUANTIZATION_LIM_RANGE;
buflen -= buffer[0];
buffer += buffer[0];
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index 7f14096cb44d..79daf46b3dcd 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -279,6 +279,9 @@ static int uvc_v4l2_try_format(struct uvc_streaming *stream,
fmt->fmt.pix.sizeimage = probe->dwMaxVideoFrameSize;
fmt->fmt.pix.pixelformat = format->fcc;
fmt->fmt.pix.colorspace = format->colorspace;
+ fmt->fmt.pix.xfer_func = format->xfer_func;
+ fmt->fmt.pix.ycbcr_enc = format->ycbcr_enc;
+ fmt->fmt.pix.quantization = format->quantization;
if (uvc_format != NULL)
*uvc_format = format;
@@ -315,6 +318,9 @@ static int uvc_v4l2_get_format(struct
Re: [PATCH] x86: work around clang IAS bug referencing __force_order
On Sat, Aug 22, 2020 at 05:10:21PM -0700, Linus Torvalds wrote: > On Sat, Aug 22, 2020 at 4:11 PM Arvind Sankar wrote: > > > > Actually, is a memory clobber required for correctness? Memory accesses > > probably shouldn't be reordered across a CRn write. Is asm volatile > > enough to stop that or do you need a memory clobber? > > You do need a memory clobber if you really care about ordering wrt > normal memory references. > > That said, I'm not convinced we do care here. Normal memory accesses > (as seen by the compiler) should be entirely immune to any changes we > do wrt CRx registers. > > Because code that really fundamentally changes kernel mappings or > access rules is already written in low-level assembler (eg the entry > routines or bootup). > > Anything that relies on the more subtle changes (ie user space > accesses etc) should already be ordered by other things - usually by > the fact that they are also "asm volatile". > > But hey, maybe somebody can come up with an exception to that. > > Linus I'm sure in practice it can't happen, as any memory accesses happening immediately around write_cr3() are probably mapped the same in both pagetables anyway, but eg cleanup_trampoline() in arch/x86/boot/compressed/pgtable_64.c: memcpy(pgtable, trampoline_pgtable, PAGE_SIZE); native_write_cr3((unsigned long)pgtable); There'll probably be trouble if the compiler were to reverse the order here. We could actually make write_crn() use memory clobber, and read_crn() use "m"(*(int *)0x1000) as an input operand. A bit hacky, but no global variable needed. And maybe read_crn() doesn't even have to be volatile. Also, if we look at the rdmsr/wrmsr pair, there's no force_order equivalent AFAICT. wrmsr has a memory clobber, but the asm volatile-ness is the only thing enforcing read/write ordering.
Re: [RFC v7 00/19] lockdep: Support deadlock detection for recursive read locks
On Fri, Aug 21, 2020 at 09:56:41PM +0200, Peter Zijlstra wrote: > On Fri, Aug 07, 2020 at 03:42:19PM +0800, Boqun Feng wrote: > > Hi Peter and Waiman, > > > > As promised, this is the updated version of my previous lockdep patchset > > for recursive read lock support. It's based on v5.8. Previous versions > > can be found at: > > OK, this all looks really nice. > > I've stuck it in my locking/core branch for testing, I've had to fix a > few minor rejects (my bad for being to slow), made a few minor edits and > fixed that one masking thing. > Thanks! Regards, Boqun > It seems to boot with the selftests all green, haven't done much else > with it yet, we'll see. > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/core > > Thanks!
[tip:x86/misc] BUILD SUCCESS c31feed8461fb8648075ba9b53d9e527d530972f
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/misc branch HEAD: c31feed8461fb8648075ba9b53d9e527d530972f x86/msr: Make source of unrecognised MSR writes unambiguous elapsed time: 723m configs tested: 30 configs skipped: 47 The following configs have been built successfully. More configs may be tested in the coming days. sh kfr2r09-romimage_defconfig sh urquell_defconfig parisc alldefconfig mips capcella_defconfig m68kdefconfig arm stm32_defconfig arm mv78xx0_defconfig arm s3c2410_defconfig c6xevmc6474_defconfig powerpc mpc885_ads_defconfig mips jazz_defconfig sh se7712_defconfig armmini2440_defconfig mips ath79_defconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig x86_64 rhel-8.3 x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] Bluetooth: fix "list_add double add" in hci_conn_complete_evt
When two HCI_EV_CONN_COMPLETE event packets with status=0 of the same
HCI connection are received, device_add would be called twice which
leads to kobject_add being called twice. Thus duplicate
(struct hci_conn *conn)->dev.kobj.entry would be inserted into
(struct hci_conn *conn)->dev.kobj.kset->list.
This issue can be fixed by checking (struct hci_conn *conn)->debugfs.
If it's not NULL, it means the HCI connection has been completed and we
won't duplicate the work as for processing the first
HCI_EV_CONN_COMPLETE event.
Reported-and-tested-by: syzbot+dd768a260f7358adb...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=dd768a260f7358adbaf9
Signed-off-by: Coiby Xu
---
net/bluetooth/hci_event.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 4b7fc430793c..1233739ce760 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2605,6 +2605,11 @@ static void hci_conn_complete_evt(struct hci_dev *hdev,
struct sk_buff *skb)
}
if (!ev->status) {
+ if (conn->debugfs) {
+ bt_dev_err(hdev, "The connection has been completed");
+ goto unlock;
+ }
+
conn->handle = __le16_to_cpu(ev->handle);
if (conn->type == ACL_LINK) {
--
2.28.0
Re: [PATCH v33 5/6] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node
On Wed, Aug 12, 2020 at 02:50:19PM -0500, Dan Murphy wrote: > Add the reg property to each channel node. This update is > to accommodate the multicolor framework. In addition to the > accommodation this allows the LEDs to be placed on any channel > and allow designs to skip channels as opposed to requiring > sequential order. > > Acked-by: Pavel Machek > Signed-off-by: Dan Murphy > CC: Shawn Guo > CC: Sascha Hauer > CC: Pengutronix Kernel Team > CC: Fabio Estevam > CC: NXP Linux Team Applied, thanks.
Re: [PATCH] usb: storage: initialize variable
On Sat, Aug 22, 2020 at 02:18:39PM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> clang static analysis reports this representative problem
>
> transport.c:495:15: warning: Assigned value is garbage or
> undefined
> length_left -= partial;
>^ ~~~
> partial is set only when usb_stor_bulk_transfer_sglist()
> is successful.
>
> So initialize to partial to 0.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Tom Rix
> ---
> drivers/usb/storage/transport.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
> index 238a8088e17f..ce920851b1f2 100644
> --- a/drivers/usb/storage/transport.c
> +++ b/drivers/usb/storage/transport.c
> @@ -461,7 +461,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
> *us, unsigned int pipe,
> int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> struct scsi_cmnd* srb)
> {
> - unsigned int partial;
> + unsigned int partial = 0;
> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> scsi_sg_count(srb), scsi_bufflen(srb),
> );
> @@ -484,7 +484,7 @@ int usb_stor_bulk_transfer_sg(struct us_data* us,
> unsigned int pipe,
> void *buf, unsigned int length_left, int use_sg, int *residual)
> {
> int result;
> - unsigned int partial;
> + unsigned int partial = 0;
>
> /* are we scatter-gathering? */
> if (use_sg) {
Yes, this is a bug. But the right way to fix it is to change
usb_stor_bulk_transfer_sglist(): Make it store 0 to *act_len at the
start.
That way you change only one localized piece of code, instead of
changing multiple callers and leaving a possibility of more errors being
added in the future.
Alan Stern
Re: [PATCH v3 09/10] gen_compile_commands: remove the warning about too few .cmd files
On Sat, Aug 22, 2020 at 7:56 AM Masahiro Yamada wrote: > > This warning was useful when users previously needed to manually > build the kernel and run this script. > > Now you can simply do 'make compile_commands.json', which updates > all the necessary build artifacts and automatically creates the > compilation database. There is no more worry for a mistake like > "Oh, I forgot to build the kernel". > > Now, this warning is rather annoying. > > You can create compile_commands.json for an external module: > > $ make M=/path/to/your/external/module compile_commands.json > > Then, this warning is displayed since there are usually less than > 300 files in a single module. > > Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers > --- > > Changes in v3: > - New patch > > scripts/gen_compile_commands.py | 10 -- > 1 file changed, 10 deletions(-) > > diff --git a/scripts/gen_compile_commands.py b/scripts/gen_compile_commands.py > index f370375b2f70..1de745577e6d 100755 > --- a/scripts/gen_compile_commands.py > +++ b/scripts/gen_compile_commands.py > @@ -21,11 +21,6 @@ _FILENAME_PATTERN = r'^\..*\.cmd$' > _LINE_PATTERN = r'^cmd_[^ ]*\.o := (.* )([^ ]*\.c)$' > _VALID_LOG_LEVELS = ['DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL'] > > -# A kernel build generally has over 2000 entries in its compile_commands.json > -# database. If this code finds 300 or fewer, then warn the user that they > might > -# not have all the .cmd files, and they might need to compile the kernel. > -_LOW_COUNT_THRESHOLD = 300 > - > > def parse_arguments(): > """Sets up and parses command-line arguments. > @@ -236,11 +231,6 @@ def main(): > with open(output, 'wt') as f: > json.dump(compile_commands, f, indent=2, sort_keys=True) > > -count = len(compile_commands) > -if count < _LOW_COUNT_THRESHOLD: > -logging.warning( > -'Found %s entries. Have you compiled the kernel?', count) > - > > if __name__ == '__main__': > main() > -- > 2.25.1 > -- Thanks, ~Nick Desaulniers
Re: [PATCH v3 07/10] gen_compile_commands: support *.o, *.a, modules.order in positional argument
On Sat, Aug 22, 2020 at 7:56 AM Masahiro Yamada wrote:
>
> This script currently searches the specified directory for .cmd files.
> One drawback is it may contain stale .cmd files after you rebuild the
> kernel several times without 'make clean'.
>
> This commit supports *.o, *.a, and modules.order as positional
> parameters. If such files are given, they are parsed to collect
> associated .cmd files. I added a generator helper for each of them.
>
> This feature is useful to get the list of active .cmd files from the
> last build, and will be used by the next commit to wire up the
> compile_commands.json rule to the Makefile.
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Nick Desaulniers
> ---
>
> Changes in v3:
> - Use 'llvm-ar' instead of 'ar' for the default of -a option
> - Fix the corrupted comment block
>
> Changes in v2:
> - Separate the file parser into generator functions
> - Use 'obj' instead of 'object' because 'object' is a built-in function
> - I think using 'file' is OK because it is not a built-in function in
> Python3
> (https://docs.python.org/3/library/functions.html)
> Anyway, the variable 'file' is no longer used in this version
> - Keep the previous work-flow to allow to search the given directory
>
> scripts/gen_compile_commands.py | 100 ++--
> 1 file changed, 96 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/gen_compile_commands.py b/scripts/gen_compile_commands.py
> index e45f17be8817..f370375b2f70 100755
> --- a/scripts/gen_compile_commands.py
> +++ b/scripts/gen_compile_commands.py
> @@ -12,6 +12,7 @@ import json
> import logging
> import os
> import re
> +import subprocess
>
> _DEFAULT_OUTPUT = 'compile_commands.json'
> _DEFAULT_LOG_LEVEL = 'WARNING'
> @@ -32,8 +33,9 @@ def parse_arguments():
> Returns:
> log_level: A logging level to filter log output.
> directory: The work directory where the objects were built.
> +ar: Command used for parsing .a archives.
> output: Where to write the compile-commands JSON file.
> -paths: The list of directories to handle to find .cmd files.
> +paths: The list of files/directories to handle to find .cmd files.
> """
> usage = 'Creates a compile_commands.json database from kernel .cmd files'
> parser = argparse.ArgumentParser(description=usage)
> @@ -53,12 +55,21 @@ def parse_arguments():
> parser.add_argument('--log_level', choices=_VALID_LOG_LEVELS,
> default=_DEFAULT_LOG_LEVEL, help=log_level_help)
>
> +ar_help = 'command used for parsing .a archives'
> +parser.add_argument('-a', '--ar', type=str, default='llvm-ar',
> help=ar_help)
> +
> +paths_help = ('directories to search or files to parse '
> + '(files should be *.o, *.a, or modules.order). '
> + 'If nothing is specified, the current directory is
> searched')
> +parser.add_argument('paths', type=str, nargs='*', help=paths_help)
> +
> args = parser.parse_args()
>
> return (args.log_level,
> os.path.abspath(args.directory),
> args.output,
> -[args.directory])
> +args.ar,
> +args.paths if len(args.paths) > 0 else [args.directory])
>
>
> def cmdfiles_in_dir(directory):
> @@ -81,6 +92,73 @@ def cmdfiles_in_dir(directory):
> yield os.path.join(dirpath, filename)
>
>
> +def to_cmdfile(path):
> +"""Return the path of .cmd file used for the given build artifact
> +
> +Args:
> +Path: file path
> +
> +Returns:
> +The path to .cmd file
> +"""
> +dir, base = os.path.split(path)
> +return os.path.join(dir, '.' + base + '.cmd')
> +
> +
> +def cmdfiles_for_o(obj):
> +"""Generate the iterator of .cmd files associated with the object
> +
> +Yield the .cmd file used to build the given object
> +
> +Args:
> +obj: The object path
> +
> +Yields:
> +The path to .cmd file
> +"""
> +yield to_cmdfile(obj)
> +
> +
> +def cmdfiles_for_a(archive, ar):
> +"""Generate the iterator of .cmd files associated with the archive.
> +
> +Parse the given archive, and yield every .cmd file used to build it.
> +
> +Args:
> +archive: The archive to parse
> +
> +Yields:
> +The path to every .cmd file found
> +"""
> +for obj in subprocess.check_output([ar, '-t', archive]).decode().split():
> +yield to_cmdfile(obj)
> +
> +
> +def cmdfiles_for_modorder(modorder):
> +"""Generate the iterator of .cmd files associated with the modules.order.
> +
> +Parse the given modules.order, and yield every .cmd file used to build
> the
> +contained modules.
> +
> +Args:
> +modorder: The modules.order file to parse
> +
> +Yields:
> +The path to every .cmd file found
> +"""
> +with open(modorder) as f:
> +for line in f:
> +ko = line.rstrip()
> +
Re: [PATCH] powerpc/pseries: Add pcibios_default_alignment implementation
On Sat, Aug 22, 2020 at 6:51 AM Shawn Anastasio wrote:
>
> Implement pcibios_default_alignment for pseries so that
> resources are page-aligned. The main benefit of this is being
> able to map any resource from userspace via mechanisms like VFIO.
Reviewed-by: Oliver O'Halloran
That said, there's nothing power specific about this so we should
probably drop the pcibios hacks and fix the default alignment in the
PCI core.
> This is identical to powernv's implementation.
>
> Signed-off-by: Shawn Anastasio
> ---
> arch/powerpc/platforms/pseries/pci.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/pci.c
> b/arch/powerpc/platforms/pseries/pci.c
> index 911534b89c85..6d922c096354 100644
> --- a/arch/powerpc/platforms/pseries/pci.c
> +++ b/arch/powerpc/platforms/pseries/pci.c
> @@ -210,6 +210,11 @@ int pseries_pcibios_sriov_disable(struct pci_dev *pdev)
> }
> #endif
>
> +static resource_size_t pseries_pcibios_default_alignment(void)
> +{
> + return PAGE_SIZE;
> +}
> +
> static void __init pSeries_request_regions(void)
> {
> if (!isa_io_base)
> @@ -231,6 +236,8 @@ void __init pSeries_final_fixup(void)
>
> eeh_show_enabled();
>
> + ppc_md.pcibios_default_alignment = pseries_pcibios_default_alignment;
> +
> #ifdef CONFIG_PCI_IOV
> ppc_md.pcibios_sriov_enable = pseries_pcibios_sriov_enable;
> ppc_md.pcibios_sriov_disable = pseries_pcibios_sriov_disable;
> --
> 2.28.0
>
Re: [RFC PATCH] pipe: make pipe_release() deferrable.
On 2020/08/23 1:30, Linus Torvalds wrote:
> On Fri, Aug 21, 2020 at 9:35 PM Tetsuo Handa
> wrote:
>>
>> Therefore, this patch tries to convert __pipe_lock() in pipe_release() to
>> killable, by deferring to a workqueue context when __pipe_lock_killable()
>> failed.
>
> I don't think this is an improvement.
>
> If somebody can delay the pipe unlock arbitrarily, you've now turned a
> user-visible blocking operation into blocking a workqueue instead. So
> it's still there, and now it possibly is much worse and blocks
> system_wq instead.
We can use a dedicated WQ_MEM_RECLAIM workqueue (like mm_percpu_wq)
if blocking system_wq is a concern.
Moving a user-visible blocking operation into blocking a workqueue helps
avoiding AB-BA deadlocks in some situations. This hung task report says that
a task can't close file descriptor of userfaultfd unless pipe_release()
completes while pipe_write() (which is blocking pipe_release()) can abort
if file descriptor of userfaultfd is closed. A different report [1] says that
a task can't close file descriptor of /dev/raw-gadget unless wdm_flush()
completes while wdm_flush() can abort if file descriptor of /dev/raw-gadget
is closed.
handle_userfault() is a method for delaying for arbitrarily period (and this
report says the period is forever due to AB-BA deadlock condition). But if each
copy_page_to_iter()/copy_page_from_iter() takes 10 seconds for whatever reason,
it is sufficient for triggering khungtaskd warning (demonstrated by patch
below).
We can't use too short pagefault timeout for "do not break e.g. live migration"
but we need to use short pagefault timeout for "do not trigger khungtaskd
warning"
and we can't use long khungtaskd timeout for "detect really hanging tasks".
I think these are incompatible as long as uninterruptible wait is used.
[1]
https://lkml.kernel.org/r/1597188375-4787-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
diff --git a/fs/pipe.c b/fs/pipe.c
index 60dbee457143..2510c6a330b8 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -82,9 +82,13 @@ void pipe_unlock(struct pipe_inode_info *pipe)
}
EXPORT_SYMBOL(pipe_unlock);
-static inline void __pipe_lock(struct pipe_inode_info *pipe)
+static inline void __pipe_lock(struct pipe_inode_info *pipe, const char *func)
{
+ if (!strcmp(current->comm, "a.out"))
+ printk("%s started __pipe_lock()\n", func);
mutex_lock_nested(>mutex, I_MUTEX_PARENT);
+ if (!strcmp(current->comm, "a.out"))
+ printk("%s completed __pipe_lock()\n", func);
}
static inline void __pipe_unlock(struct pipe_inode_info *pipe)
@@ -244,7 +248,7 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to)
return 0;
ret = 0;
- __pipe_lock(pipe);
+ __pipe_lock(pipe, __func__);
/*
* We only wake up writers if the pipe was full when we started
@@ -306,6 +310,12 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to)
break;
}
+ if (!strcmp(current->comm, "a.out")) {
+ int i;
+
+ for (i = 0; i < 10; i++)
+ schedule_timeout_uninterruptible(HZ);
+ }
written = copy_page_to_iter(buf->page, buf->offset,
chars, to);
if (unlikely(written < chars)) {
if (!ret)
@@ -381,7 +391,7 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to)
if (wait_event_interruptible_exclusive(pipe->rd_wait,
pipe_readable(pipe)) < 0)
return -ERESTARTSYS;
- __pipe_lock(pipe);
+ __pipe_lock(pipe, __func__);
was_full = pipe_full(pipe->head, pipe->tail, pipe->max_usage);
wake_next_reader = true;
}
@@ -432,7 +442,7 @@ pipe_write(struct kiocb *iocb, struct iov_iter *from)
if (unlikely(total_len == 0))
return 0;
- __pipe_lock(pipe);
+ __pipe_lock(pipe, __func__);
if (!pipe->readers) {
send_sig(SIGPIPE, current, 0);
@@ -472,6 +482,12 @@ pipe_write(struct kiocb *iocb, struct iov_iter *from)
if (ret)
goto out;
+ if (!strcmp(current->comm, "a.out")) {
+ int i;
+
+ for (i = 0; i < 10; i++)
+ schedule_timeout_uninterruptible(HZ);
+ }
ret = copy_page_from_iter(buf->page, offset, chars,
from);
if (unlikely(ret < chars)) {
ret = -EFAULT;
@@ -536,6 +552,12 @@ pipe_write(struct kiocb *iocb, struct iov_iter *from)
buf->flags = PIPE_BUF_FLAG_CAN_MERGE;
pipe->tmp_page =
Re: Re：Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero
On Sun, Aug 23, 2020 at 12:54:33AM +0800, Guohua Zhong wrote: > Yet, I have noticed that there is no checking of 'base' in these functions. > But I am not sure how to check is better.As we know that the result is > undefined when divisor is zero. It maybe good to print error and dump stack. > Let the process to know that the divisor is zero by sending SIGFPE. That is now what the PowerPC integer divide insns do: they just leave the result undefined (and they can set the overflow flag then, but no one uses that). Segher
Re: [PATCH] x86: work around clang IAS bug referencing __force_order
On Sat, Aug 22, 2020 at 4:11 PM Arvind Sankar wrote: > > Actually, is a memory clobber required for correctness? Memory accesses > probably shouldn't be reordered across a CRn write. Is asm volatile > enough to stop that or do you need a memory clobber? You do need a memory clobber if you really care about ordering wrt normal memory references. That said, I'm not convinced we do care here. Normal memory accesses (as seen by the compiler) should be entirely immune to any changes we do wrt CRx registers. Because code that really fundamentally changes kernel mappings or access rules is already written in low-level assembler (eg the entry routines or bootup). Anything that relies on the more subtle changes (ie user space accesses etc) should already be ordered by other things - usually by the fact that they are also "asm volatile". But hey, maybe somebody can come up with an exception to that. Linus
Re: [BUG RT] dump-capture kernel not executed for panic in interrupt context
On Sat, 22 Aug 2020 14:32:52 +0200
pet...@infradead.org wrote:
> On Fri, Aug 21, 2020 at 05:03:34PM -0400, Steven Rostedt wrote:
>
> > > Sigh. Is it too hard to make mutex_trylock() usable from interrupt
> > > context?
> >
> >
> > That's a question for Thomas and Peter Z.
>
> You should really know that too, the TL;DR answer is it's fundamentally
> buggered, can't work.
I knew there was an issue but I couldn't remember the reasoning, and
figured you could easily answer it without having to look back at the
code.
>
> The problem is that RT relies on being able to PI boost the mutex owner.
>
> ISTR we had a thread about all this last year or so, let me see if I can
> find that.
>
> Here goes:
>
>
> https://lkml.kernel.org/r/20191218135047.gs2...@hirez.programming.kicks-ass.net
>From this email:
> The problem happens when that owner is the idle task, this can happen
> when the irq/softirq hits the idle task, in that case the contending
> mutex_lock() will try and PI boost the idle task, and that is a big
> no-no.
What's wrong with priority boosting the idle task? It's not obvious,
and I can't find comments in the code saying it would be bad.
I looked around the code to see if I could find "why this is bad" but
couldn't find it. There's lots of places that say "Do not use
mutex_trylock in interrupt context, the implementation is not safe to
do so" but I can't find where it says "why" it is not safe to do so.
The idle task is not mentioned at all in rtmutex.c and not mentioned in
kernel/locking except for some comments about RCU in lockdep.
I see that in the idle code the prio_change method does a BUG(), but
there's no comment to say why it does so.
The commit that added that BUG, doesn't explain why it can't happen:
a8941d7ec8167 ("sched: Simplify the idle scheduling class")
I may have once known the rationale behind all this, but it's been a
long time since I worked on the PI code, and it's out of my cache.
-- Steve
Re: [PATCH v2 0/6] Add initial support for ATC260x PMICs
Hi Mani, On Sat, Aug 22, 2020 at 06:43:43PM +0530, Manivannan Sadhasivam wrote: > Hi Cristi, > > Thanks for the series! I'll take a look soon but there is a quick comment > below. > > On Sat, Aug 22, 2020 at 01:26:53AM +0300, Cristian Ciocaltea wrote: > > I have just realized I had omitted the changelog - sorry: > > > > Changes in v2: > > - Reworked MFD core & I2C driver > > * Integrated Lee's feedback > > * Added support for using the regmap within atomic contexts > > * Added support for ATC2603C chip variant > > * Reorganized KConfig entries > > - Improved regulator driver > > * Added support for ATC2603C variant > > * Used helper macros for more compact specification of regulator_desc > > items > > * Added more regulator capabilities > > - Added power controller driver > > * Provides system poweroff/reboot functionalities > > * Requires support for I2C Atomic transfers in the Owl driver (already > > submitted) > > - Added onkey driver: exposes the power button as an input device > > - Added yaml binding doc > > - Rebased patchset on kernel v5.9-rc1 > > > > Kind regards, > > Cristi > > > > On Sat, Aug 22, 2020 at 01:19:46AM +0300, Cristian Ciocaltea wrote: > > > This is re-spin of the patch series submitted some time ago by Mani, > > > who added initial support (MFD core and regulators) for the Actions > > > Semi ATC260x PMICs: > > > https://lore.kernel.org/lkml/20190617155011.15376-1-manivannan.sadhasi...@linaro.org/ > > > > > > The ATC260x family of PMICs integrates Audio Codec, Power management, > > > Clock generation and GPIO controller blocks. There are currently 3 > > > variants: ATC2603A, ATC2603C and ATC2609A. > > > > > > In addition to the ATC2609A regulator functionality provided that time, > > > this patchset adds support for the ATC2603C variant, together with some > > > new functionalities for both chips: power controller and onkey input. > > > The ATC2603A variant remains unsupported for the moment. > > > > > > This has been tested on RoseapplePi, a SBC based on the Action Semi S500 > > > SoC, which integrates ATC2603C PMIC. An initial support for this board > > > has been already submitted: > > > https://lore.kernel.org/lkml/cover.1592123160.git.cristian.ciocal...@gmail.com/ > > > > > > Please note that enabling the ATC260x PMICs on the compatible Actions > > > Semi Owl SoC based boards depends on the following: > > > > > > * Actions Semi SIRQ driver (for PMIC DTS setup): > > > > > > https://lore.kernel.org/lkml/cover.1597852360.git.cristian.ciocal...@gmail.com/ > > > > > > * I2C Atomic transfers in Actions Semi Owl driver (for proper operation > > > of the power controller driver): > > > > > > https://lore.kernel.org/lkml/b086ef6d355d9730c839359e15eb06175283e323.1596485741.git.cristian.ciocal...@gmail.com/ > > > > > > Thanks, > > > Cristi > > > > > > Cristian Ciocaltea (6): > > > dt-bindings: mfd: Add Actions Semi ATC260x PMIC binding > > > mfd: Add MFD driver for ATC260x PMICs > > > regulator: Add regulator driver for ATC260x PMICs > > You need to preserve my authorship for above two patches. Adding the > signed-off-by > is not enough. I'm very sorry for the mistake, I was not aware of the correct reposting procedure. Should I resend the series now or could we handle a first round of review before? Thanks, Cristi > > > power: reset: Add poweroff driver for ATC260x PMICs > > > input: atc260x: Add onkey driver for ATC260x PMICs > > > MAINTAINERS: Add entry for ATC260x PMIC > > I think this one too. > > Thanks, > Mani > > > > > > > .../bindings/mfd/actions,atc260x.yaml | 221 > > > MAINTAINERS | 12 + > > > drivers/input/misc/Kconfig| 11 + > > > drivers/input/misc/Makefile | 2 +- > > > drivers/input/misc/atc260x-onkey.c| 304 +++ > > > drivers/mfd/Kconfig | 18 + > > > drivers/mfd/Makefile | 3 + > > > drivers/mfd/atc260x-core.c| 290 ++ > > > drivers/mfd/atc260x-i2c.c | 73 +++ > > > drivers/power/reset/Kconfig | 8 +- > > > drivers/power/reset/Makefile | 1 + > > > drivers/power/reset/atc260x-poweroff.c| 274 ++ > > > drivers/regulator/Kconfig | 8 + > > > drivers/regulator/Makefile| 1 + > > > drivers/regulator/atc260x-regulator.c | 511 ++ > > > include/linux/mfd/atc260x/atc2603c.h | 281 ++ > > > include/linux/mfd/atc260x/atc2609a.h | 308 +++ > > > include/linux/mfd/atc260x/core.h | 86 +++ > > > 18 files changed, 2410 insertions(+), 2 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/mfd/actions,atc260x.yaml > > > create mode 100644 drivers/input/misc/atc260x-onkey.c > > > create mode 100644
Re: [PATCH] x86: work around clang IAS bug referencing __force_order
On Sat, Aug 22, 2020 at 02:08:27PM -0700, Linus Torvalds wrote: > However, in this case, can we just leave that old "__force_order" hack > alone, and to work around the clang thing, just make a dummy > definition of it anyway. > > Alternatively, just use the memory clobber. We use memory clobbers > elsewhere in inline asms to make sure they are serialized, it's not > normally a huge problem. Both clang and gcc should be smart enough to > know that a memory clobber doesn't matter for things like local > variables etc that might be on stack but have never had their address > taken. > > Or are there other cases than that particular __force_order thing that > people now worry about? > > Linus Actually, is a memory clobber required for correctness? Memory accesses probably shouldn't be reordered across a CRn write. Is asm volatile enough to stop that or do you need a memory clobber? Replacing force_order with memory clobber introduces a few extra instructions (testing with defconfig), but only in x86-64 hibernate/reboot/sleep code and early_ioremap_init on x86-32.
Re: [PATCH v5 0/3] Add Actions Semi Owl family sirq support
Hi Mani, On Sat, Aug 22, 2020 at 06:47:12PM +0530, Manivannan Sadhasivam wrote: > Hi Cristi, > > On Wed, Aug 19, 2020 at 07:37:55PM +0300, Cristian Ciocaltea wrote: > > This patch series adds support for the external interrupt controller > > (SIRQ) found in the Actions Semi Owl family of SoC's (S500, S700 and > > S900). The controller handles up to 3 external interrupt lines through > > dedicated SIRQ pins. > > > > This is a rework of the patch series submitted some time ago by > > Parthiban Nallathambi: > > https://lore.kernel.org/lkml/20181126100356.2840578-1...@denx.de/ > > > > You need to preserve the authorship while reposting the patches. If you'd > like to take the authorship intentionally then please explain the reason in > cover letter. > > Thanks, > Mani Thanks for pointing this out, I was not aware of the procedure - this is actually my very first repost. Could you please indicate how should I proceed to fix this? I had absolutely no intention to take the authorship.. Sorry for the mistake, Cristi > > Please note I have dropped, for the moment, the S700 related patches > > since I do not own a compatible hardware for testing. I'm using instead > > an S500 SoC based board for which I have already provided the initial > > support: > > https://lore.kernel.org/lkml/cover.1592123160.git.cristian.ciocal...@gmail.com/ > > > > The SIRQ controller support is a prerequisite of the soon to be submitted > > MFD driver for the Actions Semi ATC260x PMICs. > > > > Thanks and regards, > > Cristi > > > > Changes in v5: > > - Integrated Marc's review (more details in the driver patch changelog) > > - Rebased patch series on v5.9-rc1 > > > > Changes in v4: > > - Simplified the DTS structure: > > * dropped 'actions,sirq-shared-reg' node, now the differentiation > > between SoC variants is handled now via the compatible property > > * dropped 'actions,sirq-reg-offset', now controller base address in > > DTS points to SIRQ0 register, so no additional information is > > required for S500 and S700, while for S900 SoC the offsets of SIRQ1 > > and SIRQ2 regs are provided by the driver > > * 'actions,ext-irq-range' was replaced with 'actions,ext-interrupts', > > an array of the GIC interrupts triggered by the controller > > - Fixed wrong INTC_EXTCTL_TYPE_MASK definition > > - Removed redundant irq_fwspec checks in owl_sirq_domain_alloc() > > - Improved error handling in owl_sirq_of_init() > > - Added yaml binding document > > - Dropped S700 related DTS patches for lack of testing hardware: > > * arm64: dts: actions: Add sirq node for Actions Semi S700 > > * arm64: dts: actions: s700-cubieboard7: Enable SIRQ > > - Updated MAINTAINERS > > - Rebased patchset on kernel v5.8 > > - Cosmetic changes > > * Ordered include statements alphabetically > > * Added comment to owl_sirq_set_type() describing conversion of falling > >edge or active low signals > > * Replaced IRQF_TRIGGER_* with corresponding IRQ_TYPE_* variants > > * Ensured data types and function naming are consistent regarding the > >'owl_sirq' prefix > > > > Changes in v3 (Parthiban Nallathambi): > > - Set default operating frequency to 24MHz > > - Falling edge and Low Level interrupts translated to rising edge and high > > level > > - Introduced common function with lock handling for register read and write > > - Used direct GIC interrupt number for interrupt local hwirq and finding > > offset > > using DT entry (range) when registers are shared > > - Changed irq_ack to irq_eoi > > - Added translation method for irq_domain_ops > > - Clearing interrupt pending based on bitmask for edge triggered > > - Added pinctrl definition for sirq for cubieboard7. This depends on, > > https://lore.kernel.org/patchwork/patch/1012859/ > > > > Changes in v2 (Parthiban Nallathambi): > > - Added SIRQ as hierarchical chip > > GIC <> SIRQ <> External interrupt controller/Child devices > > - Device binding updates with vendor prefix > > - Register sharing handled globally and common init sequence/data for all > > actions SoC family > > > > Cristian Ciocaltea (3): > > dt-bindings: interrupt-controller: Add Actions SIRQ controller binding > > irqchip: Add Actions Semi Owl SIRQ controller > > MAINTAINERS: Add entries for Actions Semi Owl SIRQ controller > > > > .../actions,owl-sirq.yaml | 68 > > MAINTAINERS | 2 + > > drivers/irqchip/Makefile | 1 + > > drivers/irqchip/irq-owl-sirq.c| 347 ++ > > 4 files changed, 418 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml > > create mode 100644 drivers/irqchip/irq-owl-sirq.c > > > > -- > > 2.28.0 > >
Re: [patch RFC 38/38] irqchip: Add IMS array driver - NOT FOR MERGING
On Sat, Aug 22, 2020 at 03:34:45AM +0200, Thomas Gleixner wrote: > >> One question is whether the device can see partial updates to that > >> memory due to the async 'swap' of context from the device CPU. > > > > It is worse than just partial updates.. The device operation is much > > more like you'd imagine a CPU cache. There could be copies of the RAM > > in the device for long periods of time, dirty data in the device that > > will flush back to CPU RAM overwriting CPU changes, etc. > > TBH, that's insane. You clearly want to think about this some > more. If I think this general design is around 15 years old, across a healthy number of silicon generations, and rather a lager number of shipped devices. People have thought about it :) > you swap out device state and device control state then you definitly > want to have regions which are read only from the device POV and never > written back. It is not as useful as you'd think - the issue with atomicity of update still largely prevents doing much useful from the CPU, and to make any CPU side changes visible a device command would still be needed to synchronize the internal state to that modified memory. So, CPU centric updates would cover a very limited number of operations, and a device command is required anyhow. Little is actually gained. > The MSI msg store clearly belongs into that category. > But that's not restricted to the MSI msg store, there is certainly other > stuff which never wants to be written back by the device. To get a design where you'd be able to run everything from a CPU atomic context that can't trigger a WQ.. New silicon would have to implement some MSI-only 'cache' that can invalidate entries based on a simple MemWr TLP. Then the affinity update would write to the host memory, then send a MemWr to the device to trigger invalidate. As a silicon design it might work, but it means existing devices can't be used with this dev_msi. It is also the sort of thing that would need a standard document to have any hope of multiple vendors fitting into it. Eg at PCI-SIG or something. > If you don't do that then you simply can't write to that space from the > CPU and you have to transport this kind information always via command > queues. Yes, exactly. This is part of the architectural design of the device, has been for a long time. Has positives and negatives. > > I suppose the core code could provide this as a service? Sort of a > > varient of the other lazy things above? > > Kinda. That needs a lot of thought for the affinity setting stuff > because it can be called from contexts which do not allow that. It's > solvable though, but I clearly need to stare at the corner cases for a > while. If possible, this would be ideal, as we could use the dev_msi on a big installed base of existing HW. I suspect other HW can probably fit into this too as the basic ingredients should be fairly widespread. Even a restricted version for situations where affinity does not need a device update would possibly be interesting (eg x86 IOMMU remap, ARM GIC, etc) > OTOH, in normal operation for MSI interrupts (edge type) masking is not > used at all and just restricted to the startup teardown. Yeah, at least this device doesn't need masking at runtime, just startup/teardown and affinity update. Thanks, Jason
Re: [PATCH][next] carl9170: Use fallthrough pseudo-keyword
On 2020-08-21 08:52, Gustavo A. R. Silva wrote: Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva Acked-by: Christian Lamparter
Re: [GIT PULL] fallthrough pseudo-keyword macro conversions for 5.9-rc2
Hi Joe,
On 8/22/20 12:36, Joe Perches wrote:
> On Thu, 2020-08-20 at 17:02 -0500, Gustavo A. R. Silva wrote:
>> This treewide patch doesn't address ALL fall-through markings in all
>> subsystems at once because I have previously sent out patches for some of
>> such subsystems separately, and I will follow up on them; however, this
>> definitely contributes most of the work needed to replace all the
>> fall-through markings with the fallthrough pseudo-keyword macro in the
>> whole codebase.
>
> Hi Gustavo. Thanks for this.
>
> Some stragglers (for -next) in the arch/subsystems modified
> by this patch:
>
> arch/x86/
> drivers/gpu/
> drivers/misc/
> drivers/net/ethernet/
> lib/
>
> And some in scripts/ and tools/ which maybe shouldn't be changed.
>
I didn't change anything in scripts/ and tools/
I first plan to send a patch series to the following to
tools/include/linux/compiler-gcc.h:
/*
* Add the pseudo keyword 'fallthrough' so case statement blocks
* must end with any of these keywords:
* break;
* fallthrough;
* goto ;
* return [expression];
*
* gcc:
https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#Statement-Attributes
*/
#if __has_attribute(__fallthrough__)
# define fallthrough__attribute__((__fallthrough__))
#else
# define fallthroughdo {} while (0) /* fallthrough */
#endif
and address the fallthrough markings in tools/
Thanks
--
Gustavo
> Possible diffs for each straggler directory block below:
>
>> arch/x86/
>
> $ git diff -U0 arch
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 0f3d01562ded..b825a5a5ede7 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -1149 +1149 @@ static inline void x86_assign_hw_event(struct perf_event
> *event,
> - /* fall through */
> + fallthrough;
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index 983cd53ed4c9..097cc3439e53 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -190 +190 @@ static void __init e820_print_type(enum e820_type type)
> - case E820_TYPE_RAM: /* Fall through: */
> + case E820_TYPE_RAM:
> @@ -197 +197 @@ static void __init e820_print_type(enum e820_type type)
> - case E820_TYPE_PMEM:/* Fall through: */
> + case E820_TYPE_PMEM:
> @@ -1044 +1044 @@ static const char *__init e820_type_to_string(struct
> e820_entry *entry)
> - case E820_TYPE_RESERVED_KERN: /* Fall-through: */
> + case E820_TYPE_RESERVED_KERN:
> @@ -1060 +1060 @@ static unsigned long __init e820_type_to_iomem_type(struct
> e820_entry *entry)
> - case E820_TYPE_RESERVED_KERN: /* Fall-through: */
> + case E820_TYPE_RESERVED_KERN:
> @@ -1062,7 +1062,7 @@ static unsigned long __init
> e820_type_to_iomem_type(struct e820_entry *entry)
> - case E820_TYPE_ACPI:/* Fall-through: */
> - case E820_TYPE_NVS: /* Fall-through: */
> - case E820_TYPE_UNUSABLE:/* Fall-through: */
> - case E820_TYPE_PRAM:/* Fall-through: */
> - case E820_TYPE_PMEM:/* Fall-through: */
> - case E820_TYPE_RESERVED:/* Fall-through: */
> - case E820_TYPE_SOFT_RESERVED: /* Fall-through: */
> + case E820_TYPE_ACPI:
> + case E820_TYPE_NVS:
> + case E820_TYPE_UNUSABLE:
> + case E820_TYPE_PRAM:
> + case E820_TYPE_PMEM:
> + case E820_TYPE_RESERVED:
> + case E820_TYPE_SOFT_RESERVED:
> @@ -1082,3 +1082,3 @@ static unsigned long __init
> e820_type_to_iores_desc(struct e820_entry *entry)
> - case E820_TYPE_RESERVED_KERN: /* Fall-through: */
> - case E820_TYPE_RAM: /* Fall-through: */
> - case E820_TYPE_UNUSABLE:/* Fall-through: */
> + case E820_TYPE_RESERVED_KERN:
> + case E820_TYPE_RAM:
> + case E820_TYPE_UNUSABLE:
>
>> drivers/gpu/
>
> $ git diff -U1 drivers/gpu
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> index b5986d19dc08..77dec1a56b9b 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> @@ -6203,3 +6203,3 @@ static void
> si_request_link_speed_change_before_state_change(struct amdgpu_devic
> #endif
> - /* fall through */
> + fallthrough;
> default:
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
> index 886e9959496f..6ba12f141833 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -4863,3 +4863,3 @@ static void
> ci_request_link_speed_change_before_state_change(struct radeon_devic
> #endif
> - /* fall through */
> + fallthrough;
> default:
> diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
> index
[PATCH v1] PCI: pcie_bus_config can be set at build time
The Kconfig is modified so that the pcie_bus_config setting can be done at build time in the same manner as the CONFIG_PCIEASPM_ choice. The pci_bus_config setting may still be overridden by the bootline param. Signed-off-by: Jim Quinlan --- drivers/pci/Kconfig | 40 drivers/pci/pci.c | 12 2 files changed, 52 insertions(+) diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 4bef5c2bae9f..efe69b0d9f7f 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -187,6 +187,46 @@ config PCI_HYPERV The PCI device frontend driver allows the kernel to import arbitrary PCI devices from a PCI backend to support PCI driver domains. +choice + prompt "PCIE default bus config setting" + default PCIE_BUS_DEFAULT + depends on PCI + help + One of the following choices will set the pci_bus_config at + compile time. This will still be overridden by the appropriate + pci bootline parameter. + +config PCIE_BUS_TUNE_OFF + bool "Tune Off" + depends on PCI + help + Use the BIOS defaults; doesn't touch MPS at all. + +config PCIE_BUS_DEFAULT + bool "Default" + depends on PCI + help + Ensure MPS matches upstream bridge. + +config PCIE_BUS_SAFE + bool "Safe" + depends on PCI + help + Use largest MPS boot-time devices support. + +config PCIE_BUS_PERFORMANCE + bool "Performance" + depends on PCI + help + Use MPS and MRRS for best performance. + +config PCIE_BUS_PEER2PEER + bool "Peer2peer" + depends on PCI + help + Set MPS = 128 for all devices. +endchoice + source "drivers/pci/hotplug/Kconfig" source "drivers/pci/controller/Kconfig" source "drivers/pci/endpoint/Kconfig" diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index a458c46d7e39..49b66ba7c874 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -101,7 +101,19 @@ unsigned long pci_hotplug_mmio_pref_size = DEFAULT_HOTPLUG_MMIO_PREF_SIZE; #define DEFAULT_HOTPLUG_BUS_SIZE 1 unsigned long pci_hotplug_bus_size = DEFAULT_HOTPLUG_BUS_SIZE; + +/* PCIE bus config, can be overridden by bootline param */ +#ifdef CONFIG_PCIE_BUS_TUNE_OFF +enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_TUNE_OFF; +#elif defined CONFIG_PCIE_BUS_SAFE +enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_SAFE; +#elif defined CONFIG_PCIE_BUS_PERFORMANCE +enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_PERFORMANCE; +#elif defined CONFIG_PCIE_BUS_PEER2PEER +enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_PEER2PEER; +#else enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_DEFAULT; +#endif /* * The default CLS is used if arch didn't set CLS explicitly and not -- 2.17.1
Re: [tip: x86/urgent] x86/entry, selftests: Further improve user entry sanity checks
On Thu, Aug 20, 2020 at 3:24 AM wrote:
>
> On Sat, Jul 04, 2020 at 05:49:10PM -, tip-bot2 for Andy Lutomirski wrote:
>
> > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > index f392a8b..e83b3f1 100644
> > --- a/arch/x86/entry/common.c
> > +++ b/arch/x86/entry/common.c
> > @@ -49,6 +49,23 @@
> > static void check_user_regs(struct pt_regs *regs)
> > {
> > if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) {
> > + /*
> > + * Make sure that the entry code gave us a sensible EFLAGS
> > + * register. Native because we want to check the actual CPU
> > + * state, not the interrupt state as imagined by Xen.
> > + */
> > + unsigned long flags = native_save_fl();
> > + WARN_ON_ONCE(flags & (X86_EFLAGS_AC | X86_EFLAGS_DF |
> > + X86_EFLAGS_NT));
>
> This triggers with AC|TF on my !SMAP enabled machine.
>
> something like so then?
>
> diff --git a/arch/x86/include/asm/entry-common.h
> b/arch/x86/include/asm/entry-common.h
> index a8f9315b9eae..76410964585f 100644
> --- a/arch/x86/include/asm/entry-common.h
> +++ b/arch/x86/include/asm/entry-common.h
> @@ -18,8 +18,15 @@ static __always_inline void arch_check_user_regs(struct
> pt_regs *regs)
> * state, not the interrupt state as imagined by Xen.
> */
> unsigned long flags = native_save_fl();
> - WARN_ON_ONCE(flags & (X86_EFLAGS_AC | X86_EFLAGS_DF |
> - X86_EFLAGS_NT));
> + unsigned long mask = X86_EFLAGS_DF | X86_EFLAGS_NT;
> +
> + /*
> +* For !SMAP hardware we patch out CLAC on entry.
> +*/
> + if (boot_cpu_has(X86_FEATURE_SMAP))
> + mask |= X86_EFLAGS_AC;
> +
> + WARN_ON_ONCE(flags & mask);
>
> /* We think we came from user mode. Make sure pt_regs agrees.
> */
> WARN_ON_ONCE(!user_mode(regs));
LGTM.
Acked-by: Andy Lutomirski
Re: [PATCH v2] mm: Track page table modifications in __apply_to_page_range()
Hi! > > > The __apply_to_page_range() function is also used to change and/or > > > allocate page-table pages in the vmalloc area of the address space. > > > Make sure these changes get synchronized to other page-tables in the > > > system by calling arch_sync_kernel_mappings() when necessary. > > > > There's no description here of the user-visible effects of the bug. > > Please always provide this, especially when proposing a -stable > > backport. Take pity upon all the downstream kernel maintainers who are > > staring at this wondering whether they should risk adding it to their > > kernels. > > The impact appears limited to x86-32, where apply_to_page_range may miss > updating the PMD. That leads to explosions in drivers like Is this alone supposed to fix my problems with graphics on Thinkpad X60? Let me try... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH net-next] net: Remove unnecessary intermediate variables
On Sat, 2020-08-22 at 14:07 -0700, David Miller wrote: > From: Joe Perches > Date: Sat, 22 Aug 2020 14:03:31 -0700 > > > The compiler didn't inline the code without it. > > Then the compiler had a good reason for doing so, The "good" word choice there is slightly dubious. Compilers make bad decisions all the time. > or it's a compiler bug that should be reported. Or just behavioral changes between versions, or even just random compiler decisions that causes known unrepeatable compilation output. That happens all the time. If you want it just as static without the inline/__always_inline marking, let me know.
[PATCH] usb: storage: initialize variable
From: Tom Rix
clang static analysis reports this representative problem
transport.c:495:15: warning: Assigned value is garbage or
undefined
length_left -= partial;
^ ~~~
partial is set only when usb_stor_bulk_transfer_sglist()
is successful.
So initialize to partial to 0.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Tom Rix
---
drivers/usb/storage/transport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index 238a8088e17f..ce920851b1f2 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -461,7 +461,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
*us, unsigned int pipe,
int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
struct scsi_cmnd* srb)
{
- unsigned int partial;
+ unsigned int partial = 0;
int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
scsi_sg_count(srb), scsi_bufflen(srb),
);
@@ -484,7 +484,7 @@ int usb_stor_bulk_transfer_sg(struct us_data* us, unsigned
int pipe,
void *buf, unsigned int length_left, int use_sg, int *residual)
{
int result;
- unsigned int partial;
+ unsigned int partial = 0;
/* are we scatter-gathering? */
if (use_sg) {
--
2.18.1
Re: [PATCH] x86: work around clang IAS bug referencing __force_order
On Sat, Aug 22, 2020 at 08:17:32PM +0200, Miguel Ojeda wrote: > On Sat, Aug 22, 2020 at 11:52 AM Sedat Dilek wrote: > > > > I am asking myself who is using such ancient compilers? > > There are many users/companies using older versions of compilers, > kernels and everything. GCC <= 4.9 will still be used/supported (by > third parties) for a handful of years at least. > > However, the important question is whether those users/companies care > about running the latest kernels. Many of those definitely do not want > to touch their kernel either. For those that do, there are several > longterms to pick from that still support 4.9, as well as other > workarounds. > > Thus I am usually in favor of raising the minimum whenever new hacks > are required to be added. On the other hand, we already raised the > version twice this year and it is not clear to me what is the minimum > version we would need to go for to ensure this does not bite us. > > > If this is a real problem with GCC version <= 5, so can this be moved > > to a GCC specific include header-file? > > Thinking of include/linux/compiler-gcc.h or > > include/linux/compiler_types.h with a GCC-VERSION check? > > That would be better if it can be done, yes. > > Cheers, > Miguel The fix landed in gcc 6.5, 7.3 and 8.1. The bug is presumably quite difficult to actually trigger. As a sample data point, I verified that 7.1 vs 7.1+fix have no differences on 32-bit and 64-bit x86 defconfigs, on current mainline. Assuming we don't want to risk removing force_order, I'd suggest - make it an input/output operand, so it enforces ordering fully. - either restrict it to gcc < 8, or just provide a proper definition in some file (maybe arch/x86/kernel/cpu/common.c)? Thanks.
[PATCH] media: tuner-simple: fix regression in simple_set_radio_freq
From: Tom Rix
clang static analysis reports this problem
tuner-simple.c:714:13: warning: Assigned value is
garbage or undefined
buffer[1] = buffer[3];
^ ~
In simple_set_radio_freq buffer[3] used to be done
in-function with a switch of tuner type, now done
by a call to simple_radio_bandswitch which has this case
case TUNER_TENA_9533_DI:
case TUNER_YMEC_TVF_5533MF:
tuner_dbg("This tuner doesn't ...
return 0;
which does not set buffer[3]. In the old logic, this case
would have returned 0 from simple_set_radio_freq.
Recover this old behavior by returning an error for this
codition. Since the old simple_set_radio_freq behavior
returned a 0, do the same.
Fixes: c7a9f3aa1e1b ("V4L/DVB (7129): tuner-simple: move device-specific code
into three separate functions")
Signed-off-by: Tom Rix
---
drivers/media/tuners/tuner-simple.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/tuners/tuner-simple.c
b/drivers/media/tuners/tuner-simple.c
index b6e70fada3fb..8fb186b25d6a 100644
--- a/drivers/media/tuners/tuner-simple.c
+++ b/drivers/media/tuners/tuner-simple.c
@@ -500,7 +500,7 @@ static int simple_radio_bandswitch(struct dvb_frontend *fe,
u8 *buffer)
case TUNER_TENA_9533_DI:
case TUNER_YMEC_TVF_5533MF:
tuner_dbg("This tuner doesn't have FM. Most cards have a
TEA5767 for FM\n");
- return 0;
+ return -EINVAL;
case TUNER_PHILIPS_FM1216ME_MK3:
case TUNER_PHILIPS_FM1236_MK3:
case TUNER_PHILIPS_FMD1216ME_MK3:
@@ -702,7 +702,8 @@ static int simple_set_radio_freq(struct dvb_frontend *fe,
TUNER_RATIO_SELECT_50; /* 50 kHz step */
/* Bandswitch byte */
- simple_radio_bandswitch(fe, [0]);
+ if (simple_radio_bandswitch(fe, [0]))
+ return 0;
/* Convert from 1/16 kHz V4L steps to 1/20 MHz (=50 kHz) PLL steps
freq * (1 Mhz / 16000 V4L steps) * (20 PLL steps / 1 MHz) =
--
2.18.1
Re: [PATCH] x86: work around clang IAS bug referencing __force_order
On Sat, Aug 22, 2020 at 11:17 AM Miguel Ojeda wrote: > > However, the important question is whether those users/companies care > about running the latest kernels. Many of those definitely do not want > to touch their kernel either. For those that do, there are several > longterms to pick from that still support 4.9, as well as other > workarounds. > > Thus I am usually in favor of raising the minimum whenever new hacks > are required to be added. On the other hand, we already raised the > version twice this year and it is not clear to me what is the minimum > version we would need to go for to ensure this does not bite us. Yeah. The good news is that I haven't seen a lot of pushback on the gcc version updates so far. I was expecting some complaints. I haven't seen a single one. That may be because people did end up finding it very onerous and complained internally on channels I haven't seen, but it might also be indicative of us having perhaps been a bit too timid about compiler version updates. However, in this case, can we just leave that old "__force_order" hack alone, and to work around the clang thing, just make a dummy definition of it anyway. Alternatively, just use the memory clobber. We use memory clobbers elsewhere in inline asms to make sure they are serialized, it's not normally a huge problem. Both clang and gcc should be smart enough to know that a memory clobber doesn't matter for things like local variables etc that might be on stack but have never had their address taken. Or are there other cases than that particular __force_order thing that people now worry about? Linus
Re: [PATCH net-next] net: Remove unnecessary intermediate variables
From: Joe Perches Date: Sat, 22 Aug 2020 14:03:31 -0700 > The compiler didn't inline the code without it. Then the compiler had a good reason for doing so, or it's a compiler bug that should be reported. I would reject any patch that added inline to a foo.c file, so unless you want to make suggestions that will cause a contributor's patch to be rejected, I'd suggest you not recommend inline usage in this way. Thank you.
Re: [PATCH net-next] net: Remove unnecessary intermediate variables
On Sat, 2020-08-22 at 13:59 -0700, David Miller wrote: > From: Joe Perches > Date: Sat, 22 Aug 2020 13:39:28 -0700 > > > It _might_ be slightly faster to use inlines > > We are not using the inline directive in foo.c files and are letting > the compiler decide. > > Please don't give out advice like this. Actually, I checked with and without inline before posting the proposal. The compiler didn't inline the code without it. Not even with just static inline. For gcc 9.3 only the __always_inline did. That's the only version I checked.
Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION
From: Pascal Bouchareine Date: Sat, 22 Aug 2020 13:53:03 -0700 > On Sat, Aug 22, 2020 at 1:19 PM Pascal Bouchareine wrote: >> >> On Sat, Aug 22, 2020 at 12:59 PM Pascal Bouchareine wrote: >> >> > Would it make sense to also make UDIAG_SHOW_NAME use sk_description? >> > (And keep the existing change - setsockopt + show_fd_info via >> > /proc/.../fdinfo/..) >> >> >> Ah,very wrong example - to be more precise, I suppose that'd be adding >> a couple idiag_ext for sk_description and pid if possible instead > > About the pid part - > On top of multiple pids to scan for a given socket, there's also the > security provided by /proc - I'm not sure what inet_diag does for that > So maybe users calling it will need to scan /proc for a long time anyway... > > Or is that doable? I'd like to kindly ask that you do more research into how this kind of information is advertised to the user using modern interfaces, and what kinds of permissions and checks are done for those. You are proposing a new UAPI for the Linux kernel, and with that comes some level of responsibility. Thank you.
Re: [PATCH net-next] net: Remove unnecessary intermediate variables
From: Joe Perches Date: Sat, 22 Aug 2020 13:39:28 -0700 > It _might_ be slightly faster to use inlines We are not using the inline directive in foo.c files and are letting the compiler decide. Please don't give out advice like this. Thank you.
Re: [PATCH v3] memory: brcmstb_dpfe: fix array index out of bounds
On Sat, Aug 22, 2020 at 01:50:00PM -0700, Markus Mayer wrote:
> We would overrun the error_text array if we hit a TIMEOUT condition,
> because we were using the error code "ETIMEDOUT" (which is 110) as an
> array index.
>
> We fix the problem by correcting the array index and by providing a
> function to retrieve error messages rather than accessing the array
> directly. The function includes a bounds check that prevents the array
> from being overrun.
>
> This patch was prepared in response to
> https://lkml.org/lkml/2020/8/18/505.
>
> Signed-off-by: Markus Mayer
> Acked-by: Florian Fainelli
> Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE")
> Reported-by: Colin Ian King
> ---
>
> Changes since v2:
> - Added "Fixes:" and "Reported-by:"
> - Fixed "From" address
> - No changes to the code
>
> Changes since v1:
> - Added link of the coverity report to the commit message.
> - Added Florian's ack.
> - Removed second "const" from get_error_text() return type
> (thanks to the kernel test robot).
>
> drivers/memory/brcmstb_dpfe.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
"From" and SoB look good now.
Thanks, applied.
Best regards,
Krzysztof
[PATCH v4 1/1] phy: tusb1210: use bitmasks to set VENDOR_SPECIFIC2
From: Liam Beguin
Start by reading the content of the VENDOR_SPECIFIC2 register and update
each bit field based on device properties when defined.
The use of bit masks prevents fields from overriding each other and
enables users to clear bits which are set by default, like datapolarity
in this instance.
Signed-off-by: Liam Beguin
---
Changes since v1:
- use set_mask_bits
Changes since v2:
- fix missing bit shift dropped in v2
- rebase on 5.9-rc1
Changes since v3:
- switch to u8p_replace_bits() since there's little reason to protect
against concurrent access
drivers/phy/ti/phy-tusb1210.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/phy/ti/phy-tusb1210.c b/drivers/phy/ti/phy-tusb1210.c
index d8d0cc11d187..a63213f5972a 100644
--- a/drivers/phy/ti/phy-tusb1210.c
+++ b/drivers/phy/ti/phy-tusb1210.c
@@ -7,15 +7,16 @@
* Author: Heikki Krogerus
*/
#include
+#include
#include
#include
#include
#include
#define TUSB1210_VENDOR_SPECIFIC2 0x80
-#define TUSB1210_VENDOR_SPECIFIC2_IHSTX_SHIFT 0
-#define TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_SHIFT 4
-#define TUSB1210_VENDOR_SPECIFIC2_DP_SHIFT 6
+#define TUSB1210_VENDOR_SPECIFIC2_IHSTX_MASK GENMASK(3, 0)
+#define TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_MASK GENMASK(5, 4)
+#define TUSB1210_VENDOR_SPECIFIC2_DP_MASK BIT(6)
struct tusb1210 {
struct ulpi *ulpi;
@@ -118,22 +119,22 @@ static int tusb1210_probe(struct ulpi *ulpi)
* diagram optimization and DP/DM swap.
*/
+ reg = ulpi_read(ulpi, TUSB1210_VENDOR_SPECIFIC2);
+
/* High speed output drive strength configuration */
- device_property_read_u8(>dev, "ihstx", );
- reg = val << TUSB1210_VENDOR_SPECIFIC2_IHSTX_SHIFT;
+ if (!device_property_read_u8(>dev, "ihstx", ))
+ u8p_replace_bits(, val,
(u8)TUSB1210_VENDOR_SPECIFIC2_IHSTX_MASK);
/* High speed output impedance configuration */
- device_property_read_u8(>dev, "zhsdrv", );
- reg |= val << TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_SHIFT;
+ if (!device_property_read_u8(>dev, "zhsdrv", ))
+ u8p_replace_bits(, val,
(u8)TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_MASK);
/* DP/DM swap control */
- device_property_read_u8(>dev, "datapolarity", );
- reg |= val << TUSB1210_VENDOR_SPECIFIC2_DP_SHIFT;
+ if (!device_property_read_u8(>dev, "datapolarity", ))
+ u8p_replace_bits(, val,
(u8)TUSB1210_VENDOR_SPECIFIC2_DP_MASK);
- if (reg) {
- ulpi_write(ulpi, TUSB1210_VENDOR_SPECIFIC2, reg);
- tusb->vendor_specific2 = reg;
- }
+ ulpi_write(ulpi, TUSB1210_VENDOR_SPECIFIC2, reg);
+ tusb->vendor_specific2 = reg;
tusb->phy = ulpi_phy_create(ulpi, _ops);
if (IS_ERR(tusb->phy))
base-commit: 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5
--
2.27.0
Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION
On Sat, Aug 22, 2020 at 1:19 PM Pascal Bouchareine wrote: > > On Sat, Aug 22, 2020 at 12:59 PM Pascal Bouchareine wrote: > > > Would it make sense to also make UDIAG_SHOW_NAME use sk_description? > > (And keep the existing change - setsockopt + show_fd_info via > > /proc/.../fdinfo/..) > > > Ah,very wrong example - to be more precise, I suppose that'd be adding > a couple idiag_ext for sk_description and pid if possible instead About the pid part - On top of multiple pids to scan for a given socket, there's also the security provided by /proc - I'm not sure what inet_diag does for that So maybe users calling it will need to scan /proc for a long time anyway... Or is that doable?
[PATCH v3] memory: brcmstb_dpfe: fix array index out of bounds
We would overrun the error_text array if we hit a TIMEOUT condition,
because we were using the error code "ETIMEDOUT" (which is 110) as an
array index.
We fix the problem by correcting the array index and by providing a
function to retrieve error messages rather than accessing the array
directly. The function includes a bounds check that prevents the array
from being overrun.
This patch was prepared in response to
https://lkml.org/lkml/2020/8/18/505.
Signed-off-by: Markus Mayer
Acked-by: Florian Fainelli
Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE")
Reported-by: Colin Ian King
---
Changes since v2:
- Added "Fixes:" and "Reported-by:"
- Fixed "From" address
- No changes to the code
Changes since v1:
- Added link of the coverity report to the commit message.
- Added Florian's ack.
- Removed second "const" from get_error_text() return type
(thanks to the kernel test robot).
drivers/memory/brcmstb_dpfe.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index e08528b12cbd..dcf50bb8dd69 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -188,11 +188,6 @@ struct brcmstb_dpfe_priv {
struct mutex lock;
};
-static const char * const error_text[] = {
- "Success", "Header code incorrect", "Unknown command or argument",
- "Incorrect checksum", "Malformed command", "Timed out",
-};
-
/*
* Forward declaration of our sysfs attribute functions, so we can declare the
* attribute data structures early.
@@ -307,6 +302,20 @@ static const struct dpfe_api dpfe_api_v3 = {
},
};
+static const char *get_error_text(unsigned int i)
+{
+ static const char * const error_text[] = {
+ "Success", "Header code incorrect",
+ "Unknown command or argument", "Incorrect checksum",
+ "Malformed command", "Timed out", "Unknown error",
+ };
+
+ if (unlikely(i >= ARRAY_SIZE(error_text)))
+ i = ARRAY_SIZE(error_text) - 1;
+
+ return error_text[i];
+}
+
static bool is_dcpu_enabled(struct brcmstb_dpfe_priv *priv)
{
u32 val;
@@ -445,7 +454,7 @@ static int __send_command(struct brcmstb_dpfe_priv *priv,
unsigned int cmd,
}
if (resp != 0) {
mutex_unlock(>lock);
- return -ETIMEDOUT;
+ return -ffs(DCPU_RET_ERR_TIMEDOUT);
}
/* Compute checksum over the message */
@@ -695,7 +704,7 @@ static ssize_t generic_show(unsigned int command, u32
response[],
ret = __send_command(priv, command, response);
if (ret < 0)
- return sprintf(buf, "ERROR: %s\n", error_text[-ret]);
+ return sprintf(buf, "ERROR: %s\n", get_error_text(-ret));
return 0;
}
--
2.17.1
Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds
On 8/22/2020 1:47 PM, Markus Mayer wrote: On Sat, 22 Aug 2020 at 13:21, Florian Fainelli wrote: On 8/22/2020 1:14 PM, Markus Mayer wrote: On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski wrote: On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote: On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski wrote: On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote: We would overrun the error_text array if we hit a TIMEOUT condition, because we were using the error code "ETIMEDOUT" (which is 110) as an array index. We fix the problem by correcting the array index and by providing a function to retrieve error messages rather than accessing the array directly. The function includes a bounds check that prevents the array from being overrun. This patch was prepared in response to https://lkml.org/lkml/2020/8/18/505. Signed-off-by: Markus Mayer Your Signed-off-by does not match From field. Please run scripts/checkpatch on every patch you send. I fixed it up, assuming markus.ma...@broadcom.com is the valid email address. No. I have always been using mma...@broadcom.com since it is shorter. That's also what's in the MAINTAINERS file. Please change it back. I accidentally used the long form for one of my e-mail replies which is where the confusion must have originated. I'll drop the patch then. You need to resend with SoB matching email. Oh, I am starting to see what's happening here. This is new and apparently due to some changes with the mail server setup on our end. I have this in my patch file: $ head 0001-memory-brcmstb_dpfe-fix-array-index-out-of-bounds.patch From 6b424772d4c84fa56474b2522d0d3ed6b2b2b360 Mon Sep 17 00:00:00 2001 From: Markus Mayer Date: Fri, 21 Aug 2020 08:56:52 -0700 Sending patches like this used to work. Clearly our SMTP server has now taken it upon itself to rewrite the sender e-mail address. I wasn't expecting that. Let me look into it. Sorry for the hassle. It was not intentional. Yes, if you used to use the SMTP relay server which did not require authentication for internal hosts, and now you use smtp.gmail.com with your broadcom.com username, the SMTP server will rewrite the From: to match the username used to authenticate with the server. Actually, it was the other way around. Connecting to smtp.gmail.com does allow the "From:" header to be customized. The envelope sender, i.e. the "From " line at the very beginning of the e-mail, might still get rewritten, but that's okay since the "From:" header is left alone. The internal SMTP server, however, which does not require authentication, unexpectedly rewrites the "From:" header in the middle of the e-mail header. Got it set up now in a way that should work. At least it did in my test. I'll send out v3 of the patch momentarily, and then we'll know for sure. Reason #42 why I hide behind my gmail.com account! Glad you sorted it out. -- Florian
Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds
On Sat, 22 Aug 2020 at 13:46, Krzysztof Kozlowski wrote: > > On Sat, Aug 22, 2020 at 01:21:47PM -0700, Florian Fainelli wrote: > > > > > > On 8/22/2020 1:14 PM, Markus Mayer wrote: > > > On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski wrote: > > > > > > > > On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote: > > > > > On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski > > > > > wrote: > > > > > > > > > > > > On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote: > > > > > > > We would overrun the error_text array if we hit a TIMEOUT > > > > > > > condition, > > > > > > > because we were using the error code "ETIMEDOUT" (which is 110) > > > > > > > as an > > > > > > > array index. > > > > > > > > > > > > > > We fix the problem by correcting the array index and by providing > > > > > > > a > > > > > > > function to retrieve error messages rather than accessing the > > > > > > > array > > > > > > > directly. The function includes a bounds check that prevents the > > > > > > > array > > > > > > > from being overrun. > > > > > > > > > > > > > > This patch was prepared in response to > > > > > > > https://lkml.org/lkml/2020/8/18/505. > > > > > > > > > > > > > > Signed-off-by: Markus Mayer > > > > > > > > > > > > Your Signed-off-by does not match From field. Please run > > > > > > scripts/checkpatch on every patch you send. > > > > > > > > > > > > I fixed it up, assuming markus.ma...@broadcom.com is the valid email > > > > > > address. > > > > > > > > > > No. I have always been using mma...@broadcom.com since it is shorter. > > > > > That's also what's in the MAINTAINERS file. Please change it back. I > > > > > accidentally used the long form for one of my e-mail replies which is > > > > > where the confusion must have originated. > > > > > > > > I'll drop the patch then. You need to resend with SoB matching email. > > > > > > Oh, I am starting to see what's happening here. This is new and > > > apparently due to some changes with the mail server setup on our end. > > > > > > I have this in my patch file: > > > > > > $ head 0001-memory-brcmstb_dpfe-fix-array-index-out-of-bounds.patch > > > From 6b424772d4c84fa56474b2522d0d3ed6b2b2b360 Mon Sep 17 00:00:00 2001 > > > From: Markus Mayer > > > Date: Fri, 21 Aug 2020 08:56:52 -0700 > > Which means your patch actually passed checkpatch on your computer so my > comment about running it was not smart... :) It did pass, yes. :-) > > > Sending patches like this used to work. Clearly our SMTP server has > > > now taken it upon itself to rewrite the sender e-mail address. I > > > wasn't expecting that. Let me look into it. Sorry for the hassle. It > > > was not intentional. > > > > Yes, if you used to use the SMTP relay server which did not require > > authentication for internal hosts, and now you use smtp.gmail.com with your > > broadcom.com username, the SMTP server will rewrite the From: to match the > > username used to authenticate with the server. > > Markus' patch did not go via GMail. It was the Broadcom server which > mangled the things. The email headers: Indeed. > Received: by mail.kernel.org (Postfix) > Received: from rnd-relay.smtp.broadcom.com (rnd-relay.smtp.broadcom.com > [192.19.229.170]) > by mail.kernel.org (Postfix) with ESMTPS id D5B3B20702 > Received: from mail-irv-17.broadcom.com (mail-irv-17.lvn.broadcom.net > [10.75.242.48]) > Received: from lbrmn-mmayer.ric.broadcom.net (lbrmn-mmayer.ric.broadcom.net > [10.136.28.150]) > From: Markus Mayer > > Neither kernel.org nor my final server (Gmail) cares about usernames in > From fields of some specific domain. > > I guess you could try configure you git send email to use email of > "markus.mayer" while keeping Author "mmayer". You have to configure git > send email for this and such configuration results in proper two "From" > fields which maybe smtp broadcom won't change. Yep. I think I've got it set up now. Stay tuned. > Best regards, > Krzysztof
Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds
On Sat, 22 Aug 2020 at 13:21, Florian Fainelli wrote: > > On 8/22/2020 1:14 PM, Markus Mayer wrote: > > On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski wrote: > >> > >> On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote: > >>> On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski wrote: > > On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote: > > We would overrun the error_text array if we hit a TIMEOUT condition, > > because we were using the error code "ETIMEDOUT" (which is 110) as an > > array index. > > > > We fix the problem by correcting the array index and by providing a > > function to retrieve error messages rather than accessing the array > > directly. The function includes a bounds check that prevents the array > > from being overrun. > > > > This patch was prepared in response to > > https://lkml.org/lkml/2020/8/18/505. > > > > Signed-off-by: Markus Mayer > > Your Signed-off-by does not match From field. Please run > scripts/checkpatch on every patch you send. > > I fixed it up, assuming markus.ma...@broadcom.com is the valid email > address. > >>> > >>> No. I have always been using mma...@broadcom.com since it is shorter. > >>> That's also what's in the MAINTAINERS file. Please change it back. I > >>> accidentally used the long form for one of my e-mail replies which is > >>> where the confusion must have originated. > >> > >> I'll drop the patch then. You need to resend with SoB matching email. > > > > Oh, I am starting to see what's happening here. This is new and > > apparently due to some changes with the mail server setup on our end. > > > > I have this in my patch file: > > > > $ head 0001-memory-brcmstb_dpfe-fix-array-index-out-of-bounds.patch > > From 6b424772d4c84fa56474b2522d0d3ed6b2b2b360 Mon Sep 17 00:00:00 2001 > > From: Markus Mayer > > Date: Fri, 21 Aug 2020 08:56:52 -0700 > > > > Sending patches like this used to work. Clearly our SMTP server has > > now taken it upon itself to rewrite the sender e-mail address. I > > wasn't expecting that. Let me look into it. Sorry for the hassle. It > > was not intentional. > > Yes, if you used to use the SMTP relay server which did not require > authentication for internal hosts, and now you use smtp.gmail.com with > your broadcom.com username, the SMTP server will rewrite the From: to > match the username used to authenticate with the server. Actually, it was the other way around. Connecting to smtp.gmail.com does allow the "From:" header to be customized. The envelope sender, i.e. the "From " line at the very beginning of the e-mail, might still get rewritten, but that's okay since the "From:" header is left alone. The internal SMTP server, however, which does not require authentication, unexpectedly rewrites the "From:" header in the middle of the e-mail header. Got it set up now in a way that should work. At least it did in my test. I'll send out v3 of the patch momentarily, and then we'll know for sure. Regards, -Markus
Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds
On Sat, Aug 22, 2020 at 01:21:47PM -0700, Florian Fainelli wrote: > > > On 8/22/2020 1:14 PM, Markus Mayer wrote: > > On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski wrote: > > > > > > On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote: > > > > On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski > > > > wrote: > > > > > > > > > > On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote: > > > > > > We would overrun the error_text array if we hit a TIMEOUT condition, > > > > > > because we were using the error code "ETIMEDOUT" (which is 110) as > > > > > > an > > > > > > array index. > > > > > > > > > > > > We fix the problem by correcting the array index and by providing a > > > > > > function to retrieve error messages rather than accessing the array > > > > > > directly. The function includes a bounds check that prevents the > > > > > > array > > > > > > from being overrun. > > > > > > > > > > > > This patch was prepared in response to > > > > > > https://lkml.org/lkml/2020/8/18/505. > > > > > > > > > > > > Signed-off-by: Markus Mayer > > > > > > > > > > Your Signed-off-by does not match From field. Please run > > > > > scripts/checkpatch on every patch you send. > > > > > > > > > > I fixed it up, assuming markus.ma...@broadcom.com is the valid email > > > > > address. > > > > > > > > No. I have always been using mma...@broadcom.com since it is shorter. > > > > That's also what's in the MAINTAINERS file. Please change it back. I > > > > accidentally used the long form for one of my e-mail replies which is > > > > where the confusion must have originated. > > > > > > I'll drop the patch then. You need to resend with SoB matching email. > > > > Oh, I am starting to see what's happening here. This is new and > > apparently due to some changes with the mail server setup on our end. > > > > I have this in my patch file: > > > > $ head 0001-memory-brcmstb_dpfe-fix-array-index-out-of-bounds.patch > > From 6b424772d4c84fa56474b2522d0d3ed6b2b2b360 Mon Sep 17 00:00:00 2001 > > From: Markus Mayer > > Date: Fri, 21 Aug 2020 08:56:52 -0700 Which means your patch actually passed checkpatch on your computer so my comment about running it was not smart... :) > > Sending patches like this used to work. Clearly our SMTP server has > > now taken it upon itself to rewrite the sender e-mail address. I > > wasn't expecting that. Let me look into it. Sorry for the hassle. It > > was not intentional. > > Yes, if you used to use the SMTP relay server which did not require > authentication for internal hosts, and now you use smtp.gmail.com with your > broadcom.com username, the SMTP server will rewrite the From: to match the > username used to authenticate with the server. Markus' patch did not go via GMail. It was the Broadcom server which mangled the things. The email headers: Received: by mail.kernel.org (Postfix) Received: from rnd-relay.smtp.broadcom.com (rnd-relay.smtp.broadcom.com [192.19.229.170]) by mail.kernel.org (Postfix) with ESMTPS id D5B3B20702 Received: from mail-irv-17.broadcom.com (mail-irv-17.lvn.broadcom.net [10.75.242.48]) Received: from lbrmn-mmayer.ric.broadcom.net (lbrmn-mmayer.ric.broadcom.net [10.136.28.150]) From: Markus Mayer Neither kernel.org nor my final server (Gmail) cares about usernames in >From fields of some specific domain. I guess you could try configure you git send email to use email of "markus.mayer" while keeping Author "mmayer". You have to configure git send email for this and such configuration results in proper two "From" fields which maybe smtp broadcom won't change. Best regards, Krzysztof
Re: [PATCH net-next] net: Remove unnecessary intermediate variables
On Sat, 2020-08-22 at 12:33 -0700, David Miller wrote:
> From: Jianlin Lv
> Date: Sat, 22 Aug 2020 10:04:31 +0800
>
> > It is not necessary to use src/dst as an intermediate variable for
> > assignment operation; Delete src/dst intermediate variables to avoid
> > unnecessary variable declarations.
> >
> > Signed-off-by: Jianlin Lv
>
> It keeps the line lengths within reasonable length, so these local
> variables are fine.
>
> Also, the appropriate subsystem prefix for this patch should be "vxlan: "
> not "net: " in your Subject line. If someone is skimming the shortlog
> in 'git' how will they tell where exactly in the networking your change
> is being made?
>
> Anyways, I'm not applying this, thanks.
It _might_ be slightly faster to use inlines
instead so there's less copy of 16 byte structs
on the ipv6 side.
It's slightly smaller object code.
---
drivers/net/vxlan.c | 46 ++
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index b9fefe27e3e8..e0ea246b3678 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -95,7 +95,25 @@ static inline bool vxlan_collect_metadata(struct vxlan_sock
*vs)
ip_tunnel_collect_metadata();
}
+static __always_inline
+void vxlan_use_v4_addrs(struct ip_tunnel_info *info,
+ union vxlan_addr *remote_ip,
+ union vxlan_addr *local_ip)
+{
+ info->key.u.ipv4.src = remote_ip->sin.sin_addr.s_addr;
+ info->key.u.ipv4.dst = local_ip->sin.sin_addr.s_addr;
+}
+
#if IS_ENABLED(CONFIG_IPV6)
+static __always_inline
+void vxlan_use_v6_addrs(struct ip_tunnel_info *info,
+ union vxlan_addr *remote_ip,
+ union vxlan_addr *local_ip)
+{
+ info->key.u.ipv6.src = remote_ip->sin6.sin6_addr;
+ info->key.u.ipv6.dst = local_ip->sin6.sin6_addr;
+}
+
static inline
bool vxlan_addr_equal(const union vxlan_addr *a, const union vxlan_addr *b)
{
@@ -2724,17 +2742,11 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
ndst = >dst;
err = skb_tunnel_check_pmtu(skb, ndst, VXLAN_HEADROOM,
netif_is_any_bridge_port(dev));
- if (err < 0) {
+ if (err < 0)
goto tx_error;
- } else if (err) {
- if (info) {
- struct in_addr src, dst;
-
- src = remote_ip.sin.sin_addr;
- dst = local_ip.sin.sin_addr;
- info->key.u.ipv4.src = src.s_addr;
- info->key.u.ipv4.dst = dst.s_addr;
- }
+ if (err) { /* newly built encapsulation length */
+ if (info)
+ vxlan_use_v4_addrs(info, _ip, _ip);
vxlan_encap_bypass(skb, vxlan, vxlan, vni, false);
dst_release(ndst);
goto out_unlock;
@@ -2780,17 +2792,11 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
err = skb_tunnel_check_pmtu(skb, ndst, VXLAN6_HEADROOM,
netif_is_any_bridge_port(dev));
- if (err < 0) {
+ if (err < 0)
goto tx_error;
- } else if (err) {
- if (info) {
- struct in6_addr src, dst;
-
- src = remote_ip.sin6.sin6_addr;
- dst = local_ip.sin6.sin6_addr;
- info->key.u.ipv6.src = src;
- info->key.u.ipv6.dst = dst;
- }
+ if (err) { /* newly built encapsulation length */
+ if (info)
+ vxlan_use_v6_addrs(info, _ip, _ip);
vxlan_encap_bypass(skb, vxlan, vxlan, vni, false);
dst_release(ndst);
net/ipv6/ndisc.c:1362 ndisc_router_discovery() warn: unsigned 'rtime' is never less than zero.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c3d8f220d01220a5b253e422be407d068dc65511
commit: 19e16d220f0adbf899a652dfb1fde2e3a95153e9 neigh: support smaller
retrans_time settting
date: 5 months ago
config: mips-randconfig-m031-20200823 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
net/ipv6/ndisc.c:1362 ndisc_router_discovery() warn: unsigned 'rtime' is never
less than zero.
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19e16d220f0adbf899a652dfb1fde2e3a95153e9
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 19e16d220f0adbf899a652dfb1fde2e3a95153e9
vim +/rtime +1362 net/ipv6/ndisc.c
1238
1239 if (in6_dev->if_flags & IF_RS_SENT) {
1240 /*
1241 * flag that an RA was received after an RS was
sent
1242 * out on this interface.
1243 */
1244 in6_dev->if_flags |= IF_RA_RCVD;
1245 }
1246
1247 /*
1248 * Remember the managed/otherconf flags from most recently
1249 * received RA message (RFC 2462) -- yoshfuji
1250 */
1251 old_if_flags = in6_dev->if_flags;
1252 in6_dev->if_flags = (in6_dev->if_flags & ~(IF_RA_MANAGED |
1253 IF_RA_OTHERCONF)) |
1254 (ra_msg->icmph.icmp6_addrconf_managed ?
1255 IF_RA_MANAGED : 0) |
1256 (ra_msg->icmph.icmp6_addrconf_other ?
1257 IF_RA_OTHERCONF : 0);
1258
1259 if (old_if_flags != in6_dev->if_flags)
1260 send_ifinfo_notify = true;
1261
1262 if (!in6_dev->cnf.accept_ra_defrtr) {
1263 ND_PRINTK(2, info,
1264"RA: %s, defrtr is false for dev: %s\n",
1265__func__, skb->dev->name);
1266 goto skip_defrtr;
1267 }
1268
1269 /* Do not accept RA with source-addr found on local machine
unless
1270 * accept_ra_from_local is set to true.
1271 */
1272 net = dev_net(in6_dev->dev);
1273 if (!in6_dev->cnf.accept_ra_from_local &&
1274 ipv6_chk_addr(net, _hdr(skb)->saddr, in6_dev->dev, 0))
{
1275 ND_PRINTK(2, info,
1276"RA from local address detected on dev: %s:
default router ignored\n",
1277skb->dev->name);
1278 goto skip_defrtr;
1279 }
1280
1281 lifetime = ntohs(ra_msg->icmph.icmp6_rt_lifetime);
1282
1283 #ifdef CONFIG_IPV6_ROUTER_PREF
1284 pref = ra_msg->icmph.icmp6_router_pref;
1285 /* 10b is handled as if it were 00b (medium) */
1286 if (pref == ICMPV6_ROUTER_PREF_INVALID ||
1287 !in6_dev->cnf.accept_ra_rtr_pref)
1288 pref = ICMPV6_ROUTER_PREF_MEDIUM;
1289 #endif
1290 /* routes added from RAs do not use nexthop objects */
1291 rt = rt6_get_dflt_router(net, _hdr(skb)->saddr, skb->dev);
1292 if (rt) {
1293 neigh = ip6_neigh_lookup(>fib6_nh->fib_nh_gw6,
1294 rt->fib6_nh->fib_nh_dev, NULL,
1295_hdr(skb)->saddr);
1296 if (!neigh) {
1297 ND_PRINTK(0, err,
1298"RA: %s got default router without
neighbour\n",
1299__func__);
1300 fib6_info_release(rt);
1301 return;
1302 }
1303 }
1304 if (rt && lifetime == 0) {
1305 ip6_del_rt(net, rt);
1306 rt = NULL;
1307 }
1308
1309 ND_PRINTK(3, info, "RA: rt: %p lifetime: %d, for dev: %s\n",
1310rt, lifetime, skb->dev->name);
1311 if (!rt && lifetime) {
1312 ND_PRINTK(3, info, "RA: adding default router\n");
1313
1314 rt = rt6_add_dflt_router(net, _hdr(skb)->saddr,
1315 skb->dev, pref);
1316 if (!rt) {
1317 ND_PRINTK(0, err,
1318"RA: %s failed to add default
route\n",
1319__func__);
1320 return;
1321 }
1322
1323 neigh =
[PATCH] drivers: staging: comedi: fixed duplicate words from checkpatch
Fixed various different checkpatch duplicate word warnings, the TODO
file said to fix checkpatch warnings.
My old email didn't CC the mailing lists, ignore the old one, sorry.
Signed-off-by: Ethan Edwards
---
drivers/staging/comedi/comedi.h | 4 ++--
drivers/staging/comedi/comedidev.h | 2 +-
drivers/staging/comedi/drivers/addi_apci_1564.c | 4 ++--
drivers/staging/comedi/drivers/comedi_8255.c | 2 +-
drivers/staging/comedi/drivers/ni_tiocmd.c | 2 +-
drivers/staging/comedi/drivers/pcmuio.c | 2 +-
drivers/staging/comedi/drivers/quatech_daqp_cs.c | 2 +-
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/comedi/comedi.h b/drivers/staging/comedi/comedi.h
index 09a940066c0e..b5d00a006dbb 100644
--- a/drivers/staging/comedi/comedi.h
+++ b/drivers/staging/comedi/comedi.h
@@ -680,7 +680,7 @@ struct comedi_rangeinfo {
* value of 1 volt.
*
* The only defined flag value is %RF_EXTERNAL (%0x100), indicating that the
- * the range needs to be multiplied by an external reference.
+ * range needs to be multiplied by an external reference.
*/
struct comedi_krange {
int min;
@@ -970,7 +970,7 @@ enum i8254_mode {
* major reasons exist why this caused major confusion for users:
* 1) The register values are _NOT_ in user documentation, but rather in
* arcane locations, such as a few register programming manuals that are
- * increasingly hard to find and the NI MHDDK (comments in in example
code).
+ * increasingly hard to find and the NI MHDDK (comments in example code).
* There is no one place to find the various valid values of the registers.
* 2) The register values are _NOT_ completely consistent. There is no way
to
* gain any sense of intuition of which values, or even enums one should
use
diff --git a/drivers/staging/comedi/comedidev.h
b/drivers/staging/comedi/comedidev.h
index 0dff1ac057cd..0e1b95ef9a4d 100644
--- a/drivers/staging/comedi/comedidev.h
+++ b/drivers/staging/comedi/comedidev.h
@@ -627,7 +627,7 @@ extern const struct comedi_lrange range_unknown;
* @range: Array of comedi_krange, one for each range.
*
* Each element of @range[] describes the minimum and maximum physical range
- * range and the type of units. Typically, the type of unit is %UNIT_volt
+ * and the type of units. Typically, the type of unit is %UNIT_volt
* (i.e. volts) and the minimum and maximum are in millionths of a volt.
* There may also be a flag that indicates the minimum and maximum are merely
* scale factors for an unknown, external reference.
diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index fadefcb5c237..06fc7ed96200 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -544,7 +544,7 @@ static int apci1564_timer_insn_write(struct comedi_device
*dev,
{
struct apci1564_private *devpriv = dev->private;
- /* just write the last last to the reload register */
+ /* just write the last to the reload register */
if (insn->n) {
unsigned int val = data[insn->n - 1];
@@ -628,7 +628,7 @@ static int apci1564_counter_insn_write(struct comedi_device
*dev,
unsigned int chan = CR_CHAN(insn->chanspec);
unsigned long iobase = devpriv->counters + APCI1564_COUNTER(chan);
- /* just write the last last to the reload register */
+ /* just write the last to the reload register */
if (insn->n) {
unsigned int val = data[insn->n - 1];
diff --git a/drivers/staging/comedi/drivers/comedi_8255.c
b/drivers/staging/comedi/drivers/comedi_8255.c
index 3298725b9ba5..b7ca465933ee 100644
--- a/drivers/staging/comedi/drivers/comedi_8255.c
+++ b/drivers/staging/comedi/drivers/comedi_8255.c
@@ -248,7 +248,7 @@ EXPORT_SYMBOL_GPL(subdev_8255_mm_init);
* subdev_8255_regbase - get offset of 8255 registers or call-back context
* @s: comedi subdevice
*
- * Returns the 'regbase' parameter that was previously passed to to
+ * Returns the 'regbase' parameter that was previously passed to
* subdev_8255_init() or subdev_8255_mm_init() to set up the subdevice.
* Only valid if the subdevice was set up successfully.
*/
diff --git a/drivers/staging/comedi/drivers/ni_tiocmd.c
b/drivers/staging/comedi/drivers/ni_tiocmd.c
index 2a9f7e9821a7..ab6d9e8269f3 100644
--- a/drivers/staging/comedi/drivers/ni_tiocmd.c
+++ b/drivers/staging/comedi/drivers/ni_tiocmd.c
@@ -286,7 +286,7 @@ int ni_tio_cmdtest(struct comedi_device *dev,
* This should be done, but we don't yet know the actual
* register values. These should be tested and then documented
* in the ni_route_values/ni_*.csv files, with indication of
-* who/when/which/how these these were tested.
+* who/when/which/how these were tested.
*
Re: [PATCH RFC 00/12] Core-sched v6+: kernel protection and hotplug fixes
On Fri, Aug 14, 2020 at 11:19 PM Joel Fernandes (Google) wrote: > > Hello! > > This series is continuation of main core-sched v6 series [1] and adds support > for syscall and IRQ isolation from usermode processes and guests. It is key to > safely entering kernel mode in an HT while the other HT is in use by a user or > guest. The series also fixes CPU hotplug issues arising because of the > cpu_smt_mask changing while the next task is being picked. These hotplug fixes > are needed also for kernel protection to work correctly. > > The series is based on Thomas's x86/entry tree. > > [1] https://lwn.net/Articles/824918/ Hello, Just wanted to mention that we are talking about this series during the refereed talk on Monday at 16:00 UTC : https://linuxplumbersconf.org/event/7/contributions/648/ The slides are here with some nice pictures showing the kernel protection stuff: https://docs.google.com/presentation/d/1VzeQo3AyGTN35DJ3LKoPWBfiZHZJiF8q0NrX9eVYG70/edit?usp=sharing And Julien has some promising data to share which he just collected with this series (and will add them to the slides). Looking forward to possibly seeing you there and your participation for these topics both during the refereed talk and the scheduler MC, thanks! - Joel > > Background: > > Core-scheduling prevents hyperthreads in usermode from attacking each > other, but it does not do anything about one of the hyperthreads > entering the kernel for any reason. This leaves the door open for MDS > and L1TF attacks with concurrent execution sequences between > hyperthreads. > > This series adds support for protecting all syscall and IRQ kernel mode > entries > by cleverly tracking when any sibling in a core enter the kernel, and when all > the siblings exit the kernel. IPIs are sent to force siblings into the kernel. > > Care is taken to avoid waiting in IRQ-disabled sections as Thomas suggested > thus avoiding stop_machine deadlocks. Every attempt is made to avoid > unnecessary IPIs. > > Performance tests: > sysbench is used to test the performance of the patch series. Used a 8 cpu/4 > Core VM and ran 2 sysbench tests in parallel. Each sysbench test runs 4 tasks: > sysbench --test=cpu --cpu-max-prime=10 --num-threads=4 run > > Compared the performance results for various combinations as below. > The metric below is 'events per second': > > 1. Coresched disabled > sysbench-1/sysbench-2 => 175.7/175.6 > > 2. Coreched enabled, both sysbench tagged > sysbench-1/sysbench-2 => 168.8/165.6 > > 3. Coresched enabled, sysbench-1 tagged and sysbench-2 untagged > sysbench-1/sysbench-2 => 96.4/176.9 > > 4. smt off > sysbench-1/sysbench-2 => 97.9/98.8 > > When both sysbench-es are tagged, there is a perf drop of ~4%. With a > tagged/untagged case, the tagged one suffers because it always gets > stalled when the sibiling enters kernel. But this is no worse than smtoff. > > Also a modified rcutorture was used to heavily stress the kernel to make sure > there is not crash or instability. > > Joel Fernandes (Google) (5): > irq_work: Add support to detect if work is pending > entry/idle: Add a common function for activites during idle entry/exit > arch/x86: Add a new TIF flag for untrusted tasks > kernel/entry: Add support for core-wide protection of kernel-mode > entry/idle: Enter and exit kernel protection during idle entry and > exit > > Vineeth Pillai (7): > entry/kvm: Protect the kernel when entering from guest > bitops: Introduce find_next_or_bit > cpumask: Introduce a new iterator for_each_cpu_wrap_or > sched/coresched: Use for_each_cpu(_wrap)_or for pick_next_task > sched/coresched: Make core_pick_seq per run-queue > sched/coresched: Check for dynamic changes in smt_mask > sched/coresched: rq->core should be set only if not previously set > > arch/x86/include/asm/thread_info.h | 2 + > arch/x86/kvm/x86.c | 3 + > include/asm-generic/bitops/find.h | 16 ++ > include/linux/cpumask.h| 42 + > include/linux/entry-common.h | 22 +++ > include/linux/entry-kvm.h | 12 ++ > include/linux/irq_work.h | 1 + > include/linux/sched.h | 12 ++ > kernel/entry/common.c | 88 + > kernel/entry/kvm.c | 12 ++ > kernel/irq_work.c | 11 ++ > kernel/sched/core.c| 281 ++--- > kernel/sched/idle.c| 17 +- > kernel/sched/sched.h | 11 +- > lib/cpumask.c | 53 ++ > lib/find_bit.c | 56 -- > 16 files changed, 564 insertions(+), 75 deletions(-) > > -- > 2.28.0.220.ged08abb693-goog >
Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds
On 8/22/2020 1:14 PM, Markus Mayer wrote: On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski wrote: On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote: On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski wrote: On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote: We would overrun the error_text array if we hit a TIMEOUT condition, because we were using the error code "ETIMEDOUT" (which is 110) as an array index. We fix the problem by correcting the array index and by providing a function to retrieve error messages rather than accessing the array directly. The function includes a bounds check that prevents the array from being overrun. This patch was prepared in response to https://lkml.org/lkml/2020/8/18/505. Signed-off-by: Markus Mayer Your Signed-off-by does not match From field. Please run scripts/checkpatch on every patch you send. I fixed it up, assuming markus.ma...@broadcom.com is the valid email address. No. I have always been using mma...@broadcom.com since it is shorter. That's also what's in the MAINTAINERS file. Please change it back. I accidentally used the long form for one of my e-mail replies which is where the confusion must have originated. I'll drop the patch then. You need to resend with SoB matching email. Oh, I am starting to see what's happening here. This is new and apparently due to some changes with the mail server setup on our end. I have this in my patch file: $ head 0001-memory-brcmstb_dpfe-fix-array-index-out-of-bounds.patch From 6b424772d4c84fa56474b2522d0d3ed6b2b2b360 Mon Sep 17 00:00:00 2001 From: Markus Mayer Date: Fri, 21 Aug 2020 08:56:52 -0700 Sending patches like this used to work. Clearly our SMTP server has now taken it upon itself to rewrite the sender e-mail address. I wasn't expecting that. Let me look into it. Sorry for the hassle. It was not intentional. Yes, if you used to use the SMTP relay server which did not require authentication for internal hosts, and now you use smtp.gmail.com with your broadcom.com username, the SMTP server will rewrite the From: to match the username used to authenticate with the server. -- Florian
Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION
On Sat, Aug 22, 2020 at 12:59 PM Pascal Bouchareine wrote: > Would it make sense to also make UDIAG_SHOW_NAME use sk_description? > (And keep the existing change - setsockopt + show_fd_info via > /proc/.../fdinfo/..) Ah,very wrong example - to be more precise, I suppose that'd be adding a couple idiag_ext for sk_description and pid if possible instead
Re: [PATCH 5/5] Add manpage for fsconfig(2)
Hello David, On Fri, 7 Aug 2020 at 16:03, David Howells wrote: > > Add a manual page to document the fsconfig() system call. > > Signed-off-by: David Howells > --- > > man2/fsconfig.2 | 282 > +++ > 1 file changed, 282 insertions(+) > create mode 100644 man2/fsconfig.2 > > diff --git a/man2/fsconfig.2 b/man2/fsconfig.2 > new file mode 100644 > index 0..32f0bce13 > --- /dev/null > +++ b/man2/fsconfig.2 > @@ -0,0 +1,282 @@ > +'\" t > +.\" Copyright (c) 2020 David Howells > +.\" > +.\" %%%LICENSE_START(VERBATIM) > +.\" Permission is granted to make and distribute verbatim copies of this > +.\" manual provided the copyright notice and this permission notice are > +.\" preserved on all copies. > +.\" > +.\" Permission is granted to copy and distribute modified versions of this > +.\" manual under the conditions for verbatim copying, provided that the > +.\" entire resulting derived work is distributed under the terms of a > +.\" permission notice identical to this one. > +.\" > +.\" Since the Linux kernel and libraries are constantly changing, this > +.\" manual page may be incorrect or out-of-date. The author(s) assume no > +.\" responsibility for errors or omissions, or for damages resulting from > +.\" the use of the information contained herein. The author(s) may not > +.\" have taken the same level of care in the production of this manual, > +.\" which is licensed free of charge, as they might when working > +.\" professionally. > +.\" > +.\" Formatted or processed versions of this manual, if unaccompanied by > +.\" the source, must acknowledge the copyright and authors of this work. > +.\" %%%LICENSE_END > +.\" > +.TH FSCONFIG 2 2020-08-07 "Linux" "Linux Programmer's Manual" > +.SH NAME > +fsconfig \- Filesystem parameterisation > +.SH SYNOPSIS > +.nf > +.B #include > +.br Remove all instances of ".br" here in the SYNOPSIS. They aren't needed. > +.B #include > +.br > +.B #include > +.br > +.B #include > +.PP > +.BI "int fsconfig(int *" fd ", unsigned int " cmd ", const char *" key , > +.br > +.BI " const void __user *" value ", int " aux ");" > +.br > +.BI > +.fi > +.PP > +.IR Note : > +There is no glibc wrapper for this system call. > +.SH DESCRIPTION > +.PP > +.BR fsconfig () > +is used to supply parameters to and issue commands against a filesystem > +configuration context as set up by > +.BR fsopen (2) > +or > +.BR fspick (2). > +The context is supplied attached to the file descriptor specified by > +.I fd > +argument. > +.PP > +The > +.I cmd > +argument indicates the command to be issued, where some of the commands > simply > +supply parameters to the context. The meaning of > +.IR key ", " value " and " aux > +are command-dependent; unless required for the command, these should be set > to > +NULL or 0. > +.PP > +The available commands are: > +.TP > +.B FSCONFIG_SET_FLAG > +Set the parameter named by > +.IR key > +to true. This may incur error s/incur error/fail with the error/ (and below as well please) > +.B EINVAL > +if the parameter requires an argument. > +.TP > +.B FSCONFIG_SET_STRING > +Set the parameter named by > +.I key > +to a string. This may incur error > +.B EINVAL > +if the parser doesn't want a parameter here, wants a non-string or the string > +cannot be interpreted appropriately. > +.I value > +points to a NUL-terminated string. > +.TP > +.B FSCONFIG_SET_BINARY > +Set the parameter named by > +.I key > +to be a binary blob argument. This may cause > +.B EINVAL > +to be returned if the filesystem parser isn't expecting a binary blob and it > +can't be converted to something usable. > +.I value > +points to the data and > +.I aux > +indicates the size of the data. > +.TP > +.B FSCONFIG_SET_PATH > +Set the parameter named by > +.I key > +to the object at the provided path. > +.I value > +should point to a NULL-terminated pathname string and aux may indicate > +.B AT_FDCWD > +or a file descriptor indicating a directory from which to begin a relative > +pathwalk. This may return any errors incurred by the pathwalk and may return "pathwalk" is not a standard term (at least not for user-space programmers). What do you mean with this term, and can you replace all instances please. > +.B EINVAL > +if the parameter isn't expecting a path. > +.IP > +Note that FSCONFIG_SET_STRING can be used instead, implying AT_FDCWD. > +.TP > +.B FSCONFIG_SET_PATH_EMPTY > +As FSCONFIG_SET_PATH, but with > +.B AT_EMPTY_PATH > +applied to the pathwalk. > +.TP > +.B FSCONFIG_SET_FD > +Set the parameter named by > +.I key > +to the file descriptor specified by > +.IR aux . > +This will incur > +.B EINVAL > +if the parameter doesn't expect a file descriptor or > +.B EBADF > +if the file descriptor is invalid. > +.IP > +Note that FSCONFIG_SET_STRING can be used instead with the file descriptor > +passed as a decimal string. > +.TP > +.B FSCONFIG_CMD_CREATE > +This command causes the filesystem to take the parameters
Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds
On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski wrote: > > On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote: > > On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski wrote: > > > > > > On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote: > > > > We would overrun the error_text array if we hit a TIMEOUT condition, > > > > because we were using the error code "ETIMEDOUT" (which is 110) as an > > > > array index. > > > > > > > > We fix the problem by correcting the array index and by providing a > > > > function to retrieve error messages rather than accessing the array > > > > directly. The function includes a bounds check that prevents the array > > > > from being overrun. > > > > > > > > This patch was prepared in response to > > > > https://lkml.org/lkml/2020/8/18/505. > > > > > > > > Signed-off-by: Markus Mayer > > > > > > Your Signed-off-by does not match From field. Please run > > > scripts/checkpatch on every patch you send. > > > > > > I fixed it up, assuming markus.ma...@broadcom.com is the valid email > > > address. > > > > No. I have always been using mma...@broadcom.com since it is shorter. > > That's also what's in the MAINTAINERS file. Please change it back. I > > accidentally used the long form for one of my e-mail replies which is > > where the confusion must have originated. > > I'll drop the patch then. You need to resend with SoB matching email. Oh, I am starting to see what's happening here. This is new and apparently due to some changes with the mail server setup on our end. I have this in my patch file: $ head 0001-memory-brcmstb_dpfe-fix-array-index-out-of-bounds.patch >From 6b424772d4c84fa56474b2522d0d3ed6b2b2b360 Mon Sep 17 00:00:00 2001 From: Markus Mayer Date: Fri, 21 Aug 2020 08:56:52 -0700 Sending patches like this used to work. Clearly our SMTP server has now taken it upon itself to rewrite the sender e-mail address. I wasn't expecting that. Let me look into it. Sorry for the hassle. It was not intentional. Regards, -Markus > Best regards, > Krzysztof
[PATCH net-next 4/6] MAINTAINERS: GENET: Add UniMAC MDIO controller files
In preparation for removing myself from the PHYLIB entry, add the UniMAC MDIO controller files (DT binding, driver and platform_data header) to the GENET entry. The UniMAC MDIO controller is essential to the GENET operation, therefore it makes sense to group them together. Signed-off-by: Florian Fainelli --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5aeb00031182..4eb5b61d374a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3581,8 +3581,11 @@ L: bcm-kernel-feedback-l...@broadcom.com L: net...@vger.kernel.org S: Supported F: Documentation/devicetree/bindings/net/brcm,bcmgenet.txt +F: Documentation/devicetree/bindings/net/brcm,unimac-mdio.txt F: drivers/net/ethernet/broadcom/genet/ +F: drivers/net/mdio/mdio-bcm-unimac.c F: include/linux/platform_data/bcmgenet.h +F: include/linux/platform_data/mdio-bcm-unimac.h BROADCOM IPROC ARM ARCHITECTURE M: Ray Jui -- 2.17.1
[PATCH net-next 5/6] MAINTAINERS: Add entry for Broadcom Ethernet PHY drivers
Add an entry for the Broadcom Ethernet PHY drivers covering the BCM63xx, BCM7xxx, BCM87xx, BCM54140, BCM84881, the venerable broadcom.c driver and the companion library files. Signed-off-by: Florian Fainelli --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4eb5b61d374a..db4158515592 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3574,6 +3574,16 @@ L: bcm-kernel-feedback-l...@broadcom.com S: Maintained F: drivers/phy/broadcom/phy-brcm-usb* +BROADCOM ETHERNET PHY DRIVERS +M: Florian Fainelli +L: bcm-kernel-feedback-l...@broadcom.com +L: net...@vger.kernel.org +S: Supported +F: Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt +F: drivers/net/phy/bcm*.[ch] +F: drivers/net/phy/broadcom.c +F: include/linux/brcmphy.h + BROADCOM GENET ETHERNET DRIVER M: Doug Berger M: Florian Fainelli -- 2.17.1
[PATCH net-next 6/6] MAINTAINERS: Remove self from PHY LIBRARY
My last significant achievements to the PHY library was ensuring we would have small bus factor by having Andrew and Heiner added. The world has moved on past 1G, but I have not, so let more competent maintainers take over. Signed-off-by: Florian Fainelli --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index db4158515592..b1474c669e1e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6519,7 +6519,6 @@ F:net/bridge/ ETHERNET PHY LIBRARY M: Andrew Lunn -M: Florian Fainelli M: Heiner Kallweit R: Russell King L: net...@vger.kernel.org -- 2.17.1
[PATCH net-next 3/6] MAINTAINERS: GENET: Add DT binding file
When the DT binding was added in aab5127d94e6 ("Documentation: add
Device tree bindings for Broadcom GENET"), the file was not explicitly
listed under the GENET MAINTAINERS section, do that now.
Signed-off-by: Florian Fainelli
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cd80f641f9fd..5aeb00031182 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3580,6 +3580,7 @@ M:Florian Fainelli
L: bcm-kernel-feedback-l...@broadcom.com
L: net...@vger.kernel.org
S: Supported
+F: Documentation/devicetree/bindings/net/brcm,bcmgenet.txt
F: drivers/net/ethernet/broadcom/genet/
F: include/linux/platform_data/bcmgenet.h
--
2.17.1
[PATCH net-next 1/6] MAINTAINERS: GENET: Add missing platform data file
When commit b0ba512e25d7 ("net: bcmgenet: enable driver to work without
a device tree") added include/linux/platform_data/bcmgenet.h, the file
was not added to the GENET MAINTAINERS file section, add it now.
Signed-off-by: Florian Fainelli
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2c8964c9b876..0c081a21a3e9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3580,6 +3580,7 @@ L:bcm-kernel-feedback-l...@broadcom.com
L: net...@vger.kernel.org
S: Supported
F: drivers/net/ethernet/broadcom/genet/
+F: include/linux/platform_data/bcmgenet.h
BROADCOM IPROC ARM ARCHITECTURE
M: Ray Jui
--
2.17.1
[PATCH net-next 2/6] MAINTAINERS: B53: Add DT binding file
When the binding was added with 967dd82ffc52 ("net: dsa: b53: Add
support for Broadcom RoboSwitch"), it was not explicitly added to the
B53 MAINTAINERS file section, add it now.
Signed-off-by: Florian Fainelli
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0c081a21a3e9..cd80f641f9fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3388,6 +3388,7 @@ M:Florian Fainelli
L: net...@vger.kernel.org
L: openwrt-de...@lists.openwrt.org (subscribers-only)
S: Supported
+F: Documentation/devicetree/bindings/net/dsa/b53.txt
F: drivers/net/dsa/b53/*
F: include/linux/platform_data/b53.h
--
2.17.1
build failure: aicasm: renamed yaccage
Hi! My randconfig builds notoriously fail on this: [~/linux/drivers/scsi/aic7xxx/aicasm](vanilla)$ make -j1 bison -d -b aicasm_gram aicasm_gram.y mv aicasm_gram.tab.c .//aicasm_gram.c mv aicasm_gram.tab.h .//aicasm_gram.h bison -d -b aicasm_macro_gram -p mm aicasm_macro_gram.y mv aicasm_macro_gram.tab.c .//aicasm_macro_gram.c mv aicasm_macro_gram.tab.h .//aicasm_macro_gram.h flex -o aicasm_scan.c aicasm_scan.l flex -Pmm -o aicasm_macro_scan.c aicasm_macro_scan.l cc -I/usr/include -I. -I./ aicasm.c aicasm_symbol.c .//aicasm_gram.c .//aicasm_macro_gram.c .//aicasm_scan.c .//aicasm_macro_scan.c -o .//aicasm -ldb aicasm_symbol.c: In function ‘aic_print_reg_dump_end’: aicasm_symbol.c:393:13: warning: implicit declaration of function ‘tolower’ [-Wimplicit-function-declaration] 393 | *letter = tolower(*letter); | ^~~ aicasm_gram.tab.c:204:10: fatal error: aicasm_gram.tab.h: No such file or directory compilation terminated. aicasm_macro_gram.tab.c:167:10: fatal error: aicasm_macro_gram.tab.h: No such file or directory compilation terminated. And the generated yaccage has: #include "aicasm_gram.tab.h" which tries to refer to the just renamed file. As the files in question are generated, with the filename coming from $YACC rather than source, it'd take some after-processing with sed or a similar hack. Thus, instead of sending a patch, I thought it'd better to ask: what the renames are for? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i. ⠈⠳⣄
[PATCH net-next 0/6] MAINTAINERS: Remove self from PHY LIBRARY
Hi David, Heiner, Andrew, Russell, This patch series aims at allowing myself to keep track of the Ethernet PHY and MDIO bus drivers that I authored or contributed to without being listed as a maintainer in the PHY library anymore. Thank you for the fish, I will still be around. This builds on top of Andrew's series: https://lore.kernel.org/netdev/20200822180611.2576807-1-and...@lunn.ch/ Florian Fainelli (6): MAINTAINERS: GENET: Add missing platform data file MAINTAINERS: B53: Add DT binding file MAINTAINERS: GENET: Add DT binding file MAINTAINERS: GENET: Add UniMAC MDIO controller files MAINTAINERS: Add entry for Broadcom Ethernet PHY drivers MAINTAINERS: Remove self from PHY LIBRARY MAINTAINERS | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) -- 2.17.1
Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2)
Hi David, On Fri, 7 Aug 2020 at 16:03, David Howells wrote: > > Add a manual page to document the fsopen() and fsmount() system calls. > > Signed-off-by: David Howells > --- > > man2/fsmount.2 |1 > man2/fsopen.2 | 254 > > 2 files changed, 255 insertions(+) > create mode 100644 man2/fsmount.2 > create mode 100644 man2/fsopen.2 > > diff --git a/man2/fsmount.2 b/man2/fsmount.2 > new file mode 100644 > index 0..2bf59fc3e > --- /dev/null > +++ b/man2/fsmount.2 > @@ -0,0 +1 @@ > +.so man2/fsopen.2 > diff --git a/man2/fsopen.2 b/man2/fsopen.2 > new file mode 100644 > index 0..b36ea1609 > --- /dev/null > +++ b/man2/fsopen.2 > @@ -0,0 +1,254 @@ > +'\" t > +.\" Copyright (c) 2020 David Howells > +.\" > +.\" %%%LICENSE_START(VERBATIM) > +.\" Permission is granted to make and distribute verbatim copies of this > +.\" manual provided the copyright notice and this permission notice are > +.\" preserved on all copies. > +.\" > +.\" Permission is granted to copy and distribute modified versions of this > +.\" manual under the conditions for verbatim copying, provided that the > +.\" entire resulting derived work is distributed under the terms of a > +.\" permission notice identical to this one. > +.\" > +.\" Since the Linux kernel and libraries are constantly changing, this > +.\" manual page may be incorrect or out-of-date. The author(s) assume no > +.\" responsibility for errors or omissions, or for damages resulting from > +.\" the use of the information contained herein. The author(s) may not > +.\" have taken the same level of care in the production of this manual, > +.\" which is licensed free of charge, as they might when working > +.\" professionally. > +.\" > +.\" Formatted or processed versions of this manual, if unaccompanied by > +.\" the source, must acknowledge the copyright and authors of this work. > +.\" %%%LICENSE_END > +.\" > +.TH FSOPEN 2 2020-08-07 "Linux" "Linux Programmer's Manual" > +.SH NAME > +fsopen, fsmount \- Filesystem parameterisation and mount creation > +.SH SYNOPSIS > +.nf > +.B #include > +.br > +.B #include > +.br Remove all instances of ".br" here in the SYNOPSIS. They aren't needed (because of the .nf above). > +.B #include > +.br > +.BR "#include" "/* Definition of AT_* constants */" > +.PP > +.BI "int fsopen(const char *" fsname ", unsigned int " flags ); > +.PP > +.BI "int fsmount(int " fd ", unsigned int " flags ", unsigned int " > mount_attrs ); > +.fi > +.PP > +.IR Note : > +There are no glibc wrappers for these system calls. > +.SH DESCRIPTION > +.PP > +.BR fsopen () > +creates a blank filesystem configuration context within the kernel for the > +filesystem named in the > +.I fsname > +parameter, puts it into creation mode and attaches it to a file descriptor, > +which it then returns. The file descriptor can be marked close-on-exec by > +setting > +.B FSOPEN_CLOEXEC > +in > +.IR flags . > +.PP > +After calling fsopen(), the file descriptor should be passed to the > +.BR fsconfig (2) > +system call, using that to specify the desired filesystem and security > +parameters. > +.PP > +When the parameters are all set, the > +.BR fsconfig () > +system call should then be called again with > +.B FSCONFIG_CMD_CREATE > +as the command argument to effect the creation. > +.RS > +.PP > +.BR "[!]\ NOTE" : > +Depending on the filesystem type and parameters, this may rather share an > +existing in-kernel filesystem representation instead of creating a new one. > +In such a case, the parameters specified may be discarded or may overwrite > the > +parameters set by a previous mount - at the filesystem's discretion. > +.RE > +.PP > +The file descriptor also serves as a channel by which more comprehensive > error, > +warning and information messages may be retrieved from the kernel using > +.BR read (2). > + Delete blank line above. > +.PP > +Once the creation command has been successfully run on a context, the context > +is switched into need-mount mode which prevents further configuration. At > +this point, > +.BR fsmount () > +should be called to create a mount object. > +.PP > +.BR fsmount () > +takes the file descriptor returned by > +.BR fsopen () > +and creates a mount object for the filesystem root specified there. The > +attributes of the mount object are set from the > +.I mount_attrs > +parameter. The attributes specify the propagation and mount restrictions to > +be applied to accesses through this mount. > +.PP > +The mount object is then attached to a new file descriptor that looks like > one > +created by > +.BR open "(2) with " O_PATH " or " open_tree (2). > +This can be passed to > +.BR move_mount (2) > +to attach the mount object to a mountpoint, thereby completing the process. > +.PP > +The file descriptor returned by fsmount() is marked close-on-exec if > +FSMOUNT_CLOEXEC is specified in > +.IR flags . > +.PP > +After fsmount() has completed, the context
Re: [PATCH] ARM: dts: imx7d-zii-rmu2: fix rgmii phy-mode for ksz9031 phy
On Sat, Aug 22, 2020 at 12:59 PM Fabio Estevam wrote:
>
> Hi Chris,
>
> On Mon, Aug 17, 2020 at 12:04 AM Chris Healy wrote:
> >
> > From: Chris Healy
> >
> > Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the
> > KSZ9031 PHY") the networking is broken on the imx7d-zii-rmu2 board.
> >
> > Fix it by switching to phy-mode = "rgmii-id".
>
> The patch looks good, but the commit log could be improved to explain
> more about the reason for the breakage.
>
> Please check commit 0672d22a19244 ("ARM: dts: imx: Fix the AR803X
> phy-mode") as a reference.
Sounds good, I'll improve the commit log in v2.
Re: [PATCH 3/5] Add manpage for fspick(2)
Hello David, On Fri, 7 Aug 2020 at 16:02, David Howells wrote: > > Add a manual page to document the fspick() system call. > > Signed-off-by: David Howells > --- > > man2/fspick.2 | 195 > + > 1 file changed, 195 insertions(+) > create mode 100644 man2/fspick.2 > > diff --git a/man2/fspick.2 b/man2/fspick.2 > new file mode 100644 > index 0..24242b98b > --- /dev/null > +++ b/man2/fspick.2 > @@ -0,0 +1,195 @@ > +'\" t > +.\" Copyright (c) 2020 David Howells > +.\" > +.\" %%%LICENSE_START(VERBATIM) > +.\" Permission is granted to make and distribute verbatim copies of this > +.\" manual provided the copyright notice and this permission notice are > +.\" preserved on all copies. > +.\" > +.\" Permission is granted to copy and distribute modified versions of this > +.\" manual under the conditions for verbatim copying, provided that the > +.\" entire resulting derived work is distributed under the terms of a > +.\" permission notice identical to this one. > +.\" > +.\" Since the Linux kernel and libraries are constantly changing, this > +.\" manual page may be incorrect or out-of-date. The author(s) assume no > +.\" responsibility for errors or omissions, or for damages resulting from > +.\" the use of the information contained herein. The author(s) may not > +.\" have taken the same level of care in the production of this manual, > +.\" which is licensed free of charge, as they might when working > +.\" professionally. > +.\" > +.\" Formatted or processed versions of this manual, if unaccompanied by > +.\" the source, must acknowledge the copyright and authors of this work. > +.\" %%%LICENSE_END > +.\" > +.TH FSPICK 2 2020-08-07 "Linux" "Linux Programmer's Manual" > +.SH NAME > +fspick \- Select filesystem for reconfiguration > +.SH SYNOPSIS > +.nf > +.B #include > +.br Remove all instances of ".br" here in the SYNOPSIS. They aren't needed (because of the .nf above). > +.B #include > +.br > +.B #include > +.br > +.BR "#include" "/* Definition of AT_* constants */" > +.PP > +.BI "int fspick(int " dirfd ", const char *" pathname ", unsigned int " > flags ); > +.fi > +.PP > +.IR Note : > +There is no glibc wrapper for this system call. > +.SH DESCRIPTION > +.PP > +.BR fspick () > +creates a new filesystem configuration context within the kernel and > attaches a > +pre-existing superblock to it so that it can be reconfigured (similar to > +.BR mount (8) > +with the "-o remount" option). The configuration context is marked as being > in > +reconfiguration mode and attached to a file descriptor, which is returned to > +the caller. This can be marked close-on-exec by setting s/This/The file descriptor/ > +.B FSPICK_CLOEXEC > +in > +.IR flags . > +.PP > +The target is whichever superblock backs the object determined by > +.IR dfd ", " pathname " and " flags . > +The following can be set in > +.I flags > +to control the pathwalk to that object: > +.TP > +.B FSPICK_SYMLINK_NOFOLLOW > +Don't follow symbolic links in the terminal component of the path. Better: s/terminal/final/ > +.TP > +.B FSPICK_NO_AUTOMOUNT > +Don't follow automounts in the terminal component of the path. Better: s/terminal/final/ > +.TP > +.B FSPICK_EMPTY_PATH > +Allow an empty string to be specified as the pathname. This allows > +.I dirfd > +to specify a path exactly. The use of "path" in the above line is "off"; dirfd is a file descriptor. Can you reword? > +.PP > +After calling fspick(), the file descriptor should be passed to the > +.BR fsconfig (2) > +system call, using that to specify the desired changes to filesystem and > +security parameters. > +.PP > +When the parameters are all set, the > +.BR fsconfig () > +system call should then be called again with > +.B FSCONFIG_CMD_RECONFIGURE > +as the command argument to effect the reconfiguration. > +.PP > +After the reconfiguration has taken place, the context is wiped clean (apart > +from the superblock attachment, which remains) and can be reused to make > +another reconfiguration. > +.PP > +The file descriptor also serves as a channel by which more comprehensive > error, > +warning and information messages may be retrieved from the kernel using > +.BR read (2). > + > + > +.\" Please remove above three lines. > +.SS Message Retrieval Interface > +The context file descriptor may be queried for message strings at any time by > +calling > +.BR read (2) > +on the file descriptor. This will return formatted messages that are > prefixed > +to indicate their class: > +.TP > +\fB"e "\fP > +An error message string was logged. > +.TP > +\fB"i "\fP > +An informational message string was logged. > +.TP > +\fB"w "\fP > +An warning message string was logged. > +.PP > +Messages are removed from the queue as they're read and the queue has a > limited > +depth, so it's possible for some to get lost. s/depth/length/ (or "size"). And, what is the
Re: [PATCH 2/5] Add manpages for move_mount(2) and open_tree(2)
Hello David,
On Fri, 7 Aug 2020 at 16:02, David Howells wrote:
>
> Add manual pages to document the move_mount and open_tree() system calls.
Notwithstanding the title and the commit message, this patch documents
just move_mount(). Could you revise the title and commit message for
the next iteration please.
> Signed-off-by: David Howells
> ---
>
> man2/move_mount.2 | 275
> +
> 1 file changed, 275 insertions(+)
> create mode 100644 man2/move_mount.2
>
> diff --git a/man2/move_mount.2 b/man2/move_mount.2
> new file mode 100644
> index 0..aae9013fa
> --- /dev/null
> +++ b/man2/move_mount.2
> @@ -0,0 +1,275 @@
> +'\" t
> +.\" Copyright (c) 2020 David Howells
> +.\"
> +.\" %%%LICENSE_START(VERBATIM)
> +.\" Permission is granted to make and distribute verbatim copies of this
> +.\" manual provided the copyright notice and this permission notice are
> +.\" preserved on all copies.
> +.\"
> +.\" Permission is granted to copy and distribute modified versions of this
> +.\" manual under the conditions for verbatim copying, provided that the
> +.\" entire resulting derived work is distributed under the terms of a
> +.\" permission notice identical to this one.
> +.\"
> +.\" Since the Linux kernel and libraries are constantly changing, this
> +.\" manual page may be incorrect or out-of-date. The author(s) assume no
> +.\" responsibility for errors or omissions, or for damages resulting from
> +.\" the use of the information contained herein. The author(s) may not
> +.\" have taken the same level of care in the production of this manual,
> +.\" which is licensed free of charge, as they might when working
> +.\" professionally.
> +.\"
> +.\" Formatted or processed versions of this manual, if unaccompanied by
> +.\" the source, must acknowledge the copyright and authors of this work.
> +.\" %%%LICENSE_END
> +.\"
> +.TH MOVE_MOUNT 2 2020-08-07 "Linux" "Linux Programmer's Manual"
> +.SH NAME
> +move_mount \- Move mount objects around the filesystem topology
> +.SH SYNOPSIS
> +.nf
> +.B #include
> +.br
Delete the previous line (".br), and the same below (twice).
> +.B #include
> +.br
> +.B #include
> +.br
> +.BR "#include" "/* Definition of AT_* constants */"
> +.PP
> +.BI "int move_mount(int " from_dirfd ", const char *" from_pathname ","
> +.BI " int " to_dirfd ", const char *" to_pathname ","
> +.BI " unsigned int " flags );
> +.fi
> +.PP
> +.IR Note :
> +There is no glibc wrapper for this system call.
> +.SH DESCRIPTION
> +The
> +.BR move_mount ()
> +call moves a mount from one place to another; it can also be used to attach
> an
> +unattached mount created by
s/created/previously created/ ?
> +.BR fsmount "() or " open_tree "() with " OPEN_TREE_CLONE .
> +.PP
> +If
> +.BR move_mount ()
> +is called repeatedly with a file descriptor that refers to a mount object,
> +then the object will be attached/moved the first time and then moved again
> and
> +again and again, detaching it from the previous mountpoint each time.
s/again and again and again/repeatedly/
s/mountpoint/mount point/
> +.PP
> +To access the source mount object or the destination mountpoint, no
> +permissions are required on the object itself, but if either pathname is
> +supplied, execute (search) permission is required on all of the directories
> +specified in
> +.IR from_pathname " or " to_pathname .
> +.PP
> +The caller does, however, require the appropriate capabilities or permission
> +to effect a mount.
Maybe better: s/effect/create/
> +.PP
> +.BR move_mount ()
> +uses
> +.IR from_pathname ", " from_dirfd " and part of " flags
> +to locate the mount object to be moved and
> +.IR to_pathname ", " to_dirfd " and another part of " flags
> +to locate the destination mountpoint. Each lookup can be done in one of a
> +variety of ways:
> +.TP
> +[*] By absolute path.
> +The pathname points to an absolute path and the dirfd is ignored. The file
> is
> +looked up by name, starting from the root of the filesystem as seen by the
> +calling process.
> +.TP
> +[*] By cwd-relative path.
> +The pathname points to a relative path and the dirfd is
> +.IR AT_FDCWD .
> +The file is looked up by name, starting from the current working directory.
> +.TP
> +[*] By dir-relative path.
> +The pathname points to relative path and the dirfd indicates a file
> descriptor
> +pointing to a directory. The file is looked up by name, starting from the
> +directory specified by
> +.IR dirfd .
> +.TP
> +[*] By file descriptor.
> +The pathname points to "", the dirfd points directly to the mount object to
Better: The pathname is an empty string ("")
> +move or the destination mount point and the appropriate
> +.B *_EMPTY_PATH
> +flag is set.
> +.PP
> +.I flags
> +can be used to influence a path-based lookup. A value for
s/A value/The value/
> +.I flags
> +is constructed by OR'ing together zero or more of the following constants:
> +.TP
> +.BR
