Saeed Mahameed [Thu, 20 Nov 2014 12:19:44 +0000 (14:19 +0200)]
net/mlx4_en: mlx4_en_set_settings() always fails when autoneg is set
Fix ethtool set settings to not check AUTONEG_ENABLE
mlx4_en_set_settings should not check if cmd->autoneg == AUTONEG_ENABLE,
cmd->autoneg can be enabled by default and this check will fail other settings requests.
mlx4_en driver doesn't support changing autoneg value, but shouldn't fail the request
in case cmd->autoneg was set.
Fixes: d48b3ab ("net/mlx4_en: Use PTYS register to set ethtool settings (Speed)") Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Amir Vadai <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Added a pci_dma_mapping_error() call to check for mapping errors before
further using the dma handle. In case of error, control goes to a new label
where the incoming skb is freed. Unchecked dma handles were found using
Coccinelle:
@rule1@
expression e1;
identifier x;
@@
*x = pci_map_single(...);
... when != pci_dma_mapping_error(e1,x)
David S. Miller [Fri, 21 Nov 2014 20:01:35 +0000 (15:01 -0500)]
Merge branch 'tipc-next'
Richard Alpe says:
====================
tipc: new netlink API
v3
The old API is not removed.
The new API is separated from the old because of a bug in the old
tipc-config utility using it. When adding commands to the existing
genl_ops struct the get-family response message grows to a point where
it overflows the small receive buffer in tipc-config, subsequently
breaking the tool. Hence the two genl_family and genl_ops structs.
The new headers are placed in a new file called tipc_netlink.h rather
than added to tipc_config.h as they where in previous versions of this
patchset.
/v3
v2
Redesigned "socket list command" to address David Millers comments in
net-next v1 of this patchset.
Simply put the problem is that we can have an arbitrary amount of
sockets with an arbitrary amount of associated publications. In the
previous patchset this was solved by nesting as many publications as
possible into a socket. If all didn't fit it sent the same socket again
with the remaining publications. As David Miller pointed out this makes
each message malformed as the receiver cannot by the data itself know if
it has received a complete set or not. This was flagged outside of the
data and the client did the reassembly.
o socket 1
o publ 1
o publ 2
o socket 1
o publ 3
o publ 4
In this patchset this is divided into socket listing and publication
listing to avoid having nested data of arbitrary size.
TIPC_NL_SOCK_GET now dumps all sockets with any nested connection
information. However, it no longer include publication information,
only a HAS_PUBL flag to indicate whether the socket has publications or
not. To compliment this there is a new command TIPC_NL_PUBL_GET which
takes a socket as argument and dumps all associated publications.
This means that on "top-level" the data is always complete. In the case
of "tipc socket list" (new tipc-config -p) it first queries all sockets
with TIPC_NL_SOCK_GET and if the socket is published it fetches the
publications using TIPC_NL_PUBL_GET. This is slow for large amount of
sockets with a low publication count (worst case). However, the
integrity is preserved and there is no malformed messages.
/v2
This is a new netlink API for TIPC. It's intended to replace the
existing ASCII API. It utilizes many of the standard netlink
functionalities in the kernel, such as attribute nesting and
input polices.
There are a couple of reasons for this rewrite. The main and most
easily justifiable is that the existing API doesn't scale. Meaning
that a TIPC cluster with a larger amount of nodes, publications or
ports will rapidly exceed what the exiting API can handle. Resulting
in truncated or corrupt responses. In addition to this, the existing
ASCII API rarely uses "standard" kernel functions and has several
tipc specific functions for sanity checking and string formating.
The new API utilizes standard function for pushing data to socket
buffers and netlink attribute nesting to logically group data.
The new API can handle an arbitrary amount of data for things that
are likely to scale up as the TIPC usage and/or cluster size
increases.
A new user-space tool has been developed to work with this new API.
It is called "tipc" and is part of the "tipc-utils" package that
comes with many Linux distributions. The new "tipc" tool utilizes
standard functions from libnl to format, send, receive and process
messages. The tool has borrowed design philosophies from git and the
ip tool. Making the syntax resemble that of ip whiles its strong
modularity resembles that of git.
The existing tool for managing TIPC, "tipc-config" remains in the
package, but when built for kernels that has this new API it is
replaced by a script-based wrapper that maps the old syntax to the
new tool. This way, backwards compatibility is mostly preserved.
MORE ABOUT THE CODE
The main challenge here is to handle the case where the data is of
arbitrary size. This was largely neglected in the old API design.
For example when there is a lot of sockets that has a large amount of
associated publications. In this specific case we can't assume that
all ports nor for that matter all the publications can fit inside a
single netlink message. Sending everything in one batch isn't an
option as we need to yield for the socket layer to cope.
This is solved by using the standard netlink callback for dumping
data and releasing the locks when the netlink message is full. The
dumping mechanism gets us back and we keep a reference (logical) to
where we where when the message became full. This means that we are
not "atomic", what is retrieved by user-space isn't a snapshot at a
certain time but rather a continuously updated data set. In the case
where we can't find our way back i.e. our logical reference are gone
we set a standard flag (NLM_F_DUMP_INTR) to tell user-space that the
dump was interrupted.
====================
Richard Alpe [Thu, 20 Nov 2014 09:29:12 +0000 (10:29 +0100)]
tipc: add link get/dump to new netlink api
Add TIPC_NL_LINK_GET command to the new tipc netlink API.
This command supports dumping all information about all links
(including the broadcast link) or getting all information about a
specific link (not the broadcast link).
The information about a link includes name, transmission info,
properties and link statistics.
As the tipc broadcast link is special we unfortunately have to treat
it specially. It is a deliberate decision not to abstract the
broadcast link on this (API) level.
Richard Alpe [Thu, 20 Nov 2014 09:29:10 +0000 (10:29 +0100)]
tipc: add sock dump to new netlink api
Add TIPC_NL_SOCK_GET command to the new tipc netlink API.
This command supports dumping of all available sockets with their
associated connection or publication(s). It could be extended to reply
with a single socket if the NLM_F_DUMP isn't set.
The information about a socket includes reference, address, connection
information / publication information.
Netlink logical layout of response message:
-> socket
-> reference
-> address
[
-> connection
-> node
-> socket
[
-> connected flag
-> type
-> instance
]
]
[
-> publication flag
]
Richard Alpe [Thu, 20 Nov 2014 09:29:07 +0000 (10:29 +0100)]
tipc: add bearer disable/enable to new netlink api
A new netlink API for tipc that can disable or enable a tipc bearer.
The new API is separated from the old API because of a bug in the
user space client (tipc-config). The problem is that older versions
of tipc-config has a very low receive limit and adding commands to
the legacy genl_opts struct causes the ctrl_getfamily() response
message to grow, subsequently breaking the tool.
The new API utilizes netlink policies for input validation. Where the
top-level netlink attributes are tipc-logical entities, like bearer.
The top level entities then contain nested attributes. In this case
a name, nested link properties and a domain.
Netlink commands implemented in this patch:
TIPC_NL_BEARER_ENABLE
TIPC_NL_BEARER_DISABLE
hayeswang [Thu, 20 Nov 2014 02:29:05 +0000 (10:29 +0800)]
r8152: adjust r8152_submit_rx
The behavior of handling the returned status from r8152_submit_rx()
is almost same, so let r8152_submit_rx() deal with the error
directly. This could avoid the duplicate code.
Daniel Borkmann [Thu, 20 Nov 2014 00:54:48 +0000 (01:54 +0100)]
net: sctp: keep owned chunk in destructor_arg instead of skb->cb
It's just silly to hold the skb destructor argument around inside
skb->cb[] as we currently do in SCTP.
Nowadays, we're sort of cheating on data accounting in the sense
that due to commit 4c3a5bdae293 ("sctp: Don't charge for data in
sndbuf again when transmitting packet"), we orphan the skb already
in the SCTP output path, i.e. giving back charged data memory, and
use a different destructor only to make sure the sk doesn't vanish
on skb destruction time. Thus, cb[] is still valid here as we
operate within the SCTP layer. (It's generally actually a big
candidate for future rework, imho.)
However, storing the destructor in the cb[] can easily cause issues
should an non sctp_packet_set_owner_w()'ed skb ever escape the SCTP
layer, since cb[] may get overwritten by lower layers and thus can
corrupt the chunk pointer. There are no such issues at present,
but lets keep the chunk in destructor_arg, as this is the actual
purpose for it.
Florian Fainelli [Wed, 19 Nov 2014 18:29:56 +0000 (10:29 -0800)]
net: bcmgenet: log RX buffer allocation and RX/TX dma failures
To help troubleshoot heavy memory pressure conditions, add a bunch of
statistics counter to log RX buffer allocation and RX/TX DMA mapping
failures. These are reported like any other counters through the ethtool
stats interface.
Florian Fainelli [Wed, 19 Nov 2014 18:29:55 +0000 (10:29 -0800)]
net: systemport: log RX buffer allocation and RX/TX DMA failures
To help troubleshoot heavy memory pressure conditions, add a bunch of
statistics counter to log RX buffer allocation and RX/TX DMA mapping
failures. These are reported like any other counters through the ethtool
stats interface.
Willem de Bruijn [Wed, 19 Nov 2014 18:10:16 +0000 (13:10 -0500)]
packet: make packet_snd fail on len smaller than l2 header
When sending packets out with PF_PACKET, SOCK_RAW, ensure that the
packet is at least as long as the device's expected link layer header.
This check already exists in tpacket_snd, but not in packet_snd.
Also rate limit the warning in tpacket_snd.
Markus Elfring [Fri, 21 Nov 2014 16:11:49 +0000 (17:11 +0100)]
thermal: Exynos: Deletion of unnecessary checks before two function calls
The functions cpufreq_cooling_unregister() and thermal_zone_device_unregister()
test whether their argument is NULL and then return immediately.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
This series adds device and device-type abstractions to the micrel
driver, and enables support for RMII-reference clock selection for
KSZ8081 and KSZ8091 devices.
While adding support for more features for the Micrel PHYs mentioned
above, it became apparent that the configuration space is much too large
and that adding type-specific callbacks will simply not scale. Instead I
added a driver_data field to struct phy_device, which can be used to
store static device type data that can be parsed and acted on in
generic driver callbacks. This allows a lot of duplicated code to be
removed, and should make it much easier to add new features or deal with
device-type quirks in the future.
The series has been tested on a dual KSZ8081 setup. Further testing on
other Micrel PHYs would be much appreciated.
The recent commit a95a18afe4c8 ("phy/micrel: KSZ8031RNL RMII clock
reconfiguration bug") currently prevents KSZ8031 PHYs from using the
generic config-init. Bruno, who is the author of that patch, has agreed
to test this series and some follow-up diagnostic patches to determine
how best to incorporate these devices as well. I intend to send a
follow-up patch that removes the custom 8031 config-init and documents
this quirk, but the current series can be applied meanwhile.
These patches are against net-next which contains some already merged
prerequisite patches to the driver.
====================
Johan Hovold [Wed, 19 Nov 2014 11:59:21 +0000 (12:59 +0100)]
dt/bindings: add clock-select function property to micrel phy binding
Add "micrel,rmii-reference-clock-select-25-mhz" to Micrel ethernet PHY
binding documentation.
This property is needed to properly describe some revisions of Micrel
PHYs which has the function of this configuration bit inverted so that
setting it enables 25 MHz rather than 50 MHz clock mode.
Note that a clock reference ("rmii-ref") is still needed to actually
select either mode.
Johan Hovold [Wed, 19 Nov 2014 11:59:19 +0000 (12:59 +0100)]
net: phy: micrel: add support for clock-mode select to KSZ8081/KSZ8091
Micrel KSZ8081 and KSZ8091 PHYs have the RMII Reference Clock Select
bit, which is used to select 25 or 50 MHz clock mode.
Note that on some revisions of the PHY (e.g. KSZ8081RND) the function of
this bit is inverted so that setting it enables 25 rather than 50 MHz
mode. Add a new device-tree property
"micrel,rmii-reference-clock-select-25-mhz" to describe this.
Johan Hovold [Wed, 19 Nov 2014 11:59:18 +0000 (12:59 +0100)]
net: phy: micrel: add generic clock-mode-select support
Add generic RMII-Reference-Clock-Select support.
Several Micrel PHY have an RMII-Reference-Clock-Select bit to select
25 MHz or 50 MHz clock mode. Recently, support for configuring this
through device tree for KSZ8021 and KSZ8031 was added.
Generalise this support so that it can be configured for other PHY types
as well.
Note that some PHY revisions (of the same type) has this bit inverted.
This should be either configurable through a new device-tree property,
or preferably, determined based on PHY ID if possible.
Also note that this removes support for setting 25 MHz mode from board
files which was also added by the above mentioned commit 45f56cb82e45
("net/phy: micrel: Add clock support for KSZ8021/KSZ8031").
Lee Jones [Wed, 19 Nov 2014 15:50:31 +0000 (15:50 +0000)]
thermal: sti: Ignore suspend/resume functions when !PM_SLEEP
Prevents build warning:
st_thermal.c:278:12:
warning: ‘st_thermal_suspend’ defined but not used [-Wunused-function]
st_thermal.c:286:12:
warning: ‘st_thermal_resume’ defined but not used [-Wunused-function]
Al Viro [Fri, 21 Nov 2014 16:51:08 +0000 (11:51 -0500)]
Merge branch 'overlayfs-current' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs into for-linus
"The biggest change is to rename the filesystem from "overlayfs" to "overlay".
This will allow legacy overlayfs to be easily carried by distros alongside the
new mainline one. Also fix a couple of copy-up races and allow escaping comma
character in filenames."
The last bit is about commas in pathname mount options...
ARM: 8216/1: xscale: correct auxiliary register in suspend/resume
According to the manuals I have, XScale auxiliary register should be
reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init
correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and
cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to
also use c1, c0, 1.
The issue was primarily noticed thanks to qemu reporing "unsupported
instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255
XScale Core manuals and in PXA270 and PXA320 Developers Guides.
Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board.
ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
Commit 6e80e3d87549 ("ARM: exynos_defconfig: Enable MAX77802")
enabled support for the max77802 regulators but the PMIC also
has a Real-Time-Clock (RTC) and 2-channel 32kHz clock outputs.
Enable the kernel config options to have the drivers for these
devices built-in since they are present in many Exynos boards.
Jason Wang [Thu, 20 Nov 2014 09:03:05 +0000 (17:03 +0800)]
virtio-net: validate features during probe
We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
is not set but one of features depending on it is.
That's not a friendly way to report errors to
hypervisors.
Let's check, and fail probe instead.
The following patchset contains two bugfixes for your net tree, they are:
1) Validate netlink group from nfnetlink to avoid an out of bound array
access. This should only happen with superuser priviledges though.
Discovered by Andrey Ryabinin using trinity.
2) Don't push ethernet header before calling the netfilter output hook
for multicast traffic, this breaks ebtables since it expects to see
skb->data pointing to the network header, patch from Linus Luessing.
====================
Jiri Bohac [Wed, 19 Nov 2014 22:05:49 +0000 (23:05 +0100)]
ipx: fix locking regression in ipx_sendmsg and ipx_recvmsg
This fixes an old regression introduced by commit b0d0d915 (ipx: remove the BKL).
When a recvmsg syscall blocks waiting for new data, no data can be sent on the
same socket with sendmsg because ipx_recvmsg() sleeps with the socket locked.
This breaks mars-nwe (NetWare emulator):
- the ncpserv process reads the request using recvmsg
- ncpserv forks and spawns nwconn
- ncpserv calls a (blocking) recvmsg and waits for new requests
- nwconn deadlocks in sendmsg on the same socket
Commit b0d0d915 has simply replaced BKL locking with
lock_sock/release_sock. Unlike now, BKL got unlocked while
sleeping, so a blocking recvmsg did not block a concurrent
sendmsg.
Only keep the socket locked while actually working with the socket data and
release it prior to calling skb_recv_datagram().
Joe Stringer [Wed, 19 Nov 2014 21:54:49 +0000 (13:54 -0800)]
openvswitch: Don't validate IPv6 label masks.
When userspace doesn't provide a mask, OVS datapath generates a fully
unwildcarded mask for the flow by copying the flow and setting all bits
in all fields. For IPv6 label, this creates a mask that matches on the
upper 12 bits, causing the following error:
openvswitch: netlink: Invalid IPv6 flow label value (value=ffffffff, max=fffff)
This patch ignores the label validation check for masks, avoiding this
error.
Mathias Krause [Wed, 19 Nov 2014 17:05:26 +0000 (18:05 +0100)]
pptp: fix stack info leak in pptp_getname()
pptp_getname() only partially initializes the stack variable sa,
particularly only fills the pptp part of the sa_addr union. The code
thereby discloses 16 bytes of kernel stack memory via getsockname().
Dave Airlie [Fri, 21 Nov 2014 02:19:19 +0000 (12:19 +1000)]
Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
fix one regression and one endian issue.
* 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix endian swapping in vbios fetch for tdp table
drm/radeon: disable native backlight control on pre-r6xx asics (v2)
Mitch Williams [Tue, 11 Nov 2014 20:03:13 +0000 (20:03 +0000)]
i40evf: remove unnecessary else
Since the if part of this statement contains a break, there's no reason
for the else. Clean up the code and make it more obvious that the delay
happens each time through the loop.
Change-ID: I9292eaf7dd687688bdc401b8bd8d1d14f6944460 Signed-off-by: Mitch Williams <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
Mitch Williams [Tue, 11 Nov 2014 20:02:42 +0000 (20:02 +0000)]
i40evf: make checkpatch happy
This patch is the result of running checkpatch on the i40evf driver with
the --strict option. The vast majority of changes are adding/removing
blank lines, aligning function parameters, and correcting over-long
lines.
The only possible functional change is changing the flags member of the
adapter structure to be non-volatile. However, according to the kernel
documentation, this is not necessary and the volatile should be removed.
Change-ID: Ie8c6414800924f529bef831e8845292b970fe2ed Signed-off-by: Mitch Williams <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
Mitch Williams [Tue, 11 Nov 2014 20:02:19 +0000 (20:02 +0000)]
i40e: don't overload fields
Overloading the msg_size field in the arq_event_info struct is just a
bad idea. It leads to repeated bugs when the structure is used in a
loop, since the input value (buffer size) is overwritten by the output
value (actual message length).
Fix this by splitting the field into two and renaming to indicate the
actual function of each field.
Since the arq_event struct has now changed, we need to change the drivers
to support this. Note that we no longer need to initialize the buffer size
each time we go through a loop as this value is no longer destroyed by
arq processing.
In the process, we also fix a bug in i40evf_verify_api_ver where the
buffer size was not correctly reinitialized each time through the loop.
Emil Tantilov [Sat, 8 Nov 2014 01:39:51 +0000 (01:39 +0000)]
ixgbevf: compare total_rx_packets and budget in ixgbevf_clean_rx_irq
total_rx_packets is the number of packets we had cleaned, and budget is
the total number of packets that we could clean per poll. Instead of
altering both of these values we can save ourselves one write to memory by
just comparing total_rx_packets to the budget and as long as we are less
than budget we continue cleaning.
Also change the do{}while logic to while{} in order to avoid processing
packets when budget is 0.
Emil Tantilov [Fri, 21 Nov 2014 02:57:15 +0000 (02:57 +0000)]
ixgbevf: Change receive model to use double buffered page based receives
This patch changes the basic receive path for ixgbevf so that instead of
receiving the data into an skb it is received into a double buffered page.
The main change is that the receives will be done in pages only and then
pull the header out of the page and copy it into the sk_buff data.
This has the advantages of reduced cache misses and improved performance on
IOMMU enabled systems.
v2:
- added pfmemalloc check to a new function for reusable page
- moved atomic_inc outside of #if/else in ixgbevf_add_rx_frag()
- reverted the removal of the api check in ixgbevf_change_mtu()
Emil Tantilov [Sat, 8 Nov 2014 01:39:41 +0000 (01:39 +0000)]
ixgbevf: Update Rx next to clean in real time
Since the next_to_clean value is only accessed by the Rx interrupt handler
we can save on stack space by just storing our updated values back in
next_to_clean instead of using the stack variable i. This should help to
reduce stack space and we can further collapse the size of the function.
Also removed non_eop_descs counter as it was never shown in the stats.
Emil Tantilov [Sat, 8 Nov 2014 01:39:35 +0000 (01:39 +0000)]
ixgbevf: reorder main loop in ixgbe_clean_rx_irq to allow for do/while/continue
This change allows us to go from a loop based on the descriptor to one
primarily based on the budget. The advantage to this is that we can avoid
carrying too many values from one iteration to the next.
This change is meant to help cleanup the usage of temporary variables
within the Rx hot-path by removing unnecessary variables and reducing
the scope of variables that do not need to exist outside the main loop.
Emil Tantilov [Sat, 8 Nov 2014 01:39:20 +0000 (01:39 +0000)]
ixgbevf: Test Rx status bits directly out of the descriptor
Instead of keeping a local copy of the status bits from the descriptor
we can just read them directly - this is accomplished with the addition
of ixgbevf_test_staterr().
In addition instead of doing a byteswap on the status bits value, we
can byteswap the constant values we are testing since that can be done
at compile time which should help to improve performance on big-endian
systems.
Emil Tantilov [Sat, 8 Nov 2014 01:39:15 +0000 (01:39 +0000)]
ixgbevf: Update ixgbevf_alloc_rx_buffers to handle clearing of status bits
Instead of clearing the status bits in the cleanup it makes more sense to
just clear the status bits on allocation. This way we can leave the Rx
descriptor rings as a read only memory block until we actually have buffers
to give back to the hardware.
thermal: cpu_cooling: Update always cpufreq policy with thermal constraints
Existing code updates cupfreq policy only while executing
cpufreq_apply_cooling() function (i.e. when notify_device != NOTIFY_INVALID).
It doesn't apply constraints when cpufreq policy update happens from any other
place but it should update the cpufreq policy with thermal constraints every
time when there is a cpufreq policy update, to keep state of
cpufreq_cooling_device and max_feq of cpufreq policy in sync. For instance
while resuming cpufreq updates cpufreq_policy and it restores default
policy->usr_policy values irrespective of cooling device's cpufreq_state since
notification gets missed because (notify_device == NOTIFY_INVALID).
Another problem, is that userspace is able to change max_freq irrespective of
cooling device's state, as notification gets missed.
This patch modifies code to maintain a global cpufreq_dev_list and applies
constraints of all matching cooling devices for policy's cpu when there is any
policy update(ends up applying the lowest max_freq among the matching cpu
cooling devices).
This patch also removes redundant check (max_freq > policy->user_policy.max),
as cpufreq framework takes care of user_policy constraints already where ever
required, otherwise its causing an issue while increasing max_freq in normal
scenerio as it restores max_freq with policy->user_policy.max which is old
(smaller) value.
Andy Lutomirski [Wed, 19 Nov 2014 21:56:19 +0000 (13:56 -0800)]
x86, syscall: Fix _TIF_NOHZ handling in syscall_trace_enter_phase1
TIF_NOHZ is 19 (i.e. _TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME |
_TIF_SINGLESTEP), not (1<<19).
This code is involved in Dave's trinity lockup, but I don't see why
it would cause any of the problems he's seeing, except inadvertently
by causing a different path through entry_64.S's syscall handling.
Kristian Evensen [Thu, 20 Nov 2014 15:52:58 +0000 (16:52 +0100)]
mwifiex: Add USB8766 support
Adds new VID/PID for the Marvell 88W8766. The kernel currently only supports
the device as PCI, but it is also available using USB. An example of a device
delivered with the 88W8766 as USB is the Globalscale Mirabox.
TX buffer size is set to driver default (2K), as we do not know the firmware
requirement.
Markus Elfring [Thu, 20 Nov 2014 15:42:51 +0000 (16:42 +0100)]
net: brcm80211: Deletion of unnecessary checks before two function calls
The functions brcmu_pkt_buf_free_skb() and release_firmware() test whether
their argument is NULL and then return immediately. Thus the test around
the call is not needed.
This issue was detected by using the Coccinelle software.
"It has been a while since my last pull request, so we accumulated
another relatively large set of changes:
* TDLS off-channel support set from Arik/Liad, with some support
patches I did
* custom regulatory fixes from Arik
* minstrel VHT fix (and a small optimisation) from Felix
* add back radiotap vendor namespace support (myself)
* random MAC address scanning for cfg80211/mac80211/hwsim (myself)
* CSA improvements (Luca)
* WoWLAN Net Detect (wake on network found) support (Luca)
* and lots of other smaller changes from many people"
Takashi Iwai [Thu, 20 Nov 2014 20:39:14 +0000 (21:39 +0100)]
ALSA: usb-audio: Use snd_usb_ctl_msg() for Native Instruments quirk
snd_nativeinstruments_control_get() uses a stack as a buffer for
usb_control_msg(), but it's basically not allowed. Replace the call
with a safer helper, snd_usb_ctl_msg(), instead.
Johannes Berg [Wed, 19 Nov 2014 21:13:10 +0000 (22:13 +0100)]
brcmfmac: don't include linux/unaligned/access_ok.h
This is a specific implementation, <asm/unaligned.h> is the
multiplexer that has the arch-specific knowledge of which
of the implementations needs to be used, so include that.
This issue was revealed by kbuild testing
when <asm/unaligned.h> was added in <linux/ieee80211.h>
resulting in redefinition of get_unaligned_be16 (and
probably others).
Alex Deucher [Wed, 19 Nov 2014 18:12:54 +0000 (13:12 -0500)]
drm/radeon: disable native backlight control on pre-r6xx asics (v2)
Just use the acpi interface. That's what windows uses on this
generation and it's the only thing that seems to work reliably
on these generation parts.
You can still force the native backlight interface by setting
radeon.backlight=1
Yaniv Gardi [Thu, 23 Oct 2014 10:25:13 +0000 (13:25 +0300)]
ufs: fix power info after link start-up
After link start-up power mode will always be PWM G1. This is not
reflected in the pwr_info struct which will keep the previous values.
Since ufshcd_change_power_mode() tries to avoid unnecessary power mode
change if the requested power mode and current power mode are same,
power mode change won't execute again after driver initialization.
This patch solves the problem by setting pwr_info to PWM G1 after link
start-up.
Akinobu Mita [Thu, 23 Oct 2014 10:25:12 +0000 (13:25 +0300)]
ufs: fix reference counting of W-LUs
UFS driver adds three well known LUs in the initialization, but those
reference counts are not decremented, so it makes ufshcd module
impossible to unload.
This fixes it by putting scsi_device_put() in the initalization, and in
order to protect concurrent access to hba->sdev_ufs_device (UFS Device
W-LU) from manual delete, increment the reference count while requesting
device power mode setting.
The rest of W-LUs (hba->sdev_boot and hba->sdev_rpmb) are not directly
used from driver, so these references in struct ufs_hba are removed.