[PATCH bpf-next v2] bpf: support raw tracepoints in modules
Distributions build drivers as modules, including network and filesystem
drivers which export numerous tracepoints. This enables
bpf(BPF_RAW_TRACEPOINT_OPEN) to attach to those tracepoints.
Signed-off-by: Matt Mullins
---
v1->v2:
* avoid taking the mutex in bpf_event_notify when op is neither COMING nor
GOING.
* check that kzalloc actually succeeded
I didn't try to check list_empty before taking the mutex since I want to avoid
races between bpf_event_notify and bpf_get_raw_tracepoint. Additionally,
list_for_each_entry_safe is not strictly necessary upon MODULE_STATE_GOING, but
Alexei suggested I use it to protect against fragility if the subsequent break;
eventually disappears.
include/linux/module.h | 4 ++
include/linux/trace_events.h | 8 ++-
kernel/bpf/syscall.c | 11 ++--
kernel/module.c | 5 ++
kernel/trace/bpf_trace.c | 99 +++-
5 files changed, 120 insertions(+), 7 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index fce6b4335e36..5f147dd5e709 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -432,6 +432,10 @@ struct module {
unsigned int num_tracepoints;
tracepoint_ptr_t *tracepoints_ptrs;
#endif
+#ifdef CONFIG_BPF_EVENTS
+ unsigned int num_bpf_raw_events;
+ struct bpf_raw_event_map *bpf_raw_events;
+#endif
#ifdef HAVE_JUMP_LABEL
struct jump_entry *jump_entries;
unsigned int num_jump_entries;
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 4130a5497d40..8a62731673f7 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -471,7 +471,8 @@ void perf_event_detach_bpf_prog(struct perf_event *event);
int perf_event_query_prog_array(struct perf_event *event, void __user *info);
int bpf_probe_register(struct bpf_raw_event_map *btp, struct bpf_prog *prog);
int bpf_probe_unregister(struct bpf_raw_event_map *btp, struct bpf_prog *prog);
-struct bpf_raw_event_map *bpf_find_raw_tracepoint(const char *name);
+struct bpf_raw_event_map *bpf_get_raw_tracepoint(const char *name);
+void bpf_put_raw_tracepoint(struct bpf_raw_event_map *btp);
int bpf_get_perf_event_info(const struct perf_event *event, u32 *prog_id,
u32 *fd_type, const char **buf,
u64 *probe_offset, u64 *probe_addr);
@@ -502,10 +503,13 @@ static inline int bpf_probe_unregister(struct
bpf_raw_event_map *btp, struct bpf
{
return -EOPNOTSUPP;
}
-static inline struct bpf_raw_event_map *bpf_find_raw_tracepoint(const char
*name)
+static inline struct bpf_raw_event_map *bpf_get_raw_tracepoint(const char
*name)
{
return NULL;
}
+static inline void bpf_put_raw_tracepoint(struct bpf_raw_event_map *btp)
+{
+}
static inline int bpf_get_perf_event_info(const struct perf_event *event,
u32 *prog_id, u32 *fd_type,
const char **buf, u64 *probe_offset,
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 70fb11106fc2..754370e3155e 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -1609,6 +1609,7 @@ static int bpf_raw_tracepoint_release(struct inode
*inode, struct file *filp)
bpf_probe_unregister(raw_tp->btp, raw_tp->prog);
bpf_prog_put(raw_tp->prog);
}
+ bpf_put_raw_tracepoint(raw_tp->btp);
kfree(raw_tp);
return 0;
}
@@ -1634,13 +1635,15 @@ static int bpf_raw_tracepoint_open(const union bpf_attr
*attr)
return -EFAULT;
tp_name[sizeof(tp_name) - 1] = 0;
- btp = bpf_find_raw_tracepoint(tp_name);
+ btp = bpf_get_raw_tracepoint(tp_name);
if (!btp)
return -ENOENT;
raw_tp = kzalloc(sizeof(*raw_tp), GFP_USER);
- if (!raw_tp)
- return -ENOMEM;
+ if (!raw_tp) {
+ err = -ENOMEM;
+ goto out_put_btp;
+ }
raw_tp->btp = btp;
prog = bpf_prog_get_type(attr->raw_tracepoint.prog_fd,
@@ -1668,6 +1671,8 @@ static int bpf_raw_tracepoint_open(const union bpf_attr
*attr)
bpf_prog_put(prog);
out_free_tp:
kfree(raw_tp);
+out_put_btp:
+ bpf_put_raw_tracepoint(btp);
return err;
}
diff --git a/kernel/module.c b/kernel/module.c
index 49a405891587..06ec68f08387 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3093,6 +3093,11 @@ static int find_module_sections(struct module *mod,
struct load_info *info)
sizeof(*mod->tracepoints_ptrs),
>num_tracepoints);
#endif
+#ifdef CONFIG_BPF_EVENTS
+ mod->bpf_raw_events = section_objs(info, "__bpf_raw_tp_map",
+ sizeof(*mod->bpf_raw_events),
+ >num_bpf_raw_events);
+#endif
#ifdef HAVE_JUMP_LABEL
mod->jump_entries
Re: [PATCH] serial: 8250: Fix clearing FIFOs in RS485 mode again
Hi Marek / Greg / all,
On Mon, Sep 03, 2018 at 12:44:52AM +, Marek Vasut wrote:
> The 8250 FIFOs indeed need to be cleared after stopping transmission in
> RS485 mode without SER_RS485_RX_DURING_TX flag set. But there are two
> problems with the approach taken by the previous patch from Fixes tag.
>
> First, serial8250_clear_fifos() should clear fifos, but what it really
> does is it enables the FIFOs unconditionally if present, clears them
> and then sets the FCR register to zero, which effectively disables the
> FIFOs. In case the FIFO is disabled, enabling it and clearing it makes
> no sense and in fact can trigger misbehavior of the 8250 core. Moreover,
> the FCR register may contain other FIFO configuration bits which may not
> be writable unconditionally and writing them incorrectly can trigger
> misbehavior of the 8250 core too. (ie. AM335x UART swallows the first
> byte and retransmits the last byte twice because of this FCR write).
>
> Second, serial8250_clear_and_reinit_fifos() completely reloads the FCR,
> but what really has to happen at the end of the RS485 transmission is
> clearing of the FIFOs and nothing else.
>
> This patch repairs serial8250_clear_fifos() so that it really only
> clears the FIFOs by operating on FCR[2:1] bits and leaves all the
> other bits alone. It also undoes serial8250_clear_and_reinit_fifos()
> from __do_stop_tx_rs485() as serial8250_clear_fifos() is sufficient.
>
> Signed-off-by: Marek Vasut
> Fixes: 2bed8a8e7072 ("Clearing FIFOs in RS485 emulation mode causes
> subsequent transmits to break")
> Cc: Daniel Jedrychowski
> Cc: Greg Kroah-Hartman
> ---
> NOTE: I am not entirely certain this won't break some other hardware,
> esp. since there might be dependencies on the weird previous
> behavior of the serial8250_clear_fifos() somewhere.
This patch has broken the UART on my Ingenic JZ4780 based MIPS Creator
Ci20 board. After this patch the system seems to detect garbage input
that is recognized as SysRq triggers which spam the console & eventually
reset the system.
One thing of note is that both serial8250_do_startup() &
serial8250_do_shutdown() contain comments that explicitly state their
expectation that the FIFOs will be disabled by serial8250_clear_fifos(),
which is no longer true after this patch.
I found that restoring the old behaviour for serial8250_do_startup() is
enough to make my system work again, but this is obviously a hack:
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index f776b3eafb96..8def02933d19 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2210,7 +2210,11 @@ int serial8250_do_startup(struct uart_port *port)
* Clear the FIFO buffers and disable them.
* (they will be reenabled in set_termios())
*/
- serial8250_clear_fifos(up);
+ if (up->capabilities & UART_CAP_FIFO) {
+ serial_port_out(port, UART_FCR, UART_FCR_ENABLE_FIFO);
+ serial8250_clear_fifos(up);
+ serial_port_out(port, UART_FCR, 0);
+ }
/*
* Clear the interrupt registers.
Any ideas? Given the mismatch between this patch & comments that clearly
expect the old behaviour I think the __do_stop_tx_rs485() case probably
needs something different to other callers.
Thanks,
Paul
Re: [alsa-devel] [PATCH 0/2] Graph fixes for using multiple endpoints per port
* Kuninori Morimoto [181213 00:24]: > (snip) > > foo = < 0>; > > bar = < 1>; > > Ahh, it looks nice idea ! > but hmm..., it seems dtc doesn't allow us to use #address-cells = <2> > for "remote-endpoint". OK. Yeah let's scrap that then, it does not suit for endpoints it seems. Thanks for checking. > According to OF graph maintainer, he said that > counting port / endpoint are not guaranteed, > and we need to use "reg". > (It is the reason of b6f3fc005a2c8b425d7a0973b43bef05890bf479) > > If you could double checked, and we could agreed > that "reg" is the solution for us. > I will post patches. OK yes your "reg" proposal works for me. Regards, Tony
Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"
In case this was buried in previous messages, the commit I'd like to get backported to 4.14 is dbdda842fe96f: printk: Add console owner and waiter logic to load balance console writes. But another followup patch that fixes a bug in that patch is also required. That is c14376de3a1b: printk: Wake klogd when passing console_lock owner. On Wed, Dec 12, 2018 at 1:56 PM Daniel Wang wrote: > > Thank you! > > On Wed, Dec 12, 2018 at 1:52 PM Sasha Levin wrote: > > > > On Wed, Dec 12, 2018 at 01:49:25PM -0800, Daniel Wang wrote: > > >Thanks for the clarification. So I guess I don't need to start another > > >thread for it? What are the next steps? > > > > Nothing here, I'll queue it once Sergey or Petr clarify if they wanted > > additional information in the -stable commit message. > > > > -- > > Thanks, > > Sasha > > > > > -- > Best, > Daniel -- Best, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints
Hi Peter, On Mon, Dec 10, 2018 at 11:18:18AM +0100, Peter Zijlstra wrote: > On Sat, Dec 08, 2018 at 12:38:05PM -0500, Steven Rostedt wrote: > > On Sat, 8 Dec 2018 11:44:23 +0100, Peter Zijlstra wrote: > > > > > Why do we care about lost events? Because strace records *all* events, > > > > as that's what it does and that's what it always has done. It would be > > > > a break in functionality (a regression) if it were to start losing > > > > events. I use strace to see everything that an application is doing. > > > > > > So make a new tool; break the expectation of all events. See if there's > > > anybody that really cares. > > > > Basically you are saying, break strace and see if anyone notices? > > Nah, give it a new name. Clearly mark this is a new tool. > > > > > When we discussed this at plumbers, Oracle people came to me and said > > > > how awesome it would be to run strace against their database accesses. > > > > The problem today is that strace causes such a large overhead that it > > > > isn't feasible to trace any high speed applications, especially if > > > > there are time restraints involved. > > > > > > So have them run that perf thing acme pointed to. > > > > > > So far nobody's made a good argument for why we cannot have LOST events. > > > > If you don't see the use case, I'm not sure anyone can convince you. > > Again, I like the fact that when I do a strace of an application I know > > that all system calls that the application I'm tracing is recorded. I > > don't need to worry about what happened in the "lost events" space. > > You're the one pushing for this crap without _any_ justification. Why > are you getting upset if I ask for some? > > If people care so much, it shouldn't be hard to write up a coherent > story on this, so far all I seem to get is: because it's always been > like that. > > Which really isn't much of an argument. As you rightly pointed out, strace users are expecting that no events are lost because it's always been like that, and it would require some efforts to imagine what kind of things are going to break if this is no longer the case. Last FOSDEM I attended a talk [1] by Philippe Ombredanne, he was speaking about a strace-based tool called TraceCode that constructs build graphs that are used to find out "exactly which files were built, by what and how they were transformed in multiple steps from sources to your final binaries". Imagine you told Philippe that strace now works faster but it's no longer reliable because some events may be lost, and he would have to repeat builds under strace again and again until he is lucky. I can imagine his reaction to this piece of news, and I certainly wouldn't like to be the messenger. btw, I didn't ask for the implementation to be ugly. You don't have to introduce polling into the kernel if you don't want to, userspace is perfectly capable of invoking wait4(2) in a loop. Just block the tracee, notify the tracer, and let it pick up the pieces. [1] https://archive.fosdem.org/2018/schedule/event/debugging_tools_stracing_build/ -- ldv signature.asc Description: PGP signature
Re: [PATCH] rtlwifi: Fix non-working BSS STA mode
On Wed, 2018-12-12 at 13:13 +0800, Kai-Heng Feng wrote: > Once BSS STA mode gets started, it can be scanned by other clients but > cannot entablish a connection. ^^^ typo: establish > > Turns out the set_bcn_reg() and its *_set_beacon_related_registers() > callbacks never get called so it has problem beaconing. > > Enable the function in rtl_op_bss_info_changed() can make BSS STA mode > start to work. > > Signed-off-by: Kai-Heng Feng > --- > drivers/net/wireless/realtek/rtlwifi/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c > b/drivers/net/wireless/realtek/rtlwifi/core.c > index 4bf7967590ca..11d27a5cc576 100644 > --- a/drivers/net/wireless/realtek/rtlwifi/core.c > +++ b/drivers/net/wireless/realtek/rtlwifi/core.c > @@ -1054,7 +1054,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw > *hw, > "BSS_CHANGED_BEACON_ENABLED\n"); > > /*start hw beacon interrupt. */ > - /*rtlpriv->cfg->ops->set_bcn_reg(hw); */ > + rtlpriv->cfg->ops->set_bcn_reg(hw); > mac->beacon_enabled = 1; > rtlpriv->cfg->ops->update_interrupt_mask(hw, > rtlpriv->cfg->maps Which wifi chip do you use? And, please share your test scenario. Thanks
Re: rcu_preempt caused oom
On Wed, Dec 12, 2018 at 11:13:22PM +, He, Bo wrote:
> I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked
> the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu.
> Please correct me if I have something wrong.
That would be because I sent you the wrong patch, apologies! :-/
Please instead see the one below, which does add sysrq_rcu.
Thanx, Paul
> -Original Message-
> From: Paul E. McKenney
> Sent: Thursday, December 13, 2018 5:03 AM
> To: He, Bo
> Cc: Steven Rostedt ; linux-kernel@vger.kernel.org;
> j...@joshtriplett.org; mathieu.desnoy...@efficios.com;
> jiangshan...@gmail.com; Zhang, Jun ; Xiao, Jin
> ; Zhang, Yanmin ; Bai, Jie A
>
> Subject: Re: rcu_preempt caused oom
>
> On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote:
> > On Wed, Dec 12, 2018 at 01:21:33PM +, He, Bo wrote:
> > > we reproduce on two boards, but I still not see the
> > > show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the
> > > scenario.
> > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as
> > > it's extracted from the /proc/config.gz.
> >
> > Strange.
> >
> > Are the systems responsive to sysrq keys once failure occurs? If so,
> > I will provide you a sysrq-R or some such to dump out the RCU state.
>
> Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the
> patch below. Only lightly tested.
commit 04b6245c8458e8725f4169e62912c1fadfdf8141
Author: Paul E. McKenney
Date: Wed Dec 12 16:10:09 2018 -0800
rcu: Add sysrq rcu_node-dump capability
Backported from v4.21/v5.0
Life is hard if RCU manages to get stuck without triggering RCU CPU
stall warnings or triggering the rcu_check_gp_start_stall() checks
for failing to start a grace period. This commit therefore adds a
boot-time-selectable sysrq key (commandeering "y") that allows manually
dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter
must be set for this sysrq to be available.
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0b760c1369f7..e9392a9d6291 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -61,6 +61,7 @@
#include
#include
#include
+#include
#include "tree.h"
#include "rcu.h"
@@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT;
int rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # rcu_nodes in use.
*/
/* panic() on RCU Stall sysctl. */
int sysctl_panic_on_rcu_stall __read_mostly;
+/* Commandeer a sysrq key to dump RCU's tree. */
+static bool sysrq_rcu;
+module_param(sysrq_rcu, bool, 0444);
/*
* The rcu_scheduler_active variable is initialized to the value
@@ -662,6 +666,27 @@ void show_rcu_gp_kthreads(void)
}
EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads);
+/* Dump grace-period-request information due to commandeered sysrq. */
+static void sysrq_show_rcu(int key)
+{
+ show_rcu_gp_kthreads();
+}
+
+static struct sysrq_key_op sysrq_rcudump_op = {
+ .handler = sysrq_show_rcu,
+ .help_msg = "show-rcu(y)",
+ .action_msg = "Show RCU tree",
+ .enable_mask = SYSRQ_ENABLE_DUMP,
+};
+
+static int __init rcu_sysrq_init(void)
+{
+ if (sysrq_rcu)
+ return register_sysrq_key('y', _rcudump_op);
+ return 0;
+}
+early_initcall(rcu_sysrq_init);
+
/*
* Send along grace-period-related data for rcutorture diagnostics.
*/
Re: [PATCH net-next] bnxt: remove printing of hwrm message
From: Jonathan Toppins Date: Wed, 12 Dec 2018 11:58:51 -0500 > bnxt_en :19:00.0 (unregistered net_device) (uninitialized): hwrm > req_type 0x190 seq id 0x6 error 0x > > The message above is commonly seen when a newer driver is used on > hardware with older firmware. The issue is this message means nothing to > anyone except Broadcom. Remove the message to not confuse users as this > message is really not very informative. > > Signed-off-by: Jonathan Toppins > --- > > Notes: > v2: > include changes recommended by Michael Chan Applied, thank you.
Re: [PATCH v2 0/3] ntb_hw_switchtec: Added support of >=4G memory windows
On 2018-12-12 5:25 p.m., Jon Mason wrote: > On Wed, Dec 12, 2018 at 7:01 PM Logan Gunthorpe wrote: >> >> >> >> On 2018-12-12 4:57 p.m., Jon Mason wrote: >>> On Wed, Dec 12, 2018 at 6:42 PM Logan Gunthorpe wrote: On 2018-12-12 4:00 p.m., Jon Mason wrote: > So, you based your patches on a series of patches not in the > ntb/ntb-next branch? Please don't do this. I see nothing in these > patches which requires that series, which makes this even more > unnecessary. Since these are fairly trivial, I'm taking them and > pushing to the ntb-next branch to give these more time to be tested > (due to not being tested on the proper branch). I would really > appreciate you testing the ntb-next branch as a sanity check. The NTB test tools don't work with switchtec hardware without that patch set, so there's no way to test the changes without that branch. >>> >>> Then let's get those patches in. IIRC, I asked you to split up the >>> patch series to be bugfixes and features (or at least reorder the >>> series so I can split it up that way in my branches). Also, I think >>> Serge had some comments that may/may not need to be addressed. Could >>> you please reorder and resend (and Serge can comment as needed on the >>> resend)? >> >> I resent a while back and responded to all the feedback. Every patch in >> that series fixes a bug. None of them add features. > > Per https://lkml.org/lkml/2018/6/12/552, I asked the series be split > up and the comments to be cleaned-up. You repushed without addressing > this (or Serge's comments), which caused me to ignore the series. > Again, I'm happy to take it as a single series and split it up on my > end, I just need the patches reordered to have the bugfixes I > specified in the front to allow for this to be easily done. And what was not clear about my response? https://lkml.org/lkml/2018/6/12/577 That commit is absolutely *not* a feature request. Without it, none of the other fixes will fix anything and are thus worse than useless. I responded to Serge's comments and then responded *again* in the cover letter of v2. What he was asking for was, and still is, physically impossible. Logan
RE: KASAN: use-after-free Read in tipc_group_cong
> -Original Message-
> From: syzbot
> Sent: 12-Dec-18 06:11
> To: da...@davemloft.net; Jon Maloy ; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; syzkaller-
> b...@googlegroups.com; tipc-discuss...@lists.sourceforge.net;
> ying@windriver.com
> Subject: KASAN: use-after-free Read in tipc_group_cong
This seems to be an effect of the same bug as reported in
https://syzkaller.appspot.com/bug?extid=10a9db47c3a0e13eb31c
Cong posted a fix for that one. Did you see the crash after applying his patch?
///jon
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:f5d582777bcb Merge branch 'for-linus' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1705d52540
> kernel config: https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
> dashboard link:
> https://syzkaller.appspot.com/bug?extid=9845fed98688e01f431e
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101b6ba340
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+9845fed98688e01f4...@syzkaller.appspotmail.com
>
> 8021q: adding VLAN 0 to HW filter on device team0
> 8021q: adding VLAN 0 to HW filter on device team0
> audit: type=1400 audit(1544592509.246:38): avc: denied { associate } for
> pid=6204 comm="syz-executor5" name="syz5"
> scontext=unconfined_u:object_r:unlabeled_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1
> ==
>
> BUG: KASAN: use-after-free in tipc_group_find_dest net/tipc/group.c:255
> [inline]
> BUG: KASAN: use-after-free in tipc_group_cong+0x566/0x5d0
> net/tipc/group.c:416
> Read of size 8 at addr 8881c59f5000 by task syz-executor4/10565
>
> CPU: 1 PID: 10565 Comm: syz-executor4 Not tainted 4.20.0-rc6+ #151
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011 Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x244/0x39d lib/dump_stack.c:113
> print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> tipc_group_find_dest net/tipc/group.c:255 [inline]
> tipc_group_cong+0x566/0x5d0 net/tipc/group.c:416
> tipc_send_group_anycast+0x9bb/0xc80 net/tipc/socket.c:972
> __tipc_sendmsg+0x12b1/0x1d40 net/tipc/socket.c:1309
> tipc_sendmsg+0x50/0x70 net/tipc/socket.c:1272
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:631
> ___sys_sendmsg+0x7fd/0x930 net/socket.c:2116
> __sys_sendmsg+0x11d/0x280 net/socket.c:2154
> __do_sys_sendmsg net/socket.c:2163 [inline]
> __se_sys_sendmsg net/socket.c:2161 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457679
> Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
> 0f 83
> cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:7f813d748c78 EFLAGS: 0246 ORIG_RAX:
> 002e
> RAX: ffda RBX: 0003 RCX: 00457679
> RDX: RSI: 26c0 RDI: 0005
> RBP: 0072bfa0 R08: R09:
> R10: R11: 0246 R12: 7f813d7496d4
> R13: 004c44dd R14: 004d74c8 R15:
>
> Allocated by task 10551:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
> kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620
> kmalloc include/linux/slab.h:546 [inline]
> kzalloc include/linux/slab.h:741 [inline]
> tipc_group_create+0x152/0xa70 net/tipc/group.c:171
> tipc_sk_join net/tipc/socket.c:2829 [inline]
> tipc_setsockopt+0x2d1/0xd70 net/tipc/socket.c:2944
> __sys_setsockopt+0x1ba/0x3c0 net/socket.c:1902
> __do_sys_setsockopt net/socket.c:1913 [inline]
> __se_sys_setsockopt net/socket.c:1910 [inline]
> __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 10567:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kfree+0xcf/0x230 mm/slab.c:3817
> tipc_group_delete+0x2e4/0x3f0 net/tipc/group.c:227
> tipc_sk_leave+0x113/0x220 net/tipc/socket.c:2863
> tipc_setsockopt+0x97d/0xd70 net/tipc/socket.c:2947
[PATCH] quota: Lock s_umount in exclusive mode for Q_XQUOTA{ON,OFF} quotactls.
Commit 1fa5efe3622db58cb8c7b9a50665e9eb9a6c7e97 (ext4: Use generic helpers for
quotaon
and quotaoff) made possible to call quotactl(Q_XQUOTAON/OFF) on ext4 filesystems
with sysfile quota support. This leads to calling dquot_enable/disable without
s_umount
held in excl. mode, because quotactl_cmd_onoff checks only for Q_QUOTAON/OFF.
The following WARN_ON_ONCE triggers (in this case for dquot_enable, ext4,
latest Linus' tree):
[ 117.807056] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
quota,prjquota
[...]
[ 155.036847] WARNING: CPU: 0 PID: 2343 at fs/quota/dquot.c:2469
dquot_enable+0x34/0xb9
[ 155.036851] Modules linked in: quota_v2 quota_tree ipv6 af_packet joydev
mousedev psmouse serio_raw pcspkr i2c_piix4 intel_agp intel_gtt e1000 ttm
drm_kms_helper drm agpgart fb_sys_fops syscopyarea sysfillrect sysimgblt
i2c_core input_leds kvm_intel kvm irqbypass qemu_fw_cfg floppy evdev parport_pc
parport button crc32c_generic dm_mod ata_generic pata_acpi ata_piix libata loop
ext4 crc16 mbcache jbd2 usb_storage usbcore sd_mod scsi_mod
[ 155.036901] CPU: 0 PID: 2343 Comm: qctl Not tainted
4.20.0-rc6-00025-gf5d582777bcb #9
[ 155.036903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1ubuntu1 04/01/2014
[ 155.036911] RIP: 0010:dquot_enable+0x34/0xb9
[ 155.036915] Code: 41 56 41 55 41 54 55 53 4c 8b 6f 28 74 02 0f 0b 4d 8d 7d
70 49 89 fc 89 cb 41 89 d6 89 f5 4c 89 ff e8 23 09 ea ff 85 c0 74 0a <0f> 0b 4c
89 ff e8 8b 09 ea ff 85 db 74 6a 41 8b b5 f8 00 00 00 0f
[ 155.036918] RSP: 0018:b09b00493e08 EFLAGS: 00010202
[ 155.036922] RAX: 0001 RBX: 0008 RCX: 0008
[ 155.036924] RDX: 0001 RSI: 0002 RDI: 9781b67cd870
[ 155.036926] RBP: 0002 R08: R09: 61c8864680b583eb
[ 155.036929] R10: b09b00493e48 R11: ff7ce7d4 R12: 9781b7ee8d78
[ 155.036932] R13: 9781b67cd800 R14: 0004 R15: 9781b67cd870
[ 155.036936] FS: 7fd813250b88() GS:9781ba00()
knlGS:
[ 155.036939] CS: 0010 DS: ES: CR0: 80050033
[ 155.036942] CR2: 7fd812ff61d6 CR3: 7c882000 CR4: 06b0
[ 155.036951] DR0: DR1: DR2:
[ 155.036953] DR3: DR6: fffe0ff0 DR7: 0400
[ 155.036955] Call Trace:
[ 155.037004] dquot_quota_enable+0x8b/0xd0
[ 155.037011] kernel_quotactl+0x628/0x74e
[ 155.037027] ? do_mprotect_pkey+0x2a6/0x2cd
[ 155.037034] __x64_sys_quotactl+0x1a/0x1d
[ 155.037041] do_syscall_64+0x55/0xe4
[ 155.037078] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 155.037105] RIP: 0033:0x7fd812fe1198
[ 155.037109] Code: 02 77 0d 48 89 c1 48 c1 e9 3f 75 04 48 8b 04 24 48 83 c4
50 5b c3 48 83 ec 08 49 89 ca 48 63 d2 48 63 ff b8 b3 00 00 00 0f 05 <48> 89 c7
e8 c1 eb ff ff 5a c3 48 63 ff b8 bb 00 00 00 0f 05 48 89
[ 155.037112] RSP: 002b:7ffe8cd7b050 EFLAGS: 0206 ORIG_RAX:
00b3
[ 155.037116] RAX: ffda RBX: 7ffe8cd7b148 RCX: 7fd812fe1198
[ 155.037119] RDX: RSI: 7ffe8cd7cea9 RDI: 00580102
[ 155.037121] RBP: 7ffe8cd7b0f0 R08: 55fc8eba8a9d R09:
[ 155.037124] R10: 7ffe8cd7b074 R11: 0206 R12: 7ffe8cd7b168
[ 155.037126] R13: 55fc8eba8897 R14: R15:
[ 155.037131] ---[ end trace 210f864257175c51 ]---
and then the syscall proceeds without s_umount locking.
This patch locks the superblock ->s_umount sem. in exclusive mode for all
Q_XQUOTAON/OFF
quotactls too in addition to Q_QUOTAON/OFF.
AFAICT, other than ext4, only xfs and ocfs2 are affected by this change.
The VFS will now call in xfs_quota_* functions with s_umount held, which wasn't
the case
before. This looks good to me but I can not say for sure. Ext4 and ocfs2 where
already
beeing called with s_umount exclusive via quota_quotaon/off which is basically
the same.
Signed-off-by: Javier Barrio
---
[ I'm not familiar with this code, please excuse me if this is not the right
fix ]
fs/quota/quota.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/quota/quota.c b/fs/quota/quota.c
index f0cbf58ad4da..fd5dd806f1b9 100644
--- a/fs/quota/quota.c
+++ b/fs/quota/quota.c
@@ -791,7 +791,8 @@ static int quotactl_cmd_write(int cmd)
/* Return true if quotactl command is manipulating quota on/off state */
static bool quotactl_cmd_onoff(int cmd)
{
- return (cmd == Q_QUOTAON) || (cmd == Q_QUOTAOFF);
+ return (cmd == Q_QUOTAON) || (cmd == Q_QUOTAOFF) ||
+(cmd == Q_XQUOTAON) || (cmd == Q_XQUOTAOFF);
}
/*
-- 2.17.1
Re: [PATCH v2 0/3] ntb_hw_switchtec: Added support of >=4G memory windows
On 2018-12-12 4:57 p.m., Jon Mason wrote: > On Wed, Dec 12, 2018 at 6:42 PM Logan Gunthorpe wrote: >> >> >> >> On 2018-12-12 4:00 p.m., Jon Mason wrote: >>> So, you based your patches on a series of patches not in the >>> ntb/ntb-next branch? Please don't do this. I see nothing in these >>> patches which requires that series, which makes this even more >>> unnecessary. Since these are fairly trivial, I'm taking them and >>> pushing to the ntb-next branch to give these more time to be tested >>> (due to not being tested on the proper branch). I would really >>> appreciate you testing the ntb-next branch as a sanity check. >> >> The NTB test tools don't work with switchtec hardware without that patch >> set, so there's no way to test the changes without that branch. > > Then let's get those patches in. IIRC, I asked you to split up the > patch series to be bugfixes and features (or at least reorder the > series so I can split it up that way in my branches). Also, I think > Serge had some comments that may/may not need to be addressed. Could > you please reorder and resend (and Serge can comment as needed on the > resend)? I resent a while back and responded to all the feedback. Every patch in that series fixes a bug. None of them add features. Logan
Re: [PATCH v2 0/3] ntb_hw_switchtec: Added support of >=4G memory windows
On Wed, Dec 12, 2018 at 7:01 PM Logan Gunthorpe wrote: > > > > On 2018-12-12 4:57 p.m., Jon Mason wrote: > > On Wed, Dec 12, 2018 at 6:42 PM Logan Gunthorpe wrote: > >> > >> > >> > >> On 2018-12-12 4:00 p.m., Jon Mason wrote: > >>> So, you based your patches on a series of patches not in the > >>> ntb/ntb-next branch? Please don't do this. I see nothing in these > >>> patches which requires that series, which makes this even more > >>> unnecessary. Since these are fairly trivial, I'm taking them and > >>> pushing to the ntb-next branch to give these more time to be tested > >>> (due to not being tested on the proper branch). I would really > >>> appreciate you testing the ntb-next branch as a sanity check. > >> > >> The NTB test tools don't work with switchtec hardware without that patch > >> set, so there's no way to test the changes without that branch. > > > > Then let's get those patches in. IIRC, I asked you to split up the > > patch series to be bugfixes and features (or at least reorder the > > series so I can split it up that way in my branches). Also, I think > > Serge had some comments that may/may not need to be addressed. Could > > you please reorder and resend (and Serge can comment as needed on the > > resend)? > > I resent a while back and responded to all the feedback. Every patch in > that series fixes a bug. None of them add features. Per https://lkml.org/lkml/2018/6/12/552, I asked the series be split up and the comments to be cleaned-up. You repushed without addressing this (or Serge's comments), which caused me to ignore the series. Again, I'm happy to take it as a single series and split it up on my end, I just need the patches reordered to have the bugfixes I specified in the front to allow for this to be easily done. Alternatively, you can rebase and resend them as-is to the ntb mailing list and we can rehash it out there. Thanks, Jon > > Logan > > -- > You received this message because you are subscribed to the Google Groups > "linux-ntb" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-ntb+unsubscr...@googlegroups.com. > To post to this group, send email to linux-...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/linux-ntb/ff7019a0-bac2-2de2-d06c-d54a82286b90%40deltatee.com. > For more options, visit https://groups.google.com/d/optout.
Re: [PATCH 6/7] selftest/bpf: remove redundant parenthesis
On Wed, 12 Dec 2018 21:15:52 +, Edward Cree wrote:
> On 12/12/18 19:04, Jakub Kicinski wrote:
> > On Tue, 11 Dec 2018 20:56:06 +0900, Alice Ferrazzi wrote:
> >> Signed-off-by: Alice Ferrazzi
> >> ---
> >> tools/testing/selftests/bpf/test_offload.py | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/tools/testing/selftests/bpf/test_offload.py
> >> b/tools/testing/selftests/bpf/test_offload.py
> >> index 0f9130ebfd2c..b06cc0eea0eb 100755
> >> --- a/tools/testing/selftests/bpf/test_offload.py
> >> +++ b/tools/testing/selftests/bpf/test_offload.py
> >> @@ -140,7 +140,7 @@ def cmd_result(proc, include_stderr=False, fail=False):
> >>
> >>
> >> def rm(f):
> >> -cmd("rm -f %s" % (f))
> >> +cmd("rm -f %s" % f)
> >> if f in files:
> >> files.remove(f)
> >>
> > Is this in PEP8, too?
> I don't know, but it shouldn't be.
> If f is a sequence type, both the old and new code can break here,
> throwing a TypeError. It should be cmd("rm -f %s" % (f,)). The
> presence of the brackets suggests to me that that's what the
> original author intended.
Agreed, that was my intention, I didn't know about the comma option.
> Now, it's unlikely that we'd ever want to pass a list or tuple
> here, since 'rm' wouldn't understand the result, but the proper
> way to deal with that is an assertion with a meaningful message,
> since the TypeError here will have the non-obvious message "not
> all arguments converted during string formatting".
Interesting, thanks for the analysis!
Re: [PATCHv2 net 0/3] net: add support for flex_array_resize in flex_array
From: Neil Horman Date: Wed, 12 Dec 2018 07:00:15 -0500 > I suggest xin respond to messageid > 20180523011821.12165-6-kent.overstr...@gmail.com> and send a NAK, > indicating that his patch seems like it will break the build, as, > looking through it, it never removes flex_array calls from the sctp > code. If kent reposts with a conversion of the sctp code to radix > trees, we're done. If not, you can move forward with this commit. Ok, Xin please do that so we can more forward. Thanks Neil.
Re: [alsa-devel] [PATCH 0/2] Graph fixes for using multiple endpoints per port
Hi Tony
> /* Codec has 1 DAI */
> Codec {
> port {
> #address-cells = <2>;
> #size-cells = <1>;
>
> ep: endpoint {
> remote-endpoint = ;
> };
> };
> }
(snip)
> foo = < 0>;
> bar = < 1>;
Ahh, it looks nice idea !
but hmm..., it seems dtc doesn't allow us to use #address-cells = <2>
for "remote-endpoint".
--- ${LINUX}/scripts/dtc/checks.c ---
static struct node *get_remote_endpoint(struct check *c, struct dt_info *dti,
struct node *endpoint)
{
...
prop = get_property(endpoint, "remote-endpoint");
if (!prop)
return NULL;
=> phandle = propval_cell(prop);
/* Give up if this is an overlay with external references */
...
}
I'm not good at dtc, but propval_cell() is assuming it is single address cell.
We will have many assert warning on
remote-endpoint = < 0>;
Can you please double check it ?
And, I'm wonder remote-endpoint need to cross pointing, right ?
one way looks nice by address-cells <2>, but other way is ?
port {
cpu-ep0: endpoint@0 {
remote-endpoint = < 0>;
};
cpu-ep1: endpoint@1 {
remote-endpoint = < 1>;
};
};
port {
#address-cells = <2>;
#size-cells = <1>;
codec-ep: endpoint {
(*1)remote-endpoint = <>;
};
};
This case, cpu-epX -> codec-ep are OK.
But, codec-ep -> cpu-epX case can point only 1 endpoint (*1).
I'm not sure, but maybe this is not a OF graph policy (?)
> > Can you agree this ? we need extra patch,
> > but it can solve your / my problem.
>
> Yes it's starting to make sense :)
Thanks
> > Now I'm posting patches to merging
> > "audio-graph-card" and "DPCM ver audio-graph-card".
> > If you are OK, I will include above solution patch
> > to this patch-set.
>
> Sure, maybe please first check if the #size-cells = <2>
> option would work though?
maybe #address-cells, instead of #size-cells ;P
But, yeah, please double check it too.
> > Current audio-graph doesn't expect your use-case,
> > and I want to avoid conflict.
> >
> > So, "merged" audio-graph should solve your use-case.
> > If you can agree about this, I will post patch-set.
>
> Yeah I agree, just still wondering what might be the best
> way to represent 1 DAI vs 2 DAIs.
According to OF graph maintainer, he said that
counting port / endpoint are not guaranteed,
and we need to use "reg".
(It is the reason of b6f3fc005a2c8b425d7a0973b43bef05890bf479)
If you could double checked, and we could agreed
that "reg" is the solution for us.
I will post patches.
Best regards
---
Kuninori Morimoto
Re: [PATCH v2] netdevsim: convert to DEFINE_SHOW_ATTRIBUTE
From: Yangtao Li Date: Wed, 12 Dec 2018 11:40:07 -0500 > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. > > Signed-off-by: Yangtao Li > --- > v2: > -update subject Applied, thank you.
Re: [PATCH 4.19 096/139] ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops
Hello Thomas,
I have sent a new patch to fix this LED regression, after applying this
patch (ALSA: hda/realtek - fix the pop noise on headphone for lenovo
laptops) and the new patch (ALSA: hda/realtek - Fix the mute LED
regresion on Lenovo X1
Carbon), the issue will be fixed.
This is the new patch I sent (also CCed to stable):
http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/142747.html
About the noise, if you follow the steps as below, you would hear the
noticeable click/pop noise:
1. Hookup a set of headphones that you can separately place in/on your
ears. (ie. ear buds)
2. Put only the right headphone in/on your ear.
3. Go to the Gnome sound settings and bring up the "Test Speakers" function
4. Play the left speaker test
You would expect to hear nothing in the right ear, but instead you hear
a "pop" at the start of each word spoken. ("pop" Front "pop" left). You
can repeat with the left headphone and see similar results. I even tried
shifting the balance all the way to the left/right and get the same
results.
Thanks,
Hui.
On 2018/12/13 上午7:45, Thomas Zeitlhofer wrote:
I have sent a new patch to fix this LED regression, after applying this
patch
Hello,
On Tue, Dec 04, 2018 at 11:49:37AM +0100, Greg Kroah-Hartman wrote:
4.19-stable review patch. If anyone has any objections, please let me
know.
--
From: Hui Wang
commit c4cfcf6f4297c9256b53790bacbbbd6901fef468 upstream.
We have several Lenovo laptops with the codec alc285, when playing
sound via headphone, we can hear click/pop noise in the headphone, if
we let the headphone share the DAC of NID 0x2 with the speaker, the
noise disappears.
The Lenovo laptops here include P52, P72, X1 yoda2 and X1 carbon.
[...]
on a current Thinkpad X1 Yoga, this breaks the LED functionality on the
audio- and mic-mute buttons. While the buttons still work, the LEDs are
permanently off and do not reflect the mute state any more.
Reverting this patch restores the LED functionality.
Here, even without this patch, there is no click/pop noise noticeable
when using headphones.
Regards,
Thomas
Re: linux-next: Signed-off-by missing for commits in the bpf-next tree
On Wed, Dec 12, 2018 at 3:45 PM Bart Van Assche wrote: > > Are you aware of Linus' opinion about rebasing? If not, please have a look > at https://lkml.org/lkml/2016/3/26/71 or https://lwn.net/Articles/328436/. very much aware. above is not applicable to this use case.
Re: [PATCH v2 7/7] ima: Support platform keyring for kernel appraisal
Nayna Jain writes: > On secure boot enabled systems, the bootloader verifies the kernel > image and possibly the initramfs signatures based on a set of keys. A > soft reboot(kexec) of the system, with the same kernel image and > initramfs, requires access to the original keys to verify the > signatures. > > This patch allows IMA-appraisal access to those original keys, now > loaded on the platform keyring, needed for verifying the kernel image > and initramfs signatures. > > Signed-off-by: Nayna Jain > Reviewed-by: Mimi Zohar > Acked-by: Serge Hallyn > - replace 'rc' with 'xattr_len' when calling integrity_digsig_verify() > with INTEGRITY_KEYRING_IMA for readability > Suggested-by: Serge Hallyn > --- > Changelog: > > v2: > - replace 'rc' with 'xattr_len' when calling integrity_digsig_verify() > with INTEGRITY_KEYRING_IMA for readability > > security/integrity/ima/ima_appraise.c | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) With the change to only access the platform keyring when it is enabled: Reviewed-by: Thiago Jung Bauermann -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH v2 7/7] ima: Support platform keyring for kernel appraisal
On Wed, 2018-12-12 at 16:14 -0200, Thiago Jung Bauermann wrote: [snip] > Subject: [PATCH] ima: Only use the platform keyring if it's enabled > > Signed-off-by: Thiago Jung Bauermann Good catch! Thanks. Mimi > --- > security/integrity/ima/ima_appraise.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/security/integrity/ima/ima_appraise.c > b/security/integrity/ima/ima_appraise.c > index e8f520450895..f6ac405daabb 100644 > --- a/security/integrity/ima/ima_appraise.c > +++ b/security/integrity/ima/ima_appraise.c > @@ -297,7 +297,8 @@ int ima_appraise_measurement(enum ima_hooks func, > status = INTEGRITY_UNKNOWN; > break; > } > - if (rc && func == KEXEC_KERNEL_CHECK) > + if (IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING) && rc && > + func == KEXEC_KERNEL_CHECK) > rc = integrity_digsig_verify(INTEGRITY_KEYRING_PLATFORM, >(const char *)xattr_value, >xattr_len,
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On Wed, Dec 12, 2018 at 4:01 PM Jerome Glisse wrote: > > On Wed, Dec 12, 2018 at 04:37:03PM -0700, Jason Gunthorpe wrote: > > On Wed, Dec 12, 2018 at 04:53:49PM -0500, Jerome Glisse wrote: > > > > Almost, we need some safety around assuming that DMA is complete the > > > > page, so the notification would need to go all to way to userspace > > > > with something like a file lease notification. It would also need to > > > > be backstopped by an IOMMU in the case where the hardware does not / > > > > can not stop in-flight DMA. > > > > > > You can always reprogram the hardware right away it will redirect > > > any dma to the crappy page. > > > > That causes silent data corruption for RDMA users - we can't do that. > > > > The only way out for current hardware is to forcibly terminate the > > RDMA activity somehow (and I'm not even sure this is possible, at > > least it would be driver specific) > > > > Even the IOMMU idea probably doesn't work, I doubt all current > > hardware can handle a PCI-E error TLP properly. > > What i saying is reprogram hardware to crappy page ie valid page > dma map but that just has random content as a last resort to allow > filesystem to reuse block. So their should be no PCIE error unless > hardware freak out to see its page table reprogram randomly. Hardware has a hard enough time stopping I/O to existing page let alone switching to a new one in the middle of a transaction. This is a non-starter, but it's also a non-concern because the bulk of DMA is transient. For non-transient DMA there is a usually a registration phase where the capability to support revocation can be validated,
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On Wed, Dec 12, 2018 at 04:37:03PM -0700, Jason Gunthorpe wrote: > On Wed, Dec 12, 2018 at 04:53:49PM -0500, Jerome Glisse wrote: > > > Almost, we need some safety around assuming that DMA is complete the > > > page, so the notification would need to go all to way to userspace > > > with something like a file lease notification. It would also need to > > > be backstopped by an IOMMU in the case where the hardware does not / > > > can not stop in-flight DMA. > > > > You can always reprogram the hardware right away it will redirect > > any dma to the crappy page. > > That causes silent data corruption for RDMA users - we can't do that. > > The only way out for current hardware is to forcibly terminate the > RDMA activity somehow (and I'm not even sure this is possible, at > least it would be driver specific) > > Even the IOMMU idea probably doesn't work, I doubt all current > hardware can handle a PCI-E error TLP properly. What i saying is reprogram hardware to crappy page ie valid page dma map but that just has random content as a last resort to allow filesystem to reuse block. So their should be no PCIE error unless hardware freak out to see its page table reprogram randomly. > > On some hardware it probably just protects DAX by causing data > corruption for RDMA - I fail to see how that is a win for system > stability if the user obviously wants to use DAX and RDMA together... The question is who do you want to punish ? RDMA user that pin stuff and expect thing to work forever without worrying for other fs activities ? Or filesystem to pin block forever :) I am not gonna take side here but i don't think we can please both side, one will have to be mean to the user ie either the RDMA user or the file- system which also percolate to being mean to end user. > I think your approach with ODP only is the only one that meets your > requirements, the only other data-integrity-preserving approach is to > block/fail ftruncate/etc. > > > From my point of view driver should listen to ftruncate before the > > mmu notifier kicks in and send event to userspace and maybe wait > > and block ftruncate (or move it to a worker thread). > > We can do this, but we can't guarantee forward progress in userspace > and the best way we have to cancel that is portable to all RDMA > hardware is to kill the process(es).. > > So if that is acceptable then we could use user notifiers and allow > non-ODP users... Yes ODP with listening to _all_ mmu notifier event is the only sane way. But for hardware not capable of doing that (GPU are capable, so are mlx5, i won't do a list of the bad ones). We either keep the status quo that is today behavior or we do something either mean to the RDMA user or mean to the file- system. And previous discussion on failing ftruncate where a no no, can't remember why. In any case i am personnaly fine with what ever which is: S1: keep block pin until RDMA goes away, even if it means that RDMA user is no longer really accessing anything that make sense (ie the page is no longer part of the file or the original vma so as this point it fully disconnected from the original intent ie today status quo we pin block and annoy filesystem while we pretend that everything is fine. S2: notify userspace program through device/sub-system specific API and delay ftruncate. After a while if there is no answer just be mean and force hardware to use crappy page as anyway this is what happens today (note we can fully mirror today behavior by allocating pages and copying existing content their and then swaping out to point the hardware to those pages. S3: be mean to filesystem a keep block pin for as long as they are active GUP, this means failing ftruncate and or possibly munmap(). S3 can be split in sub-choices. Do we want to take vote ? Or is there a way that can please everyone ? Cheers, Jérôme
Re: [PATCH v2 2/7] integrity: Load certs to the platform keyring
Nayna Jain writes: > The patch refactors integrity_load_x509(), making it a wrapper for a new > function named integrity_add_key(). This patch also defines a new > function named integrity_load_cert() for loading the platform keys. > > Signed-off-by: Nayna Jain > Reviewed-by: Mimi Zohar > Acked-by: Serge Hallyn > --- > security/integrity/digsig.c| 71 > ++ > security/integrity/integrity.h | 20 ++ > .../integrity/platform_certs/platform_keyring.c| 23 +++ > 3 files changed, 90 insertions(+), 24 deletions(-) Reviewed-by: Thiago Jung Bauermann -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH v2 1/7] integrity: Define a trusted platform keyring
Nayna Jain writes: > On secure boot enabled systems, a verified kernel may need to kexec > additional kernels. For example, it may be used as a bootloader needing > to kexec a target kernel or it may need to kexec a crashdump kernel. In > such cases, it may want to verify the signature of the next kernel > image. > > It is further possible that the kernel image is signed with third party > keys which are stored as platform or firmware keys in the 'db' variable. > The kernel, however, can not directly verify these platform keys, and an > administrator may therefore not want to trust them for arbitrary usage. > In order to differentiate platform keys from other keys and provide the > necessary separation of trust, the kernel needs an additional keyring to > store platform keys. > > This patch creates the new keyring called ".platform" to isolate keys > provided by platform from keys by kernel. These keys are used to > facilitate signature verification during kexec. Since the scope of this > keyring is only the platform/firmware keys, it cannot be updated from > userspace. > > This keyring can be enabled by setting CONFIG_INTEGRITY_PLATFORM_KEYRING. > > Signed-off-by: Nayna Jain > Reviewed-by: Mimi Zohar > Acked-by: Serge Hallyn > --- > security/integrity/Kconfig | 11 + > security/integrity/Makefile| 1 + > security/integrity/digsig.c| 48 > +++--- > security/integrity/integrity.h | 3 +- > .../integrity/platform_certs/platform_keyring.c| 35 > 5 files changed, 83 insertions(+), 15 deletions(-) > create mode 100644 security/integrity/platform_certs/platform_keyring.c Reviewed-by: Thiago Jung Bauermann -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH v2 0/3] ntb_hw_switchtec: Added support of >=4G memory windows
On Wed, Dec 12, 2018 at 6:42 PM Logan Gunthorpe wrote: > > > > On 2018-12-12 4:00 p.m., Jon Mason wrote: > > So, you based your patches on a series of patches not in the > > ntb/ntb-next branch? Please don't do this. I see nothing in these > > patches which requires that series, which makes this even more > > unnecessary. Since these are fairly trivial, I'm taking them and > > pushing to the ntb-next branch to give these more time to be tested > > (due to not being tested on the proper branch). I would really > > appreciate you testing the ntb-next branch as a sanity check. > > The NTB test tools don't work with switchtec hardware without that patch > set, so there's no way to test the changes without that branch. Then let's get those patches in. IIRC, I asked you to split up the patch series to be bugfixes and features (or at least reorder the series so I can split it up that way in my branches). Also, I think Serge had some comments that may/may not need to be addressed. Could you please reorder and resend (and Serge can comment as needed on the resend)? Thanks, Jon > > You're right that there is no compile-time dependency. > > Logan > > -- > You received this message because you are subscribed to the Google Groups > "linux-ntb" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-ntb+unsubscr...@googlegroups.com. > To post to this group, send email to linux-...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/linux-ntb/f22b6112-920b-37f1-68fe-f43164a18f05%40deltatee.com. > For more options, visit https://groups.google.com/d/optout.
Re: [PATCH][v6] filemap: drop the mmap_sem for all blocking operations
On Wed, 12 Dec 2018 10:27:57 -0500 Josef Bacik wrote:
> v5->v6:
> - added more comments as per Andrew's suggestion.
> - fixed the fpin leaks in the two error paths that were pointed out.
>
hm,
> --- a/mm/filemap.c~filemap-drop-the-mmap_sem-for-all-blocking-operations-v6
> +++ a/mm/filemap.c
> @@ -2461,7 +2476,8 @@ static struct file *do_sync_mmap_readahe
>
> /*
> * Asynchronous readahead happens when we find the page and PG_readahead,
> - * so we want to possibly extend the readahead further..
> + * so we want to possibly extend the readahead further. We return the file
> that
> + * was pinned if we have to drop the mmap_sem in order to do IO.
> */
> static struct file *do_async_mmap_readahead(struct vm_fault *vmf,
> struct page *page)
> @@ -2545,14 +2561,15 @@ retry_find:
> page = pagecache_get_page(mapping, offset,
> FGP_CREAT|FGP_FOR_MMAP,
> vmf->gfp_mask);
> - if (!page)
> + if (!page) {
> + if (fpin)
> + goto out_retry;
Is this right? If pagecache_get_page() returns NULL we can now return
VM_FAULT_MAJOR|VM_FAULT_RETRY whereas we used to return ENOMEM.
> return vmf_error(-ENOMEM);
> + }
> }
>
> - if (!lock_page_maybe_drop_mmap(vmf, page, )) {
> - put_page(page);
> - return ret | VM_FAULT_RETRY;
> - }
> + if (!lock_page_maybe_drop_mmap(vmf, page, ))
> + goto out_retry;
>
> /* Did it get truncated? */
> if (unlikely(page->mapping != mapping)) {
Re: [PATCH] blkcg: handle dying request_queue when associating a blkg
On Tue, 2018-12-11 at 23:06 -0500, Dennis Zhou wrote:
> Hi Bart,
>
> On Tue, Dec 11, 2018 at 03:16:13PM -0800, Bart Van Assche wrote:
> > On Tue, 2018-12-11 at 18:03 -0500, Dennis Zhou wrote:
> > > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> > > index 6bd0619a7d6e..c30661ddc873 100644
> > > --- a/block/blk-cgroup.c
> > > +++ b/block/blk-cgroup.c
> > > @@ -202,6 +202,12 @@ static struct blkcg_gq *blkg_create(struct blkcg
> > > *blkcg,
> > > WARN_ON_ONCE(!rcu_read_lock_held());
> > > lockdep_assert_held(>queue_lock);
> > >
> > > + /* request_queue is dying, do not create/recreate a blkg */
> > > + if (blk_queue_dying(q)) {
> > > + ret = -ENODEV;
> > > + goto err_free_blkg;
> > > + }
> > > +
> > > /* blkg holds a reference to blkcg */
> > > if (!css_tryget_online(>css)) {
> > > ret = -ENODEV;
> >
> > What prevents that the queue state changes after blk_queue_dying() has
> > returned
> > and before blkg_create() returns? Are you sure you don't need to protect
> > this
> > code with a blk_queue_enter() / blk_queue_exit() pair?
> >
>
> Hmmm. So I think the idea is that we rely on normal shutdown as I don't
> think there is anything wrong with creating a blkg on a dying
> request_queue. When we are doing association, the request_queue should
> be pinned by the open call. What we are racing against is when the
> request_queue is shutting down, it goes around and destroys the blkgs.
> For clarity, QUEUE_FLAG_DYING is set in blk_cleanup_queue() before
> calling blk_exit_queue() which eventually calls blkcg_exit_queue().
>
> The use of blk_queue_dying() is to determine whether blkg shutdown has
> already started as if we create one after it has started, we may
> incorrectly orphan a blkg and leak it. Both blkg creation and
> destruction require holding the queue_lock, so if the QUEUE_FLAG_DYING
> flag is set after we've checked it, it means blkg destruction hasn't
> started because it has to wait on the queue_lock. If QUEUE_FLAG_DYING is
> set, then we have no guarantee of knowing what phase blkg destruction is
> in leading to a potential leak.
Hi Dennis,
To answer my own question: since all queue flag manipulations are protected
by the queue lock and since blkg_create() is called with the queue lock held
the above code does not need any further protection. Hence feel free to add
the following:
Reviewed-by: Bart Van Assche
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On Wed, Dec 12, 2018 at 3:37 PM Jason Gunthorpe wrote: > > On Wed, Dec 12, 2018 at 04:53:49PM -0500, Jerome Glisse wrote: > > > Almost, we need some safety around assuming that DMA is complete the > > > page, so the notification would need to go all to way to userspace > > > with something like a file lease notification. It would also need to > > > be backstopped by an IOMMU in the case where the hardware does not / > > > can not stop in-flight DMA. > > > > You can always reprogram the hardware right away it will redirect > > any dma to the crappy page. > > That causes silent data corruption for RDMA users - we can't do that. > > The only way out for current hardware is to forcibly terminate the > RDMA activity somehow (and I'm not even sure this is possible, at > least it would be driver specific) > > Even the IOMMU idea probably doesn't work, I doubt all current > hardware can handle a PCI-E error TLP properly. My thinking here is that we would at least have the infrastructure for userspace to opt-in to getting the callback, the threat of an IOMMU forcibly tearing down mappings, and likely some identification for pages that are revocable. With "long term" pins I would hope to move any detection of incompatibility to the memory registration phase rather than something unacceptable like injecting random truncate failures.
Gold Offer
Dear Sir We are Mr. dicko Gold mining company. We are local miners in Republic of Mali, West Africa. We have gold bars in bulk and we are looking for buyer to buy our products. We have in quantity (150)KG and of quality Gold bars. Buyers can visit our mining site in Kayes, Mali.We are dedicated to serving our customers with total enthusiasm. We appreciate our customers for the opportunity to serve them. We are looking for real investors or buyer for our product and we are ready to establish good business relationship on a long term basis. Commodity: Gold bars Quantity : 100 kg Quality : 22 carat plus Purity : 92% Regards. Mr dicko
[PATCH v4 3/5] soc: bcm: bcm2835-pm: Add support for power domains under a new binding.
This provides a free software alternative to raspberrypi-power.c's
firmware calls to manage power domains. It also exposes a reset line,
where previously the vc4 driver had to try to force power off the
domain in order to trigger a reset.
Signed-off-by: Eric Anholt
Acked-by: Rob Herring
---
v4: no change
drivers/mfd/bcm2835-pm.c | 36 +-
drivers/soc/bcm/Kconfig | 11 +
drivers/soc/bcm/Makefile | 1 +
drivers/soc/bcm/bcm2835-power.c | 661 +++
include/dt-bindings/soc/bcm2835-pm.h | 28 ++
include/linux/mfd/bcm2835-pm.h | 1 +
6 files changed, 734 insertions(+), 4 deletions(-)
create mode 100644 drivers/soc/bcm/bcm2835-power.c
create mode 100644 include/dt-bindings/soc/bcm2835-pm.h
diff --git a/drivers/mfd/bcm2835-pm.c b/drivers/mfd/bcm2835-pm.c
index 53839e6a81e7..42fe67f1538e 100644
--- a/drivers/mfd/bcm2835-pm.c
+++ b/drivers/mfd/bcm2835-pm.c
@@ -3,7 +3,7 @@
* PM MFD driver for Broadcom BCM2835
*
* This driver binds to the PM block and creates the MFD device for
- * the WDT driver.
+ * the WDT and power drivers.
*/
#include
@@ -21,11 +21,16 @@ static const struct mfd_cell bcm2835_pm_devs[] = {
{ .name = "bcm2835-wdt" },
};
+static const struct mfd_cell bcm2835_power_devs[] = {
+ { .name = "bcm2835-power" },
+};
+
static int bcm2835_pm_probe(struct platform_device *pdev)
{
struct resource *res;
struct device *dev = >dev;
struct bcm2835_pm *pm;
+ int ret;
pm = devm_kzalloc(dev, sizeof(*pm), GFP_KERNEL);
if (!pm)
@@ -39,13 +44,36 @@ static int bcm2835_pm_probe(struct platform_device *pdev)
if (IS_ERR(pm->base))
return PTR_ERR(pm->base);
- return devm_mfd_add_devices(dev, -1,
- bcm2835_pm_devs,
ARRAY_SIZE(bcm2835_pm_devs),
- NULL, 0, NULL);
+ ret = devm_mfd_add_devices(dev, -1,
+ bcm2835_pm_devs, ARRAY_SIZE(bcm2835_pm_devs),
+ NULL, 0, NULL);
+ if (ret)
+ return ret;
+
+ /* We'll use the presence of the AXI ASB regs in the
+* bcm2835-pm binding as the key for whether we can reference
+* the full PM register range and support power domains.
+*/
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (res) {
+ pm->asb = devm_ioremap_resource(dev, res);
+ if (IS_ERR(pm->asb))
+ return PTR_ERR(pm->asb);
+
+ ret = devm_mfd_add_devices(dev, -1,
+ bcm2835_power_devs,
+ ARRAY_SIZE(bcm2835_power_devs),
+ NULL, 0, NULL);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
}
static const struct of_device_id bcm2835_pm_of_match[] = {
{ .compatible = "brcm,bcm2835-pm-wdt", },
+ { .compatible = "brcm,bcm2835-pm", },
{},
};
MODULE_DEVICE_TABLE(of, bcm2835_pm_of_match);
diff --git a/drivers/soc/bcm/Kconfig b/drivers/soc/bcm/Kconfig
index 055a845ed979..fe1af29560e9 100644
--- a/drivers/soc/bcm/Kconfig
+++ b/drivers/soc/bcm/Kconfig
@@ -1,5 +1,16 @@
menu "Broadcom SoC drivers"
+config BCM2835_POWER
+ bool "BCM2835 power domain driver"
+ depends on ARCH_BCM2835 || (COMPILE_TEST && OF)
+ select PM_GENERIC_DOMAINS if PM
+ select RESET_CONTROLLER
+ help
+ This enables support for the BCM2835 power domains and reset
+ controller. Any usage of power domains by the Raspberry Pi
+ firmware means that Linux usage of the same power domain
+ must be accessed using the RASPBERRYPI_POWER driver
+
config RASPBERRYPI_POWER
bool "Raspberry Pi power domain driver"
depends on ARCH_BCM2835 || (COMPILE_TEST && OF)
diff --git a/drivers/soc/bcm/Makefile b/drivers/soc/bcm/Makefile
index dc4fced72d21..c81df4b2403c 100644
--- a/drivers/soc/bcm/Makefile
+++ b/drivers/soc/bcm/Makefile
@@ -1,2 +1,3 @@
+obj-$(CONFIG_BCM2835_POWER)+= bcm2835-power.o
obj-$(CONFIG_RASPBERRYPI_POWER)+= raspberrypi-power.o
obj-$(CONFIG_SOC_BRCMSTB) += brcmstb/
diff --git a/drivers/soc/bcm/bcm2835-power.c b/drivers/soc/bcm/bcm2835-power.c
new file mode 100644
index ..48412957ec7a
--- /dev/null
+++ b/drivers/soc/bcm/bcm2835-power.c
@@ -0,0 +1,661 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Power domain driver for Broadcom BCM2835
+ *
+ * Copyright (C) 2018 Broadcom
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PM_GNRIC0x00
+#define PM_AUDIO0x04
+#define PM_STATUS 0x18
+#define PM_RSTC0x1c
+#define PM_RSTS
[PATCH v4 0/5] BCM2835 PM driver
v4 adds the system-power-controller node to the binding as requested by Stefan. No driver changes are added to make the power controller behavior optional yet, since it's really unrelated to this series. Eric Anholt (5): dt-bindings: soc: Add a new binding for the BCM2835 PM node. (v4) bcm2835-pm: Move bcm2835-watchdog's DT probe to an MFD. soc: bcm: bcm2835-pm: Add support for power domains under a new binding. ARM: bcm283x: Extend the WDT DT node out to cover the whole PM block. (v4) ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware. .../bindings/soc/bcm/brcm,bcm2835-pm.txt | 46 ++ arch/arm/boot/dts/bcm2835-rpi.dtsi| 4 - arch/arm/boot/dts/bcm283x.dtsi| 17 +- arch/arm/mach-bcm/Kconfig | 1 + drivers/mfd/Makefile | 1 + drivers/mfd/bcm2835-pm.c | 92 +++ drivers/soc/bcm/Kconfig | 11 + drivers/soc/bcm/Makefile | 1 + drivers/soc/bcm/bcm2835-power.c | 661 ++ drivers/watchdog/bcm2835_wdt.c| 26 +- include/dt-bindings/soc/bcm2835-pm.h | 28 + include/linux/mfd/bcm2835-pm.h| 14 + 12 files changed, 878 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt create mode 100644 drivers/mfd/bcm2835-pm.c create mode 100644 drivers/soc/bcm/bcm2835-power.c create mode 100644 include/dt-bindings/soc/bcm2835-pm.h create mode 100644 include/linux/mfd/bcm2835-pm.h -- 2.20.0.rc1
[PATCH v4 5/5] ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.
The GRAFX domain only contains V3D, and this driver should be the only
accessor of V3D (firmware usage gets disabled when V3D is in the DT),
so we can safely make Linux control the GRAFX and GRAFX_V3D power
domains.
Signed-off-by: Eric Anholt
---
v4: no change
arch/arm/boot/dts/bcm2835-rpi.dtsi | 4
arch/arm/boot/dts/bcm283x.dtsi | 4 +++-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index cb2d6d78a7fb..21a930148709 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -87,10 +87,6 @@
power-domains = < RPI_POWER_DOMAIN_USB>;
};
- {
- power-domains = < RPI_POWER_DOMAIN_V3D>;
-};
-
{
power-domains = < RPI_POWER_DOMAIN_HDMI>;
status = "okay";
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 20ed8b1da11b..9777644c6c2b 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
/* firmware-provided startup stubs live here, where the secondary CPUs are
* spinning.
@@ -120,7 +121,7 @@
#interrupt-cells = <2>;
};
- watchdog@7e10 {
+ pm: watchdog@7e10 {
compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt";
#power-domain-cells = <1>;
#reset-cells = <1>;
@@ -638,6 +639,7 @@
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec0 0x1000>;
interrupts = <1 10>;
+ power-domains = < BCM2835_POWER_DOMAIN_GRAFX_V3D>;
};
vc4: gpu {
--
2.20.0.rc1
[PATCH v4 4/5] ARM: bcm283x: Extend the WDT DT node out to cover the whole PM block. (v4)
It was covering part of the PM block's range, up to the WDT regs. To
support the rest of the PM block's functionality, we need the full
register range plus the AXI Async Bridge regs for PM sequencing.
This doesn't convert any of the consumers over to the new binding yet,
since we will need to be careful in coordinating our usage of firmware
services that might power domains on and off versus the bcm2835-pm
driver's access of those same domains.
Signed-off-by: Eric Anholt
---
v4: Add the system-power-controller node.
arch/arm/boot/dts/bcm283x.dtsi | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 31b29646b14c..20ed8b1da11b 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -121,8 +121,17 @@
};
watchdog@7e10 {
- compatible = "brcm,bcm2835-pm-wdt";
- reg = <0x7e10 0x28>;
+ compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt";
+ #power-domain-cells = <1>;
+ #reset-cells = <1>;
+ reg = <0x7e10 0x114>,
+ <0x7e00a000 0x24>;
+ clocks = < BCM2835_CLOCK_V3D>,
+< BCM2835_CLOCK_PERI_IMAGE>,
+< BCM2835_CLOCK_H264>,
+< BCM2835_CLOCK_ISP>;
+ clock-names = "v3d", "peri_image", "h264", "isp";
+ system-power-controller;
};
clocks: cprman@7e101000 {
--
2.20.0.rc1
[PATCH v4 1/5] dt-bindings: soc: Add a new binding for the BCM2835 PM node. (v4)
This binding supersedes the bcm2835-pm-wdt binding which only covered
enough to provide a watchdog, but the HW block is actually mostly
about power domains.
Signed-off-by: Eric Anholt
Reviewed-by: Rob Herring (v3)
---
v4: Add the system-power-controller node.
.../bindings/soc/bcm/brcm,bcm2835-pm.txt | 46 +++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
new file mode 100644
index ..3b7d32956391
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
@@ -0,0 +1,46 @@
+BCM2835 PM (Power domains, watchdog)
+
+The PM block controls power domains and some reset lines, and includes
+a watchdog timer. This binding supersedes the brcm,bcm2835-pm-wdt
+binding which covered some of PM's register range and functionality.
+
+Required properties:
+
+- compatible: Should be "brcm,bcm2835-pm"
+- reg: Specifies base physical address and size of the two
+ register ranges ("PM" and "ASYNC_BRIDGE" in that
+ order)
+- clocks: a) v3d: The V3D clock from CPRMAN
+ b) peri_image: The PERI_IMAGE clock from CPRMAN
+ c) h264: The H264 clock from CPRMAN
+ d) isp: The ISP clock from CPRMAN
+- #reset-cells:Should be 1. This property follows the reset controller
+ bindings[1].
+- #power-domain-cells: Should be 1. This property follows the power domain
+ bindings[2].
+
+Optional properties:
+
+- timeout-sec: Contains the watchdog timeout in seconds
+- system-power-controller: Whether the watchdog is controlling the
+system power. This node follows the power controller bindings[3].
+
+[1] Documentation/devicetree/bindings/reset/reset.txt
+[2] Documentation/devicetree/bindings/power/power_domain.txt
+[3] Documentation/devicetree/bindings/power/power-controller.txt
+
+Example:
+
+pm {
+ compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt";
+ #power-domain-cells = <1>;
+ #reset-cells = <1>;
+ reg = <0x7e10 0x114>,
+ <0x7e00a000 0x24>;
+ clocks = < BCM2835_CLOCK_V3D>,
+< BCM2835_CLOCK_PERI_IMAGE>,
+< BCM2835_CLOCK_H264>,
+< BCM2835_CLOCK_ISP>;
+ clock-names = "v3d", "peri_image", "h264", "isp";
+ system-power-controller;
+};
--
2.20.0.rc1
[PATCH v4 2/5] bcm2835-pm: Move bcm2835-watchdog's DT probe to an MFD.
The PM block that the wdt driver was binding to actually has multiple
features we want to expose (power domains, reset, watchdog). Move the
DT attachment to a MFD driver and make WDT probe against MFD.
Signed-off-by: Eric Anholt
Reviewed-by: Guenter Roeck
---
v3: don't reset bcm2835_power_off_wdt on remove, drop pm driver's
empty remove, sort includes, add a "static".
v4: no change
arch/arm/mach-bcm/Kconfig | 1 +
drivers/mfd/Makefile | 1 +
drivers/mfd/bcm2835-pm.c | 64 ++
drivers/watchdog/bcm2835_wdt.c | 26 +-
include/linux/mfd/bcm2835-pm.h | 13 +++
5 files changed, 88 insertions(+), 17 deletions(-)
create mode 100644 drivers/mfd/bcm2835-pm.c
create mode 100644 include/linux/mfd/bcm2835-pm.h
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 25aac6ee2ab1..95242c2162a2 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -167,6 +167,7 @@ config ARCH_BCM2835
select BCM2835_TIMER
select PINCTRL
select PINCTRL_BCM2835
+ select MFD_CORE
help
This enables support for the Broadcom BCM2835 and BCM2836 SoCs.
This SoC is used in the Raspberry Pi and Roku 2 devices.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 12980a4ad460..ee6fb6af655e 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
obj-$(CONFIG_MFD_SM501)+= sm501.o
obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
+obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o
obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
obj-$(CONFIG_MFD_BD9571MWV)+= bd9571mwv.o
cros_ec_core-objs := cros_ec.o
diff --git a/drivers/mfd/bcm2835-pm.c b/drivers/mfd/bcm2835-pm.c
new file mode 100644
index ..53839e6a81e7
--- /dev/null
+++ b/drivers/mfd/bcm2835-pm.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * PM MFD driver for Broadcom BCM2835
+ *
+ * This driver binds to the PM block and creates the MFD device for
+ * the WDT driver.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static const struct mfd_cell bcm2835_pm_devs[] = {
+ { .name = "bcm2835-wdt" },
+};
+
+static int bcm2835_pm_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct device *dev = >dev;
+ struct bcm2835_pm *pm;
+
+ pm = devm_kzalloc(dev, sizeof(*pm), GFP_KERNEL);
+ if (!pm)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, pm);
+
+ pm->dev = dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pm->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(pm->base))
+ return PTR_ERR(pm->base);
+
+ return devm_mfd_add_devices(dev, -1,
+ bcm2835_pm_devs,
ARRAY_SIZE(bcm2835_pm_devs),
+ NULL, 0, NULL);
+}
+
+static const struct of_device_id bcm2835_pm_of_match[] = {
+ { .compatible = "brcm,bcm2835-pm-wdt", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, bcm2835_pm_of_match);
+
+static struct platform_driver bcm2835_pm_driver = {
+ .probe = bcm2835_pm_probe,
+ .driver = {
+ .name = "bcm2835-pm",
+ .of_match_table = bcm2835_pm_of_match,
+ },
+};
+module_platform_driver(bcm2835_pm_driver);
+
+MODULE_AUTHOR("Eric Anholt ");
+MODULE_DESCRIPTION("Driver for Broadcom BCM2835 PM MFD");
+MODULE_LICENSE("GPL");
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
index ed05514cc2dc..1834524ae373 100644
--- a/drivers/watchdog/bcm2835_wdt.c
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -47,6 +48,8 @@ struct bcm2835_wdt {
spinlock_t lock;
};
+static struct bcm2835_wdt *bcm2835_power_off_wdt;
+
static unsigned int heartbeat;
static bool nowayout = WATCHDOG_NOWAYOUT;
@@ -148,10 +151,7 @@ static struct watchdog_device bcm2835_wdt_wdd = {
*/
static void bcm2835_power_off(void)
{
- struct device_node *np =
- of_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm-wdt");
- struct platform_device *pdev = of_find_device_by_node(np);
- struct bcm2835_wdt *wdt = platform_get_drvdata(pdev);
+ struct bcm2835_wdt *wdt = bcm2835_power_off_wdt;
u32 val;
/*
@@ -169,7 +169,7 @@ static void bcm2835_power_off(void)
static int bcm2835_wdt_probe(struct platform_device *pdev)
{
- struct resource *res;
+ struct bcm2835_pm *pm = dev_get_drvdata(pdev->dev.parent);
struct device *dev = >dev;
struct bcm2835_wdt *wdt;
int err;
@@ -181,10 +181,7 @@ static int bcm2835_wdt_probe(struct platform_device *pdev)
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On 12/12/18 3:37 PM, Jason Gunthorpe wrote: > On Wed, Dec 12, 2018 at 04:53:49PM -0500, Jerome Glisse wrote: >>> Almost, we need some safety around assuming that DMA is complete the >>> page, so the notification would need to go all to way to userspace >>> with something like a file lease notification. It would also need to >>> be backstopped by an IOMMU in the case where the hardware does not / >>> can not stop in-flight DMA. >> >> You can always reprogram the hardware right away it will redirect >> any dma to the crappy page. > > That causes silent data corruption for RDMA users - we can't do that. > > The only way out for current hardware is to forcibly terminate the > RDMA activity somehow (and I'm not even sure this is possible, at > least it would be driver specific) > > Even the IOMMU idea probably doesn't work, I doubt all current > hardware can handle a PCI-E error TLP properly. Very true. > > On some hardware it probably just protects DAX by causing data > corruption for RDMA - I fail to see how that is a win for system > stability if the user obviously wants to use DAX and RDMA together... > > I think your approach with ODP only is the only one that meets your > requirements, the only other data-integrity-preserving approach is to > block/fail ftruncate/etc. > >> From my point of view driver should listen to ftruncate before the >> mmu notifier kicks in and send event to userspace and maybe wait >> and block ftruncate (or move it to a worker thread). > > We can do this, but we can't guarantee forward progress in userspace > and the best way we have to cancel that is portable to all RDMA > hardware is to kill the process(es).. > > So if that is acceptable then we could use user notifiers and allow > non-ODP users... > That is exactly the conclusion that some of us in the GPU world reached as well, when chatting about how this would have to work, even on modern GPU hardware that can replay page faults, in many cases. I think as long as we specify that the acceptable consequence of doing, say, umount on a filesystem that has active DMA happening is that the associated processes get killed, then we're going to be OK. What would worry me is if there was an expectation that processes could continue working properly after such a scenario. thanks, -- John Hubbard NVIDIA
Re: [PATCH 4.19 096/139] ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops
Hello, On Tue, Dec 04, 2018 at 11:49:37AM +0100, Greg Kroah-Hartman wrote: > 4.19-stable review patch. If anyone has any objections, please let me > know. > > -- > > From: Hui Wang > > commit c4cfcf6f4297c9256b53790bacbbbd6901fef468 upstream. > > We have several Lenovo laptops with the codec alc285, when playing > sound via headphone, we can hear click/pop noise in the headphone, if > we let the headphone share the DAC of NID 0x2 with the speaker, the > noise disappears. > > The Lenovo laptops here include P52, P72, X1 yoda2 and X1 carbon. [...] on a current Thinkpad X1 Yoga, this breaks the LED functionality on the audio- and mic-mute buttons. While the buttons still work, the LEDs are permanently off and do not reflect the mute state any more. Reverting this patch restores the LED functionality. Here, even without this patch, there is no click/pop noise noticeable when using headphones. Regards, Thomas
Re: linux-next: Signed-off-by missing for commits in the bpf-next tree
On Wed, 2018-12-12 at 15:39 -0800, Alexei Starovoitov wrote:
> On Thu, Dec 13, 2018 at 09:48:20AM +1100, Stephen Rothwell wrote:
> > Hi Alexei,
> >
> > On Wed, 12 Dec 2018 12:53:11 -0800 Alexei Starovoitov
> > wrote:
> > >
> > > On Thu, Dec 13, 2018 at 07:32:45AM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > Commits
> > > >
> > > > 3bdc28aa2340 ("selftests/bpf: add btf annotations for
> > > > cgroup_local_storage maps")
> > > > 1dfd1959fed4 ("bpf: add bpffs pretty print for cgroup local storage
> > > > maps")
> > > > 3adc62d9a5be ("bpf: pass struct btf pointer to the map_check_btf()
> > > > callback")
> > > > 9cf3a785dc4c ("selftests/bpf: use __bpf_constant_htons in
> > > > test_prog.c")
> > > >
> > > > are missing a Signed-off-by from their committers.
> > >
> > > the must be a script mistake?
> > >
> > > I clearly see SOBs for all of them.
> >
> > For example:
> >
> > commit 3bdc28aa2340bf1e5af753287b373522bd1c02a9 (bpf-next/master)
> > Author: Roman Gushchin
> > Date: Mon Dec 10 15:43:02 2018 -0800
> >
> > selftests/bpf: add btf annotations for cgroup_local_storage maps
> >
> > Add btf annotations to cgroup local storage maps (per-cpu and shared)
> > in the network packet counting example.
> >
> > Signed-off-by: Roman Gushchin
> > Cc: Alexei Starovoitov
> > Cc: Daniel Borkmann
> > Acked-by: Martin KaFai Lau
> > Signed-off-by: Daniel Borkmann
> >
> > But it was committed by you, not Daniel.
>
> since there were only 4 commits I fixed them up manually.
> But this approach doesn't scale.
> We do rebase our trees when we need to fixup or drop patches and
> at any given point a number of commits will be committed by me
> and another set by Daniel. When we rebase we cannot keep adding
> our SOBs to the other person SOBs.
> Then comes the next rebase and we get to the point of
> double and triple SOBs ?
>
> I think you need to adjust the script to something like:
> SOBs by Daniel | Alexei == commit by Daniel | Alexei
> in bpf and bpf-next trees.
Are you aware of Linus' opinion about rebasing? If not, please have a look
at https://lkml.org/lkml/2016/3/26/71 or https://lwn.net/Articles/328436/.
Thanks,
Bart.
Re: [PATCH 0/5] security: remove needless usage of module header
On Sun, 9 Dec 2018, Paul Gortmaker wrote: > Paul Gortmaker (5): > security: audit and remove any unnecessary uses of module.h > keys: remove needless modular infrastructure from ecryptfs_format > security: fs: make inode explicitly non-modular > security: integrity: make evm_main explicitly non-modular > security: integrity: make ima_main explicitly non-modular All applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general and next-general -- James Morris
Re: [PATCH 2/5] ARC: perf: introduce Kernel PMU events support
On 12/5/18 9:06 AM, Eugeniy Paltsev wrote:
> Export all available ARC architected hardware events as
> kernel PMU events to make non-generic events accessible.
>
> ARC PMU HW allow us to read the list of all available
> events names. So we generate kernel PMU event list
> dynamically in arc_pmu_device_probe() using
> human-readable events names we got from HW instead of
> using pre-defined events list.
>
> -->8--
> $ perf list
> [snip]
> arc_pmu/bdata64/ [Kernel PMU event]
> arc_pmu/bdcstall/ [Kernel PMU event]
> arc_pmu/bdslot/ [Kernel PMU event]
> arc_pmu/bfbmp/[Kernel PMU event]
> arc_pmu/bfirqex/ [Kernel PMU event]
> arc_pmu/bflgstal/ [Kernel PMU event]
> arc_pmu/bflush/ [Kernel PMU event]
> -->8--
@Peter do you have any comments on this patch. I'd really like to have this
upstream for next release, so any thoughts you have are more than welcome.
-Vineet
> Signed-off-by: Eugeniy Paltsev
> ---
> arch/arc/kernel/perf_event.c | 107
> ++-
> 1 file changed, 106 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c
> index 811a07a2ca21..97b88b00c418 100644
> --- a/arch/arc/kernel/perf_event.c
> +++ b/arch/arc/kernel/perf_event.c
> @@ -22,12 +22,28 @@
> /* HW holds 8 symbols + one for null terminator */
> #define ARCPMU_EVENT_NAME_LEN9
>
> +enum arc_pmu_attr_groups {
> + ARCPMU_ATTR_GR_EVENTS,
> + ARCPMU_ATTR_GR_FORMATS,
> + ARCPMU_NR_ATTR_GR
> +};
> +
> +struct arc_pmu_raw_event_entry {
> + char name[ARCPMU_EVENT_NAME_LEN];
> +};
> +
> struct arc_pmu {
> struct pmu pmu;
> unsigned intirq;
> int n_counters;
> + int n_events;
> u64 max_period;
> int ev_hw_idx[PERF_COUNT_ARC_HW_MAX];
> +
> + struct arc_pmu_raw_event_entry *raw_entry;
> + struct attribute**attrs;
> + struct perf_pmu_events_attr *attr;
> + const struct attribute_group*attr_groups[ARCPMU_NR_ATTR_GR + 1];
> };
>
> struct arc_pmu_cpu {
> @@ -196,6 +212,17 @@ static int arc_pmu_event_init(struct perf_event *event)
>(int)hwc->config, arc_pmu_ev_hw_map[ret]);
> return 0;
>
> + case PERF_TYPE_RAW:
> + if (event->attr.config >= arc_pmu->n_events)
> + return -ENOENT;
> +
> + hwc->config |= event->attr.config;
> + pr_debug("init raw event with idx %lld \'%s\'\n",
> + event->attr.config,
> + arc_pmu->raw_entry[event->attr.config].name);
> +
> + return 0;
> +
> default:
> return -ENOENT;
> }
> @@ -446,6 +473,68 @@ static void arc_cpu_pmu_irq_init(void *data)
> write_aux_reg(ARC_REG_PCT_INT_ACT, 0x);
> }
>
> +/* Event field occupies the bottom 15 bits of our config field */
> +PMU_FORMAT_ATTR(event, "config:0-14");
> +static struct attribute *arc_pmu_format_attrs[] = {
> + _attr_event.attr,
> + NULL,
> +};
> +
> +static struct attribute_group arc_pmu_format_attr_gr = {
> + .name = "format",
> + .attrs = arc_pmu_format_attrs,
> +};
> +
> +static ssize_t
> +arc_pmu_events_sysfs_show(struct device *dev,
> + struct device_attribute *attr, char *page)
> +{
> + struct perf_pmu_events_attr *pmu_attr;
> +
> + pmu_attr = container_of(attr, struct perf_pmu_events_attr, attr);
> + return sprintf(page, "event=0x%04llx\n", pmu_attr->id);
> +}
> +
> +/*
> + * We don't add attrs here as we don't have pre-defined list of perf events.
> + * We will generate and add attrs dynamically in probe() after we read HW
> + * configuration.
> + */
> +static struct attribute_group arc_pmu_events_attr_gr = {
> + .name = "events",
> +};
> +
> +static void arc_pmu_add_raw_event_attr(int j, char *str)
> +{
> + memmove(arc_pmu->raw_entry[j].name, str, ARCPMU_EVENT_NAME_LEN - 1);
> + arc_pmu->attr[j].attr.attr.name = arc_pmu->raw_entry[j].name;
> + arc_pmu->attr[j].attr.attr.mode = VERIFY_OCTAL_PERMISSIONS(0444);
> + arc_pmu->attr[j].attr.show = arc_pmu_events_sysfs_show;
> + arc_pmu->attr[j].id = j;
> + arc_pmu->attrs[j] = &(arc_pmu->attr[j].attr.attr);
> +}
> +
> +static int arc_pmu_raw_alloc(struct device *dev)
> +{
> + arc_pmu->attr = devm_kmalloc_array(dev, arc_pmu->n_events + 1,
> + sizeof(struct perf_pmu_events_attr), GFP_KERNEL | __GFP_ZERO);
> + if (!arc_pmu->attr)
> + return -ENOMEM;
> +
> + arc_pmu->attrs = devm_kmalloc_array(dev, arc_pmu->n_events + 1,
> + sizeof(*arc_pmu->attrs), GFP_KERNEL | __GFP_ZERO);
> + if (!arc_pmu->attrs)
> + return -ENOMEM;
> +
Re: [PATCH v2 0/3] ntb_hw_switchtec: Added support of >=4G memory windows
On 2018-12-12 4:00 p.m., Jon Mason wrote: > So, you based your patches on a series of patches not in the > ntb/ntb-next branch? Please don't do this. I see nothing in these > patches which requires that series, which makes this even more > unnecessary. Since these are fairly trivial, I'm taking them and > pushing to the ntb-next branch to give these more time to be tested > (due to not being tested on the proper branch). I would really > appreciate you testing the ntb-next branch as a sanity check. The NTB test tools don't work with switchtec hardware without that patch set, so there's no way to test the changes without that branch. You're right that there is no compile-time dependency. Logan
Re: [v6, PATCH 0/2] add Ethernet driver support for mt2712
From: David Miller Date: Wed, 12 Dec 2018 15:21:14 -0800 (PST) > From: Biao Huang > Date: Wed, 12 Dec 2018 17:35:30 +0800 > >> Changes in v6: >> modifications according to comments from Rob/Andrew/Sean: >> 1. use delay_ps instead of delay stage. >> 2. add comments in driver to avoid confusion. >> 2. rewrite set_delay function. >> 3. modify binding document for properties: tx-delay-ps/rx-delay-ps/pericfg >> etc. > > Series applied to net-next, thank you. Please send me a follow-up patch to fix this: WARNING: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.o Thank you.
Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
On Wed, 12 Dec 2018, Florian Weimer wrote: > * James Morris: > > > If you're depending on the script interpreter to flag that the user may > > execute code, this seems to be equivalent in security terms to depending > > on the user. e.g. what if the user uses ptrace and clears O_MAYEXEC? > > The argument I've heard is this: Using ptrace (and adding the +x > attribute) are auditable events. I guess you could also preload a modified libc which strips the flag. -- James Morris
Re: [PATCH v2 2/4] modules: Add new special vfree flags
> On Dec 11, 2018, at 4:03 PM, Rick Edgecombe > wrote: > > Add new flags for handling freeing of special permissioned memory in vmalloc, > and remove places where the handling was done in module.c. > > This will enable this flag for all architectures. > > Signed-off-by: Rick Edgecombe > --- > kernel/module.c | 43 --- > 1 file changed, 12 insertions(+), 31 deletions(-) > I count on you for merging your patch-set with mine, since clearly they conflict.
Re: [PATCH] debugobjects: Move printk out of db lock critical sections
On Wed, 12 Dec 2018 17:28:14 -0500 Waiman Long wrote:
> The db->lock is a raw spinlock and so the lock hold time is supposed
> to be short. This will not be the case when printk() is being involved
> in some of the critical sections. In order to avoid the long hold time,
> in case some messages need to be printed, the debug_object_is_on_stack()
> and debug_print_object() calls are now moved out of those critical
> sections.
>
> Holding the db->lock while calling printk() may lead to deadlock if
> printk() somehow requires the allocation/freeing of debug object that
> happens to be in the same hash bucket or a circular lock dependency
> warning from lockdep as reported in https://lkml.org/lkml/2018/12/11/143.
>
> [ 87.209665] WARNING: possible circular locking dependency detected
> [ 87.210547] 4.20.0-rc4-00057-gc96cf92 #1 Tainted: GW
> [ 87.211449] --
> [ 87.212405] getty/519 is trying to acquire lock:
> [ 87.213074] (ptrval) (_hash[i].lock){-.-.}, at:
> debug_check_no_obj_freed+0xb4/0x302
> [ 87.214343]
> [ 87.214343] but task is already holding lock:
> [ 87.215174] (ptrval) (_lock_key){-.-.}, at:
> uart_shutdown+0x3a3/0x4e2
> [ 87.216260]
> [ 87.216260] which lock already depends on the new lock.
>
> This patch was also found to be able to fix a boot hanging problem
> when the initramfs image was switched on after a debugobjects splat
> from the EFI code.
Patch looks sensible, but I have a nit about the variable names.
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -375,6 +375,8 @@ static void debug_object_is_on_stack(void *addr, int
> onstack)
> struct debug_bucket *db;
> struct debug_obj *obj;
> unsigned long flags;
> + bool debug_printobj = false;
"debug_printobject" would be better, but this code already intermingles
"obj" and "object".
> + bool debug_chkstack = false;
Not so good. Is it debug_chkstack or debug_checkstk or ...
This file uses "check" consistently so let's not depart from that?
Linux style is to avoid these tricky little abbreviations and to use
full words.
ie, debug_checkstack, please. Better would be debug_check_stack. Or
simply check_stack: the "debug" doesn't add anything useful.
Re: linux-next: Signed-off-by missing for commits in the bpf-next tree
On Thu, Dec 13, 2018 at 09:48:20AM +1100, Stephen Rothwell wrote:
> Hi Alexei,
>
> On Wed, 12 Dec 2018 12:53:11 -0800 Alexei Starovoitov
> wrote:
> >
> > On Thu, Dec 13, 2018 at 07:32:45AM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Commits
> > >
> > > 3bdc28aa2340 ("selftests/bpf: add btf annotations for
> > > cgroup_local_storage maps")
> > > 1dfd1959fed4 ("bpf: add bpffs pretty print for cgroup local storage
> > > maps")
> > > 3adc62d9a5be ("bpf: pass struct btf pointer to the map_check_btf()
> > > callback")
> > > 9cf3a785dc4c ("selftests/bpf: use __bpf_constant_htons in test_prog.c")
> > >
> > > are missing a Signed-off-by from their committers.
> >
> > the must be a script mistake?
> >
> > I clearly see SOBs for all of them.
>
> For example:
>
> commit 3bdc28aa2340bf1e5af753287b373522bd1c02a9 (bpf-next/master)
> Author: Roman Gushchin
> Date: Mon Dec 10 15:43:02 2018 -0800
>
> selftests/bpf: add btf annotations for cgroup_local_storage maps
>
> Add btf annotations to cgroup local storage maps (per-cpu and shared)
> in the network packet counting example.
>
> Signed-off-by: Roman Gushchin
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Acked-by: Martin KaFai Lau
> Signed-off-by: Daniel Borkmann
>
> But it was committed by you, not Daniel.
since there were only 4 commits I fixed them up manually.
But this approach doesn't scale.
We do rebase our trees when we need to fixup or drop patches and
at any given point a number of commits will be committed by me
and another set by Daniel. When we rebase we cannot keep adding
our SOBs to the other person SOBs.
Then comes the next rebase and we get to the point of
double and triple SOBs ?
I think you need to adjust the script to something like:
SOBs by Daniel | Alexei == commit by Daniel | Alexei
in bpf and bpf-next trees.
Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions
On Wed, Dec 12, 2018 at 04:53:49PM -0500, Jerome Glisse wrote: > > Almost, we need some safety around assuming that DMA is complete the > > page, so the notification would need to go all to way to userspace > > with something like a file lease notification. It would also need to > > be backstopped by an IOMMU in the case where the hardware does not / > > can not stop in-flight DMA. > > You can always reprogram the hardware right away it will redirect > any dma to the crappy page. That causes silent data corruption for RDMA users - we can't do that. The only way out for current hardware is to forcibly terminate the RDMA activity somehow (and I'm not even sure this is possible, at least it would be driver specific) Even the IOMMU idea probably doesn't work, I doubt all current hardware can handle a PCI-E error TLP properly. On some hardware it probably just protects DAX by causing data corruption for RDMA - I fail to see how that is a win for system stability if the user obviously wants to use DAX and RDMA together... I think your approach with ODP only is the only one that meets your requirements, the only other data-integrity-preserving approach is to block/fail ftruncate/etc. > From my point of view driver should listen to ftruncate before the > mmu notifier kicks in and send event to userspace and maybe wait > and block ftruncate (or move it to a worker thread). We can do this, but we can't guarantee forward progress in userspace and the best way we have to cancel that is portable to all RDMA hardware is to kill the process(es).. So if that is acceptable then we could use user notifiers and allow non-ODP users... Jason
Re: [PATCH net V2 0/4] Fix various issue of vhost
From: Jason Wang Date: Wed, 12 Dec 2018 18:08:15 +0800 > This series tries to fix various issues of vhost: > > - Patch 1 adds a missing write barrier between used idx updating and > logging. > - Patch 2-3 brings back the protection of device IOTLB through vq > mutex, this fixes possible use after free in device IOTLB entries. > - Patch 4-7 fixes the diry page logging when device IOTLB is > enabled. We should done through GPA instead of GIOVA, this was done > through intorudce HVA->GPA reverse mapping and convert HVA to GPA > during logging dirty pages. > > Please consider them for -stable. > > Thanks > > Changes from V1: > - silent compiler warning for 32bit. > - use mutex_trylock() on slowpath instead of mutex_lock() even on fast > path. Hello Jason. Look like Michael wants you to split out patch #4 and target net-next with it. So please do that and respin the first 3 patches here with Michael's ACKs. Thanks.
Re: [PATCH 4/5] netfilter: fix missed NULL check in nf_conntrack_proto_pernet_init()
On Wed, Dec 05, 2018 at 08:56:29PM +0800, Yafang Shao wrote: > nf_ct_l4proto_net() may return NULL. > That may happens if some module forget to set both l4proto->get_net_proto > and l4proto->net_id. > We'd check the return value here, in case crash happens. > > Signed-off-by: Yafang Shao > --- > net/netfilter/nf_conntrack_proto.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/netfilter/nf_conntrack_proto.c > b/net/netfilter/nf_conntrack_proto.c > index 154e8c0..316fef3 100644 > --- a/net/netfilter/nf_conntrack_proto.c > +++ b/net/netfilter/nf_conntrack_proto.c > @@ -946,6 +946,9 @@ int nf_conntrack_proto_pernet_init(struct net *net) > struct nf_proto_net *pn = nf_ct_l4proto_net(net, > _conntrack_l4proto_generic); There is another spot missing in this file that is missing the check for NULL. We can probably simplify all this is we place the gre conntracker in the conntrack core, as it's been suggested already. It's the only one remaining as a module and it now supports for IPv6, so it's probably better follow that path.
Re: [v6, PATCH 0/2] add Ethernet driver support for mt2712
From: Biao Huang Date: Wed, 12 Dec 2018 17:35:30 +0800 > Changes in v6: > modifications according to comments from Rob/Andrew/Sean: > 1. use delay_ps instead of delay stage. > 2. add comments in driver to avoid confusion. > 2. rewrite set_delay function. > 3. modify binding document for properties: tx-delay-ps/rx-delay-ps/pericfg > etc. Series applied to net-next, thank you.
Re: [PATCH v6 05/13] KVM: nVMX: implement enlightened VMPTRLD and VMCLEAR
On Tue, Oct 16, 2018 at 9:50 AM Vitaly Kuznetsov wrote:
>
> Per Hyper-V TLFS 5.0b:
>
> "The L1 hypervisor may choose to use enlightened VMCSs by writing 1 to
> the corresponding field in the VP assist page (see section 7.8.7).
> Another field in the VP assist page controls the currently active
> enlightened VMCS. Each enlightened VMCS is exactly one page (4 KB) in
> size and must be initially zeroed. No VMPTRLD instruction must be
> executed to make an enlightened VMCS active or current.
>
> After the L1 hypervisor performs a VM entry with an enlightened VMCS,
> the VMCS is considered active on the processor. An enlightened VMCS
> can only be active on a single processor at the same time. The L1
> hypervisor can execute a VMCLEAR instruction to transition an
> enlightened VMCS from the active to the non-active state. Any VMREAD
> or VMWRITE instructions while an enlightened VMCS is active is
> unsupported and can result in unexpected behavior."
>
> Keep Enlightened VMCS structure for the current L2 guest permanently mapped
> from struct nested_vmx instead of mapping it every time.
>
> Suggested-by: Ladi Prosek
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/vmx.c | 115 ++---
> 1 file changed, 108 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index aebd008b..cfb44acd4291 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -20,6 +20,7 @@
> #include "mmu.h"
> #include "cpuid.h"
> #include "lapic.h"
> +#include "hyperv.h"
>
> #include
> #include
> @@ -889,6 +890,8 @@ struct nested_vmx {
> bool guest_mode;
> } smm;
>
> + gpa_t hv_evmcs_vmptr;
> + struct page *hv_evmcs_page;
> struct hv_enlightened_vmcs *hv_evmcs;
> };
>
> @@ -8111,11 +8114,13 @@ static int nested_vmx_failInvalid(struct kvm_vcpu
> *vcpu)
> static int nested_vmx_failValid(struct kvm_vcpu *vcpu,
> u32 vm_instruction_error)
> {
> + struct vcpu_vmx *vmx = to_vmx(vcpu);
> +
> /*
> * failValid writes the error number to the current VMCS, which
> * can't be done if there isn't a current VMCS.
> */
> - if (to_vmx(vcpu)->nested.current_vmptr == -1ull)
> + if (vmx->nested.current_vmptr == -1ull && !vmx->nested.hv_evmcs)
> return nested_vmx_failInvalid(vcpu);
>
> vmx_set_rflags(vcpu, (vmx_get_rflags(vcpu)
> @@ -8441,6 +8446,20 @@ static void vmx_disable_shadow_vmcs(struct vcpu_vmx
> *vmx)
> vmcs_write64(VMCS_LINK_POINTER, -1ull);
> }
>
> +static inline void nested_release_evmcs(struct kvm_vcpu *vcpu)
> +{
> + struct vcpu_vmx *vmx = to_vmx(vcpu);
> +
> + if (!vmx->nested.hv_evmcs)
> + return;
> +
> + kunmap(vmx->nested.hv_evmcs_page);
> + kvm_release_page_dirty(vmx->nested.hv_evmcs_page);
> + vmx->nested.hv_evmcs_vmptr = -1ull;
> + vmx->nested.hv_evmcs_page = NULL;
> + vmx->nested.hv_evmcs = NULL;
> +}
> +
> static inline void nested_release_vmcs12(struct kvm_vcpu *vcpu)
> {
> struct vcpu_vmx *vmx = to_vmx(vcpu);
> @@ -8509,6 +8528,8 @@ static void free_nested(struct kvm_vcpu *vcpu)
>
> kvm_mmu_free_roots(vcpu, >arch.guest_mmu, KVM_MMU_ROOTS_ALL);
>
> + nested_release_evmcs(vcpu);
> +
> free_loaded_vmcs(>nested.vmcs02);
> }
>
> @@ -8542,12 +8563,18 @@ static int handle_vmclear(struct kvm_vcpu *vcpu)
> return nested_vmx_failValid(vcpu,
> VMXERR_VMCLEAR_VMXON_POINTER);
>
> - if (vmptr == vmx->nested.current_vmptr)
> - nested_release_vmcs12(vcpu);
> + if (vmx->nested.hv_evmcs_page) {
> + if (vmptr == vmx->nested.hv_evmcs_vmptr)
> + nested_release_evmcs(vcpu);
> + } else {
> + if (vmptr == vmx->nested.current_vmptr)
> + nested_release_vmcs12(vcpu);
>
> - kvm_vcpu_write_guest(vcpu,
> - vmptr + offsetof(struct vmcs12, launch_state),
> - , sizeof(zero));
> + kvm_vcpu_write_guest(vcpu,
> +vmptr + offsetof(struct vmcs12,
> + launch_state),
> +, sizeof(zero));
> + }
>
> return nested_vmx_succeed(vcpu);
> }
> @@ -8637,6 +8664,8 @@ static int copy_enlightened_to_vmcs12(struct vcpu_vmx
> *vmx)
> struct vmcs12 *vmcs12 = vmx->nested.cached_vmcs12;
> struct hv_enlightened_vmcs *evmcs = vmx->nested.hv_evmcs;
>
> + vmcs12->hdr.revision_id = evmcs->revision_id;
> +
> /* HV_VMX_ENLIGHTENED_CLEAN_FIELD_NONE */
> vmcs12->tpr_threshold = evmcs->tpr_threshold;
> vmcs12->guest_rip = evmcs->guest_rip;
> @@ -9268,6 +9297,10 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
> return nested_vmx_failValid(vcpu,
>
[GIT PULL] seccomp updates for next
Hi James, Please pull these seccomp changes for next. Thanks! -Kees The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad: Linux 4.20-rc2 (2018-11-11 17:12:31 -0600) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next for you to fetch changes up to fec7b6690541b8128663a13c9586b1daf42b0a6c: samples: add an example of seccomp user trap (2018-12-11 16:32:11 -0800) Add SECCOMP_RET_USER_NOTIF Tycho Andersen (4): seccomp: hoist struct seccomp_data recalculation higher seccomp: switch system call argument type to void * seccomp: add a return code to trap to userspace samples: add an example of seccomp user trap Documentation/ioctl/ioctl-number.txt | 1 + Documentation/userspace-api/seccomp_filter.rst | 84 + include/linux/seccomp.h| 9 +- include/linux/syscalls.h | 2 +- include/uapi/linux/seccomp.h | 40 ++- kernel/seccomp.c | 468 - samples/seccomp/.gitignore | 1 + samples/seccomp/Makefile | 7 +- samples/seccomp/user-trap.c| 375 tools/testing/selftests/seccomp/seccomp_bpf.c | 447 ++- 10 files changed, 1411 insertions(+), 23 deletions(-) create mode 100644 samples/seccomp/user-trap.c -- Kees Cook
Re: [PATCH AUTOSEL 4.19 104/123] pstore/ram: Correctly calculate usable PRZ bytes
On Wed, Dec 05, 2018 at 02:57:08PM -0800, Kees Cook wrote:
On Wed, Dec 5, 2018 at 1:41 AM Sasha Levin wrote:
From: Kees Cook
[ Upstream commit 89d328f637b9904b6d4c9af73c8a608b8dd4d6f8 ]
The actual number of bytes stored in a PRZ is smaller than the
bytes requested by platform data, since there is a header on each
PRZ. Additionally, if ECC is enabled, there are trailing bytes used
as well. Normally this mismatch doesn't matter since PRZs are circular
buffers and the leading "overflow" bytes are just thrown away. However, in
the case of a compressed record, this rather badly corrupts the results.
This corruption was visible with "ramoops.mem_size=204800 ramoops.ecc=1".
Any stored crashes would not be uncompressable (producing a pstorefs
"dmesg-*.enc.z" file), and triggering errors at boot:
[2.790759] pstore: crypto_comp_decompress failed, ret = -22!
Backporting this depends on commit 70ad35db3321 ("pstore: Convert console
write to use ->write_buf")
Please note the above. If this gets backported, this one is needed too.
Okay, I've added 70ad35db3321 for 4.9, 4.4, and 3.18.
--
Thanks,
Sasha
RE: rcu_preempt caused oom
I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the
latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu.
Please correct me if I have something wrong.
-Original Message-
From: Paul E. McKenney
Sent: Thursday, December 13, 2018 5:03 AM
To: He, Bo
Cc: Steven Rostedt ; linux-kernel@vger.kernel.org;
j...@joshtriplett.org; mathieu.desnoy...@efficios.com; jiangshan...@gmail.com;
Zhang, Jun ; Xiao, Jin ; Zhang, Yanmin
; Bai, Jie A
Subject: Re: rcu_preempt caused oom
On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote:
> On Wed, Dec 12, 2018 at 01:21:33PM +, He, Bo wrote:
> > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads()
> > dump logs, it seems the patch can't catch the scenario.
> > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's
> > extracted from the /proc/config.gz.
>
> Strange.
>
> Are the systems responsive to sysrq keys once failure occurs? If so,
> I will provide you a sysrq-R or some such to dump out the RCU state.
Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the
patch below. Only lightly tested.
Thanx, Paul
commit adfc7dff659495a3433d5084256be59eee0ac6df
Author: Paul E. McKenney
Date: Mon Dec 10 16:33:59 2018 -0800
rcu: Improve diagnostics for failed RCU grace-period start
Backported from v4.21/v5.0
If a grace period fails to start (for example, because you commented
out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core()
will invoke rcu_check_gp_start_stall(), which will notice and complain.
However, this complaint is lacking crucial debugging information such
as when the last wakeup executed and what the value of ->gp_seq was at
that time. This commit therefore removes the current pr_alert() from
rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(),
which has been updated to print the needed information, which is collected
by rcu_gp_kthread_wake().
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index
0b760c1369f7..4bcd8753e293 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void)
}
EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state);
+/*
+ * Convert a ->gp_state value to a character string.
+ */
+static const char *gp_state_getname(short gs) {
+ if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names))
+ return "???";
+ return gp_state_names[gs];
+}
+
+/*
+ * Return the root node of the specified rcu_state structure.
+ */
+static struct rcu_node *rcu_get_root(struct rcu_state *rsp) {
+ return >node[0];
+}
+
/*
* Show the state of the grace-period kthreads.
*/
void show_rcu_gp_kthreads(void)
{
int cpu;
+ unsigned long j;
+ unsigned long ja;
+ unsigned long jr;
+ unsigned long jw;
struct rcu_data *rdp;
struct rcu_node *rnp;
struct rcu_state *rsp;
+ j = jiffies;
for_each_rcu_flavor(rsp) {
- pr_info("%s: wait state: %d ->state: %#lx\n",
- rsp->name, rsp->gp_state, rsp->gp_kthread->state);
+ ja = j - READ_ONCE(rsp->gp_activity);
+ jr = j - READ_ONCE(rsp->gp_req_activity);
+ jw = j - READ_ONCE(rsp->gp_wake_time);
+ pr_info("%s: wait state: %s(%d) ->state: %#lx delta
->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld
->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n",
+ rsp->name, gp_state_getname(rsp->gp_state),
+ rsp->gp_state,
+ rsp->gp_kthread ? rsp->gp_kthread->state : 0x1L,
+ ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq),
+ (long)READ_ONCE(rsp->gp_seq),
+ (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed),
+ READ_ONCE(rsp->gp_flags));
rcu_for_each_node_breadth_first(rsp, rnp) {
if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed))
continue;
- pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed
%lu\n",
- rnp->grplo, rnp->grphi, rnp->gp_seq,
- rnp->gp_seq_needed);
+ pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed
%ld\n",
+ rnp->grplo, rnp->grphi, (long)rnp->gp_seq,
+ (long)rnp->gp_seq_needed);
if (!rcu_is_leaf_node(rnp))
continue;
for_each_leaf_node_possible_cpu(rnp, cpu) { @@ -653,8
+685,8 @@ void
Re: [PATCH v5 13/25] m68k: add asm/syscall.h
Hi Geert,
On Wed, Dec 12, 2018 at 04:07:11PM +0300, Dmitry V. Levin wrote:
> On Wed, Dec 12, 2018 at 01:54:05PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 12, 2018 at 1:37 PM Dmitry V. Levin wrote:
> > > On Wed, Dec 12, 2018 at 01:27:14PM +0100, Geert Uytterhoeven wrote:
> > > > On Wed, Dec 12, 2018 at 1:04 PM Dmitry V. Levin
> > > > wrote:
> > > > > On Wed, Dec 12, 2018 at 10:43:33AM +0100, Geert Uytterhoeven wrote:
> > > > > > On Wed, Dec 12, 2018 at 10:27 AM Dmitry V. Levin
> > > > > > wrote:
> > > > > > > On Wed, Dec 12, 2018 at 10:01:29AM +0100, Geert Uytterhoeven
> > > > > > > wrote:
> > > > > > > > On Wed, Dec 12, 2018 at 9:55 AM Dmitry V. Levin
> > > > > > > > wrote:
> > > > > > > > > On Mon, Dec 10, 2018 at 04:30:25PM +0300, Dmitry V. Levin
> > > > > > > > > wrote:
> > > > > > > > > > On Mon, Dec 10, 2018 at 02:06:28PM +0100, Geert
> > > > > > > > > > Uytterhoeven wrote:
> > > > > > > > > > > On Mon, Dec 10, 2018 at 1:41 PM Dmitry V. Levin
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Mon, Dec 10, 2018 at 09:45:42AM +0100, Geert
> > > > > > > > > > > > Uytterhoeven wrote:
> > > > > > > > > > > > > On Mon, Dec 10, 2018 at 5:30 AM Dmitry V. Levin
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > syscall_get_* functions are required to be
> > > > > > > > > > > > > > implemented on all
> > > > > > > > > > > > > > architectures in order to extend the generic ptrace
> > > > > > > > > > > > > > API with
> > > > > > > > > > > > > > PTRACE_GET_SYSCALL_INFO request.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This introduces asm/syscall.h on m68k implementing
> > > > > > > > > > > > > > all 5 syscall_get_*
> > > > > > > > > > > > > > functions as documented in asm-generic/syscall.h:
> > > > > > > > > > > > > > syscall_get_nr,
> > > > > > > > > > > > > > syscall_get_arguments, syscall_get_error,
> > > > > > > > > > > > > > syscall_get_return_value,
> > > > > > > > > > > > > > and syscall_get_arch.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Cc: Geert Uytterhoeven
> > > > > > > > > > > > > > Cc: Oleg Nesterov
> > > > > > > > > > > > > > Cc: Andy Lutomirski
> > > > > > > > > > > > > > Cc: Elvira Khabirova
> > > > > > > > > > > > > > Cc: Eugene Syromyatnikov
> > > > > > > > > > > > > > Cc: linux-m...@lists.linux-m68k.org
> > > > > > > > > > > > > > Signed-off-by: Dmitry V. Levin
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Notes:
> > > > > > > > > > > > > > v5: added syscall_get_nr,
> > > > > > > > > > > > > > syscall_get_arguments, syscall_get_error,
> > > > > > > > > > > > > > and syscall_get_return_value
> > > > > > > > > > > > > > v1: added syscall_get_arch
> > > > > > > > > > > > >
> > > > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > > > +++ b/arch/m68k/include/asm/syscall.h
> > > > > > > > > > > > > > @@ -0,0 +1,39 @@
> > > > > > > > > > > > >
> > > > > > > > > > > > > > +static inline void
> > > > > > > > > > > > > > +syscall_get_arguments(struct task_struct *task,
> > > > > > > > > > > > > > struct pt_regs *regs,
> > > > > > > > > > > > > > + unsigned int i, unsigned int
> > > > > > > > > > > > > > n, unsigned long *args)
> > > > > > > > > > > > > > +{
> > > > > > > > > > > > > > + BUG_ON(i + n > 6);
> > > > > > > > > > > > >
> > > > > > > > > > > > > Does this have to crash the kernel?
> > > > > > > > > > > >
> > > > > > > > > > > > This is what most of other architectures do, but we
> > > > > > > > > > > > could choose
> > > > > > > > > > > > a softer approach, e.g. use WARN_ON_ONCE instead.
> > > > > > > > > > > >
> > > > > > > > > > > > > Perhaps you can return an error code instead?
> > > > > > > > > > > >
> > > > > > > > > > > > That would be problematic given the signature of this
> > > > > > > > > > > > function
> > > > > > > > > > > > and the nature of the potential bug which would most
> > > > > > > > > > > > likely be a usage error.
> > > > > > > > > > >
> > > > > > > > > > > Of course to handle that, the function's signature need
> > > > > > > > > > > to be changed.
> > > > > > > > > > > Changing it has the advantage that the error handling can
> > > > > > > > > > > be done at the
> > > > > > > > > > > caller, in common code, instead of duplicating it for all
> > > > > > > > > > > architectures, possibly
> > > > > > > > > > > leading to different semantics.
> > > > > > > > > >
> > > > > > > > > > Given that *all* current users of syscall_get_arguments
> > > > > > > > > > specify i == 0
> > > > > > > > > > (and there is an architecture that has BUG_ON(i)),
> > > > > > > > > > it should be really a usage error to get into situation
> > > > > > > > > > where i + n > 6,
> > > > > > > > > > I wish a BUILD_BUG_ON could be used here instead.
> > > > > > > > > >
> > > > > > > > > > I don't think it worths pushing the change of API just to
> > > > > > > > > > convert
> > > > > > > > > > a "cannot happen" assertion
[PATCH v11 1/3] ALSA: hda: fix front speakers on Huawei MBXP.
This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
https://bugzilla.kernel.org/show_bug.cgi?id=200501
It enables the front speakers on Huawei Matebook X Pro laptops.
These laptops come with Dolby Atmos sound system and these pins
configuration enables the front speakers.
Reviewed-by: Andy Shevchenko
Reviewed-by: Takashi Iwai
Signed-off-by: Ayman Bagabas
---
sound/pci/hda/patch_realtek.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 993d34c141c2..77ee471a67e5 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5490,6 +5490,7 @@ enum {
ALC298_FIXUP_TPT470_DOCK,
ALC255_FIXUP_DUMMY_LINEOUT_VERB,
ALC255_FIXUP_DELL_HEADSET_MIC,
+ ALC256_FIXUP_HUAWEI_MBXP_PINS,
ALC295_FIXUP_HP_X360,
ALC221_FIXUP_HP_HEADSET_MIC,
};
@@ -5761,6 +5762,22 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+ [ALC256_FIXUP_HUAWEI_MBXP_PINS] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ {0x12, 0x90a60130},
+ {0x13, 0x4000},
+ {0x14, 0x90170110},
+ {0x18, 0x41f0},
+ {0x19, 0x04a11040},
+ {0x1a, 0x41f0},
+ {0x1b, 0x90170112},
+ {0x1d, 0x40759a05},
+ {0x1e, 0x41f0},
+ {0x21, 0x04211020},
+ { }
+ },
+ },
[ALC269_FIXUP_ASUS_X101_FUNC] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc269_fixup_x101_headset_mic,
@@ -6591,6 +6608,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
+ SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MBXP",
ALC256_FIXUP_HUAWEI_MBXP_PINS),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ",
ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
#if 0
--
2.19.2
[PATCH v11 2/3] x86: add support for Huawei WMI hotkeys.
This driver adds support for missing hotkeys on some Huawei laptops.
Laptops such as the Matebook X have non functioning hotkeys. Whereas
newer laptops such as the Matebook X Pro come with working hotkeys out
of the box.
Old laptops, such as the Matebook X, report hotkey events through ACPI
device "\WMI0". However, new laptops, such as the Matebook X Pro,
does not have this WMI device.
All the hotkeys on the Matebook X Pro work fine
without this patch except (micmute, wlan, and huawei key). These keys
and the brightness keys report events to "\AMW0" ACPI device. One
problem is that brightness keys on the Matebook X Pro work without this
patch. This results in reporting two brightness key press
events one is captured by ACPI and another by this driver.
A solution would be to check if such event came from the "\AMW0" WMI driver
then skip reporting event. Another solution would be to leave this to
user-space to handle. Which can be achieved by using "hwdb" tables and
remap those keys to "unknown". This solution seems more natural to me
because it leaves the decision to user-space.
Acked-by: Andy Shevchenko
Reviewed-by: Takashi Iwai
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/Kconfig | 17 +++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/huawei-wmi.c | 208 ++
3 files changed, 226 insertions(+)
create mode 100644 drivers/platform/x86/huawei-wmi.c
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 87f70e8f4dd0..45ef4d22f14c 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1292,6 +1292,23 @@ config INTEL_ATOMISP2_PM
To compile this driver as a module, choose M here: the module
will be called intel_atomisp2_pm.
+config HUAWEI_WMI
+ tristate "Huawei WMI hotkeys driver"
+ depends on ACPI_WMI
+ depends on INPUT
+ select INPUT_SPARSEKMAP
+ select LEDS_CLASS
+ select LEDS_TRIGGERS
+ select LEDS_TRIGGER_AUDIO
+ select NEW_LEDS
+ help
+ This driver provides support for Huawei WMI hotkeys.
+ It enables the missing keys and adds support to the micmute
+ LED found on some of these laptops.
+
+ To compile this driver as a module, choose M here: the module
+ will be called huawei-wmi.
+
endif # X86_PLATFORM_DEVICES
config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 39ae94135406..d841c550e3cc 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ACERHDF) += acerhdf.o
obj-$(CONFIG_HP_ACCEL) += hp_accel.o
obj-$(CONFIG_HP_WIRELESS) += hp-wireless.o
obj-$(CONFIG_HP_WMI) += hp-wmi.o
+obj-$(CONFIG_HUAWEI_WMI) += huawei-wmi.o
obj-$(CONFIG_AMILO_RFKILL) += amilo-rfkill.o
obj-$(CONFIG_GPD_POCKET_FAN) += gpd-pocket-fan.o
obj-$(CONFIG_TC1100_WMI) += tc1100-wmi.o
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
new file mode 100644
index ..59872f87b741
--- /dev/null
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Huawei WMI hotkeys
+ *
+ * Copyright (C) 2018 Ayman Bagabas
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Huawei WMI GUIDs
+ */
+#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
+#define AMW0_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+
+#define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100"
+
+struct huawei_wmi_priv {
+ struct input_dev *idev;
+ struct led_classdev cdev;
+ acpi_handle handle;
+ char *acpi_method;
+};
+
+static const struct key_entry huawei_wmi_keymap[] = {
+ { KE_KEY,0x281, { KEY_BRIGHTNESSDOWN } },
+ { KE_KEY,0x282, { KEY_BRIGHTNESSUP } },
+ { KE_KEY,0x284, { KEY_MUTE } },
+ { KE_KEY,0x285, { KEY_VOLUMEDOWN } },
+ { KE_KEY,0x286, { KEY_VOLUMEUP } },
+ { KE_KEY,0x287, { KEY_MICMUTE } },
+ { KE_KEY,0x289, { KEY_WLAN } },
+ // Huawei |M| key
+ { KE_KEY,0x28a, { KEY_CONFIG } },
+ // Keyboard backlight
+ { KE_IGNORE, 0x293, { KEY_KBDILLUMTOGGLE } },
+ { KE_IGNORE, 0x294, { KEY_KBDILLUMUP } },
+ { KE_IGNORE, 0x295, { KEY_KBDILLUMUP } },
+ { KE_END,0 }
+};
+
+static int huawei_wmi_micmute_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct huawei_wmi_priv *priv = dev_get_drvdata(led_cdev->dev->parent);
+ acpi_status status;
+ union acpi_object args[3];
+ struct acpi_object_list arg_list = {
+ .pointer = args,
+ .count = ARRAY_SIZE(args),
+ };
+
+ args[0].type = args[1].type = args[2].type = ACPI_TYPE_INTEGER;
+ args[1].integer.value = 0x04;
+
+ if
[PATCH v11 3/3] ALSA: hda: add support for Huawei WMI micmute LED
Some of Huawei laptops come with a LED in the micmute key. This patch
enables the use of micmute LED for these devices:
1. Matebook X (19e5:3200), (19e5:3201)
2. Matebook X Pro (19e5:3204)
Reviewed-by: Andy Shevchenko
Reviewed-by: Takashi Iwai
Signed-off-by: Ayman Bagabas
---
sound/pci/hda/patch_realtek.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 77ee471a67e5..9766fd249bdf 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5777,6 +5777,8 @@ static const struct hda_fixup alc269_fixups[] = {
{0x21, 0x04211020},
{ }
},
+ .chained = true,
+ .chain_id = ALC255_FIXUP_MIC_MUTE_LED
},
[ALC269_FIXUP_ASUS_X101_FUNC] = {
.type = HDA_FIXUP_FUNC,
@@ -6608,6 +6610,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
+ SND_PCI_QUIRK(0x19e5, 0x3200, "Huawei MBX", ALC255_FIXUP_MIC_MUTE_LED),
+ SND_PCI_QUIRK(0x19e5, 0x3201, "Huawei MBX", ALC255_FIXUP_MIC_MUTE_LED),
SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MBXP",
ALC256_FIXUP_HUAWEI_MBXP_PINS),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ",
ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
--
2.19.2
[PATCH v11 0/3] Huawei laptops
This patch set is based on the new audio LED triggers in topic/leds-trigger branch from git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git Changes in v11: * Minor code changes Changes in v10: * Use ec_get_handle instead of acpi_get_handle since we are using the ec device * Switch to WMI0_EXPENSIVE_GUID and wmi_query_block to fetch keycode when WMI0 is used Changes in v9: * Explicitly use NULL in acpi_get_handle * Drop __initconst from huawei_wmi_keymap Changes in v8: * Switch to wmi_driver * Use devm to allocate and manage devices * Skip registering LED subsystem if a ACPI controller method was not found Changes in v7: * Use audio LED triggers patch set * Use KEY_CONFIG (XF86Tools) instead of KEY_PROG1. In Windows, the key is used to launch Huawei PC manager. XF86Tools is used by default on most desktop environments i.e. Gnome. Changes in v6: * Review tags Changes in v5: * Consistency in file names * How module would be enabled (Kconfig) * Match license in SPDX and MODULE_LICENSE Changes in v4: * Code formatting Changes in v3: * Support for Huawei MBX * Style and formatting issues Ayman Bagabas (3): ALSA: hda: fix front speakers on Huawei MBXP. x86: add support for Huawei WMI hotkeys. ALSA: hda: add support for Huawei WMI micmute LED drivers/platform/x86/Kconfig | 17 +++ drivers/platform/x86/Makefile | 1 + drivers/platform/x86/huawei-wmi.c | 208 ++ sound/pci/hda/patch_realtek.c | 22 4 files changed, 248 insertions(+) create mode 100644 drivers/platform/x86/huawei-wmi.c -- 2.19.2
Re: [PATCH AUTOSEL 4.19 052/123] Btrfs: send, fix infinite loop due to directory rename dependencies
On Thu, Dec 06, 2018 at 06:55:19PM +0100, David Sterba wrote: On Wed, Dec 05, 2018 at 04:34:44AM -0500, Sasha Levin wrote: From: Robbie Ko [ Upstream commit a4390aee72713d9e73f1132bcdeb17d72fbbf974 ] ... Signed-off-by: Robbie Ko Reviewed-by: Filipe Manana [Wrote changelog with example and more clear explanation] Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin Ack for taking this patch to the stable trees. Thanks. Thanks David. -- Thanks, Sasha
RE: intel_pstate: Lowest frequency not reached with Intel i7-6700
On 2018.12.12 13:40 Paul Menzel wrote: > Using *powersave* as P-state selection algorithm, on an idle system Define "idle system". If your computer is running a GUI, or is even a server without a GUI but with many services running, then "idle" really isn't. Below is from my test server, with many services disabled, so "idle" really is quite "idle" doug@s15:~/temp$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt --interval 15 Busy% Bzy_MHz PkgTmp PkgWatt 0.01160827 3.71 0.01161927 3.71 0.01160028 3.71 0.01160028 3.70 Note that p state 16 (1600 MHz) is the minimum for my older i7-2600k processor. > Shouldn’t it go down until 800 MHz? We would need some actual busy information, turbostat is the recommended tool, to know for sure. ... Doug
Re: [PATCH v9 RESEND 0/4] KASLR feature to randomize each loadable module
On Wed, 2018-11-28 at 01:40 +, Edgecombe, Rick P wrote: > On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote: > > On 11/27/2018 01:19 AM, Edgecombe, Rick P wrote: > > > On Mon, 2018-11-26 at 16:36 +0100, Jessica Yu wrote: > > > > +++ Rick Edgecombe [20/11/18 15:23 -0800]: > > > > > > [snip] > > > > Hi Rick! > > > > > > > > Sorry for the delay. I'd like to take a step back and ask some broader > > > > questions - > > > > > > > > - Is the end goal of this patchset to randomize loading kernel modules, > > > > or > > > > most/all > > > >executable kernel memory allocations, including bpf, kprobes, etc? > > > > > > Thanks for taking a look! > > > > > > It started with the goal of just randomizing modules (hence the name), but > > > I > > > think there is maybe value in randomizing the placement of all runtime > > > added > > > executable code. Beyond just trying to make executable code placement less > > > deterministic in general, today all of the usages have the property of > > > starting > > > with RW permissions and then becoming RO executable, so there is the > > > benefit > > > of > > > narrowing the chances a bug could successfully write to it during the RW > > > window. > > > > > > > - It seems that a lot of complexity and heuristics are introduced just > > > > to > > > >accommodate the potential fragmentation that can happen when the > > > > module > > > > vmalloc > > > >space starts to get fragmented with bpf filters. I'm partial to the > > > > idea of > > > >splitting or having bpf own its own vmalloc space, similar to what > > > > Ard > > > > is > > > > already > > > >implementing for arm64. > > > > > > > >So a question for the bpf and x86 folks, is having a dedicated > > > > vmalloc > > > > region > > > >(as well as a seperate bpf_alloc api) for bpf feasible or desirable > > > > on > > > > x86_64? > > > > > > I actually did some prototyping and testing on this. It seems there would > > > be > > > some slowdown from the required changes to the JITed code to support > > > calling > > > back from the vmalloc region into the kernel, and so module space would > > > still be > > > the preferred region. > > > > Yes, any runtime slow-down would be no-go as BPF sits in the middle of > > critical > > networking fast-path and e.g. on XDP or tc layer and is used in load- > > balancing, > > firewalling, DDoS protection scenarios, some recent examples in [0-3]. > > > > [0] http://vger.kernel.org/lpc-networking2018.html#session-10 > > [1] http://vger.kernel.org/lpc-networking2018.html#session-15 > > [2] https://blog.cloudflare.com/how-to-drop-10-million-packets/ > > [3] http://vger.kernel.org/lpc-bpf2018.html#session-1 > > > > > >If bpf filters need to be within 2 GB of the core kernel, would it > > > > make > > > > sense > > > >to carve out a portion of the current module region for bpf > > > > filters? According > > > >to Documentation/x86/x86_64/mm.txt, the module region is ~1.5 GB. I > > > > am > > > > doubtful > > > >that any real system will actually have 1.5 GB worth of kernel > > > > modules > > > > loaded. > > > >Is there a specific reason why that much space is dedicated to kernel > > > > modules, > > > >and would it be feasible to split that region cleanly with bpf? > > > > > > Hopefully someone from BPF side of things will chime in, but my > > > understanding > > > was that they would like even more space than today if possible and so > > > they > > > may > > > not like the reduced space. > > > > I wouldn't mind of the region is split as Jessica suggests but in a way > > where > > there would be _no_ runtime regressions for BPF. This might also allow to > > have > > more flexibility in sizing the area dedicated for BPF in future, and could > > potentially be done in similar way as Ard was proposing recently [4]. > > > > [4] https://patchwork.ozlabs.org/project/netdev/list/?series=9 > > CCing Ard. > > The benefit of sharing the space, for randomization at least, is that you can > spread the allocations over a larger area. > > I think there are also other benefits to unifying how this memory is managed > though, rather than spreading it further. Today there are various patterns and > techniques used like calling different combinations of set_memory_* before > freeing, zeroing in modules or setting invalid instructions like BPF does, > etc. > There is also special care to be taken on vfree-ing executable memory. So this > way things only have to be done right once and there is less duplication. > > Not saying there shouldn't be __weak alloc and free method in BPF for arch > specific behavior, just that there is quite a few other concerns that could be > good to centralize even more than today. > > What if there was a unified executable alloc API with support for things like: > - Concepts of two regions for Ard's usage, near(modules) and far(vmalloc) > from >kernel text. Won't apply for every arch, but
Re: [PATCH v2 0/3] ntb_hw_switchtec: Added support of >=4G memory windows
On Thu, Dec 6, 2018 at 1:47 AM Wesley Sheng wrote: > > Hi, Everyone, > > This patch series adds support of >=4G memory windows. > > Current Switchtec's BAR setup registers are limited to 32bits, > corresponding to the maximum MW (memory window) size is <4G. > Increase the MW sizes with the addition of the BAR Setup Extension > Register for the upper 32bits of a 64bits MW size. This increases the MW > range to between 4K and 2^63. > > Additionally, we've made the following changes: > > * debug print 64bit aligned crosslink BAR numbers > * Fix the array size of NT req id mapping table > > Tested with ntb_test.sh successfully based on NTB fixes series from > Logan Gunthorpe at > https://github.com/sbates130272/linux-p2pmem on branch of > ntb_multiport_fixes So, you based your patches on a series of patches not in the ntb/ntb-next branch? Please don't do this. I see nothing in these patches which requires that series, which makes this even more unnecessary. Since these are fairly trivial, I'm taking them and pushing to the ntb-next branch to give these more time to be tested (due to not being tested on the proper branch). I would really appreciate you testing the ntb-next branch as a sanity check. Thanks, Jon > > Regards, > Wesley > > -- > > Changed since v1: > - Using upper_32_bits() and lower_32_bits() marcos makes it easier > to read and avoids compiler warning on 32-bit arch > - Reorder the patches to make the bug fixes first and add a "Fixes" > line to the commit messages > > -- > Paul Selles (2): > ntb_hw_switchtec: debug print 64bit aligned crosslink BAR Numbers > ntb_hw_switchtec: Added support of >=4G memory windows > > Wesley Sheng (1): > ntb_hw_switchtec: NT req id mapping table register entry number should > be 512 > > drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 11 --- > include/linux/switchtec.h | 10 +++--- > 2 files changed, 15 insertions(+), 6 deletions(-) > > -- > 2.7.4 >
Re: [PATCH 5/5] switchtec: MRPC DMA mode implementation
On 2018-12-12 3:52 p.m., Bjorn Helgaas wrote:
> On Mon, Dec 10, 2018 at 05:12:24PM +0800, Wesley Sheng wrote:
>> MRPC normal mode requires the host to read the MRPC command status and
>> output data from BAR. This results in high latency responses from the
>> Memory Read TLP and potential Completion Timeout (CTO).
>>
>> MRPC DMA mode implementation includes:
>> Macro definitions for registers and data structures corresponding to
>> MRPC DMA mode.
>>
>> Add module parameter use_dma_mrpc to select between MRPC DMA mode and
>> MRPC normal mode.
>>
>> Add MRPC mode functionality to:
>> * Retrieve MRPC DMA mode version
>> * Allocate DMA buffer, ISR registration, and enable DMA function during
>> initialization
>> * Check MRPC execution status and collect execution results from DMA buffer
>> * Release DMA buffer and disable DMA function when unloading module
>>
>> MRPC DMA mode is a new feature of firmware and the driver will fall back
>> to MRPC normal mode if there is no support in the legacy firmware.
>>
>> Include so that readq/writeq is replaced
>> by two readl/writel on systems that do not support it.
>>
>> Signed-off-by: Wesley Sheng
>> Reviewed-by: Logan Gunthorpe
>> ---
>> drivers/pci/switch/switchtec.c | 108
>> +
>> include/linux/switchtec.h | 16 ++
>> 2 files changed, 114 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
>> index 0b8862b..6b726cb 100644
>> --- a/drivers/pci/switch/switchtec.c
>> +++ b/drivers/pci/switch/switchtec.c
>> @@ -13,7 +13,7 @@
>> #include
>> #include
>> #include
>> -
>> +#include
>> #include
>>
>> MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCIe Management Driver");
>> @@ -25,6 +25,11 @@ static int max_devices = 16;
>> module_param(max_devices, int, 0644);
>> MODULE_PARM_DESC(max_devices, "max number of switchtec device instances");
>>
>> +static bool use_dma_mrpc = 1;
>> +module_param(use_dma_mrpc, bool, 0644);
>> +MODULE_PARM_DESC(use_dma_mrpc,
>> + "Enable the use of the DMA MRPC feature");
>
> What's the purpose of the module parameter? Can't you automatically
> figure out whether the firmware supports DMA mode?
>
> Module parameters make life difficult for users and lead to code
> that's rarely used and poorly tested, so I think we should avoid them
> whenever we can.
>
> If you *can't* automatically figure out when to use DMA, please make
> it clear in the changelog that the "use_dma_mrpc" parameter is
> required with legacy firmware. And in that case, it seems like it
> should be named "disable_dma" or similar, since it defaults to being
> enabled.
The code should already automatically determine whether the firmware
supports DMA or not. This parameter is just to aid debugging/testing so
we can run the module without DMA even if the firmware indicates it has
support.
It's not that critical so I'm sure we can remove it at this point if you
don't think that's a good enough justification.
Logan
Re: [PATCH 4.19 014/110] usb: xhci: Prevent bus suspend if a port connect change or polling state is detected
Hello, On Thu, Nov 29, 2018 at 03:11:45PM +0100, Greg Kroah-Hartman wrote: > 4.19-stable review patch. If anyone has any objections, please let me > know. > > -- > > From: Mathias Nyman > > commit 2f31a67f01a8beb22cae754c53522cb61a005750 upstream. [...] on a current Thinkpad X1 Yoga, this breaks resume from hibernate such that opening the lid has (in the regular use case, see below) no effect any more: The system is configured to hibernate when the lid is closed. So, the expected behavior, which is restored by reverting this patch, is: close lid => system hibernates open lid => system resumes With this patch, the following two cases are observed: 1) close lid => system hibernates open lid => system stays off press power button => system boots and resumes 2) # systemctl hibernate => system hibernates close lid open lid => system resumes Regards, Thomas
Re: [PATCH 3/5] switchtec: A temporary variable should be used for the flags of switchtec_ioctl_event_ctl
On 2018-12-12 3:43 p.m., Bjorn Helgaas wrote:
> On Mon, Dec 10, 2018 at 05:12:22PM +0800, Wesley Sheng wrote:
>> From: Joey Zhang
>>
>> For nr_idxs is larger than 1 switchtec_ioctl_event_ctl event flags will be
>> used by each event indexes. In current implementation the event flags are
>> overwritten by first call of the function event_ctl().
>>
>> Preserve the event flag value with a temporary variable.
>>
>> Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
>> Signed-off-by: Joey Zhang
>> Signed-off-by: Wesley Sheng
>> Reviewed-by: Logan Gunthorpe
>> ---
>> drivers/pci/switch/switchtec.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
>> index 480107e..a908670 100644
>> --- a/drivers/pci/switch/switchtec.c
>> +++ b/drivers/pci/switch/switchtec.c
>> @@ -796,6 +796,7 @@ static int ioctl_event_ctl(struct switchtec_dev *stdev,
>> {
>> int ret;
>> int nr_idxs;
>> +unsigned int event_flags;
>> struct switchtec_ioctl_event_ctl ctl;
>>
>> if (copy_from_user(, uctl, sizeof(ctl)))
>> @@ -817,7 +818,9 @@ static int ioctl_event_ctl(struct switchtec_dev *stdev,
>> else
>> return -EINVAL;
>>
>> +event_flags = ctl.flags;
>> for (ctl.index = 0; ctl.index < nr_idxs; ctl.index++) {
>> +ctl.flags = event_flags;
>> ret = event_ctl(stdev, );
>
> event_ctl() overwrites several other things, in addition to ctl.flags:
>
> ctl.data[]
> ctl.occurred
> ctl.count
>
> Is that what you intend? It looks like only the values from the *last*
> call of event_ctl() will be copied back to the user buffer.
Yeah, it's just SWITCHTEC_IOCTL_EVENT_IDX_ALL is perhaps a strange abuse
of the interface. The intention being that if you are querying
information about an event you'd use it's specific index. If you are
trying to set flags you can set them for all event of a specific type at
once using IDX_ALL.
Looking at it now it looks pretty ugly (and I'm not sure what I was
thinking when I wrote it). But it's what we have and this patch fixes a
bug where we aren't actually enabling/disabling all events when that's
what the user is asking for.
Logan
Re: [PATCH 5/5] switchtec: MRPC DMA mode implementation
On Mon, Dec 10, 2018 at 05:12:24PM +0800, Wesley Sheng wrote:
> MRPC normal mode requires the host to read the MRPC command status and
> output data from BAR. This results in high latency responses from the
> Memory Read TLP and potential Completion Timeout (CTO).
>
> MRPC DMA mode implementation includes:
> Macro definitions for registers and data structures corresponding to
> MRPC DMA mode.
>
> Add module parameter use_dma_mrpc to select between MRPC DMA mode and
> MRPC normal mode.
>
> Add MRPC mode functionality to:
> * Retrieve MRPC DMA mode version
> * Allocate DMA buffer, ISR registration, and enable DMA function during
> initialization
> * Check MRPC execution status and collect execution results from DMA buffer
> * Release DMA buffer and disable DMA function when unloading module
>
> MRPC DMA mode is a new feature of firmware and the driver will fall back
> to MRPC normal mode if there is no support in the legacy firmware.
>
> Include so that readq/writeq is replaced
> by two readl/writel on systems that do not support it.
>
> Signed-off-by: Wesley Sheng
> Reviewed-by: Logan Gunthorpe
> ---
> drivers/pci/switch/switchtec.c | 108
> +
> include/linux/switchtec.h | 16 ++
> 2 files changed, 114 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
> index 0b8862b..6b726cb 100644
> --- a/drivers/pci/switch/switchtec.c
> +++ b/drivers/pci/switch/switchtec.c
> @@ -13,7 +13,7 @@
> #include
> #include
> #include
> -
> +#include
> #include
>
> MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCIe Management Driver");
> @@ -25,6 +25,11 @@ static int max_devices = 16;
> module_param(max_devices, int, 0644);
> MODULE_PARM_DESC(max_devices, "max number of switchtec device instances");
>
> +static bool use_dma_mrpc = 1;
> +module_param(use_dma_mrpc, bool, 0644);
> +MODULE_PARM_DESC(use_dma_mrpc,
> + "Enable the use of the DMA MRPC feature");
What's the purpose of the module parameter? Can't you automatically
figure out whether the firmware supports DMA mode?
Module parameters make life difficult for users and lead to code
that's rarely used and poorly tested, so I think we should avoid them
whenever we can.
If you *can't* automatically figure out when to use DMA, please make
it clear in the changelog that the "use_dma_mrpc" parameter is
required with legacy firmware. And in that case, it seems like it
should be named "disable_dma" or similar, since it defaults to being
enabled.
Bjorn
Re: [PATCH] Linux: Implement membarrier function
On Wed, Dec 12, 2018 at 05:12:18PM -0500, Alan Stern wrote: > On Wed, 12 Dec 2018, Paul E. McKenney wrote: > > > > > I believe that this ordering forbids the cycle: > > > > > > > > Wa=1 > membs -> [m01] -> Rc=0 -> Wc=2 -> rcu_read_unlock() -> > > > > return from synchronize_rcu() -> Ra > > > > > > > > Does this make sense, or am I missing something? > > > > > > It's hard to tell. What you have written here isn't justified by the > > > litmus test source code, since the position of m01 in P1's program > > > order is undetermined. How do you justify m01 -> Rc, for example? > > > > ... justifies Rc=0 following [m01]. > > > > > Write it this way instead, using the relations defined in the > > > sys_membarrier patch for linux-kernel.cat: > > > > > > memb ->memb-gp memb ->rcu-link Rc ->memb-rscsi Rc ->rcu-link > > > > > > rcu_read_unlock ->rcu-rscsi rcu_read_lock ->rcu-link > > > > > > synchronize_rcu ->rcu-gp synchronize_rcu ->rcu-link memb > > > > > > Recall that: > > > > > > memb-gp is the identity relation on sys_membarrier events, > > > > > > rcu-link includes (po? ; fre ; po), > > > > > > memb-rscsi is the identity relation on all events, > > > > > > rcu-rscsi links unlocks to their corresponding locks, and > > > > > > rcu-gp is the identity relation on synchronize_rcu events. > > > > > > These facts justify the cycle above. > > > > > > Leaving off the final rcu-link step, the sequence matches the > > > definition of rcu-fence (the relations are memb-gp, memb-rscsi, > > > rcu-rscsi, rcu-gp with rcu-links in between). Therefore the cycle is > > > forbidden. > > > > Understood, but that would be using the model to check the model. ;-) > > Well, what are you trying to accomplish? Do you want to find an > argument similar to the one I posted for the 6-CPU test to show that > this test should be forbidden? I am trying to check odd corner cases. Your sys_membarrier() model is quite nice and certainly fits nicely with the rest of the model, but where I come from, that is actually reason for suspicion. ;-) All kidding aside, your argument for the 6-CPU test was extremely valuable, as it showed me a way to think of that test from an implementation viewpoint. Then the question is whether or not that viewpoint actually matches the model, which seems to be the case thus far. A good next step would be to automatically generate random tests along with an automatically generated prediction, like I did for RCU a few years back. I should be able to generalize my time-based cheat for RCU to also cover SRCU, though sys_membarrier() will require a bit more thought. (The time-based cheat was to have fixed duration RCU grace periods and RCU read-side critical sections, with the grace period duration being slightly longer than that of the critical sections. The number of processes is of course limited by the chosen durations, but that limit can easily be made insanely large.) I guess that I still haven't gotten over being a bit surprised that the RCU counting rule also applies to sys_membarrier(). ;-) Thanx, Paul
Re: linux-next: Signed-off-by missing for commits in the bpf-next tree
Hi Alexei,
On Wed, 12 Dec 2018 12:53:11 -0800 Alexei Starovoitov
wrote:
>
> On Thu, Dec 13, 2018 at 07:32:45AM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Commits
> >
> > 3bdc28aa2340 ("selftests/bpf: add btf annotations for
> > cgroup_local_storage maps")
> > 1dfd1959fed4 ("bpf: add bpffs pretty print for cgroup local storage maps")
> > 3adc62d9a5be ("bpf: pass struct btf pointer to the map_check_btf()
> > callback")
> > 9cf3a785dc4c ("selftests/bpf: use __bpf_constant_htons in test_prog.c")
> >
> > are missing a Signed-off-by from their committers.
>
> the must be a script mistake?
>
> I clearly see SOBs for all of them.
For example:
commit 3bdc28aa2340bf1e5af753287b373522bd1c02a9 (bpf-next/master)
Author: Roman Gushchin
Date: Mon Dec 10 15:43:02 2018 -0800
selftests/bpf: add btf annotations for cgroup_local_storage maps
Add btf annotations to cgroup local storage maps (per-cpu and shared)
in the network packet counting example.
Signed-off-by: Roman Gushchin
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Acked-by: Martin KaFai Lau
Signed-off-by: Daniel Borkmann
But it was committed by you, not Daniel.
--
Cheers,
Stephen Rothwell
pgpxs78t2HBJY.pgp
Description: OpenPGP digital signature
Re: [PATCH] vfio/mdev: add static modifier to add_mdev_supported_type
On Tue, 13 Nov 2018 09:45:43 +0100
Paolo Cretaro wrote:
> Set add_mdev_supported_type as static since it is only used within
> mdev_sysfs.c.
> This fixes -Wmissing-prototypes gcc warning.
>
> Signed-off-by: Paolo Cretaro
> ---
> drivers/vfio/mdev/mdev_sysfs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/mdev/mdev_sysfs.c b/drivers/vfio/mdev/mdev_sysfs.c
> index 249472f05509..ce5dd219f2c8 100644
> --- a/drivers/vfio/mdev/mdev_sysfs.c
> +++ b/drivers/vfio/mdev/mdev_sysfs.c
> @@ -92,8 +92,8 @@ static struct kobj_type mdev_type_ktype = {
> .release = mdev_type_release,
> };
>
> -struct mdev_type *add_mdev_supported_type(struct mdev_parent *parent,
> - struct attribute_group *group)
> +static struct mdev_type *add_mdev_supported_type(struct mdev_parent *parent,
> + struct attribute_group *group)
> {
> struct mdev_type *type;
> int ret;
Applied to vfio next branch with Cornlia's review. Thanks,
Alex
Re: [PATCH 3/5] switchtec: A temporary variable should be used for the flags of switchtec_ioctl_event_ctl
On Mon, Dec 10, 2018 at 05:12:22PM +0800, Wesley Sheng wrote:
> From: Joey Zhang
>
> For nr_idxs is larger than 1 switchtec_ioctl_event_ctl event flags will be
> used by each event indexes. In current implementation the event flags are
> overwritten by first call of the function event_ctl().
>
> Preserve the event flag value with a temporary variable.
>
> Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
> Signed-off-by: Joey Zhang
> Signed-off-by: Wesley Sheng
> Reviewed-by: Logan Gunthorpe
> ---
> drivers/pci/switch/switchtec.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
> index 480107e..a908670 100644
> --- a/drivers/pci/switch/switchtec.c
> +++ b/drivers/pci/switch/switchtec.c
> @@ -796,6 +796,7 @@ static int ioctl_event_ctl(struct switchtec_dev *stdev,
> {
> int ret;
> int nr_idxs;
> + unsigned int event_flags;
> struct switchtec_ioctl_event_ctl ctl;
>
> if (copy_from_user(, uctl, sizeof(ctl)))
> @@ -817,7 +818,9 @@ static int ioctl_event_ctl(struct switchtec_dev *stdev,
> else
> return -EINVAL;
>
> + event_flags = ctl.flags;
> for (ctl.index = 0; ctl.index < nr_idxs; ctl.index++) {
> + ctl.flags = event_flags;
> ret = event_ctl(stdev, );
event_ctl() overwrites several other things, in addition to ctl.flags:
ctl.data[]
ctl.occurred
ctl.count
Is that what you intend? It looks like only the values from the *last*
call of event_ctl() will be copied back to the user buffer.
> if (ret < 0)
> return ret;
> --
> 2.7.4
>
[PATCH RFC] rcu: add sparse check to rcu_assign_pointer
rcu_assign_pointer currently doesn't do any sparse checking on a pointer
assigned. So its possible that a pointer that is not __rcu annotated is
assigned with rcu_assign_pointer without sparse complainting.
rcu_dereference already does such checking so lets also make
rcu_assign_pointer to do the same. The extra error could be helpful in
cases where an RCU pointer is assigned with rcu_assign_pointer but not
annotated with __rcu.
This doesn't generate any code in the normal case because __CHECKER__ is
defined only in the context of sparse.
Also we rename rcu_dereference_sparse to rcu_check_parse since the
checking now happens not only during derereferencing but also during
assignment.
Test: Introduced an rcu_assign_pointer in code and checked the output of
sparse with and without this change. The change correctly causes sparse
to throw an error.
Signed-off-by: Joel Fernandes (Google)
---
include/linux/rcupdate.h | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 4db8bcacc51a..9e6f10da7f26 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -309,16 +309,16 @@ static inline void rcu_preempt_sleep_check(void) { }
*/
#ifdef __CHECKER__
-#define rcu_dereference_sparse(p, space) \
+#define rcu_check_sparse(p, space) \
((void)(((typeof(*p) space *)p) == p))
#else /* #ifdef __CHECKER__ */
-#define rcu_dereference_sparse(p, space)
+#define rcu_check_sparse(p, space)
#endif /* #else #ifdef __CHECKER__ */
#define __rcu_access_pointer(p, space) \
({ \
typeof(*p) *_p1 = (typeof(*p) *__force)READ_ONCE(p); \
- rcu_dereference_sparse(p, space); \
+ rcu_check_sparse(p, space); \
((typeof(*p) __force __kernel *)(_p1)); \
})
#define __rcu_dereference_check(p, c, space) \
@@ -326,13 +326,13 @@ static inline void rcu_preempt_sleep_check(void) { }
/* Dependency order vs. p above. */ \
typeof(*p) *p1 = (typeof(*p) *__force)READ_ONCE(p); \
RCU_LOCKDEP_WARN(!(c), "suspicious rcu_dereference_check() usage"); \
- rcu_dereference_sparse(p, space); \
+ rcu_check_sparse(p, space); \
((typeof(*p) __force __kernel *)(p1)); \
})
#define __rcu_dereference_protected(p, c, space) \
({ \
RCU_LOCKDEP_WARN(!(c), "suspicious rcu_dereference_protected() usage");
\
- rcu_dereference_sparse(p, space); \
+ rcu_check_sparse(p, space); \
((typeof(*p) __force __kernel *)(p)); \
})
#define rcu_dereference_raw(p) \
@@ -382,6 +382,7 @@ static inline void rcu_preempt_sleep_check(void) { }
#define rcu_assign_pointer(p, v) \
({ \
uintptr_t _r_a_p__v = (uintptr_t)(v); \
+ rcu_check_sparse(p, __rcu); \
\
if (__builtin_constant_p(v) && (_r_a_p__v) == (uintptr_t)NULL)\
WRITE_ONCE((p), (typeof(p))(_r_a_p__v)); \
@@ -785,7 +786,7 @@ static inline notrace void
rcu_read_unlock_sched_notrace(void)
*/
#define RCU_INIT_POINTER(p, v) \
do { \
- rcu_dereference_sparse(p, __rcu); \
+ rcu_check_sparse(p, __rcu); \
WRITE_ONCE(p, RCU_INITIALIZER(v)); \
} while (0)
--
2.20.0.rc1.387.gf8505762e3-goog
Re: [PATCH v2] MAINTAINERS: add maintainers for ChromeOS EC sub-drivers
On 11/12/2018 20:09:52+0100, Enric Balletbo i Serra wrote: > There are multiple ChromeOS EC sub-drivers spread in different > subsystems, as all of them are related to the Chrome stuff add > Benson and myself as a maintainers for all these sub-drivers. > > Signed-off-by: Enric Balletbo i Serra You definitively don't need my ack to get that applied but anyway: Acked-by: Alexandre Belloni However, you should probably indicate which tree do you expect that to go through ;) > --- > > Changes in v2: > - Fix typo in Benson email address. > > MAINTAINERS | 24 > 1 file changed, 24 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index a24129b0b043..bbe7180e2851 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3625,6 +3625,30 @@ S: Maintained > T: git > git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git > F: drivers/platform/chrome/ > > +CHROMEOS EC SUBDRIVERS > +M: Benson Leung > +M: Enric Balletbo i Serra > +S: Maintained > +F: Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.txt > +F: Documentation/devicetree/bindings/input/cros-ec-keyb.txt > +F: Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt > +F: Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt > +F: Documentation/devicetree/bindings/mfd/cros-ec.txt > +F: Documentation/ABI/testing/sysfs-bus-iio-cros-ec > +F: drivers/extcon/extcon-usbc-cros-ec.c > +F: drivers/i2c/busses/i2c-cros-ec-tunnel.c > +F: drivers/iio/accel/cros_ec* > +F: drivers/iio/common/cros_ec_sensors/ > +F: drivers/iio/light/cros_ec* > +F: drivers/iio/pressure/cros_ec* > +F: drivers/input/keyboard/cros_ec* > +F: drivers/mfd/cros_ec* > +F: drivers/power/supply/cros_usbpd-charger.c > +F: drivers/pwm/pwm-cros-ec.c > +F: drivers/rtc/rtc-cros-ec.c > +F: include/linux/iio/common/cros_ec_sensors_core.h > +F: include/linux/mfd/cros_ec* > + > CIRRUS LOGIC AUDIO CODEC DRIVERS > M: Brian Austin > M: Paul Handrigan > -- > 2.19.2 > -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v4 3/7] mips: rename macros and files from '64' to 'n64'
Hi Firoz, On Wed, Dec 12, 2018 at 10:04:47AM +0530, Firoz Khan wrote: > > > Will this below change will help? > > > > > > #define _MIPS_SIM_ABI32 1 > > > #define _MIPS_SIM_NABI322 > > > #define _MIPS_SIM_ABI64 3 > > > +#define _MIPS_SIM_ABIN64 _MIPS_SIM_ABI64 > > > > Hmm, I think I'd prefer that we just keep using _MIPS_SIM_ABI64. > > Sure, I think '64' to 'n64' conversion must be remove it from this patch > series.I can send v5 without '64' to 'n64' conversion. > > If we rename '64' to 'n64' in half of the place and this _MIPS_SIM_ABI64 > if we half to keep it in same looks not good (according to me). > > (FYI, This macro name - _MIPS_SIM_ABIN64 must be _MIPS_SIM_NABI64 > and defintion will be: > +#define _MIPS_SIM_NABI64 _MIPS_SIM_ABI64) > > So If you confirm I can send v5 without '64' to 'n64' conversion (not just > above > one, completely from this patch series). Or uou can take a call just > keep this macro - > _MIPS_SIM_ABI64 as it is and change it rest of the place. Let's just go ahead & leave everything as 64, and I'll do the 64 -> n64 rename later. I hoped whilst you were adding n64-specific code this would be an easy change, but at this point let's just prioritize getting the series applied without the naming change so it can sit in -next for a while before the merge window. Thanks, Paul
[PATCH] debugobjects: Move printk out of db lock critical sections
The db->lock is a raw spinlock and so the lock hold time is supposed
to be short. This will not be the case when printk() is being involved
in some of the critical sections. In order to avoid the long hold time,
in case some messages need to be printed, the debug_object_is_on_stack()
and debug_print_object() calls are now moved out of those critical
sections.
Holding the db->lock while calling printk() may lead to deadlock if
printk() somehow requires the allocation/freeing of debug object that
happens to be in the same hash bucket or a circular lock dependency
warning from lockdep as reported in https://lkml.org/lkml/2018/12/11/143.
[ 87.209665] WARNING: possible circular locking dependency detected
[ 87.210547] 4.20.0-rc4-00057-gc96cf92 #1 Tainted: GW
[ 87.211449] --
[ 87.212405] getty/519 is trying to acquire lock:
[ 87.213074] (ptrval) (_hash[i].lock){-.-.}, at:
debug_check_no_obj_freed+0xb4/0x302
[ 87.214343]
[ 87.214343] but task is already holding lock:
[ 87.215174] (ptrval) (_lock_key){-.-.}, at:
uart_shutdown+0x3a3/0x4e2
[ 87.216260]
[ 87.216260] which lock already depends on the new lock.
This patch was also found to be able to fix a boot hanging problem
when the initramfs image was switched on after a debugobjects splat
from the EFI code.
Signed-off-by: Waiman Long
---
lib/debugobjects.c | 61 +-
1 file changed, 42 insertions(+), 19 deletions(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 14afeeb..c30e786 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -375,6 +375,8 @@ static void debug_object_is_on_stack(void *addr, int
onstack)
struct debug_bucket *db;
struct debug_obj *obj;
unsigned long flags;
+ bool debug_printobj = false;
+ bool debug_chkstack = false;
fill_pool();
@@ -391,7 +393,7 @@ static void debug_object_is_on_stack(void *addr, int
onstack)
debug_objects_oom();
return;
}
- debug_object_is_on_stack(addr, onstack);
+ debug_chkstack = true;
}
switch (obj->state) {
@@ -402,20 +404,25 @@ static void debug_object_is_on_stack(void *addr, int
onstack)
break;
case ODEBUG_STATE_ACTIVE:
- debug_print_object(obj, "init");
state = obj->state;
raw_spin_unlock_irqrestore(>lock, flags);
+ debug_print_object(obj, "init");
debug_object_fixup(descr->fixup_init, addr, state);
return;
case ODEBUG_STATE_DESTROYED:
- debug_print_object(obj, "init");
+ debug_printobj = true;
break;
default:
break;
}
raw_spin_unlock_irqrestore(>lock, flags);
+ if (debug_chkstack)
+ debug_object_is_on_stack(addr, onstack);
+ if (debug_printobj)
+ debug_print_object(obj, "init");
+
}
/**
@@ -473,6 +480,8 @@ int debug_object_activate(void *addr, struct
debug_obj_descr *descr)
obj = lookup_object(addr, db);
if (obj) {
+ bool debug_printobj = false;
+
switch (obj->state) {
case ODEBUG_STATE_INIT:
case ODEBUG_STATE_INACTIVE:
@@ -481,14 +490,14 @@ int debug_object_activate(void *addr, struct
debug_obj_descr *descr)
break;
case ODEBUG_STATE_ACTIVE:
- debug_print_object(obj, "activate");
state = obj->state;
raw_spin_unlock_irqrestore(>lock, flags);
+ debug_print_object(obj, "activate");
ret = debug_object_fixup(descr->fixup_activate, addr,
state);
return ret ? 0 : -EINVAL;
case ODEBUG_STATE_DESTROYED:
- debug_print_object(obj, "activate");
+ debug_printobj = true;
ret = -EINVAL;
break;
default:
@@ -496,10 +505,13 @@ int debug_object_activate(void *addr, struct
debug_obj_descr *descr)
break;
}
raw_spin_unlock_irqrestore(>lock, flags);
+ if (debug_printobj)
+ debug_print_object(obj, "activate");
return ret;
}
raw_spin_unlock_irqrestore(>lock, flags);
+
/*
* We are here when a static object is activated. We
* let the type specific code confirm whether this is
@@ -531,6 +543,7 @@ void debug_object_deactivate(void *addr, struct
debug_obj_descr *descr)
struct debug_bucket *db;
struct debug_obj *obj;
unsigned long flags;
+ bool debug_printobj = false;
if
Re: [GIT PULL] ARM: at91: DT for 4.21
On 12/12/2018 13:05:53-0800, Olof Johansson wrote: > On Tue, Dec 11, 2018 at 06:11:12PM +0100, Alexandre Belloni wrote: > > Arnd, Olof, > > > > Here is the DT pull request for 4.21. The clock DT binding switch has > > been in -next for a while and doesn't seem to have any issue. > > > > This is based on the 4.20 fixes branch that you alredy pulled. > > > > The following changes since commit 4ab7ca092c3c7ac8b16aa28eba723a8868f82f14: > > > > ARM: dts: at91: sama5d2: use the divided clock for SMC (2018-11-21 > > 11:50:32 +0100) > > > > are available in the Git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-4.21-dt > > > > for you to fetch changes up to d8007306f6ad18f2ba0dcad68ffe9b2fd1d56bfb: > > > > ARM: dts: at91: nattis: initialize the BLON pin as output-low early > > (2018-11-21 12:24:50 +0100) > > > > > > AT91 DT for 4.21 > > > > - Switch most platforms to the new clock binding > > - Small improvement for Axentia nattis > > Merged, but how does this affect downstream users who have out-of-tree DTS > files that include the SoC dtsi? Seems like lots of stuff would break. > A few may break indeed. However, there are very few clocks that are actually exported out of the SoC (2 to 4) and they are very rarely used (usually only one to clock an audio codec). The other affected dts are the boards using the flexcom and my opinion is that we should probably get the flexcom stuff back in the dtsi anyway.. So yes, some out of tree board dts may break but they are pretty easy to fix. Also, the DT ABI compatibility is not broken so I don't expect too much breakage overall. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[PATCH v8 23/26] MIPS: GCW0: Move clocksource to TCU channel 2
The TCU channel 1, which is the default for the clocksource, is used as
PWM on the GCW Zero as it drives the backlight. Therefore we must use a
different TCU channel for the clocksource.
Signed-off-by: Paul Cercueil
---
Notes:
v8: New patch
arch/mips/boot/dts/ingenic/gcw0.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/gcw0.dts
b/arch/mips/boot/dts/ingenic/gcw0.dts
index 35f0291e8d38..8abab14eb852 100644
--- a/arch/mips/boot/dts/ingenic/gcw0.dts
+++ b/arch/mips/boot/dts/ingenic/gcw0.dts
@@ -60,3 +60,14 @@
/* The WiFi module is connected to the UHC. */
status = "okay";
};
+
+ {
+ /* Channels 1 and 3-7 are for PWM use */
+ reg = <0x50 0x10>, <0x70 0x50>;
+};
+
+ {
+ /* Use channel 2 for the clocksource */
+ reg = <0x60 0x10>;
+ clocks = < TCU_CLK_TIMER2>;
+};
--
2.11.0
[PATCH v8 19/26] MIPS: qi_lb60: Move PWM devices to devicetree
Probe the few drivers using PWMs from devicetree, now that we have a
devicetree node for the PWM driver.
Signed-off-by: Paul Cercueil
---
Notes:
v5: New patch
v6: No change
v7: No change
v8: No change
arch/mips/boot/dts/ingenic/qi_lb60.dts | 14 ++
arch/mips/jz4740/board-qi_lb60.c | 19 ---
2 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/arch/mips/boot/dts/ingenic/qi_lb60.dts
b/arch/mips/boot/dts/ingenic/qi_lb60.dts
index 76aaf8982554..85529a142409 100644
--- a/arch/mips/boot/dts/ingenic/qi_lb60.dts
+++ b/arch/mips/boot/dts/ingenic/qi_lb60.dts
@@ -9,6 +9,14 @@
chosen {
stdout-path =
};
+
+ beeper {
+ compatible = "pwm-beeper";
+ pwms = < 4 0 0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwm4>;
+ };
};
{
@@ -30,4 +38,10 @@
groups = "uart0-data";
bias-disable;
};
+
+ pins_pwm4: pwm4 {
+ function = "pwm4";
+ groups = "pwm4";
+ bias-disable;
+ };
};
diff --git a/arch/mips/jz4740/board-qi_lb60.c b/arch/mips/jz4740/board-qi_lb60.c
index af0c8ace0141..cc556be656d6 100644
--- a/arch/mips/jz4740/board-qi_lb60.c
+++ b/arch/mips/jz4740/board-qi_lb60.c
@@ -27,7 +27,6 @@
#include
#include
#include
-#include
#include
@@ -392,17 +391,6 @@ static struct jz4740_mmc_platform_data qi_lb60_mmc_pdata =
{
.power_active_low = 1,
};
-/* beeper */
-static struct pwm_lookup qi_lb60_pwm_lookup[] = {
- PWM_LOOKUP("jz4740-pwm", 4, "pwm-beeper", NULL, 0,
- PWM_POLARITY_NORMAL),
-};
-
-static struct platform_device qi_lb60_pwm_beeper = {
- .name = "pwm-beeper",
- .id = -1,
-};
-
/* charger */
static char *qi_lb60_batteries[] = {
"battery",
@@ -451,10 +439,8 @@ static struct platform_device *jz_platform_devices[]
__initdata = {
_i2s_device,
_codec_device,
_adc_device,
- _pwm_device,
_dma_device,
_lb60_gpio_keys,
- _lb60_pwm_beeper,
_lb60_charger_device,
_lb60_audio_device,
};
@@ -483,10 +469,6 @@ static struct pinctrl_map pin_map[] __initdata = {
"1001.jz4740-pinctrl", "PD0", pin_cfg_bias_disable),
PIN_MAP_CONFIGS_PIN_DEFAULT("jz4740-mmc.0",
"1001.jz4740-pinctrl", "PD2", pin_cfg_bias_disable),
-
- /* PWM pin configuration */
- PIN_MAP_MUX_GROUP_DEFAULT("jz4740-pwm",
- "1001.jz4740-pinctrl", "pwm4", "pwm4"),
};
@@ -504,7 +486,6 @@ static int __init qi_lb60_init_platform_devices(void)
spi_register_board_info(qi_lb60_spi_board_info,
ARRAY_SIZE(qi_lb60_spi_board_info));
- pwm_add_table(qi_lb60_pwm_lookup, ARRAY_SIZE(qi_lb60_pwm_lookup));
pinctrl_register_mappings(pin_map, ARRAY_SIZE(pin_map));
return platform_add_devices(jz_platform_devices,
--
2.11.0
[PATCH v8 24/26] MIPS: GCW0: Reduce system timer and clocksource to 750 kHz
The default clock (12 MHz) is too fast for the system timer, which fails
to report time accurately.
Signed-off-by: Paul Cercueil
---
Notes:
v8: New patch
arch/mips/boot/dts/ingenic/gcw0.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/gcw0.dts
b/arch/mips/boot/dts/ingenic/gcw0.dts
index 8abab14eb852..651c3f505fa5 100644
--- a/arch/mips/boot/dts/ingenic/gcw0.dts
+++ b/arch/mips/boot/dts/ingenic/gcw0.dts
@@ -61,6 +61,12 @@
status = "okay";
};
+ {
+ /* 750 kHz for the system timer and clocksource */
+ assigned-clocks = < TCU_CLK_TIMER0>, < TCU_CLK_TIMER2>;
+ assigned-clock-rates = <75>, <75>;
+};
+
{
/* Channels 1 and 3-7 are for PWM use */
reg = <0x50 0x10>, <0x70 0x50>;
--
2.11.0
[PATCH v8 21/26] MIPS: CI20: Reduce system timer and clocksource to 3 MHz
The default clock (48 MHz) is too fast for the system timer, which fails
to report time accurately.
Signed-off-by: Paul Cercueil
---
Notes:
v5: New patch
v6: Set also the rate for the clocksource channel's clock
v7: No change
v8: No change
arch/mips/boot/dts/ingenic/ci20.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
b/arch/mips/boot/dts/ingenic/ci20.dts
index 50cff3cbcc6d..f64d32443097 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -238,3 +238,9 @@
bias-disable;
};
};
+
+ {
+ /* 3 MHz for the system timer and clocksource */
+ assigned-clocks = < TCU_CLK_TIMER0>, < TCU_CLK_TIMER1>;
+ assigned-clock-rates = <300>, <300>;
+};
--
2.11.0
[PATCH v8 22/26] MIPS: CI20: defconfig: enable OST driver
The OST driver provides a clocksource and sched_clock that are much more accurate than the default ones. Signed-off-by: Paul Cercueil --- Notes: v5: New patch v6: No change v7: No change v8: No change arch/mips/configs/ci20_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig index 030ff9c205fb..9b09b9a7f943 100644 --- a/arch/mips/configs/ci20_defconfig +++ b/arch/mips/configs/ci20_defconfig @@ -111,6 +111,7 @@ CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_JZ4740=y CONFIG_DMADEVICES=y CONFIG_DMA_JZ4780=y +CONFIG_INGENIC_OST=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_MEMORY=y CONFIG_EXT4_FS=y -- 2.11.0
Re: [PATCH 4.4 00/91] 4.4.167-stable review
On Tue, Dec 11, 2018 at 04:40:19PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.167 release. > There are 91 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Dec 13 15:15:44 UTC 2018. > Anything received after that time might be too late. > For v4.4.166-91-gf16ad7a4b88c: Build results: total: 170 pass: 170 fail: 0 Qemu test results: total: 288 pass: 288 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
[PATCH v8 01/26] dt-bindings: ingenic: Add DT bindings for TCU clocks
This header provides clock numbers for the ingenic,tcu DT binding. Signed-off-by: Paul Cercueil Reviewed-by: Rob Herring --- Notes: v2: Use SPDX identifier for the license v3: No change v4: No change v5: s/JZ47*_/TCU_/ and dropped *_CLK_LAST defines v6: No change v7: No change v8: No change include/dt-bindings/clock/ingenic,tcu.h | 20 1 file changed, 20 insertions(+) create mode 100644 include/dt-bindings/clock/ingenic,tcu.h diff --git a/include/dt-bindings/clock/ingenic,tcu.h b/include/dt-bindings/clock/ingenic,tcu.h new file mode 100644 index ..d569650a7945 --- /dev/null +++ b/include/dt-bindings/clock/ingenic,tcu.h @@ -0,0 +1,20 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * This header provides clock numbers for the ingenic,tcu DT binding. + */ + +#ifndef __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ +#define __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ + +#define TCU_CLK_TIMER0 0 +#define TCU_CLK_TIMER1 1 +#define TCU_CLK_TIMER2 2 +#define TCU_CLK_TIMER3 3 +#define TCU_CLK_TIMER4 4 +#define TCU_CLK_TIMER5 5 +#define TCU_CLK_TIMER6 6 +#define TCU_CLK_TIMER7 7 +#define TCU_CLK_WDT8 +#define TCU_CLK_OST9 + +#endif /* __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ */ -- 2.11.0
[PATCH v8 17/26] MIPS: Kconfig: Select TCU timer driver when MACH_INGENIC is set
We cannot boot to userspace (not even initramfs) if the timer driver is not present; so it makes sense to enable it unconditionally when MACH_INGENIC is set. Signed-off-by: Paul Cercueil --- Notes: v5: New patch v6: No change v7: No change v8: No change arch/mips/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 8272ea4c7264..8bd53a4e871b 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -390,6 +390,7 @@ config MACH_INGENIC select BUILTIN_DTB select USE_OF select LIBFDT + select INGENIC_TIMER config LANTIQ bool "Lantiq based platforms" -- 2.11.0
Re: [PATCH 3.18 00/54] 3.18.129-stable review
On Tue, Dec 11, 2018 at 04:40:48PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.129 release. > There are 54 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Dec 13 15:15:33 UTC 2018. > Anything received after that time might be too late. > For v3.18.128-54-ge518503ddca9: Build results: total: 154 pass: 154 fail: 0 Qemu test results: total: 223 pass: 223 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
[PATCH v8 03/26] dt-bindings: Add doc for the Ingenic TCU drivers
Add documentation about how to properly use the Ingenic TCU
(Timer/Counter Unit) drivers from devicetree.
Signed-off-by: Paul Cercueil
---
Notes:
v4: New patch in this series. Corresponds to V2 patches 3-4-5 with
added content.
v5: - Edited PWM/watchdog DT bindings documentation to point to the new
document.
- Moved main document to
Documentation/devicetree/bindings/timer/ingenic,tcu.txt
- Updated documentation to reflect the new devicetree bindings.
v6: - Removed PWM/watchdog documentation files as asked by upstream
- Removed doc about properties that should be implicit
- Removed doc about ingenic,timer-channel /
ingenic,clocksource-channel as they are gone
- Fix WDT clock name in the binding doc
- Fix lengths of register areas in watchdog/pwm nodes
v7: No change
v8: - Fix address of the PWM node
- Added doc about system timer and clocksource children nodes
.../devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt | 25 ---
.../devicetree/bindings/timer/ingenic,tcu.txt | 176 +
.../bindings/watchdog/ingenic,jz4740-wdt.txt | 17 --
3 files changed, 176 insertions(+), 42 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
create mode 100644 Documentation/devicetree/bindings/timer/ingenic,tcu.txt
delete mode 100644
Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt
diff --git a/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
b/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
deleted file mode 100644
index 7d9d3f90641b..
--- a/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Ingenic JZ47xx PWM Controller
-=
-
-Required properties:
-- compatible: One of:
- * "ingenic,jz4740-pwm"
- * "ingenic,jz4770-pwm"
- * "ingenic,jz4780-pwm"
-- #pwm-cells: Should be 3. See pwm.txt in this directory for a description
- of the cells format.
-- clocks : phandle to the external clock.
-- clock-names : Should be "ext".
-
-
-Example:
-
- pwm: pwm@10002000 {
- compatible = "ingenic,jz4740-pwm";
- reg = <0x10002000 0x1000>;
-
- #pwm-cells = <3>;
-
- clocks = <>;
- clock-names = "ext";
- };
diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
new file mode 100644
index ..8a4ce7edf50f
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
@@ -0,0 +1,176 @@
+Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings
+==
+
+For a description of the TCU hardware and drivers, have a look at
+Documentation/mips/ingenic-tcu.txt.
+
+Required properties:
+
+- compatible: Must be one of:
+ * ingenic,jz4740-tcu
+ * ingenic,jz4725b-tcu
+ * ingenic,jz4770-tcu
+- reg: Should be the offset/length value corresponding to the TCU registers
+- clocks: List of phandle & clock specifiers for clocks external to the TCU.
+ The "pclk", "rtc", "ext" and "tcu" clocks should be provided.
+- clock-names: List of name strings for the external clocks.
+- #clock-cells: Should be <1>;
+ Clock consumers specify this argument to identify a clock. The valid values
+ may be found in .
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value should be 1.
+- interrupt-parent : phandle of the interrupt controller.
+- interrupts : Specifies the interrupt the controller is connected to.
+
+
+Children nodes
+==
+
+
+PWM node:
+-
+
+Required properties:
+
+- compatible: Must be one of:
+ * ingenic,jz4740-pwm
+ * ingenic,jz4725b-pwm
+- #pwm-cells: Should be 3. See ../pwm/pwm.txt for a description of the cell
+ format.
+- clocks: List of phandle & clock specifiers for the TCU clocks.
+- clock-names: List of name strings for the TCU clocks.
+
+
+Watchdog node:
+--
+
+Required properties:
+
+- compatible: Must be one of:
+ * ingenic,jz4740-watchdog
+ * ingenic,jz4780-watchdog
+- clocks: phandle to the WDT clock
+- clock-names: should be "wdt"
+
+
+OST node:
+-
+
+Required properties:
+
+- compatible: Must be one of:
+ * ingenic,jz4725b-ost
+ * ingenic,jz4770-ost
+- clocks: phandle to the OST clock
+- clock-names: should be "ost"
+- interrupts : Specifies the interrupt the OST is connected to.
+
+
+System timer node:
+--
+
+Required properties:
+
+- compatible: Must be "ingenic,jz4740-tcu-timer"
+- clocks: phandle to the clock of the TCU channel used
+- clock-names: Should be "timer"
+- interrupts : Specifies the interrupt line of the TCU channel used.
+
+
+System
[PATCH v8 00/26] Ingenic TCU patchset v8
Hi, Here's the version 8 and hopefully final version of my patchset, which adds support for the Timer/Counter Unit found in JZ47xx SoCs from Ingenic. The big change is that the timer driver has been simplified. The code to dynamically update the system timer or clocksource to a new channel has been removed. Now, the system timer and clocksource are provided as children nodes in the devicetree, and the TCU channel to use for these is deduced from their respective memory resource. The PWM driver will also deduce from its memory resources whether a given PWM channel can be used, or is reserved for the system timers. Kind regards, - Paul Cercueil
[PATCH v8 11/26] pwm: jz4740: Use regmap and clocks from TCU driver
The ingenic-timer "TCU" driver provides us with a regmap, that we can
use to safely access the TCU registers.
It also provides us with clocks, that can be (un)gated, reparented or
reclocked from devicetree, instead of having these settings hardcoded in
this driver.
While this driver is devicetree-compatible, it is never (as of now)
probed from devicetree, so this change does not introduce a ABI problem
with current devicetree files.
Signed-off-by: Paul Cercueil
---
Notes:
v5: New patch
v6: Drop requirement of probing from devicetree
v7: No change
v8: Drop useless include
drivers/pwm/Kconfig | 2 +
drivers/pwm/pwm-jz4740.c | 123 ++-
2 files changed, 82 insertions(+), 43 deletions(-)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 27e5dd47a01f..0343f0c1238e 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -202,6 +202,8 @@ config PWM_IMX
config PWM_JZ4740
tristate "Ingenic JZ47xx PWM support"
depends on MACH_INGENIC
+ depends on COMMON_CLK
+ select INGENIC_TIMER
help
Generic PWM framework driver for Ingenic JZ47xx based
machines.
diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index a7b134af5e04..6b865c14f789 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -15,20 +15,19 @@
#include
#include
-#include
#include
+#include
#include
-#include
#include
#include
-
-#include
+#include
#define NUM_PWM 8
struct jz4740_pwm_chip {
struct pwm_chip chip;
- struct clk *clk;
+ struct clk *clks[NUM_PWM];
+ struct regmap *map;
};
static inline struct jz4740_pwm_chip *to_jz4740(struct pwm_chip *chip)
@@ -38,6 +37,11 @@ static inline struct jz4740_pwm_chip *to_jz4740(struct
pwm_chip *chip)
static int jz4740_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ struct jz4740_pwm_chip *jz = to_jz4740(chip);
+ struct clk *clk;
+ char clk_name[16];
+ int ret;
+
/*
* Timers 0 and 1 are used for system tasks, so they are unavailable
* for use as PWMs.
@@ -45,65 +49,89 @@ static int jz4740_pwm_request(struct pwm_chip *chip, struct
pwm_device *pwm)
if (pwm->hwpwm < 2)
return -EBUSY;
- jz4740_timer_start(pwm->hwpwm);
+ snprintf(clk_name, sizeof(clk_name), "timer%u", pwm->hwpwm);
+
+ clk = clk_get(chip->dev, clk_name);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ clk_put(clk);
+ return ret;
+ }
+
+ jz->clks[pwm->hwpwm] = clk;
return 0;
}
static void jz4740_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
{
- jz4740_timer_set_ctrl(pwm->hwpwm, 0);
+ struct jz4740_pwm_chip *jz = to_jz4740(chip);
+ struct clk *clk = jz->clks[pwm->hwpwm];
- jz4740_timer_stop(pwm->hwpwm);
+ clk_disable_unprepare(clk);
+ clk_put(clk);
}
static int jz4740_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
- uint32_t ctrl = jz4740_timer_get_ctrl(pwm->pwm);
+ struct jz4740_pwm_chip *jz = to_jz4740(chip);
- ctrl |= JZ_TIMER_CTRL_PWM_ENABLE;
- jz4740_timer_set_ctrl(pwm->hwpwm, ctrl);
- jz4740_timer_enable(pwm->hwpwm);
+ /* Enable PWM output */
+ regmap_update_bits(jz->map, TCU_REG_TCSRc(pwm->hwpwm),
+ TCU_TCSR_PWM_EN, TCU_TCSR_PWM_EN);
+ /* Start counter */
+ regmap_write(jz->map, TCU_REG_TESR, BIT(pwm->hwpwm));
return 0;
}
static void jz4740_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
{
- uint32_t ctrl = jz4740_timer_get_ctrl(pwm->hwpwm);
+ struct jz4740_pwm_chip *jz = to_jz4740(chip);
/* Disable PWM output.
* In TCU2 mode (channel 1/2 on JZ4750+), this must be done before the
* counter is stopped, while in TCU1 mode the order does not matter.
*/
- ctrl &= ~JZ_TIMER_CTRL_PWM_ENABLE;
- jz4740_timer_set_ctrl(pwm->hwpwm, ctrl);
+ regmap_update_bits(jz->map, TCU_REG_TCSRc(pwm->hwpwm),
+ TCU_TCSR_PWM_EN, 0);
/* Stop counter */
- jz4740_timer_disable(pwm->hwpwm);
+ regmap_write(jz->map, TCU_REG_TECR, BIT(pwm->hwpwm));
}
static int jz4740_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns)
{
struct jz4740_pwm_chip *jz4740 = to_jz4740(pwm->chip);
+ struct clk *clk = jz4740->clks[pwm->hwpwm];
+ unsigned long rate, new_rate, period, duty;
unsigned long long tmp;
- unsigned long period, duty;
- unsigned int prescaler = 0;
- uint16_t ctrl;
+ unsigned int tcsr;
bool is_enabled;
- tmp = (unsigned long long)clk_get_rate(jz4740->clk) * period_ns;
-
Re: [PATCH] Linux: Implement membarrier function
On Wed, Dec 12, 2018 at 01:52:45PM -0800, Paul E. McKenney wrote:
> On Wed, Dec 12, 2018 at 04:32:50PM -0500, Alan Stern wrote:
> > On Wed, 12 Dec 2018, Paul E. McKenney wrote:
> >
> > > OK. How about this one?
> > >
> > > P0 P1 P2 P3
> > > Wa=2rcu_read_lock()Wc=2Wd=2
> > > membWb=2 Rd=0synchronize_rcu();
> > > Rb=0Rc=0 Ra=0
> > >rcu_read_unlock()
> > >
> > > The model should say that it is allowed. Taking a look...
> > >
> > > P0 P1 P2 P3
> > > Rd=0
> > > Wd=2
> > > synchronize_rcu();
> > > Ra=0
> > >Wa=2
> > >membs
> > >rcu_read_lock()
> > >[m01]
> > >Rc=0
> > > Wc=2
> > > [m02] [m03]
> > >membe
> > >Rb=0
> > >Wb=2
> > >rcu_read_unlock()
> > >
> > > Looks allowed to me. If the synchronization of P1 and P2 were
> > > interchanged, it should be forbidden:
> > >
> > > P0 P1 P2 P3
> > > Wa=2Wb=2rcu_read_lock()Wd=2
> > > membRc=0Wc=2 synchronize_rcu();
> > > Rb=0Rd=0 Ra=0
> > > rcu_read_unlock()
> > >
> > > Taking a look...
> > >
> > > P0 P1 P2 P3
> > > rcu_read_lock()
> > > Rd=0
> > > Wa=2Wb=2 Wd=2
> > > membs synchronize_rcu();
> > > [m01]
> > > Rc=0
> > > Wc=2
> > > rcu_read_unlock()
> > >[m02] Ra=0 [Forbidden?]
> > >membe
> > > Rb=0
>
> For one thing, Wb=2 needs to be down here, apologies! Which then ...
>
> > Have you tried writing these as real litmus tests and running them
> > through herd?
>
> That comes later, but yes, I will do that.
>
> > > I believe that this ordering forbids the cycle:
> > >
> > > Wa=1 > membs -> [m01] -> Rc=0 -> Wc=2 -> rcu_read_unlock() ->
> > > return from synchronize_rcu() -> Ra
> > >
> > > Does this make sense, or am I missing something?
> >
> > It's hard to tell. What you have written here isn't justified by the
> > litmus test source code, since the position of m01 in P1's program
> > order is undetermined. How do you justify m01 -> Rc, for example?
>
> ... justifies Rc=0 following [m01].
>
> > Write it this way instead, using the relations defined in the
> > sys_membarrier patch for linux-kernel.cat:
> >
> > memb ->memb-gp memb ->rcu-link Rc ->memb-rscsi Rc ->rcu-link
> >
> > rcu_read_unlock ->rcu-rscsi rcu_read_lock ->rcu-link
> >
> > synchronize_rcu ->rcu-gp synchronize_rcu ->rcu-link memb
> >
> > Recall that:
> >
> > memb-gp is the identity relation on sys_membarrier events,
> >
> > rcu-link includes (po? ; fre ; po),
> >
> > memb-rscsi is the identity relation on all events,
> >
> > rcu-rscsi links unlocks to their corresponding locks, and
> >
> > rcu-gp is the identity relation on synchronize_rcu events.
> >
> > These facts justify the cycle above.
> >
> > Leaving off the final rcu-link step, the sequence matches the
> > definition of rcu-fence (the relations are memb-gp, memb-rscsi,
> > rcu-rscsi, rcu-gp with rcu-links in between). Therefore the cycle is
> > forbidden.
>
> Understood, but that would be using the model to check the model. ;-)
And here are the litmus tests in the same order as above. They do give
the results we both called out above, which is encouraging.
Thanx, Paul
C C-memb-RCU-1
(*
* Result: Sometimes
*)
{
}
P0(int *x0, int *x1)
{
WRITE_ONCE(*x0, 1);
smp_memb();
r1 = READ_ONCE(*x1);
}
P1(int *x1, int *x2)
{
rcu_read_lock();
WRITE_ONCE(*x1, 1);
r1 = READ_ONCE(*x2);
rcu_read_unlock();
}
P2(int *x2, int *x3)
{
WRITE_ONCE(*x2, 1);
r1 = READ_ONCE(*x3);
}
P3(int *x3, int *x0)
{
WRITE_ONCE(*x3, 1);
synchronize_rcu();
r1 = READ_ONCE(*x0);
}
exists (0:r1=0 /\ 1:r1=0 /\ 2:r1=0 /\ 3:r1=0)
C C-memb-RCU-1
(*
* Result: Never
*)
{
}
P0(int *x0, int *x1)
{
WRITE_ONCE(*x0, 1);
smp_memb();
r1 = READ_ONCE(*x1);
}
P1(int *x1, int *x2)
{
WRITE_ONCE(*x1, 1);
r1 = READ_ONCE(*x2);
}
P2(int *x2, int *x3)
{
rcu_read_lock();
Re: [PATCH 2/2] ARM: mmp: fix pxa168_device_usb_phy use on aspenite
On Mon, Dec 10, 2018 at 09:43:02PM +0100, Arnd Bergmann wrote:
> This one ended up in the wrong header file, causing a build failure
> on at least one platform:
>
> arch/arm/mach-mmp/aspenite.c: In function 'common_init':
> arch/arm/mach-mmp/aspenite.c:260:28: error: 'pxa168_device_usb_phy'
> undeclared (first use in this function); did you mean 'pxa168_device_ssp5'?
>
> We can just include both the pxa168.h and pxa910.h headers to make
> that work, which gets us to the next failure:
>
> arch/arm/mach-mmp/aspenite.o: In function `common_init':
> aspenite.c:(.init.text+0x1c0): undefined reference to `pxa168_device_usb_phy'
>
> This is solved by using the matching ifdef check around the
> USB device registration, enabling them only when either USB
> host or gadget mode are enabled.
>
> Fixes: a225daf72ee7 ("ARM: mmp: add a pxa-usb-phy device")
> Signed-off-by: Arnd Bergmann
Applied to next/soc. Thanks!
-Olof
[PATCH v8 14/26] pwm: jz4740: Remove unused devicetree compatible strings
Right now none of the Ingenic-based boards probe this driver from
devicetree. This driver defined three compatible strings for the exact
same behaviour. Before these strings are used, we can remove two of
them.
Signed-off-by: Paul Cercueil
Acked-by: Thierry Reding
---
Notes:
v5: New patch
v6: No change
v7: No change
v8: No change
drivers/pwm/pwm-jz4740.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index 7b12e5628f4f..cb8d8cec353f 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -258,8 +258,6 @@ static int jz4740_pwm_remove(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id jz4740_pwm_dt_ids[] = {
{ .compatible = "ingenic,jz4740-pwm", },
- { .compatible = "ingenic,jz4770-pwm", },
- { .compatible = "ingenic,jz4780-pwm", },
{},
};
MODULE_DEVICE_TABLE(of, jz4740_pwm_dt_ids);
--
2.11.0
[PATCH v8 09/26] watchdog: jz4740: Avoid starting watchdog in set_timeout
Previously the jz4740_wdt_set_timeout() function was starting the timer
unconditionally, even if it was stopped when that function was entered.
Now, the timer will be restarted only if it was already running before
this function is called.
Signed-off-by: Paul Cercueil
Reviewed-by: Guenter Roeck
---
Notes:
v6: New patch
v7: No change
v8: No change
drivers/watchdog/jz4740_wdt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
index 0f54306aee25..45d9495170e5 100644
--- a/drivers/watchdog/jz4740_wdt.c
+++ b/drivers/watchdog/jz4740_wdt.c
@@ -64,13 +64,15 @@ static int jz4740_wdt_set_timeout(struct watchdog_device
*wdt_dev,
{
struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
u16 timeout_value = (u16)(drvdata->clk_rate * new_timeout);
+ u32 tcer;
+ regmap_read(drvdata->map, TCU_REG_WDT_TCER, );
regmap_write(drvdata->map, TCU_REG_WDT_TCER, 0);
regmap_write(drvdata->map, TCU_REG_WDT_TDR, timeout_value);
regmap_write(drvdata->map, TCU_REG_WDT_TCNT, 0);
- regmap_write(drvdata->map, TCU_REG_WDT_TCER, TCU_WDT_TCER_TCEN);
+ regmap_write(drvdata->map, TCU_REG_WDT_TCER, tcer & TCU_WDT_TCER_TCEN);
wdt_dev->timeout = new_timeout;
return 0;
@@ -86,6 +88,7 @@ static int jz4740_wdt_start(struct watchdog_device *wdt_dev)
return ret;
jz4740_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
+ regmap_write(drvdata->map, TCU_REG_WDT_TCER, TCU_WDT_TCER_TCEN);
return 0;
}
--
2.11.0
[PATCH v8 20/26] MIPS: qi_lb60: Reduce system timer and clocksource to 750 kHz
The default clock (12 MHz) is too fast for the system timer, which fails
to report time accurately.
Signed-off-by: Paul Cercueil
---
Notes:
v5: New patch
v6: Remove ingenic,clocksource-channel property
v7: No change
v8: No change
arch/mips/boot/dts/ingenic/qi_lb60.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/qi_lb60.dts
b/arch/mips/boot/dts/ingenic/qi_lb60.dts
index 85529a142409..de9d45e2c24a 100644
--- a/arch/mips/boot/dts/ingenic/qi_lb60.dts
+++ b/arch/mips/boot/dts/ingenic/qi_lb60.dts
@@ -45,3 +45,9 @@
bias-disable;
};
};
+
+ {
+ /* 750 kHz for the system timer and clocksource */
+ assigned-clocks = < TCU_CLK_TIMER0>, < TCU_CLK_TIMER1>;
+ assigned-clock-rates = <75>, <75>;
+};
--
2.11.0
Re: [GIT PULL 4/4] ARM: samsung: SoC/mach for 4.21
On Sun, Dec 09, 2018 at 12:49:11PM +0100, Krzysztof Kozlowski wrote: > The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: > > Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-soc-4.21 > > for you to fetch changes up to cafbc79e327f44411b8bd8bdc101b9e6c65ab42a: > > ARM: exynos: Remove secondary startup initialization from smp_prepare_cpus > (2018-11-18 15:12:50 +0100) > > > Samsung mach/soc changes for v4.21 > > Just cleanups of: legacy way of setting external wakeup interrupts, old > power management debugging functions and duplicated secondary startup > initialization. > > > Bartlomiej Zolnierkiewicz (2): > ARM: exynos: Remove no longer needed s3c_pm_check_*() calls > ARM: samsung: Limit SAMSUNG_PM_DEBUG config option to non-Exynos > platforms > > Krzysztof Kozlowski (2): > ARM: s5pv210: Remove legacy setting of external wakeup interrupts > ARM: exynos: Remove legacy setting of external wakeup interrupts > > Pankaj Dubey (1): > ARM: exynos: Remove secondary startup initialization from > smp_prepare_cpus Merged, thanks! -Olof
[PATCH v8 12/26] pwm: jz4740: Allow selection of PWM channels 0 and 1
The TCU channels 0 and 1 were previously reserved for system tasks, and
thus unavailable for PWM.
The driver will now only allow a PWM channel to be requested if memory
resources corresponding to the register area of the channel were
supplied to the driver. This allows the TCU channels to be reserved for
system tasks from within the devicetree.
Signed-off-by: Paul Cercueil
---
Notes:
v6: New patch
v7: No change
v8: ingenic_tcu_[request,release]_channel are dropped. We now use
the memory resources provided to the driver to detect whether
or not we are allowed to use the TCU channel.
drivers/pwm/pwm-jz4740.c | 38 +-
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index 6b865c14f789..7b12e5628f4f 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -28,6 +28,7 @@ struct jz4740_pwm_chip {
struct pwm_chip chip;
struct clk *clks[NUM_PWM];
struct regmap *map;
+ struct resource *parent_res;
};
static inline struct jz4740_pwm_chip *to_jz4740(struct pwm_chip *chip)
@@ -35,6 +36,31 @@ static inline struct jz4740_pwm_chip *to_jz4740(struct
pwm_chip *chip)
return container_of(chip, struct jz4740_pwm_chip, chip);
}
+static bool jz4740_pwm_can_use_chn(struct jz4740_pwm_chip *jz, unsigned int
chn)
+{
+ struct platform_device *pdev = to_platform_device(jz->chip.dev);
+ struct resource chn_res, *res;
+ unsigned int i;
+
+ chn_res.start = jz->parent_res->start + TCU_REG_TDFRc(chn);
+ chn_res.end = chn_res.start + TCU_CHANNEL_STRIDE - 1;
+ chn_res.flags = IORESOURCE_MEM;
+
+ /*
+* Walk the list of resources, find if there's one that contains the
+* registers for the requested TCU channel
+*/
+ for (i = 0; ; i++) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!res)
+ break;
+ if (resource_contains(res, _res))
+ return true;
+ }
+
+ return false;
+}
+
static int jz4740_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
{
struct jz4740_pwm_chip *jz = to_jz4740(chip);
@@ -42,11 +68,7 @@ static int jz4740_pwm_request(struct pwm_chip *chip, struct
pwm_device *pwm)
char clk_name[16];
int ret;
- /*
-* Timers 0 and 1 are used for system tasks, so they are unavailable
-* for use as PWMs.
-*/
- if (pwm->hwpwm < 2)
+ if (!jz4740_pwm_can_use_chn(jz, pwm->hwpwm))
return -EBUSY;
snprintf(clk_name, sizeof(clk_name), "timer%u", pwm->hwpwm);
@@ -208,6 +230,12 @@ static int jz4740_pwm_probe(struct platform_device *pdev)
return -EINVAL;
}
+ jz4740->parent_res = platform_get_resource(
+ to_platform_device(dev->parent),
+ IORESOURCE_MEM, 0);
+ if (!jz4740->parent_res)
+ return -EINVAL;
+
jz4740->chip.dev = dev;
jz4740->chip.ops = _pwm_ops;
jz4740->chip.npwm = NUM_PWM;
--
2.11.0
[PATCH v8 08/26] watchdog: jz4740: Use regmap provided by TCU driver
Since we broke the ABI by changing the clock, the driver was also
updated to use the regmap provided by the TCU driver.
Signed-off-by: Paul Cercueil
Reviewed-by: Guenter Roeck
---
Notes:
v6: New patch
v7: No change
v8: No change
drivers/watchdog/jz4740_wdt.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
index 1d504ecf45e1..0f54306aee25 100644
--- a/drivers/watchdog/jz4740_wdt.c
+++ b/drivers/watchdog/jz4740_wdt.c
@@ -13,6 +13,7 @@
*
*/
+#include
#include
#include
#include
@@ -25,10 +26,7 @@
#include
#include
#include
-
-#define JZ_REG_WDT_TIMER_DATA 0x0
-#define JZ_REG_WDT_COUNTER_ENABLE 0x4
-#define JZ_REG_WDT_TIMER_COUNTER 0x8
+#include
#define DEFAULT_HEARTBEAT 5
#define MAX_HEARTBEAT 2048
@@ -48,7 +46,7 @@ MODULE_PARM_DESC(heartbeat,
struct jz4740_wdt_drvdata {
struct watchdog_device wdt;
- void __iomem *base;
+ struct regmap *map;
struct clk *clk;
unsigned long clk_rate;
};
@@ -57,7 +55,7 @@ static int jz4740_wdt_ping(struct watchdog_device *wdt_dev)
{
struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
- writew(0x0, drvdata->base + JZ_REG_WDT_TIMER_COUNTER);
+ regmap_write(drvdata->map, TCU_REG_WDT_TCNT, 0);
return 0;
}
@@ -67,12 +65,12 @@ static int jz4740_wdt_set_timeout(struct watchdog_device
*wdt_dev,
struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
u16 timeout_value = (u16)(drvdata->clk_rate * new_timeout);
- writeb(0x0, drvdata->base + JZ_REG_WDT_COUNTER_ENABLE);
+ regmap_write(drvdata->map, TCU_REG_WDT_TCER, 0);
- writew((u16)timeout_value, drvdata->base + JZ_REG_WDT_TIMER_DATA);
- writew(0x0, drvdata->base + JZ_REG_WDT_TIMER_COUNTER);
+ regmap_write(drvdata->map, TCU_REG_WDT_TDR, timeout_value);
+ regmap_write(drvdata->map, TCU_REG_WDT_TCNT, 0);
- writeb(0x1, drvdata->base + JZ_REG_WDT_COUNTER_ENABLE);
+ regmap_write(drvdata->map, TCU_REG_WDT_TCER, TCU_WDT_TCER_TCEN);
wdt_dev->timeout = new_timeout;
return 0;
@@ -96,7 +94,7 @@ static int jz4740_wdt_stop(struct watchdog_device *wdt_dev)
{
struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
- writeb(0x0, drvdata->base + JZ_REG_WDT_COUNTER_ENABLE);
+ regmap_write(drvdata->map, TCU_REG_WDT_TCER, 0);
clk_disable_unprepare(drvdata->clk);
return 0;
@@ -138,7 +136,6 @@ static int jz4740_wdt_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct jz4740_wdt_drvdata *drvdata;
struct watchdog_device *jz4740_wdt;
- struct resource *res;
long rate;
int ret;
@@ -174,10 +171,11 @@ static int jz4740_wdt_probe(struct platform_device *pdev)
watchdog_set_nowayout(jz4740_wdt, nowayout);
watchdog_set_drvdata(jz4740_wdt, drvdata);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- drvdata->base = devm_ioremap_resource(>dev, res);
- if (IS_ERR(drvdata->base))
- return PTR_ERR(drvdata->base);
+ drvdata->map = dev_get_regmap(dev->parent, NULL);
+ if (!drvdata->map) {
+ dev_err(dev, "regmap not found\n");
+ return -EINVAL;
+ }
ret = devm_watchdog_register_device(>dev, >wdt);
if (ret < 0)
--
2.11.0
[PATCH v8 07/26] watchdog: jz4740: Use WDT clock provided by TCU driver
Instead of requesting the "ext" clock and handling the watchdog clock
divider and gating in the watchdog driver, we now request and use the
"wdt" clock that is supplied by the ingenic-timer "TCU" driver.
The major benefit is that the watchdog's clock rate and parent can now
be specified from within devicetree, instead of hardcoded in the driver.
Also, this driver won't poke anymore into the TCU registers to
enable/disable the clock, as this is now handled by the TCU driver.
On the bad side, we break the ABI with devicetree - as we now request a
different clock. In this very specific case it is still okay, as every
Ingenic JZ47xx-based board out there compile the devicetree within the
kernel; so it's still time to push breaking changes, in order to get a
clean devicetree that won't break once it musn't.
Signed-off-by: Paul Cercueil
Reviewed-by: Guenter Roeck
---
Notes:
v5: New patch
v6: - Split regmap change to new patch 09/24
- The code now sets the WDT clock to the smallest rate possible and
calculates the maximum timeout from that
v7: No change
v8: No change
drivers/watchdog/Kconfig | 2 +
drivers/watchdog/jz4740_wdt.c | 86 +--
2 files changed, 36 insertions(+), 52 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2d64333f4782..cfd7368fc3c0 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1497,7 +1497,9 @@ config INDYDOG
config JZ4740_WDT
tristate "Ingenic jz4740 SoC hardware watchdog"
depends on MACH_JZ4740 || MACH_JZ4780
+ depends on COMMON_CLK
select WATCHDOG_CORE
+ select INGENIC_TIMER
help
Hardware driver for the built-in watchdog timer on Ingenic jz4740
SoCs.
diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
index ec4d99a830ba..1d504ecf45e1 100644
--- a/drivers/watchdog/jz4740_wdt.c
+++ b/drivers/watchdog/jz4740_wdt.c
@@ -26,25 +26,9 @@
#include
#include
-#include
-
#define JZ_REG_WDT_TIMER_DATA 0x0
#define JZ_REG_WDT_COUNTER_ENABLE 0x4
#define JZ_REG_WDT_TIMER_COUNTER 0x8
-#define JZ_REG_WDT_TIMER_CONTROL 0xC
-
-#define JZ_WDT_CLOCK_PCLK 0x1
-#define JZ_WDT_CLOCK_RTC 0x2
-#define JZ_WDT_CLOCK_EXT 0x4
-
-#define JZ_WDT_CLOCK_DIV_SHIFT 3
-
-#define JZ_WDT_CLOCK_DIV_1(0 << JZ_WDT_CLOCK_DIV_SHIFT)
-#define JZ_WDT_CLOCK_DIV_4(1 << JZ_WDT_CLOCK_DIV_SHIFT)
-#define JZ_WDT_CLOCK_DIV_16 (2 << JZ_WDT_CLOCK_DIV_SHIFT)
-#define JZ_WDT_CLOCK_DIV_64 (3 << JZ_WDT_CLOCK_DIV_SHIFT)
-#define JZ_WDT_CLOCK_DIV_256 (4 << JZ_WDT_CLOCK_DIV_SHIFT)
-#define JZ_WDT_CLOCK_DIV_1024 (5 << JZ_WDT_CLOCK_DIV_SHIFT)
#define DEFAULT_HEARTBEAT 5
#define MAX_HEARTBEAT 2048
@@ -65,7 +49,8 @@ MODULE_PARM_DESC(heartbeat,
struct jz4740_wdt_drvdata {
struct watchdog_device wdt;
void __iomem *base;
- struct clk *rtc_clk;
+ struct clk *clk;
+ unsigned long clk_rate;
};
static int jz4740_wdt_ping(struct watchdog_device *wdt_dev)
@@ -80,31 +65,12 @@ static int jz4740_wdt_set_timeout(struct watchdog_device
*wdt_dev,
unsigned int new_timeout)
{
struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
- unsigned int rtc_clk_rate;
- unsigned int timeout_value;
- unsigned short clock_div = JZ_WDT_CLOCK_DIV_1;
-
- rtc_clk_rate = clk_get_rate(drvdata->rtc_clk);
-
- timeout_value = rtc_clk_rate * new_timeout;
- while (timeout_value > 0x) {
- if (clock_div == JZ_WDT_CLOCK_DIV_1024) {
- /* Requested timeout too high;
- * use highest possible value. */
- timeout_value = 0x;
- break;
- }
- timeout_value >>= 2;
- clock_div += (1 << JZ_WDT_CLOCK_DIV_SHIFT);
- }
+ u16 timeout_value = (u16)(drvdata->clk_rate * new_timeout);
writeb(0x0, drvdata->base + JZ_REG_WDT_COUNTER_ENABLE);
- writew(clock_div, drvdata->base + JZ_REG_WDT_TIMER_CONTROL);
writew((u16)timeout_value, drvdata->base + JZ_REG_WDT_TIMER_DATA);
writew(0x0, drvdata->base + JZ_REG_WDT_TIMER_COUNTER);
- writew(clock_div | JZ_WDT_CLOCK_RTC,
- drvdata->base + JZ_REG_WDT_TIMER_CONTROL);
writeb(0x1, drvdata->base + JZ_REG_WDT_COUNTER_ENABLE);
@@ -114,7 +80,13 @@ static int jz4740_wdt_set_timeout(struct watchdog_device
*wdt_dev,
static int jz4740_wdt_start(struct watchdog_device *wdt_dev)
{
- jz4740_timer_enable_watchdog();
+ struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
+ int ret;
+
+ ret = clk_prepare_enable(drvdata->clk);
+ if (ret)
+ return ret;
+
jz4740_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
return 0;
@@ -125,7 +97,7 @@ static int jz4740_wdt_stop(struct
[PATCH v8 05/26] clocksource: Add driver for the Ingenic JZ47xx OST
From: Maarten ter Huurne
OST is the OS Timer, a 64-bit timer/counter with buffered reading.
SoCs before the JZ4770 had (if any) a 32-bit OST; the JZ4770 and
JZ4780 have a 64-bit OST.
This driver will register both a clocksource and a sched_clock to the
system.
Signed-off-by: Maarten ter Huurne
Signed-off-by: Paul Cercueil
---
Notes:
v5: New patch
v6: - Get rid of SoC IDs; pass pointer to ingenic_ost_soc_info as
devicetree match data instead.
- Use device_get_match_data() instead of the of_* variant
- Handle error of dev_get_regmap() properly
v7: Fix section mismatch by using builtin_platform_driver_probe()
v8: builtin_platform_driver_probe() does not work anymore in
4.20-rc6? The probe function won't be called. Work around this
for now by using late_initcall.
drivers/clocksource/Kconfig | 8 ++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/ingenic-ost.c | 215 ++
3 files changed, 224 insertions(+)
create mode 100644 drivers/clocksource/ingenic-ost.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 4e69af15c3e7..e0646878b0de 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -648,4 +648,12 @@ config INGENIC_TIMER
help
Support for the timer/counter unit of the Ingenic JZ SoCs.
+config INGENIC_OST
+ bool "Ingenic JZ47xx Operating System Timer"
+ depends on MIPS || COMPILE_TEST
+ depends on COMMON_CLK
+ select INGENIC_TIMER
+ help
+ Support for the OS Timer of the Ingenic JZ4770 or similar SoC.
+
endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 7c8f790dcf67..7faa8108574a 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_ASM9260_TIMER) += asm9260_timer.o
obj-$(CONFIG_H8300_TMR8) += h8300_timer8.o
obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
+obj-$(CONFIG_INGENIC_OST) += ingenic-ost.o
obj-$(CONFIG_INGENIC_TIMER)+= ingenic-timer.o
obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
obj-$(CONFIG_X86_NUMACHIP) += numachip.o
diff --git a/drivers/clocksource/ingenic-ost.c
b/drivers/clocksource/ingenic-ost.c
new file mode 100644
index ..cc0fee3efd29
--- /dev/null
+++ b/drivers/clocksource/ingenic-ost.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * JZ47xx SoCs TCU Operating System Timer driver
+ *
+ * Copyright (C) 2016 Maarten ter Huurne
+ * Copyright (C) 2018 Paul Cercueil
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ingenic-timer.h"
+
+#define TCU_OST_TCSR_MASK 0xc0
+#define TCU_OST_TCSR_CNT_MDBIT(15)
+
+#define TCU_OST_CHANNEL15
+
+struct ingenic_ost_soc_info {
+ bool is64bit;
+};
+
+struct ingenic_ost {
+ struct regmap *map;
+ struct clk *clk;
+
+ struct clocksource cs;
+};
+
+static u64 notrace ingenic_ost_read_cntl(void)
+{
+ /* Bypass the regmap here as we must return as soon as possible */
+ return readl(ingenic_tcu_base + TCU_REG_OST_CNTL);
+}
+
+static u64 notrace ingenic_ost_read_cnth(void)
+{
+ /* Bypass the regmap here as we must return as soon as possible */
+ return readl(ingenic_tcu_base + TCU_REG_OST_CNTH);
+}
+
+static u64 notrace ingenic_ost_clocksource_read(struct clocksource *cs)
+{
+ u32 val1, val2;
+ u64 count, recount;
+ s64 diff;
+
+ /*
+* The buffering of the upper 32 bits of the timer prevents wrong
+* results from the bottom 32 bits overflowing due to the timer ticking
+* along. However, it does not prevent wrong results from simultaneous
+* reads of the timer, which could reset the buffer mid-read.
+* Since this kind of wrong read can happen only when the bottom bits
+* overflow, there will be minutes between wrong reads, so if we read
+* twice in succession, at least one of the reads will be correct.
+*/
+
+ /* Bypass the regmap here as we must return as soon as possible */
+ val1 = readl(ingenic_tcu_base + TCU_REG_OST_CNTL);
+ val2 = readl(ingenic_tcu_base + TCU_REG_OST_CNTHBUF);
+ count = (u64)val1 | (u64)val2 << 32;
+
+ val1 = readl(ingenic_tcu_base + TCU_REG_OST_CNTL);
+ val2 = readl(ingenic_tcu_base + TCU_REG_OST_CNTHBUF);
+ recount = (u64)val1 | (u64)val2 << 32;
+
+ /*
+* A wrong read will produce a result that is 1<<32 too high: the bottom
+* part from before overflow and the upper part from after overflow.
+* Therefore, the lower value of the two reads is the correct value.
+*/
+
+ diff = (s64)(recount - count);
+ if (unlikely(diff < 0))
+
[PATCH v8 16/26] clk: jz4740: Add TCU clock
Add the missing TCU clock to the list of clocks supplied by the CGU for
the JZ4740 SoC.
Signed-off-by: Paul Cercueil
Acked-by: Stephen Boyd
Acked-by: Rob Herring
---
Notes:
v5: New patch
v6: No change
v7: No change
v8: No change
drivers/clk/ingenic/jz4740-cgu.c | 6 ++
include/dt-bindings/clock/jz4740-cgu.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/clk/ingenic/jz4740-cgu.c b/drivers/clk/ingenic/jz4740-cgu.c
index 4479c102e899..d8ac7f2e183a 100644
--- a/drivers/clk/ingenic/jz4740-cgu.c
+++ b/drivers/clk/ingenic/jz4740-cgu.c
@@ -211,6 +211,12 @@ static const struct ingenic_cgu_clk_info
jz4740_cgu_clocks[] = {
.parents = { JZ4740_CLK_EXT, -1, -1, -1 },
.gate = { CGU_REG_CLKGR, 5 },
},
+
+ [JZ4740_CLK_TCU] = {
+ "tcu", CGU_CLK_GATE,
+ .parents = { JZ4740_CLK_EXT, -1, -1, -1 },
+ .gate = { CGU_REG_CLKGR, 1 },
+ },
};
static void __init jz4740_cgu_init(struct device_node *np)
diff --git a/include/dt-bindings/clock/jz4740-cgu.h
b/include/dt-bindings/clock/jz4740-cgu.h
index 6ed83f926ae7..e82d77028581 100644
--- a/include/dt-bindings/clock/jz4740-cgu.h
+++ b/include/dt-bindings/clock/jz4740-cgu.h
@@ -34,5 +34,6 @@
#define JZ4740_CLK_ADC 19
#define JZ4740_CLK_I2C 20
#define JZ4740_CLK_AIC 21
+#define JZ4740_CLK_TCU 22
#endif /* __DT_BINDINGS_CLOCK_JZ4740_CGU_H__ */
--
2.11.0
