[PATCH 3.19.y-ckt 59/86] x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andy Lutomirski 

commit 83c133cf11fb0e68a51681447e372489f052d40e upstream.

The NMI entry code that switches to the normal kernel stack needs to
be very careful not to clobber any extra stack slots on the NMI
stack.  The code is fine under the assumption that SWAPGS is just a
normal instruction, but that assumption isn't really true.  Use
SWAPGS_UNSAFE_STACK instead.

This is part of a fix for some random crashes that Sasha saw.

Fixes: 9b6e6a8334d5 ("x86/nmi/64: Switch stacks on userspace NMI entry")
Reported-and-tested-by: Sasha Levin 
Signed-off-by: Andy Lutomirski 
Link: 
http://lkml.kernel.org/r/974bc40edffdb5c2950a5c4977f821a446b76178.1442791737.git.l...@kernel.org
Signed-off-by: Thomas Gleixner 
[ luis: backported to 3.16:
  - file rename: arch/x86/entry/entry_64.S -> arch/x86/kernel/entry_64.S
  - adjusted context ]
Signed-off-by: Luis Henriques 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/kernel/entry_64.S | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index f8f94d4..9072010 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1504,9 +1504,12 @@ ENTRY(nmi)
 * we don't want to enable interrupts, because then we'll end
 * up in an awkward situation in which IRQs are on but NMIs
 * are off.
+*
+* We also must not push anything to the stack before switching
+* stacks lest we corrupt the "NMI executing" variable.
 */
 
-   SWAPGS
+   SWAPGS_UNSAFE_STACK
cld
movq%rsp, %rdx
movqPER_CPU_VAR(kernel_stack), %rsp
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 58/86] x86/paravirt: Replace the paravirt nop with a bona fide empty function

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andy Lutomirski 

commit fc57a7c68020dcf954428869eafd934c0ab1536f upstream.

PARAVIRT_ADJUST_EXCEPTION_FRAME generates this code (using nmi as an
example, trimmed for readability):

ff 15 00 00 00 00   callq  *0x0(%rip)# 2796 
  2792: R_X86_64_PC32 pv_irq_ops+0x2c

That's a call through a function pointer to regular C function that
does nothing on native boots, but that function isn't protected
against kprobes, isn't marked notrace, and is certainly not
guaranteed to preserve any registers if the compiler is feeling
perverse.  This is bad news for a CLBR_NONE operation.

Of course, if everything works correctly, once paravirt ops are
patched, it gets nopped out, but what if we hit this code before
paravirt ops are patched in?  This can potentially cause breakage
that is very difficult to debug.

A more subtle failure is possible here, too: if _paravirt_nop uses
the stack at all (even just to push RBP), it will overwrite the "NMI
executing" variable if it's called in the NMI prologue.

The Xen case, perhaps surprisingly, is fine, because it's already
written in asm.

Fix all of the cases that default to paravirt_nop (including
adjust_exception_frame) with a big hammer: replace paravirt_nop with
an asm function that is just a ret instruction.

The Xen case may have other problems, so document them.

This is part of a fix for some random crashes that Sasha saw.

Reported-and-tested-by: Sasha Levin 
Signed-off-by: Andy Lutomirski 
Link: 
http://lkml.kernel.org/r/8f5d2ba295f9d73751c33d97fda03e0495d9ade0.1442791737.git.l...@kernel.org
Signed-off-by: Thomas Gleixner 
[ luis: backported to 3.16:
  - file rename: arch/x86/entry/entry_64.S -> arch/x86/kernel/entry_64.S
  - adjusted context ]
Signed-off-by: Luis Henriques 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/kernel/entry_64.S | 11 +++
 arch/x86/kernel/paravirt.c | 16 
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 138e7af..f8f94d4 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1441,7 +1441,18 @@ END(error_exit)
 /* Runs on exception stack */
 ENTRY(nmi)
INTR_FRAME
+   /*
+* Fix up the exception frame if we're on Xen.
+* PARAVIRT_ADJUST_EXCEPTION_FRAME is guaranteed to push at most
+* one value to the stack on native, so it may clobber the rdx
+* scratch slot, but it won't clobber any of the important
+* slots past it.
+*
+* Xen is a different story, because the Xen frame itself overlaps
+* the "NMI executing" variable.
+*/
PARAVIRT_ADJUST_EXCEPTION_FRAME
+
/*
 * We allow breakpoints in NMIs. If a breakpoint occurs, then
 * the iretq it performs will take us out of NMI context.
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 548d25f..8d12f05 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -41,10 +41,18 @@
 #include 
 #include 
 
-/* nop stub */
-void _paravirt_nop(void)
-{
-}
+/*
+ * nop stub, which must not clobber anything *including the stack* to
+ * avoid confusing the entry prologues.
+ */
+extern void _paravirt_nop(void);
+asm (".pushsection .entry.text, \"ax\"\n"
+ ".global _paravirt_nop\n"
+ "_paravirt_nop:\n\t"
+ "ret\n\t"
+ ".size _paravirt_nop, . - _paravirt_nop\n\t"
+ ".type _paravirt_nop, @function\n\t"
+ ".popsection");
 
 /* identity function, which can be inlined */
 u32 _paravirt_ident_32(u32 x)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 50/86] usb: xhci: exit early in xhci_setup_device() if we're halted or dying

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Roger Quadros 

commit 448116bfa856d3c076fa7178ed96661a008a5d45 upstream.

During quick plug/removal of OTG adapter during dual-role testing
it can happen that xhci_alloc_device() is called for the newly
detected device after the DRD library has called xhci_stop to
remove the HCD.

If that is the case, just fail early to prevent the following warning.

[  154.732649] hub 4-0:1.0: USB hub found
[  154.742204] hub 4-0:1.0: 1 port detected
[  154.824458] hub 3-0:1.0: state 7 ports 1 chg 0002 evt 
[  154.854609] hub 4-0:1.0: state 7 ports 1 chg  evt 
[  154.944430] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[  154.951009] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
[  155.038191] xhci-hcd xhci-hcd.0.auto: remove, state 4
[  155.043315] usb usb4: USB disconnect, device number 1
[  155.055270] xhci-hcd xhci-hcd.0.auto: xhci_stop
[  155.060094] xhci-hcd xhci-hcd.0.auto: USB bus 4 deregistered
[  155.066576] xhci-hcd xhci-hcd.0.auto: remove, state 1
[  155.071710] usb usb3: USB disconnect, device number 1
[  155.077124] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
[  155.082389] [ cut here ]
[  155.087690] WARNING: CPU: 0 PID: 72 at drivers/usb/host/xhci.c:3800 
xhci_setup_device+0x410/0x484 [xhci_hcd]()
[  155.097861] Modules linked in: sd_mod usb_storage scsi_mod usb_f_ss_lb 
g_zero libcomposite ipv6 xhci_plat_hcd xhci_hcd usbcore dwc3 udc_core evdev 
ti_am335x_adc joydev kfifo_buf industrialio snd_soc_simple_cc
[  155.146734] CPU: 0 PID: 72 Comm: kworker/0:3 Tainted: GW   
4.1.4-00834-gcd9380b-dirty #50
[  155.156073] Hardware name: Generic AM43 (Flattened Device Tree)
[  155.162117] Workqueue: usb_hub_wq hub_event [usbcore]
[  155.167249] Backtrace:
[  155.169751] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)
[  155.177390]  r6:c089d4a4 r5: r4: r3:ee46c000
[  155.183137] [] (show_stack) from [] 
(dump_stack+0x84/0xd0)
[  155.190446] [] (dump_stack) from [] 
(warn_slowpath_common+0x80/0xbc)
[  155.198605]  r7:0009 r6:0ed8 r5:bf27eb70 r4:
[  155.204348] [] (warn_slowpath_common) from [] 
(warn_slowpath_null+0x24/0x2c)
[  155.213202]  r8:ee49f000 r7:ee7c0004 r6: r5:ee7c0158 r4:ee7c
[  155.220051] [] (warn_slowpath_null) from [] 
(xhci_setup_device+0x410/0x484 [xhci_hcd])
[  155.229816] [] (xhci_setup_device [xhci_hcd]) from [] 
(xhci_address_device+0x14/0x18 [xhci_hcd])
[  155.240415]  r10:ee598200 r9:0001 r8:0002 r7:0001 r6:0003 
r5:0002
[  155.248363]  r4:ee49f000
[  155.250978] [] (xhci_address_device [xhci_hcd]) from [] 
(hub_port_init+0x1b8/0xa9c [usbcore])
[  155.261403] [] (hub_port_init [usbcore]) from [] 
(hub_event+0x738/0x1020 [usbcore])
[  155.270874]  r10:ee598200 r9:ee7c r8:ee7c0038 r7:ee518800 r6:ee49f000 
r5:0001
[  155.278822]  r4:
[  155.281426] [] (hub_event [usbcore]) from [] 
(process_one_work+0x128/0x340)
[  155.290196]  r10: r9:0003 r8: r7:fedfa000 r6:eeec5400 
r5:ee598314
[  155.298151]  r4:ee434380
[  155.300718] [] (process_one_work) from [] 
(worker_thread+0x158/0x49c)
[  155.308963]  r10:ee434380 r9:0003 r8:eeec5400 r7:0008 r6:ee434398 
r5:eeec5400
[  155.316913]  r4:eeec5414
[  155.319482] [] (worker_thread) from [] 
(kthread+0xdc/0xf8)
[  155.326765]  r10: r9: r8: r7:c00577a0 r6:ee434380 
r5:ee4441c0
[  155.334713]  r4: r3:
[  155.338341] [] (kthread) from [] 
(ret_from_fork+0x14/0x2c)
[  155.345626]  r7: r6: r5:c005cb64 r4:ee4441c0
[  155.356108] ---[ end trace a58d34c223b190e6 ]---
[  155.360783] xhci-hcd xhci-hcd.0.auto: Virt dev invalid for slot_id 0x1!
[  155.574404] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
[  155.579667] [ cut here ]

Signed-off-by: Roger Quadros 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/xhci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 0dfda9e..0612a5b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3799,6 +3799,9 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct 
usb_device *udev,
 
mutex_lock(&xhci->mutex);
 
+   if (xhci->xhc_state)/* dying or halted */
+   goto out;
+
if (!udev->slot_id) {
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
"Bad Slot ID %d", udev->slot_id);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 49/86] usb: xhci: Clear XHCI_STATE_DYING on start

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Roger Quadros 

commit e5bfeab0ad515b4f6df39fe716603e9dc6d3dfd0 upstream.

For whatever reason if XHCI died in the previous instant
then it will never recover on the next xhci_start unless we
clear the DYING flag.

Signed-off-by: Roger Quadros 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/xhci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 0c4ea93..0dfda9e 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -147,7 +147,8 @@ static int xhci_start(struct xhci_hcd *xhci)
"waited %u microseconds.\n",
XHCI_MAX_HALT_USEC);
if (!ret)
-   xhci->xhc_state &= ~XHCI_STATE_HALTED;
+   xhci->xhc_state &= ~(XHCI_STATE_HALTED | XHCI_STATE_DYING);
+
return ret;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 51/86] xhci: change xhci 1.0 only restrictions to support xhci 1.1

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Mathias Nyman 

commit dca7794539eff04b786fb6907186989e5eaaa9c2 upstream.

Some changes between xhci 0.96 and xhci 1.0 specifications forced us to
check the hci version in code, some of these checks were implemented as
hci_version == 1.0, which will not work with new xhci 1.1 controllers.

xhci 1.1 behaves similar to xhci 1.0 in these cases, so change these
checks to hci_version >= 1.0

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/xhci-mem.c  | 6 +++---
 drivers/usb/host/xhci-ring.c | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index d44c904..79a3c5f 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1502,10 +1502,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
 * use Event Data TRBs, and we don't chain in a link TRB on short
 * transfers, we're basically dividing by 1.
 *
-* xHCI 1.0 specification indicates that the Average TRB Length should
-* be set to 8 for control endpoints.
+* xHCI 1.0 and 1.1 specification indicates that the Average TRB Length
+* should be set to 8 for control endpoints.
 */
-   if (usb_endpoint_xfer_control(&ep->desc) && xhci->hci_version == 0x100)
+   if (usb_endpoint_xfer_control(&ep->desc) && xhci->hci_version >= 0x100)
ep_ctx->tx_info |= cpu_to_le32(AVG_TRB_LENGTH_FOR_EP(8));
else
ep_ctx->tx_info |=
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 47364dd..06c247e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3394,8 +3394,8 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t 
mem_flags,
if (start_cycle == 0)
field |= 0x1;
 
-   /* xHCI 1.0 6.4.1.2.1: Transfer Type field */
-   if (xhci->hci_version == 0x100) {
+   /* xHCI 1.0/1.1 6.4.1.2.1: Transfer Type field */
+   if (xhci->hci_version >= 0x100) {
if (urb->transfer_buffer_length > 0) {
if (setup->bRequestType & USB_DIR_IN)
field |= TRB_TX_TYPE(TRB_DATA_IN);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 22/86] kvm: don't try to register to KVM_FAST_MMIO_BUS for non mmio eventfd

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jason Wang 

commit 8453fecbecae26edb3f278627376caab05d9a88d upstream.

We only want zero length mmio eventfd to be registered on
KVM_FAST_MMIO_BUS. So check this explicitly when arg->len is zero to
make sure this.

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Jason Wang 
Reviewed-by: Cornelia Huck 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Kamal Mostafa 
---
 virt/kvm/eventfd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 148b239..fd477e1 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -843,7 +843,7 @@ kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd 
*args)
/* When length is ignored, MMIO is also put on a separate bus, for
 * faster lookups.
 */
-   if (!args->len && !(args->flags & KVM_IOEVENTFD_FLAG_PIO)) {
+   if (!args->len && bus_idx == KVM_MMIO_BUS) {
ret = kvm_io_bus_register_dev(kvm, KVM_FAST_MMIO_BUS,
  p->addr, 0, &p->dev);
if (ret < 0)
@@ -898,7 +898,7 @@ kvm_deassign_ioeventfd(struct kvm *kvm, struct 
kvm_ioeventfd *args)
continue;
 
kvm_io_bus_unregister_dev(kvm, bus_idx, &p->dev);
-   if (!p->length) {
+   if (!p->length && p->bus_idx == KVM_MMIO_BUS) {
kvm_io_bus_unregister_dev(kvm, KVM_FAST_MMIO_BUS,
  &p->dev);
}
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 52/86] xhci-mem: Use setup_timer

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Julia Lawall 

commit 9e08a03dc12a41ce695559f8c6d999aaf245b8be upstream.

Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.

A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression t,f,d;
@@

-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// 

Signed-off-by: Julia Lawall 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
[ kamal: 3.19-stable prereq for "cc8e4fc xhci: init command timeout timer
  earlier to avoid deleting it uninitialized" ]
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/xhci-mem.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 79a3c5f..1291417e3 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -833,9 +833,8 @@ void xhci_free_stream_info(struct xhci_hcd *xhci,
 static void xhci_init_endpoint_timer(struct xhci_hcd *xhci,
struct xhci_virt_ep *ep)
 {
-   init_timer(&ep->stop_cmd_timer);
-   ep->stop_cmd_timer.data = (unsigned long) ep;
-   ep->stop_cmd_timer.function = xhci_stop_endpoint_command_watchdog;
+   setup_timer(&ep->stop_cmd_timer, xhci_stop_endpoint_command_watchdog,
+   (unsigned long)ep);
ep->xhci = xhci;
 }
 
@@ -2510,9 +2509,8 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
xhci_print_ir_set(xhci, 0);
 
/* init command timeout timer */
-   init_timer(&xhci->cmd_timer);
-   xhci->cmd_timer.data = (unsigned long) xhci;
-   xhci->cmd_timer.function = xhci_handle_command_timeout;
+   setup_timer(&xhci->cmd_timer, xhci_handle_command_timeout,
+   (unsigned long)xhci);
 
/*
 * XXX: Might need to set the Interrupter Moderation Register to
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 53/86] xhci: init command timeout timer earlier to avoid deleting it uninitialized

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Mathias Nyman 

commit cc8e4fc0c3b5e8340bc8358990515d116a3c274c upstream.

Don't check if timer is running with a timer_pending() before
deleting it with del_timer_sync(), this defies the whole point of
the sync part and can cause a possible race.

Instead we just want to make sure the timer is initialized early enough
before we have a chance to delete it.

Reported-by: Oliver Neukum 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/xhci-mem.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 1291417e3..4d45551 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1795,8 +1795,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
int size;
int i, j, num_ports;
 
-   if (timer_pending(&xhci->cmd_timer))
-   del_timer_sync(&xhci->cmd_timer);
+   del_timer_sync(&xhci->cmd_timer);
 
/* Free the Event Ring Segment Table and the actual Event Ring */
size = sizeof(struct xhci_erst_entry)*(xhci->erst.num_entries);
@@ -2324,6 +2323,10 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
 
INIT_LIST_HEAD(&xhci->cmd_list);
 
+   /* init command timeout timer */
+   setup_timer(&xhci->cmd_timer, xhci_handle_command_timeout,
+   (unsigned long)xhci);
+
page_size = readl(&xhci->op_regs->page_size);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Supported page size register = 0x%x", page_size);
@@ -2508,10 +2511,6 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
"Wrote ERST address to ir_set 0.");
xhci_print_ir_set(xhci, 0);
 
-   /* init command timeout timer */
-   setup_timer(&xhci->cmd_timer, xhci_handle_command_timeout,
-   (unsigned long)xhci);
-
/*
 * XXX: Might need to set the Interrupter Moderation Register to
 * something other than the default (~1ms minimum between interrupts).
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 48/86] usb: xhci: lock mutex on xhci_stop

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Roger Quadros 

commit 85ac90f8953a58f6a057b727bc9db97721e3fb8e upstream.

Else it races with xhci_setup_device

Signed-off-by: Roger Quadros 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/xhci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index f2194a0..0c4ea93 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -686,8 +686,11 @@ void xhci_stop(struct usb_hcd *hcd)
u32 temp;
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
 
+   mutex_lock(&xhci->mutex);
+
if (!usb_hcd_is_primary_hcd(hcd)) {
xhci_only_stop_hcd(xhci->shared_hcd);
+   mutex_unlock(&xhci->mutex);
return;
}
 
@@ -726,6 +729,7 @@ void xhci_stop(struct usb_hcd *hcd)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"xhci_stop completed - status = %x",
readl(&xhci->op_regs->status));
+   mutex_unlock(&xhci->mutex);
 }
 
 /*
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/4] x86,asm: Re-work smp_store_mb()

2015-10-27 Thread Davidlohr Bueso

On Wed, 28 Oct 2015, Linus Torvalds wrote:


On Wed, Oct 28, 2015 at 4:53 AM, Davidlohr Bueso  wrote:


Note that this might affect callers that could/would rely on the
atomicity semantics, but there are no guarantees of that for
smp_store_mb() mentioned anywhere, plus most archs use this anyway.
Thus we continue to be consistent with the memory-barriers.txt file,
and more importantly, maintain the semantics of the smp_ nature.


So I dislike this patch, mostly because it now makes it obvious that
smp_store_mb() seems to be totally pointless. Every single
implementation is now apparently WRITE_ONCE+smp_mb(), and there are
what, five users of it, so why not then open-code it?


So after having gone through pretty much all of smp_store_mb code, this
is a feeling I also share. However I justified its existence (as opposed
to dropping the call, updating all the callers/documenting the barriers
etc.) to at least encapsulate the store+mb logic, which apparently is a
pattern somewhat needed(?). Also, the name is obviously exactly what its
name implies.

But I have no strong preference either way. Now, if we should keep
smp_store_mb(), it should probably be made generic, instead of having
each arch define it.



But more importantly, is the "WRITE_ONCE()" even necessary? If there
are no atomicity guarantees, then why bother with WRTE_ONCE() either?


Agreed. Hmm, this was introduced by ab3f02fc237 (locking/arch: Add WRITE_ONCE()
to set_mb()), back when atomicity aspects were not clear yet.


So with this patch, the whole thing becomes pointless, I feel. (Ok, so
it may have been pointless before too, but at least before this patch
it generated special code, now it doesn't). So why carry it along at
all?


Ok, unless others are strongly against it, I'll send a series to drop the
call altogether.

Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 46/86] usb: Use the USB_SS_MULT() macro to get the burst multiplier.

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Mathias Nyman 

commit ff30cbc8da425754e8ab96904db1d295bd034f27 upstream.

Bits 1:0 of the bmAttributes are used for the burst multiplier.
The rest of the bits used to be reserved (zero), but USB3.1 takes bit 7
into use.

Use the existing USB_SS_MULT() macro instead to make sure the mult value
and hence max packet calculations are correct for USB3.1 devices.

Note that burst multiplier in bmAttributes is zero based and that
the USB_SS_MULT() macro adds one.

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/core/config.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index b2a540b..b9ddf0c 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -112,7 +112,7 @@ static void usb_parse_ss_endpoint_companion(struct device 
*ddev, int cfgno,
cfgno, inum, asnum, ep->desc.bEndpointAddress);
ep->ss_ep_comp.bmAttributes = 16;
} else if (usb_endpoint_xfer_isoc(&ep->desc) &&
-   desc->bmAttributes > 2) {
+  USB_SS_MULT(desc->bmAttributes) > 3) {
dev_warn(ddev, "Isoc endpoint has Mult of %d in "
"config %d interface %d altsetting %d ep %d: "
"setting to 3\n", desc->bmAttributes + 1,
@@ -121,7 +121,8 @@ static void usb_parse_ss_endpoint_companion(struct device 
*ddev, int cfgno,
}
 
if (usb_endpoint_xfer_isoc(&ep->desc))
-   max_tx = (desc->bMaxBurst + 1) * (desc->bmAttributes + 1) *
+   max_tx = (desc->bMaxBurst + 1) *
+   (USB_SS_MULT(desc->bmAttributes)) *
usb_endpoint_maxp(&ep->desc);
else if (usb_endpoint_xfer_int(&ep->desc))
max_tx = usb_endpoint_maxp(&ep->desc) *
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 44/86] sched: access local runqueue directly in single_task_running

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Dominik Dingel 

commit 00cc1633816de8c95f337608a1ea64e228faf771 upstream.

Commit 2ee507c47293 ("sched: Add function single_task_running to let a task
check if it is the only task running on a cpu") referenced the current
runqueue with the smp_processor_id.  When CONFIG_DEBUG_PREEMPT is enabled,
that is only allowed if preemption is disabled or the currrent task is
bound to the local cpu (e.g. kernel worker).

With commit f78195129963 ("kvm: add halt_poll_ns module parameter") KVM
calls single_task_running. If CONFIG_DEBUG_PREEMPT is enabled that
generates a lot of kernel messages.

To avoid adding preemption in that cases, as it would limit the usefulness,
we change single_task_running to access directly the cpu local runqueue.

Cc: Tim Chen 
Suggested-by: Peter Zijlstra 
Acked-by: Peter Zijlstra (Intel) 
Fixes: 2ee507c472939db4b146d545352b8a7c79ef47f8
Signed-off-by: Dominik Dingel 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Kamal Mostafa 
---
 kernel/sched/core.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 48b14d6..2ef0f5e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2408,13 +2408,20 @@ unsigned long nr_running(void)
 
 /*
  * Check if only the current task is running on the cpu.
+ *
+ * Caution: this function does not check that the caller has disabled
+ * preemption, thus the result might have a time-of-check-to-time-of-use
+ * race.  The caller is responsible to use it correctly, for example:
+ *
+ * - from a non-preemptable section (of course)
+ *
+ * - from a thread that is bound to a single CPU
+ *
+ * - in a loop with very short iterations (e.g. a polling loop)
  */
 bool single_task_running(void)
 {
-   if (cpu_rq(smp_processor_id())->nr_running == 1)
-   return true;
-   else
-   return false;
+   return raw_rq()->nr_running == 1;
 }
 EXPORT_SYMBOL(single_task_running);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 11/86] time: Fix timekeeping_freqadjust()'s incorrect use of abs() instead of abs64()

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: John Stultz 

commit 2619d7e9c92d524cb155ec89fd72875321512e5b upstream.

The internal clocksteering done for fine-grained error
correction uses a logarithmic approximation, so any time
adjtimex() adjusts the clock steering, timekeeping_freqadjust()
quickly approximates the correct clock frequency over a series
of ticks.

Unfortunately, the logic in timekeeping_freqadjust(), introduced
in commit:

  dc491596f639 ("timekeeping: Rework frequency adjustments to work better w/ 
nohz")

used the abs() function with a s64 error value to calculate the
size of the approximated adjustment to be made.

Per include/linux/kernel.h:

  "abs() should not be used for 64-bit types (s64, u64, long long) - use 
abs64()".

Thus on 32-bit platforms, this resulted in the clocksteering to
take a quite dampended random walk trying to converge on the
proper frequency, which caused the adjustments to be made much
slower then intended (most easily observed when large
adjustments are made).

This patch fixes the issue by using abs64() instead.

Reported-by: Nuno Gonçalves 
Tested-by: Nuno Goncalves 
Signed-off-by: John Stultz 
Cc: Linus Torvalds 
Cc: Miroslav Lichvar 
Cc: Peter Zijlstra 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1441840051-20244-1-git-send-email-john.stu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Kamal Mostafa 
---
 kernel/time/timekeeping.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 6a93185..6e80711 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1431,7 +1431,7 @@ static __always_inline void timekeeping_freqadjust(struct 
timekeeper *tk,
negative = (tick_error < 0);
 
/* Sort out the magnitude of the correction */
-   tick_error = abs(tick_error);
+   tick_error = abs64(tick_error);
for (adj = 0; tick_error > interval; adj++)
tick_error >>= 1;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 62/86] drm/i915/bios: handle MIPI Sequence Block v3+ gracefully

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jani Nikula 

commit cd67d226ebd909d239d2c6e5a6abd6e2a338d1cd upstream.

The VBT MIPI Sequence Block version 3 has forward incompatible changes:

First, the block size in the header has been specified reserved, and the
actual size is a separate 32-bit value within the block. The current
find_section() function to will only look at the size in the block
header, and, depending on what's in that now reserved size field,
continue looking for other sections in the wrong place.

Fix this by taking the new block size field into account. This will
ensure that the lookups for other sections will work properly, as long
as the new 32-bit size does not go beyond the opregion VBT mailbox size.

Second, the contents of the block have been completely
changed. Gracefully refuse parsing the yet unknown data version.

Cc: Deepak M 
Reviewed-by: Deepak M 
Signed-off-by: Jani Nikula 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/i915/intel_bios.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index a4bd90f..d96b152 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -41,7 +41,7 @@ find_section(struct bdb_header *bdb, int section_id)
 {
u8 *base = (u8 *)bdb;
int index = 0;
-   u16 total, current_size;
+   u32 total, current_size;
u8 current_id;
 
/* skip to first section */
@@ -56,6 +56,10 @@ find_section(struct bdb_header *bdb, int section_id)
current_size = *((u16 *)(base + index));
index += 2;
 
+   /* The MIPI Sequence Block v3+ has a separate size field. */
+   if (current_id == BDB_MIPI_SEQUENCE && *(base + index) >= 3)
+   current_size = *((const u32 *)(base + index + 1));
+
if (index + current_size > total)
return NULL;
 
@@ -794,6 +798,12 @@ parse_mipi(struct drm_i915_private *dev_priv, struct 
bdb_header *bdb)
return;
}
 
+   /* Fail gracefully for forward incompatible sequence block. */
+   if (sequence->version >= 3) {
+   DRM_ERROR("Unable to parse MIPI Sequence Block v3+\n");
+   return;
+   }
+
DRM_DEBUG_DRIVER("Found MIPI sequence block\n");
 
block_size = get_blocksize(sequence);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v8 50/61] PCI: Unify calculate_size() for io port and MMIO

2015-10-27 Thread Yinghai Lu
Now calculate_memsize() and calculate_iosize() is the same.

Change them to calculate_size().

Signed-off-by: Yinghai Lu 
---
 drivers/pci/setup-bus.c | 25 +
 1 file changed, 5 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index d4e8da1..a6eea60 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1104,22 +1104,7 @@ static struct resource *find_free_bus_resource(struct 
pci_bus *bus,
return NULL;
 }
 
-static resource_size_t calculate_iosize(resource_size_t size,
-   resource_size_t min_size,
-   resource_size_t old_size,
-   resource_size_t align)
-{
-   if (size < min_size)
-   size = min_size;
-   if (old_size == 1)
-   old_size = 0;
-   size = ALIGN(size, align);
-   if (size < old_size)
-   size = old_size;
-   return size;
-}
-
-static resource_size_t calculate_memsize(resource_size_t size,
+static resource_size_t calculate_size(resource_size_t size,
resource_size_t min_size,
resource_size_t old_size,
resource_size_t align)
@@ -1245,14 +1230,14 @@ static void pbus_size_io(struct pci_bus *bus, 
resource_size_t min_size,
 
size = size_aligned_for_isa(size);
size += size1;
-   size0 = calculate_iosize(size, min_size,
+   size0 = calculate_size(size, min_size,
resource_size(b_res), min_align);
sum_add_size = size_aligned_for_isa(sum_add_size);
sum_add_size += sum_add_size1;
if (sum_add_size < min_sum_size)
sum_add_size = min_sum_size;
size1 = !realloc_head ? size0 :
-   calculate_iosize(sum_add_size, min_size,
+   calculate_size(sum_add_size, min_size,
resource_size(b_res), min_align);
if (!size0 && !size1) {
if (b_res->start || b_res->end)
@@ -1580,7 +1565,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned 
long mask,
if (size || min_size) {
min_align = calculate_mem_align(&align_test_list, max_align,
size, window_align);
-   size0 = calculate_memsize(size, min_size,
+   size0 = calculate_size(size, min_size,
  resource_size(b_res), min_align);
}
free_align_test_list(&align_test_list);
@@ -1605,7 +1590,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned 
long mask,
min_add_align = calculate_mem_align(&align_test_add_list,
max_add_align, sum_add_size,
window_align);
-   size1 = calculate_memsize(sum_add_size, min_size,
+   size1 = calculate_size(sum_add_size, min_size,
 resource_size(b_res), min_add_align);
}
free_align_test_list(&align_test_add_list);
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v8 53/61] PCI: Kill macro checking for bus io port sizing

2015-10-27 Thread Yinghai Lu
We can use new generic version skip_isa_ioresource_align() instead
of macro, and then kill the marco.

Signed-off-by: Yinghai Lu 
---
 drivers/pci/setup-bus.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index f1c7b46..419eaaf 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1160,15 +1160,12 @@ int skip_isa_ioresource_align(struct pci_bus *bus)
return 0;
 }
 
-static resource_size_t size_aligned_for_isa(resource_size_t size)
+static resource_size_t size_aligned_for_isa(resource_size_t size,
+   struct pci_bus *bus)
 {
-   /*
-* To be fixed in 2.5: we should have sort of HAVE_ISA
-*  flag in the struct pci_bus.
-*/
-#if defined(CONFIG_ISA) || defined(CONFIG_EISA)
-   size = (size & 0xff) + ((size & ~0xffUL) << 2);
-#endif
+   if (!skip_isa_ioresource_align(bus))
+   size = (size & 0xff) + ((size & ~0xffUL) << 2);
+
return size;
 }
 
@@ -1237,12 +1234,12 @@ static void pbus_size_io(struct pci_bus *bus, 
resource_size_t min_size,
}
}
 
-   size = size_aligned_for_isa(size);
+   size = size_aligned_for_isa(size, bus);
size += size1;
if (size || min_size)
size0 = calculate_size(size, min_size,
resource_size(b_res), min_align);
-   sum_add_size = size_aligned_for_isa(sum_add_size);
+   sum_add_size = size_aligned_for_isa(sum_add_size, bus);
sum_add_size += sum_add_size1;
if (sum_add_size < min_sum_size)
sum_add_size = min_sum_size;
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 35/86] arm/arm64: KVM: vgic: Check for !irqchip_in_kernel() when mapping resources

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Pavel Fedin 

commit c2f58514cfb374d5368c9da945f1765cd48eb0da upstream.

Until b26e5fdac43c ("arm/arm64: KVM: introduce per-VM ops"),
kvm_vgic_map_resources() used to include a check on irqchip_in_kernel(),
and vgic_v2_map_resources() still has it.

But now vm_ops are not initialized until we call kvm_vgic_create().
Therefore kvm_vgic_map_resources() can being called without a VGIC,
and we die because vm_ops.map_resources is NULL.

Fixing this restores QEMU's kernel-irqchip=off option to a working state,
allowing to use GIC emulation in userspace.

Fixes: b26e5fdac43c ("arm/arm64: KVM: introduce per-VM ops")
Signed-off-by: Pavel Fedin 
[maz: reworked commit message]
Signed-off-by: Marc Zyngier 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/kvm/arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 3ec9687..6391fa6 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -428,7 +428,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
 * Map the VGIC hardware resources before running a vcpu the first
 * time on this VM.
 */
-   if (unlikely(!vgic_ready(kvm))) {
+   if (unlikely(irqchip_in_kernel(kvm) && !vgic_ready(kvm))) {
ret = kvm_vgic_map_resources(kvm);
if (ret)
return ret;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 40/86] arm: KVM: Disable virtual timer even if the guest is not using it

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Marc Zyngier 

commit 688bc577ac42ae3d07c889a1f0a72f0b23763d58 upstream.

When running a guest with the architected timer disabled (with QEMU and
the kernel_irqchip=off option, for example), it is important to make
sure the timer gets turned off. Otherwise, the guest may try to
enable it anyway, leading to a screaming HW interrupt.

The fix is to unconditionally turn off the virtual timer on guest
exit.

Signed-off-by: Marc Zyngier 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/kvm/interrupts_head.S | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
index f6f1481..1fb756e 100644
--- a/arch/arm/kvm/interrupts_head.S
+++ b/arch/arm/kvm/interrupts_head.S
@@ -523,8 +523,7 @@ ARM_BE8(rev r6, r6  )
 
mrc p15, 0, r2, c14, c3, 1  @ CNTV_CTL
str r2, [vcpu, #VCPU_TIMER_CNTV_CTL]
-   bic r2, #1  @ Clear ENABLE
-   mcr p15, 0, r2, c14, c3, 1  @ CNTV_CTL
+
isb
 
mrrcp15, 3, rr_lo_hi(r2, r3), c14   @ CNTV_CVAL
@@ -537,6 +536,9 @@ ARM_BE8(rev r6, r6  )
mcrrp15, 4, r2, r2, c14 @ CNTVOFF
 
 1:
+   mov r2, #0  @ Clear ENABLE
+   mcr p15, 0, r2, c14, c3, 1  @ CNTV_CTL
+
 #endif
@ Allow physical timer/counter access for the host
mrc p15, 4, r2, c14, c1, 0  @ CNTHCTL
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 34/86] x86/platform: Fix Geode LX timekeeping in the generic x86 build

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: David Woodhouse 

commit 03da3ff1cfcd7774c8780d2547ba0d995f7dc03d upstream.

In 2007, commit 07190a08eef36 ("Mark TSC on GeodeLX reliable")
bypassed verification of the TSC on Geode LX. However, this code
(now in the check_system_tsc_reliable() function in
arch/x86/kernel/tsc.c) was only present if CONFIG_MGEODE_LX was
set.

OpenWRT has recently started building its generic Geode target
for Geode GX, not LX, to include support for additional
platforms. This broke the timekeeping on LX-based devices,
because the TSC wasn't marked as reliable:
https://dev.openwrt.org/ticket/20531

By adding a runtime check on is_geode_lx(), we can also include
the fix if CONFIG_MGEODEGX1 or CONFIG_X86_GENERIC are set, thus
fixing the problem.

Signed-off-by: David Woodhouse 
Cc: Andres Salomon 
Cc: Linus Torvalds 
Cc: Marcelo Tosatti 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1442409003.131189.87.ca...@infradead.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/kernel/tsc.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 5054497..21187eb 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 unsigned int __read_mostly cpu_khz;/* TSC clocks / usec, not used here */
 EXPORT_SYMBOL(cpu_khz);
@@ -1004,15 +1005,17 @@ EXPORT_SYMBOL_GPL(mark_tsc_unstable);
 
 static void __init check_system_tsc_reliable(void)
 {
-#ifdef CONFIG_MGEODE_LX
-   /* RTSC counts during suspend */
+#if defined(CONFIG_MGEODEGX1) || defined(CONFIG_MGEODE_LX) || 
defined(CONFIG_X86_GENERIC)
+   if (is_geode_lx()) {
+   /* RTSC counts during suspend */
 #define RTSC_SUSP 0x100
-   unsigned long res_low, res_high;
+   unsigned long res_low, res_high;
 
-   rdmsr_safe(MSR_GEODE_BUSCONT_CONF0, &res_low, &res_high);
-   /* Geode_LX - the OLPC CPU has a very reliable TSC */
-   if (res_low & RTSC_SUSP)
-   tsc_clocksource_reliable = 1;
+   rdmsr_safe(MSR_GEODE_BUSCONT_CONF0, &res_low, &res_high);
+   /* Geode_LX - the OLPC CPU has a very reliable TSC */
+   if (res_low & RTSC_SUSP)
+   tsc_clocksource_reliable = 1;
+   }
 #endif
if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE))
tsc_clocksource_reliable = 1;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 45/86] KVM: x86: trap AMD MSRs for the TSeg base and mask

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Paolo Bonzini 

commit 3afb1121800128aae9f5722e50097fcf1a9d4d88 upstream.

These have roughly the same purpose as the SMRR, which we do not need
to implement in KVM.  However, Linux accesses MSR_K8_TSEG_ADDR at
boot, which causes problems when running a Xen dom0 under KVM.
Just return 0, meaning that processor protection of SMRAM is not
in effect.

Reported-by: M A Young 
Acked-by: Borislav Petkov 
Signed-off-by: Paolo Bonzini 
[ luis: backported to 3.16:
  - file rename: arch/x86/include/asm/msr-index.h ->
arch/x86/include/uapi/asm/msr-index.h
  - adjusted context ]
Signed-off-by: Luis Henriques 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/include/uapi/asm/msr-index.h | 1 +
 arch/x86/kvm/x86.c| 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/include/uapi/asm/msr-index.h 
b/arch/x86/include/uapi/asm/msr-index.h
index c8aa65d..9e49356 100644
--- a/arch/x86/include/uapi/asm/msr-index.h
+++ b/arch/x86/include/uapi/asm/msr-index.h
@@ -275,6 +275,7 @@
 /* C1E active bits in int pending message */
 #define K8_INTP_C1E_ACTIVE_MASK0x1800
 #define MSR_K8_TSEG_ADDR   0xc0010112
+#define MSR_K8_TSEG_MASK   0xc0010113
 #define K8_MTRRFIXRANGE_DRAM_ENABLE0x0004 /* MtrrFixDramEn bit*/
 #define K8_MTRRFIXRANGE_DRAM_MODIFY0x0008 /* MtrrFixDramModEn bit */
 #define K8_MTRR_RDMEM_WRMEM_MASK   0x18181818 /* Mask: RdMem|WrMem*/
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 57d5915..145832a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2469,6 +2469,8 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, 
u64 *pdata)
case MSR_IA32_LASTINTFROMIP:
case MSR_IA32_LASTINTTOIP:
case MSR_K8_SYSCFG:
+   case MSR_K8_TSEG_ADDR:
+   case MSR_K8_TSEG_MASK:
case MSR_K7_HWCR:
case MSR_VM_HSAVE_PA:
case MSR_K7_EVNTSEL0:
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 60/86] ASoC: pxa: pxa2xx-ac97: fix dma requestor lines

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Robert Jarzmik 

commit 8811191fdf7ed02ee07cb8469428158572d355a2 upstream.

PCM receive and transmit DMA requestor lines were reverted, breaking the
PCM playback interface for PXA platforms using the sound/soc/ variant
instead of the sound/arm variant.

The commit below shows the inversion in the requestor lines.

Fixes: d65a14587a9b ("ASoC: pxa: use snd_dmaengine_dai_dma_data")
Signed-off-by: Robert Jarzmik 
Signed-off-by: Mark Brown 
Signed-off-by: Kamal Mostafa 
---
 sound/soc/pxa/pxa2xx-ac97.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c
index 1f60546..9e4b04e 100644
--- a/sound/soc/pxa/pxa2xx-ac97.c
+++ b/sound/soc/pxa/pxa2xx-ac97.c
@@ -49,7 +49,7 @@ static struct snd_ac97_bus_ops pxa2xx_ac97_ops = {
.reset  = pxa2xx_ac97_cold_reset,
 };
 
-static unsigned long pxa2xx_ac97_pcm_stereo_in_req = 12;
+static unsigned long pxa2xx_ac97_pcm_stereo_in_req = 11;
 static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_stereo_in = {
.addr   = __PREG(PCDR),
.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
@@ -57,7 +57,7 @@ static struct snd_dmaengine_dai_dma_data 
pxa2xx_ac97_pcm_stereo_in = {
.filter_data= &pxa2xx_ac97_pcm_stereo_in_req,
 };
 
-static unsigned long pxa2xx_ac97_pcm_stereo_out_req = 11;
+static unsigned long pxa2xx_ac97_pcm_stereo_out_req = 12;
 static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_stereo_out = {
.addr   = __PREG(PCDR),
.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 47/86] xhci: give command abortion one more chance before killing xhci

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Mathias Nyman 

commit a6809ffd1687b3a8c192960e69add559b9d32649 upstream.

We want to give the command abortion an additional try to stop
the command ring before we completely hose xhci.

Tested-by: Vincent Pelletier 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
[ luis: backported to 3.16:
  - xhci_handshake() has an extra 'xhci' parameter in 3.16 ]
Signed-off-by: Luis Henriques 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/host/xhci-ring.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 95c340c..47364dd 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -302,6 +302,15 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
ret = xhci_handshake(xhci, &xhci->op_regs->cmd_ring,
CMD_RING_RUNNING, 0, 5 * 1000 * 1000);
if (ret < 0) {
+   /* we are about to kill xhci, give it one more chance */
+   xhci_write_64(xhci, temp_64 | CMD_RING_ABORT,
+ &xhci->op_regs->cmd_ring);
+   udelay(1000);
+   ret = xhci_handshake(xhci, &xhci->op_regs->cmd_ring,
+CMD_RING_RUNNING, 0, 3 * 1000 * 1000);
+   if (ret == 0)
+   return 0;
+
xhci_err(xhci, "Stopped the command ring failed, "
"maybe the host is dead\n");
xhci->xhc_state |= XHCI_STATE_DYING;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: perf oops/recursive fault using BTS

2015-10-27 Thread Dave Jones
On Tue, Oct 27, 2015 at 02:58:49PM -0400, Vince Weaver wrote:
 > On Tue, 27 Oct 2015, Dave Jones wrote:
 > 
 > > I was experimenting with a variant of Vince's bts_kernel test
 > > (https://github.com/deater/perf_event_tests/blob/master/tests/x86_intel/bts_kernel.c)
 > > and hit this..
 > 
 > what type of machine was this on?  
 > 

i7-5820K

Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 42/86] hp-wmi: limit hotkey enable

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Kyle Evans 

commit 8a1513b49321e503fd6c8b6793e3b1f9a8a3285b upstream.

Do not write initialize magic on systems that do not have
feature query 0xb. Fixes Bug #82451.

Redefine FEATURE_QUERY to align with 0xb and FEATURE2 with 0xd
for code clearity.

Add a new test function, hp_wmi_bios_2008_later() & simplify
hp_wmi_bios_2009_later(), which fixes a bug in cases where
an improper value is returned. Probably also fixes Bug #69131.

Add missing __init tag.

Signed-off-by: Kyle Evans 
Signed-off-by: Darren Hart 
Signed-off-by: Kamal Mostafa 
---
 drivers/platform/x86/hp-wmi.c | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
index 0ab2b37..2de5af9 100644
--- a/drivers/platform/x86/hp-wmi.c
+++ b/drivers/platform/x86/hp-wmi.c
@@ -54,8 +54,9 @@ MODULE_ALIAS("wmi:5FB7F034-2C63-45e9-BE91-3D44E2C707E4");
 #define HPWMI_HARDWARE_QUERY 0x4
 #define HPWMI_WIRELESS_QUERY 0x5
 #define HPWMI_BIOS_QUERY 0x9
+#define HPWMI_FEATURE_QUERY 0xb
 #define HPWMI_HOTKEY_QUERY 0xc
-#define HPWMI_FEATURE_QUERY 0xd
+#define HPWMI_FEATURE2_QUERY 0xd
 #define HPWMI_WIRELESS2_QUERY 0x1b
 #define HPWMI_POSTCODEERROR_QUERY 0x2a
 
@@ -295,25 +296,33 @@ static int hp_wmi_tablet_state(void)
return (state & 0x4) ? 1 : 0;
 }
 
-static int __init hp_wmi_bios_2009_later(void)
+static int __init hp_wmi_bios_2008_later(void)
 {
int state = 0;
int ret = hp_wmi_perform_query(HPWMI_FEATURE_QUERY, 0, &state,
   sizeof(state), sizeof(state));
-   if (ret)
-   return ret;
+   if (!ret)
+   return 1;
 
-   return (state & 0x10) ? 1 : 0;
+   return (ret == HPWMI_RET_UNKNOWN_CMDTYPE) ? 0 : -ENXIO;
 }
 
-static int hp_wmi_enable_hotkeys(void)
+static int __init hp_wmi_bios_2009_later(void)
 {
-   int ret;
-   int query = 0x6e;
+   int state = 0;
+   int ret = hp_wmi_perform_query(HPWMI_FEATURE2_QUERY, 0, &state,
+  sizeof(state), sizeof(state));
+   if (!ret)
+   return 1;
 
-   ret = hp_wmi_perform_query(HPWMI_BIOS_QUERY, 1, &query, sizeof(query),
-  0);
+   return (ret == HPWMI_RET_UNKNOWN_CMDTYPE) ? 0 : -ENXIO;
+}
 
+static int __init hp_wmi_enable_hotkeys(void)
+{
+   int value = 0x6e;
+   int ret = hp_wmi_perform_query(HPWMI_BIOS_QUERY, 1, &value,
+  sizeof(value), 0);
if (ret)
return -EINVAL;
return 0;
@@ -663,7 +672,7 @@ static int __init hp_wmi_input_setup(void)
hp_wmi_tablet_state());
input_sync(hp_wmi_input_dev);
 
-   if (hp_wmi_bios_2009_later() == 4)
+   if (!hp_wmi_bios_2009_later() && hp_wmi_bios_2008_later())
hp_wmi_enable_hotkeys();
 
status = wmi_install_notify_handler(HPWMI_EVENT_GUID, hp_wmi_notify, 
NULL);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 41/86] staging: ion: fix corruption of ion_import_dma_buf

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Shawn Lin 

commit 6fa92e2bcf6390e64895b12761e851c452d87bd8 upstream.

we found this issue but still exit in lastest kernel. Simply
keep ion_handle_create under mutex_lock to avoid this race.

WARNING: CPU: 2 PID: 2648 at drivers/staging/android/ion/ion.c:512 
ion_handle_add+0xb4/0xc0()
ion_handle_add: buffer already found.
Modules linked in: iwlmvm iwlwifi mac80211 cfg80211 compat
CPU: 2 PID: 2648 Comm: TimedEventQueue Tainted: GW3.14.0 #7
   9a3efd2c 80faf273 9a3efd6c 9a3efd5c 80935dc9 811d7fd3
 9a3efd88 0a58 812208a0 0200 80e128d4 80e128d4 8d4ae00c a8cd8600
 a8cd8094 9a3efd74 80935e0e 0009 9a3efd6c 811d7fd3 9a3efd88 9a3efd9c
Call Trace:
  [<80faf273>] dump_stack+0x48/0x69
  [<80935dc9>] warn_slowpath_common+0x79/0x90
  [<80e128d4>] ? ion_handle_add+0xb4/0xc0
  [<80e128d4>] ? ion_handle_add+0xb4/0xc0
  [<80935e0e>] warn_slowpath_fmt+0x2e/0x30
  [<80e128d4>] ion_handle_add+0xb4/0xc0
  [<80e144cc>] ion_import_dma_buf+0x8c/0x110
  [<80c517c4>] reg_init+0x364/0x7d0
  [<80993363>] ? futex_wait+0x123/0x210
  [<80992e0e>] ? get_futex_key+0x16e/0x1e0
  [<8099308f>] ? futex_wake+0x5f/0x120
  [<80c51e19>] vpu_service_ioctl+0x1e9/0x500
  [<80994aec>] ? do_futex+0xec/0x8e0
  [<80971080>] ? prepare_to_wait_event+0xc0/0xc0
  [<80c51c30>] ? reg_init+0x7d0/0x7d0
  [<80a22562>] do_vfs_ioctl+0x2d2/0x4c0
  [<80b198ad>] ? inode_has_perm.isra.41+0x2d/0x40
  [<80b199cf>] ? file_has_perm+0x7f/0x90
  [<80b1a5f7>] ? selinux_file_ioctl+0x47/0xf0
  [<80a227a8>] SyS_ioctl+0x58/0x80
  [<80fb45e8>] syscall_call+0x7/0x7
  [<80fb>] ? mmc_do_calc_max_discard+0xab/0xe4

Fixes: 83271f626 ("ion: hold reference to handle...")
Signed-off-by: Shawn Lin 
Reviewed-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Kamal Mostafa 
---
 drivers/staging/android/ion/ion.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 296d347..9ac97fa 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1174,13 +1174,13 @@ struct ion_handle *ion_import_dma_buf(struct ion_client 
*client, int fd)
mutex_unlock(&client->lock);
goto end;
}
-   mutex_unlock(&client->lock);
 
handle = ion_handle_create(client, buffer);
-   if (IS_ERR(handle))
+   if (IS_ERR(handle)) {
+   mutex_unlock(&client->lock);
goto end;
+   }
 
-   mutex_lock(&client->lock);
ret = ion_handle_add(client, handle);
mutex_unlock(&client->lock);
if (ret) {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 43/86] zram: fix possible use after free in zcomp_create()

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Luis Henriques 

commit 3aaf14da807a4e9931a37f21e4251abb8a67021b upstream.

zcomp_create() verifies the success of zcomp_strm_{multi,single}_create()
through comp->stream, which can potentially be pointing to memory that
was freed if these functions returned an error.

While at it, replace a 'ERR_PTR(-ENOMEM)' by a more generic
'ERR_PTR(error)' as in the future zcomp_strm_{multi,siggle}_create()
could return other error codes.  Function documentation updated
accordingly.

Fixes: beca3ec71fe5 ("zram: add multi stream functionality")
Signed-off-by: Luis Henriques 
Acked-by: Sergey Senozhatsky 
Acked-by: Minchan Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Kamal Mostafa 
---
 drivers/block/zram/zcomp.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index f1ff39a..54d946a 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -325,12 +325,14 @@ void zcomp_destroy(struct zcomp *comp)
  * allocate new zcomp and initialize it. return compressing
  * backend pointer or ERR_PTR if things went bad. ERR_PTR(-EINVAL)
  * if requested algorithm is not supported, ERR_PTR(-ENOMEM) in
- * case of allocation error.
+ * case of allocation error, or any other error potentially
+ * returned by functions zcomp_strm_{multi,single}_create.
  */
 struct zcomp *zcomp_create(const char *compress, int max_strm)
 {
struct zcomp *comp;
struct zcomp_backend *backend;
+   int error;
 
backend = find_backend(compress);
if (!backend)
@@ -342,12 +344,12 @@ struct zcomp *zcomp_create(const char *compress, int 
max_strm)
 
comp->backend = backend;
if (max_strm > 1)
-   zcomp_strm_multi_create(comp, max_strm);
+   error = zcomp_strm_multi_create(comp, max_strm);
else
-   zcomp_strm_single_create(comp);
-   if (!comp->stream) {
+   error = zcomp_strm_single_create(comp);
+   if (error) {
kfree(comp);
-   return ERR_PTR(-ENOMEM);
+   return ERR_PTR(error);
}
return comp;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 1/2] ASoC: wm9713: convert to regmap

2015-10-27 Thread Robert Jarzmik
Convert the Wolfson WM9713 to regmap API. This will leverage all the
regmap functions (debug, registers update, etc ...).

As a bonus, this will pave the path to gpio chip introduction, and
devicetree support.

Signed-off-by: Robert Jarzmik 
---
Since v1: fix suspend/resume (that specific part is not tested yet)
Since v2: split out the snd_soc_*() from regmap support
---
 sound/soc/codecs/Kconfig  |   1 +
 sound/soc/codecs/wm9713.c | 182 --
 2 files changed, 114 insertions(+), 69 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0c9733ecd17f..ba306f8f3717 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -879,6 +879,7 @@ config SND_SOC_WM9712
 
 config SND_SOC_WM9713
tristate
+   select REGMAP_AC97
 
 # Amp
 config SND_SOC_LM4857
diff --git a/sound/soc/codecs/wm9713.c b/sound/soc/codecs/wm9713.c
index 4083a5130cbd..8e2cc1112e40 100644
--- a/sound/soc/codecs/wm9713.c
+++ b/sound/soc/codecs/wm9713.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,33 +40,15 @@ struct wm9713_priv {
struct mutex lock;
 };
 
-static unsigned int ac97_read(struct snd_soc_codec *codec,
-   unsigned int reg);
-static int ac97_write(struct snd_soc_codec *codec,
-   unsigned int reg, unsigned int val);
-
-/*
- * WM9713 register cache
- * Reg 0x3c bit 15 is used by touch driver.
- */
-static const u16 wm9713_reg[] = {
-   0x6174, 0x8080, 0x8080, 0x8080,
-   0xc880, 0xe808, 0xe808, 0x0808,
-   0x00da, 0x8000, 0xd600, 0xaaa0,
-   0xaaa0, 0xaaa0, 0x, 0x,
-   0x0f0f, 0x0040, 0x, 0x7f00,
-   0x0405, 0x0410, 0xbb80, 0xbb80,
-   0x, 0xbb80, 0x, 0x4523,
-   0x, 0x2000, 0x7eff, 0x,
-   0x, 0x, 0x0080, 0x,
-   0x, 0x, 0xfffe, 0x,
-   0x, 0x, 0x, 0xfffe,
-   0x4000, 0x, 0x, 0x,
-   0xb032, 0x3e00, 0x, 0x,
-   0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x0006,
-   0x0001, 0x, 0x574d, 0x4c13,
-};
+static unsigned int ac97_read(struct snd_soc_codec *codec, unsigned int reg)
+{
+   return snd_soc_read(codec, reg);
+}
+static int ac97_write(struct snd_soc_codec *codec, unsigned int reg,
+ unsigned int val)
+{
+   return snd_soc_write(codec, reg, val);
+}
 
 #define HPL_MIXER 0
 #define HPR_MIXER 1
@@ -674,39 +657,97 @@ static const struct snd_soc_dapm_route wm9713_audio_map[] 
= {
{"Capture Mono Mux", "Right", "Right Capture Source"},
 };
 
-static unsigned int ac97_read(struct snd_soc_codec *codec,
-   unsigned int reg)
+static bool wm9713_readable_reg(struct device *dev, unsigned int reg)
 {
-   struct wm9713_priv *wm9713 = snd_soc_codec_get_drvdata(codec);
-   u16 *cache = codec->reg_cache;
-
-   if (reg == AC97_RESET || reg == AC97_GPIO_STATUS ||
-   reg == AC97_VENDOR_ID1 || reg == AC97_VENDOR_ID2 ||
-   reg == AC97_CD)
-   return soc_ac97_ops->read(wm9713->ac97, reg);
-   else {
-   reg = reg >> 1;
-
-   if (reg >= (ARRAY_SIZE(wm9713_reg)))
-   return -EIO;
-
-   return cache[reg];
+   switch (reg) {
+   case AC97_RESET ... AC97_PCM_SURR_DAC_RATE:
+   case AC97_PCM_LR_ADC_RATE:
+   case AC97_CENTER_LFE_MASTER:
+   case AC97_SPDIF ... AC97_LINE1_LEVEL:
+   case AC97_GPIO_CFG ... 0x5c:
+   case AC97_CODEC_CLASS_REV ... AC97_PCI_SID:
+   case 0x74 ... AC97_VENDOR_ID2:
+   return true;
+   default:
+   return false;
}
 }
 
-static int ac97_write(struct snd_soc_codec *codec, unsigned int reg,
-   unsigned int val)
+static bool wm9713_writeable_reg(struct device *dev, unsigned int reg)
 {
-   struct wm9713_priv *wm9713 = snd_soc_codec_get_drvdata(codec);
+   switch (reg) {
+   case AC97_VENDOR_ID1:
+   case AC97_VENDOR_ID2:
+   return false;
+   default:
+   return wm9713_readable_reg(dev, reg);
+   }
+}
 
-   u16 *cache = codec->reg_cache;
-   soc_ac97_ops->write(wm9713->ac97, reg, val);
-   reg = reg >> 1;
-   if (reg < (ARRAY_SIZE(wm9713_reg)))
-   cache[reg] = val;
+static const struct reg_default wm9713_reg_defaults[] = {
+   { 0x02, 0x8080 },   /* Speaker Output Volume */
+   { 0x04, 0x8080 },   /* Headphone Output Volume */
+   { 0x06, 0x8080 },   /* Out3/OUT4 Volume */
+   { 0x08, 0xc880 },   /* Mono Volume */
+   { 0x0a, 0xe808 },   /* LINEIN Volume */
+   { 0x0c, 0xe808 },   /* DAC PGA Volume */
+   { 0x0e, 0x0808 },   /* MIC PGA Volume */
+   { 0x10, 0x00da },   /* MIC Routing Control */
+   { 0x12, 0x8000 },   /* Record PGA Volume */
+   { 0x14, 0xd600 },   /* Record Routing */
+   { 0x16, 0xaaa0 },   /* PCBEEP Volum

[PATCH 3.19.y-ckt 30/86] powerpc/boot: Specify ABI v2 when building an LE boot wrapper

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Benjamin Herrenschmidt 

commit 655471f54c2e395ba29ae4156ba0f49928177cc1 upstream.

The kernel does it, not the boot wrapper, which breaks with some
cross compilers that still default to ABI v1.

Fixes: 147c05168fc8 ("powerpc/boot: Add support for 64bit little endian 
wrapper")
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Michael Ellerman 
Signed-off-by: Kamal Mostafa 
---
 arch/powerpc/boot/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8a5bc1c..981e607 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -28,6 +28,9 @@ BOOTCFLAGS+= -m64
 endif
 ifdef CONFIG_CPU_BIG_ENDIAN
 BOOTCFLAGS += -mbig-endian
+else
+BOOTCFLAGS += -mlittle-endian
+BOOTCFLAGS += $(call cc-option,-mabi=elfv2)
 endif
 
 BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 38/86] s390/compat: correct uc_sigmask of the compat signal frame

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Martin Schwidefsky 

commit 8d4bd0ed0439dfc780aab801a085961925ed6838 upstream.

The uc_sigmask in the ucontext structure is an array of words to keep
the 64 signal bits (or 1024 if you ask glibc but the kernel sigset_t
only has 64 bits).

For 64 bit the sigset_t contains a single 8 byte word, but for 31 bit
there are two 4 byte words. The compat signal handler code uses a
simple copy of the 64 bit sigset_t to the 31 bit compat_sigset_t.
As s390 is a big-endian architecture this is incorrect, the two words
in the 31 bit sigset_t array need to be swapped.

Reported-by: Stefan Liebler 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Kamal Mostafa 
---
 arch/s390/kernel/compat_signal.c | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/arch/s390/kernel/compat_signal.c b/arch/s390/kernel/compat_signal.c
index 34d5fa7..f564740 100644
--- a/arch/s390/kernel/compat_signal.c
+++ b/arch/s390/kernel/compat_signal.c
@@ -48,6 +48,19 @@ typedef struct
struct ucontext32 uc;
 } rt_sigframe32;
 
+static inline void sigset_to_sigset32(unsigned long *set64,
+ compat_sigset_word *set32)
+{
+   set32[0] = (compat_sigset_word) set64[0];
+   set32[1] = (compat_sigset_word)(set64[0] >> 32);
+}
+
+static inline void sigset32_to_sigset(compat_sigset_word *set32,
+ unsigned long *set64)
+{
+   set64[0] = (unsigned long) set32[0] | ((unsigned long) set32[1] << 32);
+}
+
 int copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t *from)
 {
int err;
@@ -303,10 +316,12 @@ COMPAT_SYSCALL_DEFINE0(sigreturn)
 {
struct pt_regs *regs = task_pt_regs(current);
sigframe32 __user *frame = (sigframe32 __user *)regs->gprs[15];
+   compat_sigset_t cset;
sigset_t set;
 
-   if (__copy_from_user(&set.sig, &frame->sc.oldmask, 
_SIGMASK_COPY_SIZE32))
+   if (__copy_from_user(&cset.sig, &frame->sc.oldmask, 
_SIGMASK_COPY_SIZE32))
goto badframe;
+   sigset32_to_sigset(cset.sig, set.sig);
set_current_blocked(&set);
if (restore_sigregs32(regs, &frame->sregs))
goto badframe;
@@ -323,10 +338,12 @@ COMPAT_SYSCALL_DEFINE0(rt_sigreturn)
 {
struct pt_regs *regs = task_pt_regs(current);
rt_sigframe32 __user *frame = (rt_sigframe32 __user *)regs->gprs[15];
+   compat_sigset_t cset;
sigset_t set;
 
-   if (__copy_from_user(&set, &frame->uc.uc_sigmask, sizeof(set)))
+   if (__copy_from_user(&cset, &frame->uc.uc_sigmask, sizeof(cset)))
goto badframe;
+   sigset32_to_sigset(cset.sig, set.sig);
set_current_blocked(&set);
if (compat_restore_altstack(&frame->uc.uc_stack))
goto badframe;
@@ -407,7 +424,7 @@ static int setup_frame32(struct ksignal *ksig, sigset_t 
*set,
return -EFAULT;
 
/* Create struct sigcontext32 on the signal stack */
-   memcpy(&sc.oldmask, &set->sig, _SIGMASK_COPY_SIZE32);
+   sigset_to_sigset32(set->sig, sc.oldmask);
sc.sregs = (__u32)(unsigned long __force) &frame->sregs;
if (__copy_to_user(&frame->sc, &sc, sizeof(frame->sc)))
return -EFAULT;
@@ -468,6 +485,7 @@ static int setup_frame32(struct ksignal *ksig, sigset_t 
*set,
 static int setup_rt_frame32(struct ksignal *ksig, sigset_t *set,
struct pt_regs *regs)
 {
+   compat_sigset_t cset;
rt_sigframe32 __user *frame;
unsigned long restorer;
size_t frame_size;
@@ -515,11 +533,12 @@ static int setup_rt_frame32(struct ksignal *ksig, 
sigset_t *set,
store_sigregs();
 
/* Create ucontext on the signal stack. */
+   sigset_to_sigset32(set->sig, cset.sig);
if (__put_user(uc_flags, &frame->uc.uc_flags) ||
__put_user(0, &frame->uc.uc_link) ||
__compat_save_altstack(&frame->uc.uc_stack, regs->gprs[15]) ||
save_sigregs32(regs, &frame->uc.uc_mcontext) ||
-   __copy_to_user(&frame->uc.uc_sigmask, set, sizeof(*set)) ||
+   __copy_to_user(&frame->uc.uc_sigmask, &cset, sizeof(cset)) ||
save_sigregs_ext32(regs, &frame->uc.uc_mcontext_ext))
return -EFAULT;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v3 2/2] ASoC: wm9713: use snd_soc_*() calls to update ac97 registers

2015-10-27 Thread Robert Jarzmik
Convert wm9713 to use the more modern registers manipulation functions,
such as snd_soc_read(), snd_soc_write() and snd_soc_update_bits().

Signed-off-by: Robert Jarzmik 
---
 sound/soc/codecs/wm9713.c | 140 +-
 1 file changed, 52 insertions(+), 88 deletions(-)

diff --git a/sound/soc/codecs/wm9713.c b/sound/soc/codecs/wm9713.c
index 8e2cc1112e40..15c0cbbadec2 100644
--- a/sound/soc/codecs/wm9713.c
+++ b/sound/soc/codecs/wm9713.c
@@ -40,16 +40,6 @@ struct wm9713_priv {
struct mutex lock;
 };
 
-static unsigned int ac97_read(struct snd_soc_codec *codec, unsigned int reg)
-{
-   return snd_soc_read(codec, reg);
-}
-static int ac97_write(struct snd_soc_codec *codec, unsigned int reg,
- unsigned int val)
-{
-   return snd_soc_write(codec, reg, val);
-}
-
 #define HPL_MIXER 0
 #define HPR_MIXER 1
 
@@ -203,18 +193,15 @@ static int wm9713_voice_shutdown(struct 
snd_soc_dapm_widget *w,
 struct snd_kcontrol *kcontrol, int event)
 {
struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
-   u16 status, rate;
 
if (WARN_ON(event != SND_SOC_DAPM_PRE_PMD))
return -EINVAL;
 
/* Gracefully shut down the voice interface. */
-   status = ac97_read(codec, AC97_EXTENDED_MID) | 0x1000;
-   rate = ac97_read(codec, AC97_HANDSET_RATE) & 0xF0FF;
-   ac97_write(codec, AC97_HANDSET_RATE, rate | 0x0200);
+   snd_soc_update_bits(codec, AC97_HANDSET_RATE, 0x0f00, 0x0200);
schedule_timeout_interruptible(msecs_to_jiffies(1));
-   ac97_write(codec, AC97_HANDSET_RATE, rate | 0x0F00);
-   ac97_write(codec, AC97_EXTENDED_MID, status);
+   snd_soc_update_bits(codec, AC97_HANDSET_RATE, 0x0f00, 0x0f00);
+   snd_soc_update_bits(codec, AC97_EXTENDED_MID, 0x1000, 0x1000);
 
return 0;
 }
@@ -834,10 +821,8 @@ static int wm9713_set_pll(struct snd_soc_codec *codec,
/* turn PLL off ? */
if (freq_in == 0) {
/* disable PLL power and select ext source */
-   reg = ac97_read(codec, AC97_HANDSET_RATE);
-   ac97_write(codec, AC97_HANDSET_RATE, reg | 0x0080);
-   reg = ac97_read(codec, AC97_EXTENDED_MID);
-   ac97_write(codec, AC97_EXTENDED_MID, reg | 0x0200);
+   snd_soc_update_bits(codec, AC97_HANDSET_RATE, 0x0080, 0x0080);
+   snd_soc_update_bits(codec, AC97_EXTENDED_MID, 0x0200, 0x0200);
wm9713->pll_in = 0;
return 0;
}
@@ -847,7 +832,7 @@ static int wm9713_set_pll(struct snd_soc_codec *codec,
if (pll_div.k == 0) {
reg = (pll_div.n << 12) | (pll_div.lf << 11) |
(pll_div.divsel << 9) | (pll_div.divctl << 8);
-   ac97_write(codec, AC97_LINE1_LEVEL, reg);
+   snd_soc_write(codec, AC97_LINE1_LEVEL, reg);
} else {
/* write the fractional k to the reg 0x46 pages */
reg2 = (pll_div.n << 12) | (pll_div.lf << 11) | (1 << 10) |
@@ -855,33 +840,31 @@ static int wm9713_set_pll(struct snd_soc_codec *codec,
 
/* K [21:20] */
reg = reg2 | (0x5 << 4) | (pll_div.k >> 20);
-   ac97_write(codec, AC97_LINE1_LEVEL, reg);
+   snd_soc_write(codec, AC97_LINE1_LEVEL, reg);
 
/* K [19:16] */
reg = reg2 | (0x4 << 4) | ((pll_div.k >> 16) & 0xf);
-   ac97_write(codec, AC97_LINE1_LEVEL, reg);
+   snd_soc_write(codec, AC97_LINE1_LEVEL, reg);
 
/* K [15:12] */
reg = reg2 | (0x3 << 4) | ((pll_div.k >> 12) & 0xf);
-   ac97_write(codec, AC97_LINE1_LEVEL, reg);
+   snd_soc_write(codec, AC97_LINE1_LEVEL, reg);
 
/* K [11:8] */
reg = reg2 | (0x2 << 4) | ((pll_div.k >> 8) & 0xf);
-   ac97_write(codec, AC97_LINE1_LEVEL, reg);
+   snd_soc_write(codec, AC97_LINE1_LEVEL, reg);
 
/* K [7:4] */
reg = reg2 | (0x1 << 4) | ((pll_div.k >> 4) & 0xf);
-   ac97_write(codec, AC97_LINE1_LEVEL, reg);
+   snd_soc_write(codec, AC97_LINE1_LEVEL, reg);
 
reg = reg2 | (0x0 << 4) | (pll_div.k & 0xf); /* K [3:0] */
-   ac97_write(codec, AC97_LINE1_LEVEL, reg);
+   snd_soc_write(codec, AC97_LINE1_LEVEL, reg);
}
 
/* turn PLL on and select as source */
-   reg = ac97_read(codec, AC97_EXTENDED_MID);
-   ac97_write(codec, AC97_EXTENDED_MID, reg & 0xfdff);
-   reg = ac97_read(codec, AC97_HANDSET_RATE);
-   ac97_write(codec, AC97_HANDSET_RATE, reg & 0xff7f);
+   snd_soc_update_bits(codec, AC97_EXTENDED_MID, 0x0200, 0x);
+   snd_soc_update_bits(codec, AC97_HANDSET_RATE, 0x0080, 0x);
wm9713->pll_in = freq_in;
 
/* wait 10ms AC97 link frames for the link to stabilise */
@@ -904,10 +887,10 

[PATCH 3.19.y-ckt 39/86] arm64: KVM: Disable virtual timer even if the guest is not using it

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Marc Zyngier 

commit c4cbba9fa078f55d9f6d081dbb4aec7cf969e7c7 upstream.

When running a guest with the architected timer disabled (with QEMU and
the kernel_irqchip=off option, for example), it is important to make
sure the timer gets turned off. Otherwise, the guest may try to
enable it anyway, leading to a screaming HW interrupt.

The fix is to unconditionally turn off the virtual timer on guest
exit.

Reviewed-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Kamal Mostafa 
---
 arch/arm64/kvm/hyp.S | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index cbaa8bc..0a2ff0f 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -843,8 +843,6 @@
mrs x3, cntv_ctl_el0
and x3, x3, #3
str w3, [x0, #VCPU_TIMER_CNTV_CTL]
-   bic x3, x3, #1  // Clear Enable
-   msr cntv_ctl_el0, x3
 
isb
 
@@ -852,6 +850,9 @@
str x3, [x0, #VCPU_TIMER_CNTV_CVAL]
 
 1:
+   // Disable the virtual timer
+   msr cntv_ctl_el0, xzr
+
// Allow physical timer/counter access for the host
mrs x2, cnthctl_el2
orr x2, x2, #3
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 19/86] usb: chipidea: udc: using the correct stall implementation

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Peter Chen 

commit 56ffa1d154c7e12af16273f0cdc42690dd05caf5 upstream.

According to spec, there are functional and protocol stalls.

For functional stall, it is for bulk and interrupt endpoints,
below are cases for it:
- Host sends SET_FEATURE request for Set-Halt, the udc driver
needs to set stall, and return true unconditionally.
- The gadget driver may call usb_ep_set_halt to stall certain
endpoints, if there is a transfer in pending, the udc driver
should not set stall, and return -EAGAIN accordingly.
These two kinds of stall need to be cleared by host using CLEAR_FEATURE
request (Clear-Halt).

For protocol stall, it is for control endpoint, this stall will
be set if the control request has failed. This stall will be
cleared by next setup request (hardware will do it).

It fixed usbtest (drivers/usb/misc/usbtest.c) Test 13 "set/clear halt"
test failure, meanwhile, this change has been verified by
USB2 CV Compliance Test and MSC Tests.

Cc: Alan Stern 
Cc: Felipe Balbi 
Signed-off-by: Peter Chen 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/chipidea/udc.c | 84 --
 1 file changed, 44 insertions(+), 40 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 7c14565..bd986ce 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -638,6 +638,44 @@ __acquires(hwep->lock)
return 0;
 }
 
+static int _ep_set_halt(struct usb_ep *ep, int value, bool check_transfer)
+{
+   struct ci_hw_ep *hwep = container_of(ep, struct ci_hw_ep, ep);
+   int direction, retval = 0;
+   unsigned long flags;
+
+   if (ep == NULL || hwep->ep.desc == NULL)
+   return -EINVAL;
+
+   if (usb_endpoint_xfer_isoc(hwep->ep.desc))
+   return -EOPNOTSUPP;
+
+   spin_lock_irqsave(hwep->lock, flags);
+
+   if (value && hwep->dir == TX && check_transfer &&
+   !list_empty(&hwep->qh.queue) &&
+   !usb_endpoint_xfer_control(hwep->ep.desc)) {
+   spin_unlock_irqrestore(hwep->lock, flags);
+   return -EAGAIN;
+   }
+
+   direction = hwep->dir;
+   do {
+   retval |= hw_ep_set_halt(hwep->ci, hwep->num, hwep->dir, value);
+
+   if (!value)
+   hwep->wedge = 0;
+
+   if (hwep->type == USB_ENDPOINT_XFER_CONTROL)
+   hwep->dir = (hwep->dir == TX) ? RX : TX;
+
+   } while (hwep->dir != direction);
+
+   spin_unlock_irqrestore(hwep->lock, flags);
+   return retval;
+}
+
+
 /**
  * _gadget_stop_activity: stops all USB activity, flushes & disables all endpts
  * @gadget: gadget
@@ -1033,7 +1071,7 @@ __acquires(ci->lock)
num += ci->hw_ep_max / 2;
 
spin_unlock(&ci->lock);
-   err = usb_ep_set_halt(&ci->ci_hw_ep[num].ep);
+   err = _ep_set_halt(&ci->ci_hw_ep[num].ep, 1, false);
spin_lock(&ci->lock);
if (!err)
isr_setup_status_phase(ci);
@@ -1092,8 +1130,8 @@ delegate:
 
if (err < 0) {
spin_unlock(&ci->lock);
-   if (usb_ep_set_halt(&hwep->ep))
-   dev_err(ci->dev, "error: ep_set_halt\n");
+   if (_ep_set_halt(&hwep->ep, 1, false))
+   dev_err(ci->dev, "error: _ep_set_halt\n");
spin_lock(&ci->lock);
}
 }
@@ -1124,9 +1162,9 @@ __acquires(ci->lock)
err = isr_setup_status_phase(ci);
if (err < 0) {
spin_unlock(&ci->lock);
-   if (usb_ep_set_halt(&hwep->ep))
+   if (_ep_set_halt(&hwep->ep, 1, false))
dev_err(ci->dev,
-   "error: ep_set_halt\n");
+   "error: _ep_set_halt\n");
spin_lock(&ci->lock);
}
}
@@ -1369,41 +1407,7 @@ static int ep_dequeue(struct usb_ep *ep, struct 
usb_request *req)
  */
 static int ep_set_halt(struct usb_ep *ep, int value)
 {
-   struct ci_hw_ep *hwep = container_of(ep, struct ci_hw_ep, ep);
-   int direction, retval = 0;
-   unsigned long flags;
-
-   if (ep == NULL || hwep->ep.desc == NULL)
-   return -EINVAL;
-
-   if (usb_endpoint_xfer_isoc(hwep->ep.desc))
-   return -EOPNOTSUPP;
-
-   spin_lock_irqsave(hwep->lock, flags);
-
-#ifndef STALL_IN
-   /* g_file_storage MS compliant but g_zero fails chapter 9 compliance */
-   if (value && hwep->type == USB_ENDPOINT_XFE

[PATCH 3.19.y-ckt 36/86] arm64: compat: fix vfp save/restore across signal handlers in big-endian

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Will Deacon 

commit bdec97a855ef1e239f130f7a11584721c9a1bf04 upstream.

When saving/restoring the VFP registers from a compat (AArch32)
signal frame, we rely on the compat registers forming a prefix of the
native register file and therefore make use of copy_{to,from}_user to
transfer between the native fpsimd_state and the compat_vfp_sigframe.

Unfortunately, this doesn't work so well in a big-endian environment.
Our fpsimd save/restore code operates directly on 128-bit quantities
(Q registers) whereas the compat_vfp_sigframe represents the registers
as an array of 64-bit (D) registers. The architecture packs the compat D
registers into the Q registers, with the least significant bytes holding
the lower register. Consequently, we need to swap the 64-bit halves when
converting between these two representations on a big-endian machine.

This patch replaces the __copy_{to,from}_user invocations in our
compat VFP signal handling code with explicit __put_user loops that
operate on 64-bit values and swap them accordingly.

Reviewed-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Kamal Mostafa 
---
 arch/arm64/kernel/signal32.c | 47 +---
 1 file changed, 36 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 6ae9340..7ab6dec 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -213,14 +213,32 @@ int copy_siginfo_from_user32(siginfo_t *to, 
compat_siginfo_t __user *from)
 
 /*
  * VFP save/restore code.
+ *
+ * We have to be careful with endianness, since the fpsimd context-switch
+ * code operates on 128-bit (Q) register values whereas the compat ABI
+ * uses an array of 64-bit (D) registers. Consequently, we need to swap
+ * the two halves of each Q register when running on a big-endian CPU.
  */
+union __fpsimd_vreg {
+   __uint128_t raw;
+   struct {
+#ifdef __AARCH64EB__
+   u64 hi;
+   u64 lo;
+#else
+   u64 lo;
+   u64 hi;
+#endif
+   };
+};
+
 static int compat_preserve_vfp_context(struct compat_vfp_sigframe __user 
*frame)
 {
struct fpsimd_state *fpsimd = ¤t->thread.fpsimd_state;
compat_ulong_t magic = VFP_MAGIC;
compat_ulong_t size = VFP_STORAGE_SIZE;
compat_ulong_t fpscr, fpexc;
-   int err = 0;
+   int i, err = 0;
 
/*
 * Save the hardware registers to the fpsimd_state structure.
@@ -236,10 +254,15 @@ static int compat_preserve_vfp_context(struct 
compat_vfp_sigframe __user *frame)
/*
 * Now copy the FP registers. Since the registers are packed,
 * we can copy the prefix we want (V0-V15) as it is.
-* FIXME: Won't work if big endian.
 */
-   err |= __copy_to_user(&frame->ufp.fpregs, fpsimd->vregs,
- sizeof(frame->ufp.fpregs));
+   for (i = 0; i < ARRAY_SIZE(frame->ufp.fpregs); i += 2) {
+   union __fpsimd_vreg vreg = {
+   .raw = fpsimd->vregs[i >> 1],
+   };
+
+   __put_user_error(vreg.lo, &frame->ufp.fpregs[i], err);
+   __put_user_error(vreg.hi, &frame->ufp.fpregs[i + 1], err);
+   }
 
/* Create an AArch32 fpscr from the fpsr and the fpcr. */
fpscr = (fpsimd->fpsr & VFP_FPSCR_STAT_MASK) |
@@ -264,7 +287,7 @@ static int compat_restore_vfp_context(struct 
compat_vfp_sigframe __user *frame)
compat_ulong_t magic = VFP_MAGIC;
compat_ulong_t size = VFP_STORAGE_SIZE;
compat_ulong_t fpscr;
-   int err = 0;
+   int i, err = 0;
 
__get_user_error(magic, &frame->magic, err);
__get_user_error(size, &frame->size, err);
@@ -274,12 +297,14 @@ static int compat_restore_vfp_context(struct 
compat_vfp_sigframe __user *frame)
if (magic != VFP_MAGIC || size != VFP_STORAGE_SIZE)
return -EINVAL;
 
-   /*
-* Copy the FP registers into the start of the fpsimd_state.
-* FIXME: Won't work if big endian.
-*/
-   err |= __copy_from_user(fpsimd.vregs, frame->ufp.fpregs,
-   sizeof(frame->ufp.fpregs));
+   /* Copy the FP registers into the start of the fpsimd_state. */
+   for (i = 0; i < ARRAY_SIZE(frame->ufp.fpregs); i += 2) {
+   union __fpsimd_vreg vreg;
+
+   __get_user_error(vreg.lo, &frame->ufp.fpregs[i], err);
+   __get_user_error(vreg.hi, &frame->ufp.fpregs[i + 1], err);
+   fpsimd.vregs[i >> 1] = vreg.raw;
+   }
 
/* Extract the fpsr and the fpcr from the fpscr */
__get_user_error(fpscr, &frame->ufp.fpscr, err);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info a

[PATCH 3.19.y-ckt 37/86] arm64: errata: add module build workaround for erratum #843419

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Will Deacon 

commit df057cc7b4fa59e9b55f07ffdb6c62bf02e99a00 upstream.

Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can
lead to a memory access using an incorrect address in certain sequences
headed by an ADRP instruction.

There is a linker fix to generate veneers for ADRP instructions, but
this doesn't work for kernel modules which are built as unlinked ELF
objects.

This patch adds a new config option for the erratum which, when enabled,
builds kernel modules with the mcmodel=large flag. This uses absolute
addressing for all kernel symbols, thereby removing the use of ADRP as
a PC-relative form of addressing. The ADRP relocs are removed from the
module loader so that we fail to load any potentially affected modules.

Acked-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Kamal Mostafa 
---
 arch/arm64/Kconfig | 16 
 arch/arm64/Makefile|  4 
 arch/arm64/kernel/module.c |  2 ++
 3 files changed, 22 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5fee0bd..67f5ba5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -331,6 +331,22 @@ config ARM64_ERRATUM_845719
 
  If unsure, say Y.
 
+config ARM64_ERRATUM_843419
+   bool "Cortex-A53: 843419: A load or store might access an incorrect 
address"
+   depends on MODULES
+   default y
+   help
+ This option builds kernel modules using the large memory model in
+ order to avoid the use of the ADRP instruction, which can cause
+ a subsequent memory access to use an incorrect address on Cortex-A53
+ parts up to r0p4.
+
+ Note that the kernel itself must be linked with a version of ld
+ which fixes potentially affected ADRP instructions through the
+ use of veneers.
+
+ If unsure, say Y.
+
 endmenu
 
 
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 0666888..661928f 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -32,6 +32,10 @@ endif
 
 CHECKFLAGS += -D__aarch64__
 
+ifeq ($(CONFIG_ARM64_ERRATUM_843419), y)
+CFLAGS_MODULE  += -mcmodel=large
+endif
+
 # Default value
 head-y := arch/arm64/kernel/head.o
 
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 9b6f71d..4223b0a 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -332,12 +332,14 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
ovf = reloc_insn_imm(RELOC_OP_PREL, loc, val, 0, 21,
 AARCH64_INSN_IMM_ADR);
break;
+#ifndef CONFIG_ARM64_ERRATUM_843419
case R_AARCH64_ADR_PREL_PG_HI21_NC:
overflow_check = false;
case R_AARCH64_ADR_PREL_PG_HI21:
ovf = reloc_insn_imm(RELOC_OP_PAGE, loc, val, 12, 21,
 AARCH64_INSN_IMM_ADR);
break;
+#endif
case R_AARCH64_ADD_ABS_LO12_NC:
case R_AARCH64_LDST8_ABS_LO12_NC:
overflow_check = false;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v5 1/4] media: pxa_camera: fix the buffer free path

2015-10-27 Thread Guennadi Liakhovetski
Hi Robert,

Didn't you tell me, that your dmaengine patch got rejected and therefore 
these your patches were on hold?

Thanks
Guennadi

On Sat, 24 Oct 2015, Robert Jarzmik wrote:

> Robert Jarzmik  writes:
> 
> > Fix the error path where the video buffer wasn't allocated nor
> > mapped. In this case, in the driver free path don't try to unmap memory
> > which was not mapped in the first place.
> >
> > Signed-off-by: Robert Jarzmik 
> > ---
> > Since v3: take into account the 2 paths possibilities to free_buffer()
> Okay Guennadi, it's been enough time.
> Could you you have another look at this serie please ?
> 
> Cheers.
> 
> --
> Robert
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 32/86] KVM: vmx: fix VPID is 0000H in non-root operation

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Wanpeng Li 

commit 04bb92e4b4cf06a66889d37b892b78f926faa9d4 upstream.

Reference SDM 28.1:

The current VPID is H in the following situations:
- Outside VMX operation. (This includes operation in system-management
  mode under the default treatment of SMIs and SMM with VMX operation;
  see Section 34.14.)
- In VMX root operation.
- In VMX non-root operation when the “enable VPID” VM-execution control
  is 0.

The VPID should never be H in non-root operation when "enable VPID"
VM-execution control is 1. However, commit 34a1cd60 ("kvm: x86: vmx:
move some vmx setting from vmx_init() to hardware_setup()") remove the
codes which reserve H for VMX root operation.

This patch fix it by again reserving H for VMX root operation.

Fixes: 34a1cd60d17f62c1f077c1478a6c2ca8c3d17af4
Reported-by: Wincy Van 
Signed-off-by: Wanpeng Li 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/kvm/vmx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index bde6bd1..ba2ba0f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5918,6 +5918,8 @@ static __init int hardware_setup(void)
memcpy(vmx_msr_bitmap_longmode_x2apic,
vmx_msr_bitmap_longmode, PAGE_SIZE);
 
+   set_bit(0, vmx_vpid_bitmap); /* 0 is reserved for host */
+
if (enable_apicv) {
for (msr = 0x800; msr <= 0x8ff; msr++)
vmx_disable_intercept_msr_read_x2apic(msr);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 31/86] powerpc/mm: Recompute hash value after a failed update

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Aneesh Kumar K.V" 

commit 36b35d5d807b7e57aff7d08e63de8b17731ee211 upstream.

If we had secondary hash flag set, we ended up modifying hash value in
the updatepp code path. Hence with a failed updatepp we will be using
a wrong hash value for the following hash insert. Fix this by
recomputing hash before insert.

Without this patch we can end up with using wrong slot number in linux
pte. That can result in us missing an hash pte update or invalidate
which can cause memory corruption or even machine check.

Fixes: 6d492ecc6489 ("powerpc/THP: Add code to handle HPTE faults for 
hugepages")
Signed-off-by: Aneesh Kumar K.V 
Reviewed-by: Paul Mackerras 
Signed-off-by: Michael Ellerman 
Signed-off-by: Kamal Mostafa 
---
 arch/powerpc/mm/hugepage-hash64.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/hugepage-hash64.c 
b/arch/powerpc/mm/hugepage-hash64.c
index 8668651..79cd39f 100644
--- a/arch/powerpc/mm/hugepage-hash64.c
+++ b/arch/powerpc/mm/hugepage-hash64.c
@@ -85,7 +85,6 @@ int __hash_page_thp(unsigned long ea, unsigned long access, 
unsigned long vsid,
BUG_ON(index >= 4096);
 
vpn = hpt_vpn(ea, vsid, ssize);
-   hash = hpt_hash(vpn, shift, ssize);
hpte_slot_array = get_hpte_slot_array(pmdp);
if (psize == MMU_PAGE_4K) {
/*
@@ -101,6 +100,7 @@ int __hash_page_thp(unsigned long ea, unsigned long access, 
unsigned long vsid,
valid = hpte_valid(hpte_slot_array, index);
if (valid) {
/* update the hpte bits */
+   hash = hpt_hash(vpn, shift, ssize);
hidx =  hpte_hash_index(hpte_slot_array, index);
if (hidx & _PTEIDX_SECONDARY)
hash = ~hash;
@@ -126,6 +126,7 @@ int __hash_page_thp(unsigned long ea, unsigned long access, 
unsigned long vsid,
if (!valid) {
unsigned long hpte_group;
 
+   hash = hpt_hash(vpn, shift, ssize);
/* insert new entry */
pa = pmd_pfn(__pmd(old_pmd)) << PAGE_SHIFT;
new_pmd |= _PAGE_HASHPTE;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 33/86] arm: KVM: Fix incorrect device to IPA mapping

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Marek Majtyka 

commit ca09f02f122b2ecb0f5ddfc5fd47b29ed657d4fd upstream.

A critical bug has been found in device memory stage1 translation for
VMs with more then 4GB of address space. Once vm_pgoff size is smaller
then pa (which is true for LPAE case, u32 and u64 respectively) some
more significant bits of pa may be lost as a shift operation is performed
on u32 and later cast onto u64.

Example: vm_pgoff(u32)=0x00210030, PAGE_SHIFT=12
expected pa(u64):   0x00201003
produced pa(u64):   0x1003

The fix is to change the order of operations (casting first onto phys_addr_t
and then shifting).

Reviewed-by: Marc Zyngier 
[maz: fixed changelog and patch formatting]
Signed-off-by: Marek Majtyka 
Signed-off-by: Marc Zyngier 

Signed-off-by: Kamal Mostafa 
---
 arch/arm/kvm/mmu.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 9ec6dfe..0512ed4 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1439,8 +1439,10 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
if (vma->vm_flags & VM_PFNMAP) {
gpa_t gpa = mem->guest_phys_addr +
(vm_start - mem->userspace_addr);
-   phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) +
-vm_start - vma->vm_start;
+   phys_addr_t pa;
+
+   pa = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
+   pa += vm_start - vma->vm_start;
 
ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
vm_end - vm_start,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 26/86] net: mvneta: fix DMA buffer unmapping in mvneta_rx()

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Simon Guinot 

commit daf158d0d544cec80b7b30deff8cfc59a6e17610 upstream.

This patch fixes a regression introduced by the commit a84e32894191
("net: mvneta: fix refilling for Rx DMA buffers"). Due to this commit
the newly allocated Rx buffers are DMA-unmapped in place of those passed
to the networking stack. Obviously, this causes data corruptions.

This patch fixes the issue by ensuring that the right Rx buffers are
DMA-unmapped.

Reported-by: Oren Laskin 
Signed-off-by: Simon Guinot 
Fixes: a84e32894191 ("net: mvneta: fix refilling for Rx DMA buffers")
Tested-by: Oren Laskin 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 drivers/net/ethernet/marvell/mvneta.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index fab4757..f8a081a 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1452,6 +1452,7 @@ static int mvneta_rx(struct mvneta_port *pp, int rx_todo,
struct mvneta_rx_desc *rx_desc = mvneta_rxq_next_desc_get(rxq);
struct sk_buff *skb;
unsigned char *data;
+   dma_addr_t phys_addr;
u32 rx_status;
int rx_bytes, err;
 
@@ -1459,6 +1460,7 @@ static int mvneta_rx(struct mvneta_port *pp, int rx_todo,
rx_status = rx_desc->status;
rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
data = (unsigned char *)rx_desc->buf_cookie;
+   phys_addr = rx_desc->buf_phys_addr;
 
if (!mvneta_rxq_desc_is_first_last(rx_status) ||
(rx_status & MVNETA_RXD_ERR_SUMMARY)) {
@@ -1507,7 +1509,7 @@ static int mvneta_rx(struct mvneta_port *pp, int rx_todo,
if (!skb)
goto err_drop_frame;
 
-   dma_unmap_single(dev->dev.parent, rx_desc->buf_phys_addr,
+   dma_unmap_single(dev->dev.parent, phys_addr,
 MVNETA_RX_BUF_SIZE(pp->pkt_size), 
DMA_FROM_DEVICE);
 
rcvd_pkts++;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 15/86] x86/apic: Serialize LVTT and TSC_DEADLINE writes

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Shaohua Li 

commit 5d7c631d926b59aa16f3c56eaeb83f1036c81dc7 upstream.

The APIC LVTT register is MMIO mapped but the TSC_DEADLINE register is an
MSR. The write to the TSC_DEADLINE MSR is not serializing, so it's not
guaranteed that the write to LVTT has reached the APIC before the
TSC_DEADLINE MSR is written. In such a case the write to the MSR is
ignored and as a consequence the local timer interrupt never fires.

The SDM decribes this issue for xAPIC and x2APIC modes. The
serialization methods recommended by the SDM differ.

xAPIC:
 "1. Memory-mapped write to LVT Timer Register, setting bits 18:17 to 10b.
  2. WRMSR to the IA32_TSC_DEADLINE MSR a value much larger than current 
time-stamp counter.
  3. If RDMSR of the IA32_TSC_DEADLINE MSR returns zero, go to step 2.
  4. WRMSR to the IA32_TSC_DEADLINE MSR the desired deadline."

x2APIC:
 "To allow for efficient access to the APIC registers in x2APIC mode,
  the serializing semantics of WRMSR are relaxed when writing to the
  APIC registers. Thus, system software should not use 'WRMSR to APIC
  registers in x2APIC mode' as a serializing instruction. Read and write
  accesses to the APIC registers will occur in program order. A WRMSR to
  an APIC register may complete before all preceding stores are globally
  visible; software can prevent this by inserting a serializing
  instruction, an SFENCE, or an MFENCE before the WRMSR."

The xAPIC method is to just wait for the memory mapped write to hit
the LVTT by checking whether the MSR write has reached the hardware.
There is no reason why a proper MFENCE after the memory mapped write would
not do the same. Andi Kleen confirmed that MFENCE is sufficient for the
xAPIC case as well.

Issue MFENCE before writing to the TSC_DEADLINE MSR. This can be done
unconditionally as all CPUs which have TSC_DEADLINE also have MFENCE
support.

[ tglx: Massaged the changelog ]

Signed-off-by: Shaohua Li 
Reviewed-by: Ingo Molnar 
Cc: 
Cc: 
Cc: 
Cc: Andi Kleen 
Cc: H. Peter Anvin 
Link: 
http://lkml.kernel.org/r/20150909041352.ga2059...@devbig257.prn2.facebook.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/kernel/apic/apic.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 29b5b18..c803cda 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -366,6 +366,13 @@ static void __setup_APIC_LVTT(unsigned int clocks, int 
oneshot, int irqen)
apic_write(APIC_LVTT, lvtt_value);
 
if (lvtt_value & APIC_LVT_TIMER_TSCDEADLINE) {
+   /*
+* See Intel SDM: TSC-Deadline Mode chapter. In xAPIC mode,
+* writing to the APIC LVTT and TSC_DEADLINE MSR isn't 
serialized.
+* According to Intel, MFENCE can do the serialization here.
+*/
+   asm volatile("mfence" : : : "memory");
+
printk_once(KERN_DEBUG "TSC deadline timer enabled\n");
return;
}
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 25/86] kvm: fix zero length mmio searching

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jason Wang 

commit 8f4216c7d28976f7ec1b2bcbfa0a9f787133c45e upstream.

Currently, if we had a zero length mmio eventfd assigned on
KVM_MMIO_BUS. It will never be found by kvm_io_bus_cmp() since it
always compares the kvm_io_range() with the length that guest
wrote. This will cause e.g for vhost, kick will be trapped by qemu
userspace instead of vhost. Fixing this by using zero length if an
iodevice is zero length.

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Jason Wang 
Reviewed-by: Cornelia Huck 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Kamal Mostafa 
---
 virt/kvm/kvm_main.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 0edccc8f..ce5ab83 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2871,10 +2871,25 @@ static void kvm_io_bus_destroy(struct kvm_io_bus *bus)
 static inline int kvm_io_bus_cmp(const struct kvm_io_range *r1,
  const struct kvm_io_range *r2)
 {
-   if (r1->addr < r2->addr)
+   gpa_t addr1 = r1->addr;
+   gpa_t addr2 = r2->addr;
+
+   if (addr1 < addr2)
return -1;
-   if (r1->addr + r1->len > r2->addr + r2->len)
+
+   /* If r2->len == 0, match the exact address.  If r2->len != 0,
+* accept any overlapping write.  Any order is acceptable for
+* overlapping ranges, because kvm_io_bus_get_first_dev ensures
+* we process all of them.
+*/
+   if (r2->len) {
+   addr1 += r1->len;
+   addr2 += r2->len;
+   }
+
+   if (addr1 > addr2)
return 1;
+
return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 29/86] ARM: fix Thumb2 signal handling when ARMv6 is enabled

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Russell King 

commit 9b55613f42e8d40d5c9ccb8970bde6af4764b2ab upstream.

When a kernel is built covering ARMv6 to ARMv7, we omit to clear the
IT state when entering a signal handler.  This can cause the first
few instructions to be conditionally executed depending on the parent
context.

In any case, the original test for >= ARMv7 is broken - ARMv6 can have
Thumb-2 support as well, and an ARMv6T2 specific build would omit this
code too.

Relax the test back to ARMv6 or greater.  This results in us always
clearing the IT state bits in the PSR, even on CPUs where these bits
are reserved.  However, they're reserved for the IT state, so this
should cause no harm.

Fixes: d71e1352e240 ("Clear the IT state when invoking a Thumb-2 signal 
handler")
Acked-by: Tony Lindgren 
Tested-by: H. Nikolaus Schaller 
Tested-by: Grazvydas Ignotas 
Signed-off-by: Russell King 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/kernel/signal.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index 8aa6f1b..a0d42f9 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -354,12 +354,17 @@ setup_return(struct pt_regs *regs, struct ksignal *ksig,
 */
thumb = handler & 1;
 
-#if __LINUX_ARM_ARCH__ >= 7
+#if __LINUX_ARM_ARCH__ >= 6
/*
-* Clear the If-Then Thumb-2 execution state
-* ARM spec requires this to be all 000s in ARM mode
-* Snapdragon S4/Krait misbehaves on a Thumb=>ARM
-* signal transition without this.
+* Clear the If-Then Thumb-2 execution state.  ARM spec
+* requires this to be all 000s in ARM mode.  Snapdragon
+* S4/Krait misbehaves on a Thumb=>ARM signal transition
+* without this.
+*
+* We must do this whenever we are running on a Thumb-2
+* capable CPU, which includes ARMv6T2.  However, we elect
+* to do this whenever we're on an ARMv6 or later CPU for
+* simplicity.
 */
cpsr &= ~PSR_IT_MASK;
 #endif
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 28/86] iser-target: Put the reference on commands waiting for unsol data

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jenny Derzhavetz 

commit 3e03c4b01da3e6a5f3081eb0aa252490fe83e352 upstream.

The iscsi target core teardown sequence calls wait_conn for
all active commands to finish gracefully by:
- move the queue-pair to error state
- drain all the completions
- wait for the core to finish handling all session commands

However, when tearing down a session while there are sequenced
commands that are still waiting for unsolicited data outs, we can
block forever as these are missing an extra reference put.

We basically need the equivalent of iscsit_free_queue_reqs_for_conn()
which is called after wait_conn has returned. Address this by an
explicit walk on conn_cmd_list and put the extra reference.

Signed-off-by: Jenny Derzhavetz 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Kamal Mostafa 
---
 drivers/infiniband/ulp/isert/ib_isert.c | 38 -
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/ulp/isert/ib_isert.c 
b/drivers/infiniband/ulp/isert/ib_isert.c
index aee23d9..46563f1 100644
--- a/drivers/infiniband/ulp/isert/ib_isert.c
+++ b/drivers/infiniband/ulp/isert/ib_isert.c
@@ -3294,6 +3294,41 @@ isert_wait4flush(struct isert_conn *isert_conn)
wait_for_completion(&isert_conn->conn_wait_comp_err);
 }
 
+/**
+ * isert_put_unsol_pending_cmds() - Drop commands waiting for
+ * unsolicitate dataout
+ * @conn:iscsi connection
+ *
+ * We might still have commands that are waiting for unsolicited
+ * dataouts messages. We must put the extra reference on those
+ * before blocking on the target_wait_for_session_cmds
+ */
+static void
+isert_put_unsol_pending_cmds(struct iscsi_conn *conn)
+{
+   struct iscsi_cmd *cmd, *tmp;
+   static LIST_HEAD(drop_cmd_list);
+
+   spin_lock_bh(&conn->cmd_lock);
+   list_for_each_entry_safe(cmd, tmp, &conn->conn_cmd_list, i_conn_node) {
+   if ((cmd->cmd_flags & ICF_NON_IMMEDIATE_UNSOLICITED_DATA) &&
+   (cmd->write_data_done < 
conn->sess->sess_ops->FirstBurstLength) &&
+   (cmd->write_data_done < cmd->se_cmd.data_length))
+   list_move_tail(&cmd->i_conn_node, &drop_cmd_list);
+   }
+   spin_unlock_bh(&conn->cmd_lock);
+
+   list_for_each_entry_safe(cmd, tmp, &drop_cmd_list, i_conn_node) {
+   list_del_init(&cmd->i_conn_node);
+   if (cmd->i_state != ISTATE_REMOVE) {
+   struct isert_cmd *isert_cmd = iscsit_priv_cmd(cmd);
+
+   isert_info("conn %p dropping cmd %p\n", conn, cmd);
+   isert_put_cmd(isert_cmd, true);
+   }
+   }
+}
+
 static void isert_wait_conn(struct iscsi_conn *conn)
 {
struct isert_conn *isert_conn = conn->context;
@@ -3312,8 +3347,9 @@ static void isert_wait_conn(struct iscsi_conn *conn)
isert_conn_terminate(isert_conn);
mutex_unlock(&isert_conn->conn_mutex);
 
-   isert_wait4cmds(conn);
isert_wait4flush(isert_conn);
+   isert_put_unsol_pending_cmds(conn);
+   isert_wait4cmds(conn);
isert_wait4logout(isert_conn);
 
queue_work(isert_release_wq, &isert_conn->release_work);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 21/86] arm64: head.S: initialise mdcr_el2 in el2_setup

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Will Deacon 

commit d10bcd473301888f957ec4b6b12aa3621be78d59 upstream.

When entering the kernel at EL2, we fail to initialise the MDCR_EL2
register which controls debug access and PMU capabilities at EL1.

This patch ensures that the register is initialised so that all traps
are disabled and all the PMU counters are available to the host. When a
guest is scheduled, KVM takes care to configure trapping appropriately.

Acked-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Kamal Mostafa 
---
 arch/arm64/kernel/head.S | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 98af7da..f985fc5 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -545,6 +545,11 @@ CPU_LE(movkx0, #0x30d0, lsl #16)   // 
Clear EE and E0E on LE systems
msr hstr_el2, xzr   // Disable CP15 traps to EL2
 #endif
 
+   /* EL2 debug */
+   mrs x0, pmcr_el0// Disable debug access traps
+   ubfxx0, x0, #11, #5 // to EL2 and allow access to
+   msr mdcr_el2, x0// all PMU counters from EL1
+
/* Stage-2 translation */
msr vttbr_el2, xzr
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 16/86] ARM: dts: omap3-beagle: make i2c3, ddc and tfp410 gpio work again

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Carl Frederik Werner 

commit 3a2fa775bd1d0579113666c1a2e37654a34018a0 upstream.

Let's fix pinmux address of gpio 170 used by tfp410 powerdown-gpio.

According to the OMAP35x Technical Reference Manual
  CONTROL_PADCONF_I2C3_SDA[15:0]  0x480021C4 mode0: i2c3_sda
  CONTROL_PADCONF_I2C3_SDA[31:16] 0x480021C4 mode4: gpio_170
the pinmux address of gpio 170 must be 0x480021C6.

The former wrong address broke i2c3 (used by hdmi ddc), resulting in
kernel message:
  omap_i2c 4806.i2c: controller timed out

Fixes: 8cecf52befd7 ("ARM: omap3-beagle.dts: add display information")
Signed-off-by: Carl Frederik Werner 
Signed-off-by: Tony Lindgren 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/boot/dts/omap3-beagle.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index c792391..cbcbc8a 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -204,7 +204,7 @@
 
tfp410_pins: pinmux_tfp410_pins {
pinctrl-single,pins = <
-   0x194 (PIN_OUTPUT | MUX_MODE4)  /* hdq_sio.gpio_170 */
+   0x196 (PIN_OUTPUT | MUX_MODE4)  /* hdq_sio.gpio_170 */
>;
};
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 20/86] cxl: Fix unbalanced pci_dev_get in cxl_probe

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Daniel Axtens 

commit 2925c2fdf1e0eb642482f5b30577e9435aaa8edb upstream.

Currently the first thing we do in cxl_probe is to grab a reference
on the pci device. Later on, we call device_register on our adapter.
In our remove path, we call device_unregister, but we never call
pci_dev_put. We therefore leak the device every time we do a
reflash.

device_register/unregister is sufficient to hold the reference.
Therefore, drop the call to pci_dev_get.

Here's why this is safe.
The proposed cxl_probe(pdev) calls cxl_adapter_init:
a) init calls cxl_adapter_alloc, which creates a struct cxl,
   conventionally called adapter. This struct contains a
   device entry, adapter->dev.

b) init calls cxl_configure_adapter, where we set
   adapter->dev.parent = &dev->dev (here dev is the pci dev)

So at this point, the cxl adapter's device's parent is the PCI
device that I want to be refcounted properly.

c) init calls cxl_register_adapter
   *) cxl_register_adapter calls device_register(&adapter->dev)

So now we're in device_register, where dev is the adapter device, and
we want to know if the PCI device is safe after we return.

device_register(&adapter->dev) calls device_initialize() and then
device_add().

device_add() does a get_device(). device_add() also explicitly grabs
the device's parent, and calls get_device() on it:

 parent = get_device(dev->parent);

So therefore, device_register() takes a lock on the parent PCI dev,
which is what pci_dev_get() was guarding. pci_dev_get() can therefore
be safely removed.

Fixes: f204e0b8cedd ("cxl: Driver code for powernv PCIe based cards for 
userspace access")
Signed-off-by: Daniel Axtens 
Acked-by: Ian Munsie 
Signed-off-by: Michael Ellerman 
Signed-off-by: Kamal Mostafa 
---
 drivers/misc/cxl/pci.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index eee4fd6..cc55691 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -987,8 +987,6 @@ static int cxl_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
int slice;
int rc;
 
-   pci_dev_get(dev);
-
if (cxl_verbose)
dump_cxl_config_space(dev);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 27/86] iser-target: remove command with state ISTATE_REMOVE

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jenny Derzhavetz 

commit a4c15cd957cbd728f685645de7a150df5912591a upstream.

As documented in iscsit_sequence_cmd:
/*
 * Existing callers for iscsit_sequence_cmd() will silently
 * ignore commands with CMDSN_LOWER_THAN_EXP, so force this
 * return for CMDSN_MAXCMDSN_OVERRUN as well..
 */

We need to silently finish a command when it's in ISTATE_REMOVE.
This fixes an teardown hang we were seeing where a mis-behaved
initiator (triggered by allocation error injections) sent us a
cmdsn which was lower than expected.

Signed-off-by: Jenny Derzhavetz 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Kamal Mostafa 
---
 drivers/infiniband/ulp/isert/ib_isert.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/ulp/isert/ib_isert.c 
b/drivers/infiniband/ulp/isert/ib_isert.c
index b7350d5..aee23d9 100644
--- a/drivers/infiniband/ulp/isert/ib_isert.c
+++ b/drivers/infiniband/ulp/isert/ib_isert.c
@@ -2918,9 +2918,16 @@ isert_get_dataout(struct iscsi_conn *conn, struct 
iscsi_cmd *cmd, bool recovery)
 static int
 isert_immediate_queue(struct iscsi_conn *conn, struct iscsi_cmd *cmd, int 
state)
 {
-   int ret;
+   struct isert_cmd *isert_cmd = iscsit_priv_cmd(cmd);
+   int ret = 0;
 
switch (state) {
+   case ISTATE_REMOVE:
+   spin_lock_bh(&conn->cmd_lock);
+   list_del_init(&cmd->i_conn_node);
+   spin_unlock_bh(&conn->cmd_lock);
+   isert_put_cmd(isert_cmd, true);
+   break;
case ISTATE_SEND_NOPIN_WANT_RESPONSE:
ret = isert_put_nopin(cmd, conn, false);
break;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 17/86] Btrfs: fix read corruption of compressed and shared extents

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Filipe Manana 

commit 005efedf2c7d0a270ffbe28d8997b03844f3e3e7 upstream.

If a file has a range pointing to a compressed extent, followed by
another range that points to the same compressed extent and a read
operation attempts to read both ranges (either completely or part of
them), the pages that correspond to the second range are incorrectly
filled with zeroes.

Consider the following example:

  File layout
  [0 - 8K]  [8K - 24K]
  | |
  | |
   points to extent X, points to extent X,
   offset 4K, length of 8K offset 0, length 16K

  [extent X, compressed length = 4K uncompressed length = 16K]

If a readpages() call spans the 2 ranges, a single bio to read the extent
is submitted - extent_io.c:submit_extent_page() would only create a new
bio to cover the second range pointing to the extent if the extent it
points to had a different logical address than the extent associated with
the first range. This has a consequence of the compressed read end io
handler (compression.c:end_compressed_bio_read()) finish once the extent
is decompressed into the pages covering the first range, leaving the
remaining pages (belonging to the second range) filled with zeroes (done
by compression.c:btrfs_clear_biovec_end()).

So fix this by submitting the current bio whenever we find a range
pointing to a compressed extent that was preceded by a range with a
different extent map. This is the simplest solution for this corner
case. Making the end io callback populate both ranges (or more, if we
have multiple pointing to the same extent) is a much more complex
solution since each bio is tightly coupled with a single extent map and
the extent maps associated to the ranges pointing to the shared extent
can have different offsets and lengths.

The following test case for fstests triggers the issue:

  seq=`basename $0`
  seqres=$RESULT_DIR/$seq
  echo "QA output created by $seq"
  tmp=/tmp/$$
  status=1  # failure is the default!
  trap "_cleanup; exit \$status" 0 1 2 3 15

  _cleanup()
  {
  rm -f $tmp.*
  }

  # get standard environment, filters and checks
  . ./common/rc
  . ./common/filter

  # real QA test starts here
  _need_to_be_root
  _supported_fs btrfs
  _supported_os Linux
  _require_scratch
  _require_cloner

  rm -f $seqres.full

  test_clone_and_read_compressed_extent()
  {
  local mount_opts=$1

  _scratch_mkfs >>$seqres.full 2>&1
  _scratch_mount $mount_opts

  # Create a test file with a single extent that is compressed (the
  # data we write into it is highly compressible no matter which
  # compression algorithm is used, zlib or lzo).
  $XFS_IO_PROG -f -c "pwrite -S 0xaa 0K 4K"\
  -c "pwrite -S 0xbb 4K 8K"\
  -c "pwrite -S 0xcc 12K 4K"   \
  $SCRATCH_MNT/foo | _filter_xfs_io

  # Now clone our extent into an adjacent offset.
  $CLONER_PROG -s $((4 * 1024)) -d $((16 * 1024)) -l $((8 * 1024)) \
  $SCRATCH_MNT/foo $SCRATCH_MNT/foo

  # Same as before but for this file we clone the extent into a lower
  # file offset.
  $XFS_IO_PROG -f -c "pwrite -S 0xaa 8K 4K" \
  -c "pwrite -S 0xbb 12K 8K"\
  -c "pwrite -S 0xcc 20K 4K"\
  $SCRATCH_MNT/bar | _filter_xfs_io

  $CLONER_PROG -s $((12 * 1024)) -d 0 -l $((8 * 1024)) \
  $SCRATCH_MNT/bar $SCRATCH_MNT/bar

  echo "File digests before unmounting filesystem:"
  md5sum $SCRATCH_MNT/foo | _filter_scratch
  md5sum $SCRATCH_MNT/bar | _filter_scratch

  # Evicting the inode or clearing the page cache before reading
  # again the file would also trigger the bug - reads were returning
  # all bytes in the range corresponding to the second reference to
  # the extent with a value of 0, but the correct data was persisted
  # (it was a bug exclusively in the read path). The issue happened
  # only if the same readpages() call targeted pages belonging to the
  # first and second ranges that point to the same compressed extent.
  _scratch_remount

  echo "File digests after mounting filesystem again:"
  # Must match the same digests we got before.
  md5sum $SCRATCH_MNT/foo | _filter_scratch
  md5sum $SCRATCH_MNT/bar | _filter_scratch
  }

  echo -e "\nTesting with zlib compression..."
  test_clone_and_read_compressed_extent "-o compress=zlib"

  _scratch_unmount

  echo -e "\nTesting with lzo compression..."
  test_clone_and_read_compressed_extent "-o compress=lzo"

  status=0
  exit

Signed-off-by: Filipe Manana 
Reviewed-by: Qu Wenruo
Reviewed-by: Liu Bo 
Signed-off-by: Kamal Mostafa 
---
 fs/btrfs/extent_io.c | 65 +---
 1 file changed,

[PATCH 3.19.y-ckt 24/86] kvm: fix double free for fast mmio eventfd

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jason Wang 

commit eefd6b06b17c5478e7c24bea6f64beaa2c431ca6 upstream.

We register wildcard mmio eventfd on two buses, once for KVM_MMIO_BUS
and once on KVM_FAST_MMIO_BUS but with a single iodev
instance. This will lead to an issue: kvm_io_bus_destroy() knows
nothing about the devices on two buses pointing to a single dev. Which
will lead to double free[1] during exit. Fix this by allocating two
instances of iodevs then registering one on KVM_MMIO_BUS and another
on KVM_FAST_MMIO_BUS.

CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic #28-Ubuntu
Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 ) 09/12/2013
task: 88009ae0c4b0 ti: 88020e7f task.ti: 88020e7f
RIP: 0010:[]  [] 
ioeventfd_release+0x28/0x60 [kvm]
RSP: 0018:88020e7f3bc8  EFLAGS: 00010292
RAX: dead00200200 RBX: 8801ec19c900 RCX: 00018200016d
RDX: 8801ec19cf80 RSI: ea0008bf1d40 RDI: 8801ec19c900
RBP: 88020e7f3bd8 R08: 2fc75a01 R09: 00018200016d
R10: c07df6ae R11: 88022fc75a98 R12: 88021e7cc000
R13: 88021e7cca48 R14: 88021e7cca50 R15: 8801ec19c880
FS:  7fc1ee3e6700() GS:88023e24() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f8f389d8000 CR3: 00023dc13000 CR4: 001427e0
Stack:
88021e7cc000  88020e7f3be8 c07e2622
88020e7f3c38 c07df69a 880232524160 88020e792d80
  880219b78c00 0008 8802321686a8
Call Trace:
[] ioeventfd_destructor+0x12/0x20 [kvm]
[] kvm_put_kvm+0xca/0x210 [kvm]
[] kvm_vcpu_release+0x18/0x20 [kvm]
[] __fput+0xe7/0x250
[] fput+0xe/0x10
[] task_work_run+0xd4/0xf0
[] do_exit+0x368/0xa50
[] ? recalc_sigpending+0x1f/0x60
[] do_group_exit+0x45/0xb0
[] get_signal+0x291/0x750
[] do_signal+0x28/0xab0
[] ? do_futex+0xdb/0x5d0
[] ? __wake_up_locked_key+0x18/0x20
[] ? SyS_futex+0x76/0x170
[] do_notify_resume+0x69/0xb0
[] int_signal+0x12/0x17
Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 8b 7f 20 
e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08 <48> 89 10 48 b8 00 01 
10 00 00
 RIP  [] ioeventfd_release+0x28/0x60 [kvm]
 RSP 

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Jason Wang 
Reviewed-by: Cornelia Huck 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Kamal Mostafa 
---
 virt/kvm/eventfd.c | 43 +--
 1 file changed, 25 insertions(+), 18 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 642e1d0..1280096 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -814,16 +814,6 @@ static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
if (ret < 0)
goto unlock_fail;
 
-   /* When length is ignored, MMIO is also put on a separate bus, for
-* faster lookups.
-*/
-   if (!args->len && bus_idx == KVM_MMIO_BUS) {
-   ret = kvm_io_bus_register_dev(kvm, KVM_FAST_MMIO_BUS,
- p->addr, 0, &p->dev);
-   if (ret < 0)
-   goto register_fail;
-   }
-
kvm->buses[bus_idx]->ioeventfd_count++;
list_add_tail(&p->list, &kvm->ioeventfds);
 
@@ -831,8 +821,6 @@ static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
 
return 0;
 
-register_fail:
-   kvm_io_bus_unregister_dev(kvm, bus_idx, &p->dev);
 unlock_fail:
mutex_unlock(&kvm->slots_lock);
 
@@ -871,10 +859,6 @@ kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus 
bus_idx,
continue;
 
kvm_io_bus_unregister_dev(kvm, bus_idx, &p->dev);
-   if (!p->length && p->bus_idx == KVM_MMIO_BUS) {
-   kvm_io_bus_unregister_dev(kvm, KVM_FAST_MMIO_BUS,
- &p->dev);
-   }
kvm->buses[bus_idx]->ioeventfd_count--;
ioeventfd_release(p);
ret = 0;
@@ -891,14 +875,19 @@ kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus 
bus_idx,
 static int kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
 {
enum kvm_bus bus_idx = ioeventfd_bus_from_flags(args->flags);
+   int ret = kvm_deassign_ioeventfd_idx(kvm, bus_idx, args);
+
+   if (!args->len && bus_idx == KVM_MMIO_BUS)
+   kvm_deassign_ioeventfd_idx(kvm, KVM_FAST_MMIO_BUS, args);
 
-   return kvm_deassign_ioeventfd_idx(kvm, bus_idx, args);
+   return ret;
 }
 
 static int
 kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
 {
enum kvm_bus  bus_idx;
+   int ret;
 
bus_idx = ioeventfd_bus_from_flags(args->flags);
/* must be natural-word sized, or 0 to ignore length */
@@ -927,7 +916,25 @@ kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd 
*args

[PATCH 3.19.y-ckt 12/86] USB: option: add ZTE PIDs

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: "Liu.Zhao" 

commit 19ab6bc5674a30fdb6a2436b068d19a3c17dc73e upstream.

This is intended to add ZTE device PIDs on kernel.

Signed-off-by: Liu.Zhao 
[johan: sort the new entries ]
Signed-off-by: Johan Hovold 
Signed-off-by: Kamal Mostafa 
---
 drivers/usb/serial/option.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 463feb8..17d04d9 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -278,6 +278,10 @@ static void option_instat_callback(struct urb *urb);
 #define ZTE_PRODUCT_MF622  0x0001
 #define ZTE_PRODUCT_MF628  0x0015
 #define ZTE_PRODUCT_MF626  0x0031
+#define ZTE_PRODUCT_ZM8620_X   0x0396
+#define ZTE_PRODUCT_ME3620_MBIM0x0426
+#define ZTE_PRODUCT_ME3620_X   0x1432
+#define ZTE_PRODUCT_ME3620_L   0x1433
 #define ZTE_PRODUCT_AC2726 0xfff1
 #define ZTE_PRODUCT_MG880  0xfffd
 #define ZTE_PRODUCT_CDMA_TECH  0xfffe
@@ -552,6 +556,18 @@ static const struct option_blacklist_info 
zte_mc2716_z_blacklist = {
.sendsetup = BIT(1) | BIT(2) | BIT(3),
 };
 
+static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
+   .reserved = BIT(2) | BIT(3) | BIT(4),
+};
+
+static const struct option_blacklist_info zte_me3620_xl_blacklist = {
+   .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_zm8620_x_blacklist = {
+   .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
 static const struct option_blacklist_info huawei_cdc12_blacklist = {
.reserved = BIT(1) | BIT(2),
 };
@@ -1599,6 +1615,14 @@ static const struct usb_device_id option_ids[] = {
 .driver_info = (kernel_ulong_t)&zte_ad3812_z_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2716, 
0xff, 0xff, 0xff),
 .driver_info = (kernel_ulong_t)&zte_mc2716_z_blacklist },
+   { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L),
+.driver_info = (kernel_ulong_t)&zte_me3620_xl_blacklist },
+   { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM),
+.driver_info = (kernel_ulong_t)&zte_me3620_mbim_blacklist },
+   { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X),
+.driver_info = (kernel_ulong_t)&zte_me3620_xl_blacklist },
+   { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X),
+.driver_info = (kernel_ulong_t)&zte_zm8620_x_blacklist },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) },
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 08/86] powerpc/MSI: Fix race condition in tearing down MSI interrupts

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Paul Mackerras 

commit e297c939b745e420ef0b9dc989cb87bda617b399 upstream.

This fixes a race which can result in the same virtual IRQ number
being assigned to two different MSI interrupts.  The most visible
consequence of that is usually a warning and stack trace from the
sysfs code about an attempt to create a duplicate entry in sysfs.

The race happens when one CPU (say CPU 0) is disposing of an MSI
while another CPU (say CPU 1) is setting up an MSI.  CPU 0 calls
(for example) pnv_teardown_msi_irqs(), which calls
msi_bitmap_free_hwirqs() to indicate that the MSI (i.e. its
hardware IRQ number) is no longer in use.  Then, before CPU 0 gets
to calling irq_dispose_mapping() to free up the virtal IRQ number,
CPU 1 comes in and calls msi_bitmap_alloc_hwirqs() to allocate an
MSI, and gets the same hardware IRQ number that CPU 0 just freed.
CPU 1 then calls irq_create_mapping() to get a virtual IRQ number,
which sees that there is currently a mapping for that hardware IRQ
number and returns the corresponding virtual IRQ number (which is
the same virtual IRQ number that CPU 0 was using).  CPU 0 then
calls irq_dispose_mapping() and frees that virtual IRQ number.
Now, if another CPU comes along and calls irq_create_mapping(), it
is likely to get the virtual IRQ number that was just freed,
resulting in the same virtual IRQ number apparently being used for
two different hardware interrupts.

To fix this race, we just move the call to msi_bitmap_free_hwirqs()
to after the call to irq_dispose_mapping().  Since virq_to_hw()
doesn't work for the virtual IRQ number after irq_dispose_mapping()
has been called, we need to call it before irq_dispose_mapping() and
remember the result for the msi_bitmap_free_hwirqs() call.

The pattern of calling msi_bitmap_free_hwirqs() before
irq_dispose_mapping() appears in 5 places under arch/powerpc, and
appears to have originated in commit 05af7bd2d75e ("[POWERPC] MPIC
U3/U4 MSI backend") from 2007.

Fixes: 05af7bd2d75e ("[POWERPC] MPIC U3/U4 MSI backend")
Reported-by: Alexey Kardashevskiy 
Signed-off-by: Paul Mackerras 
Signed-off-by: Michael Ellerman 
[ kamal: backport to 3.19-stable: pasemi/msi.c -->
  arch/powerpc/sysdev/mpic_pasemi_msi.c ]
Signed-off-by: Kamal Mostafa 
---
 arch/powerpc/platforms/powernv/pci.c  | 5 +++--
 arch/powerpc/sysdev/fsl_msi.c | 5 +++--
 arch/powerpc/sysdev/mpic_pasemi_msi.c | 5 +++--
 arch/powerpc/sysdev/mpic_u3msi.c  | 5 +++--
 arch/powerpc/sysdev/ppc4xx_msi.c  | 5 +++--
 5 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci.c 
b/arch/powerpc/platforms/powernv/pci.c
index 3948b8a..d35ec84 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -99,6 +99,7 @@ static void pnv_teardown_msi_irqs(struct pci_dev *pdev)
struct pci_controller *hose = pci_bus_to_host(pdev->bus);
struct pnv_phb *phb = hose->private_data;
struct msi_desc *entry;
+   irq_hw_number_t hwirq;
 
if (WARN_ON(!phb))
return;
@@ -106,10 +107,10 @@ static void pnv_teardown_msi_irqs(struct pci_dev *pdev)
list_for_each_entry(entry, &pdev->msi_list, list) {
if (entry->irq == NO_IRQ)
continue;
+   hwirq = virq_to_hw(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
-   msi_bitmap_free_hwirqs(&phb->msi_bmp,
-   virq_to_hw(entry->irq) - phb->msi_base, 1);
irq_dispose_mapping(entry->irq);
+   msi_bitmap_free_hwirqs(&phb->msi_bmp, hwirq - phb->msi_base, 1);
}
 }
 #endif /* CONFIG_PCI_MSI */
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 4bbb4b8..fd9fa2e 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -128,15 +128,16 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
 {
struct msi_desc *entry;
struct fsl_msi *msi_data;
+   irq_hw_number_t hwirq;
 
list_for_each_entry(entry, &pdev->msi_list, list) {
if (entry->irq == NO_IRQ)
continue;
+   hwirq = virq_to_hw(entry->irq);
msi_data = irq_get_chip_data(entry->irq);
irq_set_msi_desc(entry->irq, NULL);
-   msi_bitmap_free_hwirqs(&msi_data->bitmap,
-  virq_to_hw(entry->irq), 1);
irq_dispose_mapping(entry->irq);
+   msi_bitmap_free_hwirqs(&msi_data->bitmap, hwirq, 1);
}
 
return;
diff --git a/arch/powerpc/sysdev/mpic_pasemi_msi.c 
b/arch/powerpc/sysdev/mpic_pasemi_msi.c
index a3f660e..9e1da94 100644
--- a/arch/powerpc/sysdev/mpic_pasemi_msi.c
+++ b/arch/powerpc/sysdev/mpic_pasemi_msi.c
@@ -65,6 +65,7 @@ static struct irq_chip mpic_pasemi_msi_chip = {
 static void pasemi_msi_teardown_

[PATCH 3.19.y-ckt 14/86] KVM: arm64: add workaround for Cortex-A57 erratum #852523

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Will Deacon 

commit 43297dda0a51e4ffed0888ce727c218cfb7474b6 upstream.

When restoring the system register state for an AArch32 guest at EL2,
writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
which can lead to the guest effectively running with junk in the DACR
and running into unexpected domain faults.

This patch works around the issue by re-ordering our restoration of the
AArch32 register aliases so that they happen before the AArch64 system
registers. Ensuring that the registers are restored in this order
guarantees that they will be correctly synchronised by the core.

Reviewed-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Marc Zyngier 
Signed-off-by: Kamal Mostafa 
---
 arch/arm64/kvm/hyp.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index c3ca89c..cbaa8bc 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -946,13 +946,15 @@ ENTRY(__kvm_vcpu_run)
// Guest context
add x2, x0, #VCPU_CONTEXT
 
+   // We must restore the 32-bit state before the sysregs, thanks
+   // to Cortex-A57 erratum #852523.
+   restore_guest_32bit_state
bl __restore_sysregs
bl __restore_fpsimd
 
skip_debug_state x3, 1f
bl  __restore_debug
 1:
-   restore_guest_32bit_state
restore_guest_regs
 
// That's it, no more messing around.
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 01/86] sctp: donot reset the overall_error_count in SHUTDOWN_RECEIVE state

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: lucien 

commit f648f807f61e64d247d26611e34cc97e4ed03401 upstream.

Commit f8d960524328 ("sctp: Enforce retransmission limit during shutdown")
fixed a problem with excessive retransmissions in the SHUTDOWN_PENDING by not
resetting the association overall_error_count.  This allowed the association
to better enforce assoc.max_retrans limit.

However, the same issue still exists when the association is in 
SHUTDOWN_RECEIVED
state.  In this state, HB-ACKs will continue to reset the overall_error_count
for the association would extend the lifetime of association unnecessarily.

This patch solves this by resetting the overall_error_count whenever the current
state is small then SCTP_STATE_SHUTDOWN_PENDING.  As a small side-effect, we
end up also handling SCTP_STATE_SHUTDOWN_ACK_SENT and SCTP_STATE_SHUTDOWN_SENT
states, but they are not really impacted because we disable Heartbeats in those
states.

Fixes: Commit f8d960524328 ("sctp: Enforce retransmission limit during 
shutdown")
Signed-off-by: Xin Long 
Acked-by: Marcelo Ricardo Leitner 
Acked-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/sctp/sm_sideeffect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index fef2acd..85e6f03 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -702,7 +702,7 @@ static void sctp_cmd_transport_on(sctp_cmd_seq_t *cmds,
 * outstanding data and rely on the retransmission limit be reached
 * to shutdown the association.
 */
-   if (t->asoc->state != SCTP_STATE_SHUTDOWN_PENDING)
+   if (t->asoc->state < SCTP_STATE_SHUTDOWN_PENDING)
t->asoc->overall_error_count = 0;
 
/* Clear the hb_sent flag to signal that we had a good
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 06/86] spi: Fix documentation of spi_alloc_master()

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Guenter Roeck 

commit a394d635193b641f2c86ead5ada5b115d57c51f8 upstream.

Actually, spi_master_put() after spi_alloc_master() must _not_ be followed
by kfree(). The memory is already freed with the call to spi_master_put()
through spi_master_class, which registers a release function. Calling both
spi_master_put() and kfree() results in often nasty (and delayed) crashes
elsewhere in the kernel, often in the networking stack.

This reverts commit eb4af0f5349235df2e4a5057a72fc8962d00308a.

Link to patch and concerns: https://lkml.org/lkml/2012/9/3/269
or
http://lkml.iu.edu/hypermail/linux/kernel/1209.0/00790.html

Alexey Klimov: This revert becomes valid after
94c69f765f1b4a658d96905ec59928e3e3e07e6a when spi-imx.c
has been fixed and there is no need to call kfree() so comment
for spi_alloc_master() should be fixed.

Signed-off-by: Guenter Roeck 
Signed-off-by: Alexey Klimov 
Signed-off-by: Mark Brown 
Signed-off-by: Kamal Mostafa 
---
 drivers/spi/spi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index bfa47d5..2ebe805 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1492,8 +1492,7 @@ static struct class spi_master_class = {
  *
  * The caller is responsible for assigning the bus number and initializing
  * the master's methods before calling spi_register_master(); and (after errors
- * adding the device) calling spi_master_put() and kfree() to prevent a memory
- * leak.
+ * adding the device) calling spi_master_put() to prevent a memory leak.
  */
 struct spi_master *spi_alloc_master(struct device *dev, unsigned size)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 13/86] drm/vmwgfx: Fix up user_dmabuf refcounting

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Thomas Hellstrom 

commit 54c12bc374408faddbff75dbf1a6167c19af39c4 upstream.

If user space calls unreference on a user_dmabuf it will typically
kill the struct ttm_base_object member which is responsible for the
user-space visibility. However the dmabuf part may still be alive and
refcounted. In some situations, like for shared guest-backed surface
referencing/opening, the driver may try to reference the
struct ttm_base_object member again, causing an immediate kernel warning
and a later kernel NULL pointer dereference.

Fix this by always maintaining a reference on the struct
ttm_base_object member, in situations where it might subsequently be
referenced.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Kamal Mostafa 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |  6 --
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |  6 --
 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 29 +
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c   |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c  | 11 ---
 6 files changed, 39 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index d26a6da..d8896ed 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -636,7 +636,8 @@ extern int vmw_user_dmabuf_alloc(struct vmw_private 
*dev_priv,
 uint32_t size,
 bool shareable,
 uint32_t *handle,
-struct vmw_dma_buffer **p_dma_buf);
+struct vmw_dma_buffer **p_dma_buf,
+struct ttm_base_object **p_base);
 extern int vmw_user_dmabuf_reference(struct ttm_object_file *tfile,
 struct vmw_dma_buffer *dma_buf,
 uint32_t *handle);
@@ -650,7 +651,8 @@ extern uint32_t vmw_dmabuf_validate_node(struct 
ttm_buffer_object *bo,
 uint32_t cur_validate_node);
 extern void vmw_dmabuf_validate_clear(struct ttm_buffer_object *bo);
 extern int vmw_user_dmabuf_lookup(struct ttm_object_file *tfile,
- uint32_t id, struct vmw_dma_buffer **out);
+ uint32_t id, struct vmw_dma_buffer **out,
+ struct ttm_base_object **base);
 extern int vmw_stream_claim_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv);
 extern int vmw_stream_unref_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 2711b09..01b8423 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -887,7 +887,8 @@ static int vmw_translate_mob_ptr(struct vmw_private 
*dev_priv,
struct vmw_relocation *reloc;
int ret;
 
-   ret = vmw_user_dmabuf_lookup(sw_context->fp->tfile, handle, &vmw_bo);
+   ret = vmw_user_dmabuf_lookup(sw_context->fp->tfile, handle, &vmw_bo,
+NULL);
if (unlikely(ret != 0)) {
DRM_ERROR("Could not find or use MOB buffer.\n");
return -EINVAL;
@@ -948,7 +949,8 @@ static int vmw_translate_guest_ptr(struct vmw_private 
*dev_priv,
struct vmw_relocation *reloc;
int ret;
 
-   ret = vmw_user_dmabuf_lookup(sw_context->fp->tfile, handle, &vmw_bo);
+   ret = vmw_user_dmabuf_lookup(sw_context->fp->tfile, handle, &vmw_bo,
+NULL);
if (unlikely(ret != 0)) {
DRM_ERROR("Could not find or use GMR region.\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
index 87e39f6..e189898 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
@@ -484,7 +484,7 @@ int vmw_overlay_ioctl(struct drm_device *dev, void *data,
goto out_unlock;
}
 
-   ret = vmw_user_dmabuf_lookup(tfile, arg->handle, &buf);
+   ret = vmw_user_dmabuf_lookup(tfile, arg->handle, &buf, NULL);
if (ret)
goto out_unlock;
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 210ef15..c5b4c47 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -356,7 +356,7 @@ int vmw_user_lookup_handle(struct vmw_private *dev_priv,
}
 
*out_surf = NULL;
-   ret = vmw_user_dmabuf_lookup(tfile, handle, out_buf);
+   ret = vmw_user_dmabuf_lookup(tfile, handle, out_buf

[PATCH 3.19.y-ckt 09/86] CIFS: fix type confusion in copy offload ioctl

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Jann Horn 

commit 4c17a6d56bb0cad3066a714e94f7185a24b40f49 upstream.

This might lead to local privilege escalation (code execution as
kernel) for systems where the following conditions are met:

 - CONFIG_CIFS_SMB2 and CONFIG_CIFS_POSIX are enabled
 - a cifs filesystem is mounted where:
  - the mount option "vers" was used and set to a value >=2.0
  - the attacker has write access to at least one file on the filesystem

To attack this, an attacker would have to guess the target_tcon
pointer (but guessing wrong doesn't cause a crash, it just returns an
error code) and win a narrow race.

Signed-off-by: Jann Horn 
Signed-off-by: Steve French 
Signed-off-by: Kamal Mostafa 
---
 fs/cifs/ioctl.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/fs/cifs/ioctl.c b/fs/cifs/ioctl.c
index 8b7898b..64a9bca 100644
--- a/fs/cifs/ioctl.c
+++ b/fs/cifs/ioctl.c
@@ -67,6 +67,12 @@ static long cifs_ioctl_clone(unsigned int xid, struct file 
*dst_file,
goto out_drop_write;
}
 
+   if (src_file.file->f_op->unlocked_ioctl != cifs_ioctl) {
+   rc = -EBADF;
+   cifs_dbg(VFS, "src file seems to be from a different filesystem 
type\n");
+   goto out_fput;
+   }
+
if ((!src_file.file->private_data) || (!dst_file->private_data)) {
rc = -EBADF;
cifs_dbg(VFS, "missing cifsFileInfo on copy range src file\n");
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 07/86] ARM: 8429/1: disable GCC SRA optimization

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Ard Biesheuvel 

commit a077224fd35b2f7fbc93f14cf67074fc792fbac2 upstream.

While working on the 32-bit ARM port of UEFI, I noticed a strange
corruption in the kernel log. The following snprintf() statement
(in drivers/firmware/efi/efi.c:efi_md_typeattr_format())

snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",

was producing the following output in the log:

||   |   |   ||WB|WT|WC|UC]
||   |   |   ||WB|WT|WC|UC]
||   |   |   ||WB|WT|WC|UC]
|RUN|   |   |   ||WB|WT|WC|UC]*
|RUN|   |   |   ||WB|WT|WC|UC]*
||   |   |   ||WB|WT|WC|UC]
|RUN|   |   |   ||WB|WT|WC|UC]*
||   |   |   ||WB|WT|WC|UC]
|RUN|   |   |   ||   |   |   |UC]
|RUN|   |   |   ||   |   |   |UC]

As it turns out, this is caused by incorrect code being emitted for
the string() function in lib/vsprintf.c. The following code

if (!(spec.flags & LEFT)) {
while (len < spec.field_width--) {
if (buf < end)
*buf = ' ';
++buf;
}
}
for (i = 0; i < len; ++i) {
if (buf < end)
*buf = *s;
++buf; ++s;
}
while (len < spec.field_width--) {
if (buf < end)
*buf = ' ';
++buf;
}

when called with len == 0, triggers an issue in the GCC SRA optimization
pass (Scalar Replacement of Aggregates), which handles promotion of signed
struct members incorrectly. This is a known but as yet unresolved issue.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular
case, it is causing the second while loop to be executed erroneously a
single time, causing the additional space characters to be printed.

So disable the optimization by passing -fno-ipa-sra.

Acked-by: Nicolas Pitre 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/Makefile | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c1785ee..8e78ed5 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -50,6 +50,14 @@ AS   += -EL
 LD += -EL
 endif
 
+#
+# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
+# later may result in code being generated that handles signed short and signed
+# char struct members incorrectly. So disable it.
+# (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932)
+#
+KBUILD_CFLAGS  += $(call cc-option,-fno-ipa-sra)
+
 # This selects which instruction set is used.
 # Note that GCC does not numerically define an architecture version
 # macro, but instead defines a whole series of macros which makes
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 10/86] hwmon: (nct6775) Swap STEP_UP_TIME and STEP_DOWN_TIME registers for most chips

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Guenter Roeck 

commit 728d29400488d54974d3317fe8a232b45fdb42ee upstream.

The STEP_UP_TIME and STEP_DOWN_TIME registers are swapped for all chips but
NCT6775.

Reported-by: Grazvydas Ignotas 
Reviewed-by: Jean Delvare 
Signed-off-by: Guenter Roeck 
Signed-off-by: Kamal Mostafa 
---
 drivers/hwmon/nct6775.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/hwmon/nct6775.c b/drivers/hwmon/nct6775.c
index 0773930..ff80b83 100644
--- a/drivers/hwmon/nct6775.c
+++ b/drivers/hwmon/nct6775.c
@@ -353,6 +353,10 @@ static const u16 
NCT6775_REG_TEMP_CRIT[ARRAY_SIZE(nct6775_temp_label) - 1]
 
 /* NCT6776 specific data */
 
+/* STEP_UP_TIME and STEP_DOWN_TIME regs are swapped for all chips but NCT6775 
*/
+#define NCT6776_REG_FAN_STEP_UP_TIME NCT6775_REG_FAN_STEP_DOWN_TIME
+#define NCT6776_REG_FAN_STEP_DOWN_TIME NCT6775_REG_FAN_STEP_UP_TIME
+
 static const s8 NCT6776_ALARM_BITS[] = {
0, 1, 2, 3, 8, 21, 20, 16,  /* in0.. in7 */
17, -1, -1, -1, -1, -1, -1, /* in8..in14 */
@@ -3506,8 +3510,8 @@ static int nct6775_probe(struct platform_device *pdev)
data->REG_FAN_PULSES = NCT6776_REG_FAN_PULSES;
data->FAN_PULSE_SHIFT = NCT6775_FAN_PULSE_SHIFT;
data->REG_FAN_TIME[0] = NCT6775_REG_FAN_STOP_TIME;
-   data->REG_FAN_TIME[1] = NCT6775_REG_FAN_STEP_UP_TIME;
-   data->REG_FAN_TIME[2] = NCT6775_REG_FAN_STEP_DOWN_TIME;
+   data->REG_FAN_TIME[1] = NCT6776_REG_FAN_STEP_UP_TIME;
+   data->REG_FAN_TIME[2] = NCT6776_REG_FAN_STEP_DOWN_TIME;
data->REG_TOLERANCE_H = NCT6776_REG_TOLERANCE_H;
data->REG_PWM[0] = NCT6775_REG_PWM;
data->REG_PWM[1] = NCT6775_REG_FAN_START_OUTPUT;
@@ -3578,8 +3582,8 @@ static int nct6775_probe(struct platform_device *pdev)
data->REG_FAN_PULSES = NCT6779_REG_FAN_PULSES;
data->FAN_PULSE_SHIFT = NCT6775_FAN_PULSE_SHIFT;
data->REG_FAN_TIME[0] = NCT6775_REG_FAN_STOP_TIME;
-   data->REG_FAN_TIME[1] = NCT6775_REG_FAN_STEP_UP_TIME;
-   data->REG_FAN_TIME[2] = NCT6775_REG_FAN_STEP_DOWN_TIME;
+   data->REG_FAN_TIME[1] = NCT6776_REG_FAN_STEP_UP_TIME;
+   data->REG_FAN_TIME[2] = NCT6776_REG_FAN_STEP_DOWN_TIME;
data->REG_TOLERANCE_H = NCT6776_REG_TOLERANCE_H;
data->REG_PWM[0] = NCT6775_REG_PWM;
data->REG_PWM[1] = NCT6775_REG_FAN_START_OUTPUT;
@@ -3655,8 +3659,8 @@ static int nct6775_probe(struct platform_device *pdev)
data->REG_FAN_PULSES = NCT6779_REG_FAN_PULSES;
data->FAN_PULSE_SHIFT = NCT6775_FAN_PULSE_SHIFT;
data->REG_FAN_TIME[0] = NCT6775_REG_FAN_STOP_TIME;
-   data->REG_FAN_TIME[1] = NCT6775_REG_FAN_STEP_UP_TIME;
-   data->REG_FAN_TIME[2] = NCT6775_REG_FAN_STEP_DOWN_TIME;
+   data->REG_FAN_TIME[1] = NCT6776_REG_FAN_STEP_UP_TIME;
+   data->REG_FAN_TIME[2] = NCT6776_REG_FAN_STEP_DOWN_TIME;
data->REG_TOLERANCE_H = NCT6776_REG_TOLERANCE_H;
data->REG_PWM[0] = NCT6775_REG_PWM;
data->REG_PWM[1] = NCT6775_REG_FAN_START_OUTPUT;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 02/86] KEYS: Fix race between key destruction and finding a keyring by name

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: David Howells 

commit 94c4554ba07adbdde396748ee7ae01e86cf2d8d7 upstream.

There appears to be a race between:

 (1) key_gc_unused_keys() which frees key->security and then calls
 keyring_destroy() to unlink the name from the name list

 (2) find_keyring_by_name() which calls key_permission(), thus accessing
 key->security, on a key before checking to see whether the key usage is 0
 (ie. the key is dead and might be cleaned up).

Fix this by calling ->destroy() before cleaning up the core key data -
including key->security.

Reported-by: Petr Matousek 
Signed-off-by: David Howells 
Signed-off-by: Kamal Mostafa 
---
 security/keys/gc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/security/keys/gc.c b/security/keys/gc.c
index c795237..39eac1f 100644
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -134,6 +134,10 @@ static noinline void key_gc_unused_keys(struct list_head 
*keys)
kdebug("- %u", key->serial);
key_check(key);
 
+   /* Throw away the key data */
+   if (key->type->destroy)
+   key->type->destroy(key);
+
security_key_free(key);
 
/* deal with the user's key tracking and quota */
@@ -148,10 +152,6 @@ static noinline void key_gc_unused_keys(struct list_head 
*keys)
if (test_bit(KEY_FLAG_INSTANTIATED, &key->flags))
atomic_dec(&key->user->nikeys);
 
-   /* now throw away the key memory */
-   if (key->type->destroy)
-   key->type->destroy(key);
-
key_user_put(key->user);
 
kfree(key->description);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v12 4/6] fpga: add fpga bridge framework

2015-10-27 Thread atull
From: Alan Tull 

This framework adds API functions for enabling/
disabling FPGA bridges under kernel control.

This allows the Linux kernel to disable FPGA bridges
during FPGA reprogramming and to enable FPGA bridges
when FPGA reprogramming is done.  This framework is
be manufacturer-agnostic, allowing it to be used in
interfaces that use the FPGA Manager Framework to
reprogram FPGAs.

The functions are:
* of_fpga_bridge_get
* fpga_bridge_put
   Get/put a reference to a FPGA bridge.

* fpga_bridge_enable
* fpga_bridge_disable
   Enable/Disable traffic through a bridge.

* fpga_bridge_register
* fpga_bridge_unregister
   Register/unregister a device-specific low level FPGA
   Bridge driver.

Signed-off-by: Alan Tull 
---
v2:  Minor cleanup
v12: Bump version to line up with simple fpga bus
 Remove sysfs
 Improve get/put functions, get the low level driver too.
 Clean up class implementation
 Add kernel doc documentation
 Rename (un)register_fpga_bridge -> fpga_bridge_(un)register
---
 drivers/fpga/Kconfig |7 ++
 drivers/fpga/Makefile|3 +
 drivers/fpga/fpga-bridge.c   |  242 ++
 include/linux/fpga/fpga-bridge.h |   49 
 4 files changed, 301 insertions(+)
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index e8f5453..143072b 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -32,6 +32,13 @@ config FPGA_MGR_SOCFPGA_A10
help
  FPGA manager driver support for Altera Arria10 SoCFPGA.
 
+config FPGA_BRIDGE
+   bool "FPGA Bridge Drivers"
+   depends on OF
+   help
+ Say Y here if you want to support bridges connected between host
+processors and FPGAs or between FPGAs.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 0385622..9302662 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -9,5 +9,8 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
 
+# FPGA Bridge Drivers
+obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+
 # High Level Interfaces
 obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
new file mode 100644
index 000..c135988
--- /dev/null
+++ b/drivers/fpga/fpga-bridge.c
@@ -0,0 +1,242 @@
+/*
+ * fpga bridge driver
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_IDA(fpga_bridge_ida);
+static struct class *fpga_bridge_class;
+
+/**
+ * fpga_bridge_enable
+ * @bridge: fpga bridge
+ *
+ * Enable transactions on the bridge
+ *
+ * Return: 0 for success, error code otherwise.
+ */
+int fpga_bridge_enable(struct fpga_bridge *bridge)
+{
+   pr_err("%s %s\n", __func__, dev_name(&bridge->dev));
+
+   return bridge->br_ops->enable_set(bridge, 1);
+}
+EXPORT_SYMBOL_GPL(fpga_bridge_enable);
+
+/**
+ * fpga_bridge_disable
+ * @bridge: fpga bridge
+ *
+ * Disable transactions on the bridge
+ *
+ * Return: 0 for success, error code otherwise.
+ */
+int fpga_bridge_disable(struct fpga_bridge *bridge)
+{
+   pr_err("%s %s\n", __func__, dev_name(&bridge->dev));
+
+   return bridge->br_ops->enable_set(bridge, 0);
+}
+EXPORT_SYMBOL_GPL(fpga_bridge_disable);
+
+static int fpga_bridge_of_node_match(struct device *dev, const void *data)
+{
+   return dev->of_node == data;
+}
+
+/**
+ * of_fpga_bridge_get - get an exclusive reference to a fpga bridge
+ * @node: device node
+ *
+ * Given a device node, get an exclusive reference to a fpga bridge.
+ *
+ * Returns a fpga manager struct or IS_ERR() condition containing errno.
+ */
+struct fpga_bridge *of_fpga_bridge_get(struct device_node *node)
+{
+   struct device *dev;
+   struct fpga_bridge *bridge;
+   int ret = -ENODEV;
+
+   dev = class_find_device(fpga_bridge_class, NULL, node,
+   fpga_bridge_of_node_match);
+   if (!dev)
+   return ERR_PTR(-ENODEV);
+
+   bridge = to_fpga_bridge(dev);
+   if (!bridge)
+   goto err_dev;
+
+   if (!mutex_trylock(

[PATCH 3.19.y-ckt 03/86] KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: David Howells 

commit f05819df10d7b09f6d1eb6f8534a8f68e5a4fe61 upstream.

The following sequence of commands:

i=`keyctl add user a a @s`
keyctl request2 keyring foo bar @t
keyctl unlink $i @s

tries to invoke an upcall to instantiate a keyring if one doesn't already
exist by that name within the user's keyring set.  However, if the upcall
fails, the code sets keyring->type_data.reject_error to -ENOKEY or some
other error code.  When the key is garbage collected, the key destroy
function is called unconditionally and keyring_destroy() uses list_empty()
on keyring->type_data.link - which is in a union with reject_error.
Subsequently, the kernel tries to unlink the keyring from the keyring names
list - which oopses like this:

BUG: unable to handle kernel paging request at ff8a
IP: [] keyring_destroy+0x3d/0x88
...
Workqueue: events key_garbage_collector
...
RIP: 0010:[] keyring_destroy+0x3d/0x88
RSP: 0018:88003e2f3d30  EFLAGS: 00010203
RAX: ff82 RBX: 88003bf1a900 RCX: 
RDX:  RSI: 3bfc6901 RDI: 81a73a40
RBP: 88003e2f3d38 R08: 0152 R09: 
R10: 88003e2f3c18 R11: 865b R12: 88003bf1a900
R13:  R14: 88003bf1a908 R15: 88003e2f4000
...
CR2: ff8a CR3: 3e3ec000 CR4: 06f0
...
Call Trace:
 [] key_gc_unused_keys.constprop.1+0x5d/0x10f
 [] key_garbage_collector+0x1fa/0x351
 [] process_one_work+0x28e/0x547
 [] worker_thread+0x26e/0x361
 [] ? rescuer_thread+0x2a8/0x2a8
 [] kthread+0xf3/0xfb
 [] ? kthread_create_on_node+0x1c2/0x1c2
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x1c2/0x1c2

Note the value in RAX.  This is a 32-bit representation of -ENOKEY.

The solution is to only call ->destroy() if the key was successfully
instantiated.

Reported-by: Dmitry Vyukov 
Signed-off-by: David Howells 
Tested-by: Dmitry Vyukov 
Signed-off-by: Kamal Mostafa 
---
 security/keys/gc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/security/keys/gc.c b/security/keys/gc.c
index 39eac1f..addf060 100644
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -134,8 +134,10 @@ static noinline void key_gc_unused_keys(struct list_head 
*keys)
kdebug("- %u", key->serial);
key_check(key);
 
-   /* Throw away the key data */
-   if (key->type->destroy)
+   /* Throw away the key data if the key is instantiated */
+   if (test_bit(KEY_FLAG_INSTANTIATED, &key->flags) &&
+   !test_bit(KEY_FLAG_NEGATIVE, &key->flags) &&
+   key->type->destroy)
key->type->destroy(key);
 
security_key_free(key);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 4.3-rc7: kmemleak BUG: Redzone overwritten

2015-10-27 Thread Linus Torvalds
On Wed, Oct 28, 2015 at 12:46 AM, Aaro Koskinen  wrote:
>
> With 4.3-rc7 and slub_debug=FZUP, I get the below when reading
> /sys/kernel/debug/kmemleak with a large number of reported entries.
> It's pretty repeatable. HW is MIPS64.
>
> With the SLUB debugging disabled, box crashes randomly in kmem_cache_free
> or kmem_cache_alloc when the kmemleak file is read on a running system.
>
> Seems to start with 6fc37c490076 ("kmemleak: use seq_hex_dump() to
> dump buffers").

Well, so that commit itself looks fine - it just uses the seq accessor
functions to print things out, instead of doing it by hand.

So if that commit causes problems, then I suspect that the real issue
is that seq_hex_dump() itself is buggered, and that the commit just
exposed it by adding new use-cases. It looks like the hexdump wrote
one byte (the terminating NUL) past the end of the buffer:

> [   77.706871] BUG kmalloc-4096 (Not tainted): Redzone overwritten
> [   77.706877]
> [   77.706894] INFO: 0x80002e939000-0x80002e939000. First byte 0x0 
> instead of 0xcc
> [   77.706914] INFO: Allocated in seq_buf_alloc+0x24/0x58 age=452 cpu=2 
> pid=587
> [   77.706928]  __slab_alloc.isra.72.constprop.75+0x4a4/0x508
> [   77.706938]  __kmalloc+0x30c/0x3f0
> [   77.706947]  seq_buf_alloc+0x24/0x58
> [   77.706956]  seq_read+0x304/0x4a0
> [   77.706968]  __vfs_read+0x3c/0x100
> [   77.706977]  vfs_read+0x8c/0x138
> [   77.706987]  SyS_read+0x64/0xe8
> [   77.707000]  syscall_common+0x34/0x58
> [   77.707012] INFO: Freed in seq_release+0x24/0x40 age=3450 cpu=3 pid=584
> [   77.707023]  __slab_free+0x340/0x4f0
> [   77.707032]  seq_release+0x24/0x40
> [   77.707044]  kernfs_fop_release+0x50/0x80
> [   77.707055]  __fput+0xa4/0x218
> [   77.707066]  task_work_run+0xb0/0x108
> [   77.707078]  work_notifysig+0x10/0x18
> [   77.707087] INFO: Slab 0x83ec4440 objects=7 used=1 
> fp=0x80002e93e7b0 flags=0x20004081
> [   77.707095] INFO: Object 0x80002e938000 @offset=0 fp=0x80002e939148
> [   77.707095]
> [   77.707108] Object 80002e938000: 75 6e 72 65 66 65 72 65 6e 63 65 64 
> 20 6f 62 6a  unreferenced obj
> [   77.707118] Object 80002e938010: 65 63 74 20 30 78 38 30 30 30 30 30 
> 30 30 32 66  ect 0x80002f
...
> [   77.709583] Object 80002e938f90: 6d 6d 20 22 73 77 61 70 70 65 72 2f 
> 30 22 2c 20  mm "swapper/0",
> [   77.709593] Object 80002e938fa0: 70 69 64 20 31 2c 20 6a 69 66 66 69 
> 65 73 20 34  pid 1, jiffies 4
> [   77.709603] Object 80002e938fb0: 32 39 34 39 33 38 30 35 31 20 28 61 
> 67 65 20 34  294938051 (age 4
> [   77.709613] Object 80002e938fc0: 31 2e 35 37 30 73 29 0a 20 20 68 65 
> 78 20 64 75  1.570s).  hex du
> [   77.709623] Object 80002e938fd0: 6d 70 20 28 66 69 72 73 74 20 33 32 
> 20 62 79 74  mp (first 32 byt
> [   77.709633] Object 80002e938fe0: 65 73 29 3a 0a 20 20 20 20 36 62 20 
> 36 62 20 36  es):.6b 6b 6
> [   77.709643] Object 80002e938ff0: 62 20 36 62 20 36 62 20 36 62 20 36 
> 62 20 00 20  b 6b 6b 6b 6b .
> [   77.709653] Redzone 80002e939000: 00 cc cc cc cc cc cc cc  
> 

So I suspect that some seq function ends up adding a terminating NUL
character too much when the buffer overflows.

The obvious suspect would be the "hex_dump_to_buffer()" call in
seq_hex_dump(). It's the only thing that doesn't use really common
core helpers, though.

Looking at "hex_dump_to_buffer()", code like this strikes me as
particularly dangerous:

if (linebuflen < lx + 3)
goto overflow2;
 ...
overflow2:
linebuf[lx++] = '\0';
overflow1:
return ascii ? ascii_column + len : (groupsize * 2 + 1) *
ngroups - 1;

because what if lx == linebuflen in the overflow condition.

But the non-overflow condition looks a bit scary too: the
"non-overflow" case checks that there is room for three characters,
and then adds those three characters (and possible removes the last
one). Fine - but what if the three characters *exactly* filled the
buffer, and we think we haven't overflowed, and now we just do

nil:
linebuf[lx] = '\0';
return lx;

there as the "success" case.

So without trying to really analyze this, I do suspect that the
problem is in either of those cases.

I would suggest the "nil:" case do

nil:
if (lx < linebuflen)
linebuf[lx] = 0;
return lx;

and add something similar to overflow2 too.

Hmm? Does that fix your test-case? Added Al Viro as seq_file
maintainer to the cc.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v7 7/7] mtd: nand: gpmi: support NAND on i.MX6UL

2015-10-27 Thread Han Xu
support GPMI NAND on i.MX6UL

Signed-off-by: Han Xu 
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 9 +
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 4 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index d34c35014..8bdf8a1 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -89,6 +89,12 @@ static const struct gpmi_devdata gpmi_devdata_imx7d = {
.max_chain_delay = 12,
 };
 
+static const struct gpmi_devdata gpmi_devdata_imx6ul = {
+   .type = IS_MX6UL,
+   .bch_max_ecc_strength = 40,
+   .max_chain_delay = 12,
+};
+
 static irqreturn_t bch_irq(int irq, void *cookie)
 {
struct gpmi_nand_data *this = cookie;
@@ -2016,6 +2022,9 @@ static const struct of_device_id gpmi_nand_id_table[] = {
.compatible = "fsl,imx6sx-gpmi-nand",
.data = &gpmi_devdata_imx6sx,
}, {
+   .compatible = "fsl,imx6ul-gpmi-nand",
+   .data = (void *)&gpmi_devdata_imx6ul,
+   }, {
.compatible = "fsl,imx7d-gpmi-nand",
.data = (void *)&gpmi_devdata_imx7d,
}, { /* sentinel */ }
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 149a442..331f98e 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -126,6 +126,7 @@ enum gpmi_type {
IS_MX6QP,
IS_MX6SX,
IS_MX7D,
+   IS_MX6UL,
 };
 
 struct gpmi_devdata {
@@ -310,8 +311,9 @@ void gpmi_copy_bits(u8 *dst, size_t dst_bit_off,
 #define GPMI_IS_MX6QP(x)   ((x)->devdata->type == IS_MX6QP)
 #define GPMI_IS_MX6SX(x)   ((x)->devdata->type == IS_MX6SX)
 #define GPMI_IS_MX7D(x)((x)->devdata->type == IS_MX7D)
+#define GPMI_IS_MX6UL(x)   ((x)->devdata->type == IS_MX6UL)
 
 #define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6QP(x)\
-  || GPMI_IS_MX6SX(x))
+  || GPMI_IS_MX6SX(x) || GPMI_IS_MX6UL(x))
 #define GPMI_IS_MX7(x) (GPMI_IS_MX7D(x))
 #endif
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v7 6/7] mtd: nand: gpmi: correct bitflip for erased NAND page

2015-10-27 Thread Han Xu
i.MX6QP and i.MX7D BCH module integrated a new feature to detect the
bitflip number for erased NAND page. So for these two platform, set the
erase threshold to ecc_strength and if bitflip detected, GPMI driver will
correct the data to all 0xFF.

Signed-off-by: Han Xu 
---
 drivers/mtd/nand/gpmi-nand/bch-regs.h  | 10 ++
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  5 +
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 24 +++-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  5 -
 4 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/bch-regs.h 
b/drivers/mtd/nand/gpmi-nand/bch-regs.h
index 53e58bc..a84d72b 100644
--- a/drivers/mtd/nand/gpmi-nand/bch-regs.h
+++ b/drivers/mtd/nand/gpmi-nand/bch-regs.h
@@ -30,7 +30,13 @@
 #define BM_BCH_CTRL_COMPLETE_IRQ   (1 << 0)
 
 #define HW_BCH_STATUS0 0x0010
+
 #define HW_BCH_MODE0x0020
+#define BP_BCH_MODE_ERASE_THRESHOLD0
+#define BM_BCH_MODE_ERASE_THRESHOLD(0xff << BP_BCH_MODE_ERASE_THRESHOLD)
+#define BF_BCH_MODE_ERASE_THRESHOLD(v) \
+   (((v) << BP_BCH_MODE_ERASE_THRESHOLD) & BM_BCH_MODE_ERASE_THRESHOLD)
+
 #define HW_BCH_ENCODEPTR   0x0030
 #define HW_BCH_DATAPTR 0x0040
 #define HW_BCH_METAPTR 0x0050
@@ -125,4 +131,8 @@
)
 
 #define HW_BCH_VERSION 0x0160
+#define HW_BCH_DEBUG1  0x0170
+#define BP_BCH_DEBUG1_ERASED_ZERO_COUNT0
+#define BM_BCH_DEBUG1_ERASED_ZERO_COUNT\
+   (0x1ff << BP_BCH_DEBUG1_ERASED_ZERO_COUNT)
 #endif
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 1f26a79..0548d84 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -298,6 +298,11 @@ int bch_set_geometry(struct gpmi_nand_data *this)
| BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(block_size, this),
r->bch_regs + HW_BCH_FLASH0LAYOUT1);
 
+   /* Set erase threshold to ecc_strength for mx6qp and mx7 */
+   if (GPMI_IS_MX6QP(this) || GPMI_IS_MX7(this))
+   writel(BF_BCH_MODE_ERASE_THRESHOLD(ecc_strength),
+   r->bch_regs + HW_BCH_MODE);
+
/* Set *all* chip selects to use layout 0. */
writel(0, r->bch_regs + HW_BCH_LAYOUTSELECT);
 
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 8339a44..d34c35014 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -71,6 +71,12 @@ static const struct gpmi_devdata gpmi_devdata_imx6q = {
.max_chain_delay = 12,
 };
 
+static const struct gpmi_devdata gpmi_devdata_imx6qp = {
+   .type = IS_MX6QP,
+   .bch_max_ecc_strength = 40,
+   .max_chain_delay = 12,
+};
+
 static const struct gpmi_devdata gpmi_devdata_imx6sx = {
.type = IS_MX6SX,
.bch_max_ecc_strength = 62,
@@ -1010,6 +1016,7 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, 
struct nand_chip *chip,
 {
struct gpmi_nand_data *this = chip->priv;
struct bch_geometry *nfc_geo = &this->bch_geometry;
+   void __iomem *bch_regs = this->resources.bch_regs;
void  *payload_virt;
dma_addr_tpayload_phys;
void  *auxiliary_virt;
@@ -1018,6 +1025,7 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, 
struct nand_chip *chip,
unsigned char *status;
unsigned int  max_bitflips = 0;
int   ret;
+   int flag = 0;
 
dev_dbg(this->dev, "page number is : %d\n", page);
ret = read_page_prepare(this, buf, nfc_geo->payload_size,
@@ -1050,9 +1058,16 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, 
struct nand_chip *chip,
status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
 
for (i = 0; i < nfc_geo->ecc_chunk_count; i++, status++) {
-   if ((*status == STATUS_GOOD) || (*status == STATUS_ERASED))
+   if (*status == STATUS_GOOD)
continue;
 
+   if (*status == STATUS_ERASED) {
+   if (GPMI_IS_MX6QP(this) || GPMI_IS_MX7(this))
+   if (readl(bch_regs + HW_BCH_DEBUG1))
+   flag = 1;
+   continue;
+   }
+
if (*status == STATUS_UNCORRECTABLE) {
mtd->ecc_stats.failed++;
continue;
@@ -1081,6 +1096,10 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, 
struct nand_chip *chip,
nfc_geo->payload_size,
payload_virt, payload_phys);
 
+   /* if bitflip occurred in erased page, change data to all 0xff */
+   if (flag)
+   memset(buf, 0xff, nfc_geo->payload_size)

[PATCH v7 5/7] mtd: nand: gpmi: add GPMI NAND support for i.MX7D

2015-10-27 Thread Han Xu
support GPMI NAND on i.MX7D

Signed-off-by: Han Xu 
---
 drivers/mtd/nand/gpmi-nand/bch-regs.h  | 14 +++---
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c  | 10 ++
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 27 ++-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  7 +--
 4 files changed, 40 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/bch-regs.h 
b/drivers/mtd/nand/gpmi-nand/bch-regs.h
index 05bb91f..53e58bc 100644
--- a/drivers/mtd/nand/gpmi-nand/bch-regs.h
+++ b/drivers/mtd/nand/gpmi-nand/bch-regs.h
@@ -1,7 +1,7 @@
 /*
  * Freescale GPMI NAND Flash Driver
  *
- * Copyright 2008-2011 Freescale Semiconductor, Inc.
+ * Copyright 2008-2015 Freescale Semiconductor, Inc.
  * Copyright 2008 Embedded Alley Solutions, Inc.
  *
  * This program is free software; you can redistribute it and/or modify
@@ -54,7 +54,7 @@
 #define MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0 11
 #define MX6Q_BM_BCH_FLASH0LAYOUT0_ECC0 (0x1f << MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0)
 #define BF_BCH_FLASH0LAYOUT0_ECC0(v, x)\
-   (GPMI_IS_MX6(x) \
+   ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) << MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0)  \
& MX6Q_BM_BCH_FLASH0LAYOUT0_ECC0)   \
: (((v) << BP_BCH_FLASH0LAYOUT0_ECC0)   \
@@ -65,7 +65,7 @@
 #define MX6Q_BM_BCH_FLASH0LAYOUT0_GF_13_14 \
(0x1 << MX6Q_BP_BCH_FLASH0LAYOUT0_GF_13_14)
 #define BF_BCH_FLASH0LAYOUT0_GF(v, x)  \
-   ((GPMI_IS_MX6(x) && ((v) == 14))\
+   (((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) && ((v) == 14))\
? (((1) << MX6Q_BP_BCH_FLASH0LAYOUT0_GF_13_14)  \
& MX6Q_BM_BCH_FLASH0LAYOUT0_GF_13_14)   \
: 0 \
@@ -77,7 +77,7 @@
 #define MX6Q_BM_BCH_FLASH0LAYOUT0_DATA0_SIZE   \
(0x3ff << BP_BCH_FLASH0LAYOUT0_DATA0_SIZE)
 #define BF_BCH_FLASH0LAYOUT0_DATA0_SIZE(v, x)  \
-   (GPMI_IS_MX6(x) \
+   ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) >> 2) & MX6Q_BM_BCH_FLASH0LAYOUT0_DATA0_SIZE)   \
: ((v) & BM_BCH_FLASH0LAYOUT0_DATA0_SIZE)   \
)
@@ -96,7 +96,7 @@
 #define MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN 11
 #define MX6Q_BM_BCH_FLASH0LAYOUT1_ECCN (0x1f << MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN)
 #define BF_BCH_FLASH0LAYOUT1_ECCN(v, x)\
-   (GPMI_IS_MX6(x) \
+   ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) << MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN)  \
& MX6Q_BM_BCH_FLASH0LAYOUT1_ECCN)   \
: (((v) << BP_BCH_FLASH0LAYOUT1_ECCN)   \
@@ -107,7 +107,7 @@
 #define MX6Q_BM_BCH_FLASH0LAYOUT1_GF_13_14 \
(0x1 << MX6Q_BP_BCH_FLASH0LAYOUT1_GF_13_14)
 #define BF_BCH_FLASH0LAYOUT1_GF(v, x)  \
-   ((GPMI_IS_MX6(x) && ((v) == 14))\
+   (((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) && ((v) == 14))\
? (((1) << MX6Q_BP_BCH_FLASH0LAYOUT1_GF_13_14)  \
& MX6Q_BM_BCH_FLASH0LAYOUT1_GF_13_14)   \
: 0 \
@@ -119,7 +119,7 @@
 #define MX6Q_BM_BCH_FLASH0LAYOUT1_DATAN_SIZE   \
(0x3ff << BP_BCH_FLASH0LAYOUT1_DATAN_SIZE)
 #define BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(v, x)  \
-   (GPMI_IS_MX6(x) \
+   ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) >> 2) & MX6Q_BM_BCH_FLASH0LAYOUT1_DATAN_SIZE)   \
: ((v) & BM_BCH_FLASH0LAYOUT1_DATAN_SIZE)   \
)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 43fa16b..1f26a79 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -1,7 +1,7 @@
 /*
  * Freescale GPMI NAND Flash Driver
  *
- * Copyright (C) 2008-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2008-2015 Freescale Semiconductor, Inc.
  * Copyright (C) 2008 Embedded Alley Solutions, Inc.
  *
  * This program is free software; you can redistribute it and/or modify
@@ -971,7 +971,8 @@ int gpmi_extra_init(struct gpmi_nand_data *this)
struct nand_chip *chip = &this->nand;
 
/* Enable the asynchronous EDO feature. */
-   if (GPMI_IS_MX6(this) && chip->onfi_version) {
+   if ((GPMI_IS_MX6(this) || GPMI_IS_MX7(this)) &&
+   chip->onfi_version) {
int mode = onfi_get_async_timing_mode(chip);
 
/* We only support the timing mode 4 a

[PATCH v7 2/7] dmaengine: mxs: APBH DMA supports deep sleep mode

2015-10-27 Thread Han Xu
From: Huang Shijie 

Deep Sleep Mode(dsm) turns off the power for APBH DMA module, DMA
need to be re-initialized when system resumed back.

Signed-off-by: Huang Shijie 
Signed-off-by: Han Xu 
---
 drivers/dma/mxs-dma.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index 60de352..b8a4822e 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -693,7 +693,7 @@ static enum dma_status mxs_dma_tx_status(struct dma_chan 
*chan,
return mxs_chan->status;
 }
 
-static int __init mxs_dma_init(struct mxs_dma_engine *mxs_dma)
+static int mxs_dma_init(struct mxs_dma_engine *mxs_dma)
 {
int ret;
 
@@ -835,6 +835,7 @@ static int __init mxs_dma_probe(struct platform_device 
*pdev)
 
mxs_dma->pdev = pdev;
mxs_dma->dma_device.dev = &pdev->dev;
+   dev_set_drvdata(&pdev->dev, mxs_dma);
 
/* mxs_dma gets 65535 bytes maximum sg size */
mxs_dma->dma_device.dev->dma_parms = &mxs_dma->dma_parms;
@@ -872,9 +873,27 @@ static int __init mxs_dma_probe(struct platform_device 
*pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int mxs_dma_pm_resume(struct device *dev)
+{
+   struct mxs_dma_engine *mxs_dma = dev_get_drvdata(dev);
+   int ret;
+
+   ret = mxs_dma_init(mxs_dma);
+   if (ret)
+   return ret;
+   return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops mxs_dma_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(NULL, mxs_dma_pm_resume)
+};
+
 static struct platform_driver mxs_dma_driver = {
.driver = {
.name   = "mxs-dma",
+   .pm = &mxs_dma_pm_ops,
.of_match_table = mxs_dma_dt_ids,
},
.id_table   = mxs_dma_ids,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v12 6/6] ARM: socfpga: fpga bridge driver support

2015-10-27 Thread atull
From: Alan Tull 

Supports Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Allows enabling/disabling the bridges through the FPGA
Bridge Framework API functions.

The fpga2sdram driver only supports enabling and disabling
of the ports that been configured early on.  This is due to
a hardware limitation where the read, write, and command
ports on the fpga2sdram bridge can only be reconfigured
while there are no transactions to the sdram, i.e. when
running out of OCRAM before the kernel boots.

Device tree property 'init-val' configures the driver to
enable or disable the bridge during probe.  If the property
does not exist, the driver will leave the bridge in its
current state.

Signed-off-by: Alan Tull 
Signed-off-by: Dinh Nguyen 
Signed-off-by: Matthew Gerlach 
---
v2:  Use resets instead of directly writing reset registers
v12: Bump version to align with simple-fpga-bus version
 Get rid of the sysfs interface
 fpga2sdram: get configuration stored in handoff register
---
 drivers/fpga/Kconfig |7 ++
 drivers/fpga/Makefile|1 +
 drivers/fpga/altera-fpga2sdram.c |  185 ++
 drivers/fpga/altera-hps2fpga.c   |  234 ++
 4 files changed, 427 insertions(+)
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 143072b..004b83a 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -39,6 +39,13 @@ config FPGA_BRIDGE
  Say Y here if you want to support bridges connected between host
 processors and FPGAs or between FPGAs.
 
+config SOCFPGA_FPGA_BRIDGE
+   bool "Altera SoCFPGA FPGA Bridges"
+   depends on ARCH_SOCFPGA && FPGA_BRIDGE
+   help
+ Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
+ devices.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 9302662..cc01db3 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10)+= socfpga-a10.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)  += altera-hps2fpga.o altera-fpga2sdram.o
 
 # High Level Interfaces
 obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
diff --git a/drivers/fpga/altera-fpga2sdram.c b/drivers/fpga/altera-fpga2sdram.c
new file mode 100644
index 000..ee56903
--- /dev/null
+++ b/drivers/fpga/altera-fpga2sdram.c
@@ -0,0 +1,185 @@
+/*
+ * FPGA to SDRAM Bridge Driver for Altera SoCFPGA Devices
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+/*
+ * This driver manages a bridge between an FPGA and the SDRAM used by the ARM
+ * host processor system (HPS).
+ *
+ * The bridge contains 4 read ports, 4 write ports, and 6 command ports.
+ * Reconfiguring these ports requires that no SDRAM transactions occur during
+ * reconfiguration.  The code reconfiguring the ports cannot run out of SDRAM
+ * nor can the FPGA access the SDRAM during reconfiguration.  This driver does
+ * not support reconfiguring the ports.  The ports are configured by code
+ * running out of on chip ram before Linux is started and the configuration
+ * is passed in a handoff register in the system manager.
+ *
+ * This driver supports enabling and disabling of the configured ports, which
+ * allows for safe reprogramming of the FPGA, assuming that the new FPGA image
+ * uses the same port configuration.  Bridges must be disabled before
+ * reprogramming the FPGA and re-enabled after the FPGA has been programmed.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ALT_SDR_CTL_FPGAPORTRST_OFST   0x80
+#define ALT_SDR_CTL_FPGAPORTRST_PORTRSTN_MSK   0x3fff
+#define ALT_SDR_CTL_FPGAPORTRST_RD_SHIFT   0
+#define ALT_SDR_CTL_FPGAPORTRST_WR_SHIFT   4
+#define ALT_SDR_CTL_FPGAPORTRST_CTRL_SHIFT 8
+
+#define SYSMGR_ISWGRP_HANDOFF3  (0x8C)
+#define ISWGRP_HANDOFF_FPGA2SDR SYSMGR_ISWGRP_HANDOFF3
+
+#define F2S_BRIDGE_NAME "fpga2sdram"
+
+struct alt_fpga2sdram_data {
+   struct device *dev;
+   struct regmap *sdrctl;
+   int mask;
+};
+
+static int alt_fpga2sdram_enable_show(struct fpga_bridge *bridge)

[PATCH] scsi: hpsa: fix multiple issues in path_info_show

2015-10-27 Thread Rasmus Villemoes
I'm not familiar with this code, but path_info_show() (added in
8270b86243658 "hpsa: add sysfs entry path_info to show box and
bay information") seems to be broken in multiple ways.

First, there's

  817 return snprintf(buf, output_len+1, "%s%s%s%s%s%s%s%s",
  818 path[0], path[1], path[2], path[3],
  819 path[4], path[5], path[6], path[7]);

so hopefully output_len contains the combined length of the eight
strings. Otherwise, snprintf will stop copying to the output
buffer, but still end up reporting that combined length - which
in turn would result in user-space getting a bunch of useless nul
bytes (thankfully the upper sysfs layer seems to clear the output
buffer before passing it to the various ->show routines). But we have

  767 output_len = snprintf(path[i],
  768 PATH_STRING_LEN, "[%d:%d:%d:%d] %20.20s ",
  769 h->scsi_host->host_no,
  770 hdev->bus, hdev->target, hdev->lun,
  771 scsi_device_type(hdev->devtype));

so output_len at best contains the length of the last string printed.

Inside the loop, we then otherwise add to output_len. By magic,
we still have PATH_STRING_LEN available every time... This
wouldn't really be a problem if the bean-counting has been done
properly and each line actually does fit in 50 bytes, and maybe
it does, but I don't immediately see why. Suppose we end up
taking this branch:

  802 output_len += snprintf(path[i] + output_len,
  803 PATH_STRING_LEN,
  804 "BOX: %hhu BAY: %hhu %s\n",
  805 box, bay, active);

An optimistic estimate says this uses strlen("BOX: 1 BAY: 2
Active\n") which is 21. Now add the 20 bytes guaranteed by the
%20.20s and then some for the rest of that format string, and
we're easily over 50 bytes. I don't think we can get over 100
bytes even being pessimistic, so this just means we'll scribble
into the next path[i+1] and maybe get that overwritten later,
leading to some garbled output (in fact, since we'd overwrite the
previous string's 0-terminator, we could end up with one very
long string and then print various suffixes of that, leading to
much more than 400 bytes of output). Except of course when we're
filling path[7], where overrunning it means writing random stuff
to the kernel stack, which is usually a lot of fun.

We can fix all of that and get rid of the 400 byte stack buffer by
simply writing directly to the given output buffer, which the upper
layer guarantees is at least PAGE_SIZE. s[c]nprintf doesn't care where
it is writing to, so this doesn't make the spin lock hold time any
longer. Using scnprintf ensures that output_len always represents the
number of bytes actually written to the buffer, so we'll report the
proper amount to the upper layer.

Signed-off-by: Rasmus Villemoes 
---
 drivers/scsi/hpsa.c | 38 +-
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 40669f8dd0df..b892ae90e292 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -726,7 +726,6 @@ static ssize_t host_show_hp_ssd_smart_path_enabled(struct 
device *dev,
 }
 
 #define MAX_PATHS 8
-#define PATH_STRING_LEN 50
 
 static ssize_t path_info_show(struct device *dev,
 struct device_attribute *attr, char *buf)
@@ -742,9 +741,7 @@ static ssize_t path_info_show(struct device *dev,
u8 path_map_index = 0;
char *active;
unsigned char phys_connector[2];
-   unsigned char path[MAX_PATHS][PATH_STRING_LEN];
 
-   memset(path, 0, MAX_PATHS * PATH_STRING_LEN);
sdev = to_scsi_device(dev);
h = sdev_to_hba(sdev);
spin_lock_irqsave(&h->devlock, flags);
@@ -764,8 +761,9 @@ static ssize_t path_info_show(struct device *dev,
else
continue;
 
-   output_len = snprintf(path[i],
-   PATH_STRING_LEN, "[%d:%d:%d:%d] %20.20s ",
+   output_len += scnprintf(buf + output_len,
+   PAGE_SIZE - output_len,
+   "[%d:%d:%d:%d] %20.20s ",
h->scsi_host->host_no,
hdev->bus, hdev->target, hdev->lun,
scsi_device_type(hdev->devtype));
@@ -773,9 +771,9 @@ static ssize_t path_info_show(struct device *dev,
if (is_ext_target(h, hdev) ||
(hdev->devtype == TYPE_RAID) ||
is_logical_dev_addr_mode(hdev->scsi3addr)) {
-   output_len += snprintf(path[i] + output_len,
-   PATH_STRING_LEN, "%s\n",
-   active);
+   output_len += scnprintf(buf + output_len,
+

[PATCH v12 2/6] fpga: add bindings document for simple fpga bus

2015-10-27 Thread atull
From: Alan Tull 

New bindings document for simple fpga bus.

Signed-off-by: Alan Tull 
---
v9:  initial version added to this patchset
v10: s/fpga/FPGA/g
 replace DT overlay example with slightly more complicated example
 move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Changed to use FPGA bridges framework instead of resets
 for bridges.
---
 .../devicetree/bindings/fpga/simple-fpga-bus.txt   |   81 
 1 file changed, 81 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt

diff --git a/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt 
b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
new file mode 100644
index 000..2e742f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
@@ -0,0 +1,81 @@
+Simple FPGA Bus
+===
+
+A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
+before populating the devices below its node.  All this happens when a device
+tree overlay is added to the live tree.  This document describes that device
+tree overlay.
+
+Required properties:
+- compatible : should contain "simple-fpga-bus"
+- #address-cells, #size-cells, ranges: must be present to handle address space
+  mapping for children.
+
+Optional properties:
+- fpga-mgr : should contain a phandle to a FPGA manager.
+- fpga-firmware : should contain the name of a FPGA image file located on the
+  firmware search path.
+- partial-reconfig : boolean property should be defined if partial
+  reconfiguration of the FPGA is to be done, otherwise full reconfiguration
+  is done.
+- fpga-bridges : should contain a list of bridges that the bus will disable
+  before   programming the FPGA and then enable after the FPGA has been
+
+Example:
+
+/dts-v1/;
+/plugin/;
+/ {
+   fragment@0 {
+   target-path="/soc";
+   __overlay__ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   bridge@0xff20 {
+   compatible = "simple-fpga-bus";
+   reg = <0xc000 0x2000>,
+ <0xff20 0x0020>;
+   reg-names = "axi_h2f", "axi_h2f_lw";
+
+   #address-cells = <0x2>;
+   #size-cells = <0x1>;
+
+   ranges = <0x 0x 0xc000 
0x0001>,
+<0x0001 0x0002 0xff22 
0x0008>,
+<0x0001 0x00010040 0xff210040 
0x0020>;
+
+   clocks = <0x2 0x2>;
+   clock-names = "h2f_lw_axi_clock", 
"f2h_sdram0_clock";
+
+   fpga-mgr = <&hps_0_fpgamgr>;
+   fpga-firmware = "soc_system.rbf";
+
+   fpga-bridges = <&hps_fpgabridge0>, 
<&hps_fpgabridge1>, <&hps_fpgabridge2>;
+
+   onchip_memory2_0: memory@0x0 {
+   device_type = "memory";
+   compatible = "ALTR,onchipmem-15.1";
+   reg = <0x 0x 
0x0001>;
+   };
+
+   jtag_uart: serial@0x10002 {
+   compatible = "altr,juart-15.1", 
"altr,juart-1.0";
+   reg = <0x0001 0x0002 
0x0008>;
+   interrupt-parent = <&intc>;
+   interrupts = <0 42 4>;
+   };
+
+   led_pio: gpio@0x100010040 {
+   compatible = "altr,pio-15.1", 
"altr,pio-1.0";
+   reg = <0x0001 0x00010040 
0x0020>;
+   altr,gpio-bank-width = <4>;
+   resetvalue = <0>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   };
+   };
+   };
+   };
+};
+
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v7 0/7] mtd: nand: gpmi: gpmi-nand DSM and bitflip support

2015-10-27 Thread Han Xu
v1 ---> v2
change the erased page bitflip threshold to ecc strength in bitflip patch

v2 ---> v3
remove unnecessary function in mxs-dma
change the log message when legacy_set_geometry failed fix the comment message 
for bitflip add comma for all field entries

v3 ---> v4
code style change for indentation

v4 ---> v5
split the DMA PM and i.MX7D support into two patches add more comments fix the 
DMA clock count mismatch issue for i.MX7D

v5 ---> v6
add a sentinel entry for of_device_id to fix build error

v6 ---> v7
add CONFIG_PM_SLEEP for GPMI/DMA PM code.

Adrian Alonso (1):
  dmaengine: mxs: add i.MX7D APBH DMA support

Han Xu (4):
  mtd: nand: gpmi: may use minimum required ecc for 744 oobsize NAND
  mtd: nand: gpmi: add GPMI NAND support for i.MX7D
  mtd: nand: gpmi: correct bitflip for erased NAND page
  mtd: nand: gpmi: support NAND on i.MX6UL

Huang Shijie (2):
  mtd: nand: gpmi: add gpmi dsm supend/resume support
  dmaengine: mxs: APBH DMA supports deep sleep mode

 drivers/dma/mxs-dma.c  |  74 --
 drivers/mtd/nand/gpmi-nand/bch-regs.h  |  24 --
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  15 +++-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 133 -
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  14 +++-
 5 files changed, 219 insertions(+), 41 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v7 1/7] mtd: nand: gpmi: add gpmi dsm supend/resume support

2015-10-27 Thread Han Xu
From: Huang Shijie 

i.MX6SX supports deep sleep mode(DSM) that may turn off GPMI/BCH power
during suspend, add gpmi nand suspend/resume function to release DMA
channel in suspend function and re-init GPMI/BCH controller during
resume function.

Although it is not necessary to restore GPMI/BCH registers value for
i.MX6QDL, the code doesn't distinguish different platforms to keep the
code simple.

Signed-off-by: Huang Shijie 
Signed-off-by: Han Xu 
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 47 +-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 2064ada..0961b93 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1,7 +1,7 @@
 /*
  * Freescale GPMI NAND Flash Driver
  *
- * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2015 Freescale Semiconductor, Inc.
  * Copyright (C) 2008 Embedded Alley Solutions, Inc.
  *
  * This program is free software; you can redistribute it and/or modify
@@ -2036,9 +2036,54 @@ static int gpmi_nand_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int gpmi_pm_suspend(struct device *dev)
+{
+   struct gpmi_nand_data *this = dev_get_drvdata(dev);
+
+   release_dma_channels(this);
+   return 0;
+}
+
+static int gpmi_pm_resume(struct device *dev)
+{
+   struct gpmi_nand_data *this = dev_get_drvdata(dev);
+   int ret;
+
+   ret = acquire_dma_channels(this);
+   if (ret < 0)
+   return ret;
+
+   /* re-init the GPMI registers */
+   this->flags &= ~GPMI_TIMING_INIT_OK;
+   ret = gpmi_init(this);
+   if (ret) {
+   dev_err(this->dev, "Error setting GPMI : %d\n", ret);
+   return ret;
+   }
+
+   /* re-init the BCH registers */
+   ret = bch_set_geometry(this);
+   if (ret) {
+   dev_err(this->dev, "Error setting BCH : %d\n", ret);
+   return ret;
+   }
+
+   /* re-init others */
+   gpmi_extra_init(this);
+
+   return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops gpmi_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(gpmi_pm_suspend, gpmi_pm_resume)
+};
+
 static struct platform_driver gpmi_nand_driver = {
.driver = {
.name = "gpmi-nand",
+   .pm = &gpmi_pm_ops,
.of_match_table = gpmi_nand_id_table,
},
.probe   = gpmi_nand_probe,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v12 5/6] ARM: socfpga: add bindings document for fpga bridge drivers

2015-10-27 Thread atull
From: Alan Tull 

Add bindings documentation for Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Signed-off-by: Alan Tull 
Signed-off-by: Dinh Nguyen 
Signed-off-by: Matthew Gerlach 
---
v2:  separate into 2 documents for the 2 drivers
v12: bump version to line up with simple-fpga-bus version
 remove Linux specific notes such as references to sysfs
 move non-DT specific documentation elsewhere
 remove bindings that would have been used to pass configuration
 clean up formatting
---
 .../bindings/fpga/altera-fpga2sdram-bridge.txt |   18 ++
 .../bindings/fpga/altera-hps2fpga-bridge.txt   |   36 
 2 files changed, 54 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt

diff --git 
a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
new file mode 100644
index 000..11eb5b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
@@ -0,0 +1,18 @@
+Altera FPGA To SDRAM Bridge Driver
+
+Required properties:
+- compatible   : Should contain "altr,socfpga-fpga2sdram-bridge"
+
+Optional properties:
+- label: User-readable name for this bridge.
+ Default is br
+- init-val : 0 if driver should disable bridge at startup
+ 1 if driver should enable bridge at startup
+ Default is to leave bridge in current state.
+
+Example:
+   fpga2sdram_br: fpgabridge@3 {
+   compatible = "altr,socfpga-fpga2sdram-bridge";
+   label = "fpga2sdram";
+   init-val = <0>;
+   };
diff --git a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt 
b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
new file mode 100644
index 000..eb52f3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
@@ -0,0 +1,36 @@
+Altera FPGA/HPS Bridge Driver
+
+Required properties:
+- compatible   : Should contain one of:
+ "altr,socfpga-hps2fpga-bridge",
+ "altr,socfpga-lwhps2fpga-bridge", or
+ "altr,socfpga-fpga2hps-bridge"
+- clocks   : Clocks used by this module.
+
+Optional properties:
+- label: User-readable name for this bridge.
+ Default is br
+- init-val : 0 if driver should disable bridge at startup.
+ 1 if driver should enable bridge at startup.
+ Default is to leave bridge in its current state.
+
+Example:
+   hps_fpgabridge0: fpgabridge@0 {
+   compatible = "altr,socfpga-hps2fpga-bridge";
+   label = "hps2fpga";
+   clocks = <&l4_main_clk>;
+   init-val = <1>;
+   };
+
+   hps_fpgabridge1: fpgabridge@1 {
+   compatible = "altr,socfpga-lwhps2fpga-bridge";
+   label = "lwhps2fpga";
+   clocks = <&l4_main_clk>;
+   init-val = <0>;
+   };
+
+   hps_fpgabridge2: fpgabridge@2 {
+   compatible = "altr,socfpga-fpga2hps-bridge";
+   label = "fpga2hps";
+   clocks = <&l4_main_clk>;
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v12 0/6] simple fpga bus and fpga bridge framework

2015-10-27 Thread atull
From: Alan Tull 

The Simple FPGA Bus provides a manufacturer-agnostic interface
for reprogramming FPGAs using Device Tree Overlays.  It uses the
FPGA Bridge Framework and the upstreamed FPGA Manager Framework.

When a Device Tree Overlay is applied, the Simple FPGA Bus will
use information the overlay to:
 * Disable FPGA bridges
 * Reprogram the FPGA
 * Enable FPGA bridges
 * Populate the child devices

Simple FPGA Bus was originally submitted with the FPGA Manager
Framework which was accepted upstream.  This version uses the
FPGA Bridge Framework to provide methods to enable/bridges.

Alan Tull (6):
  fpga: add usage documentation for simple fpga bus
  fpga: add bindings document for simple fpga bus
  fpga: add simple-fpga-bus
  fpga: add fpga bridge framework
  ARM: socfpga: add bindings document for fpga bridge drivers
  ARM: socfpga: fpga bridge driver support

 .../bindings/fpga/altera-fpga2sdram-bridge.txt |   18 ++
 .../bindings/fpga/altera-hps2fpga-bridge.txt   |   36 +++
 .../devicetree/bindings/fpga/simple-fpga-bus.txt   |   81 +
 Documentation/fpga/simple-fpga-bus.txt |   58 
 drivers/fpga/Kconfig   |   21 ++
 drivers/fpga/Makefile  |7 +
 drivers/fpga/altera-fpga2sdram.c   |  185 +++
 drivers/fpga/altera-hps2fpga.c |  234 ++
 drivers/fpga/fpga-bridge.c |  242 +++
 drivers/fpga/simple-fpga-bus.c |  327 
 include/linux/fpga/fpga-bridge.h   |   49 +++
 11 files changed, 1258 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
 create mode 100644 Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
 create mode 100644 Documentation/fpga/simple-fpga-bus.txt
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 drivers/fpga/simple-fpga-bus.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v7 4/7] mtd: nand: gpmi: may use minimum required ecc for 744 oobsize NAND

2015-10-27 Thread Han Xu
By default NAND driver will choose the highest ecc strength that oob
could contain, in this case, for some 8K+744 NAND flash, the ecc
strength will be up to 52bit, which beyonds the i.MX6QDL BCH capability
(40bit).

This patch allows the NAND driver try to use minimum required ecc
strength if it failed to use the highest ecc, even without explicitly
claiming "fsl,use-minimum-ecc" in dts.

Signed-off-by: Han Xu 
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 0961b93..d8f2403 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -136,7 +136,7 @@ static inline bool gpmi_check_ecc(struct gpmi_nand_data 
*this)
  *
  * We may have available oob space in this case.
  */
-static bool set_geometry_by_ecc_info(struct gpmi_nand_data *this)
+static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
 {
struct bch_geometry *geo = &this->bch_geometry;
struct mtd_info *mtd = &this->mtd;
@@ -145,7 +145,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data 
*this)
unsigned int block_mark_bit_offset;
 
if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
-   return false;
+   return -EINVAL;
 
switch (chip->ecc_step_ds) {
case SZ_512:
@@ -158,19 +158,19 @@ static bool set_geometry_by_ecc_info(struct 
gpmi_nand_data *this)
dev_err(this->dev,
"unsupported nand chip. ecc bits : %d, ecc size : %d\n",
chip->ecc_strength_ds, chip->ecc_step_ds);
-   return false;
+   return -EINVAL;
}
geo->ecc_chunk_size = chip->ecc_step_ds;
geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
if (!gpmi_check_ecc(this))
-   return false;
+   return -EINVAL;
 
/* Keep the C >= O */
if (geo->ecc_chunk_size < mtd->oobsize) {
dev_err(this->dev,
"unsupported nand chip. ecc size: %d, oob size : %d\n",
chip->ecc_step_ds, mtd->oobsize);
-   return false;
+   return -EINVAL;
}
 
/* The default value, see comment in the legacy_set_geometry(). */
@@ -242,7 +242,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data 
*this)
+ ALIGN(geo->ecc_chunk_count, 4);
 
if (!this->swap_block_mark)
-   return true;
+   return 0;
 
/* For bit swap. */
block_mark_bit_offset = mtd->writesize * 8 -
@@ -251,7 +251,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data 
*this)
 
geo->block_mark_byte_offset = block_mark_bit_offset / 8;
geo->block_mark_bit_offset  = block_mark_bit_offset % 8;
-   return true;
+   return 0;
 }
 
 static int legacy_set_geometry(struct gpmi_nand_data *this)
@@ -285,7 +285,8 @@ static int legacy_set_geometry(struct gpmi_nand_data *this)
geo->ecc_strength = get_ecc_strength(this);
if (!gpmi_check_ecc(this)) {
dev_err(this->dev,
-   "required ecc strength of the NAND chip: %d is not 
supported by the GPMI controller (%d)\n",
+   "ecc strength: %d cannot be supported by the controller 
(%d)\n"
+   "try to use minimum ecc strength that NAND chip 
required\n",
geo->ecc_strength,
this->devdata->bch_max_ecc_strength);
return -EINVAL;
@@ -366,10 +367,11 @@ static int legacy_set_geometry(struct gpmi_nand_data 
*this)
 
 int common_nfc_set_geometry(struct gpmi_nand_data *this)
 {
-   if (of_property_read_bool(this->dev->of_node, "fsl,use-minimum-ecc")
-   && set_geometry_by_ecc_info(this))
-   return 0;
-   return legacy_set_geometry(this);
+   if ((of_property_read_bool(this->dev->of_node, "fsl,use-minimum-ecc"))
+   || legacy_set_geometry(this))
+   return set_geometry_by_ecc_info(this);
+
+   return 0;
 }
 
 struct dma_chan *get_dma_chan(struct gpmi_nand_data *this)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v7 3/7] dmaengine: mxs: add i.MX7D APBH DMA support

2015-10-27 Thread Han Xu
From: Adrian Alonso 

supports APBH DMA on i.MX7D by add extra clock clk_io

Signed-off-by: Fugang Duan 
Signed-off-by: Adrian Alonso 
Signed-off-by: Han Xu 
---
 drivers/dma/mxs-dma.c | 53 ---
 1 file changed, 46 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index b8a4822e..f1878d2 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2011-2015 Freescale Semiconductor, Inc. All Rights Reserved.
  *
  * Refer to drivers/dma/imx-sdma.c
  *
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-
 #include 
 
 #include "dmaengine.h"
@@ -135,6 +134,7 @@ enum mxs_dma_devtype {
 enum mxs_dma_id {
IMX23_DMA,
IMX28_DMA,
+   IMX7D_DMA,
 };
 
 struct mxs_dma_engine {
@@ -142,6 +142,7 @@ struct mxs_dma_engine {
enum mxs_dma_devtypetype;
void __iomem*base;
struct clk  *clk;
+   struct clk  *clk_io;
struct dma_device   dma_device;
struct device_dma_parametersdma_parms;
struct mxs_dma_chan mxs_chans[MXS_DMA_CHANNELS];
@@ -167,6 +168,9 @@ static struct mxs_dma_type mxs_dma_types[] = {
}, {
.id = IMX28_DMA,
.type = MXS_DMA_APBX,
+   }, {
+   .id = IMX7D_DMA,
+   .type = MXS_DMA_APBH,
}
 };
 
@@ -184,6 +188,9 @@ static const struct platform_device_id mxs_dma_ids[] = {
.name = "imx28-dma-apbx",
.driver_data = (kernel_ulong_t) &mxs_dma_types[3],
}, {
+   .name = "imx7d-dma-apbh",
+   .driver_data = (kernel_ulong_t) &mxs_dma_types[4],
+   }, {
/* end of list */
}
 };
@@ -193,6 +200,7 @@ static const struct of_device_id mxs_dma_dt_ids[] = {
{ .compatible = "fsl,imx23-dma-apbx", .data = &mxs_dma_ids[1], },
{ .compatible = "fsl,imx28-dma-apbh", .data = &mxs_dma_ids[2], },
{ .compatible = "fsl,imx28-dma-apbx", .data = &mxs_dma_ids[3], },
+   { .compatible = "fsl,imx7d-dma-apbh", .data = &mxs_dma_ids[4], },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, mxs_dma_dt_ids);
@@ -440,6 +448,13 @@ static int mxs_dma_alloc_chan_resources(struct dma_chan 
*chan)
if (ret)
goto err_clk;
 
+   /* enable the extra clk_io clock for i.MX7D */
+   if (mxs_dma->dev_id == IMX7D_DMA) {
+   ret = clk_prepare_enable(mxs_dma->clk_io);
+   if (ret)
+   goto err_clk_unprepare;
+   }
+
mxs_dma_reset_chan(chan);
 
dma_async_tx_descriptor_init(&mxs_chan->desc, chan);
@@ -450,6 +465,8 @@ static int mxs_dma_alloc_chan_resources(struct dma_chan 
*chan)
 
return 0;
 
+err_clk_unprepare:
+   clk_disable_unprepare(mxs_dma->clk);
 err_clk:
free_irq(mxs_chan->chan_irq, mxs_dma);
 err_irq:
@@ -471,6 +488,9 @@ static void mxs_dma_free_chan_resources(struct dma_chan 
*chan)
dma_free_coherent(mxs_dma->dma_device.dev, CCW_BLOCK_SIZE,
mxs_chan->ccw, mxs_chan->ccw_phys);
 
+   if (mxs_dma->dev_id == IMX7D_DMA)
+   clk_disable_unprepare(mxs_dma->clk_io);
+
clk_disable_unprepare(mxs_dma->clk);
 }
 
@@ -701,9 +721,15 @@ static int mxs_dma_init(struct mxs_dma_engine *mxs_dma)
if (ret)
return ret;
 
+   if (mxs_dma->dev_id == IMX7D_DMA) {
+   ret = clk_prepare_enable(mxs_dma->clk_io);
+   if (ret)
+   goto err_clk_bch;
+   }
+
ret = stmp_reset_block(mxs_dma->base);
if (ret)
-   goto err_out;
+   goto err_clk_io;
 
/* enable apbh burst */
if (dma_is_apbh(mxs_dma)) {
@@ -717,7 +743,10 @@ static int mxs_dma_init(struct mxs_dma_engine *mxs_dma)
writel(MXS_DMA_CHANNELS_MASK << MXS_DMA_CHANNELS,
mxs_dma->base + HW_APBHX_CTRL1 + STMP_OFFSET_REG_SET);
 
-err_out:
+err_clk_io:
+   if (mxs_dma->dev_id == IMX7D_DMA)
+   clk_disable_unprepare(mxs_dma->clk_io);
+err_clk_bch:
clk_disable_unprepare(mxs_dma->clk);
return ret;
 }
@@ -803,9 +832,19 @@ static int __init mxs_dma_probe(struct platform_device 
*pdev)
if (IS_ERR(mxs_dma->base))
return PTR_ERR(mxs_dma->base);
 
-   mxs_dma->clk = devm_clk_get(&pdev->dev, NULL);
-   if (IS_ERR(mxs_dma->clk))
-   return PTR_ERR(mxs_dma->clk);
+   if (mxs_dma->dev_id == IMX7D_DMA) {
+   mxs_dma->clk = devm_clk_get(&pdev->dev, "dma_apbh_bch");
+   if (IS_ERR(mxs_dma->clk))
+   return PTR_ERR(mxs_dma->clk);
+   mxs_dma->clk_io = devm_clk_get(&pdev->dev, "dma_apbh_io");
+   if (IS_ERR(mxs_dma->clk_io))
+  

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

2015-10-27 Thread Nishanth Aravamudan
On 26.10.2015 [18:27:46 -0700], David Miller wrote:
> From: Nishanth Aravamudan 
> Date: Fri, 23 Oct 2015 13:54:20 -0700
> 
> > 1) add a generic dma_get_page_shift implementation that just returns
> > PAGE_SHIFT
> 
> I won't object to this patch series, but if I had implemented this I
> would have required the architectures to implement this explicitly,
> one-by-one.  I think it is less error prone and more likely to end
> up with all the architectures setting this correctly.

Well, looks like I should spin up a v4 anyways for the powerpc changes.
So, to make sure I understand your point, should I make the generic
dma_get_page_shift a compile-error kind of thing? It will only fail on
architectures that actually build the NVME driver (as the only caller).
But I'm not sure how exactly to achieve that, if you could give a bit
more detail I'd appreciate it!

Thanks,
Nish

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v12 1/6] fpga: add usage documentation for simple fpga bus

2015-10-27 Thread atull
From: Alan Tull 

Add a document spelling out usage of the simple fpga bus.

Signed-off-by: Alan Tull 
---
v9:  Initial version of this patch in patchset
v10: s/fpga/FPGA/g
 improve formatting
 some rewriting
 move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging
 Small changes due to using FPGA bridge framework and not
 representing the bridges as resets.
---
 Documentation/fpga/simple-fpga-bus.txt |   58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/fpga/simple-fpga-bus.txt

diff --git a/Documentation/fpga/simple-fpga-bus.txt 
b/Documentation/fpga/simple-fpga-bus.txt
new file mode 100644
index 000..bd43478
--- /dev/null
+++ b/Documentation/fpga/simple-fpga-bus.txt
@@ -0,0 +1,58 @@
+Simple FPGA Bus
+
+Alan Tull 2015
+
+Overview
+
+
+The simple FPGA bus adds device tree overlay support for FPGA's.  Loading a
+DT overlay will result in the FPGA getting an image loaded, its bridges will
+be released, and the DT populated for nodes below the simple-fpga-bus.  This
+results in drivers getting probed for the hardware that just got added.  This
+is intended to support the FPGA usage where the FPGA has hardware that
+requires drivers.  Removing the overlay will result in the drivers getting
+removed and the bridges being disabled.
+
+The simple FPGA bus will need to disable and enable bridges that will only
+affect the child devices that are below the bus.  If partial reconfiguration
+is to be done, then bridges will need to be added within the FPGA design to
+protect the rest of the bus when one part of the FPGA design is being
+reconfigured.
+
+
+Sequence
+
+
+Load the DT overlay.  One way to do that from user space is to use Pantelis'
+DT-Overlay configfs interface.
+
+This causes the simple FPGA bus go be probed and will do the following:
+ 1. Disable the FPGA bridges.
+ 2. Call the FPGA manager core to program the FPGA.
+ 3. Release the FPGA bridges.
+ 4. Call of_platform_populate resulting in device drivers getting probed.
+
+
+Requirements
+
+
+ 1. An FPGA image that has a hardware block or blocks that use drivers that are
+supported in the kernel.
+ 2. A device tree overlay (example is in the simple-fpga-bus bindings 
document).
+ 3. A FPGA manager driver supporting writing the FPGA.
+ 4. FPGA bridge drivers.
+
+The DT overlay includes bindings (documented in bindings/simple-fpga-bus.txt)
+that specify:
+ * Which FPGA manager to use.
+ * Which image file to load.
+ * Flags indicating whether this this image is for full reconfiguration or
+   partial.
+ * A list of FPGA bridges.
+ * Child nodes specifying the devices that will be added with appropriate
+   compatible strings, etc.
+
+Since this code uses the firmware interface to get the image and DT overlay,
+they currently have to be files on the file system.  It doesn't have to be that
+way forever as DT bindings could be added to point to other sources for the
+image.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH V2] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

2015-10-27 Thread Nathan Sullivan
The USB OTG support currently depends on power management
(CONFIG_PM) being enabled, but does not actually need it enabled.
Remove this dependency.

Tested on Bay Trail hardware with dwc3 USB.

Signed-off-by: Nathan Sullivan 
---
 drivers/usb/core/Kconfig |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index a99c89e..567454f 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -43,8 +43,6 @@ config USB_DYNAMIC_MINORS
 
 config USB_OTG
bool "OTG support"
-   depends on PM
-   default n
help
  The most notable feature of USB OTG is support for a
  "Dual-Role" device, which can act as either a device
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v12 3/6] fpga: add simple-fpga-bus

2015-10-27 Thread atull
From: Alan Tull 

The Simple FPGA bus uses the FPGA Manager Framework and the
FPGA Bridge Framework to provide a manufactorer-agnostic
interface for reprogramming FPGAs that is Device Tree
Overlays-based.

When a Device Tree Overlay containing a Simple FPGA Bus is
applied, the Simple FPGA Bus will be probed and will:
 * Disable the FPGA bridges specified in the overlay
 * Reprogram a specified FPGA with a specified image file
 * Enable the specified FPGA bridges
 * Populate the child devices

Removing the Device Tree Overlay is also supported.

This supports fpga use where hardware blocks on a fpga will
need drivers.

Signed-off-by: Alan Tull 
---
v9:  initial version (this patch added during rest of patchset's v9)
v10: request deferral if fpga mgr or bridges not available yet
 cleanup as fpga manager core goes into the real kernel
 Don't assume bridges are disabled before programming FPGA
 Don't hang onto reference for fpga manager
 Move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Use fpga bridges framework.
---
 drivers/fpga/Kconfig   |7 +
 drivers/fpga/Makefile  |3 +
 drivers/fpga/simple-fpga-bus.c |  327 
 3 files changed, 337 insertions(+)
 create mode 100644 drivers/fpga/simple-fpga-bus.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 348e1dea..e8f5453 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -13,6 +13,13 @@ config FPGA
 
 if FPGA
 
+config SIMPLE_FPGA_BUS
+   bool "Simple FPGA Bus"
+   depends on OF
+   help
+ Simple FPGA Bus allows loading FPGA images under control of
+Device Tree.
+
 config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index bf0c0d2..0385622 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -8,3 +8,6 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 # FPGA Manager Drivers
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
+
+# High Level Interfaces
+obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
diff --git a/drivers/fpga/simple-fpga-bus.c b/drivers/fpga/simple-fpga-bus.c
new file mode 100644
index 000..6318cf1
--- /dev/null
+++ b/drivers/fpga/simple-fpga-bus.c
@@ -0,0 +1,327 @@
+/*
+ * Simple FPGA Bus
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct simple_fpga_bus - simple fpga bus private data
+ * @dev:   device from pdev
+ * @bridges:   FPGA bridges associated with this bus
+ * @num_bridges: size of the bridges array
+ */
+struct simple_fpga_bus {
+   struct device *dev;
+   struct fpga_bridge **bridges;
+   int num_bridges;
+};
+
+/**
+ * simple_fpga_bus_get_mgr - get associated fpga manager
+ * @priv: simple fpga bus private data
+ * pointer to fpga manager in priv->mgr on success
+ *
+ * Given a simple fpga bus, get a reference to its the fpga manager specified
+ * by its "fpga-mgr" device tree property.
+ *
+ * Return: 0 if the fpga manager is not specified.
+ * pointer to struct fpga_manager if successful.
+ * Negative error code otherwise.
+ */
+static struct fpga_manager *simple_fpga_bus_get_mgr(
+   struct simple_fpga_bus *priv)
+{
+   struct device *dev = priv->dev;
+   struct device_node *np = dev->of_node;
+   struct device_node *mgr_node;
+
+   /*
+* Return 0 (not an error) if fpga manager is not specified.
+* This supports the case where fpga was already configured.
+*/
+   mgr_node = of_parse_phandle(np, "fpga-mgr", 0);
+   if (!mgr_node) {
+   dev_dbg(dev, "could not find fpga-mgr DT property\n");
+   return 0;
+   }
+
+   return of_fpga_mgr_get(mgr_node);
+}
+
+/**
+ * simple_fpga_bus_load_image - load an fpga image under device tree control
+ * @priv: simple fpga bus private data
+ *
+ * Given a simple fpga bus, load the fpga image specified in its device
+ * tree node.
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+static int simple_fpga_bus_load_image(struct simple_fpga_bus *pr

Re: [PATCH v5 1/4] media: pxa_camera: fix the buffer free path

2015-10-27 Thread Robert Jarzmik
Guennadi Liakhovetski  writes:

> Hi Robert,
>
> Didn't you tell me, that your dmaengine patch got rejected and therefore 
> these your patches were on hold?
They were reverted, and then revamped into DMA_CTRL_REUSE, upstreamed and
merged, as in the commit 272420214d26 ("dmaengine: Add DMA_CTRL_REUSE"). I'd

Of course a pending fix is still underway
(http://www.serverphorums.com/read.php?12,1318680). But that shouldn't stop us
from reviewing to get ready to merge.

I want this serie to be ready, so that as soon as Vinod merges the fix, I can
ping you to trigger the merge into your tree, without doing (and waiting)
additional review cycles.

Cheers.

--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3.19.y-ckt 04/86] KEYS: Don't permit request_key() to construct a new keyring

2015-10-27 Thread Kamal Mostafa
3.19.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: David Howells 

commit 911b79cde95c7da0ec02f48105358a36636b7a71 upstream.

If request_key() is used to find a keyring, only do the search part - don't
do the construction part if the keyring was not found by the search.  We
don't really want keyrings in the negative instantiated state since the
rejected/negative instantiation error value in the payload is unioned with
keyring metadata.

Now the kernel gives an error:

request_key("keyring", "#selinux,bdekeyring", "keyring", 
KEY_SPEC_USER_SESSION_KEYRING) = -1 EPERM (Operation not permitted)

Signed-off-by: David Howells 
Signed-off-by: Kamal Mostafa 
---
 security/keys/request_key.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index 0c7aea4..19bbe5e6 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -439,6 +439,9 @@ static struct key *construct_key_and_link(struct 
keyring_search_context *ctx,
 
kenter("");
 
+   if (ctx->index_key.type == &key_type_keyring)
+   return ERR_PTR(-EPERM);
+   
user = key_user_lookup(current_fsuid());
if (!user)
return ERR_PTR(-ENOMEM);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 4/7 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

2015-10-27 Thread Nishanth Aravamudan
On 27.10.2015 [16:56:10 +1100], Alexey Kardashevskiy wrote:
> On 10/24/2015 07:59 AM, Nishanth Aravamudan wrote:
> >When DDW (Dynamic DMA Windows) are present for a device, we have stored
> >the TCE (Translation Control Entry) size in a special device tree
> >property. Check if we have enabled DDW for the device and return the TCE
> >size from that property if present. If the property isn't present,
> >fallback to looking the value up in struct iommu_table. If we don't find
> >a iommu_table, fallback to the kernel's page size.
> >
> >Signed-off-by: Nishanth Aravamudan 
> >---
> >  arch/powerpc/platforms/pseries/iommu.c | 36 
> > ++
> >  1 file changed, 36 insertions(+)
> >
> >diff --git a/arch/powerpc/platforms/pseries/iommu.c 
> >b/arch/powerpc/platforms/pseries/iommu.c
> >index 0946b98..1bf6471 100644
> >--- a/arch/powerpc/platforms/pseries/iommu.c
> >+++ b/arch/powerpc/platforms/pseries/iommu.c
> >@@ -1292,6 +1292,40 @@ static u64 dma_get_required_mask_pSeriesLP(struct 
> >device *dev)
> > return dma_iommu_ops.get_required_mask(dev);
> >  }
> >
> >+static unsigned long dma_get_page_shift_pSeriesLP(struct device *dev)
> >+{
> >+struct iommu_table *tbl;
> >+
> >+if (!disable_ddw && dev_is_pci(dev)) {
> >+struct pci_dev *pdev = to_pci_dev(dev);
> >+struct device_node *dn;
> >+
> >+dn = pci_device_to_OF_node(pdev);
> >+
> >+/* search upwards for ibm,dma-window */
> >+for (; dn && PCI_DN(dn) && !PCI_DN(dn)->table_group;
> >+dn = dn->parent)
> >+if (of_get_property(dn, "ibm,dma-window", NULL))
> >+break;
> >+/*
> >+ * if there is a DDW configuration, the TCE shift is stored in
> >+ * the property
> >+ */
> >+if (dn && PCI_DN(dn)) {
> >+const struct dynamic_dma_window_prop *direct64 =
> >+of_get_property(dn, DIRECT64_PROPNAME, NULL);
> 
> 
> This DIRECT64_PROPNAME property is only present under pHyp, QEMU/KVM
> does not set it as 64bit windows are dynamic there so something like
> find_existing_ddw() needs to be used here.

DIRECT64_PROPNAME is a Linux thing, not a pHyp or QEMU/KVM thing -- it's
created by the Linux DDW logic and left in the device-tree when we
successfully configure DDW.

You're right, though, that logically find_existing_ddw() would be better
to use here. I'll spin up a new version.

-Nish

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v12 4/5] null_nvm: LightNVM test driver

2015-10-27 Thread kbuild test robot
Hi Matias,

[auto build test ERROR on next-20151022 -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Matias-Bj-rling/Support-for-Open-Channel-SSDs/20151027-230440
config: i386-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `addr_to_generic_mode':
   gennvm.c:(.text+0x88e078): undefined reference to `__umoddi3'
   gennvm.c:(.text+0x88e090): undefined reference to `__udivdi3'
   gennvm.c:(.text+0x88e0a1): undefined reference to `__umoddi3'
   gennvm.c:(.text+0x88e0c7): undefined reference to `__udivdi3'
   gennvm.c:(.text+0x88e0d5): undefined reference to `__umoddi3'
   gennvm.c:(.text+0x88e10d): undefined reference to `__udivdi3'
   gennvm.c:(.text+0x88e11b): undefined reference to `__umoddi3'
   gennvm.c:(.text+0x88e144): undefined reference to `__udivdi3'
   drivers/built-in.o: In function `gennvm_block_map':
   gennvm.c:(.text+0x88e298): undefined reference to `__udivdi3'
   gennvm.c:(.text+0x88e2c9): undefined reference to `__udivdi3'
   drivers/built-in.o: In function `gennvm_erase_blk':
   gennvm.c:(.text+0x88e459): undefined reference to `__umoddi3'
   drivers/built-in.o: In function `__linear_to_generic_addr':
   rrpc.c:(.text+0x88e961): undefined reference to `__umoddi3'
   rrpc.c:(.text+0x88e979): undefined reference to `__udivdi3'
   rrpc.c:(.text+0x88e98a): undefined reference to `__umoddi3'
   rrpc.c:(.text+0x88e9b0): undefined reference to `__udivdi3'
   rrpc.c:(.text+0x88e9be): undefined reference to `__umoddi3'
   rrpc.c:(.text+0x88e9f6): undefined reference to `__udivdi3'
   rrpc.c:(.text+0x88ea04): undefined reference to `__umoddi3'
   rrpc.c:(.text+0x88ea2d): undefined reference to `__udivdi3'
   drivers/built-in.o: In function `rrpc_capacity':
   rrpc.c:(.text+0x88ebd7): undefined reference to `__udivdi3'
   drivers/built-in.o: In function `rrpc_page_invalidate':
   rrpc.c:(.text+0x88ef75): undefined reference to `__umoddi3'
   drivers/built-in.o: In function `null_id':
>> null_nvm.c:(.text+0x890537): undefined reference to `__udivdi3'
   null_nvm.c:(.text+0x89054b): undefined reference to `__udivdi3'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


[PATCH/RFC] make btrfs subvol mounts appear in /proc/mounts

2015-10-27 Thread Neil Brown

If you create a subvolume in btrfs and access it (by name) without
mounting it, then the subvolume looks like a separate mount to some
extent, returning a different st_dev to stat(), but it doesn't look like
a separate mount in that it isn't listed in /proc/mounts. This
inconsistency can confuse tools.

This patch causes these subvolumes to become separate mounts by using
the VFS' automount functionality, much like NFS uses automount when it
discovered mountpoints on the server.

The VFS currently makes it impossible to auto-mount a directory on to itself
(i.e. a bind mount).  For NFS this isn't a problem as a new superblock
is created for the child filesystem so there are two separate dentries
(and inodes) for the one directory: one in the parent filesystem, one in
the child (note that the two superblocks share a common connection to
the server so there is still a lot of commonality).

BTRFS has chosen instead to use a single superblock for all subvolumes.
This results in a single dentry for the subvol-root.  A dentry which
must be auto-mounted on itself.

This creates 2 problems.
Firstly, we want to be selective about when the dentry triggers an
automount.  When the dentry is not the root of a vfsmount, we do want to
trigger an automount.  When it is the root, we don't.
I have modified follow_managed() to understand that if ->d_manage()
returns 1, then an automount should be suppressed when
  path->mnt->mnt_root == path->dentry.

Secondly, finish_automount() explicitly tests for the case of mounting a
dentry on top of itself and fails with -ELOOP.  I've changed this to
only fail if the mounted-on directory is the root in its own vfsmount.
So now mounting a dentry on itself can be OK, but mounting the same
dentry on top of that will cause -ELOOP.

With those two VFS changes, it is straight forward to enable automounts for
btrfs subvolumes and to use clone_private_mount to create the required
vfsmount.

I have not added infrastructure to time-out the submounts after a period
of inactivity in the way that NFS does.  If that is desirable (I'm not
sure of the benefits) it can easily be added as a subsequent patch.

If this approach is acceptable, I will resubmit addressing any issues
raised and with proper updates for the automount documentation.

Thanks for any comments,
NeilBrown


diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 611b66d73e80..e96c53590f72 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -5621,6 +5621,23 @@ static void btrfs_dentry_release(struct dentry *dentry)
kfree(dentry->d_fsdata);
 }
 
+static int btrfs_dentry_manage(struct dentry *dentry, bool in_rcu)
+{
+   /* This is a 'rebind automount'.  So only trigger automount
+* when the dentry isn't the root of a mountpoint.
+*/
+   return 1;
+}
+
+static struct vfsmount *btrfs_dentry_automount(struct path *path)
+{
+   struct vfsmount *mnt;
+   mnt = clone_private_mount(path);
+   if (!IS_ERR(mnt))
+   mntget(mnt);
+   return mnt;
+}
+
 static struct dentry *btrfs_lookup(struct inode *dir, struct dentry *dentry,
   unsigned int flags)
 {
@@ -5633,6 +5650,8 @@ static struct dentry *btrfs_lookup(struct inode *dir, 
struct dentry *dentry,
else
return ERR_CAST(inode);
}
+   if (inode && inode->i_ino == BTRFS_FIRST_FREE_OBJECTID)
+   dentry->d_flags |= DCACHE_MANAGE_TRANSIT | 
DCACHE_NEED_AUTOMOUNT;
 
return d_splice_alias(inode, dentry);
 }
@@ -9990,4 +10009,6 @@ static const struct inode_operations 
btrfs_symlink_inode_operations = {
 const struct dentry_operations btrfs_dentry_operations = {
.d_delete   = btrfs_dentry_delete,
.d_release  = btrfs_dentry_release,
+   .d_manage   = btrfs_dentry_manage,
+   .d_automount= btrfs_dentry_automount,
 };
diff --git a/fs/namei.c b/fs/namei.c
index 33e9495a3129..07e4bbbadae1 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1178,6 +1178,7 @@ static int follow_managed(struct path *path, struct 
nameidata *nd)
   unlikely(managed != 0)) {
/* Allow the filesystem to manage the transit without i_mutex
 * being held. */
+   ret = 0;
if (managed & DCACHE_MANAGE_TRANSIT) {
BUG_ON(!path->dentry->d_op);
BUG_ON(!path->dentry->d_op->d_manage);
@@ -1207,7 +1208,12 @@ static int follow_managed(struct path *path, struct 
nameidata *nd)
 
/* Handle an automount point */
if (managed & DCACHE_NEED_AUTOMOUNT) {
-   ret = follow_automount(path, nd, &need_mntput);
+   if (ret == 1 && path->mnt->mnt_root == path->dentry) {
+   /* only automount when not the root */
+   ret = 0;
+   break;
+   } else
+ 

Re: [PATCH 2/7 v2] powerpc/dma-mapping: override dma_get_page_shift

2015-10-27 Thread Nishanth Aravamudan
On 27.10.2015 [17:02:16 +1100], Alexey Kardashevskiy wrote:
> On 10/24/2015 07:57 AM, Nishanth Aravamudan wrote:
> >On Power, the kernel's page size can differ from the IOMMU's page size,
> >so we need to override the generic implementation, which always returns
> >the kernel's page size. Lookup the IOMMU's page size from struct
> >iommu_table, if available. Fallback to the kernel's page size,
> >otherwise.
> >
> >Signed-off-by: Nishanth Aravamudan 
> >---
> >  arch/powerpc/include/asm/dma-mapping.h | 3 +++
> >  arch/powerpc/kernel/dma.c  | 9 +
> >  2 files changed, 12 insertions(+)
> >
> >diff --git a/arch/powerpc/include/asm/dma-mapping.h 
> >b/arch/powerpc/include/asm/dma-mapping.h
> >index 7f522c0..c5638f4 100644
> >--- a/arch/powerpc/include/asm/dma-mapping.h
> >+++ b/arch/powerpc/include/asm/dma-mapping.h
> >@@ -125,6 +125,9 @@ static inline void set_dma_offset(struct device *dev, 
> >dma_addr_t off)
> >  #define HAVE_ARCH_DMA_SET_MASK 1
> >  extern int dma_set_mask(struct device *dev, u64 dma_mask);
> >
> >+#define HAVE_ARCH_DMA_GET_PAGE_SHIFT 1
> >+extern unsigned long dma_get_page_shift(struct device *dev);
> >+
> >  #include 
> >
> >  extern int __dma_set_mask(struct device *dev, u64 dma_mask);
> >diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
> >index 59503ed..e805af2 100644
> >--- a/arch/powerpc/kernel/dma.c
> >+++ b/arch/powerpc/kernel/dma.c
> >@@ -335,6 +335,15 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
> >  }
> >  EXPORT_SYMBOL(dma_set_mask);
> >
> >+unsigned long dma_get_page_shift(struct device *dev)
> >+{
> >+struct iommu_table *tbl = get_iommu_table_base(dev);
> >+if (tbl)
> >+return tbl->it_page_shift;
> 
> 
> All PCI devices have this initialized on POWER (at least, our, IBM's
> POWER) so 4K will always be returned here while in the case of
> (get_dma_ops(dev)==&dma_direct_ops) it could actually return
> PAGE_SHIFT. Is 4K still preferred value to return here?

Right, so the logic of my series, goes like this:

a) We currently are assuming DMA_PAGE_SHIFT (conceptual constant) is
PAGE_SHIFT everywhere, including Power.

b) After 2/7, the Power code will return either the IOMMU table's shift
value, if set, or PAGE_SHIFT (I guess this would be the case if
get_dma_ops(dev) == &dma_direct_ops, as you said). That is no different
than we have now, except we can return the accurate IOMMU value if
available.

3) After 3/7, the platform can override the generic Power
get_dma_page_shift().

4) After 4/7, pseries will return the DDW value, if available, then
fallback to the IOMMU table's value. I think in the case of
get_dma_ops(dev)==&dma_direct_ops, the only way that can happen is if we
are using DDW, right?

-Nish

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] drivers:staging:wlan_ng Fix no space is necessary after a cast

2015-10-27 Thread Bogicevic Sasa

It should be fine, I meant in a sence nothing is accepted from me yet
On 10/28, Greg KH wrote:

On Tue, Oct 27, 2015 at 09:35:35AM -0200, Albino B Neto wrote:

2015-10-27 9:24 GMT-02:00 Bogicevic Sasa :
> This fixes "No space is necessary after a cast" messages from
> checkpatch.pl
>
> Signed-off-by: Bogicevic Sasa 

Tips for read: https://www.kernel.org/doc/Documentation/CodingStyle


What does that mean?  What is wrong with this patch?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH V5 2/6] watchdog: Add support for Freescale Layerscape platforms

2015-10-27 Thread Li Yang
Hi Wim,

Can you help to review the patch and pick it for the next merge window?

Regards,
Leo

On Mon, Oct 19, 2015 at 6:56 AM, Zhiqiang Hou  wrote:
> From: Shaohui Xie 
>
> Modify watchdog/Kconfig file to support Layerscape platforms.
>
> Signed-off-by: Shaohui Xie 
> Signed-off-by: Wenbin Song 
> Signed-off-by: Hou Zhiqiang 
> Acked-by: Guenter Roeck 
> ---
> V5: V4 V3 V2
>  - No change.
>
>  drivers/watchdog/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 79e1aa1..448dbaf 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -446,7 +446,7 @@ config MAX63XX_WATCHDOG
>
>  config IMX2_WDT
> tristate "IMX2+ Watchdog"
> -   depends on ARCH_MXC
> +   depends on ARCH_MXC || ARCH_LAYERSCAPE
> select REGMAP_MMIO
> select WATCHDOG_CORE
> help
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v12 0/8] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

2015-10-27 Thread Bjorn Helgaas
Hi Zhou,

On Mon, Oct 26, 2015 at 07:35:42PM +0800, Zhou Wang wrote:
> This patchset adds PCIe host support for HiSilicon SoC Hip05. The PCIe hosts
> use PCIe IP core from Synopsys, So this driver is based on designware PCIe 
> driver.
> 
> Hip05 is an ARMv8 architecture SoC. It should be able to use ARM64 PCIe API in
> designware PCIe driver. So this patch also adds ARM64 support for designware
> pcie.
> 
> This patchset is based on v4.3-rc1.

OK, this is pretty close to being ready to go.  But the patch ordering is
more complicated than it needs to be.  You have:

  PCI: designware: move calculation of bus addresses to DRA7xx
  ARM/PCI: remove align_resource in pci_sys_data
  PCI: designware: Replace DT PCI ranges parse with 
of_pci_get_host_bridge_resources
  PCI: designware: Add ARM64 support
  PCI: designware: Remove *_mod_base
  PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
  Documentation: DT: Add HiSilicon PCIe host binding
  MAINTAINERS: Add pcie-hisi maintainer

But you should have this:

  PCI: designware: Move calculation of bus addresses to DRA7xx
  PCI: designware: Remove *_mod_base
  PCI: designware: Replace DT PCI ranges parse with 
of_pci_get_host_bridge_resources
  ARM/PCI: remove align_resource in pci_sys_data
  PCI: designware: Add ARM64 support
  PCI: hisi: Add HiSilicon SoC Hip05 driver

In other words,

  - capitalize the subject lines correctly (follow previous practice),
  - do all the bus address patches together,
  - then the ARM sysdata tweak,
  - then add ARM64 support,
  - then add HiSilicon,
  - and merge the hisi driver, DT update, and maintainer update into one
patch since they're all one package.

If you do them out of order, the changes get tangled up and it makes them
harder to backport and harder to revert individually.

Bjorn

> Change from v11:
> - Split 3/6 in v11 to 3/8, 4/8, 5/8 in v12.
> - Add print in pcie-hisi.c to indicate read/write hardware defect.
> - Modify macro in 1/8 pointed by Bjorn.
> 
> Change from v10:
> - Remove MSI related setting and VMID/ASID table setting, they will be
>   implemented in BIOS.
> - Use module_platform_driver to init pcie-hisi.c
> - Add necessary comments.
> 
> Change from v9:
> - Use syscon to get subctrl base address.
> - 5/6 is based on [PATCH v3 0/2] arm64: Support Hisilicon Hip05-D02 board
>   from Ding Tianhong
> - Add hisi_pcie_cfg_read in pcie-hisi.c to match
>   [PATCH v6 0/3] PCI: designware: change dw_pcie_cfg_write() and 
> dw_pcie_cfg_read()
>   from Gabriele.
> 
> Change from v8:
> - Rebase on v4.3-rc1.
> - Add Tested-by from Gabriel and Minghuan.
> - Remove ITS domain parsing in msi_host_init in pcie-hisi.c, no need this as 
> PCI
>   core does related job. Add ITS base address parsing in msi_host_init.
> - Change vmid/asid table configuration, previous configuration was wrong.
> - Add wr_own_conf callback in pcie-hisi.c.
> - Use subsys_initcall to init hisi PCIe.
> 
> Change from v7:
> - Remove pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
>   spear13xx. Pass pp->busn->start to pci_create_root_bus as root bus number.
> - Remove bus-range parsing in pcie-hisi.c.
> 
> Change from v6:
> - Add Pratyush's Acked-by for 1/6 and 2/6.
> - Add James' Tested-by for 3/6.
> 
> Change from v5:
> - Merge 1/6 in this series, discussion about this can be found in [1]
> 
> Change from v4:
> - Change the author of 1/5 to Gabriele.
> - Modify problems in 3/5 pointed by Bjorn.
> - Modify spelling problems in 4/5.
> 
> Change from v3:
> - Change 1/5 to what Gabriele suggested.
> - Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3 series.
> 
> Change from v2:
> - Move struct pci_dev *dev and struct pci_sys_data *sys in
>   pcibios_align_resource in 1/5.
> - Add Gabriele's codes in 2/5 which delete unnecessary information parse and
>   use of_pci_get_host_bridge_resources for both ARM32 and ARM64.
> - Add maintainer patch 5/5.
> 
> Change from RFC v1:
> - Add 1/4 patch by Arnd which removes align_resource callback in ARM
>   pcibios_align_resource.
> - Change head file in pcie-designware from asm/hardirq.h to linux/hardirq.h.
> - Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
>   spear13xx.
> - Remove unnecessary parentheses of some macros in pcie-hisi.
> - Use macro to replace some magic values.
> - Merge two loops together and add some comments about it in context_config
>   function in pcie-hisi.
> - Modify some value of items in pcie node example in binding document. 
> 
> Change from RFC:
> - delete dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
>   merge related operations into dw_pcie_host_init.
> 
> Link of v11:
> - https://lkml.org/lkml/2015/10/16/228
> Link of v10:
> - http://www.spinics.net/lists/linux-pci/msg45490.html
> Link of v9:
> - http://www.spinics.net/lists/linux-pci/msg44545.html
> Link of v8:
> - http://www.spinics.net/lists/linux-pci/msg44192.html
> Link of v7:
> - http://www.spinics.net/lists/devicetree/msg90690.html

Re: [PATCH net-next] hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event

2015-10-27 Thread Richard Weinberger
On Mon, Jun 23, 2014 at 10:10 PM, David Miller  wrote:
> From: Haiyang Zhang 
> Date: Mon, 23 Jun 2014 16:09:59 +
>
>> So, what's the equivalent or similar command to "network restart" on SLES12? 
>> Could
>> you update the command line for the usermodehelper when porting this patch 
>> to SLES
>> 12?
>
> No, you are not going to keep the usermodehelper invocation in your driver
> please remove it.  It is absolutely inappropriate, and I strictly do not want
> to keep it in there because other people will copy it and then we'll have a
> real mess on our hands.

Sorry for digging up this old thread.
While talking with some guys about usermodehelper abuses I came across this gem.
Mainline still contains that "/etc/init.d/network restart" code.
Haiyang, care to cleanup?

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 0/4] x86: sigcontext fixes, again

2015-10-27 Thread Linus Torvalds
On Tue, Oct 27, 2015 at 11:05 PM, Stas Sergeev  wrote:
>
> I can't easily post an Oops: under X it doesn't even appear -
> machine freezes immediately, and under non-KMS console it is
> possible to get one, but difficult to screen-shot (using bare
> metal, not VM). Also the Oops was seemingly unrelated.
> And if you run "dosemu -s" under non-KMS console, you'll also
> reproduce this one:
> https://bugzilla.kernel.org/show_bug.cgi?id=97321

Hmm. Andrew Morton responded to that initially, but then nothing
happened, and now it's been another six months. Andrew?

The arch/x86/mm/pat.c error handling does seem to be suspect. This is
all code several years old, so none of this is new, and I think Suresh
is gone.  Adding a few other people with recent sign-offs to that
file, in the hope that somebody feels like they own it..

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

2015-10-27 Thread Busch, Keith
On Tue, Oct 27, 2015 at 03:20:10PM -0700, Nishanth Aravamudan wrote:
> On 26.10.2015 [18:27:46 -0700], David Miller wrote:
> > From: Nishanth Aravamudan 
> > Date: Fri, 23 Oct 2015 13:54:20 -0700
> > 
> > > 1) add a generic dma_get_page_shift implementation that just returns
> > > PAGE_SHIFT
> > 
> > I won't object to this patch series, but if I had implemented this I
> > would have required the architectures to implement this explicitly,
> > one-by-one.  I think it is less error prone and more likely to end
> > up with all the architectures setting this correctly.
> 
> Well, looks like I should spin up a v4 anyways for the powerpc changes.
> So, to make sure I understand your point, should I make the generic
> dma_get_page_shift a compile-error kind of thing? It will only fail on
> architectures that actually build the NVME driver (as the only caller).
> But I'm not sure how exactly to achieve that, if you could give a bit
> more detail I'd appreciate it!

If you're suggesting to compile-time break architectures that currently
work just fine with NVMe, let me stop you right there.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 4.3-rc7: kmemleak BUG: Redzone overwritten

2015-10-27 Thread Andy Shevchenko
On Wed, Oct 28, 2015 at 12:16 AM, Linus Torvalds
 wrote:
> On Wed, Oct 28, 2015 at 12:46 AM, Aaro Koskinen  
> wrote:
>>
>> With 4.3-rc7 and slub_debug=FZUP, I get the below when reading
>> /sys/kernel/debug/kmemleak with a large number of reported entries.
>> It's pretty repeatable. HW is MIPS64.
>>
>> With the SLUB debugging disabled, box crashes randomly in kmem_cache_free
>> or kmem_cache_alloc when the kmemleak file is read on a running system.
>>
>> Seems to start with 6fc37c490076 ("kmemleak: use seq_hex_dump() to
>> dump buffers").
>
> Well, so that commit itself looks fine - it just uses the seq accessor
> functions to print things out, instead of doing it by hand.
>
> So if that commit causes problems, then I suspect that the real issue
> is that seq_hex_dump() itself is buggered, and that the commit just
> exposed it by adding new use-cases. It looks like the hexdump wrote
> one byte (the terminating NUL) past the end of the buffer:
>
>> [   77.706871] BUG kmalloc-4096 (Not tainted): Redzone overwritten
>> [   77.706877]
>> [   77.706894] INFO: 0x80002e939000-0x80002e939000. First byte 0x0 
>> instead of 0xcc
>> [   77.706914] INFO: Allocated in seq_buf_alloc+0x24/0x58 age=452 cpu=2 
>> pid=587
>> [   77.706928]  __slab_alloc.isra.72.constprop.75+0x4a4/0x508
>> [   77.706938]  __kmalloc+0x30c/0x3f0
>> [   77.706947]  seq_buf_alloc+0x24/0x58
>> [   77.706956]  seq_read+0x304/0x4a0
>> [   77.706968]  __vfs_read+0x3c/0x100
>> [   77.706977]  vfs_read+0x8c/0x138
>> [   77.706987]  SyS_read+0x64/0xe8
>> [   77.707000]  syscall_common+0x34/0x58
>> [   77.707012] INFO: Freed in seq_release+0x24/0x40 age=3450 cpu=3 pid=584
>> [   77.707023]  __slab_free+0x340/0x4f0
>> [   77.707032]  seq_release+0x24/0x40
>> [   77.707044]  kernfs_fop_release+0x50/0x80
>> [   77.707055]  __fput+0xa4/0x218
>> [   77.707066]  task_work_run+0xb0/0x108
>> [   77.707078]  work_notifysig+0x10/0x18
>> [   77.707087] INFO: Slab 0x83ec4440 objects=7 used=1 
>> fp=0x80002e93e7b0 flags=0x20004081
>> [   77.707095] INFO: Object 0x80002e938000 @offset=0 
>> fp=0x80002e939148
>> [   77.707095]
>> [   77.707108] Object 80002e938000: 75 6e 72 65 66 65 72 65 6e 63 65 64 
>> 20 6f 62 6a  unreferenced obj
>> [   77.707118] Object 80002e938010: 65 63 74 20 30 78 38 30 30 30 30 30 
>> 30 30 32 66  ect 0x80002f
> ...
>> [   77.709583] Object 80002e938f90: 6d 6d 20 22 73 77 61 70 70 65 72 2f 
>> 30 22 2c 20  mm "swapper/0",
>> [   77.709593] Object 80002e938fa0: 70 69 64 20 31 2c 20 6a 69 66 66 69 
>> 65 73 20 34  pid 1, jiffies 4
>> [   77.709603] Object 80002e938fb0: 32 39 34 39 33 38 30 35 31 20 28 61 
>> 67 65 20 34  294938051 (age 4
>> [   77.709613] Object 80002e938fc0: 31 2e 35 37 30 73 29 0a 20 20 68 65 
>> 78 20 64 75  1.570s).  hex du
>> [   77.709623] Object 80002e938fd0: 6d 70 20 28 66 69 72 73 74 20 33 32 
>> 20 62 79 74  mp (first 32 byt
>> [   77.709633] Object 80002e938fe0: 65 73 29 3a 0a 20 20 20 20 36 62 20 
>> 36 62 20 36  es):.6b 6b 6
>> [   77.709643] Object 80002e938ff0: 62 20 36 62 20 36 62 20 36 62 20 36 
>> 62 20 00 20  b 6b 6b 6b 6b .
>> [   77.709653] Redzone 80002e939000: 00 cc cc cc cc cc cc cc 
>>  
>
> So I suspect that some seq function ends up adding a terminating NUL
> character too much when the buffer overflows.
>
> The obvious suspect would be the "hex_dump_to_buffer()" call in
> seq_hex_dump(). It's the only thing that doesn't use really common
> core helpers, though.
>
> Looking at "hex_dump_to_buffer()", code like this strikes me as
> particularly dangerous:
>
> if (linebuflen < lx + 3)
> goto overflow2;


Just send couple of minutes before a message (pity it was in html, due
to was sent from phone). Similar suspicion.



>  ...
> overflow2:
> linebuf[lx++] = '\0';
> overflow1:
> return ascii ? ascii_column + len : (groupsize * 2 + 1) *
> ngroups - 1;
>
> because what if lx == linebuflen in the overflow condition.
>
> But the non-overflow condition looks a bit scary too: the
> "non-overflow" case checks that there is room for three characters,
> and then adds those three characters (and possible removes the last
> one). Fine - but what if the three characters *exactly* filled the
> buffer, and we think we haven't overflowed, and now we just do
>
> nil:
> linebuf[lx] = '\0';
> return lx;
>
> there as the "success" case.
>
> So without trying to really analyze this, I do suspect that the
> problem is in either of those cases.
>
> I would suggest the "nil:" case do
>
> nil:
> if (lx < linebuflen)
> linebuf[lx] = 0;
> return lx;
>
> and add something similar to overflow2 too.

I don't think it should be fixed like this.
All other cases are checking for room correctly (if I didn't miss anything).

Here I would like to repeat the snpr

Re: 4.3-rc7: kmemleak BUG: Redzone overwritten

2015-10-27 Thread Linus Torvalds
On Wed, Oct 28, 2015 at 7:39 AM, Andy Shevchenko
 wrote:
>
> I don't think it should be fixed like this.

Right. The seqfile code really doesn't care about the terminating NUL
character, and just cares that the buffer isn't overwritten past the
end. But other users of the hex dump code may need the final NUL for
the overflow case, and would want the text itself to be truncated
rather than dropping the NUL.

So I'm certainly fine with your approach too. Aaro, can you check
Andy's version instead of mine?

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] x86/cpufeature: Add CLZERO feature

2015-10-27 Thread Borislav Petkov
On Tue, Oct 27, 2015 at 11:48:02AM -0500, Aravind Gopalakrishnan wrote:
> Forgot to ask earlier about this-
> Shall I still sanitize the comments to say "AMD extended features 1" for
> 0x8001,ecx
> and "AMD extended features 2" for 0x8008, ebx?

Just use the cpufeature.h nomenclature:

/* AMD-defined CPU features, CPUID level 0x8008, word 13 */

or so...

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Intel-wired-lan] [PATCHv2] ixgbe: Wait for 1ms, not 1us, after RST

2015-10-27 Thread Peter Hurley
On 10/27/2015 02:35 PM, ND Linux CI Server wrote:
> Greetings,
> 
> This email is automatically generated by ND's Linux Patch Testing framework
> based on aiaiai. I have performed some automatic testing of a patch (series)
> you submitted to intel-wired-...@lists.osuosl.org
> 
> The following contains output of any tests which failed to pass, and might be
> the result of developer error. The tests performed include but may not be
> limited to checkpatch.pl, bisection testing, compilation on a default kernel
> config, coccinelle scripts, cppcheck, and smatch.
> 
> If you have received this email in error, or believe that aiaiai has detected 
> a
> false positive, please email Jacob Keller .

False positive.

As long as the delay is at least 1ms (which is guaranteed), slightly longer
delays (relative to the existing reset delay of 100ms) are not harmful.

Use of usleep_range() would be unnecessary overkill for the purpose.

Regards,
Peter Hurley


> ---
> 
> I have tested your changes
> 
> [Intel-wired-lan] [PATCHv2] ixgbe: Wait for 1ms, not 1us, after RST
> 
> Project: net (net-current development queue)
> 
> Configurations: intel_defconfig,x86
> 
> Tested the patch(es) on top of the following commits:
> 505b857 ixgbe: Reset interface after enabling SR-IOV
> ce9d9b8 net: sysctl: fix a kmemleak warning
> 1acea4f ppp: fix pppoe_dev deletion condition in pppoe_release()
> f6b8dec9 af_key: fix two typos
> 
> 
> 
> Successfully built configuration "intel_defconfig,x86", no issues.
> 
> 
> 
> checkpatch.pl has some complaints:
> 
> 
> 
> checkpatch.pl results for patch "[PATCH] ixgbe: Wait for 1ms, not 1us, after 
> RST"
> 
> WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see 
> Documentation/timers/timers-howto.txt
> #29: FILE: drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c:119:
> + msleep(1);
> 
> total: 0 errors, 1 warnings, 0 checks, 13 lines checked
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 3/5] mtd: ofpart: update devicetree binding specification

2015-10-27 Thread Brian Norris
Hi Rob,

Thanks for the review.

On Mon, Oct 26, 2015 at 11:35:24PM -0500, Rob Herring wrote:
> On Sun, Oct 11, 2015 at 3:04 PM, Brian Norris
>  wrote:
> > Hi DT maintainers,
> >
> > It's a bit hypocritical of me, since I've been a slow reviewer as well,
> > but... can we get some review on this one? Usually, I'm comfortable
> > taking driver DT bindings without your review, but this one is a bit
> > more generic and is more far-reaching than the average driver.
> 
> Sorry, missed this one. This would be a good one to send to
> devicetree-spec to BTW.

I'm not very familiar with that list. With the intention of getting into
an ePAPR (or similar) spec? Or just for additional review? If the
former, would you suggest codifying both the old and the new, or just
the new?

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 04/19] rtc: isl12057: enable support for the standard "wakeup-source" property

2015-10-27 Thread Alexandre Belloni
On 21/10/2015 at 11:10:01 +0100, Sudeep Holla wrote :
> Though the isl12057 rtc driver should and will continue to support the
> legacy "isil,irq2-can-wakeup-machine" property to enable RTC as the
> wakeup source, we need to add support for the new standard property
> "wakeup-source".
> 
> This patch adds support for "wakeup-source" property in addition to the
> existing "isil,irq2-can-wakeup-machine" property.
> 
> Cc: Alessandro Zummo 
> Cc: Alexandre Belloni 
> Cc: rtc-li...@googlegroups.com
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/rtc/rtc-isl12057.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 03/19] rtc: opal: enable support for the stardard "wakeup-source" property

2015-10-27 Thread Alexandre Belloni
On 21/10/2015 at 11:10:00 +0100, Sudeep Holla wrote :
> Though the opal rtc driver should and will continue to support the legacy
> "has-tpo" property to enable RTC as the wakeup source, we need to add
> support for the new standard property "wakeup-source"
> 
> This patch adds support for "wakeup-source" property in addition to the
> existing "has-tpo" property.
> 
> Cc: Alessandro Zummo 
> Cc: Alexandre Belloni 
> Cc: rtc-li...@googlegroups.com
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/rtc/rtc-opal.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] rtc: ds1307: Fix alarm programming for mcp794xx

2015-10-27 Thread Alexandre Belloni
On 23/10/2015 at 09:29:57 +0300, Tero Kristo wrote :
> mcp794xx alarm registers must be written in BCD format. However, the
> alarm programming logic neglected this by adding one to the value
> after bin2bcd conversion has been already done, writing bad values
> to month register in case the alarm being set is in October. In this
> case, the alarm month value becomes 0x0a instead of the expected 0x10.
> 
> Fix by moving the +1 addition within the bin2bcd call also.
> 
> Fixes: 1d1945d261a2 ("drivers/rtc/rtc-ds1307.c: add alarm support for 
> mcp7941x chips")
> 
> Signed-off-by: Tero Kristo 
> ---
>  drivers/rtc/rtc-ds1307.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 5/5] block: enable dax for raw block devices

2015-10-27 Thread Ross Zwisler
On Tue, Oct 27, 2015 at 09:19:30AM +1100, Dave Chinner wrote:
> On Mon, Oct 26, 2015 at 05:56:30PM +0900, Dan Williams wrote:
> > On Mon, Oct 26, 2015 at 3:23 PM, Dave Chinner  wrote:
> > > Also, DAX access isn't a property of mmap - it's a property
> > > of the inode. We cannot do DAX access via mmap while mixing page
> > > cache based access through file descriptor based interfaces. This
> > > I why I'm adding an inode attribute (on disk) to enable per-file DAX
> > > capabilities - either everything is via the DAX paths, or nothing
> > > is.
> > >
> > 
> > Per-inode control sounds very useful, I'll look at a similar mechanism
> > for the raw block case.
> > 
> > However, still not quite convinced page-cache control is an inode-only
> > property, especially when direct-i/o is not an inode-property.  That
> > said, I agree the complexity of handling mixed mappings of the same
> > file is prohibitive.
> 
> We didn't get that choice with direct IO - support via O_DIRECT was
> kinda inherited from other OS's(*). We still have all sorts of
> coherency problems between buffered/mmap/direct IO on the same file,
> and I'd really, really like to avoid making that same mistake again
> with DAX.
> 
> i.e. We have a choice with DAX right now that will allow us to avoid
> coherency problems that we know existi and can't solve right now.
> Making DAX and inode property rather than a application context
> property avoids those coherence problems as all access will play by
> the same rules
> 
> (*)That said, some other OS's did O_DIRECT as an inode property (e.g.
> solaris) where O_DIRECT was only done if no other cached operations
> were required (e.g. mmap), and so the fd would transparently shift
> between buffered and O_DIRECT depending on external accesses to the
> inode. This was not liked because of it's unpredictable effect on
> CPU usage and IO latency
> 
> > Sounds good, get blkdev_issue_flush() functional first and then worry
> > about building a more efficient solution on top.
> 
> *nod*

Okay, I'll get this sent out this week.  I've been working furiously on the
fsync/msync solution which tracks dirty pages via the radix tree - I guess
I'll send out an RFC version of those patches tomorrow so that we can begin
the review process and any glaring issues can be addressed soon. 

That set has grown rather large, though, and I do worry that making it into
v4.4 would be a stretch, although I guess I'm still holding out hope.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


<    5   6   7   8   9   10   11   12   13   >