Re: [PATCH v2 15/30] xfs: Define usercopy region in xfs_inode slab cache
On Wed, Aug 30, 2017 at 07:51:57AM +1000, Dave Chinner wrote: > Right, I've looked at btrees, too, but it's more complex than just > using an rbtree. I originally looked at using Peter Z's old > RCU-aware btree code, but it doesn't hold data in the tree leaves. > So that needed significant modification to make work without a > memory alloc per extent and that didn't work with original aim of > RCU-safe extent lookups. I also looked at that "generic" btree > stuff that came from logfs, and after a little while ran away > screaming. I started with the latter, but it's not really looking like it any more: there nodes are formatted as a series of u64s instead of all the long magic, and the data is stored inline - in fact I use a cute trick to keep the size down, derived from our "compressed" on disk extent format: Key: +---++ | 00:51 | all 52 bits of startoff| | 52:63 | low 12 bits of startblock | +---++ Value +---++ | 00:20 | all 21 bits of length | |21 | unwritten extent bit | | 22:63 | high 42 bits of startblock | +---++ So we only need a 64-bit key and a 64-bit value by abusing parts of the key to store bits of the startblock. For non-leaf nodes we iterate through the keys only, never touching the cache lines for the value. For the leaf nodes we have to touch the value anyway because we have to do a range lookup to find the exact record. This works fine so far in an isolated simulator, and now I'm ammending it to be a b+tree with pointers to the previous and next node so that we can nicely implement our extent iterators instead of doing full lookups. > The sticking point, IMO, is the extent array index based lookups in > all the bmbt code. I've been looking at converting all that to use > offset based lookups and a cursor w/ lookup/inc/dec/insert/delete > ioperations wrapping xfs_iext_lookup_ext() and friends. This means > the modifications are pretty much identical to the on-disk extent > btree, so they can be abstracted out into a single extent update > interface for both trees. Have you planned/done any cleanup/changes > with this code? I've done various cleanups, but I've not yet consolidated the two. Basically step one at the moment is to move everyone to xfs_iext_lookup_extent + xfs_iext_get_extent that removes all the bad intrusion. Once we move to the actual b+trees the extnum_t cursor will be replaced with a real cursor structure that contains a pointer to the current b+tree leaf node, and an index inside that, which will allows us very efficient iteration. The xfs_iext_get_extent calls will be replaced with more specific xfs_iext_prev_extent, xfs_iext_next_extent calls that include the now slightly more complex cursor decrement, increment as well as a new xfs_iext_last_extent helper for the last extent that we need in a few places. insert/delete remain very similar to what they do right now, they'll get a different cursor type, and the manual xfs_iext_add calls will go away. The new xfs_iext_update_extent helper I posted to the list yesterday will become a bit more complex, as changing the startoff will have to be propagated up the tree.
[PATCH 0/6] [media] cx24116: Adjustments for two function implementations
From: Markus Elfring Date: Wed, 30 Aug 2017 09:05:04 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (6): Delete an error message for a failed memory allocation in cx24116_writeregN() Return directly after a failed kmalloc() in cx24116_writeregN() Delete an unnecessary variable initialisation in cx24116_writeregN() Improve a size determination in cx24116_attach() Delete an unnecessary variable initialisation in cx24116_attach() Delete jump targets in cx24116_attach() drivers/media/dvb-frontends/cx24116.c | 22 -- 1 file changed, 8 insertions(+), 14 deletions(-) -- 2.14.1
[PATCH 1/6] [media] cx24116: Delete an error message for a failed memory allocation in cx24116_writeregN()
From: Markus Elfring
Date: Tue, 29 Aug 2017 22:56:29 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/dvb-frontends/cx24116.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/cx24116.c
b/drivers/media/dvb-frontends/cx24116.c
index e105532bfba8..96af4ffba0f9 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -227,7 +227,6 @@ static int cx24116_writeregN(struct cx24116_state *state,
int reg,
buf = kmalloc(len + 1, GFP_KERNEL);
if (buf == NULL) {
- printk("Unable to kmalloc\n");
ret = -ENOMEM;
goto error;
}
--
2.14.1
[PATCH 2/6] [media] cx24116: Return directly after a failed kmalloc() in cx24116_writeregN()
From: Markus Elfring
Date: Wed, 30 Aug 2017 07:55:49 +0200
* Return directly after a call of the function "kmalloc" failed
at the beginning.
* Delete the jump target "error" which became unnecessary
with this refactoring.
Signed-off-by: Markus Elfring
---
drivers/media/dvb-frontends/cx24116.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/cx24116.c
b/drivers/media/dvb-frontends/cx24116.c
index 96af4ffba0f9..69c156443b50 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -226,10 +226,8 @@ static int cx24116_writeregN(struct cx24116_state *state,
int reg,
u8 *buf;
buf = kmalloc(len + 1, GFP_KERNEL);
- if (buf == NULL) {
- ret = -ENOMEM;
- goto error;
- }
+ if (!buf)
+ return -ENOMEM;
*(buf) = reg;
memcpy(buf + 1, data, len);
@@ -250,7 +248,6 @@ static int cx24116_writeregN(struct cx24116_state *state,
int reg,
ret = -EREMOTEIO;
}
-error:
kfree(buf);
return ret;
--
2.14.1
[PATCH 3/6] [media] cx24116: Delete an unnecessary variable initialisation in cx24116_writeregN()
From: Markus Elfring
Date: Wed, 30 Aug 2017 08:10:38 +0200
The variable "ret" will eventually be set to an appropriate value
a bit later. Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/media/dvb-frontends/cx24116.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/cx24116.c
b/drivers/media/dvb-frontends/cx24116.c
index 69c156443b50..54f09a5a5075 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -221,7 +221,7 @@ static int cx24116_writereg(struct cx24116_state *state,
int reg, int data)
static int cx24116_writeregN(struct cx24116_state *state, int reg,
const u8 *data, u16 len)
{
- int ret = -EREMOTEIO;
+ int ret;
struct i2c_msg msg;
u8 *buf;
--
2.14.1
[PATCH 4/6] [media] cx24116: Improve a size determination in cx24116_attach()
From: Markus Elfring
Date: Wed, 30 Aug 2017 08:15:33 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/dvb-frontends/cx24116.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/cx24116.c
b/drivers/media/dvb-frontends/cx24116.c
index 54f09a5a5075..74d610207bf2 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -1123,7 +1123,7 @@ struct dvb_frontend *cx24116_attach(const struct
cx24116_config *config,
dprintk("%s\n", __func__);
/* allocate memory for the internal state */
- state = kzalloc(sizeof(struct cx24116_state), GFP_KERNEL);
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
if (state == NULL)
goto error1;
--
2.14.1
[PATCH 5/6] [media] cx24116: Delete an unnecessary variable initialisation in cx24116_attach()
From: Markus Elfring
Date: Wed, 30 Aug 2017 08:30:12 +0200
The variable "state" will be set to an appropriate pointer a bit later.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/media/dvb-frontends/cx24116.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/cx24116.c
b/drivers/media/dvb-frontends/cx24116.c
index 74d610207bf2..902a60d2e1b5 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -1117,7 +1117,7 @@ static const struct dvb_frontend_ops cx24116_ops;
struct dvb_frontend *cx24116_attach(const struct cx24116_config *config,
struct i2c_adapter *i2c)
{
- struct cx24116_state *state = NULL;
+ struct cx24116_state *state;
int ret;
dprintk("%s\n", __func__);
--
2.14.1
Re: [PATCH v2 3/3] livepatch: force transition process to finish
On Thu 2017-08-10 12:48:15, Miroslav Benes wrote: > If a task sleeps in a set of patched functions uninterruptibly, it could > block the whole transition process indefinitely. Thus it may be useful > to clear its TIF_PATCH_PENDING to allow the process to finish. > > Admin can do that now by writing to force sysfs attribute in livepatch > sysfs directory. TIF_PATCH_PENDING is then cleared for all tasks and the > transition can finish successfully. > > Important note! Use wisely. Admin must be sure that it is safe to > execute such action. This means that it must be checked that by doing so > the consistency model guarantees are not violated. Yes, that's what admins are good for. Magically determining what state their machine is in, and deciding if all the processes are in the sane state and what the consequences are. They have all the tools they need to do that, like JTAG connection to the CPU and about 10 years of time... do they? This should taint the kernel at the very least. It should also require capabilities beyond "normal root", because it allows malicious admin to do "bad things (tm)" to the kernel. Pavel > diff --git a/Documentation/livepatch/livepatch.txt > b/Documentation/livepatch/livepatch.txt > index 343b0bfa1b9f..7626d1b947c2 100644 > --- a/Documentation/livepatch/livepatch.txt > +++ b/Documentation/livepatch/livepatch.txt > @@ -183,7 +183,11 @@ attribute. Reading from the file returns all available > operations. Writing one > of the strings to the file executes the operation. "signal" is available for > signalling all remaining blocking tasks. This is an alternative for > SIGSTOP/SIGCONT approach mentioned in the previous paragraph. It should also > be > -less harmful to the system. > +less harmful to the system. "force" clears TIF_PATCH_PENDING flag of all > tasks > +and thus forces the tasks to the patched state. Important note! Use "force" > +wisely. Administrator must be sure that it is safe to execute such action. > This > +means that it must be checked that by doing so the consistency model > guarantees > +are not violated. You may want to elaborate here a lot. If you want to pretend administrator can decide this, you need to describe what the model is, and how administrator get enough information about the system state. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH 6/6] [media] cx24116: Delete jump targets in cx24116_attach()
From: Markus Elfring
Date: Wed, 30 Aug 2017 08:44:29 +0200
* Return directly after a call of the function "kzalloc" failed
at the beginning.
* Move a bit of exception handling code into an if branch.
* Delete two jump targets which became unnecessary with this refactoring.
Signed-off-by: Markus Elfring
---
drivers/media/dvb-frontends/cx24116.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/cx24116.c
b/drivers/media/dvb-frontends/cx24116.c
index 902a60d2e1b5..8fb3f095e21c 100644
--- a/drivers/media/dvb-frontends/cx24116.c
+++ b/drivers/media/dvb-frontends/cx24116.c
@@ -1125,7 +1125,7 @@ struct dvb_frontend *cx24116_attach(const struct
cx24116_config *config,
/* allocate memory for the internal state */
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (state == NULL)
- goto error1;
+ return NULL;
state->config = config;
state->i2c = i2c;
@@ -1134,8 +1134,9 @@ struct dvb_frontend *cx24116_attach(const struct
cx24116_config *config,
ret = (cx24116_readreg(state, 0xFF) << 8) |
cx24116_readreg(state, 0xFE);
if (ret != 0x0501) {
+ kfree(state);
printk(KERN_INFO "Invalid probe, probably not a CX24116
device\n");
- goto error2;
+ return NULL;
}
/* create dvb_frontend */
@@ -1143,9 +1144,6 @@ struct dvb_frontend *cx24116_attach(const struct
cx24116_config *config,
sizeof(struct dvb_frontend_ops));
state->frontend.demodulator_priv = state;
return &state->frontend;
-
-error2: kfree(state);
-error1: return NULL;
}
EXPORT_SYMBOL(cx24116_attach);
--
2.14.1
[PATCH 1/2] arm64: stacktrace: avoid listing stacktrace functions in stacktrace
The stacktraces always begin as follows:
[] save_stack_trace_tsk+0x0/0x98
[] save_stack_trace+0x24/0x28
...
This is because the stack trace code includes the stack frames for itself.
This is incorrect behaviour, and also leads to "skip" doing the wrong thing
(which is the number of stack frames to avoid recording.)
Perversely, it does the right thing when passed a non-current thread. Fix
this by ensuring that we have a known constant number of frames above the
main stack trace function, and always skip these.
This was fixed for arch arm by Commit 3683f44c42e9 ("ARM: stacktrace: avoid
listing stacktrace functions in stacktrace")
Signed-off-by: Prakash Gupta
---
arch/arm64/kernel/stacktrace.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 3144584617e7..76809ccd309c 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -140,7 +140,8 @@ void save_stack_trace_regs(struct pt_regs *regs, struct
stack_trace *trace)
trace->entries[trace->nr_entries++] = ULONG_MAX;
}
-void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
+static noinline void __save_stack_trace(struct task_struct *tsk,
+ struct stack_trace *trace, unsigned int nosched)
{
struct stack_trace_data data;
struct stackframe frame;
@@ -150,15 +151,16 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct
stack_trace *trace)
data.trace = trace;
data.skip = trace->skip;
+ data.no_sched_functions = nosched;
if (tsk != current) {
- data.no_sched_functions = 1;
frame.fp = thread_saved_fp(tsk);
frame.pc = thread_saved_pc(tsk);
} else {
- data.no_sched_functions = 0;
+ /* We don't want this function nor the caller */
+ data.skip += 2;
frame.fp = (unsigned long)__builtin_frame_address(0);
- frame.pc = (unsigned long)save_stack_trace_tsk;
+ frame.pc = (unsigned long)__save_stack_trace;
}
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
frame.graph = tsk->curr_ret_stack;
@@ -172,9 +174,15 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct
stack_trace *trace)
}
EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
+void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
+{
+ __save_stack_trace(tsk, trace, 1);
+}
+
void save_stack_trace(struct stack_trace *trace)
{
- save_stack_trace_tsk(current, trace);
+ __save_stack_trace(current, trace, 0);
}
+
EXPORT_SYMBOL_GPL(save_stack_trace);
#endif
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/2] mm, page_owner: Skip unnecessary stack_trace entries
The page_owner stacktrace always begin as follows:
[] save_stack+0x40/0xc8
[] __set_page_owner+0x3c/0x6c
These two entries do not provide any useful information and limits the
available stacktrace depth. The page_owner stacktrace was skipping caller
function from stack entries but this was missed with commit f2ca0b557107
("mm/page_owner: use stackdepot to store stacktrace")
Example page_owner entry after the patch:
Page allocated via order 0, mask 0x8(ff80085fb714)
PFN 654411 type Movable Block 639 type CMA Flags 0x0(ffbe5c7f12c0)
[] post_alloc_hook+0x70/0x80
...
[] msm_comm_try_state+0x5f8/0x14f4
[] msm_vidc_open+0x5e4/0x7d0
[] msm_v4l2_open+0xa8/0x224
Fixes: f2ca0b557107 ("mm/page_owner: use stackdepot to store stacktrace")
Signed-off-by: Prakash Gupta
---
mm/page_owner.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_owner.c b/mm/page_owner.c
index 10d16fc45bd9..75b7c39bf1df 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -139,7 +139,7 @@ static noinline depot_stack_handle_t save_stack(gfp_t flags)
.nr_entries = 0,
.entries = entries,
.max_entries = PAGE_OWNER_STACK_DEPTH,
- .skip = 0
+ .skip = 2
};
depot_stack_handle_t handle;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
Re: [RFC PATCH v2 1/7] x86/paravirt: Add pv_idle_ops to paravirt ops
On 29/08/17 15:55, Konrad Rzeszutek Wilk wrote: > On Tue, Aug 29, 2017 at 11:46:35AM +, Yang Zhang wrote: >> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called in >> idle path which will polling for a while before we enter the real idle >> state. >> >> In virtualization, idle path includes several heavy operations >> includes timer access(LAPIC timer or TSC deadline timer) which will hurt >> performance especially for latency intensive workload like message >> passing task. The cost is mainly come from the vmexit which is a >> hardware context switch between VM and hypervisor. Our solution is to >> poll for a while and do not enter real idle path if we can get the >> schedule event during polling. >> >> Poll may cause the CPU waste so we adopt a smart polling mechanism to >> reduce the useless poll. >> >> Signed-off-by: Yang Zhang >> Signed-off-by: Quan Xu >> Cc: Jeremy Fitzhardinge >> Cc: Chris Wright >> Cc: Alok Kataria >> Cc: Rusty Russell >> Cc: Thomas Gleixner >> Cc: Ingo Molnar >> Cc: "H. Peter Anvin" >> Cc: x...@kernel.org >> Cc: Peter Zijlstra >> Cc: Andy Lutomirski >> Cc: "Kirill A. Shutemov" >> Cc: Pan Xinhui >> Cc: Kees Cook >> Cc: virtualizat...@lists.linux-foundation.org >> Cc: linux-kernel@vger.kernel.org > > Adding xen-devel. > > Juergen, we really should replace Jeremy's name with xen-devel or > your name.. I wouldn't mind being added. What does Jeremy think of being removed? > Wasn't there an patch by you that took some of the > mainternship over it? I added include/linux/hypervisor.h to the PARAVIRT section and offered to maintain it in case the PARAVIRT maintainers didn't want to. Juergen
Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface
Tue, Aug 29, 2017 at 05:57:54PM CEST, vivien.dide...@savoirfairelinux.com wrote:
>Hi David, Jiri,
>
>Jiri Pirko writes:
>
>> Tue, Aug 29, 2017 at 06:38:37AM CEST, da...@davemloft.net wrote:
>>>From: Vivien Didelot
>>>Date: Mon, 28 Aug 2017 15:17:38 -0400
>>>
This patch series adds a generic debugfs interface for the DSA
framework, so that all switch devices benefit from it, e.g. Marvell,
Broadcom, Microchip or any other DSA driver.
>>>
>>>I've been thinking this over and I agree with the feedback given that
>>>debugfs really isn't appropriate for this.
>>>
>>>Please create a DSA device class, and hang these values under
>>>appropriate sysfs device nodes that can be easily found via
>>>/sys/class/dsa/ just as easily as they would be /sys/kernel/debug/dsa/
>>>
>>>You really intend these values to be consistent across DSA devices,
>>>and you don't intend to go willy-nilly changig these exported values
>>>arbitrarily over time. That's what debugfs is for, throw-away
>>>stuff.
>>>
>>>So please make these proper device sysfs attributes rather than
>>>debugfs.
>>
>> As I wrote, I believe that there is a big overlap with devlink and its
>> dpipe subset. I think that primary we should focus on extending whatever
>> is needed for dsa there. The iface should be generic for all drivers,
>> not only dsa. dsa-specific sysfs attributes should be last-resort solution,
>> I believe we can avoid them.
>
>Please note that this interface is only meant to provide a _debug_ and
>_development_ interface to DSA users. It is enableable at compile time
>and can be ditched anytime we want, in contrary to other interfaces
>which cannot be broken or changed because they are part of the ABI.
>
>I see sysfs as a script-friendly way to access and configure kernel
>structures, so I agree with Jiri that it doesn't seem appropriate.
>
>Extending devlink is a good option for long term, but it'll take a bit
>of time to extend data structures and not duplicate stats and regs
>accesses for ports which have a net device attached to it or not.
>
>In the meantime, I didn't find anything more useful and easier to debug
>a switch fabric than dumping side-by-side stats of all ports part of the
>data plane, for example like this:
So in the meantime, if you need some quick ugly think, you can always
have it out of the tree. Sorry but these are just excuses :/
>
># watch -n1 pr -mt
> {switch0/port5,switch0/port6,switch1/port5,switch1/port3}/stats
>
>where ports 5 and 6 of both switches are DSA/CPU ports (without net
>devices attached to them) and port3 is a user port. This way one can
>easily see where and why packets get dropped.
>
>We could keep this interface and simply ditch net/dsa/debugfs.c when a
>convenient devlink alternative is in place.
>
>
>Thanks,
>
>Vivien
Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
On Wed, Aug 30, 2017 at 11:09:53AM +0900, Byungchul Park wrote:
> On Tue, Aug 29, 2017 at 10:59:39AM +0200, Peter Zijlstra wrote:
> > Subject: lockdep: Untangle xhlock history save/restore from task
> > independence
> >
> > Where XHLOCK_{SOFT,HARD} are save/restore points in the xhlocks[] to
> > ensure the temporal IRQ events don't interact with task state, the
> > XHLOCK_PROC is a fundament different beast that just happens to share
> > the interface.
> >
> > The purpose of XHLOCK_PROC is to annotate independent execution inside
> > one task. For example workqueues, each work should appear to run in its
> > own 'pristine' 'task'.
> >
> > Remove XHLOCK_PROC in favour of its own interface to avoid confusion.
>
> Much better to me than the patch you did previously, but, see blow.
>
> > Signed-off-by: Peter Zijlstra (Intel)
> > ---
> > diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> > index c0331891dec1..ab3c0dc8c7ed 100644
> > --- a/kernel/workqueue.c
> > +++ b/kernel/workqueue.c
> > @@ -2107,14 +2107,14 @@ __acquires(&pool->lock)
> > * Which would create W1->C->W1 dependencies, even though there is no
> > * actual deadlock possible. There are two solutions, using a
> > * read-recursive acquire on the work(queue) 'locks', but this will then
> > -* hit the lockdep limitation on recursive locks, or simly discard
> > +* hit the lockdep limitation on recursive locks, or simply discard
> > * these locks.
> > *
> > * AFAICT there is no possible deadlock scenario between the
> > * flush_work() and complete() primitives (except for single-threaded
> > * workqueues), so hiding them isn't a problem.
> > */
> > - crossrelease_hist_start(XHLOCK_PROC, true);
> > + lockdep_invariant_state(true);
>
> This is what I am always curious about. It would be ok if you agree with
> removing this work-around after fixing acquire things in wq. But, you
> keep to say this is essencial.
>
> You should focus on what dependencies actually are, than saparating
> contexts unnecessarily. Of course, we have to do it for each work, _BUT_
> not between outside of work and each work since there might be
> dependencies between them certainly.
You have never answered it. I'm curious about your answer. If you can't,
I think you have to revert all your patches. All yours are wrong.
Re: d82fed7529 ("locking/lockdep/selftests: Fix mixed read-write .."): BUG: -1 unexpected failures (out of 262) - debugging disabled! |
On Wed, Aug 30, 2017 at 08:29:47AM +0200, Peter Zijlstra wrote:
> On Wed, Aug 30, 2017 at 11:37:21AM +0800, kernel test robot wrote:
>
> > [0.004000]
> > -
> > [0.004000] BUG: -1 unexpected failures (out of 262) - debugging
> > disabled! |
> > [0.004000]
> > -
>
> lol.. however did that happen.. /me goes look.
Ah, I think this should cure..
---
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index cd0b5c964bd0..2b827b8a1d8c 100644
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -2031,11 +2031,13 @@ void locking_selftest(void)
print_testname("mixed read-lock/lock-write ABBA");
pr_cont(" |");
dotest(rlock_ABBA1, FAILURE, LOCKTYPE_RWLOCK);
+#ifdef CONFIG_PROVE_LOCKING
/*
* Lockdep does indeed fail here, but there's nothing we can do about
* that now. Don't kill lockdep for it.
*/
unexpected_testcase_failures--;
+#endif
pr_cont(" |");
dotest(rwsem_ABBA1, FAILURE, LOCKTYPE_RWSEM);
Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface
Tue, Aug 29, 2017 at 02:50:04PM CEST, and...@lunn.ch wrote:
>On Tue, Aug 29, 2017 at 08:25:23AM +0200, Jiri Pirko wrote:
>> Mon, Aug 28, 2017 at 10:08:34PM CEST, and...@lunn.ch wrote:
>> >> I see this overlaps a lot with DPIPE. Why won't you use that to expose
>> >> your hw state?
>> >
>> >We took a look at dpipe and i talked to you about using it for this
>> >sort of thing at netconf/netdev. But dpipe has issues displaying the
>> >sort of information we have. I never figured out how to do two
>> >dimensional tables. The output of the dpipe command is pretty
>> >unreadable. A lot of the information being dumped here is not about
>> >the data pipe, etc.
>>
>> So improve it. No problem. Also, we extend it to support what you neede.
>
>Will i did try to do this back in March. And i failed.
>
>Lets start with stats. Vivien gives an example on the cover letter:
>
># pr -mt switch0/port{5,6}/stats
>in_good_octets : 0 in_good_octets : 13824
>in_bad_octets : 0 in_bad_octets : 0
>in_unicast : 0 in_unicast : 0
>in_broadcasts : 0 in_broadcasts : 216
>in_multicasts : 0 in_multicasts : 0
>in_pause: 0 in_pause: 0
>in_undersize: 0 in_undersize: 0
>
>This is what i tried to implement using dpipe. It is a simple two
>dimensional table. First column is a string, second a u64. In debugfs
>we have such a table per port. That fits with the hierarchy that each
>port is a directory in debugfs. But it could also be implemented as
>one table with N+1 columns, for N switch ports.
Andrew, we talked about this in Montreal. What I suggested then was for
port stats to introduce devlink port statistics. Then you can have stats
for all sorts of ports that don't have netlink instance associated,
including cpu port. It aligns.
>
>How about you, or one of your team, implement that. It should be able
>to use the dsa_loop driver, which is a simple dummy switch. But it
>does have statistics counters for all ports. Florian or I can help you
>get it running if needed.
>
>This branch contains some of the basic plumbing code from my previous
>attempt:
>
>https://github.com/lunn/linux.git v4.11-rc4-net-next-dpipe
>
>Andrew
>
Re: [PATCH v2] USB: serial: option: add support for D-Link DWM-157 C1
On Tue, Aug 29, 2017 at 09:50:03PM +0200, Maciej S. Szmigiero wrote: > This commit adds support (an ID, really) for D-Link DWM-157 hardware > version C1 USB modem to option driver. > > According to manufacturer-provided Windows INF file the device has four > serial ports: > "D-Link HSPA+DataCard Diagnostics Interface" (interface 2; modem port), > "D-Link HSPA+DataCard NMEA Device" (interface 3), > "D-Link HSPA+DataCard Speech Port" (interface 4), > "D-Link HSPA+DataCard Debug Port" (interface 5). > > usb-devices output: > T: Bus=05 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=2001 ProdID=7d0e Rev=03.00 > S: Manufacturer=D-Link,Inc > S: Product=D-Link DWM-157 > C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA > I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim > I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim > I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option > I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option > I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option > I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option > I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > > Signed-off-by: Maciej S. Szmigiero > Cc: sta...@vger.kernel.org > --- > Changes from v1: Match the whole vendor-specific interface class instead > of particular interface subclasses and protocols, add usb-devices output > to the commit message. Thanks for the v2, now applied. Johan
Re: [PATCH] USB: serial: option: simplify 3 D-Link device entries
On Tue, Aug 29, 2017 at 04:41:21PM +0200, Johan Hovold wrote: > On Tue, Aug 29, 2017 at 10:45:13AM +0200, Bjørn Mork wrote: > > All the vendor specific interfaces on these devices are serial > > functions handled by this driver, so we can use a single class > > match entry for each. > > > > P: Vendor=2001 ProdID=7d01 Rev= 3.00 > > S: Manufacturer=D-Link,Inc > > S: Product=D-Link DWM-156 > > C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA > > A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 > > I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim > > E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=125us > > I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim > > I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim > > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option > > E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us > > E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option > > E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option > > E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option > > E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > > E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > > > Signed-off-by: Bjørn Mork > > --- > > > > Johan Hovold writes: > > > > > Do you want to submit a patch or should I do it? > > > > Well, I can save you that job if this is fine with you. Feel > > free to add a stable cc if you think it is appropriate. I am not > > sure... > > Thanks! Yeah, not sure about stable either. Maybe I'll just apply this > one on top the new entry coming in, and we can defer the decision to the > stable maintainers next time there's a backport conflict. Now applied (without stable-CC). Thanks, Johan
Re: [PATCH v2] mm/hugetlb.c: make huge_pte_offset() consistent and document behaviour
On Fri 18-08-17 15:54:15, Punit Agrawal wrote:
> When walking the page tables to resolve an address that points to
> !p*d_present() entry, huge_pte_offset() returns inconsistent values
> depending on the level of page table (PUD or PMD).
>
> It returns NULL in the case of a PUD entry while in the case of a PMD
> entry, it returns a pointer to the page table entry.
>
> A similar inconsitency exists when handling swap entries - returns NULL
> for a PUD entry while a pointer to the pte_t is retured for the PMD entry.
>
> Update huge_pte_offset() to make the behaviour consistent - return a
> pointer to the pte_t for hugepage or swap entries. Only return NULL in
> instances where we have a p*d_none() entry and the size parameter
> doesn't match the hugepage size at this level of the page table.
>
> Document the behaviour to clarify the expected behaviour of this function.
> This is to set clear semantics for architecture specific implementations
> of huge_pte_offset().
>
> Signed-off-by: Punit Agrawal
> Cc: Catalin Marinas
> Cc: Naoya Horiguchi
> Cc: Steve Capper
> Cc: Will Deacon
> Cc: Kirill A. Shutemov
> Cc: Michal Hocko
> Cc: Mike Kravetz
I always thought that the weird semantic is a result of the hugetlb pte
sharing. But now that I dug into history it has been added by
02b0ccef903e ("[PATCH] hugetlb: check p?d_present in huge_pte_offset()")
for a completely different reason. I suspec the weird semantic just
wasn't noticed back then.
Anyway, I didn't find any problem with the patch
Acked-by: Michal Hocko
> ---
>
> Hi Andrew,
>
> >From discussions on the arm64 implementation of huge_pte_offset()[0]
> we realised that there is benefit from returning a pte_t* in the case
> of p*d_none().
>
> The fault handling code in hugetlb_fault() can handle p*d_none()
> entries and saves an extra round trip to huge_pte_alloc(). Other
> callers of huge_pte_offset() should be ok as well.
>
> Apologies for sending a late update but I thought if we are defining
> the semantics, it's worth getting them right.
>
> Could you please pick this version please?
>
> Thanks,
> Punit
>
> [0] http://www.spinics.net/lists/linux-mm/msg133699.html
>
> v2:
>
> mm/hugetlb.c | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 31e207cb399b..1d54a131bdd5 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4600,6 +4600,15 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
> return pte;
> }
>
> +/*
> + * huge_pte_offset() - Walk the page table to resolve the hugepage
> + * entry at address @addr
> + *
> + * Return: Pointer to page table or swap entry (PUD or PMD) for
> + * address @addr, or NULL if a p*d_none() entry is encountered and the
> + * size @sz doesn't match the hugepage size at this level of the page
> + * table.
> + */
> pte_t *huge_pte_offset(struct mm_struct *mm,
> unsigned long addr, unsigned long sz)
> {
> @@ -4614,13 +4623,22 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
> p4d = p4d_offset(pgd, addr);
> if (!p4d_present(*p4d))
> return NULL;
> +
> pud = pud_offset(p4d, addr);
> - if (!pud_present(*pud))
> + if (sz != PUD_SIZE && pud_none(*pud))
> return NULL;
> - if (pud_huge(*pud))
> + /* hugepage or swap? */
> + if (pud_huge(*pud) || !pud_present(*pud))
> return (pte_t *)pud;
> +
> pmd = pmd_offset(pud, addr);
> - return (pte_t *) pmd;
> + if (sz != PMD_SIZE && pmd_none(*pmd))
> + return NULL;
> + /* hugepage or swap? */
> + if (pmd_huge(*pmd) || !pmd_present(*pmd))
> + return (pte_t *)pmd;
> +
> + return NULL;
> }
>
> #endif /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
> --
> 2.13.2
>
--
Michal Hocko
SUSE Labs
Re: [PATCH v3 3/3] eeprom: at24: enable runtime pm support
Hi Divagar,
Thanks for the update. A few more comments below.
On Wed, Aug 30, 2017 at 09:41:06AM +0530, Divagar Mohandass wrote:
> Currently the device is kept in D0, there is an opportunity
> to save power by enabling runtime pm.
>
> Device can be daisy chained from PMIC and we can't rely on I2C core
> for auto resume/suspend. Driver will decide when to resume/suspend.
>
> Signed-off-by: Divagar Mohandass
> ---
> drivers/misc/eeprom/at24.c | 39 +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 2199c42..a670814 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
> @@ -501,11 +502,22 @@ static ssize_t at24_eeprom_write_i2c(struct at24_data
> *at24, const char *buf,
> static int at24_read(void *priv, unsigned int off, void *val, size_t count)
> {
> struct at24_data *at24 = priv;
> + struct i2c_client *client;
> char *buf = val;
> + int ret;
>
> if (unlikely(!count))
> return count;
>
> + client = at24_translate_offset(at24, &off);
> +
> + ret = pm_runtime_get_sync(&client->dev);
> + if (ret < 0) {
> + pm_runtime_put_noidle(&client->dev);
> + pm_runtime_put(&client->dev);
Two puts are too much here. How about dropping this one?
> + return ret;
> + }
> +
> /*
>* Read data from chip, protecting against concurrent updates
>* from this host, but not from other I2C masters.
If an error happens between the two chunks, you'll need pm_runtime_put(),
too.
> @@ -527,17 +539,30 @@ static int at24_read(void *priv, unsigned int off, void
> *val, size_t count)
>
> mutex_unlock(&at24->lock);
>
> + pm_runtime_put(&client->dev);
> +
> return 0;
> }
>
> static int at24_write(void *priv, unsigned int off, void *val, size_t count)
> {
> struct at24_data *at24 = priv;
> + struct i2c_client *client;
> char *buf = val;
> + int ret;
>
> if (unlikely(!count))
> return -EINVAL;
>
> + client = at24_translate_offset(at24, &off);
> +
> + ret = pm_runtime_get_sync(&client->dev);
> + if (ret < 0) {
> + pm_runtime_put_noidle(&client->dev);
> + pm_runtime_put(&client->dev);
Same here.
> + return ret;
> + }
> +
> /*
>* Write data to chip, protecting against concurrent updates
>* from this host, but not from other I2C masters.
Ditto.
> @@ -559,6 +584,8 @@ static int at24_write(void *priv, unsigned int off, void
> *val, size_t count)
>
> mutex_unlock(&at24->lock);
>
> + pm_runtime_put(&client->dev);
> +
> return 0;
> }
>
> @@ -743,6 +770,15 @@ static int at24_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
>
> i2c_set_clientdata(client, at24);
>
> + /* enable runtime pm */
> + pm_runtime_get_noresume(&client->dev);
> + err = pm_runtime_set_active(&client->dev);
> + if (err < 0)
> + goto err_clients;
> +
> + pm_runtime_enable(&client->dev);
> + pm_runtime_put(&client->dev);
> +
You're just about to perform a read here. I believe you should move the
last put after that.
> /*
>* Perform a one-byte test read to verify that the
>* chip is functional.
> @@ -810,6 +846,9 @@ static int at24_remove(struct i2c_client *client)
> for (i = 1; i < at24->num_addresses; i++)
> i2c_unregister_device(at24->client[i]);
>
> + pm_runtime_disable(&client->dev);
> + pm_runtime_set_suspended(&client->dev);
> +
> return 0;
> }
>
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi
[PATCH] Input: synaptics - Lenovo Thinkpad X1 Carbon G5 (2017) with Elantech trackpoints should use RMI.
From: Edvard Holst
Lenovo use two different trackpoints in the fifth generation Thinkpad X1
Carbon. Both are accessible over SMBUS/RMI but the pnpIDs are missing. This
patch is for the Elantech trackpoint specifically which also reports SMB
version 3 so rmi_smbus needs to be updated in order to handle it.
For the record, I was not the first one to come up with this patch as it has
been floating around the internet for a while now. However, I have spent
significant time with testing and my efforts to find the original author of the
patch have been unsuccessful.
Signed-off-by: Edvard Holst
---
drivers/input/mouse/synaptics.c | 1 +
drivers/input/rmi4/rmi_smbus.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 16c30460ef04..d44f1395c379 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -173,6 +173,7 @@ static const char * const smbus_pnp_ids[] = {
"LEN0046", /* X250 */
"LEN004a", /* W541 */
"LEN200f", /* T450s */
+"LEN0073", /* X1 Carbon G5 (Elantech) */
NULL
};
diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
index 225025a0940c..2939a2f72019 100644
--- a/drivers/input/rmi4/rmi_smbus.c
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -322,7 +322,7 @@ static int rmi_smb_probe(struct i2c_client *client,
rmi_dbg(RMI_DEBUG_XPORT, &client->dev, "Smbus version is %d",
smbus_version);
- if (smbus_version != 2) {
+ if (smbus_version != 2 && smbus_version != 3) {
dev_err(&client->dev, "Unrecognized SMB version %d\n",
smbus_version);
return -ENODEV;
--
2.13.5
Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver
On 08/28/2017 01:48 PM, Peter Ujfalusi wrote: > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > Thanks for your invaluable inputs. This is more clear now and revise my driver > > I would not bother with mixed use case here, I would just make it > mandatory to go via the router. > I couldn't agree more. But it seems to me there is a flaw here. This should be possible though. I will likely look at that later on. A new revision of this driver will come soon ;) > > - Péter > Py
Re: [PATCH v3] mfd: tps65217: Introduce dependency on CONFIG_OF
Hello Keerthy,
On Wed, Aug 30, 2017 at 7:50 AM, Keerthy wrote:
> Currently the driver boots only via device tree hence add a
> dependency on CONFIG_OF. This leaves with a bunch of unused code
> so clean that up. This patch also makes use of probe_new function
> in place of the probe function so as to avoid passing i2c_device_id.
>
> Signed-off-by: Keerthy
> ---
>
> Changes in v3:
>
> * Added more details to commit log.
> * No changes in code. Rebased to latest next branch.
>
> Changes in v2:
>
> * Cleaned up chip_id and data attached to the match.
> * Cleaned up i2c_dev_id
> * dropped the rest of the patches in series for now
>
> Boot tested and checked for regulator registrations on am335x-boneblack
>
Did you check building as a module? Autoload won't work if you remove
the I2C device ID table.
[snip]
>
> -static const struct i2c_device_id tps65217_id_table[] = {
> - {"tps65217", TPS65217},
> - { /* sentinel */ }
> -};
> -MODULE_DEVICE_TABLE(i2c, tps65217_id_table);
> -
Unfortunately this can't be removed yet. We are getting there but
still some patches need to land.
Rest of the patch looks good, so if you keep the I2C device ID table
feel free to add:
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
Re: [PATCH v2 15/30] xfs: Define usercopy region in xfs_inode slab cache
On Wed, Aug 30, 2017 at 12:14:03AM -0700, Christoph Hellwig wrote:
> On Wed, Aug 30, 2017 at 07:51:57AM +1000, Dave Chinner wrote:
> > Right, I've looked at btrees, too, but it's more complex than just
> > using an rbtree. I originally looked at using Peter Z's old
> > RCU-aware btree code, but it doesn't hold data in the tree leaves.
> > So that needed significant modification to make work without a
> > memory alloc per extent and that didn't work with original aim of
> > RCU-safe extent lookups. I also looked at that "generic" btree
> > stuff that came from logfs, and after a little while ran away
> > screaming.
>
> I started with the latter, but it's not really looking like it any more:
> there nodes are formatted as a series of u64s instead of all the
> long magic,
Yeah, that was about where I started to run away and look for
something nicer
> and the data is stored inline - in fact I use a cute
> trick to keep the size down, derived from our "compressed" on disk
> extent format:
>
> Key:
>
> +---++
> | 00:51 | all 52 bits of startoff|
> | 52:63 | low 12 bits of startblock |
> +---++
>
> Value
>
> +---++
> | 00:20 | all 21 bits of length |
> |21 | unwritten extent bit |
> | 22:63 | high 42 bits of startblock |
> +---++
>
> So we only need a 64-bit key and a 64-bit value by abusing parts
> of the key to store bits of the startblock.
Neat! :)
> For non-leaf nodes we iterate through the keys only, never touching
> the cache lines for the value. For the leaf nodes we have to touch
> the value anyway because we have to do a range lookup to find the
> exact record.
>
> This works fine so far in an isolated simulator, and now I'm ammending
> it to be a b+tree with pointers to the previous and next node so
> that we can nicely implement our extent iterators instead of doing
> full lookups.
Ok, that sounds exactly what I have been looking towards
> > The sticking point, IMO, is the extent array index based lookups in
> > all the bmbt code. I've been looking at converting all that to use
> > offset based lookups and a cursor w/ lookup/inc/dec/insert/delete
> > ioperations wrapping xfs_iext_lookup_ext() and friends. This means
> > the modifications are pretty much identical to the on-disk extent
> > btree, so they can be abstracted out into a single extent update
> > interface for both trees. Have you planned/done any cleanup/changes
> > with this code?
>
> I've done various cleanups, but I've not yet consolidated the two.
> Basically step one at the moment is to move everyone to
> xfs_iext_lookup_extent + xfs_iext_get_extent that removes all the
> bad intrusion.
Yup.
> Once we move to the actual b+trees the extnum_t cursor will be replaced
> with a real cursor structure that contains a pointer to the current
> b+tree leaf node, and an index inside that, which will allows us very
> efficient iteration. The xfs_iext_get_extent calls will be replaced
> with more specific xfs_iext_prev_extent, xfs_iext_next_extent calls
> that include the now slightly more complex cursor decrement, increment
> as well as a new xfs_iext_last_extent helper for the last extent
> that we need in a few places.
Ok, that's sounds like it'll fit right in with what I've been
prototyping for the extent code in xfs_bmap.c. I can make that work
with a cursor-based lookup/inc/dec/ins/del API similar to the bmbt
API. I've been looking to abstract the extent manipulations out into
functions that modify both trees like this:
[note: just put template code in to get my thoughts straight, it's
not working code]
+static int
+xfs_bmex_delete(
+ struct xfs_iext_cursor *icur,
+ struct xfs_btree_cursor *cur,
+ int *nextents)
+{
+ int i;
+
+ xfs_iext_remove(bma->ip, bma->idx + 1, 2, state);
+ if (nextents)
+ (*nextents)--;
+ if (!cur)
+ return 0;
+ error = xfs_btree_delete(cur, &i);
+ if (error)
+ return error;
+ XFS_WANT_CORRUPTED_RETURN(cur->bc_mp, i == 1);
+ return 0;
+}
+
+static int
+xfs_bmex_increment(
+ struct xfs_iext_cursor *icur,
+ struct xfs_btree_cursor *cur)
+{
+ int i;
+
+ icur->ep = xfs_iext_get_right_ext(icur->ep);
+ if (!cur)
+ return 0;
+ error = xfs_btree_increment(cur, 0, &i);
+ if (error)
+ return error;
+ XFS_WANT_CORRUPTED_RETURN(cur->bc_mp, i == 1);
+ return 0;
+}
+
+static int
+xfs_bmex_decrement(
+ struct xfs_iext_cursor *icur,
+ struct xfs_btree_cursor *cur)
+{
+ int i;
+
+ icur->ep = xfs_iext_get_left_ext(icur->ep);
+ if (!cur)
+ return 0;
+ error =
Re: I/O hangs after resuming from suspend-to-ram
Hi, On Wed, Aug 30, 2017 at 08:15:02AM +0200, oleksa...@natalenko.name wrote: > Hello. > > Addressing your questions below. > > > Can't reproduce even with putting dmcypt on raid10 after applying my > > patch. > > Just a side note, that dm-crypt is not necessary here — I am able to trigger > hang with RAID10 and LVM only. > > > BTW, could you share us which blk-mq scheduler you are using on sata? > > Okay, now it makes sense. Previously, without your patch I was able to > reproduce the issue with "mq-deadline", "bfq" and "none". Now, I cannot > trigger it with "none" set, but "mq-deadline" still hangs for me. Does this > mean each scheduler should be modified separately? No, it shouldn't. > > > Could you apply the following debug patch and provide the dmesg log > > after running the commands below? > > Is it still relevant since I confirm issue to be fixed with "none"? Please try the following patch and previous patch together and see if they make a difference: >From bc5626b4b65c7ff26567e75f42584c2c43ffe7c1 Mon Sep 17 00:00:00 2001 From: Ming Lei Date: Wed, 30 Aug 2017 15:53:01 +0800 Subject: [PATCH] blk-mq: add requests in the tail of hctx->dispatch So that we can allow to insert request at the head of hctx->dispatch. Signed-off-by: Ming Lei --- block/blk-mq-sched.c | 2 +- block/blk-mq.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c index a026fb47..b40dd063d61f 100644 --- a/block/blk-mq-sched.c +++ b/block/blk-mq-sched.c @@ -272,7 +272,7 @@ static bool blk_mq_sched_bypass_insert(struct blk_mq_hw_ctx *hctx, * the dispatch list. */ spin_lock(&hctx->lock); - list_add(&rq->queuelist, &hctx->dispatch); + list_add_tail(&rq->queuelist, &hctx->dispatch); spin_unlock(&hctx->lock); return true; } diff --git a/block/blk-mq.c b/block/blk-mq.c index 4603b115e234..fed3d0c16266 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1067,7 +1067,7 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list) blk_mq_put_driver_tag(rq); spin_lock(&hctx->lock); - list_splice_init(list, &hctx->dispatch); + list_splice_tail_init(list, &hctx->dispatch); spin_unlock(&hctx->lock); /* -- 2.9.5 -- Ming
(Kernel Bug report) Make kaby lake cpu crash Ethernet
Hello Sir, i am using cpu i7 7700k kaby lake, i have no overclock the CPU but i think i7 7700k come across with Ethernet crash issue. Don't know why it will keeping crash. I tested the kernel since 4.8 - 4.12 almost 2-3months and i can see that the issue is still exist. Kernel error then the Ethernet is stop responded after that machine crash, i need to force reboot the computer. PS: there are no cpu overclock , latest Bios ver. Centos7 with 4.12.8 kernel Thank you for your help! Error Log enp:s 6: Reset adapter unexpectedly[47438.8192131 e1808e 8000:88:11.6 enp8s31f6: Reset adapter unexpectedly [112822.759818] el008e 8800:88:1f.6 enp0s3116: Reset adapter unexpectedly 1112838.119047] el888e 8808:80:1f.6 enp8s31f6: Reset adapter unexpectedly [112852-967086] e1800e 8000:00:11.6 enp8s31f6: Reset adapter unexpectedly 1128194.823488] e1000e 0008:80:1f.6 enp8s31f6: Reset adapter unexpectedly [128213.991461] e1808e :00:11.6 enp8s31f6: Reset adapter unexpectedly [128228.839481] 0.800e :08:1f.6 enp8s31f6: Reset adapter unexpectedly [128283.111491] el880e 0808:08:11.6 enp0s31f6: Reset adapter unexpectedly [123287.815631] e1800e :08:11.6 enp8s31f6: Reset adapter unexpectedly 1124878.8237221 el888e 0088:00:1f.6 enp0s3116: Reset adapter unexpectedly [124878.843883] kernel BUG at drivers/net/ethernet/intel/e1880e/netdev.c:38111 [124878.843832] invalid opcode: 8088 [*1] SHP [124878.843847] Modules linked in: vfat fat x86_pkg temp_thermal intel_powerclamp coretemp kvm_intel kvm irgbypass crctledif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel hci_uart crypto_simd btbcm glue_helper iltOwdt cryptd btq ca iTCO_vendor_support btintel mxm_wmi intel_cstate intel_rapl_perf ac_i881 pcspkr shpchp sg joydev bluetooth input_leds wmi ecdh_generic mei_me rfkill mei intel_lpss_acpi acpi_als intel_lpss intel_pch_thermal mfd_core kfifo_buf acpi_pad ndustrialio tcp_bbr sch_fg ip_tables xfs libcrc32c sd_mod i915 i2c_algo_bit crc32c_intel drm_kms_helper syscopyarea e1000e sysfillrect ahci sysimgblt fb_sys_fops libahci ptp pps_core libata drm video i2c_hid dm_mirror dm_region_hash dm_log dm_mod dax [124878.844060] CPU: 8 PID: 25374 Comm: kworker/0:2 Tainted: G W 4.12.8-1.e17.elrepo.x86_64 *1 [124878.844890] Hardware name: To Be Filled By O.E.M. To Be Filled By 0.E.M./2170 Pro4, BIOS P7.38 11/28/2016 [124878.844127] Workqueue: events e1000_reset_task [e1000e] 1124878.844146] task: Ifff88869e482e80 task.stack: ff1fc90820044800 1124878.844170] RIP: 0010:e1080_flush_desc rings+8x2ea/8x2f8 [e1000e] [124878.844191] RSP: 0018:f11fc900213047d68 EFLAGS: 00810202 [124878.844289] MX: 0884 RBX: 88084b42c8c0 RCX: 00880099 [124878.844233] RDX: 0084 RSI: 808000800246 RDI: 88000246 [124878.844256] RBP: 11ffc90028047d98 R08: 08088002 R09: c90020047d1c [124878.844288] R18: 808008fe R11: 8808008083c7 R12: 8808517a3880 [124878.844384] R13: 111f4b42cd78 R14: 3103f01a R15: 04008000 [124878.844328] FS: 88808e88eee0(088e) GS:aff75c01] knlGS:000880880800 [124878.844354] CS: 0010 DS: ES: C1t8: 88058033 [124878.844374] CR2: 08007f7031eb8808 CR3: 8080080001c09000 CR4: 003406f0 [124878.844397] DR8: 80880008 DR1: 8000 DR2: 0800 [124878.844421] DR3: 008000880888 DR6: 8880fffeO110 DR7: 00808400 [124878.84] Call Trace: 1124878.844468] e1880e_reset*8x4b4/8x750 [e1000e] [124878.844479] el080e_down+8xle3/0x210 [e1808e] [124878.844497] el080e_reinit_locked+0x31/0x60 [e1880e] [124878.844518] e1008_reset_task+8x32/0x68 [e1800e] [124878.844536] process_one_work+8x149/8x368 [124878.844552] worker_thread+8x4d/8x3c0 [124878.8445661 kthread+8x109/0x148 [124878.844579] ? rescuer thread+8x300/0x380 [124878.844594] ? kthread_park+8x68/0x60 [124878.844689] ? do_syscall_64+0x67/0x158 [124878.844624] ret from fork+Ox25/0x30 [124878.844637] Code: 98 e9 Be ff ff ff 4c 89 of e8 d3 fc ff ff Of if 00 e9 14 fe ff ff 31 c0 45 31 f6 66 41 89 44 24 20 e9 71 fe ff ff e8 36 73 ed e0 IA Of 11 40 00 Of 11 44 00 00 55 48 89 e5 41 57 41 56 41 55 [124878.844716] RIP: e1008_flush_desc_rings+Bx2ea/Ox2f8 [e1000e] RSP: c98020047d68 [124878.844760] ---[ end trace 4ce09c8c366f79e7 ]- [124878.844777] Kernel panic - not syncing: Fatal exception [124878.844825] Kernel Offset: disabled [124878.844833] ---[ end Kernel panic - not syncing : Fatal exception
Re: kvm splat in mmu_spte_clear_track_bits
On Tue 29-08-17 16:09:24, Andrea Arcangeli wrote: [...] > The other bug where you can reproduce the same corruption with OOM is > unrelated and caused by the OOM reaper. OOM reaper was even corrupting > data if a task was writing to disk and stuck in OOM in write() syscall > or async io write. > > To fix the KVM corruption in the OOM reaper, it needs to call > mmu_notifier_invalidate_start/end around > oom_kill.c:unmap_page_range. This additional > mmu_notifier_invalidate_start will not be good for the OOM reaper > because it's yet another case (like the mmap_sem for writing) that > will prevent the OOM reaper to run, so hindering its ability to hide > XFS OOM deadlocks, and making those resurface. Not in KVM case because > we use a spinlock to serialize against the secondary MMU activity and > the KVM critical section under spinlock isn't going to allocate > memory, but range_start can schedule or block on slow hardware where > the secondary MMU is accessed through PCI (not KVM case). I am not really familiar with mmu notifiers and what they can actually do. But from what you wrote above it is indeed not very safe to call them from the oom reaper. So I will prepare and post a patch to disable the reaper when mm_has_notifiers(). Thanks for pointing this out. -- Michal Hocko SUSE Labs
Re: (Kernel Bug report) Make kaby lake cpu crash Ethernet
On Wed, Aug 30, 2017 at 04:16:54PM +0800, Chiwu Yung wrote: > Hello Sir, i am using cpu i7 7700k kaby lake, i have no overclock the > CPU but i think i7 7700k come across with Ethernet crash issue. Don't > know why it will keeping crash. > I tested the kernel since 4.8 - 4.12 almost 2-3months and i can see > that the issue is still exist. > Kernel error then the Ethernet is stop responded after that machine > crash, i need to force reboot the computer. > > PS: there are no cpu overclock , latest Bios ver. Centos7 with 4.12.8 kernel > > Thank you for your help! > > > Error Log > > enp:s 6: Reset adapter unexpectedly[47438.8192131 e1808e 8000:88:11.6 > enp8s31f6: Reset adapter unexpectedly > [112822.759818] el008e 8800:88:1f.6 enp0s3116: Reset adapter > unexpectedly 1112838.119047] el888e 8808:80:1f.6 enp8s31f6: Reset > adapter unexpectedly > [112852-967086] e1800e 8000:00:11.6 enp8s31f6: Reset adapter > unexpectedly 1128194.823488] e1000e 0008:80:1f.6 enp8s31f6: Reset > adapter unexpectedly > [128213.991461] e1808e :00:11.6 enp8s31f6: Reset adapter unexpectedly > [128228.839481] 0.800e :08:1f.6 enp8s31f6: Reset adapter unexpectedly > [128283.111491] el880e 0808:08:11.6 enp0s31f6: Reset adapter unexpectedly > [123287.815631] e1800e :08:11.6 enp8s31f6: Reset adapter > unexpectedly 1124878.8237221 el888e 0088:00:1f.6 enp0s3116: Reset > adapter unexpectedly > [124878.843883] kernel BUG at drivers/net/ethernet/intel/e1880e/netdev.c:38111 That driver is not in the kernel.org releases, so there's nothing we can do about it. Please contact the authors of the driver you are using here, wherever you downloaded it from, and they can help you out. good luck! greg k-h
Re: [PATCH 3/7] ARM: dts: sun8i: h3: Enable dwmac-sun8i on the Nanopi M1 Plus
On Wed, Aug 30, 2017 at 11:01 AM, Philipp Rossak wrote: > From: Philipp Rossak > > The dwmac-sun8i hardware is present on the Nanopi M1 Plus. Support for this has been reverted. Please send this once it has been added again. ChenYu > It uses an external PHY. > > Signed-off-by: Philipp Rossak
[PATCH net-next v4 03/13] Documentation/bindings: phy: document the Marvell comphy driver
The Marvell Armada 7K/8K SoCs contains an hardware block called COMPHY
that provides a number of shared PHYs used by various interfaces in the
SoC: network, SATA, PCIe, etc. This Device Tree binding allows to
describe this COMPHY hardware block.
Signed-off-by: Antoine Tenart
---
.../devicetree/bindings/phy/phy-mvebu-comphy.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt
b/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt
new file mode 100644
index ..bfcf80341657
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt
@@ -0,0 +1,43 @@
+mvebu comphy driver
+---
+
+A comphy controller can be found on Marvell Armada 7k/8k on the CP110. It
+provides a number of shared PHYs used by various interfaces (network, sata,
+usb, PCIe...).
+
+Required properties:
+
+- compatible: should be "marvell,comphy-cp110"
+- reg: should contain the comphy register location and length.
+- marvell,system-controller: should contain a phandle to the
+ system controller node.
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+
+A sub-node is required for each comphy lane provided by the comphy.
+
+Required properties (child nodes):
+
+- reg: comphy lane number.
+- #phy-cells : from the generic phy bindings, must be 1. Defines the
+ input port to use for a given comphy lane.
+
+Example:
+
+ cpm_comphy: phy@12 {
+ compatible = "marvell,comphy-cp110";
+ reg = <0x12 0x6000>;
+ marvell,system-controller = <&cpm_syscon0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpm_comphy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+
+ cpm_comphy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <1>;
+ };
+ };
--
2.13.5
[PATCH net-next v4 11/13] arm64: dts: marvell: mcbin: add comphy references to Ethernet ports
This patch adds comphy phandles to the Ethernet ports in the mcbin
device tree. The comphy is used to configure the serdes PHYs used by
these ports.
Signed-off-by: Antoine Tenart
---
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index 9f0a00802452..970081ca197b 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -148,6 +148,7 @@
&cpm_eth0 {
status = "okay";
phy = <&phy0>;
+ phys = <&cpm_comphy4 0>;
phy-mode = "10gbase-kr";
};
@@ -181,6 +182,7 @@
&cps_eth0 {
status = "okay";
phy = <&phy8>;
+ phys = <&cps_comphy4 0>;
phy-mode = "10gbase-kr";
};
@@ -189,6 +191,7 @@
status = "okay";
phy = <&ge_phy>;
phy-mode = "sgmii";
+ phys = <&cps_comphy0 1>;
};
&cps_sata0 {
--
2.13.5
[PATCH net-next v4 13/13] arm64: defconfig: enable Marvell CP110 comphy
From: Miquel Raynal The comphy is an hardware block giving access to common PHYs that can be used by various other engines (Network, SATA, ...). This is used on Marvell 7k/8k platforms for now. Enable the corresponding driver. Signed-off-by: Miquel Raynal Signed-off-by: Antoine Tenart --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 6b26a05ae5b4..d453ba50df43 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -510,6 +510,7 @@ CONFIG_PWM_TEGRA=m CONFIG_PHY_RCAR_GEN3_USB2=y CONFIG_PHY_HI6220_USB=y CONFIG_PHY_SUN4I_USB=y +CONFIG_PHY_MVEBU_CP110_COMPHY=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_PHY_ROCKCHIP_EMMC=y CONFIG_PHY_ROCKCHIP_PCIE=m -- 2.13.5
[PATCH net-next v4 08/13] net: mvpp2: dynamic reconfiguration of the comphy/GoP/MAC
This patch adds logic to reconfigure the comphy/GoP/MAC when the link
state is updated at runtime. This is very useful on boards where many
link speed are supported: depending on what is negotiated the PPv2
driver will automatically reconfigures the link between the PHY and the
MAC.
Signed-off-by: Antoine Tenart
---
drivers/net/ethernet/marvell/mvpp2.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index 2f05a0b0773c..9e64b1ba3d43 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5771,9 +5771,28 @@ static void mvpp2_link_event(struct net_device *dev)
{
struct mvpp2_port *port = netdev_priv(dev);
struct phy_device *phydev = dev->phydev;
+ bool link_reconfigured = false;
u32 val;
if (phydev->link) {
+ if (port->phy_interface != phydev->interface && port->comphy) {
+ /* disable current port for reconfiguration */
+ mvpp2_interrupts_disable(port);
+ netif_carrier_off(port->dev);
+ mvpp2_port_disable(port);
+ phy_power_off(port->comphy);
+
+ /* comphy reconfiguration */
+ port->phy_interface = phydev->interface;
+ mvpp22_comphy_init(port);
+
+ /* gop/mac reconfiguration */
+ mvpp22_gop_init(port);
+ mvpp2_port_mii_set(port);
+
+ link_reconfigured = true;
+ }
+
if ((port->speed != phydev->speed) ||
(port->duplex != phydev->duplex)) {
mvpp2_gmac_set_autoneg(port, phydev);
@@ -5783,7 +5802,7 @@ static void mvpp2_link_event(struct net_device *dev)
}
}
- if (phydev->link != port->link) {
+ if (phydev->link != port->link || link_reconfigured) {
port->link = phydev->link;
if (phydev->link) {
--
2.13.5
Re: [PATCH] drm: vmwgfx: constify vmw_fence_ops
On Wed, Aug 30, 2017 at 08:21:46AM +0200, Thomas Hellstrom wrote:
> On 08/30/2017 07:47 AM, Arvind Yadav wrote:
> > vmw_fence_ops are not supposed to change at runtime. Functions
> > "dma_fence_init" working with const vmw_fence_ops provided
> > by . So mark the non-const structs as const.
> >
> > Signed-off-by: Arvind Yadav
> > ---
> > drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> > index b8bc5bc..abc5f03 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> > @@ -225,7 +225,7 @@ static long vmw_fence_wait(struct dma_fence *f, bool
> > intr, signed long timeout)
> > return ret;
> > }
> > -static struct dma_fence_ops vmw_fence_ops = {
> > +static const struct dma_fence_ops vmw_fence_ops = {
> > .get_driver_name = vmw_fence_get_driver_name,
> > .get_timeline_name = vmw_fence_get_timeline_name,
> > .enable_signaling = vmw_fence_enable_signaling,
>
> Reviewed-by: Thomas Hellstrom
Does this mean you'll merge it, or does this mean you'll expect someone
else to merge this?
I'm always confused when maintainers reply with an r-b/ack for a patch
only touching their driver, and no further information at all.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v6 1/3] perf/core: use rb trees for pinned/flexible groups
On 29.08.2017 16:51, Alexander Shishkin wrote:
> Alexey Budankov writes:
>
>> Now I figured that not all indexed events are always located under
>> the root with the same cpu, and it depends on the order of insertion
>> e.g. with insertion order 01,02,03,14,15,16 we get this:
>>
>> 02
>> / \
>>01 14
>> / \
>> 03 15
>>\
>>16
>>
>> and it is unclear how to iterate cpu==0 part of tree in this case.
>
> Using this example, rb_next() should take you through the nodes in this
> order (assuming you start with 01): 01, 02, 03, 14, etc. So you iterate
> while event->cpu==cpu using rb_next() and you should be fine.
Well, indeed we get the most left leaf (03) in rb_next() for the case above.
>
>> Iterating cpu specific subtree like this:
>>
>> #define for_each_group_event(event, group, cpu, pmu, field) \
>> for (event = rb_entry_safe(group_first(group, cpu, pmu), \
>> typeof(*event), field); \
>> event && event->cpu == cpu && event->pmu == pmu;\
>> event = rb_entry_safe(rb_next(&event->field), \
>> typeof(*event), field))
>
> Afaict, this assumes that you are also ordering on event->pmu, which
> should be reflected in your _less function. And also assuming that
> group_first() is doing the right thing. Can we see the code?
I didn't do ordering by PMU for this patch set. Yet more I implemented
groups_first() like this:
static struct perf_event *
perf_event_groups_first(struct perf_event_groups *groups, int cpu)
{
struct perf_event *node_event = NULL;
struct rb_node *node = NULL;
node = groups->tree.rb_node;
while (node) {
node_event = container_of(node,
struct perf_event, group_node);
if (cpu < node_event->cpu) {
node = node->rb_left;
} else if (cpu > node_event->cpu) {
node = node->rb_right;
} else {
node = node->rb_left;
}
}
return node_event;
}
and it doesn't work as expected for case above with cpu == 1.
I corrected the code above to this:
static struct perf_event *
perf_event_groups_first(struct perf_event_groups *groups, int cpu)
{
struct perf_event *node_event = NULL, *match = NULL;
struct rb_node *node = NULL;
node = groups->tree.rb_node;
while (node) {
node_event = container_of(node,
struct perf_event, group_node);
if (cpu < node_event->cpu) {
node = node->rb_left;
} else if (cpu > node_event->cpu) {
node = node->rb_right;
} else {
match = node_event;
node = node->rb_left;
}
}
return match;
}
but now struggling with silent oopses which I guess are not
related to multiplexing at all.
Please look at v8 for a while. It addresses your comments for v7.
>
> Regards,
> --
> Alex
>
Thanks,
Alexey
[PATCH net-next] xfrm: Add support for network devices capable of removing the ESP trailer
From: Yossi Kuperman
In conjunction with crypto offload [1], removing the ESP trailer by
hardware can potentially improve the performance by avoiding (1) a
cache miss incurred by reading the nexthdr field and (2) the necessity
to calculate the csum value of the trailer in order to keep skb->csum
valid.
This patch introduces the changes to the xfrm stack and merely serves
as an infrastructure. Subsequent patch to mlx5 driver will put this to
a good use.
[1] https://www.mail-archive.com/netdev@vger.kernel.org/msg175733.html
Signed-off-by: Yossi Kuperman
---
include/net/xfrm.h| 1 +
net/ipv4/esp4.c | 70 ++-
net/ipv6/esp6.c | 51 ++---
net/xfrm/xfrm_input.c | 5
4 files changed, 89 insertions(+), 38 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 9c7b70c..f002a2c 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1019,6 +1019,7 @@ struct xfrm_offload {
#defineCRYPTO_FALLBACK 8
#defineXFRM_GSO_SEGMENT16
#defineXFRM_GRO32
+#defineXFRM_ESP_NO_TRAILER 64
__u32 status;
#define CRYPTO_SUCCESS 1
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 741acd7..3190005 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -499,19 +499,59 @@ static int esp_output(struct xfrm_state *x, struct
sk_buff *skb)
return esp_output_tail(x, skb, &esp);
}
+static inline int esp_remove_trailer(struct sk_buff *skb)
+{
+ struct xfrm_state *x = xfrm_input_state(skb);
+ struct xfrm_offload *xo = xfrm_offload(skb);
+ struct crypto_aead *aead = x->data;
+ int alen, hlen, elen;
+ int padlen, trimlen;
+ __wsum csumdiff;
+ u8 nexthdr[2];
+ int ret;
+
+ alen = crypto_aead_authsize(aead);
+ hlen = sizeof(struct ip_esp_hdr) + crypto_aead_ivsize(aead);
+ elen = skb->len - hlen;
+
+ if (xo && (xo->flags & XFRM_ESP_NO_TRAILER)) {
+ ret = xo->proto;
+ goto out;
+ }
+
+ if (skb_copy_bits(skb, skb->len - alen - 2, nexthdr, 2))
+ BUG();
+
+ ret = -EINVAL;
+ padlen = nexthdr[0];
+ if (padlen + 2 + alen >= elen) {
+ net_dbg_ratelimited("ipsec esp packet is garbage padlen=%d,
elen=%d\n",
+ padlen + 2, elen - alen);
+ goto out;
+ }
+
+ trimlen = alen + padlen + 2;
+ if (skb->ip_summed == CHECKSUM_COMPLETE) {
+ csumdiff = skb_checksum(skb, skb->len - trimlen, trimlen, 0);
+ skb->csum = csum_block_sub(skb->csum, csumdiff,
+ skb->len - trimlen);
+ }
+ pskb_trim(skb, skb->len - trimlen);
+
+ ret = nexthdr[1];
+
+out:
+ return ret;
+}
+
int esp_input_done2(struct sk_buff *skb, int err)
{
const struct iphdr *iph;
struct xfrm_state *x = xfrm_input_state(skb);
struct xfrm_offload *xo = xfrm_offload(skb);
struct crypto_aead *aead = x->data;
- int alen = crypto_aead_authsize(aead);
int hlen = sizeof(struct ip_esp_hdr) + crypto_aead_ivsize(aead);
- int elen = skb->len - hlen;
int ihl;
- u8 nexthdr[2];
- int padlen, trimlen;
- __wsum csumdiff;
if (!xo || (xo && !(xo->flags & CRYPTO_DONE)))
kfree(ESP_SKB_CB(skb)->tmp);
@@ -519,16 +559,10 @@ int esp_input_done2(struct sk_buff *skb, int err)
if (unlikely(err))
goto out;
- if (skb_copy_bits(skb, skb->len-alen-2, nexthdr, 2))
- BUG();
-
- err = -EINVAL;
- padlen = nexthdr[0];
- if (padlen + 2 + alen >= elen)
+ err = esp_remove_trailer(skb);
+ if (unlikely(err < 0))
goto out;
- /* ... check padding bits here. Silly. :-) */
-
iph = ip_hdr(skb);
ihl = iph->ihl * 4;
@@ -569,22 +603,12 @@ int esp_input_done2(struct sk_buff *skb, int err)
skb->ip_summed = CHECKSUM_UNNECESSARY;
}
- trimlen = alen + padlen + 2;
- if (skb->ip_summed == CHECKSUM_COMPLETE) {
- csumdiff = skb_checksum(skb, skb->len - trimlen, trimlen, 0);
- skb->csum = csum_block_sub(skb->csum, csumdiff,
- skb->len - trimlen);
- }
- pskb_trim(skb, skb->len - trimlen);
-
skb_pull_rcsum(skb, hlen);
if (x->props.mode == XFRM_MODE_TUNNEL)
skb_reset_transport_header(skb);
else
skb_set_transport_header(skb, -ihl);
- err = nexthdr[1];
-
/* RFC4303: Drop dummy packets without any error */
if (err == IPPROTO_NONE)
err = -EINVAL;
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 74bde20..7fb41b0 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@
[PATCH net-next v4 10/13] arm64: dts: marvell: add comphy nodes on cp110 master and slave
Now that the comphy driver is available, this patch adds the
corresponding nodes in the cp110 master and slave device trees.
Signed-off-by: Antoine Tenart
---
.../boot/dts/marvell/armada-cp110-master.dtsi | 38 ++
.../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 38 ++
2 files changed, 76 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 9b2581473183..f2a50552bad4 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -91,6 +91,44 @@
};
};
+ cpm_comphy: phy@12 {
+ compatible = "marvell,comphy-cp110";
+ reg = <0x12 0x6000>;
+ marvell,system-controller = <&cpm_syscon0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpm_comphy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+
+ cpm_comphy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <1>;
+ };
+
+ cpm_comphy2: phy@2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+
+ cpm_comphy3: phy@3 {
+ reg = <3>;
+ #phy-cells = <1>;
+ };
+
+ cpm_comphy4: phy@4 {
+ reg = <4>;
+ #phy-cells = <1>;
+ };
+
+ cpm_comphy5: phy@5 {
+ reg = <5>;
+ #phy-cells = <1>;
+ };
+ };
+
cpm_mdio: mdio@12a200 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index d3902f218c46..bd7f7d0e6de9 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -98,6 +98,44 @@
};
};
+ cps_comphy: phy@12 {
+ compatible = "marvell,comphy-cp110";
+ reg = <0x12 0x6000>;
+ marvell,system-controller = <&cps_syscon0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cps_comphy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+
+ cps_comphy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <1>;
+ };
+
+ cps_comphy2: phy@2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+
+ cps_comphy3: phy@3 {
+ reg = <3>;
+ #phy-cells = <1>;
+ };
+
+ cps_comphy4: phy@4 {
+ reg = <4>;
+ #phy-cells = <1>;
+ };
+
+ cps_comphy5: phy@5 {
+ reg = <5>;
+ #phy-cells = <1>;
+ };
+ };
+
cps_mdio: mdio@12a200 {
#address-cells = <1>;
#size-cells = <0>;
--
2.13.5
[PATCH net-next v4 05/13] net: mvpp2: simplify the link_event function
The link_event function is somewhat complicated. This cosmetic patch
simplifies it.
Signed-off-by: Antoine Tenart
---
drivers/net/ethernet/marvell/mvpp2.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index fab231858a41..9c0c81e68d55 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5740,7 +5740,6 @@ static void mvpp2_link_event(struct net_device *dev)
{
struct mvpp2_port *port = netdev_priv(dev);
struct phy_device *phydev = dev->phydev;
- int status_change = 0;
u32 val;
if (phydev->link) {
@@ -5771,16 +5770,8 @@ static void mvpp2_link_event(struct net_device *dev)
}
if (phydev->link != port->link) {
- if (!phydev->link) {
- port->duplex = -1;
- port->speed = 0;
- }
-
port->link = phydev->link;
- status_change = 1;
- }
- if (status_change) {
if (phydev->link) {
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
val |= (MVPP2_GMAC_FORCE_LINK_PASS |
@@ -5789,9 +5780,13 @@ static void mvpp2_link_event(struct net_device *dev)
mvpp2_egress_enable(port);
mvpp2_ingress_enable(port);
} else {
+ port->duplex = -1;
+ port->speed = 0;
+
mvpp2_ingress_disable(port);
mvpp2_egress_disable(port);
}
+
phy_print_status(phydev);
}
}
--
2.13.5
[PATCH net-next v4 12/13] arm64: dts: marvell: 7040-db: add comphy references to Ethernet ports
This patch adds comphy phandles to the Ethernet ports in the 7040-db
device tree. The comphy is used to configure the serdes PHYs used by
these ports.
Signed-off-by: Antoine Tenart
---
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index 92c761c380d3..03d1c42d7c47 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -180,6 +180,7 @@
status = "okay";
phy = <&phy0>;
phy-mode = "sgmii";
+ phys = <&cpm_comphy0 1>;
};
&cpm_eth2 {
--
2.13.5
[PATCH net-next v4 00/13] net: mvpp2: comphy configuration
Hi all, This series, following up the one one the GoP/MAC configuration, aims at stopping to depend on the firmware/bootloader configuration when using the PPv2 engine. With this series the PPv2 driver does not need to rely on a previous configuration, and dynamic reconfiguration while the kernel is running can be done (i.e. switch one port from SGMII to 10G, or the opposite). A port can now be configured in a different mode than what's done in the firmware/bootloader as well. The series first contain patches in the generic PHY framework to support what is called the comphy (common PHYs), which is an h/w block providing PHYs that can be configured in various modes ranging from SGMII, 10G to SATA and others. As of now only the SGMII and 10G modes are supported by the comphy driver. Then patches are modifying the PPv2 driver to first add the comphy initialization sequence (i.e. calls to the generic PHY framework) and to then take advantage of this to allow dynamic reconfiguration (i.e. configuring the mode of a port given what's connected, between sgmii and 10G). Note the use of the comphy in the PPv2 driver is kept optional (i.e. if not described in dt the driver still as before an relies on the firmware/bootloader configuration). Finally there are dt/defconfig patches to describe and take advantage of this. This was tested on a range of devices: 8040-db, 8040-mcbin and 7040-db. @Dave: the dt patches should go through the mvebu tree (patches 9-13). Thanks! Antoine Since v3: - Now use of_phy_simple_xlate() to retrieve the phy. - Added an owner in the phy_ops structure. - Now allow the module to be selected with COMPILE_TEST. - Removed unused parameter in the comphy set_mode functions. - Added Kishon Acked-by in patch 1. Since v2: - Kept the link mode enforcement. - Removed the netif_running() check. - Reworded the "dynamic reconfiguration of the PHY mode" commit log. - Added one patch not to force the GMAC autoneg parameters when using the XLG MAC. Since v1: - Updated the mode settings variable name in the comphy driver to have 'cp110' in it. - Documented the PHY cell argument in the dt documentation. - New patch adding comphy phandles for the 7040-db board. - Checked if the carrier_on/off functions were needed. They are. - s/PHY/generic PHY/ in commit log of patch 1. - Rebased on the latest net-next/master. Antoine Tenart (12): phy: add sgmii and 10gkr modes to the phy_mode enum phy: add the mvebu cp110 comphy driver Documentation/bindings: phy: document the Marvell comphy driver net: mvpp2: initialize the comphy net: mvpp2: simplify the link_event function net: mvpp2: improve the link management function net: mvpp2: do not set GMAC autoneg when using XLG MAC net: mvpp2: dynamic reconfiguration of the comphy/GoP/MAC arm64: dts: marvell: extend the cp110 syscon register area length arm64: dts: marvell: add comphy nodes on cp110 master and slave arm64: dts: marvell: mcbin: add comphy references to Ethernet ports arm64: dts: marvell: 7040-db: add comphy references to Ethernet ports Miquel Raynal (1): arm64: defconfig: enable Marvell CP110 comphy .../devicetree/bindings/phy/phy-mvebu-comphy.txt | 43 ++ arch/arm64/boot/dts/marvell/armada-7040-db.dts | 1 + arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 3 + .../boot/dts/marvell/armada-cp110-master.dtsi | 40 +- .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 40 +- arch/arm64/configs/defconfig | 1 + drivers/net/ethernet/marvell/mvpp2.c | 153 +++-- drivers/phy/marvell/Kconfig| 11 + drivers/phy/marvell/Makefile | 1 + drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 644 + include/linux/phy/phy.h| 2 + 11 files changed, 904 insertions(+), 35 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt create mode 100644 drivers/phy/marvell/phy-mvebu-cp110-comphy.c -- 2.13.5
[PATCH net-next v4 06/13] net: mvpp2: improve the link management function
When the link status changes, the phylib calls the link_event function
in the mvpp2 driver. Before this patch only the egress/ingress transmit
was enabled/disabled. This patch adds more functionality to the link
status management code by enabling/disabling the port per-cpu
interrupts, and the port itself. The queues are now stopped as well, and
the netif carrier helpers are called.
Signed-off-by: Antoine Tenart
---
drivers/net/ethernet/marvell/mvpp2.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index 9c0c81e68d55..09cad32734f3 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5777,14 +5777,25 @@ static void mvpp2_link_event(struct net_device *dev)
val |= (MVPP2_GMAC_FORCE_LINK_PASS |
MVPP2_GMAC_FORCE_LINK_DOWN);
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+
+ mvpp2_interrupts_enable(port);
+ mvpp2_port_enable(port);
+
mvpp2_egress_enable(port);
mvpp2_ingress_enable(port);
+ netif_carrier_on(dev);
+ netif_tx_wake_all_queues(dev);
} else {
port->duplex = -1;
port->speed = 0;
+ netif_tx_stop_all_queues(dev);
+ netif_carrier_off(dev);
mvpp2_ingress_disable(port);
mvpp2_egress_disable(port);
+
+ mvpp2_port_disable(port);
+ mvpp2_interrupts_disable(port);
}
phy_print_status(phydev);
--
2.13.5
[PATCH] hwmon: (asc7621): make several arrays static const
From: Colin Ian King
Don't populate the arrays on the stack, instead make them static.
Makes the object code smaller by over 950 bytes:
Before:
textdata bss dec hex filename
26144 18768 352 45264b0d0 drivers/hwmon/asc7621.o
After:
textdata bss dec hex filename
25029 18928 352 44309ad15 drivers/hwmon/asc7621.o
Signed-off-by: Colin Ian King
---
drivers/hwmon/asc7621.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/asc7621.c b/drivers/hwmon/asc7621.c
index c77644d45a02..4875e99b59c9 100644
--- a/drivers/hwmon/asc7621.c
+++ b/drivers/hwmon/asc7621.c
@@ -512,7 +512,7 @@ static ssize_t show_pwm_ac(struct device *dev,
{
SETUP_SHOW_DATA_PARAM(dev, attr);
u8 config, altbit, regval;
- const u8 map[] = {
+ static const u8 map[] = {
0x01, 0x02, 0x04, 0x1f, 0x00, 0x06, 0x07, 0x10,
0x08, 0x0f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f
};
@@ -533,7 +533,7 @@ static ssize_t store_pwm_ac(struct device *dev,
SETUP_STORE_DATA_PARAM(dev, attr);
unsigned long reqval;
u8 currval, config, altbit, newval;
- const u16 map[] = {
+ static const u16 map[] = {
0x04, 0x00, 0x01, 0xff, 0x02, 0xff, 0x05, 0x06,
0x08, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0f,
0x07, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
--
2.14.1
[PATCH net-next v4 07/13] net: mvpp2: do not set GMAC autoneg when using XLG MAC
When using the XLG MAC, it does not make sense to force the GMAC autoneg
parameters. This patch adds checks to only set the GMAC autoneg
parameters when needed (i.e. when not using the XLG MAC).
Signed-off-by: Antoine Tenart
---
drivers/net/ethernet/marvell/mvpp2.c | 64 +++-
1 file changed, 42 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index 09cad32734f3..2f05a0b0773c 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5735,6 +5735,37 @@ static irqreturn_t mvpp2_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static void mvpp2_gmac_set_autoneg(struct mvpp2_port *port,
+ struct phy_device *phydev)
+{
+ u32 val;
+
+ if (port->phy_interface != PHY_INTERFACE_MODE_RGMII &&
+ port->phy_interface != PHY_INTERFACE_MODE_RGMII_ID &&
+ port->phy_interface != PHY_INTERFACE_MODE_RGMII_RXID &&
+ port->phy_interface != PHY_INTERFACE_MODE_RGMII_TXID &&
+ port->phy_interface != PHY_INTERFACE_MODE_SGMII)
+ return;
+
+ val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ val &= ~(MVPP2_GMAC_CONFIG_MII_SPEED |
+MVPP2_GMAC_CONFIG_GMII_SPEED |
+MVPP2_GMAC_CONFIG_FULL_DUPLEX |
+MVPP2_GMAC_AN_SPEED_EN |
+MVPP2_GMAC_AN_DUPLEX_EN);
+
+ if (phydev->duplex)
+ val |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+
+ if (phydev->speed == SPEED_1000)
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED;
+ else if (phydev->speed == SPEED_100)
+ val |= MVPP2_GMAC_CONFIG_MII_SPEED;
+
+ writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+
+}
+
/* Adjust link */
static void mvpp2_link_event(struct net_device *dev)
{
@@ -5745,24 +5776,7 @@ static void mvpp2_link_event(struct net_device *dev)
if (phydev->link) {
if ((port->speed != phydev->speed) ||
(port->duplex != phydev->duplex)) {
- u32 val;
-
- val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val &= ~(MVPP2_GMAC_CONFIG_MII_SPEED |
-MVPP2_GMAC_CONFIG_GMII_SPEED |
-MVPP2_GMAC_CONFIG_FULL_DUPLEX |
-MVPP2_GMAC_AN_SPEED_EN |
-MVPP2_GMAC_AN_DUPLEX_EN);
-
- if (phydev->duplex)
- val |= MVPP2_GMAC_CONFIG_FULL_DUPLEX;
-
- if (phydev->speed == SPEED_1000)
- val |= MVPP2_GMAC_CONFIG_GMII_SPEED;
- else if (phydev->speed == SPEED_100)
- val |= MVPP2_GMAC_CONFIG_MII_SPEED;
-
- writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ mvpp2_gmac_set_autoneg(port, phydev);
port->duplex = phydev->duplex;
port->speed = phydev->speed;
@@ -5773,10 +5787,16 @@ static void mvpp2_link_event(struct net_device *dev)
port->link = phydev->link;
if (phydev->link) {
- val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
- val |= (MVPP2_GMAC_FORCE_LINK_PASS |
- MVPP2_GMAC_FORCE_LINK_DOWN);
- writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+ if (port->phy_interface == PHY_INTERFACE_MODE_RGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_RGMII_ID
||
+ port->phy_interface ==
PHY_INTERFACE_MODE_RGMII_RXID ||
+ port->phy_interface ==
PHY_INTERFACE_MODE_RGMII_TXID ||
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ val = readl(port->base +
MVPP2_GMAC_AUTONEG_CONFIG);
+ val |= (MVPP2_GMAC_FORCE_LINK_PASS |
+ MVPP2_GMAC_FORCE_LINK_DOWN);
+ writel(val, port->base +
MVPP2_GMAC_AUTONEG_CONFIG);
+ }
mvpp2_interrupts_enable(port);
mvpp2_port_enable(port);
--
2.13.5
Re: [PATCH v2 15/30] xfs: Define usercopy region in xfs_inode slab cache
On Wed, Aug 30, 2017 at 06:05:58PM +1000, Dave Chinner wrote:
> Ok, that's sounds like it'll fit right in with what I've been
> prototyping for the extent code in xfs_bmap.c. I can make that work
> with a cursor-based lookup/inc/dec/ins/del API similar to the bmbt
> API. I've been looking to abstract the extent manipulations out into
> functions that modify both trees like this:
>
> [note: just put template code in to get my thoughts straight, it's
> not working code]
FYI, I've got somewhat working changes in that area (still has bugs
but a few tests pass :)), what I'm doing is to make sure all of
the xfs_bmap_{add,del}_extent_* routines fully operate on xfs_bmbt_irec
structures that they acquire through the xfs_bmalloca structure or
from xfs_iext_get_extent and update using xfs_iext_update_extent.
A nice fallout from that is that we can change the prototypes for
xfs_bmbt_lookup_* and xfs_bmbt_update to take a xfs_bmbt_irec
as well instead of taking the individual arguments. That should
help with your next step cleanups a bit.
[PATCH net-next v4 09/13] arm64: dts: marvell: extend the cp110 syscon register area length
This patch extends on both cp110 the system register area length to
include some of the comphy registers as well.
Signed-off-by: Antoine Tenart
---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 18299e164cb7..9b2581473183 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -118,7 +118,7 @@
cpm_syscon0: system-controller@44 {
compatible = "syscon", "simple-mfd";
- reg = <0x44 0x1000>;
+ reg = <0x44 0x2000>;
cpm_clk: clock {
compatible = "marvell,cp110-clock";
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 5ae8fa575859..d3902f218c46 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -125,7 +125,7 @@
cps_syscon0: system-controller@44 {
compatible = "syscon", "simple-mfd";
- reg = <0x44 0x1000>;
+ reg = <0x44 0x2000>;
cps_clk: clock {
compatible = "marvell,cp110-clock";
--
2.13.5
[PATCH net-next v4 02/13] phy: add the mvebu cp110 comphy driver
On the CP110 unit, which can be found on various Marvell platforms such as the 7k and 8k (currently), a comphy (common PHYs) hardware block can be found. This block provides a number of PHYs which can be used in various modes by other controllers (network, SATA ...). These common PHYs must be configured for the controllers using them to work correctly either at boot time, or when the system runs to switch the mode used. This patch adds a driver for this comphy hardware block, providing callbacks for the its PHYs so that consumers can configure the modes used. As of this commit, two modes are supported by the comphy driver: sgmii and 10gkr. Signed-off-by: Antoine Tenart --- drivers/phy/marvell/Kconfig | 11 + drivers/phy/marvell/Makefile | 1 + drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 644 +++ 3 files changed, 656 insertions(+) create mode 100644 drivers/phy/marvell/phy-mvebu-cp110-comphy.c diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig index 048d8893bc2e..68e321225400 100644 --- a/drivers/phy/marvell/Kconfig +++ b/drivers/phy/marvell/Kconfig @@ -21,6 +21,17 @@ config PHY_BERLIN_USB help Enable this to support the USB PHY on Marvell Berlin SoCs. +config PHY_MVEBU_CP110_COMPHY + tristate "Marvell CP110 comphy driver" + depends on ARCH_MVEBU || COMPILE_TEST + depends on OF + select GENERIC_PHY + help + This driver allows to control the comphy, an hardware block providing + shared serdes PHYs on Marvell Armada 7k/8k (in the CP110). Its serdes + lanes can be used by various controllers (Ethernet, sata, usb, + PCIe...). + config PHY_MVEBU_SATA def_bool y depends on ARCH_DOVE || MACH_DOVE || MACH_KIRKWOOD diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile index 3fc188f59118..0cf6a7cbaf9f 100644 --- a/drivers/phy/marvell/Makefile +++ b/drivers/phy/marvell/Makefile @@ -1,6 +1,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o +obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY) += phy-mvebu-cp110-comphy.o obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o obj-$(CONFIG_PHY_PXA_28NM_HSIC)+= phy-pxa-28nm-hsic.o obj-$(CONFIG_PHY_PXA_28NM_USB2)+= phy-pxa-28nm-usb2.o diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c new file mode 100644 index ..73ebad6634a7 --- /dev/null +++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c @@ -0,0 +1,644 @@ +/* + * Copyright (C) 2017 Marvell + * + * Antoine Tenart + * + * 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 + +/* Relative to priv->base */ +#define MVEBU_COMPHY_SERDES_CFG0(n)(0x0 + (n) * 0x1000) +#define MVEBU_COMPHY_SERDES_CFG0_PU_PLLBIT(1) +#define MVEBU_COMPHY_SERDES_CFG0_GEN_RX(n) ((n) << 3) +#define MVEBU_COMPHY_SERDES_CFG0_GEN_TX(n) ((n) << 7) +#define MVEBU_COMPHY_SERDES_CFG0_PU_RX BIT(11) +#define MVEBU_COMPHY_SERDES_CFG0_PU_TX BIT(12) +#define MVEBU_COMPHY_SERDES_CFG0_HALF_BUS BIT(14) +#define MVEBU_COMPHY_SERDES_CFG1(n)(0x4 + (n) * 0x1000) +#define MVEBU_COMPHY_SERDES_CFG1_RESET BIT(3) +#define MVEBU_COMPHY_SERDES_CFG1_RX_INIT BIT(4) +#define MVEBU_COMPHY_SERDES_CFG1_CORE_RESETBIT(5) +#define MVEBU_COMPHY_SERDES_CFG1_RF_RESET BIT(6) +#define MVEBU_COMPHY_SERDES_CFG2(n)(0x8 + (n) * 0x1000) +#define MVEBU_COMPHY_SERDES_CFG2_DFE_ENBIT(4) +#define MVEBU_COMPHY_SERDES_STATUS0(n) (0x18 + (n) * 0x1000) +#define MVEBU_COMPHY_SERDES_STATUS0_TX_PLL_RDY BIT(2) +#define MVEBU_COMPHY_SERDES_STATUS0_RX_PLL_RDY BIT(3) +#define MVEBU_COMPHY_SERDES_STATUS0_RX_INITBIT(4) +#define MVEBU_COMPHY_PWRPLL_CTRL(n)(0x804 + (n) * 0x1000) +#define MVEBU_COMPHY_PWRPLL_CTRL_RFREQ(n) ((n) << 0) +#define MVEBU_COMPHY_PWRPLL_PHY_MODE(n)((n) << 5) +#define MVEBU_COMPHY_IMP_CAL(n)(0x80c + (n) * 0x1000) +#define MVEBU_COMPHY_IMP_CAL_TX_EXT(n) ((n) << 10) +#define MVEBU_COMPHY_IMP_CAL_TX_EXT_EN BIT(15) +#define MVEBU_COMPHY_DFE_RES(n)(0x81c + (n) * 0x1000) +#define MVEBU_COMPHY_DFE_RES_FORCE_GEN_TBL BIT(15) +#define MVEBU_COMPHY_COEF(n) (0x828 + (n) * 0x1000) +#define MVEBU_COMPHY_COEF_DFE_EN BIT(14) +#define MVEBU_COMPHY_COEF_DFE_CTRL BIT(15) +#define MVEBU_COMPHY_GEN1_S0(n)(0x834 + (n) * 0x1000) +#define MVEBU_COMPHY_GEN1_S0
[PATCH net-next v4 01/13] phy: add sgmii and 10gkr modes to the phy_mode enum
This patch adds more generic PHY modes to the phy_mode enum, to
allow configuring generic PHYs to the SGMII and/or the 10GKR mode
by using the set_mode callback.
Signed-off-by: Antoine Tenart
Acked-by: Kishon Vijay Abraham I
---
include/linux/phy/phy.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 78bb0d7f6b11..e694d4008c4a 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -27,6 +27,8 @@ enum phy_mode {
PHY_MODE_USB_HOST,
PHY_MODE_USB_DEVICE,
PHY_MODE_USB_OTG,
+ PHY_MODE_SGMII,
+ PHY_MODE_10GKR,
};
/**
--
2.13.5
[PATCH net-next v4 04/13] net: mvpp2: initialize the comphy
On some platforms, the comphy is between the MAC GoP and the PHYs. The
mvpp2 driver currently relies on the firmware/bootloader to configure
the comphy. As a comphy driver was added to the generic PHY framework,
this patch uses it in the mvpp2 driver to configure the comphy at boot
time to avoid relying on the bootloader.
Signed-off-by: Antoine Tenart
---
drivers/net/ethernet/marvell/mvpp2.c | 44 +++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index e312dfc3555b..fab231858a41 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -861,6 +862,7 @@ struct mvpp2_port {
phy_interface_t phy_interface;
struct device_node *phy_node;
+ struct phy *comphy;
unsigned int link;
unsigned int duplex;
unsigned int speed;
@@ -4420,6 +4422,32 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
return -EINVAL;
}
+static int mvpp22_comphy_init(struct mvpp2_port *port)
+{
+ enum phy_mode mode;
+ int ret;
+
+ if (!port->comphy)
+ return 0;
+
+ switch (port->phy_interface) {
+ case PHY_INTERFACE_MODE_SGMII:
+ mode = PHY_MODE_SGMII;
+ break;
+ case PHY_INTERFACE_MODE_10GKR:
+ mode = PHY_MODE_10GKR;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ ret = phy_set_mode(port->comphy, mode);
+ if (ret)
+ return ret;
+
+ return phy_power_on(port->comphy);
+}
+
static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
{
u32 val;
@@ -6404,8 +6432,10 @@ static void mvpp2_start_dev(struct mvpp2_port *port)
/* Enable interrupts on all CPUs */
mvpp2_interrupts_enable(port);
- if (port->priv->hw_version == MVPP22)
+ if (port->priv->hw_version == MVPP22) {
+ mvpp22_comphy_init(port);
mvpp22_gop_init(port);
+ }
mvpp2_port_mii_set(port);
mvpp2_port_enable(port);
@@ -6436,6 +6466,7 @@ static void mvpp2_stop_dev(struct mvpp2_port *port)
mvpp2_egress_disable(port);
mvpp2_port_disable(port);
phy_stop(ndev->phydev);
+ phy_power_off(port->comphy);
}
static int mvpp2_check_ringparam_valid(struct net_device *dev,
@@ -7270,6 +7301,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
struct mvpp2 *priv)
{
struct device_node *phy_node;
+ struct phy *comphy;
struct mvpp2_port *port;
struct mvpp2_port_pcpu *port_pcpu;
struct net_device *dev;
@@ -7311,6 +7343,15 @@ static int mvpp2_port_probe(struct platform_device *pdev,
goto err_free_netdev;
}
+ comphy = devm_of_phy_get(&pdev->dev, port_node, NULL);
+ if (IS_ERR(comphy)) {
+ if (PTR_ERR(comphy) == -EPROBE_DEFER) {
+ err = -EPROBE_DEFER;
+ goto err_free_netdev;
+ }
+ comphy = NULL;
+ }
+
if (of_property_read_u32(port_node, "port-id", &id)) {
err = -EINVAL;
dev_err(&pdev->dev, "missing port-id value\n");
@@ -7344,6 +7385,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
port->phy_node = phy_node;
port->phy_interface = phy_mode;
+ port->comphy = comphy;
if (priv->hw_version == MVPP21) {
res = platform_get_resource(pdev, IORESOURCE_MEM, 2 + id);
--
2.13.5
RE: [PATCH v2] PCIe AER: report uncorrectable errors only to the functions that logged the errors
ping... > -Original Message- > From: Gabriele Paoloni > Sent: 18 August 2017 12:02 > To: helg...@kernel.org > Cc: Gabriele Paoloni; Linuxarm; liudongdong (C); linux- > p...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [PATCH v2] PCIe AER: report uncorrectable errors only to the > functions that logged the errors > > Currently if an uncorrectable error is reported by an EP the AER > driver walks over all the devices connected to the upstream port > bus and in turns call the report_error_detected() callback. > If any of the devices connected to the bus does not implement > dev->driver->err_handler->error_detected() do_recovery() will fail > leaving all the bus hierarchy devices unrecovered. > > However for non fatal errors the PCIe link should not be considered > compromised, therefore it makes sense to report the error only to > all the functions that logged an error. > This patch implements this new behaviour for non fatal errors. > > Signed-off-by: Gabriele Paoloni > Signed-off-by: Dongdong Liu > --- > Changes from v1: >- now errors are reported only to the fucntions that logged the > error > instead of all the functions in the same device. >- the patch subject has changed to match the new implementation > --- > drivers/pci/pcie/aer/aerdrv_core.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/pcie/aer/aerdrv_core.c > b/drivers/pci/pcie/aer/aerdrv_core.c > index b1303b3..057465ad 100644 > --- a/drivers/pci/pcie/aer/aerdrv_core.c > +++ b/drivers/pci/pcie/aer/aerdrv_core.c > @@ -390,7 +390,14 @@ static pci_ers_result_t > broadcast_error_message(struct pci_dev *dev, >* If the error is reported by an end point, we think this >* error is related to the upstream link of the end point. >*/ > - pci_walk_bus(dev->bus, cb, &result_data); > + if (state == pci_channel_io_normal) > + /* > + * the error is non fatal so the bus is ok, just > invoke > + * the callback for the function that logged the > error. > + */ > + cb(dev, &result_data); > + else > + pci_walk_bus(dev->bus, cb, &result_data); > } > > return result_data.result; > -- > 2.7.4 >
Re: [PATCH 14/14] arm64: kexec_file: add vmlinux format support
Mark Rutland writes:
> On Thu, Aug 24, 2017 at 06:30:50PM +0100, Mark Rutland wrote:
>> On Thu, Aug 24, 2017 at 05:18:11PM +0900, AKASHI Takahiro wrote:
>> > The first PT_LOAD segment, which is assumed to be "text" code, in vmlinux
>> > will be loaded at the offset of TEXT_OFFSET from the begining of system
>> > memory. The other PT_LOAD segments are placed relative to the first one.
>>
>> I really don't like assuming things about the vmlinux ELF file.
>>
>> > Regarding kernel verification, since there is no standard way to contain
>> > a signature within elf binary, we follow PowerPC's (not yet upstreamed)
>> > approach, that is, appending a signature right after the kernel binary
>> > itself like module signing.
>>
>> I also *really* don't like this. It's a bizarre in-band mechanism,
>> without explcit information. It's not a nice ABI.
>>
>> If we can load an Image, why do we need to be able to load a vmlinux?
>
> So IIUC, the whole point of this is to be able to kexec_file_load() a
> vmlinux + signature bundle, for !CONFIG_EFI kernels.
>
> For that, I think that we actually need a new kexec_file_load${N}
> syscall, where we can pass the signature for the kernel as a separate
> file. Ideally also with a flags argument and perhaps the ability to sign
> the initrd too.
>
> That way we don't ahve to come up with a magic vmlinux+signature format,
You don't have to come up with one, it already exists. We've been using
it for signed modules for ~5 years.
It also has the advantages of being a signature of the entire ELF, no
silly games about which sections are included, and it's attached to the
vmlinux so you don't have to remember to copy it around. And the code to
produce it and verify it already exists.
cheers
Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback
On Tue, 2017-08-29 at 20:56 -0400, Jerome Glisse wrote: > On Tue, Aug 29, 2017 at 05:11:24PM -0700, Linus Torvalds wrote: > > > People - *especially* the people who saw issues under KVM - can you > > try out Jérôme's patch-series? I aded some people to the cc, the full > > series is on lkml. Jérôme - do you have a git branch for people to > > test that they could easily pull and try out? > > https://cgit.freedesktop.org/~glisse/linux mmu-notifier branch > git://people.freedesktop.org/~glisse/linux Looks good here. I reproduced fairly quickly with RT host and 1 RT guest by just having the guest do a parallel kbuild over NFS (the guest had to be restored afterward, was corrupted). I'm currently flogging 2 guests as well as the host, whimper free. I'll let the lot broil for while longer, but at this point, smoke/flame appearance seems comfortingly unlikely. -Mike
Re: [PATCH] perf report: calculate the average cycles of iterations
Hi Arnaldo, Andi has reviewed this patch yet. https://patchwork.kernel.org/patch/9884399/ Is this patch OK for merging or any other comments? Thanks Jin Yao On 8/15/2017 11:19 AM, Andi Kleen wrote: On Mon, Aug 14, 2017 at 01:30:29AM +, Jin, Yao wrote: Hi Andi, Do you have any comments for this patch? Patch looks good to me. Reviewed-by: Andi Kleen -Andi
Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]
On Wed, Aug 30, 2017 at 03:15:11PM +0900, Sergey Senozhatsky wrote:
> Hi,
>
> On (08/30/17 14:43), Byungchul Park wrote:
> [..]
> > > notably slower than earlier 4.13 linux-next. (e.g. scrolling in vim
> > > is irritatingly slow)
> >
> > To Ingo,
> >
> > I cannot decide if we have to roll back CONFIG_LOCKDEP_CROSSRELEASE
> > dependency on CONFIG_PROVE_LOCKING in Kconfig. With them enabled,
> > lockdep detection becomes strong but has performance impact. But,
> > it's anyway a debug option so IMHO we don't have to take case of the
> > performance impact. Please let me know your decision.
>
> well, I expected it :)
>
> I've been running lockdep enabled kernels for years, and was OK with
> the performance. but now it's just too much and I'm looking at disabling
> lockdep.
>
> a more relevant test -- compilation of a relatively small project
>
> LOCKDEP -CROSSRELEASE -COMPLETIONS LOCKDEP +CROSSRELEASE +COMPLETIONS
>
>real1m23.722s real2m9.969s
>user4m11.300s user4m15.458s
>sys 0m49.386s sys 2m3.594s
>
>
> you don't want to know how much time now it takes to recompile the
> kernel ;)
Right,.. so when I look at perf annotate for __lock_acquire and
lock_release (the two most expensive lockdep functions in a kernel
profile) I don't actually see much cross-release stuff.
So the overhead looks to be spread out over all sorts, which makes it
harder to find and fix.
stack unwinding is done lots and is fairly expensive, I've not yet
checked if crossrelease does too much of that.
The below saved about 50% of my __lock_acquire() time, not sure it made
a significant difference over all though.
---
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 44c8d0d17170..f8db1ead1c48 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3386,7 +3386,7 @@ static int __lock_acquire(struct lockdep_map *lock,
unsigned int subclass,
if (!class)
return 0;
}
- atomic_inc((atomic_t *)&class->ops);
+ /* atomic_inc((atomic_t *)&class->ops); */
if (very_verbose(class)) {
printk("\nacquire class [%p] %s", class->key, class->name);
if (class->name_version > 1)
[RFC PATCH] mm, oom_reaper: skip mm structs with mmu notifiers
From: Michal Hocko
Andrea has noticed that the oom_reaper doesn't invalidate the range
via mmu notifiers (mmu_notifier_invalidate_range_start,
mmu_notifier_invalidate_range_end) and that can corrupt the memory
of the kvm guest for example. As the callback is allowed to sleep
and the implementation is out of hand of the MM it is safer to simply
bail out if there is an mmu notifier registered. In order to not
fail too early make the mm_has_notifiers check under the oom_lock
and have a little nap before failing to give the current oom victim some
more time to exit.
Fixes: aac453635549 ("mm, oom: introduce oom reaper")
Noticed-by: Andrea Arcangeli
Cc: stable
Signed-off-by: Michal Hocko
---
Hi,
Andrea has pointed this out [1] while a different (but similar) bug has been
discussed. This is an ugly hack to plug the potential memory corruption but
we definitely want a better fix longterm.
Does this sound like a viable option for now?
[1] http://lkml.kernel.org/r/20170829140924.gb21...@redhat.com
include/linux/mmu_notifier.h | 5 +
mm/oom_kill.c| 15 +++
2 files changed, 20 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index c91b3bcd158f..947f21b451d2 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -420,6 +420,11 @@ extern void mmu_notifier_synchronize(void);
#else /* CONFIG_MMU_NOTIFIER */
+static inline int mm_has_notifiers(struct mm_struct *mm)
+{
+ return 0;
+}
+
static inline void mmu_notifier_release(struct mm_struct *mm)
{
}
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 99736e026712..45f1a0c3dd90 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -488,6 +489,20 @@ static bool __oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
*/
mutex_lock(&oom_lock);
+ /*
+* If the mm has notifiers then we would need to invalidate them around
+* unmap_page_range and that is risky because notifiers can sleep and
+* what they do is basically undeterministic. So let's have a short
sleep
+* to give the oom victim some more time.
+* TODO: we really want to get rid of this ugly hack and make sure that
+* notifiers cannot block for unbounded amount of time and add
+* mmu_notifier_invalidate_range_{start,end} around unmap_page_range
+*/
+ if (mm_has_notifiers(mm)) {
+ schedule_timeout_idle(HZ);
+ goto unlock_oom;
+ }
+
if (!down_read_trylock(&mm->mmap_sem)) {
ret = false;
trace_skip_task_reaping(tsk->pid);
--
2.13.2
Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]
On Wed, Aug 30, 2017 at 10:42:07AM +0200, Peter Zijlstra wrote: > > So the overhead looks to be spread out over all sorts, which makes it > harder to find and fix. > > stack unwinding is done lots and is fairly expensive, I've not yet > checked if crossrelease does too much of that. Aah, we do an unconditional stack unwind for every __lock_acquire() now. It keeps a trace in the xhlocks[]. Does the below cure most of that overhead? diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 44c8d0d17170..7b872036b72e 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -4872,7 +4872,7 @@ static void add_xhlock(struct held_lock *hlock) xhlock->trace.max_entries = MAX_XHLOCK_TRACE_ENTRIES; xhlock->trace.entries = xhlock->trace_entries; xhlock->trace.skip = 3; - save_stack_trace(&xhlock->trace); + /* save_stack_trace(&xhlock->trace); */ } static inline int same_context_xhlock(struct hist_lock *xhlock)
[PATCH 02/13] thermal/drivers/hisi: Remove the multiple sensors support
By essence, the tsensor does not really support multiple sensor at the same
time. It allows to set a sensor and use it to get the temperature, another
sensor could be switched but with a delay of 3-5ms. It is difficult to read
simultaneously several sensors without a big delay.
Today, just one sensor is used, it is not necessary to deal with multiple
sensors in the code. Remove them and if it is needed in the future add them
on top of a code which will be clean up in the meantime.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 77 +++---
1 file changed, 20 insertions(+), 57 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 8381696..92b6889 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -39,6 +39,7 @@
#define HISI_TEMP_RESET(10)
#define HISI_MAX_SENSORS 4
+#define HISI_DEFAULT_SENSOR2
struct hisi_thermal_sensor {
struct hisi_thermal_data *thermal;
@@ -53,11 +54,10 @@ struct hisi_thermal_data {
struct mutex thermal_lock;/* protects register data */
struct platform_device *pdev;
struct clk *clk;
- struct hisi_thermal_sensor sensors[HISI_MAX_SENSORS];
-
- int irq, irq_bind_sensor;
+ struct hisi_thermal_sensor sensors;
+ int irq;
bool irq_enabled;
-
+
void __iomem *regs;
};
@@ -113,7 +113,7 @@ static void hisi_thermal_enable_bind_irq_sensor
mutex_lock(&data->thermal_lock);
- sensor = &data->sensors[data->irq_bind_sensor];
+ sensor = &data->sensors;
/* setting the hdak time */
writel(0x0, data->regs + TEMP0_CFG);
@@ -160,31 +160,8 @@ static int hisi_thermal_get_temp(void *_sensor, int *temp)
struct hisi_thermal_sensor *sensor = _sensor;
struct hisi_thermal_data *data = sensor->thermal;
- int sensor_id = -1, i;
- long max_temp = 0;
-
*temp = hisi_thermal_get_sensor_temp(data, sensor);
- sensor->sensor_temp = *temp;
-
- for (i = 0; i < HISI_MAX_SENSORS; i++) {
- if (!data->sensors[i].tzd)
- continue;
-
- if (data->sensors[i].sensor_temp >= max_temp) {
- max_temp = data->sensors[i].sensor_temp;
- sensor_id = i;
- }
- }
-
- /* If no sensor has been enabled, then skip to enable irq */
- if (sensor_id == -1)
- return 0;
-
- mutex_lock(&data->thermal_lock);
- data->irq_bind_sensor = sensor_id;
- mutex_unlock(&data->thermal_lock);
-
dev_dbg(&data->pdev->dev, "id=%d, irq=%d, temp=%d, thres=%d\n",
sensor->id, data->irq_enabled, *temp, sensor->thres_temp);
/*
@@ -197,7 +174,7 @@ static int hisi_thermal_get_temp(void *_sensor, int *temp)
return 0;
}
- if (max_temp < sensor->thres_temp) {
+ if (*temp < sensor->thres_temp) {
data->irq_enabled = true;
hisi_thermal_enable_bind_irq_sensor(data);
enable_irq(data->irq);
@@ -224,22 +201,16 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int irq,
void *dev)
{
struct hisi_thermal_data *data = dev;
struct hisi_thermal_sensor *sensor;
- int i;
mutex_lock(&data->thermal_lock);
- sensor = &data->sensors[data->irq_bind_sensor];
+ sensor = &data->sensors;
dev_crit(&data->pdev->dev, "THERMAL ALARM: T > %d\n",
sensor->thres_temp / 1000);
mutex_unlock(&data->thermal_lock);
- for (i = 0; i < HISI_MAX_SENSORS; i++) {
- if (!data->sensors[i].tzd)
- continue;
-
- thermal_zone_device_update(data->sensors[i].tzd,
- THERMAL_EVENT_UNSPECIFIED);
- }
+ thermal_zone_device_update(data->sensors.tzd,
+ THERMAL_EVENT_UNSPECIFIED);
return IRQ_HANDLED;
}
@@ -296,7 +267,6 @@ static int hisi_thermal_probe(struct platform_device *pdev)
{
struct hisi_thermal_data *data;
struct resource *res;
- int i;
int ret;
data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
@@ -347,16 +317,17 @@ static int hisi_thermal_probe(struct platform_device
*pdev)
hisi_thermal_enable_bind_irq_sensor(data);
data->irq_enabled = true;
- for (i = 0; i < HISI_MAX_SENSORS; ++i) {
- ret = hisi_thermal_register_sensor(pdev, data,
- &data->sensors[i], i);
- if (ret)
- dev_err(&pdev->dev,
- "failed to register thermal sensor: %d\n", ret);
- else
- hisi_thermal_toggle_sensor(&data->sensors[i], true);
+ ret = hisi_thermal_r
[PATCH 12/13] thermal/drivers/hisi: Remove thermal data back pointer
The presence of the thermal data pointer in the sensor structure has the unique
purpose of accessing the thermal data in the interrupt handler.
The sensor pointer is passed when registering the interrupt handler, replace the
cookie by the thermal data pointer, so the back pointer is no longer needed.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 9eee82b..b1b086ab 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -45,7 +45,6 @@
#define HISI_DEFAULT_SENSOR2
struct hisi_thermal_sensor {
- struct hisi_thermal_data *thermal;
struct thermal_zone_device *tzd;
uint32_t id;
uint32_t thres_temp;
@@ -207,10 +206,10 @@ static void hisi_thermal_disable_sensor(struct
hisi_thermal_data *data)
mutex_unlock(&data->thermal_lock);
}
-static int hisi_thermal_get_temp(void *_sensor, int *temp)
+static int hisi_thermal_get_temp(void *__data, int *temp)
{
- struct hisi_thermal_sensor *sensor = _sensor;
- struct hisi_thermal_data *data = sensor->thermal;
+ struct hisi_thermal_data *data = __data;
+ struct hisi_thermal_sensor *sensor = &data->sensor;
*temp = hisi_thermal_get_temperature(data->regs);
@@ -258,10 +257,10 @@ static int hisi_thermal_register_sensor(struct
platform_device *pdev,
const struct thermal_trip *trip;
sensor->id = index;
- sensor->thermal = data;
sensor->tzd = devm_thermal_zone_of_sensor_register(&pdev->dev,
- sensor->id, sensor, &hisi_of_thermal_ops);
+ sensor->id, data,
+
&hisi_of_thermal_ops);
if (IS_ERR(sensor->tzd)) {
ret = PTR_ERR(sensor->tzd);
sensor->tzd = NULL;
--
2.7.4
[PATCH 10/13] thermal/drivers/hisi: Rename and remove unused field
Rename the 'sensors' field to 'sensor' as we describe only one sensor.
Remove the 'sensor_temp' as it is no longer used.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index b038d8a..68b625c 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -47,8 +47,6 @@
struct hisi_thermal_sensor {
struct hisi_thermal_data *thermal;
struct thermal_zone_device *tzd;
-
- long sensor_temp;
uint32_t id;
uint32_t thres_temp;
};
@@ -57,9 +55,9 @@ struct hisi_thermal_data {
struct mutex thermal_lock;/* protects register data */
struct platform_device *pdev;
struct clk *clk;
- struct hisi_thermal_sensor sensors;
- int irq;
+ struct hisi_thermal_sensor sensor;
void __iomem *regs;
+ int irq;
};
/*
@@ -229,7 +227,7 @@ static const struct thermal_zone_of_device_ops
hisi_of_thermal_ops = {
static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, void *dev)
{
struct hisi_thermal_data *data = dev;
- struct hisi_thermal_sensor *sensor = &data->sensors;
+ struct hisi_thermal_sensor *sensor = &data->sensor;
int temp;
hisi_thermal_alarm_clear(data->regs, 1);
@@ -240,7 +238,7 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int irq,
void *dev)
dev_crit(&data->pdev->dev, "THERMAL ALARM: %d > %d\n",
temp, sensor->thres_temp);
- thermal_zone_device_update(data->sensors.tzd,
+ thermal_zone_device_update(data->sensor.tzd,
THERMAL_EVENT_UNSPECIFIED);
} else if (temp < sensor->thres_temp) {
@@ -303,7 +301,7 @@ static int hisi_thermal_setup(struct hisi_thermal_data
*data)
{
struct hisi_thermal_sensor *sensor;
- sensor = &data->sensors;
+ sensor = &data->sensor;
/* disable module firstly */
hisi_thermal_reset_enable(data->regs, 0);
@@ -376,7 +374,7 @@ static int hisi_thermal_probe(struct platform_device *pdev)
}
ret = hisi_thermal_register_sensor(pdev, data,
- &data->sensors,
+ &data->sensor,
HISI_DEFAULT_SENSOR);
if (ret) {
dev_err(&pdev->dev, "failed to register thermal sensor: %d\n",
@@ -398,7 +396,7 @@ static int hisi_thermal_probe(struct platform_device *pdev)
return ret;
}
- hisi_thermal_toggle_sensor(&data->sensors, true);
+ hisi_thermal_toggle_sensor(&data->sensor, true);
return 0;
}
@@ -406,7 +404,7 @@ static int hisi_thermal_probe(struct platform_device *pdev)
static int hisi_thermal_remove(struct platform_device *pdev)
{
struct hisi_thermal_data *data = platform_get_drvdata(pdev);
- struct hisi_thermal_sensor *sensor = &data->sensors;
+ struct hisi_thermal_sensor *sensor = &data->sensor;
hisi_thermal_toggle_sensor(sensor, false);
hisi_thermal_disable_sensor(data);
--
2.7.4
[PATCH 11/13] thermal/drivers/hisi: Convert long to int
There is no point to specify the temperature as long variable, the int is
enough.
Replace all long variables to int, so making the code consistent.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 68b625c..9eee82b 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -83,12 +83,12 @@ static inline int hisi_thermal_step_to_temp(int step)
return HISI_TEMP_BASE + (step * HISI_TEMP_STEP);
}
-static inline long hisi_thermal_temp_to_step(long temp)
+static inline int hisi_thermal_temp_to_step(int temp)
{
return (temp - HISI_TEMP_BASE) / HISI_TEMP_STEP;
}
-static inline long hisi_thermal_round_temp(int temp)
+static inline int hisi_thermal_round_temp(int temp)
{
return hisi_thermal_step_to_temp(
hisi_thermal_temp_to_step(temp));
--
2.7.4
[PATCH 13/13] thermal/drivers/hisi: Remove mutex_lock in the code
The mutex is used to protect against writes in the configuration register.
That happens at probe time, with no possible race yet.
Then when the module is unloaded and at suspend/resume.
When the module is unloaded, it is an userspace operation, thus via a process.
Suspending the system goes through the freezer to suspend all the tasks
synchronously before continuing. So it is not possible to hit the suspend ops
in this driver while we are unloading it.
The resume is the same situation than the probe.
In other words, even if there are several places where we write the
configuration register, there is no situation where we can write it at the same
time, so far as I can judge
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index b1b086ab..b9e8ee2 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -51,7 +51,6 @@ struct hisi_thermal_sensor {
};
struct hisi_thermal_data {
- struct mutex thermal_lock;/* protects register data */
struct platform_device *pdev;
struct clk *clk;
struct hisi_thermal_sensor sensor;
@@ -196,14 +195,10 @@ static inline void hisi_thermal_hdak_set(void __iomem
*addr, int value)
static void hisi_thermal_disable_sensor(struct hisi_thermal_data *data)
{
- mutex_lock(&data->thermal_lock);
-
/* disable sensor module */
hisi_thermal_enable(data->regs, 0);
hisi_thermal_alarm_enable(data->regs, 0);
hisi_thermal_reset_enable(data->regs, 0);
-
- mutex_unlock(&data->thermal_lock);
}
static int hisi_thermal_get_temp(void *__data, int *temp)
@@ -340,7 +335,6 @@ static int hisi_thermal_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
- mutex_init(&data->thermal_lock);
data->pdev = pdev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
2.7.4
[PATCH 07/13] thermal/drivers/hisi: Encapsulate register writes into helpers
Hopefully, the function name can help to clarify the semantic of the operations
when writing in the register.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 96 +++---
1 file changed, 72 insertions(+), 24 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 6f0dab1..d77a938 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -26,6 +26,7 @@
#include "thermal_core.h"
+#define TEMP0_LAG (0x0)
#define TEMP0_TH (0x4)
#define TEMP0_RST_TH (0x8)
#define TEMP0_CFG (0xC)
@@ -96,6 +97,56 @@ static inline long hisi_thermal_round_temp(int temp)
hisi_thermal_temp_to_step(temp));
}
+static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
+{
+ writel(value, addr + TEMP0_LAG);
+}
+
+static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
+{
+ writel(value, addr + TEMP0_INT_CLR);
+}
+
+static inline void hisi_thermal_alarm_enable(void __iomem *addr, int value)
+{
+ writel(value, addr + TEMP0_INT_EN);
+}
+
+static inline void hisi_thermal_alarm_set(void __iomem *addr, int temp)
+{
+ writel(hisi_thermal_temp_to_step(temp) | 0x0FF00, addr + TEMP0_TH);
+}
+
+static inline void hisi_thermal_reset_set(void __iomem *addr, int temp)
+{
+writel(hisi_thermal_temp_to_step(temp), addr + TEMP0_RST_TH);
+}
+
+static inline void hisi_thermal_reset_enable(void __iomem *addr, int value)
+{
+writel(value, addr + TEMP0_RST_MSK);
+}
+
+static inline void hisi_thermal_enable(void __iomem *addr, int value)
+{
+ writel(value, addr + TEMP0_EN);
+}
+
+static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
+{
+ writel((sensor << 12), addr + TEMP0_CFG);
+}
+
+static inline int hisi_thermal_get_temperature(void __iomem *addr)
+{
+ return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
+}
+
+static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
+{
+ writel(value, addr + TEMP0_CFG);
+}
+
static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
struct hisi_thermal_sensor *sensor)
{
@@ -104,22 +155,21 @@ static long hisi_thermal_get_sensor_temp(struct
hisi_thermal_data *data,
mutex_lock(&data->thermal_lock);
/* disable interrupt */
- writel(0x0, data->regs + TEMP0_INT_EN);
- writel(0x1, data->regs + TEMP0_INT_CLR);
+ hisi_thermal_alarm_enable(data->regs, 0);
+ hisi_thermal_alarm_clear(data->regs, 1);
/* disable module firstly */
- writel(0x0, data->regs + TEMP0_EN);
+ hisi_thermal_enable(data->regs, 0);
/* select sensor id */
- writel((sensor->id << 12), data->regs + TEMP0_CFG);
+ hisi_thermal_sensor_select(data->regs, sensor->id);
/* enable module */
- writel(0x1, data->regs + TEMP0_EN);
+ hisi_thermal_enable(data->regs, 1);
usleep_range(3000, 5000);
- val = readl(data->regs + TEMP0_VALUE);
- val = hisi_thermal_step_to_temp(val);
+ val = hisi_thermal_get_temperature(data->regs);
mutex_unlock(&data->thermal_lock);
@@ -136,29 +186,27 @@ static void hisi_thermal_enable_bind_irq_sensor
sensor = &data->sensors;
/* setting the hdak time */
- writel(0x0, data->regs + TEMP0_CFG);
+ hisi_thermal_hdak_set(data->regs, 0);
/* disable module firstly */
- writel(0x0, data->regs + TEMP0_RST_MSK);
- writel(0x0, data->regs + TEMP0_EN);
+ hisi_thermal_reset_enable(data->regs, 0);
+ hisi_thermal_enable(data->regs, 0);
/* select sensor id */
- writel((sensor->id << 12), data->regs + TEMP0_CFG);
+ hisi_thermal_sensor_select(data->regs, sensor->id);
/* enable for interrupt */
- writel(hisi_thermal_temp_to_step(sensor->thres_temp) | 0x0FF00,
- data->regs + TEMP0_TH);
+ hisi_thermal_alarm_set(data->regs, sensor->thres_temp);
- writel(hisi_thermal_temp_to_step(HISI_TEMP_RESET),
- data->regs + TEMP0_RST_TH);
+ hisi_thermal_reset_set(data->regs, HISI_TEMP_RESET);
/* enable module */
- writel(0x1, data->regs + TEMP0_RST_MSK);
- writel(0x1, data->regs + TEMP0_EN);
-
- writel(0x0, data->regs + TEMP0_INT_CLR);
- writel(0x1, data->regs + TEMP0_INT_EN);
+ hisi_thermal_reset_enable(data->regs, 1);
+ hisi_thermal_enable(data->regs, 1);
+ hisi_thermal_alarm_clear(data->regs, 0);
+ hisi_thermal_alarm_enable(data->regs, 1);
+
usleep_range(3000, 5000);
mutex_unlock(&data->thermal_lock);
@@ -169,10 +217,10 @@ static void hisi_thermal_disable_sensor(struct
hisi_thermal_data *data)
mutex_lock(&data->thermal_lock);
/* disable sensor module */
- wr
[PATCH 08/13] thermal/drivers/hisi: Fix configuration register setting
The TEMP0_CFG configuration register contains different field to set up the
temperature controller. However in the code, nothing prevents a setup to
overwrite the previous one: eg. writing the hdak value overwrites the sensor
selection, the sensor selection overwrites the hdak value.
In order to prevent such thing, use a regmap-like mechanism by reading the
value before, set the corresponding bits and write the result.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index d77a938..3e03908 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -132,19 +132,39 @@ static inline void hisi_thermal_enable(void __iomem
*addr, int value)
writel(value, addr + TEMP0_EN);
}
-static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
+static inline int hisi_thermal_get_temperature(void __iomem *addr)
{
- writel((sensor << 12), addr + TEMP0_CFG);
+ return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
}
-static inline int hisi_thermal_get_temperature(void __iomem *addr)
+/*
+ * Temperature configuration register - Sensor selection
+ *
+ * Bits [19:12]
+ *
+ * 0x0: local sensor (default)
+ * 0x1: remote sensor 1 (ACPU cluster 1)
+ * 0x2: remote sensor 2 (ACPU cluster 0)
+ * 0x3: remote sensor 3 (G3D)
+ */
+static inline void hisi_thermal_sensor_select(void __iomem *addr, int sensor)
{
- return hisi_thermal_step_to_temp(readl(addr + TEMP0_VALUE));
+ writel(readl(addr + TEMP0_CFG) | (sensor << 12), addr + TEMP0_CFG);
}
+/*
+ * Temperature configuration register - Hdak conversion polling interval
+ *
+ * Bits [5:4]
+ *
+ * 0x0 : 0.768 ms
+ * 0x1 : 6.144 ms
+ * 0x2 : 49.152 ms
+ * 0x3 : 393.216 ms
+ */
static inline void hisi_thermal_hdak_set(void __iomem *addr, int value)
{
- writel(value, addr + TEMP0_CFG);
+ writel(readl(addr + TEMP0_CFG) | (value << 4), addr + TEMP0_CFG);
}
static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
--
2.7.4
[PATCH 05/13] thermal/drivers/hisi: Fix multiple alarm interrupts firing
The DT specifies a threshold of 65000, we setup the register with a value in
the temperature resolution for the controller, 64656.
When we reach 64656, the interrupt fires, the interrupt is disabled. Then the
irq thread runs and calls thermal_zone_device_update() which will call in turn
hisi_thermal_get_temp().
The function will look if the temperature decreased, assuming it was more than
65000, but that is not the case because the current temperature is 64656
(because of the rounding when setting the threshold). This condition being
true, we re-enable the interrupt which fires immediately after exiting the irq
thread. That happens again and again until the temperature goes to more than
65000.
Potentially, there is here an interrupt storm if the temperature stabilizes at
this temperature. A very unlikely case but possible.
In any case, it does not make sense to handle dozens of alarm interrupt for
nothing.
Fix this by rounding the threshold value to the controller resolution so the
check against the threshold is consistent with the one set in the controller.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index b58ad40..524310d 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -90,6 +90,12 @@ static inline long hisi_thermal_temp_to_step(long temp)
return (temp - HISI_TEMP_BASE) / HISI_TEMP_STEP;
}
+static inline long hisi_thermal_round_temp(int temp)
+{
+ return hisi_thermal_step_to_temp(
+ hisi_thermal_temp_to_step(temp));
+}
+
static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
struct hisi_thermal_sensor *sensor)
{
@@ -221,7 +227,7 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int irq,
void *dev)
sensor = &data->sensors;
dev_crit(&data->pdev->dev, "THERMAL ALARM: T > %d\n",
-sensor->thres_temp / 1000);
+sensor->thres_temp);
mutex_unlock(&data->thermal_lock);
thermal_zone_device_update(data->sensors.tzd,
@@ -255,7 +261,7 @@ static int hisi_thermal_register_sensor(struct
platform_device *pdev,
for (i = 0; i < of_thermal_get_ntrips(sensor->tzd); i++) {
if (trip[i].type == THERMAL_TRIP_PASSIVE) {
- sensor->thres_temp = trip[i].temperature;
+ sensor->thres_temp =
hisi_thermal_round_temp(trip[i].temperature);
break;
}
}
--
2.7.4
[PATCH 09/13] thermal/drivers/hisi: Remove costly sensor inspection
The sensor is all setup, bind, resetted, acked, etc... every single second.
That was the way to workaround a problem with the interrupt bouncing again and
again.
With the following changes, we fix all in one:
- Do the setup, one time, at probe time
- Add the IRQF_ONESHOT, ack the interrupt in the threaded handler
- Remove the interrupt handler
- Set the correct value for the LAG register
- Remove all the irq_enabled stuff in the code as the interruption
handling is fixed
- Remove the 3ms delay
- Reorder the initialization routine to be in the right order
It ends up to a nicer code and more efficient, the 3-5ms delay is removed from
the get_temp() path.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 203 +++--
1 file changed, 93 insertions(+), 110 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 3e03908..b038d8a 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -39,6 +39,7 @@
#define HISI_TEMP_BASE (-6)
#define HISI_TEMP_RESET(10)
#define HISI_TEMP_STEP (784)
+#define HISI_TEMP_LAG (3500)
#define HISI_MAX_SENSORS 4
#define HISI_DEFAULT_SENSOR2
@@ -58,8 +59,6 @@ struct hisi_thermal_data {
struct clk *clk;
struct hisi_thermal_sensor sensors;
int irq;
- bool irq_enabled;
-
void __iomem *regs;
};
@@ -97,9 +96,40 @@ static inline long hisi_thermal_round_temp(int temp)
hisi_thermal_temp_to_step(temp));
}
+/*
+ * The lag register contains 5 bits encoding the temperature in steps.
+ *
+ * Each time the temperature crosses the threshold boundary, an
+ * interrupt is raised. It could be when the temperature is going
+ * above the threshold or below. However, if the temperature is
+ * fluctuating around this value due to the load, we can receive
+ * several interrupts which may not desired.
+ *
+ * We can setup a temperature representing the delta between the
+ * threshold and the current temperature when the temperature is
+ * decreasing.
+ *
+ * For instance: the lag register is 5°C, the threshold is 65°C, when
+ * the temperature reaches 65°C an interrupt is raised and when the
+ * temperature decrease to 65°C - 5°C another interrupt is raised.
+ *
+ * A very short lag can lead to an interrupt storm, a long lag
+ * increase the latency to react to the temperature changes. In our
+ * case, that is not really a problem as we are polling the
+ * temperature.
+ *
+ * [0:4] : lag register
+ *
+ * The temperature is coded in steps, cf. HISI_TEMP_STEP.
+ *
+ * Min : 0x00 : 0.0 °C
+ * Max : 0x1F : 24.3 °C
+ *
+ * The 'value' parameter is in milliCelsius.
+ */
static inline void hisi_thermal_set_lag(void __iomem *addr, int value)
{
- writel(value, addr + TEMP0_LAG);
+ writel((value / HISI_TEMP_STEP) & 0x1F, addr + TEMP0_LAG);
}
static inline void hisi_thermal_alarm_clear(void __iomem *addr, int value)
@@ -167,71 +197,6 @@ static inline void hisi_thermal_hdak_set(void __iomem
*addr, int value)
writel(readl(addr + TEMP0_CFG) | (value << 4), addr + TEMP0_CFG);
}
-static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
-struct hisi_thermal_sensor *sensor)
-{
- long val;
-
- mutex_lock(&data->thermal_lock);
-
- /* disable interrupt */
- hisi_thermal_alarm_enable(data->regs, 0);
- hisi_thermal_alarm_clear(data->regs, 1);
-
- /* disable module firstly */
- hisi_thermal_enable(data->regs, 0);
-
- /* select sensor id */
- hisi_thermal_sensor_select(data->regs, sensor->id);
-
- /* enable module */
- hisi_thermal_enable(data->regs, 1);
-
- usleep_range(3000, 5000);
-
- val = hisi_thermal_get_temperature(data->regs);
-
- mutex_unlock(&data->thermal_lock);
-
- return val;
-}
-
-static void hisi_thermal_enable_bind_irq_sensor
- (struct hisi_thermal_data *data)
-{
- struct hisi_thermal_sensor *sensor;
-
- mutex_lock(&data->thermal_lock);
-
- sensor = &data->sensors;
-
- /* setting the hdak time */
- hisi_thermal_hdak_set(data->regs, 0);
-
- /* disable module firstly */
- hisi_thermal_reset_enable(data->regs, 0);
- hisi_thermal_enable(data->regs, 0);
-
- /* select sensor id */
- hisi_thermal_sensor_select(data->regs, sensor->id);
-
- /* enable for interrupt */
- hisi_thermal_alarm_set(data->regs, sensor->thres_temp);
-
- hisi_thermal_reset_set(data->regs, HISI_TEMP_RESET);
-
- /* enable module */
- hisi_thermal_reset_enable(data->regs, 1);
- hisi_thermal_enable(data->regs, 1);
-
- hisi_thermal_alarm_clear(data->regs, 0);
- hisi_thermal_alarm_enable(data->regs, 1);
-
- usleep_range(3000, 5
[PATCH 04/13] thermal/drivers/hisi: Simplify the temperature/step computation
The step and the base temperature are fixed values, we can simplify the
computation by converting the base temperature to milli celsius and use a
pre-computed step value. That saves us a lot of mult + div for nothing at
runtime.
Take also the opportunity to change the function names to be consistent with
the rest of the code.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 67db523..b58ad40 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -35,8 +35,9 @@
#define TEMP0_RST_MSK (0x1C)
#define TEMP0_VALUE(0x28)
-#define HISI_TEMP_BASE (-60)
+#define HISI_TEMP_BASE (-6)
#define HISI_TEMP_RESET(10)
+#define HISI_TEMP_STEP (784)
#define HISI_MAX_SENSORS 4
#define HISI_DEFAULT_SENSOR2
@@ -61,19 +62,32 @@ struct hisi_thermal_data {
void __iomem *regs;
};
-/* in millicelsius */
-static inline int _step_to_temp(int step)
+/*
+ * The temperature computation on the tsensor is as follow:
+ * Unit: millidegree Celsius
+ * Step: 255/200 (0.7843)
+ * Temperature base: -60°C
+ *
+ * The register is programmed in temperature steps, every step is 784
+ * millidegree and begins at -60 000 m°C
+ *
+ * The temperature from the steps:
+ *
+ * Temp = TempBase + (steps x 784)
+ *
+ * and the steps from the temperature:
+ *
+ * steps = (Temp - TempBase) / 784
+ *
+ */
+static inline int hisi_thermal_step_to_temp(int step)
{
- /*
-* Every step equals (1 * 200) / 255 celsius, and finally
-* need convert to millicelsius.
-*/
- return (HISI_TEMP_BASE * 1000 + (step * 20 / 255));
+ return HISI_TEMP_BASE + (step * HISI_TEMP_STEP);
}
-static inline long _temp_to_step(long temp)
+static inline long hisi_thermal_temp_to_step(long temp)
{
- return ((temp - HISI_TEMP_BASE * 1000) * 255) / 20;
+ return (temp - HISI_TEMP_BASE) / HISI_TEMP_STEP;
}
static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data,
@@ -99,7 +113,7 @@ static long hisi_thermal_get_sensor_temp(struct
hisi_thermal_data *data,
usleep_range(3000, 5000);
val = readl(data->regs + TEMP0_VALUE);
- val = _step_to_temp(val);
+ val = hisi_thermal_step_to_temp(val);
mutex_unlock(&data->thermal_lock);
@@ -126,10 +140,11 @@ static void hisi_thermal_enable_bind_irq_sensor
writel((sensor->id << 12), data->regs + TEMP0_CFG);
/* enable for interrupt */
- writel(_temp_to_step(sensor->thres_temp) | 0x0FF00,
+ writel(hisi_thermal_temp_to_step(sensor->thres_temp) | 0x0FF00,
data->regs + TEMP0_TH);
- writel(_temp_to_step(HISI_TEMP_RESET), data->regs + TEMP0_RST_TH);
+ writel(hisi_thermal_temp_to_step(HISI_TEMP_RESET),
+ data->regs + TEMP0_RST_TH);
/* enable module */
writel(0x1, data->regs + TEMP0_RST_MSK);
--
2.7.4
[PATCH 06/13] thermal/drivers/hisi: Remove pointless lock
The threaded interrupt inspect the sensors structure to look in the temp
threshold field, but this field is read-only in all the code, except in the
probe function before the threaded interrupt is set. In other words there
is not race window in the threaded interrupt when reading the field value.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 524310d..6f0dab1 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -221,14 +221,10 @@ static irqreturn_t hisi_thermal_alarm_irq(int irq, void
*dev)
static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, void *dev)
{
struct hisi_thermal_data *data = dev;
- struct hisi_thermal_sensor *sensor;
-
- mutex_lock(&data->thermal_lock);
- sensor = &data->sensors;
+ struct hisi_thermal_sensor *sensor = &data->sensors;
dev_crit(&data->pdev->dev, "THERMAL ALARM: T > %d\n",
sensor->thres_temp);
- mutex_unlock(&data->thermal_lock);
thermal_zone_device_update(data->sensors.tzd,
THERMAL_EVENT_UNSPECIFIED);
--
2.7.4
[PATCH 01/13] thermal/drivers/hisi: Fix missing interrupt enablement
The interrupt for the temperature threshold is not enabled at the end of the
probe function, enable it after the setup is complete.
On the other side, the irq_enabled is not correctly set as we are checking if
the interrupt is masked where 'yes' means irq_enabled=false.
irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED,
&data->irq_enabled);
As we are always enabling the interrupt, it is pointless to check if
the interrupt is masked or not, just set irq_enabled to 'true'.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index bd3572c..8381696 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -345,8 +345,7 @@ static int hisi_thermal_probe(struct platform_device *pdev)
}
hisi_thermal_enable_bind_irq_sensor(data);
- irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED,
- &data->irq_enabled);
+ data->irq_enabled = true;
for (i = 0; i < HISI_MAX_SENSORS; ++i) {
ret = hisi_thermal_register_sensor(pdev, data,
@@ -358,6 +357,8 @@ static int hisi_thermal_probe(struct platform_device *pdev)
hisi_thermal_toggle_sensor(&data->sensors[i], true);
}
+ enable_irq(data->irq);
+
return 0;
}
--
2.7.4
[PATCH 03/13] thermal/drivers/hisi: Fix kernel panic on alarm interrupt
The threaded interrupt for the alarm interrupt is requested before the
temperature controller is setup. This one can fire an interrupt immediately
leading to a kernel panic as the sensor data is not initialized.
In order to prevent that, move the threaded irq after the Tsensor is setup.
Signed-off-by: Daniel Lezcano
---
drivers/thermal/hisi_thermal.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 92b6889..67db523 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -287,15 +287,6 @@ static int hisi_thermal_probe(struct platform_device *pdev)
if (data->irq < 0)
return data->irq;
- ret = devm_request_threaded_irq(&pdev->dev, data->irq,
- hisi_thermal_alarm_irq,
- hisi_thermal_alarm_irq_thread,
- 0, "hisi_thermal", data);
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to request alarm irq: %d\n", ret);
- return ret;
- }
-
platform_set_drvdata(pdev, data);
data->clk = devm_clk_get(&pdev->dev, "thermal_clk");
@@ -328,6 +319,15 @@ static int hisi_thermal_probe(struct platform_device *pdev)
hisi_thermal_toggle_sensor(&data->sensors, true);
+ ret = devm_request_threaded_irq(&pdev->dev, data->irq,
+ hisi_thermal_alarm_irq,
+ hisi_thermal_alarm_irq_thread,
+ 0, "hisi_thermal", data);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to request alarm irq: %d\n", ret);
+ return ret;
+ }
+
enable_irq(data->irq);
return 0;
--
2.7.4
Re: [[PATCH v1] 15/37] [CIFS] SMBD: Post a SMBD data transfer message with data payload
On Wed, Aug 30, 2017 at 02:17:56AM +, Long Li wrote: > I partially addressed this issue in the V3 patch. Most of the duplicate > code on sending path is merged. > > The difficulty with translating the buffer to pages is that: I don't > know how many pages will be translated, and how many struct page I need > to allocate in advance to hold them. I try to avoid memory allocation > in the I/O path as much as possible. So I keep two functions of > sending data: one for buffer and one for pages. You do: you'll always need speace for (len + PAGE_SIZE - 1) >> PAGE_SIZE pages. That being said: what callers even send you buffers? In general we should aim to work with pages for all allocations that aren't tiny.
RE: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]
> -Original Message- > From: Peter Zijlstra [mailto:pet...@infradead.org] > Sent: Wednesday, August 30, 2017 5:48 PM > To: Sergey Senozhatsky > Cc: Byungchul Park; Bart Van Assche; linux-kernel@vger.kernel.org; linux- > bl...@vger.kernel.org; martin.peter...@oracle.com; ax...@kernel.dk; linux- > s...@vger.kernel.org; s...@canb.auug.org.au; linux-n...@vger.kernel.org; > kernel-t...@lge.com > Subject: Re: possible circular locking dependency detected [was: linux- > next: Tree for Aug 22] > > On Wed, Aug 30, 2017 at 10:42:07AM +0200, Peter Zijlstra wrote: > > > > So the overhead looks to be spread out over all sorts, which makes it > > harder to find and fix. > > > > stack unwinding is done lots and is fairly expensive, I've not yet > > checked if crossrelease does too much of that. > > Aah, we do an unconditional stack unwind for every __lock_acquire() now. > It keeps a trace in the xhlocks[]. Yeah.. I also think this is most significant.. > > Does the below cure most of that overhead? > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index 44c8d0d17170..7b872036b72e 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -4872,7 +4872,7 @@ static void add_xhlock(struct held_lock *hlock) > xhlock->trace.max_entries = MAX_XHLOCK_TRACE_ENTRIES; > xhlock->trace.entries = xhlock->trace_entries; > xhlock->trace.skip = 3; > - save_stack_trace(&xhlock->trace); > + /* save_stack_trace(&xhlock->trace); */ > } > > static inline int same_context_xhlock(struct hist_lock *xhlock)
Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
On Wed, Aug 30, 2017 at 04:41:17PM +0900, Byungchul Park wrote: > On Wed, Aug 30, 2017 at 11:09:53AM +0900, Byungchul Park wrote: > > > Signed-off-by: Peter Zijlstra (Intel) > > > --- > > > diff --git a/kernel/workqueue.c b/kernel/workqueue.c > > > index c0331891dec1..ab3c0dc8c7ed 100644 > > > --- a/kernel/workqueue.c > > > +++ b/kernel/workqueue.c > > > @@ -2107,14 +2107,14 @@ __acquires(&pool->lock) > > >* Which would create W1->C->W1 dependencies, even though there is no > > >* actual deadlock possible. There are two solutions, using a > > >* read-recursive acquire on the work(queue) 'locks', but this will then > > > - * hit the lockdep limitation on recursive locks, or simly discard > > > + * hit the lockdep limitation on recursive locks, or simply discard > > >* these locks. > > >* > > >* AFAICT there is no possible deadlock scenario between the > > >* flush_work() and complete() primitives (except for single-threaded > > >* workqueues), so hiding them isn't a problem. > > >*/ > > > - crossrelease_hist_start(XHLOCK_PROC, true); > > > + lockdep_invariant_state(true); > > > > This is what I am always curious about. It would be ok if you agree with > > removing this work-around after fixing acquire things in wq. But, you > > keep to say this is essencial. > > > > You should focus on what dependencies actually are, than saparating > > contexts unnecessarily. Of course, we have to do it for each work, _BUT_ > > not between outside of work and each work since there might be > > dependencies between them certainly. > > You have never answered it. I'm curious about your answer. If you can't, > I think you have to revert all your patches. All yours are wrong. Because I don't understand what you're on about. And my patches actually work.
Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure
On 27/08/2017 02:18, Kirill A. Shutemov wrote:
> On Fri, Aug 18, 2017 at 12:05:13AM +0200, Laurent Dufour wrote:
>> +/*
>> + * vm_normal_page() adds some processing which should be done while
>> + * hodling the mmap_sem.
>> + */
>> +int handle_speculative_fault(struct mm_struct *mm, unsigned long address,
>> + unsigned int flags)
>> +{
>> +struct vm_fault vmf = {
>> +.address = address,
>> +};
>> +pgd_t *pgd;
>> +p4d_t *p4d;
>> +pud_t *pud;
>> +pmd_t *pmd;
>> +int dead, seq, idx, ret = VM_FAULT_RETRY;
>> +struct vm_area_struct *vma;
>> +struct mempolicy *pol;
>> +
>> +/* Clear flags that may lead to release the mmap_sem to retry */
>> +flags &= ~(FAULT_FLAG_ALLOW_RETRY|FAULT_FLAG_KILLABLE);
>> +flags |= FAULT_FLAG_SPECULATIVE;
>> +
>> +idx = srcu_read_lock(&vma_srcu);
>> +vma = find_vma_srcu(mm, address);
>> +if (!vma)
>> +goto unlock;
>> +
>> +/*
>> + * Validate the VMA found by the lockless lookup.
>> + */
>> +dead = RB_EMPTY_NODE(&vma->vm_rb);
>> +seq = raw_read_seqcount(&vma->vm_sequence); /* rmb <->
>> seqlock,vma_rb_erase() */
>> +if ((seq & 1) || dead)
>> +goto unlock;
>> +
>> +/*
>> + * Can't call vm_ops service has we don't know what they would do
>> + * with the VMA.
>> + * This include huge page from hugetlbfs.
>> + */
>> +if (vma->vm_ops)
>> +goto unlock;
>
> I think we need to have a way to white-list safe ->vm_ops.
>
>> +
>> +if (unlikely(!vma->anon_vma))
>> +goto unlock;
>
> It deserves a comment.
>
>> +
>> +vmf.vma_flags = READ_ONCE(vma->vm_flags);
>> +vmf.vma_page_prot = READ_ONCE(vma->vm_page_prot);
>> +
>> +/* Can't call userland page fault handler in the speculative path */
>> +if (unlikely(vmf.vma_flags & VM_UFFD_MISSING))
>> +goto unlock;
>> +
>> +/*
>> + * MPOL_INTERLEAVE implies additional check in mpol_misplaced() which
>> + * are not compatible with the speculative page fault processing.
>> + */
>> +pol = __get_vma_policy(vma, address);
>> +if (!pol)
>> +pol = get_task_policy(current);
>> +if (pol && pol->mode == MPOL_INTERLEAVE)
>> +goto unlock;
>> +
>> +if (vmf.vma_flags & VM_GROWSDOWN || vmf.vma_flags & VM_GROWSUP)
>> +/*
>> + * This could be detected by the check address against VMA's
>> + * boundaries but we want to trace it as not supported instead
>> + * of changed.
>> + */
>> +goto unlock;
>> +
>> +if (address < READ_ONCE(vma->vm_start)
>> +|| READ_ONCE(vma->vm_end) <= address)
>> +goto unlock;
>> +
>> +/*
>> + * The three following checks are copied from access_error from
>> + * arch/x86/mm/fault.c
>> + */
>> +if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
>> + flags & FAULT_FLAG_INSTRUCTION,
>> + flags & FAULT_FLAG_REMOTE))
>> +goto unlock;
>> +
>> +/* This is one is required to check that the VMA has write access set */
>> +if (flags & FAULT_FLAG_WRITE) {
>> +if (unlikely(!(vmf.vma_flags & VM_WRITE)))
>> +goto unlock;
>> +} else {
>> +if (unlikely(!(vmf.vma_flags & (VM_READ | VM_EXEC | VM_WRITE
>> +goto unlock;
>> +}
>> +
>> +/*
>> + * Do a speculative lookup of the PTE entry.
>> + */
>> +local_irq_disable();
>> +pgd = pgd_offset(mm, address);
>> +if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
>> +goto out_walk;
>> +
>> +p4d = p4d_alloc(mm, pgd, address);
>> +if (p4d_none(*p4d) || unlikely(p4d_bad(*p4d)))
>> +goto out_walk;
>> +
>> +pud = pud_alloc(mm, p4d, address);
>> +if (pud_none(*pud) || unlikely(pud_bad(*pud)))
>> +goto out_walk;
>> +
>> +pmd = pmd_offset(pud, address);
>> +if (pmd_none(*pmd) || unlikely(pmd_bad(*pmd)))
>> +goto out_walk;
>> +
>> +/*
>> + * The above does not allocate/instantiate page-tables because doing so
>> + * would lead to the possibility of instantiating page-tables after
>> + * free_pgtables() -- and consequently leaking them.
>> + *
>> + * The result is that we take at least one !speculative fault per PMD
>> + * in order to instantiate it.
>> + */
>
>
> Doing all this job and just give up because we cannot allocate page tables
> looks very wasteful to me.
>
> Have you considered to look how we can hand over from speculative to
> non-speculative path without starting from scratch (when possible)?
>
>> +/* Transparent huge pages are not supported. */
>> +if (unlikely(pmd_trans_huge(*pmd)))
>> +goto out_walk;
>
> That's looks like a blocker to me.
>
> Is there any problem with making it supported (besides plain coding)?
Re: [PATCH v3] mfd: tps65217: Introduce dependency on CONFIG_OF
On Wednesday 30 August 2017 01:35 PM, Javier Martinez Canillas wrote:
> Hello Keerthy,
>
> On Wed, Aug 30, 2017 at 7:50 AM, Keerthy wrote:
>> Currently the driver boots only via device tree hence add a
>> dependency on CONFIG_OF. This leaves with a bunch of unused code
>> so clean that up. This patch also makes use of probe_new function
>> in place of the probe function so as to avoid passing i2c_device_id.
>>
>> Signed-off-by: Keerthy
>> ---
>>
>> Changes in v3:
>>
>> * Added more details to commit log.
>> * No changes in code. Rebased to latest next branch.
>>
>> Changes in v2:
>>
>> * Cleaned up chip_id and data attached to the match.
>> * Cleaned up i2c_dev_id
>> * dropped the rest of the patches in series for now
>>
>> Boot tested and checked for regulator registrations on am335x-boneblack
>>
>
> Did you check building as a module? Autoload won't work if you remove
> the I2C device ID table.
You are right! I tracked many of your patches that are already in master
branch so assumed it to be working. Seems like not. Thanks for your
feedback.
>
> [snip]
>
>>
>> -static const struct i2c_device_id tps65217_id_table[] = {
>> - {"tps65217", TPS65217},
>> - { /* sentinel */ }
>> -};
>> -MODULE_DEVICE_TABLE(i2c, tps65217_id_table);
>> -
>
> Unfortunately this can't be removed yet. We are getting there but
> still some patches need to land.
>
> Rest of the patch looks good, so if you keep the I2C device ID table
> feel free to add:
>
> Reviewed-by: Javier Martinez Canillas
Thanks!
>
> Best regards,
> Javier
>
RE: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
> -Original Message- > From: Peter Zijlstra [mailto:pet...@infradead.org] > Sent: Wednesday, August 30, 2017 5:54 PM > To: Byungchul Park > Cc: mi...@kernel.org; t...@kernel.org; boqun.f...@gmail.com; > da...@fromorbit.com; johan...@sipsolutions.net; o...@redhat.com; linux- > ker...@vger.kernel.org; kernel-t...@lge.com > Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation > > On Wed, Aug 30, 2017 at 04:41:17PM +0900, Byungchul Park wrote: > > On Wed, Aug 30, 2017 at 11:09:53AM +0900, Byungchul Park wrote: > > > > > Signed-off-by: Peter Zijlstra (Intel) > > > > --- > > > > diff --git a/kernel/workqueue.c b/kernel/workqueue.c > > > > index c0331891dec1..ab3c0dc8c7ed 100644 > > > > --- a/kernel/workqueue.c > > > > +++ b/kernel/workqueue.c > > > > @@ -2107,14 +2107,14 @@ __acquires(&pool->lock) > > > > * Which would create W1->C->W1 dependencies, even though > there is no > > > > * actual deadlock possible. There are two solutions, using > a > > > > * read-recursive acquire on the work(queue) 'locks', but > this will then > > > > -* hit the lockdep limitation on recursive locks, or simly > discard > > > > +* hit the lockdep limitation on recursive locks, or simply > discard > > > > * these locks. > > > > * > > > > * AFAICT there is no possible deadlock scenario between the > > > > * flush_work() and complete() primitives (except for > single-threaded > > > > * workqueues), so hiding them isn't a problem. > > > > */ > > > > - crossrelease_hist_start(XHLOCK_PROC, true); > > > > + lockdep_invariant_state(true); > > > > > > This is what I am always curious about. It would be ok if you agree > with > > > removing this work-around after fixing acquire things in wq. But, you > > > keep to say this is essencial. > > > > > > You should focus on what dependencies actually are, than saparating > > > contexts unnecessarily. Of course, we have to do it for each work, > _BUT_ > > > not between outside of work and each work since there might be > > > dependencies between them certainly. > > > > You have never answered it. I'm curious about your answer. If you can't, > > I think you have to revert all your patches. All yours are wrong. > > Because I don't understand what you're on about. And my patches actually > work. My point is that we inevitably lose valuable dependencies by yours. That's why I've endlessly asked you 'do you have any reason you try those patches?' a ton of times. And you have never answered it.
[PATCH] usb: host: make ehci_fsl_overrides const and __initconst
Make this structure const as it is not modified. And replace __initdata
with __initconst to avoid section conflict error.
Signed-off-by: Bhumika Goyal
---
drivers/usb/host/ehci-fsl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 4a08b70..d025cc0 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -642,7 +642,7 @@ static int ehci_start_port_reset(struct usb_hcd *hcd,
unsigned port)
#define ehci_start_port_reset NULL
#endif /* CONFIG_USB_OTG */
-static struct ehci_driver_overrides ehci_fsl_overrides __initdata = {
+static const struct ehci_driver_overrides ehci_fsl_overrides __initconst = {
.extra_priv_size = sizeof(struct ehci_fsl),
.reset = ehci_fsl_setup,
};
--
1.9.1
Re: [PATCH v5 1/2] platform: Add driver for RAVE Supervisory Processor
On Mon 2017-08-28 09:23:10, Andrey Smirnov wrote: > On Thu, Aug 24, 2017 at 9:04 AM, Pavel Machek wrote: > > On Fri 2017-07-28 07:27:03, Andrey Smirnov wrote: > >> Add a driver for RAVE Supervisory Processor, an MCU implementing > >> varoius bits of housekeeping functionality (watchdoging, backlight > >> control, LED control, etc) on RAVE family of products by Zodiac > >> Inflight Innovations. > >> > >> This driver implementes core MFD/serdev device as well as > >> communication subroutines necessary for commanding the device. > > > > This introduces new /sysfs userland interfaces, right? That needs > > documenting, > > and some review. > > > > Correct and yes, good point. I was originally asked to implement all > of the exposed attributes via sysfs, but, after more discussion, I now > have green light to move a large chunk of those into debugfs which is > what I intend to do in v6, I'll also update it to document all of the > remaining sysfs entries. Ok, we still would like to have documentation. .. and debugfs is for debugging, not for production use. > > For example... bootreason is there on Nokia N900, too. We want to use same > > interface... > > > > I tried grepping Documentation/ABI and kernel tree in general for that > sysfs interface, but wasn't able to find it. If you don't mind, could > you point me to where it's implemented? I'm not sure if the implementation is in the mainline, but the bootloader provides this functionality. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH V1] regulator: pv88090: Exception handling for out of bounds
From: Eric Jeong
This is a patch for exception handlding that the index of array is
out of bounds. And the definitions have been updated to use
proper device name.
Signed-off-by: Eric Jeong
---
This patch applies against linux-next and next-20170829
drivers/regulator/pv88090-regulator.c | 11 ---
drivers/regulator/pv88090-regulator.h |8
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/pv88090-regulator.c
b/drivers/regulator/pv88090-regulator.c
index ab51e25..7a0c159 100644
--- a/drivers/regulator/pv88090-regulator.c
+++ b/drivers/regulator/pv88090-regulator.c
@@ -43,7 +43,7 @@ enum {
struct pv88090_regulator {
struct regulator_desc desc;
/* Current limiting */
- unsignedn_current_limits;
+ unsigned int n_current_limits;
const int *current_limits;
unsigned int limit_mask;
unsigned int conf;
@@ -398,9 +398,14 @@ static int pv88090_i2c_probe(struct i2c_client *i2c,
return ret;
range = (range >>
-(PV88080_BUCK_VRANGE_GAIN_SHIFT + i - 1)) &
- PV88080_BUCK_VRANGE_GAIN_MASK;
+(PV88090_BUCK_VRANGE_GAIN_SHIFT + i - 1)) &
+ PV88090_BUCK_VRANGE_GAIN_MASK;
index = ((range << 1) | conf2);
+ if (index > PV88090_ID_BUCK3) {
+ dev_err(chip->dev,
+ "Invalid index(%d)\n", index);
+ return -EINVAL;
+ }
pv88090_regulator_info[i].desc.min_uV
= pv88090_buck_vol[index].min_uV;
diff --git a/drivers/regulator/pv88090-regulator.h
b/drivers/regulator/pv88090-regulator.h
index d7aca8d..62d9029 100644
--- a/drivers/regulator/pv88090-regulator.h
+++ b/drivers/regulator/pv88090-regulator.h
@@ -89,10 +89,10 @@
#define PV88090_BUCK_VDAC_RANGE_2 0x01
/* PV88090_REG_BUCK_FOLD_RANGE (addr=0x61) */
-#define PV88080_BUCK_VRANGE_GAIN_SHIFT 3
-#define PV88080_BUCK_VRANGE_GAIN_MASK 0x01
+#define PV88090_BUCK_VRANGE_GAIN_SHIFT 3
+#define PV88090_BUCK_VRANGE_GAIN_MASK 0x01
-#define PV88080_BUCK_VRANGE_GAIN_1 0x00
-#define PV88080_BUCK_VRANGE_GAIN_2 0x01
+#define PV88090_BUCK_VRANGE_GAIN_1 0x00
+#define PV88090_BUCK_VRANGE_GAIN_2 0x01
#endif /* __PV88090_REGISTERS_H__ */
--
end-of-patch for PATCH V1
Re: [RFC PATCH] mm, oom_reaper: skip mm structs with mmu notifiers
On Wed 30-08-17 10:46:00, Michal Hocko wrote:
> From: Michal Hocko
>
> Andrea has noticed that the oom_reaper doesn't invalidate the range
> via mmu notifiers (mmu_notifier_invalidate_range_start,
> mmu_notifier_invalidate_range_end) and that can corrupt the memory
> of the kvm guest for example.
Forgot to mention that tlb_flush_mmu_tlbonly already invokes mmu
notifiers but that is not sufficient as per Andrea:
: mmu_notifier_invalidate_range cannot be used in replacement of
: mmu_notifier_invalidate_range_start/end. For KVM
: mmu_notifier_invalidate_range is a noop and rightfully so. A MMU
: notifier implementation has to implement either
: ->invalidate_range method or the invalidate_range_start/end
: methods, not both. And if you implement invalidate_range_start/end
: like KVM is forced to do, calling mmu_notifier_invalidate_range in
: common code is a noop for KVM.
:
: For those MMU notifiers that can get away only implementing
: ->invalidate_range, the ->invalidate_range is implicitly called by
: mmu_notifier_invalidate_range_end(). And only those secondary MMUs
: that share the same pagetable with the primary MMU (like AMD
: iommuv2) can get away only implementing ->invalidate_range.
> As the callback is allowed to sleep
> and the implementation is out of hand of the MM it is safer to simply
> bail out if there is an mmu notifier registered. In order to not
> fail too early make the mm_has_notifiers check under the oom_lock
> and have a little nap before failing to give the current oom victim some
> more time to exit.
>
> Fixes: aac453635549 ("mm, oom: introduce oom reaper")
> Noticed-by: Andrea Arcangeli
> Cc: stable
> Signed-off-by: Michal Hocko
> ---
>
> Hi,
> Andrea has pointed this out [1] while a different (but similar) bug has been
> discussed. This is an ugly hack to plug the potential memory corruption but
> we definitely want a better fix longterm.
> Does this sound like a viable option for now?
>
> [1] http://lkml.kernel.org/r/20170829140924.gb21...@redhat.com
>
> include/linux/mmu_notifier.h | 5 +
> mm/oom_kill.c| 15 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index c91b3bcd158f..947f21b451d2 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -420,6 +420,11 @@ extern void mmu_notifier_synchronize(void);
>
> #else /* CONFIG_MMU_NOTIFIER */
>
> +static inline int mm_has_notifiers(struct mm_struct *mm)
> +{
> + return 0;
> +}
> +
> static inline void mmu_notifier_release(struct mm_struct *mm)
> {
> }
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 99736e026712..45f1a0c3dd90 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include "internal.h"
> @@ -488,6 +489,20 @@ static bool __oom_reap_task_mm(struct task_struct *tsk,
> struct mm_struct *mm)
>*/
> mutex_lock(&oom_lock);
>
> + /*
> + * If the mm has notifiers then we would need to invalidate them around
> + * unmap_page_range and that is risky because notifiers can sleep and
> + * what they do is basically undeterministic. So let's have a short
> sleep
> + * to give the oom victim some more time.
> + * TODO: we really want to get rid of this ugly hack and make sure that
> + * notifiers cannot block for unbounded amount of time and add
> + * mmu_notifier_invalidate_range_{start,end} around unmap_page_range
> + */
> + if (mm_has_notifiers(mm)) {
> + schedule_timeout_idle(HZ);
> + goto unlock_oom;
> + }
> +
> if (!down_read_trylock(&mm->mmap_sem)) {
> ret = false;
> trace_skip_task_reaping(tsk->pid);
> --
> 2.13.2
>
--
Michal Hocko
SUSE Labs
Re: [PATCH] drm: vmwgfx: constify vmw_fence_ops
On 08/30/2017 10:30 AM, Daniel Vetter wrote:
On Wed, Aug 30, 2017 at 08:21:46AM +0200, Thomas Hellstrom wrote:
On 08/30/2017 07:47 AM, Arvind Yadav wrote:
vmw_fence_ops are not supposed to change at runtime. Functions
"dma_fence_init" working with const vmw_fence_ops provided
by . So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index b8bc5bc..abc5f03 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -225,7 +225,7 @@ static long vmw_fence_wait(struct dma_fence *f, bool intr,
signed long timeout)
return ret;
}
-static struct dma_fence_ops vmw_fence_ops = {
+static const struct dma_fence_ops vmw_fence_ops = {
.get_driver_name = vmw_fence_get_driver_name,
.get_timeline_name = vmw_fence_get_timeline_name,
.enable_signaling = vmw_fence_enable_signaling,
Reviewed-by: Thomas Hellstrom
Does this mean you'll merge it, or does this mean you'll expect someone
else to merge this?
I'm always confused when maintainers reply with an r-b/ack for a patch
only touching their driver, and no further information at all.
-Daniel
For patches only touching our driver, I'd say we're always responsible
for sorting out how it's going to be merged.
Since Sinclair is maintaining the vmwgfx trees I thought I'd give him a
chance to comment on how he wanted it merged.
/Thomas
[PATCH] [SCSI] esas2r: make default_sas_nvram const
Make this const as it is never modified.
Signed-off-by: Bhumika Goyal
---
drivers/scsi/esas2r/esas2r_flash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/esas2r/esas2r_flash.c
b/drivers/scsi/esas2r/esas2r_flash.c
index 7bd376d..f8414b5 100644
--- a/drivers/scsi/esas2r/esas2r_flash.c
+++ b/drivers/scsi/esas2r/esas2r_flash.c
@@ -54,7 +54,7 @@
#define ESAS2R_FS_DRVR_VER 2
-static struct esas2r_sas_nvram default_sas_nvram = {
+static const struct esas2r_sas_nvram default_sas_nvram = {
{ 'E', 'S', 'A', 'S' }, /* signature */
SASNVR_VERSION, /* version*/
0, /* checksum */
--
1.9.1
Re: [RESEND PATCH 2/3] regulator: Add support for stm32-vrefbuf
On 08/29/2017 08:57 PM, Mark Brown wrote:
> On Mon, Aug 28, 2017 at 02:58:52PM +0200, Fabrice Gasnier wrote:
>
>> +ret = clk_prepare_enable(priv->clk);
>> +if (ret) {
>> +dev_err(&pdev->dev, "clk prepare failed\n");
>
> If you're printing an error include the error code, it'll help users
> figure out what went wrong.
Hi Mark,
Thanks for reviewing,
I'll add it in v2.
>
>> +dev_info(&pdev->dev, "STM32 VREFBUF initialized\n");
>
> This is just noise, remove it.
I'll remove it in v2.
>
>> +static int __init stm32_vrefbuf_init(void)
>> +{
>> +return platform_driver_register(&stm32_vrefbuf_driver);
>> +}
>> +subsys_initcall(stm32_vrefbuf_init);
>
> Why is this at subsys_initcall()?
>
Several consumers depend on it when it's being used, among which: STM32
internal ADC and DAC, but also external components. Purpose is to ensure
it's ready before these drivers gets probed, instead of being deferred.
Is it ok to keep it ?
Please let me know,
Best Regards,
Fabrice
Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
On Wed, Aug 30, 2017 at 06:01:59PM +0900, Byungchul Park wrote: > My point is that we inevitably lose valuable dependencies by yours. That's > why I've endlessly asked you 'do you have any reason you try those patches?' > a ton of times. And you have never answered it. The only dependencies that are lost are those between the first work and the setup of the workqueue thread. And there obviously _should_ not be any dependencies between those. A work should not depend on the setup of the thread.
Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
On Wed, Aug 30, 2017 at 11:12:23AM +0200, Peter Zijlstra wrote: > On Wed, Aug 30, 2017 at 06:01:59PM +0900, Byungchul Park wrote: > > My point is that we inevitably lose valuable dependencies by yours. That's > > why I've endlessly asked you 'do you have any reason you try those patches?' > > a ton of times. And you have never answered it. > > The only dependencies that are lost are those between the first work and > the setup of the workqueue thread. > > And there obviously _should_ not be any dependencies between those. A > work should not depend on the setup of the thread. Furthermore, the save/restore can't preserve those dependencies. The moment a work exhausts xhlocks[] they are gone. So by assuming the first work _will_ exhaust the history there is effectively nothing lost.
Re: [PATCH v8 2/3] PCI: iproc: retry request when CRS returned from EP
On Wed, Aug 30, 2017 at 1:32 AM, Bjorn Helgaas wrote:
> On Tue, Aug 29, 2017 at 11:02:23AM +0530, Oza Oza wrote:
>> On Tue, Aug 29, 2017 at 3:17 AM, Bjorn Helgaas wrote:
>> > On Thu, Aug 24, 2017 at 10:34:25AM +0530, Oza Pawandeep wrote:
>> >> PCIe spec r3.1, sec 2.3.2
>> >> If CRS software visibility is not enabled, the RC must reissue the
>> >> config request as a new request.
>> >>
>> >> - If CRS software visibility is enabled,
>> >> - for a config read of Vendor ID, the RC must return 0x0001 data
>> >> - for all other config reads/writes, the RC must reissue the
>> >> request
>> >>
>> >> iproc PCIe Controller spec:
>> >> 4.7.3.3. Retry Status On Configuration Cycle
>> >> Endpoints are allowed to generate retry status on configuration
>> >> cycles. In this case, the RC needs to re-issue the request. The IP
>> >> does not handle this because the number of configuration cycles needed
>> >> will probably be less than the total number of non-posted operations
>> >> needed.
>> >>
>> >> When a retry status is received on the User RX interface for a
>> >> configuration request that was sent on the User TX interface,
>> >> it will be indicated with a completion with the CMPL_STATUS field set
>> >> to 2=CRS, and the user will have to find the address and data values
>> >> and send a new transaction on the User TX interface.
>> >> When the internal configuration space returns a retry status during a
>> >> configuration cycle (user_cscfg = 1) on the Command/Status interface,
>> >> the pcie_cscrs will assert with the pcie_csack signal to indicate the
>> >> CRS status.
>> >> When the CRS Software Visibility Enable register in the Root Control
>> >> register is enabled, the IP will return the data value to 0x0001 for
>> >> the Vendor ID value and 0x (all 1’s) for the rest of the data in
>> >> the request for reads of offset 0 that return with CRS status. This
>> >> is true for both the User RX Interface and for the Command/Status
>> >> interface. When CRS Software Visibility is enabled, the CMPL_STATUS
>> >> field of the completion on the User RX Interface will not be 2=CRS and
>> >> the pcie_cscrs signal will not assert on the Command/Status interface.
>> >>
>> >> Per PCIe r3.1, sec 2.3.2, config requests that receive completions
>> >> with Configuration Request Retry Status (CRS) should be reissued by
>> >> the hardware except reads of the Vendor ID when CRS Software
>> >> Visibility is enabled.
>> >>
>> >> This hardware never reissues configuration requests when it receives
>> >> CRS completions.
>> >> Note that, neither PCIe host bridge nor PCIe core re-issues the
>> >> request for any configuration offset.
>> >>
>> >> For config reads, this hardware returns CFG_RETRY_STATUS data when
>> >> it receives a CRS completion for a config read, regardless of the
>> >> address of the read or the CRS Software Visibility Enable bit.
>> >>
>> >> This patch implements iproc_pcie_config_read which gets called for
>> >> Stingray, if it receives a CRS completion, it retries reading it again.
>> >> In case of timeout, it returns 0x.
>> >> For other iproc based SOC, it falls back to PCI generic APIs.
>> >>
>> >> Signed-off-by: Oza Pawandeep
>> >>
>> >> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>> >> index 61d9be6..37f4adf 100644
>> >> --- a/drivers/pci/host/pcie-iproc.c
>> >> +++ b/drivers/pci/host/pcie-iproc.c
>> >> @@ -68,6 +68,9 @@
>> >> #define APB_ERR_EN_SHIFT 0
>> >> #define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
>> >>
>> >> +#define CFG_RETRY_STATUS 0x0001
>> >> +#define CFG_RETRY_STATUS_TIMEOUT_US 50 /* 500 milli-seconds. */
>> >> +
>> >> /* derive the enum index of the outbound/inbound mapping registers */
>> >> #define MAP_REG(base_reg, index) ((base_reg) + (index) * 2)
>> >>
>> >> @@ -473,6 +476,64 @@ static void __iomem
>> >> *iproc_pcie_map_ep_cfg_reg(struct iproc_pcie *pcie,
>> >> return (pcie->base + offset);
>> >> }
>> >>
>> >> +static unsigned int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
>> >> +{
>> >> + int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
>> >> + unsigned int data;
>> >> +
>> >> + /*
>> >> + * As per PCIe spec r3.1, sec 2.3.2, CRS Software
>> >> + * Visibility only affects config read of the Vendor ID.
>> >> + * For config write or any other config read the Root must
>> >> + * automatically re-issue configuration request again as a
>> >> + * new request.
>> >> + *
>> >> + * For config reads, this hardware returns CFG_RETRY_STATUS data
>> >> when
>> >> + * it receives a CRS completion for a config read, regardless of the
>> >> + * address of the read or the CRS Software Visibility Enable bit.
>> >> As a
>> >> + * partial workaround for this, we retry in software any read that
>> >> + * returns CFG_RETRY_STATUS.
>> >> + */
>> >> + data = readl(cfg_data_p);
>> >> + while (data == CFG_RETRY_STATUS && timeout--
Re: [PATCH v3 3/6] dt: booting-without-of: DT fix s/#interrupt-cell/#interrupt-cells/
Geert Uytterhoeven writes: > Signed-off-by: Geert Uytterhoeven > Acked-by: Rob Herring > --- Rob this has your ack, but I'd expect it to go via your tree? Or should I grab it? cheers > diff --git a/Documentation/devicetree/booting-without-of.txt > b/Documentation/devicetree/booting-without-of.txt > index 280d283304bb82d8..f35d3adacb987f7d 100644 > --- a/Documentation/devicetree/booting-without-of.txt > +++ b/Documentation/devicetree/booting-without-of.txt > @@ -1309,7 +1309,7 @@ number and level/sense information. All interrupt > children in an > OpenPIC interrupt domain use 2 cells per interrupt in their interrupts > property. > > -The PCI bus binding specifies a #interrupt-cell value of 1 to encode > +The PCI bus binding specifies a #interrupt-cells value of 1 to encode > which interrupt pin (INTA,INTB,INTC,INTD) is used. > > 2) interrupt-parent property > -- > 2.7.4
[RFC PATCH] arm64: move THREAD_* definitions to separated header
Hi Mark, all.
In patch 'dbc9344a68e506f19f8 ("arm64: clean up THREAD_* definitions")'
you move THREAD_* definitions from arch/arm64/include/asm/thread_info.h
to asm/memory.h. After that asm/thread_info.h starts to depend on
asm/memory.h.
When I try to apply ilp32 series on top of it [1], it causes circular
dependencies like this one:
In file included from ./arch/arm64/include/asm/memory.h:30:0,
from ./arch/arm64/include/asm/thread_info.h:30,
from ./include/linux/thread_bits.h:20,
from ./include/linux/thread_info.h:13,
from ./include/asm-generic/preempt.h:4,
from ./arch/arm64/include/generated/asm/preempt.h:1,
from ./include/linux/preempt.h:80,
from ./include/linux/rcupdate.h:40,
from ./include/linux/rculist.h:10,
from ./include/linux/pid.h:4,
from ./include/linux/sched.h:13,
from arch/arm64/kernel/asm-offsets.c:21:
./arch/arm64/include/asm/is_compat.h: In function ‘is_a32_compat_task’:
./arch/arm64/include/asm/is_compat.h:25:9: error: implicit declaration of
function ‘test_thread_flag’ [-Werror=implicit-function-declaration]
return test_thread_flag(TIF_32BIT);
^~~~
The problem is that asm/memory.h depends on asm/is_compat.h to define
TASK_SIZE, which in turn requires asm/thread_info.h.
The most obvious solution for it is to create is_compat.c file and make
is_*_compat() real functions. The other option is to move THREAD_*
definitions to separated macro. I would prefer 2nd one because of following
reasons:
- TASK_SIZE macro is used many times in kernel, including hot paths;
- asm/memory.h is included widely, as well as asm/thread_info.h, and it's
better not to make them depend one from another;
- THREAD_SIZE etc are not memory-related definitions.
In this patch THREAD_* definitions moved to separated asm/thread_size.h
header. It's enough to resolve dependency above.
If you find this approach useful, I can prepare other patch that moves
TASK_* definitions from asm/memory.h to new header to remove the dependency
from asm/is_compat.h.
Also, arch/arm64/kernel/entry.S and arch/arm64/kernel/hibernate-asm.S
#includes list is cleaned.
[1] https://github.com/norov/linux/tree/ilp32-next (still in progress)
CC: Will Deacon
CC: Laura Abbott
Cc: Ard Biesheuvel
Cc: Catalin Marinas
Cc: James Morse
Signed-off-by: Yury Norov
---
arch/arm64/include/asm/memory.h | 30 +---
arch/arm64/include/asm/thread_info.h | 2 +-
arch/arm64/include/asm/thread_size.h | 53
arch/arm64/kernel/entry.S| 2 +-
arch/arm64/kernel/hibernate-asm.S| 1 -
5 files changed, 56 insertions(+), 32 deletions(-)
create mode 100644 arch/arm64/include/asm/thread_size.h
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 0c3ee6afda5b..bc7ec1930659 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -21,6 +21,7 @@
#ifndef __ASM_MEMORY_H
#define __ASM_MEMORY_H
+#include
#include
#include
#include
@@ -105,35 +106,6 @@
#define KASAN_SHADOW_SIZE (0)
#endif
-#define MIN_THREAD_SHIFT 14
-
-/*
- * VMAP'd stacks are allocated at page granularity, so we must ensure that such
- * stacks are a multiple of page size.
- */
-#if defined(CONFIG_VMAP_STACK) && (MIN_THREAD_SHIFT < PAGE_SHIFT)
-#define THREAD_SHIFT PAGE_SHIFT
-#else
-#define THREAD_SHIFT MIN_THREAD_SHIFT
-#endif
-
-#if THREAD_SHIFT >= PAGE_SHIFT
-#define THREAD_SIZE_ORDER (THREAD_SHIFT - PAGE_SHIFT)
-#endif
-
-#define THREAD_SIZE(UL(1) << THREAD_SHIFT)
-
-/*
- * By aligning VMAP'd stacks to 2 * THREAD_SIZE, we can detect overflow by
- * checking sp & (1 << THREAD_SHIFT), which we can do cheaply in the entry
- * assembly.
- */
-#ifdef CONFIG_VMAP_STACK
-#define THREAD_ALIGN (2 * THREAD_SIZE)
-#else
-#define THREAD_ALIGN THREAD_SIZE
-#endif
-
#define IRQ_STACK_SIZE THREAD_SIZE
#define OVERFLOW_STACK_SIZESZ_4K
diff --git a/arch/arm64/include/asm/thread_info.h
b/arch/arm64/include/asm/thread_info.h
index 5d889c645321..6267ba7bd0e4 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -27,7 +27,7 @@
struct task_struct;
-#include
+#include
#include
#include
diff --git a/arch/arm64/include/asm/thread_size.h
b/arch/arm64/include/asm/thread_size.h
new file mode 100644
index ..dd0b8906f9de
--- /dev/null
+++ b/arch/arm64/include/asm/thread_size.h
@@ -0,0 +1,53 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warran
RE: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
> -Original Message- > From: Peter Zijlstra [mailto:pet...@infradead.org] > Sent: Wednesday, August 30, 2017 6:12 PM > To: Byungchul Park > Cc: mi...@kernel.org; t...@kernel.org; boqun.f...@gmail.com; > da...@fromorbit.com; johan...@sipsolutions.net; o...@redhat.com; linux- > ker...@vger.kernel.org; kernel-t...@lge.com > Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation > > On Wed, Aug 30, 2017 at 06:01:59PM +0900, Byungchul Park wrote: > > My point is that we inevitably lose valuable dependencies by yours. > That's > > why I've endlessly asked you 'do you have any reason you try those > patches?' > > a ton of times. And you have never answered it. > > The only dependencies that are lost are those between the first work and > the setup of the workqueue thread. > > And there obviously _should_ not be any dependencies between those. A 100% right. Since there obviously should not be any, it would be better to check them. So I've endlessly asked you 'do you have any reason removing the opportunity for that check?'. Overhead? Logical problem? Or want to believe workqueue setup code perfect forever? I mean, is it a problem if we check them? > work should not depend on the setup of the thread. 100% right.
[PATCH] net: bcm63xx_enet: make bcm_enetsw_ethtool_ops const
Make this const as it is never modified.
Signed-off-by: Bhumika Goyal
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 61a88b6..4f3845a 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -2674,7 +2674,7 @@ static int bcm_enetsw_set_ringparam(struct net_device
*dev,
return 0;
}
-static struct ethtool_ops bcm_enetsw_ethtool_ops = {
+static const struct ethtool_ops bcm_enetsw_ethtool_ops = {
.get_strings= bcm_enetsw_get_strings,
.get_sset_count = bcm_enetsw_get_sset_count,
.get_ethtool_stats = bcm_enetsw_get_ethtool_stats,
--
1.9.1
Linux 4.4.85
I'm announcing the release of the 4.4.85 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arc/include/asm/cache.h|2 arch/arc/mm/cache.c | 13 - drivers/acpi/apei/ghes.c|1 drivers/acpi/ioapic.c |6 ++ drivers/android/binder.c| 14 +++-- drivers/gpu/drm/drm_atomic.c|5 +- drivers/gpu/drm/drm_gem.c |6 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c |6 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 ++-- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |8 +-- drivers/gpu/drm/rcar-du/rcar_lvds_regs.h|2 drivers/i2c/busses/i2c-designware-platdrv.c | 14 + drivers/iio/common/hid-sensors/hid-sensor-trigger.c |8 +-- drivers/iio/imu/adis16480.c |2 drivers/input/mouse/elan_i2c_core.c |1 drivers/input/mouse/trackpoint.c|3 - drivers/input/mouse/trackpoint.h|3 - drivers/misc/mei/hw-me-regs.h |5 ++ drivers/misc/mei/pci-me.c |4 + drivers/ntb/ntb_transport.c |8 +-- drivers/staging/rtl8188eu/os_dep/usb_intf.c |1 fs/cifs/dir.c | 18 +-- fs/cifs/smb2pdu.c |4 - fs/nfsd/nfs4xdr.c |6 -- include/net/ip.h|4 - include/net/sch_generic.h |5 +- kernel/events/core.c| 39 +++- kernel/trace/trace_events_filter.c |4 + net/bluetooth/bnep/core.c | 11 ++-- net/bluetooth/cmtp/core.c | 17 --- net/bluetooth/hidp/core.c | 33 + net/dccp/proto.c| 19 +-- net/ipv4/fib_semantics.c| 12 ++--- net/ipv4/route.c|2 net/ipv4/tcp_input.c|3 - net/ipv6/ip6_fib.c | 26 ++ net/irda/af_irda.c |2 net/key/af_key.c| 48 ++-- net/sched/act_ipt.c |2 net/sched/sch_sfq.c |5 +- net/sctp/ipv6.c |2 net/tipc/netlink_compat.c |6 +- sound/core/control.c|2 sound/pci/hda/patch_conexant.c |1 sound/soc/generic/simple-card.c |2 sound/soc/sh/rcar/adg.c |2 sound/soc/sh/rcar/core.c| 21 +++- sound/soc/sh/rcar/src.c | 18 ++- sound/soc/sh/rcar/ssi.c |3 - 50 files changed, 275 insertions(+), 166 deletions(-) Aaro Koskinen (1): ASoC: simple-card: don't fail if sysclk setting is not supported Aaron Ma (1): Input: trackpoint - add new trackpoint firmware ID Alexander Potapenko (1): sctp: fully initialize the IPv6 address in sctp_v6_to_addr() Alexey Brodkin (1): ARCv2: PAE40: Explicitly set MSB counterpart of SLC region ops addresses Charles Milette (1): staging: rtl8188eu: add RNX-N150NUB support Chris Wilson (1): drm: Release driver tracking before making the object available again Chuck Lever (1): nfsd: Limit end of page list when decoding NFSv4 WRITE Colin Ian King (1): irda: do not leak initialized list.dev to userspace Dragos Bogdan (1): iio: imu: adis16480: Fix acceleration scale factor for adis16480 Eric Dumazet (6): af_key: do not use GFP_KERNEL in atomic contexts dccp: purge write queue in dccp_destroy_sock() dccp: defer ccid_hc_tx_delete() at dismantle time ipv4: fix NULL dereference in free_fib_info_rcu() ipv4: better IP_MAX_MTU enforcement tipc: fix use-after-free Geert Uytterhoeven (1): ASoC: rsnd: Add missing initialization of ADG req_rate Greg Kroah-Hartman (1): Linux 4.4.85 James Morse (1): ACPI / APEI: Add missing synchronize_rcu() on NOTIFY_SCI removal Jeffy Chen (3):
Re: Linux 3.18.68
diff --git a/Makefile b/Makefile
index 7d6526eed64a..0d7f1e91e910 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 18
-SUBLEVEL = 67
+SUBLEVEL = 68
EXTRAVERSION =
NAME = Diseased Newt
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index fc5f780bb61d..d5acb885b2e6 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1078,6 +1078,7 @@ static int ghes_remove(struct platform_device *ghes_dev)
if (list_empty(&ghes_sci))
unregister_acpi_hed_notifier(&ghes_notifier_sci);
mutex_unlock(&ghes_list_mutex);
+ synchronize_rcu();
break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index f6ca51259fa3..ace9278467b8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -711,13 +711,13 @@ drm_gem_object_release_handle(int id, void *ptr, void
*data)
struct drm_gem_object *obj = ptr;
struct drm_device *dev = obj->dev;
+ if (dev->driver->gem_close_object)
+ dev->driver->gem_close_object(obj, file_priv);
+
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_gem_remove_prime_handles(obj, file_priv);
drm_vma_node_revoke(&obj->vma_node, file_priv->filp);
- if (dev->driver->gem_close_object)
- dev->driver->gem_close_object(obj, file_priv);
-
drm_gem_object_handle_unreference_unlocked(obj);
return 0;
diff --git a/drivers/iio/imu/adis16480.c b/drivers/iio/imu/adis16480.c
index b94bfd3f595b..7a9c50842d8b 100644
--- a/drivers/iio/imu/adis16480.c
+++ b/drivers/iio/imu/adis16480.c
@@ -696,7 +696,7 @@ static const struct adis16480_chip_info
adis16480_chip_info[] = {
.gyro_max_val = IIO_RAD_TO_DEGREE(22500),
.gyro_max_scale = 450,
.accel_max_val = IIO_M_S_2_TO_G(12500),
- .accel_max_scale = 5,
+ .accel_max_scale = 10,
},
[ADIS16485] = {
.channels = adis16485_channels,
diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
index 30c8b6998808..bd5c176c7a2d 100644
--- a/drivers/input/mouse/trackpoint.c
+++ b/drivers/input/mouse/trackpoint.c
@@ -263,7 +263,8 @@ static int trackpoint_start_protocol(struct psmouse
*psmouse, unsigned char *fir
if (ps2_command(&psmouse->ps2dev, param, MAKE_PS2_CMD(0, 2,
TP_READ_ID)))
return -1;
- if (param[0] != TP_MAGIC_IDENT)
+ /* add new TP ID. */
+ if (!(param[0] & TP_MAGIC_IDENT))
return -1;
if (firmware_id)
diff --git a/drivers/input/mouse/trackpoint.h b/drivers/input/mouse/trackpoint.h
index ecd0547964a5..2d7be0435957 100644
--- a/drivers/input/mouse/trackpoint.h
+++ b/drivers/input/mouse/trackpoint.h
@@ -21,8 +21,9 @@
#define TP_COMMAND 0xE2/* Commands start with this */
#define TP_READ_ID 0xE1/* Sent for device identification */
-#define TP_MAGIC_IDENT 0x01/* Sent after a TP_READ_ID followed */
+#define TP_MAGIC_IDENT 0x03/* Sent after a TP_READ_ID followed */
/* by the firmware ID */
+ /* Firmware ID includes 0x1, 0x2, 0x3 */
/*
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index e33f0458fafc..e606a7a6c278 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -50,6 +50,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
{USB_DEVICE(0x2001, 0x3311)}, /* DLink GO-USB-N150 REV B1 */
{USB_DEVICE(0x2357, 0x010c)}, /* TP-Link TL-WN722N v2 */
{USB_DEVICE(0x0df6, 0x0076)}, /* Sitecom N150 v2 */
+ {USB_DEVICE(USB_VENDER_ID_REALTEK, 0xffef)}, /* Rosewill RNX-N150NUB */
{} /* Terminating entry */
};
diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index ed7b6f7d5abe..711d95c046f4 100644
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -183,15 +183,20 @@ cifs_bp_rename_retry:
}
/*
+ * Don't allow path components longer than the server max.
* Don't allow the separator character in a path component.
* The VFS will not allow "/", but "\" is allowed by posix.
*/
static int
-check_name(struct dentry *direntry)
+check_name(struct dentry *direntry, struct cifs_tcon *tcon)
{
struct cifs_sb_info *cifs_sb = CIFS_SB(direntry->d_sb);
int i;
+ if (unlikely(direntry->d_name.len >
+tcon->fsAttrInfo.MaxPathNameComponentLength))
+ return -ENAMETOOLONG;
+
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_POSIX_PATHS)) {
for (i = 0; i < direntry->d_name.len; i++) {
if (direntry->d_name.name[i] == '\\') {
@@ -489,10 +494,6 @@ cifs_atomic_open(struct inode *in
Linux 3.18.68
I'm announcing the release of the 3.18.68 kernel.
All users of the 3.18 kernel series must upgrade.
The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
Makefile|2 -
drivers/acpi/apei/ghes.c|1
drivers/gpu/drm/drm_gem.c |6 ++--
drivers/iio/imu/adis16480.c |2 -
drivers/input/mouse/trackpoint.c|3 +-
drivers/input/mouse/trackpoint.h|3 +-
drivers/staging/rtl8188eu/os_dep/usb_intf.c |1
fs/cifs/dir.c | 18
fs/cifs/smb2pdu.c |4 +-
fs/nfsd/nfs4xdr.c |6 +---
include/net/sch_generic.h |5 ++-
kernel/events/core.c| 39 +---
kernel/trace/trace_events_filter.c |4 ++
net/bluetooth/bnep/core.c | 11 +++
net/bluetooth/cmtp/core.c | 17 +++-
net/bluetooth/hidp/core.c | 33 +++
net/dccp/proto.c| 19 +
net/ipv4/tcp_input.c|3 --
net/irda/af_irda.c |2 -
net/sched/act_ipt.c |2 +
net/sctp/ipv6.c |2 +
sound/core/control.c|2 -
sound/pci/hda/patch_conexant.c |1
23 files changed, 112 insertions(+), 74 deletions(-)
Aaron Ma (1):
Input: trackpoint - add new trackpoint firmware ID
Alexander Potapenko (1):
sctp: fully initialize the IPv6 address in sctp_v6_to_addr()
Charles Milette (1):
staging: rtl8188eu: add RNX-N150NUB support
Chris Wilson (1):
drm: Release driver tracking before making the object available again
Chuck Lever (1):
nfsd: Limit end of page list when decoding NFSv4 WRITE
Colin Ian King (1):
irda: do not leak initialized list.dev to userspace
Dragos Bogdan (1):
iio: imu: adis16480: Fix acceleration scale factor for adis16480
Eric Dumazet (2):
dccp: purge write queue in dccp_destroy_sock()
dccp: defer ccid_hc_tx_delete() at dismantle time
Greg Kroah-Hartman (1):
Linux 3.18.68
James Morse (1):
ACPI / APEI: Add missing synchronize_rcu() on NOTIFY_SCI removal
Jeffy Chen (3):
Bluetooth: hidp: fix possible might sleep error in hidp_session_thread
Bluetooth: cmtp: fix possible might sleep error in cmtp_session
Bluetooth: bnep: fix possible might sleep error in bnep_session
Konstantin Khlebnikov (1):
net_sched: fix order of queue length updates in qdisc_replace()
Mark Rutland (1):
perf/core: Fix group {cpu,task} validation
Neal Cardwell (1):
tcp: when rearming RTO, if RTO time is in past then fire RTO ASAP
Ronnie Sahlberg (1):
cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup()
Sachin Prabhu (1):
cifs: Fix df output for users with quota limits
Steven Rostedt (VMware) (1):
tracing: Fix freeing of filter in create_filter() when set_str is false
Takashi Iwai (2):
ALSA: core: Fix unexpected error at replacing user TLV
ALSA: hda - Add stereo mic quirk for Lenovo G50-70 (17aa:3978)
Xin Long (1):
net: sched: fix NULL pointer dereference when action calls some targets
signature.asc
Description: PGP signature
Re: Linux 4.9.46
diff --git a/Makefile b/Makefile
index ccd6d91f616e..846ef1b57a02 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 45
+SUBLEVEL = 46
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h
index b3410ff6a62d..4fd6272e6c01 100644
--- a/arch/arc/include/asm/cache.h
+++ b/arch/arc/include/asm/cache.h
@@ -89,7 +89,9 @@ extern unsigned long perip_base, perip_end;
#define ARC_REG_SLC_FLUSH 0x904
#define ARC_REG_SLC_INVALIDATE 0x905
#define ARC_REG_SLC_RGN_START 0x914
+#define ARC_REG_SLC_RGN_START1 0x915
#define ARC_REG_SLC_RGN_END0x916
+#define ARC_REG_SLC_RGN_END1 0x917
/* Bit val in SLC_CONTROL */
#define SLC_CTRL_IM0x040
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 8147583c4434..bbdfeb31dee6 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -562,6 +562,7 @@ noinline void slc_op(phys_addr_t paddr, unsigned long sz,
const int op)
static DEFINE_SPINLOCK(lock);
unsigned long flags;
unsigned int ctrl;
+ phys_addr_t end;
spin_lock_irqsave(&lock, flags);
@@ -591,8 +592,16 @@ noinline void slc_op(phys_addr_t paddr, unsigned long sz,
const int op)
* END needs to be setup before START (latter triggers the operation)
* END can't be same as START, so add (l2_line_sz - 1) to sz
*/
- write_aux_reg(ARC_REG_SLC_RGN_END, (paddr + sz + l2_line_sz - 1));
- write_aux_reg(ARC_REG_SLC_RGN_START, paddr);
+ end = paddr + sz + l2_line_sz - 1;
+ if (is_pae40_enabled())
+ write_aux_reg(ARC_REG_SLC_RGN_END1, upper_32_bits(end));
+
+ write_aux_reg(ARC_REG_SLC_RGN_END, lower_32_bits(end));
+
+ if (is_pae40_enabled())
+ write_aux_reg(ARC_REG_SLC_RGN_START1, upper_32_bits(paddr));
+
+ write_aux_reg(ARC_REG_SLC_RGN_START, lower_32_bits(paddr));
while (read_aux_reg(ARC_REG_SLC_CTRL) & SLC_CTRL_BUSY);
diff --git a/arch/powerpc/include/asm/mmu_context.h
b/arch/powerpc/include/asm/mmu_context.h
index 0012f0353fd6..fe208b70b8b1 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -75,9 +75,27 @@ static inline void switch_mm_irqs_off(struct mm_struct *prev,
struct task_struct *tsk)
{
/* Mark this context has been used on the new CPU */
- if (!cpumask_test_cpu(smp_processor_id(), mm_cpumask(next)))
+ if (!cpumask_test_cpu(smp_processor_id(), mm_cpumask(next))) {
cpumask_set_cpu(smp_processor_id(), mm_cpumask(next));
+ /*
+* This full barrier orders the store to the cpumask above vs
+* a subsequent operation which allows this CPU to begin loading
+* translations for next.
+*
+* When using the radix MMU that operation is the load of the
+* MMU context id, which is then moved to SPRN_PID.
+*
+* For the hash MMU it is either the first load from slb_cache
+* in switch_slb(), and/or the store of paca->mm_ctx_id in
+* copy_mm_to_paca().
+*
+* On the read side the barrier is in pte_xchg(), which orders
+* the store to the PTE vs the load of mm_cpumask.
+*/
+ smp_mb();
+ }
+
/* 32-bit keeps track of the current PGDIR in the thread struct */
#ifdef CONFIG_PPC32
tsk->thread.pgdir = next->pgd;
diff --git a/arch/powerpc/include/asm/pgtable-be-types.h
b/arch/powerpc/include/asm/pgtable-be-types.h
index 49c0a5a80efa..68e087e807f8 100644
--- a/arch/powerpc/include/asm/pgtable-be-types.h
+++ b/arch/powerpc/include/asm/pgtable-be-types.h
@@ -87,6 +87,7 @@ static inline bool pte_xchg(pte_t *ptep, pte_t old, pte_t new)
unsigned long *p = (unsigned long *)ptep;
__be64 prev;
+ /* See comment in switch_mm_irqs_off() */
prev = (__force __be64)__cmpxchg_u64(p, (__force unsigned
long)pte_raw(old),
(__force unsigned
long)pte_raw(new));
diff --git a/arch/powerpc/include/asm/pgtable-types.h
b/arch/powerpc/include/asm/pgtable-types.h
index e7f4f3e0fcde..41e9d0a6cbeb 100644
--- a/arch/powerpc/include/asm/pgtable-types.h
+++ b/arch/powerpc/include/asm/pgtable-types.h
@@ -62,6 +62,7 @@ static inline bool pte_xchg(pte_t *ptep, pte_t old, pte_t new)
{
unsigned long *p = (unsigned long *)ptep;
+ /* See comment in switch_mm_irqs_off() */
return pte_val(old) == __cmpxchg_u64(p, pte_val(old), pte_val(new));
}
#endif
diff --git a/arch/s390/kvm/sthyi.c b/arch/s390/kvm/sthyi.c
index 05c98bb853cf..2f04ad1ea01c 100644
--- a/arch/s390/kvm/sthyi.c
+++ b/arch/s390/kvm/sthyi.c
@@ -394,7 +394,7 @@ static int sthyi(u64 vaddr)
"srl %[cc],28\n"
: [cc] "
Linux 4.9.46
I'm announcing the release of the 4.9.46 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arc/include/asm/cache.h|2 arch/arc/mm/cache.c | 13 + arch/powerpc/include/asm/mmu_context.h | 20 + arch/powerpc/include/asm/pgtable-be-types.h |1 arch/powerpc/include/asm/pgtable-types.h|1 arch/s390/kvm/sthyi.c |7 arch/sparc/kernel/pci_sun4v.c |2 arch/x86/events/intel/rapl.c| 58 ++--- arch/x86/include/asm/mmu_context.h |4 arch/x86/kvm/cpuid.c|2 drivers/acpi/apei/ghes.c|1 drivers/acpi/ec.c | 17 - drivers/acpi/internal.h |1 drivers/acpi/ioapic.c |6 drivers/acpi/scan.c |1 drivers/android/binder.c| 19 - drivers/gpu/drm/drm_atomic.c|5 drivers/gpu/drm/drm_gem.c |6 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |6 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 drivers/i2c/busses/i2c-designware-platdrv.c | 14 + drivers/iio/common/hid-sensors/hid-sensor-trigger.c |8 drivers/iio/imu/adis16480.c |2 drivers/input/mouse/alps.c | 41 +++ drivers/input/mouse/alps.h |8 drivers/input/mouse/elan_i2c_core.c |1 drivers/input/mouse/trackpoint.c|3 drivers/input/mouse/trackpoint.h|3 drivers/leds/trigger/ledtrig-heartbeat.c| 31 --- drivers/net/ethernet/mellanox/mlx4/main.c |4 drivers/net/ethernet/netronome/nfp/nfp_net_common.c |3 drivers/ntb/ntb_transport.c | 62 +- drivers/staging/rtl8188eu/os_dep/usb_intf.c |1 fs/cifs/dir.c | 18 + fs/cifs/smb2pdu.c |4 fs/nfsd/nfs4xdr.c |6 include/asm-generic/vmlinux.lds.h | 38 ++- include/linux/bpf_verifier.h|1 include/linux/cpuhotplug.h |1 include/linux/fs.h |4 include/linux/ptr_ring.h|9 include/linux/skb_array.h |3 include/net/ip.h|4 include/net/sch_generic.h |5 kernel/bpf/verifier.c | 206 +--- kernel/events/core.c| 39 +-- kernel/fork.c |1 kernel/time/timer.c | 50 +++- kernel/trace/bpf_trace.c| 34 ++- kernel/trace/ftrace.c |4 kernel/trace/trace.c|2 kernel/trace/trace_events_filter.c |4 kernel/trace/tracing_map.c | 11 - mm/madvise.c|2 mm/memblock.c |2 mm/shmem.c |4 net/bluetooth/bnep/core.c | 11 - net/bluetooth/cmtp/core.c | 17 - net/bluetooth/hidp/core.c | 33 ++- net/dccp/proto.c| 19 + net/ipv4/fib_semantics.c| 12 - net/ipv4/route.c|2 net/ipv4/tcp_input.c|3 net/ipv6/ip6_fib.c | 26 +- net/irda/af_irda.c |2 net/key/af_key.c| 48 ++-- net/netfilter/nf_nat_core.c | 17 - net/openvswitch/actions.c |1 net/openvswitch/datapath.c |7 net/openvswitch/datapath.h |2 net/sched/act_ipt.c |2 net/sched/sch_api.c |3 net/sched/sch_sfq.c |5
Re: Linux 4.4.85
diff --git a/Makefile b/Makefile
index 9d77ac063ec0..0f3d843f42a7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 84
+SUBLEVEL = 85
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h
index 210ef3e72332..0ddd7144c492 100644
--- a/arch/arc/include/asm/cache.h
+++ b/arch/arc/include/asm/cache.h
@@ -88,7 +88,9 @@ extern int ioc_exists;
#define ARC_REG_SLC_FLUSH 0x904
#define ARC_REG_SLC_INVALIDATE 0x905
#define ARC_REG_SLC_RGN_START 0x914
+#define ARC_REG_SLC_RGN_START1 0x915
#define ARC_REG_SLC_RGN_END0x916
+#define ARC_REG_SLC_RGN_END1 0x917
/* Bit val in SLC_CONTROL */
#define SLC_CTRL_IM0x040
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index d81b6d7e11e7..9a84cbdd44b0 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -543,6 +543,7 @@ noinline void slc_op(phys_addr_t paddr, unsigned long sz,
const int op)
static DEFINE_SPINLOCK(lock);
unsigned long flags;
unsigned int ctrl;
+ phys_addr_t end;
spin_lock_irqsave(&lock, flags);
@@ -572,8 +573,16 @@ noinline void slc_op(phys_addr_t paddr, unsigned long sz,
const int op)
* END needs to be setup before START (latter triggers the operation)
* END can't be same as START, so add (l2_line_sz - 1) to sz
*/
- write_aux_reg(ARC_REG_SLC_RGN_END, (paddr + sz + l2_line_sz - 1));
- write_aux_reg(ARC_REG_SLC_RGN_START, paddr);
+ end = paddr + sz + l2_line_sz - 1;
+ if (is_pae40_enabled())
+ write_aux_reg(ARC_REG_SLC_RGN_END1, upper_32_bits(end));
+
+ write_aux_reg(ARC_REG_SLC_RGN_END, lower_32_bits(end));
+
+ if (is_pae40_enabled())
+ write_aux_reg(ARC_REG_SLC_RGN_START1, upper_32_bits(paddr));
+
+ write_aux_reg(ARC_REG_SLC_RGN_START, lower_32_bits(paddr));
while (read_aux_reg(ARC_REG_SLC_CTRL) & SLC_CTRL_BUSY);
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index eac4f3b02df9..bb81cd05f0bc 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1067,6 +1067,7 @@ static int ghes_remove(struct platform_device *ghes_dev)
if (list_empty(&ghes_sci))
unregister_acpi_hed_notifier(&ghes_notifier_sci);
mutex_unlock(&ghes_list_mutex);
+ synchronize_rcu();
break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index ccdc8db16bb8..fa2cf2dc4e33 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -45,6 +45,12 @@ static acpi_status setup_res(struct acpi_resource *acpi_res,
void *data)
struct resource *res = data;
struct resource_win win;
+ /*
+* We might assign this to 'res' later, make sure all pointers are
+* cleared before the resource is added to the global list
+*/
+ memset(&win, 0, sizeof(win));
+
res->flags = 0;
if (acpi_dev_filter_resource_type(acpi_res, IORESOURCE_MEM) == 0)
return AE_OK;
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 47ddfefe2443..5531f020e561 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -1718,8 +1718,12 @@ static void binder_transaction(struct binder_proc *proc,
list_add_tail(&t->work.entry, target_list);
tcomplete->type = BINDER_WORK_TRANSACTION_COMPLETE;
list_add_tail(&tcomplete->entry, &thread->todo);
- if (target_wait)
- wake_up_interruptible(target_wait);
+ if (target_wait) {
+ if (reply || !(t->flags & TF_ONE_WAY))
+ wake_up_interruptible_sync(target_wait);
+ else
+ wake_up_interruptible(target_wait);
+ }
return;
err_get_unused_fd_failed:
@@ -2865,7 +2869,7 @@ static int binder_mmap(struct file *filp, struct
vm_area_struct *vma)
const char *failure_string;
struct binder_buffer *buffer;
- if (proc->tsk != current)
+ if (proc->tsk != current->group_leader)
return -EINVAL;
if ((vma->vm_end - vma->vm_start) > SZ_4M)
@@ -2966,8 +2970,8 @@ static int binder_open(struct inode *nodp, struct file
*filp)
proc = kzalloc(sizeof(*proc), GFP_KERNEL);
if (proc == NULL)
return -ENOMEM;
- get_task_struct(current);
- proc->tsk = current;
+ get_task_struct(current->group_leader);
+ proc->tsk = current->group_leader;
INIT_LIST_HEAD(&proc->todo);
init_waitqueue_head(&proc->wait);
proc->default_priority = task_nice(current);
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 6253775b8d9c..50d74e5ce41b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1247,6 +1247,9 @@ int drm_atomic_
Linux 4.12.10
I'm announcing the release of the 4.12.10 kernel. All users of the 4.12 kernel series must upgrade. The updated 4.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.12.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arc/include/asm/cache.h|2 arch/arc/include/asm/mmu.h |2 arch/arc/mm/cache.c | 50 - arch/arc/mm/tlb.c | 12 + arch/arm64/kernel/fpsimd.c |2 arch/powerpc/include/asm/mmu_context.h | 20 +- arch/powerpc/include/asm/pgtable-be-types.h |1 arch/powerpc/include/asm/pgtable-types.h|1 arch/s390/kvm/sthyi.c |7 arch/sparc/kernel/pci_sun4v.c |2 arch/x86/include/asm/fpu/internal.h |6 arch/x86/include/asm/kvm_host.h |1 arch/x86/include/asm/mmu_context.h |4 arch/x86/kvm/cpuid.c|2 arch/x86/kvm/kvm_cache_regs.h |5 arch/x86/kvm/mmu.h |2 arch/x86/kvm/svm.c |7 arch/x86/kvm/vmx.c | 25 -- arch/x86/kvm/x86.c | 17 + drivers/acpi/acpi_apd.c |4 drivers/acpi/ec.c | 17 - drivers/acpi/internal.h |1 drivers/acpi/property.c |2 drivers/acpi/scan.c |1 drivers/android/binder.c| 19 - drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c |2 drivers/gpu/drm/drm_atomic.c| 11 - drivers/gpu/drm/drm_gem.c |6 drivers/gpu/drm/drm_plane.c |1 drivers/gpu/drm/i915/gvt/cmd_parser.c |2 drivers/gpu/drm/i915/intel_bios.c | 15 - drivers/gpu/drm/sun4i/sun4i_drv.c |8 drivers/i2c/busses/i2c-designware-platdrv.c | 14 + drivers/iio/common/hid-sensors/hid-sensor-trigger.c |8 drivers/iio/imu/adis16480.c |2 drivers/iio/magnetometer/st_magn_core.c |4 drivers/infiniband/core/uverbs_cmd.c|2 drivers/input/mouse/alps.c | 41 +++- drivers/input/mouse/alps.h |8 drivers/input/mouse/elan_i2c_core.c |1 drivers/input/mouse/trackpoint.c|3 drivers/input/mouse/trackpoint.h|3 drivers/iommu/amd_iommu_types.h |4 drivers/iommu/intel-iommu.c |4 drivers/iommu/iommu-sysfs.c | 32 ++- drivers/net/bonding/bond_main.c | 13 - drivers/net/ethernet/mellanox/mlx4/main.c |4 drivers/net/ethernet/netronome/nfp/nfp_net_common.c |3 drivers/net/tun.c |3 drivers/ntb/ntb_transport.c |4 drivers/staging/rtl8188eu/os_dep/usb_intf.c |1 drivers/virtio/virtio_pci_common.c | 10 - fs/cifs/dir.c | 18 + fs/cifs/smb2pdu.c |4 fs/dax.c| 10 + fs/nfsd/nfs4xdr.c |6 include/asm-generic/vmlinux.lds.h | 38 ++- include/linux/bpf_verifier.h|1 include/linux/fs.h |4 include/linux/iommu.h | 12 + include/linux/ptr_ring.h|9 include/linux/skb_array.h |3 include/net/bonding.h |5 include/net/ip.h|4 include/net/sch_generic.h |5 kernel/bpf/verifier.c | 191 +--- kernel/events/core.c| 39 +--- kernel/fork.c |1 kernel/time/timer.c | 50 - kernel/trace/bpf_trace.c| 34 +++ kernel/trace/ftrace.c |4 kernel/trace/ring_buffer.c | 14 - kernel/trace/ring_buffer_benchmark.c|2 k
[PATCH v4] mfd: tps65217: Introduce dependency on CONFIG_OF
Currently the driver boots only via device tree hence add a
dependency on CONFIG_OF. This leaves with a bunch of unused code
so clean that up. This patch also makes use of probe_new function
in place of the probe function so as to avoid passing i2c_device_id.
Signed-off-by: Keerthy
Reviewed-by: Javier Martinez Canillas
---
Changes in v4:
* Added Javier's Reviewed-by.
* Added back I2C Device ID struct as it is needed for module autoprobe.
Changes in v3:
* Added more details to commit log.
* No changes in code. Rebased to latest next branch.
Changes in v2:
* Cleaned up chip_id and data attached to the match.
* Cleaned up i2c_dev_id
* dropped the rest of the patches in series for now
Boot tested and checked for regulator registrations on am335x-boneblack
both as part of zImage and as module autoprobed.
drivers/mfd/Kconfig| 2 +-
drivers/mfd/tps65217.c | 28 +---
drivers/regulator/tps65217-regulator.c | 5 -
drivers/video/backlight/tps65217_bl.c | 14 +++---
include/linux/mfd/tps65217.h | 6 --
5 files changed, 9 insertions(+), 46 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c601ee1..1d5be80 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1338,7 +1338,7 @@ config MFD_TPS65090
config MFD_TPS65217
tristate "TI TPS65217 Power Management / White LED chips"
- depends on I2C
+ depends on I2C && OF
select MFD_CORE
select REGMAP_I2C
select IRQ_DOMAIN
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index f769c7d..7566ce4 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -311,37 +311,20 @@ static bool tps65217_volatile_reg(struct device *dev,
unsigned int reg)
};
static const struct of_device_id tps65217_of_match[] = {
- { .compatible = "ti,tps65217", .data = (void *)TPS65217 },
+ { .compatible = "ti,tps65217"},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, tps65217_of_match);
-static int tps65217_probe(struct i2c_client *client,
- const struct i2c_device_id *ids)
+static int tps65217_probe(struct i2c_client *client)
{
struct tps65217 *tps;
unsigned int version;
- unsigned long chip_id = ids->driver_data;
- const struct of_device_id *match;
bool status_off = false;
int ret;
- if (client->dev.of_node) {
- match = of_match_device(tps65217_of_match, &client->dev);
- if (!match) {
- dev_err(&client->dev,
- "Failed to find matching dt id\n");
- return -EINVAL;
- }
- chip_id = (unsigned long)match->data;
- status_off = of_property_read_bool(client->dev.of_node,
- "ti,pmic-shutdown-controller");
- }
-
- if (!chip_id) {
- dev_err(&client->dev, "id is null.\n");
- return -ENODEV;
- }
+ status_off = of_property_read_bool(client->dev.of_node,
+ "ti,pmic-shutdown-controller");
tps = devm_kzalloc(&client->dev, sizeof(*tps), GFP_KERNEL);
if (!tps)
@@ -349,7 +332,6 @@ static int tps65217_probe(struct i2c_client *client,
i2c_set_clientdata(client, tps);
tps->dev = &client->dev;
- tps->id = chip_id;
tps->regmap = devm_regmap_init_i2c(client, &tps65217_regmap_config);
if (IS_ERR(tps->regmap)) {
@@ -430,7 +412,7 @@ static int tps65217_remove(struct i2c_client *client)
.of_match_table = tps65217_of_match,
},
.id_table = tps65217_id_table,
- .probe = tps65217_probe,
+ .probe_new = tps65217_probe,
.remove = tps65217_remove,
};
diff --git a/drivers/regulator/tps65217-regulator.c
b/drivers/regulator/tps65217-regulator.c
index 5324dc9..7b12e88 100644
--- a/drivers/regulator/tps65217-regulator.c
+++ b/drivers/regulator/tps65217-regulator.c
@@ -228,11 +228,6 @@ static int tps65217_regulator_probe(struct platform_device
*pdev)
int i, ret;
unsigned int val;
- if (tps65217_chip_id(tps) != TPS65217) {
- dev_err(&pdev->dev, "Invalid tps chip version\n");
- return -ENODEV;
- }
-
/* Allocate memory for strobes */
tps->strobes = devm_kzalloc(&pdev->dev, sizeof(u8) *
TPS65217_NUM_REGULATOR, GFP_KERNEL);
diff --git a/drivers/video/backlight/tps65217_bl.c
b/drivers/video/backlight/tps65217_bl.c
index fd524ad..5ce8791 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -275,17 +275,9 @@ static int tps65217_bl_probe(struct platform_device *pdev)
struct tps65217_bl_pdata *pdata;
struct backlight_properties bl_props;
- if (tps
Re: [PATCH v3 3/6] android: binder: Move buffer out of area shared with user space
On Tue, Aug 29, 2017 at 05:46:59PM -0700, Sherry Yang wrote: > Binder driver allocates buffer meta data in a region that is mapped > in user space. These meta data contain pointers in the kernel. > > This patch allocates buffer meta data on the kernel heap that is > not mapped in user space, and uses a pointer to refer to the data mapped. > > Also move alloc->buffers initialization from mmap to init since it's > now used even when mmap failed or was not called. > > Signed-off-by: Sherry Yang > --- The difference between v2 and v3 is that we've shifted some initialization around to fix the crashing bug that kbuild found. You should not that difference here under the --- cut off. > drivers/android/binder_alloc.c | 146 > +++- > drivers/android/binder_alloc.h | 2 +- > drivers/android/binder_alloc_selftest.c | 11 ++- > 3 files changed, 91 insertions(+), 68 deletions(-) But really we still need to have some answers or discussion about the questions that Greg and I raised. Greg asked if the other Android devs had Acked this. Please ping Arve to Ack this. I was curious about the security impact or why we were writing this patch 3/6. It seems we are fixing an information disclosure bug. Or is it something worse than that? Or have I misunderstood entirely. We probably original put the buffers in userspace for accounting reasons so we could kill programs that used too much RAM. This patch doesn't create a problem with that hopefully? We're just moving the metadata to kernel space? regards, dan carpenter
Re: [PATCH resend v2] power: supply: bq27xxx: enable writing capacity values for bq27421
Hi Liam and Sebastian,
> Am 29.08.2017 um 22:20 schrieb Liam Breck :
>
> Hi Nikolaus, thanks for the patch...
>
> On Tue, Aug 29, 2017 at 1:10 PM, H. Nikolaus Schaller
> wrote:
>> Tested on Pyra prototype with bq27421.
>>
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/power/supply/bq27xxx_battery.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/power/supply/bq27xxx_battery.c
>> b/drivers/power/supply/bq27xxx_battery.c
>> index b6c3120ca5ad..e3c878ef7c7e 100644
>> --- a/drivers/power/supply/bq27xxx_battery.c
>> +++ b/drivers/power/supply/bq27xxx_battery.c
>> @@ -688,7 +688,7 @@ static struct bq27xxx_dm_reg bq27545_dm_regs[] = {
>> #define bq27545_dm_regs 0
>> #endif
>>
>> -#if 0 /* not yet tested */
>> +#if 1 /* tested on Pyra */
>> static struct bq27xxx_dm_reg bq27421_dm_regs[] = {
>
> I think we can drop the #if and #else...#endif so it's just the
> dm_regs table, as with bq27425.
I have fixed that and did take the chance to update my OpenPandora
kernel so that I also could test and make the bq27500 working.
The biggest hurdle was to find out that I have to change the
compatible string to "ti,bq27500-1" to get non-NULL dm_regs...
[ 12.765930] bq27xxx_battery_i2c_probe name=bq27500-1-0
[ 12.771392] bq27xxx_battery_i2c_probe call setup
[ 12.874816] bq27xxx_battery_setup
[ 12.904266] bq27xxx_battery_setup: dm_regs=bf0520e0
[ 12.933380] (NULL device *): hwmon: 'bq27500-1-0' is not a valid name
attribute, please fix
[ 13.234893] bq27xxx_battery_settings
[ 13.238891] bq27xxx-battery 2-0055: invalid
battery:energy-full-design-microwatt-hours 1480
[ 13.312469] bq27xxx_battery_set_config
[ 13.407745] bq27xxx_battery_unseal
[ 13.455993] bq27xxx_battery_update_dm_block
[ 13.460418] bq27xxx-battery 2-0055: update terminate-voltage to 3200
[ 13.694885] bq27xxx_battery_seal
Does this look ok for
bat: battery {
compatible = "simple-battery", "openpandora-battery";
voltage-min-design-microvolt = <320>;
energy-full-design-microwatt-hours = <1480>;
charge-full-design-microamp-hours = <400>;
};
?
I will send a patch for enabling both fuel gauges and the
omap3-pandora-common.dtsi asap.
BR and thanks,
Nikolaus
Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure
On 30/08/2017 07:58, Peter Zijlstra wrote:
> On Wed, Aug 30, 2017 at 10:33:50AM +0530, Anshuman Khandual wrote:
>> diff --git a/mm/filemap.c b/mm/filemap.c
>> index a497024..08f3042 100644
>> --- a/mm/filemap.c
>> +++ b/mm/filemap.c
>> @@ -1181,6 +1181,18 @@ int __lock_page_killable(struct page *__page)
>> int __lock_page_or_retry(struct page *page, struct mm_struct *mm,
>> unsigned int flags)
>> {
>> + if (flags & FAULT_FLAG_SPECULATIVE) {
>> + if (flags & FAULT_FLAG_KILLABLE) {
>> + int ret;
>> +
>> + ret = __lock_page_killable(page);
>> + if (ret)
>> + return 0;
>> + } else
>> + __lock_page(page);
>> + return 1;
>> + }
>> +
>> if (flags & FAULT_FLAG_ALLOW_RETRY) {
>> /*
>> * CAUTION! In this case, mmap_sem is not released
>
> Yeah, that looks right.
Hum, I'm wondering if FAULT_FLAG_RETRY_NOWAIT should be forced in the
speculative path in that case to match the semantics of
__lock_page_or_retry().
>
>> @@ -4012,17 +4010,7 @@ int handle_speculative_fault(struct mm_struct *mm,
>> unsigned long address,
>> goto unlock;
>> }
>>
>> + if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) {
>> trace_spf_vma_notsup(_RET_IP_, vma, address);
>> goto unlock;
>> }
>
> As riel pointed out on IRC slightly later, private file maps also need
> ->anon_vma and those actually have ->vm_ops IIRC so the condition needs
> to be slightly more complicated.
Yes I read again the code and lead to the same conclusion.
Re: (Kernel Bug report) Make kaby lake cpu crash Ethernet
Chiwu Yung wrote: > Hello Sir, i am using cpu i7 7700k kaby lake, i have no overclock the > CPU but i think i7 7700k come across with Ethernet crash issue. Don't > know why it will keeping crash. > I tested the kernel since 4.8 - 4.12 almost 2-3months and i can see > that the issue is still exist. > Kernel error then the Ethernet is stop responded after that machine > crash, i need to force reboot the computer. > PS: there are no cpu overclock , latest Bios ver. Centos7 with 4.12.8 kernel > Thank you for your help! > > Error Log > > enp:s 6: Reset adapter unexpectedly[47438.8192131 e1808e 8000:88:11.6 > enp8s31f6: Reset adapter unexpectedly > [112822.759818] el008e 8800:88:1f.6 enp0s3116: Reset adapter > unexpectedly 1112838.119047] el888e 8808:80:1f.6 enp8s31f6: Reset > adapter unexpectedly > [112852-967086] e1800e 8000:00:11.6 enp8s31f6: Reset adapter > unexpectedly 1128194.823488] e1000e 0008:80:1f.6 enp8s31f6: Reset > adapter unexpectedly > [128213.991461] e1808e :00:11.6 enp8s31f6: Reset adapter unexpectedly > [128228.839481] 0.800e :08:1f.6 enp8s31f6: Reset adapter unexpectedly > [128283.111491] el880e 0808:08:11.6 enp0s31f6: Reset adapter unexpectedly > [123287.815631] e1800e :08:11.6 enp8s31f6: Reset adapter > unexpectedly 1124878.8237221 el888e 0088:00:1f.6 enp0s3116: Reset > adapter unexpectedly Check memory. Note driver name stranformation in logs: 'el008e 8800:88:1f.6 enp0s3116' vs 'el888e 8808:80:1f.6 enp8s31f6' 'e1800e 8000:00:11.6 enp8s31f6' vs 'e1000e 0008:80:1f.6 enp8s31f6' 'e1808e :00:11.6 enp8s31f6' vs '0.800e :08:1f.6 enp8s31f6' 'el880e 0808:08:11.6 enp0s31f6' vs 'e1800e :08:11.6 enp8s31f6'
