Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall
* Reshetova, Elena wrote: > > * Reshetova, Elena wrote: > > > > > CONFIG_PAGE_TABLE_ISOLATION=n: > > > > > > base: Simple syscall: 0.0510 microseconds > > > get_random_bytes(4096 bytes buffer): Simple syscall: 0.0597 microseconds > > > > > > So, pure speed wise get_random_bytes() with 1 page per-cpu buffer wins. > > > > It still adds +17% overhead to the system call path, which is sad. > > Why is it so expensive? > > I guess I can experiment further with buffer size increase and/or > using HW acceleration (I mostly played around different rdrand paths now). > > What would be acceptable overheard approximately (so that I know how > much I need to squeeze this thing)? As much as possible? No idea, I'm sad about anything that is more than 0%, and I'd be *really* sad about anything more than say 1-2%. I find it ridiculous that even with 4K blocked get_random_bytes(), which gives us 32k bits, which with 5 bits should amortize the RNG call to something like "once per 6553 calls", we still see 17% overhead? It's either a measurement artifact, or something doesn't compute. Thanks, Ingo
[PATCH v2 1/3] x86/tsc: use CPUID.0x16 to calculate missing crystal frequency
native_calibrate_tsc() had a data mapping Intel CPU families
and crystal clock speed, but hardcoded tables are not ideal, and this
approach was already problematic at least in the Skylake X case, as
seen in commit b51120309348 ("x86/tsc: Fix erroneous TSC rate on Skylake
Xeon").
By examining CPUID data from http://instlatx64.atw.hu/ and units
in the lab, we have found that 3 different scenarios need to be dealt
with, and we can eliminate most of the hardcoded data using an approach a
little more advanced than before:
1. ApolloLake, GeminiLake, CannonLake (and presumably all new chipsets
from this point) report the crystal frequency directly via CPUID.0x15.
That's definitive data that we can rely upon.
2. Skylake, Kabylake and all variants of those two chipsets report a
crystal frequency of zero, however we can calculate the crystal clock
speed by condidering data from CPUID.0x16.
This method correctly distinguishes between the two crystal clock
frequencies present on different Skylake X variants that caused
headaches before.
As the calculations do not quite match the previously-hardcoded values
in some cases (e.g. 23913043Hz instead of 24MHz), TSC refinement is
enabled on all platforms where we had to calculate the crystal
frequency in this way.
3. Denverton (GOLDMONT_X) reports a crystal frequency of zero and does
not support CPUID.0x16, so we leave this entry hardcoded.
Link: https://lkml.kernel.org/r/20190419083533.32388-1-dr...@endlessm.com
Suggested-by: Thomas Gleixner
Signed-off-by: Daniel Drake
---
Notes:
v2:
- Clarify the situation around Skylake X better.
- Enable TSC refinement when we had to calculate the crystal clock,
in case slight differences in the calculation result cause problems
similar to those reported earlier on Skylake X.
arch/x86/kernel/tsc.c | 47 +--
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 15b5e98a86f9..6e6d933fb99c 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -631,31 +631,38 @@ unsigned long native_calibrate_tsc(void)
crystal_khz = ecx_hz / 1000;
- if (crystal_khz == 0) {
- switch (boot_cpu_data.x86_model) {
- case INTEL_FAM6_SKYLAKE_MOBILE:
- case INTEL_FAM6_SKYLAKE_DESKTOP:
- case INTEL_FAM6_KABYLAKE_MOBILE:
- case INTEL_FAM6_KABYLAKE_DESKTOP:
- crystal_khz = 24000;/* 24.0 MHz */
- break;
- case INTEL_FAM6_ATOM_GOLDMONT_X:
- crystal_khz = 25000;/* 25.0 MHz */
- break;
- case INTEL_FAM6_ATOM_GOLDMONT:
- crystal_khz = 19200;/* 19.2 MHz */
- break;
- }
- }
+ /*
+* Denverton SoCs don't report crystal clock, and also don't support
+* CPUID.0x16 for the calculation below, so hardcode the 25MHz crystal
+* clock.
+*/
+ if (crystal_khz == 0 &&
+ boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT_X)
+ crystal_khz = 25000;
- if (crystal_khz == 0)
- return 0;
/*
-* TSC frequency determined by CPUID is a "hardware reported"
+* TSC frequency reported directly by CPUID is a "hardware reported"
* frequency and is the most accurate one so far we have. This
* is considered a known frequency.
*/
- setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
+ if (crystal_khz != 0)
+ setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
+
+ /*
+* Some Intel SoCs like Skylake and Kabylake don't report the crystal
+* clock, but we can easily calculate it to a high degree of accuracy
+* by considering the crystal ratio and the CPU speed.
+*/
+ if (crystal_khz == 0 && boot_cpu_data.cpuid_level >= 0x16) {
+ unsigned int eax_base_mhz, ebx, ecx, edx;
+
+ cpuid(0x16, _base_mhz, , , );
+ crystal_khz = eax_base_mhz * 1000 *
+ eax_denominator / ebx_numerator;
+ }
+
+ if (crystal_khz == 0)
+ return 0;
/*
* For Atom SoCs TSC is the only reliable clocksource.
--
2.20.1
[PATCH v2 2/3] x86/apic: rename lapic_timer_frequency to lapic_timer_period
This variable is a period unit (number of clock cycles per jiffy),
not a frequency (which is number of cycles per second).
Give it a more appropriate name.
Suggested-by: Ingo Molnar
Signed-off-by: Daniel Drake
---
arch/x86/include/asm/apic.h| 2 +-
arch/x86/kernel/apic/apic.c| 20 ++--
arch/x86/kernel/cpu/mshyperv.c | 4 ++--
arch/x86/kernel/cpu/vmware.c | 2 +-
arch/x86/kernel/jailhouse.c| 2 +-
arch/x86/kernel/tsc_msr.c | 4 ++--
6 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 130e81e10fc7..fc505a84aa93 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -52,7 +52,7 @@ extern unsigned int apic_verbosity;
extern int local_apic_timer_c2_ok;
extern int disable_apic;
-extern unsigned int lapic_timer_frequency;
+extern unsigned int lapic_timer_period;
extern enum apic_intr_mode_id apic_intr_mode;
enum apic_intr_mode_id {
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index ab6af775f06c..93de7862eef8 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -194,7 +194,7 @@ static struct resource lapic_resource = {
.flags = IORESOURCE_MEM | IORESOURCE_BUSY,
};
-unsigned int lapic_timer_frequency = 0;
+unsigned int lapic_timer_period = 0;
static void apic_pm_activate(void);
@@ -500,7 +500,7 @@ lapic_timer_set_periodic_oneshot(struct clock_event_device
*evt, bool oneshot)
if (evt->features & CLOCK_EVT_FEAT_DUMMY)
return 0;
- __setup_APIC_LVTT(lapic_timer_frequency, oneshot, 1);
+ __setup_APIC_LVTT(lapic_timer_period, oneshot, 1);
return 0;
}
@@ -804,11 +804,11 @@ calibrate_by_pmtimer(long deltapm, long *delta, long
*deltatsc)
static int __init lapic_init_clockevent(void)
{
- if (!lapic_timer_frequency)
+ if (!lapic_timer_period)
return -1;
/* Calculate the scaled math multiplication factor */
- lapic_clockevent.mult = div_sc(lapic_timer_frequency/APIC_DIVISOR,
+ lapic_clockevent.mult = div_sc(lapic_timer_period/APIC_DIVISOR,
TICK_NSEC, lapic_clockevent.shift);
lapic_clockevent.max_delta_ns =
clockevent_delta2ns(0x7FFF, _clockevent);
@@ -838,7 +838,7 @@ static int __init calibrate_APIC_clock(void)
*/
if (!lapic_init_clockevent()) {
apic_printk(APIC_VERBOSE, "lapic timer already calibrated %d\n",
- lapic_timer_frequency);
+ lapic_timer_period);
/*
* Direct calibration methods must have an always running
* local APIC timer, no need for broadcast timer.
@@ -883,13 +883,13 @@ static int __init calibrate_APIC_clock(void)
pm_referenced = !calibrate_by_pmtimer(lapic_cal_pm2 - lapic_cal_pm1,
, );
- lapic_timer_frequency = (delta * APIC_DIVISOR) / LAPIC_CAL_LOOPS;
+ lapic_timer_period = (delta * APIC_DIVISOR) / LAPIC_CAL_LOOPS;
lapic_init_clockevent();
apic_printk(APIC_VERBOSE, ". delta %ld\n", delta);
apic_printk(APIC_VERBOSE, ". mult: %u\n", lapic_clockevent.mult);
apic_printk(APIC_VERBOSE, ". calibration result: %u\n",
- lapic_timer_frequency);
+ lapic_timer_period);
if (boot_cpu_has(X86_FEATURE_TSC)) {
apic_printk(APIC_VERBOSE, ". CPU clock speed is "
@@ -900,13 +900,13 @@ static int __init calibrate_APIC_clock(void)
apic_printk(APIC_VERBOSE, ". host bus clock speed is "
"%u.%04u MHz.\n",
- lapic_timer_frequency / (100 / HZ),
- lapic_timer_frequency % (100 / HZ));
+ lapic_timer_period / (100 / HZ),
+ lapic_timer_period % (100 / HZ));
/*
* Do a sanity check on the APIC calibration result
*/
- if (lapic_timer_frequency < (100 / HZ)) {
+ if (lapic_timer_period < (100 / HZ)) {
local_irq_enable();
pr_warning("APIC frequency too slow, disabling apic timer\n");
return -1;
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 3fa238a137d2..faae6115ddef 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -270,9 +270,9 @@ static void __init ms_hyperv_init_platform(void)
rdmsrl(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
hv_lapic_frequency = div_u64(hv_lapic_frequency, HZ);
- lapic_timer_frequency = hv_lapic_frequency;
+ lapic_timer_period = hv_lapic_frequency;
pr_info("Hyper-V: LAPIC Timer Frequency: %#x\n",
- lapic_timer_frequency);
+
[PATCH v2 3/3] x86/tsc: set LAPIC timer period to crystal clock frequency
The APIC timer calibration (calibrate_APIC_timer()) can be skipped in cases where we know the APIC timer frequency. On Intel SoCs, we believe that the APIC is fed by the crystal clock; this would make sense, and the crystal clock frequency has been verified against the APIC timer calibration result on ApolloLake, GeminiLake, Kabylake, CoffeeLake, WhiskeyLake and AmberLake. Set lapic_timer_period based on the crystal clock frequency accordingly. APIC timer calibration would normally be skipped on modern CPUs by nature of the TSC deadline timer being used instead, however this change is still potentially useful, e.g. if the TSC deadline timer has been disabled with a kernel parameter. calibrate_APIC_timer() uses the legacy timer, but we are seeing new platforms that omit such legacy functionality, so avoiding such codepaths is becoming more important. Link: https://lkml.kernel.org/r/20190419083533.32388-1-dr...@endlessm.com Link: https://lkml.kernel.org/r/alpine.deb.2.21.1904031206440.1...@nanos.tec.linutronix.de Suggested-by: Thomas Gleixner Signed-off-by: Daniel Drake --- Notes: v2: - remove unnecessary braces - use newly renamed variable lapic_timer_period arch/x86/kernel/tsc.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index 6e6d933fb99c..8f47c4862c56 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -671,6 +671,16 @@ unsigned long native_calibrate_tsc(void) if (boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT) setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE); +#ifdef CONFIG_X86_LOCAL_APIC + /* +* The local APIC appears to be fed by the core crystal clock +* (which sounds entirely sensible). We can set the global +* lapic_timer_period here to avoid having to calibrate the APIC +* timer later. +*/ + lapic_timer_period = crystal_khz * 1000 / HZ; +#endif + return crystal_khz * ebx_numerator / eax_denominator; } -- 2.20.1
[PATCH] tty: serial_core: Fix the incorrect configuration of baud rate and data length at the console serial port resume
When userspace opens a serial port for console, uart_port_startup()
is called. This function assigns the uport->cons->cflag value to
TTY->termios.c_cflag, then it is cleared to 0. When the user space
closes this serial port, the TTY structure will be released, and at
this time uport->cons->cflag has also been cleared.
On the Spreadtrum platform, in some special scenarios, like charging mode,
userspace needs to close the console, which means the uport->cons->cflag
has also been cleared. But printing logs is still needed in the kernel. So
when system enters suspend and resume, the console needs to be configure
the baud rate and data length of the serial port according to its own cflag
when resuming the console port. At this time, the cflag is 0, which will
cause serial port to produce configuration errors that do not meet user
expectations.
To fix this, assigning the TTY->termios.c_cflag value to uport->cons->cflag
before the userspace closes this console serial port. It will ensure that
the correct cflag value can be gotten when the console serial port was
resumed.
Signed-off-by: Lanqing Liu
---
drivers/tty/serial/serial_core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 351843f..f233cf8 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1539,6 +1539,7 @@ static void uart_set_termios(struct tty_struct *tty,
static void uart_close(struct tty_struct *tty, struct file *filp)
{
struct uart_state *state = tty->driver_data;
+ struct uart_port *uport;
if (!state) {
struct uart_driver *drv = tty->driver->driver_state;
@@ -1553,6 +1554,9 @@ static void uart_close(struct tty_struct *tty, struct
file *filp)
}
pr_debug("uart_close(%d) called\n", tty->index);
+ uport = uart_port_check(state);
+ if (uport && uart_console(uport))
+ uport->cons->cflag = tty->termios.c_cflag;
tty_port_close(tty->port, tty, filp);
}
--
1.9.1
general protection fault in do_move_mount
Hello, syzbot found the following crash on: HEAD commit:80f23212 Merge git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11ab8dd0a0 kernel config: https://syzkaller.appspot.com/x/.config?x=40a58b399941db7e dashboard link: https://syzkaller.appspot.com/bug?extid=494c7ddf66acac0ad747 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+494c7ddf66acac0ad...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 8663 Comm: syz-executor.3 Not tainted 5.1.0+ #3 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:do_move_mount.isra.0+0x5eb/0xe00 fs/namespace.c:2602 Code: ff 45 89 e6 e9 a0 fb ff ff e8 d1 df b5 ff 48 8b 85 50 ff ff ff 48 8d 78 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 6d 07 00 00 48 8b 85 50 ff ff ff 31 ff 4c 8b 78 RSP: 0018:888067d97ca8 EFLAGS: 00010206 RAX: dc00 RBX: 888067d97e18 RCX: c9000c432000 RDX: 0009 RSI: 81baa93f RDI: 0048 RBP: 888067d97d88 R08: 88808a6020c0 R09: ed1015d26be0 R10: ed1015d26bdf R11: 8880ae935efb R12: 88809e88f700 R13: 88808a079620 R14: 888067d97e40 R15: 8880a99cf8f0 FS: 7fb568cc3700() GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 98704bb8 CR3: 8e438000 CR4: 001426e0 Call Trace: do_move_mount_old fs/namespace.c:2662 [inline] do_mount+0xee7/0x1c00 fs/namespace.c:3108 ksys_mount+0xdb/0x150 fs/namespace.c:3319 __do_sys_mount fs/namespace.c: [inline] __se_sys_mount fs/namespace.c:3330 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3330 do_syscall_64+0x103/0x670 arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x458da9 Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fb568cc2c78 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: 0005 RCX: 00458da9 RDX: RSI: 2340 RDI: 2000 RBP: 0073bf00 R08: R09: R10: 2002 R11: 0246 R12: 7fb568cc36d4 R13: 004c4dfd R14: 004d8ac8 R15: Modules linked in: ---[ end trace f3c85670e73e74c9 ]--- RIP: 0010:do_move_mount.isra.0+0x5eb/0xe00 fs/namespace.c:2602 Code: ff 45 89 e6 e9 a0 fb ff ff e8 d1 df b5 ff 48 8b 85 50 ff ff ff 48 8d 78 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 6d 07 00 00 48 8b 85 50 ff ff ff 31 ff 4c 8b 78 RSP: 0018:888067d97ca8 EFLAGS: 00010206 RAX: dc00 RBX: 888067d97e18 RCX: c9000c432000 RDX: 0009 RSI: 81baa93f RDI: 0048 RBP: 888067d97d88 R08: 88808a6020c0 R09: ed1015d26be0 R10: ed1015d26bdf R11: 8880ae935efb R12: 88809e88f700 R13: 88808a079620 R14: 888067d97e40 R15: 8880a99cf8f0 FS: 7fb568cc3700() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0070d158 CR3: 8e438000 CR4: 001426f0 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
linux-next: manual merge of the akpm-current tree with the rdma tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
drivers/infiniband/core/umem.c
between commit:
db6c6774af0d ("RDMA/umem: Remove hugetlb flag")
from the rdma tree and commit:
c041ba1a3294 ("mm/gup: replace get_user_pages_longterm() with FOLL_LONGTERM")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/core/umem.c
index 0a23048db523,31191f098e73..
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@@ -295,10 -189,11 +295,11 @@@ struct ib_umem *ib_umem_get(struct ib_u
while (npages) {
down_read(>mmap_sem);
- ret = get_user_pages_longterm(cur_base,
+ ret = get_user_pages(cur_base,
min_t(unsigned long, npages,
PAGE_SIZE / sizeof (struct page *)),
-gup_flags, page_list, NULL);
+gup_flags | FOLL_LONGTERM,
- page_list, vma_list);
++ page_list, NULL);
if (ret < 0) {
up_read(>mmap_sem);
goto umem_release;
pgpIuUrntVmty.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with the parisc-hd tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/parisc/mm/init.c
between commit:
98429dded340 ("parisc: Enable SPARSEMEM_VMEMMAP")
from the parisc-hd tree and commit:
2e5adbd9e97a ("initramfs: provide a generic free_initrd_mem implementation")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/parisc/mm/init.c
index 6fa6d3b1d3f4,437d4c35c562..
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@@ -928,18 -921,3 +928,11 @@@ void flush_tlb_all(void
spin_unlock(_lock);
}
#endif
+
- #ifdef CONFIG_BLK_DEV_INITRD
- void free_initrd_mem(unsigned long start, unsigned long end)
- {
- free_reserved_area((void *)start, (void *)end, -1, "initrd");
- }
- #endif
-
+#if defined(CONFIG_SPARSEMEM) && defined(CONFIG_SPARSEMEM_VMEMMAP)
+int __meminit vmemmap_populate(unsigned long vstart, unsigned long vend,
+ int node, struct vmem_altmap *altmap)
+{
+ return vmemmap_populate_basepages(vstart, vend, node);
+}
+#endif
pgpGBBeB2EPt2.pgp
Description: OpenPGP digital signature
Re: [PATCH] cifs: fix checkpatch warnings and normalize strings
Merged into cifs-2.6.git for-next with minor cleanup. I also
(ironically) had to change the patch title since
checkpatch complained about mentioning "checkpatch" in the patch name.
Also FYI - since it didn't merge cleanly, I had to add one of the
changes manually as a distinct patch. See attached.
On Wed, May 8, 2019 at 2:37 PM Christoph Probst via samba-technical
wrote:
>
> Fix checkpatch warnings/errors in smb2ops.c except "LONG_LINE". Add missing
> linebreaks, indentings, __func__. Remove void-returns, unneeded braces.
>
> Add SPDX License Header.
>
> Add missing "\n" and capitalize first letter in some cifs_dbg() strings.
>
> Signed-off-by: Christoph Probst
> ---
> fs/cifs/smb2ops.c | 46 +++---
> 1 file changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
> index c36ff0d..9bda7e5 100644
> --- a/fs/cifs/smb2ops.c
> +++ b/fs/cifs/smb2ops.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * SMB2 version specific operations
> *
> @@ -282,7 +283,7 @@ smb2_find_mid(struct TCP_Server_Info *server, char *buf)
> __u64 wire_mid = le64_to_cpu(shdr->MessageId);
>
> if (shdr->ProtocolId == SMB2_TRANSFORM_PROTO_NUM) {
> - cifs_dbg(VFS, "encrypted frame parsing not supported yet");
> + cifs_dbg(VFS, "Encrypted frame parsing not supported yet\n");
> return NULL;
> }
>
> @@ -324,6 +325,7 @@ static int
> smb2_negotiate(const unsigned int xid, struct cifs_ses *ses)
> {
> int rc;
> +
> ses->server->CurrentMid = 0;
> rc = SMB2_negotiate(xid, ses);
> /* BB we probably don't need to retry with modern servers */
> @@ -789,8 +791,6 @@ smb3_qfs_tcon(const unsigned int xid, struct cifs_tcon
> *tcon)
> SMB2_close(xid, tcon, fid.persistent_fid, fid.volatile_fid);
> else
> close_shroot(>crfid);
> -
> - return;
> }
>
> static void
> @@ -818,7 +818,6 @@ smb2_qfs_tcon(const unsigned int xid, struct cifs_tcon
> *tcon)
> SMB2_QFS_attr(xid, tcon, fid.persistent_fid, fid.volatile_fid,
> FS_DEVICE_INFORMATION);
> SMB2_close(xid, tcon, fid.persistent_fid, fid.volatile_fid);
> - return;
> }
>
> static int
> @@ -906,9 +905,8 @@ move_smb2_ea_to_cifs(char *dst, size_t dst_size,
> value = >ea_data[src->ea_name_length + 1];
> value_len = (size_t)le16_to_cpu(src->ea_value_length);
>
> - if (name_len == 0) {
> + if (name_len == 0)
> break;
> - }
>
> if (src_size < 8 + name_len + 1 + value_len) {
> cifs_dbg(FYI, "EA entry goes beyond length of
> list\n");
> @@ -1161,6 +1159,7 @@ static void
> smb2_clear_stats(struct cifs_tcon *tcon)
> {
> int i;
> +
> for (i = 0; i < NUMBER_OF_SMB2_COMMANDS; i++) {
> atomic_set(>stats.smb2_stats.smb2_com_sent[i], 0);
> atomic_set(>stats.smb2_stats.smb2_com_failed[i], 0);
> @@ -1501,7 +1500,7 @@ smb2_copychunk_range(const unsigned int xid,
> if (pcchunk == NULL)
> return -ENOMEM;
>
> - cifs_dbg(FYI, "in smb2_copychunk_range - about to call request res
> key\n");
> + cifs_dbg(FYI, "%s: about to call request res key\n", __func__);
> /* Request a key from the server to identify the source of the copy */
> rc = SMB2_request_res_key(xid, tlink_tcon(srcfile->tlink),
> srcfile->fid.persistent_fid,
> @@ -1621,6 +1620,7 @@ static unsigned int
> smb2_read_data_offset(char *buf)
> {
> struct smb2_read_rsp *rsp = (struct smb2_read_rsp *)buf;
> +
> return rsp->DataOffset;
> }
>
> @@ -1749,7 +1749,7 @@ smb2_duplicate_extents(const unsigned int xid,
> dup_ext_buf.SourceFileOffset = cpu_to_le64(src_off);
> dup_ext_buf.TargetFileOffset = cpu_to_le64(dest_off);
> dup_ext_buf.ByteCount = cpu_to_le64(len);
> - cifs_dbg(FYI, "duplicate extents: src off %lld dst off %lld len %lld",
> + cifs_dbg(FYI, "Duplicate extents: src off %lld dst off %lld len
> %lld\n",
> src_off, dest_off, len);
>
> rc = smb2_set_file_size(xid, tcon, trgtfile, dest_off + len, false);
> @@ -1766,7 +1766,7 @@ smb2_duplicate_extents(const unsigned int xid,
> _data_len);
>
> if (ret_data_len > 0)
> - cifs_dbg(FYI, "non-zero response length in duplicate
> extents");
> + cifs_dbg(FYI, "Non-zero response length in duplicate
> extents\n");
>
> duplicate_extents_out:
> return rc;
> @@ -1947,9 +1947,9 @@ smb2_close_dir(const unsigned int xid, struct cifs_tcon
> *tcon,
> }
>
> /*
> -* If we negotiate SMB2 protocol and get STATUS_PENDING - update
> -* the number of credits and return true. Otherwise - return false.
> -*/
> + * If we negotiate SMB2
RE: [EXT] Re: [PATCH 1/2] i2c: imx: I2C Driver doesn't consider I2C_IPGCLK_SEL RCW bit when using ls1046a SoC
-Original Message-
From: Sumit Batra
Sent: Thursday, May 9, 2019 10:06 AM
To: Chuanhua Han ; Sascha Hauer
Cc: shawn...@kernel.org; Leo Li ; robh...@kernel.org;
mark.rutl...@arm.com; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
feste...@gmail.com; dl-linux-imx ;
wsa+rene...@sang-engineering.com; u.kleine-koe...@pengutronix.de;
e...@deif.com; li...@rempel-privat.de; l.st...@pengutronix.de; p...@axentia.se
Subject: RE: [EXT] Re: [PATCH 1/2] i2c: imx: I2C Driver doesn't consider
I2C_IPGCLK_SEL RCW bit when using ls1046a SoC
Hi Sascha,
Please check my comment
-Original Message-
From: Chuanhua Han
Sent: Wednesday, May 8, 2019 5:05 PM
To: Sascha Hauer
Cc: shawn...@kernel.org; Leo Li ; robh...@kernel.org;
mark.rutl...@arm.com; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
feste...@gmail.com; dl-linux-imx ;
wsa+rene...@sang-engineering.com; u.kleine-koe...@pengutronix.de;
e...@deif.com; li...@rempel-privat.de; l.st...@pengutronix.de; p...@axentia.se;
Sumit Batra
Subject: RE: [EXT] Re: [PATCH 1/2] i2c: imx: I2C Driver doesn't consider
I2C_IPGCLK_SEL RCW bit when using ls1046a SoC
> -Original Message-
> From: Sascha Hauer
> Sent: 2019年5月6日 15:38
> To: Chuanhua Han
> Cc: shawn...@kernel.org; Leo Li ;
> robh...@kernel.org; mark.rutl...@arm.com;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; feste...@gmail.com; dl-linux-imx
> ; wsa+rene...@sang-engineering.com;
> u.kleine-koe...@pengutronix.de; e...@deif.com; li...@rempel-privat.de;
> l.st...@pengutronix.de; p...@axentia.se; Sumit Batra
>
> Subject: Re: [EXT] Re: [PATCH 1/2] i2c: imx: I2C Driver doesn't
> consider I2C_IPGCLK_SEL RCW bit when using ls1046a SoC
>
> Caution: EXT Email
>
> On Sat, May 04, 2019 at 09:28:48AM +, Chuanhua Han wrote:
> >
> >
> > > -Original Message-
> > > From: Sascha Hauer
> > > Sent: 2019年4月30日 20:51
> > > To: Chuanhua Han
> > > Cc: shawn...@kernel.org; Leo Li ;
> > > robh...@kernel.org; mark.rutl...@arm.com;
> > > linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org;
> > > devicet...@vger.kernel.org; feste...@gmail.com; dl-linux-imx
> > > ; wsa+rene...@sang-engineering.com;
> > > u.kleine-koe...@pengutronix.de; e...@deif.com;
> > > li...@rempel-privat.de; l.st...@pengutronix.de; p...@axentia.se;
> > > Sumit Batra
> > > Subject: [EXT] Re: [PATCH 1/2] i2c: imx: I2C Driver doesn't
> > > consider I2C_IPGCLK_SEL RCW bit when using ls1046a SoC
> > >
> > > Caution: EXT Email
> > >
> > > On Tue, Apr 30, 2019 at 12:47:18PM +0800, Chuanhua Han wrote:
> > > > The current kernel driver does not consider I2C_IPGCLK_SEL (424
> > > > bit of
> > > > RCW) in deciding i2c_clk_rate in function i2c_imx_set_clk() { 0
> > > > Platform clock/4, 1 Platform clock/2}.
> > > >
> > > > When using ls1046a SoC, this populates incorrect value in IBFD
> > > > register if I2C_IPGCLK_SEL = 0, which generates half of the desired
> > > > Clock.
> > > >
> > > > Therefore, if ls1046a SoC is used, we need to set the i2c clock
> > > > according to the corresponding RCW.
> > >
> > > So the clock driver reports the wrong clock. Please fix the clock driver
> > > then.
> > No, this is a problem with the i2c driver. It is not a problem with
> > the clock driver, so the i2c driver needs to be modified.
>
> So how does this RCW bit get evaluated?
According to the reference manual
> only one clock goes to the i2c module (described as 1/2 Platform
> Clock) and the i2c module only takes one clock. So it seems there must
> be a /2 divider somewhere, either in each i2c module or somewhere
> outside. Can your IC guys tell you where it is?
I need to confirm this with the IC team
[Sumit Batra] There are 2 places where clock division takes place -
1) There is a clock divider outside of I2C block, which makes the
clock reaching I2C module as - Platform Clock/2
2) There is another clock divider which specifically divides the clock
to the I2C block, based on RCW bit 424 (if 424th bit is 0 then the baud clock
source is Platform Clock/4, if 424th bit is 1 then it remains Platform Clock/2)
3) Now based on the what is the desired SCL value (100KHz etc)
and the clock which is received by I2C block, there is a calculation that goes
on inside the I2C driver module which is used to map a value in this
imx_i2c_clk_div table.
This value is used to program the IMX_I2C_IFDR register of
the I2C block. Now if we don't consider the RCW bit 424 in our I2C driver
calculation then the IMX_I2C_IFDR value that gets set makes SCL half of what is
desired by the user.
This is because if you make the RCW 424th bit as 0 then
anyhow I2C block (hardware) will receive
Re: [GIT] IDE
The pull request you sent on Wed, 08 May 2019 16:53:20 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide refs/heads/master has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/89c3b37af87ec183b666d83428cb28cc421671a6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH] i2c: sh_mobile: Fix compilation warning
This currently generates a warning:
drivers/i2c/busses/i2c-sh_mobile.c: In function 'sh_mobile_i2c_isr':
drivers/i2c/busses/i2c-sh_mobile.c:399:26: warning: 'data' may be used
uninitialized in this function [-Wmaybe-uninitialized]
Though the code looks okay and shouldn't ever use the variable
uninitialized.
Fix the warning by moving the code around and getting rid of 'data'.
Compile tested only.
Signed-off-by: Viresh Kumar
---
drivers/i2c/busses/i2c-sh_mobile.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c
b/drivers/i2c/busses/i2c-sh_mobile.c
index 8777af4c695e..945eb8504fb7 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -369,7 +369,6 @@ static int sh_mobile_i2c_isr_tx(struct sh_mobile_i2c_data
*pd)
static int sh_mobile_i2c_isr_rx(struct sh_mobile_i2c_data *pd)
{
- unsigned char data;
int real_pos;
/* switch from TX (address) to RX (data) adds two interrupts */
@@ -390,13 +389,11 @@ static int sh_mobile_i2c_isr_rx(struct sh_mobile_i2c_data
*pd)
if (real_pos < 0)
i2c_op(pd, OP_RX_STOP);
else
- data = i2c_op(pd, OP_RX_STOP_DATA);
+ pd->msg->buf[real_pos] = i2c_op(pd, OP_RX_STOP_DATA);
} else if (real_pos >= 0) {
- data = i2c_op(pd, OP_RX);
+ pd->msg->buf[real_pos] = i2c_op(pd, OP_RX);
}
- if (real_pos >= 0)
- pd->msg->buf[real_pos] = data;
done:
pd->pos++;
return pd->pos == (pd->msg->len + 2);
--
2.21.0.rc0.269.g1a574e7a288b
Re: [PATCH 4/5] mm/hmm: hmm_vma_fault() doesn't always call hmm_range_unregister()
On Tue, May 7, 2019 at 11:42 PM Ralph Campbell wrote:
>
>
> On 5/7/19 6:15 AM, Souptick Joarder wrote:
> > On Tue, May 7, 2019 at 5:00 AM wrote:
> >>
> >> From: Ralph Campbell
> >>
> >> The helper function hmm_vma_fault() calls hmm_range_register() but is
> >> missing a call to hmm_range_unregister() in one of the error paths.
> >> This leads to a reference count leak and ultimately a memory leak on
> >> struct hmm.
> >>
> >> Always call hmm_range_unregister() if hmm_range_register() succeeded.
> >
> > How about * Call hmm_range_unregister() in error path if
> > hmm_range_register() succeeded* ?
>
> Sure, sounds good.
> I'll include that in v2.
Thanks.
>
> >>
> >> Signed-off-by: Ralph Campbell
> >> Cc: John Hubbard
> >> Cc: Ira Weiny
> >> Cc: Dan Williams
> >> Cc: Arnd Bergmann
> >> Cc: Balbir Singh
> >> Cc: Dan Carpenter
> >> Cc: Matthew Wilcox
> >> Cc: Souptick Joarder
> >> Cc: Andrew Morton
> >> ---
> >> include/linux/hmm.h | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> >> index 35a429621e1e..fa0671d67269 100644
> >> --- a/include/linux/hmm.h
> >> +++ b/include/linux/hmm.h
> >> @@ -559,6 +559,7 @@ static inline int hmm_vma_fault(struct hmm_range
> >> *range, bool block)
> >> return (int)ret;
> >>
> >> if (!hmm_range_wait_until_valid(range,
> >> HMM_RANGE_DEFAULT_TIMEOUT)) {
> >> + hmm_range_unregister(range);
> >> /*
> >> * The mmap_sem was taken by driver we release it here and
> >> * returns -EAGAIN which correspond to mmap_sem have been
> >> @@ -570,13 +571,13 @@ static inline int hmm_vma_fault(struct hmm_range
> >> *range, bool block)
> >>
> >> ret = hmm_range_fault(range, block);
> >> if (ret <= 0) {
> >> + hmm_range_unregister(range);
> >
> > what is the reason to moved it up ?
>
> I moved it up because the normal calling pattern is:
> down_read(>mmap_sem)
> hmm_vma_fault()
> hmm_range_register()
> hmm_range_fault()
> hmm_range_unregister()
> up_read(>mmap_sem)
>
> I don't think it is a bug to unlock mmap_sem and then unregister,
> it is just more consistent nesting.
Ok. I think, adding it in change log will be helpful :)
>
> >> if (ret == -EBUSY || !ret) {
> >> /* Same as above, drop mmap_sem to match old API.
> >> */
> >> up_read(>vma->vm_mm->mmap_sem);
> >> ret = -EBUSY;
> >> } else if (ret == -EAGAIN)
> >> ret = -EBUSY;
> >> - hmm_range_unregister(range);
> >> return ret;
> >> }
> >> return 0;
> >> --
> >> 2.20.1
> >>
RE: [EXT] Re: [PATCH 1/2] i2c: imx: I2C Driver doesn't consider I2C_IPGCLK_SEL RCW bit when using ls1046a SoC
Hi Sascha,
Please check my comment
-Original Message-
From: Chuanhua Han
Sent: Wednesday, May 8, 2019 5:05 PM
To: Sascha Hauer
Cc: shawn...@kernel.org; Leo Li ; robh...@kernel.org;
mark.rutl...@arm.com; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
feste...@gmail.com; dl-linux-imx ;
wsa+rene...@sang-engineering.com; u.kleine-koe...@pengutronix.de;
e...@deif.com; li...@rempel-privat.de; l.st...@pengutronix.de; p...@axentia.se;
Sumit Batra
Subject: RE: [EXT] Re: [PATCH 1/2] i2c: imx: I2C Driver doesn't consider
I2C_IPGCLK_SEL RCW bit when using ls1046a SoC
> -Original Message-
> From: Sascha Hauer
> Sent: 2019年5月6日 15:38
> To: Chuanhua Han
> Cc: shawn...@kernel.org; Leo Li ;
> robh...@kernel.org; mark.rutl...@arm.com;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; feste...@gmail.com; dl-linux-imx
> ; wsa+rene...@sang-engineering.com;
> u.kleine-koe...@pengutronix.de; e...@deif.com; li...@rempel-privat.de;
> l.st...@pengutronix.de; p...@axentia.se; Sumit Batra
>
> Subject: Re: [EXT] Re: [PATCH 1/2] i2c: imx: I2C Driver doesn't
> consider I2C_IPGCLK_SEL RCW bit when using ls1046a SoC
>
> Caution: EXT Email
>
> On Sat, May 04, 2019 at 09:28:48AM +, Chuanhua Han wrote:
> >
> >
> > > -Original Message-
> > > From: Sascha Hauer
> > > Sent: 2019年4月30日 20:51
> > > To: Chuanhua Han
> > > Cc: shawn...@kernel.org; Leo Li ;
> > > robh...@kernel.org; mark.rutl...@arm.com;
> > > linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org;
> > > devicet...@vger.kernel.org; feste...@gmail.com; dl-linux-imx
> > > ; wsa+rene...@sang-engineering.com;
> > > u.kleine-koe...@pengutronix.de; e...@deif.com;
> > > li...@rempel-privat.de; l.st...@pengutronix.de; p...@axentia.se;
> > > Sumit Batra
> > > Subject: [EXT] Re: [PATCH 1/2] i2c: imx: I2C Driver doesn't
> > > consider I2C_IPGCLK_SEL RCW bit when using ls1046a SoC
> > >
> > > Caution: EXT Email
> > >
> > > On Tue, Apr 30, 2019 at 12:47:18PM +0800, Chuanhua Han wrote:
> > > > The current kernel driver does not consider I2C_IPGCLK_SEL (424
> > > > bit of
> > > > RCW) in deciding i2c_clk_rate in function i2c_imx_set_clk() { 0
> > > > Platform clock/4, 1 Platform clock/2}.
> > > >
> > > > When using ls1046a SoC, this populates incorrect value in IBFD
> > > > register if I2C_IPGCLK_SEL = 0, which generates half of the desired
> > > > Clock.
> > > >
> > > > Therefore, if ls1046a SoC is used, we need to set the i2c clock
> > > > according to the corresponding RCW.
> > >
> > > So the clock driver reports the wrong clock. Please fix the clock driver
> > > then.
> > No, this is a problem with the i2c driver. It is not a problem with
> > the clock driver, so the i2c driver needs to be modified.
>
> So how does this RCW bit get evaluated?
According to the reference manual
> only one clock goes to the i2c module (described as 1/2 Platform
> Clock) and the i2c module only takes one clock. So it seems there must
> be a /2 divider somewhere, either in each i2c module or somewhere
> outside. Can your IC guys tell you where it is?
I need to confirm this with the IC team
[Sumit Batra] There are 2 places where clock division takes place -
1) There is a clock divider outside of I2C block, which makes the
clock reaching I2C module as - Platform Clock/2
2) There is another clock divider which specifically divides the clock
to the I2C block, based on RCW bit 424 (if 424th bit is 0 then the baud clock
source is Platform Clock/4, if 424th bit is 1 then it remains Platform Clock/2)
3) Now based on the what is the desired SCL value (100KHz etc)
and the clock which is received by I2C block, there is a calculation that goes
on inside the I2C driver module which is used to map a value in this
imx_i2c_clk_div table.
This value is used to program the IMX_I2C_IFDR register of
the I2C block. Now if we don't consider the RCW bit 424 in our I2C driver
calculation then the IMX_I2C_IFDR value that gets set makes SCL half of what is
desired by the user.
This is because if you make the RCW 424th bit as 0 then
anyhow I2C block (hardware) will receive Platform Clock/4, but the driver
(since it has not considered this bit) will consider it as Platform Clock/2 so
it'll program a bigger divider from the imx_i2c_clk_div table
>
> One reason I suggested the clock driver is that the clock driver
> contains SoC specific code already, so it should be easier to integrate there.
It seems inappropriate to put the clock frequency division modification of i2c
in the clock driver, because the clock driver is for all IP and is a universal
code, so I think it is better to modify the clock in the IP driver.
>
> Sascha
>
>
> --
> Pengutronix e.K.
Re: [PATCH] ACPICA: acpica: Fix possible NULL pointer dereference in acpi_ut_remove_reference
On 2019/5/9 3:52, Schmauss, Erik wrote:
>
>
>> -Original Message-
>> From: YueHaibing [mailto:yuehaib...@huawei.com]
>> Sent: Wednesday, May 8, 2019 8:07 AM
>> To: Moore, Robert ; Schmauss, Erik
>> ; Wysocki, Rafael J ;
>> l...@kernel.org
>> Cc: linux-kernel@vger.kernel.org; de...@acpica.org; linux-
>> a...@vger.kernel.org; YueHaibing
>> Subject: [PATCH] ACPICA: acpica: Fix possible NULL pointer dereference in
>> acpi_ut_remove_reference
>>
>> BUG: kernel NULL pointer dereference, address:
>> #PF: supervisor read access in kernel mode
>> #PF: error_code(0x) - not-present page PGD 0 P4D 0
>> Oops: [#1
>> CPU: 0 PID: 7393 Comm: modprobe Not tainted 5.1.0+ #34 Hardware name:
>> QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-
>> prebuilt.qemu-project.org 04/01/2014
>> RIP: 0010:acpi_ut_update_object_reference+0xda/0x1e8
>> Code: 4c 89 e7 eb ea 48 8b 7b 18 48 85 ff 0f 84 95 00 00 00 4c 8b 67 38 44
>> 89 ee
>> e8 dd fb ff ff 4c 89 e7 eb e6 48 8b 43 18 44 89 e2 <48> 8b 3c d0 48 85 ff 75
>> 0b 41
>> ff c4 44 3b 63 2c 72 e7 eb 66 8a 47
>> RSP: 0018:c90001c9f550 EFLAGS: 00010283
>> RAX: RBX: 8882310d7288 RCX:
>> RDX: RSI: 0001 RDI: 8882310d7288
>> RBP: c90001c9f580 R08: R09:
>> R10: 0001 R11: 3ef29b78 R12:
>> R13: 0001 R14: 88823122e000 R15:
>> FS: 7f4469ead540() GS:888237a0()
>> knlGS:
>> CS: 0010 DS: ES: CR0: 80050033
>> CR2: CR3: 00022c2b5000 CR4: 06f0 Call
>> Trace:
>> acpi_ut_remove_reference+0x29/0x2c
>> acpi_ut_copy_iobject_to_iobject+0xd7/0xee
>> acpi_ds_store_object_to_local+0x9a/0x181
>> acpi_ex_store+0x233/0x279
>> ? acpi_ds_create_operands+0x74/0xdb
>> acpi_ex_opcode_1A_1T_1R+0x3c3/0x4fc
>> acpi_ds_exec_end_op+0xd1/0x419
>> acpi_ps_parse_loop+0x532/0x5d0
>> acpi_ps_parse_aml+0x93/0x2c8
>> acpi_ps_execute_method+0x16d/0x1b2
>> acpi_ns_evaluate+0x1c1/0x26c
>> acpi_ut_evaluate_object+0x7d/0x1a4
>> acpi_rs_get_prt_method_data+0x30/0x66
>> acpi_get_irq_routing_table+0x3d/0x56
>> acpi_pci_irq_find_prt_entry+0x8d/0x300
>> ? trace_hardirqs_on+0x3f/0x110
>> acpi_pci_irq_lookup+0x35/0x1f0
>> acpi_pci_irq_enable+0x72/0x1e0
>> ? pci_read_config_word+0x2e/0x30
>> pcibios_enable_device+0x2e/0x40
>> do_pci_enable_device+0x5c/0x100
>> pci_enable_device_flags+0xe0/0x130
>> pci_enable_device+0xe/0x10
>> e1000_probe+0xd2/0xfc0 [e1000
>> ? trace_hardirqs_on+0x3f/0x110
>> local_pci_probe+0x41/0x90
>> pci_device_probe+0x14c/0x1b0
>> really_probe+0x1d4/0x2d0
>> driver_probe_device+0x50/0xf0
>> device_driver_attach+0x54/0x60
>> __driver_attach+0x7e/0xd0
>> ? device_driver_attach+0x60/0x60
>> bus_for_each_dev+0x68/0xc0
>> driver_attach+0x19/0x20
>> bus_add_driver+0x15e/0x200
>> driver_register+0x5b/0xf0
>> __pci_register_driver+0x66/0x70
>> ? 0xa0179000
>> e1000_init_module+0x50/0x1000 [e1000
>> ? 0xa0179000
>> do_one_initcall+0x6c/0x3cc
>> ? do_init_module+0x22/0x207
>> ? rcu_read_lock_sched_held+0x97/0xb0
>> ? kmem_cache_alloc_trace+0x325/0x3b0
>> do_init_module+0x5b/0x207
>> load_module+0x1e34/0x2560
>> ? m_show+0x1d0/0x1d0
>> __do_sys_finit_module+0xc5/0xd0
>> __x64_sys_finit_module+0x15/0x20
>> do_syscall_64+0x6b/0x1d0
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>
>> In acpi_ut_copy_iobject_to_iobject, if
>> acpi_ut_copy_ipackage_to_ipackage failed with AE_NO_MEMORY,
>> acpi_ut_remove_reference will be called and in which calls
>> acpi_ut_update_object_reference, then it try to dereference 'object-
>>> package.elements[i]'
>> which trigger NULL pointer dereference.
>>
>> Reported-by: Hulk Robot
>> Fixes: 8aa5e56eeb61 ("ACPICA: Utilities: Fix memory leak in
>> acpi_ut_copy_iobject_to_iobject")
>> Signed-off-by: YueHaibing
>> ---
>> drivers/acpi/acpica/utcopy.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/acpica/utcopy.c b/drivers/acpi/acpica/utcopy.c
>> index
>> 1fb8327..038d518 100644
>> --- a/drivers/acpi/acpica/utcopy.c
>> +++ b/drivers/acpi/acpica/utcopy.c
>> @@ -895,7 +895,6 @@
>>
>> dest_obj->common.type = source_obj->common.type;
>> dest_obj->common.flags = source_obj->common.flags;
>> -dest_obj->package.count = source_obj->package.count;
>>
>> /*
>> * Create the object array and walk the source package tree @@ -
>> 909,6 +908,8 @@
>> return_ACPI_STATUS(AE_NO_MEMORY);
>> }
>>
>> +dest_obj->package.count = source_obj->package.count;
>> +
>> /*
>> * Copy the package element-by-element by walking the package
>> "tree".
>> * This handles nested packages of arbitrary depth.
>> --
>> 1.8.3.1
>>
>
> Please provide the acpidump as well as the dmesg
Re: [alsa-devel] [RFC PATCH 1/7] soundwire: Add sysfs support for master(s)
On 08-05-19, 15:57, Pierre-Louis Bossart wrote:
>
>
> On 5/8/19 11:59 AM, Greg KH wrote:
> > On Wed, May 08, 2019 at 11:42:15AM -0500, Pierre-Louis Bossart wrote:
> > >
> > >
> > > On 5/8/19 4:16 AM, Greg KH wrote:
> > > > On Wed, May 08, 2019 at 01:16:06PM +0530, Vinod Koul wrote:
> > > > > On 07-05-19, 17:49, Pierre-Louis Bossart wrote:
> > > > > >
> > > > > > > > The model here is that Master device is PCI or Platform device
> > > > > > > > and then
> > > > > > > > creates a bus instance which has soundwire slave devices.
> > > > > > > >
> > > > > > > > So for any attribute on Master device (which has properties as
> > > > > > > > well and
> > > > > > > > representation in sysfs), device specfic struct (PCI/platfrom
> > > > > > > > doesn't
> > > > > > > > help). For slave that is not a problem as sdw_slave structure
> > > > > > > > takes care
> > > > > > > > if that.
> > > > > > > >
> > > > > > > > So, the solution was to create the psedo sdw_master device for
> > > > > > > > the
> > > > > > > > representation and have device-specific structure.
> > > > > > >
> > > > > > > Ok, much like the "USB host controller" type device. That's
> > > > > > > fine, make
> > > > > > > such a device, add it to your bus, and set the type correctly.
> > > > > > > And keep
> > > > > > > a pointer to that structure in your device-specific structure if
> > > > > > > you
> > > > > > > really need to get to anything in it.
> > > > > >
> > > > > > humm, you lost me on the last sentence. Did you mean using
> > > > > > set_drv/platform_data during the init and retrieving the bus
> > > > > > information
> > > > > > with get_drv/platform_data as needed later? Or something else I
> > > > > > badly need
> > > > > > to learn?
> > > > >
> > > > > IIUC Greg meant we should represent a soundwire master device type and
> > > > > use that here. Just like we have soundwire slave device type.
> > > > > Something
> > > > > like:
> > > > >
> > > > > struct sdw_master {
> > > > > struct device dev;
> > > > > struct sdw_master_prop *prop;
> > > > > ...
> > > > > };
> > > > >
> > > > > In show function you get master from dev (container of) and then use
> > > > > that to access the master properties. So int.sdw.0 can be of this
> > > > > type.
> > > >
> > > > Yes, you need to represent the master device type if you are going to be
> > > > having an internal representation of it.
> > >
> > > Humm, confused...In the existing code bus and master are synonyms, see
> > > e.g.
> > > following code excerpts:
> > >
> > > * sdw_add_bus_master() - add a bus Master instance
> > > * @bus: bus instance
> > > *
> > > * Initializes the bus instance, read properties and create child
> > > * devices.
> > >
> > > struct sdw_bus {
> > > struct device *dev; <<< pointer here
> >
> > That's the pointer to what? The device that the bus is "attached to"
> > (i.e. parent, like a platform device or a pci device)?
> >
> > Why isn't this a "real" device in itself?
Correct, I am revisiting this and I think I have a fair idea of
expectations here (looking at usb and greybus model), will hack
something up
> Allow me to provide a bit of background. I am not trying to be pedantic but
> make sure we are on the same page.
>
> The SoundWire spec only defines a Master and Slaves attached to that Master.
>
> In real applications, there is a need to have multiple links, which can
> possibly operate in synchronized ways, so Intel came up with the concept of
> Controller, which expose multiple Master interfaces that are in sync (two
> streams can start at exactly the same clock edge of different links).
>
> The Controller is exposed in ACPI as a child of the HDAudio controller (ACPI
> companion of a PCI device). The controller exposes a 'master-count' and a
> set of link-specific properties needed for bandwidth/clock scaling.
>
> For some reason, our Windows friends did not want to have a device for each
> Master interface, likely because they did not want to load a driver per
> Master interface or have 'yellow bangs'.
>
> So the net result is that we have the following hierarchy in ACPI
>
> Device(HDAS) // HDaudio controller
> Device(SNDW) // SoundWire Controller
> Device(SDW0) { // Slave0
> _ADR(link0, vendorX, partY...)
> }
> Device(SDW1) { // Slave0
> _ADR(link0, vendorX, partY...)
> }
> Device(SDW2) { // Slave0
> _ADR(link1, vendorX, partY...)
> }
> Device(SDWM) { // Slave0
> _ADR(linkM, vendorX, partY...)
> }
>
> There is no master device represented in ACPI and the only way by which we
> know to which Master a Slave device is attached by looking up the _ADR which
> contains the link information.
>
> So, coming back to the plot, when we parse the Controller properties, we
> find out how many Master interfaces we have, create a platform_device for
> each of them, then initialize all the bus stuff.
So the idea here would be to go back and
Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT
On 4/30/19 8:39 AM, Hans de Goede wrote: > > Hi, > > On 4/25/19 6:38 PM, Robert R. Howell wrote: >> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote: >> >>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell wrote: On 4/23/19 2:07 AM, Rafael J. Wysocki wrote: > > On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell > wrote: >> >> On 4/18/19 5:42 AM, Hans de Goede wrote: >> On 4/8/19 2:16 AM, Hans de Goede wrote:> > > Hmm, interesting so you have hibernation working on a T100TA > (with 5.0 + 02e45646d53b reverted), right ? > >> >> >> I've managed to find a way around the i2c_designware timeout issues >> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND, >> which was added in the 02e45646d53b commit. >> >> To test that I've started with a 5.1-rc5 kernel, applied your recent >> patch >> to acpi_lpss.c, then apply the following patch of mine, removing >> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some >> other patches as well but those are not related to the i2c-designware or >> acpi issues addressed here.) >> >> On a resume from hibernation I still see one error: >> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended" >> but I no longer get the i2c_designware timeouts, and audio does now work >> after the resume. >> >> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other >> hardware, but perhaps this will give you a clue as to what is going >> wrong with hibernate/resume on the T100TA's. > > What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead? > I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both, then the timeouts go away. >>> >>> OK, thanks! >>> >>> Is non-hibernation system suspend affected too? >> >> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch >> applied >> but without any changes to i2c-designware-platdrv.c, so the >> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED >> flags >> are all set. >> >> Suspend does work OK, and after resume I do NOT get any of the crippling >> i2c_designware timeout errors which cause sound to fail after hibernate. I >> DO see one >> "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended" >> error on resume, just as I do on hibernate. I've attached a portion of >> dmesg below. >> The "asus_wmi: Unknown key 79 pressed" error is a glitch which occurs >> intermittently on these machines, but doesn't seem related to the other >> issues. >> I had one test run when it was absent but the rest of the messages were the >> same -- but then kept getting that unknown key error on all my later tries. > > I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" > error > on suspend/resume on my own T100TA and I could not reproduce this. > > Can you try without the BT keyboard paired and waking up from suspend using > the > tablet part's power-button ? > > Also do you still have the scripts to rmmod some modules before suspend ? > The T100TA keyboard is actually a hardwired connection rather than Bluetooth but I did physically disconnect the keyboard, and also unpaired all the actual Bluetooth devices (such as the mouse) and then powered down the T100TA bluetooth adapter. When I suspend, then resume using the tablet power button, I still get the i2c_dw_xfererror error during the resume. But whatever causes this error isn't fatal, in the sense that after resume the sound and other i2c functions do still work OK. While I always get this i2c_dw_xfer error on resume from suspend or hibernation on the T100TA, I also have a T100TAM and curiously, it NEVER shows that error -- although all the other suspend and hibernate behavior seems similar. I'm not sure if the following could be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen controller while the T100TAM uses an i2c connected SIS0817 touchscreen controller. Other than that the hardware seems almost identical. Regarding scripts, while I do still need a systemd hibernate script which removes the brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I no longer need any script for suspend. >> I did notice the "2sidle" in the following rather than "shallow" or "deep". >> A >> cat of /sys/power/state shows "freeze mem disk" but a >> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow >> and deep >> are not enabled for this system. I did check the input power (or really >> current) >> as it went into suspend and the micro-usb power input drops from about >> 0.5 amps to
[PATCH 1/1] i2c: iproc: Add multi byte read-write support for slave mode
Add multiple byte read-write support for slave mode.
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Srinath Mannam
---
drivers/i2c/busses/i2c-bcm-iproc.c | 117 +
1 file changed, 53 insertions(+), 64 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
b/drivers/i2c/busses/i2c-bcm-iproc.c
index a845b8d..2c7f145 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -165,12 +165,6 @@ enum i2c_slave_read_status {
I2C_SLAVE_RX_END,
};
-enum i2c_slave_xfer_dir {
- I2C_SLAVE_DIR_READ = 0,
- I2C_SLAVE_DIR_WRITE,
- I2C_SLAVE_DIR_NONE,
-};
-
enum bus_speed_index {
I2C_SPD_100K = 0,
I2C_SPD_400K,
@@ -203,7 +197,6 @@ struct bcm_iproc_i2c_dev {
struct i2c_msg *msg;
struct i2c_client *slave;
- enum i2c_slave_xfer_dir xfer_dir;
/* bytes that have been transferred */
unsigned int tx_bytes;
@@ -219,7 +212,8 @@ struct bcm_iproc_i2c_dev {
| BIT(IS_M_RX_THLD_SHIFT))
#define ISR_MASK_SLAVE (BIT(IS_S_START_BUSY_SHIFT)\
- | BIT(IS_S_RX_EVENT_SHIFT) | BIT(IS_S_RD_EVENT_SHIFT))
+ | BIT(IS_S_RX_EVENT_SHIFT) | BIT(IS_S_RD_EVENT_SHIFT)\
+ | BIT(IS_S_TX_UNDERRUN_SHIFT))
static int bcm_iproc_i2c_reg_slave(struct i2c_client *slave);
static int bcm_iproc_i2c_unreg_slave(struct i2c_client *slave);
@@ -297,15 +291,11 @@ static void bcm_iproc_i2c_slave_init(
/* clear all pending slave interrupts */
iproc_i2c_wr_reg(iproc_i2c, IS_OFFSET, ISR_MASK_SLAVE);
- /* Enable interrupt register for any READ event */
- val = BIT(IE_S_RD_EVENT_SHIFT);
/* Enable interrupt register to indicate a valid byte in receive fifo */
- val |= BIT(IE_S_RX_EVENT_SHIFT);
+ val = BIT(IE_S_RX_EVENT_SHIFT);
/* Enable interrupt register for the Slave BUSY command */
val |= BIT(IE_S_START_BUSY_SHIFT);
iproc_i2c_wr_reg(iproc_i2c, IE_OFFSET, val);
-
- iproc_i2c->xfer_dir = I2C_SLAVE_DIR_NONE;
}
static void bcm_iproc_i2c_check_slave_status(
@@ -314,8 +304,11 @@ static void bcm_iproc_i2c_check_slave_status(
u32 val;
val = iproc_i2c_rd_reg(iproc_i2c, S_CMD_OFFSET);
- val = (val >> S_CMD_STATUS_SHIFT) & S_CMD_STATUS_MASK;
+ /* status is valid only when START_BUSY is cleared after it was set */
+ if (val & BIT(S_CMD_START_BUSY_SHIFT))
+ return;
+ val = (val >> S_CMD_STATUS_SHIFT) & S_CMD_STATUS_MASK;
if (val == S_CMD_STATUS_TIMEOUT) {
dev_err(iproc_i2c->device, "slave random stretch time
timeout\n");
@@ -327,70 +320,66 @@ static void bcm_iproc_i2c_check_slave_status(
}
static bool bcm_iproc_i2c_slave_isr(struct bcm_iproc_i2c_dev *iproc_i2c,
- u32 status)
+ u32 status)
{
- u8 value;
u32 val;
- u32 rd_status;
- u32 tmp;
+ u8 value, rx_status;
- /* Start of transaction. check address and populate the direction */
- if (iproc_i2c->xfer_dir == I2C_SLAVE_DIR_NONE) {
- tmp = iproc_i2c_rd_reg(iproc_i2c, S_RX_OFFSET);
- rd_status = (tmp >> S_RX_STATUS_SHIFT) & S_RX_STATUS_MASK;
- /* This condition checks whether the request is a new request */
- if (((rd_status == I2C_SLAVE_RX_START) &&
- (status & BIT(IS_S_RX_EVENT_SHIFT))) ||
- ((rd_status == I2C_SLAVE_RX_END) &&
- (status & BIT(IS_S_RD_EVENT_SHIFT {
-
- /* Last bit is W/R bit.
-* If 1 then its a read request(by master).
-*/
- iproc_i2c->xfer_dir = tmp & SLAVE_READ_WRITE_BIT_MASK;
- if (iproc_i2c->xfer_dir == I2C_SLAVE_DIR_WRITE)
- i2c_slave_event(iproc_i2c->slave,
- I2C_SLAVE_READ_REQUESTED, );
- else
- i2c_slave_event(iproc_i2c->slave,
+ /* Slave RX byte receive */
+ if (status & BIT(IS_S_RX_EVENT_SHIFT)) {
+ val = iproc_i2c_rd_reg(iproc_i2c, S_RX_OFFSET);
+ rx_status = (val >> S_RX_STATUS_SHIFT) & S_RX_STATUS_MASK;
+ if (rx_status == I2C_SLAVE_RX_START) {
+ /* Start of SMBUS for Master write */
+ i2c_slave_event(iproc_i2c->slave,
I2C_SLAVE_WRITE_REQUESTED, );
- }
- }
- /* read request from master */
- if ((status & BIT(IS_S_RD_EVENT_SHIFT)) &&
- (iproc_i2c->xfer_dir == I2C_SLAVE_DIR_WRITE)) {
- i2c_slave_event(iproc_i2c->slave,
- I2C_SLAVE_READ_PROCESSED, );
- iproc_i2c_wr_reg(iproc_i2c, S_TX_OFFSET, value);
+
[PATCH 1/1] i2c: iproc: Add multi byte read-write support for slave mode
Add multiple byte read-write support for slave mode.
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Srinath Mannam
---
drivers/i2c/busses/i2c-bcm-iproc.c | 117 +
1 file changed, 53 insertions(+), 64 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
b/drivers/i2c/busses/i2c-bcm-iproc.c
index a845b8d..2c7f145 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -165,12 +165,6 @@ enum i2c_slave_read_status {
I2C_SLAVE_RX_END,
};
-enum i2c_slave_xfer_dir {
- I2C_SLAVE_DIR_READ = 0,
- I2C_SLAVE_DIR_WRITE,
- I2C_SLAVE_DIR_NONE,
-};
-
enum bus_speed_index {
I2C_SPD_100K = 0,
I2C_SPD_400K,
@@ -203,7 +197,6 @@ struct bcm_iproc_i2c_dev {
struct i2c_msg *msg;
struct i2c_client *slave;
- enum i2c_slave_xfer_dir xfer_dir;
/* bytes that have been transferred */
unsigned int tx_bytes;
@@ -219,7 +212,8 @@ struct bcm_iproc_i2c_dev {
| BIT(IS_M_RX_THLD_SHIFT))
#define ISR_MASK_SLAVE (BIT(IS_S_START_BUSY_SHIFT)\
- | BIT(IS_S_RX_EVENT_SHIFT) | BIT(IS_S_RD_EVENT_SHIFT))
+ | BIT(IS_S_RX_EVENT_SHIFT) | BIT(IS_S_RD_EVENT_SHIFT)\
+ | BIT(IS_S_TX_UNDERRUN_SHIFT))
static int bcm_iproc_i2c_reg_slave(struct i2c_client *slave);
static int bcm_iproc_i2c_unreg_slave(struct i2c_client *slave);
@@ -297,15 +291,11 @@ static void bcm_iproc_i2c_slave_init(
/* clear all pending slave interrupts */
iproc_i2c_wr_reg(iproc_i2c, IS_OFFSET, ISR_MASK_SLAVE);
- /* Enable interrupt register for any READ event */
- val = BIT(IE_S_RD_EVENT_SHIFT);
/* Enable interrupt register to indicate a valid byte in receive fifo */
- val |= BIT(IE_S_RX_EVENT_SHIFT);
+ val = BIT(IE_S_RX_EVENT_SHIFT);
/* Enable interrupt register for the Slave BUSY command */
val |= BIT(IE_S_START_BUSY_SHIFT);
iproc_i2c_wr_reg(iproc_i2c, IE_OFFSET, val);
-
- iproc_i2c->xfer_dir = I2C_SLAVE_DIR_NONE;
}
static void bcm_iproc_i2c_check_slave_status(
@@ -314,8 +304,11 @@ static void bcm_iproc_i2c_check_slave_status(
u32 val;
val = iproc_i2c_rd_reg(iproc_i2c, S_CMD_OFFSET);
- val = (val >> S_CMD_STATUS_SHIFT) & S_CMD_STATUS_MASK;
+ /* status is valid only when START_BUSY is cleared after it was set */
+ if (val & BIT(S_CMD_START_BUSY_SHIFT))
+ return;
+ val = (val >> S_CMD_STATUS_SHIFT) & S_CMD_STATUS_MASK;
if (val == S_CMD_STATUS_TIMEOUT) {
dev_err(iproc_i2c->device, "slave random stretch time
timeout\n");
@@ -327,70 +320,66 @@ static void bcm_iproc_i2c_check_slave_status(
}
static bool bcm_iproc_i2c_slave_isr(struct bcm_iproc_i2c_dev *iproc_i2c,
- u32 status)
+ u32 status)
{
- u8 value;
u32 val;
- u32 rd_status;
- u32 tmp;
+ u8 value, rx_status;
- /* Start of transaction. check address and populate the direction */
- if (iproc_i2c->xfer_dir == I2C_SLAVE_DIR_NONE) {
- tmp = iproc_i2c_rd_reg(iproc_i2c, S_RX_OFFSET);
- rd_status = (tmp >> S_RX_STATUS_SHIFT) & S_RX_STATUS_MASK;
- /* This condition checks whether the request is a new request */
- if (((rd_status == I2C_SLAVE_RX_START) &&
- (status & BIT(IS_S_RX_EVENT_SHIFT))) ||
- ((rd_status == I2C_SLAVE_RX_END) &&
- (status & BIT(IS_S_RD_EVENT_SHIFT {
-
- /* Last bit is W/R bit.
-* If 1 then its a read request(by master).
-*/
- iproc_i2c->xfer_dir = tmp & SLAVE_READ_WRITE_BIT_MASK;
- if (iproc_i2c->xfer_dir == I2C_SLAVE_DIR_WRITE)
- i2c_slave_event(iproc_i2c->slave,
- I2C_SLAVE_READ_REQUESTED, );
- else
- i2c_slave_event(iproc_i2c->slave,
+ /* Slave RX byte receive */
+ if (status & BIT(IS_S_RX_EVENT_SHIFT)) {
+ val = iproc_i2c_rd_reg(iproc_i2c, S_RX_OFFSET);
+ rx_status = (val >> S_RX_STATUS_SHIFT) & S_RX_STATUS_MASK;
+ if (rx_status == I2C_SLAVE_RX_START) {
+ /* Start of SMBUS for Master write */
+ i2c_slave_event(iproc_i2c->slave,
I2C_SLAVE_WRITE_REQUESTED, );
- }
- }
- /* read request from master */
- if ((status & BIT(IS_S_RD_EVENT_SHIFT)) &&
- (iproc_i2c->xfer_dir == I2C_SLAVE_DIR_WRITE)) {
- i2c_slave_event(iproc_i2c->slave,
- I2C_SLAVE_READ_PROCESSED, );
- iproc_i2c_wr_reg(iproc_i2c, S_TX_OFFSET, value);
+
[PATCH] ARM: dts: aspeed: Add Facebook YAMP BMC
Add initial version of device tree for Facebook YAMP ast2500 BMC.
Signed-off-by: Tao Ren
---
arch/arm/boot/dts/Makefile| 1 +
.../arm/boot/dts/aspeed-bmc-facebook-yamp.dts | 160 ++
2 files changed, 161 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed-bmc-facebook-yamp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f4f5aeaf3298..710616dcb62e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1254,6 +1254,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-arm-stardragon4800-rep2.dtb \
aspeed-bmc-facebook-cmm.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
+ aspeed-bmc-facebook-yamp.dtb \
aspeed-bmc-intel-s2600wf.dtb \
aspeed-bmc-opp-lanyang.dtb \
aspeed-bmc-opp-palmetto.dtb \
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-yamp.dts
b/arch/arm/boot/dts/aspeed-bmc-facebook-yamp.dts
new file mode 100644
index ..4e09a9cf32b7
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-yamp.dts
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2018 Facebook Inc.
+/dts-v1/;
+
+#include "aspeed-g5.dtsi"
+
+/ {
+ model = "Facebook YAMP 100 BMC";
+ compatible = "facebook,yamp-bmc", "aspeed,ast2500";
+
+ aliases {
+ /*
+* Override the default uart aliases to avoid breaking
+* the legacy applications.
+*/
+ serial0 =
+ serial1 =
+ serial2 =
+ serial3 =
+ };
+
+ chosen {
+ stdout-path =
+ bootargs = "console=ttyS0,9600n8 root=/dev/ram rw";
+ };
+
+ memory@8000 {
+ reg = <0x8000 0x2000>;
+ };
+};
+
+ {
+ aspeed,external-nodes = < >;
+};
+
+/*
+ * Update reset type to "system" (full chip) to fix warm reboot hang issue
+ * when reset type is set to default ("soc", gated by reset mask registers).
+ */
+ {
+ status = "okay";
+ aspeed,reset-type = "system";
+};
+
+/*
+ * wdt2 is not used by Yamp.
+ */
+ {
+ status = "disabled";
+};
+
+ {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+#include "facebook-bmc-flash-layout.dtsi"
+ };
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_txd1_default
+_rxd1_default>;
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_txd2_default
+_rxd2_default>;
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_txd3_default
+_rxd3_default>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ use-ncsi;
+ no-hw-checksum;
+ pinctrl-names = "default";
+ pinctrl-0 = <_rmii1_default>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ i2c-switch@75 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x75>;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
2.17.1
[PATCH] ARM: dts: aspeed: cmm: enable ehci host controllers
Enable ehci0 and ehci1 USB host controllers on Facebook Backpack CMM BMC.
Signed-off-by: Tao Ren
---
arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts
b/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts
index 43aba4071a5c..d519d307aa2a 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts
@@ -372,3 +372,11 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
2.17.1
Question about dev_queue_xmit and guaranteed packet transmission
I noticed that Linux has been updated on later versions to always consume the skb in calls to dev_queue_xmit, and may even drop the skb after returning a return code of NETDEV_TX_OK which seems kind of broken. I have an application which requires guaranteed skb transmission and the following code seems to work well for me if I call the netdev->netdev_ops->ndo_start_xmit function directly instead of using dev_queue_xmit. Is there a method of calling dev_queue_xmit which guarantees packet transmission? The current implementation of dev_queue_xmit used to return error codes without consuming the skb, which allowed programs which call it to simply resend the failing skb by calling dev_queue_xmit again without having to recreate and repopulate the skb. There also appears to be no reliable way to know for certain if dev_queue_xmit even sent a packet since it can at times return NETDEV_TX_OK then turn around and drop the packet later on. I have it working calling the ndo_start_xmit driver function directly which does seem to guarantee transmission, but would like to know if there is a way to get guaranteed TX of skb's with dev_queue_xmit. Jeff
Gold Bars Purchase/Investment!!
Greetings My name is Mr. George Kwame from Odikro Royal Family Bolgatanga Upper East Region Northern Ghana. We are a group of local gold Miners and end sellers we are looking for a direct buyer or an agent who will help us look for buyer on Commission basis. The Purity of our gold is 93% and 22Carats Plus and our price per kilo is affordable. We have 350 Kilos in Stock and we are looking for a buyer or an investor who will partner with us to invest in other of our 2Concessions. Kindly contact me for me details if you are interested to work with us. Hoping to hear from you. Regards George Kwame
Re: BUG: soft lockup in kvm_vm_ioctl
On Wed, May 08, 2019 at 06:58:28PM +0200, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> From: Dmitry Vyukov
> Date: Wed, May 8, 2019 at 1:25 PM
> To: Eric Biggers
> Cc: syzbot, KVM list, , David Miller, Artem
> Bityutskiy, , Josh Poimboeuf, LKML,
> , Andy Lutomirski, Ingo Molnar, Peter
> Zijlstra, Richard Weinberger, Rik van Riel, Steven Rostedt,
> syzkaller-bugs, Thomas Gleixner
>
> > From: Eric Biggers
> > Date: Thu, May 2, 2019 at 4:34 AM
> > To: syzbot, Dmitry Vyukov,
> > Cc: , ,
> > , , ,
> > , ,
> > , , ,
> > , , ,
> > ,
> >
> > > On Wed, May 01, 2019 at 07:36:05AM -0700, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following crash on:
> > > >
> > > > HEAD commit:baf76f0c slip: make slhc_free() silently accept an
> > > > error p..
> > > > git tree: upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1407f57f20
> > > > kernel config:
> > > > https://syzkaller.appspot.com/x/.config?x=a42d110b47dd6b36
> > > > dashboard link:
> > > > https://syzkaller.appspot.com/bug?extid=8d9bb6157e7b379f740e
> > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > syz repro:
> > > > https://syzkaller.appspot.com/x/repro.syz?x=1266a588a0
> > > >
> > > > The bug was bisected to:
> > > >
> > > > commit 252153ba518ac0bcde6b7152c63380d4415bfe5d
> > > > Author: Eric Biggers
> > > > Date: Wed Nov 29 20:43:17 2017 +
> > > >
> > > > ubifs: switch to fscrypt_prepare_setattr()
> > > >
> > > > bisection log:
> > > > https://syzkaller.appspot.com/x/bisect.txt?x=1448f588a0
> > > > final crash:
> > > > https://syzkaller.appspot.com/x/report.txt?x=1648f588a0
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1248f588a0
> > > >
> > > > IMPORTANT: if you fix the bug, please add the following tag to the
> > > > commit:
> > > > Reported-by: syzbot+8d9bb6157e7b379f7...@syzkaller.appspotmail.com
> > > > Fixes: 252153ba518a ("ubifs: switch to fscrypt_prepare_setattr()")
> > > >
> > > > watchdog: BUG: soft lockup - CPU#0 stuck for 123s!
> > > > [syz-executor.3:22023]
> > > > Modules linked in:
> > > > irq event stamp: 26556
> > > > hardirqs last enabled at (26555): []
> > > > trace_hardirqs_on_thunk+0x1a/0x1c
> > > > hardirqs last disabled at (26556): []
> > > > trace_hardirqs_off_thunk+0x1a/0x1c
> > > > softirqs last enabled at (596): []
> > > > __do_softirq+0x662/0x95a kernel/softirq.c:320
> > > > softirqs last disabled at (517): [] invoke_softirq
> > > > kernel/softirq.c:374 [inline]
> > > > softirqs last disabled at (517): []
> > > > irq_exit+0x180/0x1d0
> > > > kernel/softirq.c:414
> > > > CPU: 0 PID: 22023 Comm: syz-executor.3 Not tainted 5.1.0-rc6+ #89
> > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > Google 01/01/2011
> > > > RIP: 0010:csd_lock_wait kernel/smp.c:108 [inline]
> > > > RIP: 0010:smp_call_function_single+0x13e/0x420 kernel/smp.c:302
> > > > Code: 00 48 8b 4c 24 08 48 8b 54 24 10 48 8d 74 24 40 8b 7c 24 1c e8 23
> > > > fa
> > > > ff ff 41 89 c5 eb 07 e8 e9 87 0a 00 f3 90 44 8b 64 24 58 <31> ff 41 83
> > > > e4 01
> > > > 44 89 e6 e8 54 89 0a 00 45 85 e4 75 e1 e8 ca 87
> > > > RSP: 0018:88809277f3e0 EFLAGS: 0293 ORIG_RAX: ff13
> > > > RAX: 8880a8bfc040 RBX: 1110124efe80 RCX: 8166051c
> > > > RDX: RSI: 81660507 RDI: 0005
> > > > RBP: 88809277f4b8 R08: 8880a8bfc040 R09: ed1015d25be9
> > > > R10: ed1015d25be8 R11: 8880ae92df47 R12: 0003
> > > > R13: R14: 0001 R15:
> > > > FS: 7fd569980700() GS:8880ae80()
> > > > knlGS:
> > > > CS: 0010 DS: ES: CR0: 80050033
> > > > CR2: 7fd56997e178 CR3: a4fd2000 CR4: 001426f0
> > > > DR0: DR1: DR2:
> > > > DR3: DR6: fffe0ff0 DR7: 0400
> > > > Call Trace:
> > > > smp_call_function_many+0x750/0x8c0 kernel/smp.c:434
> > > > smp_call_function+0x42/0x90 kernel/smp.c:492
> > > > on_each_cpu+0x31/0x200 kernel/smp.c:602
> > > > text_poke_bp+0x107/0x19b arch/x86/kernel/alternative.c:821
> > > > __jump_label_transform+0x263/0x330 arch/x86/kernel/jump_label.c:91
> > > > arch_jump_label_transform+0x2b/0x40 arch/x86/kernel/jump_label.c:99
> > > > __jump_label_update+0x16a/0x210 kernel/jump_label.c:389
> > > > jump_label_update kernel/jump_label.c:752 [inline]
> > > > jump_label_update+0x1ce/0x3d0 kernel/jump_label.c:731
> > > > static_key_slow_inc_cpuslocked+0x1c1/0x250 kernel/jump_label.c:129
> > > > static_key_slow_inc+0x1b/0x30 kernel/jump_label.c:144
> > > > kvm_arch_vcpu_init+0x6b7/0x870 arch/x86/kvm/x86.c:9068
> > > > kvm_vcpu_init+0x272/0x370 arch/x86/kvm/../../../virt/kvm/kvm_main.c:320
> > > > vmx_create_vcpu+0x191/0x2540 arch/x86/kvm/vmx/vmx.c:6577
> > > > kvm_arch_vcpu_create+0x80/0x120
Re: [PATCH v2 2/3] iio: dps310: Temperature measurement errata
On Thu, May 9, 2019 at 3:36 AM Eddie James wrote:
>
> From: Christopher Bostic
>
> Add a manufacturer's suggested workaround to deal with early revisions
> of chip that don't indicate correct temperature. Readings can be in the
> ~60C range when they should be in the ~20's.
>
> Signed-off-by: Christopher Bostic
> Signed-off-by: Joel Stanley
> Signed-off-by: Eddie James
> ---
> drivers/iio/pressure/dps310.c | 51
> ++-
> 1 file changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/pressure/dps310.c b/drivers/iio/pressure/dps310.c
> index 7afaa88..c42808e 100644
> --- a/drivers/iio/pressure/dps310.c
> +++ b/drivers/iio/pressure/dps310.c
> @@ -221,6 +221,9 @@ static bool dps310_is_writeable_reg(struct device *dev,
> unsigned int reg)
> case DPS310_MEAS_CFG:
> case DPS310_CFG_REG:
> case DPS310_RESET:
> + case 0x0e:
> + case 0x0f:
> + case 0x62:
What is with the magic values? Are they not documented to what they
are, and hence not defining enum values for them?
- Matt
> return true;
> default:
> return false;
> @@ -237,6 +240,7 @@ static bool dps310_is_volatile_reg(struct device *dev,
> unsigned int reg)
> case DPS310_TMP_B1:
> case DPS310_TMP_B2:
> case DPS310_MEAS_CFG:
> + case 0x32:
> return true;
> default:
> return false;
> @@ -314,7 +318,7 @@ static int dps310_read_raw(struct iio_dev *iio,
> .writeable_reg = dps310_is_writeable_reg,
> .volatile_reg = dps310_is_volatile_reg,
> .cache_type = REGCACHE_RBTREE,
> - .max_register = 0x29,
> + .max_register = 0x62,
> };
>
> static const struct iio_info dps310_info = {
> @@ -322,6 +326,47 @@ static int dps310_read_raw(struct iio_dev *iio,
> .write_raw = dps310_write_raw,
> };
>
> +/*
> + * Some verions of chip will read temperatures in the ~60C range when
> + * its actually ~20C. This is the manufacturer recommended workaround
> + * to correct the issue.
> + */
> +static int dps310_temp_workaround(struct dps310_data *data)
> +{
> + int r, reg;
> +
> + r = regmap_read(data->regmap, 0x32, );
> + if (r < 0)
> + return r;
> +
> + /*
> +* If bit 1 is set then the device is okay, and the workaround does
> not
> +* need to be applied
> +*/
> + if (reg & BIT(1))
> + return 0;
> +
> + r = regmap_write(data->regmap, 0x0e, 0xA5);
> + if (r < 0)
> + return r;
> +
> + r = regmap_write(data->regmap, 0x0f, 0x96);
> + if (r < 0)
> + return r;
> +
> + r = regmap_write(data->regmap, 0x62, 0x02);
> + if (r < 0)
> + return r;
> +
> + r = regmap_write(data->regmap, 0x0e, 0x00);
> + if (r < 0)
> + return r;
> +
> + r = regmap_write(data->regmap, 0x0f, 0x00);
> +
> + return r;
> +}
> +
> static int dps310_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -383,6 +428,10 @@ static int dps310_probe(struct i2c_client *client,
> if (r < 0)
> goto err;
>
> + r = dps310_temp_workaround(data);
> + if (r < 0)
> + return r;
> +
> r = devm_iio_device_register(>dev, iio);
> if (r)
> goto err;
> --
> 1.8.3.1
>
[PATCH] Documentation: xfs: Fix typo
In "Y+P" of this line, there are two non-ASCII characters(0xd9 0x8d) following behind the 'Y'. Shown as a small '=' under the '+' in VIM and a '賺' in webpage[1]. I think it's a mistake and remove these strange characters. [1]: https://www.kernel.org/doc/Documentation/filesystems/xfs-delayed-logging-design.txt Signed-off-by: Shiyang Ruan --- Documentation/filesystems/xfs-delayed-logging-design.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/filesystems/xfs-delayed-logging-design.txt b/Documentation/filesystems/xfs-delayed-logging-design.txt index 2ce36439c09f..9a6dd289b17b 100644 --- a/Documentation/filesystems/xfs-delayed-logging-design.txt +++ b/Documentation/filesystems/xfs-delayed-logging-design.txt @@ -34,7 +34,7 @@ transaction: DA+B+C+D X+n+m+o E E Y (> X+n+m+o) - F E+F Yٍ+p + F E+F Y+p In other words, each time an object is relogged, the new transaction contains the aggregation of all the previous changes currently held only in the log. -- 2.17.0
Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support
On Wed 08 May 19:25 PDT 2019, Rob Clark wrote: > On Wed, May 8, 2019 at 7:16 PM Brian Masney wrote: > > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote: > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi > > > > b/arch/arm/boot/dts/qcom-msm8974.dtsi > > > [..] > > > > + clocks = < MDSS_MDP_CLK>, > > > > +< MDSS_AHB_CLK>, > > > > +< MDSS_AXI_CLK>, > > > > +< MDSS_BYTE0_CLK>, > > > > +< MDSS_PCLK0_CLK>, > > > > +< MDSS_ESC0_CLK>, > > > > +< MMSS_MISC_AHB_CLK>; > > > > + clock-names = "mdp_core", > > > > + "iface", > > > > + "bus", > > > > + "byte", > > > > + "pixel", > > > > + "core", > > > > + "core_mmss"; > > > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some > > > underrun error from DSI. You don't see anything like this? > > > > > > (These clocks are controlled by msm_bus downstream and should be driven > > > by interconnect upstream) > > > > > > > > > Apart from this, I think this looks nice. Happy to see the progress. > > > > No, I'm not seeing an underrun errors from the DSI. I think the clocks > > are fine since I'm able to get this working with 4.17 using these same > > clocks. I just sent out v2 and the cover letter has some details, along > > with the full dmesg. > > since we don't have interconnect driver for 8974, I guess there is > some chance that things work or not based on how lk leaves things? > Right, I guess the bootloader on my device does not leave the busses ticking - perhaps there's a boot splash involved on Brian's device? Regardless, this works on Nexus 5 and allows Brian to make further progress so I'm all for merging it. Regards, Bjorn
Re: [PATCH] kdb: Fix bound check compiler warning
On 5/8/19 4:16 PM, Daniel Thompson wrote:
On Wed, May 08, 2019 at 09:52:39AM +0800, Wenlin Kang wrote:
The strncpy() function may leave the destination string buffer
unterminated, better use strlcpy() instead.
This fixes the following warning with gcc 8.2:
kernel/debug/kdb/kdb_io.c: In function 'kdb_getstr':
kernel/debug/kdb/kdb_io.c:449:3: warning: 'strncpy' specified bound 256 equals
destination size [-Wstringop-truncation]
strncpy(kdb_prompt_str, prompt, CMD_BUFLEN);
^~~
Signed-off-by: Wenlin Kang
---
kernel/debug/kdb/kdb_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 6a4b414..7fd4513 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -446,7 +446,7 @@ static char *kdb_read(char *buffer, size_t bufsize)
char *kdb_getstr(char *buffer, size_t bufsize, const char *prompt)
{
if (prompt && kdb_prompt_str != prompt)
- strncpy(kdb_prompt_str, prompt, CMD_BUFLEN);
+ strlcpy(kdb_prompt_str, prompt, CMD_BUFLEN);
Shouldn't that be strscpy?
Hi Daniel
I thought about strscpy, but I think strlcpy is better, because it only
copy the real number of characters if src string less than that size.
Daniel.
kdb_printf(kdb_prompt_str);
kdb_nextline = 1; /* Prompt and input resets line number */
return kdb_read(buffer, bufsize);
--
1.9.1
--
Thanks,
Wenlin Kang
[PATCH] kconfig: remove trailing whitespaces
There are still some trailing whitespaces under scripts/kconfig/tests/,
but they must be kept. Otherwise, "make testconfig" would break.
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/gconf.c | 2 +-
scripts/kconfig/lxdialog/BIG.FAT.WARNING | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/kconfig/gconf.c b/scripts/kconfig/gconf.c
index 5d4ecf309ee4..e36b342f1065 100644
--- a/scripts/kconfig/gconf.c
+++ b/scripts/kconfig/gconf.c
@@ -638,7 +638,7 @@ on_set_option_mode3_activate(GtkMenuItem *menuitem,
gpointer user_data)
void on_introduction1_activate(GtkMenuItem * menuitem, gpointer user_data)
{
GtkWidget *dialog;
- const gchar *intro_text =
+ const gchar *intro_text =
"Welcome to gkc, the GTK+ graphical configuration tool\n"
"For each option, a blank box indicates the feature is disabled,
a\n"
"check indicates it is enabled, and a dot indicates that it is to\n"
diff --git a/scripts/kconfig/lxdialog/BIG.FAT.WARNING
b/scripts/kconfig/lxdialog/BIG.FAT.WARNING
index a8999d82bdb3..7cb5a7ec93d2 100644
--- a/scripts/kconfig/lxdialog/BIG.FAT.WARNING
+++ b/scripts/kconfig/lxdialog/BIG.FAT.WARNING
@@ -1,4 +1,4 @@
This is NOT the official version of dialog. This version has been
significantly modified from the original. It is for use by the Linux
-kernel configuration script. Please do not bother Savio Lam with
+kernel configuration script. Please do not bother Savio Lam with
questions about this program.
--
2.17.1
Re: [PATCH] packet: Fix error path in packet_init
On 2019/5/8 23:50, Eric Dumazet wrote: > On Wed, May 8, 2019 at 8:33 AM YueHaibing wrote: >> >> kernel BUG at lib/list_debug.c:47! >> invalid opcode: [#1 >> CPU: 0 PID: 11195 Comm: rmmod Tainted: GW 5.1.0+ #33 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >> rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 >> RIP: 0010:__list_del_entry_valid+0x55/0x90 >> Code: 12 48 39 d7 75 39 48 8b 50 08 48 39 d7 75 1d b8 01 00 00 00 5d c3 48 >> 89 c2 48 89 fe >> 31 c0 48 c7 c7 40 3a fe 82 e8 74 c1 78 ff <0f> 0b 48 89 fe 31 c0 48 c7 c7 >> f0 3a fe 82 e8 61 c1 78 ff 0f 0b 48 >> RSP: 0018:c90001b8be48 EFLAGS: 00010246 >> RAX: 004e RBX: a021 RCX: >> RDX: RSI: 888237a16808 RDI: >> RBP: c90001b8be48 R08: R09: 0001 >> R10: R11: 842c1640 R12: 0800 >> R13: R14: c90001b8be58 R15: a021 >> FS: 7f58963c7540() GS:888237a0() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 56064c7af818 CR3: 0001e9895000 CR4: 06f0 >> Call Trace: >> unregister_pernet_operations+0x34/0x110 >> unregister_pernet_subsys+0x1c/0x30 >> packet_exit+0x1c/0x1dd [af_packet >> __x64_sys_delete_module+0x16b/0x290 >> ? trace_hardirqs_off_thunk+0x1a/0x1c >> do_syscall_64+0x6b/0x1d0 >> entry_SYSCALL_64_after_hwframe+0x49/0xbe >> >> Fix error handing path in packet_init to >> avoid possilbe issue if some error occur. > > The trace is about rmmod, and the patch is in packet_init() ? Sorry for confusion. When modprobe module, register_pernet_subsys fails and does a cleanup, ops->list is set to LIST_POISON1, but the module init is considered to success, then while rmmod BUG_ON is triggered in __list_del_entry_valid which is called from unregister_pernet_subsys. I can rework the commit log in v2. the full CallTrace: [ 209.641390][T12911] CPU: 0 PID: 12911 Comm: modprobe Tainted: GW 5.1.0+ #47 [ 209.642637][T12911] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 [ 209.644436][T12911] Call Trace: [ 209.644912][T12911] dump_stack+0xa5/0xdc [ 209.645513][T12911] should_fail+0x145/0x170 [ 209.646150][T12911] __should_failslab+0x49/0x50 [ 209.646854][T12911] should_failslab+0x9/0x14 [ 209.647500][T12911] kmem_cache_alloc+0x47/0x700 [ 209.648203][T12911] __proc_create+0xcb/0x270 [ 209.648855][T12911] proc_create_reg+0x44/0x70 [ 209.649515][T12911] proc_create_net_data+0x24/0x60 [ 209.650254][T12911] packet_net_init+0x52/0x60 [af_packet] [ 209.651088][T12911] ops_init+0x3f/0x170 [ 209.651677][T12911] register_pernet_operations+0x109/0x1f0 [ 209.652513][T12911] ? 0xa0187000 [ 209.653116][T12911] register_pernet_subsys+0x23/0x40 [ 209.653862][T12911] packet_init+0x31/0x1000 [af_packet] [ 209.654655][T12911] do_one_initcall+0x65/0x350 [ 209.655333][T12911] do_init_module+0x5a/0x205 [ 209.655996][T12911] load_module+0x1f07/0x2710 [ 209.656674][T12911] ? ima_post_read_file+0xec/0x130 [ 209.657417][T12911] __do_sys_finit_module+0xd1/0xf0 [ 209.658159][T12911] ? __do_sys_finit_module+0xd1/0xf0 [ 209.658924][T12911] __x64_sys_finit_module+0x15/0x20 [ 209.659683][T12911] do_syscall_64+0x6e/0x1f0 [ 209.660329][T12911] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 209.661185][T12911] RIP: 0033:0x7f6eeb066839 [ 209.661836][T12911] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 [ 209.664697][T12911] RSP: 002b:7ffe60f7c1d8 EFLAGS: 0246 ORIG_RAX: 0139 [ 209.665913][T12911] RAX: ffda RBX: 563b7b82ab40 RCX: 7f6eeb066839 [ 209.667071][T12911] RDX: RSI: 563b7aa4ac2e RDI: 0003 [ 209.668226][T12911] RBP: 563b7aa4ac2e R08: R09: 563b7b82ce80 [ 209.669388][T12911] R10: 0003 R11: 0246 R12: [ 209.670542][T12911] R13: 563b7b8324a0 R14: 0004 R15: 563b7b82ab40 [ 209.695525][T12914] list_del corruption, a0184000->next is LIST_POISON1 (dead0100) [ 209.696916][T12914] [ cut here ] [ 209.697736][T12914] kernel BUG at lib/list_debug.c:47! [ 209.698514][T12914] invalid opcode: [#1] PREEMPT SMP [ 209.699325][T12914] CPU: 0 PID: 12914 Comm: rmmod Tainted: GW 5.1.0+ #47 [ 209.700536][T12914] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 [ 209.702391][T12914] RIP: 0010:__list_del_entry_valid+0x53/0x90 [ 209.703265][T12914] Code: 48 8b 32 48 39 fe 75 35 48 8b 50 08 48 39 f2
Re: [PATCHv2 10/10] vfio/mdev: Synchronize device create/remove with parent removal
On Tue, 30 Apr 2019 17:49:37 -0500
Parav Pandit wrote:
> In following sequences, child devices created while removing mdev parent
> device can be left out, or it may lead to race of removing half
> initialized child mdev devices.
>
> issue-1:
>
>cpu-0 cpu-1
>- -
> mdev_unregister_device()
> device_for_each_child()
> mdev_device_remove_cb()
> mdev_device_remove()
> create_store()
> mdev_device_create() [...]
> device_add()
> parent_remove_sysfs_files()
>
> /* BUG: device added by cpu-0
> * whose parent is getting removed
> * and it won't process this mdev.
> */
>
> issue-2:
>
> Below crash is observed when user initiated remove is in progress
> and mdev_unregister_driver() completes parent unregistration.
>
>cpu-0 cpu-1
>- -
> remove_store()
>mdev_device_remove()
>active = false;
> mdev_unregister_device()
> parent device removed.
>[...]
>parents->ops->remove()
> /*
> * BUG: Accessing invalid parent.
> */
>
> This is similar race like create() racing with mdev_unregister_device().
>
> BUG: unable to handle kernel paging request at c0585668
> PGD e8f618067 P4D e8f618067 PUD e8f61a067 PMD 85adca067 PTE 0
> Oops: [#1] SMP PTI
> CPU: 41 PID: 37403 Comm: bash Kdump: loaded Not tainted 5.1.0-rc6-vdevbus+ #6
> Hardware name: Supermicro SYS-6028U-TR4+/X10DRU-i+, BIOS 2.0b 08/09/2016
> RIP: 0010:mdev_device_remove+0xfa/0x140 [mdev]
> Call Trace:
> remove_store+0x71/0x90 [mdev]
> kernfs_fop_write+0x113/0x1a0
> vfs_write+0xad/0x1b0
> ksys_write+0x5a/0xe0
> do_syscall_64+0x5a/0x210
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Therefore, mdev core is improved as below to overcome above issues.
>
> Wait for any ongoing mdev create() and remove() to finish before
> unregistering parent device using refcount and completion.
> This continues to allow multiple create and remove to progress in
> parallel for different mdev devices as most common case.
> At the same time guard parent removal while parent is being access by
> create() and remove callbacks.
>
> Code is simplified from kref to use refcount as unregister_device() has
> to wait anyway for all create/remove to finish.
>
> While removing mdev devices during parent unregistration, there isn't
> need to acquire refcount of parent device, hence code is restructured
> using mdev_device_remove_common() to avoid it.
Did you consider calling parent_remove_sysfs_files() earlier in
mdev_unregister_device() and adding srcu support to know there are no
in-flight callers of the create path? I think that would address
issue-1.
Issue-2 suggests a bug in our handling of the parent device krefs, the
parent object should exist until all child devices which have a kref
reference to the parent are removed, but clearly
mdev_unregister_device() is not blocking for that to occur allowing the
parent driver .remove callback to finish. This seems similar to
vfio_del_group_dev() where we need to block a vfio bus driver from
removing a device until it becomes unused, could a similar solution
with a wait_queue and wait_woken be used here?
I'm not immediately sold on the idea that removing a kref to solve this
problem is a good thing, it seems odd to me that mdevs don't hold a
reference to the parent throughout their life with this change, and the
remove_store path branch to exit if we find we're racing the parent
remove path is rather ugly. BTW, why is the sanitization loop in
mdev_device_remove() still here, wasn't that fixed by the previous two
patches? Thanks,
Alex
> Fixes: 7b96953bc640 ("vfio: Mediated device Core driver")
> Signed-off-by: Parav Pandit
> ---
> drivers/vfio/mdev/mdev_core.c| 86
> drivers/vfio/mdev/mdev_private.h | 6 ++-
> 2 files changed, 60 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index 2b98da2ee361..a5da24d662f4 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -78,34 +78,41 @@ static struct mdev_parent *__find_parent_device(struct
> device *dev)
> return NULL;
> }
>
> -static void mdev_release_parent(struct kref *kref)
> +static bool mdev_try_get_parent(struct mdev_parent *parent)
> {
> - struct mdev_parent *parent = container_of(kref, struct mdev_parent,
> - ref);
> - struct device *dev = parent->dev;
> -
> - kfree(parent);
> - put_device(dev);
> + if (parent)
> + return refcount_inc_not_zero(>refcount);
> + return false;
> }
>
>
Re: WARNING: locking bug in nfs_get_client
syzbot has bisected this bug to:
commit 950a578c6128c2886e295b9c7ecb0b6b22fcc92b
Author: Roberto Bergantinos Corpas
Date: Thu Apr 25 13:36:51 2019 +
NFS: make nfs_match_client killable
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11e40aaca0
start commit: 31ccad9b Add linux-next specific files for 20190508
git tree: linux-next
final crash:https://syzkaller.appspot.com/x/report.txt?x=13e40aaca0
console output: https://syzkaller.appspot.com/x/log.txt?x=15e40aaca0
kernel config: https://syzkaller.appspot.com/x/.config?x=63cd766601c6c9fc
dashboard link: https://syzkaller.appspot.com/bug?extid=228a82b263b5da91883d
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=140fdce8a0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=134dce02a0
Reported-by: syzbot+228a82b263b5da918...@syzkaller.appspotmail.com
Fixes: 950a578c6128 ("NFS: make nfs_match_client killable")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
linux-next: manual merge of the mfd tree with Linus' tree
Hi all,
Today's linux-next merge of the mfd tree got a conflict in:
MAINTAINERS
between commit:
10b5d3d10759 ("MAINTAINERS: add maintainer for maxbotix ultrasonic driver")
from Linus' tree and commit:
796fad0101d3 ("MAINTAINERS: Add an entry for MAX77650 PMIC driver")
from the mfd tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc MAINTAINERS
index 77471dd6cb46,1effe9789023..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -9521,13 -9414,20 +9527,27 @@@ S: Maintaine
F:Documentation/devicetree/bindings/sound/max9860.txt
F:sound/soc/codecs/max9860.*
+MAXBOTIX ULTRASONIC RANGER IIO DRIVER
+M:Andreas Klinger
+L:linux-...@vger.kernel.org
+S:Maintained
+F:Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
+F:drivers/iio/proximity/mb1232.c
+
+ MAXIM MAX77650 PMIC MFD DRIVER
+ M:Bartosz Golaszewski
+ L:linux-kernel@vger.kernel.org
+ S:Maintained
+ F:Documentation/devicetree/bindings/*/*max77650.txt
+ F:Documentation/devicetree/bindings/*/max77650*.txt
+ F:include/linux/mfd/max77650.h
+ F:drivers/mfd/max77650.c
+ F:drivers/regulator/max77650-regulator.c
+ F:drivers/power/supply/max77650-charger.c
+ F:drivers/input/misc/max77650-onkey.c
+ F:drivers/leds/leds-max77650.c
+ F:drivers/gpio/gpio-max77650.c
+
MAXIM MAX77802 PMIC REGULATOR DEVICE DRIVER
M:Javier Martinez Canillas
L:linux-kernel@vger.kernel.org
pgpALKP_AycFb.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 1/8] iommu: Add ops entry for supported default domain type
Hi Robin,
On 5/7/19 6:28 PM, Robin Murphy wrote:
On 06/05/2019 16:32, Tom Murphy via iommu wrote:
The AMD driver already solves this problem and uses the generic
iommu_request_dm_for_dev function. It seems like both drivers have the
same problem and could use the same solution. Is there any reason we
can't have use the same solution for the intel and amd driver?
Could we just copy the implementation of the AMD driver? It would be
nice to have the same behavior across both drivers especially as we
move to make both drivers use more generic code.
TBH I don't think the API really needs to be involved at all here.
Drivers can already not provide the requested default domain type if
they don't support it, so as long as the driver can ensure that the
device ends up with IOMMU or direct DMA ops as appropriate, I don't see
any great problem with drivers just returning a passthrough domain when
a DMA domain was requested, or vice versa (and logging a message that
the requested type was overridden). The only type that we really do have
to honour strictly is non-default (i.e. unmanaged) domains.
I agree with you that we only have to honor strictly the non-default
domains. But domain type saved in iommu_domain is consumed in iommu.c
and exposed to user through sysfs. It's not clean if the iommu driver
silently replace the default domain.
Best regards,
Lu Baolu
Robin.
On Mon, Apr 29, 2019 at 3:16 AM Lu Baolu
wrote:
This adds an optional ops entry to query the default domain
types supported by the iommu driver for a specific device.
This is necessary in cases where the iommu driver can only
support a specific type of default domain for a device. In
normal cases, this ops will return IOMMU_DOMAIN_ANY which
indicates that the iommu driver supports both IOMMU_DOMAIN_DMA
and IOMMU_DOMAIN_IDENTITY, hence the static default domain
type will be used.
Signed-off-by: Lu Baolu
---
drivers/iommu/iommu.c | 13 ++---
include/linux/iommu.h | 11 +++
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index acd6830e6e9b..1ad9a1f2e078 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1097,15 +1097,22 @@ struct iommu_group
*iommu_group_get_for_dev(struct device *dev)
* IOMMU driver.
*/
if (!group->default_domain) {
+ unsigned int domain_type = IOMMU_DOMAIN_ANY;
struct iommu_domain *dom;
- dom = __iommu_domain_alloc(dev->bus,
iommu_def_domain_type);
- if (!dom && iommu_def_domain_type != IOMMU_DOMAIN_DMA) {
+ if (ops->def_domain_type)
+ domain_type = ops->def_domain_type(dev);
+
+ if (domain_type == IOMMU_DOMAIN_ANY)
+ domain_type = iommu_def_domain_type;
+
+ dom = __iommu_domain_alloc(dev->bus, domain_type);
+ if (!dom && domain_type != IOMMU_DOMAIN_DMA) {
dom = __iommu_domain_alloc(dev->bus,
IOMMU_DOMAIN_DMA);
if (dom) {
dev_warn(dev,
"failed to allocate default
IOMMU domain of type %u; falling back to IOMMU_DOMAIN_DMA",
- iommu_def_domain_type);
+ domain_type);
}
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 8239ece9fdfc..ba9a5b996a63 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -79,12 +79,16 @@ struct iommu_domain_geometry {
* IOMMU_DOMAIN_DMA - Internally used for DMA-API
implementations.
* This flag allows IOMMU drivers to
implement
* certain optimizations for these
domains
+ * IOMMU_DOMAIN_ANY - All domain types defined here
*/
#define IOMMU_DOMAIN_BLOCKED (0U)
#define IOMMU_DOMAIN_IDENTITY (__IOMMU_DOMAIN_PT)
#define IOMMU_DOMAIN_UNMANAGED (__IOMMU_DOMAIN_PAGING)
#define IOMMU_DOMAIN_DMA (__IOMMU_DOMAIN_PAGING | \
__IOMMU_DOMAIN_DMA_API)
+#define IOMMU_DOMAIN_ANY (IOMMU_DOMAIN_IDENTITY | \
+ IOMMU_DOMAIN_UNMANAGED | \
+ IOMMU_DOMAIN_DMA)
struct iommu_domain {
unsigned type;
@@ -196,6 +200,11 @@ enum iommu_dev_features {
* @dev_feat_enabled: check enabled feature
* @aux_attach/detach_dev: aux-domain specific attach/detach entries.
* @aux_get_pasid: get the pasid given an aux-domain
+ * @def_domain_type: get per-device default domain type that the IOMMU
+ * driver is able to support. Valid returns values:
+ * - IOMMU_DOMAIN_DMA: only suports non-identity domain
+ * - IOMMU_DOMAIN_IDENTITY: only supports identity domain
+ * -
RE: [EXT] [PATCH v2 6/6] soc/fsl/qe: qe.c: fold qe_get_num_of_snums into qe_snums_init
On 2019/5/1 17:29, Rasmus Villemoes wrote:
> -Original Message-
> From: Rasmus Villemoes
> Sent: 2019年5月1日 17:29
> To: devicet...@vger.kernel.org; Qiang Zhao ; Leo Li
>
> Cc: linuxppc-...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; Rob Herring ; Scott Wood
> ; Christophe Leroy ; Mark
> Rutland ; Rasmus Villemoes
>
> Subject: [PATCH v2 6/6] soc/fsl/qe: qe.c: fold qe_get_num_of_snums into
> qe_snums_init
>
> The comment "No QE ever has fewer than 28 SNUMs" is false; e.g. the
> MPC8309 has 14. The code path returning -EINVAL is also a recipe for instant
> disaster, since the caller (qe_snums_init) uncritically assigns the return
> value to
> the unsigned qe_num_of_snum, and would thus proceed to attempt to copy
> 4GB from snum_init_46[] to the snum[] array.
>
> So fold the handling of the legacy fsl,qe-num-snums into qe_snums_init, and
> make sure we do not end up using the snum_init_46 array in cases other than
> the two where we know it makes sense.
>
> Signed-off-by: Rasmus Villemoes
> ---
Reviewed-by: Qiang Zhao
> drivers/soc/fsl/qe/qe.c | 46 ++---
> 1 file changed, 16 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index
> 325d689cbf5c..276d7d78ebfc 100644
> --- a/drivers/soc/fsl/qe/qe.c
> +++ b/drivers/soc/fsl/qe/qe.c
> @@ -308,24 +308,33 @@ static void qe_snums_init(void)
> int i;
>
> bitmap_zero(snum_state, QE_NUM_OF_SNUM);
> + qe_num_of_snum = 28; /* The default number of snum for threads
> + is 28 */
> qe = qe_get_device_node();
> if (qe) {
> i = of_property_read_variable_u8_array(qe, "fsl,qe-snums",
>snums, 1,
> QE_NUM_OF_SNUM);
> - of_node_put(qe);
> if (i > 0) {
> + of_node_put(qe);
> qe_num_of_snum = i;
> return;
> }
> + /*
> +* Fall back to legacy binding of using the value of
> +* fsl,qe-num-snums to choose one of the static arrays
> +* above.
> +*/
> + of_property_read_u32(qe, "fsl,qe-num-snums",
> _num_of_snum);
> + of_node_put(qe);
> }
>
> - qe_num_of_snum = qe_get_num_of_snums();
> -
> - if (qe_num_of_snum == 76)
> + if (qe_num_of_snum == 76) {
> snum_init = snum_init_76;
> - else
> + } else if (qe_num_of_snum == 28 || qe_num_of_snum == 46) {
> snum_init = snum_init_46;
> -
> + } else {
> + pr_err("QE: unsupported value of fsl,qe-num-snums: %u\n",
> qe_num_of_snum);
> + return;
> + }
> memcpy(snums, snum_init, qe_num_of_snum); }
>
> @@ -641,30 +650,7 @@ EXPORT_SYMBOL(qe_get_num_of_risc);
>
> unsigned int qe_get_num_of_snums(void)
> {
> - struct device_node *qe;
> - int size;
> - unsigned int num_of_snums;
> - const u32 *prop;
> -
> - num_of_snums = 28; /* The default number of snum for threads is 28
> */
> - qe = qe_get_device_node();
> - if (!qe)
> - return num_of_snums;
> -
> - prop = of_get_property(qe, "fsl,qe-num-snums", );
> - if (prop && size == sizeof(*prop)) {
> - num_of_snums = *prop;
> - if ((num_of_snums < 28) || (num_of_snums >
> QE_NUM_OF_SNUM)) {
> - /* No QE ever has fewer than 28 SNUMs */
> - pr_err("QE: number of snum is invalid\n");
> - of_node_put(qe);
> - return -EINVAL;
> - }
> - }
> -
> - of_node_put(qe);
> -
> - return num_of_snums;
> + return qe_num_of_snum;
> }
> EXPORT_SYMBOL(qe_get_num_of_snums);
>
> --
> 2.20.1
Best Regards
Qiang Zhao
Re: [PATCH v5 1/3] ASoC: rt5677: allow multiple interrupt sources
On Wed, May 08, 2019 at 02:39:32PM -0700, Curtis Malainey wrote: > Pixelbooks (Samus Chromebook) are the only devices that use this part. > Realtek has confirmed this. Therefore we only have to worry about > breaking ourselves. That being said I agree there is likely a better And there are no other parts that are software compatible enough to share the same driver? > way to handle general abstraction here. We will need the explicit irq > handling since I will be following these patches up with patches that > enable hotwording on the codec (we will be sending the firmware to > linux-firmware as well that is needed for the process.) OK. Like I said it might also be clearer split into multiple patches, it was just really difficult to tell what was going on with the diff there. signature.asc Description: PGP signature
[PATCH] rtc: ds2404: use hw endiannes variable
Converting from hardware to host endiannes was done using reassignment
to the same variable which makes sparse unhappy as it can not verify
the endiannes handling properly. To allow sparse to verify endiannes
handling an explicit __le32 is introduced. Note that this patch does
not change the generated binary (x86_64 and ppc64 binary diff).
Signed-off-by: Nicholas Mc Guire
---
Problem located by an experimental coccinelle script to locate
patters that make sparse unhappy (false positives):
on little-endian x86_64 sparse complains about:
drivers/rtc/rtc-ds2404.c:187:16: warning: cast to restricted __le32
on big-endian ppc64 sparse complains about
drivers/rtc/rtc-ds2404.c:187:16: warning: cast to restricted __le32
drivers/rtc/rtc-ds2404.c:187:16: warning: cast to restricted __le32
drivers/rtc/rtc-ds2404.c:187:16: warning: cast to restricted __le32
drivers/rtc/rtc-ds2404.c:187:16: warning: cast to restricted __le32
drivers/rtc/rtc-ds2404.c:187:16: warning: cast to restricted __le32
drivers/rtc/rtc-ds2404.c:187:16: warning: cast to restricted __le32
Patch was compiletested with:
x86_64_defconfig + RTC_DRV_DS2404=m
ppc64_defconfig + RTC_DRV_DS2404=m
in both cases applying the patch has no impact on the generated binary.
Patch is against 5.1 (localversion-next is next-20190508)
drivers/rtc/rtc-ds2404.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ds2404.c b/drivers/rtc/rtc-ds2404.c
index 1e9f429..9df0c44 100644
--- a/drivers/rtc/rtc-ds2404.c
+++ b/drivers/rtc/rtc-ds2404.c
@@ -182,9 +182,10 @@ static void ds2404_enable_osc(struct device *dev)
static int ds2404_read_time(struct device *dev, struct rtc_time *dt)
{
unsigned long time = 0;
+ __le32 hw_time = 0;
- ds2404_read_memory(dev, 0x203, 4, (u8 *));
- time = le32_to_cpu(time);
+ ds2404_read_memory(dev, 0x203, 4, (u8 *)_time);
+ time = le32_to_cpu(hw_time);
rtc_time64_to_tm(time, dt);
return 0;
--
2.1.4
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On 5/8/19 6:44 PM, Theodore Ts'o wrote: > On Wed, May 08, 2019 at 05:58:49PM -0700, Frank Rowand wrote: >> >> If KUnit is added to the kernel, and a subsystem that I am submitting >> code for has chosen to use KUnit instead of kselftest, then yes, I do >> *have* to use KUnit if my submission needs to contain a test for the >> code unless I want to convince the maintainer that somehow my case >> is special and I prefer to use kselftest instead of KUnittest. > > That's going to be between you and the maintainer. Today, if you want > to submit a substantive change to xfs or ext4, you're going to be > asked to create test for that new feature using xfstests. It doesn't > matter that xfstests isn't in the kernel --- if that's what is > required by the maintainer. Yes, that is exactly what I was saying. Please do not cut the pertinent parts of context that I am replying to. >>> supposed to be a simple way to run a large number of small tests that >>> for specific small components in a system. >> >> kselftest also supports running a subset of tests. That subset of tests >> can also be a large number of small tests. There is nothing inherent >> in KUnit vs kselftest in this regard, as far as I am aware. > The big difference is that kselftests are driven by a C program that > runs in userspace. Take a look at > tools/testing/selftests/filesystem/dnotify_test.c > it has a main(int argc, char *argv) function. > > In contrast, KUnit are fragments of C code which run in the kernel; > not in userspace. This allows us to test internal functions inside > complex file system (such as the block allocator in ext4) directly. > This makes it *fundamentally* different from kselftest. No, totally incorrect. kselftests also supports in kernel modules as I mention in another reply to this patch. This is talking past each other a little bit, because your next reply is a reply to my email about modules. -Frank > > Cheers, > > - Ted >
drivers/net/ethernet/micrel/ks8851.c:429:3: note: in expansion of macro 'memcpy'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: ef75bd71c5d31dc17ae41ff8bec92630a3037d69
commit: a51645f70f6384ae3329551750f7f502cb8de5fc net: ethernet: support
of_get_mac_address new ERR_PTR error
date: 31 hours ago
config: i386-randconfig-c0-05090856 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout a51645f70f6384ae3329551750f7f502cb8de5fc
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/string.h:3:0,
from include/linux/string.h:20,
from include/linux/bitmap.h:9,
from include/linux/cpumask.h:12,
from include/linux/interrupt.h:8,
from drivers/net/ethernet/micrel/ks8851.c:16:
drivers/net/ethernet/micrel/ks8851.c: In function 'ks8851_probe':
arch/x86/include/asm/string_32.h:182:25: warning: argument 2 null where
non-null expected [-Wnonnull]
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
^
>> drivers/net/ethernet/micrel/ks8851.c:429:3: note: in expansion of macro
>> 'memcpy'
memcpy(dev->dev_addr, mac_addr, ETH_ALEN);
^~
arch/x86/include/asm/string_32.h:182:25: note: in a call to built-in
function '__builtin_memcpy'
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
^
>> drivers/net/ethernet/micrel/ks8851.c:429:3: note: in expansion of macro
>> 'memcpy'
memcpy(dev->dev_addr, mac_addr, ETH_ALEN);
^~
--
In file included from arch/x86/include/asm/string.h:3:0,
from include/linux/string.h:20,
from include/linux/bitmap.h:9,
from include/linux/cpumask.h:12,
from include/linux/interrupt.h:8,
from drivers/net/ethernet/micrel/ks8851_mll.c:25:
drivers/net/ethernet/micrel/ks8851_mll.c: In function 'ks8851_probe':
arch/x86/include/asm/string_32.h:182:25: warning: argument 2 null where
non-null expected [-Wnonnull]
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
^
>> drivers/net/ethernet/micrel/ks8851_mll.c:1331:4: note: in expansion of macro
>> 'memcpy'
memcpy(ks->mac_addr, mac, ETH_ALEN);
^~
arch/x86/include/asm/string_32.h:182:25: note: in a call to built-in
function '__builtin_memcpy'
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
^
>> drivers/net/ethernet/micrel/ks8851_mll.c:1331:4: note: in expansion of macro
>> 'memcpy'
memcpy(ks->mac_addr, mac, ETH_ALEN);
^~
vim +/memcpy +429 drivers/net/ethernet/micrel/ks8851.c
a9a8de21 drivers/net/ethernet/micrel/ks8851.c Ben Dooks 2011-11-21 411
a9a8de21 drivers/net/ethernet/micrel/ks8851.c Ben Dooks 2011-11-21 412 /**
3ba81f3e drivers/net/ks8851.c Ben Dooks 2009-07-16 413 *
ks8851_init_mac - initialise the mac address
3ba81f3e drivers/net/ks8851.c Ben Dooks 2009-07-16 414 *
@ks: The device structure
3ba81f3e drivers/net/ks8851.c Ben Dooks 2009-07-16 415 *
3ba81f3e drivers/net/ks8851.c Ben Dooks 2009-07-16 416 *
Get or create the initial mac address for the device and then set that
566bd54b drivers/net/ethernet/micrel/ks8851.c Lukas Wunner 2017-12-18 417 *
into the station address register. A mac address supplied in the device
566bd54b drivers/net/ethernet/micrel/ks8851.c Lukas Wunner 2017-12-18 418 *
tree takes precedence. Otherwise, if there is an EEPROM present, then
7efd26d0 drivers/net/ethernet/micrel/ks8851.c Joe Perches 2012-07-12 419 *
we try that. If no valid mac address is found we use eth_random_addr()
3ba81f3e drivers/net/ks8851.c Ben Dooks 2009-07-16 420 *
to create a new one.
3ba81f3e drivers/net/ks8851.c Ben Dooks 2009-07-16 421 */
3ba81f3e drivers/net/ks8851.c Ben Dooks 2009-07-16 422
static void ks8851_init_mac(struct ks8851_net *ks)
3ba81f3e drivers/net/ks8851.c Ben Dooks 2009-07-16 423 {
3ba81f3e drivers/net/ks8851.c Ben Dooks 2009-07-16 424
struct net_device *dev = ks->netdev;
566bd54b drivers/net/ethernet/micrel/ks8851.c Lukas Wunner 2017-12-18 425
const u8 *mac_addr;
566bd54b drivers/net/ethernet/micrel/ks8851.c Lukas Wunner 2017-12-18 426
566bd54b drivers/net/ethernet/micrel/ks8851.c Lukas Wunner 2017-12-18 427
mac_addr = of_get_mac_address(ks->spidev->dev.of_node);
a51645f7 drivers/net/ethernet/micrel/ks8851.c Petr Štetiar 2019-05-06 428
if (!IS_ERR(mac_addr)) {
566bd54b
Re: [RFC PATCH v2 00/17] Core scheduling v2
On Wed, May 08, 2019 at 01:49:09PM -0400, Julien Desfossez wrote: > On 08-May-2019 10:30:09 AM, Aaron Lu wrote: > > On Mon, May 06, 2019 at 03:39:37PM -0400, Julien Desfossez wrote: > > > On 29-Apr-2019 11:53:21 AM, Aaron Lu wrote: > > > > This is what I have used to make sure no two unmatched tasks being > > > > scheduled on the same core: (on top of v1, I thinks it's easier to just > > > > show the diff instead of commenting on various places of the patches :-) > > > > > > We imported this fix in v2 and made some small changes and optimizations > > > (with and without Peter’s fix from https://lkml.org/lkml/2019/4/26/658) > > > and in both cases, the performance problem where the core can end up > > > > By 'core', do you mean a logical CPU(hyperthread) or the entire core? > No I really meant the entire core. > > I’m sorry, I should have added a little bit more context. This relates > to a performance issue we saw in v1 and discussed here: > https://lore.kernel.org/lkml/20190410150116.gi2...@worktop.programming.kicks-ass.net/T/#mb9f1f54a99bac468fc5c55b06a9da306ff48e90b > > We proposed a fix that solved this, Peter came up with a better one > (https://lkml.org/lkml/2019/4/26/658), but if we add your isolation fix > as posted above, the same problem reappears. Hope this clarifies your > ask. It's clear now, thanks. I don't immediately see how my isolation fix would make your fix stop working, will need to check. But I'm busy with other stuffs so it will take a while. > > I hope that we did not miss anything crucial while integrating your fix > on top of v2 + Peter’s fix. The changes are conceptually similar, but we > refactored it slightly to make the logic clear. Please have a look and > let us know I suppose you already have a branch that have all the bits there? I wonder if you can share that branch somewhere so I can start working on top of it to make sure we are on the same page? Also, it would be good if you can share the workload, cmdline options, how many workers need to start etc. to reproduce this issue. Thanks.
Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support
On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote: > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi > > b/arch/arm/boot/dts/qcom-msm8974.dtsi > [..] > > + clocks = < MDSS_MDP_CLK>, > > +< MDSS_AHB_CLK>, > > +< MDSS_AXI_CLK>, > > +< MDSS_BYTE0_CLK>, > > +< MDSS_PCLK0_CLK>, > > +< MDSS_ESC0_CLK>, > > +< MMSS_MISC_AHB_CLK>; > > + clock-names = "mdp_core", > > + "iface", > > + "bus", > > + "byte", > > + "pixel", > > + "core", > > + "core_mmss"; > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some > underrun error from DSI. You don't see anything like this? > > (These clocks are controlled by msm_bus downstream and should be driven > by interconnect upstream) > > > Apart from this, I think this looks nice. Happy to see the progress. No, I'm not seeing an underrun errors from the DSI. I think the clocks are fine since I'm able to get this working with 4.17 using these same clocks. I just sent out v2 and the cover letter has some details, along with the full dmesg. Brian
Re: [RFC PATCH v2 11/17] sched: Basic tracking of matching tasks
On 5/8/19 6:38 PM, Aubrey Li wrote: On Thu, May 9, 2019 at 8:29 AM Subhra Mazumdar wrote: On 5/8/19 5:01 PM, Aubrey Li wrote: On Thu, May 9, 2019 at 2:41 AM Subhra Mazumdar wrote: On 5/8/19 11:19 AM, Subhra Mazumdar wrote: On 5/8/19 8:49 AM, Aubrey Li wrote: Pawan ran an experiment setting up 2 VMs, with one VM doing a parallel kernel build and one VM doing sysbench, limiting both VMs to run on 16 cpu threads (8 physical cores), with 8 vcpu for each VM. Making the fix did improve kernel build time by 7%. I'm gonna agree with the patch below, but just wonder if the testing result is consistent, as I didn't see any improvement in my testing environment. IIUC, from the code behavior, especially for 2 VMs case(only 2 different cookies), the per-rq rb tree unlikely has nodes with different cookies, that is, all the nodes on this tree should have the same cookie, so: - if the parameter cookie is equal to the rb tree cookie, we meet a match and go the third branch - else, no matter we go left or right, we can't find a match, and we'll return idle thread finally. Please correct me if I was wrong. Thanks, -Aubrey This is searching in the per core rb tree (rq->core_tree) which can have 2 different cookies. But having said that, even I didn't see any improvement with the patch for my DB test case. But logically it is correct. Ah, my bad. It is per rq. But still can have 2 different cookies. Not sure why you think it is unlikely? Yeah, I meant 2 different cookies on the system, but unlikely 2 different cookies on one same rq. If I read the source correctly, for the sched_core_balance path, when try to steal cookie from another CPU, sched_core_find() uses dst's cookie to search if there is a cookie match in src's rq, and sched_core_find() returns idle or matched task, and later put this matched task onto dst's rq (activate_task() in sched_core_find()). At this moment, the nodes on the rq's rb tree should have same cookies. Thanks, -Aubrey Yes, but sched_core_find is also called from pick_task to find a local matching task. Can a local searching introduce a different cookies? Where is it from? No. I meant the local search uses the same binary search of sched_core_find so it has to be correct. The enqueue side logic of the scheduler is unchanged with core scheduling, But only the task with cookies is placed onto this rb tree? so it is possible tasks with different cookies are enqueued on the same rq. So while searching for a matching task locally doing it correctly should matter. May I know how exactly? select_task_rq_* seems to be unchanged. So the search logic to find a cpu to enqueue when a task becomes runnable is same as before and doesn't do any kind of cookie matching. Thanks, -Aubrey
Re: [PATCH] fpga: dfl: afu: Pass the correct device to dma_mapping_error()
Hi Scott,
On Wed, May 08, 2019 at 04:39:51PM -0500, Scott Wood wrote:
> On Mon, 2019-04-15 at 14:22 -0500, Alan Tull wrote:
> > On Thu, Apr 11, 2019 at 11:36 AM Moritz Fischer
> > wrote:
> >
> > Hi Scott,
> >
> > Thanks!
> >
> > > Hi Scott,
> > >
> > > good catch!
> > >
> > > On Thu, Apr 11, 2019 at 5:49 AM Wu Hao wrote:
> > > > On Wed, Apr 10, 2019 at 04:53:27PM -0500, Scott Wood wrote:
> > > > > dma_mapping_error() was being called on a different device struct
> > > > > than
> > > > > what was passed to map/unmap. Besides rendering the error checking
> > > > > ineffective, it caused a debug splat with CONFIG_DMA_API_DEBUG.
> > > > >
> > > > > Signed-off-by: Scott Wood
> > > >
> > > > Hi Scott,
> > > >
> > > > Looks good to me. Thanks for catching this issue.
> > > >
> > > > Acked-by: Wu Hao
> > > >
> > > > Hao
> > > >
> > > > > ---
> > > > > drivers/fpga/dfl-afu-dma-region.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/fpga/dfl-afu-dma-region.c b/drivers/fpga/dfl-
> > > > > afu-dma-region.c
> > > > > index e18a786fc943..cd68002ac097 100644
> > > > > --- a/drivers/fpga/dfl-afu-dma-region.c
> > > > > +++ b/drivers/fpga/dfl-afu-dma-region.c
> > > > > @@ -399,7 +399,7 @@ int afu_dma_map_region(struct
> > > > > dfl_feature_platform_data *pdata,
> > > > > region->pages[0], 0,
> > > > > region->length,
> > > > > DMA_BIDIRECTIONAL);
> > > > > - if (dma_mapping_error(>dev->dev, region->iova)) {
> > > > > + if (dma_mapping_error(dfl_fpga_pdata_to_parent(pdata), region-
> > > > > >iova)) {
> > > > > dev_err(>dev->dev, "failed to map for dma\n");
> > > > > ret = -EFAULT;
> > > > > goto unpin_pages;
> > > > > --
> > > > > 1.8.3.1
> > >
> > > Acked-by: Moritz Fischer
> >
> > Acked-by: Alan Tull
>
> Whose tree would these patches be going through?
Greg, usually. We're a bit late this time... again ... But haven't forgotten
about it.
Sorry,
Moritz
[PATCH] iio: dummy_evgen: check iio_evgen in iio_dummy_evgen_free()
if iio_dummy_evgen_create() fails, iio_evgen should be NULL, when call
iio_evgen_release() to cleanup, it throws some warning and could cause
double free.
Reported-by: Hulk Robot
Signed-off-by: Kefeng Wang
---
drivers/iio/dummy/iio_dummy_evgen.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/iio/dummy/iio_dummy_evgen.c
b/drivers/iio/dummy/iio_dummy_evgen.c
index c6033e341963..2327b5f52086 100644
--- a/drivers/iio/dummy/iio_dummy_evgen.c
+++ b/drivers/iio/dummy/iio_dummy_evgen.c
@@ -58,6 +58,7 @@ static int iio_dummy_evgen_create(void)
ret = irq_sim_init(_evgen->irq_sim, IIO_EVENTGEN_NO);
if (ret < 0) {
kfree(iio_evgen);
+ iio_evgen = NULL;
return ret;
}
@@ -118,6 +119,9 @@ EXPORT_SYMBOL_GPL(iio_dummy_evgen_get_regs);
static void iio_dummy_evgen_free(void)
{
+ if (!iio_evgen)
+ return;
+
irq_sim_fini(_evgen->irq_sim);
kfree(iio_evgen);
}
--
2.20.1
Re: [PATCH] platform/x86: acer-wmi: Mark expected switch fall-throughs
Darren,
Please, see my comments below...
On 5/8/19 6:06 PM, Darren Hart wrote:
> On Wed, May 08, 2019 at 11:49:34AM -0500, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> This patch fixes the following warnings:
>>
>> drivers/platform/x86/acer-wmi.c: In function ‘set_u32’:
>> drivers/platform/x86/acer-wmi.c:1378:33: warning: this statement may fall
>> through [-Wimplicit-fallthrough=]
>> if (cap == ACER_CAP_WIRELESS ||
>> ^
>> drivers/platform/x86/acer-wmi.c:1386:3: note: here
>>case ACER_WMID:
>>^~~~
>> drivers/platform/x86/acer-wmi.c:1393:12: warning: this statement may fall
>> through [-Wimplicit-fallthrough=]
>> else if (wmi_has_guid(WMID_GUID2))
>> ^
>> drivers/platform/x86/acer-wmi.c:1395:3: note: here
>>default:
>>^~~
>> drivers/platform/x86/acer-wmi.c: In function ‘get_u32’:
>> drivers/platform/x86/acer-wmi.c:1340:6: warning: this statement may fall
>> through [-Wimplicit-fallthrough=]
>>if (cap == ACER_CAP_MAILLED) {
>> ^
>> drivers/platform/x86/acer-wmi.c:1344:2: note: here
>> case ACER_WMID:
>> ^~~~
>> drivers/platform/x86/acer-wmi.c: In function ‘WMID_get_u32’:
>> drivers/platform/x86/acer-wmi.c:1013:6: warning: this statement may fall
>> through [-Wimplicit-fallthrough=]
>>if (quirks->mailled == 1) {
>> ^
>> drivers/platform/x86/acer-wmi.c:1018:2: note: here
>> default:
>> ^~~
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This patch is part of the ongoing efforts to enable
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva
>> ---
>> drivers/platform/x86/acer-wmi.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/platform/x86/acer-wmi.c
>> b/drivers/platform/x86/acer-wmi.c
>> index fcfeadd1301f..bd87f9037f95 100644
>> --- a/drivers/platform/x86/acer-wmi.c
>> +++ b/drivers/platform/x86/acer-wmi.c
>> @@ -1015,6 +1015,7 @@ static acpi_status WMID_get_u32(u32 *value, u32 cap)
>> *value = tmp & 0x1;
>> return 0;
>> }
>> +/* fall through */
>> default:
>> return AE_ERROR;
>> }
>> @@ -1341,6 +1342,7 @@ static acpi_status get_u32(u32 *value, u32 cap)
>> status = AMW0_get_u32(value, cap);
>> break;
>> }
>> +/* fall through */
>
> This doesn't strike me as obviously the right thing to do here. If the
> interface
> type is AMW0_V2, why is it the right thing to do to use WMID_get_u32 if the
> cap
> isn't ACER_CAP_MAILLED?
>
In commit commit 745a5d2126926808295742932d0e36d485efa485 case ACER_AMW0_V2
falls
through to case ACER_WMID deliberately in function set_u32(), without reporting
any error or warning. So, I thought it was fair to assume that the fall-through
is intentional in both functions get_u32() and set_u32(). Otherwise I would
expect to see a message indicating that interface ACER_AMW0_V2 is unavailable
in function set_u32().
This is also complemented by the following...
>> case ACER_WMID:
>> status = WMID_get_u32(value, cap);
>> break;
>> @@ -1383,6 +1385,7 @@ static acpi_status set_u32(u32 value, u32 cap)
>>
>> return AMW0_set_u32(value, cap);
>> }
>> +/* fall through */
>
> Similarly here.
>
> Are we documenting intended behavior, or covering up a bug.
>
Commit 5c742b45dd5fbbb6cf74d3378341704f4b23c5e8 mentions that "This was fixed
in acer_acpi some time ago, but I forgot to port the patch over to acer-wmi
when it was merged." Notice that this driver (acer-wmi) is based on the
no-longer existing acer_acpi driver. But after googling for a while I could
found the fix the original author talks about:
https://repo.or.cz/acer_acpi.git/commitdiff/74c08a38875ffa9989c3100947650ac8a388c189
So, the fix is indeed similar and contains the same fall-throughs from case
ACER_AMW0_V2 to case ACER_WMID in both functions get_u32() and set_u32().
Thanks
--
Gustavo
[PATCH] kernel/panic: Use SYSTEM_RESET2 command for warm reset
Some platforms may need warm reboot support when kernel crashed for post mortem analysis instead of cold reboot. So use config CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci command support for warm reset. Signed-off-by: Prasad Sodagudi --- kernel/panic.c| 4 lib/Kconfig.debug | 10 ++ 2 files changed, 14 insertions(+) diff --git a/kernel/panic.c b/kernel/panic.c index c1fcaad..6ab6675 100644 --- a/kernel/panic.c +++ b/kernel/panic.c @@ -198,6 +198,10 @@ void panic(const char *fmt, ...) console_verbose(); bust_spinlocks(1); +#ifdef CONFIG_WARM_REBOOT_ON_PANIC + /* Configure for warm reboot instead of cold reboot. */ + reboot_mode = REBOOT_WARM; +#endif va_start(args, fmt); len = vscnprintf(buf, sizeof(buf), fmt, args); va_end(args); diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index d695ec1..2a727d8 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1000,6 +1000,16 @@ config PANIC_TIMEOUT value n > 0 will wait n seconds before rebooting, while a timeout value n < 0 will reboot immediately. +config WARM_REBOOT_ON_PANIC + bool "Warm reboot instead of cold reboot for panic" + default n + help + Some vendor platform may need warm reboot instead of cold reboot + for debugging. Before vendor specific power off driver is + probed, platform always gets cold reset. By setting Y here and + support for PSCI V1.1 is present from firmware, platform would + get warm reset instead of cold reset. + config SCHED_DEBUG bool "Collect scheduler debugging info" depends on DEBUG_KERNEL && PROC_FS -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project
RE: [PATCH V12 3/5] thermal: imx_sc: add i.MX system controller thermal support
Ping...
> -Original Message-
> From: Anson Huang [mailto:anson.hu...@nxp.com]
> Sent: Tuesday, April 16, 2019 11:22 AM
> To: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> catalin.mari...@arm.com; will.dea...@arm.com; rui.zh...@intel.com;
> edubez...@gmail.com; daniel.lezc...@linaro.org; Aisheng Dong
> ; ulf.hans...@linaro.org; Daniel Baluta
> ; Peng Fan ;
> he...@sntech.de; horms+rene...@verge.net.au; agr...@kernel.org;
> o...@lixom.net; bjorn.anders...@linaro.org; ja...@amarulasolutions.com;
> enric.balle...@collabora.com; marc.w.gonza...@free.fr;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux...@vger.kernel.org
> Cc: dl-linux-imx
> Subject: [PATCH V12 3/5] thermal: imx_sc: add i.MX system controller
> thermal support
>
> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller inside,
> the system controller is in charge of controlling power, clock and thermal
> sensors etc..
>
> This patch adds i.MX system controller thermal driver support, Linux kernel
> has to communicate with system controller via MU (message unit) IPC to get
> each thermal sensor's temperature, it supports multiple sensors which are
> passed from device tree, please see the binding doc for details.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V11:
> - move the API of getting thermal zone sensor ID to of-thermal.c as
> generic API;
> - remove unnecessary __packed.
> ---
> drivers/thermal/Kconfig | 11
> drivers/thermal/Makefile | 1 +
> drivers/thermal/imx_sc_thermal.c | 137
> +++
> 3 files changed, 149 insertions(+)
> create mode 100644 drivers/thermal/imx_sc_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index
> 653aa27..4e4fa7e 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -223,6 +223,17 @@ config IMX_THERMAL
> cpufreq is used as the cooling device to throttle CPUs when the
> passive trip is crossed.
>
> +config IMX_SC_THERMAL
> + tristate "Temperature sensor driver for NXP i.MX SoCs with System
> Controller"
> + depends on (ARCH_MXC && IMX_SCU) || COMPILE_TEST
> + depends on OF
> + help
> + Support for Temperature Monitor (TEMPMON) found on NXP i.MX
> SoCs with
> + system controller inside, Linux kernel has to communicate with
> system
> + controller via MU (message unit) IPC to get temperature from
> thermal
> + sensor. It supports one critical trip point and one
> + passive trip point for each thermal sensor.
> +
> config MAX77620_THERMAL
> tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
> depends on MFD_MAX77620
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index
> 486d682..4062627 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -40,6 +40,7 @@ obj-$(CONFIG_DB8500_THERMAL)+=
> db8500_thermal.o
> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
> obj-$(CONFIG_TANGO_THERMAL) += tango_thermal.o
> obj-$(CONFIG_IMX_THERMAL)+= imx_thermal.o
> +obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
> obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
> obj-$(CONFIG_QORIQ_THERMAL) += qoriq_thermal.o
> obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
> diff --git a/drivers/thermal/imx_sc_thermal.c
> b/drivers/thermal/imx_sc_thermal.c
> new file mode 100644
> index 000..dcf16fc
> --- /dev/null
> +++ b/drivers/thermal/imx_sc_thermal.c
> @@ -0,0 +1,137 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2018-2019 NXP.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "thermal_core.h"
> +
> +#define IMX_SC_MISC_FUNC_GET_TEMP13
> +#define IMX_SC_C_TEMP0
> +
> +static struct imx_sc_ipc *thermal_ipc_handle;
> +
> +struct imx_sc_sensor {
> + struct thermal_zone_device *tzd;
> + u32 resource_id;
> +};
> +
> +struct req_get_temp {
> + u16 resource_id;
> + u8 type;
> +} __packed;
> +
> +struct resp_get_temp {
> + u16 celsius;
> + u8 tenths;
> +} __packed;
> +
> +struct imx_sc_msg_misc_get_temp {
> + struct imx_sc_rpc_msg hdr;
> + union {
> + struct req_get_temp req;
> + struct resp_get_temp resp;
> + } data;
> +};
> +
> +static int imx_sc_thermal_get_temp(void *data, int *temp) {
> + struct imx_sc_msg_misc_get_temp msg;
> + struct imx_sc_rpc_msg *hdr =
> + struct imx_sc_sensor *sensor = data;
> + int ret;
> +
> + msg.data.req.resource_id = sensor->resource_id;
> + msg.data.req.type = IMX_SC_C_TEMP;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_MISC;
> + hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
> + hdr->size = 2;
> +
> + ret =
RE: [PATCH V11 0/5] Add i.MX7ULP EVK PWM backlight support
Ping... > -Original Message- > From: Anson Huang > Sent: Wednesday, April 24, 2019 10:59 AM > To: thierry.red...@gmail.com; robh...@kernel.org; mark.rutl...@arm.com; > shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de; > feste...@gmail.com; li...@armlinux.org.uk; ste...@agner.ch; > ota...@ossystems.com.br; Leonard Crestez ; > Robin Gong ; u.kleine-koe...@pengutronix.de; linux- > p...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org > Cc: dl-linux-imx > Subject: RE: [PATCH V11 0/5] Add i.MX7ULP EVK PWM backlight support > > Gentle ping... > > > -Original Message- > > From: Anson Huang > > Sent: Wednesday, April 10, 2019 9:47 AM > > To: thierry.red...@gmail.com; robh...@kernel.org; > > mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de; > > ker...@pengutronix.de; feste...@gmail.com; li...@armlinux.org.uk; > > ste...@agner.ch; ota...@ossystems.com.br; Leonard Crestez > > ; Robin Gong ; > > u.kleine-koe...@pengutronix.de; linux- p...@vger.kernel.org; > > devicet...@vger.kernel.org; linux-arm- ker...@lists.infradead.org; > > linux-kernel@vger.kernel.org > > Cc: dl-linux-imx > > Subject: [PATCH V11 0/5] Add i.MX7ULP EVK PWM backlight support > > > > i.MX7ULP EVK board has MIPI-DSI display, its backlight is supplied by > > TPM PWM module, this patch set enables i.MX7ULP TPM PWM driver > support > > and also add backlight support for MIPI-DSI display. > > > > Changes since V10: > > - ONLY change the pwm driver patch. > > > > Anson Huang (5): > > dt-bindings: pwm: Add i.MX TPM PWM binding > > pwm: Add i.MX TPM PWM driver support > > ARM: imx_v6_v7_defconfig: Add TPM PWM support by default > > ARM: dts: imx7ulp: Add tpm pwm support > > ARM: dts: imx7ulp-evk: Add backlight support > > > > .../devicetree/bindings/pwm/imx-tpm-pwm.txt| 22 + > > arch/arm/boot/dts/imx7ulp-evk.dts | 21 + > > arch/arm/boot/dts/imx7ulp.dtsi | 10 + > > arch/arm/configs/imx_v6_v7_defconfig | 1 + > > drivers/pwm/Kconfig| 11 + > > drivers/pwm/Makefile | 1 + > > drivers/pwm/pwm-imx-tpm.c | 442 > + > > 7 files changed, 508 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm- > > pwm.txt > > create mode 100644 drivers/pwm/pwm-imx-tpm.c > > > > -- > > 2.7.4
Re: [PATCH 2/8] soc: tegra: fuse: Change to the correct __dma_request_channel() prototype
On Wed, 8 May 2019 at 23:15, Dmitry Osipenko wrote: > > 07.05.2019 9:09, Baolin Wang пишет: > > Since we've introduced one device node parameter for > > __dma_request_channel(), > > thus change to the correct function prototype. > > > > Signed-off-by: Baolin Wang > > --- > > drivers/soc/tegra/fuse/fuse-tegra20.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/soc/tegra/fuse/fuse-tegra20.c > > b/drivers/soc/tegra/fuse/fuse-tegra20.c > > index 49ff017..e2571b6 100644 > > --- a/drivers/soc/tegra/fuse/fuse-tegra20.c > > +++ b/drivers/soc/tegra/fuse/fuse-tegra20.c > > @@ -110,7 +110,7 @@ static int tegra20_fuse_probe(struct tegra_fuse *fuse) > > dma_cap_zero(mask); > > dma_cap_set(DMA_SLAVE, mask); > > > > - fuse->apbdma.chan = __dma_request_channel(, dma_filter, NULL); > > + fuse->apbdma.chan = __dma_request_channel(, dma_filter, NULL, > > NULL); > > if (!fuse->apbdma.chan) > > return -EPROBE_DEFER; > > > > > > 1) Kernel should be kept bisect'able by not having intermediate patches > that break compilation. Hence you should squash the changes into a > single patch. > > 2) Better to replace __dma_request_channel() with dma_request_channel() > since they are equal. Good point. I'll change to use dma_request_channel() in next version if no other objections. Thanks. -- Baolin Wang Best Regards
RE: [PATCH] mailbox: imx: use devm_platform_ioremap_resource() to simplify code
Ping...
> -Original Message-
> From: Anson Huang
> Sent: Sunday, April 28, 2019 2:27 PM
> To: jassisinghb...@gmail.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Cc: dl-linux-imx
> Subject: RE: [PATCH] mailbox: imx: use devm_platform_ioremap_resource()
> to simplify code
>
> Ping...
>
> > -Original Message-
> > From: Anson Huang
> > Sent: Monday, April 1, 2019 1:15 PM
> > To: jassisinghb...@gmail.com; shawn...@kernel.org;
> > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> > Cc: dl-linux-imx
> > Subject: [PATCH] mailbox: imx: use devm_platform_ioremap_resource() to
> > simplify code
> >
> > Use the new helper devm_platform_ioremap_resource() which wraps the
> > platform_get_resource() and devm_ioremap_resource() together, to
> > simplify the code.
> >
> > Signed-off-by: Anson Huang
> > ---
> > drivers/mailbox/imx-mailbox.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/mailbox/imx-mailbox.c
> > b/drivers/mailbox/imx-mailbox.c index 85fc5b5..25be8bb 100644
> > --- a/drivers/mailbox/imx-mailbox.c
> > +++ b/drivers/mailbox/imx-mailbox.c
> > @@ -264,7 +264,6 @@ static int imx_mu_probe(struct platform_device
> > *pdev) {
> > struct device *dev = >dev;
> > struct device_node *np = dev->of_node;
> > - struct resource *iomem;
> > struct imx_mu_priv *priv;
> > unsigned int i;
> > int ret;
> > @@ -275,8 +274,7 @@ static int imx_mu_probe(struct platform_device
> > *pdev)
> >
> > priv->dev = dev;
> >
> > - iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > - priv->base = devm_ioremap_resource(>dev, iomem);
> > + priv->base = devm_platform_ioremap_resource(pdev, 0);
> > if (IS_ERR(priv->base))
> > return PTR_ERR(priv->base);
> >
> > --
> > 2.7.4
RE: [RESEND] input: keyboard: imx: make sure keyboard can always wake up system
Ping...
> -Original Message-
> From: Anson Huang
> Sent: Thursday, April 25, 2019 9:50 AM
> To: dmitry.torok...@gmail.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> linux-in...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Cc: dl-linux-imx
> Subject: RE: [RESEND] input: keyboard: imx: make sure keyboard can always
> wake up system
>
> Gentle ping...
>
> > -Original Message-
> > From: Anson Huang
> > Sent: Thursday, April 4, 2019 9:40 AM
> > To: dmitry.torok...@gmail.com; shawn...@kernel.org;
> > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> > linux-in...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > linux- ker...@vger.kernel.org
> > Cc: dl-linux-imx
> > Subject: [RESEND] input: keyboard: imx: make sure keyboard can always
> > wake up system
> >
> > There are several scenarios that keyboard can NOT wake up system from
> > suspend, e.g., if a keyboard is depressed between system device
> > suspend phase and device noirq suspend phase, the keyboard ISR will be
> > called and both keyboard depress and release interrupts will be
> > disabled, then keyboard will no longer be able to wake up system.
> > Another scenario would be, if a keyboard is kept depressed, and then
> > system goes into suspend, the expected behavior would be when keyboard
> > is released, system will be waked up, but current implementation can
> > NOT achieve that, because both depress and release interrupts are
> > disabled in ISR, and the event check is still in progress.
> >
> > To fix these issues, need to make sure keyboard's depress or release
> > interrupt is enabled after noirq device suspend phase, this patch
> > moves the suspend/resume callback to noirq suspend/resume phase, and
> > enable the corresponding interrupt according to current keyboard status.
> >
> > Signed-off-by: Anson Huang
> > ---
> > drivers/input/keyboard/imx_keypad.c | 18 ++
> > 1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/input/keyboard/imx_keypad.c
> > b/drivers/input/keyboard/imx_keypad.c
> > index cf08f4a..97500a2 100644
> > --- a/drivers/input/keyboard/imx_keypad.c
> > +++ b/drivers/input/keyboard/imx_keypad.c
> > @@ -524,11 +524,12 @@ static int imx_keypad_probe(struct
> > platform_device *pdev)
> > return 0;
> > }
> >
> > -static int __maybe_unused imx_kbd_suspend(struct device *dev)
> > +static int __maybe_unused imx_kbd_noirq_suspend(struct device *dev)
> > {
> > struct platform_device *pdev = to_platform_device(dev);
> > struct imx_keypad *kbd = platform_get_drvdata(pdev);
> > struct input_dev *input_dev = kbd->input_dev;
> > + unsigned short reg_val = readw(kbd->mmio_base + KPSR);
> >
> > /* imx kbd can wake up system even clock is disabled */
> > mutex_lock(_dev->mutex);
> > @@ -538,13 +539,20 @@ static int __maybe_unused
> imx_kbd_suspend(struct
> > device *dev)
> >
> > mutex_unlock(_dev->mutex);
> >
> > - if (device_may_wakeup(>dev))
> > + if (device_may_wakeup(>dev)) {
> > + if (reg_val & KBD_STAT_KPKD)
> > + reg_val |= KBD_STAT_KRIE;
> > + if (reg_val & KBD_STAT_KPKR)
> > + reg_val |= KBD_STAT_KDIE;
> > + writew(reg_val, kbd->mmio_base + KPSR);
> > +
> > enable_irq_wake(kbd->irq);
> > + }
> >
> > return 0;
> > }
> >
> > -static int __maybe_unused imx_kbd_resume(struct device *dev)
> > +static int __maybe_unused imx_kbd_noirq_resume(struct device *dev)
> > {
> > struct platform_device *pdev = to_platform_device(dev);
> > struct imx_keypad *kbd = platform_get_drvdata(pdev); @@ -568,7
> > +576,9 @@ static int __maybe_unused imx_kbd_resume(struct device
> *dev)
> > return ret;
> > }
> >
> > -static SIMPLE_DEV_PM_OPS(imx_kbd_pm_ops, imx_kbd_suspend,
> > imx_kbd_resume);
> > +static const struct dev_pm_ops imx_kbd_pm_ops = {
> > + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_kbd_noirq_suspend,
> > +imx_kbd_noirq_resume) };
> >
> > static struct platform_driver imx_keypad_driver = {
> > .driver = {
> > --
> > 2.7.4
RE: [PATCH] input: imx6ul_tsc: use devm_platform_ioremap_resource() to simplify code
Ping...
> -Original Message-
> From: Anson Huang
> Sent: Sunday, April 28, 2019 2:30 PM
> To: Mukesh Ojha ; dmitry.torok...@gmail.com;
> shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de;
> feste...@gmail.com; linux-in...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: dl-linux-imx
> Subject: RE: [PATCH] input: imx6ul_tsc: use
> devm_platform_ioremap_resource() to simplify code
>
> Ping...
>
> > -Original Message-
> > From: Mukesh Ojha [mailto:mo...@codeaurora.org]
> > Sent: Monday, April 1, 2019 4:02 PM
> > To: Anson Huang ; dmitry.torok...@gmail.com;
> > shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de;
> > feste...@gmail.com; linux-in...@vger.kernel.org; linux-arm-
> > ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> > Cc: dl-linux-imx
> > Subject: Re: [PATCH] input: imx6ul_tsc: use
> > devm_platform_ioremap_resource() to simplify code
> >
> >
> > On 4/1/2019 10:49 AM, Anson Huang wrote:
> > > Use the new helper devm_platform_ioremap_resource() which wraps the
> > > platform_get_resource() and devm_ioremap_resource() together, to
> > > simplify the code.
> > >
> > > Signed-off-by: Anson Huang
> >
> >
> > Reviewed-by: Mukesh Ojha
> >
> > Cheers,
> > -Mukesh
> >
> > > ---
> > > drivers/input/touchscreen/imx6ul_tsc.c | 8 ++--
> > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/input/touchscreen/imx6ul_tsc.c
> > > b/drivers/input/touchscreen/imx6ul_tsc.c
> > > index c10fc59..e04eecd 100644
> > > --- a/drivers/input/touchscreen/imx6ul_tsc.c
> > > +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> > > @@ -364,8 +364,6 @@ static int imx6ul_tsc_probe(struct
> > > platform_device
> > *pdev)
> > > struct device_node *np = pdev->dev.of_node;
> > > struct imx6ul_tsc *tsc;
> > > struct input_dev *input_dev;
> > > - struct resource *tsc_mem;
> > > - struct resource *adc_mem;
> > > int err;
> > > int tsc_irq;
> > > int adc_irq;
> > > @@ -403,16 +401,14 @@ static int imx6ul_tsc_probe(struct
> > platform_device *pdev)
> > > return err;
> > > }
> > >
> > > - tsc_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > - tsc->tsc_regs = devm_ioremap_resource(>dev, tsc_mem);
> > > + tsc->tsc_regs = devm_platform_ioremap_resource(pdev, 0);
> > > if (IS_ERR(tsc->tsc_regs)) {
> > > err = PTR_ERR(tsc->tsc_regs);
> > > dev_err(>dev, "failed to remap tsc memory: %d\n",
> > err);
> > > return err;
> > > }
> > >
> > > - adc_mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > > - tsc->adc_regs = devm_ioremap_resource(>dev, adc_mem);
> > > + tsc->adc_regs = devm_platform_ioremap_resource(pdev, 1);
> > > if (IS_ERR(tsc->adc_regs)) {
> > > err = PTR_ERR(tsc->adc_regs);
> > > dev_err(>dev, "failed to remap adc memory: %d\n",
> > err);
RE: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle
> -Original Message- > From: Christoph Hellwig > Sent: Wednesday, May 8, 2019 2:52 PM > To: Limonciello, Mario > Cc: kai.heng.f...@canonical.com; kbu...@kernel.org; keith.bu...@intel.com; > ax...@fb.com; h...@lst.de; s...@grimberg.me; linux-n...@lists.infradead.org; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 > on > Suspend-to-Idle > > > [EXTERNAL EMAIL] > > On Wed, May 08, 2019 at 07:38:50PM +, mario.limoncie...@dell.com wrote: > > The existing routines have an implied assumption that firmware will come > swinging > > with a hammer to control the rails the SSD sits on. > > With S2I everything needs to come from the driver side and it really is a > > different paradigm. > > And that is why is this patch is fundamentally broken. > > When using the simple pm ops suspend the pm core expects the device > to be powered off. If fancy suspend doesn't want that we need to > communicate what to do to the device in another way, as the whole > thing is a platform decision. There probabl is one (or five) methods > in dev_pm_ops that do the right thing, but please coordinate this > with the PM maintainers to make sure it does the right thing and > doesn't for example break either hibernate where we really don't > expect just a lower power state, or You might think this would be adding runtime_suspend/runtime_resume callbacks, but those also get called actually at runtime which is not the goal here. At runtime, these types of disks should rely on APST which should calculate the appropriate latencies around the different power states. This code path is only applicable in the suspend to idle state, which /does/ call suspend/resume functions associated with dev_pm_ops. There isn't a dedicated function in there for use only in suspend to idle, which is why pm_suspend_via_s2idle() needs to get called. SIMPLE_DEV_PM_OPS normally sets the same function for suspend and freeze (hibernate), so to avoid any changes to the hibernate case it seems to me that there needs to be a new nvme_freeze() that calls into the existing nvme_dev_disable for the freeze pm op and nvme_thaw() that calls into the existing nvme_reset_ctrl for the thaw pm op. > enterprise class NVMe devices > that don't do APST and don't really do different power states at > all in many cases. Enterprise class NVMe devices that don't do APST - do they typically have a non-zero value for ndev->ctrl.npss? If not, they wouldn't enter this new codepath even if the server entered into S2I.
Re: [RFC PATCH v2 11/17] sched: Basic tracking of matching tasks
On Thu, May 9, 2019 at 8:29 AM Subhra Mazumdar wrote: > > > On 5/8/19 5:01 PM, Aubrey Li wrote: > > On Thu, May 9, 2019 at 2:41 AM Subhra Mazumdar > > wrote: > >> > >> On 5/8/19 11:19 AM, Subhra Mazumdar wrote: > >>> On 5/8/19 8:49 AM, Aubrey Li wrote: > > Pawan ran an experiment setting up 2 VMs, with one VM doing a > > parallel kernel build and one VM doing sysbench, > > limiting both VMs to run on 16 cpu threads (8 physical cores), with > > 8 vcpu for each VM. > > Making the fix did improve kernel build time by 7%. > I'm gonna agree with the patch below, but just wonder if the testing > result is consistent, > as I didn't see any improvement in my testing environment. > > IIUC, from the code behavior, especially for 2 VMs case(only 2 > different cookies), the > per-rq rb tree unlikely has nodes with different cookies, that is, all > the nodes on this > tree should have the same cookie, so: > - if the parameter cookie is equal to the rb tree cookie, we meet a > match and go the > third branch > - else, no matter we go left or right, we can't find a match, and > we'll return idle thread > finally. > > Please correct me if I was wrong. > > Thanks, > -Aubrey > >>> This is searching in the per core rb tree (rq->core_tree) which can have > >>> 2 different cookies. But having said that, even I didn't see any > >>> improvement with the patch for my DB test case. But logically it is > >>> correct. > >>> > >> Ah, my bad. It is per rq. But still can have 2 different cookies. Not sure > >> why you think it is unlikely? > > Yeah, I meant 2 different cookies on the system, but unlikely 2 > > different cookies > > on one same rq. > > > > If I read the source correctly, for the sched_core_balance path, when try to > > steal cookie from another CPU, sched_core_find() uses dst's cookie to search > > if there is a cookie match in src's rq, and sched_core_find() returns idle > > or > > matched task, and later put this matched task onto dst's rq > > (activate_task() in > > sched_core_find()). At this moment, the nodes on the rq's rb tree should > > have > > same cookies. > > > > Thanks, > > -Aubrey > Yes, but sched_core_find is also called from pick_task to find a local > matching task. Can a local searching introduce a different cookies? Where is it from? > The enqueue side logic of the scheduler is unchanged with > core scheduling, But only the task with cookies is placed onto this rb tree? > so it is possible tasks with different cookies are > enqueued on the same rq. So while searching for a matching task locally > doing it correctly should matter. May I know how exactly? Thanks, -Aubrey
Re: PSCI version 1.1 and SYSTEM_RESET2
On 2019-05-02 02:05, Sudeep Holla wrote: On Wed, May 01, 2019 at 11:43:00AM -0700, Sodagudi Prasad wrote: On 2019-05-01 02:49, Sudeep Holla wrote: > On Tue, Apr 30, 2019 at 05:07:31PM -0700, Sodagudi Prasad wrote: > > On 2019-04-30 14:44, Sodagudi Prasad wrote: [...] > > > > It would nice if there is a config option to reboot the device > > either in > > warm or cold in the case of kernel panic. > > I presume you prefer to do warm boot in case of panic to get a dump of > the memory to inspect ? If so, is kexec/kdump not the mechanism to > achieve that ? Hi Sudeep, Thanks for your response and sharing details about your patch. > If so, is kexec/kdump not the mechanism to achieve that? > Qualcomm is having vendor specific solution to capture ram contents and for offline analysis. Ah OK. > > I am just trying to understand the use case. Xilinx asked for the same > but never got to understand their use case. Here is the background - Usually, power off drivers are overriding arm_pm_restart and pm_power_off callbacks and registering with reboot notifier with some priority for the reboot operations. Here is the Qualcomm poweroff driver for reference. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/reset/msm-poweroff.c Before vendor chip set specific power off driver is probed, arm_pm_restart functions pointer holds the psci_sys_reset function. Once vendor power off driver is probed, vendor drivers can override the arm_pm_restart function pointer. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/psci.c#n562 Once vendor driver is probed, drivers can take care of devices warm or hard reset configuration part properly. But there is a window from start_kernel() to vendor specific driver probed, devices are getting cold resets even if kernel crashed. This is due to arm_pm_restart points to psci_sys_reset function by default. Is this problem clear now? Too specific use case IMO and I am not sure if we need a generic solution to deal with this. Anyways, I don't see any check in arch/psci specific code for what you want, just ensure reboot_mode is set appropriately. Post a patch and see what people have to say. Hi Sudeep, Yes. With your system_reset2 command support addition, just configuring the reboot_mode is good enough. -Thanks, Prasad Qualcomm downstream kernel has a lot of use cases with respect device reset sequence and the downstream driver is much different from upstream drivers. I think, the above-mentioned problem is common for all the chipset vendors and it is not specific Qualcomm use cases. I have one downstream solution to this problem but thought to bring up this problem to the upstream community for a common solution, so that all the vendors can use it. May be or may be not, post the patch and let's see. I have modified below flow to avoid cold restart in the case of early kernel panic. panic() --> emergency_restart() --> machine_emergency_restart() --> machine_restart(NULL); -Thanks, Prasad > > -- > Regards, > Sudeep -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, Linux Foundation Collaborative Project -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, Linux Foundation Collaborative Project
[PATCH v4 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation
Restrict kdump to only reserve crashkernel below 64TB. The reaons is that the kdump may jump from 5-level to 4-level, and if the kdump kernel is put above 64TB, then the jumping will fail. While the 1st kernel reserves crashkernel region during bootup, we don't know yet which kind of kernel will be loaded after system bootup, 5-level kernel or 5-level kernel. Signed-off-by: Baoquan He Acked-by: Kirill A. Shutemov --- arch/x86/kernel/setup.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 905dae880563..efb0934a46f6 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -452,15 +452,26 @@ static void __init memblock_x86_reserve_range_setup_data(void) #define CRASH_ALIGNSZ_16M /* - * Keep the crash kernel below this limit. On 32 bits earlier kernels - * would limit the kernel to the low 512 MiB due to mapping restrictions. + * Keep the crash kernel below this limit. + * + * On 32 bits earlier kernels would limit the kernel to the low + * 512 MiB due to mapping restrictions. + * + * On 64bit, old kexec-tools need to be under 896MiB. The later + * supports to put kernel above 4G, up to system RAM top. Here + * kdump kernel need be restricted to be under 64TB, which is + * the upper limit of system RAM in 4-level paing mode. Since + * the kdump jumping could be from 5-level to 4-level, the jumping + * will fail if kernel is put above 64TB, and there's no way to + * detect the paging mode of the kernel which will be loaded for + * dumping during the 1st kernel bootup. */ #ifdef CONFIG_X86_32 # define CRASH_ADDR_LOW_MAXSZ_512M # define CRASH_ADDR_HIGH_MAX SZ_512M #else # define CRASH_ADDR_LOW_MAXSZ_4G -# define CRASH_ADDR_HIGH_MAX MAXMEM +# define CRASH_ADDR_HIGH_MAX (64UL << 40) #endif static int __init reserve_crashkernel_low(void) -- 2.17.2
[PATCH v4 0/3] Add restrictions for kexec/kdump jumping between 5-level and 4-level kernel
This patchset is trying to fix several issues for kexec/kdump when dynamic switching of paging mode is enabled in x86_64. The current kernel supports 5-level paging mode, and supports dynamically choosing paging mode during bootup according to kernel image, hardware and kernel parameter setting. This flexibility brings several issues for kexec/kdump: Issues: 1) Dynamic switching between paging mode requires code change in target kernel. So we can't kexec jump from 5-level kernel to old 4-level kernel which lacks the code change. 2) Switching from 5-level paging to 4-level paging kernel would fail, if kexec() put kernel image above 64TiB of memory. 3) Kdump jumping has similar issue as 2). This require us to only reserve crashkernel below 64TB, otherwise jumping from 5-level to 4-level kernel will fail. Note: Since we have two interfaces kexec_load() and kexec_file_load() to load kexec/kdump kernel, handling for them is a little different. For kexec_load(), most of the loading job is done in user space utility kexec_tools. However, for kexec_file_load(), most of the loading codes have moved into kernel because of kernel image verification. Fixes: a) For issue 1), we need check if XLF_5LEVEL is set, otherwise error out a message. -This need be done in both kernel and kexec_tools utility. -Patch 2/3 is the handling of kernel part. -Will post user space patch to kexec mailing list later. b) For issue 2), we need check if both XLF_5LEVEL and XLF_5LEVEL_ENABLED are set, otherwise error out a message. -This only need be done in kexec_tools utility. Because for kexec_file_load(), the current code searches area to put kernel from bottom to up in system RAM, we usually can always find an area below 4 GB, no need to worry about 5-level kernel jumping to 4-level kernel. While for kexec_load(), it's top down seraching area for kernel loading, and implemented in user space. We need make sure that 5-level kernel find an area under 64 TB for a kexec-ed kernel of 4-level. -Will post user space patch to kexec mailing list later. c) For issues 3), just limit kernel to reserve crashkernel below 64 TB. -This only need be done in kernel. -It doesn't need to check bit XLF_5LEVEL or XLF_5LEVEL_ENABLED, we just simply limit it below 64 TB which should be enough. Because crashernel is reserved during the 1st kernel's bootup, we don't know what kernel will be loaded for kdump usage. -Patch 3/3 handles this. Changelog: v3->v4: No functional change. - Rewrite log of patch 1/3 tell who the newly added bits are gonna be used. - Rewrite log of patch 2/3 per tglx's words. - Add Kirill's Acked-by. v2->v3: Change the constant to match the notation for the rest of defines as Kirill suggested; v1->v2: Correct the subject of patch 1 according to tglx's comment; Add more information to cover-letter to address reviewers' concerns; The original v1 post can be found here: http://lkml.kernel.org/r/20180829141624.13985-1-...@redhat.com Later a v1 RESEND version: http://lkml.kernel.org/r/20190125022817.29506-1-...@redhat.com V2 post is here: http://lkml.kernel.org/r/20190312005004.19182-1-...@redhat.com v3 post: http://lkml.kernel.org/r/20190312103051.18086-1-...@redhat.com Baoquan He (3): x86/boot: Add xloadflags bits for 5-level kernel checking x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel x86/kdump/64: Change the upper limit of crashkernel reservation arch/x86/boot/header.S| 12 +++- arch/x86/include/uapi/asm/bootparam.h | 2 ++ arch/x86/kernel/kexec-bzimage64.c | 5 + arch/x86/kernel/setup.c | 17 ++--- 4 files changed, 32 insertions(+), 4 deletions(-) -- 2.17.2
[PATCH v4 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel
If the running kernel has 5-level paging activated, the 5-level paging
mode is preserved across kexec. If the kexec'ed kernel does not contain
support for handling active 5-level paging mode in the decompressor, the
decompressor will crash with #GP.
Prevent this situation at load time. If 5-level paging is active, check the
xloadflags whether the kexec kernel can handle 5-level paging at least in
the decompressor. If not, reject the load attempt and print out error
message.
Signed-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
---
arch/x86/kernel/kexec-bzimage64.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86/kernel/kexec-bzimage64.c
index 22f60dd26460..858cc892672f 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -321,6 +321,11 @@ static int bzImage64_probe(const char *buf, unsigned long
len)
return ret;
}
+ if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
+ pr_err("Can not jump to old 4-level kernel from 5-level
kernel.\n");
+ return ret;
+ }
+
/* I've got a bzImage */
pr_debug("It's a relocatable bzImage64\n");
ret = 0;
--
2.17.2
[PATCH v4 1/3] x86/boot: Add xloadflags bits for 5-level kernel checking
The current kernel supports 5-level paging mode, and supports dynamically choosing paging mode during bootup according to kernel image, hardware and kernel parameter setting. This flexibility brings several issues to kexec/kdump: 1) Dynamic switching between paging modes requires code change in target kernel. So we can't do kexec-jumping from 5-level kernel to old 4-level kernel which lacks the code change. 2) Kexec jumping from 5-level kernel to 4-level kernel would fail, if kexec loading puts kernel image above 64 TB of memory. Because kexec loading searches area to put kernel from top to down in system RAM, the 2nd kernel will be loaded above 64 TB if the amount of system RAM is bigger than 64 TB. Here no need to worry about kexec_file loading, because it searches area from bottom to up, and can always find area below 4 GB. Solution: Add two bits XLF_5LEVEL and XLF_5LEVEL_ENABLED for 5-level kernel. - Bit XLF_5LEVEL indicates if 5-level related code is contained in this kernel. - Bit XLF_5LEVEL_ENABLED indicates if CONFIG_X86_5LEVEL=y is set. a) For issue 1), need check if XLF_5LEVEL is set, otherwise print out error message. - This checking need be added in kernel, for the code of kexec_file loading; - And also need be added into kexec_tools utility, for kexec loading. b) For issue 2), need check if both XLF_5LEVEL and XLF_5LEVEL_ENABLED are set, otherwise print out error message. - This only need be done in kexec_tools utility, because kexec loading does the searching in user space kexec_tools. So here add XLF_5LEVEL and XLF_5LEVEL_ENABLED into xloadflags. The later code will check XLF_5LEVEL bit in kexec_file implementation of kernel. And the kexec_tools code will check both XLF_5LEVEL and XLF_5LEVEL_ENABLED for kexec loading. Signed-off-by: Baoquan He Acked-by: Kirill A. Shutemov --- arch/x86/boot/header.S| 12 +++- arch/x86/include/uapi/asm/bootparam.h | 2 ++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 850b8762e889..be19f4199727 100644 --- a/arch/x86/boot/header.S +++ b/arch/x86/boot/header.S @@ -419,7 +419,17 @@ xloadflags: # define XLF4 0 #endif - .word XLF0 | XLF1 | XLF23 | XLF4 +#ifdef CONFIG_X86_64 +#ifdef CONFIG_X86_5LEVEL +#define XLF56 (XLF_5LEVEL|XLF_5LEVEL_ENABLED) +#else +#define XLF56 XLF_5LEVEL +#endif +#else +#define XLF56 0 +#endif + + .word XLF0 | XLF1 | XLF23 | XLF4 | XLF56 cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line, #added with boot protocol diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h index 60733f137e9a..c895df5482c5 100644 --- a/arch/x86/include/uapi/asm/bootparam.h +++ b/arch/x86/include/uapi/asm/bootparam.h @@ -29,6 +29,8 @@ #define XLF_EFI_HANDOVER_32(1<<2) #define XLF_EFI_HANDOVER_64(1<<3) #define XLF_EFI_KEXEC (1<<4) +#define XLF_5LEVEL (1<<5) +#define XLF_5LEVEL_ENABLED (1<<6) #ifndef __ASSEMBLY__ -- 2.17.2
Re: [PATCH 2/4] x86/kprobes: Fix frame pointer annotations
Hi Josh, On Wed, 8 May 2019 13:48:48 -0500 Josh Poimboeuf wrote: > On Wed, May 08, 2019 at 05:39:07PM +0200, Peter Zijlstra wrote: > > On Wed, May 08, 2019 at 07:42:48AM -0500, Josh Poimboeuf wrote: > > > On Wed, May 08, 2019 at 02:04:16PM +0200, Peter Zijlstra wrote: > > > > > > Do the x86_64 variants also want some ORC annotation? > > > > > > Maybe so. Though it looks like regs->ip isn't saved. The saved > > > registers might need to be tweaked. I'll need to look into it. > > > > What all these sites do (and maybe we should look at unifying them > > somehow) is turn a CALL frame (aka RET-IP) into an exception frame (aka > > pt_regs). > > > > So regs->ip will be the return address (which is fixed up to be the CALL > > address in the handler). > > But from what I can tell, trampoline_handler() hard-codes regs->ip to > point to kretprobe_trampoline(), and the original return address is > placed in regs->sp. > > Masami, is there a reason why regs->ip doesn't have the original return > address and regs->sp doesn't have the original SP? I think that would > help the unwinder understand things. Yes, for regs->ip, there is a histrical reason. Since previously, we had an int3 at trampoline, so the user (kretprobe) handler expects that regs->ip is trampoline address and ri->ret_addr is original return address. It is better to check the other archs, but I think it is possible to change the regs->ip to original return address, since no one cares such "fixed address". :) For the regs->sp, there are 2 reasons. For x86-64, it's just for over-optimizing (reduce stack usage). I think we can make a gap for putting return address, something like "kretprobe_trampoline:\n" #ifdef CONFIG_X86_64 " pushq %rsp\n" /* Make a gap for return address */ " pushq 0(%rsp)\n"/* Copy original stack pointer */ " pushfq\n" SAVE_REGS_STRING " movq %rsp, %rdi\n" " call trampoline_handler\n" /* Push the true return address to the bottom */ " movq %rax, 20*8(%rsp)\n" RESTORE_REGS_STRING " popfq\n" " addq $8, %rsp\n"/* Skip original stack pointer */ For i386 (x86-32), there is no other way to keep >sp as the original stack pointer. It has to be changed with this series, maybe as same as x86-64. Thank you, -- Masami Hiramatsu
Re: [PATCH v2] hv: tools: fixed Python pep8/flake8 warnings for lsvmbus
On Tue, May 07, 2019 at 05:02:47AM +, Dexuan Cui wrote: From: Adrian Vladu Sent: Monday, May 6, 2019 10:34 AM To: linux-kernel@vger.kernel.org Cc: Adrian Vladu ; KY Srinivasan ; Haiyang Zhang ; Stephen Hemminger ; Sasha Levin ; Dexuan Cui ; Alessandro Pilotti Subject: [PATCH v2] hv: tools: fixed Python pep8/flake8 warnings for lsvmbus Fixed pep8/flake8 python style code for lsvmbus tool. The TAB indentation was on purpose ignored (pep8 rule W191) to make sure the code is complying with the Linux code guideline. The following command do not show any warnings now: pep8 --ignore=W191 lsvmbus flake8 --ignore=W191 lsvmbus Signed-off-by: Adrian Vladu Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Sasha Levin Cc: Dexuan Cui Cc: Alessandro Pilotti [...] Looks good to me. Thanks, Adrian! Reviewed-by: Dexuan Cui Queued for hyperv-fixes, thanks! -- Thanks, Sasha
Re: [PATCH] hv: tools: fix KVP and VSS daemons exit code
On Mon, May 06, 2019 at 04:50:58PM +, Adrian Vladu wrote: HyperV KVP and VSS daemons should exit with 0 when the '--help' or '-h' flags are used. Signed-off-by: Adrian Vladu Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Sasha Levin Cc: Alessandro Pilotti Queued for hyperv-fixes, thanks! -- Thanks, Sasha
Re: [PATCH] hv: tools: fix typos in toolchain
On Mon, May 06, 2019 at 04:51:24PM +, Adrian Vladu wrote: Fix typos in the HyperV toolchain. Signed-off-by: Adrian Vladu Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Sasha Levin Cc: Alessandro Pilotti Queued for hyperv-fixes, thanks! -- Thanks, Sasha
Re: [PATCH] Drivers: hv: vmbus: Fix virt_to_hvpfn() for X86_PAE
On Tue, May 07, 2019 at 12:51:51PM +, Michael Kelley wrote:
From: Dexuan Cui Sent: Tuesday, May 7, 2019 12:47 AM
In the case of X86_PAE, unsigned long is u32, but the physical address type
should be u64. Due to the bug here, the netvsc driver can not load
successfully, and sometimes the VM can panic due to memory corruption (the
hypervisor writes data to the wrong location).
Fixes: 6ba34171bcbd ("Drivers: hv: vmbus: Remove use of slow_virt_to_phys()")
Cc: sta...@vger.kernel.org
Cc: Michael Kelley
Reported-and-tested-by: Juliana Rodrigueiro
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
Queued for hyperv-fixes, thanks!
--
Thanks,
Sasha
[PATCH v2] kbuild: re-enable int-in-bool-context warning
This warning was disabled by commit bd664f6b3e37 ("disable new
gcc-7.1.1 warnings for now") just because it was too noisy.
Thanks to Arnd Bergmann, all warnings have been fixed. Now, we are
ready to re-enable it.
Signed-off-by: Masahiro Yamada
Cc: Arnd Bergmann
---
Changes in v2:
- rebase
Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/Makefile b/Makefile
index a61a95b..2896518 100644
--- a/Makefile
+++ b/Makefile
@@ -692,7 +692,6 @@ KBUILD_CFLAGS += $(call
cc-option,-fno-delete-null-pointer-checks,)
KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
KBUILD_CFLAGS += $(call cc-disable-warning, format-overflow)
-KBUILD_CFLAGS += $(call cc-disable-warning, int-in-bool-context)
KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
--
2.7.4
[PATCH] i2c: tegra: use busendiannes variable
Converting from bus to host endiannes was done using the same variable
which makes sparse unhappy as it can not verify the endiannes handling
properly. To allow sparse to verify endiannes handling a __le32 is
introduced. This patch does not actually change the code logic while
the binary does change due to limit on instruction re-ordering induced
by the additional constraint.
Signed-off-by: Nicholas Mc Guire
---
Problem located by an experimental coccinelle script to locate
patters that make sparse unhappy (false positives):
sparse was complaining about:
drivers/i2c/busses/i2c-tegra.c:596:23: warning: cast to restricted __le32
Note that the binary does change in this case - from inspection of the
.lst files it seems that the introduction of the __le32 limits
the re-ordering options for the compiler so one instruction
position changed (ldr r1, [sp, #4]) but from my understanding
that does not change the program logic here.
Patch was compile-tested with: tegra_defconfig (implies I2C_TEGRA=y)
Patch is against 5.1 (localversion-next is next-20190508)
drivers/i2c/busses/i2c-tegra.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index ebaa78d..cbaddcc 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -543,18 +543,19 @@ static int tegra_i2c_empty_rx_fifo(struct tegra_i2c_dev
*i2c_dev)
static int tegra_i2c_fill_tx_fifo(struct tegra_i2c_dev *i2c_dev)
{
u32 val;
+ __le32 busval;
int tx_fifo_avail;
u8 *buf = i2c_dev->msg_buf;
size_t buf_remaining = i2c_dev->msg_buf_remaining;
int words_to_transfer;
if (i2c_dev->hw->has_mst_fifo) {
- val = i2c_readl(i2c_dev, I2C_MST_FIFO_STATUS);
- tx_fifo_avail = (val & I2C_MST_FIFO_STATUS_TX_MASK) >>
+ busval = i2c_readl(i2c_dev, I2C_MST_FIFO_STATUS);
+ tx_fifo_avail = (busval & I2C_MST_FIFO_STATUS_TX_MASK) >>
I2C_MST_FIFO_STATUS_TX_SHIFT;
} else {
- val = i2c_readl(i2c_dev, I2C_FIFO_STATUS);
- tx_fifo_avail = (val & I2C_FIFO_STATUS_TX_MASK) >>
+ busval = i2c_readl(i2c_dev, I2C_FIFO_STATUS);
+ tx_fifo_avail = (busval & I2C_FIFO_STATUS_TX_MASK) >>
I2C_FIFO_STATUS_TX_SHIFT;
}
@@ -592,8 +593,8 @@ static int tegra_i2c_fill_tx_fifo(struct tegra_i2c_dev
*i2c_dev)
*/
if (tx_fifo_avail > 0 && buf_remaining > 0) {
BUG_ON(buf_remaining > 3);
- memcpy(, buf, buf_remaining);
- val = le32_to_cpu(val);
+ memcpy(, buf, buf_remaining);
+ val = le32_to_cpu(busval);
/* Again update before writing to FIFO to make sure isr sees. */
i2c_dev->msg_buf_remaining = 0;
--
2.1.4
Re: [PATCH v2 00/23] locking/lockdep: Small improvements
Thank you so much. On Wed, 8 May 2019 at 16:56, Peter Zijlstra wrote: > > On Mon, May 06, 2019 at 04:19:16PM +0800, Yuyang Du wrote: > > Hi Peter, > > > > Let me post these small bits first while waiting for Frederic's patches > > to be merged. > > > > They apply nicely and should show up in tip after the merge window > closes or thereabout. > > Thanks!
Re: [PATCH] ia64: require -Wl,--hash-style=sysv
On Thu, May 9, 2019 at 4:27 AM Nick Desaulniers wrote: > > bumping for review, as the merge window is now open. ia64 is not very active these days. I applied this to my kbuild tree. I will send PR for this in the current MW. Thanks. > On Tue, Apr 30, 2019 at 1:24 PM Nick Desaulniers > wrote: > > > > On Tue, Apr 23, 2019 at 1:48 PM Nick Desaulniers > > wrote: > > > > > > Towards the goal of removing cc-ldoption, it seems that --hash-style= > > > was added to binutils 2.17.50.0.2 in 2006. The minimal required version > > > of binutils for the kernel according to > > > Documentation/process/changes.rst is 2.20. > > > > > > Link: https://gcc.gnu.org/ml/gcc/2007-01/msg01141.html > > > Cc: clang-built-li...@googlegroups.com > > > Suggested-by: Masahiro Yamada > > > Signed-off-by: Nick Desaulniers > > > --- > > > arch/ia64/kernel/Makefile.gate | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/ia64/kernel/Makefile.gate > > > b/arch/ia64/kernel/Makefile.gate > > > index f53faf48b7ce..846867bff6d6 100644 > > > --- a/arch/ia64/kernel/Makefile.gate > > > +++ b/arch/ia64/kernel/Makefile.gate > > > @@ -11,7 +11,7 @@ quiet_cmd_gate = GATE$@ > > >cmd_gate = $(CC) -nostdlib $(GATECFLAGS_$(@F)) -Wl,-T,$(filter-out > > > FORCE,$^) -o $@ > > > > > > GATECFLAGS_gate.so = -shared -s -Wl,-soname=linux-gate.so.1 \ > > > -$(call cc-ldoption, -Wl$(comma)--hash-style=sysv) > > > +-Wl,--hash-style=sysv > > > $(obj)/gate.so: $(obj)/gate.lds $(obj)/gate.o FORCE > > > $(call if_changed,gate) > > > > > > -- > > > 2.21.0.593.g511ec345e18-goog > > > > > > > bumping for review > > > > -- > > Thanks, > > ~Nick Desaulniers > > > > -- > Thanks, > ~Nick Desaulniers -- Best Regards Masahiro Yamada
linux-next: manual merge of the jc_docs tree with Linus' tree
Hi Jon,
Today's linux-next merge of the jc_docs tree got a conflict in:
Documentation/x86/x86_64/mm.txt
between commit:
89502a019790 ("x86/mm: Fix the 56-bit addresses memory map in
Documentation/x86/x86_64/mm.txt")
from Linus' tree and commit:
b88679d2f2b9 ("Documentation: x86: convert x86_64/mm.txt to reST")
from the jc_docs tree.
I fixed it up (I deleted the file and added teh following patch) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
From: Stephen Rothwell
Date: Thu, 9 May 2019 10:39:31 +1000
Subject: [PATCH] Documentation: x86: update for "x86/mm: Fix the 56-bit
addresses memory map in Documentation/x86/x86_64/mm.txt"
Signed-off-by: Stephen Rothwell
---
Documentation/x86/x86_64/mm.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/x86/x86_64/mm.rst b/Documentation/x86/x86_64/mm.rst
index 52020577b8de..267fc4808945 100644
--- a/Documentation/x86/x86_64/mm.rst
+++ b/Documentation/x86/x86_64/mm.rst
@@ -78,7 +78,7 @@ Complete virtual memory map with 5-level page tables
.. note::
- With 56-bit addresses, user-space memory gets expanded by a factor of 512x,
- from 0.125 PB to 64 PB. All kernel mappings shift down to the -64 PT
starting
+ from 0.125 PB to 64 PB. All kernel mappings shift down to the -64 PB
starting
offset and many of the regions expand to support the much larger physical
memory supported.
@@ -91,7 +91,7 @@ Complete virtual memory map with 5-level page tables
|0 | 00ff | 64 PB | user-space
virtual memory, different per mm
__||__|_|___
|| | |
- 8000 | +64PB | 7fff | ~16K PB | ... huge,
still almost 64 bits wide hole of non-canonical
+ 0100 | +64PB | feff | ~16K PB | ... huge,
still almost 64 bits wide hole of non-canonical
|| | | virtual
memory addresses up to the -64 PB
|| | | starting
offset of kernel mappings.
__||__|_|___
@@ -107,7 +107,7 @@ Complete virtual memory map with 5-level page tables
ffd2 | -11.5 PB | ffd3 | 0.5 PB | ... unused hole
ffd4 | -11PB | ffd5 | 0.5 PB | virtual memory
map (vmemmap_base)
ffd6 | -10.5 PB | ffde | 2.25 PB | ... unused hole
- ffdf | -8.25 PB | fdff | ~8 PB | KASAN shadow
memory
+ ffdf | -8.25 PB | fbff | ~8 PB | KASAN shadow
memory
__||__|_|
|
| Identical
layout to the 47-bit one from here on:
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpYbksxtSPXq.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] sh: vsyscall: drop unnecessary cc-ldoption
On Thu, May 9, 2019 at 5:13 AM Nick Desaulniers wrote: > > bumping for review, as the merge window is now open. sh is not very active these days. I applied this to my kbuild tree. I will send PR for this in the current MW. Thanks. > On Tue, Apr 30, 2019 at 1:26 PM Nick Desaulniers > wrote: > > > > On Wed, Apr 24, 2019 at 11:02 AM Nick Desaulniers > > wrote: > > > > > > Towards the goal of removing cc-ldoption, it seems that --hash-style= > > > was added to binutils 2.17.50.0.2 in 2006. The minimal required version > > > of binutils for the kernel according to > > > Documentation/process/changes.rst is 2.20. > > > > > > Link: https://gcc.gnu.org/ml/gcc/2007-01/msg01141.html > > > Cc: clang-built-li...@googlegroups.com > > > Suggested-by: Masahiro Yamada > > > Signed-off-by: Nick Desaulniers > > > --- > > > Changes V1 -> V2: > > > * update commit subject and message as per Masahiro/Geert. > > > > > > To Geert's question about minimum binutils versions; no change needed to > > > binutils. > > > > > > > > > arch/sh/kernel/vsyscall/Makefile | 3 +-- > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > diff --git a/arch/sh/kernel/vsyscall/Makefile > > > b/arch/sh/kernel/vsyscall/Makefile > > > index 5db6579bc44c..6e8664448048 100644 > > > --- a/arch/sh/kernel/vsyscall/Makefile > > > +++ b/arch/sh/kernel/vsyscall/Makefile > > > @@ -15,8 +15,7 @@ quiet_cmd_syscall = SYSCALL $@ > > > > > > export CPPFLAGS_vsyscall.lds += -P -C -Ush > > > > > > -vsyscall-flags = -shared -s -Wl,-soname=linux-gate.so.1 \ > > > - $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) > > > +vsyscall-flags = -shared -s -Wl,-soname=linux-gate.so.1 > > > -Wl,--hash-style=sysv > > > > > > SYSCFLAGS_vsyscall-trapa.so= $(vsyscall-flags) > > > > > > -- > > > 2.21.0.593.g511ec345e18-goog > > > > > > > bumping for review > > -- > > Thanks, > > ~Nick Desaulniers > > > > -- > Thanks, > ~Nick Desaulniers -- Best Regards Masahiro Yamada
Re: [RFC PATCH v2 11/17] sched: Basic tracking of matching tasks
On 5/8/19 5:01 PM, Aubrey Li wrote: On Thu, May 9, 2019 at 2:41 AM Subhra Mazumdar wrote: On 5/8/19 11:19 AM, Subhra Mazumdar wrote: On 5/8/19 8:49 AM, Aubrey Li wrote: Pawan ran an experiment setting up 2 VMs, with one VM doing a parallel kernel build and one VM doing sysbench, limiting both VMs to run on 16 cpu threads (8 physical cores), with 8 vcpu for each VM. Making the fix did improve kernel build time by 7%. I'm gonna agree with the patch below, but just wonder if the testing result is consistent, as I didn't see any improvement in my testing environment. IIUC, from the code behavior, especially for 2 VMs case(only 2 different cookies), the per-rq rb tree unlikely has nodes with different cookies, that is, all the nodes on this tree should have the same cookie, so: - if the parameter cookie is equal to the rb tree cookie, we meet a match and go the third branch - else, no matter we go left or right, we can't find a match, and we'll return idle thread finally. Please correct me if I was wrong. Thanks, -Aubrey This is searching in the per core rb tree (rq->core_tree) which can have 2 different cookies. But having said that, even I didn't see any improvement with the patch for my DB test case. But logically it is correct. Ah, my bad. It is per rq. But still can have 2 different cookies. Not sure why you think it is unlikely? Yeah, I meant 2 different cookies on the system, but unlikely 2 different cookies on one same rq. If I read the source correctly, for the sched_core_balance path, when try to steal cookie from another CPU, sched_core_find() uses dst's cookie to search if there is a cookie match in src's rq, and sched_core_find() returns idle or matched task, and later put this matched task onto dst's rq (activate_task() in sched_core_find()). At this moment, the nodes on the rq's rb tree should have same cookies. Thanks, -Aubrey Yes, but sched_core_find is also called from pick_task to find a local matching task. The enqueue side logic of the scheduler is unchanged with core scheduling, so it is possible tasks with different cookies are enqueued on the same rq. So while searching for a matching task locally doing it correctly should matter.
WARNING: locking bug in nfs_get_client
Hello, syzbot found the following crash on: HEAD commit:31ccad9b Add linux-next specific files for 20190508 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1082d2aca0 kernel config: https://syzkaller.appspot.com/x/.config?x=63cd766601c6c9fc dashboard link: https://syzkaller.appspot.com/bug?extid=228a82b263b5da91883d compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=140fdce8a0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=134dce02a0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+228a82b263b5da918...@syzkaller.appspotmail.com [ cut here ] DEBUG_LOCKS_WARN_ON(depth <= 0) WARNING: CPU: 1 PID: 7948 at kernel/locking/lockdep.c:4052 __lock_release kernel/locking/lockdep.c:4052 [inline] WARNING: CPU: 1 PID: 7948 at kernel/locking/lockdep.c:4052 lock_release+0x667/0xa00 kernel/locking/lockdep.c:4321 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 7948 Comm: syz-executor561 Not tainted 5.1.0-next-20190508 #3 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+0x172/0x1f0 lib/dump_stack.c:113 panic+0x2cb/0x75a kernel/panic.c:218 __warn.cold+0x20/0x47 kernel/panic.c:575 report_bug+0x263/0x2b0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] fixup_bug arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:972 RIP: 0010:__lock_release kernel/locking/lockdep.c:4052 [inline] RIP: 0010:lock_release+0x667/0xa00 kernel/locking/lockdep.c:4321 Code: 0f 85 a0 03 00 00 8b 35 a7 02 09 08 85 f6 75 23 48 c7 c6 e0 57 6b 87 48 c7 c7 80 27 6b 87 4c 89 85 70 ff ff ff e8 37 7c eb ff <0f> 0b 4c 8b 85 70 ff ff ff 4c 89 ea 4c 89 e6 4c 89 c7 e8 52 63 ff RSP: 0018:888095867730 EFLAGS: 00010082 RAX: RBX: 111012b0ceec RCX: RDX: RSI: 815b20c6 RDI: ed1012b0ced8 RBP: 8880958677e8 R08: 88809a5b83c0 R09: fbfff1133071 R10: fbfff1133070 R11: 88998383 R12: 888219eeb700 R13: 821668ab R14: 8a45bd40 R15: 8880958677c0 __raw_spin_unlock include/linux/spinlock_api_smp.h:150 [inline] _raw_spin_unlock+0x1b/0x50 kernel/locking/spinlock.c:183 spin_unlock include/linux/spinlock.h:378 [inline] nfs_get_client+0xc1b/0x1300 fs/nfs/client.c:412 nfs_init_server+0x26f/0xea0 fs/nfs/client.c:675 nfs_create_server+0x12b/0x6d0 fs/nfs/client.c:962 nfs_try_mount+0x15a/0x910 fs/nfs/super.c:1882 nfs_fs_mount+0x184a/0x2690 fs/nfs/super.c:2718 legacy_get_tree+0x10a/0x220 fs/fs_context.c:665 vfs_get_tree+0x93/0x3a0 fs/super.c:1476 do_new_mount fs/namespace.c:2790 [inline] do_mount+0x138c/0x1c00 fs/namespace.c:3110 ksys_mount+0xdb/0x150 fs/namespace.c:3319 __do_sys_mount fs/namespace.c: [inline] __se_sys_mount fs/namespace.c:3330 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3330 do_syscall_64+0x103/0x670 arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4467d9 Code: e8 5c b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 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 0b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f54c53e0db8 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: 006dbc38 RCX: 004467d9 RDX: 20fb5ffc RSI: 20343ff8 RDI: RBP: 006dbc30 R08: 2000a000 R09: R10: R11: 0246 R12: 006dbc3c R13: 7ffe22037e2f R14: 7f54c53e19c0 R15: 20c49ba5e353f7cf Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH RFC] selinux: provide __le variables explicitly
On Wed, May 08, 2019 at 05:47:32PM -0400, Paul Moore wrote: > On Wed, May 8, 2019 at 2:27 AM Nicholas Mc Guire wrote: > > While the endiannes is being handled properly sparse was unable to verify > > this due to type inconsistency. So introduce an additional __le32 > > respectively _le64 variable to be passed to le32/64_to_cpu() to allow > > sparse to verify proper typing. Note that this patch does not change > > the generated binary on little-endian systems - on 32bit powerpc it > > does change the binary. > > > > Signed-off-by: Nicholas Mc Guire > > --- > > > > Problem located by an experimental coccinelle script to locate > > patters that make sparse unhappy (false positives): > > > > sparse complaints on different architectures fixed by this patch are: > > > > ppc6xx_defconfig > > CHECK security/selinux/ss/ebitmap.c > > security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 > > security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 > > security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 > > security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 > > security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 > > security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > > > Little-endian systems: > > > > loongson3_defconfig > > security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > > > x86_64_defconfig > > security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 > > security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 > > > > Patch was compile-tested with: x86_64_defconfig,loongson3_defconfig (both > > little-endian) and ppc603_defconfig (big-endian). > > > > On little-endian systems the patch has no impact on the generated binary > > (which is expected) but on the 32bit powerpc it does change the binary > > which is not expected but since I'm not able to generate the .lst files > > in security/selinux/ss/ due to the lack of a Makefile it is not clear > > if this is an unexpected side-effect or due only to the introduction of > > the additional variables. From my understanding the patch does not change > > the program logic so if the code was correct on big-endian systems before > > it should still be correct now. > > This is a bit worrisome, but I tend to agree that this patch *should* > be correct. I'm thinking you're probably right in that the resulting > binary difference could be due to the extra variable. Have you tried > any other big-endian arches? > just tried ppc64_defconfig + AUDIT=y, SECURITY=y, SECURITY_NETWORK=y, SECURITY_SELINUX=y sparse will complain in the original version about: CHECK security/selinux/ss/ebitmap.c security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 security/selinux/ss/ebitmap.c:389:28: warning: cast to restricted __le32 security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 security/selinux/ss/ebitmap.c:431:23: warning: cast to restricted __le64 which is the same as 32bit ppc - after the patch is applied that is resolved and and the generated ebitmap.o files are binary identical. I just had chosen ppc6xx_defconfig as my big-endian test-target as SELINUX was on
Re: fix SG list handling in the sparc32 iommu driver
From: Christoph Hellwig Date: Tue, 16 Apr 2019 20:23:38 +0200 > this series fixes some long standing bugs in the sparc32 iommu driver, > mostly the lack of handling of large sglist offsets in the map_sg > method, but also a few other smaller bits. These now show up all the > time do some block layer changes in linux-next. Series applied, thanks.
Re: [RFC PATCH v2 11/17] sched: Basic tracking of matching tasks
On Thu, May 9, 2019 at 2:41 AM Subhra Mazumdar wrote: > > > On 5/8/19 11:19 AM, Subhra Mazumdar wrote: > > > > On 5/8/19 8:49 AM, Aubrey Li wrote: > >>> Pawan ran an experiment setting up 2 VMs, with one VM doing a > >>> parallel kernel build and one VM doing sysbench, > >>> limiting both VMs to run on 16 cpu threads (8 physical cores), with > >>> 8 vcpu for each VM. > >>> Making the fix did improve kernel build time by 7%. > >> I'm gonna agree with the patch below, but just wonder if the testing > >> result is consistent, > >> as I didn't see any improvement in my testing environment. > >> > >> IIUC, from the code behavior, especially for 2 VMs case(only 2 > >> different cookies), the > >> per-rq rb tree unlikely has nodes with different cookies, that is, all > >> the nodes on this > >> tree should have the same cookie, so: > >> - if the parameter cookie is equal to the rb tree cookie, we meet a > >> match and go the > >> third branch > >> - else, no matter we go left or right, we can't find a match, and > >> we'll return idle thread > >> finally. > >> > >> Please correct me if I was wrong. > >> > >> Thanks, > >> -Aubrey > > This is searching in the per core rb tree (rq->core_tree) which can have > > 2 different cookies. But having said that, even I didn't see any > > improvement with the patch for my DB test case. But logically it is > > correct. > > > Ah, my bad. It is per rq. But still can have 2 different cookies. Not sure > why you think it is unlikely? Yeah, I meant 2 different cookies on the system, but unlikely 2 different cookies on one same rq. If I read the source correctly, for the sched_core_balance path, when try to steal cookie from another CPU, sched_core_find() uses dst's cookie to search if there is a cookie match in src's rq, and sched_core_find() returns idle or matched task, and later put this matched task onto dst's rq (activate_task() in sched_core_find()). At this moment, the nodes on the rq's rb tree should have same cookies. Thanks, -Aubrey
Re: [PATCH] sparc: vdso: add FORCE to the build rule of %.so
From: Masahiro Yamada Date: Wed, 3 Apr 2019 17:32:24 +0900 > $(call if_changed,...) must have FORCE as a prerequisite. > > Signed-off-by: Masahiro Yamada Applied.
Re: [PATCH] arch:sparc:kernel/uprobes.c : Remove duplicate header
From: jagdsh.li...@gmail.com Date: Thu, 28 Mar 2019 02:58:45 +0530 > From: Jagadeesh Pagadala > > Remove duplicate header which is included twice. > > Signed-off-by: Jagadeesh Pagadala Applied.
[GIT] IDE
Finally deprecate the legacy IDE layer. Frankly this is long overdue. Please pull, thanks a lot! The following changes since commit ef75bd71c5d31dc17ae41ff8bec92630a3037d69: Merge tag 'gfs2-for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2 (2019-05-08 13:16:07 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide for you to fetch changes up to 7ad19a99ad431b5cae005c30b09096517058e84e: ide: officially deprecated the legacy IDE driver (2019-05-08 16:47:23 -0700) Christoph Hellwig (1): ide: officially deprecated the legacy IDE driver drivers/ide/ide-probe.c | 3 +++ 1 file changed, 3 insertions(+)
Re: [GIT PULL] MIPS changes for 5.2
The pull request you sent on Wed, 8 May 2019 21:04:46 +: > git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git tags/mips_5.2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/92fab77b6b309dc219b02da4a69ad5dc76f7ec74 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCHv3 00/12] perf tools: Display eBPF code in intel_pt trace
>> - patches are rebased on top of Arnaldo's perf/core with perf/urgent >merged in >> >> It's also available in here: >> git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git >> perf/fixes >> >> thanks, >> jirka >> > >For the series: > >Acked-by: Song Liu Monday I'll test and apply, thanks! - Arnaldo
Re: [PATCH] platform/x86: pmc_atom: Add Lex 3I380D industrial PC to critclk_systems DMI table
On Wed, May 08, 2019 at 03:55:22PM -0700, Darren Hart wrote: > On Wed, May 08, 2019 at 11:20:52AM +0200, Hans de Goede wrote: > > Hi, > > > > On 08-05-19 10:42, Andy Shevchenko wrote: > > > On Wed, May 8, 2019 at 10:48 AM Hans de Goede wrote: > > > > On 07-05-19 22:17, Stephen Boyd wrote: > > > > > Quoting Hans de Goede (2019-05-06 08:05:42) > > > > > > > > I guess this is urgent? > > > > > > > > Somewhat, getting this into e.g. rc2 would be fine too, waiting till 5.3 > > > > would be bad. > > > > > > So, I can do it as a fixes for rc2, just ping me after merge window. > > > > Ok, will do. > > Andy, what is the issue here? If the dependency is in v5.1 we can do a "merge > --ff-only v5.1" in our for-next branch in order to pull it in, that would be > the > same as an immutable branch basically. > A simpler solution for this case would be to issue two PRs to Linus from two different branches. Other subsystems send topic branches, so this isn't out of the ordinary. I have merged the two patches in question from Hans and Steffen to for-next-2. We could send two PRs back to back, with a note to Linus why this is a bit different than usual, and then come back together in our for-next and fixes branches once both are merged and continue as usual. Any concerns with this approach? -- Darren Hart VMware Open Source Technology Center
Re: [PATCH v2] memcg, fsnotify: no oom-kill for remote memcg charging
On Sat, May 04, 2019 at 07:52:42AM -0700, Shakeel Butt wrote:
> The commit d46eb14b735b ("fs: fsnotify: account fsnotify metadata to
> kmemcg") added remote memcg charging for fanotify and inotify event
> objects. The aim was to charge the memory to the listener who is
> interested in the events but without triggering the OOM killer.
> Otherwise there would be security concerns for the listener. At the
> time, oom-kill trigger was not in the charging path. A parallel work
> added the oom-kill back to charging path i.e. commit 29ef680ae7c2
> ("memcg, oom: move out_of_memory back to the charge path"). So to not
> trigger oom-killer in the remote memcg, explicitly add
> __GFP_RETRY_MAYFAIL to the fanotigy and inotify event allocations.
>
> Signed-off-by: Shakeel Butt
> ---
> Changelog since v1:
> - Fixed usage of __GFP_RETRY_MAYFAIL flag.
>
> fs/notify/fanotify/fanotify.c| 5 -
> fs/notify/inotify/inotify_fsnotify.c | 7 +--
> 2 files changed, 9 insertions(+), 3 deletions(-)
Hi Shakeel,
the patch looks good to me!
Reviewed-by: Roman Gushchin
Thanks!
Re: [PATCH v2 00/11] dts: Update DT bindings for CoreSight replicator and funnel
On Wed, May 08, 2019 at 03:29:12PM +0100, Suzuki K Poulose wrote: > > On 08/05/2019 03:18, Leo Yan wrote: > > Since the DT bindings consolidatoins for CoreSight replicator and funnel > > is ready for kernel v5.2 merge window [1], this patch set is to update > > the related CoreSight DT bindings for platforms; IIUC, this patch set > > will be safe for merging into kernel v5.2 because the dependency > > patches in [1] will be landed into mainline kernel v5.2 cycle. > > > > In this patch set, it tries to update below two compatible strings to > > the latest strings: > > > >s/"arm,coresight-replicator"/"arm,coresight-static-replicator" > >s/"arm,coresight-funnel"/"arm,coresight-dynamic-funnel" > > > > Please note, some platforms have two continuous patches, one is for > > updating static replicator compatible string and another is for dynamic > > funnel change; and other platforms have only one patch since it only > > needs to change for dynamic funnel. > > This is now misleading ;-), but that doesn't matter. Oops ... > For the entire series : > > Acked-by: Suzuki K Poulose Thanks for reviewing!
Re: linux-next: Tree for May 8 (drivers/platform/x86/intel_pmc_core_plat_drv.c)
From: Andy Shevchenko Date: Wed, May 8, 2019 at 2:22 PM To: Randy Dunlap Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, Rajat Jain, Platform Driver, Rajneesh Bhardwaj, Vishwanath Somayaji > On Wed, May 8, 2019 at 11:45 PM Randy Dunlap wrote: > > > > On 5/8/19 12:34 AM, Stephen Rothwell wrote: > > > Hi all, > > > > > > Changes since 20190507: > > > > > > The ubifs tree gained a conflict against Linus' tree. > > > > > > > on i386 or x86_64: > > Thank you for report. Can you provide what is the config option for > this module? I suppose it's built-in. > Rajat, I will drop this from the repo, because I don't see it would > have a chance to be tested in time. OK, NP. Just to be sure I understand, 1) Please let me know if I should send in a fix (it would be #include/linux/module.h and also add MODULE_LICENSE() I believe)? 2) Would this be lined up for next version though? Thanks, Rajat > > > > > > > > CC drivers/platform/x86/intel_pmc_core_plat_drv.o > > ../drivers/platform/x86/intel_pmc_core_plat_drv.c:40:1: warning: data > > definition has no type or storage class [enabled by default] > > MODULE_DEVICE_TABLE(x86cpu, intel_pmc_core_platform_ids); > > ^ > > ../drivers/platform/x86/intel_pmc_core_plat_drv.c:40:1: error: type > > defaults to ‘int’ in declaration of ‘MODULE_DEVICE_TABLE’ > > [-Werror=implicit-int] > > ../drivers/platform/x86/intel_pmc_core_plat_drv.c:40:1: warning: parameter > > names (without types) in function declaration [enabled by default] > > ../drivers/platform/x86/intel_pmc_core_plat_drv.c:59:1: warning: data > > definition has no type or storage class [enabled by default] > > module_init(pmc_core_platform_init); > > ^ > > ../drivers/platform/x86/intel_pmc_core_plat_drv.c:59:1: error: type > > defaults to ‘int’ in declaration of ‘module_init’ [-Werror=implicit-int] > > ../drivers/platform/x86/intel_pmc_core_plat_drv.c:59:1: warning: parameter > > names (without types) in function declaration [enabled by default] > > ../drivers/platform/x86/intel_pmc_core_plat_drv.c:60:1: warning: data > > definition has no type or storage class [enabled by default] > > module_exit(pmc_core_platform_exit); > > ^ > > ../drivers/platform/x86/intel_pmc_core_plat_drv.c:60:1: error: type > > defaults to ‘int’ in declaration of ‘module_exit’ [-Werror=implicit-int] > > ../drivers/platform/x86/intel_pmc_core_plat_drv.c:60:1: warning: parameter > > names (without types) in function declaration [enabled by default] > > ../drivers/platform/x86/intel_pmc_core_plat_drv.c:42:19: warning: > > ‘pmc_core_platform_init’ defined but not used [-Wunused-function] > > static int __init pmc_core_platform_init(void) > >^ > > > > and > > WARNING: modpost: missing MODULE_LICENSE() in > > drivers/platform/x86/intel_pmc_core_plat_drv.o > > > > -- > > ~Randy > > > > -- > With Best Regards, > Andy Shevchenko
Re: [PATCH] platform/x86: acer-wmi: Mark expected switch fall-throughs
On Wed, May 08, 2019 at 11:49:34AM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/platform/x86/acer-wmi.c: In function ‘set_u32’:
> drivers/platform/x86/acer-wmi.c:1378:33: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
> if (cap == ACER_CAP_WIRELESS ||
> ^
> drivers/platform/x86/acer-wmi.c:1386:3: note: here
>case ACER_WMID:
>^~~~
> drivers/platform/x86/acer-wmi.c:1393:12: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
> else if (wmi_has_guid(WMID_GUID2))
> ^
> drivers/platform/x86/acer-wmi.c:1395:3: note: here
>default:
>^~~
> drivers/platform/x86/acer-wmi.c: In function ‘get_u32’:
> drivers/platform/x86/acer-wmi.c:1340:6: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
>if (cap == ACER_CAP_MAILLED) {
> ^
> drivers/platform/x86/acer-wmi.c:1344:2: note: here
> case ACER_WMID:
> ^~~~
> drivers/platform/x86/acer-wmi.c: In function ‘WMID_get_u32’:
> drivers/platform/x86/acer-wmi.c:1013:6: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
>if (quirks->mailled == 1) {
> ^
> drivers/platform/x86/acer-wmi.c:1018:2: note: here
> default:
> ^~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/platform/x86/acer-wmi.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> index fcfeadd1301f..bd87f9037f95 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -1015,6 +1015,7 @@ static acpi_status WMID_get_u32(u32 *value, u32 cap)
> *value = tmp & 0x1;
> return 0;
> }
> + /* fall through */
> default:
> return AE_ERROR;
> }
> @@ -1341,6 +1342,7 @@ static acpi_status get_u32(u32 *value, u32 cap)
> status = AMW0_get_u32(value, cap);
> break;
> }
> + /* fall through */
This doesn't strike me as obviously the right thing to do here. If the interface
type is AMW0_V2, why is it the right thing to do to use WMID_get_u32 if the cap
isn't ACER_CAP_MAILLED?
> case ACER_WMID:
> status = WMID_get_u32(value, cap);
> break;
> @@ -1383,6 +1385,7 @@ static acpi_status set_u32(u32 value, u32 cap)
>
> return AMW0_set_u32(value, cap);
> }
> + /* fall through */
Similarly here.
Are we documenting intended behavior, or covering up a bug.
> case ACER_WMID:
> return WMID_set_u32(value, cap);
--
Darren Hart
VMware Open Source Technology Center
Re: [PATCH 0/3] arm64: meson-g12a: Add Infrared Decoder support
Neil Armstrong writes: > Add Infrared Decoder support for the Amlogic G12A and enable it on the > X96 Max and U200 Reference Design boards. Queued for v5.3 (branch: v5.3/dt64) Kevin
Re: [PATCH 1/3] arm64: dts: meson-g12a: Add IR nodes
Neil Armstrong writes:
> Amlogic G12A SoCs uses the exact same IR decoder as previous
> families, add the IR node and the pintctrl setting.
>
> Signed-off-by: Neil Armstrong
> ---
> arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
> index 734c5ee60efa..9cb76d325bb7 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
> @@ -559,6 +559,13 @@
> mux {
> groups = "pwm_ao_d_e";
> function = "pwm_ao_d";
> + };
> + };
nit: you had applied this based on top of the PWM series, but didn't
mention that in the cover letter.
Kevin
> + remote_input_ao_pins: remote-input-ao {
> + mux {
> + groups =
> "remote_ao_input";
> + function =
> "remote_ao_input";
> bias-disable;
> };
> };
> @@ -623,6 +630,13 @@
> status = "disabled";
> };
>
> + ir: ir@8000 {
> + compatible = "amlogic,meson-gxbb-ir";
> + reg = <0x0 0x8000 0x0 0x20>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> saradc: adc@9000 {
> compatible = "amlogic,meson-g12a-saradc",
>"amlogic,meson-saradc";
> --
> 2.21.0
Re: [PATCH] platform/x86: pmc_atom: Add Lex 3I380D industrial PC to critclk_systems DMI table
On Wed, May 08, 2019 at 11:20:52AM +0200, Hans de Goede wrote: > Hi, > > On 08-05-19 10:42, Andy Shevchenko wrote: > > On Wed, May 8, 2019 at 10:48 AM Hans de Goede wrote: > > > On 07-05-19 22:17, Stephen Boyd wrote: > > > > Quoting Hans de Goede (2019-05-06 08:05:42) > > > > > > I guess this is urgent? > > > > > > Somewhat, getting this into e.g. rc2 would be fine too, waiting till 5.3 > > > would be bad. > > > > So, I can do it as a fixes for rc2, just ping me after merge window. > > Ok, will do. Andy, what is the issue here? If the dependency is in v5.1 we can do a "merge --ff-only v5.1" in our for-next branch in order to pull it in, that would be the same as an immutable branch basically. -- Darren Hart VMware Open Source Technology Center
Re: [PATCH v9 00/24] ILP32 for ARM64
Hi all, On Wed, May 16, 2018 at 11:18:45AM +0300, Yury Norov wrote: > This series enables AARCH64 with ILP32 mode. > > As supporting work, it introduces ARCH_32BIT_OFF_T configuration > option that is enabled for existing 32-bit architectures but disabled > for new arches (so 64-bit off_t userspace type is used by new userspace). > Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64. > > Based on kernel v4.16. Tested with LTP, glibc testsuite, trinity, lmbench, > CPUSpec. > > This series on github: > https://github.com/norov/linux/tree/ilp32-4.16 > Linaro toolchain: > http://snapshots.linaro.org/components/toolchain/binaries/7.3-2018.04-rc1/aarch64-linux-gnu_ilp32/ > Debian repo: > http://people.linaro.org/~wookey/ilp32/ > OpenSUSE repo: > https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32 This is the 5.1-based version. Changes comparing to 5.0: - drop arch patches that has been taken upstream: 80d7da1cac62 asm-generic: Drop getrlimit and setrlimit syscalls from default list 942fa985e9f1 32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option 0d0216c03a7a compat ABI: use non-compat openat and open_by_handle_at variants - in include/linux/thread_bits.h define current_thread_info() prior to inclusion of asm/thread_info.h, to avoid circullar dependencies (thread: move thread bits accessors to separated file); - enable old IPC interfaces for ilp32, according to mainline changes (arm64: ilp32: introduce syscall table for ILP32). Thanks, Yury
Re: [PATCH] EDAC, sb_edac: remove redundant update of tad_base
On Wed, May 08, 2019 at 11:42:01PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable tad_base is being set to a value that is never read
> and is being over-written on the next iteration of a for-loop.
> This assignment is therefore redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> drivers/edac/sb_edac.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index 9353c3fc7c05..6aa4b1b73a15 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -1513,7 +1513,6 @@ static int knl_get_dimm_capacity(struct sbridge_pvt
> *pvt, u64 *mc_sizes)
> sad_actual_size[mc] += tad_size;
> }
> }
> - tad_base = tad_limit+1;
> }
> }
>
Looks good to me.
Acked-by: Tony Luck
[PATCH v4 2/3] arm64: dts: qcom: qcs404: Add PCIe related nodes
The QCS404 has a PCIe2 PHY and a Qualcomm PCIe controller, define these
to for the platform.
Reviewed-by: Niklas Cassel
Signed-off-by: Bjorn Andersson
---
Changes since v3:
- Split single patch, no functional change
arch/arm64/boot/dts/qcom/qcs404.dtsi | 65
1 file changed, 65 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index 65a2cbeb28be..f97e9c96b7f7 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -412,6 +412,21 @@
#interrupt-cells = <4>;
};
+ pcie_phy: phy@7786000 {
+ compatible = "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy";
+ reg = <0x07786000 0xb8>;
+
+ clocks = < GCC_PCIE_0_PIPE_CLK>;
+ resets = < GCC_PCIEPHY_0_PHY_BCR>,
+< GCC_PCIE_0_PIPE_ARES>;
+ reset-names = "phy", "pipe";
+
+ clock-output-names = "pcie_0_pipe_clk";
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
sdcc1: sdcc@7804000 {
compatible = "qcom,sdhci-msm-v5";
reg = <0x07804000 0x1000>, <0x7805000 0x1000>;
@@ -797,6 +812,56 @@
status = "disabled";
};
};
+
+ pcie: pci@1000 {
+ compatible = "qcom,pcie-qcs404", "snps,dw-pcie";
+ reg = <0x1000 0xf1d>,
+ <0x1f20 0xa8>,
+ <0x0778 0x2000>,
+ <0x10001000 0x2000>;
+ reg-names = "dbi", "elbi", "parf", "config";
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ bus-range = <0x00 0xff>;
+ num-lanes = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges = <0x8100 0 0 0x10003000 0
0x0001>, /* I/O */
+<0x8200 0 0x10013000 0x10013000 0
0x007ed000>; /* memory */
+
+ interrupts = ;
+ interrupt-names = "msi";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 GIC_SPI 68
IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 GIC_SPI 224
IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 GIC_SPI 267
IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 GIC_SPI 268
IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+ clocks = < GCC_PCIE_0_CFG_AHB_CLK>,
+< GCC_PCIE_0_AUX_CLK>,
+< GCC_PCIE_0_MSTR_AXI_CLK>,
+< GCC_PCIE_0_SLV_AXI_CLK>;
+ clock-names = "iface", "aux", "master_bus", "slave_bus";
+
+ resets = < GCC_PCIE_0_AXI_MASTER_ARES>,
+< GCC_PCIE_0_AXI_SLAVE_ARES>,
+< GCC_PCIE_0_AXI_MASTER_STICKY_ARES>,
+< GCC_PCIE_0_CORE_STICKY_ARES>,
+< GCC_PCIE_0_BCR>,
+< GCC_PCIE_0_AHB_ARES>;
+ reset-names = "axi_m",
+ "axi_s",
+ "axi_m_sticky",
+ "pipe_sticky",
+ "pwr",
+ "ahb";
+
+ phys = <_phy>;
+ phy-names = "pciephy";
+
+ status = "disabled";
+ };
};
timer {
--
2.18.0
[PATCH] EDAC, sb_edac: remove redundant update of tad_base
From: Colin Ian King
The variable tad_base is being set to a value that is never read
and is being over-written on the next iteration of a for-loop.
This assignment is therefore redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/edac/sb_edac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 9353c3fc7c05..6aa4b1b73a15 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1513,7 +1513,6 @@ static int knl_get_dimm_capacity(struct sbridge_pvt *pvt,
u64 *mc_sizes)
sad_actual_size[mc] += tad_size;
}
}
- tad_base = tad_limit+1;
}
}
--
2.20.1
[PATCH v4 3/3] arm64: dts: qcom: qcs404-evb: Enable PCIe
Enable the PCIe PHY and controller found on the QCS404 EVB.
Signed-off-by: Bjorn Andersson
---
Changes since v3:
- Split single patch, no functional change
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 26
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index 2c3127167e3c..d1108a6abd0a 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2018, Linaro Limited
+#include
#include "qcs404.dtsi"
#include "pms405.dtsi"
@@ -68,6 +69,22 @@
};
};
+ {
+ status = "ok";
+
+ perst-gpio = < 43 GPIO_ACTIVE_LOW>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_state>;
+};
+
+_phy {
+ status = "ok";
+
+ vdda-vp-supply = <_l3_1p05>;
+ vdda-vph-supply = <_l5_1p8>;
+};
+
_adsp {
status = "ok";
};
@@ -184,6 +201,15 @@
};
{
+ perst_state: perst {
+ pins = "gpio43";
+ function = "gpio";
+
+ drive-strength = <2>;
+ bias-disable;
+ output-low;
+ };
+
sdc1_on: sdc1-on {
clk {
pins = "sdc1_clk";
--
2.18.0
[PATCH v4 0/3] arm64: dts: qcom: qcs404: Enable PCIe
This series defines the PCIe PHY and controller on QCS404 and enable them for EVB. This was 1 commit, but per Vinod's request its split up in its individual pieces. Bjorn Andersson (3): arm64: dts: qcom: qcs404: Make gcc as reset-controller arm64: dts: qcom: qcs404: Add PCIe related nodes arm64: dts: qcom: qcs404-evb: Enable PCIe arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 26 ++ arch/arm64/boot/dts/qcom/qcs404.dtsi | 66 2 files changed, 92 insertions(+) -- 2.18.0
[PATCH v4 1/3] arm64: dts: qcom: qcs404: Make gcc as reset-controller
GCC is a reset-controller, so define #reset-cells. Signed-off-by: Bjorn Andersson --- Changes since v3: - Split single patch, no functional change arch/arm64/boot/dts/qcom/qcs404.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi b/arch/arm64/boot/dts/qcom/qcs404.dtsi index ffedf9640af7..65a2cbeb28be 100644 --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi @@ -383,6 +383,7 @@ compatible = "qcom,gcc-qcs404"; reg = <0x0180 0x8>; #clock-cells = <1>; + #reset-cells = <1>; assigned-clocks = < GCC_APSS_AHB_CLK_SRC>; assigned-clock-rates = <1920>; -- 2.18.0
Re: [PATCH v2 3/3] arm64: dts: meson-g12a: Add PWM nodes
Neil Armstrong writes: > This adds the EE and AO PWM nodes and the possible pinctrl settings. > > Signed-off-by: Neil Armstrong > Reviewed-by: Martin Blumenstingl Since bindings are acked, and there's no build dependency on the driver itself, queuing this for v5.3 (branch: v5.3/dt64) Thanks, Kevin
[PATCH v4] clk: gcc-qcs404: Add PCIe resets
Enabling PCIe requires several of the PCIe related resets from GCC, so
add them all.
Reviewed-by: Niklas Cassel
Acked-by: Stephen Boyd
Acked-by: Rob Herring
Signed-off-by: Bjorn Andersson
---
Changes since v3:
- Fix rebase mistake in v2
Changes since v2:
- Rebase patch
drivers/clk/qcom/gcc-qcs404.c | 7 +++
include/dt-bindings/clock/qcom,gcc-qcs404.h | 7 +++
2 files changed, 14 insertions(+)
diff --git a/drivers/clk/qcom/gcc-qcs404.c b/drivers/clk/qcom/gcc-qcs404.c
index a54807eb3b28..29cf464dd2c8 100644
--- a/drivers/clk/qcom/gcc-qcs404.c
+++ b/drivers/clk/qcom/gcc-qcs404.c
@@ -2766,6 +2766,13 @@ static const struct qcom_reset_map gcc_qcs404_resets[] =
{
[GCC_PCIE_0_PHY_BCR] = { 0x3e004 },
[GCC_PCIE_0_LINK_DOWN_BCR] = { 0x3e038 },
[GCC_PCIEPHY_0_PHY_BCR] = { 0x3e03c },
+ [GCC_PCIE_0_AXI_MASTER_STICKY_ARES] = { 0x3e040, 6},
+ [GCC_PCIE_0_AHB_ARES] = { 0x3e040, 5 },
+ [GCC_PCIE_0_AXI_SLAVE_ARES] = { 0x3e040, 4 },
+ [GCC_PCIE_0_AXI_MASTER_ARES] = { 0x3e040, 3 },
+ [GCC_PCIE_0_CORE_STICKY_ARES] = { 0x3e040, 2 },
+ [GCC_PCIE_0_SLEEP_ARES] = { 0x3e040, 1 },
+ [GCC_PCIE_0_PIPE_ARES] = { 0x3e040, 0 },
[GCC_EMAC_BCR] = { 0x4e000 },
};
diff --git a/include/dt-bindings/clock/qcom,gcc-qcs404.h
b/include/dt-bindings/clock/qcom,gcc-qcs404.h
index 454b3f43f538..2cd62c98561f 100644
--- a/include/dt-bindings/clock/qcom,gcc-qcs404.h
+++ b/include/dt-bindings/clock/qcom,gcc-qcs404.h
@@ -166,5 +166,12 @@
#define GCC_PCIEPHY_0_PHY_BCR 12
#define GCC_EMAC_BCR 13
#define GCC_CDSP_RESTART 14
+#define GCC_PCIE_0_AXI_MASTER_STICKY_ARES 15
+#define GCC_PCIE_0_AHB_ARES16
+#define GCC_PCIE_0_AXI_SLAVE_ARES 17
+#define GCC_PCIE_0_AXI_MASTER_ARES 18
+#define GCC_PCIE_0_CORE_STICKY_ARES19
+#define GCC_PCIE_0_SLEEP_ARES 20
+#define GCC_PCIE_0_PIPE_ARES 21
#endif
--
2.18.0
[PATCH] dma: dw-axi-dmac: fix null dereference when pointer first is null
From: Colin Ian King
In the unlikely event that axi_desc_get returns a null desc in the
very first iteration of the while-loop the error exit path ends
up calling axi_desc_put on a null pointer 'first' and this causes
a null pointer dereference. Fix this by adding a null check on
pointer 'first' before calling axi_desc_put.
Addresses-Coverity: ("Explicit null dereference")
fixes: 1fe20f1b8454 ("dmaengine: Introduce DW AXI DMAC driver")
Signed-off-by: Colin Ian King
---
drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index b2ac1d2c5b86..a1ce307c502f 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -512,7 +512,8 @@ dma_chan_prep_dma_memcpy(struct dma_chan *dchan, dma_addr_t
dst_adr,
return vchan_tx_prep(>vc, >vd, flags);
err_desc_get:
- axi_desc_put(first);
+ if (first)
+ axi_desc_put(first);
return NULL;
}
--
2.20.1
Re: [PATCH 4/6] kvm: lapic: Add apicv activate/deactivate helper function
On 22/03/2019 12.57, Suthikulpanit, Suravee wrote:
> Introduce a helper function for setting lapic parameters when
> activate/deactivate apicv.
>
> Signed-off-by: Suravee Suthikulpanit
> ---
> arch/x86/kvm/lapic.c | 23 ++-
> arch/x86/kvm/lapic.h | 1 +
> 2 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 95295cf81283..9c5cd1a98928 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -2126,6 +2126,22 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64
> value)
>
> }
>
> +void kvm_apic_update_apicv(struct kvm_vcpu *vcpu)
> +{
> + struct kvm_lapic *apic = vcpu->arch.apic;
> + bool active = vcpu->arch.apicv_active;
> +
> + if (active) {
> + /* irr_pending is always true when apicv is activated. */
> + apic->irr_pending = true;
> + apic->isr_count = 1;
> + } else {
> + apic->irr_pending = !!count_vectors(apic->regs + APIC_IRR);
What about:
apic->irr_pending = apic_search_irr(apic) != -1;
instead? (more in line with the logic in apic_clear_irr())
Related to this, I wonder if we need to ensure to execute
kvm_x86_ops->sync_pir_to_irr() just before apicv_active transitions
from true to false, so that we don't miss an interrupt and irr_pending
is set correctly in this function (on Intel at least).
Hmm... there seems to be other stuff as well, that depends on
vcpu->arch.apicv_active, which is not updated on a transition. For
example: posted interrupts, CR8 intercept, and a potential asymmetry
via avic_vcpu_load()/avic_vcpu_put() because the bottom half
of just one of the two functions may be skipped...
Do these need to be handled in some way?
Regards
Jan
> + apic->isr_count = count_vectors(apic->regs + APIC_ISR);
> + }
> +}
> +EXPORT_SYMBOL(kvm_apic_update_apicv);
> +
> void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool init_event)
> {
> struct kvm_lapic *apic = vcpu->arch.apic;
> @@ -2170,8 +2186,7 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool
> init_event)
> kvm_lapic_set_reg(apic, APIC_ISR + 0x10 * i, 0);
> kvm_lapic_set_reg(apic, APIC_TMR + 0x10 * i, 0);
> }
> - apic->irr_pending = vcpu->arch.apicv_active;
> - apic->isr_count = vcpu->arch.apicv_active ? 1 : 0;
> + kvm_apic_update_apicv(vcpu);
> apic->highest_isr_cache = -1;
> update_divide_count(apic);
> atomic_set(>lapic_timer.pending, 0);
> @@ -2433,9 +2448,7 @@ int kvm_apic_set_state(struct kvm_vcpu *vcpu, struct
> kvm_lapic_state *s)
> apic_manage_nmi_watchdog(apic, kvm_lapic_get_reg(apic, APIC_LVT0));
> update_divide_count(apic);
> start_apic_timer(apic);
> - apic->irr_pending = true;
> - apic->isr_count = vcpu->arch.apicv_active ?
> - 1 : count_vectors(apic->regs + APIC_ISR);
> + kvm_apic_update_apicv(vcpu);
> apic->highest_isr_cache = -1;
> if (vcpu->arch.apicv_active) {
> kvm_x86_ops->apicv_post_state_restore(vcpu);
> diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
> index ff6ef9c3d760..b657605cfec0 100644
> --- a/arch/x86/kvm/lapic.h
> +++ b/arch/x86/kvm/lapic.h
> @@ -88,6 +88,7 @@ void kvm_apic_update_ppr(struct kvm_vcpu *vcpu);
> int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct kvm_lapic_irq *irq,
>struct dest_map *dest_map);
> int kvm_apic_local_deliver(struct kvm_lapic *apic, int lvt_type);
> +void kvm_apic_update_apicv(struct kvm_vcpu *vcpu);
>
> bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct kvm_lapic *src,
> struct kvm_lapic_irq *irq, int *r, struct dest_map *dest_map);
>
Re: linux-next: Signed-off-by missing for commit in the risc-v tree
On Wed, 08 May 2019 14:47:45 PDT (-0700), Stephen Rothwell wrote:
Hi all,
Commits
da8e7c379659 ("riscv: Support BUG() in kernel module")
564bd22ea4e5 ("riscv: Add the support for c.ebreak check in
is_valid_bugaddr()")
67363778b72c ("riscv: support trap-based WARN()")
efd48cf0b393 ("riscv: fix sbi_remote_sfence_vma{,_asid}.")
89f7840cf346 ("riscv: move switch_mm to its own file")
8c0e1593f15d ("riscv: move flush_icache_{all,mm} to cacheflush.c")
are missing a Signed-off-by from their committer.
Sorry about that, these should be fixed now.
