Daniel Vetter [Thu, 22 Jan 2015 15:36:23 +0000 (16:36 +0100)]
drm/atomic-helpers: Recover full cursor plane behaviour
Cursor plane updates have historically been fully async and mutliple
updates batched together for the next vsync. And userspace relies upon
that. Since implementing a full queue of async atomic updates is a bit
of work lets just recover the cursor specific behaviour with a hint
flag and some hacks to drop the vblank wait.
This builds on top of the crtc->active infrastructure to implement
legacy DPMS. My choice of semantics is somewhat arbitrary, but the
entire pipe is enabled as along as one output is still enabled.
Of course it also clamps everything that's not ON to OFF.
v2: Fix spelling in one comment.
v3: Don't do an async commit (Thierry)
v4: Dan Carpenter noticed missing error case handling.
Daniel Vetter [Thu, 22 Jan 2015 15:36:21 +0000 (16:36 +0100)]
drm/atomic: Add drm_crtc_state->active
This is the infrastructure for DPMS ported to the atomic world.
Fundamental changes compare to legacy DPMS are:
- No more per-connector dpms state, instead there's just one per each
display pipeline. So if you clone either you have to unclone first
if you only want to switch off one screen, or you just switch of
everything (like all desktops do). This massively reduces complexity
for cloning since now there's no more half-enabled cloned configs to
consider.
- Only on/off, dpms standby/suspend are as dead as real CRTs. Again
reduces complexity a lot.
Now especially for backwards compat the really important part for dpms
support is that dpms on always succeeds (except for hw death and
unplugged cables ofc). Which means everything that could fail (like
configuration checking, resources assignments and buffer management)
must be done irrespective from ->active. ->active is really only a
toggle to change the hardware state. More precisely:
- Drivers MUST NOT look at ->active in their ->atomic_check callbacks.
Changes to ->active MUST always suceed if nothing else changes.
- Drivers using the atomic helpers MUST NOT look at ->active anywhere,
period. The helpers will take care of calling the respective
enable/modeset/disable hooks as necessary. As before the helpers
will carefully keep track of the state and not call any hooks
unecessarily, so still no double-disables or enables like with crtc
helpers.
- ->mode_set hooks are only called when the mode or output
configuration changes, not for changes in ->active state.
- Drivers which reconstruct the state objects in their ->reset hooks
or through some other hw state readout infrastructure must ensure
that ->active reflects actual hw state.
This just implements the core bits and helper logic, a subsequent
patch will implement the helper code to implement legacy dpms with
this.
v2: Rebase on top of the drm ioctl work:
- Move crtc checks to the core check function.
- Also check for ->active_changed when deciding whether a modeset
might happen (for the ALLOW_MODESET mode).
- Expose the ->active state with an atomic prop.
v3: Review from Rob
- Spelling fix in comment.
- Extract needs_modeset helper to consolidate the ->mode_changed ||
->active_changed checks.
v4: Fixup fumble between crtc->state and crtc_state.
Daniel Vetter [Wed, 21 Jan 2015 07:47:38 +0000 (08:47 +0100)]
drm: Add standardized boolean props
Not a new type exposed to userspace, just a standard way to create
them since between range, bitmask and enum there's 3 different ways to
pull out a boolean prop.
Also add the kerneldoc for the recently added new prop types, which
Rob forgot all about.
Matt Roper [Thu, 22 Jan 2015 00:35:40 +0000 (16:35 -0800)]
drm: Add rotation value to plane state
The rotation property is shared by multiple drivers, so it makes sense
to store the rotation value (for atomic-converted drivers) in the common
plane state so that core code can eventually access it as well.
With the commit d75b1ade567ffab ("net: less interrupt masking in NAPI") napi
repoll is done only when work_done == budget. When in busy_poll is we return 0
in napi_poll. We should return budget.
ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too
Lubomir Rintel reported that during replacing a route the interface
reference counter isn't correctly decremented.
To quote bug <https://bugzilla.kernel.org/show_bug.cgi?id=91941>:
| [root@rhel7-5 lkundrak]# sh -x lal
| + ip link add dev0 type dummy
| + ip link set dev0 up
| + ip link add dev1 type dummy
| + ip link set dev1 up
| + ip addr add 2001:db8:8086::2/64 dev dev0
| + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20
| + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10
| + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20
| + ip link del dev0 type dummy
| Message from syslogd@rhel7-5 at Jan 23 10:54:41 ...
| kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
|
| Message from syslogd@rhel7-5 at Jan 23 10:54:51 ...
| kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
During replacement of a rt6_info we must walk all parent nodes and check
if the to be replaced rt6_info got propagated. If so, replace it with
an alive one.
Fixes: 4a287eba2de3957 ("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag") Reported-by: Lubomir Rintel <[email protected]> Signed-off-by: Hannes Frederic Sowa <[email protected]> Tested-by: Lubomir Rintel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Ben Hutchings [Tue, 27 Jan 2015 00:50:24 +0000 (00:50 +0000)]
sh_eth: Fix DMA-API usage for RX buffers
- Use the return value of dma_map_single(), rather than calling
virt_to_page() separately
- Check for mapping failue
- Call dma_unmap_single() rather than dma_sync_single_for_cpu()
Ben Hutchings [Tue, 27 Jan 2015 00:49:32 +0000 (00:49 +0000)]
sh_eth: Ensure DMA engines are stopped before freeing buffers
Currently we try to clear EDRRR and EDTRR and immediately continue to
free buffers. This is unsafe because:
- In general, register writes are not serialised with DMA, so we still
have to wait for DMA to complete somehow
- The R8A7790 (R-Car H2) manual states that the TX running flag cannot
be cleared by writing to EDTRR
- The same manual states that clearing the RX running flag only stops
RX DMA at the next packet boundary
I applied this patch to the driver to detect DMA writes to freed
buffers:
while ethtool -G eth0 rx 128 ; ethtool -G eth0 rx 64; do echo -n .; done
and 'ping -f' toward the sh_eth port from another machine. The
warning fired several times a minute.
To fix these issues:
- Deactivate all TX descriptors rather than writing to EDTRR
- As there seems to be no way of telling when RX DMA is stopped,
perform a soft reset to ensure that both DMA enginess are stopped
- To reduce the possibility of the reset truncating a transmitted
frame, disable egress and wait a reasonable time to reach a
packet boundary before resetting
- Update statistics before resetting
(The 'reasonable time' does not allow for CS/CD in half-duplex
mode, but half-duplex no longer seems reasonable!)
Ben Hutchings [Tue, 27 Jan 2015 00:41:16 +0000 (00:41 +0000)]
sh_eth: Remove RX overflow log messages
If RX traffic is overflowing the FIFO or DMA ring, logging every time
this happens just makes things worse. These errors are visible in the
statistics anyway.
An exception is seen in ICMP ping receive path where the skb
destructor sock_rfree() tries to access a freed socket. This happens
because ping_rcv() releases socket reference with sock_put() and this
internally frees up the socket. Later icmp_rcv() will try to free the
skb and as part of this, skb destructor is called and which leads
to a kernel panic as the socket is freed already in ping_rcv().
Herbert Xu [Fri, 23 Jan 2015 21:02:40 +0000 (08:02 +1100)]
udp_diag: Fix socket skipping within chain
While working on rhashtable walking I noticed that the UDP diag
dumping code is buggy. In particular, the socket skipping within
a chain never happens, even though we record the number of sockets
that should be skipped.
As this code was supposedly copied from TCP, this patch does what
TCP does and resets num before we walk a chain.
Ahmed S. Darwish [Mon, 26 Jan 2015 05:25:43 +0000 (07:25 +0200)]
can: kvaser_usb: Fix state handling upon BUS_ERROR events
While being in an ERROR_WARNING state, and receiving further
bus error events with error counters still in the ERROR_WARNING
range of 97-127 inclusive, the state handling code erroneously
reverts back to ERROR_ACTIVE.
Per the CAN standard, only revert to ERROR_ACTIVE when the
error counters are less than 96.
Moreover, in certain Kvaser models, the BUS_ERROR flag is
always set along with undefined bits in the M16C status
register. Thus use bitwise operators instead of full equality
for checking that register against bus errors.
Ahmed S. Darwish [Mon, 26 Jan 2015 05:24:06 +0000 (07:24 +0200)]
can: kvaser_usb: Retry the first bulk transfer on -ETIMEDOUT
On some x86 laptops, plugging a Kvaser device again after an
unplug makes the firmware always ignore the very first command.
For such a case, provide some room for retries instead of
completely exiting the driver init code.
Ahmed S. Darwish [Mon, 26 Jan 2015 05:20:39 +0000 (07:20 +0200)]
can: kvaser_usb: Do not sleep in atomic context
Upon receiving a hardware event with the BUS_RESET flag set,
the driver kills all of its anchored URBs and resets all of
its transmit URB contexts.
Unfortunately it does so under the context of URB completion
handler `kvaser_usb_read_bulk_callback()', which is often
called in an atomic context.
While the device is flooded with many received error packets,
usb_kill_urb() typically sleeps/reschedules till the transfer
request of each killed URB in question completes, leading to
the sleep in atomic bug. [3]
In v2 submission of the original driver patch [1], it was
stated that the URBs kill and tx contexts reset was needed
since we don't receive any tx acknowledgments later and thus
such resources will be locked down forever. Fortunately this
is no longer needed since an earlier bugfix in this patch
series is now applied: all tx URB contexts are reset upon CAN
channel close. [2]
Moreover, a BUS_RESET is now treated _exactly_ like a BUS_OFF
event, which is the recommended handling method advised by
the device manufacturer.
David S. Miller [Tue, 27 Jan 2015 01:32:24 +0000 (17:32 -0800)]
Merge tag 'mac80211-for-davem-2015-01-23' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Another set of last-minute fixes:
* fix station double-removal when suspending while associating
* fix the HT (802.11n) header length calculation
* fix the CCK radiotap flag used for monitoring, a pretty
old regression but a simple one-liner
* fix per-station group-key handling
ipv4: try to cache dst_entries which would cause a redirect
Not caching dst_entries which cause redirects could be exploited by hosts
on the same subnet, causing a severe DoS attack. This effect aggravated
since commit f88649721268999 ("ipv4: fix dst race in sk_dst_get()").
Lookups causing redirects will be allocated with DST_NOCACHE set which
will force dst_release to free them via RCU. Unfortunately waiting for
RCU grace period just takes too long, we can end up with >1M dst_entries
waiting to be released and the system will run OOM. rcuos threads cannot
catch up under high softirq load.
Attaching the flag to emit a redirect later on to the specific skb allows
us to cache those dst_entries thus reducing the pressure on allocation
and deallocation.
bpf: rcu lock must not be held when calling copy_to_user()
BUG: sleeping function called from invalid context at mm/memory.c:3732
in_atomic(): 0, irqs_disabled(): 0, pid: 671, name: test_maps
1 lock held by test_maps/671:
#0: (rcu_read_lock){......}, at: [<0000000000264190>] map_lookup_elem+0xe8/0x260
Call Trace:
([<0000000000115b7e>] show_trace+0x12e/0x150)
[<0000000000115c40>] show_stack+0xa0/0x100
[<00000000009b163c>] dump_stack+0x74/0xc8
[<000000000017424a>] ___might_sleep+0x23a/0x248
[<00000000002b58e8>] might_fault+0x70/0xe8
[<0000000000264230>] map_lookup_elem+0x188/0x260
[<0000000000264716>] SyS_bpf+0x20e/0x840
Fix it by allocating temporary buffer to store map element value.
Fixes: db20fd2b0108 ("bpf: add lookup/update/delete/iterate methods to BPF maps") Reported-by: Michael Holzheu <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Daniel Borkmann [Thu, 22 Jan 2015 17:26:54 +0000 (18:26 +0100)]
net: sctp: fix slab corruption from use after free on INIT collisions
When hitting an INIT collision case during the 4WHS with AUTH enabled, as
already described in detail in commit 1be9a950c646 ("net: sctp: inherit
auth_capable on INIT collisions"), it can happen that we occasionally
still remotely trigger the following panic on server side which seems to
have been uncovered after the fix from commit 1be9a950c646 ...
Since this only triggers in some collision-cases with AUTH, the problem at
heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice
when having refcnt 1, once directly in sctp_assoc_update() and yet again
from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on
the already kzfree'd memory, which is also consistent with the observation
of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected
at a later point in time when poison is checked on new allocation).
Reference counting of auth keys revisited:
Shared keys for AUTH chunks are being stored in endpoints and associations
in endpoint_shared_keys list. On endpoint creation, a null key is being
added; on association creation, all endpoint shared keys are being cached
and thus cloned over to the association. struct sctp_shared_key only holds
a pointer to the actual key bytes, that is, struct sctp_auth_bytes which
keeps track of users internally through refcounting. Naturally, on assoc
or enpoint destruction, sctp_shared_key are being destroyed directly and
the reference on sctp_auth_bytes dropped.
User space can add keys to either list via setsockopt(2) through struct
sctp_authkey and by passing that to sctp_auth_set_key() which replaces or
adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes
with refcount 1 and in case of replacement drops the reference on the old
sctp_auth_bytes. A key can be set active from user space through setsockopt()
on the id via sctp_auth_set_active_key(), which iterates through either
endpoint_shared_keys and in case of an assoc, invokes (one of various places)
sctp_auth_asoc_init_active_key().
sctp_auth_asoc_init_active_key() computes the actual secret from local's
and peer's random, hmac and shared key parameters and returns a new key
directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops
the reference if there was a previous one. The secret, which where we
eventually double drop the ref comes from sctp_auth_asoc_set_secret() with
intitial refcount of 1, which also stays unchanged eventually in
sctp_assoc_update(). This key is later being used for crypto layer to
set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac().
To close the loop: asoc->asoc_shared_key is freshly allocated secret
material and independant of the sctp_shared_key management keeping track
of only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76
("net: sctp: fix memory leak in auth key management") is independant of
this bug here since it concerns a different layer (though same structures
being used eventually). asoc->asoc_shared_key is reference dropped correctly
on assoc destruction in sctp_association_free() and when active keys are
being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount
of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is
to remove that sctp_auth_key_put() from there which fixes these panics.
Linus Torvalds [Tue, 27 Jan 2015 00:25:42 +0000 (16:25 -0800)]
Merge branch 'akpm' (patches from Andrew Morton)
Merge misc fixes from Andrew Morton:
"Six fixes"
* emailed patches from Andrew Morton <[email protected]>:
drivers/rtc/rtc-s5m.c: terminate s5m_rtc_id array with empty element
printk: add dummy routine for when CONFIG_PRINTK=n
mm/vmscan: fix highidx argument type
memcg: remove extra newlines from memcg oom kill log
x86, build: replace Perl script with Shell script
mm: page_alloc: embed OOM killing naturally into allocation slowpath
net: mv643xx_eth: Use dma_map_single() to map the skb fragments
caused a nasty regression by removing the support for highmem skb
fragments. By using page_address() to get the address of a fragment's
page, we are assuming a lowmem page. However, such assumption is incorrect,
as fragments can be in highmem pages, resulting in very nasty issues.
This commit fixes this by using the skb_frag_dma_map() helper,
which takes care of mapping the skb fragment properly. Additionally,
the type of mapping is now tracked, so it can be unmapped using
dma_unmap_page or dma_unmap_single when appropriate.
This commit also fixes the error path in txq_init() to release the
resources properly.
Fixes: 69ad0dd7af22 ("net: mv643xx_eth: Use dma_map_single() to map the skb fragments") Reported-by: Russell King <[email protected]> Signed-off-by: Ezequiel Garcia <[email protected]> Signed-off-by: David S. Miller <[email protected]>
David S. Miller [Tue, 27 Jan 2015 00:13:20 +0000 (16:13 -0800)]
Merge branch 'sh_eth'
Ben Hutchings says:
====================
Fixes for sh_eth #2
I'm continuing review and testing of Ethernet support on the R-Car H2
chip. This series fixes more of the issues I've found, but it won't be
the last set.
These are not tested on any of the other supported chips.
====================
Ben Hutchings [Thu, 22 Jan 2015 12:44:08 +0000 (12:44 +0000)]
sh_eth: Fix serialisation of interrupt disable with interrupt & NAPI handlers
In order to stop the RX path accessing the RX ring while it's being
stopped or resized, we clear the interrupt mask (EESIPR) and then call
free_irq() or synchronise_irq(). This is insufficient because the
interrupt handler or NAPI poller may set EESIPR again after we clear
it. Also, in sh_eth_set_ringparam() we currently don't disable NAPI
polling at all.
I could easily trigger a crash by running the loop:
while ethtool -G eth0 rx 128 && ethtool -G eth0 rx 64; do echo -n .; done
and 'ping -f' toward the sh_eth port from another machine.
To fix this:
- Add a software flag (irq_enabled) to signal whether interrupts
should be enabled
- In the interrupt handler, if the flag is clear then clear EESIPR
and return
- In the NAPI poller, if the flag is clear then don't set EESIPR
- Set the flag before enabling interrupts in sh_eth_dev_init() and
sh_eth_set_ringparam()
- Clear the flag and serialise with the interrupt and NAPI
handlers before clearing EESIPR in sh_eth_close() and
sh_eth_set_ringparam()
After this, I could run the loop for 100,000 iterations successfully.
Ben Hutchings [Thu, 22 Jan 2015 12:40:25 +0000 (12:40 +0000)]
sh_eth: Detach net device when stopping queue to resize DMA rings
We must only ever stop TX queues when they are full or the net device
is not 'ready' so far as the net core, and specifically the watchdog,
is concerned. Otherwise, the watchdog may fire *immediately* if no
packets have been added to the queue in the last 5 seconds.
What's more, sh_eth_tx_timeout() will likely crash if called while
we're resizing the TX ring.
I could easily trigger this by running the loop:
while ethtool -G eth0 rx 128 && ethtool -G eth0 rx 64; do echo -n .; done
Ben Hutchings [Thu, 22 Jan 2015 12:40:13 +0000 (12:40 +0000)]
sh_eth: Fix padding of short frames on TX
If an skb to be transmitted is shorter than the minimum Ethernet frame
length, we currently set the DMA descriptor length to the minimum but
do not add zero-padding. This could result in leaking sensitive
data. We also pass different lengths to dma_map_single() and
dma_unmap_single().
Use skb_padto() to pad properly, before calling dma_map_single().
In Dual EMAC, the default VLANs are used to segregate Rx packets between
the ports, so adding the same default VLAN to the switch will affect the
normal packet transfers. So returning error on addition of dual EMAC
default VLANs.
Even if EMAC 0 default port VLAN is added to EMAC 1, it will lead to
break dual EMAC port separations.
Dave Airlie [Mon, 26 Jan 2015 23:56:13 +0000 (09:56 +1000)]
Merge branch 'drm-fixes-3.19' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
Suspend/resume regression fix for 3.19.
* 'drm-fixes-3.19' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: Remove rdev->gart.pages_addr array
drm/radeon: Restore GART table contents after pinning it in VRAM v3
drm/radeon: Split off gart_get_page_entry ASIC hook from set_page_entry
David S. Miller [Mon, 26 Jan 2015 23:50:24 +0000 (15:50 -0800)]
Merge branch 'cls_bpf'
Daniel Borkmann says:
====================
Two cls_bpf fixes
Found them while doing a review on act_bpf and going over the
cls_bpf code again. Will also address the first issue in act_bpf
as it needs to be fixed there, too.
====================
Daniel Borkmann [Thu, 22 Jan 2015 09:41:02 +0000 (10:41 +0100)]
net: cls_bpf: fix auto generation of per list handles
When creating a bpf classifier in tc with priority collisions and
invoking automatic unique handle assignment, cls_bpf_grab_new_handle()
will return a wrong handle id which in fact is non-unique. Usually
altering of specific filters is being addressed over major id, but
in case of collisions we result in a filter chain, where handle ids
address individual cls_bpf_progs inside the classifier.
Issue is, in cls_bpf_grab_new_handle() we probe for head->hgen handle
in cls_bpf_get() and in case we found a free handle, we're supposed
to use exactly head->hgen. In case of insufficient numbers of handles,
we bail out later as handle id 0 is not allowed.
Daniel Borkmann [Thu, 22 Jan 2015 09:41:01 +0000 (10:41 +0100)]
net: cls_bpf: fix size mismatch on filter preparation
In cls_bpf_modify_existing(), we read out the number of filter blocks,
do some sanity checks, allocate a block on that size, and copy over the
BPF instruction blob from user space, then pass everything through the
classic BPF checker prior to installation of the classifier.
We should reject mismatches here, there are 2 scenarios: the number of
filter blocks could be smaller than the provided instruction blob, so
we do a partial copy of the BPF program, and thus the instructions will
either be rejected from the verifier or a valid BPF program will be run;
in the other case, we'll end up copying more than we're supposed to,
and most likely the trailing garbage will be rejected by the verifier
as well (i.e. we need to fit instruction pattern, ret {A,K} needs to be
last instruction, load/stores must be correct, etc); in case not, we
would leak memory when dumping back instruction patterns. The code should
have only used nla_len() as Dave noted to avoid this from the beginning.
Anyway, lets fix it by rejecting such load attempts.
Fixes: 7d1d65cb84e1 ("net: sched: cls_bpf: add BPF-based classifier") Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Dave Airlie [Mon, 26 Jan 2015 23:48:33 +0000 (09:48 +1000)]
Merge tag 'drm-amdkfd-fixes-2015-01-26' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes
A couple of fixes for -rc7 in amdkfd:
- Forgot to free resources when creation of queue has failed
- Initialization of pipelines was incorrect (3 patches)
In addition, The patch "drm/amdkfd: Allow user to limit only queues per device"
is not a fix, but I would like to push it for 3.19 as it changes the ABI
between amdkfd and userspace (by changing the module parameters). I would
prefer *not* to support the two deprecated module parameters if I don't have
too, as amdkfd hasn't been released yet.
* tag 'drm-amdkfd-fixes-2015-01-26' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: Fix bug in call to init_pipelines()
drm/amdkfd: Fix bug in pipelines initialization
drm/radeon: Don't increment pipe_id in kgd_init_pipeline
drm/amdkfd: Allow user to limit only queues per device
drm/amdkfd: PQM handle queue creation fault
Dave Airlie [Mon, 26 Jan 2015 23:39:58 +0000 (09:39 +1000)]
Merge branch 'drm-next-3.20' of git://people.freedesktop.org/~agd5f/linux into drm-next
Radeon drm-next changes for 3.20. Highlights:
- Indirect draw support for evergreen/NI hw
- SMC fan control support for SI/CI
- Manual fan control for SI/CI
- DP audio support
- Lots of code cleanup
* 'drm-next-3.20' of git://people.freedesktop.org/~agd5f/linux: (45 commits)
drm/radeon: make MMU_NOTIFIER optional
drm/radeon: use NULL rather then 0 in audio detect
drm/radeon: whitespace clean up in radeon_audio.c
radeon/audio: enable DP audio
radeon/audio: moved audio caps programming to audio_hotplug() function
radeon/audio: applied audio_dpms() and audio_mode_set() calls
radeon/audio: consolidate audio_mode_set() functions
radeon/audio: removed unnecessary debug settings
radeon/audio: moved mute programming to a separate function
radeon/audio: moved audio packet programming to a separate function
radeon/audio: set_avi_packet() function cleanup
radeon/audio: removed unnecessary CRC control programing
radeon: moved HDMI color depth programming to a separate function
radeon/audio: moved VBI packet programming to separate functions
radeon/audio: consolidate update_acr() functions (v2)
radeon/audio: consolidate update_avi_infoframe() functions
radeon/audio: consolidate audio_set_dto() functions
radeon/audio: consolidate audio_fini() functions
radeon/audio: consolidate audio_enable() functions
radeon/audio: consolidate select_pin() functions
...
Dave Airlie [Mon, 26 Jan 2015 23:38:29 +0000 (09:38 +1000)]
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
This pull request includes some code refactoring which removes
Exynos specific structure names and uses generic structure
names instead, and makes all plane updating to be done
by only exynos_update_plane function. And also it includes
some cleanup and fixup patches.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (22 commits)
drm/exynos: fimd: check error status for drm_iommu_attach_device
drm/exynos: create exynos_check_plane()
drm/exynos: remove mode_set() ops from exynos_crtc
drm/exynos: don't duplicate drm_display_mode in fimd context
drm/exynos: remove struct exynos_drm_manager
drm/exynos: remove drm_dev from struct exynos_drm_manager
drm/exynos: move 'type' from manager to crtc struct
drm/exynos: remove pipe member of struct exynos_drm_manager
drm/exynos: add pipe param to exynos_drm_crtc_create()
drm/exynos: rename base object of struct exynos_drm_crtc to 'base'
drm/exynos: remove exynos_drm_crtc_mode_set_commit()
drm/exynos: call exynos_update_plane() directly on page flips
drm/exynos: unify plane update on exynos_update_plane()
drm/exynos: remove exynos_plane_commit() wrapper
drm/exynos: don't do any DPMS operation while updating planes
drm/exynos: Don't touch DPMS when updating overlay planes
drm/exynos/vidi: remove useless ops->commit()
drm/exynos/fimd: don't initialize 'ret' variable in fimd_probe()
drm/exynos: remove struct exynos_drm_overlay
drm/exynos: remove exynos_drm_crtc_plane_* wrappers
...
David S. Miller [Mon, 26 Jan 2015 23:24:14 +0000 (15:24 -0800)]
Merge tag 'linux-can-fixes-for-3.19-20150121' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2015-01-21
this is a pull request for v3.19, net/master, which consists of a single patch.
Viktor Babrian fixes the issue in the c_can dirver, that the CAN interface
might continue to send frames after the interface has been shut down.
====================
Linus Torvalds [Mon, 26 Jan 2015 23:17:34 +0000 (15:17 -0800)]
Merge branch 'for-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup fix from Tejun Heo:
"The lifetime rules of cgroup hierarchies always have been somewhat
counter-intuitive and cgroup core tried to enforce that hierarchies
w/o userland-visible usages must die in finite amount of time so that
the controllers can be reused for other hierarchies; unfortunately,
this can't be implemented reasonably for the memory controller - the
kmemcg part doesn't have any way to forcefully drain the existing
usages, leading to an interruptible hang if a following mount attempts
to use the controller in any way.
So, it seems like we're stuck with "hierarchies live on till they die
whenever that may be" at least for now. This pretty much confines
attaching controllers to hierarchies to before the hierarchies are
actively used by making dynamic configurations post active usages
unreliable. This has never been reliable and should be fine in
practice given how cgroups are used.
After the patch, hierarchies aren't killed if it isn't already
drained. A following mount attempt of the same mount options will
reuse the existing hierarchy. Mount attempts with differing options
will fail w/ -EBUSY"
* 'for-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cgroup: prevent mount hang due to memory controller lifetime
Dave Airlie [Mon, 26 Jan 2015 23:14:15 +0000 (09:14 +1000)]
Merge tag 'drm-amdkfd-next-fixes-2015-01-25' of git://people.freedesktop.org/~gabbayo/linux into drm-next
Here is a pull request of fixes for 3.20 patches, including the fix you asked
me when you merged the previous pull request.
* tag 'drm-amdkfd-next-fixes-2015-01-25' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: change amdkfd version to 0.7.1
drm/radeon: cik_sdma_ctx_switch_enable() can be static
drm/amdkfd: Fix sparse errors
drm/amdkfd: Handle case of invalid queue type
drm/amdkfd: Add break at the end of case
drm/amdkfd: Remove negative check of uint variable
Dave Airlie [Mon, 26 Jan 2015 23:12:53 +0000 (09:12 +1000)]
Merge branch 'drm-tda998x-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm into drm-fixes
3 fixes for the tda998x.
* 'drm-tda998x-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
drm/i2c: tda998x: set the CEC I2C address based on the slave I2C address
drm: tda998x: Fix EDID read timeout on HDMI connect
drm: tda998x: Protect the page register
Dave Airlie [Mon, 26 Jan 2015 23:01:09 +0000 (09:01 +1000)]
Merge tag 'drm-intel-next-2015-01-17' of git://anongit.freedesktop.org/drm-intel into drm-next
- refactor i915/snd-hda interaction to use the component framework (Imre)
- psr cleanups and small fixes (Rodrigo)
- a few perf w/a from Ken Graunke
- switch to atomic plane helpers (Matt Roper)
- wc mmap support (Chris Wilson & Akash Goel)
- smaller things all over
* tag 'drm-intel-next-2015-01-17' of git://anongit.freedesktop.org/drm-intel: (40 commits)
drm/i915: Update DRIVER_DATE to 20150117
i915: reuse %ph to dump small buffers
drm/i915: Ensure the HiZ RAW Stall Optimization is on for Cherryview.
drm/i915: Enable the HiZ RAW Stall Optimization on Broadwell.
drm/i915: PSR link standby at debugfs
drm/i915: group link_standby setup and let this info visible everywhere.
drm/i915: Add missing vbt check.
drm/i915: PSR HSW/BDW: Fix inverted logic at sink main_link_active bit.
drm/i915: PSR VLV/CHV: Remove condition checks that only applies to Haswell.
drm/i915: VLV/CHV PSR needs to exit PSR on every flush.
drm/i915: Fix kerneldoc for i915 atomic plane code
drm/i915: Don't pretend SDVO hotplug works on 915
drm/i915: Don't register HDMI connectors for eDP ports on VLV/CHV
drm/i915: Remove I915_HAS_HOTPLUG() check from i915_hpd_irq_setup()
drm/i915: Make hpd arrays big enough to avoid out of bounds access
Revert "drm/i915/chv: Use timeout mode for RC6 on chv"
drm/i915: Improve HiZ throughput on Cherryview.
drm/i915: Reset CSB read pointer in ring init
drm/i915: Drop unused position fields (v2)
drm/i915: Move to atomic plane helpers (v9)
...
Dave Airlie [Mon, 26 Jan 2015 22:54:11 +0000 (08:54 +1000)]
Merge tag 'topic/core-stuff-2015-01-23' of git://anongit.freedesktop.org/drm-intel into drm-next
Just flushing out my drm-misc branch, nothing major. Well too old patches
I've dug out from years since a patch from Rob look eerily familiar ;-)
* tag 'topic/core-stuff-2015-01-23' of git://anongit.freedesktop.org/drm-intel:
drm/probe-helper: clamp unknown connector status in the poll work
drm/probe-helper: don't lose hotplug event
next: drm/atomic: Use copy_from_user to copy 64 bit data from user space
drm: Make drm_read() more robust against multithreaded races
drm/fb-helper: Propagate errors from initial config failure
drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"
Linus Torvalds [Mon, 26 Jan 2015 22:52:08 +0000 (14:52 -0800)]
Merge tag 'regulator-v3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"One correctness fix here for the s2mps11 driver which would have
resulted in some of the regulators being completely broken together
with a fix for locking in regualtor_put() (which is fortunately rarely
called at all in practical systems)"
* tag 'regulator-v3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: s2mps11: Fix wrong calculation of register offset
regulator: core: fix race condition in regulator_put()
Linus Torvalds [Mon, 26 Jan 2015 22:51:19 +0000 (14:51 -0800)]
Merge tag 'spi-v3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A few driver specific fixes here, some fixes for issues introduced and
discovered during recent work on the DesignWare driver (which has been
getting a lot of attention recently) and a couple of other drivers.
All serious things for people who run into them"
* tag 'spi-v3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: dw: amend warning message
spi: sh-msiof: fix MDR1_FLD_MASK value
spi: dw-mid: fix FIFO size
spi: dw: Fix detecting FIFO depth
spi/pxa2xx: Clear cur_chip pointer before starting next message
Greg Thelen [Mon, 26 Jan 2015 20:58:38 +0000 (12:58 -0800)]
memcg: remove extra newlines from memcg oom kill log
Commit e61734c55c24 ("cgroup: remove cgroup->name") added two extra
newlines to memcg oom kill log messages. This makes dmesg hard to read
and parse. The issue affects 3.15+.
Example:
Task in /t <<< extra #1
killed as a result of limit of /t
<<< extra #2
memory: usage 102400kB, limit 102400kB, failcnt 274712
Remove the extra newlines from memcg oom kill messages, so the messages
look like:
Task in /t killed as a result of limit of /t
memory: usage 102400kB, limit 102400kB, failcnt 240649
Kees Cook [Mon, 26 Jan 2015 20:58:35 +0000 (12:58 -0800)]
x86, build: replace Perl script with Shell script
Commit e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
added Perl to the required build environment. This reimplements in
shell the Perl script used to find the size of the kernel with bss and
brk added.
Johannes Weiner [Mon, 26 Jan 2015 20:58:32 +0000 (12:58 -0800)]
mm: page_alloc: embed OOM killing naturally into allocation slowpath
The OOM killing invocation does a lot of duplicative checks against the
task's allocation context. Rework it to take advantage of the existing
checks in the allocator slowpath.
The OOM killer is invoked when the allocator is unable to reclaim any
pages but the allocation has to keep looping. Instead of having a check
for __GFP_NORETRY hidden in oom_gfp_allowed(), just move the OOM
invocation to the true branch of should_alloc_retry(). The __GFP_FS
check from oom_gfp_allowed() can then be moved into the OOM avoidance
branch in __alloc_pages_may_oom(), along with the PF_DUMPCORE test.
__alloc_pages_may_oom() can then signal to the caller whether the OOM
killer was invoked, instead of requiring it to duplicate the order and
high_zoneidx checks to guess this when deciding whether to continue.
David S. Miller [Mon, 26 Jan 2015 07:38:20 +0000 (23:38 -0800)]
Merge branch 's390'
Ursula Braun says:
====================
s390/qeth patches for net
here are two s390/qeth patches built for net.
One patch is quite large, but we would like to fix the locking warning
seen in recent kernels as soon as possible. But if you want me to submit
these patches for net-next, I will do.
Or Gerlitz says:
====================
Thomas Richter [Wed, 21 Jan 2015 12:39:10 +0000 (13:39 +0100)]
390/qeth: Fix locking warning during qeth device setup
Do not wait for channel command buffers in IPA commands.
The potential wait could be done while holding a spin lock and causes
in recent kernels such a bug if kernel lock debugging is enabled:
The device driver has plenty of command buffers available
per channel for channel command communication.
In the extremely rare case when there is no command buffer
available, return a NULL pointer and issue a warning
in the kernel log. The caller handles the case when
a NULL pointer is encountered and returns an error.
In the case the wait for command buffer is possible
(because no lock is held as in the OSN case), still wait
until a channel command buffer is available.
Eugene Crosser [Wed, 21 Jan 2015 12:39:09 +0000 (13:39 +0100)]
qeth: clean up error handling
In the functions that are registering and unregistering MAC
addresses in the qeth-handled hardware, remove callback functions
that are unnesessary, as only the return code is analyzed.
Translate hardware response codes to semi-standard 'errno'-like
codes for readability.
Add kernel-doc description to the internal API function
qeth_send_control_data().
Matt Roper [Mon, 19 Jan 2015 16:31:49 +0000 (08:31 -0800)]
drm/plane-helper: Skip prepare_fb/cleanup_fb when newfb==oldfb
When commiting a plane update where the framebuffer doesn't change, we
can skip the prepare_fb/cleanup_fb steps. This also allows us to avoid
an unnecessary vblank wait at the end of the operation when we're just
moving a plane and not changing its image (e.g., for a cursor).
At the moment, i915 is the only upstream driver using the transitional
plane helpers, and thus the only driver affected by this change.
Note that this replicates a corresponding change in the atomic helpers
implemented in
Martin KaFai Lau [Wed, 21 Jan 2015 03:16:02 +0000 (19:16 -0800)]
ipv6: Fix __ip6_route_redirect
In my last commit (a3c00e4: ipv6: Remove BACKTRACK macro), the changes in
__ip6_route_redirect is incorrect. The following case is missed:
1. The for loop tries to find a valid gateway rt. If it fails to find
one, rt will be NULL.
2. When rt is NULL, it is set to the ip6_null_entry.
3. The newly added 'else if', from a3c00e4, will stop the backtrack from
happening.
Linus Torvalds [Mon, 26 Jan 2015 02:11:17 +0000 (18:11 -0800)]
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"Hopefully the last round of fixes for 3.19
- regression fix for the LDT changes
- regression fix for XEN interrupt handling caused by the APIC
changes
- regression fixes for the PAT changes
- last minute fixes for new the MPX support
- regression fix for 32bit UP
- fix for a long standing relocation issue on 64bit tagged for stable
- functional fix for the Hyper-V clocksource tagged for stable
- downgrade of a pr_err which tends to confuse users
Looks a bit on the large side, but almost half of it are valuable
comments"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/tsc: Change Fast TSC calibration failed from error to info
x86/apic: Re-enable PCI_MSI support for non-SMP X86_32
x86, mm: Change cachemode exports to non-gpl
x86, tls: Interpret an all-zero struct user_desc as "no segment"
x86, tls, ldt: Stop checking lm in LDT_empty
x86, mpx: Strictly enforce empty prctl() args
x86, mpx: Fix potential performance issue on unmaps
x86, mpx: Explicitly disable 32-bit MPX support on 64-bit kernels
x86, hyperv: Mark the Hyper-V clocksource as being continuous
x86: Don't rely on VMWare emulating PAT MSR correctly
x86, irq: Properly tag virtualization entry in /proc/interrupts
x86, boot: Skip relocs when load address unchanged
x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi
ACPI: pci: Do not clear pci_dev->irq in acpi_pci_irq_disable()
x86/xen: Treat SCI interrupt as normal GSI interrupt
Linus Torvalds [Mon, 26 Jan 2015 02:07:01 +0000 (18:07 -0800)]
Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Thomas Gleixner:
"From the irqchip departement you get:
- regression fix for omap-intc
- regression fix for atmel-aic-common
- functional correctness fix for hip04
- type mismatch fix for gic-v3-its
- proper error pointer check for mtd-sysirq
Mostly one and two liners except for the omap regression fix which is
slightly larger than desired"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip: atmel-aic-common: Prevent clobbering of priority when changing IRQ type
irqchip: omap-intc: Fix legacy DMA regression
irqchip: gic-v3-its: Fix use of max with decimal constant
irqchip: hip04: Initialize hip04_cpu_map to 0xffff
irqchip: mtk-sysirq: Use IS_ERR() instead of NULL pointer check
Linus Torvalds [Mon, 26 Jan 2015 01:47:34 +0000 (17:47 -0800)]
Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fixes from Thomas Gleixner:
"A set of small fixes:
- regression fix for exynos_mct clocksource
- trivial build fix for kona clocksource
- functional one liner fix for the sh_tmu clocksource
- two validation fixes to prevent (root only) data corruption in the
kernel via settimeofday and adjtimex. Tagged for stable"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
time: adjtimex: Validate the ADJ_FREQUENCY values
time: settimeofday: Validate the values of tv from user
clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast
clocksource: kona: fix __iomem annotation
clocksource: exynos_mct: Fix bitmask regression for exynos4_mct_write
Linus Torvalds [Mon, 26 Jan 2015 01:29:06 +0000 (17:29 -0800)]
Merge tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"A week's worth of fixes for various ARM platforms. Diff wise, the
largest fix is for OMAP to deal with how GIC now registers interrupts
(irq_domain_add_legacy() -> irq_domain_add_linear() changes).
Besides this, a few more renesas platforms needed the GIC instatiation
done for legacy boards. There's also a fix that disables coherency of
mvebu due to issues, and a few other smaller fixes"
* tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
arm64: dts: add baud rate to Juno stdout-path
ARM: dts: imx25: Fix PWM "per" clocks
bus: mvebu-mbus: fix support of MBus window 13
Merge tag 'mvebu-fixes-3.19-3' of git://git.infradead.org/linux-mvebu into fixes
ARM: mvebu: completely disable hardware I/O coherency
ARM: OMAP: Work around hardcoded interrupts
ARM: shmobile: r8a7779: Instantiate GIC from C board code in legacy builds
ARM: shmobile: r8a7778: Instantiate GIC from C board code in legacy builds
arm: boot: dts: dra7: enable dwc3 suspend PHY quirk
Linus Torvalds [Mon, 26 Jan 2015 01:27:18 +0000 (17:27 -0800)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull vfs fixes from Al Viro:
"A couple of fixes - deadlock in CIFS and build breakage in cris serial
driver (resurfaced f_dentry in there)"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
VFS: Convert file->f_dentry->d_inode to file_inode()
fix deadlock in cifs_ioctl_clone()
Linus Torvalds [Mon, 26 Jan 2015 01:25:01 +0000 (17:25 -0800)]
Merge tag 'dm-3.19-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
"Two stable fixes for dm-cache and one 3.19 DM core fix:
- fix potential for dm-cache metadata corruption via stale metadata
buffers being used when switching an inactive cache table to
active; this could occur due to each table having it's own bufio
client rather than sharing the client between tables.
- fix dm-cache target to properly account for discard IO while
suspending otherwise IO quiescing could complete prematurely.
- fix DM core's handling of multiple internal suspends by maintaining
an 'internal_suspend_count' and only resuming the device when this
count drops to zero"
* tag 'dm-3.19-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm: fix handling of multiple internal suspends
dm cache: fix problematic dual use of a single migration count variable
dm cache: share cache-metadata object across inactive and active DM tables
Linus Torvalds [Mon, 26 Jan 2015 01:23:34 +0000 (17:23 -0800)]
Merge branch 'for-linus' of git://git.kernel.dk/linux-block
Pull two block layer fixes from Jens Axboe:
"Two small patches that should make it into 3.19:
- a fixup from me for NVMe, making the cq_vector a signed variable.
Otherwise our -1 comparison fails, and commit 2b25d981790b doesn't
do what it was supposed to.
- a fixup for the hotplug handling for blk-mq from Ming Lei, using
the proper kobject referencing to ensure we release resources at
the right time"
* 'for-linus' of git://git.kernel.dk/linux-block:
blk-mq: fix hctx/ctx kobject use-after-free
NVMe: cq_vector should be signed
Vivien Didelot [Wed, 21 Jan 2015 00:13:32 +0000 (19:13 -0500)]
net: dsa: set slave MII bus PHY mask
When registering a mdio bus, Linux assumes than every port has a PHY and tries
to scan it. If a switch port has no PHY registered, DSA will fail to register
the slave MII bus. To fix this, set the slave MII bus PHY mask to the switch
PHYs mask.
As an example, if we use a Marvell MV88E6352 (which is a 7-port switch with no
registered PHYs for port 5 and port 6), with the following declared names:
DSA will fail to create the switch instance. With the PHY mask set for the
slave MII bus, only the PHY for ports 0-4 will be scanned and the instance will
be successfully created.
Gustavo Padovan [Sun, 18 Jan 2015 09:16:23 +0000 (18:16 +0900)]
drm/exynos: remove struct exynos_drm_manager
exynos_drm_manager was just a redundant struct to represent the crtc as
well. In this commit we merge exynos_drm_manager into exynos_drm_crtc to
remove an unnecessary level of indirection easing the understand of the
flow on exynos.
Gustavo Padovan [Wed, 26 Nov 2014 18:43:27 +0000 (16:43 -0200)]
drm/exynos: remove drm_dev from struct exynos_drm_manager
manager-drm_dev is only accessed by exynos_drm_crtc_create() so this patch
pass drm_dev as argument on exynos_drm_crtc_create() and remove it from
struct exynos_drm_manager.
Gustavo Padovan [Tue, 25 Nov 2014 13:21:17 +0000 (11:21 -0200)]
drm/exynos: unify plane update on exynos_update_plane()
We can safely use the exynos_update_plane() to update the plane
framebuffer for both the overlay and primary planes.
Note that this patch removes a call to manager->ops->commit() in
exynos_drm_crtc_mode_set_commit(). The commit() call is used only by the
fimd driver to set underlying timings and need only in full modeset
operations. For plane update only win_commit is needed.
Gustavo Padovan [Mon, 3 Nov 2014 20:13:27 +0000 (18:13 -0200)]
drm/exynos: remove struct exynos_drm_overlay
struct exynos_drm_overlay has no practical advantage nor serves as
important piece of the exynos API design. The only place it was used
was inside the struct exynos_plane which was just causing a extra
access overhead. Users had to access the overlay first and just then
get the plane information it contains.
This patch merges struct exynos_drm_overlay into struct exynos_plane.
It also renames struct exynos_plane to struct exynos_drm_plane.
The rational is to cut one step to access plane information.
Gustavo Padovan [Fri, 31 Oct 2014 17:33:30 +0000 (17:33 +0000)]
drm/exynos: expose struct exynos_drm_crtc
Let other pieces of the driver access struct exynos_drm_crtc as well.
struct exynos_drm_manager will be merged into struct exynos_drm_crtc, in
the sense we will move all its members to exynos_drm_crtc, so to start
this conversion exynos_drm_crtc need to be exposed as well.
Mahesh Bandewar [Sun, 25 Jan 2015 05:53:43 +0000 (21:53 -0800)]
ipvlan: fix incorrect usage of IS_ERR() macro in IPv6 code path.
The ip6_route_output() always returns a valid dst pointer unlike in IPv4
case. So the validation has to be different from the IPv4 path. Correcting
that error in this patch.
This was picked up by a static checker with a following warning -
drivers/net/ipvlan/ipvlan_core.c:380 ipvlan_process_v6_outbound()
warn: 'dst' isn't an ERR_PTR
Sasha Levin [Sat, 24 Jan 2015 01:47:00 +0000 (20:47 -0500)]
net: llc: use correct size for sysctl timeout entries
The timeout entries are sizeof(int) rather than sizeof(long), which
means that when they were getting read we'd also leak kernel memory
to userspace along with the timeout values.
With the commit d75b1ade567ffab ("net: less interrupt masking in NAPI") napi repoll
is done only when work_done == budget. When we are in busy_poll we return 0 in
napi_poll. We should return budget.