Re: Memory hotplug softlock issue
On 11/15/18 at 08:30am, Michal Hocko wrote:
> On Thu 15-11-18 13:10:34, Baoquan He wrote:
> > On 11/14/18 at 04:00pm, Michal Hocko wrote:
> > > On Wed 14-11-18 22:52:50, Baoquan He wrote:
> > > > On 11/14/18 at 10:01am, Michal Hocko wrote:
> > > > > I have seen an issue when the migration cannot make a forward progress
> > > > > because of a glibc page with a reference count bumping up and down.
> > > > > Most
> > > > > probable explanation is the faultaround code. I am working on this and
> > > > > will post a patch soon. In any case the migration should converge and
> > > > > if
> > > > > it doesn't do then there is a bug lurking somewhere.
> > > > >
> > > > > Failing on ENOMEM is a questionable thing. I haven't seen that
> > > > > happening
> > > > > wildly but if it is a case then I wouldn't be opposed.
> > > >
> > > > Applied your debugging patches, it helps a lot to printing message.
> > > >
> > > > Below is the dmesg log about the migrating failure. It can't pass
> > > > migrate_pages() and loop forever.
> > > >
> > > > [ +0.083841] migrating pfn 10fff7d0 failed
> > > > [ +0.05] page:ea043ffdf400 count:208 mapcount:201
> > > > mapping:888dff4bdda8 index:0x2
> > > > [ +0.012689] xfs_address_space_operations [xfs]
> > > > [ +0.30] name:"stress"
> > > > [ +0.004556] flags: 0x5fc004(uptodate)
> > > > [ +0.007339] raw: 005fc004 c90e3d80 c90e3d80
> > > > 888dff4bdda8
> > > > [ +0.009488] raw: 0002 00cb00c8
> > > > 888e7353d000
> > > > [ +0.007726] page->mem_cgroup:888e7353d000
> > > > [ +0.084538] migrating pfn 10fff7d0 failed
> > > > [ +0.06] page:ea043ffdf400 count:210 mapcount:201
> > > > mapping:888dff4bdda8 index:0x2
> > > > [ +0.012798] xfs_address_space_operations [xfs]
> > > > [ +0.34] name:"stress"
> > > > [ +0.004524] flags: 0x5fc004(uptodate)
> > > > [ +0.007068] raw: 005fc004 c90e3d80 c90e3d80
> > > > 888dff4bdda8
> > > > [ +0.009359] raw: 0002 00cb00c8
> > > > 888e7353d000
> > > > [ +0.007728] page->mem_cgroup:888e7353d000
> > >
> > > I wouldn't be surprised if this was a similar/same issue I've been
> > > chasing recently. Could you try to disable faultaround to see if that
> > > helps. It seems that it helped in my particular case but I am still
> > > waiting for the final good-to-go to post the patch as I do not own the
> > > workload which triggered that issue.
> >
> > Tried, still stuck in last block sometime. Usually after several times
> > of hotplug/unplug. If stop stress program, the last block will be
> > offlined immediately.
>
> Is the pattern still the same? I mean failing over few pages with
> reference count jumping up and down between attempts?
->count jumping up and down, mapcount stays the same value.
>
> > [root@ ~]# cat /sys/kernel/debug/fault_around_bytes
> > 4096
>
> Can you make it 0?
I executed 'echo 0 > fault_around_bytes', value less than one page size
will round up to one page.
/*
* fault_around_bytes must be rounded down to the nearest page order as it's
* what do_fault_around() expects to see.
*/
static int fault_around_bytes_set(void *data, u64 val)
{
if (val / PAGE_SIZE > PTRS_PER_PTE)
return -EINVAL;
if (val > PAGE_SIZE)
fault_around_bytes = rounddown_pow_of_two(val);
else
fault_around_bytes = PAGE_SIZE; /* rounddown_pow_of_two(0) is
undefined */
return 0;
}
Re: Memory hotplug softlock issue
On 11/15/18 at 08:30am, Michal Hocko wrote:
> On Thu 15-11-18 13:10:34, Baoquan He wrote:
> > On 11/14/18 at 04:00pm, Michal Hocko wrote:
> > > On Wed 14-11-18 22:52:50, Baoquan He wrote:
> > > > On 11/14/18 at 10:01am, Michal Hocko wrote:
> > > > > I have seen an issue when the migration cannot make a forward progress
> > > > > because of a glibc page with a reference count bumping up and down.
> > > > > Most
> > > > > probable explanation is the faultaround code. I am working on this and
> > > > > will post a patch soon. In any case the migration should converge and
> > > > > if
> > > > > it doesn't do then there is a bug lurking somewhere.
> > > > >
> > > > > Failing on ENOMEM is a questionable thing. I haven't seen that
> > > > > happening
> > > > > wildly but if it is a case then I wouldn't be opposed.
> > > >
> > > > Applied your debugging patches, it helps a lot to printing message.
> > > >
> > > > Below is the dmesg log about the migrating failure. It can't pass
> > > > migrate_pages() and loop forever.
> > > >
> > > > [ +0.083841] migrating pfn 10fff7d0 failed
> > > > [ +0.05] page:ea043ffdf400 count:208 mapcount:201
> > > > mapping:888dff4bdda8 index:0x2
> > > > [ +0.012689] xfs_address_space_operations [xfs]
> > > > [ +0.30] name:"stress"
> > > > [ +0.004556] flags: 0x5fc004(uptodate)
> > > > [ +0.007339] raw: 005fc004 c90e3d80 c90e3d80
> > > > 888dff4bdda8
> > > > [ +0.009488] raw: 0002 00cb00c8
> > > > 888e7353d000
> > > > [ +0.007726] page->mem_cgroup:888e7353d000
> > > > [ +0.084538] migrating pfn 10fff7d0 failed
> > > > [ +0.06] page:ea043ffdf400 count:210 mapcount:201
> > > > mapping:888dff4bdda8 index:0x2
> > > > [ +0.012798] xfs_address_space_operations [xfs]
> > > > [ +0.34] name:"stress"
> > > > [ +0.004524] flags: 0x5fc004(uptodate)
> > > > [ +0.007068] raw: 005fc004 c90e3d80 c90e3d80
> > > > 888dff4bdda8
> > > > [ +0.009359] raw: 0002 00cb00c8
> > > > 888e7353d000
> > > > [ +0.007728] page->mem_cgroup:888e7353d000
> > >
> > > I wouldn't be surprised if this was a similar/same issue I've been
> > > chasing recently. Could you try to disable faultaround to see if that
> > > helps. It seems that it helped in my particular case but I am still
> > > waiting for the final good-to-go to post the patch as I do not own the
> > > workload which triggered that issue.
> >
> > Tried, still stuck in last block sometime. Usually after several times
> > of hotplug/unplug. If stop stress program, the last block will be
> > offlined immediately.
>
> Is the pattern still the same? I mean failing over few pages with
> reference count jumping up and down between attempts?
->count jumping up and down, mapcount stays the same value.
>
> > [root@ ~]# cat /sys/kernel/debug/fault_around_bytes
> > 4096
>
> Can you make it 0?
I executed 'echo 0 > fault_around_bytes', value less than one page size
will round up to one page.
/*
* fault_around_bytes must be rounded down to the nearest page order as it's
* what do_fault_around() expects to see.
*/
static int fault_around_bytes_set(void *data, u64 val)
{
if (val / PAGE_SIZE > PTRS_PER_PTE)
return -EINVAL;
if (val > PAGE_SIZE)
fault_around_bytes = rounddown_pow_of_two(val);
else
fault_around_bytes = PAGE_SIZE; /* rounddown_pow_of_two(0) is
undefined */
return 0;
}
Re: [GIT PULL] PCI fixes for v4.20
On Thu, Nov 15, 2018 at 01:12:53AM -0600, Bjorn Helgaas wrote: > > and I kinda see the point of maybe not having your ssh username in the > > URL. Not that it is a big deal for us, k.org users though. > > Sorry, I don't understand the problem. I have this in my .gitconfig: > > [url "ssh://g...@gitolite.kernel.org"] > insteadOf = https://git.kernel.org > insteadOf = http://git.kernel.org > insteadOf = git://git.kernel.org > > because I thought that was the recommended way (see the end of > https://korg.wiki.kernel.org/userdoc/gitolite). But that also makes my > request-pull: > > $ git request-pull origin/master > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git > pci-v4.20-fixes-1 > > generate the ssh URL above. If I remove the insteadOf stuff from > .gitconfig, request-pull produces this instead: > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git > tags/pci-v4.20-fixes-1 > > I'm happy to do either; just tell me which :) You didn't really do anything wrong. In *general* I prefer to see public URLs if they are sent to public lists, so if you're cc'ing something to LKML, I would generally expect the pull request to have a public URL like https://git.kernel.org/ instead of a private ssh:// URL that is only accessible to people with a kernel.org account. That's basically all there is to it. It doesn't *really* matter, since Linus is the one who will be merging the actual pull request, and he certainly has access to internal ssh:// URLs. However, in case someone else was interested in reviewing the pull request, it would be more friendly to have a public URL for them. Best, -K
Re: [GIT PULL] PCI fixes for v4.20
On Thu, Nov 15, 2018 at 01:12:53AM -0600, Bjorn Helgaas wrote: > > and I kinda see the point of maybe not having your ssh username in the > > URL. Not that it is a big deal for us, k.org users though. > > Sorry, I don't understand the problem. I have this in my .gitconfig: > > [url "ssh://g...@gitolite.kernel.org"] > insteadOf = https://git.kernel.org > insteadOf = http://git.kernel.org > insteadOf = git://git.kernel.org > > because I thought that was the recommended way (see the end of > https://korg.wiki.kernel.org/userdoc/gitolite). But that also makes my > request-pull: > > $ git request-pull origin/master > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git > pci-v4.20-fixes-1 > > generate the ssh URL above. If I remove the insteadOf stuff from > .gitconfig, request-pull produces this instead: > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git > tags/pci-v4.20-fixes-1 > > I'm happy to do either; just tell me which :) You didn't really do anything wrong. In *general* I prefer to see public URLs if they are sent to public lists, so if you're cc'ing something to LKML, I would generally expect the pull request to have a public URL like https://git.kernel.org/ instead of a private ssh:// URL that is only accessible to people with a kernel.org account. That's basically all there is to it. It doesn't *really* matter, since Linus is the one who will be merging the actual pull request, and he certainly has access to internal ssh:// URLs. However, in case someone else was interested in reviewing the pull request, it would be more friendly to have a public URL for them. Best, -K
Re: [RFC/RFT 2/2] RISC-V: kprobes/kretprobe support
On Wed, 14 Nov 2018 22:10:52 +0100
Patrick Staehlin wrote:
> On 14.11.18 16:49, Masami Hiramatsu wrote:
> > On Wed, 14 Nov 2018 00:37:30 -0800
> > Masami Hiramatsu wrote:
> >
> >>> +
> >>> +static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
> >>> +{
> >>> + if (is_compressed_insn(opcode))
> >>> + *(u16 *)addr = cpu_to_le16(opcode);
> >>> + else
> >>> + *addr = cpu_to_le32(opcode);
> >>> +
> >
> > BTW, don't RISC-V need any i-cache flush and per-core serialization
> > for patching the text area? (and no text_mutex protection?)
>
> Yes, we should probably call flush_icache_all. This code works on
> QEMU/virt but I guess on real hardware you may run into problems,
> especially when disarming the kprobe. I'll have a look at the arm64 code
> again to see what's missing.
Note that self code-modifying is a special case for any processors, especially
if that is multi-processor. In general, this may depend on the circuit desgin,
not ISA.
Some processor implementation will do in-order and no i-cache, no SMP, that will
be simple, but if it is out-of-order, deep pipeline, huge i-cache, and
many-core,
you might have to care many things. We have to talk with someone who is
designing
real hardware, and maybe better to make the patch_text pluggable for variants.
(or choose the safest way)
> >>> diff --git a/arch/riscv/kernel/probes/kprobes_trampoline.S
> >>> b/arch/riscv/kernel/probes/kprobes_trampoline.S
> >>> new file mode 100644
> >>> index ..c7ceda9556a3
> >>> --- /dev/null
> >>> +++ b/arch/riscv/kernel/probes/kprobes_trampoline.S
> >>> @@ -0,0 +1,91 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0+ */
> >>> +
> >>> +#include
> >>> +
> >>> +#include
> >>> +#include
> >>> +
> >>> + .text
> >>> + .altmacro
> >>> +
> >>> + .macro save_all_base_regs
> >>> + REG_S x1, PT_RA(sp)
> >>> + REG_S x3, PT_GP(sp)
> >>> + REG_S x4, PT_TP(sp)
> >>> + REG_S x5, PT_T0(sp)
> >>> + REG_S x6, PT_T1(sp)
> >>> + REG_S x7, PT_T2(sp)
> >>> + REG_S x8, PT_S0(sp)
> >>> + REG_S x9, PT_S1(sp)
> >>> + REG_S x10, PT_A0(sp)
> >>> + REG_S x11, PT_A1(sp)
> >>> + REG_S x12, PT_A2(sp)
> >>> + REG_S x13, PT_A3(sp)
> >>> + REG_S x14, PT_A4(sp)
> >>> + REG_S x15, PT_A5(sp)
> >>> + REG_S x16, PT_A6(sp)
> >>> + REG_S x17, PT_A7(sp)
> >>> + REG_S x18, PT_S2(sp)
> >>> + REG_S x19, PT_S3(sp)
> >>> + REG_S x20, PT_S4(sp)
> >>> + REG_S x21, PT_S5(sp)
> >>> + REG_S x22, PT_S6(sp)
> >>> + REG_S x23, PT_S7(sp)
> >>> + REG_S x24, PT_S8(sp)
> >>> + REG_S x25, PT_S9(sp)
> >>> + REG_S x26, PT_S10(sp)
> >>> + REG_S x27, PT_S11(sp)
> >>> + REG_S x28, PT_T3(sp)
> >>> + REG_S x29, PT_T4(sp)
> >>> + REG_S x30, PT_T5(sp)
> >>> + REG_S x31, PT_T6(sp)
> >>> + .endm
> >>> +
> >>> + .macro restore_all_base_regs
> >>> + REG_L x3, PT_GP(sp)
> >>> + REG_L x4, PT_TP(sp)
> >>> + REG_L x5, PT_T0(sp)
> >>> + REG_L x6, PT_T1(sp)
> >>> + REG_L x7, PT_T2(sp)
> >>> + REG_L x8, PT_S0(sp)
> >>> + REG_L x9, PT_S1(sp)
> >>> + REG_L x10, PT_A0(sp)
> >>> + REG_L x11, PT_A1(sp)
> >>> + REG_L x12, PT_A2(sp)
> >>> + REG_L x13, PT_A3(sp)
> >>> + REG_L x14, PT_A4(sp)
> >>> + REG_L x15, PT_A5(sp)
> >>> + REG_L x16, PT_A6(sp)
> >>> + REG_L x17, PT_A7(sp)
> >>> + REG_L x18, PT_S2(sp)
> >>> + REG_L x19, PT_S3(sp)
> >>> + REG_L x20, PT_S4(sp)
> >>> + REG_L x21, PT_S5(sp)
> >>> + REG_L x22, PT_S6(sp)
> >>> + REG_L x23, PT_S7(sp)
> >>> + REG_L x24, PT_S8(sp)
> >>> + REG_L x25, PT_S9(sp)
> >>> + REG_L x26, PT_S10(sp)
> >>> + REG_L x27, PT_S11(sp)
> >>> + REG_L x28, PT_T3(sp)
> >>> + REG_L x29, PT_T4(sp)
> >>> + REG_L x30, PT_T5(sp)
> >>> + REG_L x31, PT_T6(sp)
> >>> + .endm
> >
> >
> > It seems thses macros can be (partially?) shared with entry.S
>
> Yes, I wanted to avoid somebody changing the shared code and breaking
> random things. But that's what reviews are for. I'll think of something
> for v2.
Ah, OK. So for the first version, we introduce this separated code until
someone complains it.
Thank you,
--
Masami Hiramatsu
Re: [RFC/RFT 2/2] RISC-V: kprobes/kretprobe support
On Wed, 14 Nov 2018 22:10:52 +0100
Patrick Staehlin wrote:
> On 14.11.18 16:49, Masami Hiramatsu wrote:
> > On Wed, 14 Nov 2018 00:37:30 -0800
> > Masami Hiramatsu wrote:
> >
> >>> +
> >>> +static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
> >>> +{
> >>> + if (is_compressed_insn(opcode))
> >>> + *(u16 *)addr = cpu_to_le16(opcode);
> >>> + else
> >>> + *addr = cpu_to_le32(opcode);
> >>> +
> >
> > BTW, don't RISC-V need any i-cache flush and per-core serialization
> > for patching the text area? (and no text_mutex protection?)
>
> Yes, we should probably call flush_icache_all. This code works on
> QEMU/virt but I guess on real hardware you may run into problems,
> especially when disarming the kprobe. I'll have a look at the arm64 code
> again to see what's missing.
Note that self code-modifying is a special case for any processors, especially
if that is multi-processor. In general, this may depend on the circuit desgin,
not ISA.
Some processor implementation will do in-order and no i-cache, no SMP, that will
be simple, but if it is out-of-order, deep pipeline, huge i-cache, and
many-core,
you might have to care many things. We have to talk with someone who is
designing
real hardware, and maybe better to make the patch_text pluggable for variants.
(or choose the safest way)
> >>> diff --git a/arch/riscv/kernel/probes/kprobes_trampoline.S
> >>> b/arch/riscv/kernel/probes/kprobes_trampoline.S
> >>> new file mode 100644
> >>> index ..c7ceda9556a3
> >>> --- /dev/null
> >>> +++ b/arch/riscv/kernel/probes/kprobes_trampoline.S
> >>> @@ -0,0 +1,91 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0+ */
> >>> +
> >>> +#include
> >>> +
> >>> +#include
> >>> +#include
> >>> +
> >>> + .text
> >>> + .altmacro
> >>> +
> >>> + .macro save_all_base_regs
> >>> + REG_S x1, PT_RA(sp)
> >>> + REG_S x3, PT_GP(sp)
> >>> + REG_S x4, PT_TP(sp)
> >>> + REG_S x5, PT_T0(sp)
> >>> + REG_S x6, PT_T1(sp)
> >>> + REG_S x7, PT_T2(sp)
> >>> + REG_S x8, PT_S0(sp)
> >>> + REG_S x9, PT_S1(sp)
> >>> + REG_S x10, PT_A0(sp)
> >>> + REG_S x11, PT_A1(sp)
> >>> + REG_S x12, PT_A2(sp)
> >>> + REG_S x13, PT_A3(sp)
> >>> + REG_S x14, PT_A4(sp)
> >>> + REG_S x15, PT_A5(sp)
> >>> + REG_S x16, PT_A6(sp)
> >>> + REG_S x17, PT_A7(sp)
> >>> + REG_S x18, PT_S2(sp)
> >>> + REG_S x19, PT_S3(sp)
> >>> + REG_S x20, PT_S4(sp)
> >>> + REG_S x21, PT_S5(sp)
> >>> + REG_S x22, PT_S6(sp)
> >>> + REG_S x23, PT_S7(sp)
> >>> + REG_S x24, PT_S8(sp)
> >>> + REG_S x25, PT_S9(sp)
> >>> + REG_S x26, PT_S10(sp)
> >>> + REG_S x27, PT_S11(sp)
> >>> + REG_S x28, PT_T3(sp)
> >>> + REG_S x29, PT_T4(sp)
> >>> + REG_S x30, PT_T5(sp)
> >>> + REG_S x31, PT_T6(sp)
> >>> + .endm
> >>> +
> >>> + .macro restore_all_base_regs
> >>> + REG_L x3, PT_GP(sp)
> >>> + REG_L x4, PT_TP(sp)
> >>> + REG_L x5, PT_T0(sp)
> >>> + REG_L x6, PT_T1(sp)
> >>> + REG_L x7, PT_T2(sp)
> >>> + REG_L x8, PT_S0(sp)
> >>> + REG_L x9, PT_S1(sp)
> >>> + REG_L x10, PT_A0(sp)
> >>> + REG_L x11, PT_A1(sp)
> >>> + REG_L x12, PT_A2(sp)
> >>> + REG_L x13, PT_A3(sp)
> >>> + REG_L x14, PT_A4(sp)
> >>> + REG_L x15, PT_A5(sp)
> >>> + REG_L x16, PT_A6(sp)
> >>> + REG_L x17, PT_A7(sp)
> >>> + REG_L x18, PT_S2(sp)
> >>> + REG_L x19, PT_S3(sp)
> >>> + REG_L x20, PT_S4(sp)
> >>> + REG_L x21, PT_S5(sp)
> >>> + REG_L x22, PT_S6(sp)
> >>> + REG_L x23, PT_S7(sp)
> >>> + REG_L x24, PT_S8(sp)
> >>> + REG_L x25, PT_S9(sp)
> >>> + REG_L x26, PT_S10(sp)
> >>> + REG_L x27, PT_S11(sp)
> >>> + REG_L x28, PT_T3(sp)
> >>> + REG_L x29, PT_T4(sp)
> >>> + REG_L x30, PT_T5(sp)
> >>> + REG_L x31, PT_T6(sp)
> >>> + .endm
> >
> >
> > It seems thses macros can be (partially?) shared with entry.S
>
> Yes, I wanted to avoid somebody changing the shared code and breaking
> random things. But that's what reviews are for. I'll think of something
> for v2.
Ah, OK. So for the first version, we introduce this separated code until
someone complains it.
Thank you,
--
Masami Hiramatsu
Re: [RFC PATCH] mm, memory_hotplug: do not clear numa_node association after hot_remove
On Wed 14-11-18 15:18:09, Andrew Morton wrote: > On Wed, 14 Nov 2018 08:14:42 +0100 Michal Hocko wrote: > > > It seems there were no objections here. So can we have it in linux-next > > for a wider testing a possibly target the next merge window? > > > > top-posting sucks! I thought it would make your life easier in this case. Will do it differently next time. > I already have this queued for 4.21-rc1. Thanks! I must have missed the mm-commit email. -- Michal Hocko SUSE Labs
[PATCH] platform/x86: thinkpad_acpi: add adaptive_kbd_modes parameter
This bitmap parameter allows the user to add/remove modes for
DFR_CHANGE_ROW to cycle through.
Users who wish to cycle through WEB_BROWSER_MODE and/or
WEB_CONFERENCE_MODE may now do so by enabling corresponding bits.
While some appreciate more modes, I made this feature because I
wanted to lock the keyboard into FUNCTION_MODE. This is because
my Fn key (DFR_CHANGE_ROW) is mapped to Escape, and my "Esc" key
is mapped to grave/asciitilde to match the layout of a regular
keyboard.
The default remains unchanged with the DFR_CHANGE_ROW key
toggling between HOME_MODE and FUNCTION_MODE. Thus the
default "adaptive_kbd_modes" value is 9, but I use 8:
echo 8 >/sys/devices/platform/thinkpad_acpi/adaptive_kbd_modes
The above setting with this change and the following keymap
preserves my sanity on the atrocious adaptive keyboard on
the 2nd-gen X1 Carbon:
{
echo keymaps 0-255
# Esc key maps to '`' or '~'
echo keycode 1 = grave asciitilde
# Fn key maps to Escape
echo keycode 143 = Escape
# Home and End on the keyboard map to Control
echo keycode 102 = Control
echo keycode 107 = Control
} | loadkeys -
Or with the following xmodmaprc:
remove Control = Control_L
remove Lock = Control_L
keycode 9 = grave asciitilde grave
keycode 110 = Control_L NoSymbol Control_L
keycode 115 = Control_L NoSymbol Control_L
keycode 151 = Escape NoSymbol Escape
add Control = Control_L
Signed-off-by: Eric Wong
---
Documentation/laptops/thinkpad-acpi.txt | 11 +
drivers/platform/x86/thinkpad_acpi.c| 79 ++---
2 files changed, 64 insertions(+), 26 deletions(-)
diff --git a/Documentation/laptops/thinkpad-acpi.txt
b/Documentation/laptops/thinkpad-acpi.txt
index 6cced88de6da..36c8731b6919 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -1378,6 +1378,17 @@ For more details about which buttons will appear
depending on the mode, please
review the laptop's user guide:
http://www.lenovo.com/shop/americas/content/user_guides/x1carbon_2_ug_en.pdf
+sysfs device attribute: adaptive_kbd_modes
+
+This bitmap attribute controls the modes the "Fn" key is allowed
+to cycle through. The value can be read and set. Enabled bits
+correspond to the modes above (that is, the first bit is "Home mode"
+and the fourth bit "Function mode").
+
+The default value is 9, which allows cycling between Home and Function modes.
+Setting and unsetting corresponding bits allows adding or removing modes
+to cycle through.
+
Multiple Commands, Module Parameters
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index fde08a997557..77b4f00e0443 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3094,8 +3094,44 @@ static ssize_t adaptive_kbd_mode_store(struct device
*dev,
static DEVICE_ATTR_RW(adaptive_kbd_mode);
+/* Thinkpad X1 Carbon support 5 modes including Home mode, Web browser
+ * mode, Web conference mode, Function mode and Lay-flat mode.
+ * We support cycling between Home mode and Function mode by default.
+ *
+ * Users may enable and disable other modes by changing the
+ * adaptive_kbd_modes bitmap attribute
+ */
+static unsigned adaptive_kbd_modes =
+ 1 << HOME_MODE |
+/* 1 << WEB_BROWSER_MODE |
+ 1 << WEB_CONFERENCE_MODE | */
+ 1 << FUNCTION_MODE;
+
+static ssize_t adaptive_kbd_modes_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "%u\n", adaptive_kbd_modes);
+}
+
+static ssize_t adaptive_kbd_modes_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long t;
+
+ if (parse_strtoul(buf, (1 << LAYFLAT_MODE) - 1, ))
+ return -EINVAL;
+
+ adaptive_kbd_modes = (unsigned int)t;
+ return count;
+}
+
+static DEVICE_ATTR_RW(adaptive_kbd_modes);
+
static struct attribute *adaptive_kbd_attributes[] = {
_attr_adaptive_kbd_mode.attr,
+ _attr_adaptive_kbd_modes.attr,
NULL
};
@@ -3763,20 +3799,7 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
return (res < 0) ? res : 1;
}
-/* Thinkpad X1 Carbon support 5 modes including Home mode, Web browser
- * mode, Web conference mode, Function mode and Lay-flat mode.
- * We support Home mode and Function mode currently.
- *
- * Will consider support rest of modes in future.
- *
- */
-static const int adaptive_keyboard_modes[] = {
- HOME_MODE,
-/* WEB_BROWSER_MODE = 2,
- WEB_CONFERENCE_MODE = 3, */
- FUNCTION_MODE
-};
-
+/* Thinkpad X1 Carbon adaptive keyboard */
#define
Re: [RFC PATCH] mm, memory_hotplug: do not clear numa_node association after hot_remove
On Wed 14-11-18 15:18:09, Andrew Morton wrote: > On Wed, 14 Nov 2018 08:14:42 +0100 Michal Hocko wrote: > > > It seems there were no objections here. So can we have it in linux-next > > for a wider testing a possibly target the next merge window? > > > > top-posting sucks! I thought it would make your life easier in this case. Will do it differently next time. > I already have this queued for 4.21-rc1. Thanks! I must have missed the mm-commit email. -- Michal Hocko SUSE Labs
[PATCH] platform/x86: thinkpad_acpi: add adaptive_kbd_modes parameter
This bitmap parameter allows the user to add/remove modes for
DFR_CHANGE_ROW to cycle through.
Users who wish to cycle through WEB_BROWSER_MODE and/or
WEB_CONFERENCE_MODE may now do so by enabling corresponding bits.
While some appreciate more modes, I made this feature because I
wanted to lock the keyboard into FUNCTION_MODE. This is because
my Fn key (DFR_CHANGE_ROW) is mapped to Escape, and my "Esc" key
is mapped to grave/asciitilde to match the layout of a regular
keyboard.
The default remains unchanged with the DFR_CHANGE_ROW key
toggling between HOME_MODE and FUNCTION_MODE. Thus the
default "adaptive_kbd_modes" value is 9, but I use 8:
echo 8 >/sys/devices/platform/thinkpad_acpi/adaptive_kbd_modes
The above setting with this change and the following keymap
preserves my sanity on the atrocious adaptive keyboard on
the 2nd-gen X1 Carbon:
{
echo keymaps 0-255
# Esc key maps to '`' or '~'
echo keycode 1 = grave asciitilde
# Fn key maps to Escape
echo keycode 143 = Escape
# Home and End on the keyboard map to Control
echo keycode 102 = Control
echo keycode 107 = Control
} | loadkeys -
Or with the following xmodmaprc:
remove Control = Control_L
remove Lock = Control_L
keycode 9 = grave asciitilde grave
keycode 110 = Control_L NoSymbol Control_L
keycode 115 = Control_L NoSymbol Control_L
keycode 151 = Escape NoSymbol Escape
add Control = Control_L
Signed-off-by: Eric Wong
---
Documentation/laptops/thinkpad-acpi.txt | 11 +
drivers/platform/x86/thinkpad_acpi.c| 79 ++---
2 files changed, 64 insertions(+), 26 deletions(-)
diff --git a/Documentation/laptops/thinkpad-acpi.txt
b/Documentation/laptops/thinkpad-acpi.txt
index 6cced88de6da..36c8731b6919 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -1378,6 +1378,17 @@ For more details about which buttons will appear
depending on the mode, please
review the laptop's user guide:
http://www.lenovo.com/shop/americas/content/user_guides/x1carbon_2_ug_en.pdf
+sysfs device attribute: adaptive_kbd_modes
+
+This bitmap attribute controls the modes the "Fn" key is allowed
+to cycle through. The value can be read and set. Enabled bits
+correspond to the modes above (that is, the first bit is "Home mode"
+and the fourth bit "Function mode").
+
+The default value is 9, which allows cycling between Home and Function modes.
+Setting and unsetting corresponding bits allows adding or removing modes
+to cycle through.
+
Multiple Commands, Module Parameters
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index fde08a997557..77b4f00e0443 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3094,8 +3094,44 @@ static ssize_t adaptive_kbd_mode_store(struct device
*dev,
static DEVICE_ATTR_RW(adaptive_kbd_mode);
+/* Thinkpad X1 Carbon support 5 modes including Home mode, Web browser
+ * mode, Web conference mode, Function mode and Lay-flat mode.
+ * We support cycling between Home mode and Function mode by default.
+ *
+ * Users may enable and disable other modes by changing the
+ * adaptive_kbd_modes bitmap attribute
+ */
+static unsigned adaptive_kbd_modes =
+ 1 << HOME_MODE |
+/* 1 << WEB_BROWSER_MODE |
+ 1 << WEB_CONFERENCE_MODE | */
+ 1 << FUNCTION_MODE;
+
+static ssize_t adaptive_kbd_modes_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "%u\n", adaptive_kbd_modes);
+}
+
+static ssize_t adaptive_kbd_modes_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long t;
+
+ if (parse_strtoul(buf, (1 << LAYFLAT_MODE) - 1, ))
+ return -EINVAL;
+
+ adaptive_kbd_modes = (unsigned int)t;
+ return count;
+}
+
+static DEVICE_ATTR_RW(adaptive_kbd_modes);
+
static struct attribute *adaptive_kbd_attributes[] = {
_attr_adaptive_kbd_mode.attr,
+ _attr_adaptive_kbd_modes.attr,
NULL
};
@@ -3763,20 +3799,7 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
return (res < 0) ? res : 1;
}
-/* Thinkpad X1 Carbon support 5 modes including Home mode, Web browser
- * mode, Web conference mode, Function mode and Lay-flat mode.
- * We support Home mode and Function mode currently.
- *
- * Will consider support rest of modes in future.
- *
- */
-static const int adaptive_keyboard_modes[] = {
- HOME_MODE,
-/* WEB_BROWSER_MODE = 2,
- WEB_CONFERENCE_MODE = 3, */
- FUNCTION_MODE
-};
-
+/* Thinkpad X1 Carbon adaptive keyboard */
#define
Re: Memory hotplug softlock issue
On Thu 15-11-18 13:10:34, Baoquan He wrote: > On 11/14/18 at 04:00pm, Michal Hocko wrote: > > On Wed 14-11-18 22:52:50, Baoquan He wrote: > > > On 11/14/18 at 10:01am, Michal Hocko wrote: > > > > I have seen an issue when the migration cannot make a forward progress > > > > because of a glibc page with a reference count bumping up and down. Most > > > > probable explanation is the faultaround code. I am working on this and > > > > will post a patch soon. In any case the migration should converge and if > > > > it doesn't do then there is a bug lurking somewhere. > > > > > > > > Failing on ENOMEM is a questionable thing. I haven't seen that happening > > > > wildly but if it is a case then I wouldn't be opposed. > > > > > > Applied your debugging patches, it helps a lot to printing message. > > > > > > Below is the dmesg log about the migrating failure. It can't pass > > > migrate_pages() and loop forever. > > > > > > [ +0.083841] migrating pfn 10fff7d0 failed > > > [ +0.05] page:ea043ffdf400 count:208 mapcount:201 > > > mapping:888dff4bdda8 index:0x2 > > > [ +0.012689] xfs_address_space_operations [xfs] > > > [ +0.30] name:"stress" > > > [ +0.004556] flags: 0x5fc004(uptodate) > > > [ +0.007339] raw: 005fc004 c90e3d80 c90e3d80 > > > 888dff4bdda8 > > > [ +0.009488] raw: 0002 00cb00c8 > > > 888e7353d000 > > > [ +0.007726] page->mem_cgroup:888e7353d000 > > > [ +0.084538] migrating pfn 10fff7d0 failed > > > [ +0.06] page:ea043ffdf400 count:210 mapcount:201 > > > mapping:888dff4bdda8 index:0x2 > > > [ +0.012798] xfs_address_space_operations [xfs] > > > [ +0.34] name:"stress" > > > [ +0.004524] flags: 0x5fc004(uptodate) > > > [ +0.007068] raw: 005fc004 c90e3d80 c90e3d80 > > > 888dff4bdda8 > > > [ +0.009359] raw: 0002 00cb00c8 > > > 888e7353d000 > > > [ +0.007728] page->mem_cgroup:888e7353d000 > > > > I wouldn't be surprised if this was a similar/same issue I've been > > chasing recently. Could you try to disable faultaround to see if that > > helps. It seems that it helped in my particular case but I am still > > waiting for the final good-to-go to post the patch as I do not own the > > workload which triggered that issue. > > Tried, still stuck in last block sometime. Usually after several times > of hotplug/unplug. If stop stress program, the last block will be > offlined immediately. Is the pattern still the same? I mean failing over few pages with reference count jumping up and down between attempts? > [root@ ~]# cat /sys/kernel/debug/fault_around_bytes > 4096 Can you make it 0? -- Michal Hocko SUSE Labs
Re: Memory hotplug softlock issue
On Thu 15-11-18 13:10:34, Baoquan He wrote: > On 11/14/18 at 04:00pm, Michal Hocko wrote: > > On Wed 14-11-18 22:52:50, Baoquan He wrote: > > > On 11/14/18 at 10:01am, Michal Hocko wrote: > > > > I have seen an issue when the migration cannot make a forward progress > > > > because of a glibc page with a reference count bumping up and down. Most > > > > probable explanation is the faultaround code. I am working on this and > > > > will post a patch soon. In any case the migration should converge and if > > > > it doesn't do then there is a bug lurking somewhere. > > > > > > > > Failing on ENOMEM is a questionable thing. I haven't seen that happening > > > > wildly but if it is a case then I wouldn't be opposed. > > > > > > Applied your debugging patches, it helps a lot to printing message. > > > > > > Below is the dmesg log about the migrating failure. It can't pass > > > migrate_pages() and loop forever. > > > > > > [ +0.083841] migrating pfn 10fff7d0 failed > > > [ +0.05] page:ea043ffdf400 count:208 mapcount:201 > > > mapping:888dff4bdda8 index:0x2 > > > [ +0.012689] xfs_address_space_operations [xfs] > > > [ +0.30] name:"stress" > > > [ +0.004556] flags: 0x5fc004(uptodate) > > > [ +0.007339] raw: 005fc004 c90e3d80 c90e3d80 > > > 888dff4bdda8 > > > [ +0.009488] raw: 0002 00cb00c8 > > > 888e7353d000 > > > [ +0.007726] page->mem_cgroup:888e7353d000 > > > [ +0.084538] migrating pfn 10fff7d0 failed > > > [ +0.06] page:ea043ffdf400 count:210 mapcount:201 > > > mapping:888dff4bdda8 index:0x2 > > > [ +0.012798] xfs_address_space_operations [xfs] > > > [ +0.34] name:"stress" > > > [ +0.004524] flags: 0x5fc004(uptodate) > > > [ +0.007068] raw: 005fc004 c90e3d80 c90e3d80 > > > 888dff4bdda8 > > > [ +0.009359] raw: 0002 00cb00c8 > > > 888e7353d000 > > > [ +0.007728] page->mem_cgroup:888e7353d000 > > > > I wouldn't be surprised if this was a similar/same issue I've been > > chasing recently. Could you try to disable faultaround to see if that > > helps. It seems that it helped in my particular case but I am still > > waiting for the final good-to-go to post the patch as I do not own the > > workload which triggered that issue. > > Tried, still stuck in last block sometime. Usually after several times > of hotplug/unplug. If stop stress program, the last block will be > offlined immediately. Is the pattern still the same? I mean failing over few pages with reference count jumping up and down between attempts? > [root@ ~]# cat /sys/kernel/debug/fault_around_bytes > 4096 Can you make it 0? -- Michal Hocko SUSE Labs
Re: [PATCH v2 1/2] pci: prevent sk hynix nvme from entering D3
Hi, > On Nov 9, 2018, at 08:21, Bjorn Helgaas wrote: > > On Tue, Nov 06, 2018 at 03:12:13PM +0800, AceLan Kao wrote: >> It leads to the power consumption raises to 2.2W during s2idle, while >> it consumes less than 1W during long idle if put SK hynix nvme to D3 >> and then enter s2idle. >> From SK hynix FE, MS Windows doesn't put nvme to D3, and uses its own >> APST feature to do the power management. >> To leverage its APST feature during s2idle, we can't disable nvme >> device while suspending, too. We have a new Intel NVMe [8086:f1a6] that has this “new” behavior. > > I don't know how APST works, but it sounds like you want to disable D3 > if you're using APST. But that's not what this patch does; this > disables it always. Ok, will work on a new patch that only disables D3 when APST is enabled. > > I'm not sure we want a quirk for this at all, since as Christoph > points out, it doesn't fix a functional issue as the other uses of > quirk_no_ata_d3() do. > > From your emails with Christoph, it sounds like this quirk is a > workaround for a firmware defect. If we *do* end up wanting a quirk, > the changelog should at least mention the firmware defect and maybe > check whether it has been fixed. According to SK Hynix folks and new evidence on the new Intel NVMe we have, this is something we are going to see more often. Kai-Heng > >> BTW, prevent it from entering D3 will increase the power consumtion around >> 0.13W ~ 0.15W during short/long idle, and the power consumption during >> s2idle becomes 0.77W. >> >> Signed-off-by: AceLan Kao >> --- >> drivers/pci/quirks.c| 1 + >> include/linux/pci_ids.h | 2 ++ >> 2 files changed, 3 insertions(+) >> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >> index 4700d24e5d55..b7e6492e8311 100644 >> --- a/drivers/pci/quirks.c >> +++ b/drivers/pci/quirks.c >> @@ -1332,6 +1332,7 @@ DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AL, >> PCI_ANY_ID, >>occur when mode detecting */ >> DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, PCI_ANY_ID, >> PCI_CLASS_STORAGE_IDE, 8, quirk_no_ata_d3); >> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SK_HYNIX, 0x1527, quirk_no_ata_d3); >> >> /* >> * This was originally an Alpha-specific thing, but it really fits here. >> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h >> index 69f0abe1ba1a..5f5adda07de0 100644 >> --- a/include/linux/pci_ids.h >> +++ b/include/linux/pci_ids.h >> @@ -3090,4 +3090,6 @@ >> >> #define PCI_VENDOR_ID_NCUBE 0x10ff >> >> +#define PCI_VENDOR_ID_SK_HYNIX 0x1c5c >> + >> #endif /* _LINUX_PCI_IDS_H */ >> -- >> 2.17.1 >> >> >> ___ >> Linux-nvme mailing list >> linux-n...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-nvme
Re: [PATCH v2 1/2] pci: prevent sk hynix nvme from entering D3
Hi, > On Nov 9, 2018, at 08:21, Bjorn Helgaas wrote: > > On Tue, Nov 06, 2018 at 03:12:13PM +0800, AceLan Kao wrote: >> It leads to the power consumption raises to 2.2W during s2idle, while >> it consumes less than 1W during long idle if put SK hynix nvme to D3 >> and then enter s2idle. >> From SK hynix FE, MS Windows doesn't put nvme to D3, and uses its own >> APST feature to do the power management. >> To leverage its APST feature during s2idle, we can't disable nvme >> device while suspending, too. We have a new Intel NVMe [8086:f1a6] that has this “new” behavior. > > I don't know how APST works, but it sounds like you want to disable D3 > if you're using APST. But that's not what this patch does; this > disables it always. Ok, will work on a new patch that only disables D3 when APST is enabled. > > I'm not sure we want a quirk for this at all, since as Christoph > points out, it doesn't fix a functional issue as the other uses of > quirk_no_ata_d3() do. > > From your emails with Christoph, it sounds like this quirk is a > workaround for a firmware defect. If we *do* end up wanting a quirk, > the changelog should at least mention the firmware defect and maybe > check whether it has been fixed. According to SK Hynix folks and new evidence on the new Intel NVMe we have, this is something we are going to see more often. Kai-Heng > >> BTW, prevent it from entering D3 will increase the power consumtion around >> 0.13W ~ 0.15W during short/long idle, and the power consumption during >> s2idle becomes 0.77W. >> >> Signed-off-by: AceLan Kao >> --- >> drivers/pci/quirks.c| 1 + >> include/linux/pci_ids.h | 2 ++ >> 2 files changed, 3 insertions(+) >> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >> index 4700d24e5d55..b7e6492e8311 100644 >> --- a/drivers/pci/quirks.c >> +++ b/drivers/pci/quirks.c >> @@ -1332,6 +1332,7 @@ DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AL, >> PCI_ANY_ID, >>occur when mode detecting */ >> DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, PCI_ANY_ID, >> PCI_CLASS_STORAGE_IDE, 8, quirk_no_ata_d3); >> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SK_HYNIX, 0x1527, quirk_no_ata_d3); >> >> /* >> * This was originally an Alpha-specific thing, but it really fits here. >> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h >> index 69f0abe1ba1a..5f5adda07de0 100644 >> --- a/include/linux/pci_ids.h >> +++ b/include/linux/pci_ids.h >> @@ -3090,4 +3090,6 @@ >> >> #define PCI_VENDOR_ID_NCUBE 0x10ff >> >> +#define PCI_VENDOR_ID_SK_HYNIX 0x1c5c >> + >> #endif /* _LINUX_PCI_IDS_H */ >> -- >> 2.17.1 >> >> >> ___ >> Linux-nvme mailing list >> linux-n...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-nvme
Re: [GIT PULL] PCI fixes for v4.20
On Wed, Nov 14, 2018 at 11:48:39PM +0100, Borislav Petkov wrote: > On Wed, Nov 14, 2018 at 05:21:54PM -0500, Konstantin Ryabitsev wrote: > > For the record, there's nothing wrong with that, it's just a condition > > that I didn't expect. I have a fix in place that should avoid this in > > the future. > > Actually, I meant the pull request URL. My pull request URL was this: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.20-fixes-1 > Here's some background info: > > https://lkml.kernel.org/r/CA%2B55aFyMxkS=8jzz%2brooafkwr45ekbnq0gumqs4f%2br_-ffw...@mail.gmail.com > > and I kinda see the point of maybe not having your ssh username in the > URL. Not that it is a big deal for us, k.org users though. Sorry, I don't understand the problem. I have this in my .gitconfig: [url "ssh://g...@gitolite.kernel.org"] insteadOf = https://git.kernel.org insteadOf = http://git.kernel.org insteadOf = git://git.kernel.org because I thought that was the recommended way (see the end of https://korg.wiki.kernel.org/userdoc/gitolite). But that also makes my request-pull: $ git request-pull origin/master git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci-v4.20-fixes-1 generate the ssh URL above. If I remove the insteadOf stuff from .gitconfig, request-pull produces this instead: git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.20-fixes-1 I'm happy to do either; just tell me which :) Bjorn
Re: [GIT PULL] PCI fixes for v4.20
On Wed, Nov 14, 2018 at 11:48:39PM +0100, Borislav Petkov wrote: > On Wed, Nov 14, 2018 at 05:21:54PM -0500, Konstantin Ryabitsev wrote: > > For the record, there's nothing wrong with that, it's just a condition > > that I didn't expect. I have a fix in place that should avoid this in > > the future. > > Actually, I meant the pull request URL. My pull request URL was this: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.20-fixes-1 > Here's some background info: > > https://lkml.kernel.org/r/CA%2B55aFyMxkS=8jzz%2brooafkwr45ekbnq0gumqs4f%2br_-ffw...@mail.gmail.com > > and I kinda see the point of maybe not having your ssh username in the > URL. Not that it is a big deal for us, k.org users though. Sorry, I don't understand the problem. I have this in my .gitconfig: [url "ssh://g...@gitolite.kernel.org"] insteadOf = https://git.kernel.org insteadOf = http://git.kernel.org insteadOf = git://git.kernel.org because I thought that was the recommended way (see the end of https://korg.wiki.kernel.org/userdoc/gitolite). But that also makes my request-pull: $ git request-pull origin/master git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci-v4.20-fixes-1 generate the ssh URL above. If I remove the insteadOf stuff from .gitconfig, request-pull produces this instead: git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.20-fixes-1 I'm happy to do either; just tell me which :) Bjorn
[resend PATCH] dt-bindings: sound: Add documentation for pcm3060 property out-single-ended
Output of pcm3060 codec may be configured as single-ended or differential
Signed-off-by: Kirill Marinushkin
Cc: devicet...@vger.kernel.org
---
Hello Mark,
yesterday there was a misunderstanding: when I wrote you
> I think you forgot one patch in the series
you accidently applied the already-applied patch instead of the forgotten
one. To avoid the confusion, in this e-mail I resend you the proper
forgotten patch in a separate mailing thread.
Please apply this patch for-next.
Best Regards,
Kirill
---
Documentation/devicetree/bindings/sound/pcm3060.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/pcm3060.txt
b/Documentation/devicetree/bindings/sound/pcm3060.txt
index 90fcb8523099..97de66932d44 100644
--- a/Documentation/devicetree/bindings/sound/pcm3060.txt
+++ b/Documentation/devicetree/bindings/sound/pcm3060.txt
@@ -9,9 +9,15 @@ Required properties:
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
+Optional properties:
+
+- ti,out-single-ended: "true" if output is single-ended;
+ "false" or not specified if output is differential.
+
Examples:
pcm3060: pcm3060@46 {
compatible = "ti,pcm3060";
reg = <0x46>;
+ti,out-single-ended = "true";
};
--
2.13.6
[resend PATCH] dt-bindings: sound: Add documentation for pcm3060 property out-single-ended
Output of pcm3060 codec may be configured as single-ended or differential
Signed-off-by: Kirill Marinushkin
Cc: devicet...@vger.kernel.org
---
Hello Mark,
yesterday there was a misunderstanding: when I wrote you
> I think you forgot one patch in the series
you accidently applied the already-applied patch instead of the forgotten
one. To avoid the confusion, in this e-mail I resend you the proper
forgotten patch in a separate mailing thread.
Please apply this patch for-next.
Best Regards,
Kirill
---
Documentation/devicetree/bindings/sound/pcm3060.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/pcm3060.txt
b/Documentation/devicetree/bindings/sound/pcm3060.txt
index 90fcb8523099..97de66932d44 100644
--- a/Documentation/devicetree/bindings/sound/pcm3060.txt
+++ b/Documentation/devicetree/bindings/sound/pcm3060.txt
@@ -9,9 +9,15 @@ Required properties:
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
+Optional properties:
+
+- ti,out-single-ended: "true" if output is single-ended;
+ "false" or not specified if output is differential.
+
Examples:
pcm3060: pcm3060@46 {
compatible = "ti,pcm3060";
reg = <0x46>;
+ti,out-single-ended = "true";
};
--
2.13.6
[PATCH] spi: npcm: fix platform_no_drv_owner.cocci warnings
From: kbuild test robot
drivers/spi/spi-npcm-pspi.c:470:3-8: No need to set .owner here. The core will
do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Fixes: 2a22f1b30cee ("spi: npcm: add NPCM PSPI controller driver")
CC: Tomer Maimon
Signed-off-by: kbuild test robot
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: f4ad10924cb922842beafe644dd1b2aa8fa55189
commit: 2a22f1b30cee8d1e104a6c5062a609bedbfd5c39 [2986/3290] spi: npcm: add
NPCM PSPI controller driver
spi-npcm-pspi.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/spi/spi-npcm-pspi.c
+++ b/drivers/spi/spi-npcm-pspi.c
@@ -467,7 +467,6 @@ static struct platform_driver npcm_pspi_
.driver = {
.name = DRIVER_NAME,
.of_match_table = npcm_pspi_match,
- .owner = THIS_MODULE,
},
.probe = npcm_pspi_probe,
.remove = npcm_pspi_remove,
[PATCH] spi: npcm: fix platform_no_drv_owner.cocci warnings
From: kbuild test robot
drivers/spi/spi-npcm-pspi.c:470:3-8: No need to set .owner here. The core will
do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Fixes: 2a22f1b30cee ("spi: npcm: add NPCM PSPI controller driver")
CC: Tomer Maimon
Signed-off-by: kbuild test robot
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: f4ad10924cb922842beafe644dd1b2aa8fa55189
commit: 2a22f1b30cee8d1e104a6c5062a609bedbfd5c39 [2986/3290] spi: npcm: add
NPCM PSPI controller driver
spi-npcm-pspi.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/spi/spi-npcm-pspi.c
+++ b/drivers/spi/spi-npcm-pspi.c
@@ -467,7 +467,6 @@ static struct platform_driver npcm_pspi_
.driver = {
.name = DRIVER_NAME,
.of_match_table = npcm_pspi_match,
- .owner = THIS_MODULE,
},
.probe = npcm_pspi_probe,
.remove = npcm_pspi_remove,
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
Hi Finn Am 15.11.2018 um 12:54 schrieb Michael Schmitz: That one does appear to work - different versions of ARAnyM, and different userland versions though. I'll test that again with the setup that saw c606b5cf902 fail. Still fails on that emulator / userland. Must be a quirk of ARAnyM 1.0.2 (or powerpc). With 0.9.15 on x86_64, it's fine. I'm sufficiently convinced to try this on actual hardware now. Well, it sort of works - I've seen one login timeout on the console under load (less than 10 seconds after typing in the password), but most attempts went OK. Couldn't log in through SSH without increasing fatal: Timeout before authenticationthe LoginGraceTime parameter though. I usually get reliable login using ssh key files with the default setting of 120 seconds (takes around 90 to 100 seconds to complete). With your patch, even increasing this to 4800 doesn't result in reliable login. The error I see in the logs is 'fatal: Timeout before authentication'. Cheers, Michael
Re: [PATCH 1/4] dt-bindings: pwm: update bindings for MT7629 SoC
On Thu, 2018-11-15 at 14:26 +0800, Ryder Lee wrote: > This updates bindings for MT7629 pwm controller. > > Signed-off-by: Ryder Lee > --- > Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > index 991728c..4a2885b 100644 > --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > @@ -6,6 +6,7 @@ Required properties: > - "mediatek,mt7622-pwm": found on mt7622 SoC. > - "mediatek,mt7623-pwm": found on mt7623 SoC. > - "mediatek,mt7628-pwm": found on mt7628 SoC. > + - "mediatek,mt7629-pwm": found on mt7629 SoC. > - reg: physical base address and length of the controller's registers. > - #pwm-cells: must be 2. See pwm.txt in this directory for a description of > the cell format. Please ignore this PWM patch. Sorry for the inconvenience :( Ryder
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
Hi Finn Am 15.11.2018 um 12:54 schrieb Michael Schmitz: That one does appear to work - different versions of ARAnyM, and different userland versions though. I'll test that again with the setup that saw c606b5cf902 fail. Still fails on that emulator / userland. Must be a quirk of ARAnyM 1.0.2 (or powerpc). With 0.9.15 on x86_64, it's fine. I'm sufficiently convinced to try this on actual hardware now. Well, it sort of works - I've seen one login timeout on the console under load (less than 10 seconds after typing in the password), but most attempts went OK. Couldn't log in through SSH without increasing fatal: Timeout before authenticationthe LoginGraceTime parameter though. I usually get reliable login using ssh key files with the default setting of 120 seconds (takes around 90 to 100 seconds to complete). With your patch, even increasing this to 4800 doesn't result in reliable login. The error I see in the logs is 'fatal: Timeout before authentication'. Cheers, Michael
Re: [PATCH 1/4] dt-bindings: pwm: update bindings for MT7629 SoC
On Thu, 2018-11-15 at 14:26 +0800, Ryder Lee wrote: > This updates bindings for MT7629 pwm controller. > > Signed-off-by: Ryder Lee > --- > Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > index 991728c..4a2885b 100644 > --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt > @@ -6,6 +6,7 @@ Required properties: > - "mediatek,mt7622-pwm": found on mt7622 SoC. > - "mediatek,mt7623-pwm": found on mt7623 SoC. > - "mediatek,mt7628-pwm": found on mt7628 SoC. > + - "mediatek,mt7629-pwm": found on mt7629 SoC. > - reg: physical base address and length of the controller's registers. > - #pwm-cells: must be 2. See pwm.txt in this directory for a description of > the cell format. Please ignore this PWM patch. Sorry for the inconvenience :( Ryder
[PATCH 1/4] dt-bindings: mtd: mtk-quadspi: update bindings for MT7629 SoC
This updates bindings for the MT7629 SPI-NOR controller. Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/mtd/mtk-quadspi.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt index 56d3668..a12e3b5 100644 --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt @@ -1,4 +1,4 @@ -* Serial NOR flash controller for MTK MT81xx (and similar) +* Serial NOR flash controller for MediaTek SoCs Required properties: - compatible:For mt8173, compatible should be "mediatek,mt8173-nor", @@ -10,6 +10,7 @@ Required properties: "mediatek,mt2712-nor", "mediatek,mt8173-nor" "mediatek,mt7622-nor", "mediatek,mt8173-nor" "mediatek,mt7623-nor", "mediatek,mt8173-nor" + "mediatek,mt7629-nor", "mediatek,mt8173-nor" "mediatek,mt8173-nor" - reg: physical base address and length of the controller's register - clocks:the phandle of the clocks needed by the nor controller -- 1.9.1
[PATCH 1/4] dt-bindings: mtd: mtk-quadspi: update bindings for MT7629 SoC
This updates bindings for the MT7629 SPI-NOR controller. Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/mtd/mtk-quadspi.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt index 56d3668..a12e3b5 100644 --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt @@ -1,4 +1,4 @@ -* Serial NOR flash controller for MTK MT81xx (and similar) +* Serial NOR flash controller for MediaTek SoCs Required properties: - compatible:For mt8173, compatible should be "mediatek,mt8173-nor", @@ -10,6 +10,7 @@ Required properties: "mediatek,mt2712-nor", "mediatek,mt8173-nor" "mediatek,mt7622-nor", "mediatek,mt8173-nor" "mediatek,mt7623-nor", "mediatek,mt8173-nor" + "mediatek,mt7629-nor", "mediatek,mt8173-nor" "mediatek,mt8173-nor" - reg: physical base address and length of the controller's register - clocks:the phandle of the clocks needed by the nor controller -- 1.9.1
[PATCH 4/4] mtd: spi-nor: mtk-quadspi: rename config to a common one
The quadspi is a generic communication interface which could be shared with other MediaTek SoCs. Hence rename it to a common one. Signed-off-by: Ryder Lee --- drivers/mtd/spi-nor/Kconfig | 16 drivers/mtd/spi-nor/Makefile | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index 6cc9c92..2062611 100644 --- a/drivers/mtd/spi-nor/Kconfig +++ b/drivers/mtd/spi-nor/Kconfig @@ -7,14 +7,6 @@ menuconfig MTD_SPI_NOR if MTD_SPI_NOR -config MTD_MT81xx_NOR - tristate "Mediatek MT81xx SPI NOR flash controller" - depends on HAS_IOMEM - help - This enables access to SPI NOR flash, using MT81xx SPI NOR flash - controller. This controller does not support generic SPI BUS, it only - supports SPI NOR Flash. - config MTD_SPI_NOR_USE_4K_SECTORS bool "Use small 4096 B erase sectors" default y @@ -86,6 +78,14 @@ config SPI_NXP_SPIFI Flash. Enable this option if you have a device with a SPIFI controller and want to access the Flash as a mtd device. +config SPI_MTK_QUADSPI + tristate "MediaTek Quad SPI controller" + depends on HAS_IOMEM + help + This enables support for the Quad SPI controller in master mode. + This controller does not support generic SPI. It only supports + SPI NOR. + config SPI_INTEL_SPI tristate diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile index f4c61d2..7f4b6f6 100644 --- a/drivers/mtd/spi-nor/Makefile +++ b/drivers/mtd/spi-nor/Makefile @@ -5,7 +5,7 @@ obj-$(CONFIG_SPI_ATMEL_QUADSPI) += atmel-quadspi.o obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o -obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o +obj-$(CONFIG_SPI_MTK_QUADSPI)+= mtk-quadspi.o obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o obj-$(CONFIG_SPI_INTEL_SPI)+= intel-spi.o obj-$(CONFIG_SPI_INTEL_SPI_PCI)+= intel-spi-pci.o -- 1.9.1
[PATCH 4/4] mtd: spi-nor: mtk-quadspi: rename config to a common one
The quadspi is a generic communication interface which could be shared with other MediaTek SoCs. Hence rename it to a common one. Signed-off-by: Ryder Lee --- drivers/mtd/spi-nor/Kconfig | 16 drivers/mtd/spi-nor/Makefile | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index 6cc9c92..2062611 100644 --- a/drivers/mtd/spi-nor/Kconfig +++ b/drivers/mtd/spi-nor/Kconfig @@ -7,14 +7,6 @@ menuconfig MTD_SPI_NOR if MTD_SPI_NOR -config MTD_MT81xx_NOR - tristate "Mediatek MT81xx SPI NOR flash controller" - depends on HAS_IOMEM - help - This enables access to SPI NOR flash, using MT81xx SPI NOR flash - controller. This controller does not support generic SPI BUS, it only - supports SPI NOR Flash. - config MTD_SPI_NOR_USE_4K_SECTORS bool "Use small 4096 B erase sectors" default y @@ -86,6 +78,14 @@ config SPI_NXP_SPIFI Flash. Enable this option if you have a device with a SPIFI controller and want to access the Flash as a mtd device. +config SPI_MTK_QUADSPI + tristate "MediaTek Quad SPI controller" + depends on HAS_IOMEM + help + This enables support for the Quad SPI controller in master mode. + This controller does not support generic SPI. It only supports + SPI NOR. + config SPI_INTEL_SPI tristate diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile index f4c61d2..7f4b6f6 100644 --- a/drivers/mtd/spi-nor/Makefile +++ b/drivers/mtd/spi-nor/Makefile @@ -5,7 +5,7 @@ obj-$(CONFIG_SPI_ATMEL_QUADSPI) += atmel-quadspi.o obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o -obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o +obj-$(CONFIG_SPI_MTK_QUADSPI)+= mtk-quadspi.o obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o obj-$(CONFIG_SPI_INTEL_SPI)+= intel-spi.o obj-$(CONFIG_SPI_INTEL_SPI_PCI)+= intel-spi-pci.o -- 1.9.1
[PATCH 1/4] dt-bindings: pwm: update bindings for MT7629 SoC
This updates bindings for MT7629 pwm controller. Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt index 991728c..4a2885b 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt @@ -6,6 +6,7 @@ Required properties: - "mediatek,mt7622-pwm": found on mt7622 SoC. - "mediatek,mt7623-pwm": found on mt7623 SoC. - "mediatek,mt7628-pwm": found on mt7628 SoC. + - "mediatek,mt7629-pwm": found on mt7629 SoC. - reg: physical base address and length of the controller's registers. - #pwm-cells: must be 2. See pwm.txt in this directory for a description of the cell format. -- 1.9.1
[PATCH 3/4] mtd: spi-nor: mtk-quadspi: add SNOR_HWCAPS_READ for capcity setting
From: Guochun Mao
SNOR_HWCAPS_READ is a basic read mode for both flash and controller,
it should be supported, so add the capcity for mtk-quadspi.
Signed-off-by: Guochun Mao
Tested-by: Ryder Lee
---
drivers/mtd/spi-nor/mtk-quadspi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index 2278677..c198fd2 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -433,7 +433,8 @@ static int mtk_nor_init(struct mtk_nor *mtk_nor,
struct device_node *flash_node)
{
const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ_FAST |
+ .mask = SNOR_HWCAPS_READ |
+ SNOR_HWCAPS_READ_FAST |
SNOR_HWCAPS_READ_1_1_2 |
SNOR_HWCAPS_PP,
};
--
1.9.1
[PATCH 1/4] dt-bindings: pwm: update bindings for MT7629 SoC
This updates bindings for MT7629 pwm controller. Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt index 991728c..4a2885b 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt @@ -6,6 +6,7 @@ Required properties: - "mediatek,mt7622-pwm": found on mt7622 SoC. - "mediatek,mt7623-pwm": found on mt7623 SoC. - "mediatek,mt7628-pwm": found on mt7628 SoC. + - "mediatek,mt7629-pwm": found on mt7629 SoC. - reg: physical base address and length of the controller's registers. - #pwm-cells: must be 2. See pwm.txt in this directory for a description of the cell format. -- 1.9.1
[PATCH 3/4] mtd: spi-nor: mtk-quadspi: add SNOR_HWCAPS_READ for capcity setting
From: Guochun Mao
SNOR_HWCAPS_READ is a basic read mode for both flash and controller,
it should be supported, so add the capcity for mtk-quadspi.
Signed-off-by: Guochun Mao
Tested-by: Ryder Lee
---
drivers/mtd/spi-nor/mtk-quadspi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index 2278677..c198fd2 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -433,7 +433,8 @@ static int mtk_nor_init(struct mtk_nor *mtk_nor,
struct device_node *flash_node)
{
const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ_FAST |
+ .mask = SNOR_HWCAPS_READ |
+ SNOR_HWCAPS_READ_FAST |
SNOR_HWCAPS_READ_1_1_2 |
SNOR_HWCAPS_PP,
};
--
1.9.1
[PATCH 2/4] mtd: spi-nor: mtk-quadspi: use ofpart for parsing partitions
From: Guochun Mao
Replace mtd_device_register with mtd_device_parse_register for
parsing partitions.
Add ofpart support.
Signed-off-by: Guochun Mao
Tested-by: Ryder Lee
---
drivers/mtd/spi-nor/mtk-quadspi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index 5442993..2278677 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -118,6 +118,8 @@ struct mtk_nor {
struct clk *nor_clk;
};
+static const char * const probes[] = { "ofpart", NULL };
+
static void mtk_nor_set_read_mode(struct mtk_nor *mtk_nor)
{
struct spi_nor *nor = _nor->nor;
@@ -457,7 +459,7 @@ static int mtk_nor_init(struct mtk_nor *mtk_nor,
if (ret)
return ret;
- return mtd_device_register(>mtd, NULL, 0);
+ return mtd_device_parse_register(>mtd, probes, NULL, NULL, 0);
}
static int mtk_nor_drv_probe(struct platform_device *pdev)
--
1.9.1
[PATCH 2/4] mtd: spi-nor: mtk-quadspi: use ofpart for parsing partitions
From: Guochun Mao
Replace mtd_device_register with mtd_device_parse_register for
parsing partitions.
Add ofpart support.
Signed-off-by: Guochun Mao
Tested-by: Ryder Lee
---
drivers/mtd/spi-nor/mtk-quadspi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index 5442993..2278677 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -118,6 +118,8 @@ struct mtk_nor {
struct clk *nor_clk;
};
+static const char * const probes[] = { "ofpart", NULL };
+
static void mtk_nor_set_read_mode(struct mtk_nor *mtk_nor)
{
struct spi_nor *nor = _nor->nor;
@@ -457,7 +459,7 @@ static int mtk_nor_init(struct mtk_nor *mtk_nor,
if (ret)
return ret;
- return mtd_device_register(>mtd, NULL, 0);
+ return mtd_device_parse_register(>mtd, probes, NULL, NULL, 0);
}
static int mtk_nor_drv_probe(struct platform_device *pdev)
--
1.9.1
Re: [PATCH 1/2] clocksource: meson6_timer: use register names from the datasheet
Hi Daniel,
thanks for your feedback!
On Thu, Nov 15, 2018 at 2:35 AM Daniel Lezcano
wrote:
>
> On 28/10/2018 13:55, Martin Blumenstingl wrote:
> > This makes the driver use the names from S805 datasheet for the
> > preprocessor #defines. This makes it easier to spot that the driver
> > currently only supports Timer A (as clockevent with interrupt support)
> > and Timer E (as clocksource without interrupts). Timer B, C and D (which
> > are similar to Timer A) are currently not supported by the driver.
> >
> > While here, this also removes the internal "CED_ID" and "CSD_ID" defines
> > which are used to identify the timer. These IDs are not described in the
> > datasheet and thus make it harder to compare the code to what's written
> > in the datasheet.
> >
> > Signed-off-by: Martin Blumenstingl
> > ---
> > drivers/clocksource/meson6_timer.c | 110 ++---
> > 1 file changed, 68 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/clocksource/meson6_timer.c
> > b/drivers/clocksource/meson6_timer.c
> > index 92f20991a937..c622135bee9d 100644
> > --- a/drivers/clocksource/meson6_timer.c
> > +++ b/drivers/clocksource/meson6_timer.c
> > @@ -10,6 +10,8 @@
> > * warranty of any kind, whether express or implied.
> > */
> >
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > @@ -20,80 +22,102 @@
> > #include
> > #include
> >
> > -#define CED_ID 0
> > -#define CSD_ID 4
> > -
> > -#define TIMER_ISA_MUX0
> > -#define TIMER_ISA_VAL(t) (((t) + 1) << 2)
> > -
> > -#define TIMER_INPUT_BIT(t) (2 * (t))
> > -#define TIMER_ENABLE_BIT(t) (16 + (t))
> > -#define TIMER_PERIODIC_BIT(t)(12 + (t))
> > +enum meson6_timera_input_clock {
> > + MESON_TIMERA_CLOCK_1US = 0x0,
> > + MESON_TIMERA_CLOCK_10US = 0x1,
> > + MESON_TIMERA_CLOCK_100US = 0x2,
> > + MESON_TIMERA_CLOCK_1MS = 0x3,
> > +};
> >
> > -#define TIMER_CED_INPUT_MASK (3UL << TIMER_INPUT_BIT(CED_ID))
> > -#define TIMER_CSD_INPUT_MASK (7UL << TIMER_INPUT_BIT(CSD_ID))
> > +enum meson6_timere_input_clock {
> > + MESON_TIMERE_CLOCK_SYSTEM_CLOCK = 0x0,
> > + MESON_TIMERE_CLOCK_1US = 0x1,
> > + MESON_TIMERE_CLOCK_10US = 0x2,
> > + MESON_TIMERE_CLOCK_100US = 0x3,
> > + MESON_TIMERE_CLOCK_1MS = 0x4,
> > +};
>
> It is not required to specify the values. The standard defines the
> default first value is zero, and each enum has the value which is +1 of
> the previous one.
the idea behind this is: these are values from the datasheet so I
wanted to make them easy to find when comparing the datasheet with the
driver.
I will replace the enums with simple #defines if there are no
objections (that also makes it consistent with the other register
values in the driver).
Regards
Martin
RE: [PATCH v5 3/9] spi: Add a driver for the Freescale/NXP QuadSPI controller
Hi Frieder,
With below patch on top of your v5, Read/Write/Erase on CS1 is working fine for
me.
I have tested with JFFS2 mounting and booting also for both CS0 and CS1.
diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c
index ce45e8e..4467983 100644
--- a/drivers/spi/spi-fsl-qspi.c
+++ b/drivers/spi/spi-fsl-qspi.c
@@ -490,28 +490,10 @@ static void fsl_qspi_select_mem(struct fsl_qspi *q,
struct spi_device *spi)
{
unsigned long rate = spi->max_speed_hz;
int ret, i;
- u32 map_addr;
if (q->selected == spi->chip_select)
return;
- /*
-* In HW there can be a maximum of four chips on two buses with
-* two chip selects on each bus. We use four chip selects in SW
-* to differentiate between the four chips.
-* We use the SFA1AD, SFA2AD, SFB1AD, SFB2AD registers to select
-* the chip we want to access.
-*/
- for (i = 0; i < 4; i++) {
- if (i < spi->chip_select)
- map_addr = q->memmap_phy;
- else
- map_addr = q->memmap_phy +
- 2 * q->devtype_data->ahb_buf_size;
-
- qspi_writel(q, map_addr, q->iobase + QUADSPI_SFA1AD + (i * 4));
- }
-
if (needs_4x_clock(q))
rate *= 4;
@@ -534,7 +516,9 @@ static void fsl_qspi_select_mem(struct fsl_qspi *q, struct
spi_device *spi)
static void fsl_qspi_read_ahb(struct fsl_qspi *q, const struct spi_mem_op *op)
{
- memcpy_fromio(op->data.buf.in, q->ahb_addr, op->data.nbytes);
+ memcpy_fromio(op->data.buf.in,
+ q->ahb_addr + q->selected * q->devtype_data->ahb_buf_size,
+ op->data.nbytes);
}
static void fsl_qspi_fill_txfifo(struct fsl_qspi *q,
@@ -634,7 +618,9 @@ static int fsl_qspi_exec_op(struct spi_mem *mem, const
struct spi_mem_op *op)
fsl_qspi_select_mem(q, mem->spi);
- qspi_writel(q, q->memmap_phy, base + QUADSPI_SFAR);
+ qspi_writel(q,
+ q->selected * q->devtype_data->ahb_buf_size,
+ base + QUADSPI_SFAR);
qspi_writel(q, qspi_readl(q, base + QUADSPI_MCR) |
QUADSPI_MCR_CLR_RXF_MASK | QUADSPI_MCR_CLR_TXF_MASK,
@@ -733,6 +719,19 @@ static int fsl_qspi_default_setup(struct fsl_qspi *q)
QUADSPI_BUF3CR_ADATSZ(q->devtype_data->ahb_buf_size / 8),
base + QUADSPI_BUF3CR);
+ /*
+* In HW there can be a maximum of four chips on two buses with
+* two chip selects on each bus. We use four chip selects in SW
+* to differentiate between the four chips.
+* We use the SFA1AD, SFA2AD, SFB1AD, SFB2AD registers to select
+* the chip we want to access.
+*/
+
+ qspi_writel(q, q->devtype_data->ahb_buf_size, base + QUADSPI_SFA1AD);
+ qspi_writel(q, q->devtype_data->ahb_buf_size * 2 , base +
QUADSPI_SFA2AD);
+ qspi_writel(q, q->devtype_data->ahb_buf_size * 3 , base +
QUADSPI_SFB1AD);
+ qspi_writel(q, q->devtype_data->ahb_buf_size * 4 , base +
QUADSPI_SFB2AD);
+
q->selected = -1;
--
Regards
Yogesh Gaur
[..]
Re: [PATCH 1/2] clocksource: meson6_timer: use register names from the datasheet
Hi Daniel,
thanks for your feedback!
On Thu, Nov 15, 2018 at 2:35 AM Daniel Lezcano
wrote:
>
> On 28/10/2018 13:55, Martin Blumenstingl wrote:
> > This makes the driver use the names from S805 datasheet for the
> > preprocessor #defines. This makes it easier to spot that the driver
> > currently only supports Timer A (as clockevent with interrupt support)
> > and Timer E (as clocksource without interrupts). Timer B, C and D (which
> > are similar to Timer A) are currently not supported by the driver.
> >
> > While here, this also removes the internal "CED_ID" and "CSD_ID" defines
> > which are used to identify the timer. These IDs are not described in the
> > datasheet and thus make it harder to compare the code to what's written
> > in the datasheet.
> >
> > Signed-off-by: Martin Blumenstingl
> > ---
> > drivers/clocksource/meson6_timer.c | 110 ++---
> > 1 file changed, 68 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/clocksource/meson6_timer.c
> > b/drivers/clocksource/meson6_timer.c
> > index 92f20991a937..c622135bee9d 100644
> > --- a/drivers/clocksource/meson6_timer.c
> > +++ b/drivers/clocksource/meson6_timer.c
> > @@ -10,6 +10,8 @@
> > * warranty of any kind, whether express or implied.
> > */
> >
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > @@ -20,80 +22,102 @@
> > #include
> > #include
> >
> > -#define CED_ID 0
> > -#define CSD_ID 4
> > -
> > -#define TIMER_ISA_MUX0
> > -#define TIMER_ISA_VAL(t) (((t) + 1) << 2)
> > -
> > -#define TIMER_INPUT_BIT(t) (2 * (t))
> > -#define TIMER_ENABLE_BIT(t) (16 + (t))
> > -#define TIMER_PERIODIC_BIT(t)(12 + (t))
> > +enum meson6_timera_input_clock {
> > + MESON_TIMERA_CLOCK_1US = 0x0,
> > + MESON_TIMERA_CLOCK_10US = 0x1,
> > + MESON_TIMERA_CLOCK_100US = 0x2,
> > + MESON_TIMERA_CLOCK_1MS = 0x3,
> > +};
> >
> > -#define TIMER_CED_INPUT_MASK (3UL << TIMER_INPUT_BIT(CED_ID))
> > -#define TIMER_CSD_INPUT_MASK (7UL << TIMER_INPUT_BIT(CSD_ID))
> > +enum meson6_timere_input_clock {
> > + MESON_TIMERE_CLOCK_SYSTEM_CLOCK = 0x0,
> > + MESON_TIMERE_CLOCK_1US = 0x1,
> > + MESON_TIMERE_CLOCK_10US = 0x2,
> > + MESON_TIMERE_CLOCK_100US = 0x3,
> > + MESON_TIMERE_CLOCK_1MS = 0x4,
> > +};
>
> It is not required to specify the values. The standard defines the
> default first value is zero, and each enum has the value which is +1 of
> the previous one.
the idea behind this is: these are values from the datasheet so I
wanted to make them easy to find when comparing the datasheet with the
driver.
I will replace the enums with simple #defines if there are no
objections (that also makes it consistent with the other register
values in the driver).
Regards
Martin
RE: [PATCH v5 3/9] spi: Add a driver for the Freescale/NXP QuadSPI controller
Hi Frieder,
With below patch on top of your v5, Read/Write/Erase on CS1 is working fine for
me.
I have tested with JFFS2 mounting and booting also for both CS0 and CS1.
diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c
index ce45e8e..4467983 100644
--- a/drivers/spi/spi-fsl-qspi.c
+++ b/drivers/spi/spi-fsl-qspi.c
@@ -490,28 +490,10 @@ static void fsl_qspi_select_mem(struct fsl_qspi *q,
struct spi_device *spi)
{
unsigned long rate = spi->max_speed_hz;
int ret, i;
- u32 map_addr;
if (q->selected == spi->chip_select)
return;
- /*
-* In HW there can be a maximum of four chips on two buses with
-* two chip selects on each bus. We use four chip selects in SW
-* to differentiate between the four chips.
-* We use the SFA1AD, SFA2AD, SFB1AD, SFB2AD registers to select
-* the chip we want to access.
-*/
- for (i = 0; i < 4; i++) {
- if (i < spi->chip_select)
- map_addr = q->memmap_phy;
- else
- map_addr = q->memmap_phy +
- 2 * q->devtype_data->ahb_buf_size;
-
- qspi_writel(q, map_addr, q->iobase + QUADSPI_SFA1AD + (i * 4));
- }
-
if (needs_4x_clock(q))
rate *= 4;
@@ -534,7 +516,9 @@ static void fsl_qspi_select_mem(struct fsl_qspi *q, struct
spi_device *spi)
static void fsl_qspi_read_ahb(struct fsl_qspi *q, const struct spi_mem_op *op)
{
- memcpy_fromio(op->data.buf.in, q->ahb_addr, op->data.nbytes);
+ memcpy_fromio(op->data.buf.in,
+ q->ahb_addr + q->selected * q->devtype_data->ahb_buf_size,
+ op->data.nbytes);
}
static void fsl_qspi_fill_txfifo(struct fsl_qspi *q,
@@ -634,7 +618,9 @@ static int fsl_qspi_exec_op(struct spi_mem *mem, const
struct spi_mem_op *op)
fsl_qspi_select_mem(q, mem->spi);
- qspi_writel(q, q->memmap_phy, base + QUADSPI_SFAR);
+ qspi_writel(q,
+ q->selected * q->devtype_data->ahb_buf_size,
+ base + QUADSPI_SFAR);
qspi_writel(q, qspi_readl(q, base + QUADSPI_MCR) |
QUADSPI_MCR_CLR_RXF_MASK | QUADSPI_MCR_CLR_TXF_MASK,
@@ -733,6 +719,19 @@ static int fsl_qspi_default_setup(struct fsl_qspi *q)
QUADSPI_BUF3CR_ADATSZ(q->devtype_data->ahb_buf_size / 8),
base + QUADSPI_BUF3CR);
+ /*
+* In HW there can be a maximum of four chips on two buses with
+* two chip selects on each bus. We use four chip selects in SW
+* to differentiate between the four chips.
+* We use the SFA1AD, SFA2AD, SFB1AD, SFB2AD registers to select
+* the chip we want to access.
+*/
+
+ qspi_writel(q, q->devtype_data->ahb_buf_size, base + QUADSPI_SFA1AD);
+ qspi_writel(q, q->devtype_data->ahb_buf_size * 2 , base +
QUADSPI_SFA2AD);
+ qspi_writel(q, q->devtype_data->ahb_buf_size * 3 , base +
QUADSPI_SFB1AD);
+ qspi_writel(q, q->devtype_data->ahb_buf_size * 4 , base +
QUADSPI_SFB2AD);
+
q->selected = -1;
--
Regards
Yogesh Gaur
[..]
[PATCH v3 2/2] proc: add /proc//arch_state
Add a /proc//arch_state interface to expose per-task cpu specific
state values.
Exposing AVX-512 Hi16_ZMM registers usage is for the user space job
scheduler to cluster AVX-512 using tasks together, because these tasks
could cause core turbo frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 16
fs/proc/base.c | 13 +
2 files changed, 29 insertions(+)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 87a57b7..10224ee 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1245,3 +1246,18 @@ int copy_user_to_xstate(struct xregs_state *xsave, const
void __user *ubuf)
return 0;
}
+
+/*
+ * report CPU specific thread state
+ */
+void arch_thread_state(struct seq_file *m, struct task_struct *task)
+{
+ /*
+* Report AVX-512 Hi16_ZMM registers usage
+*/
+ if (task->thread.fpu.hi16zmm_usage)
+ seq_putc(m, '1');
+ else
+ seq_putc(m, '0');
+ seq_putc(m, '\n');
+}
diff --git a/fs/proc/base.c b/fs/proc/base.c
index aaffc0c..efd51ec 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2893,6 +2893,17 @@ static int proc_pid_patch_state(struct seq_file *m,
struct pid_namespace *ns,
}
#endif /* CONFIG_LIVEPATCH */
+void __weak arch_thread_state(struct seq_file *m, struct task_struct *task)
+{
+}
+
+static int proc_pid_arch_state(struct seq_file *m, struct pid_namespace *ns,
+struct pid *pid, struct task_struct *task)
+{
+ arch_thread_state(m, task);
+ return 0;
+}
+
/*
* Thread groups
*/
@@ -2994,6 +3005,7 @@ static const struct pid_entry tgid_base_stuff[] = {
#ifdef CONFIG_LIVEPATCH
ONE("patch_state", S_IRUSR, proc_pid_patch_state),
#endif
+ ONE("arch_state", S_IRUSR, proc_pid_arch_state),
};
static int proc_tgid_base_readdir(struct file *file, struct dir_context *ctx)
@@ -3372,6 +3384,7 @@ static const struct pid_entry tid_base_stuff[] = {
#ifdef CONFIG_LIVEPATCH
ONE("patch_state", S_IRUSR, proc_pid_patch_state),
#endif
+ ONE("arch_state", S_IRUSR, proc_pid_arch_state),
};
static int proc_tid_base_readdir(struct file *file, struct dir_context *ctx)
--
2.7.4
[PATCH v3 1/2] x86/fpu: track AVX-512 usage of tasks
User space tools which do automated task placement need information
about AVX-512 usage of tasks, because AVX-512 usage could cause core
turbo frequency drop and impact the running task on the sibling CPU.
XSAVE header contains a state-component bitmap, which allows software
to discover the state of the init optimization used by XSAVEOPT and
XSAVES. Set bits in the bitmap denotes the usage of the components.
AVX-512 component has 3 states, only Hi16_ZMM state causes notable
frequency drop. Add per task Hi16_ZMM state tracking to context switch.
The tracking turns on the usage flag immediately, but requires 3
consecutive context switches with no usage to clear it. This decay is
required because of AVX-512 using tasks could set Hi16_ZMM state back
to the init state themselves.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 26 ++
arch/x86/include/asm/fpu/types.h| 9 +
2 files changed, 35 insertions(+)
diff --git a/arch/x86/include/asm/fpu/internal.h
b/arch/x86/include/asm/fpu/internal.h
index a38bf5a..f382449 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -275,6 +275,31 @@ static inline void copy_fxregs_to_kernel(struct fpu *fpu)
: "D" (st), "m" (*st), "a" (lmask), "d" (hmask)\
: "memory")
+#defineHI16ZMM_STATE_DECAY_COUNT 3
+/*
+ * This function is called during context switch to update Hi16_ZMM state
+ */
+static inline void update_hi16zmm_state(struct fpu *fpu)
+{
+ /*
+* XSAVE header contains a state-component bitmap(xfeatures),
+* which allows software to discover the state of the init
+* optimization used by XSAVEOPT and XSAVES.
+*
+* Hi16_ZMM state(one state of AVX-512 component) is tracked here
+* because its usage could cause notable core turbo frequency drop.
+*
+* AVX512-using tasks could set Hi16_ZMM state back to the init
+* state themselves. Thus, this tracking mechanism can miss.
+* The decay usage ensures that false-negatives do not immediately
+* make a task be considered as not using Hi16_ZMM registers.
+*/
+ if (fpu->state.xsave.header.xfeatures & XFEATURE_MASK_Hi16_ZMM)
+ fpu->hi16zmm_usage = HI16ZMM_STATE_DECAY_COUNT;
+ else if (fpu->hi16zmm_usage)
+ fpu->hi16zmm_usage--;
+}
+
/*
* This function is called only during boot time when x86 caps are not set
* up and alternative can not be used yet.
@@ -411,6 +436,7 @@ static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
{
if (likely(use_xsave())) {
copy_xregs_to_kernel(>state.xsave);
+ update_hi16zmm_state(fpu);
return 1;
}
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 202c539..c0c7577 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -303,6 +303,15 @@ struct fpu {
unsigned char initialized;
/*
+* @hi16zmm_usage:
+*
+* Records the usage of the upper 16 AVX512 registers: ZMM16-ZMM31.
+* A value of non-zero is used to indicate whether there is valid
+* state in these AVX512 registers.
+*/
+ unsigned char hi16zmm_usage;
+
+ /*
* @state:
*
* In-memory copy of all FPU registers that we save/restore
--
2.7.4
[PATCH v3 1/2] x86/fpu: track AVX-512 usage of tasks
User space tools which do automated task placement need information
about AVX-512 usage of tasks, because AVX-512 usage could cause core
turbo frequency drop and impact the running task on the sibling CPU.
XSAVE header contains a state-component bitmap, which allows software
to discover the state of the init optimization used by XSAVEOPT and
XSAVES. Set bits in the bitmap denotes the usage of the components.
AVX-512 component has 3 states, only Hi16_ZMM state causes notable
frequency drop. Add per task Hi16_ZMM state tracking to context switch.
The tracking turns on the usage flag immediately, but requires 3
consecutive context switches with no usage to clear it. This decay is
required because of AVX-512 using tasks could set Hi16_ZMM state back
to the init state themselves.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 26 ++
arch/x86/include/asm/fpu/types.h| 9 +
2 files changed, 35 insertions(+)
diff --git a/arch/x86/include/asm/fpu/internal.h
b/arch/x86/include/asm/fpu/internal.h
index a38bf5a..f382449 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -275,6 +275,31 @@ static inline void copy_fxregs_to_kernel(struct fpu *fpu)
: "D" (st), "m" (*st), "a" (lmask), "d" (hmask)\
: "memory")
+#defineHI16ZMM_STATE_DECAY_COUNT 3
+/*
+ * This function is called during context switch to update Hi16_ZMM state
+ */
+static inline void update_hi16zmm_state(struct fpu *fpu)
+{
+ /*
+* XSAVE header contains a state-component bitmap(xfeatures),
+* which allows software to discover the state of the init
+* optimization used by XSAVEOPT and XSAVES.
+*
+* Hi16_ZMM state(one state of AVX-512 component) is tracked here
+* because its usage could cause notable core turbo frequency drop.
+*
+* AVX512-using tasks could set Hi16_ZMM state back to the init
+* state themselves. Thus, this tracking mechanism can miss.
+* The decay usage ensures that false-negatives do not immediately
+* make a task be considered as not using Hi16_ZMM registers.
+*/
+ if (fpu->state.xsave.header.xfeatures & XFEATURE_MASK_Hi16_ZMM)
+ fpu->hi16zmm_usage = HI16ZMM_STATE_DECAY_COUNT;
+ else if (fpu->hi16zmm_usage)
+ fpu->hi16zmm_usage--;
+}
+
/*
* This function is called only during boot time when x86 caps are not set
* up and alternative can not be used yet.
@@ -411,6 +436,7 @@ static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
{
if (likely(use_xsave())) {
copy_xregs_to_kernel(>state.xsave);
+ update_hi16zmm_state(fpu);
return 1;
}
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 202c539..c0c7577 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -303,6 +303,15 @@ struct fpu {
unsigned char initialized;
/*
+* @hi16zmm_usage:
+*
+* Records the usage of the upper 16 AVX512 registers: ZMM16-ZMM31.
+* A value of non-zero is used to indicate whether there is valid
+* state in these AVX512 registers.
+*/
+ unsigned char hi16zmm_usage;
+
+ /*
* @state:
*
* In-memory copy of all FPU registers that we save/restore
--
2.7.4
[PATCH v3 2/2] proc: add /proc//arch_state
Add a /proc//arch_state interface to expose per-task cpu specific
state values.
Exposing AVX-512 Hi16_ZMM registers usage is for the user space job
scheduler to cluster AVX-512 using tasks together, because these tasks
could cause core turbo frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 16
fs/proc/base.c | 13 +
2 files changed, 29 insertions(+)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 87a57b7..10224ee 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1245,3 +1246,18 @@ int copy_user_to_xstate(struct xregs_state *xsave, const
void __user *ubuf)
return 0;
}
+
+/*
+ * report CPU specific thread state
+ */
+void arch_thread_state(struct seq_file *m, struct task_struct *task)
+{
+ /*
+* Report AVX-512 Hi16_ZMM registers usage
+*/
+ if (task->thread.fpu.hi16zmm_usage)
+ seq_putc(m, '1');
+ else
+ seq_putc(m, '0');
+ seq_putc(m, '\n');
+}
diff --git a/fs/proc/base.c b/fs/proc/base.c
index aaffc0c..efd51ec 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2893,6 +2893,17 @@ static int proc_pid_patch_state(struct seq_file *m,
struct pid_namespace *ns,
}
#endif /* CONFIG_LIVEPATCH */
+void __weak arch_thread_state(struct seq_file *m, struct task_struct *task)
+{
+}
+
+static int proc_pid_arch_state(struct seq_file *m, struct pid_namespace *ns,
+struct pid *pid, struct task_struct *task)
+{
+ arch_thread_state(m, task);
+ return 0;
+}
+
/*
* Thread groups
*/
@@ -2994,6 +3005,7 @@ static const struct pid_entry tgid_base_stuff[] = {
#ifdef CONFIG_LIVEPATCH
ONE("patch_state", S_IRUSR, proc_pid_patch_state),
#endif
+ ONE("arch_state", S_IRUSR, proc_pid_arch_state),
};
static int proc_tgid_base_readdir(struct file *file, struct dir_context *ctx)
@@ -3372,6 +3384,7 @@ static const struct pid_entry tid_base_stuff[] = {
#ifdef CONFIG_LIVEPATCH
ONE("patch_state", S_IRUSR, proc_pid_patch_state),
#endif
+ ONE("arch_state", S_IRUSR, proc_pid_arch_state),
};
static int proc_tid_base_readdir(struct file *file, struct dir_context *ctx)
--
2.7.4
Re: [PATCH 0/5] Switchtec MRPC DMA mode support
On 15/11/18 02:43 AM, Wesley Sheng wrote: > Hi, Everyone, > > This patch series adds support for the Switchtec MRPC DMA mode. I've reviewed this series from it's conception on github[1] and would like to see it land in the upstream driver, so for the entire series: Reviewed-by: Logan Gunthorpe Thanks, Logan [1] https://github.com/Microsemi/switchtec-kernel
Re: [PATCH 0/5] Switchtec MRPC DMA mode support
On 15/11/18 02:43 AM, Wesley Sheng wrote: > Hi, Everyone, > > This patch series adds support for the Switchtec MRPC DMA mode. I've reviewed this series from it's conception on github[1] and would like to see it land in the upstream driver, so for the entire series: Reviewed-by: Logan Gunthorpe Thanks, Logan [1] https://github.com/Microsemi/switchtec-kernel
Re: [PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook
On Wed, Nov 7, 2018 at 11:30 PM Chen-Yu Tsai wrote:
> > +
> > + speaker_amp: speaker_amp {
> > + compatible = "simple-audio-amplifier";
> > + enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
>
> You might want to add a sound-name-prefix property. See
>
> Documentation/devicetree/bindings/sound/name-prefix.txt
>
> Also this should have a reference to its power supply regulator.
You're right, it should reference its power supply which should be a
fixed regulator controlled via GPIO from AXP803.
Unfortunately there's no AXP803 GPIO support yet and
simple-audio-amplifier doesn't have regulator property.
I have no time (and interest) to work on it in near future, so if
anyone wants to pick it up - feel free to do so.
Regards,
Vasily
Re: [PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook
On Wed, Nov 7, 2018 at 11:30 PM Chen-Yu Tsai wrote:
> > +
> > + speaker_amp: speaker_amp {
> > + compatible = "simple-audio-amplifier";
> > + enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
>
> You might want to add a sound-name-prefix property. See
>
> Documentation/devicetree/bindings/sound/name-prefix.txt
>
> Also this should have a reference to its power supply regulator.
You're right, it should reference its power supply which should be a
fixed regulator controlled via GPIO from AXP803.
Unfortunately there's no AXP803 GPIO support yet and
simple-audio-amplifier doesn't have regulator property.
I have no time (and interest) to work on it in near future, so if
anyone wants to pick it up - feel free to do so.
Regards,
Vasily
Re: [PATCH] serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250
On Wed, Nov 14, 2018 at 07:56:47PM -0800, Florian Fainelli wrote: > > > On November 14, 2018 5:11:25 PM PST, Guenter Roeck wrote: > >On Thu, Nov 01, 2018 at 11:26:06AM -0700, Florian Fainelli wrote: > >> It is way too easy to miss enabling SERIAL_OF_PLATFORM which would > >> result in the inability for the kernel to have a valid console > >device, > >> which can be seen with: > >> > >> Warning: unable to open an initial console. > >> > >> and then: > >> > >> Run /init as init process > >> Kernel panic - not syncing: Attempted to kill init! > >exitcode=0x0100 > >> > >> Since SERIAL_OF_PLATFORM already depends on SERIAL_8250 && OF there > >> really is no drawback to defaulting this config to the value of > >> SERIAL_8250. > >> > >> Signed-off-by: Florian Fainelli > >> Signed-off-by: Greg Kroah-Hartman > > > >This patch results in situations where CONFIG_SERIAL_OF_PLATFORM is now > >defined where it was not previously. Example mpc85xx_defconfig. This in > >turn results in boot failures for those configurations, with an error > >message of > > > >of_serial: probe of e0004500.serial failed with error -22 > > > >which wasn't seen before. > > Do you know which Device Tree is being used here? The most obvious thing that > could be done is to add a !PPC condition but this might be missing other > platforms doing their own 8250 registration yet being OF aware (sparc?). > > > > >Not sure if replacing a potential problem with a real one is really an > >improvement.` > > That comment is not particularly helpful though I have an appreciation for > when a change breaks things in unexpected ways and how frustrating that can > be. Actally, never mind. I dropped the test cases. Sorry for the noise. Guenter
Re: [PATCH] serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250
On Wed, Nov 14, 2018 at 07:56:47PM -0800, Florian Fainelli wrote: > > > On November 14, 2018 5:11:25 PM PST, Guenter Roeck wrote: > >On Thu, Nov 01, 2018 at 11:26:06AM -0700, Florian Fainelli wrote: > >> It is way too easy to miss enabling SERIAL_OF_PLATFORM which would > >> result in the inability for the kernel to have a valid console > >device, > >> which can be seen with: > >> > >> Warning: unable to open an initial console. > >> > >> and then: > >> > >> Run /init as init process > >> Kernel panic - not syncing: Attempted to kill init! > >exitcode=0x0100 > >> > >> Since SERIAL_OF_PLATFORM already depends on SERIAL_8250 && OF there > >> really is no drawback to defaulting this config to the value of > >> SERIAL_8250. > >> > >> Signed-off-by: Florian Fainelli > >> Signed-off-by: Greg Kroah-Hartman > > > >This patch results in situations where CONFIG_SERIAL_OF_PLATFORM is now > >defined where it was not previously. Example mpc85xx_defconfig. This in > >turn results in boot failures for those configurations, with an error > >message of > > > >of_serial: probe of e0004500.serial failed with error -22 > > > >which wasn't seen before. > > Do you know which Device Tree is being used here? The most obvious thing that > could be done is to add a !PPC condition but this might be missing other > platforms doing their own 8250 registration yet being OF aware (sparc?). > > > > >Not sure if replacing a potential problem with a real one is really an > >improvement.` > > That comment is not particularly helpful though I have an appreciation for > when a change breaks things in unexpected ways and how frustrating that can > be. Actally, never mind. I dropped the test cases. Sorry for the noise. Guenter
Re: [PATCH] serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250
On Wed, Nov 14, 2018 at 07:56:47PM -0800, Florian Fainelli wrote: > > > On November 14, 2018 5:11:25 PM PST, Guenter Roeck wrote: > >On Thu, Nov 01, 2018 at 11:26:06AM -0700, Florian Fainelli wrote: > >> It is way too easy to miss enabling SERIAL_OF_PLATFORM which would > >> result in the inability for the kernel to have a valid console > >device, > >> which can be seen with: > >> > >> Warning: unable to open an initial console. > >> > >> and then: > >> > >> Run /init as init process > >> Kernel panic - not syncing: Attempted to kill init! > >exitcode=0x0100 > >> > >> Since SERIAL_OF_PLATFORM already depends on SERIAL_8250 && OF there > >> really is no drawback to defaulting this config to the value of > >> SERIAL_8250. > >> > >> Signed-off-by: Florian Fainelli > >> Signed-off-by: Greg Kroah-Hartman > > > >This patch results in situations where CONFIG_SERIAL_OF_PLATFORM is now > >defined where it was not previously. Example mpc85xx_defconfig. This in > >turn results in boot failures for those configurations, with an error > >message of > > > >of_serial: probe of e0004500.serial failed with error -22 > > > >which wasn't seen before. > > Do you know which Device Tree is being used here? The most obvious thing that > could be done is to add a !PPC condition but this might be missing other > platforms doing their own 8250 registration yet being OF aware (sparc?). This is a qemu boot test. No, I don't know what exactly is happening, except that this (emulated) system obviously does not expect CONFIG_SERIAL_OF_PLATFORM to be enabled and, afaik, the devicetree is generated internally by qemu. I would have thought that just enabling a configuration by default out of the blue might be considered problematic by itself, but maybe I am wrong. > > > > >Not sure if replacing a potential problem with a real one is really an > >improvement.` > > That comment is not particularly helpful though I have an appreciation for > when a change breaks things in unexpected ways and how frustrating that can > be. What is really frustrating (and let me think about dropping all those boot tests) is that one ends up having to argue if the problem is real or only applies to a presumably or possibly wrong qemu emulation, and that one ends up having to discuss the validity of the test case. Since this is "only" an emulation and thus not a "real" system, please feel free to ignore this report. I'll just drop all boot tests using this configuration once the patch hits mainline. Guenter
Re: [PATCH] serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250
On Wed, Nov 14, 2018 at 07:56:47PM -0800, Florian Fainelli wrote: > > > On November 14, 2018 5:11:25 PM PST, Guenter Roeck wrote: > >On Thu, Nov 01, 2018 at 11:26:06AM -0700, Florian Fainelli wrote: > >> It is way too easy to miss enabling SERIAL_OF_PLATFORM which would > >> result in the inability for the kernel to have a valid console > >device, > >> which can be seen with: > >> > >> Warning: unable to open an initial console. > >> > >> and then: > >> > >> Run /init as init process > >> Kernel panic - not syncing: Attempted to kill init! > >exitcode=0x0100 > >> > >> Since SERIAL_OF_PLATFORM already depends on SERIAL_8250 && OF there > >> really is no drawback to defaulting this config to the value of > >> SERIAL_8250. > >> > >> Signed-off-by: Florian Fainelli > >> Signed-off-by: Greg Kroah-Hartman > > > >This patch results in situations where CONFIG_SERIAL_OF_PLATFORM is now > >defined where it was not previously. Example mpc85xx_defconfig. This in > >turn results in boot failures for those configurations, with an error > >message of > > > >of_serial: probe of e0004500.serial failed with error -22 > > > >which wasn't seen before. > > Do you know which Device Tree is being used here? The most obvious thing that > could be done is to add a !PPC condition but this might be missing other > platforms doing their own 8250 registration yet being OF aware (sparc?). This is a qemu boot test. No, I don't know what exactly is happening, except that this (emulated) system obviously does not expect CONFIG_SERIAL_OF_PLATFORM to be enabled and, afaik, the devicetree is generated internally by qemu. I would have thought that just enabling a configuration by default out of the blue might be considered problematic by itself, but maybe I am wrong. > > > > >Not sure if replacing a potential problem with a real one is really an > >improvement.` > > That comment is not particularly helpful though I have an appreciation for > when a change breaks things in unexpected ways and how frustrating that can > be. What is really frustrating (and let me think about dropping all those boot tests) is that one ends up having to argue if the problem is real or only applies to a presumably or possibly wrong qemu emulation, and that one ends up having to discuss the validity of the test case. Since this is "only" an emulation and thus not a "real" system, please feel free to ignore this report. I'll just drop all boot tests using this configuration once the patch hits mainline. Guenter
Re: Official Linux system wrapper library?
On Wed, Nov 14, 2018 at 06:47:57PM +, Joseph Myers wrote: > On Wed, 14 Nov 2018, Daniel Colascione wrote: > > > A good demonstration of a new commitment to pragmatism would be > > merging the trivial wrappers for gettid(2). > > I support the addition of gettid (for use with those syscalls that take > tids, and with appropriate documentation explaining the properties of > tids) - and, generally, wrappers for all non-obsolescent > architecture-independent Linux kernel syscalls, including ones that are > very Linux-specific, except maybe for a few interfaces fundamentally > inconsistent with glibc managing TLS etc. - they are, at least, no worse > as a source of APIs than all the old BSD / SVID interfaces we have from > when those were used as sources of APIs. That's great. But is it or is it not true (either de jure or de facto) that "a single active glibc developer" can block a system call from being supported by glibc by objecting? And if not, under what is the process by resolving a conflict? - Ted
Re: Official Linux system wrapper library?
On Wed, Nov 14, 2018 at 06:47:57PM +, Joseph Myers wrote: > On Wed, 14 Nov 2018, Daniel Colascione wrote: > > > A good demonstration of a new commitment to pragmatism would be > > merging the trivial wrappers for gettid(2). > > I support the addition of gettid (for use with those syscalls that take > tids, and with appropriate documentation explaining the properties of > tids) - and, generally, wrappers for all non-obsolescent > architecture-independent Linux kernel syscalls, including ones that are > very Linux-specific, except maybe for a few interfaces fundamentally > inconsistent with glibc managing TLS etc. - they are, at least, no worse > as a source of APIs than all the old BSD / SVID interfaces we have from > when those were used as sources of APIs. That's great. But is it or is it not true (either de jure or de facto) that "a single active glibc developer" can block a system call from being supported by glibc by objecting? And if not, under what is the process by resolving a conflict? - Ted
Re: Memory hotplug softlock issue
On 11/14/18 at 04:00pm, Michal Hocko wrote: > On Wed 14-11-18 22:52:50, Baoquan He wrote: > > On 11/14/18 at 10:01am, Michal Hocko wrote: > > > I have seen an issue when the migration cannot make a forward progress > > > because of a glibc page with a reference count bumping up and down. Most > > > probable explanation is the faultaround code. I am working on this and > > > will post a patch soon. In any case the migration should converge and if > > > it doesn't do then there is a bug lurking somewhere. > > > > > > Failing on ENOMEM is a questionable thing. I haven't seen that happening > > > wildly but if it is a case then I wouldn't be opposed. > > > > Applied your debugging patches, it helps a lot to printing message. > > > > Below is the dmesg log about the migrating failure. It can't pass > > migrate_pages() and loop forever. > > > > [ +0.083841] migrating pfn 10fff7d0 failed > > [ +0.05] page:ea043ffdf400 count:208 mapcount:201 > > mapping:888dff4bdda8 index:0x2 > > [ +0.012689] xfs_address_space_operations [xfs] > > [ +0.30] name:"stress" > > [ +0.004556] flags: 0x5fc004(uptodate) > > [ +0.007339] raw: 005fc004 c90e3d80 c90e3d80 > > 888dff4bdda8 > > [ +0.009488] raw: 0002 00cb00c8 > > 888e7353d000 > > [ +0.007726] page->mem_cgroup:888e7353d000 > > [ +0.084538] migrating pfn 10fff7d0 failed > > [ +0.06] page:ea043ffdf400 count:210 mapcount:201 > > mapping:888dff4bdda8 index:0x2 > > [ +0.012798] xfs_address_space_operations [xfs] > > [ +0.34] name:"stress" > > [ +0.004524] flags: 0x5fc004(uptodate) > > [ +0.007068] raw: 005fc004 c90e3d80 c90e3d80 > > 888dff4bdda8 > > [ +0.009359] raw: 0002 00cb00c8 > > 888e7353d000 > > [ +0.007728] page->mem_cgroup:888e7353d000 > > I wouldn't be surprised if this was a similar/same issue I've been > chasing recently. Could you try to disable faultaround to see if that > helps. It seems that it helped in my particular case but I am still > waiting for the final good-to-go to post the patch as I do not own the > workload which triggered that issue. Tried, still stuck in last block sometime. Usually after several times of hotplug/unplug. If stop stress program, the last block will be offlined immediately. [root@ ~]# cat /sys/kernel/debug/fault_around_bytes 4096
Re: Memory hotplug softlock issue
On 11/14/18 at 04:00pm, Michal Hocko wrote: > On Wed 14-11-18 22:52:50, Baoquan He wrote: > > On 11/14/18 at 10:01am, Michal Hocko wrote: > > > I have seen an issue when the migration cannot make a forward progress > > > because of a glibc page with a reference count bumping up and down. Most > > > probable explanation is the faultaround code. I am working on this and > > > will post a patch soon. In any case the migration should converge and if > > > it doesn't do then there is a bug lurking somewhere. > > > > > > Failing on ENOMEM is a questionable thing. I haven't seen that happening > > > wildly but if it is a case then I wouldn't be opposed. > > > > Applied your debugging patches, it helps a lot to printing message. > > > > Below is the dmesg log about the migrating failure. It can't pass > > migrate_pages() and loop forever. > > > > [ +0.083841] migrating pfn 10fff7d0 failed > > [ +0.05] page:ea043ffdf400 count:208 mapcount:201 > > mapping:888dff4bdda8 index:0x2 > > [ +0.012689] xfs_address_space_operations [xfs] > > [ +0.30] name:"stress" > > [ +0.004556] flags: 0x5fc004(uptodate) > > [ +0.007339] raw: 005fc004 c90e3d80 c90e3d80 > > 888dff4bdda8 > > [ +0.009488] raw: 0002 00cb00c8 > > 888e7353d000 > > [ +0.007726] page->mem_cgroup:888e7353d000 > > [ +0.084538] migrating pfn 10fff7d0 failed > > [ +0.06] page:ea043ffdf400 count:210 mapcount:201 > > mapping:888dff4bdda8 index:0x2 > > [ +0.012798] xfs_address_space_operations [xfs] > > [ +0.34] name:"stress" > > [ +0.004524] flags: 0x5fc004(uptodate) > > [ +0.007068] raw: 005fc004 c90e3d80 c90e3d80 > > 888dff4bdda8 > > [ +0.009359] raw: 0002 00cb00c8 > > 888e7353d000 > > [ +0.007728] page->mem_cgroup:888e7353d000 > > I wouldn't be surprised if this was a similar/same issue I've been > chasing recently. Could you try to disable faultaround to see if that > helps. It seems that it helped in my particular case but I am still > waiting for the final good-to-go to post the patch as I do not own the > workload which triggered that issue. Tried, still stuck in last block sometime. Usually after several times of hotplug/unplug. If stop stress program, the last block will be offlined immediately. [root@ ~]# cat /sys/kernel/debug/fault_around_bytes 4096
[PATCH v2] mtd: change len type from signed to unsigned type
From: "huijin.park"
This patch casts the "len" parameter to an unsigned int.
The callers of erase_write() pass the "len" parameter as unsigned int.
Signed-off-by: huijin.park
---
drivers/mtd/mtdblock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
index a5b1933..b2d5ed1 100644
--- a/drivers/mtd/mtdblock.c
+++ b/drivers/mtd/mtdblock.c
@@ -56,7 +56,7 @@ struct mtdblk_dev {
*/
static int erase_write (struct mtd_info *mtd, unsigned long pos,
- int len, const char *buf)
+ unsigned int len, const char *buf)
{
struct erase_info erase;
size_t retlen;
--
1.7.9.5
[PATCH v2] mtd: change len type from signed to unsigned type
From: "huijin.park"
This patch casts the "len" parameter to an unsigned int.
The callers of erase_write() pass the "len" parameter as unsigned int.
Signed-off-by: huijin.park
---
drivers/mtd/mtdblock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
index a5b1933..b2d5ed1 100644
--- a/drivers/mtd/mtdblock.c
+++ b/drivers/mtd/mtdblock.c
@@ -56,7 +56,7 @@ struct mtdblk_dev {
*/
static int erase_write (struct mtd_info *mtd, unsigned long pos,
- int len, const char *buf)
+ unsigned int len, const char *buf)
{
struct erase_info erase;
size_t retlen;
--
1.7.9.5
[PATCH v2] mtd: spi-nor: cast to u64 to avoid uint overflows
From: "huijin.park" The "params->size" is defined as "u64". And "info->sector_size" and "info->n_sectors" are defined as unsigned int and u16. Thus, u64 data might have strange data(loss data) if the result overflows an unsigned int. This patch casts "info->sector_size" and "info->n_sectors" to an u64. Signed-off-by: huijin.park --- drivers/mtd/spi-nor/spi-nor.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index d9c368c..527f281 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -2459,7 +2459,7 @@ static int spi_nor_init_params(struct spi_nor *nor, memset(params, 0, sizeof(*params)); /* Set SPI NOR sizes. */ - params->size = info->sector_size * info->n_sectors; + params->size = (u64)info->sector_size * (u64)info->n_sectors; params->page_size = info->page_size; /* (Fast) Read settings. */ -- 1.7.9.5
[PATCH v2] mtd: spi-nor: cast to u64 to avoid uint overflows
From: "huijin.park" The "params->size" is defined as "u64". And "info->sector_size" and "info->n_sectors" are defined as unsigned int and u16. Thus, u64 data might have strange data(loss data) if the result overflows an unsigned int. This patch casts "info->sector_size" and "info->n_sectors" to an u64. Signed-off-by: huijin.park --- drivers/mtd/spi-nor/spi-nor.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index d9c368c..527f281 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -2459,7 +2459,7 @@ static int spi_nor_init_params(struct spi_nor *nor, memset(params, 0, sizeof(*params)); /* Set SPI NOR sizes. */ - params->size = info->sector_size * info->n_sectors; + params->size = (u64)info->sector_size * (u64)info->n_sectors; params->page_size = info->page_size; /* (Fast) Read settings. */ -- 1.7.9.5
linux-next: Tree for Nov 15
Hi all, Changes since 20181114: New trees: gnss-fixes, gnss The tip tree still had its build failure for which I applied a fix patch. Non-merge commits (relative to Linus' tree): 2799 2907 files changed, 117529 insertions(+), 99581 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 298 trees (counting Linus' and 68 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (3472f66013d1 Merge tag 'acpi-4.20-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux) Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2) Merging arc-current/for-curr (121e38e5acdc ARC: mm: fix uninitialised signal code in do_page_fault) Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE) Merging arm64-fixes/for-next/fixes (24cc61d8cb5a arm64: memblock: don't permit memblock resizing until linear mapping is up) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (2c7645b0f7d1 selftests/powerpc: Fix wild_bctr test to work on ppc64) Merging sparc/master (1f2b5b8e2df4 sparc64: Wire up compat getpeername and getsockname.) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (db8ddde766ad Merge branch 'qed-Miscellaneous-bug-fixes') Merging bpf/master (da85d8bfd151 kselftests/bpf: use ping6 as the default ipv6 ping binary when it exists) Merging ipsec/master (ca92e173ab34 xfrm: Fix bucket count reported to userspace) Merging netfilter/master (29e3880109e3 netfilter: nf_tables: fix use-after-free when deleting compat expressions) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (b374e8686fc3 mt76: fix building without CONFIG_LEDS_CLASS) Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore during STA disconnect in concurrent interfaces) Merging rdma-fixes/for-rc (99b77fef3c6c net/mlx5: Fix XRC SRQ umem valid bits) Merging sound-current/for-linus (d99501b8575d ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()) Merging sound-asoc-fixes/for-linus (95026e01c800 Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8) Merging regulator-fixes/for-linus (2f729bc9888b Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (f8303a12bb45 Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (1a87119b7bcf Revert "ACPI/PCI: Pay attention to device-specific _PXM node values") Merging driver-core.current/driver-core-linus (a66d972465d1 devres: Align data[] to ARCH_KMALLOC_MINALIGN) Merging tty.current/tty-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging usb.current/usb-linus (11644a765952 xhci: Add quirk to workaround the errata seen on Cavium Thunder-X2 Soc) Merging usb-gadget-fixes/fixes (2fc6d4be35fb usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers) Merging usb-serial-fixes/usb-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always buil
linux-next: Tree for Nov 15
Hi all, Changes since 20181114: New trees: gnss-fixes, gnss The tip tree still had its build failure for which I applied a fix patch. Non-merge commits (relative to Linus' tree): 2799 2907 files changed, 117529 insertions(+), 99581 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 298 trees (counting Linus' and 68 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (3472f66013d1 Merge tag 'acpi-4.20-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux) Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2) Merging arc-current/for-curr (121e38e5acdc ARC: mm: fix uninitialised signal code in do_page_fault) Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE) Merging arm64-fixes/for-next/fixes (24cc61d8cb5a arm64: memblock: don't permit memblock resizing until linear mapping is up) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (2c7645b0f7d1 selftests/powerpc: Fix wild_bctr test to work on ppc64) Merging sparc/master (1f2b5b8e2df4 sparc64: Wire up compat getpeername and getsockname.) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (db8ddde766ad Merge branch 'qed-Miscellaneous-bug-fixes') Merging bpf/master (da85d8bfd151 kselftests/bpf: use ping6 as the default ipv6 ping binary when it exists) Merging ipsec/master (ca92e173ab34 xfrm: Fix bucket count reported to userspace) Merging netfilter/master (29e3880109e3 netfilter: nf_tables: fix use-after-free when deleting compat expressions) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (b374e8686fc3 mt76: fix building without CONFIG_LEDS_CLASS) Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore during STA disconnect in concurrent interfaces) Merging rdma-fixes/for-rc (99b77fef3c6c net/mlx5: Fix XRC SRQ umem valid bits) Merging sound-current/for-linus (d99501b8575d ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()) Merging sound-asoc-fixes/for-linus (95026e01c800 Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8) Merging regulator-fixes/for-linus (2f729bc9888b Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (f8303a12bb45 Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (1a87119b7bcf Revert "ACPI/PCI: Pay attention to device-specific _PXM node values") Merging driver-core.current/driver-core-linus (a66d972465d1 devres: Align data[] to ARCH_KMALLOC_MINALIGN) Merging tty.current/tty-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging usb.current/usb-linus (11644a765952 xhci: Add quirk to workaround the errata seen on Cavium Thunder-X2 Soc) Merging usb-gadget-fixes/fixes (2fc6d4be35fb usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers) Merging usb-serial-fixes/usb-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always buil
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
On Thu, 15 Nov 2018, Michael Schmitz wrote: > Hi Finn, > > On 14/11/18 3:58 PM, Michael Schmitz wrote: > > Hi Finn, > > > > Am 14.11.2018 um 14:08 schrieb Michael Schmitz: > > > > Can you also test tree fbf8405cd982 please? > > > > > > > My tests were on c606b5cf902 in case it wasn't clear. I've now seen > > > fbf8405cd982, one moment please ... > > > > > > That one does appear to work - different versions of ARAnyM, and > > > different userland versions though. I'll test that again with the setup > > > that saw c606b5cf902 fail. > > > > Still fails on that emulator / userland. > > > Must be a quirk of ARAnyM 1.0.2 (or powerpc). With 0.9.15 on x86_64, it's > fine. > Could be a regression in aranym? Maybe it's worth trying 0.9.15 on the powerpc host? > I'm sufficiently convinced to try this on actual hardware now. > Thanks! -- > Cheers, > > ??? Michael > > >
Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
On Thu, 15 Nov 2018, Michael Schmitz wrote: > Hi Finn, > > On 14/11/18 3:58 PM, Michael Schmitz wrote: > > Hi Finn, > > > > Am 14.11.2018 um 14:08 schrieb Michael Schmitz: > > > > Can you also test tree fbf8405cd982 please? > > > > > > > My tests were on c606b5cf902 in case it wasn't clear. I've now seen > > > fbf8405cd982, one moment please ... > > > > > > That one does appear to work - different versions of ARAnyM, and > > > different userland versions though. I'll test that again with the setup > > > that saw c606b5cf902 fail. > > > > Still fails on that emulator / userland. > > > Must be a quirk of ARAnyM 1.0.2 (or powerpc). With 0.9.15 on x86_64, it's > fine. > Could be a regression in aranym? Maybe it's worth trying 0.9.15 on the powerpc host? > I'm sufficiently convinced to try this on actual hardware now. > Thanks! -- > Cheers, > > ??? Michael > > >
Re: Build regressions/improvements in v4.20-rc2
Geert Uytterhoeven writes:
> Below is the list of build error/warning regressions/improvements in
> v4.20-rc2[1] compared to v4.19[2].
>
> Summarized:
> - build errors: +3/-0
> - build warnings: +123/-12803
>
> JFYI, when comparing v4.20-rc2[1] to v4.20-rc1[3], the summaries are:
> - build errors: +0/-0
> - build warnings: +61/-10479
>
> Happy fixing! ;-)
>
> Thanks to the linux-next team for providing the build service.
>
> [1]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/ccda4af0f4b92f7b4c308d3acc262f4a7e3affad/
> (all 240 configs)
> [2]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d/
> (all 240 configs)
> [3]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/651022382c7f8da46cb4872a545ee1da6d097d2a/
> (all 240 configs)
>
>
> *** ERRORS ***
>
> 3 error regressions:
> + /kisskb/src/arch/s390/kernel/nospec-branch.c: error: macro "memcpy"
> passed 6 arguments, but takes just 3: => 130:61
> + /kisskb/src/sound/pci/hda/patch_ca0132.c: error: implicit declaration of
> function 'pci_iomap' [-Werror=implicit-function-declaration]: => 8799:3
> + {standard input}: Error: Unrecognized opcode: `slbfee.': => 89, 37
I have a fix queued for this one.
cheers
Re: Build regressions/improvements in v4.20-rc2
Geert Uytterhoeven writes:
> Below is the list of build error/warning regressions/improvements in
> v4.20-rc2[1] compared to v4.19[2].
>
> Summarized:
> - build errors: +3/-0
> - build warnings: +123/-12803
>
> JFYI, when comparing v4.20-rc2[1] to v4.20-rc1[3], the summaries are:
> - build errors: +0/-0
> - build warnings: +61/-10479
>
> Happy fixing! ;-)
>
> Thanks to the linux-next team for providing the build service.
>
> [1]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/ccda4af0f4b92f7b4c308d3acc262f4a7e3affad/
> (all 240 configs)
> [2]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d/
> (all 240 configs)
> [3]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/651022382c7f8da46cb4872a545ee1da6d097d2a/
> (all 240 configs)
>
>
> *** ERRORS ***
>
> 3 error regressions:
> + /kisskb/src/arch/s390/kernel/nospec-branch.c: error: macro "memcpy"
> passed 6 arguments, but takes just 3: => 130:61
> + /kisskb/src/sound/pci/hda/patch_ca0132.c: error: implicit declaration of
> function 'pci_iomap' [-Werror=implicit-function-declaration]: => 8799:3
> + {standard input}: Error: Unrecognized opcode: `slbfee.': => 89, 37
I have a fix queued for this one.
cheers
Re: [PATCH AUTOSEL 4.18 39/59] i2c: omap: Enable for ARCH_K3
Hi,
On 15/11/18 3:53 AM, Sasha Levin wrote:
> From: Vignesh R
>
> [ Upstream commit 5b277402deac0691226a947df71c581686bd4020 ]
This patch depends on c77245722fb4 ("arm64: Add support for TI's K3
Multicore SoC architecture") which adds ARCH_K3 Kconfig symbol and
merged to mainline in v4.19. Since I don't see c77245722fb4 in
stable tree, please drop this commit from stable queues prior to v4.19
(4.18, 4.14, 4.9, 4.4 and 3.18).
>
> Allow I2C_OMAP to be built for K3 platforms.
>
> Signed-off-by: Vignesh R
> Reviewed-by: Grygorii Strashko
> Signed-off-by: Wolfram Sang
> Signed-off-by: Sasha Levin
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 4f8df2ec87b1..fb3a3707a66e 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -754,7 +754,7 @@ config I2C_OCORES
>
> config I2C_OMAP
> tristate "OMAP I2C adapter"
> - depends on ARCH_OMAP
> + depends on ARCH_OMAP || ARCH_K3
> default y if MACH_OMAP_H3 || MACH_OMAP_OSK
> help
> If you say yes to this option, support will be included for the
>
--
Regards
Vignesh
Re: [PATCH AUTOSEL 4.18 39/59] i2c: omap: Enable for ARCH_K3
Hi,
On 15/11/18 3:53 AM, Sasha Levin wrote:
> From: Vignesh R
>
> [ Upstream commit 5b277402deac0691226a947df71c581686bd4020 ]
This patch depends on c77245722fb4 ("arm64: Add support for TI's K3
Multicore SoC architecture") which adds ARCH_K3 Kconfig symbol and
merged to mainline in v4.19. Since I don't see c77245722fb4 in
stable tree, please drop this commit from stable queues prior to v4.19
(4.18, 4.14, 4.9, 4.4 and 3.18).
>
> Allow I2C_OMAP to be built for K3 platforms.
>
> Signed-off-by: Vignesh R
> Reviewed-by: Grygorii Strashko
> Signed-off-by: Wolfram Sang
> Signed-off-by: Sasha Levin
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 4f8df2ec87b1..fb3a3707a66e 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -754,7 +754,7 @@ config I2C_OCORES
>
> config I2C_OMAP
> tristate "OMAP I2C adapter"
> - depends on ARCH_OMAP
> + depends on ARCH_OMAP || ARCH_K3
> default y if MACH_OMAP_H3 || MACH_OMAP_OSK
> help
> If you say yes to this option, support will be included for the
>
--
Regards
Vignesh
USLUGI REPETITORA
USLUGI REPETITORA 1-7 klass. Nizkie ceni 7:27:08 AM
USLUGI REPETITORA
USLUGI REPETITORA 1-7 klass. Nizkie ceni 7:27:08 AM
[PATCH 2/2] ASoC: rt5663: Add regulator support
Add regulator support to turn on cpvdd and avdd in probe.
If a regulator is not given from device tree, a dummy regulator will be
used.
Signed-off-by: Cheng-Yi Chiang
---
sound/soc/codecs/rt5663.c | 68 +++
1 file changed, 61 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/rt5663.c b/sound/soc/codecs/rt5663.c
index 2444fad7c2dfe..7e9c1901a0a67 100644
--- a/sound/soc/codecs/rt5663.c
+++ b/sound/soc/codecs/rt5663.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -33,6 +34,9 @@
#define RT5663_DEVICE_ID_2 0x6451
#define RT5663_DEVICE_ID_1 0x6406
+#define RT5663_POWER_ON_DELAY_MS 300
+#define RT5663_SUPPLY_CURRENT_UA 50
+
enum {
CODEC_VER_1,
CODEC_VER_0,
@@ -48,6 +52,11 @@ struct impedance_mapping_table {
unsigned int dc_offset_r_manual_mic;
};
+static const char *const rt5663_supply_names[] = {
+ "avdd",
+ "cpvdd",
+};
+
struct rt5663_priv {
struct snd_soc_component *component;
struct rt5663_platform_data pdata;
@@ -56,6 +65,7 @@ struct rt5663_priv {
struct snd_soc_jack *hs_jack;
struct timer_list btn_check_timer;
struct impedance_mapping_table *imp_table;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(rt5663_supply_names)];
int codec_ver;
int sysclk;
@@ -3480,7 +3490,7 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
{
struct rt5663_platform_data *pdata = dev_get_platdata(>dev);
struct rt5663_priv *rt5663;
- int ret;
+ int ret, i;
unsigned int val;
struct regmap *regmap;
@@ -3497,6 +3507,37 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
else
rt5663_parse_dp(rt5663, >dev);
+ for (i = 0; i < ARRAY_SIZE(rt5663->supplies); i++)
+ rt5663->supplies[i].supply = rt5663_supply_names[i];
+
+ ret = devm_regulator_bulk_get(>dev,
+ ARRAY_SIZE(rt5663->supplies),
+ rt5663->supplies);
+ if (ret) {
+ dev_err(>dev, "Failed to request supplies: %d\n", ret);
+ return ret;
+ }
+
+ /* Set load for regulator. */
+ for (i = 0; i < ARRAY_SIZE(rt5663->supplies); i++) {
+ ret = regulator_set_load(rt5663->supplies[i].consumer,
+RT5663_SUPPLY_CURRENT_UA);
+ if (ret) {
+ dev_err(>dev,
+ "Failed to set regulator %s, ret: %d\n",
+ rt5663->supplies[i].supply, ret);
+ }
+ }
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(rt5663->supplies),
+ rt5663->supplies);
+
+ if (ret) {
+ dev_err(>dev, "Failed to enable supplies: %d\n", ret);
+ return ret;
+ }
+ msleep(RT5663_POWER_ON_DELAY_MS);
+
regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(regmap)) {
ret = PTR_ERR(regmap);
@@ -3527,7 +3568,8 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
dev_err(>dev,
"Device with ID register %#x is not rt5663\n",
val);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_enable;
}
if (IS_ERR(rt5663->regmap)) {
@@ -3632,20 +3674,30 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
ret = request_irq(i2c->irq, rt5663_irq,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
| IRQF_ONESHOT, "rt5663", rt5663);
- if (ret)
+ if (ret) {
dev_err(>dev, "%s Failed to reguest IRQ: %d\n",
__func__, ret);
+ goto err_enable;
+ }
}
ret = devm_snd_soc_register_component(>dev,
_component_dev_rt5663,
rt5663_dai, ARRAY_SIZE(rt5663_dai));
- if (ret) {
- if (i2c->irq)
- free_irq(i2c->irq, rt5663);
- }
+ if (ret)
+ goto err_irq;
+ return 0;
+
+err_irq:
+ if (i2c->irq)
+ free_irq(i2c->irq, rt5663);
+
+err_enable:
+ dev_err(>dev,
+ "%s: Disable regulator after probe error\n", __func__);
+ regulator_bulk_disable(ARRAY_SIZE(rt5663->supplies), rt5663->supplies);
return ret;
}
@@ -3656,6 +3708,8 @@ static int rt5663_i2c_remove(struct i2c_client *i2c)
if (i2c->irq)
free_irq(i2c->irq, rt5663);
+ regulator_bulk_disable(ARRAY_SIZE(rt5663->supplies), rt5663->supplies);
+
return 0;
}
--
2.19.1.930.g4563a0d9d0-goog
[PATCH 2/2] ASoC: rt5663: Add regulator support
Add regulator support to turn on cpvdd and avdd in probe.
If a regulator is not given from device tree, a dummy regulator will be
used.
Signed-off-by: Cheng-Yi Chiang
---
sound/soc/codecs/rt5663.c | 68 +++
1 file changed, 61 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/rt5663.c b/sound/soc/codecs/rt5663.c
index 2444fad7c2dfe..7e9c1901a0a67 100644
--- a/sound/soc/codecs/rt5663.c
+++ b/sound/soc/codecs/rt5663.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -33,6 +34,9 @@
#define RT5663_DEVICE_ID_2 0x6451
#define RT5663_DEVICE_ID_1 0x6406
+#define RT5663_POWER_ON_DELAY_MS 300
+#define RT5663_SUPPLY_CURRENT_UA 50
+
enum {
CODEC_VER_1,
CODEC_VER_0,
@@ -48,6 +52,11 @@ struct impedance_mapping_table {
unsigned int dc_offset_r_manual_mic;
};
+static const char *const rt5663_supply_names[] = {
+ "avdd",
+ "cpvdd",
+};
+
struct rt5663_priv {
struct snd_soc_component *component;
struct rt5663_platform_data pdata;
@@ -56,6 +65,7 @@ struct rt5663_priv {
struct snd_soc_jack *hs_jack;
struct timer_list btn_check_timer;
struct impedance_mapping_table *imp_table;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(rt5663_supply_names)];
int codec_ver;
int sysclk;
@@ -3480,7 +3490,7 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
{
struct rt5663_platform_data *pdata = dev_get_platdata(>dev);
struct rt5663_priv *rt5663;
- int ret;
+ int ret, i;
unsigned int val;
struct regmap *regmap;
@@ -3497,6 +3507,37 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
else
rt5663_parse_dp(rt5663, >dev);
+ for (i = 0; i < ARRAY_SIZE(rt5663->supplies); i++)
+ rt5663->supplies[i].supply = rt5663_supply_names[i];
+
+ ret = devm_regulator_bulk_get(>dev,
+ ARRAY_SIZE(rt5663->supplies),
+ rt5663->supplies);
+ if (ret) {
+ dev_err(>dev, "Failed to request supplies: %d\n", ret);
+ return ret;
+ }
+
+ /* Set load for regulator. */
+ for (i = 0; i < ARRAY_SIZE(rt5663->supplies); i++) {
+ ret = regulator_set_load(rt5663->supplies[i].consumer,
+RT5663_SUPPLY_CURRENT_UA);
+ if (ret) {
+ dev_err(>dev,
+ "Failed to set regulator %s, ret: %d\n",
+ rt5663->supplies[i].supply, ret);
+ }
+ }
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(rt5663->supplies),
+ rt5663->supplies);
+
+ if (ret) {
+ dev_err(>dev, "Failed to enable supplies: %d\n", ret);
+ return ret;
+ }
+ msleep(RT5663_POWER_ON_DELAY_MS);
+
regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(regmap)) {
ret = PTR_ERR(regmap);
@@ -3527,7 +3568,8 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
dev_err(>dev,
"Device with ID register %#x is not rt5663\n",
val);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_enable;
}
if (IS_ERR(rt5663->regmap)) {
@@ -3632,20 +3674,30 @@ static int rt5663_i2c_probe(struct i2c_client *i2c,
ret = request_irq(i2c->irq, rt5663_irq,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
| IRQF_ONESHOT, "rt5663", rt5663);
- if (ret)
+ if (ret) {
dev_err(>dev, "%s Failed to reguest IRQ: %d\n",
__func__, ret);
+ goto err_enable;
+ }
}
ret = devm_snd_soc_register_component(>dev,
_component_dev_rt5663,
rt5663_dai, ARRAY_SIZE(rt5663_dai));
- if (ret) {
- if (i2c->irq)
- free_irq(i2c->irq, rt5663);
- }
+ if (ret)
+ goto err_irq;
+ return 0;
+
+err_irq:
+ if (i2c->irq)
+ free_irq(i2c->irq, rt5663);
+
+err_enable:
+ dev_err(>dev,
+ "%s: Disable regulator after probe error\n", __func__);
+ regulator_bulk_disable(ARRAY_SIZE(rt5663->supplies), rt5663->supplies);
return ret;
}
@@ -3656,6 +3708,8 @@ static int rt5663_i2c_remove(struct i2c_client *i2c)
if (i2c->irq)
free_irq(i2c->irq, rt5663);
+ regulator_bulk_disable(ARRAY_SIZE(rt5663->supplies), rt5663->supplies);
+
return 0;
}
--
2.19.1.930.g4563a0d9d0-goog
[PATCH 1/2] ASoC: rt5663: Add documentation for power supply support
rt5663 codec driver will support setting CPVDD and AVDD power supply
from device tree.
Signed-off-by: Cheng-Yi Chiang
---
Fixed the commit title of v1.
Documentation/devicetree/bindings/sound/rt5663.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rt5663.txt
b/Documentation/devicetree/bindings/sound/rt5663.txt
index 23386446c63d6..d4058dfde0392 100644
--- a/Documentation/devicetree/bindings/sound/rt5663.txt
+++ b/Documentation/devicetree/bindings/sound/rt5663.txt
@@ -36,6 +36,9 @@ Optional properties:
"realtek,impedance_sensing_num" is 2. It means that there are 2 ranges of
impedance in the impedance sensing function.
+- avdd-supply: Power supply for AVDD, providing 1.8V.
+- cpvdd-supply: Power supply for CPVDD, providing 3.5V.
+
Pins on the device (for linking into audio routes) for RT5663:
* IN1P
@@ -51,4 +54,6 @@ rt5663: codec@12 {
compatible = "realtek,rt5663";
reg = <0x12>;
interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ avdd-supply = <_a_alc5662>;
+ cpvdd-supply = <_a_alc5662>;
};
--
2.19.1.930.g4563a0d9d0-goog
[PATCH 1/2] ASoC: rt5663: Add documentation for power supply support
rt5663 codec driver will support setting CPVDD and AVDD power supply
from device tree.
Signed-off-by: Cheng-Yi Chiang
---
Fixed the commit title of v1.
Documentation/devicetree/bindings/sound/rt5663.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rt5663.txt
b/Documentation/devicetree/bindings/sound/rt5663.txt
index 23386446c63d6..d4058dfde0392 100644
--- a/Documentation/devicetree/bindings/sound/rt5663.txt
+++ b/Documentation/devicetree/bindings/sound/rt5663.txt
@@ -36,6 +36,9 @@ Optional properties:
"realtek,impedance_sensing_num" is 2. It means that there are 2 ranges of
impedance in the impedance sensing function.
+- avdd-supply: Power supply for AVDD, providing 1.8V.
+- cpvdd-supply: Power supply for CPVDD, providing 3.5V.
+
Pins on the device (for linking into audio routes) for RT5663:
* IN1P
@@ -51,4 +54,6 @@ rt5663: codec@12 {
compatible = "realtek,rt5663";
reg = <0x12>;
interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ avdd-supply = <_a_alc5662>;
+ cpvdd-supply = <_a_alc5662>;
};
--
2.19.1.930.g4563a0d9d0-goog
Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset
On Wed, 14 Nov 2018, Russell King - ARM Linux wrote: > However, I now see (having searched mailing lists) what you are trying > to do - you have _not_ copied me or the mailing lists I'm on with your > cover message, so I'm *totally* lacking in the context of your patch > series, particularly where you are converting m68k to use clocksources > without needing the gettimeoffset() stuff. > True. I should have included all interested parties in the recipients of the cover letter. My bad. > You have failed to explain that in this thread - probably assuming that > I've read your cover message. I offered to write a patch to add a clocksource to replace the arch_gettimeoffset functionality for RPC and EBSA110. You even replied to that offer. I did not propose degrading functionality while there is someone able to test modernization patches (assuming there is...). Would you consider merging untested modernization patches for the arch_gettimeoffset API? > I haven't until now, because you never sent it to me or the > linux-arm-kernel mailing list. > > I have found this thread _very_ frustrating, and frankly a waste of my > time discussing the finer points because of this lack of context. Sorry for any frustration I've caused you. The thread went way off-topic when Christoph took the opportunity to suggest the removal of RPC and EBSA110. That doesn't interest me. My interest remains API modernization. The actual patches I've sent are intended to modernize the clock API *without* degrading any functionality. > Please ensure that if you're going to be sending a patch series, that > the cover message at least finds its way to the intended audience of > your patches, so that everyone has the context they need when looking at > (eg) the single patch they may receive. > OK. I'll have to improve my patch submission scripts. -- > Alternatively, if someone raises a problem with the patch, and you > _know_ you haven't done that, then please consider informing them where > they can get more context, eg, by providing a link to your archived > cover message. It would help avoid misunderstandings. > > Thanks. > >
Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset
On Wed, 14 Nov 2018, Russell King - ARM Linux wrote: > However, I now see (having searched mailing lists) what you are trying > to do - you have _not_ copied me or the mailing lists I'm on with your > cover message, so I'm *totally* lacking in the context of your patch > series, particularly where you are converting m68k to use clocksources > without needing the gettimeoffset() stuff. > True. I should have included all interested parties in the recipients of the cover letter. My bad. > You have failed to explain that in this thread - probably assuming that > I've read your cover message. I offered to write a patch to add a clocksource to replace the arch_gettimeoffset functionality for RPC and EBSA110. You even replied to that offer. I did not propose degrading functionality while there is someone able to test modernization patches (assuming there is...). Would you consider merging untested modernization patches for the arch_gettimeoffset API? > I haven't until now, because you never sent it to me or the > linux-arm-kernel mailing list. > > I have found this thread _very_ frustrating, and frankly a waste of my > time discussing the finer points because of this lack of context. Sorry for any frustration I've caused you. The thread went way off-topic when Christoph took the opportunity to suggest the removal of RPC and EBSA110. That doesn't interest me. My interest remains API modernization. The actual patches I've sent are intended to modernize the clock API *without* degrading any functionality. > Please ensure that if you're going to be sending a patch series, that > the cover message at least finds its way to the intended audience of > your patches, so that everyone has the context they need when looking at > (eg) the single patch they may receive. > OK. I'll have to improve my patch submission scripts. -- > Alternatively, if someone raises a problem with the patch, and you > _know_ you haven't done that, then please consider informing them where > they can get more context, eg, by providing a link to your archived > cover message. It would help avoid misunderstandings. > > Thanks. > >
Re: [PATCH] Uprobes: Fix kernel oops with delayed_uprobe_remove()
Hi Oleg, On 11/14/18 9:36 PM, Oleg Nesterov wrote: > On 11/14, Ravi Bangoria wrote: >> >> syzbot reported a kernel crash with delayed_uprobe_remove(): >> https://lkml.org/lkml/2018/11/1/1244 >> >> Backtrace mentioned in the link points to a race between process >> exit and uprobe_unregister(). Fix it by locking delayed_uprobe_lock >> before calling delayed_uprobe_remove() from put_uprobe(). > > The patch looks good to me, but could you update the changelog? > > Please explain that the exiting task calls uprobe_clear_state() which > can race with delayed_uprobe_remove(). IIUC this is the only problem > solved by this patch, right? Right. Is this better: There could be a race between task exit and probe unregister: exit_mm() mmput() __mmput() uprobe_unregister() uprobe_clear_state() put_uprobe() delayed_uprobe_remove() delayed_uprobe_remove() put_uprobe() is calling delayed_uprobe_remove() without taking delayed_uprobe_lock and thus the race sometimes results in a kernel crash. Fix this by taking delayed_uprobe_lock before calling delayed_uprobe_remove() from put_uprobe(). Detailed crash log can be found at: https://lkml.org/lkml/2018/11/1/1244
Re: KMSAN: uninit-value in rcu_accelerate_cbs / KMSAN: uninit-value in rcu_process_callbacks
Thank you for all your comments. Thanks, Kyungtae Kim On Wed, Nov 14, 2018 at 11:05 AM Paul E. McKenney wrote: > > On Wed, Nov 14, 2018 at 04:31:11PM +0100, Alexander Potapenko wrote: > > On Wed, Nov 14, 2018 at 4:09 PM Paul E. McKenney > > wrote: > > > > > > On Wed, Nov 14, 2018 at 04:03:33AM -0500, Kyungtae Kim wrote: > > > > We report two crashes in v4.19-rc8 (4.20-rc1 as well, I guess): > > > > (Unfortunately, there is no repro for those.) > > > > > > > > The two crashes seem to share the same issue. > > > > In both cases, (uninitialized) memory access violation occurs > > > > when "rdp->cblist" is about to be accessed > > > > (kernel/rcu/tree.c:2838,1728). > > > > I guess those are freed before the use, but I still haven't figured > > > > out the reason why. > > > > I'm looking forward to some help. > > > > First of all, I'd avoid reporting KMSAN bugs without clear reproducers. > > The tool is still in beta and may still give false positives due to > > either missed initialization or rare memory corruptions. > > OK, I will set this aside, then, thank you! > > Thanx, Paul > > > > You lost me on this one. In both cases, rdp references a per-CPU > > > variable that is implicitly initialized to all zeroes, due to being > > > (sort of) a C-language global. > > > > > > If a callback is queued early, then the following lines in __call_rcu() > > > will make an honest list of that field because of the : > > > > > > if (rcu_segcblist_empty(>cblist)) > > > rcu_segcblist_init(>cblist); > > > > > > Otherwise, when rcu_init() is invoked during early boot, we have this > > > in rcu_init_percpu_data(), which is called from rcutree_prepare_cpu() > > > which is called from rcu_init(), which is called from start_kernel(): > > > > > > if (rcu_segcblist_empty(>cblist) && /* No early-boot CBs? */ > > > !init_nocb_callback_list(rdp)) > > > rcu_segcblist_init(>cblist); /* Re-enable > > > callbacks. */ > > > > > > So either init_nocb_callback_list() initializes the alternative callback > > > lists for a no-CBs CPU or rcu_segcblist_init() again makes an honest > > > list of that field. > > > > > > My guess is that your tool is missing the > > > > > > rdp = this_cpu_ptr(rsp->rda); > > > > > > in the __call_rcu() case, and also missing the > > > > > > struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu); > > > > > > Note that the ->rda field is explicitly compile-time initialized to > > > the base address of the per-CPU variable, which is rcu_preempt_data, > > > rcu_bh_data, or rcu_sched_data, depending on which RCU flavor is at hand. > > > (In v4.20-rc1, these are all merged into a single flavor to rule them > > > all.) > > > > > > Alternatively, your tool might be missing the implicit initialization > > > of per-CPU variables. > > This used to be fine, but after rebasing to v4.20-rc2 I also started > > seeing strange reports on per-CPU variables. Taking a look. > > > Or maybe I am missing something. If so, please let me know what it is. > > > > > > Thanx, Paul > > > > > > > Crash log 1 > > > > = > > > > BUG: KMSAN: uninit-value in __rcu_process_callbacks > > > > kernel/rcu/tree.c:2838 [inline] > > > > BUG: KMSAN: uninit-value in rcu_process_callbacks+0x5ac/0x1cb0 > > > > kernel/rcu/tree.c:2864 > > > > CPU: 0 PID: 20 Comm: kauditd Not tainted 4.19.0-rc8+ #18 > > > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs > > > > 01/01/2011 > > > > Call Trace: > > > > > > > > __dump_stack lib/dump_stack.c:77 [inline] > > > > dump_stack+0x305/0x460 lib/dump_stack.c:113 > > > > kmsan_report+0x1a2/0x2e0 mm/kmsan/kmsan.c:917 > > > > __msan_warning+0x7d/0xe0 mm/kmsan/kmsan_instr.c:500 > > > > __rcu_process_callbacks kernel/rcu/tree.c:2838 [inline] > > > > rcu_process_callbacks+0x5ac/0x1cb0 kernel/rcu/tree.c:2864 > > > > __do_softirq+0x5ff/0xa55 kernel/softirq.c:292 > > > > invoke_softirq kernel/softirq.c:373 [inline] > > > > irq_exit+0x22d/0x270 kernel/softirq.c:414 > > > > exiting_irq+0xe/0x10 arch/x86/include/asm/apic.h:536 > > > > smp_apic_timer_interrupt+0x64/0x90 arch/x86/kernel/apic/apic.c:1059 > > > > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:869 > > > > > > > > RIP: 0010:finish_lock_switch+0x2b/0x40 kernel/sched/core.c:2578 > > > > Code: 48 89 e5 53 48 89 fb e8 e3 43 9a 00 8b b8 88 0c 00 00 48 8b 00 > > > > 48 85 c0 75 12 48 89 df e8 7d 38 9a 00 c6 00 00 c6 03 00 fb 5b <5d> c3 > > > > e8 de 42 9a 00 eb e7 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 > > > > RSP: 0018:88010622fca0 EFLAGS: 0286 ORIG_RAX: ff13 > > > > RAX: 8801105bcc40 RBX: 8801061554c0 RCX: 8801105bdc40 > > > > RDX: 8801105bdc40 RSI: b000 RDI: ea00077ec560 > > > > RBP: 88010622fca0 R08: 7fff R09: 0002
Re: [PATCH] Uprobes: Fix kernel oops with delayed_uprobe_remove()
Hi Oleg, On 11/14/18 9:36 PM, Oleg Nesterov wrote: > On 11/14, Ravi Bangoria wrote: >> >> syzbot reported a kernel crash with delayed_uprobe_remove(): >> https://lkml.org/lkml/2018/11/1/1244 >> >> Backtrace mentioned in the link points to a race between process >> exit and uprobe_unregister(). Fix it by locking delayed_uprobe_lock >> before calling delayed_uprobe_remove() from put_uprobe(). > > The patch looks good to me, but could you update the changelog? > > Please explain that the exiting task calls uprobe_clear_state() which > can race with delayed_uprobe_remove(). IIUC this is the only problem > solved by this patch, right? Right. Is this better: There could be a race between task exit and probe unregister: exit_mm() mmput() __mmput() uprobe_unregister() uprobe_clear_state() put_uprobe() delayed_uprobe_remove() delayed_uprobe_remove() put_uprobe() is calling delayed_uprobe_remove() without taking delayed_uprobe_lock and thus the race sometimes results in a kernel crash. Fix this by taking delayed_uprobe_lock before calling delayed_uprobe_remove() from put_uprobe(). Detailed crash log can be found at: https://lkml.org/lkml/2018/11/1/1244
Re: KMSAN: uninit-value in rcu_accelerate_cbs / KMSAN: uninit-value in rcu_process_callbacks
Thank you for all your comments. Thanks, Kyungtae Kim On Wed, Nov 14, 2018 at 11:05 AM Paul E. McKenney wrote: > > On Wed, Nov 14, 2018 at 04:31:11PM +0100, Alexander Potapenko wrote: > > On Wed, Nov 14, 2018 at 4:09 PM Paul E. McKenney > > wrote: > > > > > > On Wed, Nov 14, 2018 at 04:03:33AM -0500, Kyungtae Kim wrote: > > > > We report two crashes in v4.19-rc8 (4.20-rc1 as well, I guess): > > > > (Unfortunately, there is no repro for those.) > > > > > > > > The two crashes seem to share the same issue. > > > > In both cases, (uninitialized) memory access violation occurs > > > > when "rdp->cblist" is about to be accessed > > > > (kernel/rcu/tree.c:2838,1728). > > > > I guess those are freed before the use, but I still haven't figured > > > > out the reason why. > > > > I'm looking forward to some help. > > > > First of all, I'd avoid reporting KMSAN bugs without clear reproducers. > > The tool is still in beta and may still give false positives due to > > either missed initialization or rare memory corruptions. > > OK, I will set this aside, then, thank you! > > Thanx, Paul > > > > You lost me on this one. In both cases, rdp references a per-CPU > > > variable that is implicitly initialized to all zeroes, due to being > > > (sort of) a C-language global. > > > > > > If a callback is queued early, then the following lines in __call_rcu() > > > will make an honest list of that field because of the : > > > > > > if (rcu_segcblist_empty(>cblist)) > > > rcu_segcblist_init(>cblist); > > > > > > Otherwise, when rcu_init() is invoked during early boot, we have this > > > in rcu_init_percpu_data(), which is called from rcutree_prepare_cpu() > > > which is called from rcu_init(), which is called from start_kernel(): > > > > > > if (rcu_segcblist_empty(>cblist) && /* No early-boot CBs? */ > > > !init_nocb_callback_list(rdp)) > > > rcu_segcblist_init(>cblist); /* Re-enable > > > callbacks. */ > > > > > > So either init_nocb_callback_list() initializes the alternative callback > > > lists for a no-CBs CPU or rcu_segcblist_init() again makes an honest > > > list of that field. > > > > > > My guess is that your tool is missing the > > > > > > rdp = this_cpu_ptr(rsp->rda); > > > > > > in the __call_rcu() case, and also missing the > > > > > > struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu); > > > > > > Note that the ->rda field is explicitly compile-time initialized to > > > the base address of the per-CPU variable, which is rcu_preempt_data, > > > rcu_bh_data, or rcu_sched_data, depending on which RCU flavor is at hand. > > > (In v4.20-rc1, these are all merged into a single flavor to rule them > > > all.) > > > > > > Alternatively, your tool might be missing the implicit initialization > > > of per-CPU variables. > > This used to be fine, but after rebasing to v4.20-rc2 I also started > > seeing strange reports on per-CPU variables. Taking a look. > > > Or maybe I am missing something. If so, please let me know what it is. > > > > > > Thanx, Paul > > > > > > > Crash log 1 > > > > = > > > > BUG: KMSAN: uninit-value in __rcu_process_callbacks > > > > kernel/rcu/tree.c:2838 [inline] > > > > BUG: KMSAN: uninit-value in rcu_process_callbacks+0x5ac/0x1cb0 > > > > kernel/rcu/tree.c:2864 > > > > CPU: 0 PID: 20 Comm: kauditd Not tainted 4.19.0-rc8+ #18 > > > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs > > > > 01/01/2011 > > > > Call Trace: > > > > > > > > __dump_stack lib/dump_stack.c:77 [inline] > > > > dump_stack+0x305/0x460 lib/dump_stack.c:113 > > > > kmsan_report+0x1a2/0x2e0 mm/kmsan/kmsan.c:917 > > > > __msan_warning+0x7d/0xe0 mm/kmsan/kmsan_instr.c:500 > > > > __rcu_process_callbacks kernel/rcu/tree.c:2838 [inline] > > > > rcu_process_callbacks+0x5ac/0x1cb0 kernel/rcu/tree.c:2864 > > > > __do_softirq+0x5ff/0xa55 kernel/softirq.c:292 > > > > invoke_softirq kernel/softirq.c:373 [inline] > > > > irq_exit+0x22d/0x270 kernel/softirq.c:414 > > > > exiting_irq+0xe/0x10 arch/x86/include/asm/apic.h:536 > > > > smp_apic_timer_interrupt+0x64/0x90 arch/x86/kernel/apic/apic.c:1059 > > > > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:869 > > > > > > > > RIP: 0010:finish_lock_switch+0x2b/0x40 kernel/sched/core.c:2578 > > > > Code: 48 89 e5 53 48 89 fb e8 e3 43 9a 00 8b b8 88 0c 00 00 48 8b 00 > > > > 48 85 c0 75 12 48 89 df e8 7d 38 9a 00 c6 00 00 c6 03 00 fb 5b <5d> c3 > > > > e8 de 42 9a 00 eb e7 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 > > > > RSP: 0018:88010622fca0 EFLAGS: 0286 ORIG_RAX: ff13 > > > > RAX: 8801105bcc40 RBX: 8801061554c0 RCX: 8801105bdc40 > > > > RDX: 8801105bdc40 RSI: b000 RDI: ea00077ec560 > > > > RBP: 88010622fca0 R08: 7fff R09: 0002
[PATCH v2 1/2] Makefile: Fix distcc compilation with x86 macros
Introducing the use of asm macros in c-code broke distcc, since it only sends the preprocessed source file. The solution is to break the compilation into two separate phases of compilation and assembly, and between the two concatenate the assembly macros and the compiled (yet not assembled) source file. Since this is less efficient, this compilation mode is only used when distcc or icecc are used. Note that the assembly stage should also be distributed, if distcc is configured using "CFLAGS=-DENABLE_REMOTE_ASSEMBLE". Reported-by: Logan Gunthorpe Signed-off-by: Nadav Amit --- Makefile | 4 +++- arch/x86/Makefile | 7 +-- scripts/Makefile.build | 30 -- 3 files changed, 36 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 9fce8b91c15f..c07349fc38c7 100644 --- a/Makefile +++ b/Makefile @@ -743,7 +743,9 @@ KBUILD_CFLAGS += $(call cc-option, -gsplit-dwarf, -g) else KBUILD_CFLAGS += -g endif -KBUILD_AFLAGS += -Wa,-gdwarf-2 +AFLAGS_DEBUG_INFO = -Wa,-gdwarf-2 +export AFLAGS_DEBUG_INFO +KBUILD_AFLAGS += $(AFLAGS_DEBUG_INFO) endif ifdef CONFIG_DEBUG_INFO_DWARF4 KBUILD_CFLAGS += $(call cc-option, -gdwarf-4,) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index f5d7f4134524..b5953cbcc9c8 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -235,10 +235,13 @@ archscripts: scripts_basic archheaders: $(Q)$(MAKE) $(build)=arch/x86/entry/syscalls all +ASM_MACRO_FILE = arch/x86/kernel/macros.s +export ASM_MACRO_FILE + archmacros: - $(Q)$(MAKE) $(build)=arch/x86/kernel arch/x86/kernel/macros.s + $(Q)$(MAKE) $(build)=arch/x86/kernel $(ASM_MACRO_FILE) -ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s +ASM_MACRO_FLAGS = -Wa,$(ASM_MACRO_FILE) export ASM_MACRO_FLAGS KBUILD_CFLAGS += $(ASM_MACRO_FLAGS) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 6a6be9f440cf..b8d26bdf48b0 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -155,8 +155,34 @@ $(obj)/%.ll: $(src)/%.c FORCE quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ +# If distcc (or icecc) are used, and when assembly macro files are needed, the +# compilation stage and the assembly stage needs to be separated. Providing the +# "IGNORE_DISTCC=y" option disables separate compilation and assembly. + +cmd_cc_o_c_direct = $(CC) $(c_flags) -c -o $(1) $< + +ifneq ($(if $(IGNORE_DISTCC),,$(shell $(CC) --version 2>&1 | head -n 1 | grep -E 'distcc|ICECC')),) +a_flags_no_debug = $(filter-out $(AFLAGS_DEBUG_INFO), $(a_flags)) +c_flags_no_macros = $(filter-out $(ASM_MACRO_FLAGS), $(c_flags)) + +cmd_cc_o_c_two_steps = \ + $(CC) $(c_flags_no_macros) $(DISABLE_LTO) -fverbose-asm -S \ + -o $(@D)/.$(@F:.o=.s) $<; \ + cat $(ASM_MACRO_FILE) $(@D)/.$(@F:.o=.s) > \ + $(@D)/.tmp_$(@F:.o=.s); \ + $(CC) $(a_flags_no_debug) -c -o $(1) $(@D)/.tmp_$(@F:.o=.s);\ + rm -f $(@D)/.$(@F:.o=.s) $(@D)/.tmp_$(@F:.o=.s) \ + +cmd_cc_o_c_helper =\ + $(if $(findstring $(ASM_MACRO_FLAGS),$(c_flags)), \ + $(call cmd_cc_o_c_two_steps, $(1)), \ + $(call cmd_cc_o_c_direct, $(1))) +else +cmd_cc_o_c_helper = $(call cmd_cc_o_c_direct, $(1)) +endif + ifndef CONFIG_MODVERSIONS -cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< +cmd_cc_o_c = $(call cmd_cc_o_c_helper,$@) else # When module versioning is enabled the following steps are executed: @@ -171,7 +197,7 @@ else # replace the unresolved symbols __crc_exported_symbol with # the actual value of the checksum generated by genksyms -cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $< +cmd_cc_o_c = $(call cmd_cc_o_c_helper,$(@D)/.tmp_$(@F)) cmd_modversions_c = \ if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then \ -- 2.17.1
[PATCH v2 2/2] x86: set a dependency on macros.S
Changes in macros.S should trigger the recompilation of all C files, as
the macros might need to affect their compilation.
Acked-by: Ingo Molnar
Signed-off-by: Nadav Amit
---
scripts/Makefile.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index b8d26bdf48b0..efec77991c2b 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -313,13 +313,13 @@ cmd_undef_syms = echo
endif
# Built-in and composite module parts
-$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
+$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep)
$(ASM_MACRO_FILE:.s=.S) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
# Single-part modules are special since we need to mark them in $(MODVERDIR)
-$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep)
FORCE
+$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep)
$(ASM_MACRO_FILE:.s=.S) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
@{ echo $(@:.o=.ko); echo $@; \
--
2.17.1
[PATCH v2 0/2] x86: Asm macros fixes
There has been a complaint that the recent use of assembly macros in C files broke distcc. The first patch fixes this issue. The second patch adds a dependency for all C files on macros.S, to trigger their recompilation when the relevant macros change. I think it will be better to get the patches through tip. Please advise if you disagree. v1->v2: * Remove whitespaces [Ingo] * Automatically enable split compilation when distcc or icecc are used Nadav Amit (2): Makefile: Fix distcc compilation with x86 macros x86: set a dependency on macros.S Makefile | 4 +++- arch/x86/Makefile | 7 +-- scripts/Makefile.build | 34 ++ 3 files changed, 38 insertions(+), 7 deletions(-) -- 2.17.1
[PATCH v2 1/2] Makefile: Fix distcc compilation with x86 macros
Introducing the use of asm macros in c-code broke distcc, since it only sends the preprocessed source file. The solution is to break the compilation into two separate phases of compilation and assembly, and between the two concatenate the assembly macros and the compiled (yet not assembled) source file. Since this is less efficient, this compilation mode is only used when distcc or icecc are used. Note that the assembly stage should also be distributed, if distcc is configured using "CFLAGS=-DENABLE_REMOTE_ASSEMBLE". Reported-by: Logan Gunthorpe Signed-off-by: Nadav Amit --- Makefile | 4 +++- arch/x86/Makefile | 7 +-- scripts/Makefile.build | 30 -- 3 files changed, 36 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 9fce8b91c15f..c07349fc38c7 100644 --- a/Makefile +++ b/Makefile @@ -743,7 +743,9 @@ KBUILD_CFLAGS += $(call cc-option, -gsplit-dwarf, -g) else KBUILD_CFLAGS += -g endif -KBUILD_AFLAGS += -Wa,-gdwarf-2 +AFLAGS_DEBUG_INFO = -Wa,-gdwarf-2 +export AFLAGS_DEBUG_INFO +KBUILD_AFLAGS += $(AFLAGS_DEBUG_INFO) endif ifdef CONFIG_DEBUG_INFO_DWARF4 KBUILD_CFLAGS += $(call cc-option, -gdwarf-4,) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index f5d7f4134524..b5953cbcc9c8 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -235,10 +235,13 @@ archscripts: scripts_basic archheaders: $(Q)$(MAKE) $(build)=arch/x86/entry/syscalls all +ASM_MACRO_FILE = arch/x86/kernel/macros.s +export ASM_MACRO_FILE + archmacros: - $(Q)$(MAKE) $(build)=arch/x86/kernel arch/x86/kernel/macros.s + $(Q)$(MAKE) $(build)=arch/x86/kernel $(ASM_MACRO_FILE) -ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s +ASM_MACRO_FLAGS = -Wa,$(ASM_MACRO_FILE) export ASM_MACRO_FLAGS KBUILD_CFLAGS += $(ASM_MACRO_FLAGS) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 6a6be9f440cf..b8d26bdf48b0 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -155,8 +155,34 @@ $(obj)/%.ll: $(src)/%.c FORCE quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ +# If distcc (or icecc) are used, and when assembly macro files are needed, the +# compilation stage and the assembly stage needs to be separated. Providing the +# "IGNORE_DISTCC=y" option disables separate compilation and assembly. + +cmd_cc_o_c_direct = $(CC) $(c_flags) -c -o $(1) $< + +ifneq ($(if $(IGNORE_DISTCC),,$(shell $(CC) --version 2>&1 | head -n 1 | grep -E 'distcc|ICECC')),) +a_flags_no_debug = $(filter-out $(AFLAGS_DEBUG_INFO), $(a_flags)) +c_flags_no_macros = $(filter-out $(ASM_MACRO_FLAGS), $(c_flags)) + +cmd_cc_o_c_two_steps = \ + $(CC) $(c_flags_no_macros) $(DISABLE_LTO) -fverbose-asm -S \ + -o $(@D)/.$(@F:.o=.s) $<; \ + cat $(ASM_MACRO_FILE) $(@D)/.$(@F:.o=.s) > \ + $(@D)/.tmp_$(@F:.o=.s); \ + $(CC) $(a_flags_no_debug) -c -o $(1) $(@D)/.tmp_$(@F:.o=.s);\ + rm -f $(@D)/.$(@F:.o=.s) $(@D)/.tmp_$(@F:.o=.s) \ + +cmd_cc_o_c_helper =\ + $(if $(findstring $(ASM_MACRO_FLAGS),$(c_flags)), \ + $(call cmd_cc_o_c_two_steps, $(1)), \ + $(call cmd_cc_o_c_direct, $(1))) +else +cmd_cc_o_c_helper = $(call cmd_cc_o_c_direct, $(1)) +endif + ifndef CONFIG_MODVERSIONS -cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< +cmd_cc_o_c = $(call cmd_cc_o_c_helper,$@) else # When module versioning is enabled the following steps are executed: @@ -171,7 +197,7 @@ else # replace the unresolved symbols __crc_exported_symbol with # the actual value of the checksum generated by genksyms -cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $< +cmd_cc_o_c = $(call cmd_cc_o_c_helper,$(@D)/.tmp_$(@F)) cmd_modversions_c = \ if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then \ -- 2.17.1
[PATCH v2 2/2] x86: set a dependency on macros.S
Changes in macros.S should trigger the recompilation of all C files, as
the macros might need to affect their compilation.
Acked-by: Ingo Molnar
Signed-off-by: Nadav Amit
---
scripts/Makefile.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index b8d26bdf48b0..efec77991c2b 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -313,13 +313,13 @@ cmd_undef_syms = echo
endif
# Built-in and composite module parts
-$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
+$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep)
$(ASM_MACRO_FILE:.s=.S) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
# Single-part modules are special since we need to mark them in $(MODVERDIR)
-$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep)
FORCE
+$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep)
$(ASM_MACRO_FILE:.s=.S) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
@{ echo $(@:.o=.ko); echo $@; \
--
2.17.1
[PATCH v2 0/2] x86: Asm macros fixes
There has been a complaint that the recent use of assembly macros in C files broke distcc. The first patch fixes this issue. The second patch adds a dependency for all C files on macros.S, to trigger their recompilation when the relevant macros change. I think it will be better to get the patches through tip. Please advise if you disagree. v1->v2: * Remove whitespaces [Ingo] * Automatically enable split compilation when distcc or icecc are used Nadav Amit (2): Makefile: Fix distcc compilation with x86 macros x86: set a dependency on macros.S Makefile | 4 +++- arch/x86/Makefile | 7 +-- scripts/Makefile.build | 34 ++ 3 files changed, 38 insertions(+), 7 deletions(-) -- 2.17.1
Re: [PATCH] serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250
On November 14, 2018 5:11:25 PM PST, Guenter Roeck wrote: >On Thu, Nov 01, 2018 at 11:26:06AM -0700, Florian Fainelli wrote: >> It is way too easy to miss enabling SERIAL_OF_PLATFORM which would >> result in the inability for the kernel to have a valid console >device, >> which can be seen with: >> >> Warning: unable to open an initial console. >> >> and then: >> >> Run /init as init process >> Kernel panic - not syncing: Attempted to kill init! >exitcode=0x0100 >> >> Since SERIAL_OF_PLATFORM already depends on SERIAL_8250 && OF there >> really is no drawback to defaulting this config to the value of >> SERIAL_8250. >> >> Signed-off-by: Florian Fainelli >> Signed-off-by: Greg Kroah-Hartman > >This patch results in situations where CONFIG_SERIAL_OF_PLATFORM is now >defined where it was not previously. Example mpc85xx_defconfig. This in >turn results in boot failures for those configurations, with an error >message of > >of_serial: probe of e0004500.serial failed with error -22 > >which wasn't seen before. Do you know which Device Tree is being used here? The most obvious thing that could be done is to add a !PPC condition but this might be missing other platforms doing their own 8250 registration yet being OF aware (sparc?). > >Not sure if replacing a potential problem with a real one is really an >improvement.` That comment is not particularly helpful though I have an appreciation for when a change breaks things in unexpected ways and how frustrating that can be. -- Florian
Re: [PATCH] serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250
On November 14, 2018 5:11:25 PM PST, Guenter Roeck wrote: >On Thu, Nov 01, 2018 at 11:26:06AM -0700, Florian Fainelli wrote: >> It is way too easy to miss enabling SERIAL_OF_PLATFORM which would >> result in the inability for the kernel to have a valid console >device, >> which can be seen with: >> >> Warning: unable to open an initial console. >> >> and then: >> >> Run /init as init process >> Kernel panic - not syncing: Attempted to kill init! >exitcode=0x0100 >> >> Since SERIAL_OF_PLATFORM already depends on SERIAL_8250 && OF there >> really is no drawback to defaulting this config to the value of >> SERIAL_8250. >> >> Signed-off-by: Florian Fainelli >> Signed-off-by: Greg Kroah-Hartman > >This patch results in situations where CONFIG_SERIAL_OF_PLATFORM is now >defined where it was not previously. Example mpc85xx_defconfig. This in >turn results in boot failures for those configurations, with an error >message of > >of_serial: probe of e0004500.serial failed with error -22 > >which wasn't seen before. Do you know which Device Tree is being used here? The most obvious thing that could be done is to add a !PPC condition but this might be missing other platforms doing their own 8250 registration yet being OF aware (sparc?). > >Not sure if replacing a potential problem with a real one is really an >improvement.` That comment is not particularly helpful though I have an appreciation for when a change breaks things in unexpected ways and how frustrating that can be. -- Florian
Re: [PATCH v6 0/2] arm64: dts: add prng-ee nodes
On 01-10-18, 11:51, Vinod Koul wrote: > This adds prng-ee nodes for msm8996 and sdm845 Ping Andy, would appreciate if you can pick these up. Thanks > > changes in v6: > - Fix comments given by Stan > > changes in v5: > - Add more description in patch logs > > changes in v4: > - Fix node address on sdm845 > > changes in v3: > - Add Bjorn's reviewed-by > - Update patch titles to reflect that they add nodes > > changes in v2: > - rebase on v4.19-rc1 > > Vinod Koul (2): > arm64: dts: msm8996: add prng-ee node > arm64: dts: sdm845: add prng-ee node > > arch/arm64/boot/dts/qcom/msm8996.dtsi | 7 +++ > arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 > 2 files changed, 15 insertions(+) > > -- > 2.14.4 -- ~Vinod
Re: [PATCH v6 0/2] arm64: dts: add prng-ee nodes
On 01-10-18, 11:51, Vinod Koul wrote: > This adds prng-ee nodes for msm8996 and sdm845 Ping Andy, would appreciate if you can pick these up. Thanks > > changes in v6: > - Fix comments given by Stan > > changes in v5: > - Add more description in patch logs > > changes in v4: > - Fix node address on sdm845 > > changes in v3: > - Add Bjorn's reviewed-by > - Update patch titles to reflect that they add nodes > > changes in v2: > - rebase on v4.19-rc1 > > Vinod Koul (2): > arm64: dts: msm8996: add prng-ee node > arm64: dts: sdm845: add prng-ee node > > arch/arm64/boot/dts/qcom/msm8996.dtsi | 7 +++ > arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 > 2 files changed, 15 insertions(+) > > -- > 2.14.4 -- ~Vinod
[PATCH] vmw_balloon: update maintainers list
From: Xavier Deguillard Julien will be replacing me as the vmw_balloon maintainer. Cc: Julien Freche Signed-off-by: Xavier Deguillard Signed-off-by: Nadav Amit --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a78d45755881..add462ad3780 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15808,7 +15808,7 @@ F: drivers/vme/ F: include/linux/vme* VMWARE BALLOON DRIVER -M: Xavier Deguillard +M: Julien Freche M: Nadav Amit M: "VMware, Inc." L: linux-kernel@vger.kernel.org -- 2.17.1
[PATCH] vmw_balloon: update maintainers list
From: Xavier Deguillard Julien will be replacing me as the vmw_balloon maintainer. Cc: Julien Freche Signed-off-by: Xavier Deguillard Signed-off-by: Nadav Amit --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a78d45755881..add462ad3780 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15808,7 +15808,7 @@ F: drivers/vme/ F: include/linux/vme* VMWARE BALLOON DRIVER -M: Xavier Deguillard +M: Julien Freche M: Nadav Amit M: "VMware, Inc." L: linux-kernel@vger.kernel.org -- 2.17.1
Re: [PATCH] mm, memory_hotplug: check zone_movable in has_unmovable_pages
On 11/15/18 at 11:13am, Baoquan He wrote:
> On 11/06/18 at 10:55am, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Page state checks are racy. Under a heavy memory workload (e.g. stress
> > -m 200 -t 2h) it is quite easy to hit a race window when the page is
> > allocated but its state is not fully populated yet. A debugging patch to
>
> The original phenomenon is the value of
> /sys/devices/system/memory/memoryxxx/removable
> is 0 on several memory blocks of hotpluggable node. And almost on each
> hotpluggable node, there are one or several blocks which has this zero
> value of removable attribute. It caused the hot removing failure always.
>
> And only cat /sys/devices/system/memory/memoryxxx/removable will trigger
> the call trace.
>
> With this fix, all 'removable' of memory block on those hotpluggable
> nodes are '1', and hotplug can succeed.
Oh, by the way, hot removing/adding can always succeed when no memory
pressure is added.
The hot removing failure with high memory pressure has been raised in
another thread.
Thanks
Baoquan
>
> > dump the struct page state shows
> > : [ 476.575516] has_unmovable_pages: pfn:0x10dfec00, found:0x1, count:0x0
> > : [ 476.582103] page:ea0437fb count:1 mapcount:1
> > mapping:880e05239841 index:0x7f26e5000 compound_mapcount: 1
> > : [ 476.592645] flags:
> > 0x5fc0090034(uptodate|lru|active|head|swapbacked)
> >
> > Note that the state has been checked for both PageLRU and PageSwapBacked
> > already. Closing this race completely would require some sort of retry
> > logic. This can be tricky and error prone (think of potential endless
> > or long taking loops).
> >
> > Workaround this problem for movable zones at least. Such a zone should
> > only contain movable pages. 15c30bc09085 ("mm, memory_hotplug: make
> > has_unmovable_pages more robust") has told us that this is not strictly
> > true though. Bootmem pages should be marked reserved though so we can
> > move the original check after the PageReserved check. Pages from other
> > zones are still prone to races but we even do not pretend that memory
> > hotremove works for those so pre-mature failure doesn't hurt that much.
> >
> > Reported-and-tested-by: Baoquan He
> > Acked-by: Baoquan He
> > Fixes: "mm, memory_hotplug: make has_unmovable_pages more robust")
>
> Fixes: 15c30bc09085 "mm, memory_hotplug: make has_unmovable_pages more
> robust")
>
> > Signed-off-by: Michal Hocko
> > ---
> >
> > Hi,
> > this has been reported [1] and we have tried multiple things to address
> > the issue. The only reliable way was to reintroduce the movable zone
> > check into has_unmovable_pages. This time it should be safe also for
> > the bug originally fixed by 15c30bc09085.
> >
> > [1] http://lkml.kernel.org/r/20181101091055.GA15166@MiWiFi-R3L-srv
> > mm/page_alloc.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 863d46da6586..c6d900ee4982 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -7788,6 +7788,14 @@ bool has_unmovable_pages(struct zone *zone, struct
> > page *page, int count,
> > if (PageReserved(page))
> > goto unmovable;
> >
> > + /*
> > +* If the zone is movable and we have ruled out all reserved
> > +* pages then it should be reasonably safe to assume the rest
> > +* is movable.
> > +*/
> > + if (zone_idx(zone) == ZONE_MOVABLE)
> > + continue;
> > +
> > /*
> > * Hugepages are not in LRU lists, but they're movable.
> > * We need not scan over tail pages bacause we don't
> > --
> > 2.19.1
> >
Re: [PATCH] mm, memory_hotplug: check zone_movable in has_unmovable_pages
On 11/15/18 at 11:13am, Baoquan He wrote:
> On 11/06/18 at 10:55am, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Page state checks are racy. Under a heavy memory workload (e.g. stress
> > -m 200 -t 2h) it is quite easy to hit a race window when the page is
> > allocated but its state is not fully populated yet. A debugging patch to
>
> The original phenomenon is the value of
> /sys/devices/system/memory/memoryxxx/removable
> is 0 on several memory blocks of hotpluggable node. And almost on each
> hotpluggable node, there are one or several blocks which has this zero
> value of removable attribute. It caused the hot removing failure always.
>
> And only cat /sys/devices/system/memory/memoryxxx/removable will trigger
> the call trace.
>
> With this fix, all 'removable' of memory block on those hotpluggable
> nodes are '1', and hotplug can succeed.
Oh, by the way, hot removing/adding can always succeed when no memory
pressure is added.
The hot removing failure with high memory pressure has been raised in
another thread.
Thanks
Baoquan
>
> > dump the struct page state shows
> > : [ 476.575516] has_unmovable_pages: pfn:0x10dfec00, found:0x1, count:0x0
> > : [ 476.582103] page:ea0437fb count:1 mapcount:1
> > mapping:880e05239841 index:0x7f26e5000 compound_mapcount: 1
> > : [ 476.592645] flags:
> > 0x5fc0090034(uptodate|lru|active|head|swapbacked)
> >
> > Note that the state has been checked for both PageLRU and PageSwapBacked
> > already. Closing this race completely would require some sort of retry
> > logic. This can be tricky and error prone (think of potential endless
> > or long taking loops).
> >
> > Workaround this problem for movable zones at least. Such a zone should
> > only contain movable pages. 15c30bc09085 ("mm, memory_hotplug: make
> > has_unmovable_pages more robust") has told us that this is not strictly
> > true though. Bootmem pages should be marked reserved though so we can
> > move the original check after the PageReserved check. Pages from other
> > zones are still prone to races but we even do not pretend that memory
> > hotremove works for those so pre-mature failure doesn't hurt that much.
> >
> > Reported-and-tested-by: Baoquan He
> > Acked-by: Baoquan He
> > Fixes: "mm, memory_hotplug: make has_unmovable_pages more robust")
>
> Fixes: 15c30bc09085 "mm, memory_hotplug: make has_unmovable_pages more
> robust")
>
> > Signed-off-by: Michal Hocko
> > ---
> >
> > Hi,
> > this has been reported [1] and we have tried multiple things to address
> > the issue. The only reliable way was to reintroduce the movable zone
> > check into has_unmovable_pages. This time it should be safe also for
> > the bug originally fixed by 15c30bc09085.
> >
> > [1] http://lkml.kernel.org/r/20181101091055.GA15166@MiWiFi-R3L-srv
> > mm/page_alloc.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 863d46da6586..c6d900ee4982 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -7788,6 +7788,14 @@ bool has_unmovable_pages(struct zone *zone, struct
> > page *page, int count,
> > if (PageReserved(page))
> > goto unmovable;
> >
> > + /*
> > +* If the zone is movable and we have ruled out all reserved
> > +* pages then it should be reasonably safe to assume the rest
> > +* is movable.
> > +*/
> > + if (zone_idx(zone) == ZONE_MOVABLE)
> > + continue;
> > +
> > /*
> > * Hugepages are not in LRU lists, but they're movable.
> > * We need not scan over tail pages bacause we don't
> > --
> > 2.19.1
> >
[PATCH 4/5] switchtec: Improve MRPC efficiency by leveraging write combining
From: Kelvin Cao
MRPC Input buffer is mostly memory without any side effects, thus we can
improve the access time by enabling write combining on only this region of
the BAR.
In a few places, we still need to flush the WC buffer. To do this, we
simply read from the Outbound Doorbell register seeing reads to this
register are processed by low latency hardware.
Signed-off-by: Kelvin Cao
Signed-off-by: Wesley Sheng
---
drivers/pci/switch/switchtec.c | 41 +++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index a908670..0b8862b 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -113,6 +113,19 @@ static void stuser_set_state(struct switchtec_user *stuser,
static void mrpc_complete_cmd(struct switchtec_dev *stdev);
+static void flush_wc_buf(struct switchtec_dev *stdev)
+{
+ struct ntb_dbmsg_regs __iomem *mmio_dbmsg;
+
+ /*
+* odb (outbound doorbell) register is processed by low latency
+* hardware and w/o side effect
+*/
+ mmio_dbmsg = (void __iomem *)stdev->mmio_ntb +
+ SWITCHTEC_NTB_REG_DBMSG_OFFSET;
+ ioread32(_dbmsg->odb);
+}
+
static void mrpc_cmd_submit(struct switchtec_dev *stdev)
{
/* requires the mrpc_mutex to already be held when called */
@@ -132,6 +145,7 @@ static void mrpc_cmd_submit(struct switchtec_dev *stdev)
stdev->mrpc_busy = 1;
memcpy_toio(>mmio_mrpc->input_data,
stuser->data, stuser->data_len);
+ flush_wc_buf(stdev);
iowrite32(stuser->cmd, >mmio_mrpc->cmd);
schedule_delayed_work(>mrpc_timeout,
@@ -1231,23 +1245,38 @@ static int switchtec_init_pci(struct switchtec_dev
*stdev,
struct pci_dev *pdev)
{
int rc;
+ void __iomem *map;
+ unsigned long res_start, res_len;
rc = pcim_enable_device(pdev);
if (rc)
return rc;
- rc = pcim_iomap_regions(pdev, 0x1, KBUILD_MODNAME);
- if (rc)
- return rc;
-
rc = dma_set_coherent_mask(>dev, DMA_BIT_MASK(64));
if (rc)
return rc;
pci_set_master(pdev);
- stdev->mmio = pcim_iomap_table(pdev)[0];
- stdev->mmio_mrpc = stdev->mmio + SWITCHTEC_GAS_MRPC_OFFSET;
+ res_start = pci_resource_start(pdev, 0);
+ res_len = pci_resource_len(pdev, 0);
+
+ if (!devm_request_mem_region(>dev, res_start,
+res_len, KBUILD_MODNAME))
+ return -EBUSY;
+
+ stdev->mmio_mrpc = devm_ioremap_wc(>dev, res_start,
+ SWITCHTEC_GAS_TOP_CFG_OFFSET);
+ if (!stdev->mmio_mrpc)
+ return -ENOMEM;
+
+ map = devm_ioremap(>dev,
+ res_start + SWITCHTEC_GAS_TOP_CFG_OFFSET,
+ res_len - SWITCHTEC_GAS_TOP_CFG_OFFSET);
+ if (!map)
+ return -ENOMEM;
+
+ stdev->mmio = map - SWITCHTEC_GAS_TOP_CFG_OFFSET;
stdev->mmio_sw_event = stdev->mmio + SWITCHTEC_GAS_SW_EVENT_OFFSET;
stdev->mmio_sys_info = stdev->mmio + SWITCHTEC_GAS_SYS_INFO_OFFSET;
stdev->mmio_flash_info = stdev->mmio + SWITCHTEC_GAS_FLASH_INFO_OFFSET;
--
2.7.4
[PATCH 5/5] switchtec: MRPC DMA mode implementation
MRPC normal mode requires the host to read the MRPC command status and
output data from BAR. This results in high latency responses from the
Memory Read TLP and potential Completion Timeout (CTO).
MRPC DMA mode implementation includes:
Macro definitions for registers and data structures corresponding to
MRPC DMA mode.
Add module parameter use_dma_mrpc to select between MRPC DMA mode and
MRPC normal mode.
Add MRPC mode functionality to:
* Retrieve MRPC DMA mode version
* Allocate DMA buffer, ISR registration, and enable DMA function during
initialization
* Check MRPC execution status and collect execution results from DMA buffer
* Release DMA buffer and disable DMA function when unloading module
MRPC DMA mode is a new feature of firmware and the driver will fall back
to MRPC normal mode if there is no support in the legacy firmware.
Include so that readq/writeq is replaced
by two readl/writel on systems that do not support it.
Signed-off-by: Wesley Sheng
---
drivers/pci/switch/switchtec.c | 108 +
include/linux/switchtec.h | 16 ++
2 files changed, 114 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 0b8862b..6b726cb 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -13,7 +13,7 @@
#include
#include
#include
-
+#include
#include
MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCIe Management Driver");
@@ -25,6 +25,11 @@ static int max_devices = 16;
module_param(max_devices, int, 0644);
MODULE_PARM_DESC(max_devices, "max number of switchtec device instances");
+static bool use_dma_mrpc = 1;
+module_param(use_dma_mrpc, bool, 0644);
+MODULE_PARM_DESC(use_dma_mrpc,
+"Enable the use of the DMA MRPC feature");
+
static dev_t switchtec_devt;
static DEFINE_IDA(switchtec_minor_ida);
@@ -141,6 +146,11 @@ static void mrpc_cmd_submit(struct switchtec_dev *stdev)
stuser = list_entry(stdev->mrpc_queue.next, struct switchtec_user,
list);
+ if (stdev->dma_mrpc) {
+ stdev->dma_mrpc->status = SWITCHTEC_MRPC_STATUS_INPROGRESS;
+ memset(stdev->dma_mrpc->data, 0xFF,
SWITCHTEC_MRPC_PAYLOAD_SIZE);
+ }
+
stuser_set_state(stuser, MRPC_RUNNING);
stdev->mrpc_busy = 1;
memcpy_toio(>mmio_mrpc->input_data,
@@ -180,7 +190,11 @@ static void mrpc_complete_cmd(struct switchtec_dev *stdev)
stuser = list_entry(stdev->mrpc_queue.next, struct switchtec_user,
list);
- stuser->status = ioread32(>mmio_mrpc->status);
+ if (stdev->dma_mrpc)
+ stuser->status = stdev->dma_mrpc->status;
+ else
+ stuser->status = ioread32(>mmio_mrpc->status);
+
if (stuser->status == SWITCHTEC_MRPC_STATUS_INPROGRESS)
return;
@@ -190,13 +204,19 @@ static void mrpc_complete_cmd(struct switchtec_dev *stdev)
if (stuser->status != SWITCHTEC_MRPC_STATUS_DONE)
goto out;
- stuser->return_code = ioread32(>mmio_mrpc->ret_value);
+ if (stdev->dma_mrpc)
+ stuser->return_code = stdev->dma_mrpc->rtn_code;
+ else
+ stuser->return_code = ioread32(>mmio_mrpc->ret_value);
if (stuser->return_code != 0)
goto out;
- memcpy_fromio(stuser->data, >mmio_mrpc->output_data,
- stuser->read_len);
-
+ if (stdev->dma_mrpc)
+ memcpy(stuser->data, >dma_mrpc->data,
+ stuser->read_len);
+ else
+ memcpy_fromio(stuser->data, >mmio_mrpc->output_data,
+ stuser->read_len);
out:
complete_all(>comp);
list_del_init(>list);
@@ -231,7 +251,10 @@ static void mrpc_timeout_work(struct work_struct *work)
mutex_lock(>mrpc_mutex);
- status = ioread32(>mmio_mrpc->status);
+ if (stdev->dma_mrpc)
+ status = stdev->dma_mrpc->status;
+ else
+ status = ioread32(>mmio_mrpc->status);
if (status == SWITCHTEC_MRPC_STATUS_INPROGRESS) {
schedule_delayed_work(>mrpc_timeout,
msecs_to_jiffies(500));
@@ -239,7 +262,6 @@ static void mrpc_timeout_work(struct work_struct *work)
}
mrpc_complete_cmd(stdev);
-
out:
mutex_unlock(>mrpc_mutex);
}
@@ -1030,10 +1052,24 @@ static void enable_link_state_events(struct
switchtec_dev *stdev)
}
}
+static void enable_dma_mrpc(struct switchtec_dev *stdev)
+{
+ writeq(stdev->dma_mrpc_dma_addr, >mmio_mrpc->dma_addr);
+ flush_wc_buf(stdev);
+ iowrite32(SWITCHTEC_DMA_MRPC_EN, >mmio_mrpc->dma_en);
+}
+
static void stdev_release(struct device *dev)
{
struct switchtec_dev *stdev = to_stdev(dev);
+ if (stdev->dma_mrpc) {
+ iowrite32(0, >mmio_mrpc->dma_en);
+
[PATCH 3/5] switchtec: A temporary variable should be used for the flags of switchtec_ioctl_event_ctl
From: Joey Zhang
For nr_idxs is larger than 1 switchtec_ioctl_event_ctl event flags will be
used by each event indexes. In current implementation the event flags are
overwritten by first call of the function event_ctl().
Preserve the event flag value with a temporary variable.
Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
Signed-off-by: Joey Zhang
Signed-off-by: Wesley Sheng
---
drivers/pci/switch/switchtec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 480107e..a908670 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -796,6 +796,7 @@ static int ioctl_event_ctl(struct switchtec_dev *stdev,
{
int ret;
int nr_idxs;
+ unsigned int event_flags;
struct switchtec_ioctl_event_ctl ctl;
if (copy_from_user(, uctl, sizeof(ctl)))
@@ -817,7 +818,9 @@ static int ioctl_event_ctl(struct switchtec_dev *stdev,
else
return -EINVAL;
+ event_flags = ctl.flags;
for (ctl.index = 0; ctl.index < nr_idxs; ctl.index++) {
+ ctl.flags = event_flags;
ret = event_ctl(stdev, );
if (ret < 0)
return ret;
--
2.7.4
[PATCH 5/5] switchtec: MRPC DMA mode implementation
MRPC normal mode requires the host to read the MRPC command status and
output data from BAR. This results in high latency responses from the
Memory Read TLP and potential Completion Timeout (CTO).
MRPC DMA mode implementation includes:
Macro definitions for registers and data structures corresponding to
MRPC DMA mode.
Add module parameter use_dma_mrpc to select between MRPC DMA mode and
MRPC normal mode.
Add MRPC mode functionality to:
* Retrieve MRPC DMA mode version
* Allocate DMA buffer, ISR registration, and enable DMA function during
initialization
* Check MRPC execution status and collect execution results from DMA buffer
* Release DMA buffer and disable DMA function when unloading module
MRPC DMA mode is a new feature of firmware and the driver will fall back
to MRPC normal mode if there is no support in the legacy firmware.
Include so that readq/writeq is replaced
by two readl/writel on systems that do not support it.
Signed-off-by: Wesley Sheng
---
drivers/pci/switch/switchtec.c | 108 +
include/linux/switchtec.h | 16 ++
2 files changed, 114 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 0b8862b..6b726cb 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -13,7 +13,7 @@
#include
#include
#include
-
+#include
#include
MODULE_DESCRIPTION("Microsemi Switchtec(tm) PCIe Management Driver");
@@ -25,6 +25,11 @@ static int max_devices = 16;
module_param(max_devices, int, 0644);
MODULE_PARM_DESC(max_devices, "max number of switchtec device instances");
+static bool use_dma_mrpc = 1;
+module_param(use_dma_mrpc, bool, 0644);
+MODULE_PARM_DESC(use_dma_mrpc,
+"Enable the use of the DMA MRPC feature");
+
static dev_t switchtec_devt;
static DEFINE_IDA(switchtec_minor_ida);
@@ -141,6 +146,11 @@ static void mrpc_cmd_submit(struct switchtec_dev *stdev)
stuser = list_entry(stdev->mrpc_queue.next, struct switchtec_user,
list);
+ if (stdev->dma_mrpc) {
+ stdev->dma_mrpc->status = SWITCHTEC_MRPC_STATUS_INPROGRESS;
+ memset(stdev->dma_mrpc->data, 0xFF,
SWITCHTEC_MRPC_PAYLOAD_SIZE);
+ }
+
stuser_set_state(stuser, MRPC_RUNNING);
stdev->mrpc_busy = 1;
memcpy_toio(>mmio_mrpc->input_data,
@@ -180,7 +190,11 @@ static void mrpc_complete_cmd(struct switchtec_dev *stdev)
stuser = list_entry(stdev->mrpc_queue.next, struct switchtec_user,
list);
- stuser->status = ioread32(>mmio_mrpc->status);
+ if (stdev->dma_mrpc)
+ stuser->status = stdev->dma_mrpc->status;
+ else
+ stuser->status = ioread32(>mmio_mrpc->status);
+
if (stuser->status == SWITCHTEC_MRPC_STATUS_INPROGRESS)
return;
@@ -190,13 +204,19 @@ static void mrpc_complete_cmd(struct switchtec_dev *stdev)
if (stuser->status != SWITCHTEC_MRPC_STATUS_DONE)
goto out;
- stuser->return_code = ioread32(>mmio_mrpc->ret_value);
+ if (stdev->dma_mrpc)
+ stuser->return_code = stdev->dma_mrpc->rtn_code;
+ else
+ stuser->return_code = ioread32(>mmio_mrpc->ret_value);
if (stuser->return_code != 0)
goto out;
- memcpy_fromio(stuser->data, >mmio_mrpc->output_data,
- stuser->read_len);
-
+ if (stdev->dma_mrpc)
+ memcpy(stuser->data, >dma_mrpc->data,
+ stuser->read_len);
+ else
+ memcpy_fromio(stuser->data, >mmio_mrpc->output_data,
+ stuser->read_len);
out:
complete_all(>comp);
list_del_init(>list);
@@ -231,7 +251,10 @@ static void mrpc_timeout_work(struct work_struct *work)
mutex_lock(>mrpc_mutex);
- status = ioread32(>mmio_mrpc->status);
+ if (stdev->dma_mrpc)
+ status = stdev->dma_mrpc->status;
+ else
+ status = ioread32(>mmio_mrpc->status);
if (status == SWITCHTEC_MRPC_STATUS_INPROGRESS) {
schedule_delayed_work(>mrpc_timeout,
msecs_to_jiffies(500));
@@ -239,7 +262,6 @@ static void mrpc_timeout_work(struct work_struct *work)
}
mrpc_complete_cmd(stdev);
-
out:
mutex_unlock(>mrpc_mutex);
}
@@ -1030,10 +1052,24 @@ static void enable_link_state_events(struct
switchtec_dev *stdev)
}
}
+static void enable_dma_mrpc(struct switchtec_dev *stdev)
+{
+ writeq(stdev->dma_mrpc_dma_addr, >mmio_mrpc->dma_addr);
+ flush_wc_buf(stdev);
+ iowrite32(SWITCHTEC_DMA_MRPC_EN, >mmio_mrpc->dma_en);
+}
+
static void stdev_release(struct device *dev)
{
struct switchtec_dev *stdev = to_stdev(dev);
+ if (stdev->dma_mrpc) {
+ iowrite32(0, >mmio_mrpc->dma_en);
+
[PATCH 3/5] switchtec: A temporary variable should be used for the flags of switchtec_ioctl_event_ctl
From: Joey Zhang
For nr_idxs is larger than 1 switchtec_ioctl_event_ctl event flags will be
used by each event indexes. In current implementation the event flags are
overwritten by first call of the function event_ctl().
Preserve the event flag value with a temporary variable.
Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
Signed-off-by: Joey Zhang
Signed-off-by: Wesley Sheng
---
drivers/pci/switch/switchtec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 480107e..a908670 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -796,6 +796,7 @@ static int ioctl_event_ctl(struct switchtec_dev *stdev,
{
int ret;
int nr_idxs;
+ unsigned int event_flags;
struct switchtec_ioctl_event_ctl ctl;
if (copy_from_user(, uctl, sizeof(ctl)))
@@ -817,7 +818,9 @@ static int ioctl_event_ctl(struct switchtec_dev *stdev,
else
return -EINVAL;
+ event_flags = ctl.flags;
for (ctl.index = 0; ctl.index < nr_idxs; ctl.index++) {
+ ctl.flags = event_flags;
ret = event_ctl(stdev, );
if (ret < 0)
return ret;
--
2.7.4
[PATCH 4/5] switchtec: Improve MRPC efficiency by leveraging write combining
From: Kelvin Cao
MRPC Input buffer is mostly memory without any side effects, thus we can
improve the access time by enabling write combining on only this region of
the BAR.
In a few places, we still need to flush the WC buffer. To do this, we
simply read from the Outbound Doorbell register seeing reads to this
register are processed by low latency hardware.
Signed-off-by: Kelvin Cao
Signed-off-by: Wesley Sheng
---
drivers/pci/switch/switchtec.c | 41 +++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index a908670..0b8862b 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -113,6 +113,19 @@ static void stuser_set_state(struct switchtec_user *stuser,
static void mrpc_complete_cmd(struct switchtec_dev *stdev);
+static void flush_wc_buf(struct switchtec_dev *stdev)
+{
+ struct ntb_dbmsg_regs __iomem *mmio_dbmsg;
+
+ /*
+* odb (outbound doorbell) register is processed by low latency
+* hardware and w/o side effect
+*/
+ mmio_dbmsg = (void __iomem *)stdev->mmio_ntb +
+ SWITCHTEC_NTB_REG_DBMSG_OFFSET;
+ ioread32(_dbmsg->odb);
+}
+
static void mrpc_cmd_submit(struct switchtec_dev *stdev)
{
/* requires the mrpc_mutex to already be held when called */
@@ -132,6 +145,7 @@ static void mrpc_cmd_submit(struct switchtec_dev *stdev)
stdev->mrpc_busy = 1;
memcpy_toio(>mmio_mrpc->input_data,
stuser->data, stuser->data_len);
+ flush_wc_buf(stdev);
iowrite32(stuser->cmd, >mmio_mrpc->cmd);
schedule_delayed_work(>mrpc_timeout,
@@ -1231,23 +1245,38 @@ static int switchtec_init_pci(struct switchtec_dev
*stdev,
struct pci_dev *pdev)
{
int rc;
+ void __iomem *map;
+ unsigned long res_start, res_len;
rc = pcim_enable_device(pdev);
if (rc)
return rc;
- rc = pcim_iomap_regions(pdev, 0x1, KBUILD_MODNAME);
- if (rc)
- return rc;
-
rc = dma_set_coherent_mask(>dev, DMA_BIT_MASK(64));
if (rc)
return rc;
pci_set_master(pdev);
- stdev->mmio = pcim_iomap_table(pdev)[0];
- stdev->mmio_mrpc = stdev->mmio + SWITCHTEC_GAS_MRPC_OFFSET;
+ res_start = pci_resource_start(pdev, 0);
+ res_len = pci_resource_len(pdev, 0);
+
+ if (!devm_request_mem_region(>dev, res_start,
+res_len, KBUILD_MODNAME))
+ return -EBUSY;
+
+ stdev->mmio_mrpc = devm_ioremap_wc(>dev, res_start,
+ SWITCHTEC_GAS_TOP_CFG_OFFSET);
+ if (!stdev->mmio_mrpc)
+ return -ENOMEM;
+
+ map = devm_ioremap(>dev,
+ res_start + SWITCHTEC_GAS_TOP_CFG_OFFSET,
+ res_len - SWITCHTEC_GAS_TOP_CFG_OFFSET);
+ if (!map)
+ return -ENOMEM;
+
+ stdev->mmio = map - SWITCHTEC_GAS_TOP_CFG_OFFSET;
stdev->mmio_sw_event = stdev->mmio + SWITCHTEC_GAS_SW_EVENT_OFFSET;
stdev->mmio_sys_info = stdev->mmio + SWITCHTEC_GAS_SYS_INFO_OFFSET;
stdev->mmio_flash_info = stdev->mmio + SWITCHTEC_GAS_FLASH_INFO_OFFSET;
--
2.7.4
[PATCH 0/5] Switchtec MRPC DMA mode support
Hi, Everyone, This patch series adds support for the Switchtec MRPC DMA mode. Switchtec switches supports 2 MRPC interaction modes: MRPC normal mode and MRPC DMA mode, a new feature in the latest firmware versions. MRPC normal mode requires the host to read the MRPC command status and output data. In MRPC DMA mode the command status and output data are pushed directly to host memory and issues an interrupt upon completion. The advantage of MRPC DMA mode is avoiding potential high latency response from the Memory Read TLP. Additionally, we've made the following changes: * Improve the efficiency of filling MRPC Input buffer by enabling write combining on MRPC region of BAR * Software workaround for delay responded Memory READ TLPs that access the BAR * And several bug fixes Regards, Wesley Boris Glimcher (1): switchtec: Set DMA coherent mask in Switchtec driver Joey Zhang (1): switchtec: A temporary variable should be used for the flags of switchtec_ioctl_event_ctl Kelvin Cao (2): switchtec: Remove immediate status check after submit a MRPC command switchtec: Improve MRPC efficiency by leveraging write combining Wesley Sheng (1): switchtec: MRPC DMA mode implementation drivers/pci/switch/switchtec.c | 154 - include/linux/switchtec.h | 16 + 2 files changed, 153 insertions(+), 17 deletions(-) -- 2.7.4
[PATCH 2/5] switchtec: Set DMA coherent mask in Switchtec driver
From: Boris Glimcher Switchtec hardware supports 64-bit DMA, set the correct DMA mask. This allows the CMA to allocate larger buffers for memory windows. Signed-off-by: Boris Glimcher Signed-off-by: Wesley Sheng --- drivers/pci/switch/switchtec.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c index d2bca2d..480107e 100644 --- a/drivers/pci/switch/switchtec.c +++ b/drivers/pci/switch/switchtec.c @@ -1237,6 +1237,10 @@ static int switchtec_init_pci(struct switchtec_dev *stdev, if (rc) return rc; + rc = dma_set_coherent_mask(>dev, DMA_BIT_MASK(64)); + if (rc) + return rc; + pci_set_master(pdev); stdev->mmio = pcim_iomap_table(pdev)[0]; -- 2.7.4
