Johan Hedberg [Mon, 16 Sep 2013 10:05:19 +0000 (13:05 +0300)]
Bluetooth: Fix waiting for clearing of BT_SK_SUSPEND flag
In the case of blocking sockets we should not proceed with sendmsg() if
the socket has the BT_SK_SUSPEND flag set. So far the code was only
ensuring that POLLOUT doesn't get set for non-blocking sockets using
poll() but there was no code in place to ensure that blocking sockets do
the right thing when writing to them.
This patch adds a new bt_sock_wait_ready helper function to sleep in the
sendmsg call if the BT_SK_SUSPEND flag is set, and wake up as soon as it
is unset. It also updates the L2CAP and RFCOMM sendmsg callbacks to take
advantage of this new helper function.
Johan Hedberg [Mon, 16 Sep 2013 10:05:18 +0000 (13:05 +0300)]
Bluetooth: Fix responding to invalid L2CAP signaling commands
When we have an LE link we should not respond to any data on the BR/EDR
L2CAP signaling channel (0x0001) and vice-versa when we have a BR/EDR
link we should not respond to LE L2CAP (CID 0x0005) signaling commands.
This patch fixes this issue by checking for a valid link type and
ignores data if it is wrong.
Johan Hedberg [Mon, 16 Sep 2013 10:05:17 +0000 (13:05 +0300)]
Bluetooth: Fix sending responses to identified L2CAP response packets
When L2CAP packets return a non-zero error and the value is passed
onwards by l2cap_bredr_sig_cmd this will trigger a command reject packet
to be sent. However, the core specification (page 1416 in core 4.0) says
the following: "Command Reject packets should not be sent in response to
an identified Response packet.".
This patch ensures that a command reject packet is not sent for any
identified response packet by ignoring the error return value from the
response handler functions.
Johan Hedberg [Mon, 16 Sep 2013 10:05:16 +0000 (13:05 +0300)]
Bluetooth: Fix L2CAP command reject reason
There are several possible reason codes that can be sent in the command
reject L2CAP packet. Before this patch the code has used a hard-coded
single response code ("command not understood"). This patch adds a
helper function to map the return value of an L2CAP handler function to
the correct command reject reason.
Johan Hedberg [Mon, 16 Sep 2013 10:05:15 +0000 (13:05 +0300)]
Bluetooth: Fix L2CAP Disconnect response for unknown CID
If we receive an L2CAP Disconnect Request for an unknown CID we should
not just silently drop it but reply with a proper Command Reject
response. This patch fixes this by ensuring that the disconnect handler
returns a proper error instead of 0 and will cause the function caller
to send the right response.
Johan Hedberg [Mon, 16 Sep 2013 10:05:14 +0000 (13:05 +0300)]
Bluetooth: Fix L2CAP error return used for failed channel lookups
The EFAULT error should only be used for memory address related errors
and ENOENT might be needed for other purposes than invalid CID errors.
This patch fixes the l2cap_config_req, l2cap_connect_create_rsp and
l2cap_create_channel_req handlers to use the unique EBADSLT error to
indicate failed lookups on a given CID.
Johan Hedberg [Mon, 16 Sep 2013 10:05:13 +0000 (13:05 +0300)]
Bluetooth: Fix double error response for l2cap_create_chan_req
When an L2CAP request handler returns non-zero the calling code will
send a command reject response. The l2cap_create_chan_req function will
in some cases send its own response but then still return a -EFAULT
error which would cause two responses to be sent. This patch fixes this
by making the function return 0 after sending its own response.
Olof Johansson [Wed, 18 Sep 2013 21:01:39 +0000 (14:01 -0700)]
Merge tag 'omap-for-v3.12/fixes-dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
From Tony Lindgren, OMAP DT fixes for 3.12-rc1:
OMAP device tree changes that are needed to fix regressions and avoid
electrical issues on beaglebone black.
Via Benoit Cousson <bcousson@baylibre.com>:
Fix BBB LDO voltage to avoid HDMI destruction
Fix OMAP5 wrong attribute
Fix typo in beagle xM strings
Fix missing pinmux and regulator for OMAP4 wifi
Fix missing pinmux for igep headset
* tag 'omap-for-v3.12/fixes-dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: igep00x0: Add pinmux configuration for MCBSP2
ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for blaze
ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
ARM: dts: OMAP5: fix ocp2scp DTS data
ARM: dts: OMAP5: fix reg property size
ARM: dts: am335x-bone*: add DT for BeagleBone Black
ARM: dts: omap3-beagle-xm: fix string error in compatible property
Currently when using an initrd on a MIPS system the start of the bootmem region of
memory is set to the larger of the end of the kernel bss region (_end) or the end
of the initrd. In a typical memory layout where the initrd is at some address above
the kernel image this means that the start of the bootmem region will be the end of
the initrd. But when we are done processing/loading the initrd we have no way to
reclaim the memory region it occupied, and we lose a large chunk of now otherwise
empty RAM from our final running system.
The bootmem code is designed to allow this initrd to be reserved (and the code in
finalize_initrd() currently does this). When the initrd is finally processed/loaded
its reserved memory is freed.
Fix the setting of the start of the bootmem map to be the end of the kernel.
MIPS: BCM47XX: Fix detected clock on Asus WL520GC and WL520GU
The Asus WL520GC and WL520GU are based on the BCM5354 and clocked at
200MHz, but they do not have a clkfreq nvram variable set to the
correct value. This adds a workaround for these devices.
MIPS: BCM47XX: Fix clock detection for BCM5354 with 200MHz clock
Some BCM5354 SoCs are running at 200MHz, but it is not possible to read
the clock from a register like it is done on some other SoC in ssb and
bcma. These devices should have a clkfreq nvram configuration value set
to 200, read it and set the clock to the correct value.
Input: i8042 - i8042_flush fix for a full 8042 buffer
When 8042 internal data buffer is full, the driver
erroneously decides that the controller is not present.
i8042_flush returns the number of flushed bytes, which is
in 0 - I8042_BUFFER_SIZE range inclusive. Therefore, i8042_flush
has no way to indicate an error. Moreover i8042_controller_check
takes initially full buffer (i8042_flush returned
I8042_BUFFER_SIZE) as a sign of absence of the controller.
Let's change i8042 to return success/error instead and make sure
we do not return error prematurely.
It is supposed that sar_base is initialized in irq_save_context, which
is called on CPU_CLUSTER_PM_ENTER notification. If this notification
has been missed and CPU_CLUSTER_PM_EXIT is received sar_base is NULL.
Fix it by calling CPU_CLUSTER_PM_{ENTER,EXIT} under the same condition.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com> Acked-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
projects / karo-tx-linux.git / log