Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 22 4月, 2016 2 次提交
  3. 21 4月, 2016 4 次提交
  5. 20 4月, 2016 2 次提交
    • T
      Bluetooth: vhci: Fix race at creating hci device · c7c999cb
      由 Takashi Iwai 提交于 
      hci_vhci driver creates a hci device object dynamically upon each
HCI_VENDOR_PKT write.  Although it checks the already created object
and returns an error, it's still racy and may build multiple hci_dev
objects concurrently when parallel writes are performed, as the device
tracks only a single hci_dev object.

This patch introduces a mutex to protect against the concurrent device
creations.

Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c7c999cb
    • A
      at86rf230: increase sleep to off timings · 60f5f5d3
      由 Alexander Aring 提交于 
      I expierenced when setting channel while sleep mode it didn't changed
the channel inside the hardware registers. Then I got another report of
an user which has similar issues.

I increased the sleep to off state change timing, which is according
at86rf233 at maximum 1000 us. After this change I got no similar effects
again.

I tried another option to wait on AWAKE_END irq, which can be used to
wait until the transceiver is awaked. I tested it and the IRQ took 4
seconds after starting state change. I don't believe it takes 4 seconds
to go into the TRX_OFF state from SLEEP state. The alternative is to
increase the timings which seems to work.

Cc: Oleg Hahm <oliver.hahm@inria.fr>
Signed-off-by: NAlexander Aring <aar@pengutronix.de>
Reviewed-by: Stefan Schmidt<stefan@osg.samsung.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      60f5f5d3
  7. 13 4月, 2016 26 次提交
  9. 12 4月, 2016 6 次提交
    • D
      Merge branch 'for-upstream' of... · 69fb7812
      由 David S. Miller 提交于 
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next

Johan Hedberg says:

====================
pull request: bluetooth-next 2016-04-12

Here's a set of Bluetooth & 802.15.4 patches intended for the 4.7 kernel:

 - Fix for race condition in vhci driver
 - Memory leak fix for ieee802154/adf7242 driver
 - Improvements to deal with single-mode (LE-only) Bluetooth controllers
 - Fix for allowing the BT_SECURITY_FIPS security level
 - New BCM2E71 ACPI ID
 - NULL pointer dereference fix fox hci_ldisc driver

Let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69fb7812
    • A
      net: mdio: Fix lockdep falls positive splat · 9a6f2b01
      由 Andrew Lunn 提交于 
      MDIO devices can be stacked upon each other. The current code supports
two levels, which until recently has been enough for a DSA mdio bus on
top of another bus. Now we have hardware which has an MDIO mux in the
middle.

Define an MDIO MUTEX class with three levels.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a6f2b01
    • D
      Merge branch 'rprpc-2nd-rewrite-part-1' · 7c3da7d0
      由 David S. Miller 提交于 
      David Howells says:

====================
RxRPC: 2nd rewrite part 1

Okay, I'm in the process of rewriting the RxRPC rewrite.  The primary aim of
this second rewrite is to strictly control the number of active connections we
know about and to get rid of connections we don't need much more quickly.

On top of this, there are fixes to the protocol handling which will all occur
in later parts.

Here's the first set of patches from the second go, aimed at net-next.  These
are all fixes and cleanups preparatory to the main event.

Notable parts of this set include:

 (1) A fix for the AFS filesystem to wait for outstanding calls to complete
     before closing the RxRPC socket.

 (2) Differentiation of local and remote abort codes.  At a future point
     userspace will get to see this via control message data on recvmsg().

 (3) Absorb the rxkad module into the af_rxrpc module to prevent a dependency
     loop.

 (4) Create a null security module and unconditionalise calls into the
     security module that's in force (there will always be a security module
     applied to a connection, even if it's just the null one).
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c3da7d0
    • D
      rxrpc: Create a null security type and get rid of conditional calls · e0e4d82f
      由 David Howells 提交于 
      Create a null security type for security index 0 and get rid of all
conditional calls to the security operations.  We expect normally to be
using security, so this should be of little negative impact.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0e4d82f
    • D
      rxrpc: Absorb the rxkad security module · 648af7fc
      由 David Howells 提交于 
      Absorb the rxkad security module into the af_rxrpc module so that there's
only one module file.  This avoids a circular dependency whereby rxkad pins
af_rxrpc and cached connections pin rxkad but can't be manually evicted
(they will expire eventually and cease pinning).

With this change, af_rxrpc can just be unloaded, despite having cached
connections.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      648af7fc
    • D
      rxrpc: Don't assume transport address family and size when using it · 6dd050f8
      由 David Howells 提交于 
      Don't assume transport address family and size when using the peer address
to send a packet.  Instead, use the start of the transport address rather
than any particular element of the union and use the transport address
length noted inside the sockaddr_rxrpc struct.

This will be necessary when IPv6 support is introduced.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6dd050f8