Re: [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
On Monday 28 November 2016 01:12 PM, Tomi Valkeinen wrote: > On 28/11/16 07:24, Sekhar Nori wrote: >> On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote: >>> It has been determined that the maximum resolution supported correctly >>> by tilcdc rev1 on da850 SoCs is 800x600@60. Due to memory throughput >>> constraints we must filter out higher modes. >>> >>> Specify the max-bandwidth property for the display node for >>> da850-based boards. >>> >>> Signed-off-by: Bartosz Golaszewski >>> --- >>> arch/arm/boot/dts/da850.dtsi | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi >>> index 8e30d9b..9b7c444 100644 >>> --- a/arch/arm/boot/dts/da850.dtsi >>> +++ b/arch/arm/boot/dts/da850.dtsi >>> @@ -452,6 +452,7 @@ >>> compatible = "ti,da850-tilcdc"; >>> reg = <0x213000 0x1000>; >>> interrupts = <52>; >>> + max-bandwidth = <2880>; >> >> If this is effectively the max pixel clock that the device supports, >> then why not use the datasheet specified value of 37.5 MHz (Tc = 26.66 ns). > > There's a separate property for max-pixelclock. This one is maximum > pixels per second (which does sound almost the same), but the doc says > it's about the particular memory interface + LCDC combination. DA850 supports both mDDR and DDR2, at slightly different speeds. So memory bandwidth limitation is also board specific. This should probably move to board file. But I would like to know why using max-pixelclock is not good enough. Have experiments shown that LCDC on DA850 LCDK underflows even if pixel clock is below the datasheet recommendation? Thanks, Sekhar
[PATCH 1/1] net: macb: ensure ordering write to re-enable RX smoothly
When a hardware issue happened as described by inline comments, the register
write pattern looks like the following:
+ wmb();
There might be a memory barrier between these two write operations, so add wmb
to ensure an flip from 0 to 1 for NCR.
Signed-off-by: Zumeng Chen
---
drivers/net/ethernet/cadence/macb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 533653b..2f9c5b2 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1156,6 +1156,7 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
if (status & MACB_BIT(RXUBR)) {
ctrl = macb_readl(bp, NCR);
macb_writel(bp, NCR, ctrl & ~MACB_BIT(RE));
+ wmb();
macb_writel(bp, NCR, ctrl | MACB_BIT(RE));
if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
--
2.4.11
[PATCH] bcma: add Dell Inspiron 3148
This is what is in the laptop:
01:00.0 Network controller [0280]: Broadcom Limited BCM43142 802.11b/g/n
[14e4:4365] (rev 01)
Subsystem: Dell Device [1028:0018]
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at b040 (64-bit, non-prefetchable) [size=32K]
Capabilities: [40] Power Management version 3
Capabilities: [58] Vendor Specific Information: Len=78
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [d0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-9a-ff-ff-f3-40-b8
Capabilities: [16c] Power Budgeting
With the patch, I can see:
bcma: bus0: Found chip with id 43142, rev 0x01 and package 0x08
bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x28, class
0x0)
bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x21, class
0x0)
bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x16, class 0x0)
bcma: bus0: Core 3 found: UNKNOWN (manuf 0x43B, id 0x368, rev 0x00, class 0x0)
bcma: bus0: Bus registered
The wifi is not currently supported by brcmsmac yet:
brcmsmac bcma1:1: mfg 4bf core 812 rev 33 class 0 irq 18
brcmsmac: unknown device id 4365
So don't expect a working wifi from this patch :).
Signed-off-by: Jiri Slaby
Cc: Rafał Miłecki
Cc:
---
drivers/bcma/host_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
index bd46569e0e52..925842996986 100644
--- a/drivers/bcma/host_pci.c
+++ b/drivers/bcma/host_pci.c
@@ -295,6 +295,7 @@ static const struct pci_device_id bcma_pci_bridge_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4359) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4360) },
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_BROADCOM, 0x4365, PCI_VENDOR_ID_DELL,
0x0016) },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_BROADCOM, 0x4365, PCI_VENDOR_ID_DELL,
0x0018) },
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_BROADCOM, 0x4365, PCI_VENDOR_ID_FOXCONN,
0xe092) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a0) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a9) },
--
2.10.2
[PATCH] dt-bindings: add MYIR Tech hardware vendor prefix
MYIR Tech Limited offers a range of ARM powered development boards and SoMs, for details reference a list on http://elinux.org/Development_Platforms#ARM or company's website http://myirtech.com Signed-off-by: Vladimir Zapolskiy --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 8a82bfe..3db548a 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -182,6 +182,7 @@ mti Imagination Technologies Ltd. (formerly MIPS Technologies Inc.) mundoreaderMundo Reader S.L. murata Murata Manufacturing Co., Ltd. mxicy Macronix International Co., Ltd. +myir MYIR Tech Limited national National Semiconductor necNEC LCD Technologies, Ltd. neonodeNeonode Inc. -- 2.10.2
RE: [PATCH v2] fsl/usb: Workarourd for USB erratum-A005697
Thanks a lot, Alan,
I will send the v3 with your suggestion.
Best Regards
Jerry Huang
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Friday, November 25, 2016 11:14 PM
To: Jerry Huang
Cc: gre...@linuxfoundation.org; Ramneek Mehresh ;
julia.law...@lip6.fr; Sriram Dash ;
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] fsl/usb: Workarourd for USB erratum-A005697
On Fri, 25 Nov 2016, Changming Huang wrote:
> The EHCI specification states the following in the SUSP bit description:
> In the Suspend state, the port is senstive to resume detection.
> Note that the bit status does not change untile the port is suspended
> and that there may be a delay in susupending a port if there is a
> transaction currently in progress on the USB.
>
> However, in NXP USBDR controller, the PORTSCx[SUSP] bit changes
> immediately when the application sets it and not when the port is actually
> suspended.
>
> So the application must wait for at least 10 milliseconds after a port
> indicates that it is suspended, to make sure this port has entered
> suspended state before initiating this port resume using the Force
> Port Resume bit. This bit is for NXP controller, not EHCI compatible.
>
> Signed-off-by: Changming Huang
> Signed-off-by: Ramneek Mehresh
> ---
> Change in v2:
> - move sleep out of spin-lock and add more comment for this workaround
This patch is incomplete.
> --- a/drivers/usb/host/ehci-hub.c
> +++ b/drivers/usb/host/ehci-hub.c
> @@ -310,6 +310,13 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
> }
> spin_unlock_irq(&ehci->lock);
>
> + if (changed && ehci_has_fsl_susp_errata(ehci))
> + /* Wait for at least 10 millisecondes to ensure the controller
> + * enter the suspend status before initiating a port resume
> + * using the Fore Port Resume bit (Not-EHCI compatible).
> + */
The proper style for multi-line comments is:
/*
* Wait for ...
* ...
*/
Also, "Force" is misspelled.
> + usleep_range(1, 2);
> +
> if ((changed && ehci->has_tdi_phy_lpm) || fs_idle_delay) {
> /*
>* Wait for HCD to enter low-power mode or for the bus
The patch does not change the code around line 1190 in the original
file:
/* After above check the port must be connected.
* Set appropriate bit thus could put phy into low power
* mode if we have tdi_phy_lpm feature
*/
temp &= ~PORT_WKCONN_E;
temp |= PORT_WKDISC_E | PORT_WKOC_E;
ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
This code sets the PORT_SUSPEND bit but does not have a 10-ms delay.
You need to add a delay here.
Alan Stern
[PATCH] x86/traps: get rid of unnecessary preempt_disable/preempt_enable_no_resched
Exception handlers which may run on IST stack calls ist_enter() at the
start of execution and ist_exit() in the end. The ist_enter() disables
preemption unconditionally and ist_exit() enables it.
Besides this, such exception handlers do additional unnecessary calls
of preempt_disable() and preempt_enable_no_resched() after/before
ist_enter()/ist_exit(). Let's get rid from them.
Signed-off-by: Alexander Kuleshov
---
arch/x86/kernel/traps.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index bd4e3d4..5fbff64 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -563,11 +563,9 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs,
long error_code)
* as we may switch to the interrupt stack.
*/
debug_stack_usage_inc();
- preempt_disable();
cond_local_irq_enable(regs);
do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, NULL);
cond_local_irq_disable(regs);
- preempt_enable_no_resched();
debug_stack_usage_dec();
exit:
ist_exit(regs);
@@ -742,14 +740,12 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
error_code)
debug_stack_usage_inc();
/* It's safe to allow irq's after DR6 has been saved */
- preempt_disable();
cond_local_irq_enable(regs);
if (v8086_mode(regs)) {
handle_vm86_trap((struct kernel_vm86_regs *) regs, error_code,
X86_TRAP_DB);
cond_local_irq_disable(regs);
- preempt_enable_no_resched();
debug_stack_usage_dec();
goto exit;
}
@@ -769,7 +765,6 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
error_code)
if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS) || user_icebp)
send_sigtrap(tsk, regs, error_code, si_code);
cond_local_irq_disable(regs);
- preempt_enable_no_resched();
debug_stack_usage_dec();
exit:
--
2.8.0.rc3.1353.gea9bdc0
Re: virtio gpu sparse warning
On Do, 2016-11-24 at 04:57 +0200, Michael S. Tsirkin wrote:
> sparse produces these warnings:
>
> drivers/gpu/drm/virtio/virtgpu_fb.c:340:27: warning: incorrect type in
> assignment (different address spaces)
> drivers/gpu/drm/virtio/virtgpu_fb.c:340:27:expected char [noderef]
> *screen_base
> drivers/gpu/drm/virtio/virtgpu_fb.c:340:27:got void *vmap
>
> This is because the expected type is void __iomem *, while
> virtio gpu object is void *vmap.
>
> We could just cast the warning away but I'm not sure this
> is not a symptom of an actual problem. For example, might
> some code call iounmap on this address?
Nobody is ever going to unmap that, the kernel will simply use given
address to access the framebuffer.
Actually it looks like this (in include/linux/fb.h):
union {
char __iomem *screen_base; /* Virtual address */
char *screen_buffer;
};
and given that the virtio always uses normal ram as backing storage for
the framebuffer we should simply s/screen_base/screen_buffer/. I'll go
prepare a patch.
cheers,
Gerd
Re: [GIT PULL] stm class/intel_th: Updates for char-misc-next
On Wed, Nov 23, 2016 at 01:45:16PM +0200, Alexander Shishkin wrote: > Hi Greg, > > Let's try again. These are my updates for STM and Intel TH for > v4.10. Please consider pulling. Thanks. > > The following changes since commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6: > > Linux 4.9-rc5 (2016-11-13 10:32:32 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git > tags/stm-for-greg-20161118 Pulled and pushed out, thanks. greg k-h
Re: [GIT PULL] phy: for 4.10
On Fri, Nov 18, 2016 at 06:58:23PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Please find the pull request for 4.10 merge window below. Major changes > include adding anew phy driver for meson8b/gxbb SoC, removing a couple > of phy drivers from unsupported SoCs, adding sysfs entry to perform > usb role swap in rcar SoC and adding support for otg port in rk3399. > It also includes other minor fixes and cleanups. > > >From this -rc cycle onwards, the phy tree is also included in linux-next. > So we shouldn't get into the fiasco we got into during the last merge > window (when phy tree conflicted with extcon) when it reaches your tree. > > Let me know if you want me to change something. Pulled and pushed out, thanks. greg k-h
Re: [GIT PULL] extcon next for v4.10
On Tue, Nov 22, 2016 at 03:08:03PM +0900, Chanwoo Choi wrote: > Dear Greg, > > This is extcon-next pull request for v4.10. I add detailed description of > this pull request on below. Please pull extcon with following updates. > > Best Regards, > Chanwoo Choi > > The following changes since commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6: > > Linux 4.9-rc5 (2016-11-13 10:32:32 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git > tags/extcon-next-for-4.10 Pulled and pushed out, thanks. greg k-h
Re: [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
On 28/11/16 07:24, Sekhar Nori wrote: > On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote: >> It has been determined that the maximum resolution supported correctly >> by tilcdc rev1 on da850 SoCs is 800x600@60. Due to memory throughput >> constraints we must filter out higher modes. >> >> Specify the max-bandwidth property for the display node for >> da850-based boards. >> >> Signed-off-by: Bartosz Golaszewski >> --- >> arch/arm/boot/dts/da850.dtsi | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi >> index 8e30d9b..9b7c444 100644 >> --- a/arch/arm/boot/dts/da850.dtsi >> +++ b/arch/arm/boot/dts/da850.dtsi >> @@ -452,6 +452,7 @@ >> compatible = "ti,da850-tilcdc"; >> reg = <0x213000 0x1000>; >> interrupts = <52>; >> +max-bandwidth = <2880>; > > If this is effectively the max pixel clock that the device supports, > then why not use the datasheet specified value of 37.5 MHz (Tc = 26.66 ns). There's a separate property for max-pixelclock. This one is maximum pixels per second (which does sound almost the same), but the doc says it's about the particular memory interface + LCDC combination. But this 'max-bandwidth' does sound quite odd, as the it really should be bytes, not pixels... Bad bindings again, which we just have to use. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 10/30] perf clang: Add builtin clang support ant test case
On 2016/11/27 1:17, Alexei Starovoitov wrote:
On Sat, Nov 26, 2016 at 07:03:34AM +, Wang Nan wrote:
Add basic clang support in clang.cpp and test__clang() testcase. The
first testcase checks if builtin clang is able to generate LLVM IR.
tests/clang.c is a proxy. Real testcase resides in
utils/c++/clang-test.cpp in c++ and exports C interface to perf test
subsystem.
Test result:
$ perf test -v clang
51: Test builtin clang support :
51.1: Test builtin clang compile C source to IR :
--- start ---
test child forked, pid 13215
test child finished with 0
end
Test builtin clang support subtest 0: Ok
Signed-off-by: Wang Nan
...
+static CompilerInvocation *
+createCompilerInvocation(StringRef& Path, DiagnosticsEngine& Diags)
+{
+ llvm::opt::ArgStringList CCArgs {
+ "-cc1",
+ "-triple", "bpf-pc-linux",
+ "-fsyntax-only",
+ "-ferror-limit", "19",
+ "-fmessage-length", "127",
why such limits?
+ "-O2",
+ "-nostdsysteminc",
+ "-nobuiltininc",
+ "-vectorize-loops",
+ "-vectorize-slp",
Thank you for pointing these out. These arguments are get by analysising
the clang example:
https://llvm.org/svn/llvm-project/cfe/branches/ggreif/CallInst-operands/examples/clang-interpreter/main.cpp
The above example create a C compiler using clang::driver::Driver (bcc
also uses driver).
I form the argument list according to arglist the driver created for its CI,
and leaves arguments I'm not quite sure unchanged.
why above two flags are needed?
+ "-Wno-unused-value",
+ "-Wno-pointer-sign",
these two -Wno makes sense. please add the comment to explain the reasons.
They are inherited from samples/bpf/Makefile to suppress some warning
when include kernel headers.
Thank you.
Re: [PATCH v2] usb: xhci: Remove unuseful 'return' and 'break' statement
On 28 November 2016 at 15:21, Greg KH wrote: > On Mon, Nov 28, 2016 at 02:29:25PM +0800, Baolin Wang wrote: >> Hi Mathias, >> >> On 24 November 2016 at 19:16, Baolin Wang wrote: >> > Since these 'return' statements are not generally useful in void >> > function, remove them. Also remove one unuseful 'break' statement >> > in xhci_setup_addressable_virt_dev() function. >> > >> > Signed-off-by: Baolin Wang >> > --- >> > Changes since v1: >> > - Add description of removing 'break' statement in commitlog. >> > --- >> >> Could you apply this patch if there are no other comments? Thanks. > > Less than a week response for a simple cleanup patch? Why the rush and > pressure? Relax, this really isn't an important patch... I am sorry for the pressure, I just thought it is one simple cleanup patch. It is okay for me to wait for. -- Baolin.wang Best Regards
Re: [PATCH v6 0/6] Introduce ZONE_CMA
On Mon, Nov 07, 2016 at 03:25:01PM +0900, Joonsoo Kim wrote: > On Fri, Oct 14, 2016 at 12:03:10PM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > Hello, > > > > Changes from v5 > > o Add acked/reviewed-by tag from Vlastimil and Aneesh > > o Rebase on next-20161013 > > o Cosmetic change on patch 1 > > o Optimize span of ZONE_CMA on multiple node system > > Hello, Andrew. > > I got some acked/reviewed-by tags from some of main MM developers who > are actually familiar/associated with this change. Could you merge > this patchset to your tree to get more test coverage? > > If I need to do more things to merge this patchset, please let me know > about it. Hello, Andrew. Could I get your answer about this patchset? Thanks.
Re: [PATCH] cpuset: Remove unused 'struct cpuset*' variable
On Sat 26-11-16 08:42:40, Li Zefan wrote:
> On 2016/11/25 17:46, Arnd Bergmann wrote:
> > On Friday, November 25, 2016 1:46:04 PM CET Zefan Li wrote:
> >> On 2016/11/25 12:55, Kirtika Ruchandani wrote:
> >>> 'struct cpuset* cs' that is set but not used, was introduced in commit
> >>> 1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration from
> >>> subtree_control enabling").
> >>> cpuset_cancel_attach() uses css_cs(css) instead. Compiling with W=1
> >>> gives the folllowing harmless warning, which we'd like to fix to
> >>> reduce the noise with W=1 in the kernel.
> >>>
> >>> kernel/cpuset.c: In function ‘cpuset_cancel_attach’:
> >>> kernel/cpuset.c:1502:17: warning: variable ‘cs’ set but not used
> >>> [-Wunused-but-set-variable]
> >>> struct cpuset *cs;
> >>> ^
> >>>
> >>> Fixes: 1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration
> >>> from subtree_control enabling").
> >>
> >> This isn't a bug, so I don't think this tag is proper.
> >
> > I think it's ok since the changelog makes it clear that the
> > warning is harmless. It's still useful information to know
> > what commit introduced the warning, and the warning is fixed
> > by this patch.
> >
>
> People like stable tree maintainers use scripts to find out bug fixes
> that needs to be backported to older kernels, and those scripts tracks
> the Fixes tag. No doubt this patch doesn't require backporting, so
> it's better avoid using this tag.
I would disagree here. Randomly picking up fixes just because they are
Fixing some commit is just too dangerous for the stable trees. Fixes tag
should tell what was the culprit of the issue fixed by the patch,
nothing more and nothing less.
--
Michal Hocko
SUSE Labs
Re: [patch] mm, slab: faster active and free stats
On Fri, Nov 11, 2016 at 02:30:39AM -0800, David Rientjes wrote: > On Fri, 11 Nov 2016, Joonsoo Kim wrote: > > > Hello, David. > > > > Maintaining acitve/free_slab counters looks so complex. And, I think > > that we don't need to maintain these counters for faster slabinfo. > > Key point is to remove iterating n->slabs_partial list. > > > > We can calculate active slab/object by following equation as you did in > > this patch. > > > > active_slab(n) = n->num_slab - the number of free_slab > > active_object(n) = n->num_slab * cachep->num - n->free_objects > > > > To get the number of free_slab, we need to iterate n->slabs_free list > > but I guess it would be small enough. > > > > If you don't like to iterate n->slabs_free list in slabinfo, just > > maintaining the number of slabs_free would be enough. > > > > Hi Joonsoo, > > It's a good point, although I don't think the patch has overly complex > logic to keep track of slab state. > > We don't prefer to do any iteration in get_slabinfo() since users can > read /proc/slabinfo constantly; it's better to just settle the stats when > slab state changes instead of repeating an expensive operation over and > over if someone is running slabtop(1) or /proc/slabinfo is scraped > regularly for stats. > > That said, I imagine there are more clever ways to arrive at the same > answer, and you bring up a good point about maintaining a n->num_slabs and > n->free_slabs rather than n->active_slabs and n->free_slabs. > > I don't feel strongly about either approach, but I think some improvement, > such as what this patch provides, is needed to prevent how expensive > simply reading /proc/slabinfo can be. Hello, Sorry for long delay. I agree that this improvement is needed. Could you try the approach that maintains n->num_slabs and n->free_slabs? I guess that it would be simpler than this patch so more maintainable. Thanks.
Re: Adding a .platform_init callback to sdhci_arasan_ops
+Sai for Xilinx perspective. On 25.11.2016 16:24, Sebastian Frias wrote: > Hi, > > When using the Arasan SDHCI HW IP, there is a set of parameters called > "Hardware initialized registers" > > (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4 > AHB Host Controller", revision 6.0 document) > > In some platforms those signals are connected to registers that need to > be programmed at some point for proper driver/HW initialisation. > > I found that the 'struct sdhci_ops' contains a '.platform_init' callback > that is called from within 'sdhci_pltfm_init', and that seems a good > candidate for a place to program those registers (*). > > Do you agree? > > Best regards, > > Sebastian > > > (*): This has been prototyped on 4.7 as working properly. > However, upstream commit: > > commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5 > Author: Douglas Anderson > Date: Mon Jun 20 10:56:47 2016 -0700 > > mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399 > ... > > could affect this solution because of the way the 'sdhci_arasan_of_match' > struct is used after that commit. >
Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup
On Sun, Nov 27, 2016 at 04:59:14PM -0700, Jonathan Corbet wrote: > On Fri, 25 Nov 2016 22:58:14 +0100 > Peter Zijlstra wrote: > > > Not a fan of this. The atomic_ops.txt file needs a lot of love, and I > > wouldn't want to edit a .rst file. > > > > Then again, I probably won't actually get around to fixing this document > > any time soon either. > > > > But if and when I would get around to it, I'll have to change it back to > > a regular .txt file. > > Peter, could you please describe what the trouble with RST is? Mostly that its not txt. I don't know what RST is, and I frankly don't care. For me changing this is 'make work', and I really don't need that. Changing this away from txt will simply make want to write documentation less, because it means having to figure out wtf RST is first, which means I'll simply won't do it. > Most of > the files in Documentation/ are already almost in RST format; should we > change them to something else? :) Why change them? What was wrong with txt to begin with?
Re: linux-next: build warning after merge of the wireless-drivers-next tree
Stephen Rothwell writes:
> Hi all,
>
> After merging the wireless-drivers-next tree, today's linux-next build
> (x86_64 allmodconfig) produced this warning:
>
> In file included from include/linux/usb/ch9.h:35:0,
> from include/linux/usb.h:5,
> from
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:32:
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c: In function
> 'rtl8xxxu_fill_txdesc_v2':
> include/linux/device.h:1214:36: warning: 'rate' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> #define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
> ^
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:4841:6: note: 'rate'
> was declared here
> u32 rate;
> ^
>
> Introduced by commit
>
> b4c3d9cfb607 ("rtl8xxxu: Pass tx_info to fill_txdesc in order to have
> access to retry count")
>
> This is a correct diagnosis.
Thanks for the report. Jes, can you send a patch to fix this? (Unless
someone else beats to it.)
--
Kalle Valo
[tip:x86/urgent] x86/build: Annotate die() with noreturn to fix build warning on clang
Commit-ID: adee8705d2517f0e163ffc45e8d7f9e97a58f1f6 Gitweb: http://git.kernel.org/tip/adee8705d2517f0e163ffc45e8d7f9e97a58f1f6 Author: Peter Foley AuthorDate: Sat, 26 Nov 2016 17:22:29 -0500 Committer: Ingo Molnar CommitDate: Mon, 28 Nov 2016 07:47:22 +0100 x86/build: Annotate die() with noreturn to fix build warning on clang Fixes below warning with clang: In file included from ../arch/x86/tools/relocs_64.c:17: ../arch/x86/tools/relocs.c:977:6: warning: variable 'do_reloc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] Signed-off-by: Peter Foley Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/2016112629.673-1-pefol...@pefoley.com Signed-off-by: Ingo Molnar --- arch/x86/tools/relocs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/tools/relocs.h b/arch/x86/tools/relocs.h index f595906..1d23bf9 100644 --- a/arch/x86/tools/relocs.h +++ b/arch/x86/tools/relocs.h @@ -16,7 +16,7 @@ #include #include -void die(char *fmt, ...); +void die(char *fmt, ...) __attribute__((noreturn)); #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
[tip:x86/build] x86/build: Remove three unneeded genhdr-y entries
Commit-ID: 9190e21780dfeff524a67c6e7b806c8a9d496086
Gitweb: http://git.kernel.org/tip/9190e21780dfeff524a67c6e7b806c8a9d496086
Author: Paul Bolle
AuthorDate: Fri, 25 Nov 2016 13:41:47 +0100
Committer: Ingo Molnar
CommitDate: Mon, 28 Nov 2016 07:49:17 +0100
x86/build: Remove three unneeded genhdr-y entries
In x86's include/asm/Kbuild three entries are appended to the genhdr-y make
variable:
genhdr-y += unistd_32.h
genhdr-y += unistd_64.h
genhdr-y += unistd_x32.h
The same entries are also appended to that variable in
include/uapi/asm/Kbuild. So commit:
10b63956fce7 ("UAPI: Plumb the UAPI Kbuilds into the user header installation
and checking")
... removed these three entries from include/asm/Kbuild. But, apparently, some
merge conflict resolution re-added them.
The net effect is, in short, that the genhdr-y make variable contains these
file names twice and, as a consequence, that the corresponding headers get
installed twice. And so the build prints:
INSTALL usr/include/asm/ (65 files)
... while in reality only 62 files are installed in that directory.
Nothing breaks because of all that, but it's a good idea to finally remove
these unneeded entries nevertheless.
Signed-off-by: Paul Bolle
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1480077707-2837-1-git-send-email-pebo...@tiscali.nl
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/Kbuild | 4
1 file changed, 4 deletions(-)
diff --git a/arch/x86/include/asm/Kbuild b/arch/x86/include/asm/Kbuild
index 2cfed17..2b892e2 100644
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@ -6,10 +6,6 @@ generated-y += unistd_32_ia32.h
generated-y += unistd_64_x32.h
generated-y += xen-hypercalls.h
-genhdr-y += unistd_32.h
-genhdr-y += unistd_64.h
-genhdr-y += unistd_x32.h
-
generic-y += clkdev.h
generic-y += cputime.h
generic-y += dma-contiguous.h
[tip:x86/urgent] x86/unwind: Fix guess-unwinder regression
Commit-ID: 55f856e640560494518eaf24fe9d2d2089fba71a
Gitweb: http://git.kernel.org/tip/55f856e640560494518eaf24fe9d2d2089fba71a
Author: Josh Poimboeuf
AuthorDate: Sun, 27 Nov 2016 23:13:07 -0600
Committer: Ingo Molnar
CommitDate: Mon, 28 Nov 2016 07:47:54 +0100
x86/unwind: Fix guess-unwinder regression
My attempt at fixing some KASAN false positive warnings was rather brain
dead, and it broke the guess unwinder. With frame pointers disabled,
/proc//stack is broken:
# cat /proc/1/stack
[] 0x
Restore the code flow to more closely resemble its previous state, while
still using READ_ONCE_NOCHECK() macros to silence KASAN false positives.
Signed-off-by: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: c2d75e03d630 ("x86/unwind: Prevent KASAN false positive warnings in
guess unwinder")
Link:
http://lkml.kernel.org/r/b824f92c2c22eca5ec95ac56bd2a7c84cf0b9df9.1480309971.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/unwind_guess.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/unwind_guess.c b/arch/x86/kernel/unwind_guess.c
index b80e8bf..22881dd 100644
--- a/arch/x86/kernel/unwind_guess.c
+++ b/arch/x86/kernel/unwind_guess.c
@@ -7,11 +7,13 @@
unsigned long unwind_get_return_address(struct unwind_state *state)
{
- unsigned long addr = READ_ONCE_NOCHECK(*state->sp);
+ unsigned long addr;
if (unwind_done(state))
return 0;
+ addr = READ_ONCE_NOCHECK(*state->sp);
+
return ftrace_graph_ret_addr(state->task, &state->graph_idx,
addr, state->sp);
}
@@ -25,11 +27,12 @@ bool unwind_next_frame(struct unwind_state *state)
return false;
do {
- unsigned long addr = READ_ONCE_NOCHECK(*state->sp);
+ for (state->sp++; state->sp < info->end; state->sp++) {
+ unsigned long addr = READ_ONCE_NOCHECK(*state->sp);
- for (state->sp++; state->sp < info->end; state->sp++)
if (__kernel_text_address(addr))
return true;
+ }
state->sp = info->next_sp;
[tip:x86/urgent] x86/platform/olpc: Fix resume handler build warning
Commit-ID: 20ab6677716c7bbdcfd1cdb9aef296a0b3101f73
Gitweb: http://git.kernel.org/tip/20ab6677716c7bbdcfd1cdb9aef296a0b3101f73
Author: Borislav Petkov
AuthorDate: Sat, 26 Nov 2016 15:27:06 +0100
Committer: Ingo Molnar
CommitDate: Mon, 28 Nov 2016 07:46:03 +0100
x86/platform/olpc: Fix resume handler build warning
Fix:
arch/x86/platform/olpc/olpc-xo15-sci.c:199:12: warning: ‘xo15_sci_resume’
defined but not used [-Wunused-function]
static int xo15_sci_resume(struct device *dev)
^
which I see in randconfig builds here.
Signed-off-by: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20161126142706.13602-1...@alien8.de
Signed-off-by: Ingo Molnar
---
arch/x86/platform/olpc/olpc-xo15-sci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/platform/olpc/olpc-xo15-sci.c
b/arch/x86/platform/olpc/olpc-xo15-sci.c
index 5513084..c0533fb 100644
--- a/arch/x86/platform/olpc/olpc-xo15-sci.c
+++ b/arch/x86/platform/olpc/olpc-xo15-sci.c
@@ -196,6 +196,7 @@ static int xo15_sci_remove(struct acpi_device *device)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
static int xo15_sci_resume(struct device *dev)
{
/* Enable all EC events */
@@ -207,6 +208,7 @@ static int xo15_sci_resume(struct device *dev)
return 0;
}
+#endif
static SIMPLE_DEV_PM_OPS(xo15_sci_pm, NULL, xo15_sci_resume);
Re: 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free
Marc, could you try this patch please? I think it should be pretty clear
it should help you but running it through your use case would be more
than welcome before I ask Greg to take this to the 4.8 stable tree.
Thanks!
On Wed 23-11-16 07:34:10, Michal Hocko wrote:
[...]
> commit b2ccdcb731b666aa28f86483656c39c5e53828c7
> Author: Michal Hocko
> Date: Wed Nov 23 07:26:30 2016 +0100
>
> mm, oom: stop pre-mature high-order OOM killer invocations
>
> 31e49bfda184 ("mm, oom: protect !costly allocations some more for
> !CONFIG_COMPACTION") was an attempt to reduce chances of pre-mature OOM
> killer invocation for high order requests. It seemed to work for most
> users just fine but it is far from bullet proof and obviously not
> sufficient for Marc who has reported pre-mature OOM killer invocations
> with 4.8 based kernels. 4.9 will all the compaction improvements seems
> to be behaving much better but that would be too intrusive to backport
> to 4.8 stable kernels. Instead this patch simply never declares OOM for
> !costly high order requests. We rely on order-0 requests to do that in
> case we are really out of memory. Order-0 requests are much more common
> and so a risk of a livelock without any way forward is highly unlikely.
>
> Reported-by: Marc MERLIN
> Signed-off-by: Michal Hocko
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index a2214c64ed3c..7401e996009a 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3161,6 +3161,16 @@ should_compact_retry(struct alloc_context *ac,
> unsigned int order, int alloc_fla
> if (!order || order > PAGE_ALLOC_COSTLY_ORDER)
> return false;
>
> +#ifdef CONFIG_COMPACTION
> + /*
> + * This is a gross workaround to compensate a lack of reliable
> compaction
> + * operation. We cannot simply go OOM with the current state of the
> compaction
> + * code because this can lead to pre mature OOM declaration.
> + */
> + if (order <= PAGE_ALLOC_COSTLY_ORDER)
> + return true;
> +#endif
> +
> /*
>* There are setups with compaction disabled which would prefer to loop
>* inside the allocator rather than hit the oom killer prematurely.
> --
> Michal Hocko
> SUSE Labs
--
Michal Hocko
SUSE Labs
[tip:x86/build] x86/build: Don't use $(LINUXINCLUDE) twice
Commit-ID: 06cbbac0f57d947656a12c30a0a69d4cf0ac6dea Gitweb: http://git.kernel.org/tip/06cbbac0f57d947656a12c30a0a69d4cf0ac6dea Author: Paul Bolle AuthorDate: Fri, 25 Nov 2016 13:38:34 +0100 Committer: Ingo Molnar CommitDate: Mon, 28 Nov 2016 07:49:17 +0100 x86/build: Don't use $(LINUXINCLUDE) twice The make variable KBUILD_CFLAGS contains $(LINUXINCLUDE). But the build already picks up $(LINUXINCLUDE) from scripts/Makefile.lib. The net effect is that the (long) list of include directories is used twice. This is harmless but pointless. So stop using $(LINUXINCLUDE) twice. Signed-off-by: Paul Bolle Cc: Linus Torvalds Cc: Masahiro Yamada Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1480077514-2586-1-git-send-email-pebo...@tiscali.nl Signed-off-by: Ingo Molnar --- arch/x86/realmode/rm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile index 25012ab..4463fa7 100644 --- a/arch/x86/realmode/rm/Makefile +++ b/arch/x86/realmode/rm/Makefile @@ -69,7 +69,7 @@ $(obj)/realmode.relocs: $(obj)/realmode.elf FORCE # --- -KBUILD_CFLAGS := $(LINUXINCLUDE) $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \ +KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \ -I$(srctree)/arch/x86/boot KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ GCOV_PROFILE := n
[tip:x86/boot] x86/boot/64: Optimize fixmap page fixup
Commit-ID: 6248f4567442081994ad61c63bd9870e147983e0 Gitweb: http://git.kernel.org/tip/6248f4567442081994ad61c63bd9870e147983e0 Author: Borislav Petkov AuthorDate: Fri, 25 Nov 2016 12:14:48 +0100 Committer: Ingo Molnar CommitDate: Mon, 28 Nov 2016 07:45:17 +0100 x86/boot/64: Optimize fixmap page fixup Single-stepping through head_64.S made me look at the fixmap page PTEs fixup loop: So we're going through the whole level2_fixmap_pgt 4K page, looking at whether PAGE_PRESENT is set in those PTEs and add the delta between where we're compiled to run and where we actually end up running. However, if that delta is 0 (most cases) we go through all those 512 PTEs for no reason at all. Oh well, we add 0 but that's no reason to me. Skipping that useless fixup gives us a boot speedup of 0.004 seconds in my guest. Not a lot but considering how cheap it is, I'll take it. Here is the printk time difference: before: ... [0.00] tsc: Marking TSC unstable due to TSCs unsynchronized [0.013590] Calibrating delay loop (skipped), value calculated using timer frequency.. 8027.17 BogoMIPS (lpj=16054348) [0.017094] pid_max: default: 32768 minimum: 301 ... after: ... [0.00] tsc: Marking TSC unstable due to TSCs unsynchronized [0.009587] Calibrating delay loop (skipped), value calculated using timer frequency.. 8026.86 BogoMIPS (lpj=16053724) [0.013090] pid_max: default: 32768 minimum: 301 ... For the other two changes converting naked numbers to defines: # arch/x86/kernel/head_64.o: textdata bss dec hex filename 1124 2908644096 296084 48494 head_64.o.before 1124 2908644096 296084 48494 head_64.o.after md5: 87086e202588939296f66e892414ffe2 head_64.o.before.asm 87086e202588939296f66e892414ffe2 head_64.o.after.asm Signed-off-by: Borislav Petkov Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20161125111448.23623-1...@alien8.de Signed-off-by: Ingo Molnar --- arch/x86/kernel/head_64.S | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index b4421cc..a4a814f 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -147,6 +147,9 @@ startup_64: decl%ecx jnz 1b + test %rbp, %rbp + jz .Lskip_fixup + /* * Fixup the kernel text+data virtual addresses. Note that * we might write invalid pmds, when the kernel is relocated @@ -154,9 +157,9 @@ startup_64: * beyond _end. */ leaqlevel2_kernel_pgt(%rip), %rdi - leaq4096(%rdi), %r8 + leaqPAGE_SIZE(%rdi), %r8 /* See if it is a valid page table entry */ -1: testb $1, 0(%rdi) +1: testb $_PAGE_PRESENT, 0(%rdi) jz 2f addq%rbp, 0(%rdi) /* Go to the next page */ @@ -167,6 +170,7 @@ startup_64: /* Fixup phys_base */ addq%rbp, phys_base(%rip) +.Lskip_fixup: movq$(early_level4_pgt - __START_KERNEL_map), %rax jmp 1f ENTRY(secondary_startup_64)
Re: [PATCH v2] usb: xhci: Remove unuseful 'return' and 'break' statement
On Mon, Nov 28, 2016 at 02:29:25PM +0800, Baolin Wang wrote: > Hi Mathias, > > On 24 November 2016 at 19:16, Baolin Wang wrote: > > Since these 'return' statements are not generally useful in void > > function, remove them. Also remove one unuseful 'break' statement > > in xhci_setup_addressable_virt_dev() function. > > > > Signed-off-by: Baolin Wang > > --- > > Changes since v1: > > - Add description of removing 'break' statement in commitlog. > > --- > > Could you apply this patch if there are no other comments? Thanks. Less than a week response for a simple cleanup patch? Why the rush and pressure? Relax, this really isn't an important patch... greg k-h
Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
On 25 November 2016 at 21:00, Mark Brown wrote: > On Tue, Nov 22, 2016 at 09:40:07AM +1100, NeilBrown wrote: > >> I agree that the question of where the responsibility for information >> aggregation lies is open for discussion. If fact all details on how >> things should work are always open for discussion. >> I don't agree that this is the main different between our positions, >> though I can see how you might get that impression. > >> You could even fix them so they look *exactly* like the notifiers that >> Baolin is proposing. This is my key point. It is not the end result >> that I particularly object to (though I do object to some details). It > > Ah, OK. This really hadn't been at all clear - both Baolin and I had > the impression that the it was both that were blockers for you. What > were the details here? > >> is the process of getting to the end result that I don't like. If the >> current system doesn't work and something different is needed, then the >> correct thing to do is to transform the existing system into something >> new that works better. This should be a clear series of steps. Each > > Sometimes there's something to be said for working out what we want > things to look like before setting out to make these gradual > refactorings and sometimes the refactorings are just more pain than > they're worth, especially when they go across subsystems. In this case > I do worry about the cross subsystem aspect causing hassle, it may be > more practical to do anything that represents an interface change by > adding the new interface, converting the users to it and then removing > the old interface. > > At the very least the series should grow to incorporate conversion of > the existing users though. Baolin, I think this does need adding to the > series but probably best to think about how to do it - some of Neil's > suggestions for incremental steps do seem like they should be useful > for organizing things here, probably we can get some things that can be > done internally within individual drivers merged while everything else > is under discussion. OK. I will think about how to incorporate conversion of the existing users according to Neil's suggestion. > >> But I think here my key point got lost too, in part because it was hard >> to refer to an actual instance. >> My point was that in the present patch set, the "usb charger" is given >> a name which is dependant on discovery order, and only supports >> lookup-by-name. This cannot work. > > There's two bits here: one is the way names are assigned and the other > is the lookup by name. I agree that the lookup by name isn't > particularly useful as things stand, that could just be dropped until > some naming mechanism is added. We'd be more likely to use phandles in > DT systems, I don't know what ACPI systems would look like but I guess > it'd be something similar. > >> If they supported lookup by phy-name or lookup-by-active (i.e. "find me >> any usb-charger which has power available"), or look up by some other >> attribute, then discover-order naming could work. But the only >> lookup-mechanism is by-name, and the names aren't reliably stable. So >> the name/lookup system proposed cannot possibly do anything useful >> with more than one usb_charger. > > Baolin, I think adding a DT binding and lookup mechanism makes sense > here - do you agree? Yes, I agree. But 'usb charger' is one virtual device and we described nothing in DT about 'usb charger'. But as you and Neil said, we need one usful method to look up the USB charger. I will think about that. Thanks. -- Baolin.wang Best Regards
Re: drm: GPF in drm_getcap
On 28/11/16 03:55 PM, Daniel Vetter wrote: > On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann wrote: >> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov wrote: >>> grep "card0" dmesg: >>> [5.298617] device: 'card0': device_add >>> [5.298946] PM: Adding info for No Bus:card0 >>> [6.436178] device: 'card0': device_add >>> [6.436488] PM: Adding info for No Bus:card0 >>> >>> >>> # ls -l /dev/dri/card0 >>> crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0 >>> >>> # ls -lt /sys/class/drm/card0/device/ >>> ls: cannot access /sys/class/drm/card0/device/: No such file or directory >>> >>> # ls -lt /sys/class/drm/card0/device/driver >>> ls: cannot access /sys/class/drm/card0/device/driver: No such file or >>> directory >> >> Looks like vgem. Something like this should help: >> >> https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2 >> >> I wonder whether it would be more appropriate to return -ENOTSUPP rather >> than 0. Can't see how that would matter FWIW. > Seems a bit overkill, but can't hurt. This is most likely a > regression, probably introduced in > > commit f837297ad82480024d3ad08cd84f6670bcafa862 > Author: Michel Dänzer > Date: Mon Aug 8 16:23:39 2016 +0900 > > drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2 > > Michel, can you pls take care of this? Either with a minimal fix, or > by adopting David's patch? Can't we just use David's patch as-is? If not, I think Dmitry or someone else would be better equipped than me to extract a minimal fix from it and test it. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Re: [PATCH] net: fec: turn on device when extracting statistics
28.11.2016 04:29, David Miller пишет:
> From: Nikita Yushchenko
> Date: Fri, 25 Nov 2016 13:02:00 +0300
>
>> +int i, ret;
>> +
>> +ret = pm_runtime_get_sync(&fep->pdev->dev);
>> +if (IS_ERR_VALUE(ret)) {
>> +memset(data, 0, sizeof(*data) * ARRAY_SIZE(fec_stats));
>> +return;
>> +}
>
> This really isn't the way to do this.
>
> When the device is suspended and the clocks are going to be stopped,
> you must fetch the statistic values into a software copy and provide
> those if the device is suspended when statistics are requested.
Ok, can do that, although can't see what's wrong with waking device
here. The situation of requesting stats on down device isn't something
widely used, thus keeping handling of that as local as possible looks
better for me.
[PATCH] vxlan: fix a potential issue when create a new vxlan fdb entry.
vxlan_fdb_append may return error, so add the proper check,
otherwise it will cause memory leak.
Signed-off-by: Haishuang Yan
---
drivers/net/vxlan.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 21e92be..3b7b237 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -611,6 +611,7 @@ static int vxlan_fdb_create(struct vxlan_dev *vxlan,
struct vxlan_rdst *rd = NULL;
struct vxlan_fdb *f;
int notify = 0;
+ int rc = 0;
f = __vxlan_find_mac(vxlan, mac);
if (f) {
@@ -641,8 +642,7 @@ static int vxlan_fdb_create(struct vxlan_dev *vxlan,
if ((flags & NLM_F_APPEND) &&
(is_multicast_ether_addr(f->eth_addr) ||
is_zero_ether_addr(f->eth_addr))) {
- int rc = vxlan_fdb_append(f, ip, port, vni, ifindex,
- &rd);
+ rc = vxlan_fdb_append(f, ip, port, vni, ifindex, &rd);
if (rc < 0)
return rc;
@@ -673,7 +673,11 @@ static int vxlan_fdb_create(struct vxlan_dev *vxlan,
INIT_LIST_HEAD(&f->remotes);
memcpy(f->eth_addr, mac, ETH_ALEN);
- vxlan_fdb_append(f, ip, port, vni, ifindex, &rd);
+ rc = vxlan_fdb_append(f, ip, port, vni, ifindex, &rd);
+ if (rc < 0) {
+ kfree(f);
+ return rc;
+ }
++vxlan->addrcnt;
hlist_add_head_rcu(&f->hlist,
--
1.8.3.1
RE: BALANCE PAYMENT
Dear Sir/s, Please see attached. Thanks and regards, Accounts Department Al Omraniya Trading Co. LLC P.O. Box: 10757, Al Khabaisi Area, Deira 2, Dubai, U.A.E. Tel: +971 4 268 2730 / Fax: +971 4 268 4117
RE: [PATCH 0/7] hv: CPU onlining/offlining fixes and improvements
> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Sunday, November 27, 2016 01:06 > To: Vitaly Kuznetsov > Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; KY Srinivasan > ; Haiyang Zhang ; Dexuan Cui > > Subject: Re: [PATCH 0/7] hv: CPU onlining/offlining fixes and improvements > > On Fri, 25 Nov 2016 13:48:36 +0100 > Vitaly Kuznetsov wrote: > > > Some time ago we forbade CPU offlining for Hyper-V and this was sufficient > > if you boot with all CPUs onlined. Turns out, people may want to limit the > > number online CPUs by passing 'maxcpus=' kernel parameter and we hit a > > crash in Hyper-V code in this case. After some thinking, I think we may not > > only fix the crash but also make the offlining prevention fine-grained: we > > need to prevent from offlining CPUs which have VMBus channels attached > > only. All offlined CPUs may always be onlined. > > > > As a temporary solution this is ok, but long term we need to support > dynamic CPU online/offline. If a CPU is bound to some channels, it seems impossible to make it offline, unless Hyper-V supplies a mechanism to dynamically rebind the channels (i.e. without closing & opening the channels) to another CPU, e.g. CPU0. Currently it looks there is no such mechanism. For CPU online, my understanding is: this patchset of Vitaly actually makes it work (see PATCH 6/7). Thanks, -- Dexuan
[PATCH v2] clkdev: add devm_of_clk_get()
Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
This patch adds it. This is based on devm_clk_get()
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
- update git log
drivers/clk/clkdev.c | 26 ++
include/linux/clk.h | 7 +++
2 files changed, 33 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 89cc700..93a613b 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -55,6 +55,32 @@ struct clk *of_clk_get(struct device_node *np, int index)
}
EXPORT_SYMBOL(of_clk_get);
+static void devm_of_clk_release(struct device *dev, void *res)
+{
+ clk_put(*(struct clk **)res);
+}
+
+struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index)
+{
+ struct clk **ptr, *clk;
+
+ ptr = devres_alloc(devm_of_clk_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ clk = of_clk_get(np, index);
+ if (!IS_ERR(clk)) {
+ *ptr = clk;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return clk;
+}
+EXPORT_SYMBOL(devm_of_clk_get);
+
static struct clk *__of_clk_get_by_name(struct device_node *np,
const char *dev_id,
const char *name)
diff --git a/include/linux/clk.h b/include/linux/clk.h
index a89ba4e..33cd540 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -502,6 +502,8 @@ struct of_phandle_args;
#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
struct clk *of_clk_get(struct device_node *np, int index);
+struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index);
struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
#else
@@ -509,6 +511,11 @@ static inline struct clk *of_clk_get(struct device_node
*np, int index)
{
return ERR_PTR(-ENOENT);
}
+static inline struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index)
+{
+ return ERR_PTR(-ENOENT);
+}
static inline struct clk *of_clk_get_by_name(struct device_node *np,
const char *name)
{
--
1.9.1
Re: drm: GPF in drm_getcap
On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann wrote: > On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov wrote: >> grep "card0" dmesg: >> [5.298617] device: 'card0': device_add >> [5.298946] PM: Adding info for No Bus:card0 >> [6.436178] device: 'card0': device_add >> [6.436488] PM: Adding info for No Bus:card0 >> >> >> # ls -l /dev/dri/card0 >> crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0 >> >> # ls -lt /sys/class/drm/card0/device/ >> ls: cannot access /sys/class/drm/card0/device/: No such file or directory >> >> # ls -lt /sys/class/drm/card0/device/driver >> ls: cannot access /sys/class/drm/card0/device/driver: No such file or >> directory > > Looks like vgem. Something like this should help: > > https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2 > > I wonder whether it would be more appropriate to return -ENOTSUPP rather than > 0. Seems a bit overkill, but can't hurt. This is most likely a regression, probably introduced in commit f837297ad82480024d3ad08cd84f6670bcafa862 Author: Michel Dänzer Date: Mon Aug 8 16:23:39 2016 +0900 drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2 Michel, can you pls take care of this? Either with a minimal fix, or by adopting David's patch? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
RE: BALANCE PAYMENT
Dear Sir/s, Please see attached. Thanks and regards, Accounts Department Al Omraniya Trading Co. LLC P.O. Box: 10757, Al Khabaisi Area, Deira 2, Dubai, U.A.E. Tel: +971 4 268 2730 / Fax: +971 4 268 4117
Re: [PATCH 2/2] rcu: Force resched_cpu when jiffies >= rcu_state.jiffies_resched
On Sat, Nov 26, 2016 at 04:00:46AM -0800, Paul E. McKenney wrote:
> On Fri, Nov 25, 2016 at 12:34:26AM -0800, Paul E. McKenney wrote:
> > On Tue, Nov 22, 2016 at 05:12:20PM +0900, Byungchul Park wrote:
> > > On Wed, Nov 09, 2016 at 03:32:15PM +0900, Byungchul Park wrote:
> > > > Currently rcu code forces CPU into scheduler when jiffies >=
> > > > rcu_state.gp_start + jiffies_till_sched_qs, via resched_cpu().
> > > >
> > > > It would be better to force CPU into scheduler when jiffies >=
> > > > rcu_state.jiffies_resched, too.
> > >
> > > Hello,
> > >
> > > I think these two patches are necessary to call resched_cpu() even in
> > > case of jiffies >= rcu_state.jiffies_resched, too. Am I wrong?
> > >
> > > It would be appriciated if you let me know if I was wrong.
> >
> > My current thought is that both the "if" statement and the call to
> > resched_cpu() should be removed, but I am still testing and working
> > through the timing.
> >
> > Either way, I do very much appreciate your having called my attention
> > to this code!
>
> And the patch shown below seems to do the trick. Thoughts?
Hello,
I see.. I didn't check the log 'rcu: Stop treating in-kernel CPU-bound
workloads as errors'.
If you are convinced to remove them, no objection.
Thank you,
Byungchul
>
> Thanx, Paul
>
>
>
> commit d2db185bfee894c573faebed93461e9938bdbb61
> Author: Paul E. McKenney
> Date: Fri Nov 25 00:07:23 2016 -0800
>
> rcu: Remove short-term CPU kicking
>
> Commit 4914950aaa12d ("rcu: Stop treating in-kernel CPU-bound workloads
> as errors") added a (relatively) short-timeout call to resched_cpu().
> This was inspired by as issue that was fixed by b7e7ade34e61 ("sched/core:
> Fix remote wakeups"). But given that this issue was fixed, it is time
> for the current commit to remove this call to resched_cpu().
>
> Reported-by: Byungchul Park
> Signed-off-by: Paul E. McKenney
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 5f4f80d07852..91a68e4e6671 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -1345,12 +1345,6 @@ static int rcu_implicit_dynticks_qs(struct rcu_data
> *rdp,
> rdp->rsp->jiffies_resched += 5; /* Re-enable beating. */
> }
>
> - /* And if it has been a really long time, kick the CPU as well. */
> - if (ULONG_CMP_GE(jiffies,
> - rdp->rsp->gp_start + 2 * jiffies_till_sched_qs) ||
> - ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
> - resched_cpu(rdp->cpu); /* Force CPU into scheduler. */
> -
> return 0;
> }
>
[patch net] net: dsa: fix unbalanced dsa_switch_tree reference counting
_dsa_register_switch() gets a dsa_switch_tree object either via
dsa_get_dst() or via dsa_add_dst(). Former path does not increase kref
in returned object (resulting into caller not owning a reference),
while later path does create a new object (resulting into caller owning
a reference).
The rest of _dsa_register_switch() assumes that it owns a reference, and
calls dsa_put_dst().
This causes a memory breakage if first switch in the tree initialized
successfully, but second failed to initialize. In particular, freed
dsa_swith_tree object is left referenced by switch that was initialized,
and later access to sysfs attributes of that switch cause OOPS.
To fix, need to add kref_get() call to dsa_get_dst().
Signed-off-by: Nikita Yushchenko
Fixes: 83c0afaec7b7 ("net: dsa: Add new binding implementation")
Reviewed-by: Andrew Lunn
---
net/dsa/dsa2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index f8a7d9aab437..5fff951a0a49 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -28,8 +28,10 @@ static struct dsa_switch_tree *dsa_get_dst(u32 tree)
struct dsa_switch_tree *dst;
list_for_each_entry(dst, &dsa_switch_trees, list)
- if (dst->tree == tree)
+ if (dst->tree == tree) {
+ kref_get(&dst->refcount);
return dst;
+ }
return NULL;
}
--
2.1.4
[PATCH v4 2/2] usb: dwc3: core: Support the dwc3 host suspend/resume
For some mobile devices with strict power management, we also want to suspend
the host when the slave is detached for power saving. Thus we add the host
suspend/resume functions to support this requirement.
Signed-off-by: Baolin Wang
---
Changes since v3:
- No updates.
Changes since v2:
- Remove pm_children_suspended() and other unused macros.
Changes since v1:
- Add pm_runtime.h head file to avoid kbuild error.
---
drivers/usb/dwc3/Kconfig |7 +++
drivers/usb/dwc3/core.c | 26 +-
drivers/usb/dwc3/core.h | 15 +++
drivers/usb/dwc3/host.c | 37 +
4 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index a45b4f1..47bb2f3 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -47,6 +47,13 @@ config USB_DWC3_DUAL_ROLE
endchoice
+config USB_DWC3_HOST_SUSPEND
+ bool "Choose if the DWC3 host (xhci) can be suspend/resume"
+ depends on USB_DWC3_HOST=y || USB_DWC3_DUAL_ROLE=y
+ help
+ We can suspend the host when the slave is detached for power saving,
+ and resume the host when one slave is attached.
+
comment "Platform Glue Driver Support"
config USB_DWC3_OMAP
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9a4a5e4..7ad4bc3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1091,6 +1091,7 @@ static int dwc3_probe(struct platform_device *pdev)
pm_runtime_use_autosuspend(dev);
pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
pm_runtime_enable(dev);
+ pm_suspend_ignore_children(dev, true);
ret = pm_runtime_get_sync(dev);
if (ret < 0)
goto err1;
@@ -1215,15 +1216,27 @@ static int dwc3_remove(struct platform_device *pdev)
static int dwc3_suspend_common(struct dwc3 *dwc)
{
unsigned long flags;
+ int ret;
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+ spin_lock_irqsave(&dwc->lock, flags);
+ dwc3_gadget_suspend(dwc);
+ spin_unlock_irqrestore(&dwc->lock, flags);
+ break;
case USB_DR_MODE_OTG:
+ ret = dwc3_host_suspend(dwc);
+ if (ret)
+ return ret;
+
spin_lock_irqsave(&dwc->lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
break;
case USB_DR_MODE_HOST:
+ ret = dwc3_host_suspend(dwc);
+ if (ret)
+ return ret;
default:
/* do nothing */
break;
@@ -1245,12 +1258,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+ spin_lock_irqsave(&dwc->lock, flags);
+ dwc3_gadget_resume(dwc);
+ spin_unlock_irqrestore(&dwc->lock, flags);
+ break;
case USB_DR_MODE_OTG:
+ ret = dwc3_host_resume(dwc);
+ if (ret)
+ return ret;
+
spin_lock_irqsave(&dwc->lock, flags);
dwc3_gadget_resume(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
- /* FALLTHROUGH */
+ break;
case USB_DR_MODE_HOST:
+ ret = dwc3_host_resume(dwc);
+ if (ret)
+ return ret;
default:
/* do nothing */
break;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b585a30..db41908 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1226,4 +1226,19 @@ static inline void dwc3_ulpi_exit(struct dwc3 *dwc)
{ }
#endif
+#if IS_ENABLED(CONFIG_USB_DWC3_HOST_SUSPEND)
+int dwc3_host_suspend(struct dwc3 *dwc);
+int dwc3_host_resume(struct dwc3 *dwc);
+#else
+static inline int dwc3_host_suspend(struct dwc3 *dwc)
+{
+ return 0;
+}
+
+static inline int dwc3_host_resume(struct dwc3 *dwc)
+{
+ return 0;
+}
+#endif
+
#endif /* __DRIVERS_USB_DWC3_CORE_H */
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index ed82464..8e5309d6 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -16,6 +16,7 @@
*/
#include
+#include
#include "core.h"
@@ -130,3 +131,39 @@ void dwc3_host_exit(struct dwc3 *dwc)
dev_name(&dwc->xhci->dev));
platform_device_unregister(dwc->xhci);
}
+
+#ifdef CONFIG_USB_DWC3_HOST_SUSPEND
+int dwc3_host_suspend(struct dwc3 *dwc)
+{
+ struct device *xhci = &dwc->xhci->dev;
+ int ret;
+
+ /*
+* Note: if we get the -EBUSY, which means the xHCI children devices are
+* not in suspend state yet, the glue layer need to wait for a while and
+* try to suspend xHCI device again.
+
[PATCH v4] Fixes for compiling with clang
Fix reversed conditional checking if HOSTCC is clang. Suppress warnings about unsupported optimization options. Suppress warnings about unused functions, as they are generated for every module and are therefore far too spammy. Disable clang's integrated assembler which is incompatible with kernel asm constructs. Changes from v1: * Move the $(cc-name) conditional below the definition of $(CC) Changes from v2: * Actually commit the changes in v2. Changes from v3: * HOSTCC is not guaranteed to be the same as CC, adjust accordingly. Signed-off-by: Peter Foley --- Makefile | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 694111b43cf8..9c4803a74117 100644 --- a/Makefile +++ b/Makefile @@ -301,12 +301,12 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ HOSTCC = gcc HOSTCXX = g++ -HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89 +HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89 \ + -Wno-unused-value -Wno-unused-parameter -Wno-missing-field-initializers HOSTCXXFLAGS = -O2 -ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1) -HOSTCFLAGS += -Wno-unused-value -Wno-unused-parameter \ - -Wno-missing-field-initializers -fno-delete-null-pointer-checks +ifneq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1) +HOSTCFLAGS += -fno-delete-null-pointer-checks endif # Decide whether to build built-in, modular, or both. @@ -685,7 +685,9 @@ KBUILD_CFLAGS += $(stackp-flag) ifeq ($(cc-name),clang) KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,) KBUILD_CPPFLAGS += $(call cc-option,-Wno-unknown-warning-option,) +KBUILD_CFLAGS += $(call cc-disable-warning, ignored-optimization-argument) KBUILD_CFLAGS += $(call cc-disable-warning, unused-variable) +KBUILD_CFLAGS += $(call cc-disable-warning, unused-function) KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier) KBUILD_CFLAGS += $(call cc-disable-warning, gnu) # Quiet clang warning: comparison of unsigned expression < 0 is always false @@ -695,6 +697,8 @@ KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare) # See modpost pattern 2 KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,) KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior) +KBUILD_CFLAGS += $(call cc-option, -fno-integrated-as) +KBUILD_AFLAGS += $(call cc-option, -fno-integrated-as) else # These warnings generated too much noise in a regular build. -- 2.11.0.rc2
[PATCH v4 1/2] usb: host: plat: Enable xhci plat runtime PM
Enable the xhci plat runtime PM for parent device to suspend/resume xhci.
Also call pm_runtime_get_noresume() in probe() function in case the parent
device doesn't call suspend/resume callback by runtime PM now.
Signed-off-by: Baolin Wang
---
Changes since v3:
- Fix kbuild error.
Changes since v2:
- Add pm_runtime_get_noresume() in probe() function.
- Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove() function.
Changes since v1:
- No updates.
---
drivers/usb/host/xhci-plat.c | 41 -
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ed56bf9..5805c6a 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto dealloc_usb2_hcd;
+ pm_runtime_get_noresume(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
return 0;
@@ -274,6 +278,10 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
+ pm_runtime_set_suspended(&dev->dev);
+ pm_runtime_put_noidle(&dev->dev);
+ pm_runtime_disable(&dev->dev);
+
usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
@@ -311,14 +319,37 @@ static int xhci_plat_resume(struct device *dev)
return xhci_resume(xhci, 0);
}
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_PM
+static int xhci_plat_runtime_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+ return xhci_suspend(xhci, device_may_wakeup(dev));
+}
+
+static int xhci_plat_runtime_resume(struct device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+ return xhci_resume(xhci, 0);
+}
+
+static int xhci_plat_runtime_idle(struct device *dev)
+{
+ return 0;
+}
+#endif /* CONFIG_PM */
static const struct dev_pm_ops xhci_plat_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
+
+ SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend, xhci_plat_runtime_resume,
+ xhci_plat_runtime_idle)
};
-#define DEV_PM_OPS (&xhci_plat_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
static const struct acpi_device_id usb_xhci_acpi_match[] = {
/* XHCI-compliant USB Controller */
@@ -332,7 +363,7 @@ static int xhci_plat_resume(struct device *dev)
.remove = xhci_plat_remove,
.driver = {
.name = "xhci-hcd",
- .pm = DEV_PM_OPS,
+ .pm = &xhci_plat_pm_ops,
.of_match_table = of_match_ptr(usb_xhci_of_match),
.acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
--
1.7.9.5
Re: [PATCH v3 20/30] perf clang jit: add PerfModule::doJIT to JIT perfhook functions
On 2016/11/27 1:29, Alexei Starovoitov wrote:
On Sat, Nov 26, 2016 at 07:03:44AM +, Wang Nan wrote:
PerfModule::doJIT JIT compile perfhook functions and saves result into
a map. Add a test case for it.
At this stage perfhook functions can do no useful things because they
can't invoke external functions and can't return value. Following
commits are going to make improvment.
Don't hook functions right after jitted because bpf_object is unavailable
during jitting but it should be the context of jitted functions.
Signed-off-by: Wang Nan
...
+ for (Function *F : JITFunctions) {
+ JITSymbol sym = CompileLayer.findSymbol(F->getName().str(),
true);
+
+ /*
+* Type of F->getSection() is moving from
+* const char * to StringRef.
+* Convert it to std::string so we don't need
+* consider this API change.
+*/
+ std::string sec(F->getSection());
+ std::string hook(&sec.c_str()[sizeof("perfhook:") - 1]);
+ perf_hook_func_t func =
(perf_hook_func_t)(intptr_t)sym.getAddress();
+
+ if (JITResult[hook])
+ llvm::errs() << "Warning: multiple functions on hook "
+<< hook << ", only one is used\n";
+ JITResult[hook] = func;
+ }
+ return 0;
+}
+
class ClangOptions {
llvm::SmallString FileName;
llvm::SmallString<64> KVerDef;
@@ -292,6 +359,10 @@ void perf_clang__init(void)
LLVMInitializeBPFTarget();
LLVMInitializeBPFTargetMC();
LLVMInitializeBPFAsmPrinter();
+
+ llvm::InitializeNativeTarget();
+ llvm::InitializeNativeTargetAsmPrinter();
+ llvm::InitializeNativeTargetAsmParser();
Looks great. I bet a lot of people reading perf code
won't be able to understand what you're doing here.
Could you please add a design doc on how perf<->clang/llvm interaction
is done.
I'll put a perf-clang.txt in tools/perf/Documentation.
Thank you.
Acked-by: Alexei Starovoitov
Re: [PATCH v3 02/11] pwm: imx: remove ipg clock
Hi Boris, Stefan,
> On Tue, 22 Nov 2016 13:04:11 -0800
> Stefan Agner wrote:
>
> > On 2016-11-01 00:10, Lukasz Majewski wrote:
> > > From: Sascha Hauer
> > >
> > > The use of the ipg clock was introduced with commit 7b27c160c681
> > > ("pwm: i.MX: fix clock lookup").
> > > In the commit message it was claimed that the ipg clock is
> > > enabled for register accesses. This is true for the ->config()
> > > callback, but not for the ->set_enable() callback. Given that the
> > > ipg clock is not consistently enabled for all register accesses
> > > we can assume that either it is not required at all or that the
> > > current code does not work. Remove the ipg clock code for now so
> > > that it's no longer in the way of refactoring the driver.
> > >
> > > Signed-off-by: Sascha Hauer
> > > Cc: Philipp Zabel
> >
> > I have to NACK here, sorry guys.
> >
> > Just tested this on a i.MX 7, the kernel freezes in imx_pwm_config,
> > I guess that is where the code accesses a register first.
> >
> > The i.MX 7 DT (imx7s.dtsi) specifies the same clock for ipg and
> > per, but it seems that this clock is crucial for register access on
> > i.MX 7:
> >
> > clocks = <&clks IMX7D_PWM1_ROOT_CLK>,
> > <&clks IMX7D_PWM1_ROOT_CLK>;
> > clock-names = "ipg", "per";
> >
> > So since the "per" clock is the same in the i.MX 7 case,
> > imx_pwm_enable worked...
> >
> > I agree that the old code is a bit weird, especially that we get the
> > clock in imx_pwm_enable. It seems that all device trees specify a
> > "ipg" clock, so I guess we can get the clock at probe time for all
> > variants of this IP and just enable it on peripheral access...
>
> Or, we patch the code to take the per clk before accessing PWM regs,
> and release it once we're done.
> AFAIU, the IPG clock is only supposed to be enabled when the PWM takes
> its sources from the IPG channel,
+1
That is what TRM says about this clock.
> it has nothing to do we register
> accesses. If this is correct, then doing what you suggest implies
> abusing the IPG clk meaning.
+1
Best regards,
Łukasz Majewski
>
> >
> > --
> > Stefan
> >
> >
> > > ---
> > > [commit message text refactored by Lukasz Majewski
> > > ] ---
> > > Changes for v3:
> > > - New patch
> > > ---
> > > drivers/pwm/pwm-imx.c | 19 +--
> > > 1 file changed, 1 insertion(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > > index d600fd5..70609ef2 100644
> > > --- a/drivers/pwm/pwm-imx.c
> > > +++ b/drivers/pwm/pwm-imx.c
> > > @@ -49,7 +49,6 @@
> > >
> > > struct imx_chip {
> > > struct clk *clk_per;
> > > - struct clk *clk_ipg;
> > >
> > > void __iomem*mmio_base;
> > >
> > > @@ -204,17 +203,8 @@ static int imx_pwm_config(struct pwm_chip
> > > *chip, struct pwm_device *pwm, int duty_ns, int period_ns)
> > > {
> > > struct imx_chip *imx = to_imx_chip(chip);
> > > - int ret;
> > > -
> > > - ret = clk_prepare_enable(imx->clk_ipg);
> > > - if (ret)
> > > - return ret;
> > >
> > > - ret = imx->config(chip, pwm, duty_ns, period_ns);
> > > -
> > > - clk_disable_unprepare(imx->clk_ipg);
> > > -
> > > - return ret;
> > > + return imx->config(chip, pwm, duty_ns, period_ns);
> > > }
> > >
> > > static int imx_pwm_enable(struct pwm_chip *chip, struct
> > > pwm_device *pwm) @@ -293,13 +283,6 @@ static int
> > > imx_pwm_probe(struct platform_device *pdev) return
> > > PTR_ERR(imx->clk_per); }
> > >
> > > - imx->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> > > - if (IS_ERR(imx->clk_ipg)) {
> > > - dev_err(&pdev->dev, "getting ipg clock failed
> > > with %ld\n",
> > > - PTR_ERR(imx->clk_ipg));
> > > - return PTR_ERR(imx->clk_ipg);
> > > - }
> > > -
> > > imx->chip.ops = &imx_pwm_ops;
> > > imx->chip.dev = &pdev->dev;
> > > imx->chip.base = -1;
>
pgpJZNXaITtCA.pgp
Description: OpenPGP digital signature
RE: [PATCH 1/7] hv: acquire vmbus_connection.channel_mutex in vmbus_free_channels()
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Friday, November 25, 2016 20:49
> To: de...@linuxdriverproject.org
> Cc: linux-kernel@vger.kernel.org; KY Srinivasan ; Haiyang
> Zhang ; Dexuan Cui ;
> Stephen Hemminger
> Subject: [PATCH 1/7] hv: acquire vmbus_connection.channel_mutex in
> vmbus_free_channels()
>
> "kernel BUG at drivers/hv/channel_mgmt.c:350!" is observed when hv_vmbus
> module is unloaded. BUG_ON() was introduced in commit 85d9aa705184
> ("Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()") as
> vmbus_free_channels() codepath was apparently forgotten.
>
> Fixes: 85d9aa705184 ("Drivers: hv: vmbus: add an API
> vmbus_hvsock_device_unregister()")
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Dexuan Cui
Thanks for the fix!
-- Dexuan
Re: [PATCH v3 14/30] perf clang: Support compile IR to BPF object and add testcase
On 2016/11/27 1:25, Alexei Starovoitov wrote:
On Sat, Nov 26, 2016 at 07:03:38AM +, Wang Nan wrote:
getBPFObjectFromModule() is introduced to compile LLVM IR(Module)
to BPF object. Add new testcase for it.
Test result:
$ ./buildperf/perf test -v clang
51: Test builtin clang support :
51.1: Test builtin clang compile C source to IR :
--- start ---
test child forked, pid 21822
test child finished with 0
end
Test builtin clang support subtest 0: Ok
51.2: Test builtin clang compile C source to ELF object :
--- start ---
test child forked, pid 21823
test child finished with 0
end
Test builtin clang support subtest 1: Ok
Signed-off-by: Wang Nan
...
+ legacy::PassManager PM;
+ if (TargetMachine->addPassesToEmitFile(PM, ostream,
+ TargetMachine::CGFT_ObjectFile))
{
+ llvm::errs() << "TargetMachine can't emit a file of this
type\n";
+ return std::unique_ptr>(nullptr);;
+ }
+ PM.run(*Module);
I'm pretty sure you want to add FunctionInlingPass as well otherwise
I think llvm won't be doing much inlining and only very very simple
programs will compile fine. See what we did on bcc side.
Thank you for your information. I though inlining should be done during
C to IR phase, and we have use -O2 for it. Let me check it.
Also did you consider skipping elf generation and using in memory
instead ? That will improve compile/run time.
Maybe in future work? Current design reuse libelf and bpf-loader for
loading BPF code. Skipping ELF generation make compiling faster, but
require another loader to be coexist with bpf-loader.c, or we need
a new libbpf. In my current experience, outputting ELF is not so slow
for both server and smartphone.
Thank you.
Re: [PATCH v2] usb: xhci: Remove unuseful 'return' and 'break' statement
Hi Mathias, On 24 November 2016 at 19:16, Baolin Wang wrote: > Since these 'return' statements are not generally useful in void > function, remove them. Also remove one unuseful 'break' statement > in xhci_setup_addressable_virt_dev() function. > > Signed-off-by: Baolin Wang > --- > Changes since v1: > - Add description of removing 'break' statement in commitlog. > --- Could you apply this patch if there are no other comments? Thanks. -- Baolin.wang Best Regards
Talent Scout
Dear Concern, I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a Film Corporation Located in the United State, is Soliciting for the Right to use Your Photo/Face and Personality as One of the Semi -Major Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story of Ferdinand (Ferdinand 2017) The Movie is Currently Filming (In Production) Please Note That There Will Be No Auditions, Traveling or Any Special / Professional Acting Skills, Since the Production of This Movie Will Be Done with our State of Art Computer -Generating Imagery Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For More Information/Understanding, Please Write us on the E-Mail Below. CONTACT EMAIL: blueskyfi...@usa.com All Reply to: blueskyfi...@usa.com Note: Only the Response send to this mail will be Given a Prior Consideration. Talent Scout Camilia Brunnet
Re: [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
On Wed, Nov 23, 2016 at 9:03 PM, Sekhar Nori wrote:
> On Thursday 24 November 2016 04:18 AM, David Lechner wrote:
>> On 11/23/2016 04:32 PM, Kevin Hilman wrote:
>>> David Lechner writes:
>>>
On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
> 2016-11-22 23:23 GMT+01:00 David Lechner :
>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>
>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>> controller drivers to da850.dtsi.
>>>
>>> Signed-off-by: Bartosz Golaszewski
>>> ---
>>> v1 -> v2:
>>> - moved the priority controller node above the cfgchip node
>>> - renamed added nodes to better reflect their purpose
>>>
>>> arch/arm/boot/dts/da850.dtsi | 8
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>> b/arch/arm/boot/dts/da850.dtsi
>>> index 1bb1f6d..412eec6 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -210,6 +210,10 @@
>>> };
>>>
>>> };
>>> + prictrl: priority-controller@14110 {
>>> + compatible = "ti,da850-mstpri";
>>> + reg = <0x14110 0x0c>;
>>
>>
>> I think we should add status = "disabled"; here and let boards opt in.
>>
>>> + };
>>> cfgchip: chip-controller@1417c {
>>> compatible = "ti,da830-cfgchip", "syscon",
>>> "simple-mfd";
>>> reg = <0x1417c 0x14>;
>>> @@ -451,4 +455,8 @@
>>> 1 0 0x6800 0x8000>;
>>> status = "disabled";
>>> };
>>> + memctrl: memory-controller@b000 {
>>> + compatible = "ti,da850-ddr-controller";
>>> + reg = <0xb000 0xe8>;
>>
>>
>> same here. status = "disabled";
>>
>>> + };
>>> };
>>>
>
> Hi David,
>
> I did that initially[1][2] and it was rejected by Kevin[3] and
> Laurent[4].
>
> FYI this patch has already been queued by Sekhar.
Thanks. I did not see those threads.
FYI to maintainers, having these enabled by default causes error
messages in the kernel log for other boards that are not supported by
the drivers.
>>>
>>> Then the driver is too noisy and should be cleaned up.
>>>
Since there is only one board that is supported and soon
to be 2 that are not, I would rather have this disabled by default to
avoid the error messages.
>>>
>>> IMO, what exactly are the error messages? Sounds like the driver is
>>> being too verbose, and calling things errors that are not really errors.
>>
>> It is just one line per driver.
>>
>> dev_err(dev, "no master priorities defined for this board\n");
>>
>> and
>>
>> dev_err(dev, "no settings defined for this board\n");
>>
>>
>> Since "ti,da850-lcdk" is the only board supported in these drivers, all
>> other boards will see these error messages.
>
> Thats pretty bad. Sorry about that. The original justification for
> keeping them enabled all the time was that they are in-SoC modules with
> no external dependencies (like IO lines or voltage rails) so they can be
> enabled on all boards that use DA850. While that remains true, the
> configuration itself is board specific.
>
> I think the error messages are still useful, so instead of silencing
> them, I think we should go back to keeping these nodes disabled by
> default and enabling only on boards which have support for it in the driver.
I don't have a strong preference for the enabled/disabled by default,
but I think the error messages are not error messages. It seems
perfectly reasonable for boards to accept the reset (or bootloader)
configuration of these registers, and not consider that an error.
Kevin
Re: [PATCH] md/raid5: limit request size according to implementation limits
On Mon, Nov 28, 2016 at 7:40 AM, Coly Li wrote: > On 2016/11/28 上午12:32, Konstantin Khlebnikov wrote: >> Current implementation employ 16bit counter of active stripes in lower >> bits of bio->bi_phys_segments. If request is big enough to overflow >> this counter bio will be completed and freed too early. >> >> Fortunately this not happens in default configuration because several >> other limits prevent that: stripe_cache_size * nr_disks effectively >> limits count of active stripes. And small max_sectors_kb at lower >> disks prevent that during normal read/write operations. >> >> Overflow easily happens in discard if it's enabled by module parameter >> "devices_handle_discard_safely" and stripe_cache_size is set big enough. >> >> This patch limits requests size with 256Mb - 8Kb to prevent overflows. >> >> Signed-off-by: Konstantin Khlebnikov >> Cc: Shaohua Li >> Cc: Neil Brown >> Cc: sta...@vger.kernel.org >> --- >> drivers/md/raid5.c |9 + >> 1 file changed, 9 insertions(+) >> >> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c >> index 92ac251e91e6..cce6057b9aca 100644 >> --- a/drivers/md/raid5.c >> +++ b/drivers/md/raid5.c >> @@ -6984,6 +6984,15 @@ static int raid5_run(struct mddev *mddev) >> stripe = (stripe | (stripe-1)) + 1; >> mddev->queue->limits.discard_alignment = stripe; >> mddev->queue->limits.discard_granularity = stripe; >> + >> + /* >> + * We use 16-bit counter of active stripes in bi_phys_segments >> + * (minus one for over-loaded initialization) >> + */ >> + blk_queue_max_hw_sectors(mddev->queue, 0xfffe * >> STRIPE_SECTORS); >> + blk_queue_max_discard_sectors(mddev->queue, >> + 0xfffe * STRIPE_SECTORS); >> + > > Could you please to explain why use 0xfffe * STRIPE_SECTORS here ? This code send individual bio to lower device for each STRIPE_SECTORS (8) and count them in 16-bit counter 0x max (you could find this constant above in this file) but counter initialized with 1 to prevent hitting zero during generation thus maximum is 0xfffe stripes which is 256Mb - 8Kb in bytes > > Thanks. > > Coly >
linux-next: Tree for Nov 28
Hi all, Changes since 20161125: New tree: modules The mmc tree gained a conflict against the block tree. The edac-amd tree gained a conflict agaainst the edac tree. The kvm tree gained a conflict against the tip tree. The akpm-current tree still had its build failure for which I added a supplied patch. Non-merge commits (relative to Linus' tree): 8268 8247 files changed, 480978 insertions(+), 181864 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 and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) 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 (with KALLSYMS_EXTRA_PASS=1) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 244 trees (counting Linus' and 34 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 (e5517c2a5a49 Linux 4.9-rc7) Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/rc-fixes (152b695d7437 builddeb: fix cross-building to arm64 producing host-arch debs) Merging arc-current/for-curr (a25f0944ba9b Linux 4.9-rc5) Merging arm-current/fixes (8478132a8784 Revert "arm: move exports to definitions") Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro) Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally) Merging powerpc-fixes/fixes (984d7a1ec67c powerpc/mm: Fixup kernel read only mapping) Merging sparc/master (9dd35d6882a1 sparc: drop duplicate header scatterlist.h) Merging net/master (d8e435f3ab6f Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging ipsec/master (6b2264878155 flowcache: Increase threshold for refusing new allocations) Merging netfilter/master (9b6c14d51bd2 net: tcp response should set oif only if it is L3 master) Merging ipvs/master (9b6c14d51bd2 net: tcp response should set oif only if it is L3 master) Merging wireless-drivers/master (fcd2042e8d36 mwifiex: printk() overflow with 32-byte SSIDs) Merging mac80211/master (51b9a31c42ed tipc: eliminate obsolete socket locking policy description) Merging sound-current/for-linus (b5337cfe067e ALSA: hda/ca0132 - Add quirk for Alienware 15 R2 2016) Merging pci-current/for-linus (e42010d8207f PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)) Merging driver-core.current/driver-core-linus (a25f0944ba9b Linux 4.9-rc5) Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3) Merging usb.current/usb-linus (16ae16c6e561 Merge tag 'mmc-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc) Merging usb-gadget-fixes/fixes (05e78c6933d6 usb: gadget: f_fs: fix wrong parenthesis in ffs_func_req_match()) Merging usb-serial-fixes/usb-linus (2ab13292d7a3 USB: serial: cp210x: add ID for the Zone DPMX) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking unknown bit of pmu) Merging staging.current/staging-linus (a25f0944ba9b Linux 4.9-rc5) Merging char-misc.current/char-misc-linus (a25f0944ba9b Linux 4.9-rc5) Merging input-current/for-linus (e9fb7cc63801 Input: psmouse - disable automatic probing of BYD touchpads) Merging crypto-current/master (c8467f7a3620 crypto: scatterwalk - Remove unnecessary aliasing check in map_and_copy) Merging ide/master (797cee982eef Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit) Merging vfio-fixes/for-linus (05692d7005a3 vfio/pci: Fix int
Re: [PATCH v3 07/11] pwm: imx: Provide atomic PWM support for i.MX PWMv2
Dear Stefan, Boris,
> On 2016-11-23 00:38, Boris Brezillon wrote:
> > On Tue, 22 Nov 2016 13:55:33 -0800
> > Stefan Agner wrote:
> >
> >> On 2016-11-01 00:10, Lukasz Majewski wrote:
> >> > This commit provides apply() callback implementation for i.MX's
> >> > PWMv2.
> >> >
> >> > Suggested-by: Stefan Agner
> >> > Suggested-by: Boris Brezillon
> >> > Signed-off-by: Lukasz
> >> > Majewski Reviewed-by: Boris Brezillon
> >> > ---
> >> > Changes for v3:
> >> > - Remove ipg clock enable/disable functions
> >> >
> >> > Changes for v2:
> >> > - None
> >> > ---
> >> > drivers/pwm/pwm-imx.c | 70
> >> > +++ 1 file
> >> > changed, 70 insertions(+)
> >> >
> >> > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> >> > index ebe9b0c..cd53c05 100644
> >> > --- a/drivers/pwm/pwm-imx.c
> >> > +++ b/drivers/pwm/pwm-imx.c
> >> > @@ -159,6 +159,75 @@ static void imx_pwm_wait_fifo_slot(struct
> >> > pwm_chip *chip, }
> >> > }
> >> >
> >> > +static int imx_pwm_apply_v2(struct pwm_chip *chip, struct
> >> > pwm_device *pwm,
> >> > +struct pwm_state *state)
> >> > +{
> >> > +unsigned long period_cycles, duty_cycles, prescale;
> >> > +struct imx_chip *imx = to_imx_chip(chip);
> >> > +struct pwm_state cstate;
> >> > +unsigned long long c;
> >> > +u32 cr = 0;
> >> > +int ret;
> >> > +
> >> > +pwm_get_state(pwm, &cstate);
> >> > +
> >>
> >> Couldn't we do:
> >>
> >> if (cstate.enabled) { ...
> >>
> >> > +c = clk_get_rate(imx->clk_per);
> >> > +c *= state->period;
> >> > +
> >> > +do_div(c, 10);
> >> > +period_cycles = c;
> >> > +
> >> > +prescale = period_cycles / 0x1 + 1;
> >> > +
> >> > +period_cycles /= prescale;
> >> > +c = (unsigned long long)period_cycles *
> >> > state->duty_cycle;
> >> > +do_div(c, state->period);
> >> > +duty_cycles = c;
> >> > +
> >> > +/*
> >> > + * according to imx pwm RM, the real period value
> >> > should be
> >> > + * PERIOD value in PWMPR plus 2.
> >> > + */
> >> > +if (period_cycles > 2)
> >> > +period_cycles -= 2;
> >> > +else
> >> > +period_cycles = 0;
> >> > +
> >> > +/* Enable the clock if the PWM is being enabled. */
> >> > +if (state->enabled && !cstate.enabled) {
> >> > +ret = clk_prepare_enable(imx->clk_per);
> >> > +if (ret)
> >> > +return ret;
> >> > +}
> >> > +
> >> > +/*
> >> > + * Wait for a free FIFO slot if the PWM is already
> >> > enabled, and flush
> >> > + * the FIFO if the PWM was disabled and is about to be
> >> > enabled.
> >> > + */
> >> > +if (cstate.enabled)
> >> > +imx_pwm_wait_fifo_slot(chip, pwm);
> >> > +else if (state->enabled)
> >> > +imx_pwm_sw_reset(chip);
> >> > +
> >> > +writel(duty_cycles, imx->mmio_base + MX3_PWMSAR);
> >> > +writel(period_cycles, imx->mmio_base + MX3_PWMPR);
> >> > +
> >> > +cr |= MX3_PWMCR_PRESCALER(prescale) |
> >> > + MX3_PWMCR_DOZEEN | MX3_PWMCR_WAITEN |
> >> > + MX3_PWMCR_DBGEN | MX3_PWMCR_CLKSRC_IPG_HIGH;
> >> > +
> >> > +if (state->enabled)
> >> > +cr |= MX3_PWMCR_EN;
> >>
> >> } else if (state->enabled) {
> >>imx_pwm_sw_reset(chip);
> >> }
> >>
> >> and get rid of the if (state->enabled) in between? This would safe
> >> us useless recalculation when disabling the controller...
> >
> > I get your point, but I'm pretty sure your proposal does not do what
> > you want (remember that cstate is the current state, and state is
> > the new state to apply).
> >
> > Something like that would work better:
> >
> > if (state->enabled) {
>
> Oops, yes, got that wrong. state->enabled is what I meant.
>
> > c = clk_get_rate(imx->clk_per);
> > c *= state->period;
> >
> > do_div(c, 10);
> > period_cycles = c;
> >
> > prescale = period_cycles / 0x1 + 1;
> >
> > period_cycles /= prescale;
> > c = (unsigned long long)period_cycles *
> > state->duty_cycle;
> > do_div(c, state->period);
> > duty_cycles = c;
> >
> > /*
> > * According to imx pwm RM, the real period value
> > * should be PERIOD value in PWMPR plus 2.
> > */
> > if (period_cycles > 2)
> > period_cycles -= 2;
> > else
> > period_cycles = 0;
> >
> > /*
> > * Enable the clock if the PWM is not already
> > * enabled.
> > */
> > if (!cstate.enabled) {
> > ret = clk_prepare_enable(imx->clk_per);
> >
Re: [PATCH] geneve: fix ip_hdr_len reserved for geneve6 tunnel.
On Sun, Nov 27, 2016 at 9:26 PM, Haishuang Yan
wrote:
> It shold reserved sizeof(ipv6hdr) for geneve in ipv6 tunnel.
>
> Fixes: c3ef5aa5e5 ('geneve: Merge ipv4 and ipv6 geneve_build_skb()')
>
> Signed-off-by: Haishuang Yan
Thanks for fix.
Acked-by: Pravin B Shelar
Re: Enabling peer to peer device transactions for PCIe devices
+Qiang, who is working on it. On 2016年11月27日 22:07, Christian König wrote: Am 27.11.2016 um 15:02 schrieb Haggai Eran: On 11/25/2016 9:32 PM, Jason Gunthorpe wrote: On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote: Like you say below we have to handle short lived in the usual way, and that covers basically every device except IB MRs, including the command queue on a NVMe drive. Well a problem which wasn't mentioned so far is that while GPUs do have a page table to mirror the CPU page table, they usually can't recover from page faults. So what we do is making sure that all memory accessed by the GPU Jobs stays in place while those jobs run (pretty much the same pinning you do for the DMA). Yes, it is DMA, so this is a valid approach. But, you don't need page faults from the GPU to do proper coherent page table mirroring. Basically when the driver submits the work to the GPU it 'faults' the pages into the CPU and mirror translation table (instead of pinning). Like in ODP, MMU notifiers/HMM are used to monitor for translation changes. If a change comes in the GPU driver checks if an executing command is touching those pages and blocks the MMU notifier until the command flushes, then unfaults the page (blocking future commands) and unblocks the mmu notifier. I think blocking mmu notifiers against something that is basically controlled by user-space can be problematic. This can block things like memory reclaim. If you have user-space access to the device's queues, user-space can block the mmu notifier forever. Really good point. I think this means the bare minimum if we don't have recoverable page faults is to have preemption support like Felix described in his answer as well. Going to keep that in mind, Christian. ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [virtio-dev] Re: [PATCH v2 2/2] crypto: add virtio-crypto driver
> > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Monday, November 28, 2016 1:09 PM > To: Gonglei (Arei) > Subject: Re: [virtio-dev] Re: [PATCH v2 2/2] crypto: add virtio-crypto driver > > On Mon, Nov 28, 2016 at 04:47:21AM +, Gonglei (Arei) wrote: > > Michael, I'd like to add virtio-crypto stuff to your maintaining part likes > > the virtio-net/blk parts so that the corresponding patches > > can be CC'ed to you too because the virtio-crypto doesn't lay in > > driver/virtio directory. Will you? > > > > Thanks! > > -Gonglei > > Sure, that's fine. > Will do in the next version. :) Thanks, -Gonglei
Re: [PATCH v3 1/3] mm: support anonymous stable page
Hello, On (11/28/16 09:41), Minchan Kim wrote: > > I'm going on a long vacation so forgive if I respond slowly. :) no prob. have a good one! > On Sun, Nov 27, 2016 at 10:19:10PM +0900, Sergey Senozhatsky wrote: [..] > > wondering - how many pages can it hold? we are in low memory, that's why we > > failed to zsmalloc in fast path, so how likely this to worsen memory > > pressure? > > Actually, I don't have real number to say but a thing I can say surely is > it's really hard to meet in normal stress test I have done until now. > That's why it takes a long time to find(i.e., I could encounter the bug > once two days). But once I understood the problem, I can reproduce the > problem in 15 minutes. > > About memory pressure, my testing was already severe memory pressure(i.e., > many memory failure and frequent OOM kill) so it doesn't make any > meaningful difference before and after. > > > just asking. in async zram the window between zram_rw_page() and actual > > write of a page even bigger, isn't it? > > Yes. That's why I found the problem with that feature enabled. Lucky. ;) I see. just curious, the worst case is deflate compression (which can be 8-9 slower than lz4) and sync zram. right? are we speaking of megabytes here? > > we *probably* and *may be* can try handle it in zram: > > > > -- store the previous clen before re-compression > > -- check if new clen > saved_clen and if it is - we can't use previously > >allocate handle and need to allocate a new one again. if it's less or > >equal than the saved one - store the object (wasting some space, > >yes. but we are in low mem). > > It was my first attempt but changed mind. > It can save against crash but broken data could go to the disk > (i.e., zram). If someone want to read block directly(e.g., > open /dev/zram0; read /dev/zram or DIO), it cannot read the data > forever until someone writes some stable data into that sectors. > Instead, he will see many decompression failure message. > It's weired. > > I believe stable page problem should be solved by generic layer, > not driver itself. yeah, I'm fine with this. at the same, there are chances, I suspect, that may be we will see some 'regressions'. well, just may be. -ss
Re: [PATCH] ARM: dts: da850: enable the memctrl and mstpri nodes per board
On Thursday 24 November 2016 03:01 PM, Bartosz Golaszewski wrote: > Currently the memory controller and master priorities drivers are > enabled in da850.dtsi. For boards for which there are no settings > defined, this makes these drivers emit error messages. > > Disable the nodes in da850.dtsi and only enable them for da850-lcdk - > the only board that currently needs them. > > Signed-off-by: Bartosz Golaszewski Applied to v4.10/dt Thanks, Sekhar
[PATCH] geneve: fix ip_hdr_len reserved for geneve6 tunnel.
It shold reserved sizeof(ipv6hdr) for geneve in ipv6 tunnel.
Fixes: c3ef5aa5e5 ('geneve: Merge ipv4 and ipv6 geneve_build_skb()')
Signed-off-by: Haishuang Yan
---
drivers/net/geneve.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 7b80e28..45301cb 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -852,7 +852,7 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct
net_device *dev,
ip_hdr(skb), skb);
ttl = key->ttl ? : ip6_dst_hoplimit(dst);
}
- err = geneve_build_skb(dst, skb, info, xnet, sizeof(struct iphdr));
+ err = geneve_build_skb(dst, skb, info, xnet, sizeof(struct ipv6hdr));
if (unlikely(err))
return err;
--
1.8.3.1
Re: [PATCH] ARM: dts: da850-lcdk: Add ethernet0 alias to DT
On Thursday 24 November 2016 08:05 PM, Fabien Parent wrote: > In order to avoid Linux generating a random mac address on every boot, > add an ethernet0 alias that will allow u-boot to patch the dtb with > the MAC address programmed into the EEPROM. > > Signed-off-by: Fabien Parent Applied to v4.10/dt. Thanks! Regards, Sekhar
BMW PROMO
Congratulations, Dear Mr. /Mrs. you are lucky to have been chosen in the BMW 2016 lottery draw. That was just concluded in an E lottery online machine draw and the email with lotto number BMW216021653096 and ticket draw number 5000342. Has won $150,000(ONE HUNDRED AND FIFTHY THOUSAND DOLLARS) VERIFY TO CLAIM YOUR PRIZE .EMAIL THE PROMOTIONAL HEAD MANAGER ON (tonyrich...@usa.com) FOR YOUR CLAIMS. THANKS. tony richmond (promotional head)
Re: [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote: > It has been determined that the maximum resolution supported correctly > by tilcdc rev1 on da850 SoCs is 800x600@60. Due to memory throughput > constraints we must filter out higher modes. > > Specify the max-bandwidth property for the display node for > da850-based boards. > > Signed-off-by: Bartosz Golaszewski > --- > arch/arm/boot/dts/da850.dtsi | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi > index 8e30d9b..9b7c444 100644 > --- a/arch/arm/boot/dts/da850.dtsi > +++ b/arch/arm/boot/dts/da850.dtsi > @@ -452,6 +452,7 @@ > compatible = "ti,da850-tilcdc"; > reg = <0x213000 0x1000>; > interrupts = <52>; > + max-bandwidth = <2880>; If this is effectively the max pixel clock that the device supports, then why not use the datasheet specified value of 37.5 MHz (Tc = 26.66 ns). Thanks, Sekhar
Re: [PATCH 01/22] cpufreq/acpi-cpufreq: Convert to hotplug state machine
On 27-11-16, 00:13, Sebastian Andrzej Siewior wrote:
> Install the callbacks via the state machine.
>
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: linux...@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/cpufreq/acpi-cpufreq.c | 93
> --
> 1 file changed, 45 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index 297e9128fe9f..2c29cbaca7b5 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -536,46 +536,33 @@ static void free_acpi_perf_data(void)
> free_percpu(acpi_perf_data);
> }
>
> -static int boost_notify(struct notifier_block *nb, unsigned long action,
> - void *hcpu)
> +static int cpufreq_boost_online(unsigned int cpu)
> +{
> + const struct cpumask *cpumask;
> +
> + cpumask = get_cpu_mask(cpu);
> + /*
> + * On the CPU_UP path we simply keep the boost-disable flag
> + * in sync with the current global state.
> + */
> + boost_set_msrs(acpi_cpufreq_driver.boost_enabled, cpumask);
> + return 0;
> +}
> +
> +static int cpufreq_boost_down_prep(unsigned int cpu)
> {
> - unsigned cpu = (long)hcpu;
> const struct cpumask *cpumask;
>
> cpumask = get_cpu_mask(cpu);
>
> /*
>* Clear the boost-disable bit on the CPU_DOWN path so that
> - * this cpu cannot block the remaining ones from boosting. On
> - * the CPU_UP path we simply keep the boost-disable flag in
> - * sync with the current global state.
> + * this cpu cannot block the remaining ones from boosting.
>*/
> -
> - switch (action) {
> - case CPU_DOWN_FAILED:
> - case CPU_DOWN_FAILED_FROZEN:
> - case CPU_ONLINE:
> - case CPU_ONLINE_FROZEN:
> - boost_set_msrs(acpi_cpufreq_driver.boost_enabled, cpumask);
> - break;
> -
> - case CPU_DOWN_PREPARE:
> - case CPU_DOWN_PREPARE_FROZEN:
> - boost_set_msrs(1, cpumask);
> - break;
> -
> - default:
> - break;
> - }
> -
> - return NOTIFY_OK;
> + boost_set_msrs(1, cpumask);
> + return 0;
> }
>
> -
> -static struct notifier_block boost_nb = {
> - .notifier_call = boost_notify,
> -};
> -
> /*
> * acpi_cpufreq_early_init - initialize ACPI P-States library
> *
> @@ -922,37 +909,47 @@ static struct cpufreq_driver acpi_cpufreq_driver = {
> .attr = acpi_cpufreq_attr,
> };
>
> +static enum cpuhp_state acpi_cpufreq_online;
> +
> static void __init acpi_cpufreq_boost_init(void)
> {
> - if (boot_cpu_has(X86_FEATURE_CPB) || boot_cpu_has(X86_FEATURE_IDA)) {
> - msrs = msrs_alloc();
> + int ret;
>
> - if (!msrs)
> - return;
> + if (!(boot_cpu_has(X86_FEATURE_CPB) || boot_cpu_has(X86_FEATURE_IDA)))
> + return;
>
> - acpi_cpufreq_driver.set_boost = set_boost;
> - acpi_cpufreq_driver.boost_enabled = boost_state(0);
> + msrs = msrs_alloc();
>
> - cpu_notifier_register_begin();
> + if (!msrs)
> + return;
>
> - /* Force all MSRs to the same value */
> - boost_set_msrs(acpi_cpufreq_driver.boost_enabled,
> -cpu_online_mask);
Why isn't this required anymore ?
> + acpi_cpufreq_driver.set_boost = set_boost;
> + acpi_cpufreq_driver.boost_enabled = boost_state(0);
>
> - __register_cpu_notifier(&boost_nb);
> -
> - cpu_notifier_register_done();
> + /*
> + * This calls the online callback on all online cpu and forces all
> + * MSRs to the same value.
> + */
> + ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "cpufreq/acpi:online",
> + cpufreq_boost_online, cpufreq_boost_down_prep);
> + if (ret < 0) {
> + pr_err("acpi_cpufreq: failed to register hotplug callbacks\n");
> + msrs_free(msrs);
If 'msrs = NULL' is required to be done in the _exit() routine, then it should
be done here as well. Right?
> + return;
> }
> + acpi_cpufreq_online = ret;
> }
>
> static void acpi_cpufreq_boost_exit(void)
> {
> - if (msrs) {
> - unregister_cpu_notifier(&boost_nb);
> + if (!msrs)
> + return;
>
> - msrs_free(msrs);
> - msrs = NULL;
> - }
> + if (acpi_cpufreq_online >= 0)
> + cpuhp_remove_state_nocalls(acpi_cpufreq_online);
> +
> + msrs_free(msrs);
> + msrs = NULL;
> }
>
> static int __init acpi_cpufreq_init(void)
> --
> 2.10.2
--
viresh
[PATCH] x86/unwind: fix guess unwinder regression
My attempt at fixing some KASAN false positive warnings was rather brain
dead, and it broke the guess unwinder. With frame pointers disabled,
/proc//stack is broken:
# cat /proc/1/stack
[] 0x
Restore the code flow to more closely resemble its previous state, while
still using READ_ONCE_NOCHECK macros to silence KASAN false positives.
Fixes: c2d75e03d630 ("x86/unwind: Prevent KASAN false positive warnings in
guess unwinder")
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/unwind_guess.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/unwind_guess.c b/arch/x86/kernel/unwind_guess.c
index b80e8bf..22881dd 100644
--- a/arch/x86/kernel/unwind_guess.c
+++ b/arch/x86/kernel/unwind_guess.c
@@ -7,11 +7,13 @@
unsigned long unwind_get_return_address(struct unwind_state *state)
{
- unsigned long addr = READ_ONCE_NOCHECK(*state->sp);
+ unsigned long addr;
if (unwind_done(state))
return 0;
+ addr = READ_ONCE_NOCHECK(*state->sp);
+
return ftrace_graph_ret_addr(state->task, &state->graph_idx,
addr, state->sp);
}
@@ -25,11 +27,12 @@ bool unwind_next_frame(struct unwind_state *state)
return false;
do {
- unsigned long addr = READ_ONCE_NOCHECK(*state->sp);
+ for (state->sp++; state->sp < info->end; state->sp++) {
+ unsigned long addr = READ_ONCE_NOCHECK(*state->sp);
- for (state->sp++; state->sp < info->end; state->sp++)
if (__kernel_text_address(addr))
return true;
+ }
state->sp = info->next_sp;
--
2.7.4
Re: Add modules-next branch to linux-next
Hi Jessica, On Sat, 26 Nov 2016 14:42:09 -0800 Jessica Yu wrote: > > Could you please add the modules-next branch at: > >git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git modules-next > > to linux-next? The branch contains patches for modules targeted for the next > merge window. It is meant to replace Rusty's old modules-next branch. Added from today. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgement of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au
Re: [virtio-dev] Re: [PATCH v2 2/2] crypto: add virtio-crypto driver
On Mon, Nov 28, 2016 at 04:47:21AM +, Gonglei (Arei) wrote: > Michael, I'd like to add virtio-crypto stuff to your maintaining part likes > the virtio-net/blk parts so that the corresponding patches > can be CC'ed to you too because the virtio-crypto doesn't lay in > driver/virtio directory. Will you? > > Thanks! > -Gonglei Sure, that's fine. -- MST
Re: [PATCH v3 net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
On 11/26/2016 04:20 AM, Lino Sanfilippo wrote:
> Add driver for Alacritech gigabit ethernet cards with SLIC (session-layer
> interface control) technology. The driver provides basic support without
> SLIC for the following devices:
>
> - Mojave cards (single port PCI Gigabit) both copper and fiber
> - Oasis cards (single and dual port PCI-x Gigabit) copper and fiber
> - Kalahari cards (dual and quad port PCI-e Gigabit) copper and fiber
This looks great, a few nits below:
> +#define SLIC_MAX_TX_COMPLETIONS 100
You usually don't want to limit the number of TX completion, if the
entire TX ring needs to be cleaned, you would want to allow that.
[snip]
> + while (slic_get_free_rx_descs(rxq) > SLIC_MAX_REQ_RX_DESCS) {
> + skb = alloc_skb(maplen + ALIGN_MASK, gfp);
> + if (!skb)
> + break;
> +
> + paddr = dma_map_single(&sdev->pdev->dev, skb->data, maplen,
> +DMA_FROM_DEVICE);
> + if (dma_mapping_error(&sdev->pdev->dev, paddr)) {
> + netdev_err(dev, "mapping rx packet failed\n");
> + /* drop skb */
> + dev_kfree_skb_any(skb);
> + break;
> + }
> + /* ensure head buffer descriptors are 256 byte aligned */
> + offset = 0;
> + misalign = paddr & ALIGN_MASK;
> + if (misalign) {
> + offset = SLIC_RX_BUFF_ALIGN - misalign;
> + skb_reserve(skb, offset);
> + }
> + /* the HW expects dma chunks for descriptor + frame data */
> + desc = (struct slic_rx_desc *)skb->data;
> + memset(desc, 0, sizeof(*desc));
Do you really need to zero-out the prepending RX descriptor? Are not you
missing a write barrier here?
[snip]
> +
> + dma_sync_single_for_cpu(&sdev->pdev->dev,
> + dma_unmap_addr(buff, map_addr),
> + buff->addr_offset + sizeof(*desc),
> + DMA_FROM_DEVICE);
> +
> + status = le32_to_cpu(desc->status);
> + if (!(status & SLIC_IRHDDR_SVALID))
> + break;
> +
> + buff->skb = NULL;
> +
> + dma_unmap_single(&sdev->pdev->dev,
> + dma_unmap_addr(buff, map_addr),
> + dma_unmap_len(buff, map_len),
> + DMA_FROM_DEVICE);
This is potentially inefficient, you already did a cache invalidation
for the RX descriptor here, you could be more efficient with just
invalidating the packet length, minus the descriptor length.
> +
> + /* skip rx descriptor that is placed before the frame data */
> + skb_reserve(skb, SLIC_RX_BUFF_HDR_SIZE);
> +
> + if (unlikely(status & SLIC_IRHDDR_ERR)) {
> + slic_handle_frame_error(sdev, skb);
> + dev_kfree_skb_any(skb);
> + } else {
> + struct ethhdr *eh = (struct ethhdr *)skb->data;
> +
> + if (is_multicast_ether_addr(eh->h_dest))
> + SLIC_INC_STATS_COUNTER(&sdev->stats, rx_mcasts);
> +
> + len = le32_to_cpu(desc->length) & SLIC_IRHDDR_FLEN_MSK;
> + skb_put(skb, len);
> + skb->protocol = eth_type_trans(skb, dev);
> + skb->ip_summed = CHECKSUM_UNNECESSARY;
> + skb->dev = dev;
eth_type_trans() already assigns skb->dev = dev;
> +static int slic_poll(struct napi_struct *napi, int todo)
> +{
> + struct slic_device *sdev = container_of(napi, struct slic_device, napi);
> + struct slic_shmem *sm = &sdev->shmem;
> + struct slic_shmem_data *sm_data = sm->shmem_data;
> + u32 isr = le32_to_cpu(sm_data->isr);
> + unsigned int done = 0;
> +
> + slic_handle_irq(sdev, isr, todo, &done);
> +
> + if (done < todo) {
> + napi_complete(napi);
napi_complete_done() since you know how many packets you completed.
> + /* reenable irqs */
> + sm_data->isr = 0;
> + /* make sure sm_data->isr is cleard before irqs are reenabled */
> + wmb();
> + slic_write(sdev, SLIC_REG_ISR, 0);
> + slic_flush_write(sdev);
> + }
> +
> + return done;
> +}
> +
> +static irqreturn_t slic_irq(int irq, void *dev_id)
> +{
> + struct slic_device *sdev = dev_id;
> + struct slic_shmem *sm = &sdev->shmem;
> + struct slic_shmem_data *sm_data = sm->shmem_data;
> +
> + slic_write(sdev, SLIC_REG_ICR, SLIC_ICR_INT_MASK);
> + slic_flush_write(sdev);
> + /* make sure sm_data->isr is read after ICR_INT_MASK is set */
> + wmb();
> +
> + if (!sm_data->isr) {
> + dma_rmb();
> + /* spurious interrupt */
> + slic_write
Re: [PATCH net v2 0/5] net: fix phydev reference leaks
From: Timur Tabi Date: Sun, 27 Nov 2016 20:11:17 -0600 > David Miller wrote: >> Series applied, thanks. > > I was really hoping you'd give me the chance to test the patches > before applying them. Sorry, if anything is broken I will happily revert if it isn't fixed promptly.
Re: [PATCH] Input: Change msleep to usleep_range for small msecs
Hi Aniroop,
On Fri, Nov 25, 2016 at 12:54:39AM +0530, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device suspend time, device enable time, data reading time, etc.
> Thus, change msleep to usleep_range for precise wakeups.
>
> Signed-off-by: Aniroop Mathur
> ---
> drivers/input/gameport/ns558.c | 4 ++--
> drivers/input/joystick/adi.c| 4 ++--
> drivers/input/joystick/analog.c | 12 ++--
> drivers/input/joystick/gf2k.c | 8
> drivers/input/joystick/sidewinder.c | 24
> drivers/input/keyboard/lm8323.c | 2 +-
> drivers/input/mouse/navpoint.c | 2 +-
> drivers/input/mouse/pxa930_trkball.c| 2 +-
> drivers/input/mouse/synaptics_i2c.c | 6 +++---
> drivers/input/touchscreen/ads7846.c | 4 ++--
> drivers/input/touchscreen/edt-ft5x06.c | 4 ++--
> drivers/input/touchscreen/w90p910_ts.c | 4 ++--
> drivers/input/touchscreen/zylonite-wm97xx.c | 4 ++--
This does make sense and probably even needed for the joystick drivers,
but I would like to make sure this is tested. Can you please split the
patch by driver and try to find people with the hardware to test this?
Thanks!
> 13 files changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/input/gameport/ns558.c b/drivers/input/gameport/ns558.c
> index 7c21784..046cb28 100644
> --- a/drivers/input/gameport/ns558.c
> +++ b/drivers/input/gameport/ns558.c
> @@ -98,7 +98,7 @@ static int ns558_isa_probe(int io)
> release_region(io, 1);
> return -ENODEV;
> }
> - msleep(3);
> + usleep_range(3000, 3100);
> /*
> * After some time (4ms) the axes shouldn't change anymore.
> */
> @@ -124,7 +124,7 @@ static int ns558_isa_probe(int io)
> outb(0xff, io & (-1 << i));
> for (j = b = 0; j < 1000; j++)
> if (inb(io & (-1 << i)) != inb((io & (-1 << i)) + (1 <<
> i) - 1)) b++;
> - msleep(3);
> + usleep_range(3000, 3100);
>
> if (b > 300) { /* We allow 30%
> difference */
> release_region(io & (-1 << i), (1 << i));
> diff --git a/drivers/input/joystick/adi.c b/drivers/input/joystick/adi.c
> index d09cefa..f1955bf 100644
> --- a/drivers/input/joystick/adi.c
> +++ b/drivers/input/joystick/adi.c
> @@ -48,7 +48,7 @@ MODULE_LICENSE("GPL");
> #define ADI_MAX_START200 /* Trigger to packet timeout
> [200us] */
> #define ADI_MAX_STROBE 40 /* Single bit timeout [40us] */
> #define ADI_INIT_DELAY 10 /* Delay after init packet
> [10ms] */
> -#define ADI_DATA_DELAY 4 /* Delay after data packet
> [4ms] */
> +#define ADI_DATA_DELAY 4000/* Delay after data packet
> [4000us] */
>
> #define ADI_MAX_LENGTH 256
> #define ADI_MIN_LENGTH 8
> @@ -514,7 +514,7 @@ static int adi_connect(struct gameport *gameport, struct
> gameport_driver *drv)
>
> msleep(ADI_INIT_DELAY);
> if (adi_read(port)) {
> - msleep(ADI_DATA_DELAY);
> + usleep_range(ADI_DATA_DELAY, ADI_DATA_DELAY + 100);
> adi_read(port);
> }
>
> diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
> index 3d8ff09..2891704 100644
> --- a/drivers/input/joystick/analog.c
> +++ b/drivers/input/joystick/analog.c
> @@ -88,7 +88,7 @@ MODULE_PARM_DESC(map, "Describes analog joysticks
> type/capabilities");
> #define ANALOG_EXTENSIONS0x7ff00
> #define ANALOG_GAMEPAD 0x8
>
> -#define ANALOG_MAX_TIME 3 /* 3 ms */
> +#define ANALOG_MAX_TIME 3000/* 3000 us */
> #define ANALOG_LOOP_TIME 2000/* 2 * loop */
> #define ANALOG_SAITEK_DELAY 200 /* 200 us */
> #define ANALOG_SAITEK_TIME 2000/* 2000 us */
> @@ -257,7 +257,7 @@ static int analog_cooked_read(struct analog_port *port)
> int i, j;
>
> loopout = (ANALOG_LOOP_TIME * port->loop) / 1000;
> - timeout = ANALOG_MAX_TIME * port->speed;
> + timeout = (ANALOG_MAX_TIME / 1000) * port->speed;
>
> local_irq_save(flags);
> gameport_trigger(gameport);
> @@ -625,20 +625,20 @@ static int analog_init_port(struct gameport *gameport,
> struct gameport_driver *d
>
> gameport_trigger(gameport);
> t = gameport_read(gameport);
> - msleep(ANALOG_MAX_TIME);
> + usleep_range(ANALOG_MAX_TIME, ANALOG_MAX_TIME + 100);
> port->mask = (gameport_read(gameport) ^ t) & t & 0xf;
> port->fuzz = (port->speed * ANALOG_FUZZ_MAGIC) / port->loop /
> 1000 + ANALOG_FUZZ_B
RE: [virtio-dev] Re: [PATCH v2 2/2] crypto: add virtio-crypto driver
Hi Michael, > > Subject: [virtio-dev] Re: [PATCH v2 2/2] crypto: add virtio-crypto driver > > On Tue, Nov 22, 2016 at 04:10:23PM +0800, Gonglei wrote: > > This patch introduces virtio-crypto driver for Linux Kernel. > > > > The virtio crypto device is a virtual cryptography device > > as well as a kind of virtual hardware accelerator for > > virtual machines. The encryption anddecryption requests > > are placed in the data queue and are ultimately handled by > > thebackend crypto accelerators. The second queue is the > > control queue used to create or destroy sessions for > > symmetric algorithms and will control some advanced features > > in the future. The virtio crypto device provides the following > > cryptoservices: CIPHER, MAC, HASH, and AEAD. > > > > For more information about virtio-crypto device, please see: > > http://qemu-project.org/Features/VirtioCrypto > > > > CC: Michael S. Tsirkin > > CC: Cornelia Huck > > CC: Stefan Hajnoczi > > CC: Herbert Xu > > CC: Halil Pasic > > CC: David S. Miller > > CC: Zeng Xin > > Signed-off-by: Gonglei > > --- > > MAINTAINERS | 8 + > > drivers/crypto/Kconfig | 2 + > > drivers/crypto/Makefile | 1 + > > drivers/crypto/virtio/Kconfig| 10 + > > drivers/crypto/virtio/Makefile | 5 + > > drivers/crypto/virtio/virtio_crypto.c| 444 > +++ > > drivers/crypto/virtio/virtio_crypto_algs.c | 524 > +++ > > drivers/crypto/virtio/virtio_crypto_common.h | 124 +++ > > drivers/crypto/virtio/virtio_crypto_mgr.c| 258 + > > include/uapi/linux/Kbuild| 1 + > > include/uapi/linux/virtio_crypto.h | 435 > ++ > > include/uapi/linux/virtio_ids.h | 1 + > > 12 files changed, 1813 insertions(+) > > create mode 100644 drivers/crypto/virtio/Kconfig > > create mode 100644 drivers/crypto/virtio/Makefile > > create mode 100644 drivers/crypto/virtio/virtio_crypto.c > > create mode 100644 drivers/crypto/virtio/virtio_crypto_algs.c > > create mode 100644 drivers/crypto/virtio/virtio_crypto_common.h > > create mode 100644 drivers/crypto/virtio/virtio_crypto_mgr.c > > create mode 100644 include/uapi/linux/virtio_crypto.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 411e3b8..d6b18bb 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -12844,6 +12844,14 @@ S: Maintained > > F: drivers/virtio/virtio_input.c > > F: include/uapi/linux/virtio_input.h > > > > +VIRTIO CRYPTO DRIVER > > +M: Gonglei > > +L: virtualizat...@lists.linux-foundation.org > > +L: linux-cry...@vger.kernel.org > > +S: Maintained > > +F: drivers/crypto/virtio/ > > +F: include/uapi/linux/virtio_crypto.h > > + > > VIA RHINE NETWORK DRIVER > > S: Orphan > > F: drivers/net/ethernet/via/via-rhine.c > > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig > > index 4d2b81f..7956478 100644 > > --- a/drivers/crypto/Kconfig > > +++ b/drivers/crypto/Kconfig > > @@ -555,4 +555,6 @@ config CRYPTO_DEV_ROCKCHIP > > > > source "drivers/crypto/chelsio/Kconfig" > > > > +source "drivers/crypto/virtio/Kconfig" > > + > > endif # CRYPTO_HW > > diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile > > index ad7250f..bc53cb8 100644 > > --- a/drivers/crypto/Makefile > > +++ b/drivers/crypto/Makefile > > @@ -32,3 +32,4 @@ obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/ > > obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/ > > obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/ > > obj-$(CONFIG_CRYPTO_DEV_CHELSIO) += chelsio/ > > +obj-$(CONFIG_CRYPTO_DEV_VIRTIO) += virtio/ > > diff --git a/drivers/crypto/virtio/Kconfig b/drivers/crypto/virtio/Kconfig > > new file mode 100644 > > index 000..ceae88c > > --- /dev/null > > +++ b/drivers/crypto/virtio/Kconfig > > @@ -0,0 +1,10 @@ > > +config CRYPTO_DEV_VIRTIO > > + tristate "VirtIO crypto driver" > > + depends on VIRTIO > > +select CRYPTO_AEAD > > +select CRYPTO_AUTHENC > > +select CRYPTO_BLKCIPHER > > + default m > > + help > > + This driver provides support for virtio crypto device. If you > > + choose 'M' here, this module will be called virtio-crypto. > > diff --git a/drivers/crypto/virtio/Makefile b/drivers/crypto/virtio/Makefile > > new file mode 100644 > > index 000..a316e92 > > --- /dev/null > > +++ b/drivers/crypto/virtio/Makefile > > @@ -0,0 +1,5 @@ > > +obj-$(CONFIG_CRYPTO_DEV_VIRTIO) += virtio-crypto.o > > +virtio-crypto-objs := \ > > + virtio_crypto_algs.o \ > > + virtio_crypto_mgr.o \ > > + virtio_crypto.o > > diff --git a/drivers/crypto/virtio/virtio_crypto.c > b/drivers/crypto/virtio/virtio_crypto.c > > new file mode 100644 > > index 000..56fdfed > > --- /dev/null > > +++ b/drivers/crypto/virtio/virtio_crypto.c > > @@ -0,0 +1,444 @@ > > + /* Driver for Virtio crypto device. > > + * > > + * Copyright 2016 HUAWEI TECHNOLOGIES CO., LTD. > > + *
Re: [PATCH] md/raid5: limit request size according to implementation limits
On 2016/11/28 上午12:32, Konstantin Khlebnikov wrote: > Current implementation employ 16bit counter of active stripes in lower > bits of bio->bi_phys_segments. If request is big enough to overflow > this counter bio will be completed and freed too early. > > Fortunately this not happens in default configuration because several > other limits prevent that: stripe_cache_size * nr_disks effectively > limits count of active stripes. And small max_sectors_kb at lower > disks prevent that during normal read/write operations. > > Overflow easily happens in discard if it's enabled by module parameter > "devices_handle_discard_safely" and stripe_cache_size is set big enough. > > This patch limits requests size with 256Mb - 8Kb to prevent overflows. > > Signed-off-by: Konstantin Khlebnikov > Cc: Shaohua Li > Cc: Neil Brown > Cc: sta...@vger.kernel.org > --- > drivers/md/raid5.c |9 + > 1 file changed, 9 insertions(+) > > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c > index 92ac251e91e6..cce6057b9aca 100644 > --- a/drivers/md/raid5.c > +++ b/drivers/md/raid5.c > @@ -6984,6 +6984,15 @@ static int raid5_run(struct mddev *mddev) > stripe = (stripe | (stripe-1)) + 1; > mddev->queue->limits.discard_alignment = stripe; > mddev->queue->limits.discard_granularity = stripe; > + > + /* > + * We use 16-bit counter of active stripes in bi_phys_segments > + * (minus one for over-loaded initialization) > + */ > + blk_queue_max_hw_sectors(mddev->queue, 0xfffe * STRIPE_SECTORS); > + blk_queue_max_discard_sectors(mddev->queue, > + 0xfffe * STRIPE_SECTORS); > + Could you please to explain why use 0xfffe * STRIPE_SECTORS here ? Thanks. Coly
Re: [PATCH 1/4] serial: core: Add LED trigger support
On 11/24/2016 12:17 AM, Sascha Hauer wrote: > On Wed, Nov 23, 2016 at 10:57:13AM -0800, Florian Fainelli wrote: >> On 11/23/2016 02:01 AM, Sascha Hauer wrote: >>> With this patch the serial core provides LED triggers for RX and TX. >>> >>> As the serial core layer does not know when the hardware actually sends >>> or receives characters, this needs help from the UART drivers. >> >> Looking at 8250, we call serial8250_tx_chars from __start_tx which is >> called form the uart_ops::start_tx, for RX I sort of agree, since this >> happens in interrupt handler. I suppose some drivers could actually >> queue work but not do it right away though? > > RX is not the problem. When characters are received all drivers call > tty_flip_buffer_push() which could be used for LED triggering (either > directly or we replace the calls to tty_flip_buffer_push() with some > wrapper function). > The problem comes with TX. The serial core has a FIFO which gets > characters from the tty layer. There is no function which the serial > drivers could call to read from this FIFO, instead they have to open code > this. > Continuing with the 8250 driver serial8250_tx_chars() is not only called > from __start_tx(), but also from the interrupt handler. Transmission > works without the serial_core ever noticing. > >> >>> The LED triggers are registered in uart_add_led_triggers() called from >>> the UART drivers which want to support LED triggers. All the driver >>> has to do then is to call uart_led_trigger_[tx|rx] to indicate >>> activity. >> >> Could we somehow remedy the lack of knowledge from the core as whether >> the HW sends/receives characters first before adding support for LED >> triggers? It would be more generic and future proof to require UART >> drivers to report to the core when they actually TX/RX, and then at the >> core level, utilize that knowledge to perform the LED trigger. > > Maybe we could introduce a function to read from the TX FIFO. Having > open coded this in each and every driver is not nice anyway. Something like that could be nice to have yes. > >> >> Side note: are you positive using drv->dev_name is robust enough on >> systems with many different UART drivers, yet all of them being ttyS*? > > If we have different UART drivers, only one of them provides ttyS*, no? > Other drivers will have to use another namespace. I remember this was a problem a couple of years ago last I tried, with the 8250 driver being actually preventing other drivers from using ttyS*, but if you don't have 8250 taking over the low ttyS numbers, you may run into a case where several drivers successfully register their character devices under a ttyS* numbering scheme. Whether this is hypothetical or not nowadays, it may be nicer to provide a more uniquely distinct name like what dev_name() returns, or ttyS*-driver-tx for instance? -- Florian
Re: [PATCH v5 14/14] ASoC: add simple-graph-scu-card support
Hi Kuninori,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc7]
[cannot apply to glikely/devicetree/next asoc/for-next next-20161125]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Kuninori-Morimoto/ASoC-add-OF-graph-base-simple-card/20161128-111639
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
sound/soc/generic/simple-graph-scu-card.c: In function
'asoc_simple_card_dai_link_of':
>> sound/soc/generic/simple-graph-scu-card.c:167:3: error: implicit declaration
>> of function 'snd_soc_of_parse_audio_prefix_from_node'
>> [-Werror=implicit-function-declaration]
snd_soc_of_parse_audio_prefix_from_node(&priv->snd_card,
^~~
sound/soc/generic/simple-graph-scu-card.c: In function
'asoc_simple_card_parse_of':
>> sound/soc/generic/simple-graph-scu-card.c:214:8: error: implicit declaration
>> of function 'snd_soc_of_parse_audio_routing_from_node'
>> [-Werror=implicit-function-declaration]
ret = snd_soc_of_parse_audio_routing_from_node(&priv->snd_card,
^~~~
cc1: some warnings being treated as errors
vim +/snd_soc_of_parse_audio_prefix_from_node +167
sound/soc/generic/simple-graph-scu-card.c
161 ret = asoc_simple_card_set_dailink_name(dev, dai_link,
162 "be.%s",
163
dai_link->codec_dai_name);
164 if (ret < 0)
165 return ret;
166
> 167 snd_soc_of_parse_audio_prefix_from_node(&priv->snd_card,
168 port->parent,
169
&priv->codec_conf,
170
dai_link->codec_of_node,
171 PREFIX
"prefix");
172 }
173
174 ret = snd_soc_of_parse_tdm_slot(ep,
175 &dai_props->tx_slot_mask,
176 &dai_props->rx_slot_mask,
177 &dai_props->slots,
178 &dai_props->slot_width);
179 if (ret)
180 return ret;
181
182 ret = asoc_simple_card_canonicalize_dailink(dai_link);
183 if (ret < 0)
184 return ret;
185
186 dai_link->dai_fmt = daifmt;
187 dai_link->dpcm_playback = 1;
188 dai_link->dpcm_capture = 1;
189 dai_link->ops = &asoc_simple_card_ops;
190 dai_link->init = asoc_simple_card_dai_init;
191
192 dev_dbg(dev, "\t%s / %04x / %d\n",
193 dai_link->name,
194 dai_link->dai_fmt,
195 dai_props->sysclk);
196
197 return 0;
198 }
199
200 static int asoc_simple_card_parse_of(struct device_node *node,
201 struct simple_card_data *priv)
202 {
203 struct device *dev = simple_priv_to_dev(priv);
204 struct device *cpu_dev = dev->parent;
205 struct device_node *ports = of_graph_get_top_port(cpu_dev);
206 struct snd_soc_card *card = &priv->snd_card;
207 struct device_node *port, *cpu_ep, *r_cpu_ep, *codec_ep;
208 unsigned int daifmt = 0;
209 int i, ret, done;
210
211 if (!node)
212 return -EINVAL;
213
> 214 ret = snd_soc_of_parse_audio_routing_from_node(&priv->snd_card,
215 ports, PREFIX
"routing");
216 if (ret)
217 return ret;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
RE: [PATCH v2] fsl/usb: Workarourd for USB erratum-A005697
Thanks a lot for you look into this patch, I will fixed these typos.
Best Regards
Jerry Huang
-Original Message-
From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
Sent: Friday, November 25, 2016 9:12 PM
To: Jerry Huang ; st...@rowland.harvard.edu;
gre...@linuxfoundation.org
Cc: Ramneek Mehresh ; julia.law...@lip6.fr; Sriram
Dash ; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] fsl/usb: Workarourd for USB erratum-A005697
Hello.
On 11/25/2016 06:24 AM, Changming Huang wrote:
> The EHCI specification states the following in the SUSP bit description:
> In the Suspend state, the port is senstive to resume detection.
Sensitive.
> Note that the bit status does not change untile the port is suspended
> and
Until.
> that there may be a delay in susupending a port if there is a
> transaction
Suspending.
> currently in progress on the USB.
>
> However, in NXP USBDR controller, the PORTSCx[SUSP] bit changes
> immediately when the application sets it and not when the port is actually
> suspended.
>
> So the application must wait for at least 10 milliseconds after a port
> indicates that it is suspended, to make sure this port has entered
> suspended state before initiating this port resume using the Force
> Port Resume bit. This bit is for NXP controller, not EHCI compatible.
>
> Signed-off-by: Changming Huang
> Signed-off-by: Ramneek Mehresh
[...]
> diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
> index 74f62d6..81e2310 100644
> --- a/drivers/usb/host/ehci-hub.c
> +++ b/drivers/usb/host/ehci-hub.c
> @@ -310,6 +310,13 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
> }
> spin_unlock_irq(&ehci->lock);
>
> + if (changed && ehci_has_fsl_susp_errata(ehci))
> + /* Wait for at least 10 millisecondes to ensure the controller
Milliseconds.
> + * enter the suspend status before initiating a port resume
> + * using the Fore Port Resume bit (Not-EHCI compatible).
Maybe force?
s/Not/non/ also.
> + */
> + usleep_range(1, 2);
> +
> if ((changed && ehci->has_tdi_phy_lpm) || fs_idle_delay) {
> /*
>* Wait for HCD to enter low-power mode or for the bus
[...]
> @@ -703,10 +704,15 @@ struct ehci_tt { #if defined(CONFIG_PPC_85xx)
> /* Some Freescale processors have an erratum (USB A-005275) in which
> * incoming packets get corrupted in HS mode
> + * Some Freescale processors have an erratum (USB A-005697) in which
> + * we need to wait for 10ms for bus to fo into suspend mode after
Fo?
[...]
MBR, Sergei
[PATCH 1/5] KVM: x86: Add a return value to kvm_emulate_cpuid
skip_emulated_instruction is going to grow a return value, and we'll need
to return it from kvm_emulate_cpuid.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/cpuid.c| 3 ++-
arch/x86/kvm/svm.c | 3 +--
arch/x86/kvm/vmx.c | 3 +--
4 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 77cb3f9..80bad5c 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1129,17 +1129,17 @@ void kvm_enable_efer_bits(u64);
bool kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer);
int kvm_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr);
int kvm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr);
struct x86_emulate_ctxt;
int kvm_fast_pio_out(struct kvm_vcpu *vcpu, int size, unsigned short port);
int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size, unsigned short port);
-void kvm_emulate_cpuid(struct kvm_vcpu *vcpu);
+int kvm_emulate_cpuid(struct kvm_vcpu *vcpu);
int kvm_emulate_halt(struct kvm_vcpu *vcpu);
int kvm_vcpu_halt(struct kvm_vcpu *vcpu);
int kvm_emulate_wbinvd(struct kvm_vcpu *vcpu);
void kvm_get_segment(struct kvm_vcpu *vcpu, struct kvm_segment *var, int seg);
int kvm_load_segment_descriptor(struct kvm_vcpu *vcpu, u16 selector, int seg);
void kvm_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu, u8 vector);
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 25f0f15..07cc629 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -874,22 +874,23 @@ void kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx,
u32 *ecx, u32 *edx)
*ecx = best->ecx;
*edx = best->edx;
} else
*eax = *ebx = *ecx = *edx = 0;
trace_kvm_cpuid(function, *eax, *ebx, *ecx, *edx);
}
EXPORT_SYMBOL_GPL(kvm_cpuid);
-void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
+int kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
{
u32 eax, ebx, ecx, edx;
eax = kvm_register_read(vcpu, VCPU_REGS_RAX);
ecx = kvm_register_read(vcpu, VCPU_REGS_RCX);
kvm_cpuid(vcpu, &eax, &ebx, &ecx, &edx);
kvm_register_write(vcpu, VCPU_REGS_RAX, eax);
kvm_register_write(vcpu, VCPU_REGS_RBX, ebx);
kvm_register_write(vcpu, VCPU_REGS_RCX, ecx);
kvm_register_write(vcpu, VCPU_REGS_RDX, edx);
kvm_x86_ops->skip_emulated_instruction(vcpu);
+ return 1;
}
EXPORT_SYMBOL_GPL(kvm_emulate_cpuid);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5e64e656..5bdffcd 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3234,18 +3234,17 @@ static int task_switch_interception(struct vcpu_svm
*svm)
return 0;
}
return 1;
}
static int cpuid_interception(struct vcpu_svm *svm)
{
svm->next_rip = kvm_rip_read(&svm->vcpu) + 2;
- kvm_emulate_cpuid(&svm->vcpu);
- return 1;
+ return kvm_emulate_cpuid(&svm->vcpu);
}
static int iret_interception(struct vcpu_svm *svm)
{
++svm->vcpu.stat.nmi_window_exits;
clr_intercept(svm, INTERCEPT_IRET);
svm->vcpu.arch.hflags |= HF_IRET_MASK;
svm->nmi_iret_rip = kvm_rip_read(&svm->vcpu);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 0e86219..e4af9699 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5832,18 +5832,17 @@ static void vmx_sync_dirty_debug_regs(struct kvm_vcpu
*vcpu)
static void vmx_set_dr7(struct kvm_vcpu *vcpu, unsigned long val)
{
vmcs_writel(GUEST_DR7, val);
}
static int handle_cpuid(struct kvm_vcpu *vcpu)
{
- kvm_emulate_cpuid(vcpu);
- return 1;
+ return kvm_emulate_cpuid(vcpu);
}
static int handle_rdmsr(struct kvm_vcpu *vcpu)
{
u32 ecx = vcpu->arch.regs[VCPU_REGS_RCX];
struct msr_data msr_info;
msr_info.index = ecx;
--
2.10.2
[PATCH 3/5] KVM: VMX: Move skip_emulated_instruction out of nested_vmx_check_vmcs12
We can't return both the pass/fail boolean for the vmcs and the upcoming
continue/exit-to-userspace boolean for skip_emulated_instruction out of
nested_vmx_check_vmcs, so move skip_emulated_instruction out of it instead.
Additionally, VMENTER/VMRESUME only trigger singlestep exceptions when
they advance the IP to the following instruction, not when they a) succeed,
b) fail MSR validation or c) throw an exception. Add a
skip_emulated_instruction_no_trap variant that will not check RFLAGS.TF.
Signed-off-by: Kyle Huey
---
arch/x86/kvm/vmx.c | 60 +++---
1 file changed, 39 insertions(+), 21 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index f2f9cf5..9cc4c41 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2455,28 +2455,33 @@ static void vmx_set_interrupt_shadow(struct kvm_vcpu
*vcpu, int mask)
interruptibility |= GUEST_INTR_STATE_MOV_SS;
else if (mask & KVM_X86_SHADOW_INT_STI)
interruptibility |= GUEST_INTR_STATE_STI;
if ((interruptibility != interruptibility_old))
vmcs_write32(GUEST_INTERRUPTIBILITY_INFO, interruptibility);
}
-static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
+static void skip_emulated_instruction_no_trap(struct kvm_vcpu *vcpu)
{
unsigned long rip;
rip = kvm_rip_read(vcpu);
rip += vmcs_read32(VM_EXIT_INSTRUCTION_LEN);
kvm_rip_write(vcpu, rip);
/* skipping an emulated instruction also counts */
vmx_set_interrupt_shadow(vcpu, 0);
}
+static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
+{
+ skip_emulated_instruction_no_trap(vcpu);
+}
+
/*
* KVM wants to inject page-faults which it got to the guest. This function
* checks whether in a nested guest, we need to inject them to L1 or L2.
*/
static int nested_vmx_check_exception(struct kvm_vcpu *vcpu, unsigned nr)
{
struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
@@ -7319,33 +7324,36 @@ static void copy_vmcs12_to_shadow(struct vcpu_vmx *vmx)
* VMX instructions which assume a current vmcs12 (i.e., that VMPTRLD was
* used before) all generate the same failure when it is missing.
*/
static int nested_vmx_check_vmcs12(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
if (vmx->nested.current_vmptr == -1ull) {
nested_vmx_failInvalid(vcpu);
- skip_emulated_instruction(vcpu);
return 0;
}
return 1;
}
static int handle_vmread(struct kvm_vcpu *vcpu)
{
unsigned long field;
u64 field_value;
unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
u32 vmx_instruction_info = vmcs_read32(VMX_INSTRUCTION_INFO);
gva_t gva = 0;
- if (!nested_vmx_check_permission(vcpu) ||
- !nested_vmx_check_vmcs12(vcpu))
+ if (!nested_vmx_check_permission(vcpu))
+ return 1;
+
+ if (!nested_vmx_check_vmcs12(vcpu)) {
+ skip_emulated_instruction(vcpu);
return 1;
+ }
/* Decode instruction info and find the field to read */
field = kvm_register_readl(vcpu, (((vmx_instruction_info) >> 28) &
0xf));
/* Read the field, zero-extended to a u64 field_value */
if (vmcs12_read_any(vcpu, field, &field_value) < 0) {
nested_vmx_failValid(vcpu, VMXERR_UNSUPPORTED_VMCS_COMPONENT);
skip_emulated_instruction(vcpu);
return 1;
@@ -7383,19 +7391,23 @@ static int handle_vmwrite(struct kvm_vcpu *vcpu)
* mode, and eventually we need to write that into a field of several
* possible lengths. The code below first zero-extends the value to 64
* bit (field_value), and then copies only the appropriate number of
* bits into the vmcs12 field.
*/
u64 field_value = 0;
struct x86_exception e;
- if (!nested_vmx_check_permission(vcpu) ||
- !nested_vmx_check_vmcs12(vcpu))
+ if (!nested_vmx_check_permission(vcpu))
+ return 1;
+
+ if (!nested_vmx_check_vmcs12(vcpu)) {
+ skip_emulated_instruction(vcpu);
return 1;
+ }
if (vmx_instruction_info & (1u << 10))
field_value = kvm_register_readl(vcpu,
(((vmx_instruction_info) >> 3) & 0xf));
else {
if (get_vmx_mem_address(vcpu, exit_qualification,
vmx_instruction_info, false, &gva))
return 1;
@@ -10041,21 +10053,22 @@ static int nested_vmx_run(struct kvm_vcpu *vcpu, bool
launch)
{
struct vmcs12 *vmcs12;
struct vcpu_vmx *vmx = to_vmx(vcpu);
int cpu;
struct loaded_vmcs *vmcs02;
bool ia32e;
u32 msr_entry_idx;
- if (!nested_vmx_check_permission(vcpu) ||
- !nested_vmx_check_vmcs12(vcpu))
+ if (!neste
[PATCH 5/5] KVM: VMX: Handle RFLAGS.TF in skip_emulated_instruction
Similar to the code in kvm_vcpu_check_singlestep, check for TF and,
depending on the origin, synthesize a DB exception or an exit to userspace.
Signed-off-by: Kyle Huey
---
arch/x86/kvm/vmx.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index f404aef..6583e97 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2470,16 +2470,37 @@ static void skip_emulated_instruction_no_trap(struct
kvm_vcpu *vcpu)
/* skipping an emulated instruction also counts */
vmx_set_interrupt_shadow(vcpu, 0);
}
static int skip_emulated_instruction(struct kvm_vcpu *vcpu)
{
skip_emulated_instruction_no_trap(vcpu);
+
+ if (unlikely(vmx_get_rflags(vcpu) & X86_EFLAGS_TF)) {
+ if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
+ vcpu->run->debug.arch.dr6 = DR6_BS | DR6_FIXED_1 |
+ DR6_RTM;
+ vcpu->run->debug.arch.pc = vcpu->arch.singlestep_rip;
+ vcpu->run->debug.arch.exception = DB_VECTOR;
+ vcpu->run->exit_reason = KVM_EXIT_DEBUG;
+ return 0;
+ }
+
+ /*
+* "Certain debug exceptions may clear bit 0-3. The
+* remaining contents of the DR6 register are never
+* cleared by the processor".
+*/
+ vcpu->arch.dr6 &= ~15;
+ vcpu->arch.dr6 |= DR6_BS | DR6_RTM;
+ kvm_queue_exception(vcpu, DB_VECTOR);
+ }
+
return 1;
}
/*
* KVM wants to inject page-faults which it got to the guest. This function
* checks whether in a nested guest, we need to inject them to L1 or L2.
*/
static int nested_vmx_check_exception(struct kvm_vcpu *vcpu, unsigned nr)
--
2.10.2
[PATCH 4/5] KVM: x86: Add a return value to skip_emulated_instruction and propagate it.
Return 1 (for the moment) from skip_emulated_instruction and propagate it
through. This is straightforward, except for:
- ICEBP, which is already inside a trap, so avoid triggering another trap.
- Instructions that can trigger exits to userspace, such as the IO insns,
MOVs to CR8, and HALT. If skip_emulated_instruction does trigger a
KVM_GUESTDBG_SINGLESTEP exit, and the handling code for
IN/OUT/MOV CR8/HALT also triggers an exit to userspace, the latter will
take precedence. The singlestep will be triggered again on the next
instruction, which is the current behavior.
- XSAVES/XRSTORS, which should never be called.
- Task switch instructions which would require additional handling (e.g.
the task switch bit) and are instead modified to use the no_trap
variant.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/kvm_host.h | 4 +-
arch/x86/kvm/cpuid.c| 3 +-
arch/x86/kvm/svm.c | 16 ++--
arch/x86/kvm/vmx.c | 175
arch/x86/kvm/x86.c | 22 +++--
5 files changed, 92 insertions(+), 128 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 80bad5c..f846610 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -919,17 +919,17 @@ struct kvm_x86_ops {
u32 (*get_pkru)(struct kvm_vcpu *vcpu);
void (*fpu_activate)(struct kvm_vcpu *vcpu);
void (*fpu_deactivate)(struct kvm_vcpu *vcpu);
void (*tlb_flush)(struct kvm_vcpu *vcpu);
void (*run)(struct kvm_vcpu *vcpu);
int (*handle_exit)(struct kvm_vcpu *vcpu);
- void (*skip_emulated_instruction)(struct kvm_vcpu *vcpu);
+ int (*skip_emulated_instruction)(struct kvm_vcpu *vcpu);
void (*set_interrupt_shadow)(struct kvm_vcpu *vcpu, int mask);
u32 (*get_interrupt_shadow)(struct kvm_vcpu *vcpu);
void (*patch_hypercall)(struct kvm_vcpu *vcpu,
unsigned char *hypercall_addr);
void (*set_irq)(struct kvm_vcpu *vcpu);
void (*set_nmi)(struct kvm_vcpu *vcpu);
void (*queue_exception)(struct kvm_vcpu *vcpu, unsigned nr,
bool has_error_code, u32 error_code,
@@ -1363,17 +1363,17 @@ void kvm_arch_async_page_not_present(struct kvm_vcpu
*vcpu,
struct kvm_async_pf *work);
void kvm_arch_async_page_present(struct kvm_vcpu *vcpu,
struct kvm_async_pf *work);
void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu,
struct kvm_async_pf *work);
bool kvm_arch_can_inject_async_page_present(struct kvm_vcpu *vcpu);
extern bool kvm_find_async_pf_gfn(struct kvm_vcpu *vcpu, gfn_t gfn);
-void kvm_complete_insn_gp(struct kvm_vcpu *vcpu, int err);
+int kvm_complete_insn_gp(struct kvm_vcpu *vcpu, int err);
int kvm_is_in_guest(void);
int __x86_set_memory_region(struct kvm *kvm, int id, gpa_t gpa, u32 size);
int x86_set_memory_region(struct kvm *kvm, int id, gpa_t gpa, u32 size);
bool kvm_vcpu_is_reset_bsp(struct kvm_vcpu *vcpu);
bool kvm_vcpu_is_bsp(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 07cc629..d733ac2 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -885,12 +885,11 @@ int kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
eax = kvm_register_read(vcpu, VCPU_REGS_RAX);
ecx = kvm_register_read(vcpu, VCPU_REGS_RCX);
kvm_cpuid(vcpu, &eax, &ebx, &ecx, &edx);
kvm_register_write(vcpu, VCPU_REGS_RAX, eax);
kvm_register_write(vcpu, VCPU_REGS_RBX, ebx);
kvm_register_write(vcpu, VCPU_REGS_RCX, ecx);
kvm_register_write(vcpu, VCPU_REGS_RDX, edx);
- kvm_x86_ops->skip_emulated_instruction(vcpu);
- return 1;
+ return kvm_x86_ops->skip_emulated_instruction(vcpu);
}
EXPORT_SYMBOL_GPL(kvm_emulate_cpuid);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5bdffcd..ed28be0 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -603,37 +603,38 @@ static void svm_set_interrupt_shadow(struct kvm_vcpu
*vcpu, int mask)
if (mask == 0)
svm->vmcb->control.int_state &= ~SVM_INTERRUPT_SHADOW_MASK;
else
svm->vmcb->control.int_state |= SVM_INTERRUPT_SHADOW_MASK;
}
-static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
+static int skip_emulated_instruction(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
if (svm->vmcb->control.next_rip != 0) {
WARN_ON_ONCE(!static_cpu_has(X86_FEATURE_NRIPS));
svm->next_rip = svm->vmcb->control.next_rip;
}
if (!svm->next_rip) {
if (emulate_instruction(vcpu, EMULTYPE_SKIP) !=
EMULATE_DONE)
printk(KERN_DEBUG "%s: NOP\n", __func__);
- return;
+ return 1;
[PATCH 2/5] KVM: VMX: Reorder some skip_emulated_instruction calls
The functions being moved ahead of skip_emulated_instruction here don't
need updated IPs, and moving skip_emulated_instruction to the end will
make it easier to return its return value.
Signed-off-by: Kyle Huey
---
arch/x86/kvm/vmx.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e4af9699..f2f9cf5 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5703,18 +5703,18 @@ static int handle_cr(struct kvm_vcpu *vcpu)
vcpu->run->exit_reason = KVM_EXIT_SET_TPR;
return 0;
}
}
break;
case 2: /* clts */
handle_clts(vcpu);
trace_kvm_cr_write(0, kvm_read_cr0(vcpu));
- skip_emulated_instruction(vcpu);
vmx_fpu_activate(vcpu);
+ skip_emulated_instruction(vcpu);
return 1;
case 1: /*mov from cr*/
switch (cr) {
case 3:
val = kvm_read_cr3(vcpu);
kvm_register_write(vcpu, reg, val);
trace_kvm_cr_read(cr, val);
skip_emulated_instruction(vcpu);
@@ -6128,18 +6128,18 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu)
static int handle_ept_misconfig(struct kvm_vcpu *vcpu)
{
int ret;
gpa_t gpa;
gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS);
if (!kvm_io_bus_write(vcpu, KVM_FAST_MMIO_BUS, gpa, 0, NULL)) {
- skip_emulated_instruction(vcpu);
trace_kvm_fast_mmio(gpa);
+ skip_emulated_instruction(vcpu);
return 1;
}
ret = handle_mmio_page_fault(vcpu, gpa, true);
if (likely(ret == RET_MMIO_PF_EMULATE))
return x86_emulate_instruction(vcpu, gpa, 0, NULL, 0) ==
EMULATE_DONE;
@@ -6502,18 +6502,18 @@ static __exit void hardware_unsetup(void)
* Indicate a busy-waiting vcpu in spinlock. We do not enable the PAUSE
* exiting, so only get here on cpu with PAUSE-Loop-Exiting.
*/
static int handle_pause(struct kvm_vcpu *vcpu)
{
if (ple_gap)
grow_ple_window(vcpu);
- skip_emulated_instruction(vcpu);
kvm_vcpu_on_spin(vcpu);
+ skip_emulated_instruction(vcpu);
return 1;
}
static int handle_nop(struct kvm_vcpu *vcpu)
{
skip_emulated_instruction(vcpu);
return 1;
@@ -6957,18 +6957,18 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
vmx->nested.vmcs02_num = 0;
hrtimer_init(&vmx->nested.preemption_timer, CLOCK_MONOTONIC,
HRTIMER_MODE_REL_PINNED);
vmx->nested.preemption_timer.function = vmx_preemption_timer_fn;
vmx->nested.vmxon = true;
- skip_emulated_instruction(vcpu);
nested_vmx_succeed(vcpu);
+ skip_emulated_instruction(vcpu);
return 1;
out_shadow_vmcs:
kfree(vmx->nested.cached_vmcs12);
out_cached_vmcs12:
free_page((unsigned long)vmx->nested.msr_bitmap);
@@ -7078,18 +7078,18 @@ static void free_nested(struct vcpu_vmx *vmx)
}
/* Emulate the VMXOFF instruction */
static int handle_vmoff(struct kvm_vcpu *vcpu)
{
if (!nested_vmx_check_permission(vcpu))
return 1;
free_nested(to_vmx(vcpu));
- skip_emulated_instruction(vcpu);
nested_vmx_succeed(vcpu);
+ skip_emulated_instruction(vcpu);
return 1;
}
/* Emulate the VMCLEAR instruction */
static int handle_vmclear(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
gpa_t vmptr;
@@ -7119,18 +7119,18 @@ static int handle_vmclear(struct kvm_vcpu *vcpu)
}
vmcs12 = kmap(page);
vmcs12->launch_state = 0;
kunmap(page);
nested_release_page(page);
nested_free_vmcs02(vmx, vmptr);
- skip_emulated_instruction(vcpu);
nested_vmx_succeed(vcpu);
+ skip_emulated_instruction(vcpu);
return 1;
}
static int nested_vmx_run(struct kvm_vcpu *vcpu, bool launch);
/* Emulate the VMLAUNCH instruction */
static int handle_vmlaunch(struct kvm_vcpu *vcpu)
{
--
2.10.2
Re: [PATCH v5 12/14] ASoC: add simple-graph-card support
Hi Kuninori,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc7]
[cannot apply to glikely/devicetree/next asoc/for-next next-20161125]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Kuninori-Morimoto/ASoC-add-OF-graph-base-simple-card/20161128-111639
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
sound/soc/generic/simple-graph-card.c: In function
'asoc_simple_card_parse_of':
>> sound/soc/generic/simple-graph-card.c:331:10: error: implicit declaration of
>> function 'snd_soc_of_parse_audio_simple_widgets_from_node'
>> [-Werror=implicit-function-declaration]
ret = snd_soc_of_parse_audio_simple_widgets_from_node(
^~~
>> sound/soc/generic/simple-graph-card.c:340:10: error: implicit declaration of
>> function 'snd_soc_of_parse_audio_routing_from_node'
>> [-Werror=implicit-function-declaration]
ret = snd_soc_of_parse_audio_routing_from_node(
^~~~
cc1: some warnings being treated as errors
vim +/snd_soc_of_parse_audio_simple_widgets_from_node +331
sound/soc/generic/simple-graph-card.c
325 for_each_of_port(node, port) {
326 if (!of_graph_port_type_is_sound(port))
327 continue;
328
329 /* The off-codec widgets */
330 if (of_property_read_bool(port, PREFIX "widgets")) {
> 331 ret =
> snd_soc_of_parse_audio_simple_widgets_from_node(
332 &priv->snd_card,
333 port, PREFIX "widgets");
334 if (ret)
335 return ret;
336 }
337
338 /* DAPM routes */
339 if (of_property_read_bool(port, PREFIX "routing")) {
> 340 ret = snd_soc_of_parse_audio_routing_from_node(
341 &priv->snd_card,
342 port, PREFIX "routing");
343 if (ret)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH 0/5] KVM: VMX: Fix single stepping with emulated instructions.
KVM does not currently honor the trap flag when emulating instructions that cause VM exits. This is observable from guest userspace, try stepping on a CPUID instruction in gdb in a KVM guest. The program will stop two instructions after CPUID. To fix this, in skip_emulated_instruction we can check for RFLAGS.TF. Patch 5 does this. To handle both the guest setting TF and the KVM_GUESTDBG_SINGLESTEP cases we need to be able to indicate to callees that an exit to userspace is required. Patches 1-4 are largely plumbing to make this possible. Traps triggered by task switch instructions require some additional handling and are not implemented. KVM_GUESTDBG_SINGLESTEP traps can be squashed by certain instructions which also trigger userspace exits, such as HALT, MOV CR8, and IO instructions. I believe (although I have not tested) that KVM will simply generate another trap on the next instruction, so this is no worse than the current behavior. These patches only fix this issue for VMX. I don't have AMD silicon to test on. A small patch to kvm-unit-tests is coming in a separate email.
Re: [PATCH] cpufreq: intel_pstate: fix intel_pstate_exit_perf_limits prototype
On 25-11-16, 17:50, Arnd Bergmann wrote:
> The addition of the generic governor support marked the
> intel_pstate_exit_perf_limits as inline, which fixed a warning,
> but it introduced another warning:
>
> drivers/cpufreq/intel_pstate.c: In function ‘intel_pstate_exit_perf_limits’:
> drivers/cpufreq/intel_pstate.c:483:1: error: no return statement in function
> returning non-void [-Werror=return-type]
>
> This changes it back to a 'void' return type, and changes the
> corresponding intel_pstate_init_acpi_perf_limits() function to
> be inline as well for consistency.
>
> Fixes: 001c76f05b01 ("cpufreq: intel_pstate: Generic governors support")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/cpufreq/intel_pstate.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 7159dbde0160..8921686b8cd2 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -474,11 +474,11 @@ static void intel_pstate_exit_perf_limits(struct
> cpufreq_policy *policy)
> }
>
> #else
> -static void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy *policy)
> +static inline void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy
> *policy)
> {
> }
>
> -static inline int intel_pstate_exit_perf_limits(struct cpufreq_policy
> *policy)
> +static inline void intel_pstate_exit_perf_limits(struct cpufreq_policy
> *policy)
> {
> }
> #endif
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH v5 09/14] ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai()
Hi > [auto build test ERROR on robh/for-next] > [also build test ERROR on v4.9-rc7] > [cannot apply to glikely/devicetree/next asoc/for-next next-20161125] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Kuninori-Morimoto/ASoC-add-OF-graph-base-simple-card/20161128-111639 > base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git > for-next > config: i386-randconfig-x002-201648 (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce: > # save the attached .config to linux build tree > make ARCH=i386 I didn't indicate, but, this patch-set is based on Mark's this branch git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git :: topic/of-graph Best regards --- Kuninori Morimoto
[PATCH] ARC: mm: PAE40: Cast pfn to pte_t in pfn_pte() macro
Originally pfn_pte(pfn, prot) macro had this definition: __pte(((pfn) << PAGE_SHIFT) | pgprot_val(prot)) The value of pfn (Page Frame Number) is shifted to the left to get the value of pte (Page Table Entry). Usually a 4-byte value is passed to this macro as value of pfn. However if Linux is configured with support of PAE40 then value of pte has 8-byte type because it must contain additional 8 bits of the physical address. Thus if value of pfn represents a physical page frame above of 4GB boundary then shifting of pfn to the left by PAGE_SHIFT wipes most significant bits of the 40-bit physical address. As a result all physical addresses above of 4GB boundary in systems with PAE40 are mapped to virtual address incorrectly. An error may occur when the kernel tries to unmap such bad pages: [ECR ]: 0x00050100 => Invalid Read @ 0x41414144 by insn @ 0x801644c6 [EFA ]: 0x41414144 [BLINK ]: unmap_page_range+0x134/0x700 [ERET ]: unmap_page_range+0x17a/0x700 [STAT32]: 0x8008021e : IE K BTA: 0x801644c6 SP: 0x901a5e84 FP: 0x5ff35de8 LPS: 0x8026462c LPE: 0x80264630 LPC: 0x r00: 0x8fcc4fc0 r01: 0x2fe68000 r02: 0x41414140 r03: 0x2c05c000 r04: 0x2fe6a000 r05: 0x0009 r06: 0x901b6898 r07: 0x2fe68000 r08: 0x0001 r09: 0x804a807c r10: 0x067e r11: 0x r12: 0x80164480 Stack Trace: unmap_page_range+0x17a/0x700 unmap_vmas+0x46/0x64 do_munmap+0x210/0x450 SyS_munmap+0x2c/0x50 EV_Trap+0xfc/0x100 So the value of pfn must be casted to pte_t before shifting to ensure that 40-bit address will not be truncated: __pte(((pte_t) (pfn) << PAGE_SHIFT) | pgprot_val(prot)) Signed-off-by: Yuriy Kolerov --- arch/arc/include/asm/pgtable.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h index 89eeb37..77bc51c 100644 --- a/arch/arc/include/asm/pgtable.h +++ b/arch/arc/include/asm/pgtable.h @@ -280,7 +280,8 @@ static inline void pmd_set(pmd_t *pmdp, pte_t *ptep) #define pte_page(pte) pfn_to_page(pte_pfn(pte)) #define mk_pte(page, prot) pfn_pte(page_to_pfn(page), prot) -#define pfn_pte(pfn, prot) __pte(((pfn) << PAGE_SHIFT) | pgprot_val(prot)) +#define pfn_pte(pfn, prot) \ + __pte(((pte_t) (pfn) << PAGE_SHIFT) | pgprot_val(prot)) /* Don't use virt_to_pfn for macros below: could cause truncations for PAE40*/ #define pte_pfn(pte) (pte_val(pte) >> PAGE_SHIFT) -- 2.7.4
[PATCH v3] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
GPIO7 is configured in POWERHOLD mode which has higher priority over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON bit is turned off. This property enables driver to over ride the POWERHOLD value to GPIO7 so as to turn off the PMIC in power off scenarios. Signed-off-by: Keerthy Acked-by: Rob Herring --- Remaining patches of the series are already queued. Changes in v3: Added Rob's Ack. Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt index caf297b..c28d4eb8 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt @@ -35,6 +35,15 @@ Optional properties: - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode. Selection primary or secondary function associated to GPADC_START and SYSEN2 pin/pad for DVFS2 interface +- ti,palmas-override-powerhold: This is applicable for PMICs for which + GPIO7 is configured in POWERHOLD mode which has higher priority + over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON + bit is turned off. This property enables driver to over ride the + POWERHOLD value to GPIO7 so as to turn off the PMIC in power off + scenarios. So for GPIO7 if ti,palmas-override-powerhold is set + then the GPIO_7 field should never be muxed to anything else. + It should be set to POWERHOLD by default and only in case of + power off scenarios the driver will over ride the mux value. This binding uses the following generic properties as defined in pinctrl-bindings.txt: -- 1.9.1
linux-next: manual merge of the kvm tree with the tip tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/x86/kvm/cpuid.c
between commit:
c592b5734706 ("x86/fpu: Remove use_eager_fpu()")
from the tip tree and commit:
4504b5c9414c ("kvm: x86: Add AVX512_4VNNIW and AVX512_4FMAPS support")
from the kvm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/kvm/cpuid.c
index 0aefb626fa8f,25f0f15fab1a..
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@@ -16,6 -16,8 +16,7 @@@
#include
#include
#include
+ #include
-#include /* For use_eager_fpu. Ugh! */
#include
#include
#include "cpuid.h"
Re: [PATCH v2 1/5] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
On Thursday 24 November 2016 02:15 PM, Lee Jones wrote: On Thu, 24 Nov 2016, Keerthy wrote: On Tuesday 15 November 2016 07:13 AM, Rob Herring wrote: On Thu, Nov 10, 2016 at 10:39:16AM +0530, Keerthy wrote: GPIO7 is configured in POWERHOLD mode which has higher priority over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON bit is turned off. This property enables driver to over ride the POWERHOLD value to GPIO7 so as to turn off the PMIC in power off scenarios. Signed-off-by: Keerthy --- Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt | 9 + 1 file changed, 9 insertions(+) Acked-by: Rob Herring Tony, Are you planning to pick this one as well? This should be taken by LinusW. Okay. I will post this separately.
linux-next: manual merge of the edac-amd tree with the edac tree
Hi Borislav,
Today's linux-next merge of the edac-amd tree got a conflict in:
drivers/edac/edac_mc.c
between commit:
ef91afa61088 ("edac: move documentation from edac_mc.c to edac_core.h")
from the edac tree and commit:
c73e8833bec5 ("EDAC, mc: Fix locking around mc_devices list")
from the edac-amd tree.
I fixed it up (see below - there may be more fixes needed in
edac_core.h) and can carry the fix as necessary. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/edac/edac_mc.c
index d50653d36918,d2ea9c4f1824..
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@@ -470,6 -499,24 +470,17 @@@ static struct mem_ctl_info *__find_mci_
return NULL;
}
+
-/**
- * find_mci_by_dev
- *
- *scan list of controllers looking for the one that manages
- *the 'dev' device
- * @dev: pointer to a struct device related with the MCI
- */
+ struct mem_ctl_info *find_mci_by_dev(struct device *dev)
+ {
+ struct mem_ctl_info *ret;
+
+ mutex_lock(&mem_ctls_mutex);
+ ret = __find_mci_by_dev(dev);
+ mutex_unlock(&mem_ctls_mutex);
+
+ return ret;
+ }
EXPORT_SYMBOL_GPL(find_mci_by_dev);
/*
@@@ -599,10 -646,18 +610,12 @@@ static int del_mc_from_global_list(stru
return handlers;
}
-/**
- * edac_mc_find: Search for a mem_ctl_info structure whose index is 'idx'.
- *
- * If found, return a pointer to the structure.
- * Else return NULL.
- */
struct mem_ctl_info *edac_mc_find(int idx)
{
+ struct mem_ctl_info *mci = NULL;
struct list_head *item;
- struct mem_ctl_info *mci;
+
+ mutex_lock(&mem_ctls_mutex);
list_for_each(item, &mc_devices) {
mci = list_entry(item, struct mem_ctl_info, link);
Re: [PATCH v5 09/14] ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai()
Hi Kuninori,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc7]
[cannot apply to glikely/devicetree/next asoc/for-next next-20161125]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Kuninori-Morimoto/ASoC-add-OF-graph-base-simple-card/20161128-111639
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-randconfig-x002-201648 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
sound/soc/generic/simple-card-utils.c: In function
'asoc_simple_card_parse_card_name':
sound/soc/generic/simple-card-utils.c:92:8: error: implicit declaration of
function 'snd_soc_of_parse_card_name_from_node'
[-Werror=implicit-function-declaration]
ret = snd_soc_of_parse_card_name_from_node(card, node, prop);
^~~~
sound/soc/generic/simple-card-utils.c: In function
'asoc_simple_card_parse_graph_dai':
>> sound/soc/generic/simple-card-utils.c:210:9: error: implicit declaration of
>> function 'snd_soc_get_dai_name' [-Werror=implicit-function-declaration]
ret = snd_soc_get_dai_name(&args, dai_name);
^~~~
cc1: some warnings being treated as errors
vim +/snd_soc_get_dai_name +210 sound/soc/generic/simple-card-utils.c
86 char prop[128];
87 int ret;
88
89 snprintf(prop, sizeof(prop), "%sname", prefix);
90
91 /* Parse the card name from DT */
> 92 ret = snd_soc_of_parse_card_name_from_node(card, node, prop);
93 if (ret < 0)
94 return ret;
95
96 if (!card->name && card->dai_link)
97 card->name = card->dai_link->name;
98
99 return 0;
100 }
101 EXPORT_SYMBOL_GPL(asoc_simple_card_parse_card_name);
102
103 int asoc_simple_card_parse_clk(struct device_node *node,
104 struct device_node *dai_of_node,
105 struct asoc_simple_dai *simple_dai)
106 {
107 struct clk *clk;
108 u32 val;
109
110 /*
111 * Parse dai->sysclk come from "clocks = <&xxx>"
112 * (if system has common clock)
113 * or "system-clock-frequency = "
114 * or device's module clock.
115 */
116 clk = of_clk_get(node, 0);
117 if (!IS_ERR(clk)) {
118 simple_dai->sysclk = clk_get_rate(clk);
119 simple_dai->clk = clk;
120 } else if (!of_property_read_u32(node,
"system-clock-frequency", &val)) {
121 simple_dai->sysclk = val;
122 } else {
123 clk = of_clk_get(dai_of_node, 0);
124 if (!IS_ERR(clk))
125 simple_dai->sysclk = clk_get_rate(clk);
126 }
127
128 return 0;
129 }
130 EXPORT_SYMBOL_GPL(asoc_simple_card_parse_clk);
131
132 int asoc_simple_card_parse_dai(struct device_node *node,
133 struct device_node **dai_of_node,
134 const char **dai_name,
135 const char *list_name,
136 const char *cells_name,
137 int *is_single_link)
138 {
139 struct of_phandle_args args;
140 int ret;
141
142 if (!node)
143 return 0;
144
145 /*
146 * Get node via "sound-dai = <&phandle port>"
147 * it will be used as xxx_of_node on soc_bind_dai_link()
148 */
149 ret = of_parse_phandle_with_args(node, list_name, cells_name,
0, &args);
150 if (ret)
151 return ret;
152
153 /* Get dai->name */
154 if (dai_name) {
155 ret = snd_soc_of_get_dai_name(node, dai_name);
156 if (ret < 0)
157 return ret;
158 }
159
160 *dai_of_node = args.np;
161
162 if (is_single_link)
163 *is_single_link = !args.args_count;
164
165 return 0;
166 }
167 EXPORT_SYMBOL_GPL(asoc_simple_card_parse_dai);
168
169 int asoc_simple_card_parse_graph_dai(struct device_node *ep,
170 struct device_node **dai_of_node,
171 const char **dai_name)
172 {
173 struct device_node *node, *port, *endpoint;
174 int i, id;
Re: [PATCH 3/3] hwmon: tmp108: Update driver to use hwmon_chip_info.
On 11/27/2016 06:10 PM, John Muir wrote: On 2016.11.27, at 15:00 , Guenter Roeck wrote: On Sat, Nov 26, 2016 at 09:15:37PM -0800, John Muir wrote: Move the tmp108 driver from hwmon attribute groups to hwmon_chip_info. Signed-off-by: John Muir --- Hi John, please have a look at the following patch. Something else: Symbolic permissions are out of favor nowadays. You might instead just use 0644 / 0444. Not that I really care, but it prevents the inevitable follow-up patches. Hi Guenter, Thank you for this patch. I will attempt to implement the same changes using the older interfaces in my 4.4 implementation. I will incorporate your changes and other comments as soon as I can (early this week) and re-send my patch series. Hi John, My pleasure. I also wrote a module test for the driver (with my patch applied): https://github.com/groeck/module-tests/blob/master/scripts/tmp108.sh Just in case you want to give it a try. Guenter
[bug report v4.8] fs/locks.c: kernel oops during posix lock stress test
Hi Guys, When I run stress-ng via the following steps on one ARM64 dual socket system(Cavium Thunder), the kernel oops[1] can often be triggered after running the stress test for several hours(sometimes it may take longer): - git clone git://kernel.ubuntu.com/cking/stress-ng.git - apply the attachment patch which just makes the posix file lock stress test more aggressive - run the test via '~/git/stress-ng$./stress-ng --lockf 128 --aggressive' >From the oops log, looks one garbage file_lock node is got from the linked list of 'ctx->flc_posix' when the issue happens. BTW, the issue isn't observed on single socket Cavium Thunder yet, and the same issue can be seen on Ubuntu Xenial(v4.4 based kernel) too. Thanks, Ming [1] kernel oops log ubuntu@ubuntu:~/git/stress-ng$ ./stress-ng --lockf 128 --aggressive stress-ng: info: [63828] defaulting to a 86400 second run per stressor stress-ng: info: [63828] dispatching hogs: 128 lockf stress-ng: info: [63828] cache allocate: default cache size: 16384K [80659.799092] Unable to handle kernel NULL pointer dereference at virtual address 0030 [80659.807219] pgd = 81001f365800 [80659.810683] [0030] *pgd=01001a290003, *pud=01001a290003, *pmd=010fa07f0003, *pte= [80659.821029] Internal error: Oops: 9607 [#1] SMP [80659.825901] Modules linked in: [80659.828962] CPU: 15 PID: 63848 Comm: stress-ng-lockf Tainted: G W 4.8.0 #167 [80659.837132] Hardware name: Cavium ThunderX CRB/To be filled by O.E.M., BIOS 5.11 12/12/2012 [80659.845479] task: 81001ee78580 task.stack: 81001f798000 [80659.851402] PC is at posix_locks_conflict+0x94/0xc0 [80659.856282] LR is at posix_lock_inode+0x90/0x6b0 [80659.860896] pc : [] lr : [] pstate: a145 [80659.868285] sp : 81001f79bca0 [80659.871596] x29: 81001f79bca0 x28: 81001f798000 [80659.876915] x27: 800fdffbc160 x26: [80659.882234] x25: 800fd2da2b30 x24: 800fce927430 [80659.887551] x23: 800fce92d8f0 x22: 81001f79bd30 [80659.892869] x21: 800fd2da2b18 x20: fff8 [80659.898187] x19: 800fdffbc160 x18: 1140 [80659.903504] x17: 8870a578 x16: 08245768 [80659.908821] x15: 888bc000 x14: [80659.914139] x13: 0003e800 x12: 0018 [80659.919457] x11: 000e6a17 x10: ffd0 [80659.924776] x9 : x8 : 800fce927500 [80659.930094] x7 : x6 : 007f [80659.935413] x5 : 0080 x4 : 800fce927438 [80659.940729] x3 : 800fce927458 x2 : 26b9 [80659.946047] x1 : 81001f37f300 x0 : [80659.951363] [80659.952851] Process stress-ng-lockf (pid: 63848, stack limit = 0x81001f798020) [80659.960415] Stack: (0x81001f79bca0 to 0x81001f79c000) [80659.966158] bca0: 81001f79bcc0 0828cd90 fff8 800fa3a66568 [80659.973986] bcc0: 81001f79bd40 0828d5f0 800f8185c700 800fdffbc160 [80659.981812] bce0: 0006 81001f79bdd0 0006 [80659.989638] bd00: 0120 0019 088b1000 81001f798000 [80659.997465] bd20: 81001f79bd40 08403fec 81001f79bd30 81001f79bd30 [80660.005292] bd40: 81001f79bd70 0828d8bc 800f8185c700 800fdffbc160 [80660.013118] bd60: 800fdffbc1b8 800f8185c700 81001f79bde0 0828ef10 [80660.020944] bd80: 800f8185c700 800fdffbc160 800fa3a66568 [80660.028770] bda0: 0006 0004 81001f79bde0 0828ee14 [80660.036596] bdc0: 800f8185c700 fff2 800fdffbc160 810ff99aae80 [80660.044423] bde0: 81001f79be70 08245b84 800f8185c700 800f8185c700 [80660.052249] be00: 0006 dad5d4b0 0004 [80660.060087] be20: 0120 003e 00010001 [80660.067916] be40: 0008 00010001 [80660.075742] be60: 0008 080836f0 [80660.083568] be80: 005c5000 8870a3b8 [80660.091394] bea0: 8000 0015 8000 005c5000 [80660.099220] bec0: 0004 0006 dad5d4b0 ff80 [80660.107046] bee0: dad5d490 26c26373 176f 4650 [80660.114873] bf00: 0019 6536 ffd0 000e6a17 [80660.122698] bf20: 0018 0003e800 888bc000 [80660.130524] bf40: 0048a170 8870a578 1140 055f [80660.138351] bf60: 005c5000 0004 879f9008 [80660.146177] bf80: 0002 0048b530 2001000800400201 dad60758 [80660.154004] bfa
[PATCH v13 3/8] x86/arch_prctl: Add do_arch_prctl_common
Add do_arch_prctl_common() to handle arch_prctls that are not specific to 64
bit mode. Call it from the syscall entry point, but not any of the other
callsites in the kernel, which all want one of the existing 64 bit only
arch_prctls.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/proto.h | 3 +++
arch/x86/kernel/process.c| 6 ++
arch/x86/kernel/process_64.c | 8 +++-
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index f8e9194..99836d9 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -26,9 +26,12 @@ void entry_SYSCALL_compat(void);
void entry_INT80_compat(void);
#endif
void x86_configure_nx(void);
void x86_report_nx(void);
extern int reboot_force;
+long do_arch_prctl_common(struct task_struct *task, int code,
+ unsigned long cpuid_enabled);
+
#endif /* _ASM_X86_PROTO_H */
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 0888a87..5ac20b5 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -579,8 +579,14 @@ unsigned long get_wchan(struct task_struct *p)
}
fp = READ_ONCE_NOCHECK(*(unsigned long *)fp);
} while (count++ < 16 && p->state != TASK_RUNNING);
out:
put_task_stack(p);
return ret;
}
+
+long do_arch_prctl_common(struct task_struct *task, int code,
+ unsigned long cpuid_enabled)
+{
+ return -EINVAL;
+}
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 611df20..bf75d26 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -612,15 +612,21 @@ long do_arch_prctl_64(struct task_struct *task, int code,
unsigned long arg2)
break;
}
return ret;
}
SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
{
- return do_arch_prctl_64(current, code, arg2);
+ long ret;
+
+ ret = do_arch_prctl_64(current, code, arg2);
+ if (ret == -EINVAL)
+ ret = do_arch_prctl_common(current, code, arg2);
+
+ return ret;
}
unsigned long KSTK_ESP(struct task_struct *task)
{
return task_pt_regs(task)->sp;
}
--
2.10.2
[PATCH v13 4/8] x86/syscalls/32: Wire up arch_prctl on x86-32
Hook up arch_prctl to call do_arch_prctl() on x86-32, and in 32 bit compat
mode on x86-64. This allows us to have arch_prctls that are not specific to
64 bits.
On UML, simply stub out this syscall.
Signed-off-by: Kyle Huey
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/kernel/process_32.c | 7 +++
arch/x86/kernel/process_64.c | 7 +++
arch/x86/um/Makefile | 2 +-
arch/x86/um/syscalls_32.c | 7 +++
include/linux/compat.h | 2 ++
6 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/um/syscalls_32.c
diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
b/arch/x86/entry/syscalls/syscall_32.tbl
index 2b36185..d78c6b5 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -384,8 +384,9 @@
375i386membarrier sys_membarrier
376i386mlock2 sys_mlock2
377i386copy_file_range sys_copy_file_range
378i386preadv2 sys_preadv2
compat_sys_preadv2
379i386pwritev2sys_pwritev2
compat_sys_pwritev2
380i386pkey_mprotect sys_pkey_mprotect
381i386pkey_alloc sys_pkey_alloc
382i386pkey_free sys_pkey_free
+385i386arch_prctl sys_arch_prctl
compat_sys_arch_prctl
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index bd7be8e..95d3adc 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -30,16 +30,17 @@
#include
#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#ifdef CONFIG_MATH_EMULATION
#include
@@ -49,16 +50,17 @@
#include
#include
#include
#include
#include
#include
#include
+#include
void __show_regs(struct pt_regs *regs, int all)
{
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
unsigned long d0, d1, d2, d3, d6, d7;
unsigned long sp;
unsigned short ss, gs;
@@ -296,8 +298,13 @@ __switch_to(struct task_struct *prev_p, struct task_struct
*next_p)
lazy_load_gs(next->gs);
switch_fpu_finish(next_fpu, fpu_switch);
this_cpu_write(current_task, next_p);
return prev_p;
}
+
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+{
+ return do_arch_prctl_common(current, code, arg2);
+}
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index bf75d26..3a2a84d 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -621,12 +621,19 @@ SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long,
arg2)
ret = do_arch_prctl_64(current, code, arg2);
if (ret == -EINVAL)
ret = do_arch_prctl_common(current, code, arg2);
return ret;
}
+#ifdef CONFIG_IA32_EMULATION
+COMPAT_SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+{
+ return do_arch_prctl_common(current, code, arg2);
+}
+#endif
+
unsigned long KSTK_ESP(struct task_struct *task)
{
return task_pt_regs(task)->sp;
}
diff --git a/arch/x86/um/Makefile b/arch/x86/um/Makefile
index e7e7055..69f0827 100644
--- a/arch/x86/um/Makefile
+++ b/arch/x86/um/Makefile
@@ -11,17 +11,17 @@ endif
obj-y = bug.o bugs_$(BITS).o delay.o fault.o ldt.o \
ptrace_$(BITS).o ptrace_user.o setjmp_$(BITS).o signal.o \
stub_$(BITS).o stub_segv.o \
sys_call_table_$(BITS).o sysrq_$(BITS).o tls_$(BITS).o \
mem_$(BITS).o subarch.o os-$(OS)/
ifeq ($(CONFIG_X86_32),y)
-obj-y += checksum_32.o
+obj-y += checksum_32.o syscalls_32.o
obj-$(CONFIG_ELF_CORE) += elfcore.o
subarch-y = ../lib/string_32.o ../lib/atomic64_32.o ../lib/atomic64_cx8_32.o
subarch-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += ../lib/rwsem.o
else
obj-y += syscalls_64.o vdso/
diff --git a/arch/x86/um/syscalls_32.c b/arch/x86/um/syscalls_32.c
new file mode 100644
index 000..ccf0598
--- /dev/null
+++ b/arch/x86/um/syscalls_32.c
@@ -0,0 +1,7 @@
+#include
+#include
+
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+{
+ return -EINVAL;
+}
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 6360939..0ddfc2ba 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -716,16 +716,18 @@ int __compat_save_altstack(compat_stack_t __user *,
unsigned long);
} while (0);
asmlinkage long compat_sys_sched_rr_get_interval(compat_pid_t pid,
struct compat_timespec __user
*interval);
asmlinkage long compat_sys_fanotify_mark(int, unsigned int, __u32, __u32,
int, const char __user *);
+asmlinkage long compat_sys_arch_prctl(int code, unsigned long arg2);
+
/*
* For most but not all architectures, "am I in a c
[PATCH v13 5/8] x86/cpufeature: Detect CPUID faulting support
Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
When enabled, the processor will fault on attempts to execute the CPUID
instruction with CPL>0. This will allow a ptracer to emulate the CPUID
instruction.
Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
documented in detail in Section 2.3.2 of
https://bugzilla.kernel.org/attachment.cgi?id=243991
Detect support for this feature and expose it as X86_FEATURE_CPUID_FAULT.
Signed-off-by: Kyle Huey
Reviewed-by: Borislav Petkov
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 2 ++
arch/x86/kernel/cpu/intel.c| 12
3 files changed, 15 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index a396292..85f853f 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -182,16 +182,17 @@
/*
* Auxiliary flags: Linux defined - For features scattered in various
* CPUID levels like 0x6, 0xA etc, word 7.
*
* Reuse free bits when adding new feature flags!
*/
+#define X86_FEATURE_CPUID_FAULT ( 7*32+ 0) /* Intel CPUID faulting */
#define X86_FEATURE_CPB( 7*32+ 2) /* AMD Core Performance
Boost */
#define X86_FEATURE_EPB( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS
support */
#define X86_FEATURE_HW_PSTATE ( 7*32+ 8) /* AMD HW-PState */
#define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
#define X86_FEATURE_INTEL_PT ( 7*32+15) /* Intel Processor Trace */
#define X86_FEATURE_AVX512_4VNNIW (7*32+16) /* AVX-512 Neural Network
Instructions */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 78f3760..3ac0acf 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -36,16 +36,18 @@
#define EFER_LMSLE (1<<_EFER_LMSLE)
#define EFER_FFXSR (1<<_EFER_FFXSR)
/* Intel MSRs. Some also available on other CPUs */
#define MSR_IA32_PERFCTR0 0x00c1
#define MSR_IA32_PERFCTR1 0x00c2
#define MSR_FSB_FREQ 0x00cd
#define MSR_PLATFORM_INFO 0x00ce
+#define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
+#define MSR_PLATFORM_INFO_CPUID_FAULT
BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
#define MSR_NHM_SNB_PKG_CST_CFG_CTL0x00e2
#define NHM_C3_AUTO_DEMOTE (1UL << 25)
#define NHM_C1_AUTO_DEMOTE (1UL << 26)
#define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
#define SNB_C1_AUTO_UNDEMOTE (1UL << 27)
#define SNB_C3_AUTO_UNDEMOTE (1UL << 28)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index fcd484d..12f 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -447,16 +447,26 @@ static void intel_bsp_resume(struct cpuinfo_x86 *c)
{
/*
* MSR_IA32_ENERGY_PERF_BIAS is lost across suspend/resume,
* so reinitialize it properly like during bootup:
*/
init_intel_energy_perf(c);
}
+static void init_intel_misc_features(struct cpuinfo_x86 *c)
+{
+ u64 msr;
+
+ if (!rdmsrl_safe(MSR_PLATFORM_INFO, &msr)) {
+ if (msr & MSR_PLATFORM_INFO_CPUID_FAULT)
+ set_cpu_cap(c, X86_FEATURE_CPUID_FAULT);
+ }
+}
+
static void init_intel(struct cpuinfo_x86 *c)
{
unsigned int l2 = 0;
early_init_intel(c);
intel_workarounds(c);
@@ -560,16 +570,18 @@ static void init_intel(struct cpuinfo_x86 *c)
/* Work around errata */
srat_detect_node(c);
if (cpu_has(c, X86_FEATURE_VMX))
detect_vmx_virtcap(c);
init_intel_energy_perf(c);
+
+ init_intel_misc_features(c);
}
#ifdef CONFIG_X86_32
static unsigned int intel_size_cache(struct cpuinfo_x86 *c, unsigned int size)
{
/*
* Intel PIII Tualatin. This comes in two flavours.
* One has 256kb of cache, the other 512. We have no way
--
2.10.2
Re: [PATCH v2] Avoid nested function definition
On 2016/11/28 上午10:50, Peter Foley wrote:
> Fixes below error with clang:
> ../drivers/md/bcache/sysfs.c:759:3: error: function definition is not allowed
> here
> { return *((uint16_t *) r) - *((uint16_t *) l); }
> ^
> ../drivers/md/bcache/sysfs.c:789:32: error: use of undeclared identifier 'cmp'
> sort(p, n, sizeof(uint16_t), cmp, NULL);
> ^
> 2 errors generated.
>
> v2:
> rename function to __bch_cache_cmp
>
> Signed-off-by: Peter Foley
> ---
> drivers/md/bcache/sysfs.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
> index b3ff57d61dde..8f12089a69e7 100644
> --- a/drivers/md/bcache/sysfs.c
> +++ b/drivers/md/bcache/sysfs.c
> @@ -731,6 +731,11 @@ static struct attribute *bch_cache_set_internal_files[]
> = {
> };
> KTYPE(bch_cache_set_internal);
>
> +static int __bch_cache_cmp(const void *l, const void *r)
> +{
> + return *((uint16_t *)r) - *((uint16_t *)l);
> +}
> +
> SHOW(__bch_cache)
> {
> struct cache *ca = container_of(kobj, struct cache, kobj);
> @@ -755,9 +760,6 @@ SHOW(__bch_cache)
> CACHE_REPLACEMENT(&ca->sb));
>
> if (attr == &sysfs_priority_stats) {
> - int cmp(const void *l, const void *r)
> - { return *((uint16_t *) r) - *((uint16_t *) l); }
> -
> struct bucket *b;
> size_t n = ca->sb.nbuckets, i;
> size_t unused = 0, available = 0, dirty = 0, meta = 0;
> @@ -786,7 +788,7 @@ SHOW(__bch_cache)
> p[i] = ca->buckets[i].prio;
> mutex_unlock(&ca->set->bucket_lock);
>
> - sort(p, n, sizeof(uint16_t), cmp, NULL);
> + sort(p, n, sizeof(uint16_t), __bch_cache_cmp, NULL);
>
> while (n &&
> !cached[n - 1])
>
Acked-by: Coly Li
--
Coly Li
[PATCH v13 7/8] x86/arch_prctl: Selftest for ARCH_[GET|SET]_CPUID
Test disabling and reenabling the cpuid instruction via the new arch_prctl
ARCH_SET_CPUID, retrieving the current state via ARCH_GET_CPUID, and the
expected behaviors across fork() and exec().
Signed-off-by: Kyle Huey
---
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/cpuid-fault.c | 251 ++
2 files changed, 252 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/x86/cpuid-fault.c
diff --git a/tools/testing/selftests/x86/Makefile
b/tools/testing/selftests/x86/Makefile
index a89f80a..3744f28 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -1,17 +1,17 @@
all:
include ../lib.mk
.PHONY: all all_32 all_64 warn_32bit_failure clean
TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt
ptrace_syscall test_mremap_vdso \
check_initial_reg_state sigreturn ldt_gdt iopl \
- protection_keys
+ protection_keys cpuid-fault
TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso
unwind_vdso \
test_FCMOV test_FCOMI test_FISTTP \
vdso_restorer
TARGETS_C_64BIT_ONLY := fsgsbase
TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
TARGETS_C_64BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_64BIT_ONLY)
BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
diff --git a/tools/testing/selftests/x86/cpuid-fault.c
b/tools/testing/selftests/x86/cpuid-fault.c
new file mode 100644
index 000..d061abd
--- /dev/null
+++ b/tools/testing/selftests/x86/cpuid-fault.c
@@ -0,0 +1,251 @@
+
+/*
+ * Tests for arch_prctl(ARCH_GET_CPUID, ...) / arch_prctl(ARCH_SET_CPUID, ...)
+ *
+ * Basic test to test behaviour of ARCH_GET_CPUID and ARCH_SET_CPUID
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+/*
+#define ARCH_GET_CPUID 0x1005
+#define ARCH_SET_CPUID 0x1006
+#ifdef __x86_64__
+#define SYS_arch_prctl 158
+#else
+#define SYS_arch_prctl 385
+#endif
+*/
+
+const char *cpuid_names[] = {
+ [0] = "[cpuid disabled]",
+ [1] = "[cpuid enabled]",
+};
+
+int arch_prctl(int code, unsigned long arg2)
+{
+ return syscall(SYS_arch_prctl, code, arg2);
+}
+
+int cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
+ unsigned int *edx)
+{
+ return __get_cpuid(0, eax, ebx, ecx, edx);
+}
+
+int do_child_exec_test(int eax, int ebx, int ecx, int edx)
+{
+ int cpuid_val = 0, child = 0, status = 0;
+
+ printf("arch_prctl(ARCH_GET_CPUID); ");
+
+ cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
+ if (cpuid_val < 0)
+ errx(1, "ARCH_GET_CPUID fails now, but not before?");
+
+ printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
+ if (cpuid_val != 0)
+ errx(1, "How did cpuid get re-enabled on fork?");
+
+ child = fork();
+ if (child == 0) {
+ cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
+ if (cpuid_val < 0)
+ errx(1, "ARCH_GET_CPUID fails now, but not before?");
+
+ printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
+ if (cpuid_val != 0)
+ errx(1, "How did cpuid get re-enabled on fork?");
+
+ printf("exec\n");
+ execl("/proc/self/exe", "cpuid-fault", "-early-return", NULL);
+ }
+
+ if (child != waitpid(child, &status, 0))
+ errx(1, "waitpid failed!?");
+
+ if (WEXITSTATUS(status) != 0)
+ errx(1, "Execed child exited abnormally");
+
+ return 0;
+}
+
+int child_received_signal;
+
+void child_sigsegv_cb(int sig)
+{
+ int cpuid_val = 0;
+
+ child_received_signal = 1;
+ printf("[ SIG_SEGV ]\n");
+ printf("arch_prctl(ARCH_GET_CPUID); ");
+
+ cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
+ if (cpuid_val < 0)
+ errx(1, "ARCH_GET_CPUID fails now, but not before?");
+
+ printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
+ printf("arch_prctl(ARCH_SET_CPUID, 1)\n");
+ if (arch_prctl(ARCH_SET_CPUID, 1) != 0)
+ exit(errno);
+
+ printf("cpuid() == ");
+}
+
+int do_child_test(void)
+{
+ unsigned int eax = 0, ebx = 0, ecx = 0, edx = 0;
+
+ signal(SIGSEGV, child_sigsegv_cb);
+
+ /* the child starts out with cpuid disabled, the signal handler
+* attempts to enable and retry
+*/
+ printf("cpuid() == ");
+ cpuid(&eax, &ebx, &ecx, &edx);
+ printf("{%x, %x, %x, %x}\n", eax, ebx, ecx, edx);
+ return child_received_signal ? 0 : 42;
+}
+
+int signal_count;
+
+void sigsegv_cb(int sig)
+{
+ int cpuid_val = 0;
+
+ signal_count++;
+ printf("[ SIG_SEGV ]\n");
+ printf("arch_prctl(ARCH_GET_CPUID); ");
+
+ cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
+ if (
[PATCH v13 2/8] x86/arch_prctl/64: Rename do_arch_prctl to do_arch_prctl_64
In order to introduce new arch_prctls that are not 64 bit only, rename the
existing 64 bit implementation to do_arch_prctl_64(). Also rename the second
argument to arch_prctl(), which will no longer always be an address.
Signed-off-by: Kyle Huey
Reviewed-by: Andy Lutomirski
---
arch/um/include/shared/os.h | 2 +-
arch/x86/include/asm/proto.h | 3 +--
arch/x86/kernel/process_64.c | 32 +---
arch/x86/kernel/ptrace.c | 8
arch/x86/um/os-Linux/prctl.c | 4 ++--
arch/x86/um/syscalls_64.c| 12 ++--
6 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index de5d572..2b47e0e 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -298,17 +298,17 @@ extern void os_set_ioignore(void);
/* sigio.c */
extern int add_sigio_fd(int fd);
extern int ignore_sigio_fd(int fd);
extern void maybe_sigio_broken(int fd, int read);
extern void sigio_broken(int fd, int read);
/* sys-x86_64/prctl.c */
-extern int os_arch_prctl(int pid, int code, unsigned long *addr);
+extern int os_arch_prctl(int pid, int code, unsigned long *arg2);
/* tty.c */
extern int get_pty(void);
/* sys-$ARCH/task_size.c */
extern unsigned long os_get_top_address(void);
long syscall(long number, ...);
diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index 9b9b30b..f8e9194 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -4,16 +4,17 @@
#include
/* misc architecture specific prototypes */
void syscall_init(void);
#ifdef CONFIG_X86_64
void entry_SYSCALL_64(void);
+long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2);
#endif
#ifdef CONFIG_X86_32
void entry_INT80_32(void);
void entry_SYSENTER_32(void);
void __begin_SYSENTER_singlestep_region(void);
void __end_SYSENTER_singlestep_region(void);
#endif
@@ -25,11 +26,9 @@ void entry_SYSCALL_compat(void);
void entry_INT80_compat(void);
#endif
void x86_configure_nx(void);
void x86_report_nx(void);
extern int reboot_force;
-long do_arch_prctl(struct task_struct *task, int code, unsigned long addr);
-
#endif /* _ASM_X86_PROTO_H */
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 2718cf9..611df20 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -193,17 +193,17 @@ int copy_thread_tls(unsigned long clone_flags, unsigned
long sp,
*/
if (clone_flags & CLONE_SETTLS) {
#ifdef CONFIG_IA32_EMULATION
if (in_ia32_syscall())
err = do_set_thread_area(p, -1,
(struct user_desc __user *)tls, 0);
else
#endif
- err = do_arch_prctl(p, ARCH_SET_FS, tls);
+ err = do_arch_prctl_64(p, ARCH_SET_FS, tls);
if (err)
goto out;
}
err = 0;
out:
if (err && p->thread.io_bitmap_ptr) {
kfree(p->thread.io_bitmap_ptr);
p->thread.io_bitmap_max = 0;
@@ -534,91 +534,93 @@ static long prctl_map_vdso(const struct vdso_image
*image, unsigned long addr)
ret = map_vdso_once(image, addr);
if (ret)
return ret;
return (long)image->size;
}
#endif
-long do_arch_prctl(struct task_struct *task, int code, unsigned long addr)
+long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2)
{
int ret = 0;
int doit = task == current;
int cpu;
switch (code) {
case ARCH_SET_GS:
- if (addr >= TASK_SIZE_MAX)
+ if (arg2 >= TASK_SIZE_MAX)
return -EPERM;
cpu = get_cpu();
task->thread.gsindex = 0;
- task->thread.gsbase = addr;
+ task->thread.gsbase = arg2;
if (doit) {
load_gs_index(0);
- ret = wrmsrl_safe(MSR_KERNEL_GS_BASE, addr);
+ ret = wrmsrl_safe(MSR_KERNEL_GS_BASE, arg2);
}
put_cpu();
break;
case ARCH_SET_FS:
/* Not strictly needed for fs, but do it for symmetry
with gs */
- if (addr >= TASK_SIZE_MAX)
+ if (arg2 >= TASK_SIZE_MAX)
return -EPERM;
cpu = get_cpu();
task->thread.fsindex = 0;
- task->thread.fsbase = addr;
+ task->thread.fsbase = arg2;
if (doit) {
/* set the selector to 0 to not confuse __switch_to */
loadsegment(fs, 0);
- ret = wrmsrl_safe(MSR_FS_BASE, addr);
+ ret = wrmsrl_safe(MSR_FS_BASE, arg2);
}
put_cpu();
break;
case ARCH_
[PATCH v13 8/8] KVM: x86: virtualize cpuid faulting
Hardware support for faulting on the cpuid instruction is not required to
emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant
MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a
cpuid-induced VM exit checks the cpuid faulting state and the CPL.
kvm_require_cpl is even kind enough to inject the GP fault for us.
Signed-off-by: Kyle Huey
Reviewed-by: David Matlack
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/cpuid.c| 3 +++
arch/x86/kvm/cpuid.h| 11 +++
arch/x86/kvm/emulate.c | 7 +++
arch/x86/kvm/x86.c | 26 ++
5 files changed, 49 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index bdde807..954f37c 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -592,16 +592,18 @@ struct kvm_vcpu_arch {
u64 pat;
unsigned switch_db_regs;
unsigned long db[KVM_NR_DB_REGS];
unsigned long dr6;
unsigned long dr7;
unsigned long eff_db[KVM_NR_DB_REGS];
unsigned long guest_debug_dr7;
+ u64 msr_platform_info;
+ u64 msr_misc_features_enables;
u64 mcg_cap;
u64 mcg_status;
u64 mcg_ctl;
u64 mcg_ext_ctl;
u64 *mce_banks;
/* Cache MMIO info */
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index afa7bbb..0109bc0 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -862,16 +862,19 @@ void kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx,
u32 *ecx, u32 *edx)
trace_kvm_cpuid(function, *eax, *ebx, *ecx, *edx);
}
EXPORT_SYMBOL_GPL(kvm_cpuid);
void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
{
u32 function, eax, ebx, ecx, edx;
+ if (cpuid_fault_enabled(vcpu) && !kvm_require_cpl(vcpu, 0))
+ return;
+
function = eax = kvm_register_read(vcpu, VCPU_REGS_RAX);
ecx = kvm_register_read(vcpu, VCPU_REGS_RCX);
kvm_cpuid(vcpu, &eax, &ebx, &ecx, &edx);
kvm_register_write(vcpu, VCPU_REGS_RAX, eax);
kvm_register_write(vcpu, VCPU_REGS_RBX, ebx);
kvm_register_write(vcpu, VCPU_REGS_RCX, ecx);
kvm_register_write(vcpu, VCPU_REGS_RDX, edx);
kvm_x86_ops->skip_emulated_instruction(vcpu);
diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index 35058c2..a6fd40a 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -200,9 +200,20 @@ static inline int guest_cpuid_stepping(struct kvm_vcpu
*vcpu)
best = kvm_find_cpuid_entry(vcpu, 0x1, 0);
if (!best)
return -1;
return x86_stepping(best->eax);
}
+static inline bool supports_cpuid_fault(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.msr_platform_info & MSR_PLATFORM_INFO_CPUID_FAULT;
+}
+
+static inline bool cpuid_fault_enabled(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.msr_misc_features_enables &
+ MSR_MISC_FEATURES_ENABLES_CPUID_FAULT;
+}
+
#endif
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index a3ce9d2..7939bd0 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3779,16 +3779,23 @@ static int em_sti(struct x86_emulate_ctxt *ctxt)
ctxt->interruptibility = KVM_X86_SHADOW_INT_STI;
ctxt->eflags |= X86_EFLAGS_IF;
return X86EMUL_CONTINUE;
}
static int em_cpuid(struct x86_emulate_ctxt *ctxt)
{
u32 eax, ebx, ecx, edx;
+ u64 msr = 0;
+
+ ctxt->ops->get_msr(ctxt, MSR_MISC_FEATURES_ENABLES, &msr);
+ if (msr & MSR_MISC_FEATURES_ENABLES_CPUID_FAULT &&
+ ctxt->ops->cpl(ctxt)) {
+ return emulate_gp(ctxt, 0);
+ }
eax = reg_read(ctxt, VCPU_REGS_RAX);
ecx = reg_read(ctxt, VCPU_REGS_RCX);
ctxt->ops->get_cpuid(ctxt, &eax, &ebx, &ecx, &edx);
*reg_write(ctxt, VCPU_REGS_RAX) = eax;
*reg_write(ctxt, VCPU_REGS_RBX) = ebx;
*reg_write(ctxt, VCPU_REGS_RCX) = ecx;
*reg_write(ctxt, VCPU_REGS_RDX) = edx;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 04c5d96..da50a3f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -995,16 +995,18 @@ static u32 emulated_msrs[] = {
MSR_IA32_TSC_ADJUST,
MSR_IA32_TSCDEADLINE,
MSR_IA32_MISC_ENABLE,
MSR_IA32_MCG_STATUS,
MSR_IA32_MCG_CTL,
MSR_IA32_MCG_EXT_CTL,
MSR_IA32_SMBASE,
+ MSR_PLATFORM_INFO,
+ MSR_MISC_FEATURES_ENABLES,
};
static unsigned num_emulated_msrs;
bool kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
{
if (efer & efer_reserved_bits)
return false;
@@ -2283,16 +2285,31 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
return 1;
vcpu->arch.osvw.length = data;
break;
case MSR_AMD64_OSVW_STATUS:
if (!guest_cpuid_has_osvw(vcpu))
r
[PATCH v13 1/8] x86/arch_prctl/64: Use SYSCALL_DEFINE2 to define sys_arch_prctl
Use the SYSCALL_DEFINE2 macro instead of manually defining it.
Signed-off-by: Kyle Huey
---
arch/x86/kernel/process_64.c | 3 ++-
arch/x86/um/syscalls_64.c| 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index b3760b3..2718cf9 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -30,16 +30,17 @@
#include
#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include
#include
@@ -607,17 +608,17 @@ long do_arch_prctl(struct task_struct *task, int code,
unsigned long addr)
default:
ret = -EINVAL;
break;
}
return ret;
}
-long sys_arch_prctl(int code, unsigned long addr)
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, addr)
{
return do_arch_prctl(current, code, addr);
}
unsigned long KSTK_ESP(struct task_struct *task)
{
return task_pt_regs(task)->sp;
}
diff --git a/arch/x86/um/syscalls_64.c b/arch/x86/um/syscalls_64.c
index e655227..ab3f7f4 100644
--- a/arch/x86/um/syscalls_64.c
+++ b/arch/x86/um/syscalls_64.c
@@ -1,16 +1,17 @@
/*
* Copyright (C) 2003 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
* Copyright 2003 PathScale, Inc.
*
* Licensed under the GPL
*/
#include
+#include
#include
#include /* XXX This should get the constants from libc */
#include
long arch_prctl(struct task_struct *task, int code, unsigned long __user *addr)
{
unsigned long *ptr = addr, tmp;
long ret;
@@ -67,17 +68,17 @@ long arch_prctl(struct task_struct *task, int code,
unsigned long __user *addr)
case ARCH_GET_GS:
ret = put_user(tmp, addr);
break;
}
return ret;
}
-long sys_arch_prctl(int code, unsigned long addr)
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, addr)
{
return arch_prctl(current, code, (unsigned long __user *) addr);
}
void arch_switch_to(struct task_struct *to)
{
if ((to->thread.arch.fs == 0) || (to->mm == NULL))
return;
base-commit: e5517c2a5a49ed5e99047008629f1cd60246ea0e
--
2.10.2
[PATCH v13 6/8] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
When enabled, the processor will fault on attempts to execute the CPUID
instruction with CPL>0. Exposing this feature to userspace will allow a
ptracer to trap and emulate the CPUID instruction.
When supported, this feature is controlled by toggling bit 0 of
MSR_MISC_FEATURES_ENABLES. It is documented in detail in Section 2.3.2 of
https://bugzilla.kernel.org/attachment.cgi?id=243991
Implement a new pair of arch_prctls, available on both x86-32 and x86-64.
ARCH_GET_CPUID: Returns the current CPUID state, either 0 if CPUID faulting
is enabled (and thus the CPUID instruction is not available) or 1 if
CPUID faulting is not enabled.
ARCH_SET_CPUID: Set the CPUID state to the second argument. If
cpuid_enabled is 0 CPUID faulting will be activated, otherwise it will
be deactivated. Returns ENODEV if CPUID faulting is not supported on
this system.
The state of the CPUID faulting flag is propagated across forks, but reset
upon exec.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/msr-index.h | 3 ++
arch/x86/include/asm/processor.h | 2 +
arch/x86/include/asm/thread_info.h | 6 ++-
arch/x86/include/uapi/asm/prctl.h | 3 ++
arch/x86/kernel/cpu/intel.c| 7
arch/x86/kernel/process.c | 82 ++
fs/exec.c | 1 +
include/linux/thread_info.h| 4 ++
8 files changed, 107 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 3ac0acf..b138b8f 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -49,16 +49,19 @@
#define NHM_C1_AUTO_DEMOTE (1UL << 26)
#define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
#define SNB_C1_AUTO_UNDEMOTE (1UL << 27)
#define SNB_C3_AUTO_UNDEMOTE (1UL << 28)
#define MSR_MTRRcap0x00fe
#define MSR_IA32_BBL_CR_CTL0x0119
#define MSR_IA32_BBL_CR_CTL3 0x011e
+#define MSR_MISC_FEATURES_ENABLES 0x0140
+#define MSR_MISC_FEATURES_ENABLES_CPUID_FAULT_BIT 0
+#define MSR_MISC_FEATURES_ENABLES_CPUID_FAULT
BIT_ULL(MSR_MISC_FEATURES_ENABLES_CPUID_FAULT_BIT)
#define MSR_IA32_SYSENTER_CS 0x0174
#define MSR_IA32_SYSENTER_ESP 0x0175
#define MSR_IA32_SYSENTER_EIP 0x0176
#define MSR_IA32_MCG_CAP 0x0179
#define MSR_IA32_MCG_STATUS0x017a
#define MSR_IA32_MCG_CTL 0x017b
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 984a7bf..65b2494 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -803,16 +803,18 @@ extern void start_thread(struct pt_regs *regs, unsigned
long new_ip,
/* Get/set a process' ability to use the timestamp counter instruction */
#define GET_TSC_CTL(adr) get_tsc_mode((adr))
#define SET_TSC_CTL(val) set_tsc_mode((val))
extern int get_tsc_mode(unsigned long adr);
extern int set_tsc_mode(unsigned int val);
+DECLARE_PER_CPU(u64, msr_misc_features_shadow);
+
/* Register/unregister a process' MPX related resource */
#define MPX_ENABLE_MANAGEMENT()mpx_enable_management()
#define MPX_DISABLE_MANAGEMENT() mpx_disable_management()
#ifdef CONFIG_X86_INTEL_MPX
extern int mpx_enable_management(void);
extern int mpx_disable_management(void);
#else
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index ad6f5eb0..9fc44b9 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -82,16 +82,17 @@ struct thread_info {
#define TIF_SIGPENDING 2 /* signal pending */
#define TIF_NEED_RESCHED 3 /* rescheduling necessary */
#define TIF_SINGLESTEP 4 /* reenable singlestep on user return*/
#define TIF_SYSCALL_EMU6 /* syscall emulation active */
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP8 /* secure computing */
#define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */
#define TIF_UPROBE 12 /* breakpointed or singlestepping */
+#define TIF_NOCPUID15 /* CPUID is not accessible in userland
*/
#define TIF_NOTSC 16 /* TSC is not accessible in userland */
#define TIF_IA32 17 /* IA32 compatibility process */
#define TIF_NOHZ 19 /* in adaptive nohz mode */
#define TIF_MEMDIE 20 /* is terminating due to OOM killer */
#define TIF_POLLING_NRFLAG 21 /* idle is polling for TIF_NEED_RESCHED
*/
#define TIF_IO_BITMAP 22 /* uses I/O bitmap */
#define TIF_FORCED_TF 24 /* true if TF in eflags artificially */
#define TIF_BLOCKSTEP 25 /* set
[PATCH v13 0/8] x86/arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction
rr (http://rr-project.org/), a userspace record-and-replay reverse- execution debugger, would like to trap and emulate the CPUID instruction. This would allow us to a) mask away certain hardware features that rr does not support (e.g. RDRAND) and b) enable trace portability across machines by providing constant results. Newer Intel CPUs (Ivy Bridge and later) can fault when CPUID is executed at CPL > 0. Expose this capability to userspace as a new pair of arch_prctls, ARCH_GET_CPUID and ARCH_SET_CPUID. Since v12: Patch 4: x86/syscalls/32: Wire up arch_prctl on x86-32 - compat_sys_arch_prctl prototype has argument names. Patch 5: x86/cpufeature: Detect CPUID faulting support - s/init_intel_misc_features_enables/init_intel_misc_features/. - Added Reviewed-by Borislav. Patch 6: x86/arch_prctl: Add ARCH_[GET|SET]_CPUID - Selftest was split out into Patch 7. - s/msr_misc_features_enables_shadow/msr_misc_features_shadow/. - ARCH_GET_CPUID now returns its value directly, not in an outparam. - ARCH_SET_CPUID now takes a simple 0/1 value, ARCH_CPUID_ENABLE and ARCH_CPUID_SIGSEGV are gone. - ARCH_[GET|SET]_CPUID now operate on the enabledness of the CPUID instruction, not the CPUID faulting bit. Thus the default return value of ARCH_GET_CPUID is 1, and calling ARCH_SET_CPUID with 0 activates CPUID faulting (and thus disabling the CPUID instruction). Patch 7: x86/arch_prctl: Selftest for ARCH_[GET|SET]_CPUID - The self test was updated for the API changes.
Re: [PATCH] vfio/pci: Support error recovery
On Sun, Nov 27, 2016 at 07:34:17PM +0800, Cao jin wrote:
> It is user space driver's or device-specific driver's(in guest) responsbility
> to do a serious recovery when error happened. Link-reset is one part of
> recovery, when pci device is assigned to VM via vfio, link-reset will do
> twice in host & guest separately, which will cause many trouble for a
> successful recovery, so, disable the vfio-pci's link-reset in aer driver
> in host, this is a keypoint for guest to do error recovery successfully.
>
> CC: alex.william...@redhat.com
> CC: m...@redhat.com
> Signed-off-by: Cao jin
> ---
> This is actually a RFC version(has debug lines left), and has minor changes in
> aer driver, so I think maybe it is better not to CC pci guys in this round.
> Later will do.
>
> drivers/pci/pcie/aer/aerdrv_core.c | 12 ++-
> drivers/vfio/pci/vfio_pci.c | 63
> +++--
> drivers/vfio/pci/vfio_pci_private.h | 2 ++
> 3 files changed, 74 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
> b/drivers/pci/pcie/aer/aerdrv_core.c
> index 521e39c..289fb8e 100644
> --- a/drivers/pci/pcie/aer/aerdrv_core.c
> +++ b/drivers/pci/pcie/aer/aerdrv_core.c
> @@ -496,7 +496,17 @@ static void do_recovery(struct pci_dev *dev, int
> severity)
> "error_detected",
> report_error_detected);
>
> - if (severity == AER_FATAL) {
> + /* vfio-pci as a general meta driver, it actually couldn't do any real
> + * recovery for device. It is user space driver, or device-specific
> + * driver in guest who should take care of the serious error recovery,
> + * link reset actually is one part of whole recovery. Doing reset_link
> + * in aer driver of host kernel for vfio-pci devices will cause many
> + * trouble for user space driver or guest's device-specific driver,
> + * for example: the serious recovery often need to read register in
> + * config space, but if register reading happens during link-resetting,
> + * it is quite possible to return invalid value like all F's, which
> + * will result in unpredictable error. */
Fix multi-comment style please.
> + if (severity == AER_FATAL && strcmp(dev->driver->name, "vfio-pci")) {
You really want some flag in the device, or something similar.
Also, how do we know driver is not going away at this point?
> result = reset_link(dev);
> if (result != PCI_ERS_RESULT_RECOVERED)
> goto failed;
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 712a849..aefd751 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -535,6 +535,15 @@ static long vfio_pci_ioctl(void *device_data,
> struct vfio_pci_device *vdev = device_data;
> unsigned long minsz;
>
> + if (vdev->aer_recovering && (cmd == VFIO_DEVICE_SET_IRQS ||
> + cmd == VFIO_DEVICE_RESET || cmd == VFIO_DEVICE_PCI_HOT_RESET)) {
> + int ret;
> + ret = wait_for_completion_interruptible(
> + &vdev->aer_error_completion);
> + if (ret)
> + return ret;
> + }
> +
> if (cmd == VFIO_DEVICE_GET_INFO) {
> struct vfio_device_info info;
>
> @@ -1117,6 +1126,7 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
> vdev->irq_type = VFIO_PCI_NUM_IRQS;
> mutex_init(&vdev->igate);
> spin_lock_init(&vdev->irqlock);
> + init_completion(&vdev->aer_error_completion);
>
> ret = vfio_add_group_dev(&pdev->dev, &vfio_pci_ops, vdev);
> if (ret) {
> @@ -1176,6 +1186,9 @@ static pci_ers_result_t
> vfio_pci_aer_err_detected(struct pci_dev *pdev,
> {
> struct vfio_pci_device *vdev;
> struct vfio_device *device;
> + u32 uncor_status = 0;
> + unsigned int aer_cap_offset = 0;
> + int ret;
>
> device = vfio_device_get_from_dev(&pdev->dev);
> if (device == NULL)
> @@ -1187,10 +1200,30 @@ static pci_ers_result_t
> vfio_pci_aer_err_detected(struct pci_dev *pdev,
> return PCI_ERS_RESULT_DISCONNECT;
> }
>
> + /* get device's uncorrectable error status as soon as possible,
> + * and signal it to user space. The later we read it, the possibility
> + * the register value is mangled grows. */
> + aer_cap_offset = pci_find_ext_capability(vdev->pdev,
> PCI_EXT_CAP_ID_ERR);
> + ret = pci_read_config_dword(vdev->pdev, aer_cap_offset +
> +PCI_ERR_UNCOR_STATUS, &uncor_status);
> +if (ret)
> +return PCI_ERS_RESULT_DISCONNECT;
> +
> + pr_err("device %d got AER detect notification. uncorrectable error
> status = 0x%x\n", pdev->devfn, uncor_status);//to be removed
> mutex_lock(&vdev->igate);
> +
> + vdev->aer_recovering = true;
> + reinit_completion(&vdev->aer_error_co
