[PATCH 2/3] tracing: initialize variable in create_dyn_event()
From: Frank Rowand
Fix compile warning in create_dyn_event(): 'ret' may be used uninitialized
in this function [-Wuninitialized].
Link:
http://lkml.kernel.org/r/1553237900-8555-1-git-send-email-frowand.l...@gmail.com
Cc: Masami Hiramatsu
Cc: Ingo Molnar
Cc: Tom Zanussi
Cc: Ravi Bangoria
Cc: sta...@vger.kernel.org
Fixes: 5448d44c3855 ("tracing: Add unified dynamic event framework")
Signed-off-by: Frank Rowand
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_dynevent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_dynevent.c b/kernel/trace/trace_dynevent.c
index dd1f43588d70..fa100ed3b4de 100644
--- a/kernel/trace/trace_dynevent.c
+++ b/kernel/trace/trace_dynevent.c
@@ -74,7 +74,7 @@ int dyn_event_release(int argc, char **argv, struct
dyn_event_operations *type)
static int create_dyn_event(int argc, char **argv)
{
struct dyn_event_operations *ops;
- int ret;
+ int ret = -ENODEV;
if (argv[0][0] == '-' || argv[0][0] == '!')
return dyn_event_release(argc, argv, NULL);
--
2.20.1
[PATCH 0/3] [GIT PULL] tracing: Minor fixes for 5.1-rc2
Linus, Three small fixes: - A fix to a double free in the histogram code - Uninitialized variable fix - Use NULL instead of zero fix and spelling fixes Please pull the latest trace-v5.1-rc2 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-v5.1-rc2 Tag SHA1: ed41a01c516cdb7f43a2e0fde385f94f06dff5ff Head SHA1: 9efb85c5cfac7e1f0caae4471446d936ff2163fe Frank Rowand (1): tracing: initialize variable in create_dyn_event() Hariprasad Kelam (1): ftrace: Fix warning using plain integer as NULL & spelling corrections Tom Zanussi (1): tracing: Remove unnecessary var_ref destroy in track_data_destroy() kernel/trace/ftrace.c| 12 ++-- kernel/trace/trace_dynevent.c| 2 +- kernel/trace/trace_events_hist.c | 1 - 3 files changed, 7 insertions(+), 8 deletions(-)
[PATCH v2 0/6] Device property improvements, add %pfw format specifier
Hi all,
This set adds functionality into the device property API (counting a
node's parents as well as obtaining its name) in order to support printing
fwnode names using a new conversion specifier "%pfw". The names that are
produced are equivalent to its OF counterpart "%pOF" on OF systems for the
two supported modifiers ("f" and "P").
Printing a node's name is something that's been available on OF for a long
time and if something is converted to device property API (such as the
V4L2 fwnode framework) it always got removed of a nice feature that was
sometimes essential in debugging. With this set, that no longer is the
case.
This set depends on a cleanup fully releasing the now-deprecated %pf for
other use:
https://lore.kernel.org/lkml/20190325211906.ga24...@google.com/T/#t>
I was a bit hesitant on how much of this should be covered by the fwnode
ops and how much would be just better to reside in lib/vsprintf.c, but
opted for putting it to the fwnode interface. This keeps it clean in
vsprintf.c and still rather lean on the fwnode ops side while making it
possible to add other firmware types (although that is unlikely I guess).
since v1:
- Add patch to remove support for %pf and %pF (depends on another patch
removing all use of %pf and %pF) (now 4th patch)
- Fix kerneldoc argument documentation for fwnode_get_name (2nd patch)
- Align kerneldoc style with the rest of drivers/base/property.c (no extra
newline after function name)
- Make checkpatch.pl complain about "%pf" not followed by "w" (6th patch)
- WARN_ONCE() on use of invalid conversion specifiers ("%pf" not followed
by "w")
Sakari Ailus (6):
device property: Add functions for accessing node's parents
device property: Add fwnode_get_name for returning the name of a node
device property: Add a function to obtain a node's prefix
lib/vsprintf: Remove support for %pF and %pf in favour of %pS and %ps
lib/vsprintf: Make use of fwnode API to obtain node names and
separators
lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
Documentation/core-api/printk-formats.rst | 34 +++---
drivers/acpi/property.c | 46 ++
drivers/base/property.c | 82 +---
drivers/of/property.c | 16 +
include/linux/fwnode.h| 4 ++
include/linux/property.h | 5 ++
lib/vsprintf.c| 101 +-
scripts/checkpatch.pl | 4 +-
8 files changed, 245 insertions(+), 47 deletions(-)
--
2.11.0
[PATCH 1/3] tracing: Remove unnecessary var_ref destroy in track_data_destroy()
From: Tom Zanussi
Commit 656fe2ba85e8 (tracing: Use hist trigger's var_ref array to
destroy var_refs) centralized the destruction of all the var_refs
in one place so that other code didn't have to do it.
The track_data_destroy() added later ignored that and also destroyed
the track_data var_ref, causing a double-free error flagged by KASAN.
==
BUG: KASAN: use-after-free in destroy_hist_field+0x30/0x70
Read of size 8 at addr 888086df2210 by task bash/1694
CPU: 6 PID: 1694 Comm: bash Not tainted 5.1.0-rc1-test+ #15
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03
07/14/2016
Call Trace:
dump_stack+0x71/0xa0
? destroy_hist_field+0x30/0x70
print_address_description.cold.3+0x9/0x1fb
? destroy_hist_field+0x30/0x70
? destroy_hist_field+0x30/0x70
kasan_report.cold.4+0x1a/0x33
? __kasan_slab_free+0x100/0x150
? destroy_hist_field+0x30/0x70
destroy_hist_field+0x30/0x70
track_data_destroy+0x55/0xe0
destroy_hist_data+0x1f0/0x350
hist_unreg_all+0x203/0x220
event_trigger_open+0xbb/0x130
do_dentry_open+0x296/0x700
? stacktrace_count_trigger+0x30/0x30
? generic_permission+0x56/0x200
? __x64_sys_fchdir+0xd0/0xd0
? inode_permission+0x55/0x200
? security_inode_permission+0x18/0x60
path_openat+0x633/0x22b0
? path_lookupat.isra.50+0x420/0x420
? __kasan_kmalloc.constprop.12+0xc1/0xd0
? kmem_cache_alloc+0xe5/0x260
? getname_flags+0x6c/0x2a0
? do_sys_open+0x149/0x2b0
? do_syscall_64+0x73/0x1b0
? entry_SYSCALL_64_after_hwframe+0x44/0xa9
? _raw_write_lock_bh+0xe0/0xe0
? __kernel_text_address+0xe/0x30
? unwind_get_return_address+0x2f/0x50
? __list_add_valid+0x2d/0x70
? deactivate_slab.isra.62+0x1f4/0x5a0
? getname_flags+0x6c/0x2a0
? set_track+0x76/0x120
do_filp_open+0x11a/0x1a0
? may_open_dev+0x50/0x50
? _raw_spin_lock+0x7a/0xd0
? _raw_write_lock_bh+0xe0/0xe0
? __alloc_fd+0x10f/0x200
do_sys_open+0x1db/0x2b0
? filp_open+0x50/0x50
do_syscall_64+0x73/0x1b0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fa7b24a4ca2
Code: 25 00 00 41 00 3d 00 00 41 00 74 4c 48 8d 05 85 7a 0d 00 8b 00 85 c0
75 6d 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff
0f 87 a2 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
RSP: 002b:7fffbafb3af0 EFLAGS: 0246 ORIG_RAX: 0101
RAX: ffda RBX: 55d3648ade30 RCX: 7fa7b24a4ca2
RDX: 0241 RSI: 55d364a55240 RDI: ff9c
RBP: 7fffbafb3bf0 R08: 0020 R09: 0002
R10: 01b6 R11: 0246 R12:
R13: 0003 R14: 0001 R15: 55d364a55240
==
So remove the track_data_destroy() destroy_hist_field() call for that
var_ref.
Link:
http://lkml.kernel.org/r/1deffec420f6a16d11dd8647318d34a66d1989a9.ca...@linux.intel.com
Fixes: 466f4528fbc69 ("tracing: Generalize hist trigger onmax and save action")
Reported-by: Steven Rostedt (VMware)
Signed-off-by: Tom Zanussi
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_events_hist.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index ca46339f3009..795aa2038377 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -3713,7 +3713,6 @@ static void track_data_destroy(struct hist_trigger_data
*hist_data,
struct trace_event_file *file = hist_data->event_file;
destroy_hist_field(data->track_data.track_var, 0);
- destroy_hist_field(data->track_data.var_ref, 0);
if (data->action == ACTION_SNAPSHOT) {
struct track_data *track_data;
--
2.20.1
[PATCH 3/3] ftrace: Fix warning using plain integer as NULL & spelling corrections
From: Hariprasad Kelam
Changed 0 --> NULL to avoid sparse warning
Corrected spelling mistakes reported by checkpatch.pl
Sparse warning below:
sudo make C=2 CF=-D__CHECK_ENDIAN__ M=kernel/trace
CHECK kernel/trace/ftrace.c
kernel/trace/ftrace.c:3007:24: warning: Using plain integer as NULL pointer
kernel/trace/ftrace.c:4758:37: warning: Using plain integer as NULL pointer
Link: http://lkml.kernel.org/r/20190323183523.GA2244@hari-Inspiron-1545
Signed-off-by: Hariprasad Kelam
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/ftrace.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index fa79323331b2..26c8ca9bd06b 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -1992,7 +1992,7 @@ static void print_bug_type(void)
* modifying the code. @failed should be one of either:
* EFAULT - if the problem happens on reading the @ip address
* EINVAL - if what is read at @ip is not what was expected
- * EPERM - if the problem happens on writting to the @ip address
+ * EPERM - if the problem happens on writing to the @ip address
*/
void ftrace_bug(int failed, struct dyn_ftrace *rec)
{
@@ -2391,7 +2391,7 @@ __ftrace_replace_code(struct dyn_ftrace *rec, int enable)
return ftrace_modify_call(rec, ftrace_old_addr, ftrace_addr);
}
- return -1; /* unknow ftrace bug */
+ return -1; /* unknown ftrace bug */
}
void __weak ftrace_replace_code(int mod_flags)
@@ -3004,7 +3004,7 @@ ftrace_allocate_pages(unsigned long num_to_init)
int cnt;
if (!num_to_init)
- return 0;
+ return NULL;
start_pg = pg = kzalloc(sizeof(*pg), GFP_KERNEL);
if (!pg)
@@ -4755,7 +4755,7 @@ static int
ftrace_set_addr(struct ftrace_ops *ops, unsigned long ip, int remove,
int reset, int enable)
{
- return ftrace_set_hash(ops, 0, 0, ip, remove, reset, enable);
+ return ftrace_set_hash(ops, NULL, 0, ip, remove, reset, enable);
}
/**
@@ -5463,7 +5463,7 @@ void ftrace_create_filter_files(struct ftrace_ops *ops,
/*
* The name "destroy_filter_files" is really a misnomer. Although
- * in the future, it may actualy delete the files, but this is
+ * in the future, it may actually delete the files, but this is
* really intended to make sure the ops passed in are disabled
* and that when this function returns, the caller is free to
* free the ops.
@@ -5786,7 +5786,7 @@ void ftrace_module_enable(struct module *mod)
/*
* If the tracing is enabled, go ahead and enable the record.
*
-* The reason not to enable the record immediatelly is the
+* The reason not to enable the record immediately is the
* inherent check of ftrace_make_nop/ftrace_make_call for
* correct previous instructions. Making first the NOP
* conversion puts the module to the correct state, thus
--
2.20.1
[PATCH v2 3/6] device property: Add a function to obtain a node's prefix
The prefix is used for printing purpose before a node, and it also works
as a separator between two nodes.
Signed-off-by: Sakari Ailus
---
drivers/acpi/property.c | 22 ++
drivers/base/property.c | 12
drivers/of/property.c| 10 ++
include/linux/fwnode.h | 2 ++
include/linux/property.h | 1 +
5 files changed, 47 insertions(+)
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 8c9a4c02cde2..c167fd748f86 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -1314,6 +1314,27 @@ static const char *acpi_fwnode_get_name(const struct
fwnode_handle *fwnode)
return adev ? acpi_device_bid(adev) : NULL;
}
+static const char *
+acpi_fwnode_get_name_prefix(const struct fwnode_handle *fwnode)
+{
+ struct fwnode_handle *parent;
+
+ parent = fwnode_get_parent(fwnode);
+ /* Root node. */
+ if (!parent)
+ return "";
+
+ parent = fwnode_get_next_parent(parent);
+ /* Second node from the root; no prefix here either. */
+ if (!parent)
+ return "";
+
+ fwnode_handle_put(parent);
+
+ /* ACPI device or data node. */
+ return ".";
+}
+
static struct fwnode_handle *
acpi_fwnode_get_parent(struct fwnode_handle *fwnode)
{
@@ -1355,6 +1376,7 @@ acpi_fwnode_device_get_match_data(const struct
fwnode_handle *fwnode,
.get_next_child_node = acpi_get_next_subnode, \
.get_named_child_node = acpi_fwnode_get_named_child_node, \
.get_name = acpi_fwnode_get_name, \
+ .get_name_prefix = acpi_fwnode_get_name_prefix, \
.get_reference_args = acpi_fwnode_get_reference_args, \
.graph_get_next_endpoint = \
acpi_graph_get_next_endpoint, \
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 04a8591cd1b0..2e5b826a2376 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -544,6 +544,18 @@ const char *fwnode_get_name(const struct fwnode_handle
*fwnode)
}
/**
+ * fwnode_get_name_prefix - Return the prefix of node for printing purposes
+ * @fwnode: The firmware node
+ *
+ * Returns the prefix of a node, intended to be printed right before the node.
+ * The prefix works also as a separator between the nodes.
+ */
+const char *fwnode_get_name_prefix(const struct fwnode_handle *fwnode)
+{
+ return fwnode_call_ptr_op(fwnode, get_name_prefix);
+}
+
+/**
* fwnode_get_parent - Return parent firwmare node
* @fwnode: Firmware whose parent is retrieved
*
diff --git a/drivers/of/property.c b/drivers/of/property.c
index f0a7b78f2d9f..8fed3b142b41 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -877,6 +877,15 @@ static const char *of_fwnode_get_name(const struct
fwnode_handle *fwnode)
return kbasename(to_of_node(fwnode)->full_name);
}
+static const char *of_fwnode_get_name_prefix(const struct fwnode_handle
*fwnode)
+{
+ /* Root needs no prefix here (its name is "/"). */
+ if (!to_of_node(fwnode)->parent)
+ return "";
+
+ return "/";
+}
+
static struct fwnode_handle *
of_fwnode_get_parent(const struct fwnode_handle *fwnode)
{
@@ -999,6 +1008,7 @@ const struct fwnode_operations of_fwnode_ops = {
.property_read_int_array = of_fwnode_property_read_int_array,
.property_read_string_array = of_fwnode_property_read_string_array,
.get_name = of_fwnode_get_name,
+ .get_name_prefix = of_fwnode_get_name_prefix,
.get_parent = of_fwnode_get_parent,
.get_next_child_node = of_fwnode_get_next_child_node,
.get_named_child_node = of_fwnode_get_named_child_node,
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 85b7fa4dc727..592ac6936e14 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -60,6 +60,7 @@ struct fwnode_reference_args {
* @property_read_string_array: Read an array of string properties. Return zero
* on success, a negative error code otherwise.
* @get_name: Return the name of an fwnode.
+ * @get_name_prefix: Get a prefix for a node (for printing purposes).
* @get_parent: Return the parent of an fwnode.
* @get_next_child_node: Return the next child node in an iteration.
* @get_named_child_node: Return a child node with a given name.
@@ -87,6 +88,7 @@ struct fwnode_operations {
const char *propname, const char **val,
size_t nval);
const char *(*get_name)(const struct fwnode_handle *fwnode);
+ const char *(*get_name_prefix)(const struct fwnode_handle *fwnode);
struct fwnode_handle *(*get_parent)(const struct fwnode_handle *fwnode);
struct fwnode_handle *
(*get_next_child_node)(const struct fwnode_handle *fwnode,
diff --git
[PATCH v2 5/6] lib/vsprintf: Make use of fwnode API to obtain node names and separators
Instead of implementing our own means of discovering parent nodes, node
names or counting how many parents a node has, use the newly added
functions in the fwnode API to obtain that information.
Signed-off-by: Sakari Ailus
---
lib/vsprintf.c | 37 +++--
1 file changed, 15 insertions(+), 22 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 5f60b8d41277..91f2a3e4892e 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_BLOCK
#include
#endif
@@ -1720,32 +1721,23 @@ char *flags_string(char *buf, char *end, void
*flags_ptr, const char *fmt)
return format_flags(buf, end, flags, names);
}
-static const char *device_node_name_for_depth(const struct device_node *np,
int depth)
-{
- for ( ; np && depth; depth--)
- np = np->parent;
-
- return kbasename(np->full_name);
-}
-
static noinline_for_stack
-char *device_node_gen_full_name(const struct device_node *np, char *buf, char
*end)
+char *fwnode_gen_full_name(struct fwnode_handle *fwnode, char *buf, char *end)
{
int depth;
- const struct device_node *parent = np->parent;
- /* special case for root node */
- if (!parent)
- return string(buf, end, "/", default_str_spec);
+ for (depth = fwnode_count_parents(fwnode); depth >= 0; depth--) {
+ struct fwnode_handle *__fwnode =
+ fwnode_get_nth_parent(fwnode, depth);
- for (depth = 0; parent->parent; depth++)
- parent = parent->parent;
-
- for ( ; depth >= 0; depth--) {
- buf = string(buf, end, "/", default_str_spec);
- buf = string(buf, end, device_node_name_for_depth(np, depth),
+ buf = string(buf, end, fwnode_get_name_prefix(__fwnode),
+default_str_spec);
+ buf = string(buf, end, fwnode_get_name(__fwnode),
default_str_spec);
+
+ fwnode_handle_put(__fwnode);
}
+
return buf;
}
@@ -1790,10 +1782,11 @@ char *device_node_string(char *buf, char *end, struct
device_node *dn,
switch (*fmt) {
case 'f': /* full_name */
- buf = device_node_gen_full_name(dn, buf, end);
+ buf = fwnode_gen_full_name(of_fwnode_handle(dn), buf,
+ end);
break;
case 'n': /* name */
- p = kbasename(of_node_full_name(dn));
+ p = fwnode_get_name(of_fwnode_handle(dn));
precision = str_spec.precision;
str_spec.precision = strchrnul(p, '@') - p;
buf = string(buf, end, p, str_spec);
@@ -1803,7 +1796,7 @@ char *device_node_string(char *buf, char *end, struct
device_node *dn,
buf = number(buf, end, (unsigned int)dn->phandle,
num_spec);
break;
case 'P': /* path-spec */
- p = kbasename(of_node_full_name(dn));
+ p = fwnode_get_name(of_fwnode_handle(dn));
if (!p[1])
p = "/";
buf = string(buf, end, p, str_spec);
--
2.11.0
[PATCH v2 4/6] lib/vsprintf: Remove support for %pF and %pf in favour of %pS and %ps
%pS and %ps are now the preferred conversion specifiers to print function
%names. The functionality is equivalent; remove the old, deprecated %pF
%and %pf support.
Depends-on: ("treewide: Switch printk users from %pf and %pF to %ps and
%pS, respectively")
Signed-off-by: Sakari Ailus
---
Documentation/core-api/printk-formats.rst | 10 --
lib/vsprintf.c| 8 ++--
scripts/checkpatch.pl | 1 -
3 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentation/core-api/printk-formats.rst
index c37ec7cd9c06..c90826a1ff17 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -78,8 +78,6 @@ Symbols/Function Pointers
%pS versatile_init+0x0/0x110
%ps versatile_init
- %pF versatile_init+0x0/0x110
- %pf versatile_init
%pSRversatile_init+0x9/0x110
(with __builtin_extract_return_addr() translation)
%pB prev_fn_of_versatile_init+0x88/0x88
@@ -89,14 +87,6 @@ The ``S`` and ``s`` specifiers are used for printing a
pointer in symbolic
format. They result in the symbol name with (S) or without (s)
offsets. If KALLSYMS are disabled then the symbol address is printed instead.
-Note, that the ``F`` and ``f`` specifiers are identical to ``S`` (``s``)
-and thus deprecated. We have ``F`` and ``f`` because on ia64, ppc64 and
-parisc64 function pointers are indirect and, in fact, are function
-descriptors, which require additional dereferencing before we can lookup
-the symbol. As of now, ``S`` and ``s`` perform dereferencing on those
-platforms (when needed), so ``F`` and ``f`` exist for compatibility
-reasons only.
-
The ``B`` specifier results in the symbol name with offsets and should be
used when printing stack backtraces. The specifier takes into
consideration the effect of compiler optimisations which may occur
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 791b6fa36905..5f60b8d41277 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -797,7 +797,7 @@ char *symbol_string(char *buf, char *end, void *ptr,
#ifdef CONFIG_KALLSYMS
if (*fmt == 'B')
sprint_backtrace(sym, value);
- else if (*fmt != 'f' && *fmt != 's')
+ else if (*fmt != 's')
sprint_symbol(sym, value);
else
sprint_symbol_no_offset(sym, value);
@@ -1853,9 +1853,7 @@ char *device_node_string(char *buf, char *end, struct
device_node *dn,
*
* - 'S' For symbolic direct pointers (or function descriptors) with offset
* - 's' For symbolic direct pointers (or function descriptors) without offset
- * - 'F' Same as 'S'
- * - 'f' Same as 's'
- * - '[FfSs]R' as above with __builtin_extract_return_addr() translation
+ * - '[Ss]R' as above with __builtin_extract_return_addr() translation
* - 'B' For backtraced symbolic direct pointers with offset
* - 'R' For decoded struct resource, e.g., [mem 0x0-0x1f 64bit pref]
* - 'r' For raw struct resource, e.g., [mem 0x0-0x1f flags 0x201]
@@ -1970,8 +1968,6 @@ char *pointer(const char *fmt, char *buf, char *end, void
*ptr,
}
switch (*fmt) {
- case 'F':
- case 'f':
case 'S':
case 's':
ptr = dereference_symbol_descriptor(ptr);
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 5b756278df13..b2e80259fb8c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5994,7 +5994,6 @@ sub process {
my $ext_type = "Invalid";
my $use = "";
if ($bad_specifier =~ /p[Ff]/) {
- $ext_type = "Deprecated";
$use = " - use %pS instead";
$use =~ s/pS/ps/ if
($bad_specifier =~ /pf/);
}
--
2.11.0
[PATCH v2 1/6] device property: Add functions for accessing node's parents
Add two convenience functions for accessing node's parents:
fwnode_count_parents() returns the number of parent nodes a given node
has. fwnode_get_nth_parent() returns node's parent at a given distance
from the node itself.
Also reorder fwnode_get_parent() in property.c according to the same order
as in property.h.
Signed-off-by: Sakari Ailus
---
drivers/base/property.c | 59 ++--
include/linux/property.h | 3 +++
2 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 8b91ab380d14..61eb6ceacc3f 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -533,6 +533,19 @@ int device_add_properties(struct device *dev,
EXPORT_SYMBOL_GPL(device_add_properties);
/**
+ * fwnode_get_parent - Return parent firwmare node
+ * @fwnode: Firmware whose parent is retrieved
+ *
+ * Return parent firmware node of the given node if possible or %NULL if no
+ * parent was available.
+ */
+struct fwnode_handle *fwnode_get_parent(const struct fwnode_handle *fwnode)
+{
+ return fwnode_call_ptr_op(fwnode, get_parent);
+}
+EXPORT_SYMBOL_GPL(fwnode_get_parent);
+
+/**
* fwnode_get_next_parent - Iterate to the node's parent
* @fwnode: Firmware whose parent is retrieved
*
@@ -554,17 +567,49 @@ struct fwnode_handle *fwnode_get_next_parent(struct
fwnode_handle *fwnode)
EXPORT_SYMBOL_GPL(fwnode_get_next_parent);
/**
- * fwnode_get_parent - Return parent firwmare node
- * @fwnode: Firmware whose parent is retrieved
+ * fwnode_count_parents - Return the number of parents a node has
+ * @fwnode: The node the parents of which are to be counted
*
- * Return parent firmware node of the given node if possible or %NULL if no
- * parent was available.
+ * Returns the number of parents a node has.
*/
-struct fwnode_handle *fwnode_get_parent(const struct fwnode_handle *fwnode)
+unsigned int fwnode_count_parents(struct fwnode_handle *fwnode)
{
- return fwnode_call_ptr_op(fwnode, get_parent);
+ unsigned int count;
+
+ fwnode_handle_get(fwnode);
+
+ for (count = 0; fwnode; count++)
+ fwnode = fwnode_get_next_parent(fwnode);
+
+ return count - 1;
}
-EXPORT_SYMBOL_GPL(fwnode_get_parent);
+EXPORT_SYMBOL_GPL(fwnode_count_parents);
+
+/**
+ * fwnode_get_nth_parent - Return an nth parent of a node
+ * @fwnode: The node the parent of which is requested
+ * @depth: Distance of the parent from the node
+ *
+ * Returns the nth parent of a node. If @depth is 0, the functionality is
+ * equivalent to fwnode_handle_get(). For @depth == 1, it is
fwnode_get_parent()
+ * and so on.
+ *
+ * The caller is responsible for calling fwnode_handle_put() for the returned
+ * node.
+ */
+struct fwnode_handle *fwnode_get_nth_parent(struct fwnode_handle *fwnode,
+ unsigned int depth)
+{
+ unsigned int i;
+
+ fwnode_handle_get(fwnode);
+
+ for (i = 0; i < depth && fwnode; i++)
+ fwnode = fwnode_get_next_parent(fwnode);
+
+ return fwnode;
+}
+EXPORT_SYMBOL_GPL(fwnode_get_nth_parent);
/**
* fwnode_get_next_child_node - Return the next child node handle for a node
diff --git a/include/linux/property.h b/include/linux/property.h
index 65d3420dd5d1..1164ac974ee8 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -81,6 +81,9 @@ int fwnode_property_get_reference_args(const struct
fwnode_handle *fwnode,
struct fwnode_handle *fwnode_get_parent(const struct fwnode_handle *fwnode);
struct fwnode_handle *fwnode_get_next_parent(
struct fwnode_handle *fwnode);
+unsigned int fwnode_count_parents(struct fwnode_handle *fwn);
+struct fwnode_handle *fwnode_get_nth_parent(struct fwnode_handle *fwn,
+ unsigned int depth);
struct fwnode_handle *fwnode_get_next_child_node(
const struct fwnode_handle *fwnode, struct fwnode_handle *child);
struct fwnode_handle *fwnode_get_next_available_child_node(
--
2.11.0
[PATCH v2 6/6] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
Add support for %pfw conversion specifier (with "f" and "P" modifiers) to
support printing full path of the node, including its name ("f") and only
the node's name ("P") in the printk family of functions. The two flags
have equivalent functionality to existing %pOF with the same two modifiers
("f" and "P") on OF based systems. The ability to do the same on ACPI
based systems is added by this patch.
On ACPI based systems the resulting strings look like
\_SB.PCI0.CIO2.port@1.endpoint@0
where the nodes are separated by a dot (".") and the first three are
ACPI device nodes and the latter two ACPI data nodes.
Signed-off-by: Sakari Ailus
---
Documentation/core-api/printk-formats.rst | 24 +
lib/vsprintf.c| 56 +++
scripts/checkpatch.pl | 3 +-
3 files changed, 82 insertions(+), 1 deletion(-)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentation/core-api/printk-formats.rst
index c90826a1ff17..209625e0c61d 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -410,6 +410,30 @@ Examples::
Passed by reference.
+Fwnode handles
+--
+
+::
+
+ %pfw[fP]
+
+For printing information on fwnode handles. The default is to print the full
+node name, including the path. The modifiers are functionally equivalent to
+%pOF above.
+
+ - f - full name of the node, including the path
+ - P - the name of the node including an address (if there is one)
+
+Examples (ACPI):
+
+ %pfwf \_SB.PCI0.CIO2.port@1.endpoint@0- Full node name
+ %pfwP endpoint@0 - Node name
+
+Examples (OF):
+
+ %pfwf /ocp@6800/i2c@48072000/camera@10/port/endpoint - Full name
+ %pfwP endpoint- Node name
+
Time and date (struct rtc_time)
---
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 91f2a3e4892e..43df0472d001 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1834,6 +1834,48 @@ char *device_node_string(char *buf, char *end, struct
device_node *dn,
return widen_string(buf, buf - buf_start, end, spec);
}
+static noinline_for_stack
+char *fwnode_string(char *buf, char *end, struct fwnode_handle *fwnode,
+ struct printf_spec spec, const char *fmt)
+{
+ const char * const modifiers = "fP";
+ struct printf_spec str_spec = spec;
+ char *buf_start = buf;
+ bool pass;
+
+ str_spec.field_width = -1;
+
+ if ((unsigned long)fwnode < PAGE_SIZE)
+ return string(buf, end, "(null)", spec);
+
+ /* simple case without anything any more format specifiers */
+ fmt++;
+ if (fmt[0] == '\0' || strcspn(fmt, modifiers) > 0)
+ fmt = "f";
+
+ for (pass = false; strspn(fmt, modifiers); fmt++, pass = true) {
+ if (pass) {
+ if (buf < end)
+ *buf = ':';
+ buf++;
+ }
+
+ switch (*fmt) {
+ case 'f': /* full_name */
+ buf = fwnode_gen_full_name(fwnode, buf, end);
+ break;
+ case 'P': /* name */
+ buf = string(buf, end, fwnode_get_name(fwnode),
+str_spec);
+ break;
+ default:
+ break;
+ }
+ }
+
+ return widen_string(buf, buf - buf_start, end, spec);
+}
+
/*
* Show a '%p' thing. A kernel extension is that the '%p' is followed
* by an extra set of alphanumeric characters that are extended format
@@ -1936,6 +1978,10 @@ char *device_node_string(char *buf, char *end, struct
device_node *dn,
* F device node flags
* c major compatible string
* C full compatible string
+ * - 'fw[fP]' For a firmware node (struct fwnode_handle) pointer
+ * Without an option prints the full name of the node
+ * f full name
+ * P node name, including a possible unit address
* - 'x' For printing the address. Equivalent to "%lx".
*
* ** When making changes please also update:
@@ -2060,6 +2106,16 @@ char *pointer(const char *fmt, char *buf, char *end,
void *ptr,
return device_node_string(buf, end, ptr, spec, fmt + 1);
}
break;
+ case 'f':
+ switch (fmt[1]) {
+ case 'w':
+ return fwnode_string(buf, end, ptr, spec, fmt + 1);
+ default:
+ WARN_ONCE(1, "Unsupported pointer conversion %%p%c\n",
+ fmt[1]);
+ return buf;
+ }
+ break;
case 'x':
return pointer_string(buf, end, ptr,
[PATCH v2 2/6] device property: Add fwnode_get_name for returning the name of a node
The fwnode framework did not have means to obtain the name of a node. Add
that now, in form of the fwnode_get_name() function and a corresponding
get_name fwnode op. OF and ACPI support is included.
Signed-off-by: Sakari Ailus
---
drivers/acpi/property.c | 24
drivers/base/property.c | 11 +++
drivers/of/property.c| 6 ++
include/linux/fwnode.h | 2 ++
include/linux/property.h | 1 +
5 files changed, 44 insertions(+)
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 77abe0ec4043..8c9a4c02cde2 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -1291,6 +1291,29 @@ acpi_fwnode_get_reference_args(const struct
fwnode_handle *fwnode,
args_count, args);
}
+static const char *acpi_fwnode_get_name(const struct fwnode_handle *fwnode)
+{
+ const struct acpi_device *adev;
+ struct fwnode_handle *parent;
+
+ parent = fwnode_get_parent(fwnode);
+ /* Is this the root node? */
+ if (!parent)
+ return "\\";
+
+ fwnode_handle_put(parent);
+
+ if (is_acpi_data_node(fwnode)) {
+ const struct acpi_data_node *dn = to_acpi_data_node(fwnode);
+
+ return dn->name;
+ }
+
+ adev = to_acpi_device_node(fwnode);
+
+ return adev ? acpi_device_bid(adev) : NULL;
+}
+
static struct fwnode_handle *
acpi_fwnode_get_parent(struct fwnode_handle *fwnode)
{
@@ -1331,6 +1354,7 @@ acpi_fwnode_device_get_match_data(const struct
fwnode_handle *fwnode,
.get_parent = acpi_node_get_parent, \
.get_next_child_node = acpi_get_next_subnode, \
.get_named_child_node = acpi_fwnode_get_named_child_node, \
+ .get_name = acpi_fwnode_get_name, \
.get_reference_args = acpi_fwnode_get_reference_args, \
.graph_get_next_endpoint = \
acpi_graph_get_next_endpoint, \
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 61eb6ceacc3f..04a8591cd1b0 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -533,6 +533,17 @@ int device_add_properties(struct device *dev,
EXPORT_SYMBOL_GPL(device_add_properties);
/**
+ * fwnode_get_name - Return the name of a node
+ * @fwnode: The firmware node
+ *
+ * Returns a pointer to the node name.
+ */
+const char *fwnode_get_name(const struct fwnode_handle *fwnode)
+{
+ return fwnode_call_ptr_op(fwnode, get_name);
+}
+
+/**
* fwnode_get_parent - Return parent firwmare node
* @fwnode: Firmware whose parent is retrieved
*
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 8631efa1daa1..f0a7b78f2d9f 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -872,6 +872,11 @@ of_fwnode_property_read_string_array(const struct
fwnode_handle *fwnode,
of_property_count_strings(node, propname);
}
+static const char *of_fwnode_get_name(const struct fwnode_handle *fwnode)
+{
+ return kbasename(to_of_node(fwnode)->full_name);
+}
+
static struct fwnode_handle *
of_fwnode_get_parent(const struct fwnode_handle *fwnode)
{
@@ -993,6 +998,7 @@ const struct fwnode_operations of_fwnode_ops = {
.property_present = of_fwnode_property_present,
.property_read_int_array = of_fwnode_property_read_int_array,
.property_read_string_array = of_fwnode_property_read_string_array,
+ .get_name = of_fwnode_get_name,
.get_parent = of_fwnode_get_parent,
.get_next_child_node = of_fwnode_get_next_child_node,
.get_named_child_node = of_fwnode_get_named_child_node,
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index faebf0ca0686..85b7fa4dc727 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -59,6 +59,7 @@ struct fwnode_reference_args {
* otherwise.
* @property_read_string_array: Read an array of string properties. Return zero
* on success, a negative error code otherwise.
+ * @get_name: Return the name of an fwnode.
* @get_parent: Return the parent of an fwnode.
* @get_next_child_node: Return the next child node in an iteration.
* @get_named_child_node: Return a child node with a given name.
@@ -85,6 +86,7 @@ struct fwnode_operations {
(*property_read_string_array)(const struct fwnode_handle *fwnode_handle,
const char *propname, const char **val,
size_t nval);
+ const char *(*get_name)(const struct fwnode_handle *fwnode);
struct fwnode_handle *(*get_parent)(const struct fwnode_handle *fwnode);
struct fwnode_handle *
(*get_next_child_node)(const struct fwnode_handle *fwnode,
diff --git a/include/linux/property.h b/include/linux/property.h
index
Re: [PATCH v19,RESEND 16/27] x86/sgx: Add the Linux SGX Enclave Driver
On Tue, 26 Mar 2019, Huang, Kai wrote: > On Wed, 2019-03-20 at 18:21 +0200, Jarkko Sakkinen wrote: > > 13 files changed, 1657 insertions(+), 2 deletions(-) > > create mode 100644 arch/x86/include/uapi/asm/sgx.h > > create mode 100644 arch/x86/kernel/cpu/sgx/driver/Makefile > > create mode 100644 arch/x86/kernel/cpu/sgx/driver/driver.h > > create mode 100644 arch/x86/kernel/cpu/sgx/driver/ioctl.c > > create mode 100644 arch/x86/kernel/cpu/sgx/driver/main.c > > create mode 100644 arch/x86/kernel/cpu/sgx/encl.c > > create mode 100644 arch/x86/kernel/cpu/sgx/encl.h > > Shouldn't the driver be located somewhere under drivers/, but not under > arch/x86? > > I don't think x86 maintainers should have the burden to review every code > change made to SGX driver? I rather prefer to have it in x86. Why? Because driver code has a tendency to get under the radar. Thanks, tglx
RE: [RFC v2 1/2] vfio/pci: export common symbols in vfio-pci
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, March 26, 2019 2:17 AM
> To: Liu, Yi L
> Subject: Re: [RFC v2 1/2] vfio/pci: export common symbols in vfio-pci
>
> On Sat, 23 Mar 2019 11:06:44 +
> "Liu, Yi L" wrote:
> > Hi Alex,
[...]
> >
> > I tried to get a common file which includes the definitions of the module
> > options and the common interfaces and get it linked separately with each
> > module. It works well when linked separately by config the
> > CONFIG_VFIO_PCI=m and CONFIG_VFIO_PCI_MDEV=m in kernel
> > configuration file. CONFIG_VFIO_PCI_MDEV is a new Kconfig macro
> > for the mdev wrapped version driver. However, if building the vfio-pci
> > and the mdev wrapped version into kernel image (config the
> > CONFIG_VFIO_PCI=y and CONFIG_VFIO_PCI_MDEV=y), then the symbols
> > defined in the common file will be shared thus doesn't allow dissimilar
> > user settings.
> >
> > Per my understanding, I think we expect to allow simultaneous usage of
> > the two drivers. So I think the way above doesn't meet our expectation.
>
> I agree. They should be related in implementation only, from a user
> perspective they should be entirely separate.
>
> > I considered a possible proposal as below. May listen to your opinion
> > on it before heading to cook. Also, better idea is welcomed. :-)
> >
> > - get a common file includes interfaces which are common and have
> > input parameters to differentiate the calling from vfio-pci and the
> > wrapped version. e.g. vfio_pci_rw(). may call it as vfio_pci_common.c.
> >
> > - get another common file includes the definitions of the module options,
> > and the functions which referred the options. Define all of them as
> > static.
> > may call it as common.c
> >
> > - get vfio_pci.c which includes the module_init/exit interfaces and driver
> > registration operations of vfio-pci.ko. This file should include the
> > common.c
> > above to have same module options with the mdev wrapped version.
> >
> > - get vfio_pci_mdev.c which includes the module_init/exit interfaces and
> > driver registration operations of vfio-pci-mdev.ko. It should also include
> > the common.c above to have same module options with vfio-pci.ko.
> >
> > - Makefile:
> > vfio-pci-y := vfio_pci.o vfio_pci_common.o vfio_pci_intrs.o vfio_pci_rdwr.o
> vfio_pci_config.o
> > vfio-pci-$(CONFIG_VFIO_PCI_IGD) += vfio_pci_igd.o
> > vfio-pci-$(CONFIG_VFIO_PCI_NVLINK2) += vfio_pci_nvlink2.o
> >
> > vfio-pci-mdev-y := vfio_pci_mdev.o vfio_pci_common.o vfio_pci_intrs.o
> vfio_pci_rdwr.o vfio_pci_config.o
> > vfio-pci-mdev-$(CONFIG_VFIO_PCI_IGD) += vfio_pci_igd.o
> > vfio-pci-mdev-$(CONFIG_VFIO_PCI_NVLINK2) += vfio_pci_nvlink2.o
> >
> > obj-$(CONFIG_VFIO_PCI) += vfio-pci.o
> > obj-$(CONFIG_VFIO_PCI_MDEV) += vfio-pci-mdev.o
>
> Each module needs it's own module_init/exit and will register its own
> struct pci_driver, which gives us separate control of the probe and
Agreed.
> remove callbacks. I think we want the drivers to have the same module
> parameters initially, but we don't necessarily want to require it for
> any future options, so we can duplicate the parameter declarations.
> Then to support the shared code, I think we can easily push nointxmask,
> disable_vga, and disable_idle_d3 into bools on the struct
> vfio_pci_device, which would be allocated and set by each module's
> probe function before calling the shared probe function.
sounds good to me.
> vfio_fill_ids() could take a pointer to the array to keep them separate
> between modules.
Agreed.
> I think that just leaves the config permission bits,
> vfio_pci_{un}init_perm_bits(). Could we use a simple atomic reference
> counter on those to potentially share them so they get initialized by
> the first caller and freed by the last user, at least in the case of
> both drivers being compiled statically into the kernel? Thanks,
Sure, I can add it. The two modules will still share the cap_perms and
ecap_perms config bits when built statically in kernel. However, I think
such share is reasonable. I'll check if any other similar bits in other files.
> Alex
Thanks for the suggestions, Alex. Let me prepare another RFC.
Regards,
Yi Liu
Re: [External] Re: Print map for total physical and virtual memory
From: Matthew Wilcox Sent: 26 March 2019 17:06 To: Pankaj Suryawanshi Cc: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: [External] Re: Print map for total physical and virtual memory CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, Mar 26, 2019 at 08:34:20AM +, Pankaj Suryawanshi wrote: > Hello, > > 1. Is there any way to print whole physical and virtual memory map in > kernel/user space ? > > 2. Is there any way to print map of cma area reserved memory and movable > pages of cma area. > > 3. Is there any way to know who pinned the pages from cma reserved area ? You probably want tools/vm/page-types.c Can you please elaborate about tools/vm/page-types.c ? * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: [kernfs] e19dfdc83b: BUG:KASAN:global-out-of-bounds_in_s
On Mon, Mar 25, 2019 at 6:06 PM Ondrej Mosnacek wrote: > On Mon, Mar 25, 2019 at 4:17 PM Paul Moore wrote: > > Ondrej, please look into this. > > > > You've looked at this code more recently than I have, but it looks > > like there might be an issue with __kernfs_iattrs() returning a > > pointer to a kernfs_iattrs object without taking a kernfs reference > > (kernfs_get(kn)). Although I would be a little surprised if this was > > the problem as I think it would cause a number of issues beyond just > > this one ... ? > > I think this is actually because of how xattr_full_name() reconstructs > the full name from the xattr suffix. It assumes that the suffix was > obtained from the full name by just taking a pointer inside it, but in > kernfs_security_xattr_get/set() I pass the suffix directly... I'm > surprised that this didn't fail spectacularly earlier during testing. > Maybe the newer GCC does some clever merging of the string constants, > so that XATTR_SELINUX_SUFFIX actually ends up as a substring of > XATTR_NAME_SELINUX? (That would be one hell of a "lucky" coincidence > :) > > I'll post a patch that converts kernfs_security_xattr_get/set() to > take the full name and hopefully that will fix the problem. I'll see > if I can run the reproducer locally tomorrow... I managed to reproduce the KASAN warning in my kernel testing environment by simply enabling CONFIG_KASAN and running the cgroupfs issue reproducer from the original patchset. With the patch I posted I no longer get the warning, so I believe it really fixes the problem. -- Ondrej Mosnacek Software Engineer, Security Technologies Red Hat, Inc.
[PATCH 2/2] devantech-srf04.txt: remove old DT documentation
remove the outdated DT documentation of devantech srf04 iio driver which
is replaced by devantech-srf04.yaml
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/devantech-srf04.txt | 28 --
1 file changed, 28 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
diff --git
a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
deleted file mode 100644
index d4dc7a227e2e..
--- a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Devantech SRF04 ultrasonic range finder
- Bit-banging driver using two GPIOs
-
-Required properties:
- - compatible: Should be "devantech,srf04"
-
- - trig-gpios: Definition of the GPIO for the triggering (output)
- This GPIO is set for about 10 us by the driver to tell the
- device it should initiate the measurement cycle.
-
- - echo-gpios: Definition of the GPIO for the echo (input)
- This GPIO is set by the device as soon as an ultrasonic
- burst is sent out and reset when the first echo is
- received.
- Thus this GPIO is set while the ultrasonic waves are doing
- one round trip.
- It needs to be an GPIO which is able to deliver an
- interrupt because the time between two interrupts is
- measured in the driver.
- See Documentation/devicetree/bindings/gpio/gpio.txt for
- information on how to specify a consumer gpio.
-
-Example:
-srf04@0 {
- compatible = "devantech,srf04";
- trig-gpios = < 15 GPIO_ACTIVE_HIGH>;
- echo-gpios = < 6 GPIO_ACTIVE_HIGH>;
-};
--
2.11.0
[PATCH 1/2] devantech-srf04.yaml: transform DT binding to YAML
use devantech-srf04.txt and transform binding into yaml
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/devantech-srf04.yaml| 62 ++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
diff --git
a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
new file mode 100644
index ..cd065393b062
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/devantech-srf04.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devantech SRF04 ultrasonic range finder
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ Bit-banging driver using two GPIOs:
+ - trigger-gpio is raised by the driver to start sending out an ultrasonic
+burst
+ - echo-gpio is held high by the sensor after sending ultrasonic burst
+until it is received once again
+
+ Specifications about the driver can be found at:
+ http://www.robot-electronics.co.uk/htm/srf04tech.htm
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+items:
+ - const: devantech,srf04
+
+ trig-gpios:
+description:
+ Definition of the GPIO for the triggering (output) This GPIO is set
+ for about 10 us by the driver to tell the device it should initiate
+ the measurement cycle.
+maxItems: 1
+
+ echo-gpios:
+description:
+ Definition of the GPIO for the echo (input)
+ This GPIO is set by the device as soon as an ultrasonic burst is sent
+ out and reset when the first echo is received.
+ Thus this GPIO is set while the ultrasonic waves are doing one round
+ trip.
+ It needs to be an GPIO which is able to deliver an interrupt because
+ the time between two interrupts is measured in the driver.
+ See Documentation/devicetree/bindings/gpio/gpio.txt for information
+ on how to specify a consumer gpio.
+maxItems: 1
+
+required:
+ - compatible
+ - trig-gpios
+ - echo-gpios
+
+examples:
+ - |
+#include
+proximity {
+compatible = "devantech,srf04";
+trig-gpios = < 15 GPIO_ACTIVE_HIGH>;
+echo-gpios = < 6 GPIO_ACTIVE_HIGH>;
+};
--
2.11.0
Re: [PATCH/RFC] driver core: Postpone DMA tear-down until after devres release
Hi John,
CC robh
On Tue, Mar 26, 2019 at 12:42 PM John Garry wrote:
> > Memory is incorrectly freed using the direct ops, as dma_map_ops = NULL.
> > Oops...
> >
> > After reversing the order of the calls to arch_teardown_dma_ops() and
> > devres_release_all(), dma_map_ops is still valid, and the DMA memory is
> > now released using __iommu_free_attrs():
> >
> > +sata_rcar ee30.sata: dmam_release:32: size 2048 vaddr
> > ff8012145000 dma_handle 0x0xf000 attrs 0x0
> > +sata_rcar ee30.sata: dma_free_attrs:289: size 2048, ops =
> > iommu_dma_ops
> > +sata_rcar ee30.sata: dma_free_attrs:311: calling
> > __iommu_free_attrs()
> > ---
> > drivers/base/dd.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > index 8ac10af17c0043a3..d62487d024559620 100644
> > --- a/drivers/base/dd.c
> > +++ b/drivers/base/dd.c
> > @@ -968,9 +968,9 @@ static void __device_release_driver(struct device *dev,
> > struct device *parent)
> > drv->remove(dev);
> >
> > device_links_driver_cleanup(dev);
> > - arch_teardown_dma_ops(dev);
> >
> > devres_release_all(dev);
> > + arch_teardown_dma_ops(dev);
> > dev->driver = NULL;
>
> Hi guys,
>
> Could there still be the same problem in the error path of really_probe():
>
> static int really_probe(struct device *dev, struct device_driver *drv)
> {
>
> [...]
>
> goto done;
>
> probe_failed:
> arch_teardown_dma_ops(dev);
> dma_failed:
> if (dev->bus)
> blocking_notifier_call_chain(>bus->p->bus_notifier,
> BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
> pinctrl_bind_failed:
> device_links_no_driver(dev);
> devres_release_all(dev);
> driver_sysfs_remove(dev);
> dev->driver = NULL;
> dev_set_drvdata(dev, NULL);
>
> We seem to be able to call arch_teardown_dma_ops() prior to
> devres_release_all() if we reach probe_failed label.
Yes, this looks like another instance of the same problem.
And test_remove doesn't expose this, as it doesn't exercise the full cycle.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] timekeeping: Force upper bound for setting CLOCK_REALTIME
On Tue, 26 Mar 2019, Miroslav Lichvar wrote: > On Sat, Mar 23, 2019 at 11:36:19AM +0100, Thomas Gleixner wrote: > > It is reasonable to force an upper bound for the various methods of setting > > CLOCK_REALTIME. Year 2262 is the absolute upper bound. Assume a maximum > > uptime of 30 years which is plenty enough even for esoteric embedded > > systems. That results in an upper bound of year 2232 for setting the time. > > The patch looks good to me. > > I like this approach better than using a larger value closer to the > overflow (e.g. one week) and stepping the clock back automatically > when the clock reaches that time, but I suspect it might possibly > break more tests (or any unusual applications messing with time) as a > much larger interval is now EINVAL. I'm fine with breaking a few tests on the way rather than having undefined behaviour and the constant flow of patches tackling the wrong end of the stick. Thanks, tglx
[PATCH 0/2] transform devantech-srf04.txt into yaml format
use yaml description language to document Devantech SRF04 ultrasonic iio proximity driver Andreas Klinger (2): devantech-srf04.yaml: transform DT binding to YAML devantech-srf04.txt: remove old DT documentation .../bindings/iio/proximity/devantech-srf04.txt | 28 -- .../bindings/iio/proximity/devantech-srf04.yaml| 62 ++ 2 files changed, 62 insertions(+), 28 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt create mode 100644 Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml -- 2.11.0 -- Andreas Klinger Grabenreith 27 84508 Burgkirchen +49 8623 919966 a...@it-klinger.de www.it-klinger.de www.grabenreith.de
Re: [PATCH -next] x86/apic: Reduce print level of CPU limit announcement
On Tue, Mar 26, 2019 at 1:02 PM Leon Romanovsky wrote:
>
> From: Leon Romanovsky
>
> Kernel is booted with less possible CPUs (possible_cpus kernel boot
> option) than available CPUs will have prints like this:
>
> [1.131039] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor
> 55/0x1f ignored.
> [1.132228] ACPI: Unable to map lapic to logical cpu number
>
> Those warnings are printed for every not-enabled CPU and on the systems
> with large number of such CPUs, we see a lot of those prints for default
> print level.
>
> Simple conversion of those prints to be in debug level removes them
> while leaving the option to debug system.
But generally dynamic debug must be enabled in order for pr_debug()
prints to be visible which is kind of cumbersome to do via the command
line.
> Signed-off-by: Leon Romanovsky
> ---
> arch/x86/kernel/acpi/boot.c | 2 +-
> arch/x86/kernel/apic/apic.c | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 8dcbf6890714..3ef8ab89c02d 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -770,7 +770,7 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid,
> u32 acpi_id,
>
> cpu = acpi_register_lapic(physid, acpi_id, ACPI_MADT_ENABLED);
> if (cpu < 0) {
> - pr_info(PREFIX "Unable to map lapic to logical cpu number\n");
> + pr_debug(PREFIX "Unable to map lapic to logical cpu
> number\n");
And this one is printed sometimes when something really goes wrong
which may be really hard to debug otherwise, so there is value in the
info level here.
Would it be possible to avoid printing it just in some cases?
> return cpu;
> }
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index b7bcdd781651..8c2a487b5216 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2305,9 +2305,9 @@ int generic_processor_info(int apicid, int version)
> if (num_processors >= nr_cpu_ids) {
> int thiscpu = max + disabled_cpus;
>
> - pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
> - "reached. Processor %d/0x%x ignored.\n",
> - max, thiscpu, apicid);
> + pr_debug(
> + "APIC: NR_CPUS/possible_cpus limit of %i reached.
> Processor %d/0x%x ignored.\n",
> + max, thiscpu, apicid);
I completely agree with this change, though.
>
> disabled_cpus++;
> return -EINVAL;
> --
Re: [PATCH 22/27] Lock down kprobes
On Mon, 25 Mar 2019 15:09:49 -0700
Matthew Garrett wrote:
> From: David Howells
>
> Disallow the creation of kprobes when the kernel is locked down by
> preventing their registration. This prevents kprobes from being used to
> access kernel memory, either to make modifications or to steal crypto data.
Hmm, if you enforce signature check of modules, those modules
should be allowed to use kprobes?
I think we should introduce some kind of trust inheritance from
signed (trusted) modules.
Thank you,
>
> Reported-by: Alexei Starovoitov
> Signed-off-by: David Howells
> Signed-off-by: Matthew Garrett
> Cc: Naveen N. Rao
> Cc: Anil S Keshavamurthy
> Cc: da...@davemloft.net
> Cc: Masami Hiramatsu
> ---
> kernel/kprobes.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index f4ddfdd2d07e..6f66cca8e2c6 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1552,6 +1552,9 @@ int register_kprobe(struct kprobe *p)
> struct module *probed_mod;
> kprobe_opcode_t *addr;
>
> + if (kernel_is_locked_down("Use of kprobes"))
> + return -EPERM;
> +
> /* Adjust probe address from symbol */
> addr = kprobe_addr(p);
> if (IS_ERR(addr))
> --
> 2.21.0.392.gf8f6787159e-goog
>
--
Masami Hiramatsu
Re: [PATCH v2 0/6] Add nvmem support on STM32
Hi Fabrice On 2/28/19 11:19 AM, Fabrice Gasnier wrote: Non volatile memory area is available on STM32. It contains various factory programmed information such as unique device ID, analog calibration... This patchset adds: - NVMEM support to access stm32 data cells - helper to read 16 bits cells. --- Changes in v2: - update "st,stm32f4-otp" compatible as discussed with Rob - add stm32f429 dts - add core helper to read 16 bits cells Fabrice Gasnier (6): ... ARM: dts: stm32: Add romem and temperature calibration on stm32mp157c ARM: dts: stm32: Add romem and temperature calibration on stm32f429 DT patches applied on stm32-next. Regards Alex
Re: [RFC] mm/hotplug: Make get_nid_for_pfn() work with HAVE_ARCH_PFN_VALID
On Tue 26-03-19 17:33:19, Anshuman Khandual wrote: [...] > I could get it working with the following re-order of memblock_[free|remove] > and > arch_remove_memory(). I did not observe any other adverse side affect because > of > this change. Does it look okay ? Memblock should only work with physical memory ranges without touching struct pages so this should be safe. But you should double check of course. > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1863,11 +1863,11 @@ void __ref __remove_memory(int nid, u64 start, u64 > size) > > /* remove memmap entry */ > firmware_map_remove(start, start + size, "System RAM"); > + arch_remove_memory(nid, start, size, NULL); > + > memblock_free(start, size); > memblock_remove(start, size); > > - arch_remove_memory(nid, start, size, NULL); > - > try_offline_node(nid); > > mem_hotplug_done(); -- Michal Hocko SUSE Labs
Re: [PATCH v2 3/3] rcu: validate arguments for rcu tracepoints
Paul,
Are you OK with this patch? If you ack it, I'll pull it in through my
tree.
-- Steve
On Tue, 26 Mar 2019 20:13:11 +0800
Yafang Shao wrote:
> When CONFIG_RCU_TRACE is not set, all these tracepoints are defined as
> do-nothing macro.
> We'd better make those inline functions that take proper arguments.
>
> As RCU_TRACE() is defined as do-nothing marco as well when
> CONFIG_RCU_TRACE is not set, so we can clean it up.
>
> Signed-off-by: Yafang Shao
> ---
> include/trace/events/rcu.h | 81
> ++
> kernel/rcu/rcu.h | 9 ++
> kernel/rcu/tree.c | 8 ++---
> 3 files changed, 31 insertions(+), 67 deletions(-)
>
> diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
> index f0c4d10..e3f357b 100644
> --- a/include/trace/events/rcu.h
> +++ b/include/trace/events/rcu.h
> @@ -7,6 +7,12 @@
>
> #include
>
> +#ifdef CONFIG_RCU_TRACE
> +#define TRACE_EVENT_RCU TRACE_EVENT
> +#else
> +#define TRACE_EVENT_RCU TRACE_EVENT_NOP
> +#endif
> +
> /*
> * Tracepoint for start/end markers used for utilization calculations.
> * By convention, the string is of the following forms:
> @@ -35,8 +41,6 @@
> TP_printk("%s", __entry->s)
> );
>
> -#ifdef CONFIG_RCU_TRACE
> -
> #if defined(CONFIG_TREE_RCU) || defined(CONFIG_PREEMPT_RCU)
>
> /*
> @@ -62,7 +66,7 @@
> * "end": End a grace period.
> * "cpuend": CPU first notices a grace-period end.
> */
> -TRACE_EVENT(rcu_grace_period,
> +TRACE_EVENT_RCU(rcu_grace_period,
>
> TP_PROTO(const char *rcuname, unsigned long gp_seq, const char
> *gpevent),
>
> @@ -101,7 +105,7 @@
> * "Cleanup": Clean up rcu_node structure after previous GP.
> * "CleanupMore": Clean up, and another GP is needed.
> */
> -TRACE_EVENT(rcu_future_grace_period,
> +TRACE_EVENT_RCU(rcu_future_grace_period,
>
> TP_PROTO(const char *rcuname, unsigned long gp_seq,
>unsigned long gp_seq_req, u8 level, int grplo, int grphi,
> @@ -141,7 +145,7 @@
> * rcu_node structure, and the mask of CPUs that will be waited for.
> * All but the type of RCU are extracted from the rcu_node structure.
> */
> -TRACE_EVENT(rcu_grace_period_init,
> +TRACE_EVENT_RCU(rcu_grace_period_init,
>
> TP_PROTO(const char *rcuname, unsigned long gp_seq, u8 level,
>int grplo, int grphi, unsigned long qsmask),
> @@ -186,7 +190,7 @@
> * "endwake": Woke piggybackers up.
> * "done": Someone else did the expedited grace period for us.
> */
> -TRACE_EVENT(rcu_exp_grace_period,
> +TRACE_EVENT_RCU(rcu_exp_grace_period,
>
> TP_PROTO(const char *rcuname, unsigned long gpseq, const char *gpevent),
>
> @@ -218,7 +222,7 @@
> * "nxtlvl": Advance to next level of rcu_node funnel
> * "wait": Wait for someone else to do expedited GP
> */
> -TRACE_EVENT(rcu_exp_funnel_lock,
> +TRACE_EVENT_RCU(rcu_exp_funnel_lock,
>
> TP_PROTO(const char *rcuname, u8 level, int grplo, int grphi,
>const char *gpevent),
> @@ -269,7 +273,7 @@
> * "WaitQueue": Enqueue partially done, timed wait for it to complete.
> * "WokeQueue": Partial enqueue now complete.
> */
> -TRACE_EVENT(rcu_nocb_wake,
> +TRACE_EVENT_RCU(rcu_nocb_wake,
>
> TP_PROTO(const char *rcuname, int cpu, const char *reason),
>
> @@ -297,7 +301,7 @@
> * include SRCU), the grace-period number that the task is blocking
> * (the current or the next), and the task's PID.
> */
> -TRACE_EVENT(rcu_preempt_task,
> +TRACE_EVENT_RCU(rcu_preempt_task,
>
> TP_PROTO(const char *rcuname, int pid, unsigned long gp_seq),
>
> @@ -324,7 +328,7 @@
> * read-side critical section exiting that critical section. Track the
> * type of RCU (which one day might include SRCU) and the task's PID.
> */
> -TRACE_EVENT(rcu_unlock_preempted_task,
> +TRACE_EVENT_RCU(rcu_unlock_preempted_task,
>
> TP_PROTO(const char *rcuname, unsigned long gp_seq, int pid),
>
> @@ -353,7 +357,7 @@
> * whether there are any blocked tasks blocking the current grace period.
> * All but the type of RCU are extracted from the rcu_node structure.
> */
> -TRACE_EVENT(rcu_quiescent_state_report,
> +TRACE_EVENT_RCU(rcu_quiescent_state_report,
>
> TP_PROTO(const char *rcuname, unsigned long gp_seq,
>unsigned long mask, unsigned long qsmask,
> @@ -396,7 +400,7 @@
> * state, which can be "dti" for dyntick-idle mode or "kick" when kicking
> * a CPU that has been in dyntick-idle mode for too long.
> */
> -TRACE_EVENT(rcu_fqs,
> +TRACE_EVENT_RCU(rcu_fqs,
>
> TP_PROTO(const char *rcuname, unsigned long gp_seq, int cpu, const char
> *qsevent),
>
> @@ -436,7 +440,7 @@
> * events use two separate counters, and that the "++=" and "--=" events
> * for irq/NMI will change the counter by two, otherwise by one.
> */
> -TRACE_EVENT(rcu_dyntick,
> +TRACE_EVENT_RCU(rcu_dyntick,
>
> TP_PROTO(const char *polarity, long oldnesting, long newnesting,
>
Re: [PATCH v2 2/3] sched/fair: do not expose some tracepoints to user if CONFIG_SCHEDSTATS is not set
Peter, Ingo,
Are you OK with this patch? If you ack it, I'll pull it in through my
tree.
-- Steve
On Tue, 26 Mar 2019 20:13:10 +0800
Yafang Shao wrote:
> The tracepoints trace_sched_stat_{iowait, blocked, wait, sleep} should
> be not exposed to user if CONFIG_SCHEDSTATS is not set.
>
> Signed-off-by: Yafang Shao
> ---
> include/trace/events/sched.h | 21 ++---
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
> index 9a4bdfa..c8c7c7e 100644
> --- a/include/trace/events/sched.h
> +++ b/include/trace/events/sched.h
> @@ -241,7 +241,6 @@ static inline long __trace_sched_switch_state(bool
> preempt, struct task_struct *
> DEFINE_EVENT(sched_process_template, sched_process_free,
>TP_PROTO(struct task_struct *p),
>TP_ARGS(p));
> -
>
> /*
> * Tracepoint for a task exiting:
> @@ -336,11 +335,20 @@ static inline long __trace_sched_switch_state(bool
> preempt, struct task_struct *
> __entry->pid, __entry->old_pid)
> );
>
> +
> +#ifdef CONFIG_SCHEDSTATS
> +#define DEFINE_EVENT_SCHEDSTAT DEFINE_EVENT
> +#define DECLARE_EVENT_CLASS_SCHEDSTAT DECLARE_EVENT_CLASS
> +#else
> +#define DEFINE_EVENT_SCHEDSTAT DEFINE_EVENT_NOP
> +#define DECLARE_EVENT_CLASS_SCHEDSTAT DECLARE_EVENT_CLASS_NOP
> +#endif
> +
> /*
> * XXX the below sched_stat tracepoints only apply to SCHED_OTHER/BATCH/IDLE
> * adding sched_stat support to SCHED_FIFO/RR would be welcome.
> */
> -DECLARE_EVENT_CLASS(sched_stat_template,
> +DECLARE_EVENT_CLASS_SCHEDSTAT(sched_stat_template,
>
> TP_PROTO(struct task_struct *tsk, u64 delay),
>
> @@ -363,12 +371,11 @@ static inline long __trace_sched_switch_state(bool
> preempt, struct task_struct *
> (unsigned long long)__entry->delay)
> );
>
> -
> /*
> * Tracepoint for accounting wait time (time the task is runnable
> * but not actually running due to scheduler contention).
> */
> -DEFINE_EVENT(sched_stat_template, sched_stat_wait,
> +DEFINE_EVENT_SCHEDSTAT(sched_stat_template, sched_stat_wait,
>TP_PROTO(struct task_struct *tsk, u64 delay),
>TP_ARGS(tsk, delay));
>
> @@ -376,7 +383,7 @@ static inline long __trace_sched_switch_state(bool
> preempt, struct task_struct *
> * Tracepoint for accounting sleep time (time the task is not runnable,
> * including iowait, see below).
> */
> -DEFINE_EVENT(sched_stat_template, sched_stat_sleep,
> +DEFINE_EVENT_SCHEDSTAT(sched_stat_template, sched_stat_sleep,
>TP_PROTO(struct task_struct *tsk, u64 delay),
>TP_ARGS(tsk, delay));
>
> @@ -384,14 +391,14 @@ static inline long __trace_sched_switch_state(bool
> preempt, struct task_struct *
> * Tracepoint for accounting iowait time (time the task is not runnable
> * due to waiting on IO to complete).
> */
> -DEFINE_EVENT(sched_stat_template, sched_stat_iowait,
> +DEFINE_EVENT_SCHEDSTAT(sched_stat_template, sched_stat_iowait,
>TP_PROTO(struct task_struct *tsk, u64 delay),
>TP_ARGS(tsk, delay));
>
> /*
> * Tracepoint for accounting blocked time (time the task is in
> uninterruptible).
> */
> -DEFINE_EVENT(sched_stat_template, sched_stat_blocked,
> +DEFINE_EVENT_SCHEDSTAT(sched_stat_template, sched_stat_blocked,
>TP_PROTO(struct task_struct *tsk, u64 delay),
>TP_ARGS(tsk, delay));
>
Re: [RFC PATCH 0/10] Another Approach to Use PMEM as NUMA Node
On Mon, 25 Mar 2019 16:37:07 -0700 Dan Williams wrote: > On Mon, Mar 25, 2019 at 4:09 PM Brice Goglin wrote: > > > > > > Le 25/03/2019 à 20:29, Dan Williams a écrit : > > > Perhaps "path" might be a suitable replacement identifier rather than > > > type. I.e. memory that originates from an ACPI.NFIT root device is > > > likely "pmem". > > > > > > Could work. > > > > What kind of "path" would we get for other types of memory? (DDR, > > non-ACPI-based based PMEM if any, NVMe PMR?) > > I think for memory that is described by the HMAT "Reservation hint", > and no other ACPI table, it would need to have "HMAT" in the path. For > anything not ACPI it gets easier because the path can be the parent > PCI device. > There is no HMAT reservation hint in ACPI 6.3 - but there are other ways of doing much the same thing so this is just a nitpick. J
Re: [PATCH v2] PCI: al: Add Amazon Annapurna Labs PCIe host controller driver
[+Zhou, Gustavo]
On Tue, Mar 26, 2019 at 12:00:55PM +0200, Jonathan Chocron wrote:
> Adding support for Amazon's Annapurna Labs PCIe driver.
> The HW controller is based on DesignWare's IP.
>
> The HW doesn't support accessing the Root Port's config space via
> ECAM, so we obtain its base address via an AMZN0001 device.
>
> Furthermore, the DesignWare PCIe controller doesn't filter out
> config transactions sent to devices 1 and up on its bus, so they
> are filtered by the driver.
> All subordinate buses do support ECAM access.
>
> Implementing specific PCI config access functions involves:
> - Adding an init function to obtain the Root Port's base address
>from an AMZN0001 device.
> - Adding a new entry in the mcfg quirk array
>
> Co-developed-by: Vladimir Aerov
> Signed-off-by: Jonathan Chocron
> Signed-off-by: Vladimir Aerov
> Reviewed-by: Benjamin Herrenschmidt
> Reviewed-by: David Woodhouse
Review tags should be given on public mailing lists for public
review and I have not seen them (they were already there in v1) so
you should drop them.
> Changes from v1:
> - Fix commit message comments (incl. using AMZN0001
> instead of PNP0C02)
> - Use the usual multi-line comment style
>
> MAINTAINERS | 6 +++
> drivers/acpi/pci_mcfg.c | 12 +
> drivers/pci/controller/dwc/Makefile | 1 +
> drivers/pci/controller/dwc/pcie-al.c | 93
>
> include/linux/pci-ecam.h | 1 +
> 5 files changed, 113 insertions(+)
> create mode 100644 drivers/pci/controller/dwc/pcie-al.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 32d76a90..7a17017f9f82 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11769,6 +11769,12 @@ T: git
> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git/
> S: Supported
> F: drivers/pci/controller/
>
> +PCIE DRIVER FOR ANNAPURNA LABS
> +M: Jonathan Chocron
> +L: linux-...@vger.kernel.org
> +S: Maintained
> +F: drivers/pci/controller/dwc/pcie-al.c
I do not think we need a maintainer file for that see below, and
actually this quirk should be handled by DWC maintainers since it is a
DWC quirk, not a platform one.
> +
> PCIE DRIVER FOR AMLOGIC MESON
> M: Yue Wang
> L: linux-...@vger.kernel.org
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index a4e8432fc2fb..b42be067fb83 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -52,6 +52,18 @@ struct mcfg_fixup {
> static struct mcfg_fixup mcfg_quirks[] = {
> /* { OEM_ID, OEM_TABLE_ID, REV, SEGMENT, BUS_RANGE, ops, cfgres }, */
>
> +#define AL_ECAM(table_id, rev, seg, ops) \
> + { "AMAZON", table_id, rev, seg, MCFG_BUS_ANY, ops }
> +
> + AL_ECAM("GRAVITON", 0, 0, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 1, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 2, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 3, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 4, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 5, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 6, _pcie_ops),
> + AL_ECAM("GRAVITON", 0, 7, _pcie_ops),
> +
> #define QCOM_ECAM32(seg) \
> { "QCOM ", "QDF2432 ", 1, seg, MCFG_BUS_ANY, _32b_ops }
>
> diff --git a/drivers/pci/controller/dwc/Makefile
> b/drivers/pci/controller/dwc/Makefile
> index 7bcdcdf5024e..1ea773c0070d 100644
> --- a/drivers/pci/controller/dwc/Makefile
> +++ b/drivers/pci/controller/dwc/Makefile
> @@ -28,5 +28,6 @@ obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
> # depending on whether ACPI, the DT driver, or both are enabled.
>
> ifdef CONFIG_PCI
> +obj-$(CONFIG_ARM64) += pcie-al.o
> obj-$(CONFIG_ARM64) += pcie-hisi.o
> endif
> diff --git a/drivers/pci/controller/dwc/pcie-al.c
> b/drivers/pci/controller/dwc/pcie-al.c
> new file mode 100644
> index ..65a9776c12be
> --- /dev/null
> +++ b/drivers/pci/controller/dwc/pcie-al.c
> @@ -0,0 +1,93 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PCIe host controller driver for Amazon's Annapurna Labs IP (used in chips
> + * such as Graviton and Alpine)
> + *
> + * Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights Reserved.
> + *
> + * Author: Jonathan Chocron
> + */
> +
> +#include
> +#include
> +#include
> +#include "../../pci.h"
> +
> +#if defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS)
> +
> +struct al_pcie_acpi {
> + void __iomem *dbi_base;
> +};
> +
> +static void __iomem *al_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
> + int where)
> +{
> + struct pci_config_window *cfg = bus->sysdata;
> + struct al_pcie_acpi *pcie = cfg->priv;
> + void __iomem *dbi_base = pcie->dbi_base;
> +
> + if (bus->number == cfg->busr.start) {
> + /*
> + * The DW PCIe core doesn't filter out transactions to other
> + * devices/functions on the primary bus num, so we do this here.
> + */
> + if (PCI_SLOT(devfn) > 0)
> +
Re: [PATCH v19,RESEND 08/27] x86/cpu/intel: Detect SGX support and update caps appropriately
On Wed, 2019-03-20 at 18:21 +0200, Jarkko Sakkinen wrote:
> From: Sean Christopherson
>
> Similar to other large Intel features such as VMX and TXT, SGX must be
> explicitly enabled in IA32_FEATURE_CONTROL MSR to be truly usable.
> Clear all SGX related capabilities if SGX is not fully enabled in
> IA32_FEATURE_CONTROL or if the SGX1 instruction set isn't supported
> (impossible on bare metal, theoretically possible in a VM if the VMM is
> doing something weird).
>
> Like SGX itself, SGX Launch Control must be explicitly enabled via a
> flag in IA32_FEATURE_CONTROL. Clear the SGX_LC capability if Launch
> Control is not fully enabled (or obviously if SGX itself is disabled).
>
> Note that clearing X86_FEATURE_SGX_LC creates a bit of a conundrum
> regarding the SGXLEPUBKEYHASH MSRs, as it may be desirable to read the
> MSRs even if they are not writable, e.g. to query the configured key,
> but clearing the capability leaves no breadcrum for discerning whether
> or not the MSRs exist. But, such usage will be rare (KVM is the only
> known case at this time) and not performance critical, so it's not
> unreasonable to require the use of rdmsr_safe(). Clearing the cap bit
> eliminates the need for an additional flag to track whether or not
> Launch Control is truly enabled, which is what we care about the vast
> majority of the time.
[Resend. Somehow my last reply doesn't show up in my mailbox so not sure
whether I sent it
successfully or not. Sorry if you receving duplicated mails.]
However this is not consistent with HW behavior. If LC feature flag is not
present, then MSRs should
have hash of Intel's key, which is not always the case here, when you expose
SGX to KVM. Enclave in
KVM guest will get unexpected EINIT error when launing Intel enclave, if on HW
MSRs are configured
to 3rd party value but locked to readonly.
My opition is we already have enough cases that violates HW behavior in SGX
virtualization, let's
not have one more.
Besides, why do we "need an additional flag to track whether or not Launch
Control is truly
enabled"? Doesn't driver only need to know whether MSRs are writable?
Thanks,
-Kai
>
> Signed-off-by: Sean Christopherson
> Co-developed-by: Jarkko Sakkinen
> Signed-off-by: Jarkko Sakkinen
> ---
> arch/x86/kernel/cpu/intel.c | 39 +
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index fc3c07fe7df5..702497f34a96 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -596,6 +596,42 @@ static void detect_tme(struct cpuinfo_x86 *c)
> c->x86_phys_bits -= keyid_bits;
> }
>
> +static void __maybe_unused detect_sgx(struct cpuinfo_x86 *c)
> +{
> + unsigned long long fc;
> +
> + rdmsrl(MSR_IA32_FEATURE_CONTROL, fc);
> + if (!(fc & FEATURE_CONTROL_LOCKED)) {
> + pr_err_once("sgx: The feature control MSR is not locked\n");
> + goto err_unsupported;
> + }
> +
> + if (!(fc & FEATURE_CONTROL_SGX_ENABLE)) {
> + pr_err_once("sgx: SGX is not enabled in IA32_FEATURE_CONTROL
> MSR\n");
> + goto err_unsupported;
> + }
> +
> + if (!cpu_has(c, X86_FEATURE_SGX1)) {
> + pr_err_once("sgx: SGX1 instruction set is not supported\n");
> + goto err_unsupported;
> + }
> +
> + if (!(fc & FEATURE_CONTROL_SGX_LE_WR)) {
> + pr_info_once("sgx: The launch control MSRs are not writable\n");
> + goto err_msrs_rdonly;
> + }
> +
> + return;
> +
> +err_unsupported:
> + setup_clear_cpu_cap(X86_FEATURE_SGX);
> + setup_clear_cpu_cap(X86_FEATURE_SGX1);
> + setup_clear_cpu_cap(X86_FEATURE_SGX2);
> +
> +err_msrs_rdonly:
> + setup_clear_cpu_cap(X86_FEATURE_SGX_LC);
> +}
> +
> static void init_intel_energy_perf(struct cpuinfo_x86 *c)
> {
> u64 epb;
> @@ -763,6 +799,9 @@ static void init_intel(struct cpuinfo_x86 *c)
> if (cpu_has(c, X86_FEATURE_TME))
> detect_tme(c);
>
> + if (IS_ENABLED(CONFIG_INTEL_SGX) && cpu_has(c, X86_FEATURE_SGX))
> + detect_sgx(c);
> +
> init_intel_energy_perf(c);
>
> init_intel_misc_features(c);
[PATCH v2 0/3] tracing: introduce TRACE_EVENT_NOP and use it
In this patchset, I introduce some new macros TRACE_EVENT_NOP,
DEFINE_EVENT_NOP and DECLARE_EVENT_CLASS_NOP, which will
define a tracepoint as do-nothing inline function.
#define DECLARE_EVENT_NOP(name, proto) \
static inline void trace_##name(proto) \
{ } \
static inline bool trace_##name##_enabled(void) \
{ \
return false; \
}
Let's take some examples for why these macros are needed.
- sched
The tracepoints trace_sched_stat_{iowait, blocked, wait, sleep} should
be not exposed to user if CONFIG_SCHEDSTATS is not set.
- rcu
When CONFIG_RCU_TRACE is not set, some rcu tracepoints are defined as
do-nothing macro without validating arguments, that is not proper.
We should validate the arguments.
Yafang Shao (3):
tracing: introduce TRACE_EVENT_NOP()
sched/fair: do not expose some tracepoints to user if
CONFIG_SCHEDSTATS is not set
rcu: validate arguments for rcu tracepoints
include/linux/tracepoint.h | 15
include/trace/define_trace.h | 8 +
include/trace/events/rcu.h | 81 ++--
include/trace/events/sched.h | 21
kernel/rcu/rcu.h | 9 ++---
kernel/rcu/tree.c| 8 ++---
6 files changed, 68 insertions(+), 74 deletions(-)
--
1.8.3.1
[PATCH v2 3/3] rcu: validate arguments for rcu tracepoints
When CONFIG_RCU_TRACE is not set, all these tracepoints are defined as
do-nothing macro.
We'd better make those inline functions that take proper arguments.
As RCU_TRACE() is defined as do-nothing marco as well when
CONFIG_RCU_TRACE is not set, so we can clean it up.
Signed-off-by: Yafang Shao
---
include/trace/events/rcu.h | 81 ++
kernel/rcu/rcu.h | 9 ++
kernel/rcu/tree.c | 8 ++---
3 files changed, 31 insertions(+), 67 deletions(-)
diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index f0c4d10..e3f357b 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -7,6 +7,12 @@
#include
+#ifdef CONFIG_RCU_TRACE
+#define TRACE_EVENT_RCU TRACE_EVENT
+#else
+#define TRACE_EVENT_RCU TRACE_EVENT_NOP
+#endif
+
/*
* Tracepoint for start/end markers used for utilization calculations.
* By convention, the string is of the following forms:
@@ -35,8 +41,6 @@
TP_printk("%s", __entry->s)
);
-#ifdef CONFIG_RCU_TRACE
-
#if defined(CONFIG_TREE_RCU) || defined(CONFIG_PREEMPT_RCU)
/*
@@ -62,7 +66,7 @@
* "end": End a grace period.
* "cpuend": CPU first notices a grace-period end.
*/
-TRACE_EVENT(rcu_grace_period,
+TRACE_EVENT_RCU(rcu_grace_period,
TP_PROTO(const char *rcuname, unsigned long gp_seq, const char
*gpevent),
@@ -101,7 +105,7 @@
* "Cleanup": Clean up rcu_node structure after previous GP.
* "CleanupMore": Clean up, and another GP is needed.
*/
-TRACE_EVENT(rcu_future_grace_period,
+TRACE_EVENT_RCU(rcu_future_grace_period,
TP_PROTO(const char *rcuname, unsigned long gp_seq,
unsigned long gp_seq_req, u8 level, int grplo, int grphi,
@@ -141,7 +145,7 @@
* rcu_node structure, and the mask of CPUs that will be waited for.
* All but the type of RCU are extracted from the rcu_node structure.
*/
-TRACE_EVENT(rcu_grace_period_init,
+TRACE_EVENT_RCU(rcu_grace_period_init,
TP_PROTO(const char *rcuname, unsigned long gp_seq, u8 level,
int grplo, int grphi, unsigned long qsmask),
@@ -186,7 +190,7 @@
* "endwake": Woke piggybackers up.
* "done": Someone else did the expedited grace period for us.
*/
-TRACE_EVENT(rcu_exp_grace_period,
+TRACE_EVENT_RCU(rcu_exp_grace_period,
TP_PROTO(const char *rcuname, unsigned long gpseq, const char *gpevent),
@@ -218,7 +222,7 @@
* "nxtlvl": Advance to next level of rcu_node funnel
* "wait": Wait for someone else to do expedited GP
*/
-TRACE_EVENT(rcu_exp_funnel_lock,
+TRACE_EVENT_RCU(rcu_exp_funnel_lock,
TP_PROTO(const char *rcuname, u8 level, int grplo, int grphi,
const char *gpevent),
@@ -269,7 +273,7 @@
* "WaitQueue": Enqueue partially done, timed wait for it to complete.
* "WokeQueue": Partial enqueue now complete.
*/
-TRACE_EVENT(rcu_nocb_wake,
+TRACE_EVENT_RCU(rcu_nocb_wake,
TP_PROTO(const char *rcuname, int cpu, const char *reason),
@@ -297,7 +301,7 @@
* include SRCU), the grace-period number that the task is blocking
* (the current or the next), and the task's PID.
*/
-TRACE_EVENT(rcu_preempt_task,
+TRACE_EVENT_RCU(rcu_preempt_task,
TP_PROTO(const char *rcuname, int pid, unsigned long gp_seq),
@@ -324,7 +328,7 @@
* read-side critical section exiting that critical section. Track the
* type of RCU (which one day might include SRCU) and the task's PID.
*/
-TRACE_EVENT(rcu_unlock_preempted_task,
+TRACE_EVENT_RCU(rcu_unlock_preempted_task,
TP_PROTO(const char *rcuname, unsigned long gp_seq, int pid),
@@ -353,7 +357,7 @@
* whether there are any blocked tasks blocking the current grace period.
* All but the type of RCU are extracted from the rcu_node structure.
*/
-TRACE_EVENT(rcu_quiescent_state_report,
+TRACE_EVENT_RCU(rcu_quiescent_state_report,
TP_PROTO(const char *rcuname, unsigned long gp_seq,
unsigned long mask, unsigned long qsmask,
@@ -396,7 +400,7 @@
* state, which can be "dti" for dyntick-idle mode or "kick" when kicking
* a CPU that has been in dyntick-idle mode for too long.
*/
-TRACE_EVENT(rcu_fqs,
+TRACE_EVENT_RCU(rcu_fqs,
TP_PROTO(const char *rcuname, unsigned long gp_seq, int cpu, const char
*qsevent),
@@ -436,7 +440,7 @@
* events use two separate counters, and that the "++=" and "--=" events
* for irq/NMI will change the counter by two, otherwise by one.
*/
-TRACE_EVENT(rcu_dyntick,
+TRACE_EVENT_RCU(rcu_dyntick,
TP_PROTO(const char *polarity, long oldnesting, long newnesting,
atomic_t dynticks),
@@ -468,7 +472,7 @@
* number of lazy callbacks queued, and the fourth element is the
* total number of callbacks queued.
*/
-TRACE_EVENT(rcu_callback,
+TRACE_EVENT_RCU(rcu_callback,
TP_PROTO(const char *rcuname, struct rcu_head *rhp, long qlen_lazy,
long qlen),
@@ -504,7 +508,7 @@
* the fourth argument is the number of lazy
[PATCH v2 2/3] sched/fair: do not expose some tracepoints to user if CONFIG_SCHEDSTATS is not set
The tracepoints trace_sched_stat_{iowait, blocked, wait, sleep} should
be not exposed to user if CONFIG_SCHEDSTATS is not set.
Signed-off-by: Yafang Shao
---
include/trace/events/sched.h | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 9a4bdfa..c8c7c7e 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -241,7 +241,6 @@ static inline long __trace_sched_switch_state(bool preempt,
struct task_struct *
DEFINE_EVENT(sched_process_template, sched_process_free,
TP_PROTO(struct task_struct *p),
TP_ARGS(p));
-
/*
* Tracepoint for a task exiting:
@@ -336,11 +335,20 @@ static inline long __trace_sched_switch_state(bool
preempt, struct task_struct *
__entry->pid, __entry->old_pid)
);
+
+#ifdef CONFIG_SCHEDSTATS
+#define DEFINE_EVENT_SCHEDSTAT DEFINE_EVENT
+#define DECLARE_EVENT_CLASS_SCHEDSTAT DECLARE_EVENT_CLASS
+#else
+#define DEFINE_EVENT_SCHEDSTAT DEFINE_EVENT_NOP
+#define DECLARE_EVENT_CLASS_SCHEDSTAT DECLARE_EVENT_CLASS_NOP
+#endif
+
/*
* XXX the below sched_stat tracepoints only apply to SCHED_OTHER/BATCH/IDLE
* adding sched_stat support to SCHED_FIFO/RR would be welcome.
*/
-DECLARE_EVENT_CLASS(sched_stat_template,
+DECLARE_EVENT_CLASS_SCHEDSTAT(sched_stat_template,
TP_PROTO(struct task_struct *tsk, u64 delay),
@@ -363,12 +371,11 @@ static inline long __trace_sched_switch_state(bool
preempt, struct task_struct *
(unsigned long long)__entry->delay)
);
-
/*
* Tracepoint for accounting wait time (time the task is runnable
* but not actually running due to scheduler contention).
*/
-DEFINE_EVENT(sched_stat_template, sched_stat_wait,
+DEFINE_EVENT_SCHEDSTAT(sched_stat_template, sched_stat_wait,
TP_PROTO(struct task_struct *tsk, u64 delay),
TP_ARGS(tsk, delay));
@@ -376,7 +383,7 @@ static inline long __trace_sched_switch_state(bool preempt,
struct task_struct *
* Tracepoint for accounting sleep time (time the task is not runnable,
* including iowait, see below).
*/
-DEFINE_EVENT(sched_stat_template, sched_stat_sleep,
+DEFINE_EVENT_SCHEDSTAT(sched_stat_template, sched_stat_sleep,
TP_PROTO(struct task_struct *tsk, u64 delay),
TP_ARGS(tsk, delay));
@@ -384,14 +391,14 @@ static inline long __trace_sched_switch_state(bool
preempt, struct task_struct *
* Tracepoint for accounting iowait time (time the task is not runnable
* due to waiting on IO to complete).
*/
-DEFINE_EVENT(sched_stat_template, sched_stat_iowait,
+DEFINE_EVENT_SCHEDSTAT(sched_stat_template, sched_stat_iowait,
TP_PROTO(struct task_struct *tsk, u64 delay),
TP_ARGS(tsk, delay));
/*
* Tracepoint for accounting blocked time (time the task is in
uninterruptible).
*/
-DEFINE_EVENT(sched_stat_template, sched_stat_blocked,
+DEFINE_EVENT_SCHEDSTAT(sched_stat_template, sched_stat_blocked,
TP_PROTO(struct task_struct *tsk, u64 delay),
TP_ARGS(tsk, delay));
--
1.8.3.1
[PATCH v2 1/3] tracing: introduce TRACE_EVENT_NOP()
Sometimes we want to define a tracepoint as a do-nothing function.
So I introduce TRACE_EVENT_NOP, DECLARE_EVENT_CLASS_NOP and
DEFINE_EVENT_NOP for this kind of usage.
Signed-off-by: Yafang Shao
---
include/linux/tracepoint.h | 15 +++
include/trace/define_trace.h | 8
2 files changed, 23 insertions(+)
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 9c31865..86b019a 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -548,4 +548,19 @@ static inline struct tracepoint
*tracepoint_ptr_deref(tracepoint_ptr_t *p)
#define TRACE_EVENT_PERF_PERM(event, expr...)
+#define DECLARE_EVENT_NOP(name, proto, args) \
+ static inline void trace_##name(proto) \
+ { } \
+ static inline bool trace_##name##_enabled(void) \
+ { \
+ return false; \
+ }
+
+#define TRACE_EVENT_NOP(name, proto, args, struct, assign, print) \
+ DECLARE_EVENT_NOP(name, PARAMS(proto), PARAMS(args))
+
+#define DECLARE_EVENT_CLASS_NOP(name, proto, args, tstruct, assign, print)
+#define DEFINE_EVENT_NOP(template, name, proto, args) \
+ DECLARE_EVENT_NOP(name, PARAMS(proto), PARAMS(args))
+
#endif /* ifdef TRACE_EVENT (see note above) */
diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h
index cb30c55..bd75f97 100644
--- a/include/trace/define_trace.h
+++ b/include/trace/define_trace.h
@@ -46,6 +46,12 @@
assign, print, reg, unreg) \
DEFINE_TRACE_FN(name, reg, unreg)
+#undef TRACE_EVENT_NOP
+#define TRACE_EVENT_NOP(name, proto, args, struct, assign, print)
+
+#undef DEFINE_EVENT_NOP
+#define DEFINE_EVENT_NOP(template, name, proto, args)
+
#undef DEFINE_EVENT
#define DEFINE_EVENT(template, name, proto, args) \
DEFINE_TRACE(name)
@@ -102,6 +108,8 @@
#undef TRACE_EVENT_FN
#undef TRACE_EVENT_FN_COND
#undef TRACE_EVENT_CONDITION
+#undef TRACE_EVENT_NOP
+#undef DEFINE_EVENT_NOP
#undef DECLARE_EVENT_CLASS
#undef DEFINE_EVENT
#undef DEFINE_EVENT_FN
--
1.8.3.1
[PATCH v3] KEYS: trusted: allow trusted.ko to initialize w/o a TPM
Allow trusted.ko to initialize w/o a TPM. This commit adds checks to the
key type callbacks and exported functions to fail when a TPM is not
available.
Cc: James Morris
Reported-by: Dan Williams
Tested-by: Dan Williams
Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...")
Signed-off-by: Jarkko Sakkinen
---
v3:
- remove unnecessary check for chip in init_trusted()
v2:
- Remove checks from the key type callbacks because the key type will
not be registered.
- Cc to James Morris because hopefully we can land this 5.1.0.
security/keys/trusted.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index ecec672d3a77..efdbf17f3915 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -135,6 +135,9 @@ int TSS_authhmac(unsigned char *digest, const unsigned char
*key,
int ret;
va_list argp;
+ if (!chip)
+ return -ENODEV;
+
sdesc = init_sdesc(hashalg);
if (IS_ERR(sdesc)) {
pr_info("trusted_key: can't alloc %s\n", hash_alg);
@@ -196,6 +199,9 @@ int TSS_checkhmac1(unsigned char *buffer,
va_list argp;
int ret;
+ if (!chip)
+ return -ENODEV;
+
bufsize = LOAD32(buffer, TPM_SIZE_OFFSET);
tag = LOAD16(buffer, 0);
ordinal = command;
@@ -363,6 +369,9 @@ int trusted_tpm_send(unsigned char *cmd, size_t buflen)
{
int rc;
+ if (!chip)
+ return -ENODEV;
+
dump_tpm_buf(cmd);
rc = tpm_send(chip, cmd, buflen);
dump_tpm_buf(cmd);
@@ -429,6 +438,9 @@ int oiap(struct tpm_buf *tb, uint32_t *handle, unsigned
char *nonce)
{
int ret;
+ if (!chip)
+ return -ENODEV;
+
INIT_BUF(tb);
store16(tb, TPM_TAG_RQU_COMMAND);
store32(tb, TPM_OIAP_SIZE);
@@ -1245,9 +1257,13 @@ static int __init init_trusted(void)
{
int ret;
+ /* encrypted_keys.ko depends on successful load of this module even if
+* TPM is not used.
+*/
chip = tpm_default_chip();
if (!chip)
- return -ENOENT;
+ return 0;
+
ret = init_digests();
if (ret < 0)
goto err_put;
@@ -1269,10 +1285,12 @@ static int __init init_trusted(void)
static void __exit cleanup_trusted(void)
{
- put_device(>dev);
- kfree(digests);
- trusted_shash_release();
- unregister_key_type(_type_trusted);
+ if (chip) {
+ put_device(>dev);
+ kfree(digests);
+ trusted_shash_release();
+ unregister_key_type(_type_trusted);
+ }
}
late_initcall(init_trusted);
--
2.19.1
Re: Bad file pattern in MAINTAINERS section 'KEYS-TRUSTED'
Hi Jarrko, On Tue, 2019-03-26 at 13:37 +0200, Jarkko Sakkinen wrote: > Mimi, > > Can you fix this and I can ack and send PR through my tree? Making the "trusted.h" include file public was part of David's "KEYS: Support TPM-wrapped key and crypto ops" patch set. I wasn't involved in reviewing or upstreaming this patch set. As I recall, it was upstreamed rather quickly without much review. As it is TPM related, it should have at least been posted on the linux-integrity mailing list. I have no idea if "trusted.h" should have been made public. I'm not sure just "fixing" the MAINTAINERS file is the right solution. I was hoping to look at it later this week. Perhaps you and James could take a look? Mimi
Re: WARNING in ovl_instantiate
syzbot has bisected this bug to:
commit 01b39dcc95680b04c7af5de7f39f577e9c4865e3
Author: Amir Goldstein
Date: Fri May 11 08:15:15 2018 +
ovl: use inode_insert5() to hash a newly created inode
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=176da0cd20
start commit: de6629eb Merge tag 'pci-v5.0-fixes-1' of git://git.kernel...
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=14eda0cd20
console output: https://syzkaller.appspot.com/x/log.txt?x=10eda0cd20
kernel config: https://syzkaller.appspot.com/x/.config?x=edf1c3031097c304
dashboard link: https://syzkaller.appspot.com/bug?extid=9c69c282adc4edd2b540
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12c7a94f40
Reported-by: syzbot+9c69c282adc4edd2b...@syzkaller.appspotmail.com
Fixes: 01b39dcc9568 ("ovl: use inode_insert5() to hash a newly created
inode")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH v2] KEYS: trusted: allow trusted.ko to initialize w/o a TPM
Allow trusted.ko to initialize w/o a TPM. This commit adds checks to the
key type callbacks and exported functions to fail when a TPM is not
available.
Cc: James Morris
Reported-by: Dan Williams
Tested-by: Dan Williams
Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...")
Signed-off-by: Jarkko Sakkinen
---
v2:
- Remove checks from the key type callbacks because the key type will
not be registered.
- Cc to James Morris because hopefully we can land this 5.1.0.
security/keys/trusted.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index ecec672d3a77..67c0e19a2125 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -135,6 +135,9 @@ int TSS_authhmac(unsigned char *digest, const unsigned char
*key,
int ret;
va_list argp;
+ if (!chip)
+ return -ENODEV;
+
sdesc = init_sdesc(hashalg);
if (IS_ERR(sdesc)) {
pr_info("trusted_key: can't alloc %s\n", hash_alg);
@@ -196,6 +199,9 @@ int TSS_checkhmac1(unsigned char *buffer,
va_list argp;
int ret;
+ if (!chip)
+ return -ENODEV;
+
bufsize = LOAD32(buffer, TPM_SIZE_OFFSET);
tag = LOAD16(buffer, 0);
ordinal = command;
@@ -363,6 +369,9 @@ int trusted_tpm_send(unsigned char *cmd, size_t buflen)
{
int rc;
+ if (!chip)
+ return -ENODEV;
+
dump_tpm_buf(cmd);
rc = tpm_send(chip, cmd, buflen);
dump_tpm_buf(cmd);
@@ -429,6 +438,9 @@ int oiap(struct tpm_buf *tb, uint32_t *handle, unsigned
char *nonce)
{
int ret;
+ if (!chip)
+ return -ENODEV;
+
INIT_BUF(tb);
store16(tb, TPM_TAG_RQU_COMMAND);
store32(tb, TPM_OIAP_SIZE);
@@ -1245,9 +1257,13 @@ static int __init init_trusted(void)
{
int ret;
+ /* encrypted_keys.ko depends on successful load of this module even if
+* TPM is not used.
+*/
chip = tpm_default_chip();
if (!chip)
- return -ENOENT;
+ return 0;
+
ret = init_digests();
if (ret < 0)
goto err_put;
@@ -1263,16 +1279,19 @@ static int __init init_trusted(void)
err_free:
kfree(digests);
err_put:
- put_device(>dev);
+ if (chip)
+ put_device(>dev);
return ret;
}
static void __exit cleanup_trusted(void)
{
- put_device(>dev);
- kfree(digests);
- trusted_shash_release();
- unregister_key_type(_type_trusted);
+ if (chip) {
+ put_device(>dev);
+ kfree(digests);
+ trusted_shash_release();
+ unregister_key_type(_type_trusted);
+ }
}
late_initcall(init_trusted);
--
2.19.1
Re: [RFC] mm/hotplug: Make get_nid_for_pfn() work with HAVE_ARCH_PFN_VALID
On 03/22/2019 05:32 PM, Michal Hocko wrote: > On Fri 22-03-19 11:49:30, Anshuman Khandual wrote: >> >> On 03/21/2019 02:06 PM, Michal Hocko wrote: >>> On Thu 21-03-19 13:38:20, Anshuman Khandual wrote: Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs entries between memory block and node. It first checks pfn validity with pfn_valid_within() before fetching nid. With CONFIG_HOLES_IN_ZONE config (arm64 has this enabled) pfn_valid_within() calls pfn_valid(). pfn_valid() is an arch implementation on arm64 (CONFIG_HAVE_ARCH_PFN_VALID) which scans all mapped memblock regions with memblock_is_map_memory(). This creates a problem in memory hot remove path which has already removed given memory range from memory block with memblock_[remove|free] before arriving at unregister_mem_sect_under_nodes(). >>> Could you be more specific on what is the actual problem please? It >>> would be also helpful to mention when is the memblock[remove|free] >>> called actually. >> The problem is in unregister_mem_sect_under_nodes() as it skips calling into >> both >> instances of sysfs_remove_link() which removes node-memory block sysfs >> symlinks. >> The node enumeration of the memory block still remains in sysfs even if the >> memory >> block itself has been removed. >> >> This happens because get_nid_for_pfn() returns -1 for a given pfn even if it >> has >> a valid associated struct page to fetch the node ID from. >> >> On arm64 (with CONFIG_HOLES_IN_ZONE) >> >> get_nid_for_pfn() -> pfn_valid_within() -> pfn_valid -> >> memblock_is_map_memory() >> >> At this point memblock for the range has been removed. >> >> __remove_memory() >> memblock_free() >> memblock_remove() > memblock has already been removed >> arch_remove_memory() >> __remove_pages() >> __remove_section() >> unregister_memory_section() >> remove_memory_section() >> >> unregister_mem_sect_under_nodes() >> >> There is a dependency on memblock (after it has been removed) through >> pfn_valid(). > Can we reorganize or rework the code that the memblock is removed later? > I guess this is what Oscar was suggesting. I could get it working with the following re-order of memblock_[free|remove] and arch_remove_memory(). I did not observe any other adverse side affect because of this change. Does it look okay ? --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1863,11 +1863,11 @@ void __ref __remove_memory(int nid, u64 start, u64 size) /* remove memmap entry */ firmware_map_remove(start, start + size, "System RAM"); + arch_remove_memory(nid, start, size, NULL); + memblock_free(start, size); memblock_remove(start, size); - arch_remove_memory(nid, start, size, NULL); - try_offline_node(nid); mem_hotplug_done();
Re: [PATCH 4.9 00/30] 4.9.166-stable review
stable-rc/linux-4.9.y boot: 98 boots: 0 failed, 86 passed with 12 offline (v4.9.165-31-gb7e63ff5d9f9) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.165-31-gb7e63ff5d9f9/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.165-31-gb7e63ff5d9f9/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.165-31-gb7e63ff5d9f9 Git Commit: b7e63ff5d9f9f1ae13c633d2b98e6b180398ff5f Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 50 unique boards, 22 SoC families, 15 builds out of 197 Offline Platforms: arm: bcm2835_defconfig: gcc-7 bcm2835-rpi-b: 1 offline lab multi_v7_defconfig: gcc-7 alpine-db: 1 offline lab at91-sama5d4_xplained: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab sun5i-r8-chip: 1 offline lab tegra124-jetson-tk1: 1 offline lab tegra_defconfig: gcc-7 tegra124-jetson-tk1: 1 offline lab sunxi_defconfig: gcc-7 sun5i-r8-chip: 1 offline lab sama5_defconfig: gcc-7 at91-sama5d4_xplained: 1 offline lab socfpga_defconfig: gcc-7 socfpga_cyclone5_de0_sockit: 1 offline lab arm64: defconfig: gcc-7 apq8016-sbc: 1 offline lab juno-r2: 1 offline lab --- For more info write to
[PATCH -next] x86/apic: Reduce print level of CPU limit announcement
From: Leon Romanovsky
Kernel is booted with less possible CPUs (possible_cpus kernel boot
option) than available CPUs will have prints like this:
[1.131039] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor
55/0x1f ignored.
[1.132228] ACPI: Unable to map lapic to logical cpu number
Those warnings are printed for every not-enabled CPU and on the systems
with large number of such CPUs, we see a lot of those prints for default
print level.
Simple conversion of those prints to be in debug level removes them
while leaving the option to debug system.
Signed-off-by: Leon Romanovsky
---
arch/x86/kernel/acpi/boot.c | 2 +-
arch/x86/kernel/apic/apic.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 8dcbf6890714..3ef8ab89c02d 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -770,7 +770,7 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid,
u32 acpi_id,
cpu = acpi_register_lapic(physid, acpi_id, ACPI_MADT_ENABLED);
if (cpu < 0) {
- pr_info(PREFIX "Unable to map lapic to logical cpu number\n");
+ pr_debug(PREFIX "Unable to map lapic to logical cpu number\n");
return cpu;
}
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index b7bcdd781651..8c2a487b5216 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2305,9 +2305,9 @@ int generic_processor_info(int apicid, int version)
if (num_processors >= nr_cpu_ids) {
int thiscpu = max + disabled_cpus;
- pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
- "reached. Processor %d/0x%x ignored.\n",
- max, thiscpu, apicid);
+ pr_debug(
+ "APIC: NR_CPUS/possible_cpus limit of %i reached.
Processor %d/0x%x ignored.\n",
+ max, thiscpu, apicid);
disabled_cpus++;
return -EINVAL;
--
2.20.1
Re: [PATCH v19,RESEND 16/27] x86/sgx: Add the Linux SGX Enclave Driver
On Wed, 2019-03-20 at 18:21 +0200, Jarkko Sakkinen wrote: > Intel Software Guard eXtensions (SGX) is a set of CPU instructions that > can be used by applications to set aside private regions of code and > data. The code outside the enclave is disallowed to access the memory > inside the enclave by the CPU access control. > > This commit adds the Linux SGX Enclave Driver that provides an ioctl API > to manage enclaves. The address range for an enclave, commonly referred > as ELRANGE in the documentation (e.g. Intel SDM), is reserved with > mmap() against /dev/sgx. After that a set ioctls is used to build > the enclave to the ELRANGE. > > Signed-off-by: Jarkko Sakkinen > Co-developed-by: Sean Christopherson > Signed-off-by: Sean Christopherson > Co-developed-by: Serge Ayoun > Signed-off-by: Serge Ayoun > Co-developed-by: Shay Katz-zamir > Signed-off-by: Shay Katz-zamir > Co-developed-by: Suresh Siddha > Signed-off-by: Suresh Siddha > --- > Documentation/ioctl/ioctl-number.txt| 1 + > arch/x86/Kconfig| 17 +- > arch/x86/include/uapi/asm/sgx.h | 59 ++ > arch/x86/kernel/cpu/sgx/Makefile| 5 +- > arch/x86/kernel/cpu/sgx/driver/Makefile | 3 + > arch/x86/kernel/cpu/sgx/driver/driver.h | 38 ++ > arch/x86/kernel/cpu/sgx/driver/ioctl.c | 795 > arch/x86/kernel/cpu/sgx/driver/main.c | 290 + > arch/x86/kernel/cpu/sgx/encl.c | 358 +++ > arch/x86/kernel/cpu/sgx/encl.h | 88 +++ > arch/x86/kernel/cpu/sgx/encls.c | 1 + > arch/x86/kernel/cpu/sgx/main.c | 3 + > arch/x86/kernel/cpu/sgx/sgx.h | 1 + > 13 files changed, 1657 insertions(+), 2 deletions(-) > create mode 100644 arch/x86/include/uapi/asm/sgx.h > create mode 100644 arch/x86/kernel/cpu/sgx/driver/Makefile > create mode 100644 arch/x86/kernel/cpu/sgx/driver/driver.h > create mode 100644 arch/x86/kernel/cpu/sgx/driver/ioctl.c > create mode 100644 arch/x86/kernel/cpu/sgx/driver/main.c > create mode 100644 arch/x86/kernel/cpu/sgx/encl.c > create mode 100644 arch/x86/kernel/cpu/sgx/encl.h Shouldn't the driver be located somewhere under drivers/, but not under arch/x86? I don't think x86 maintainers should have the burden to review every code change made to SGX driver? Thanks, -Kai
Re: [PATCH] firmware: arm_scmi: Fix leak in scmi_mailbox_check
On 26/03/2019 07:23, Mukesh Ojha wrote:
>
> On 3/25/2019 11:07 PM, Steven Price wrote:
>> of_parse_phandle_with_args() requires the caller to call of_node_put() on
>> the returned args->np pointer. Otherwise the reference count will remain
>> incremented.
>>
>> However, in this case, since we don't actually use the returned pointer,
>> we can simply pass in NULL.
>>
>> Fixes: aa4f886f3893f ("firmware: arm_scmi: add basic driver
>> infrastructure for SCMI")
>> Signed-off-by: Steven Price
>> ---
>> drivers/firmware/arm_scmi/driver.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/firmware/arm_scmi/driver.c
>> b/drivers/firmware/arm_scmi/driver.c
>> index 8f952f2f1a29..dd967d675c08 100644
>> --- a/drivers/firmware/arm_scmi/driver.c
>> +++ b/drivers/firmware/arm_scmi/driver.c
>> @@ -654,9 +654,7 @@ static int scmi_xfer_info_init(struct scmi_info
>> *sinfo)
>> static int scmi_mailbox_check(struct device_node *np)
>> {
>> - struct of_phandle_args arg;
>> -
>> - return of_parse_phandle_with_args(np, "mboxes", "#mbox-cells", 0,
>> );
>> + return of_parse_phandle_with_args(np, "mboxes", "#mbox-cells", 0,
>> NULL);
>
> Although, it is not used but it is better to put arg->np instead of
> passing NULL.
> Here, you are making the driver not to fill arguement which is
> customised solution, that may change in future.
The function of_parse_phandle_with_args() is documented thus:
> * of_parse_phandle_with_args() - Find a node pointed by phandle in a list
> * @np: pointer to a device tree node containing a list
> * @list_name:property name that contains a list
> * @cells_name: property name that specifies phandles' arguments count
> * @index:index of a phandle to parse out
> * @out_args: optional pointer to output arguments structure (will be filled)
So I'm going by the documentation (and implementation) which both
consider out_args to be optional. The alternative is of course:
> diff --git a/drivers/firmware/arm_scmi/driver.c
> b/drivers/firmware/arm_scmi/driver.c
> index 8f952f2f1a29..aa6c0728e676 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -655,8 +655,11 @@ static int scmi_xfer_info_init(struct scmi_info *sinfo)
> static int scmi_mailbox_check(struct device_node *np)
> {
> struct of_phandle_args arg;
> + int ret;
>
> - return of_parse_phandle_with_args(np, "mboxes", "#mbox-cells", 0, );
> + ret = of_parse_phandle_with_args(np, "mboxes", "#mbox-cells", 0, );
> + of_node_put(arg->np);
> + return ret;
> }
>
> static int scmi_mbox_free_channel(int id, void *p, void *data)
But personally that doesn't seem as good. Is there any reason to think
the interface of of_parse_phandle_with_args() will change?
Steve
Re: [PATCH] clk: asr: clock driver support for ASR AquilaC Soc
On Sat, Mar 23, 2019 at 10:08:35PM +0800, qiaozhou wrote: > From: Qiao Zhou > > add clock driver support for ASR AquilaC SoC. > > We add clk-gate, clk-mix, and clk-pll drivers: > 1. clk-gate driver is for regisers which have different enable/disable bits > to control gating. > 2. clk-mix driver is for registers which request to set div and mux > bits at the same time. > 3. clk-pll driver is for pll configuration. > > Signed-off-by: qiaozhou > --- > drivers/clk/Kconfig | 1 + > drivers/clk/Makefile | 1 + > drivers/clk/asr/Kconfig | 17 ++ > drivers/clk/asr/Makefile | 6 + > drivers/clk/asr/clk-aquilac.c | 595 ++ > drivers/clk/asr/clk-gate.c| 151 ++ > drivers/clk/asr/clk-mix.c | 393 ++ > drivers/clk/asr/clk-pll.c | 642 > ++ > drivers/clk/asr/clk-pll.h | 91 ++ > drivers/clk/asr/clk.c | 222 +++ > drivers/clk/asr/clk.h | 235 > 11 files changed, 2354 insertions(+) > create mode 100644 drivers/clk/asr/Kconfig > create mode 100644 drivers/clk/asr/Makefile > create mode 100644 drivers/clk/asr/clk-aquilac.c > create mode 100644 drivers/clk/asr/clk-gate.c > create mode 100644 drivers/clk/asr/clk-mix.c > create mode 100644 drivers/clk/asr/clk-pll.c > create mode 100644 drivers/clk/asr/clk-pll.h > create mode 100644 drivers/clk/asr/clk.c > create mode 100644 drivers/clk/asr/clk.h > > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig > index e705aab..0ea9f74 100644 > --- a/drivers/clk/Kconfig > +++ b/drivers/clk/Kconfig > @@ -315,5 +315,6 @@ source "drivers/clk/tegra/Kconfig" > source "drivers/clk/ti/Kconfig" > source "drivers/clk/uniphier/Kconfig" > source "drivers/clk/zynqmp/Kconfig" > +source "drivers/clk/asr/Kconfig" > > endmenu > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile > index 1db1336..a88b3b9 100644 > --- a/drivers/clk/Makefile > +++ b/drivers/clk/Makefile > @@ -112,3 +112,4 @@ endif > obj-$(CONFIG_ARCH_ZX)+= zte/ > obj-$(CONFIG_ARCH_ZYNQ) += zynq/ > obj-$(CONFIG_COMMON_CLK_ZYNQMP) += zynqmp/ > +obj-$(CONFIG_COMMON_CLK_ASR) += asr/ > diff --git a/drivers/clk/asr/Kconfig b/drivers/clk/asr/Kconfig > new file mode 100644 > index 000..ded68b5 > --- /dev/null > +++ b/drivers/clk/asr/Kconfig > @@ -0,0 +1,17 @@ > +config COMMON_CLK_ASR > + bool "Support for ASR's clock controllers" > + depends on OF > + depends on ARCH_ASR || COMPILE_TEST > + help > + Build the clock drivers for ASR8751C SoC. It contains clock-gate, > + clock-mix, clock-pll drivers which manages general gating, divider, > + mux, and pll enabling/disabling controls. > + Say Y if you want to support clock controls on ASR8751C SoCs > + > +config ASR_AQUILAC_CLK > + bool "ASR AquilaC clock controller support" > + depends on OF > + depends on ARCH_ASR > + depends on COMMON_CLK_ASR > + help > + Build the clock driver for ASR8751C AquilaC development board. > diff --git a/drivers/clk/asr/Makefile b/drivers/clk/asr/Makefile > new file mode 100644 > index 000..f6b9bd3 > --- /dev/null > +++ b/drivers/clk/asr/Makefile > @@ -0,0 +1,6 @@ > +# > +# Makefile for asr specific clk > +# > + > +obj-$(CONFIG_COMMON_CLK_ASR) += clk-pll.o clk-gate.o clk-mix.o clk.o > +obj-$(CONFIG_ASR_AQUILAC_CLK) += clk-aquilac.o > diff --git a/drivers/clk/asr/clk-aquilac.c b/drivers/clk/asr/clk-aquilac.c > new file mode 100644 > index 000..7274b60 > --- /dev/null > +++ b/drivers/clk/asr/clk-aquilac.c > @@ -0,0 +1,595 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * clock driver file for asr AquilaC > + * > + * Copyright (C) 2019 ASR Microelectronics(Shanghai) Co., Ltd. > + * Gang Wu > + * Qiao Zhou ^ Remove extra spaces. > + * > + * This file is licensed under the terms of the GNU General Public > + * License version 2. This program is licensed "as is" without any > + * warranty of any kind, whether express or implied. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "clk.h" > +#include "clk-pll.h" > + > +/* APBC register offset for asr AquilaC */ > +#define APBC_UART0 0x0 > +#define APBC_UART1 0x4 > +#define APBC_GPIO0x8 > +#define APBC_SSP00x1c > +#define APBC_IPC 0x24 > +#define APBC_RTC 0x28 > +#define APBC_TWSI0 0x2c > +#define APBC_KPC 0x30 > +#define APBC_TIMERS 0x34 > +#define APBC_AIB 0x3c > +#define APBC_SSP20x4c > +#define APBC_TWSI1 0x60 > +#define APBC_THERMAL 0x6c > +#define APBC_UART2 0x78 > +#define APBC_TWSI4
Re: [PATCH v1] phy: qcom-qmp: Add msm8998 PCIe QMP PHY support
On 26/03/2019 08:45, Kishon Vijay Abraham I wrote: > On 22/03/19 9:42 PM, Marc Gonzalez wrote: > >> Copy init sequence from downstream: >> https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/arch/arm/boot/dts/qcom/msm8998-v2.dtsi?h=LE.UM.1.3.r3.25#n372 > > Can't we instead have reference to HW manual or datasheet? I have heard of these legendary beasts, but I have never seen one. >> Signed-off-by: Marc Gonzalez >> --- >> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 5 + >> drivers/phy/qualcomm/phy-qcom-qmp.c | 110 ++ >> drivers/phy/qualcomm/phy-qcom-qmp.h | 12 ++ >> 3 files changed, 127 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt >> b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt >> index 5d181fc3cc18..6000ae34b12b 100644 >> --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt >> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt >> @@ -11,6 +11,7 @@ Required properties: >> "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, >> "qcom,msm8998-qmp-usb3-phy" for USB3 QMP V3 phy on msm8998, >> "qcom,msm8998-qmp-ufs-phy" for UFS QMP phy on msm8998, >> + "qcom,msm8998-qmp-pcie-phy" for PCIe QMP phy on msm8998, >> "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845, >> "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845, >> "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845. >> @@ -48,6 +49,8 @@ Required properties: >> "aux", "cfg_ahb", "ref". >> For "qcom,msm8998-qmp-ufs-phy" must contain: >> "ref", "ref_aux". >> +For "qcom,msm8998-qmp-pcie-phy" must contain: >> +"aux", "cfg_ahb", "ref". >> For "qcom,sdm845-qmp-usb3-phy" must contain: >> "aux", "cfg_ahb", "ref", "com_aux". >> For "qcom,sdm845-qmp-usb3-uni-phy" must contain: >> @@ -70,6 +73,8 @@ Required properties: >> For "qcom,msm8998-qmp-usb3-phy" must contain >> "phy", "common". >> For "qcom,msm8998-qmp-ufs-phy": no resets are listed. >> +For "qcom,msm8998-qmp-pcie-phy" must contain: >> +"phy", "common", "cfg". >> For "qcom,sdm845-qmp-usb3-phy" must contain: >> "phy", "common". >> For "qcom,sdm845-qmp-usb3-uni-phy" must contain: > > Please send the dt binding in a separate patch. Coming right up.
Re: [PATCH] KEYS: trusted: allow trusted.ko to initialize w/o a TPM
On Mon, Mar 25, 2019 at 04:47:35PM +0200, Jarkko Sakkinen wrote:
> Allow trusted.ko to initialize w/o a TPM. This commit adds checks to the
> key type callbacks and exported functions to fail when a TPM is not
> available.
>
> Cc: Dan Williams
> Cc: sta...@vger.kernel.org
> Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...")
> Signed-off-by: Jarkko Sakkinen
Will send a revised version: since now the key type is not registered,
none of the callbacks needs the check for the chip instance. Only the
exported functions should have it.
/Jarkko
Re: [RESEND] i2c: imx: defer probing on dma channel request
Hi Steve,
Thanks for the review! Few comments inline.
On 25.03.2019 19:12, Steven Price wrote:
> On 25/03/2019 15:30, laurentiu.tu...@nxp.com wrote:
>> From: Laurentiu Tudor
>>
>> If the dma controller is not yet probed, defer i2c probe.
>> The error path in probe was slightly modified (no functional change)
>
> There is a functional change for cases like:
>
>> ret = pm_runtime_get_sync(>dev);
>> if (ret < 0)
>> goto rpm_disable;
>
> ...as rpm_disable will no longer fall through to the call of
> clk_disable_unprepare().
Good point, I missed that.
>> to avoid triggering this WARN_ON():
>> "cg-pll0-div1 already disabled
>> WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:828 clk_core_disable+0xa8/0xb0"
>
> I'm also not sure how this WARN_ON was hit. i2c_imx_probe() calls
> clk_prepare_enable() which should increment the reference count. So it
> should always be possible to decrememt the enable_count. What am I missing?
I am no longer able to replicate this. Perhaps in the mean time changes
in the clk core fixed this corner case.
>> Signed-off-by: Laurentiu Tudor
>> ---
>> drivers/i2c/busses/i2c-imx.c | 21 +
>> 1 file changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
>> index 42fed40198a0..4e34b1572756 100644
>> --- a/drivers/i2c/busses/i2c-imx.c
>> +++ b/drivers/i2c/busses/i2c-imx.c
>> @@ -,7 +,8 @@ static int i2c_imx_probe(struct platform_device *pdev)
>> pdev->name, i2c_imx);
>> if (ret) {
>> dev_err(>dev, "can't claim irq %d\n", irq);
>> -goto clk_disable;
>> +clk_disable_unprepare(i2c_imx->clk);
>> +return ret;
>> }
>>
>> /* Init queue */
>> @@ -1161,19 +1162,25 @@ static int i2c_imx_probe(struct platform_device
>> *pdev)
>> pm_runtime_mark_last_busy(>dev);
>> pm_runtime_put_autosuspend(>dev);
>>
>> +/* Init DMA config if supported */
>> +ret = i2c_imx_dma_request(i2c_imx, phy_addr);
>> +if (ret) {
>> +if (ret != -EPROBE_DEFER)
>> +dev_info(>dev, "can't use DMA, using PIO
>> instead.\n");
>> +else
>> +goto del_adapter;
>> +}
>> +
>
> This can be simplified by reversing the condition:
Well, in the mean time I just found out that this commit [1] fixes the
issue I was seeing so I think the patch is no longer needed.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/commit/?h=i2c/for-next=e1ab9a468e3b1
---
Best Regards, Laurentiu
Re: [PATCH] KEYS: trusted: allow trusted.ko to initialize w/o a TPM
On Mon, Mar 25, 2019 at 02:33:38PM -0700, Dan Williams wrote: > On Mon, Mar 25, 2019 at 7:48 AM Jarkko Sakkinen > wrote: > > > > Allow trusted.ko to initialize w/o a TPM. This commit adds checks to the > > key type callbacks and exported functions to fail when a TPM is not > > available. > > > > Cc: Dan Williams > > Reported-and-tested-by: Dan Williams Thanks Dan! /Jarkko
Re: [RFC net-next 1/8] subdev: Introducing subdev bus
On Fri, Mar 01, 2019 at 08:17:27AM +0100, Greg KH wrote: > On Thu, Feb 28, 2019 at 11:37:45PM -0600, Parav Pandit wrote: > > Introduce a new subdev bus which holds sub devices created from a > > primary device. These devices are named as 'subdev'. > > A subdev is identified similarly to pci device using 16-bit vendor id > > and device id. > > Unlike PCI devices, scope of subdev is limited to Linux kernel. > > But these are limited to only PCI devices, right? > > This sounds a lot like that ARM proposal a week or so ago that asked for > something like this, are you working with them to make sure your > proposal works for them as well? (sorry, can't find where that was > announced, it was online somewhere...) Thanks for pointing this out and sorry for the delay in chiming in. Blog post and white paper are available here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/high-performance-device-virtualization-approach-to-standardization It would be certainly good to reach a degree of convergence in this design space, which eventually will be beneficial for the kernel interfaces required. Thanks again for pointing this out. Lorenzo
Re: [PATCH v2] arm64: dts: rockchip: add rk3399 UART DMAs
On 25/03/2019 12:34, Heiko Stuebner wrote: Am Donnerstag, 21. März 2019, 17:22:44 CET schrieb Katsuhiro Suzuki: Add UART dma channels as specified by the rk3399 TRM. Refer: RK3399 TRM V1.4: Chapter 12 DMA Controller Signed-off-by: Katsuhiro Suzuki applied for 5.2 As a heads-up, I did manage to try my board with this patch applied over the weekend, and it makes probing the bluetooth adapter fail with communication errors, so I'm not sure the 8250 and pl330 drivers are really cooperating well enough :( Robin.
[PATCH v5 2/2] dt-bindings: net: bluetooth: Add device tree bindings for QTI chip WCN3998
This patch enables regulators for the Qualcomm Bluetooth WCN3998 controller. Signed-off-by: Harish Bandi --- Changes in V5: - modified the DT document for wcn399x to make inline - in function call with driver code --- Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt index 824c0e2..7ef6118 100644 --- a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt +++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt @@ -11,20 +11,21 @@ Required properties: - compatible: should contain one of the following: * "qcom,qca6174-bt" * "qcom,wcn3990-bt" + * "qcom,wcn3998-bt" Optional properties for compatible string qcom,qca6174-bt: - enable-gpios: gpio specifier used to enable chip - clocks: clock provided to the controller (SUSCLK_32KHZ) -Required properties for compatible string qcom,wcn3990-bt: +Required properties for compatible string qcom,wcn399x-bt: - vddio-supply: VDD_IO supply regulator handle. - vddxo-supply: VDD_XO supply regulator handle. - vddrf-supply: VDD_RF supply regulator handle. - vddch0-supply: VDD_CH0 supply regulator handle. -Optional properties for compatible string qcom,wcn3990-bt: +Optional properties for compatible string qcom,wcn399x-bt: - max-speed: see Documentation/devicetree/bindings/serial/slave-device.txt -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v5 1/2] Bluetooth: hci_qca: Added support for WCN3998
Added new compatible for WCN3998 and corresponding voltage
and current values to WCN3998 compatible.
Changed driver code to support WCN3998
Signed-off-by: Harish Bandi
---
Changes in V5:
- changed is_qca_soc_type_wcn399x_family to
- qca_is_wcn399x helper function
- moved the qca_is_wcn399x function to btqca.c
---
drivers/bluetooth/btqca.c | 13 +++--
drivers/bluetooth/btqca.h | 8 +++-
drivers/bluetooth/hci_qca.c | 40 ++--
3 files changed, 44 insertions(+), 17 deletions(-)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index 6122685..383e99f 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -344,7 +344,7 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
/* Download rampatch file */
config.type = TLV_TYPE_PATCH;
- if (soc_type == QCA_WCN3990) {
+ if (qca_is_wcn399x(soc_type)) {
/* Firmware files to download are based on ROM version.
* ROM version is derived from last two bytes of soc_ver.
*/
@@ -365,7 +365,7 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
/* Download NVM configuration */
config.type = TLV_TYPE_NVM;
- if (soc_type == QCA_WCN3990)
+ if (qca_is_wcn399x(soc_type))
snprintf(config.fwname, sizeof(config.fwname),
"qca/crnv%02x.bin", rom_ver);
else
@@ -410,6 +410,15 @@ int qca_set_bdaddr(struct hci_dev *hdev, const bdaddr_t
*bdaddr)
}
EXPORT_SYMBOL_GPL(qca_set_bdaddr);
+bool qca_is_wcn399x(enum qca_btsoc_type soc_type)
+{
+ if ((soc_type == QCA_WCN3990) || (soc_type == QCA_WCN3998))
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(qca_is_wcn399x);
+
MODULE_AUTHOR("Ben Young Tae Kim ");
MODULE_DESCRIPTION("Bluetooth support for Qualcomm Atheros family ver "
VERSION);
MODULE_VERSION(VERSION);
diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
index 6fdc25d..aca7b0d 100644
--- a/drivers/bluetooth/btqca.h
+++ b/drivers/bluetooth/btqca.h
@@ -132,7 +132,8 @@ enum qca_btsoc_type {
QCA_INVALID = -1,
QCA_AR3002,
QCA_ROME,
- QCA_WCN3990
+ QCA_WCN3990,
+ QCA_WCN3998,
};
#if IS_ENABLED(CONFIG_BT_QCA)
@@ -142,6 +143,7 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
enum qca_btsoc_type soc_type, u32 soc_ver);
int qca_read_soc_version(struct hci_dev *hdev, u32 *soc_version);
int qca_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr);
+bool qca_is_wcn399x(enum qca_btsoc_type soc_type);
#else
static inline int qca_set_bdaddr_rome(struct hci_dev *hdev, const bdaddr_t
*bdaddr)
@@ -165,4 +167,8 @@ static inline int qca_set_bdaddr(struct hci_dev *hdev,
const bdaddr_t *bdaddr)
return -EOPNOTSUPP;
}
+static inline bool qca_is_wcn399x(enum qca_btsoc_type soc_type)
+{
+ return -EOPNOTSUPP;
+}
#endif
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 4ea995d..4af580a 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -521,7 +521,7 @@ static int qca_open(struct hci_uart *hu)
if (hu->serdev) {
qcadev = serdev_device_get_drvdata(hu->serdev);
- if (qcadev->btsoc_type != QCA_WCN3990) {
+ if (!qca_is_wcn399x(qcadev->btsoc_type)) {
gpiod_set_value_cansleep(qcadev->bt_en, 1);
} else {
hu->init_speed = qcadev->init_speed;
@@ -627,7 +627,7 @@ static int qca_close(struct hci_uart *hu)
if (hu->serdev) {
qcadev = serdev_device_get_drvdata(hu->serdev);
- if (qcadev->btsoc_type == QCA_WCN3990)
+ if (qca_is_wcn399x(qcadev->btsoc_type))
qca_power_shutdown(hu);
else
gpiod_set_value_cansleep(qcadev->bt_en, 0);
@@ -1008,7 +1008,7 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t
baudrate)
msecs_to_jiffies(CMD_TRANS_TIMEOUT_MS));
/* Give the controller time to process the request */
- if (qca_soc_type(hu) == QCA_WCN3990)
+ if (qca_is_wcn399x(qca_soc_type(hu)))
msleep(10);
else
msleep(300);
@@ -1084,7 +1084,7 @@ static unsigned int qca_get_speed(struct hci_uart *hu,
static int qca_check_speeds(struct hci_uart *hu)
{
- if (qca_soc_type(hu) == QCA_WCN3990) {
+ if (qca_is_wcn399x(qca_soc_type(hu))) {
if (!qca_get_speed(hu, QCA_INIT_SPEED) &&
!qca_get_speed(hu, QCA_OPER_SPEED))
return -EINVAL;
@@ -1116,7 +1116,7 @@ static int qca_set_speed(struct hci_uart *hu, enum
qca_speed_type speed_type)
/* Disable flow control for wcn3990 to deassert RTS while
* changing the baudrate of chip and host.
*/
-
[PATCH v5 0/2] Enable Bluetooth functionality for WCN3998.
This patch series we add support for WCN3998 BT chip set. This new chip set is based from the WCN3990 with minimal power numbers. So here in this patch The major difference between wcn3990 and WCN3998 is only power numbers. where as init process and fw download is same with wcn3990. So we add new compatible for WCN3998. Removed the Reading of regulator values from dts. Added new compatible for WCN3998. Changes in V5: changed is_qca_soc_type_wcn399x_family to qca_is_wcn399x helper function Moved the qca_is_wcn399x function to btqca.c modified the DT document for wcn399x as per driver code Changes in V4: Added is_qca_soc_type_wcn399x_family helper function to get the soc type is wcn399x or not. Changes in V3: updated to latest code base. Harish Bandi (2): Bluetooth: hci_qca: Added support for WCN3998 dt-bindings: net: bluetooth: Add device tree bindings for QTI chip WCN3998 .../devicetree/bindings/net/qualcomm-bluetooth.txt | 5 +-- drivers/bluetooth/btqca.c | 13 +-- drivers/bluetooth/btqca.h | 8 - drivers/bluetooth/hci_qca.c| 40 ++ 4 files changed, 47 insertions(+), 19 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 4/4] drivers/base/memory.c: Rename the misleading parameter
On Tue, Mar 26, 2019 at 05:02:27PM +0800, Baoquan He wrote: > The input parameter 'phys_index' of memory_block_action() is actually > the section number, but not the phys_index of memory_block. Fix it. > static int > -memory_block_action(unsigned long phys_index, unsigned long action, int > online_type) > +memory_block_action(unsigned long sec, unsigned long action, int online_type) 'sec' is a bad abbreviation for 'section'. We don't use it anyhere else in the vm. Looking through include/, I see it used as an abbreviation for second, security, ELF section, and section of a book. Nowhere as a memory block section. Please use an extra four letters for this parameter.
Re: Bad file pattern in MAINTAINERS section 'SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER'
On Mon, 25 Mar 2019 at 22:29, Joe Perches wrote: > > A file pattern line in this section of the MAINTAINERS file in linux-next > does not have a match in the linux source files. Thanks for reminder, the patch adding file is pending. Best regards, Krzysztof
Re: [PATCH v5.1 RESEND] dt-bindings: hwrng: Add Samsung Exynos 5250+ True RNG bindings
On Fri, 11 Jan 2019 at 14:22, Łukasz Stelmach wrote: > > Add binding documentation for the True Random Number Generator > found on Samsung Exynos 5250+ SoCs. > > Acked-by: Rob Herring > Reviewed-by: Krzysztof Kozlowski > Signed-off-by: Łukasz Stelmach > --- Rob, Could you apply this directly? You acked this some time ago but it never went through drivers tree. Lukasz resent this patch and it is waiting since then. The driver implementing compatible is already in mainline. Best regards, Krzysztof
Re: [PATCH v12 01/11] bitops: Introduce the for_each_set_clump8 macro
On Tue, Mar 26, 2019 at 11:54:59AM +0900, William Breathitt Gray wrote: > On Mon, Mar 25, 2019 at 03:12:36PM +0200, Andy Shevchenko wrote: > > On Mon, Mar 25, 2019 at 03:22:23PM +0900, William Breathitt Gray wrote: > > > This macro iterates for each 8-bit group of bits (clump) with set bits, > > > within a bitmap memory region. For each iteration, "start" is set to the > > > bit offset of the found clump, while the respective clump value is > > > stored to the location pointed by "clump". Additionally, the > > > bitmap_get_value8 and bitmap_set_value8 functions are introduced to > > > respectively get and set an 8-bit value in a bitmap memory region. > > > > > > This seems to miss Randy's (IIRC) comment about too many const specifiers. > > I disagree with removing the const qualifiers; I believe they are useful > and do not significantly impact the clarity of the code (in fact, I'd > argue the opposite). Had you checked the assembly? I'm talking about const for values on the stack. I think if you put less const there compiler can keep something in the registers instead of using direct constants or accessing stack. I might be mistaken, so, I can't argue without evidence of either. > The const qualifiers make it clear these values are > constant, allowing readers at a glace to know these values never change > within this function. Although I believe GCC is smart enough in this > case to deduce implicitly that these are constant values, generally > speaking const qualifiers do make it easier for compilers to optimize > sections of code (OoO execution, algorithm simplification, etc.), so I > believe it's useful in a technical sense as well. Again, what the difference do you see in assembly if any? > I added the const qualifier to these variables because they really are > constant, and I believe there is merit in making it explicit in the > code. If the primary reason for removing the const qualifiers is for > aesthetics, then I must dissent with that decision. The point is, if there is no difference, I would prefer one which will be better to read, otherwise check the assembly. > However, it is difficult to read the definitions that wrap around to a > second line. These definitions are long enough that even removing the > const qualifiers would not help prevent the wrapping, so perhaps it > would make to let these stay on a single line. Do you think it would > help to ignore the 80-character maximum line width coding style rule for > these cases here? 80-characters rule can be slightly bended depending on the context. Here, I think, we might continue discussing the matter after having an evidence how const qualifiers affect the code. -- With Best Regards, Andy Shevchenko
Re: [PATCH 4.9 00/30] 4.9.166-stable review
On Tue, 26 Mar 2019 at 12:01, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.166 release. > There are 30 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Mar 28 04:25:51 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.166-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. NOTE: We started running perf tests on all our kernel branches. Summary kernel: 4.9.166-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: b7e63ff5d9f9f1ae13c633d2b98e6b180398ff5f git describe: v4.9.165-31-gb7e63ff5d9f9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.165-31-gb7e63ff5d9f9 No regressions (compared to build v4.9.165) No fixes (compared to build v4.9.165) Ran 22730 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
RE: [PATCH v4 1/2] x86/MCE: Add function to allow filtering of MCA errors
> -Original Message- > From: linux-edac-ow...@vger.kernel.org On > Behalf Of Borislav Petkov > Sent: Tuesday, March 26, 2019 2:57 AM > To: Ghannam, Yazen > Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; > tony.l...@intel.com; x...@kernel.org; ra...@milecki.pl; > cle...@gmail.com > Subject: Re: [PATCH v4 1/2] x86/MCE: Add function to allow filtering of MCA > errors > > On Mon, Mar 25, 2019 at 04:34:22PM +, Ghannam, Yazen wrote: > > From: Yazen Ghannam > > > > Some systems may report spurious MCA errors. In general, spurious MCA > > errors may be disabled by clearing a particular bit in MCA_CTL. However, > > clearing a bit in MCA_CTL may not be recommended for some errors, so the > > only option is to ignore them. > > > > An MCA error is printed and handled after it has been added to the MCE > > event pool. So an MCA error can be ignored by not adding it to the pool. > > > > Define a default function that does not filter any errors. > > > > Check if an MCA error should be filtered out when adding it to the MCE > > event pool. > > > > Cc: # 5.0.x > > The old version of the patches had 4.14.x here as a kernel version. Why > change? > They don't apply cleanly to v4.14 anymore because of the recent header change. I figured they would need to be fixed up and submitted separately to older stable versions. Is that okay? Thanks, Yazen
Re: [PATCH v3] PCI: xilinx: Check for __get_free_pages() failure
On 25/03/2019 22:19, Kangjie Lu wrote:
> If __get_free_pages() fails, the patch returns -ENOMEM to avoid
As Bjorn suggested s/the patch returns/return/ would suffice and is
slightly easier to read. But I'm happy either way.
> NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu
Reviewed-by: Steven Price
> ---
> v3: remove "unlikely", as suggested by Bjorn Helgaas.
> v2: caller is redefined to accept the error code, as suggested by
> Steven Price
> ---
> drivers/pci/controller/pcie-xilinx.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-xilinx.c
> b/drivers/pci/controller/pcie-xilinx.c
> index 9bd1a35cd5d8..abc214e94f7c 100644
> --- a/drivers/pci/controller/pcie-xilinx.c
> +++ b/drivers/pci/controller/pcie-xilinx.c
> @@ -336,14 +336,19 @@ static const struct irq_domain_ops msi_domain_ops = {
> * xilinx_pcie_enable_msi - Enable MSI support
> * @port: PCIe port information
> */
> -static void xilinx_pcie_enable_msi(struct xilinx_pcie_port *port)
> +static int xilinx_pcie_enable_msi(struct xilinx_pcie_port *port)
> {
> phys_addr_t msg_addr;
>
> port->msi_pages = __get_free_pages(GFP_KERNEL, 0);
> + if (!port->msi_pages)
> + return -ENOMEM;
> +
> msg_addr = virt_to_phys((void *)port->msi_pages);
> pcie_write(port, 0x0, XILINX_PCIE_REG_MSIBASE1);
> pcie_write(port, msg_addr, XILINX_PCIE_REG_MSIBASE2);
> +
> + return 0;
> }
>
> /* INTx Functions */
> @@ -498,6 +503,7 @@ static int xilinx_pcie_init_irq_domain(struct
> xilinx_pcie_port *port)
> struct device *dev = port->dev;
> struct device_node *node = dev->of_node;
> struct device_node *pcie_intc_node;
> + int ret;
>
> /* Setup INTx */
> pcie_intc_node = of_get_next_child(node, NULL);
> @@ -526,7 +532,9 @@ static int xilinx_pcie_init_irq_domain(struct
> xilinx_pcie_port *port)
> return -ENODEV;
> }
>
> - xilinx_pcie_enable_msi(port);
> + ret = xilinx_pcie_enable_msi(port);
> + if (ret)
> + return ret;
> }
>
> return 0;
>
Re: [PATCH v2 0/2] Correct the processing for base_frequency
On Monday, March 25, 2019 5:04:38 PM CET Srinivas Pandruvada wrote: > The base_frequency display in cpufreq sysfs for intel_pstate gets the > guaranteed ratio by reading CPPC guaranteed performance register as a > first preference before falling back to x86 MSR for Hardware P-state > Capabilities. The current code in cppc_acpi.c assumed that "guaranteed > performance register" can be an integer field, which is invalid as per > ACPI spec. So this change explicitly check for INTEGER values for > invalid BIOS/firmware and ignore. > Also guaranteed performance register field is optional and when not > present, nominal performance can be used as the guaranteed performance. > But spec calls that this is true only in non-autonomous mode. So > no change is made in cppc_acpi.c to make nominal as guaranteed in this > case to avoid dependency on autonomous and non-autonomous mode. Instead > a change is added to intel_pstate driver, which is specific to x86 to > make nominal as guaranteed when guaranteed performance field is absent > or has invalid value. > Also we are working to clarify this non-autonomous mode requirement > through ACPI standard body. > > v2: > Changes done as suggested by Rafael. > > > Srinivas Pandruvada (2): > ACPI / CPPC: Fix processing for guaranteed performance > cpufreq: intel_pstate: Also use cppc nominal_perf for base_frequency > > drivers/acpi/cppc_acpi.c | 9 +++-- > drivers/cpufreq/intel_pstate.c | 5 - > 2 files changed, 11 insertions(+), 3 deletions(-) > > Both applied, thanks!
Re: Print map for total physical and virtual memory
On Tue, Mar 26, 2019 at 08:34:20AM +, Pankaj Suryawanshi wrote: > Hello, > > 1. Is there any way to print whole physical and virtual memory map in > kernel/user space ? > > 2. Is there any way to print map of cma area reserved memory and movable > pages of cma area. > > 3. Is there any way to know who pinned the pages from cma reserved area ? You probably want tools/vm/page-types.c
Re: Bad file pattern in MAINTAINERS section 'KEYS-TRUSTED'
Mimi,
Can you fix this and I can ack and send PR through my tree?
/Jarkko
On Mon, Mar 25, 2019 at 02:27:05PM -0700, Joe Perches wrote:
> A file pattern line in this section of the MAINTAINERS file in linux-next
> does not have a match in the linux source files.
>
> This could occur because a matching filename was never added, was deleted
> or renamed in some other commit.
>
> The commits that added and if found renamed or removed the file pattern
> are shown below.
>
> Please fix this defect appropriately.
>
> 1: ---
>
> linux-next MAINTAINERS section:
>
> 8587KEYS-TRUSTED
> 8588M: James Bottomley
> 8589M: Jarkko Sakkinen
> 8590M: Mimi Zohar
> 8591L: linux-integr...@vger.kernel.org
> 8592L: keyri...@vger.kernel.org
> 8593S: Supported
> 8594F: Documentation/security/keys/trusted-encrypted.rst
> 8595F: include/keys/trusted-type.h
> 8596F: security/keys/trusted.c
> --> 8597F: security/keys/trusted.h
>
> 2: ---
>
> The most recent commit that added or modified file pattern
> 'security/keys/trusted.h':
>
> commit 7f3c68bee977ab872827e44de017216736fe21d7
> Author: Mimi Zohar
> Date: Tue Jan 18 09:07:13 2011 -0500
>
> keys: add trusted and encrypted maintainers
>
> Add myself and David Safford as maintainers for trusted/encrypted keys.
>
> Signed-off-by: Mimi Zohar
> Acked-by: David Howells
> Signed-off-by: James Morris
>
> MAINTAINERS | 22 ++
> 1 file changed, 22 insertions(+)
>
> 3: ---
>
> The last commit with a real presence of file pattern
> 'security/keys/trusted.h':
>
> commit 22447981fc050b5f1bdd0e7cbee89b4152a2b2d8
> Author: Denis Kenzior
> Date: Tue Oct 9 17:48:49 2018 +0100
>
> KEYS: Move trusted.h to include/keys [ver #2]
>
> Signed-off-by: Denis Kenzior
> Signed-off-by: David Howells
> Tested-by: Marcel Holtmann
> Reviewed-by: Marcel Holtmann
> Signed-off-by: James Morris
>
> {security => include}/keys/trusted.h | 0
> security/keys/trusted.c | 2 +-
> 2 files changed, 1 insertion(+), 1 deletion(-)
Re: ceph: fix use-after-free on symlink traversal
On Tue, Mar 26, 2019 at 2:39 AM Al Viro wrote:
>
> free the symlink body after the same RCU delay we have for freeing the
> struct inode itself, so that traversal during RCU pathwalk wouldn't step
> into freed memory.
>
> Signed-off-by: Al Viro
> ---
> diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
> index e3346628efe2..2d61ddda9bf5 100644
> --- a/fs/ceph/inode.c
> +++ b/fs/ceph/inode.c
> @@ -524,6 +524,7 @@ static void ceph_i_callback(struct rcu_head *head)
> struct inode *inode = container_of(head, struct inode, i_rcu);
> struct ceph_inode_info *ci = ceph_inode(inode);
>
> + kfree(ci->i_symlink);
> kmem_cache_free(ceph_inode_cachep, ci);
> }
>
> @@ -566,7 +567,6 @@ void ceph_destroy_inode(struct inode *inode)
> }
> }
>
> - kfree(ci->i_symlink);
> while ((n = rb_first(>i_fragtree)) != NULL) {
> frag = rb_entry(n, struct ceph_inode_frag, node);
> rb_erase(n, >i_fragtree);
Al, I see you directed this patch at Linus instead of ceph-devel.
I can pick it up for -rc3 as I have an important libceph fix pending
anyway. Let me know if you want me to handle it.
Thanks,
Ilya
Re: [PATCH v2 2/2] media:st-mipid02: MIPID02 CSI-2 to PARALLEL bridge driver
Hi Mickael, On Mon, Mar 25, 2019 at 12:22:17PM +, Mickael GUENE wrote: ... > >> + /* register it for later use */ > >> + bridge->rx = ep; > >> + bridge->rx.link_frequencies = ep.nr_of_link_frequencies == 1 ? > >> + >link_frequency : NULL; > > > > I think you need to simply ignore the link frequencies here. The > > transmitting device can tell the frequency based on its configuration > > (based on the link frequencies). You seem to have implemented that already. > > > Idea of this was to allow some support for sensor that doesn't implement > V4L2_CID_PIXEL_RATE. Do you think it's useless ? Sensor drivers need to be amended with support for that control. -- Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH] firmware: arm_scmi: check return value of idr_find
On 25/03/2019 20:48, Kangjie Lu wrote:
> Thanks for Steven Price's review of this patch. In the current code,
There's no need to include a "thanks" message in the commit message -
the "Reviewed-by" tag is sufficient. Please also remember to include an
appropriate version tag in the subject - this should be "v2".
Thanks,
Steve
> idr_find won't return NULL because the SCMI_PROTOCOL_BASE id must
> exist. However, it might return NULL in the future code if the check
> is on another node while processing the children in subsequent calls
> to scmi_mbox_chan_setup().
> Therefore, the patch conservatively checks the return value and
> returns -EINVAL when it indeed failed.
>
> Signed-off-by: Kangjie Lu
> Reviewed-by: Steven Price
> ---
> drivers/firmware/arm_scmi/driver.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/driver.c
> b/drivers/firmware/arm_scmi/driver.c
> index 8f952f2f1a29..35faa203d549 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -709,6 +709,8 @@ scmi_mbox_chan_setup(struct scmi_info *info, struct
> device *dev, int prot_id)
>
> if (scmi_mailbox_check(np)) {
> cinfo = idr_find(>tx_idr, SCMI_PROTOCOL_BASE);
> + if (!cinfo)
> + return -EINVAL;
> goto idr_alloc;
> }
>
>
[PATCH] clocksource: Make clocksource insert entry more efficient
In clocksource_enqueue(), it is unnecessary to do
entry = >list
in every loop,do it once in the last loop is enough.
Signed-off-by: Yongkai Wu
---
kernel/time/clocksource.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 3bcc19c..da4829b 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -829,11 +829,12 @@ static void clocksource_enqueue(struct clocksource *cs)
list_for_each_entry(tmp, _list, list) {
/* Keep track of the place, where to insert */
- if (tmp->rating < cs->rating)
+ if (tmp->rating < cs->rating) {
+ entry = >list;
break;
- entry = >list;
+ }
}
- list_add(>list, entry);
+ list_add_tail(>list, entry);
}
/**
--
1.8.3.1
Re: [PATCH] dt-bindings: reset: meson-g12a: Add missing USB2 PHY resets
Hi Kevin, On Fri, 2019-03-22 at 15:53 -0700, Kevin Hilman wrote: [...] > Could ou make a immtable tag for this in your tree? This is needed for > some upcoming DT users we'd like to queue for the next cycle. I have just sent a reset/fixes pull request including this patch. Once that gets merged, you can either wait for the next -rc that includes it or pull in git://git.pengutronix.de/pza/linux reset/meson-g12a which is just the first patch of the two. regards Philipp
Re: [PATCH v12 3/4] cpuidle: Export the next timer/tick expiration for a CPU
On Tue, 26 Mar 2019 at 11:36, Rafael J. Wysocki wrote: > > On Mon, Mar 25, 2019 at 3:24 PM Ulf Hansson wrote: > > > > On Mon, 25 Mar 2019 at 13:21, Rafael J. Wysocki wrote: > > > > > > On Wednesday, February 27, 2019 8:58:35 PM CET Ulf Hansson wrote: > > > > To be able to predict the sleep duration for a CPU that is entering > > > > idle, > > > > knowing when the next timer/tick is going to expire, is extremely > > > > useful. > > > > Both the teo and the menu cpuidle governors already makes use of this > > > > information, while selecting an idle state. > > > > > > [cut] > > > > > > > > + > > > > if (cpuidle_state_is_coupled(drv, index)) > > > > return cpuidle_enter_state_coupled(dev, drv, index); > > > > return cpuidle_enter_state(dev, drv, index); > > > > > > Also I would clear next_hrtimer here to avoid dragging stale values > > > around. > > > > Right, I can do that. > > > > However, at least in my case it would be an unnecessary update of the > > variable, as I am never in a path where the value can be "stale". > > It easily can AFAICS. After all, cpu_power_down_ok() need not run on > the same CPU that is setting next_hrtimer here. That's correct. > > > Even if one theoretically could use a stale value, it's seems likely to not > > be an issue, don't you think? > > That would be because of the locking in the ->enter() callback I > suppose? But is it actually universally guaranteed that setting > next_hrtimer will never be reordered with acquiring the lock? In the PSCI case and for those CPUs that shares the same genpd governor (even hierarchically), then yes. Unfortunate, I haven't been able to explore this in that great detail for other legacy ARM32 platforms, so maybe it's just better to play safe, as you suggest and avoid a stale value. > > Also, there is some overhead to be avoided if cpu_power_down_ok() > checked the next_hrtimer of the other CPUs against 0 explicitly, isn't > it? In regards to overhead and when using genpd for CPUs, there are a couple of things I have in mind that we could try to improve. Yes, checking for next_hrtimer against 0 could be one thing to consider. Kind regards Uffe
[PATCH] ARM: dts: sun7i: fix typos in uart pin mux
The recently added uart mux options had a few typos. Fix them.
Fixes: 43d0fe112585 ("ARM: dts: sun7i: add pinctrl for missing uart mux
options")
Reported-by: Werner Böllmann
Signed-off-by: Mans Rullgard
---
arch/arm/boot/dts/sun7i-a20.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 9f8bd8f3164b..9234cf8f72bf 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -1006,19 +1006,19 @@
/omit-if-no-ref/
uart1_cts_rts_pa_pins: uart1-cts-rts-pa-pins {
- pins = "PA12", "PIA13";
- function = "uart2";
+ pins = "PA12", "PA13";
+ function = "uart1";
};
/omit-if-no-ref/
uart2_pa_pins: uart2-pa-pins {
- pins = "PIA2", "PIA3";
+ pins = "PA2", "PA3";
function = "uart2";
};
/omit-if-no-ref/
uart2_cts_rts_pa_pins: uart2-cts-rts-pa-pins {
- pins = "PA0", "PIA1";
+ pins = "PA0", "PA1";
function = "uart2";
};
--
2.21.0
Re: [PATCH v2 3/3] ARM: dts: stm32: Add clock on stm32mp157c syscfg
Hi Fabrice
On 12/12/18 9:48 AM, Fabrice Gasnier wrote:
STM32 syscfg needs a clock to access registers.
Signed-off-by: Fabrice Gasnier
---
arch/arm/boot/dts/stm32mp157c.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi
b/arch/arm/boot/dts/stm32mp157c.dtsi
index 8bf1c17..61b2a70 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -820,6 +820,7 @@
syscfg: syscon@5002 {
compatible = "st,stm32mp157-syscfg", "syscon";
reg = <0x5002 0x400>;
+ clocks = < SYSCFG>;
};
lptimer2: timer@50021000 {
For the DT patch:
Applied on stm32-next.
Thanks.
Alex
[PATCH v3 3/4] cpufreq: schedutil: Simplify iowait boosting
From: Rafael J. Wysocki
There is not reason for the minimum iowait boost value in the
schedutil cpufreq governor to depend on the available range of CPU
frequencies. In fact, that dependency is generally confusing,
because it causes the iowait boost to behave somewhat differently
on CPUs with the same maximum frequency and different minimum
frequencies, for example.
For this reason, replace the min field in struct sugov_cpu
with a constant and choose its values to be 1/8 of
SCHED_CAPACITY_SCALE (for consistency with the intel_pstate
driver's internal governor).
[Note that policy->cpuinfo.max_freq will not be a constant any more
after a subsequent change, so this change is depended on by it.]
Link:
https://lore.kernel.org/lkml/20190305083202.gu32...@hirez.programming.kicks-ass.net/T/#ee20bdc98b7d89f6110c0d00e5c3ee8c2ced93c3d
Suggested-by: Peter Zijlstra
Signed-off-by: Rafael J. Wysocki
---
kernel/sched/cpufreq_schedutil.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
Index: linux-pm/kernel/sched/cpufreq_schedutil.c
===
--- linux-pm.orig/kernel/sched/cpufreq_schedutil.c
+++ linux-pm/kernel/sched/cpufreq_schedutil.c
@@ -13,6 +13,8 @@
#include
#include
+#define IOWAIT_BOOST_MIN (SCHED_CAPACITY_SCALE / 8)
+
struct sugov_tunables {
struct gov_attr_set attr_set;
unsigned intrate_limit_us;
@@ -51,7 +53,6 @@ struct sugov_cpu {
u64 last_update;
unsigned long bw_dl;
- unsigned long min;
unsigned long max;
/* The field below is for single-CPU policies only: */
@@ -303,7 +304,7 @@ static bool sugov_iowait_reset(struct su
if (delta_ns <= TICK_NSEC)
return false;
- sg_cpu->iowait_boost = set_iowait_boost ? sg_cpu->min : 0;
+ sg_cpu->iowait_boost = set_iowait_boost ? IOWAIT_BOOST_MIN : 0;
sg_cpu->iowait_boost_pending = set_iowait_boost;
return true;
@@ -349,7 +350,7 @@ static void sugov_iowait_boost(struct su
}
/* First wakeup after IO: start with minimum boost */
- sg_cpu->iowait_boost = sg_cpu->min;
+ sg_cpu->iowait_boost = IOWAIT_BOOST_MIN;
}
/**
@@ -389,7 +390,7 @@ static unsigned long sugov_iowait_apply(
* No boost pending; reduce the boost value.
*/
sg_cpu->iowait_boost >>= 1;
- if (sg_cpu->iowait_boost < sg_cpu->min) {
+ if (sg_cpu->iowait_boost < IOWAIT_BOOST_MIN) {
sg_cpu->iowait_boost = 0;
return util;
}
@@ -826,9 +827,6 @@ static int sugov_start(struct cpufreq_po
memset(sg_cpu, 0, sizeof(*sg_cpu));
sg_cpu->cpu = cpu;
sg_cpu->sg_policy = sg_policy;
- sg_cpu->min =
- (SCHED_CAPACITY_SCALE * policy->cpuinfo.min_freq) /
- policy->cpuinfo.max_freq;
}
for_each_cpu(cpu, policy->cpus) {
[PATCH v3 0/4] cpufreq: intel_pstate: Handle _PPC updates on global turbo disable/enable
Hi All, This is a new version of the following with one patch added: > This is a follow-up to the RFT patch set posted previously: > https://lore.kernel.org/lkml/9956076.f4luudm...@aspire.rjw.lan/ > > Patch [1/3] causes intel_pstate to update all policies if it gets a _PPC > change notification and sees a global turbo disable/enable change. > > Patch [2/3] adds cpufreq_cpu_acquire() and cpufreq_cpu_release() to reduce > code duplication after the next patch a bit (and Srinivas wanted the rwsem > manipulation to not be done directly by the driver). > > Patch [3/3] makes intel_pstate update cpuinfo.max_freq for all policies in > those cases. > > I've atted Tested-by tags to patches [1/3] and [3/3], because there are only > cosmetic differences between them and what has been tested. The new patch goes (as the new [3/4]) before the old [3/3] (which becomes the new [4/4] obviously) and it modifies the schedutil governor to prevent it from caching values that depend on cpuinfo.max_freq. The other patches are the same as before. Thanks, Rafael
[PATCH v3 1/4] cpufreq: intel_pstate: Driver-specific handling of _PPC updates
From: Rafael J. Wysocki
In some cases, the platform firmware disables or enables turbo
frequencies for all CPUs globally before triggering a _PPC change
notification for one of them. Obviously, that global change affects
all CPUs, not just the notified one, and it needs to be acted upon by
cpufreq.
The intel_pstate driver is able to detect such global changes of
the settings, but it also needs to update policy limits for all
CPUs if that happens, in particular if turbo frequencies are
enabled globally - to allow them to be used.
For this reason, introduce a new cpufreq driver callback to be
invoked on _PPC notifications, if present, instead of simply
calling cpufreq_update_policy() for the notified CPU and make
intel_pstate use it to trigger policy updates for all CPUs
in the system if global settings change.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200759
Reported-by: Gabriele Mazzotta
Tested-by: Gabriele Mazzotta
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
---
v2 -> v3:
* Added Acked-by from Viresh.
---
drivers/acpi/processor_perflib.c |2 +-
drivers/cpufreq/cpufreq.c| 16
drivers/cpufreq/intel_pstate.c | 24
include/linux/cpufreq.h |4
4 files changed, 45 insertions(+), 1 deletion(-)
Index: linux-pm/drivers/acpi/processor_perflib.c
===
--- linux-pm.orig/drivers/acpi/processor_perflib.c
+++ linux-pm/drivers/acpi/processor_perflib.c
@@ -181,7 +181,7 @@ void acpi_processor_ppc_has_changed(stru
acpi_processor_ppc_ost(pr->handle, 0);
}
if (ret >= 0)
- cpufreq_update_policy(pr->id);
+ cpufreq_update_limits(pr->id);
}
int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -2370,6 +2370,22 @@ unlock:
}
EXPORT_SYMBOL(cpufreq_update_policy);
+/**
+ * cpufreq_update_limits - Update policy limits for a given CPU.
+ * @cpu: CPU to update the policy limits for.
+ *
+ * Invoke the driver's ->update_limits callback if present or call
+ * cpufreq_update_policy() for @cpu.
+ */
+void cpufreq_update_limits(unsigned int cpu)
+{
+ if (cpufreq_driver->update_limits)
+ cpufreq_driver->update_limits(cpu);
+ else
+ cpufreq_update_policy(cpu);
+}
+EXPORT_SYMBOL_GPL(cpufreq_update_limits);
+
/*
* BOOST *
*/
Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -179,6 +179,7 @@ struct vid_data {
* based on the MSR_IA32_MISC_ENABLE value and whether or
* not the maximum reported turbo P-state is different from
* the maximum reported non-turbo one.
+ * @turbo_disabled_s: Saved @turbo_disabled value.
* @min_perf_pct: Minimum capacity limit in percent of the maximum turbo
* P-state capacity.
* @max_perf_pct: Maximum capacity limit in percent of the maximum turbo
@@ -187,6 +188,7 @@ struct vid_data {
struct global_params {
bool no_turbo;
bool turbo_disabled;
+ bool turbo_disabled_s;
int max_perf_pct;
int min_perf_pct;
};
@@ -894,6 +896,25 @@ static void intel_pstate_update_policies
cpufreq_update_policy(cpu);
}
+static void intel_pstate_update_limits(unsigned int cpu)
+{
+ mutex_lock(_pstate_driver_lock);
+
+ update_turbo_state();
+ /*
+* If turbo has been turned on or off globally, policy limits for
+* all CPUs need to be updated to reflect that.
+*/
+ if (global.turbo_disabled_s != global.turbo_disabled) {
+ global.turbo_disabled_s = global.turbo_disabled;
+ intel_pstate_update_policies();
+ } else {
+ cpufreq_update_policy(cpu);
+ }
+
+ mutex_unlock(_pstate_driver_lock);
+}
+
/** sysfs begin /
#define show_one(file_name, object)\
static ssize_t show_##file_name \
@@ -2135,6 +2156,7 @@ static int __intel_pstate_cpu_init(struc
/* cpuinfo and default policy values */
policy->cpuinfo.min_freq = cpu->pstate.min_pstate * cpu->pstate.scaling;
update_turbo_state();
+ global.turbo_disabled_s = global.turbo_disabled;
policy->cpuinfo.max_freq = global.turbo_disabled ?
[PATCH v3 2/4] cpufreq: Add cpufreq_cpu_acquire() and cpufreq_cpu_release()
From: Rafael J. Wysocki
It sometimes is necessary to find a cpufreq policy for a given CPU
and acquire its rwsem (for writing) immediately after that, so
introduce cpufreq_cpu_acquire() as a helper for that and the
complementary cpufreq_cpu_release().
Make cpufreq_update_policy() use the new functions.
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
---
v2 -> v3:
* Added Acked-by from Viresh.
---
drivers/cpufreq/cpufreq.c | 56 ++
1 file changed, 47 insertions(+), 9 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -250,6 +250,51 @@ void cpufreq_cpu_put(struct cpufreq_poli
}
EXPORT_SYMBOL_GPL(cpufreq_cpu_put);
+/**
+ * cpufreq_cpu_release - Unlock a policy and decrement its usage counter.
+ * @policy: cpufreq policy returned by cpufreq_cpu_acquire().
+ */
+static void cpufreq_cpu_release(struct cpufreq_policy *policy)
+{
+ if (WARN_ON(!policy))
+ return;
+
+ lockdep_assert_held(>rwsem);
+
+ up_write(>rwsem);
+
+ cpufreq_cpu_put(policy);
+}
+
+/**
+ * cpufreq_cpu_acquire - Find policy for a CPU, mark it as busy and lock it.
+ * @cpu: CPU to find the policy for.
+ *
+ * Call cpufreq_cpu_get() to get a reference on the cpufreq policy for @cpu and
+ * if the policy returned by it is not NULL, acquire its rwsem for writing.
+ * Return the policy if it is active or release it and return NULL otherwise.
+ *
+ * The policy returned by this function has to be released with the help of
+ * cpufreq_cpu_release() in order to release its rwsem and balance its usage
+ * counter properly.
+ */
+static struct cpufreq_policy *cpufreq_cpu_acquire(unsigned int cpu)
+{
+ struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
+
+ if (!policy)
+ return NULL;
+
+ down_write(>rwsem);
+
+ if (policy_is_inactive(policy)) {
+ cpufreq_cpu_release(policy);
+ return NULL;
+ }
+
+ return policy;
+}
+
/*
*EXTERNALLY AFFECTING FREQUENCY CHANGES *
*/
@@ -2337,17 +2382,12 @@ static int cpufreq_set_policy(struct cpu
*/
void cpufreq_update_policy(unsigned int cpu)
{
- struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
+ struct cpufreq_policy *policy = cpufreq_cpu_acquire(cpu);
struct cpufreq_policy new_policy;
if (!policy)
return;
- down_write(>rwsem);
-
- if (policy_is_inactive(policy))
- goto unlock;
-
/*
* BIOS might change freq behind our back
* -> ask driver for current freq and notify governors about a change
@@ -2364,9 +2404,7 @@ void cpufreq_update_policy(unsigned int
cpufreq_set_policy(policy, _policy);
unlock:
- up_write(>rwsem);
-
- cpufreq_cpu_put(policy);
+ cpufreq_cpu_release(policy);
}
EXPORT_SYMBOL(cpufreq_update_policy);
[PATCH v3 4/4] cpufreq: intel_pstate: Update max frequency on global turbo changes
From: Rafael J. Wysocki
While the cpuinfo.max_freq value doesn't really matter for
intel_pstate in the active mode, in the passive mode it is used by
governors as the maximum physical frequency of the CPU and the
results of governor computations generally depend on it. Also it
is made available to user space via sysfs and it should match the
current HW configuration.
For this reason, make intel_pstate update cpuinfo.max_freq for all
CPUs if it detects a global change of turbo frequency settings from
"disable" to "enable" or the other way associated with a _PPC change
notification from the platform firmware.
Note that policy_is_inactive(), cpufreq_cpu_acquire(),
cpufreq_cpu_release(), and cpufreq_set_policy() need to be made
available to it for this purpose.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200759
Reported-by: Gabriele Mazzotta
Tested-by: Gabriele Mazzotta
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
---
v2 -> v3:
* Added Acked-by from Viresh.
---
drivers/cpufreq/cpufreq.c | 16
drivers/cpufreq/intel_pstate.c | 35 +--
include/linux/cpufreq.h| 10 ++
3 files changed, 43 insertions(+), 18 deletions(-)
Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -179,7 +179,7 @@ struct vid_data {
* based on the MSR_IA32_MISC_ENABLE value and whether or
* not the maximum reported turbo P-state is different from
* the maximum reported non-turbo one.
- * @turbo_disabled_s: Saved @turbo_disabled value.
+ * @turbo_disabled_mf: The @turbo_disabled value reflected by cpuinfo.max_freq.
* @min_perf_pct: Minimum capacity limit in percent of the maximum turbo
* P-state capacity.
* @max_perf_pct: Maximum capacity limit in percent of the maximum turbo
@@ -188,7 +188,7 @@ struct vid_data {
struct global_params {
bool no_turbo;
bool turbo_disabled;
- bool turbo_disabled_s;
+ bool turbo_disabled_mf;
int max_perf_pct;
int min_perf_pct;
};
@@ -896,6 +896,28 @@ static void intel_pstate_update_policies
cpufreq_update_policy(cpu);
}
+static void intel_pstate_update_max_freq(unsigned int cpu)
+{
+ struct cpufreq_policy *policy = cpufreq_cpu_acquire(cpu);
+ struct cpufreq_policy new_policy;
+ struct cpudata *cpudata;
+
+ if (!policy)
+ return;
+
+ cpudata = all_cpu_data[cpu];
+ policy->cpuinfo.max_freq = global.turbo_disabled_mf ?
+ cpudata->pstate.max_freq : cpudata->pstate.turbo_freq;
+
+ memcpy(_policy, policy, sizeof(*policy));
+ new_policy.max = min(policy->user_policy.max, policy->cpuinfo.max_freq);
+ new_policy.min = min(policy->user_policy.min, new_policy.max);
+
+ cpufreq_set_policy(policy, _policy);
+
+ cpufreq_cpu_release(policy);
+}
+
static void intel_pstate_update_limits(unsigned int cpu)
{
mutex_lock(_pstate_driver_lock);
@@ -905,9 +927,10 @@ static void intel_pstate_update_limits(u
* If turbo has been turned on or off globally, policy limits for
* all CPUs need to be updated to reflect that.
*/
- if (global.turbo_disabled_s != global.turbo_disabled) {
- global.turbo_disabled_s = global.turbo_disabled;
- intel_pstate_update_policies();
+ if (global.turbo_disabled_mf != global.turbo_disabled) {
+ global.turbo_disabled_mf = global.turbo_disabled;
+ for_each_possible_cpu(cpu)
+ intel_pstate_update_max_freq(cpu);
} else {
cpufreq_update_policy(cpu);
}
@@ -2156,7 +2179,7 @@ static int __intel_pstate_cpu_init(struc
/* cpuinfo and default policy values */
policy->cpuinfo.min_freq = cpu->pstate.min_pstate * cpu->pstate.scaling;
update_turbo_state();
- global.turbo_disabled_s = global.turbo_disabled;
+ global.turbo_disabled_mf = global.turbo_disabled;
policy->cpuinfo.max_freq = global.turbo_disabled ?
cpu->pstate.max_pstate : cpu->pstate.turbo_pstate;
policy->cpuinfo.max_freq *= cpu->pstate.scaling;
Index: linux-pm/drivers/cpufreq/cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -34,11 +34,6 @@
static LIST_HEAD(cpufreq_policy_list);
-static inline bool policy_is_inactive(struct cpufreq_policy *policy)
-{
- return cpumask_empty(policy->cpus);
-}
-
/* Macros to iterate over CPU policies */
#define for_each_suitable_policy(__policy, __active)\
list_for_each_entry(__policy, _policy_list, policy_list) \
@@ -254,7
[PATCH v7 3/3] iio:temperature: Add MAX31856 thermocouple support
From: Paresh Chaudhary
This patch adds support for Maxim MAX31856 thermocouple
temperature sensor support.
More information can be found in:
https://www.maximintegrated.com/en/ds/MAX31856.pdf
NOTE: Driver support only Comparator Mode.
Signed-off-by: Paresh Chaudhary
Signed-off-by: Matt Weber
Signed-off-by: Patrick Havelange
---
Changes
v1 -> v2
[Peter
1. Fixed all space & 'return' related comments
2. Removed 'sysfs_create_group' api because
iio_device_register function is handling sysfs entry
3. Return -EIO if there is any fault
4. Added check for 'read_size' before spi read call
5. Removed license text from the source file
6. Added .o file in alphabetic order
7. Used #defines instead of magic bits
v2 -> v3
[Jonathan
1. Used bool for fault_oc and fault_ovuv
2. Changed 'max31856_read' function and use byte array to
store registers value.
3. Used 'GENMASK' where required
4. Changed logic 'max31856_thermocouple_read' function. Used
array to read registers value.
5. Used 'devm_iio_device_register' and removed 'max31856_remove'.
6. Fixed other cosmetic changes.
7. Added 'sysfs-bus-iio-temperature-max31856' file and updated
'MAINTAINERS' file.
v3 -> v4
[Jonathan
1. Removed unwanted logic
2. Updated code to handle return value of max31856_read call
3. Added devicetree id table
4. Removed one-shot support from driver as this support was not
implemented with correct design.
v4 -> v5
[Patrick
1. Rename thermocouple type to maxim,thermocouple-type for DT entry
2. Don't cache values from the Fault Status Register
3. Simplify a bit max31856_init()
4. Use IIO_NO_MOD in switch case + default error case
5. Use dev_*() instead of pr_*()
6. Fix missing space in comments
7. Removed iio_info.driver_module assignment as no longer present
8. Don't keep read/write buffer into the internal driver struct
9. Updated kernel version, add missing space in documentation
10. Updated (c) year
11. Removed linux/init.h #include
12. More use of BIT() macro
13. Removed iio_chan_spec.address assignment as not used
14. In max31856_thermocouple_read(), same switch case order as
channels definition
15. Refactor show_fault_*() functions
16. Use u8 as register type in max31856_{read,write}()
v5 -> v6
[Patrick
1. Use generic thermocouple-type property
2. Fix doc for fault_ovuv entry
3. Add check for supported thermocouple-types in probe()
v6 -> v7
[Patrick
1. None
---
.../sysfs-bus-iio-temperature-max31856| 24 ++
drivers/iio/temperature/Kconfig | 10 +
drivers/iio/temperature/Makefile | 1 +
drivers/iio/temperature/max31856.c| 353 ++
4 files changed, 388 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
create mode 100644 drivers/iio/temperature/max31856.c
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
new file mode 100644
index ..3b3509a3ef2f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
@@ -0,0 +1,24 @@
+What: /sys/bus/iio/devices/iio:deviceX/fault_oc
+KernelVersion: 5.1
+Contact: linux-...@vger.kernel.org
+Description:
+ Open-circuit fault. The detection of open-circuit faults,
+ such as those caused by broken thermocouple wires.
+ Reading returns either '1' or '0'.
+ '1' = An open circuit such as broken thermocouple wires
+ has been detected.
+ '0' = No open circuit or broken thermocouple wires are detected
+
+What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv
+KernelVersion: 5.1
+Contact: linux-...@vger.kernel.org
+Description:
+ Overvoltage or Undervoltage Input Fault. The internal circuitry
+ is protected from excessive voltages applied to the thermocouple
+ cables by integrated MOSFETs at the T+ and T- inputs, and the
+ BIAS output. These MOSFETs turn off when the input voltage is
+ negative or greater than VDD.
+ Reading returns either '1' or '0'.
+ '1' = The input voltage is negative or greater than VDD.
+ '0' = The input voltage is positive and less than VDD (normal
+ state).
diff --git a/drivers/iio/temperature/Kconfig b/drivers/iio/temperature/Kconfig
index 82e4a62745e2..c66eeb23615b 100644
--- a/drivers/iio/temperature/Kconfig
+++ b/drivers/iio/temperature/Kconfig
@@ -97,4 +97,14 @@ config TSYS02D
This driver can also be built as a module. If so, the module will
[PATCH v7 1/3] dt-bindings: iio/temperature: Add thermocouple types (and doc)
This patch introduces common thermocouple types used by various temperature sensors. Also a brief documentation explaining this "thermocouple-type" property. Signed-off-by: Patrick Havelange --- Changes v7 - Merge header and doc in same patch - Doc:add it's a single cell entry - Doc:removed non complete example Changes v6 - Add this file --- .../iio/temperature/temperature-bindings.txt | 7 +++ .../dt-bindings/iio/temperature/thermocouple.h | 16 2 files changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt create mode 100644 include/dt-bindings/iio/temperature/thermocouple.h diff --git a/Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt b/Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt new file mode 100644 index ..8f339cab74ae --- /dev/null +++ b/Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt @@ -0,0 +1,7 @@ +If the temperature sensor device can be configured to use some specific +thermocouple type, you can use the defined types provided in the file +"include/dt-bindings/iio/temperature/thermocouple.h". + +Property: +thermocouple-type: A single cell representing the type of the thermocouple + used by the device. diff --git a/include/dt-bindings/iio/temperature/thermocouple.h b/include/dt-bindings/iio/temperature/thermocouple.h new file mode 100644 index ..ce037f5238ac --- /dev/null +++ b/include/dt-bindings/iio/temperature/thermocouple.h @@ -0,0 +1,16 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DT_BINDINGS_TEMPERATURE_THERMOCOUPLE_H +#define _DT_BINDINGS_TEMPERATURE_THERMOCOUPLE_H + + +#define THERMOCOUPLE_TYPE_B0x00 +#define THERMOCOUPLE_TYPE_E0x01 +#define THERMOCOUPLE_TYPE_J0x02 +#define THERMOCOUPLE_TYPE_K0x03 +#define THERMOCOUPLE_TYPE_N0x04 +#define THERMOCOUPLE_TYPE_R0x05 +#define THERMOCOUPLE_TYPE_S0x06 +#define THERMOCOUPLE_TYPE_T0x07 + +#endif /* _DT_BINDINGS_TEMPERATURE_THERMOCOUPLE_H */ -- 2.19.1
[PATCH v7 2/3] iio:temperature:max31856:Add device tree bind info
From: Paresh Chaudhary
This patch added device tree binding info for MAX31856 driver.
Signed-off-by: Paresh Chaudhary
Signed-off-by: Matt Weber
Signed-off-by: Patrick Havelange
Reviewed-by: Rob Herring
---
Changes
v1 -> v2
[Matt
- Removed comment block and added possibilities of
thermocouple type in device tree binding doc.
v2 -> v3
- Rebased
v3 -> v4
- Removed one-shot property related information.
- Used standard name 'temp-sensor'
v4 -> v5
[Patrick
- Rename thermocouple type to maxim,thermocouple-type for DT entry
v5 -> v6
[Patrick
- use generic thermocouple-type for DT entry
v6 -> v7
[Patrick
- None
---
.../bindings/iio/temperature/max31856.txt | 24 +++
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/temperature/max31856.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/max31856.txt
b/Documentation/devicetree/bindings/iio/temperature/max31856.txt
new file mode 100644
index ..06ab43bb4de8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/max31856.txt
@@ -0,0 +1,24 @@
+Maxim MAX31856 thermocouple support
+
+https://datasheets.maximintegrated.com/en/ds/MAX31856.pdf
+
+Optional property:
+ - thermocouple-type: Type of thermocouple (THERMOCOUPLE_TYPE_K if
+ omitted). Supported types are B, E, J, K, N, R, S, T.
+
+Required properties:
+ - compatible: must be "maxim,max31856"
+ - reg: SPI chip select number for the device
+ - spi-max-frequency: As per datasheet max. supported freq is 500
+ - spi-cpha: must be defined for max31856 to enable SPI mode 1
+
+ Refer to spi/spi-bus.txt for generic SPI slave bindings.
+
+ Example:
+ temp-sensor@0 {
+ compatible = "maxim,max31856";
+ reg = <0>;
+ spi-max-frequency = <500>;
+ spi-cpha;
+ thermocouple-type = ;
+ };
--
2.19.1
Re: [PATCH 0/3] ARM: dts: stm32: IPCC mailbox support on STM32MP157c
Hi Fabien On 3/1/19 10:18 AM, Fabien Dessenne wrote: Support IPCC mailbox on STM32MP157c-ed1 and STM32MP157a-dk1 boards. Fabien Dessenne (3): ARM: dts: stm32: add IPCC mailbox support on STM32MP157c ARM: dts: stm32: enable IPCC mailbox support on STM32MP157c-ed1 ARM: dts: stm32: enable IPCC mailbox support on STM32MP157a-dk1 arch/arm/boot/dts/stm32mp157a-dk1.dts | 4 arch/arm/boot/dts/stm32mp157c-ed1.dts | 4 arch/arm/boot/dts/stm32mp157c.dtsi| 15 +++ 3 files changed, 23 insertions(+) Series applied on stm32-next. Regards Alex
Re: [PATCH v2] genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent()
Hi Stephen,
On 25/03/2019 18:10, Stephen Boyd wrote:
> This function returns an error if a child irqchip calls
> irq_chip_set_wake_parent() but its parent irqchip has the
> IRQCHIP_SKIP_SET_WAKE flag set. Let's return 0 for success here instead
> because there isn't anything to do.
>
> This keeps the behavior consistent with how set_irq_wake_real() is
> implemented. That function returns 0 when the irqchip has the
> IRQCHIP_SKIP_SET_WAKE flag set. It doesn't attempt to walk the chain of
> parents and set irq wake on any chips that don't have the flag set
> either. If the intent is to call the .irq_set_wake() callback of the
> parent irqchip, then we expect irqchip implementations to omit the
> IRQCHIP_SKIP_SET_WAKE flag and implement an .irq_set_wake() function
> that calls irq_chip_set_wake_parent().
>
> This fixes a problem on my Qualcomm sdm845 device where I can't set wake
> on any GPIO interrupts after I apply work in progress wakeup irq patches
> to the GPIO driver. The chain of chips looks like this:
>
> ARM GIC (skip) -> QCOM PDC (skip) -> QCOM GPIO
nit: the parenting chain is actually built the other way around (we
don't express the 'child' relationship). This doesn't change anything to
the patch, but would make the reasoning a but easier to understand.
>
> The GPIO controller is a child of the QCOM PDC irqchip which is a child
> of the ARM GIC irqchip. The QCOM PDC irqchip has the
> IRQCHIP_SKIP_SET_WAKE flag set, and so does the grandparent ARM GIC.
>
> The GPIO driver doesn't know if the parent needs to set wake or not, so
> it unconditionally calls irq_chip_set_wake_parent() causing this
> function to return a failure because the parent irqchip (PDC) doesn't
> have the .irq_set_wake() callback set. Returning 0 instead makes
> everything work and irqs from the GPIO controller can be configured for
> wakeup.
>
> Cc: Lina Iyer
> Cc: Marc Zyngier
> Signed-off-by: Stephen Boyd
Fixes: 08b55e2a9208e ("genirq: Add irqchip_set_wake_parent")
Acked-by: Marc Zyngier
Thanks,
M.
--
Jazz is not dead. It just smells funny...
[PATCH v4 1/2] mmc: sdhci: Export sdhci_finish_command()
Make sdhci_finish_command() public so that it can be called from platform
drivers.
Signed-off-by: Faiz Abbas
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a8141ff9be03..76d36e13a011 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1445,7 +1445,7 @@ static void sdhci_read_rsp_136(struct sdhci_host *host,
struct mmc_command *cmd)
}
}
-static void sdhci_finish_command(struct sdhci_host *host)
+void sdhci_finish_command(struct sdhci_host *host)
{
struct mmc_command *cmd = host->cmd;
@@ -1495,6 +1495,7 @@ static void sdhci_finish_command(struct sdhci_host *host)
sdhci_finish_mrq(host, cmd->mrq);
}
}
+EXPORT_SYMBOL_GPL(sdhci_finish_command);
static u16 sdhci_get_preset_value(struct sdhci_host *host)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 01002cba1359..49b133babf47 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -798,5 +798,6 @@ void sdhci_start_tuning(struct sdhci_host *host);
void sdhci_end_tuning(struct sdhci_host *host);
void sdhci_reset_tuning(struct sdhci_host *host);
void sdhci_send_tuning(struct sdhci_host *host, u32 opcode);
+void sdhci_finish_command(struct sdhci_host *host);
#endif /* __SDHCI_HW_H */
--
2.19.2
[PATCH v4 2/2] mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
commit 5b0d62108b46 ("mmc: sdhci-omap: Add platform specific reset
callback") skips data resets during tuning operation. Because of this,
a data error or data finish interrupt might still arrive after a command
error has been handled and the mrq ended. This ends up with a "mmc0: Got
data interrupt 0x0002 even though no data operation was in progress"
error message.
Fix this by adding a platform specific callback for sdhci_irq. Mark the
mrq as a failure but wait for a data interrupt instead of calling
finish_mrq().
Signed-off-by: Faiz Abbas
---
drivers/mmc/host/sdhci-omap.c | 37 +++
1 file changed, 37 insertions(+)
diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
index 5bbed477c9b1..9da2ff9ede8b 100644
--- a/drivers/mmc/host/sdhci-omap.c
+++ b/drivers/mmc/host/sdhci-omap.c
@@ -797,6 +797,42 @@ void sdhci_omap_reset(struct sdhci_host *host, u8 mask)
sdhci_reset(host, mask);
}
+#define CMD_ERR_MASK (SDHCI_INT_CRC | SDHCI_INT_END_BIT | SDHCI_INT_INDEX |\
+ SDHCI_INT_TIMEOUT)
+#define CMD_MASK (CMD_ERR_MASK | SDHCI_INT_RESPONSE)
+
+static irqreturn_t sdhci_omap_irq(struct sdhci_host *host, u32 intmask)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
+
+ if (omap_host->is_tuning && (intmask & CMD_ERR_MASK)) {
+
+ /*
+* Since we are not resetting data lines during tuning
+* operation, data error or data complete interrupts
+* might still arrive. Mark this request as a failure
+* but still wait for the data interrupt
+*/
+ if (intmask & SDHCI_INT_TIMEOUT)
+ host->cmd->error = -ETIMEDOUT;
+ else
+ host->cmd->error = -EILSEQ;
+
+ sdhci_finish_command(host);
+
+ /*
+* Sometimes command error interrupts and command complete
+* interrupt will arrive together. Clear all command related
+* interrupts here.
+*/
+ sdhci_writel(host, intmask & CMD_MASK, SDHCI_INT_STATUS);
+ intmask &= ~CMD_MASK;
+ }
+
+ return intmask;
+}
+
static struct sdhci_ops sdhci_omap_ops = {
.set_clock = sdhci_omap_set_clock,
.set_power = sdhci_omap_set_power,
@@ -807,6 +843,7 @@ static struct sdhci_ops sdhci_omap_ops = {
.platform_send_init_74_clocks = sdhci_omap_init_74_clocks,
.reset = sdhci_omap_reset,
.set_uhs_signaling = sdhci_omap_set_uhs_signaling,
+ .irq = sdhci_omap_irq,
};
static int sdhci_omap_set_capabilities(struct sdhci_omap_host *omap_host)
--
2.19.2
[PATCH v4 0/2] Fix command errors during tuning
These patches fix the following error message in dra7xx boards: [4.833198] mmc1: Got data interrupt 0x0002 even though no data operation was in progress. Tested with 100 times boot tests on dra71x-evm, dra72x-evm and dra7xx-evm. v4: Fixed commit description for patch 1. Added SDHCI_INT_TIMEOUT to CMD_ERR_MASK in patch 2. v3: Removed the command error specific callback and using the already existing sdhci_irq callback instead. No measurable drop in performance. v2: Added EXPORT_SYMBOL_GPL for sdhci_cmd_err and sdhci_send_command to fix errors when built as module. Faiz Abbas (2): mmc: sdhci: Export sdhci_finish_command() mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning drivers/mmc/host/sdhci-omap.c | 37 +++ drivers/mmc/host/sdhci.c | 3 ++- drivers/mmc/host/sdhci.h | 1 + 3 files changed, 40 insertions(+), 1 deletion(-) -- 2.19.2
[PATCH v2] MAINTAINERS: Fix the link to ad7606 dt-bindings
The devicetree bindings documentation for ad7606 should also include
the vendor prefix: ad7606.txt -> adi,ad7606.txt
Fixes: 6e33a125df66 ("dt-bindings: iio: adc: Add docs for AD7606 ADC")
Signed-off-by: Stefan Popa
---
Changes in v2:
- Added Fixes tag
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ff2c2f2..4f81cdc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -860,7 +860,7 @@ L: linux-...@vger.kernel.org
W: http://ez.analog.com/community/linux-device-drivers
S: Supported
F: drivers/iio/adc/ad7606.c
-F: Documentation/devicetree/bindings/iio/adc/ad7606.txt
+F: Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
ANALOG DEVICES INC AD7768-1 DRIVER
M: Stefan Popa
--
2.7.4
Re: [PATCH v1] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
On Tue, 26 Mar 2019 at 11:35, Anand Moon wrote:
(...)
> > This is third or fourth submission but you marked it as v1. This makes
> > it very difficult to discuss and reference previous versions.
> >
> > The commit message did not change since beginning (first version). I
> > asked twice that you need to explain exactly why you put the the
> > regulator to off or on state in suspend. Why?
> > Because:
> > 1. This change looks without justification - once you put on, then you
> > put off, now again on,
> > 2. Anyone reading the code later must know the rationale why this was done,
> > 3. I am not quite sure whether this is good setting so I would be
> > happy to be convinced.
> >
>
> Like I mention in the patch summary that this.
>
> Current changes are based on
> [0]
> https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/max77686.txt
>
> Regulators which can be turned off during system suspend:
> -LDOn : 2, 6-8, 10-12, 14-16,
> -BUCKn : 1-4.
> Use standard regulator bindings for it ('regulator-off-in-suspend').
I do not see how this is related to my questions.
> > How to provide such explanation? The best in commit message. Sometimes
> > in the comment in the code, depends.
>
> Ok I have been testing with following regulator debug prints to catch error.
> [0] max77686-regulator.patch
>
> below is the console logs during suspend and resume.
> ---
> Last login: Sat Mar 23 18:22:46 on ttySAC1
> [root@archl-u3e ~]# echo no > /sys/module/printk/parameters/console_suspend
> [root@archl-u3e ~]# rtcwake -d /dev/rtc0 -m mem -s 10
> rtcwake: wakeup from "mem" using /dev/rtc0 at Sat Mar 23 19:56:17 2019
> [ 38.595854] PM: suspend entry (deep)
> [ 38.596603] PM: Syncing filesystems ... done.
> [ 38.629351] Freezing user space processes ... (elapsed 0.002 seconds) done.
> [ 38.633192] OOM killer disabled.
> [ 38.636035] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds) done.
> [ 38.675059] smsc95xx 1-2:1.0 eth0: entering SUSPEND2 mode
> [ 38.753120] dwc2 1248.hsotg: suspending usb gadget g_ether
> [ 38.754007] dwc2 1248.hsotg: new device is full-speed
> [ 38.758960] dwc2 1248.hsotg: dwc2_hsotg_ep_disable: called for ep0
> [ 38.765507] dwc2 1248.hsotg: dwc2_hsotg_ep_disable: called for ep0
> [ 38.774050] wake enabled for irq 119
> [ 38.775761] BUCK9: No configuration
> [ 38.779191] BUCK8_P3V3: No configuration
> [ 38.782852] BUCK7_2.0V: No configuration
> [ 38.786851] BUCK6_1.35V: No configuration
> [ 38.790752] VDDQ_CKEM1_2_1.2V: No configuration
> [ 38.796220] BUCK4: regulator suspend disable supported
> [ 38.800769] BUCK3: regulator suspend disable supported
> [ 38.806002] BUCK1: regulator suspend disable supported
> [ 38.810644] LDO26: No configuration
> [ 38.814169] VDDQ_LCD_1.8V: No configuration
> [ 38.818267] LDO24: No configuration
> [ 38.821732] LDO23: No configuration
> [ 38.825262] LDO22_VDDQ_MMC4_2.8V: No configuration
> [ 38.829992] TFLASH_2.8V: No configuration
> [ 38.834040] LDO20_1.8V: No configuration
> [ 38.837883] LDO19: No configuration
> [ 38.841349] LDO18: No configuration
> [ 38.844878] LDO17: No configuration
> [ 38.848667] LDO16: regulator suspend disable supported
> [ 38.853889] LDO15: regulator suspend disable supported
> [ 38.858931] LDO14: regulator suspend disable supported
> [ 38.863771] VDDQ_C2C_W_1.8V: No configuration
> [ 38.868378] LDO12: regulator suspend disable supported
> [ 38.873508] LDO11: regulator suspend disable supported
> [ 38.878545] LDO10: regulator suspend disable supported
> [ 38.883384] LDO9: No configuration
> [ 38.887190] LDO8: regulator suspend disable supported
> [ 38.892168] LDO7: regulator suspend disable supported
> [ 38.897279] LDO6: regulator suspend disable supported
> [ 38.901872] VDDQ_MMC1_3_1.8V: No configuration
> [ 38.906363] VDDQ_MMC2_2.8V: No configuration
> [ 38.910541] VDDQ_EXT_1.8V: No configuration
> [ 38.915134] LDO2: regulator suspend disable supported
> [ 38.919753] VDD_ALIVE_1.0V: No configuration
> [ 38.935229] usb3503 0-0008: switched to STANDBY mode
> [ 38.935981] wake enabled for irq 123
> [ 38.955192] samsung-pinctrl 1100.pinctrl: Setting external
> wakeup interrupt mask: 0xfbfff7ff
> [ 38.975448] Disabling non-boot CPUs ...
> [ 39.029279] s3c2410-wdt 1006.watchdog: watchdog disabled
> [ 39.029576] wake disabled for irq 123
> [ 39.044319] usb3503 0-0008: switched to HUB mode
> [ 39.144089] wake disabled for irq 119
> [ 39.144812] dwc2 1248.hsotg: resuming usb gadget g_ether
> [ 39.422626] usb 1-2: reset high-speed USB device number 2 using exynos-ehci
> [ 39.774632] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
> [ 40.106478] OOM killer enabled.
> [ 40.106609] Restarting tasks ... done.
> [ 40.00] PM: suspend exit
> [ 40.124058] mmc_host mmc1: Bus speed
[GIT PULL] file locking bugfix for v5.1
The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00: Linux 5.1-rc2 (2019-03-24 14:02:26 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git tags/locks-v5.1 for you to fetch changes up to 945ab8f6de94430c23a82f3cf2e3f6d6f2945ff7: locks: wake any locks blocked on request before deadlock check (2019-03-25 08:36:24 -0400) Hi Linus, Just a single fix for a bug that crept into POSIX lock deadlock detection in v5.0. Jeff Layton (1): locks: wake any locks blocked on request before deadlock check fs/locks.c | 5 + 1 file changed, 5 insertions(+) -- Jeff Layton signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/1] pwm: meson: fix scheduling while atomic issue
Hello,
On Tue, Mar 26, 2019 at 10:06:31AM +0100, Neil Armstrong wrote:
> On 25/03/2019 18:41, Martin Blumenstingl wrote:
> > On Mon, Mar 25, 2019 at 9:41 AM Uwe Kleine-König
> > wrote:
> >> On Sun, Mar 24, 2019 at 11:02:16PM +0100, Martin Blumenstingl wrote:
> >>> Back in January a "BUG: scheduling while atomic" error showed up during
> >>> boot on my Meson8b Odroid-C1 (which uses a PWM regulator as CPU supply).
> >>> The call trace comes down to:
> >>> __mutex_lock
> >>> clk_prepare_lock
> >>> clk_core_get_rate
> >>> meson_pwm_apply
> >>> ..
> >>> dev_pm_opp_set_rate
> >>> ..
> >>>
> >>> Jerome has also seen the same problem but from pwm-leds (instead of a
> >>> pwm-regulator). He posted a patch which replaces the spinlock with a
> >>> mutex. That works. I believe we can optimize this by reducing the time
> >>> where the lock is held - that also allows to keep the spin-lock.
> >>>
> >>> Analyzing this issue helped me understand the pwm-meson driver better.
> >>> My plan is to send some cleanups (with the goal of re-using more of the
> >>> goodies from the PWM core in the pwm-meson driver) after this single fix
> >>> is merged (they can be found here: [1]).
> >>
> >> I didn't look over these in detail, but I see an issue that according
> >> to the shortlogs isn't addressed: In the .apply callback there is
> >> (simplified):
> >>
> >> if (!state->enabled) {
> >> meson_pwm_disable(meson, pwm->hwpwm);
> >> return;
> >> }
> >>
> >> This results in the wrong output after:
> >>
> >> pwm_apply_state(pwm, { .enabled = true, .polarity =
> >> PWM_POLARITY_NORMAL, ...});
> >> pwm_apply_state(pwm, { .enabled = false, .polarity =
> >> PWM_POLARITY_INVERTED, ...});
> >>
> >> because the polarity isn't checked.
> > let me rephrase this to make sure I understand this correctly:
> > - applying a PWM state with .enabled = true and PWM_POLARITY_NORMAL
> > will enable the PWM output
> > - applying a PWM state with .enabled = false and PWM_POLARITY_NORMAL
> > will disable the PWM output
> > - applying a PWM state with .enabled = true and PWM_POLARITY_INVERTED
> > will disable the PWM output
> > - applying a PWM state with .enabled = false and PWM_POLARITY_INVERTED
> > will enable the PWM output
> >
> > in other words: the polarity doesn't only apply to period and
> > duty_cycle but also to the enabled state.
>
> Sorry I don't understand your point.
> If the apply state is disable, well we disable the PWM output, I don't see why
> the polarity changes the enable state.
Martin's summary was at least misleading, I didn't understand what he
meant.
The relevant point is: When the PWM is disabled (either by pwm_disable
or equivalent by pwm_apply_state(pwm, { .enabled = false, ... })) the
expectation is that the output becomes "inactive". That means "constant
low" for a normal PWM and "constant high" for an inverted PWM.
Then as meson_pwm_apply doesn't check for state->polarity if
state->enabled == false there is a bug.
> I'd like to point out the architecture of the PWM.
> The PWM is only a set of Gates, Dividers and Counters.
>
> We achieve a PWM output by calculating a clock that permits us to calculate
> 2 periods (low and high) and we set the counter to switch after N cycles
> for the first half period.
>
> We do not have an explicit "polarity" setting, we simply reverse the period
> cycles (the low length is inversed with the high length).
>
> To apply the dividers and counters, we need to disable the PWM input clock
> gate, set the dividers and counter and release the input gate.
>
> So yes, we should maybe stop disabling the PWM for a long period of time
> when we calculate the new settings, it can be fixed easily by calculating
> the settings and applying in a separate code path.
If the hardware supports it the counter should not be stopped---most
other PWMs in my bubble can at least change the duty cycle as required.
(That is, complete the currently running period and that without delay
start a new period with the new settings.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH 3/4] mtd: spinand: Enabled support to detect parameter page
Some of the SPI NAND devices has parameter page which is similar to ONFI
table.
But, it may not be self sufficient to propagate all the required
parameters. Fixup function has been added in struct manufacturer to
accommodate this.
Signed-off-by: Shivamurthy Shastri
---
drivers/mtd/nand/spi/core.c | 113 +++-
include/linux/mtd/spinand.h | 5 ++
2 files changed, 117 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 985ad52cdaa7..40882a1d2bc1 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -574,6 +574,108 @@ static int spinand_lock_block(struct spinand_device
*spinand, u8 lock)
return spinand_write_reg_op(spinand, REG_BLOCK_LOCK, lock);
}
+/**
+ * spinand_read_param_page_op - Read parameter page operation
+ * @spinand: the spinand device
+ * @page: page number where parameter page tables can be found
+ * @parameters: buffer used to store the parameter page
+ * @len: length of the buffer
+ *
+ * Read parameter page
+ *
+ * Returns 0 on success, a negative error code otherwise.
+ */
+static int spinand_parameter_page_read(struct nand_device *base,
+ u8 page, void *buf, unsigned int len)
+{
+ struct spinand_device *spinand = nand_to_spinand(base);
+ struct spi_mem_op pread_op = SPINAND_PAGE_READ_OP(page);
+ struct spi_mem_op pread_cache_op =
+ SPINAND_PAGE_READ_FROM_CACHE_OP(false,
+ 0,
+ 1,
+ buf,
+ len);
+ u8 feature;
+ u8 status;
+ int ret;
+
+ if (len && !buf)
+ return -EINVAL;
+
+ ret = spinand_read_reg_op(spinand, REG_CFG,
+ );
+ if (ret)
+ return ret;
+
+ /* CFG_OTP_ENABLE is used to enable parameter page access */
+ feature |= CFG_OTP_ENABLE;
+
+ spinand_write_reg_op(spinand, REG_CFG, feature);
+
+ ret = spi_mem_exec_op(spinand->spimem, _op);
+ if (ret)
+ return ret;
+
+ ret = spinand_wait(spinand, );
+ if (ret < 0)
+ return ret;
+
+ ret = spi_mem_exec_op(spinand->spimem, _cache_op);
+ if (ret)
+ return ret;
+
+ ret = spinand_read_reg_op(spinand, REG_CFG,
+ );
+ if (ret)
+ return ret;
+
+ feature &= ~CFG_OTP_ENABLE;
+
+ spinand_write_reg_op(spinand, REG_CFG, feature);
+
+ return 1;
+}
+
+static int check_version(struct nand_device *base,
+struct nand_onfi_params *p, int *onfi_version)
+{
+ /**
+* SPI NAND do not support ONFI standard
+* But, parameter page looks same as ONFI table
+*/
+ if (!le16_to_cpu(p->revision))
+ *onfi_version = 0;
+
+ return 1;
+}
+
+static int spinand_intf_data(struct nand_device *base,
+struct nand_onfi_params *p)
+{
+ struct spinand_device *spinand = nand_to_spinand(base);
+
+ /**
+* Manufacturers may interpret the parameter page differently
+*/
+ if (spinand->manufacturer->ops->fixup_param_page)
+ spinand->manufacturer->ops->fixup_param_page(spinand, p);
+
+ return 1;
+}
+
+static int spinand_param_page_detect(struct spinand_device *spinand)
+{
+ struct nand_device *base = spinand_to_nand(spinand);
+
+ base->helper.page = 0x01;
+ base->helper.check_revision = check_version;
+ base->helper.parameter_page_read = spinand_parameter_page_read;
+ base->helper.init_intf_data = spinand_intf_data;
+
+ return nand_onfi_detect(base);
+}
+
static int spinand_read_page(struct spinand_device *spinand,
const struct nand_page_io_req *req)
{
@@ -896,7 +998,7 @@ static void spinand_manufacturer_cleanup(struct
spinand_device *spinand)
return spinand->manufacturer->ops->cleanup(spinand);
}
-static const struct spi_mem_op *
+const struct spi_mem_op *
spinand_select_op_variant(struct spinand_device *spinand,
const struct spinand_op_variants *variants)
{
@@ -1012,6 +1114,15 @@ static int spinand_detect(struct spinand_device *spinand)
return ret;
}
+ if (!spinand->base.memorg.pagesize) {
+ ret = spinand_param_page_detect(spinand);
+ if (ret < 0) {
+ dev_err(dev, "no parameter page for %*phN\n",
+ SPINAND_MAX_ID_LEN, spinand->id.data);
+ return ret;
+ }
+ }
+
if (nand->memorg.ntargets > 1 && !spinand->select_target) {
[PATCH 2/4] mtd: nand: Move ONFI code into nand/ directory
Move generic ONFI code to nand/ directory, which can be used by SPI
NAND layer.
Signed-off-by: Shivamurthy Shastri
---
drivers/mtd/nand/Makefile| 2 +-
drivers/mtd/nand/{raw/nand_onfi.c => onfi.c} | 0
drivers/mtd/nand/raw/Makefile| 1 -
3 files changed, 1 insertion(+), 2 deletions(-)
rename drivers/mtd/nand/{raw/nand_onfi.c => onfi.c} (100%)
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 9772e781534d..1b43a911aa4a 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
-nandcore-objs := core.o bbt.o
+nandcore-objs := core.o bbt.o onfi.o
obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
obj-y += onenand/
diff --git a/drivers/mtd/nand/raw/nand_onfi.c b/drivers/mtd/nand/onfi.c
similarity index 100%
rename from drivers/mtd/nand/raw/nand_onfi.c
rename to drivers/mtd/nand/onfi.c
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 898e90508a3a..3467bbb4a51a 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -59,7 +59,6 @@ obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o
obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o
nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o
-nand-objs += nand_onfi.o
nand-objs += nand_jedec.o
nand-objs += nand_amd.o
nand-objs += nand_esmt.o
--
2.17.1
[PATCH 4/4] mtd: spinand: micron: Support for new Micron SPI NAND flashes
Driver is redesigned using parameter page to support Micron SPI NAND
flashes.
Support for selecting die is enabled for multi-die flashes.
Turn OOB layout generic.
Fixup some of the parameter page data as per Micron datasheet.
Signed-off-by: Shivamurthy Shastri
---
drivers/mtd/nand/spi/micron.c | 109 +-
1 file changed, 80 insertions(+), 29 deletions(-)
diff --git a/drivers/mtd/nand/spi/micron.c b/drivers/mtd/nand/spi/micron.c
index 7d7b1f7fcf71..663bb2809036 100644
--- a/drivers/mtd/nand/spi/micron.c
+++ b/drivers/mtd/nand/spi/micron.c
@@ -14,7 +14,7 @@
#define MICRON_STATUS_ECC_MASK GENMASK(7, 4)
#define MICRON_STATUS_ECC_NO_BITFLIPS (0 << 4)
-#define MICRON_STATUS_ECC_1TO3_BITFLIPS(1 << 4)
+#define MICRON_STATUS_ECC_1TO3_BITFLIPSBIT(4)
#define MICRON_STATUS_ECC_4TO6_BITFLIPS(3 << 4)
#define MICRON_STATUS_ECC_7TO8_BITFLIPS(5 << 4)
@@ -34,38 +34,38 @@ static SPINAND_OP_VARIANTS(update_cache_variants,
SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
SPINAND_PROG_LOAD(false, 0, NULL, 0));
-static int mt29f2g01abagd_ooblayout_ecc(struct mtd_info *mtd, int section,
- struct mtd_oob_region *region)
+static int ooblayout_ecc(struct mtd_info *mtd, int section,
+struct mtd_oob_region *region)
{
if (section)
return -ERANGE;
- region->offset = 64;
- region->length = 64;
+ region->offset = mtd->oobsize / 2;
+ region->length = mtd->oobsize / 2;
return 0;
}
-static int mt29f2g01abagd_ooblayout_free(struct mtd_info *mtd, int section,
-struct mtd_oob_region *region)
+static int ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
{
if (section)
return -ERANGE;
/* Reserve 2 bytes for the BBM. */
region->offset = 2;
- region->length = 62;
+ region->length = (mtd->oobsize / 2) - 2;
return 0;
}
-static const struct mtd_ooblayout_ops mt29f2g01abagd_ooblayout = {
- .ecc = mt29f2g01abagd_ooblayout_ecc,
- .free = mt29f2g01abagd_ooblayout_free,
+static const struct mtd_ooblayout_ops ooblayout = {
+ .ecc = ooblayout_ecc,
+ .free = ooblayout_free,
};
-static int mt29f2g01abagd_ecc_get_status(struct spinand_device *spinand,
-u8 status)
+static int ecc_get_status(struct spinand_device *spinand,
+ u8 status)
{
switch (status & MICRON_STATUS_ECC_MASK) {
case STATUS_ECC_NO_BITFLIPS:
@@ -90,22 +90,23 @@ static int mt29f2g01abagd_ecc_get_status(struct
spinand_device *spinand,
return -EINVAL;
}
-static const struct spinand_info micron_spinand_table[] = {
- SPINAND_INFO("MT29F2G01ABAGD", 0x24,
-NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 2, 1, 1),
-NAND_ECCREQ(8, 512),
-SPINAND_INFO_OP_VARIANTS(_cache_variants,
- _cache_variants,
- _cache_variants),
-0,
-SPINAND_ECCINFO(_ooblayout,
-mt29f2g01abagd_ecc_get_status)),
-};
+static int mt29f8g_select_target(struct spinand_device *spinand,
+unsigned int target)
+{
+ struct spi_mem_op op = SPINAND_SET_FEATURE_OP(0xd0,
+ spinand->scratchbuf);
+
+ if (target == 1)
+ target = 0x40;
+
+ *spinand->scratchbuf = target;
+ return spi_mem_exec_op(spinand->spimem, );
+}
static int micron_spinand_detect(struct spinand_device *spinand)
{
+ const struct spi_mem_op *op;
u8 *id = spinand->id.data;
- int ret;
/*
* Micron SPI NAND read ID need a dummy byte,
@@ -114,16 +115,66 @@ static int micron_spinand_detect(struct spinand_device
*spinand)
if (id[1] != SPINAND_MFR_MICRON)
return 0;
- ret = spinand_match_and_init(spinand, micron_spinand_table,
-ARRAY_SIZE(micron_spinand_table), id[2]);
- if (ret)
- return ret;
+ spinand->flags = 0;
+ spinand->eccinfo.get_status = ecc_get_status;
+ spinand->eccinfo.ooblayout =
+ spinand->select_target = mt29f8g_select_target;
+
+ op = spinand_select_op_variant(spinand,
+ _cache_variants);
+ if (!op)
+ return -ENOTSUPP;
+
+ spinand->op_templates.read_cache = op;
+
+ op = spinand_select_op_variant(spinand,
+ _cache_variants);
+ if (!op)
+ return -ENOTSUPP;
+
+ spinand->op_templates.write_cache = op;
+
+ op =
[PATCH 0/4] Introduce generic ONFI support
Current support to ONFI parameter page is only for raw NAND, this patch series turn ONFI support into generic. So that, other NAND devices like SPI NAND can use this. Support to detect parameter page is enabled in SPI NAND core. Turned Micron SPI NAND driver to use parameter page. >From SPI NAND side, this patch series is tested with Micron flashes MT29F2G01ABXGD, MT29F4G01ABXFD, MT29F8G01ADXFD, MT29F1G01ABXFD. I created this patch series based on mtd/next + Miquel Raynal's new series of patches, as I needed some of the changes done by him. Shivamurthy Shastri (4): mtd: rawnand: Turn the ONFI support to generic mtd: nand: Move ONFI code into nand/ directory mtd: spinand: Enabled support to detect parameter page mtd: spinand: micron: Support for new Micron SPI NAND flashes drivers/mtd/nand/Makefile| 2 +- drivers/mtd/nand/onfi.c | 169 + drivers/mtd/nand/raw/Makefile| 1 - drivers/mtd/nand/raw/internals.h | 6 +- drivers/mtd/nand/raw/nand_base.c | 236 +-- drivers/mtd/nand/raw/nand_onfi.c | 312 --- drivers/mtd/nand/spi/core.c | 113 ++- drivers/mtd/nand/spi/micron.c| 109 --- include/linux/mtd/nand.h | 30 +++ include/linux/mtd/rawnand.h | 5 + include/linux/mtd/spinand.h | 5 + 11 files changed, 620 insertions(+), 368 deletions(-) create mode 100644 drivers/mtd/nand/onfi.c delete mode 100644 drivers/mtd/nand/raw/nand_onfi.c -- 2.17.1
[PATCH 1/4] mtd: rawnand: Turn the ONFI support to generic
Fix headers to make way for adding helper functions.
Add onfi helper structure.
Add helper functions in raw NAND core, which later will be used during
ONFI detection.
Signed-off-by: Shivamurthy Shastri
---
drivers/mtd/nand/raw/internals.h | 6 +-
drivers/mtd/nand/raw/nand_base.c | 236 ---
drivers/mtd/nand/raw/nand_onfi.c | 215 +---
include/linux/mtd/nand.h | 30
include/linux/mtd/rawnand.h | 5 +
5 files changed, 289 insertions(+), 203 deletions(-)
diff --git a/drivers/mtd/nand/raw/internals.h b/drivers/mtd/nand/raw/internals.h
index a204f9d7e123..eb34dece4754 100644
--- a/drivers/mtd/nand/raw/internals.h
+++ b/drivers/mtd/nand/raw/internals.h
@@ -90,7 +90,7 @@ int nand_write_page_raw_notsupp(struct nand_chip *chip, const
u8 *buf,
int oob_required, int page);
int nand_exit_status_op(struct nand_chip *chip);
int nand_read_param_page_op(struct nand_chip *chip, u8 page, void *buf,
- unsigned int len);
+ unsigned int len);
void nand_decode_ext_id(struct nand_chip *chip);
void panic_nand_wait(struct nand_chip *chip, unsigned long timeo);
void sanitize_string(uint8_t *s, size_t len);
@@ -138,10 +138,6 @@ void nand_legacy_set_defaults(struct nand_chip *chip);
void nand_legacy_adjust_cmdfunc(struct nand_chip *chip);
int nand_legacy_check_hooks(struct nand_chip *chip);
-/* ONFI functions */
-u16 onfi_crc16(u16 crc, u8 const *p, size_t len);
-int nand_onfi_detect(struct nand_chip *chip);
-
/* JEDEC functions */
int nand_jedec_detect(struct nand_chip *chip);
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 0bc898bdb6e1..fc2c7d6ea4f2 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4194,24 +4194,6 @@ static void nand_set_defaults(struct nand_chip *chip)
chip->buf_align = 1;
}
-/* Sanitize ONFI strings so we can safely print them */
-void sanitize_string(uint8_t *s, size_t len)
-{
- ssize_t i;
-
- /* Null terminate */
- s[len - 1] = 0;
-
- /* Remove non printable chars */
- for (i = 0; i < len - 1; i++) {
- if (s[i] < ' ' || s[i] > 127)
- s[i] = '?';
- }
-
- /* Remove trailing spaces */
- strim(s);
-}
-
/*
* nand_id_has_period - Check if an ID string has a given wraparound period
* @id_data: the ID string
@@ -4461,6 +4443,222 @@ nand_manufacturer_name(const struct nand_manufacturer
*manufacturer)
return manufacturer ? manufacturer->name : "Unknown";
}
+/* Parse the ONFI parameter Page */
+int nand_onfi_read_op(struct nand_device *base, u8 page, void *buf,
+ unsigned int len)
+{
+ struct nand_chip *chip = device_to_nand(base);
+ struct nand_onfi_params *p = buf;
+ int ret;
+ unsigned int i;
+
+ ret = nand_read_param_page_op(chip, 0, NULL, 0);
+ if (ret)
+ return 0;
+
+ for (i = 0; i < 3; i++) {
+ ret = nand_read_data_op(chip, [i], sizeof(*p), true);
+ if (ret)
+ return 0;
+ }
+
+ return 1;
+}
+
+/* Parse the Extended Parameter Page. */
+static int nand_ext_param_page(struct nand_chip *chip,
+ struct nand_onfi_params *p)
+{
+ struct onfi_ext_param_page *ep;
+ struct onfi_ext_section *s;
+ struct onfi_ext_ecc_info *ecc;
+ u8 *cursor;
+ int ret;
+ int len;
+ int i;
+
+ /*
+* The nand_flash_detect_ext_param_page() uses the
+* Change Read Column command which maybe not supported
+* by the chip->legacy.cmdfunc. So try to update the
+* chip->legacy.cmdfunc now. We do not replace user supplied
+* command function.
+*/
+ nand_legacy_adjust_cmdfunc(chip);
+
+ len = le16_to_cpu(p->ext_param_page_length) * 16;
+ ep = kmalloc(len, GFP_KERNEL);
+ if (!ep)
+ return -ENOMEM;
+
+ /* Send our own NAND_CMD_PARAM. */
+ ret = nand_read_param_page_op(chip, 0, NULL, 0);
+ if (ret)
+ goto ext_out;
+
+ /* Use the Change Read Column command to skip the ONFI param pages. */
+ ret = nand_change_read_column_op(chip,
+sizeof(*p) * p->num_of_param_pages,
+ep, len, true);
+ if (ret)
+ goto ext_out;
+
+ ret = -EINVAL;
+ if ((onfi_crc16(ONFI_CRC_BASE, ((uint8_t *)ep) + 2, len - 2)
+ != le16_to_cpu(ep->crc))) {
+ pr_debug("fail in the CRC.\n");
+ goto ext_out;
+ }
+
+ /*
+* Check the signature.
+* Do not strictly follow the ONFI spec, maybe changed in future.
+*/
+ if (strncmp(ep->sig, "EPPS", 4)) {
+ pr_debug("The signature is invalid.\n");
+
Re: [PATCH v2 0/4] Add new features for the Spreadtrum serial controller
Hi Greg, On Mon, 4 Mar 2019 at 16:59, Baolin Wang wrote: > > This patch set fixes the baud rate calculation formula issue, as well as > adding power management support and DMA mode support for the Spreadtrum > serial controller. > > Changes from v1: > - The patch 1 of V1 was applied, so remove the baud rate fix from this patch > set. > - Add reviewed tag from Rob for patch 1. > - Fix the incorrect names' order in patch 3. Could you apply this patch set if no objection from you? Thanks. -- Baolin Wang Best Regards
Re: ceph: fix use-after-free on symlink traversal
On Mon, Mar 25, 2019 at 9:39 PM Al Viro wrote:
>
> free the symlink body after the same RCU delay we have for freeing the
> struct inode itself, so that traversal during RCU pathwalk wouldn't step
> into freed memory.
>
> Signed-off-by: Al Viro
> ---
> diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
> index e3346628efe2..2d61ddda9bf5 100644
> --- a/fs/ceph/inode.c
> +++ b/fs/ceph/inode.c
> @@ -524,6 +524,7 @@ static void ceph_i_callback(struct rcu_head *head)
> struct inode *inode = container_of(head, struct inode, i_rcu);
> struct ceph_inode_info *ci = ceph_inode(inode);
>
> + kfree(ci->i_symlink);
> kmem_cache_free(ceph_inode_cachep, ci);
> }
>
> @@ -566,7 +567,6 @@ void ceph_destroy_inode(struct inode *inode)
> }
> }
>
> - kfree(ci->i_symlink);
> while ((n = rb_first(>i_fragtree)) != NULL) {
> frag = rb_entry(n, struct ceph_inode_frag, node);
> rb_erase(n, >i_fragtree);
Reviewed-by: Jeff Layton
Re: [RFC PATCH v2 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller
On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote:
> Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming
> IP is pretty simple and provides direct memory mapped access to
> connected Flash devices.
>
> Add basic support for the IP without DMA. Second ChipSelect is not
> supported for now.
>
> Signed-off-by: Vignesh Raghavendra
[...]
> diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile
> index ca61dedd730d..24abd1d43ade 100644
> --- a/drivers/mtd/hyperbus/Makefile
> +++ b/drivers/mtd/hyperbus/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
>
> obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o
> +obj-$(CONFIG_HBMC_AM654) += hbmc_am654.o
> diff --git a/drivers/mtd/hyperbus/hbmc_am654.c
> b/drivers/mtd/hyperbus/hbmc_am654.c
> new file mode 100644
> index ..abf2b0959a35
> --- /dev/null
> +++ b/drivers/mtd/hyperbus/hbmc_am654.c
> @@ -0,0 +1,108 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> +// Author: Vignesh Raghavendra
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct am654_hbmc_priv {
> + struct hyperbus_ctlr ctlr;
> + struct hyperbus_device hbdev;
> + void __iomem*regbase;
> +};
> +
> +static const struct hyperbus_ops am654_hbmc_ops = {
> + .calibrate = hyperbus_calibrate,
> +};
> +
> +static int am654_hbmc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct am654_hbmc_priv *priv;
> + struct resource *res;
> + int ret;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
This is redundant as devm_ioremap_resource() checks for !res anyway.
> + dev_err(>dev, "failed to get memory resource\n");
> + return -ENOENT;
> + }
> +
> + priv->regbase = devm_ioremap_resource(dev, res);
BTW, there's devm_platform_ioremap_resource() now...
[...]
MBR, Sergei
Re: [PATCH 0/8] stm32 m4 remoteproc on STM32MP157c
Hi fabien On 3/5/19 3:24 PM, Fabien Dessenne wrote: STMicrolectronics STM32MP157 MPU are based on a Dual Arm Cortex-A7 core and a Cortex-M4. This patchset adds the support of the stm32_rproc driver allowing to control the M4 remote processor. Fabien Dessenne (8): dt-bindings: stm32: add bindings for ML-AHB interconnect dt-bindings: remoteproc: add bindings for stm32 remote processor driver remoteproc: stm32: add an ST stm32_rproc driver ARM: dts: stm32: add m4 remoteproc support on STM32MP157c ARM: dts: stm32: declare copro reserved memories on STM32MP157c-ed1 ARM: dts: stm32: enable m4 coprocessor support on STM32MP157c-ed1 ARM: dts: stm32: declare copro reserved memories on STM32MP157a-dk1 ARM: dts: stm32: enable m4 coprocessor support on STM32MP157a-dk1 .../devicetree/bindings/arm/stm32/mlahb.txt| 30 + .../devicetree/bindings/remoteproc/stm32-rproc.txt | 67 +++ arch/arm/boot/dts/stm32mp157a-dk1.dts | 54 ++ arch/arm/boot/dts/stm32mp157c-ed1.dts | 54 ++ arch/arm/boot/dts/stm32mp157c.dtsi | 21 + drivers/remoteproc/Kconfig | 15 + drivers/remoteproc/Makefile| 1 + drivers/remoteproc/stm32_rproc.c | 624 + 8 files changed, 866 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/stm32/mlahb.txt create mode 100644 Documentation/devicetree/bindings/remoteproc/stm32-rproc.txt create mode 100644 drivers/remoteproc/stm32_rproc.c Concerning DT patches, at first glance I don't see obvious issues. I'll take Dt patches as soon as driver and bindings patches are acked. regards Alex
Re: [PATCH v12 3/4] cpuidle: Export the next timer/tick expiration for a CPU
On Mon, Mar 25, 2019 at 3:24 PM Ulf Hansson wrote: > > On Mon, 25 Mar 2019 at 13:21, Rafael J. Wysocki wrote: > > > > On Wednesday, February 27, 2019 8:58:35 PM CET Ulf Hansson wrote: > > > To be able to predict the sleep duration for a CPU that is entering idle, > > > knowing when the next timer/tick is going to expire, is extremely useful. > > > Both the teo and the menu cpuidle governors already makes use of this > > > information, while selecting an idle state. > > > [cut] > > > > > + > > > if (cpuidle_state_is_coupled(drv, index)) > > > return cpuidle_enter_state_coupled(dev, drv, index); > > > return cpuidle_enter_state(dev, drv, index); > > > > Also I would clear next_hrtimer here to avoid dragging stale values > > around. > > Right, I can do that. > > However, at least in my case it would be an unnecessary update of the > variable, as I am never in a path where the value can be "stale". It easily can AFAICS. After all, cpu_power_down_ok() need not run on the same CPU that is setting next_hrtimer here. > Even if one theoretically could use a stale value, it's seems likely to not > be an issue, don't you think? That would be because of the locking in the ->enter() callback I suppose? But is it actually universally guaranteed that setting next_hrtimer will never be reordered with acquiring the lock? Also, there is some overhead to be avoided if cpu_power_down_ok() checked the next_hrtimer of the other CPUs against 0 explicitly, isn't it?
RE: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon syscall
> On Mon, Mar 18, 2019 at 1:16 PM Andy Lutomirski wrote: > > On Mon, Mar 18, 2019 at 2:41 AM Elena Reshetova > > wrote: > > > Performance: > > > > > > 1) lmbench: ./lat_syscall -N 100 null > > > base: Simple syscall: 0.1774 microseconds > > > random_offset (rdtsc): Simple syscall: 0.1803 microseconds > > > random_offset (rdrand): Simple syscall: 0.3702 microseconds > > > > > > 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys > > > base: 1000 loops in 1.62224s = 162.22 nsec / > > > loop > > > random_offset (rdtsc): 1000 loops in 1.64660s = 164.66 nsec / > > > loop > > > random_offset (rdrand): 1000 loops in 3.51315s = 351.32 nsec / > > > loop > > > > > > > Egads! RDTSC is nice and fast but probably fairly easy to defeat. > > RDRAND is awful. I had hoped for better. > > RDRAND can also fail. > > > So perhaps we need a little percpu buffer that collects 64 bits of > > randomness at a time, shifts out the needed bits, and refills the > > buffer when we run out. > > I'd like to avoid saving the _exact_ details of where the next offset > will be, but if nothing else works, this should be okay. We can use 8 > bits at a time and call prandom_u32() every 4th call. Something like > prandom_bytes(), but where it doesn't throw away the unused bytes. Actually I think this would make the end result even worse security-wise than simply using rdtsc() on every syscall. Saving the randomness in percpu buffer, which is probably easily accessible and can be probed if needed, would supply attacker with much more knowledge about the next 3-4 random offsets that what he would get if we use "weak" rdtsc. Given that for a successful exploit, an attacker would need to have stack aligned once only, having a knowledge of 3-4 next offsets sounds like a present to an exploit writer... Additionally it creates complexity around the code that I have issues justifying with "security" argument because of above... I have the patch now with alloca() and rdtsc() working, I can post it (albeit it is very simple), but I am really hesitating on adding the percpu buffer randomness storage to it... Best Regards, Elena.
Re: [PATCH v1] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
Hi Krzysztof,
Thanks your for your valuable comments.
I will try to answer your queries to best of my knowledge.
On Mon, 25 Mar 2019 at 18:16, Krzysztof Kozlowski wrote:
>
> On Sun, 24 Mar 2019 at 09:33, Anand Moon wrote:
> >
> > Add suspend-to-mem node to regulator core to be enabled or disabled
> > during system suspend and also support changing the regulator operating
> > mode during runtime and when the system enter sleep mode (stand by mode).
> >
> > Cc: Marek Szyprowski
> > Cc: Krzysztof Kozlowski
> > Cc: Chanwoo Choi
> > Signed-off-by: Anand Moon
> > ---
> > Current patch:
> >
> > Note: Both microSD and eMMC suspend resume works this changes at my end.
> >
> > regulator-off-in-suspend:
> > set the regulator node into suspend state i.e. standby mode during suspend
> > operation.
> >
> > Current changes are based on
> > [0]
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/max77686.txt
> >
> > Regulators which can be turned off during system suspend:
> > -LDOn : 2, 6-8, 10-12, 14-16,
> > -BUCKn : 1-4.
> > Use standard regulator bindings for it ('regulator-off-in-suspend').
> >
> > drop the suspend off binding which are not supported by the driver.
> >
> > RFC version
> > [1] https://patchwork.kernel.org/patch/10810909/
> > These changes had some problem with eMMC not entering into suspend mode.
> > with some miss configuration in regulator-off-in-suspend mode.
> >
> > Changes from previos patch.
> > [2] https://patchwork.kernel.org/patch/10712549/
> >
> > Set all the non used regulator in suspend-odd state
> > LD02, LD03, LD05, LD06, LD07, LD011, LD013, LDO14, LD016
> >
> > BUCK5, BUCK6, BUCK7 and not confirable as per driver max77686-regulator
> > ---
> > .../boot/dts/exynos4412-odroid-common.dtsi| 39 +++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > index 08d3a0a7b4eb..375156ad5454 100644
> > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > @@ -288,6 +288,9 @@
> > regulator-min-microvolt = <180>;
> > regulator-max-microvolt = <180>;
> > regulator-always-on;
> > + regulator-state-mem {
> > + regulator-off-in-suspend;
>
> Please maintain proper versioning of patches.
> First patch sent to lists should be either RFC or v1. Second
> release/submission is then always v2. Third v3.
I tried to mixed up some changes that's the reason.
Ok if needed next version will be Patch V3.
>
> This is third or fourth submission but you marked it as v1. This makes
> it very difficult to discuss and reference previous versions.
>
> The commit message did not change since beginning (first version). I
> asked twice that you need to explain exactly why you put the the
> regulator to off or on state in suspend. Why?
> Because:
> 1. This change looks without justification - once you put on, then you
> put off, now again on,
> 2. Anyone reading the code later must know the rationale why this was done,
> 3. I am not quite sure whether this is good setting so I would be
> happy to be convinced.
>
Like I mention in the patch summary that this.
Current changes are based on
[0]
https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/max77686.txt
Regulators which can be turned off during system suspend:
-LDOn : 2, 6-8, 10-12, 14-16,
-BUCKn : 1-4.
Use standard regulator bindings for it ('regulator-off-in-suspend').
> How to provide such explanation? The best in commit message. Sometimes
> in the comment in the code, depends.
Ok I have been testing with following regulator debug prints to catch error.
[0] max77686-regulator.patch
below is the console logs during suspend and resume.
---
Last login: Sat Mar 23 18:22:46 on ttySAC1
[root@archl-u3e ~]# echo no > /sys/module/printk/parameters/console_suspend
[root@archl-u3e ~]# rtcwake -d /dev/rtc0 -m mem -s 10
rtcwake: wakeup from "mem" using /dev/rtc0 at Sat Mar 23 19:56:17 2019
[ 38.595854] PM: suspend entry (deep)
[ 38.596603] PM: Syncing filesystems ... done.
[ 38.629351] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 38.633192] OOM killer disabled.
[ 38.636035] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[ 38.675059] smsc95xx 1-2:1.0 eth0: entering SUSPEND2 mode
[ 38.753120] dwc2 1248.hsotg: suspending usb gadget g_ether
[ 38.754007] dwc2 1248.hsotg: new device is full-speed
[ 38.758960] dwc2 1248.hsotg: dwc2_hsotg_ep_disable: called for ep0
[ 38.765507] dwc2 1248.hsotg: dwc2_hsotg_ep_disable: called for ep0
[ 38.774050] wake enabled for irq 119
[ 38.775761]
Re: [PATCH v2 1/2] arm64: dts: mt8173: correct cpu type of cpu2 and cpu3 to cortex-a72
On Mon, 2019-02-25 at 14:51 +0800, Seiya Wang wrote:
> The cpu type of cpu2 and cpu3 should be cortex-a72, not cortex-a57.
>
> Signed-off-by: Seiya Wang
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 44374c506a1c..99675c51577a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -178,12 +178,12 @@
>
> cpu2: cpu@100 {
> device_type = "cpu";
> - compatible = "arm,cortex-a57";
> + compatible = "arm,cortex-a72";
> reg = <0x100>;
> enable-method = "psci";
> cpu-idle-states = <_SLEEP_0>;
> #cooling-cells = <2>;
> - clocks = < CLK_INFRA_CA57SEL>,
> + clocks = < CLK_INFRA_CA72SEL>,
>< CLK_APMIXED_MAINPLL>;
> clock-names = "cpu", "intermediate";
> operating-points-v2 = <_opp>;
> @@ -191,12 +191,12 @@
>
> cpu3: cpu@101 {
> device_type = "cpu";
> - compatible = "arm,cortex-a57";
> + compatible = "arm,cortex-a72";
> reg = <0x101>;
> enable-method = "psci";
> cpu-idle-states = <_SLEEP_0>;
> #cooling-cells = <2>;
> - clocks = < CLK_INFRA_CA57SEL>,
> + clocks = < CLK_INFRA_CA72SEL>,
>< CLK_APMIXED_MAINPLL>;
> clock-names = "cpu", "intermediate";
> operating-points-v2 = <_opp>;
Since CLK_INFRA_CA72SEL has been added in mt8173-clk.h , please review
this patch. Thanks.
