* [PATCH v2] cpufreq: intel_pstate: Use cpu load based algorithm for PM_MOBILE
From: Srinivas Pandruvada @ 2016-11-14 18:31 UTC (permalink / raw)
To: rjw; +Cc: linux-pm, rdunlap, sfr, arnd, linux-kernel, Srinivas Pandruvada
Use get_target_pstate_use_cpu_load() to calculate target P-State for
devices, which uses preferred power management profile as PM_MOBILE
in ACPI FADT.
This may help in resolving some thermal issues caused by low sustained
cpu bound workloads. The current algorithm tend to over provision in this
case as it doesn't look at the CPU busyness.
Also included the fix from Arnd Bergmann <arnd@arndb.de> to solve compile
issue, when CONFIG_ACPI is not defined.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
v2:
Include fix from Arnd Bergmann for fixing compile issue
drivers/cpufreq/intel_pstate.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index eb76073..9be0720 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1828,6 +1828,19 @@ static void __init copy_pid_params(struct pstate_adjust_policy *policy)
pid_params.setpoint = policy->setpoint;
}
+#ifdef CONFIG_ACPI
+static void intel_pstate_use_acpi_profile(void)
+{
+ if (acpi_gbl_FADT.preferred_profile == PM_MOBILE)
+ pstate_funcs.get_target_pstate =
+ get_target_pstate_use_cpu_load;
+}
+#else
+static void intel_pstate_use_acpi_profile(void)
+{
+}
+#endif
+
static void __init copy_cpu_funcs(struct pstate_funcs *funcs)
{
pstate_funcs.get_max = funcs->get_max;
@@ -1839,6 +1852,7 @@ static void __init copy_cpu_funcs(struct pstate_funcs *funcs)
pstate_funcs.get_vid = funcs->get_vid;
pstate_funcs.get_target_pstate = funcs->get_target_pstate;
+ intel_pstate_use_acpi_profile();
}
#ifdef CONFIG_ACPI
--
2.7.4
^ permalink raw reply related
* [PATCH tip/core/rcu 4/5] rcu: Abstract extended quiescent state determination
From: Paul E. McKenney @ 2016-11-14 18:30 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114183000.GA27133@linux.vnet.ibm.com>
This commit is the fourth step towards full abstraction of all accesses
to the ->dynticks counter, implementing previously open-coded checks and
comparisons in new rcu_dynticks_in_eqs() and rcu_dynticks_in_eqs_since()
functions. This abstraction will ease changes to the ->dynticks counter
operation.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
include/linux/rcutiny.h | 6 ++++++
kernel/rcu/tree.c | 52 +++++++++++++++++++++++++++++++++++-------------
kernel/rcu/tree.h | 2 ++
kernel/rcu/tree_exp.h | 6 +++---
kernel/rcu/tree_plugin.h | 2 +-
kernel/rcu/tree_trace.c | 2 +-
6 files changed, 51 insertions(+), 19 deletions(-)
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index ac81e4063b40..4f9b2fa2173d 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -27,6 +27,12 @@
#include <linux/cache.h>
+struct rcu_dynticks;
+static inline int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
+{
+ return 0;
+}
+
static inline unsigned long get_state_synchronize_rcu(void)
{
return 0;
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 52e844902a43..c2b2f5b591b7 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -338,10 +338,22 @@ static void rcu_dynticks_eqs_online(void)
}
/*
+ * Is the current CPU in an extended quiescent state?
+ *
+ * No ordering, as we are sampling CPU-local information.
+ */
+bool rcu_dynticks_curr_cpu_in_eqs(void)
+{
+ struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+
+ return !(atomic_read(&rdtp->dynticks) & 0x1);
+}
+
+/*
* Snapshot the ->dynticks counter with full ordering so as to allow
* stable comparison of this counter with past and future snapshots.
*/
-static int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
+int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
{
int snap = atomic_add_return(0, &rdtp->dynticks);
@@ -349,6 +361,25 @@ static int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
}
/*
+ * Return true if the snapshot returned from rcu_dynticks_snap()
+ * indicates that RCU is in an extended quiescent state.
+ */
+static bool rcu_dynticks_in_eqs(int snap)
+{
+ return !(snap & 0x1);
+}
+
+/*
+ * Return true if the CPU corresponding to the specified rcu_dynticks
+ * structure has spent some time in an extended quiescent state since
+ * rcu_dynticks_snap() returned the specified snapshot.
+ */
+static bool rcu_dynticks_in_eqs_since(struct rcu_dynticks *rdtp, int snap)
+{
+ return snap != rcu_dynticks_snap(rdtp);
+}
+
+/*
* Do a double-increment of the ->dynticks counter to emulate a
* momentary idle-CPU quiescent state.
*/
@@ -1046,7 +1077,7 @@ void rcu_nmi_enter(void)
* to be in the outermost NMI handler that interrupted an RCU-idle
* period (observation due to Andy Lutomirski).
*/
- if (!(atomic_read(&rdtp->dynticks) & 0x1)) {
+ if (rcu_dynticks_curr_cpu_in_eqs()) {
rcu_dynticks_eqs_exit();
incby = 1;
}
@@ -1072,7 +1103,7 @@ void rcu_nmi_exit(void)
* to us!)
*/
WARN_ON_ONCE(rdtp->dynticks_nmi_nesting <= 0);
- WARN_ON_ONCE(!(atomic_read(&rdtp->dynticks) & 0x1));
+ WARN_ON_ONCE(rcu_dynticks_curr_cpu_in_eqs());
/*
* If the nesting level is not 1, the CPU wasn't RCU-idle, so
@@ -1098,9 +1129,7 @@ void rcu_nmi_exit(void)
*/
bool notrace __rcu_is_watching(void)
{
- struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
-
- return atomic_read(&rdtp->dynticks) & 0x1;
+ return !rcu_dynticks_curr_cpu_in_eqs();
}
/**
@@ -1185,7 +1214,7 @@ static int dyntick_save_progress_counter(struct rcu_data *rdp,
{
rdp->dynticks_snap = rcu_dynticks_snap(rdp->dynticks);
rcu_sysidle_check_cpu(rdp, isidle, maxj);
- if ((rdp->dynticks_snap & 0x1) == 0) {
+ if (rcu_dynticks_in_eqs(rdp->dynticks_snap)) {
trace_rcu_fqs(rdp->rsp->name, rdp->gpnum, rdp->cpu, TPS("dti"));
if (ULONG_CMP_LT(READ_ONCE(rdp->gpnum) + ULONG_MAX / 4,
rdp->mynode->gpnum))
@@ -1204,12 +1233,7 @@ static int dyntick_save_progress_counter(struct rcu_data *rdp,
static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
bool *isidle, unsigned long *maxj)
{
- unsigned int curr;
int *rcrmp;
- unsigned int snap;
-
- curr = (unsigned int)rcu_dynticks_snap(rdp->dynticks);
- snap = (unsigned int)rdp->dynticks_snap;
/*
* If the CPU passed through or entered a dynticks idle phase with
@@ -1219,7 +1243,7 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
* read-side critical section that started before the beginning
* of the current RCU grace period.
*/
- if ((curr & 0x1) == 0 || UINT_CMP_GE(curr, snap + 2)) {
+ if (rcu_dynticks_in_eqs_since(rdp->dynticks, rdp->dynticks_snap)) {
trace_rcu_fqs(rdp->rsp->name, rdp->gpnum, rdp->cpu, TPS("dti"));
rdp->dynticks_fqs++;
return 1;
@@ -3808,7 +3832,7 @@ rcu_boot_init_percpu_data(int cpu, struct rcu_state *rsp)
rdp->grpmask = leaf_node_cpu_bit(rdp->mynode, cpu);
rdp->dynticks = &per_cpu(rcu_dynticks, cpu);
WARN_ON_ONCE(rdp->dynticks->dynticks_nesting != DYNTICK_TASK_EXIT_IDLE);
- WARN_ON_ONCE(atomic_read(&rdp->dynticks->dynticks) != 1);
+ WARN_ON_ONCE(rcu_dynticks_in_eqs(rcu_dynticks_snap(rdp->dynticks)));
rdp->cpu = cpu;
rdp->rsp = rsp;
rcu_boot_init_nocb_percpu_data(rdp);
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index fe98dd24adf8..3b953dcf6afc 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -595,6 +595,8 @@ extern struct rcu_state rcu_bh_state;
extern struct rcu_state rcu_preempt_state;
#endif /* #ifdef CONFIG_PREEMPT_RCU */
+int rcu_dynticks_snap(struct rcu_dynticks *rdtp);
+
#ifdef CONFIG_RCU_BOOST
DECLARE_PER_CPU(unsigned int, rcu_cpu_kthread_status);
DECLARE_PER_CPU(int, rcu_cpu_kthread_cpu);
diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index 75f079ac79f9..a3a8756670d1 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -360,7 +360,7 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
rdp->exp_dynticks_snap =
rcu_dynticks_snap(rdp->dynticks);
if (raw_smp_processor_id() == cpu ||
- !(rdp->exp_dynticks_snap & 0x1) ||
+ rcu_dynticks_in_eqs(rdp->exp_dynticks_snap) ||
!(rnp->qsmaskinitnext & rdp->grpmask))
mask_ofl_test |= rdp->grpmask;
}
@@ -383,8 +383,8 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
if (!(mask_ofl_ipi & mask))
continue;
retry_ipi:
- if (rcu_dynticks_snap(rdp->dynticks) !=
- rdp->exp_dynticks_snap) {
+ if (rcu_dynticks_in_eqs_since(rdp->dynticks,
+ rdp->exp_dynticks_snap)) {
mask_ofl_test |= mask;
continue;
}
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 85c5a883c6e3..98cd997b078e 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1643,7 +1643,7 @@ static void print_cpu_stall_info(struct rcu_state *rsp, int cpu)
"o."[!!(rdp->grpmask & rdp->mynode->qsmaskinit)],
"N."[!!(rdp->grpmask & rdp->mynode->qsmaskinitnext)],
ticks_value, ticks_title,
- atomic_read(&rdtp->dynticks) & 0xfff,
+ rcu_dynticks_snap(rdtp) & 0xfff,
rdtp->dynticks_nesting, rdtp->dynticks_nmi_nesting,
rdp->softirq_snap, kstat_softirqs_cpu(RCU_SOFTIRQ, cpu),
READ_ONCE(rsp->n_force_qs) - rsp->n_force_qs_gpstart,
diff --git a/kernel/rcu/tree_trace.c b/kernel/rcu/tree_trace.c
index b1f28972872c..b833cd0a29e8 100644
--- a/kernel/rcu/tree_trace.c
+++ b/kernel/rcu/tree_trace.c
@@ -124,7 +124,7 @@ static void print_one_rcu_data(struct seq_file *m, struct rcu_data *rdp)
rdp->rcu_qs_ctr_snap == per_cpu(rcu_qs_ctr, rdp->cpu),
rdp->core_needs_qs);
seq_printf(m, " dt=%d/%llx/%d df=%lu",
- atomic_read(&rdp->dynticks->dynticks),
+ rcu_dynticks_snap(rdp->dynticks),
rdp->dynticks->dynticks_nesting,
rdp->dynticks->dynticks_nmi_nesting,
rdp->dynticks_fqs);
--
2.5.2
^ permalink raw reply related
* [PATCH] doc: mention transfer data leaks in more places
From: Matt McCutchen @ 2016-11-14 18:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <1479148088.2406.27.camel@mattmccutchen.net>
The "SECURITY" section of the gitnamespaces(7) man page described two
ways for a client to steal data from a server that wasn't intended to be
shared. Similar attacks can be performed by a server on a client, so
adapt the section to cover both directions and add it to the
git-fetch(1), git-pull(1), and git-push(1) man pages. Also add
references to this section from the documentation of server
configuration options that attempt to control data leakage but may not
be fully effective.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
Documentation/config.txt | 17 ++++++++++++++---
Documentation/git-fetch.txt | 2 ++
Documentation/git-pull.txt | 2 ++
Documentation/git-push.txt | 2 ++
Documentation/gitnamespaces.txt | 20 +-------------------
Documentation/transfer-data-leaks.txt | 30 ++++++++++++++++++++++++++++++
6 files changed, 51 insertions(+), 22 deletions(-)
create mode 100644 Documentation/transfer-data-leaks.txt
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 21fdddf..fc2cf83 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2898,6 +2898,11 @@ is omitted from the advertisements but `refs/heads/master` and
`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
"have" lines. In order to match refs before stripping, add a `^` in front of
the ref name. If you combine `!` and `^`, `!` must be specified first.
++
+Even if you hide refs, a client may still be able to steal the target
+objects via the techniques described in the "SECURITY" section of the
+linkgit:gitnamespaces[7] man page; it's best to keep private data in a
+separate repository.
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
@@ -2907,7 +2912,7 @@ transfer.unpackLimit::
uploadarchive.allowUnreachable::
If true, allow clients to use `git archive --remote` to request
any tree, whether reachable from the ref tips or not. See the
- discussion in the `SECURITY` section of
+ discussion in the "SECURITY" section of
linkgit:git-upload-archive[1] for more details. Defaults to
`false`.
@@ -2921,13 +2926,19 @@ uploadpack.allowTipSHA1InWant::
When `uploadpack.hideRefs` is in effect, allow `upload-pack`
to accept a fetch request that asks for an object at the tip
of a hidden ref (by default, such a request is rejected).
- see also `uploadpack.hideRefs`.
+ See also `uploadpack.hideRefs`. Even if this is false, a client
+ may be able to steal objects via the techniques described in the
+ "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
+ best to keep private data in a separate repository.
uploadpack.allowReachableSHA1InWant::
Allow `upload-pack` to accept a fetch request that asks for an
object that is reachable from any ref tip. However, note that
calculating object reachability is computationally expensive.
- Defaults to `false`.
+ Defaults to `false`. Even if this is false, a client may be able
+ to steal objects via the techniques described in the "SECURITY"
+ section of the linkgit:gitnamespaces[7] man page; it's best to
+ keep private data in a separate repository.
uploadpack.keepAlive::
When `upload-pack` has started `pack-objects`, there may be a
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 9e42169..b153aef 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -192,6 +192,8 @@ The first command fetches the `maint` branch from the repository at
objects will eventually be removed by git's built-in housekeeping (see
linkgit:git-gc[1]).
+include::transfer-data-leaks.txt[]
+
BUGS
----
Using --recurse-submodules can only fetch new commits in already checked
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index d033b25..4470e4b 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -237,6 +237,8 @@ If you tried a pull which resulted in complex conflicts and
would want to start over, you can recover with 'git reset'.
+include::transfer-data-leaks.txt[]
+
BUGS
----
Using --recurse-submodules can only fetch new commits in already checked
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 47b77e6..8eefabd 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -559,6 +559,8 @@ Commits A and B would no longer belong to a branch with a symbolic name,
and so would be unreachable. As such, these commits would be removed by
a `git gc` command on the origin repository.
+include::transfer-data-leaks.txt[]
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/Documentation/gitnamespaces.txt b/Documentation/gitnamespaces.txt
index 7685e36..b614969 100644
--- a/Documentation/gitnamespaces.txt
+++ b/Documentation/gitnamespaces.txt
@@ -61,22 +61,4 @@ For a simple local test, you can use linkgit:git-remote-ext[1]:
git clone ext::'git --namespace=foo %s /tmp/prefixed.git'
----------
-SECURITY
---------
-
-Anyone with access to any namespace within a repository can potentially
-access objects from any other namespace stored in the same repository.
-You can't directly say "give me object ABCD" if you don't have a ref to
-it, but you can do some other sneaky things like:
-
-. Claiming to push ABCD, at which point the server will optimize out the
- need for you to actually send it. Now you have a ref to ABCD and can
- fetch it (claiming not to have it, of course).
-
-. Requesting other refs, claiming that you have ABCD, at which point the
- server may generate deltas against ABCD.
-
-None of this causes a problem if you only host public repositories, or
-if everyone who may read one namespace may also read everything in every
-other namespace (for instance, if everyone in an organization has read
-permission to every repository).
+include::transfer-data-leaks.txt[]
diff --git a/Documentation/transfer-data-leaks.txt b/Documentation/transfer-data-leaks.txt
new file mode 100644
index 0000000..914bacc
--- /dev/null
+++ b/Documentation/transfer-data-leaks.txt
@@ -0,0 +1,30 @@
+SECURITY
+--------
+The fetch and push protocols are not designed to prevent one side from
+stealing data from the other repository that was not intended to be
+shared. If you have private data that you need to protect from a malicious
+peer, your best option is to store it in another repository. This applies
+to both clients and servers. In particular, namespaces on a server are not
+effective for read access control; you should only grant read access to a
+namespace to clients that you would trust with read access to the entire
+repository.
+
+The known attack vectors are as follows:
+
+. The victim sends "have" lines advertising the IDs of objects it has that
+ are not explicitly intended to be shared but can be used to optimize the
+ transfer if the peer also has them. The attacker chooses an object ID X
+ to steal and sends a ref to X, but isn't required to send the content of
+ X because the victim already has it. Now the victim believes that the
+ attacker has X, and it sends the content of X back to the attacker
+ later. (This attack is most straightforward for a client to perform on a
+ server, by creating a ref to X in the namespace the client has access
+ to and then fetching it. The most likely way for a server to perform it
+ on a client is to "merge" X into a public branch and hope that the user
+ does additional work on this branch and pushes it back to the server
+ without noticing the merge.)
+
+. As in #1, the attacker chooses an object ID X to steal. The victim sends
+ an object Y that the attacker already has, and the attacker falsely
+ claims to have X and not Y, so the victim sends Y as a delta against X.
+ The delta reveals regions of X that are similar to Y to the attacker.
--
2.7.4
^ permalink raw reply related
* RE: [PATCH] libselinux: fix subdir build and usage of cmdline CFLAGS
From: Roberts, William C @ 2016-11-14 18:31 UTC (permalink / raw)
To: Stephen Smalley, selinux@tycho.nsa.gov
In-Reply-To: <1479147126-11727-1-git-send-email-sds@tycho.nsa.gov>
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Monday, November 14, 2016 10:12 AM
> To: selinux@tycho.nsa.gov
> Cc: Roberts, William C <william.c.roberts@intel.com>; Stephen Smalley
> <sds@tycho.nsa.gov>
> Subject: [PATCH] libselinux: fix subdir build and usage of cmdline CFLAGS
>
> commit 16c123f4b1f3c8d20b3f597df161d7e635620923 ("libselinux:
> support ANDROID_HOST=1 on Mac") broke the ability to run make in the src
> subdirectory of libselinux (because OS and COMPILER were not defined) and also
> caused some warning flags that could be overridden via command-line CFLAGS to
> be mandatory. Fix it.
Ack.
It would be nice if we could avoid the duplication running repent throughout these make files,
maybe include a file that has the definitions/callable functions for all of this stuff?
>
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> libselinux/src/Makefile | 12 ++++++++++--
> libselinux/utils/Makefile | 10 +++++++++-
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile index
> 24946ce..76efe49 100644
> --- a/libselinux/src/Makefile
> +++ b/libselinux/src/Makefile
> @@ -23,6 +23,14 @@ LIBSEPOLA ?= $(LIBDIR)/libsepol.a VERSION = $(shell cat
> ../VERSION) LIBVERSION = 1
>
> +OS ?= $(shell uname)
> +
> +ifeq ($(shell $(CC) -v 2>&1 | grep "clang"),) COMPILER ?= gcc else
> +COMPILER ?= clang endif
> +
> LIBA=libselinux.a
> TARGET=libselinux.so
> LIBPC=libselinux.pc
> @@ -67,12 +75,12 @@ CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k -Wformat-
> security -Winit-self -Wmissi LD_SONAME_FLAGS=-soname,$(LIBSO),-z,defs,-
> z,relro
>
> ifeq ($(COMPILER), gcc)
> -override CFLAGS += -fipa-pure-const -Wlogical-op -Wpacked-bitfield-compat -
> Wsync-nand \
> +CFLAGS += -fipa-pure-const -Wlogical-op -Wpacked-bitfield-compat
> +-Wsync-nand \
> -Wcoverage-mismatch -Wcpp -Wformat-contains-nul -Wnormalized=nfc -
> Wsuggest-attribute=const \
> -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines
> -Wjump-misses-init \
> -Wno-suggest-attribute=pure -Wno-suggest-attribute=const -Wp,-
> D_FORTIFY_SOURCE=2 else -override CFLAGS += -Wunused-command-line-
> argument
> +CFLAGS += -Wunused-command-line-argument
> endif
>
> ifeq ($(OS), Darwin)
> diff --git a/libselinux/utils/Makefile b/libselinux/utils/Makefile index
> a4f9903..7744184 100644
> --- a/libselinux/utils/Makefile
> +++ b/libselinux/utils/Makefile
> @@ -5,6 +5,14 @@ USRBINDIR ?= $(PREFIX)/sbin SBINDIR ?= $(DESTDIR)/sbin
> INCLUDEDIR ?= $(PREFIX)/include
>
> +OS ?= $(shell uname)
> +
> +ifeq ($(shell $(CC) -v 2>&1 | grep "clang"),) COMPILER ?= gcc else
> +COMPILER ?= clang endif
> +
> MAX_STACK_SIZE=8192
> CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k -Wformat-security -Winit-self -
> Wmissing-include-dirs \
> -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow -Wpointer-
> arith \ @@ -26,7 +34,7 @@ CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k -
> Wformat-security -Winit-self -Wmissi LD_SONAME_FLAGS=-soname,$(LIBSO),-
> z,defs,-z,relro
>
> ifeq ($(COMPILER), gcc)
> -override CFLAGS += -fipa-pure-const -Wpacked-bitfield-compat -Wsync-nand -
> Wcoverage-mismatch \
> +CFLAGS += -fipa-pure-const -Wpacked-bitfield-compat -Wsync-nand
> +-Wcoverage-mismatch \
> -Wcpp -Wformat-contains-nul -Wnormalized=nfc -Wsuggest-
> attribute=const \
> -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines
> -Wjump-misses-init \
> -Wno-suggest-attribute=pure -Wno-suggest-attribute=const
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH] ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes
From: Kevin Hilman @ 2016-11-14 18:31 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
carlo-KA+7E9HrN00dnm+yROfE0A, afaerber-l3A5Bk7waGM,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161112130719.24995-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
> All boards from the Tronsmart Vega S95 series are sharing similar MMC
> based hardware.
> sd_emmc_a is used to connect a Broadcom based SDIO wifi card (supported
> by the brcmfmac driver). The 32.768KHz LPO clock for the wifi chip is
> generated by PWM_E.
> sd_emmc_b is routed to the SD-card. Unlike p20x there is no GPIO
> regulator, meaning it only supports 3.3V (which seems to be hard-wired).
> The eMMC chip is connected to sd_emmc_c and is implemented similar to
> the meson-gxbb-p20x boards (meaning that hard-wired fixed regulators
> are used).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Applied to v4.10/dt64.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes
From: Kevin Hilman @ 2016-11-14 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112130719.24995-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> All boards from the Tronsmart Vega S95 series are sharing similar MMC
> based hardware.
> sd_emmc_a is used to connect a Broadcom based SDIO wifi card (supported
> by the brcmfmac driver). The 32.768KHz LPO clock for the wifi chip is
> generated by PWM_E.
> sd_emmc_b is routed to the SD-card. Unlike p20x there is no GPIO
> regulator, meaning it only supports 3.3V (which seems to be hard-wired).
> The eMMC chip is connected to sd_emmc_c and is implemented similar to
> the meson-gxbb-p20x boards (meaning that hard-wired fixed regulators
> are used).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Applied to v4.10/dt64.
Kevin
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes
From: Kevin Hilman @ 2016-11-14 18:31 UTC (permalink / raw)
To: linus-amlogic
In-Reply-To: <20161112130719.24995-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> All boards from the Tronsmart Vega S95 series are sharing similar MMC
> based hardware.
> sd_emmc_a is used to connect a Broadcom based SDIO wifi card (supported
> by the brcmfmac driver). The 32.768KHz LPO clock for the wifi chip is
> generated by PWM_E.
> sd_emmc_b is routed to the SD-card. Unlike p20x there is no GPIO
> regulator, meaning it only supports 3.3V (which seems to be hard-wired).
> The eMMC chip is connected to sd_emmc_c and is implemented similar to
> the meson-gxbb-p20x boards (meaning that hard-wired fixed regulators
> are used).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Applied to v4.10/dt64.
Kevin
^ permalink raw reply
* [PATCH tip/core/rcu 1/5] rcu: Abstract the dynticks momentary-idle operation
From: Paul E. McKenney @ 2016-11-14 18:30 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114183000.GA27133@linux.vnet.ibm.com>
This commit is the first step towards full abstraction of all accesses to
the ->dynticks counter, implementing the previously open-coded atomic add
of two in a new rcu_dynticks_momentary_idle() function. This abstraction
will ease changes to the ->dynticks counter operation.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
kernel/rcu/tree.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 96c52e43f7ca..73b2b1da912d 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -278,6 +278,19 @@ static DEFINE_PER_CPU(struct rcu_dynticks, rcu_dynticks) = {
#endif /* #ifdef CONFIG_NO_HZ_FULL_SYSIDLE */
};
+/*
+ * Do a double-increment of the ->dynticks counter to emulate a
+ * momentary idle-CPU quiescent state.
+ */
+static void rcu_dynticks_momentary_idle(void)
+{
+ struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+ int special = atomic_add_return(2, &rdtp->dynticks);
+
+ /* It is illegal to call this from idle state. */
+ WARN_ON_ONCE(!(special & 0x1));
+}
+
DEFINE_PER_CPU_SHARED_ALIGNED(unsigned long, rcu_qs_ctr);
EXPORT_PER_CPU_SYMBOL_GPL(rcu_qs_ctr);
@@ -297,7 +310,6 @@ EXPORT_PER_CPU_SYMBOL_GPL(rcu_qs_ctr);
static void rcu_momentary_dyntick_idle(void)
{
struct rcu_data *rdp;
- struct rcu_dynticks *rdtp;
int resched_mask;
struct rcu_state *rsp;
@@ -324,10 +336,7 @@ static void rcu_momentary_dyntick_idle(void)
* quiescent state, with no need for this CPU to do anything
* further.
*/
- rdtp = this_cpu_ptr(&rcu_dynticks);
- smp_mb__before_atomic(); /* Earlier stuff before QS. */
- atomic_add(2, &rdtp->dynticks); /* QS. */
- smp_mb__after_atomic(); /* Later stuff after QS. */
+ rcu_dynticks_momentary_idle();
break;
}
}
--
2.5.2
^ permalink raw reply related
* [PATCH tip/core/rcu 3/5] rcu: Abstract dynticks extended quiescent state enter/exit operations
From: Paul E. McKenney @ 2016-11-14 18:30 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114183000.GA27133@linux.vnet.ibm.com>
This commit is the third step towards full abstraction of all accesses
to the ->dynticks counter, implementing the previously open-coded atomic
add of 1 and entry checks in a new rcu_dynticks_eqs_enter() function, and
the same but with exit checks in a new rcu_dynticks_eqs_exit() function.
This abstraction will ease changes to the ->dynticks counter operation.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
kernel/rcu/tree.c | 92 +++++++++++++++++++++++++++++++++++++++----------------
1 file changed, 66 insertions(+), 26 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 9bc60b29ea5c..52e844902a43 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -279,6 +279,65 @@ static DEFINE_PER_CPU(struct rcu_dynticks, rcu_dynticks) = {
};
/*
+ * Record entry into an extended quiescent state. This is only to be
+ * called when not already in an extended quiescent state.
+ */
+static void rcu_dynticks_eqs_enter(void)
+{
+ struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+
+ /*
+ * CPUs seeing atomic_inc() must see prior RCU read-side critical
+ * sections, and we also must force ordering with the next idle
+ * sojourn.
+ */
+ smp_mb__before_atomic(); /* See above. */
+ atomic_inc(&rdtp->dynticks);
+ smp_mb__after_atomic(); /* See above. */
+ WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
+ atomic_read(&rdtp->dynticks) & 0x1);
+}
+
+/*
+ * Record exit from an extended quiescent state. This is only to be
+ * called from an extended quiescent state.
+ */
+static void rcu_dynticks_eqs_exit(void)
+{
+ struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+
+ /*
+ * CPUs seeing atomic_inc() must see prior idle sojourns,
+ * and we also must force ordering with the next RCU read-side
+ * critical section.
+ */
+ smp_mb__before_atomic(); /* See above. */
+ atomic_inc(&rdtp->dynticks);
+ smp_mb__after_atomic(); /* See above. */
+ WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
+ !(atomic_read(&rdtp->dynticks) & 0x1));
+}
+
+/*
+ * Reset the current CPU's ->dynticks counter to indicate that the
+ * newly onlined CPU is no longer in an extended quiescent state.
+ * This will either leave the counter unchanged, or increment it
+ * to the next non-quiescent value.
+ *
+ * The non-atomic test/increment sequence works because the upper bits
+ * of the ->dynticks counter are manipulated only by the corresponding CPU,
+ * or when the corresponding CPU is offline.
+ */
+static void rcu_dynticks_eqs_online(void)
+{
+ struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+
+ if (atomic_read(&rdtp->dynticks) & 0x1)
+ return;
+ atomic_add(0x1, &rdtp->dynticks);
+}
+
+/*
* Snapshot the ->dynticks counter with full ordering so as to allow
* stable comparison of this counter with past and future snapshots.
*/
@@ -690,7 +749,7 @@ static void rcu_eqs_enter_common(long long oldval, bool user)
{
struct rcu_state *rsp;
struct rcu_data *rdp;
- struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+ struct rcu_dynticks __maybe_unused *rdtp = this_cpu_ptr(&rcu_dynticks);
trace_rcu_dyntick(TPS("Start"), oldval, rdtp->dynticks_nesting);
if (IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
@@ -709,12 +768,7 @@ static void rcu_eqs_enter_common(long long oldval, bool user)
do_nocb_deferred_wakeup(rdp);
}
rcu_prepare_for_idle();
- /* CPUs seeing atomic_inc() must see prior RCU read-side crit sects */
- smp_mb__before_atomic(); /* See above. */
- atomic_inc(&rdtp->dynticks);
- smp_mb__after_atomic(); /* Force ordering with next sojourn. */
- WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
- atomic_read(&rdtp->dynticks) & 0x1);
+ rcu_dynticks_eqs_enter();
rcu_dynticks_task_enter();
/*
@@ -843,15 +897,10 @@ void rcu_irq_exit_irqson(void)
*/
static void rcu_eqs_exit_common(long long oldval, int user)
{
- struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+ struct rcu_dynticks __maybe_unused *rdtp = this_cpu_ptr(&rcu_dynticks);
rcu_dynticks_task_exit();
- smp_mb__before_atomic(); /* Force ordering w/previous sojourn. */
- atomic_inc(&rdtp->dynticks);
- /* CPUs seeing atomic_inc() must see later RCU read-side crit sects */
- smp_mb__after_atomic(); /* See above. */
- WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
- !(atomic_read(&rdtp->dynticks) & 0x1));
+ rcu_dynticks_eqs_exit();
rcu_cleanup_after_idle();
trace_rcu_dyntick(TPS("End"), oldval, rdtp->dynticks_nesting);
if (IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
@@ -998,11 +1047,7 @@ void rcu_nmi_enter(void)
* period (observation due to Andy Lutomirski).
*/
if (!(atomic_read(&rdtp->dynticks) & 0x1)) {
- smp_mb__before_atomic(); /* Force delay from prior write. */
- atomic_inc(&rdtp->dynticks);
- /* atomic_inc() before later RCU read-side crit sects */
- smp_mb__after_atomic(); /* See above. */
- WARN_ON_ONCE(!(atomic_read(&rdtp->dynticks) & 0x1));
+ rcu_dynticks_eqs_exit();
incby = 1;
}
rdtp->dynticks_nmi_nesting += incby;
@@ -1040,11 +1085,7 @@ void rcu_nmi_exit(void)
/* This NMI interrupted an RCU-idle CPU, restore RCU-idleness. */
rdtp->dynticks_nmi_nesting = 0;
- /* CPUs seeing atomic_inc() must see prior RCU read-side crit sects */
- smp_mb__before_atomic(); /* See above. */
- atomic_inc(&rdtp->dynticks);
- smp_mb__after_atomic(); /* Force delay to next write. */
- WARN_ON_ONCE(atomic_read(&rdtp->dynticks) & 0x1);
+ rcu_dynticks_eqs_enter();
}
/**
@@ -3797,8 +3838,7 @@ rcu_init_percpu_data(int cpu, struct rcu_state *rsp)
init_callback_list(rdp); /* Re-enable callbacks on this CPU. */
rdp->dynticks->dynticks_nesting = DYNTICK_TASK_EXIT_IDLE;
rcu_sysidle_init_percpu_data(rdp->dynticks);
- atomic_set(&rdp->dynticks->dynticks,
- (atomic_read(&rdp->dynticks->dynticks) & ~0x1) + 1);
+ rcu_dynticks_eqs_online();
raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */
/*
--
2.5.2
^ permalink raw reply related
* [PATCH v6] media: et8ek8: add device tree binding documentation
From: Pavel Machek @ 2016-11-14 18:30 UTC (permalink / raw)
To: Rob Herring
Cc: ivo.g.dimitrov.75, sakari.ailus, sre, pali.rohar, linux-media,
pawel.moll, mark.rutland, ijc+devicetree, galak, mchehab,
devicetree, linux-kernel
In-Reply-To: <20161107104648.GB5326@amd>
[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]
Add device tree binding documentation for toshiba et8ek8 sensor.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
---
v6: added missing article, fixed signal polarity.
diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
new file mode 100644
index 0000000..b03b21d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
@@ -0,0 +1,53 @@
+Toshiba et8ek8 5MP sensor
+
+Toshiba et8ek8 5MP sensor is an image sensor found in Nokia N900 device
+
+More detailed documentation can be found in
+Documentation/devicetree/bindings/media/video-interfaces.txt .
+
+
+Mandatory properties
+--------------------
+
+- compatible: "toshiba,et8ek8"
+- reg: I2C address (0x3e, or an alternative address)
+- vana-supply: Analogue voltage supply (VANA), 2.8 volts
+- clocks: External clock to the sensor
+- clock-frequency: Frequency of the external clock to the sensor. Camera
+ driver will set this frequency on the external clock. The clock frequency is
+ a pre-determined frequency known to be suitable to the board.
+- reset-gpios: XSHUTDOWN GPIO. The XSHUTDOWN signal is active low. The sensor
+ is in hardware standby mode when the signal is in the low state.
+
+
+Endpoint node mandatory properties
+----------------------------------
+
+- remote-endpoint: A phandle to the bus receiver's endpoint node.
+
+Endpoint node optional properties
+----------------------------------
+
+- clock-lanes: <0>
+- data-lanes: <1..n>
+
+Example
+-------
+
+&i2c3 {
+ clock-frequency = <400000>;
+
+ cam1: camera@3e {
+ compatible = "toshiba,et8ek8";
+ reg = <0x3e>;
+ vana-supply = <&vaux4>;
+ clocks = <&isp 0>;
+ clock-frequency = <9600000>;
+ reset-gpio = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102 */
+ port {
+ csi_cam1: endpoint {
+ remote-endpoint = <&csi_out1>;
+ };
+ };
+ };
+};
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* [PATCH tip/core/rcu 2/5] rcu: Abstract the dynticks snapshot operation
From: Paul E. McKenney @ 2016-11-14 18:30 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114183000.GA27133@linux.vnet.ibm.com>
This commit is the second step towards full abstraction of all accesses to
the ->dynticks counter, implementing the previously open-coded atomic
add of zero in a new rcu_dynticks_snap() function. This abstraction will
ease changes o the ->dynticks counter operation.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
kernel/rcu/tree.c | 19 ++++++++++++++++---
kernel/rcu/tree_exp.h | 6 ++----
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 73b2b1da912d..9bc60b29ea5c 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -279,6 +279,17 @@ static DEFINE_PER_CPU(struct rcu_dynticks, rcu_dynticks) = {
};
/*
+ * Snapshot the ->dynticks counter with full ordering so as to allow
+ * stable comparison of this counter with past and future snapshots.
+ */
+static int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
+{
+ int snap = atomic_add_return(0, &rdtp->dynticks);
+
+ return snap;
+}
+
+/*
* Do a double-increment of the ->dynticks counter to emulate a
* momentary idle-CPU quiescent state.
*/
@@ -1046,7 +1057,9 @@ void rcu_nmi_exit(void)
*/
bool notrace __rcu_is_watching(void)
{
- return atomic_read(this_cpu_ptr(&rcu_dynticks.dynticks)) & 0x1;
+ struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+
+ return atomic_read(&rdtp->dynticks) & 0x1;
}
/**
@@ -1129,7 +1142,7 @@ static int rcu_is_cpu_rrupt_from_idle(void)
static int dyntick_save_progress_counter(struct rcu_data *rdp,
bool *isidle, unsigned long *maxj)
{
- rdp->dynticks_snap = atomic_add_return(0, &rdp->dynticks->dynticks);
+ rdp->dynticks_snap = rcu_dynticks_snap(rdp->dynticks);
rcu_sysidle_check_cpu(rdp, isidle, maxj);
if ((rdp->dynticks_snap & 0x1) == 0) {
trace_rcu_fqs(rdp->rsp->name, rdp->gpnum, rdp->cpu, TPS("dti"));
@@ -1154,7 +1167,7 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
int *rcrmp;
unsigned int snap;
- curr = (unsigned int)atomic_add_return(0, &rdp->dynticks->dynticks);
+ curr = (unsigned int)rcu_dynticks_snap(rdp->dynticks);
snap = (unsigned int)rdp->dynticks_snap;
/*
diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index d3053e99fdb6..75f079ac79f9 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -356,10 +356,9 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
mask_ofl_test = 0;
for_each_leaf_node_possible_cpu(rnp, cpu) {
struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
- struct rcu_dynticks *rdtp = &per_cpu(rcu_dynticks, cpu);
rdp->exp_dynticks_snap =
- atomic_add_return(0, &rdtp->dynticks);
+ rcu_dynticks_snap(rdp->dynticks);
if (raw_smp_processor_id() == cpu ||
!(rdp->exp_dynticks_snap & 0x1) ||
!(rnp->qsmaskinitnext & rdp->grpmask))
@@ -380,12 +379,11 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
for_each_leaf_node_possible_cpu(rnp, cpu) {
unsigned long mask = leaf_node_cpu_bit(rnp, cpu);
struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
- struct rcu_dynticks *rdtp = &per_cpu(rcu_dynticks, cpu);
if (!(mask_ofl_ipi & mask))
continue;
retry_ipi:
- if (atomic_add_return(0, &rdtp->dynticks) !=
+ if (rcu_dynticks_snap(rdp->dynticks) !=
rdp->exp_dynticks_snap) {
mask_ofl_test |= mask;
continue;
--
2.5.2
^ permalink raw reply related
* [PATCH tip/core/rcu 5/5] rcu: Maintain special bits at bottom of ->dynticks counter
From: Paul E. McKenney @ 2016-11-14 18:30 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114183000.GA27133@linux.vnet.ibm.com>
Currently, IPIs are used to force other CPUs to invalidate their TLBs
in response to a kernel virtual-memory mapping change. This works, but
degrades both battery lifetime (for idle CPUs) and real-time response
(for nohz_full CPUs), and in addition results in unnecessary IPIs due to
the fact that CPUs executing in usermode are unaffected by stale kernel
mappings. It would be better to cause a CPU executing in usermode to
wait until it is entering kernel mode to do the flush, first to avoid
interrupting usemode tasks and second to handle multiple flush requests
with a single flush in the case of a long-running user task.
This commit therefore reserves a bit at the bottom of the ->dynticks
counter, which is checked upon exit from extended quiescent states.
If it is set, it is cleared and then a new rcu_eqs_special_exit() macro is
invoked, which, if not supplied, is an empty single-pass do-while loop.
If this bottom bit is set on -entry- to an extended quiescent state,
then a WARN_ON_ONCE() triggers.
This bottom bit may be set using a new rcu_eqs_special_set() function,
which returns true if the bit was set, or false if the CPU turned
out to not be in an extended quiescent state. Please note that this
function refuses to set the bit for a non-nohz_full CPU when that CPU
is executing in usermode because usermode execution is tracked by RCU
as a dyntick-idle extended quiescent state only for nohz_full CPUs.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
include/linux/rcutiny.h | 5 +++
kernel/rcu/tree.c | 81 +++++++++++++++++++++++++++++++++++++------------
kernel/rcu/tree.h | 1 +
3 files changed, 67 insertions(+), 20 deletions(-)
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index 4f9b2fa2173d..7232d199a81c 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -33,6 +33,11 @@ static inline int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
return 0;
}
+static inline bool rcu_eqs_special_set(int cpu)
+{
+ return false; /* Never flag non-existent other CPUs! */
+}
+
static inline unsigned long get_state_synchronize_rcu(void)
{
return 0;
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index c2b2f5b591b7..2c399db6df6e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -269,9 +269,19 @@ void rcu_bh_qs(void)
static DEFINE_PER_CPU(int, rcu_sched_qs_mask);
+/*
+ * Steal a bit from the bottom of ->dynticks for idle entry/exit
+ * control. Initially this is for TLB flushing.
+ */
+#define RCU_DYNTICK_CTRL_MASK 0x1
+#define RCU_DYNTICK_CTRL_CTR (RCU_DYNTICK_CTRL_MASK + 1)
+#ifndef rcu_eqs_special_exit
+#define rcu_eqs_special_exit() do { } while (0)
+#endif
+
static DEFINE_PER_CPU(struct rcu_dynticks, rcu_dynticks) = {
.dynticks_nesting = DYNTICK_TASK_EXIT_IDLE,
- .dynticks = ATOMIC_INIT(1),
+ .dynticks = ATOMIC_INIT(RCU_DYNTICK_CTRL_CTR),
#ifdef CONFIG_NO_HZ_FULL_SYSIDLE
.dynticks_idle_nesting = DYNTICK_TASK_NEST_VALUE,
.dynticks_idle = ATOMIC_INIT(1),
@@ -285,17 +295,20 @@ static DEFINE_PER_CPU(struct rcu_dynticks, rcu_dynticks) = {
static void rcu_dynticks_eqs_enter(void)
{
struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+ int seq;
/*
- * CPUs seeing atomic_inc() must see prior RCU read-side critical
- * sections, and we also must force ordering with the next idle
- * sojourn.
+ * CPUs seeing atomic_inc_return() must see prior RCU read-side
+ * critical sections, and we also must force ordering with the
+ * next idle sojourn.
*/
- smp_mb__before_atomic(); /* See above. */
- atomic_inc(&rdtp->dynticks);
- smp_mb__after_atomic(); /* See above. */
+ seq = atomic_add_return(RCU_DYNTICK_CTRL_CTR, &rdtp->dynticks);
+ /* Better be in an extended quiescent state! */
+ WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
+ (seq & RCU_DYNTICK_CTRL_CTR));
+ /* Better not have special action (TLB flush) pending! */
WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
- atomic_read(&rdtp->dynticks) & 0x1);
+ (seq & RCU_DYNTICK_CTRL_MASK));
}
/*
@@ -305,17 +318,22 @@ static void rcu_dynticks_eqs_enter(void)
static void rcu_dynticks_eqs_exit(void)
{
struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
+ int seq;
/*
- * CPUs seeing atomic_inc() must see prior idle sojourns,
+ * CPUs seeing atomic_inc_return() must see prior idle sojourns,
* and we also must force ordering with the next RCU read-side
* critical section.
*/
- smp_mb__before_atomic(); /* See above. */
- atomic_inc(&rdtp->dynticks);
- smp_mb__after_atomic(); /* See above. */
+ seq = atomic_add_return(RCU_DYNTICK_CTRL_CTR, &rdtp->dynticks);
WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
- !(atomic_read(&rdtp->dynticks) & 0x1));
+ !(seq & RCU_DYNTICK_CTRL_CTR));
+ if (seq & RCU_DYNTICK_CTRL_MASK) {
+ rcu_eqs_special_exit();
+ /* Prefer duplicate flushes to losing a flush. */
+ smp_mb__before_atomic(); /* NMI safety. */
+ atomic_and(~RCU_DYNTICK_CTRL_MASK, &rdtp->dynticks);
+ }
}
/*
@@ -332,9 +350,9 @@ static void rcu_dynticks_eqs_online(void)
{
struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
- if (atomic_read(&rdtp->dynticks) & 0x1)
+ if (atomic_read(&rdtp->dynticks) & RCU_DYNTICK_CTRL_CTR)
return;
- atomic_add(0x1, &rdtp->dynticks);
+ atomic_add(RCU_DYNTICK_CTRL_CTR, &rdtp->dynticks);
}
/*
@@ -346,7 +364,7 @@ bool rcu_dynticks_curr_cpu_in_eqs(void)
{
struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
- return !(atomic_read(&rdtp->dynticks) & 0x1);
+ return !(atomic_read(&rdtp->dynticks) & RCU_DYNTICK_CTRL_CTR);
}
/*
@@ -357,7 +375,7 @@ int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
{
int snap = atomic_add_return(0, &rdtp->dynticks);
- return snap;
+ return snap & ~RCU_DYNTICK_CTRL_MASK;
}
/*
@@ -366,7 +384,7 @@ int rcu_dynticks_snap(struct rcu_dynticks *rdtp)
*/
static bool rcu_dynticks_in_eqs(int snap)
{
- return !(snap & 0x1);
+ return !(snap & RCU_DYNTICK_CTRL_CTR);
}
/*
@@ -386,10 +404,33 @@ static bool rcu_dynticks_in_eqs_since(struct rcu_dynticks *rdtp, int snap)
static void rcu_dynticks_momentary_idle(void)
{
struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
- int special = atomic_add_return(2, &rdtp->dynticks);
+ int special = atomic_add_return(2 * RCU_DYNTICK_CTRL_CTR,
+ &rdtp->dynticks);
/* It is illegal to call this from idle state. */
- WARN_ON_ONCE(!(special & 0x1));
+ WARN_ON_ONCE(!(special & RCU_DYNTICK_CTRL_CTR));
+}
+
+/*
+ * Set the special (bottom) bit of the specified CPU so that it
+ * will take special action (such as flushing its TLB) on the
+ * next exit from an extended quiescent state. Returns true if
+ * the bit was successfully set, or false if the CPU was not in
+ * an extended quiescent state.
+ */
+bool rcu_eqs_special_set(int cpu)
+{
+ int old;
+ int new;
+ struct rcu_dynticks *rdtp = &per_cpu(rcu_dynticks, cpu);
+
+ do {
+ old = atomic_read(&rdtp->dynticks);
+ if (old & RCU_DYNTICK_CTRL_CTR)
+ return false;
+ new = old | RCU_DYNTICK_CTRL_MASK;
+ } while (atomic_cmpxchg(&rdtp->dynticks, old, new) != old);
+ return true;
}
DEFINE_PER_CPU_SHARED_ALIGNED(unsigned long, rcu_qs_ctr);
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 3b953dcf6afc..7dcdd59d894c 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -596,6 +596,7 @@ extern struct rcu_state rcu_preempt_state;
#endif /* #ifdef CONFIG_PREEMPT_RCU */
int rcu_dynticks_snap(struct rcu_dynticks *rdtp);
+bool rcu_eqs_special_set(int cpu);
#ifdef CONFIG_RCU_BOOST
DECLARE_PER_CPU(unsigned int, rcu_cpu_kthread_status);
--
2.5.2
^ permalink raw reply related
* Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Hannes Frederic Sowa @ 2016-11-14 18:33 UTC (permalink / raw)
To: David Ahern, Jason A. Donenfeld, Netdev, WireGuard mailing list,
LKML, YOSHIFUJI Hideaki
In-Reply-To: <0214eaf8-70c6-5a37-cddd-faa1c4268871@cumulusnetworks.com>
On Mon, Nov 14, 2016, at 18:48, David Ahern wrote:
> On 11/14/16 10:33 AM, Hannes Frederic Sowa wrote:
> >>>>> I just also quickly read up on the history (sorry was travelling last
> >>>>> week) and wonder if you ever saw a user space facing bug or if this is
> >>>>> basically some difference you saw while writing out of tree code?
> >>>>
> >>>> I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
> >>>
> >>> Hmm, so it fixes no real bug.
> >>>
> >>> Because of translations of flowi6_oif we actually can't do a correct
> >>> check of source address for cases like the one I outlined above? Hmm,
> >>> maybe we should simply depend on user space checks.
> >>
> >> I believe Jason's case is forwarding path and the ipv6_stub->ipv6_dst_lookup API.
> >
> > It is not a kernel API, because we don't support something like that for
> > external kernel modules. We basically exported ipv6_dst_lookup to allow
> > some IPv4 code to do ipv6 stunts when the IPv6 module is loaded. ;)
>
> ???
>
> ipv6_stub is exported for modules (EXPORT_SYMBOL_GPL(ipv6_stub)).
>
> ipv6_stub->ipv6_dst_lookup is used by several modules -- geneve, tipc,
> vxlan, mpls -- for IPv6 lookups, not IPv4 code do IPv6 stunts.
>
> So how do you say that is not an exported kernel API?
Sorry, yes, I noticed I wrote it in a confusing way.
I meant to say, we don't require the IPv6 "API" to behave in a similar
way like the IPv4 one. We do this function pointer trick to allow
_in-kernel_ tree modules to use the function dynamically, even the
kernel ipv6 module would be available but is not loaded but don't
guarante any "API like IPv4" to outside tree modules.
I tried to make the point, that it is still something internal to the
kernel if compared to out-of-tree function users. And that different
behavior by itself doesn't count as a bug.
We could as well require the users of this function to check for the
source address before or require to check the source address after the
ipv6_dst_lookup call.
vxlan currently seems wrong and would impacted by this patch in a better
way, so I am all in for such a change, but I think we need to check if
we are also correct scope-wise and not just match for the address on its
own.
Thanks,
Hannes
^ permalink raw reply
* [PATCH RFC tip/core/rcu 0/5] Consolidate RCU dyntick-idle counter manipulation
From: Paul E. McKenney @ 2016-11-14 18:30 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, luto
Hello!
The first four patches of this series consolidate RCU's dyntick-idle
counter manipulations into a set of access functions. These are currently
queued for 4.12 (merge window after next). The last patch in this series
uses the bottom bit of RCU's dyntick-idle counter to track a CPU's state,
and has been proposed to track the need to flush the local CPU's TLB.
This last patch will not be pushed until it has a use.
The patches are as follows:
1. Abstract the dynticks momentary-idle operation.
2. Abstract the dynticks snapshot operation.
3. Abstract dynticks extended quiescent state enter/exit operations.
4. Abstract extended quiescent state determination.
5. Maintain special bits at bottom of ->dynticks counter, which
might be used to track a given CPU's need to flush TLBs.
Thanx, Paul
------------------------------------------------------------------------
include/linux/rcutiny.h | 11 +
kernel/rcu/tree.c | 263 ++++++++++++++++++++++++++++++++++-------------
kernel/rcu/tree.h | 3
kernel/rcu/tree_exp.h | 12 --
kernel/rcu/tree_plugin.h | 2
kernel/rcu/tree_trace.c | 2
6 files changed, 216 insertions(+), 77 deletions(-)
^ permalink raw reply
* [PATCH v2] staging: vc04_services: rework ioctl code path
From: Michael Zoran @ 2016-11-14 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111134646.GI28701@mwanda>
On Mon, 2016-11-14 at 12:48 +0300, Dan Carpenter wrote:
> On Thu, Nov 10, 2016 at 10:15:31PM -0800, Michael Zoran wrote:
> > +static void *
> > +vchiq_ioctl_kmalloc(struct vchiq_ioctl_call_context *ctxt, size_t
> > size)
> > +{
> > + void *mem;
> > +
> > + if (!ctxt->stackmem_used && size < sizeof(ctxt->stackmem))
> > {
> > + ctxt->stackmem_used = true;
> > + return ctxt->stackmem;
> > + }
> > +
> > + mem = kmalloc(size + sizeof(void *), GFP_KERNEL);
>
> This is a potential integer overflow leading to corruption.??I don't
> understand why we need this complicated memory management anyway...
>
You could be right. This patch was very large and it hasn't received
the review that it probably should get. Also the checkpatch.pl
utility is complaining about obsolete kernel functionality that the old
code had and I really don't have the time to redo.
Perhaps the entire patch should be removed from consideration until I
can possibly work out a V3?
> > + if (!mem)
> > + return NULL;
> > +
> > + *(void **)mem = ctxt->prev_kmalloc;
> > + ctxt->prev_kmalloc = mem;
> > +
> > + return mem + sizeof(void *);
> > +}
>
> regards,
> dan carpenter
^ permalink raw reply
* Re: [PATCH] fetch/push: document that private data can be leaked
From: Matt McCutchen @ 2016-11-14 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <xmqq1syezs3g.fsf@gitster.mtv.corp.google.com>
On Sun, 2016-11-13 at 18:57 -0800, Junio C Hamano wrote:
> Matt McCutchen <matt@mattmccutchen.net> writes:
>
> >
> > Documentation/fetch-push-security.txt | 9 +++++++++
>
> A new (consolidated) piece like this that can be included in
> multiple places is a good idea. I wonder if the original
> description in "namespaces" thing can be moved here and then
> "namespaces" page can be made to also borrow from this?
I gave this a try. New patch coming.
> > --- /dev/null
> > +++ b/Documentation/fetch-push-security.txt
> > @@ -0,0 +1,9 @@
> > +SECURITY
> > +--------
> > +The fetch and push protocols are not designed to prevent a
> > malicious
> > +server from stealing data from your repository that you did not
> > intend to
> > +share. The possible attacks are similar to the ones described in
> > the
> > +"SECURITY" section of linkgit:gitnamespaces[7]. If you have
> > private data
> > +that you need to protect from the server, keep it in a separate
> > +repository.
>
> Yup, and then "do not push to untrustworthy place without checking
> what you are pushing", too?
If there is no private data in the repository, then there is no need
for the user to check what they are pushing. As I've indicated before,
IMO manually checking each push would not be a workable security
measure in the long term anyway.
Matt
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Zygo Blaxell @ 2016-11-14 18:27 UTC (permalink / raw)
To: Niccolò Belli; +Cc: James Pharaoh, linux-btrfs
In-Reply-To: <e9a425e6-0f1a-42ca-8200-1cad1193f048@linuxsystems.it>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
On Tue, Nov 08, 2016 at 12:06:01PM +0100, Niccolò Belli wrote:
> Nice, you should probably update the btrfs wiki as well, because there is no
> mention of btrfs-dedupe.
>
> First question, why this name? Don't you plan to support xfs as well?
Does XFS plan to support LOGICAL_INO, INO_PATHS, and something analogous
to SEARCH_V2?
POSIX API + FILE_EXTENT_SAME is OK for the lowest common denominator
across arbitrary filesystems, but a btrfs-specific tool can do a lot
better. Especially for incremental dedup and low-RAM algorithms.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [lustre-devel] [PATCH 00/35] second batch of missing lustre 2.8 patches
From: James Simmons @ 2016-11-14 18:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Andreas Dilger, Oleg Drokin, Linux Kernel Mailing List,
Lustre Development List
In-Reply-To: <20161114151650.GA12605@kroah.com>
> On Thu, Nov 10, 2016 at 12:30:30PM -0500, James Simmons wrote:
> > More fixes missing from the upstream client. Also a nice cleanup
> > with the removal of cl_req which is no longer needed. More cleanup
> > for lustre_idl.h which is a uapi header. Like the last batch these
> > patches are independent of order.
>
> I didn't apply a few of these (string parsing stuff, and build
> breakages.)
>
> What's the plan for getting this out of staging? I feel like you all
> are still adding new features along with these "cleanups". Normally
> that's fine, but I really really want to get this out of staging as it's
> been there for way too long. When is that going to happen?
First I should address why the push to bring it into sync with our
prouction code base. One was to make it attractive to our user base.
In my other email I explained that. Second the feed back here has been
so valuable. We are at the point where bugs we haven't found are being
reported here and addressed. Also your input has made the Lustre
developers to reflect on what we have done. In a way leaving staging will
be sad since that will stop :-( Lastly I really didn't want to cleanup
the lustre client and then when it left staging do this massive dump
of changes without people like Julia, Dan and you looking at it. I just
felt that wouldn't of been right.
We are super close to reaching a very important mile stone of reaching
lustre 2.8.0 level of suppport. At this point we can stop at our lustre
2.8.0 release for the sync since currently most the lustre users out their
are staying at that version. Secondly the major of patches landed to our
soon to be release 2.9 version was for the patches missing from the
staging tree.
So before we consider moving out of staging some gaps need to be filled.
The zero day system has found bugs on platforms we don't have access too.
We really need to hook into that system. Also Julia Lawall Coccinelle
work has been really wonderful. Intel does have a mirror of your tree and
have started the integration of the test harness. For my work I have
using a local private test harness setup. This Intel one is planned for
public consumption. What is done here with Coccinelle and zero day needs
to be intergrated. So this is what needs to be done from our side.
Now for what is required to leave the staging tree. Honestly I can think
of many many many things that need to be done. The question becomes what
has to be done before leaving staging verses what can be completed after
leaving staging. We have the normal style issues and checkpatch issues
which is not much anymore. Then their is the uapi header cleanup. What
else beyond that?
^ permalink raw reply
* [PATCH 09/11] mailbox: bcm-pdc: Performance improvements
From: Rob Rice @ 2016-11-14 18:26 UTC (permalink / raw)
To: Jassi Brar; +Cc: bcm-kernel-feedback-list, linux-kernel, Steve Lin, Rob Rice
In-Reply-To: <1479147965-29662-1-git-send-email-rob.rice@broadcom.com>
Three changes to improve performance in the PDC driver:
- disable and reenable interrupts while the interrupt handler is
running
- update rxin and txin descriptor indexes more efficiently
- group receive descriptor context into a structure and keep
context in a single array rather than five to improve locality
of reference
Signed-off-by: Rob Rice <rob.rice@broadcom.com>
Reviewed-by: Andy Gospodarek <gospo@broadcom.com>
---
drivers/mailbox/bcm-pdc-mailbox.c | 85 ++++++++++++++++++++++-----------------
1 file changed, 49 insertions(+), 36 deletions(-)
diff --git a/drivers/mailbox/bcm-pdc-mailbox.c b/drivers/mailbox/bcm-pdc-mailbox.c
index e7dc1a2..8c2aa7c 100644
--- a/drivers/mailbox/bcm-pdc-mailbox.c
+++ b/drivers/mailbox/bcm-pdc-mailbox.c
@@ -260,6 +260,27 @@ struct pdc_ring_alloc {
u32 size; /* ring allocation size in bytes */
};
+/*
+ * context associated with a receive descriptor.
+ * @rxp_ctx: opaque context associated with frame that starts at each
+ * rx ring index.
+ * @dst_sg: Scatterlist used to form reply frames beginning at a given ring
+ * index. Retained in order to unmap each sg after reply is processed.
+ * @rxin_numd: Number of rx descriptors associated with the message that starts
+ * at a descriptor index. Not set for every index. For example,
+ * if descriptor index i points to a scatterlist with 4 entries,
+ * then the next three descriptor indexes don't have a value set.
+ * @resp_hdr: Virtual address of buffer used to catch DMA rx status
+ * @resp_hdr_daddr: physical address of DMA rx status buffer
+ */
+struct pdc_rx_ctx {
+ void *rxp_ctx;
+ struct scatterlist *dst_sg;
+ u32 rxin_numd;
+ void *resp_hdr;
+ dma_addr_t resp_hdr_daddr;
+};
+
/* PDC state structure */
struct pdc_state {
/* Index of the PDC whose state is in this structure instance */
@@ -377,11 +398,7 @@ struct pdc_state {
/* Index of next rx descriptor to post. */
u32 rxout;
- /*
- * opaque context associated with frame that starts at each
- * rx ring index.
- */
- void *rxp_ctx[PDC_RING_ENTRIES];
+ struct pdc_rx_ctx rx_ctx[PDC_RING_ENTRIES];
/*
* Scatterlists used to form request and reply frames beginning at a
@@ -389,18 +406,6 @@ struct pdc_state {
* is processed
*/
struct scatterlist *src_sg[PDC_RING_ENTRIES];
- struct scatterlist *dst_sg[PDC_RING_ENTRIES];
-
- /*
- * Number of rx descriptors associated with the message that starts
- * at this descriptor index. Not set for every index. For example,
- * if descriptor index i points to a scatterlist with 4 entries, then
- * the next three descriptor indexes don't have a value set.
- */
- u32 rxin_numd[PDC_RING_ENTRIES];
-
- void *resp_hdr[PDC_RING_ENTRIES];
- dma_addr_t resp_hdr_daddr[PDC_RING_ENTRIES];
struct dentry *debugfs_stats; /* debug FS stats file for this PDC */
@@ -591,11 +596,11 @@ pdc_receive_one(struct pdc_state *pdcs)
struct brcm_message mssg;
u32 len, rx_status;
u32 num_frags;
- int i;
u8 *resp_hdr; /* virtual addr of start of resp message DMA header */
u32 frags_rdy; /* number of fragments ready to read */
u32 rx_idx; /* ring index of start of receive frame */
dma_addr_t resp_hdr_daddr;
+ struct pdc_rx_ctx *rx_ctx;
mbc = &pdcs->mbc;
chan = &mbc->chans[0];
@@ -607,7 +612,8 @@ pdc_receive_one(struct pdc_state *pdcs)
* to read.
*/
frags_rdy = NRXDACTIVE(pdcs->rxin, pdcs->last_rx_curr, pdcs->nrxpost);
- if ((frags_rdy == 0) || (frags_rdy < pdcs->rxin_numd[pdcs->rxin]))
+ if ((frags_rdy == 0) ||
+ (frags_rdy < pdcs->rx_ctx[pdcs->rxin].rxin_numd))
/* No response ready */
return -EAGAIN;
@@ -617,24 +623,23 @@ pdc_receive_one(struct pdc_state *pdcs)
dma_unmap_sg(dev, pdcs->src_sg[pdcs->txin],
sg_nents(pdcs->src_sg[pdcs->txin]), DMA_TO_DEVICE);
- for (i = 0; i < num_frags; i++)
- pdcs->txin = NEXTTXD(pdcs->txin, pdcs->ntxpost);
+ pdcs->txin = (pdcs->txin + num_frags) & pdcs->ntxpost;
dev_dbg(dev, "PDC %u reclaimed %d tx descriptors",
pdcs->pdc_idx, num_frags);
rx_idx = pdcs->rxin;
- num_frags = pdcs->rxin_numd[rx_idx];
+ rx_ctx = &pdcs->rx_ctx[rx_idx];
+ num_frags = rx_ctx->rxin_numd;
/* Return opaque context with result */
- mssg.ctx = pdcs->rxp_ctx[rx_idx];
- pdcs->rxp_ctx[rx_idx] = NULL;
- resp_hdr = pdcs->resp_hdr[rx_idx];
- resp_hdr_daddr = pdcs->resp_hdr_daddr[rx_idx];
- dma_unmap_sg(dev, pdcs->dst_sg[rx_idx],
- sg_nents(pdcs->dst_sg[rx_idx]), DMA_FROM_DEVICE);
+ mssg.ctx = rx_ctx->rxp_ctx;
+ rx_ctx->rxp_ctx = NULL;
+ resp_hdr = rx_ctx->resp_hdr;
+ resp_hdr_daddr = rx_ctx->resp_hdr_daddr;
+ dma_unmap_sg(dev, rx_ctx->dst_sg, sg_nents(rx_ctx->dst_sg),
+ DMA_FROM_DEVICE);
- for (i = 0; i < num_frags; i++)
- pdcs->rxin = NEXTRXD(pdcs->rxin, pdcs->nrxpost);
+ pdcs->rxin = (pdcs->rxin + num_frags) & pdcs->nrxpost;
dev_dbg(dev, "PDC %u reclaimed %d rx descriptors",
pdcs->pdc_idx, num_frags);
@@ -826,6 +831,7 @@ static int pdc_rx_list_init(struct pdc_state *pdcs, struct scatterlist *dst_sg,
u32 rx_pkt_cnt = 1; /* Adding a single rx buffer */
dma_addr_t daddr;
void *vaddr;
+ struct pdc_rx_ctx *rx_ctx;
rx_avail = pdcs->nrxpost - NRXDACTIVE(pdcs->rxin, pdcs->rxout,
pdcs->nrxpost);
@@ -849,15 +855,16 @@ static int pdc_rx_list_init(struct pdc_state *pdcs, struct scatterlist *dst_sg,
/* This is always the first descriptor in the receive sequence */
flags = D64_CTRL1_SOF;
- pdcs->rxin_numd[pdcs->rx_msg_start] = 1;
+ pdcs->rx_ctx[pdcs->rx_msg_start].rxin_numd = 1;
if (unlikely(pdcs->rxout == (pdcs->nrxd - 1)))
flags |= D64_CTRL1_EOT;
- pdcs->rxp_ctx[pdcs->rxout] = ctx;
- pdcs->dst_sg[pdcs->rxout] = dst_sg;
- pdcs->resp_hdr[pdcs->rxout] = vaddr;
- pdcs->resp_hdr_daddr[pdcs->rxout] = daddr;
+ rx_ctx = &pdcs->rx_ctx[pdcs->rxout];
+ rx_ctx->rxp_ctx = ctx;
+ rx_ctx->dst_sg = dst_sg;
+ rx_ctx->resp_hdr = vaddr;
+ rx_ctx->resp_hdr_daddr = daddr;
pdc_build_rxd(pdcs, daddr, pdcs->pdc_resp_hdr_len, flags);
return PDC_SUCCESS;
}
@@ -925,7 +932,7 @@ static int pdc_rx_list_sg_add(struct pdc_state *pdcs, struct scatterlist *sg)
desc_w++;
sg = sg_next(sg);
}
- pdcs->rxin_numd[pdcs->rx_msg_start] += desc_w;
+ pdcs->rx_ctx[pdcs->rx_msg_start].rxin_numd += desc_w;
return PDC_SUCCESS;
}
@@ -954,6 +961,9 @@ static irqreturn_t pdc_irq_handler(int irq, void *data)
/* Clear interrupt flags in device */
iowrite32(intstatus, pdcs->pdc_reg_vbase + PDC_INTSTATUS_OFFSET);
+ /* Disable interrupts until soft handler runs */
+ iowrite32(0, pdcs->pdc_reg_vbase + PDC_INTMASK_OFFSET);
+
/* Wakeup IRQ thread */
if (likely(pdcs && (irq == pdcs->pdc_irq) &&
(intstatus & PDC_INTMASK))) {
@@ -971,6 +981,9 @@ static void pdc_tasklet_cb(unsigned long data)
rx_int = test_and_clear_bit(PDC_RCVINT_0, &pdcs->intstatus);
if (likely(pdcs && rx_int))
pdc_receive(pdcs);
+
+ /* reenable interrupts */
+ iowrite32(PDC_INTMASK, pdcs->pdc_reg_vbase + PDC_INTMASK_OFFSET);
}
/**
--
2.1.0
^ permalink raw reply related
* [PATCH 05/11] mailbox: bcm-pdc: streamline rx code
From: Rob Rice @ 2016-11-14 18:25 UTC (permalink / raw)
To: Jassi Brar; +Cc: bcm-kernel-feedback-list, linux-kernel, Steve Lin, Rob Rice
In-Reply-To: <1479147965-29662-1-git-send-email-rob.rice@broadcom.com>
Remove the unnecessary rmb() from the receive path.
If the rx ring has multiple messages ready, avoid reading
last_rx_curr multiple times from the register.
Signed-off-by: Rob Rice <rob.rice@broadcom.com>
Reviewed-by: Andy Gospodarek <gospo@broadcom.com>
---
drivers/mailbox/bcm-pdc-mailbox.c | 108 +++++++++++++++++---------------------
1 file changed, 48 insertions(+), 60 deletions(-)
diff --git a/drivers/mailbox/bcm-pdc-mailbox.c b/drivers/mailbox/bcm-pdc-mailbox.c
index fa3f484..2195760 100644
--- a/drivers/mailbox/bcm-pdc-mailbox.c
+++ b/drivers/mailbox/bcm-pdc-mailbox.c
@@ -570,27 +570,23 @@ pdc_build_txd(struct pdc_state *pdcs, dma_addr_t dma_addr, u32 buf_len,
}
/**
- * pdc_receive() - Receive a response message from a given SPU.
+ * pdc_receive_one() - Receive a response message from a given SPU.
* @pdcs: PDC state for the SPU to receive from
- * @mssg: mailbox message to be returned to client
*
* When the return code indicates success, the response message is available in
* the receive buffers provided prior to submission of the request.
*
- * Input:
- * pdcs - PDC state structure for the SPU to be polled
- * mssg - mailbox message to be returned to client. This function sets the
- * context pointer on the message to help the client associate the
- * response with a request.
- *
* Return: PDC_SUCCESS if one or more receive descriptors was processed
* -EAGAIN indicates that no response message is available
* -EIO an error occurred
*/
static int
-pdc_receive(struct pdc_state *pdcs, struct brcm_message *mssg)
+pdc_receive_one(struct pdc_state *pdcs)
{
struct device *dev = &pdcs->pdev->dev;
+ struct mbox_controller *mbc;
+ struct mbox_chan *chan;
+ struct brcm_message mssg;
u32 len, rx_status;
u32 num_frags;
int i;
@@ -599,29 +595,23 @@ pdc_receive(struct pdc_state *pdcs, struct brcm_message *mssg)
u32 rx_idx; /* ring index of start of receive frame */
dma_addr_t resp_hdr_daddr;
+ mbc = &pdcs->mbc;
+ chan = &mbc->chans[0];
+ mssg.type = BRCM_MESSAGE_SPU;
+
/*
* return if a complete response message is not yet ready.
* rxin_numd[rxin] is the number of fragments in the next msg
* to read.
*/
frags_rdy = NRXDACTIVE(pdcs->rxin, pdcs->last_rx_curr, pdcs->nrxpost);
- if ((frags_rdy == 0) || (frags_rdy < pdcs->rxin_numd[pdcs->rxin])) {
- /* See if the hw has written more fragments than we know */
- pdcs->last_rx_curr =
- (ioread32((void *)&pdcs->rxregs_64->status0) &
- CRYPTO_D64_RS0_CD_MASK) / RING_ENTRY_SIZE;
- frags_rdy = NRXDACTIVE(pdcs->rxin, pdcs->last_rx_curr,
- pdcs->nrxpost);
- if ((frags_rdy == 0) ||
- (frags_rdy < pdcs->rxin_numd[pdcs->rxin])) {
- /* No response ready */
- return -EAGAIN;
- }
- /* can't read descriptors/data until write index is read */
- rmb();
- }
+ if ((frags_rdy == 0) || (frags_rdy < pdcs->rxin_numd[pdcs->rxin]))
+ /* No response ready */
+ return -EAGAIN;
num_frags = pdcs->txin_numd[pdcs->txin];
+ WARN_ON(num_frags == 0);
+
dma_unmap_sg(dev, pdcs->src_sg[pdcs->txin],
sg_nents(pdcs->src_sg[pdcs->txin]), DMA_TO_DEVICE);
@@ -634,7 +624,7 @@ pdc_receive(struct pdc_state *pdcs, struct brcm_message *mssg)
rx_idx = pdcs->rxin;
num_frags = pdcs->rxin_numd[rx_idx];
/* Return opaque context with result */
- mssg->ctx = pdcs->rxp_ctx[rx_idx];
+ mssg.ctx = pdcs->rxp_ctx[rx_idx];
pdcs->rxp_ctx[rx_idx] = NULL;
resp_hdr = pdcs->resp_hdr[rx_idx];
resp_hdr_daddr = pdcs->resp_hdr_daddr[rx_idx];
@@ -674,12 +664,35 @@ pdc_receive(struct pdc_state *pdcs, struct brcm_message *mssg)
dma_pool_free(pdcs->rx_buf_pool, resp_hdr, resp_hdr_daddr);
+ mbox_chan_received_data(chan, &mssg);
+
pdcs->pdc_replies++;
- /* if we read one or more rx descriptors, claim success */
- if (num_frags > 0)
- return PDC_SUCCESS;
- else
- return -EIO;
+ return PDC_SUCCESS;
+}
+
+/**
+ * pdc_receive() - Process as many responses as are available in the rx ring.
+ * @pdcs: PDC state
+ *
+ * Called within the hard IRQ.
+ * Return:
+ */
+static int
+pdc_receive(struct pdc_state *pdcs)
+{
+ int rx_status;
+
+ /* read last_rx_curr from register once */
+ pdcs->last_rx_curr =
+ (ioread32((void *)&pdcs->rxregs_64->status0) &
+ CRYPTO_D64_RS0_CD_MASK) / RING_ENTRY_SIZE;
+
+ do {
+ /* Could be many frames ready */
+ rx_status = pdc_receive_one(pdcs);
+ } while (rx_status == PDC_SUCCESS);
+
+ return 0;
}
/**
@@ -946,14 +959,13 @@ static irqreturn_t pdc_irq_handler(int irq, void *cookie)
}
/**
- * pdc_irq_thread() - Function invoked on deferred thread when a DMA tx has
- * completed or data is available to receive.
+ * pdc_irq_thread() - Function invoked on deferred thread when data is available
+ * to receive.
* @irq: Interrupt number
* @cookie: PDC state for PDC that generated the interrupt
*
- * On DMA tx complete, notify the mailbox client. On DMA rx complete, process
- * as many SPU response messages as are available and send each to the mailbox
- * client.
+ * On DMA rx complete, process as many SPU response messages as are available
+ * and send each to the mailbox client.
*
* Return: IRQ_HANDLED if we recognized and handled the interrupt
* IRQ_NONE otherwise
@@ -961,39 +973,15 @@ static irqreturn_t pdc_irq_handler(int irq, void *cookie)
static irqreturn_t pdc_irq_thread(int irq, void *cookie)
{
struct pdc_state *pdcs = cookie;
- struct mbox_controller *mbc;
- struct mbox_chan *chan;
bool rx_int;
- int rx_status;
- struct brcm_message mssg;
rx_int = test_and_clear_bit(PDC_RCVINT_0, &pdcs->intstatus);
-
if (pdcs && rx_int) {
dev_dbg(&pdcs->pdev->dev,
"%s() got irq %d with rx_int %s",
__func__, irq, rx_int ? "set" : "clear");
- mbc = &pdcs->mbc;
- chan = &mbc->chans[0];
-
- while (1) {
- /* Could be many frames ready */
- memset(&mssg, 0, sizeof(mssg));
- mssg.type = BRCM_MESSAGE_SPU;
- rx_status = pdc_receive(pdcs, &mssg);
- if (rx_status >= 0) {
- dev_dbg(&pdcs->pdev->dev,
- "%s(): invoking client rx cb",
- __func__);
- mbox_chan_received_data(chan, &mssg);
- } else {
- dev_dbg(&pdcs->pdev->dev,
- "%s(): no SPU response available",
- __func__);
- break;
- }
- }
+ pdc_receive(pdcs);
return IRQ_HANDLED;
}
return IRQ_NONE;
--
2.1.0
^ permalink raw reply related
* [PATCH] ARM: Drop fixed 200 Hz timer requirement from Exynos platforms
From: Krzysztof Kozlowski @ 2016-11-14 18:27 UTC (permalink / raw)
To: linux-arm-kernel
All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
200 Hz. Unfortunately in case of multiplatform image this affects also
other platforms when Exynos is selected.
This looks like an very old legacy code, dating back to initial
upstreaming of S3C24xx. Probably it was required for s3c24xx timer
driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
unused plat-samsung/time.c").
Since then, this fixed 200 Hz spread everywhere, including out-of-tree
Samsung kernels (SoC vendor's and Tizen's). I believe this choice
was rather an effect of coincidence instead of conscious choice. In
fact Exynos can work with different timers.
Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
other values.
Reported-by: Lee Jones <lee.jones@linaro.org>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Testing on other Exynos platforms would be appreciated.
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..0d10e45f9175 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1497,7 +1497,7 @@ source kernel/Kconfig.preempt
config HZ_FIXED
int
default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
- ARCH_S5PV210 || ARCH_EXYNOS4
+ ARCH_S5PV210
default 128 if SOC_AT91RM9200
default 0
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: Drop fixed 200 Hz timer requirement from Exynos platforms
From: Krzysztof Kozlowski @ 2016-11-14 18:27 UTC (permalink / raw)
To: Russell King, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, linux-arm-kernel, linux-samsung-soc,
linux-kernel
Cc: Ben Dooks, Lee Jones, Arnd Bergmann, Marek Szyprowski,
Bartlomiej Zolnierkiewicz, Sylwester Nawrocki, Tomasz Figa
All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
200 Hz. Unfortunately in case of multiplatform image this affects also
other platforms when Exynos is selected.
This looks like an very old legacy code, dating back to initial
upstreaming of S3C24xx. Probably it was required for s3c24xx timer
driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
unused plat-samsung/time.c").
Since then, this fixed 200 Hz spread everywhere, including out-of-tree
Samsung kernels (SoC vendor's and Tizen's). I believe this choice
was rather an effect of coincidence instead of conscious choice. In
fact Exynos can work with different timers.
Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
other values.
Reported-by: Lee Jones <lee.jones@linaro.org>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Testing on other Exynos platforms would be appreciated.
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..0d10e45f9175 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1497,7 +1497,7 @@ source kernel/Kconfig.preempt
config HZ_FIXED
int
default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
- ARCH_S5PV210 || ARCH_EXYNOS4
+ ARCH_S5PV210
default 128 if SOC_AT91RM9200
default 0
--
2.7.4
^ permalink raw reply related
* [PATCH 02/11] mailbox: bcm-pdc: Changes so mbox client can be removed / re-inserted
From: Rob Rice @ 2016-11-14 18:25 UTC (permalink / raw)
To: Jassi Brar; +Cc: bcm-kernel-feedback-list, linux-kernel, Steve Lin, Rob Rice
In-Reply-To: <1479147965-29662-1-git-send-email-rob.rice@broadcom.com>
From: Steve Lin <steven.lin1@broadcom.com>
Ensure that DMA is disabled, and pointers reset, when changing
DMA base addresses in pdc_ring_init(). This allows a mailbox client
to be re-inserted after being removed. Otherwise, the DMA doesn't
restart so the client hangs while being reinserted.
Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
Signed-off-by: Rob Rice <rob.rice@broadcom.com>
Reviewed-by: Andy Gospodarek <gospo@broadcom.com>
---
drivers/mailbox/bcm-pdc-mailbox.c | 54 +++++++++++++++++++++++++++++++++------
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/mailbox/bcm-pdc-mailbox.c b/drivers/mailbox/bcm-pdc-mailbox.c
index a9c804f..3b4ebbe 100644
--- a/drivers/mailbox/bcm-pdc-mailbox.c
+++ b/drivers/mailbox/bcm-pdc-mailbox.c
@@ -117,15 +117,16 @@
/*
* Sets the following bits for write to transmit control reg:
- * 0 - XmtEn - enable activity on the tx channel
* 11 - PtyChkDisable - parity check is disabled
* 20:18 - BurstLen = 3 -> 2^7 = 128 byte data reads from memory
*/
-#define PDC_TX_CTL 0x000C0801
+#define PDC_TX_CTL 0x000C0800
+
+/* Bit in tx control reg to enable tx channel */
+#define PDC_TX_ENABLE 0x1
/*
* Sets the following bits for write to receive control reg:
- * 0 - RcvEn - enable activity on the rx channel
* 7:1 - RcvOffset - size in bytes of status region at start of rx frame buf
* 9 - SepRxHdrDescEn - place start of new frames only in descriptors
* that have StartOfFrame set
@@ -135,7 +136,10 @@
* 11 - PtyChkDisable - parity check is disabled
* 20:18 - BurstLen = 3 -> 2^7 = 128 byte data reads from memory
*/
-#define PDC_RX_CTL 0x000C0E01
+#define PDC_RX_CTL 0x000C0E00
+
+/* Bit in rx control reg to enable rx channel */
+#define PDC_RX_ENABLE 0x1
#define CRYPTO_D64_RS0_CD_MASK ((PDC_RING_ENTRIES * RING_ENTRY_SIZE) - 1)
@@ -1054,6 +1058,15 @@ static int pdc_ring_init(struct pdc_state *pdcs, int ringset)
/* Tell device the base DMA address of each ring */
dma_reg = &pdcs->regs->dmaregs[ringset];
+
+ /* But first disable DMA and set curptr to 0 for both TX & RX */
+ iowrite32(PDC_TX_CTL, &dma_reg->dmaxmt.control);
+ iowrite32((PDC_RX_CTL + (pdcs->rx_status_len << 1)),
+ (void *)&dma_reg->dmarcv.control);
+ iowrite32(0, (void *)&dma_reg->dmaxmt.ptr);
+ iowrite32(0, (void *)&dma_reg->dmarcv.ptr);
+
+ /* Set base DMA addresses */
iowrite32(lower_32_bits(pdcs->tx_ring_alloc.dmabase),
(void *)&dma_reg->dmaxmt.addrlow);
iowrite32(upper_32_bits(pdcs->tx_ring_alloc.dmabase),
@@ -1064,6 +1077,11 @@ static int pdc_ring_init(struct pdc_state *pdcs, int ringset)
iowrite32(upper_32_bits(pdcs->rx_ring_alloc.dmabase),
(void *)&dma_reg->dmarcv.addrhigh);
+ /* Re-enable DMA */
+ iowrite32(PDC_TX_CTL | PDC_TX_ENABLE, &dma_reg->dmaxmt.control);
+ iowrite32((PDC_RX_CTL | PDC_RX_ENABLE | (pdcs->rx_status_len << 1)),
+ (void *)&dma_reg->dmarcv.control);
+
/* Initialize descriptors */
for (i = 0; i < PDC_RING_ENTRIES; i++) {
/* Every tx descriptor can be used for start of frame. */
@@ -1235,23 +1253,41 @@ void pdc_hw_init(struct pdc_state *pdcs)
pdcs->nrxd = PDC_RING_ENTRIES;
pdcs->ntxpost = PDC_RING_ENTRIES - 1;
pdcs->nrxpost = PDC_RING_ENTRIES - 1;
- pdcs->regs->intmask = 0;
+ iowrite32(0, &pdcs->regs->intmask);
dma_reg = &pdcs->regs->dmaregs[ringset];
- iowrite32(0, (void *)&dma_reg->dmaxmt.ptr);
- iowrite32(0, (void *)&dma_reg->dmarcv.ptr);
- iowrite32(PDC_TX_CTL, (void *)&dma_reg->dmaxmt.control);
+ /* Configure DMA but will enable later in pdc_ring_init() */
+ iowrite32(PDC_TX_CTL, &dma_reg->dmaxmt.control);
iowrite32(PDC_RX_CTL + (pdcs->rx_status_len << 1),
(void *)&dma_reg->dmarcv.control);
+ /* Reset current index pointers after making sure DMA is disabled */
+ iowrite32(0, &dma_reg->dmaxmt.ptr);
+ iowrite32(0, &dma_reg->dmarcv.ptr);
+
if (pdcs->pdc_resp_hdr_len == PDC_SPU2_RESP_HDR_LEN)
iowrite32(PDC_CKSUM_CTRL,
pdcs->pdc_reg_vbase + PDC_CKSUM_CTRL_OFFSET);
}
/**
+ * pdc_hw_disable() - Disable the tx and rx control in the hw.
+ * @pdcs: PDC state structure
+ *
+ */
+static void pdc_hw_disable(struct pdc_state *pdcs)
+{
+ struct dma64 *dma_reg;
+
+ dma_reg = &pdcs->regs->dmaregs[PDC_RINGSET];
+ iowrite32(PDC_TX_CTL, &dma_reg->dmaxmt.control);
+ iowrite32(PDC_RX_CTL + (pdcs->rx_status_len << 1),
+ &dma_reg->dmarcv.control);
+}
+
+/**
* pdc_rx_buf_pool_create() - Pool of receive buffers used to catch the metadata
* header returned with each response message.
* @pdcs: PDC state structure
@@ -1505,6 +1541,8 @@ static int pdc_remove(struct platform_device *pdev)
pdc_free_debugfs();
+ pdc_hw_disable(pdcs);
+
mbox_controller_unregister(&pdcs->mbc);
dma_pool_destroy(pdcs->rx_buf_pool);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net 1/3] bpf, mlx5: fix mlx5e_create_rq taking reference on prog
From: Daniel Borkmann @ 2016-11-14 18:26 UTC (permalink / raw)
To: Saeed Mahameed, davem
Cc: alexei.starovoitov, bblanco, tariqt, zhiyisun, ranas, netdev
In-Reply-To: <918902f3-1852-ae68-b12d-eaa1c45bf641@mellanox.com>
Hi Saeed,
On 11/14/2016 07:15 PM, Saeed Mahameed wrote:
> On 11/14/2016 02:43 AM, Daniel Borkmann wrote:
>> In mlx5e_create_rq(), when creating a new queue, we call bpf_prog_add() but
>> without checking the return value. bpf_prog_add() can fail, so we really
>
> Didn't know this, thanks for noticing, I wonder why taking a reference for an object would fail ?
> especially when someone is requesting from the driver to take a reference to it ndo_xdp_set ?! sounds like a bad design.
>
> Anyway I will check that later.
See 92117d8443bc ("bpf: fix refcnt overflow").
>> must check it. Take the reference right when we assign it to the rq from
>> priv->xdp_prog, and just drop the reference on error path. Destruction in
>> mlx5e_destroy_rq() looks good, though.
>>
>> Fixes: 86994156c736 ("net/mlx5e: XDP fast RX drop bpf programs support")
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>> ---
>> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 14 +++++++++++---
>> kernel/bpf/syscall.c | 1 +
>> 2 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> index 84e8b25..2b83667 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> @@ -489,7 +489,16 @@ static int mlx5e_create_rq(struct mlx5e_channel *c,
>> rq->channel = c;
>> rq->ix = c->ix;
>> rq->priv = c->priv;
>> +
>> rq->xdp_prog = priv->xdp_prog;
>
> Why keeping this assignment ? just test priv->xdp_prog.
>
>> + if (rq->xdp_prog) {
>> + rq->xdp_prog = bpf_prog_inc(rq->xdp_prog);
>> + if (IS_ERR(rq->xdp_prog)) {
>> + err = PTR_ERR(rq->xdp_prog);
>> + rq->xdp_prog = NULL;
>> + goto err_rq_wq_destroy;
>> + }
>> + }
>
> Try this, simpler and less indentations:
>
> rq->xdp_prog = priv->xdp_prog ? bpf_prog_inc(priv->xdp_prog) : NULL;
> if (IS_ERR(rq->xdp_prog)) {
> err = PTR_ERR(rq->xdp_prog);
> rq->xdp_prog = NULL;
> goto err_rq_wq_destroy;
> }
Sure, I don't mind. Will do.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] mpm-transport: Update commit id with fixes
From: Nelson, Sam @ 2016-11-14 15:49 UTC (permalink / raw)
To: meta-ti@yoctoproject.org
In-Reply-To: <1478961971-54163-1-git-send-email-sam.nelson@ti.com>
NAK
Ignore this.
> -----Original Message-----
> From: Nelson, Sam
> Sent: Saturday, November 12, 2016 9:46 AM
> To: meta-ti@yoctoproject.org
> Cc: Nelson, Sam
> Subject: [PATCH] mpm-transport: Update commit id with fixes
>
> Update and fixes to handle different type of memory sections in sysfs entry
> or device tree.
>
> Signed-off-by: Sam Nelson <sam.nelson@ti.com>
> ---
> recipes-ti/mpm-transport/mpm-transport_git.bb | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-ti/mpm-transport/mpm-transport_git.bb b/recipes-
> ti/mpm-transport/mpm-transport_git.bb
> index 51b5e9e..ee28f2f 100644
> --- a/recipes-ti/mpm-transport/mpm-transport_git.bb
> +++ b/recipes-ti/mpm-transport/mpm-transport_git.bb
> @@ -15,11 +15,11 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
> SRC_URI = "git://git.ti.com/keystone-linux/mpm-
> transport.git;protocol=git;branch=${BRANCH}"
>
> BRANCH = "master"
> -# This commit corresponds to tag DEV.MPM-TRANSPORT-02.00.02.00 -
> SRCREV = "696a9ec37559b671860ef393194c6032b7b6d9ef"
> +# This commit corresponds to tag DEV.MPM-TRANSPORT-02.00.02.00A
> SRCREV
> += "7284e75d36b265ef8535d2e2ee54d1f2c700e862"
>
> PV = "2.0.2.0"
> -PR = "r0"
> +PR = "r1"
>
> EXTRA_OEMAKE = "PDK_INSTALL_PATH=${STAGING_INCDIR}"
> EXTRA_OEMAKE_append_k2hk-evm += "HYPLNK_TRANSPORT=true
> SRIO_TRANSPORT=true"
> --
> 1.9.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.