This patch changes the IEEE 802.15.4 subsystem maintainer to Alexander Aring.
We discussed this change before via e-mail and I collected the acks from the
current maintainers.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Acked-by: Alexander Smirnov <alex.bluesman.sminov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since AI lines could be selected at will (linux-3.11) the sending
and receiving ends of the FIFO does not agree about what step is used
for a line. It only works if the last lines are used, like 5,6,7,
and fails if ie 2,4,6 is selected in DT.
Signed-off-by: Jan Kardell <jan.kardell@telliq.com>
Tested-by: Zubair Lutfullah <zubair.lutfullah@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: stable@vger.kernel.org
Nothing major, but potentially annoying and worthwhile to fix.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTvCJCAAoJEMsfJm/On5mB1J0QAIWyzyNIpvKpMb3s7lf282vu
zsBkIa6/7Bigi9cOdpI9HuMgI6tqtbakYGyja/sZyiVmcS8VMzn8qC2Ae3cqJhr9
bOxY+l8qnQ75nauE99SuLul4tRqMi5WLOUnoCwZgH1uQegR4Ap9ffnVz8l2U9ZoF
8UsigejxIxcSGZ3L1ad9Al6IWzrnWVKGxbbaZB2EjKthwN2ptjhlUxBjNRAvwMtC
SC3YrFGpFnJ1FY9kioCY7eKm37FbZ3ZlCGu+EhDNhQbXa7WQYMlEQLvFux7Cf7qG
gYMV+IrPks8gkDXHqMcyaDwQVH8+Agd9CpD4HRf5yotT7e6dzOcSjRmJY/Dw50W4
AG3XIy6VQkdGfpiuKoljYnvSxMWzfyy48cE0QbCTDLcB07lENw6VyB0zsDWvmvsp
RXAdz7Xg6GsRYUXBcKNNxG4g1MV4eYkoNMyW4eLJ9uqwQ0Kf1JYwg+w4tmtG20s5
zb5FhnHT1Zr/b1Z7EsbX5YXEM9CKchjRPDwzjtLZiu5FQaupMDwUeQggLcCue5Tp
RwkMuzO0JpThkgswKHhkmuvlKJPrt8eVr9J4aAaymiZXGa/5P0aDelI4+eWJp4cr
yMwzKLxv9e9MELKRCAAfL16IJDTO570gENMyuRU17TSYCVnIklNfdZ9XAhxFOtbJ
8SUxBvC3l3bdjuXXhKaD
=otbz
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
"Fix a number of zero-day bugs, mostly found with module test scripts.
Nothing major, but potentially annoying and worthwhile to fix"
* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (adc128d818) Drop write support on inX_input attributes
hwmon: (emc2103) Clamp limits instead of bailing out
hwmon: (adm1031) Fix writes to limit registers
hwmon: (adm1021) Fix cache problem when writing temperature limits
hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div
hwmon: (amc6821) Fix permissions for temp2_input
hwmon: (ntc_thermistor) Correct information printed during probe
David Vrabel says:
====================
xen-netfront: multi-queue related locking fixes
Two fixes to the per-queue locking bugs in xen-netfront that were
introduced in 3.16-rc1 with the multi-queue support.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
In xennet_disconnect_backend(), netif_carrier_off() was called once
per queue when it needs to only be called once.
The queue locking around the netif_carrier_off() call looked very
odd. I think they were supposed to synchronize any NAPI instances with
the expectation that no further NAPI instances would be scheduled
because of the carrier being off (see the check in
xennet_rx_interrupt()). But I can't easily tell if this works
correctly.
Instead, add a napi_synchronize() call after disabling the interrupts.
This is obviously correct as with no Rx interrupts, no further NAPI
instances will be scheduled.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The nesting of the per-queue rx_lock and tx_lock in xennet_connect()
is confusing to both humans and lockdep. The locking is safe because
this is the only place where the locks are nested in this way but
lockdep still warns.
Instead of adding the missing lockdep annotations, refactor the
locking to avoid the confusing nesting. This is still safe, because
the xenbus connection state changes are all serialized by the xenwatch
thread.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
include/linux/sched.h implements TASK_SIZE_OF as TASK_SIZE if it
is not set by the architecture headers. TASK_SIZE uses the
current task to determine the size of the virtual address space.
On a 64-bit kernel this will cause reading /proc/pid/pagemap of a
64-bit process from a 32-bit process to return EOF when it reads
past 0xffffffff.
Implement TASK_SIZE_OF exactly the same as TASK_SIZE with
test_tsk_thread_flag instead of test_thread_flag.
Cc: stable@vger.kernel.org
Signed-off-by: Colin Cross <ccross@android.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The __cpu_clear_user_page() and __cpu_copy_user_page() functions
are not currently exported. This prevents modules from using
clear_user_page() and copy_user_page().
Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This patch fixes the dma state machine lockup due to the processing
of IDENTIFY DEVICE PIO mode command. The X-Gene AHCI controller
has an errata in which it cannot clear the BSY bit after the PIO setup
FIS. The dma state machine enters CMFatalErrorUpdate state and locks
up. This patch also removes the dma restart workaround from the read_id
function as the read_id function is only called by libata layer for
ATA_INTERNAL commands. But for some cases eg: PORT MULTIPLIER
and udev, the framework will enumerate using SCSI commands and it will
not call read_id function.
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The subsequent patch will make use of them.
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Vendor ID 0x10de0070 is used by a yet-to-be-named GPU chip.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This code is not working currently and it can be removed. There is a
conflict in sharing resources with the actual HDMI driver and with
the ASoC HDMI audio DAI driver.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
PRCM code (when DSPBridge is used) for v3.16-rc.
Basic build, boot, and PM test logs are available here:
http://www.pwsan.com/omap/testlogs/prcm-a-v3.16-rc/20140706174258/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTusBYAAoJEMePsQ0LvSpL0JgQAKsVXDTh1yeLzU1NT3Np0zJs
rptjUTz3KGdq0ReU5N1Oe0J/cGbz4JFcN/Ug7l2fywKFeqK7QBBzcWL9NBVYKP+v
OndbBi7OARd6iYEYsJwgFERe86ZwpE1KpR4Vnyo9uv3sA2AbbXbwvbjC0d/sktnV
oCC83X2ahYauPj0/6suHtiZamuTvThCmM3hxMH2TFFoPaQKKV5BHp8dRXNjCZ5jg
s/dfCX3dgb9S9HGbgsZBToqTmyMQ09hv0H0m3KAOveJQFgdwBSDgE94chOSdx3Kk
DanBawF1LJmkpFwLUcTIbIkdBjGBBat4b2EVgPjyEFqWqWJgEHs56vSLsSwCkbi5
9tIu67aUP7VJCsibWECAOMtli7uYy/liYY/dUZhqrck6TT1tukhHKjjsuWr/9xY+
TU/Rd8PA5ytp92r2AkdN+Ztz6j1HUQQbGPmmIfOHuBB4WilwSF0Zgx+3c6bc9hMf
36J0qLYowaBYY57UN6joLGiPNcR7TgsEunCzsCxuGGby4rpFqy95Ml2aWFRn32bH
LUgmAgaSNlk+v4E1iG7jJMHoH2xpKw+2+PNkIVC3WE8saE10qjZvebNUVJXb9bY1
VMuLHHrSc148ou0g+rM4ehF3PEbIBPd4SOxFwVsefPbAnpUSC+hj+SptYGWbLPJJ
D+2noXhqssqVlvizxGoj
=CanJ
-----END PGP SIGNATURE-----
Merge tag 'for-v3.16-rc/omap-fixes-b' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.16/fixes
Some miscellaneous fixes for OMAP clock code, DRA7xx device data, and
PRCM code (when DSPBridge is used) for v3.16-rc.
Basic build, boot, and PM test logs are available here:
http://www.pwsan.com/omap/testlogs/prcm-a-v3.16-rc/20140706174258/
The undo code assumes that, upon entering loss recovery, TCP
1) always retransmit something
2) the retransmission never fails locally (e.g., qdisc drop)
so undo_marker is set in tcp_enter_recovery() and undo_retrans is
incremented only when tcp_retransmit_skb() is successful.
When the assumption is broken because TCP's cwnd is too small to
retransmit or the retransmit fails locally. The next (DUP)ACK
would incorrectly revert the cwnd and the congestion state in
tcp_try_undo_dsack() or tcp_may_undo(). Subsequent (DUP)ACKs
may enter the recovery state. The sender repeatedly enter and
(incorrectly) exit recovery states if the retransmits continue to
fail locally while receiving (DUP)ACKs.
The fix is to initialize undo_retrans to -1 and start counting on
the first retransmission. Always increment undo_retrans even if the
retransmissions fail locally because they couldn't cause DSACKs to
undo the cwnd reduction.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The add_vxlan_port ndo driver code was wrongly testing whether HW vxlan offloads
are supported by the device instead of checking if they are currently enabled.
This causes the driver to configure the HW parser to conduct matching for vxlan
packets but since no steering rules were set, vxlan packets are dropped on RX.
Fix that by doing the right test, as done in the del_vxlan_port ndo handler.
Fixes: 1b136de ('net/mlx4: Implement vxlan ndo calls')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The problem was triggered by these steps:
1) create socket, bind and then setsockopt for add mc group.
mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37");
mreq.imr_interface.s_addr = inet_addr("192.168.1.2");
setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));
2) drop the mc group for this socket.
mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37");
mreq.imr_interface.s_addr = inet_addr("0.0.0.0");
setsockopt(sockfd, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));
3) and then drop the socket, I found the mc group was still used by the dev:
netstat -g
Interface RefCnt Group
--------------- ------ ---------------------
eth2 1 255.0.0.37
Normally even though the IP_DROP_MEMBERSHIP return error, the mc group still need
to be released for the netdev when drop the socket, but this process was broken when
route default is NULL, the reason is that:
The ip_mc_leave_group() will choose the in_dev by the imr_interface.s_addr, if input addr
is NULL, the default route dev will be chosen, then the ifindex is got from the dev,
then polling the inet->mc_list and return -ENODEV, but if the default route dev is NULL,
the in_dev and ifIndex is both NULL, when polling the inet->mc_list, the mc group will be
released from the mc_list, but the dev didn't dec the refcnt for this mc group, so
when dropping the socket, the mc_list is NULL and the dev still keep this group.
v1->v2: According Hideaki's suggestion, we should align with IPv6 (RFC3493) and BSDs,
so I add the checking for the in_dev before polling the mc_list, make sure when
we remove the mc group, dec the refcnt to the real dev which was using the mc address.
The problem would never happened again.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Let's say clock A and B are two gate clocks that share the same register
bit in hardware. Therefore they are registered as shared gate clocks
with imx_clk_gate2_shared().
In a scenario that only clock A is enabled by clk_enable(A) while B is
not used, the shared gate will be unexpectedly disabled in hardware.
It happens because clk_enable(A) increments the share_count from 0 to 1,
while clock B is unused to clock core, and therefore the core function
will just disable B by calling clk->ops->disable() directly. The
consequence of that call is share_count is decremented to 0 and the gate
is disabled in hardware, even though clock A is still in use.
The patch fixes the issue by initializing the share_count per hardware
state and returns enable state per share_count from .is_enabled() hook,
in case it's a shared gate.
While at it, add a check in clk_gate2_disable() to ensure it's never
called with a zero share_count.
Reported-by: Fabio Estevam <fabio.estevam@freescale.com>
Fixes: f9f28cdf21 ("ARM: imx: add shared gate clock support")
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
A bug was introduced in NETDEV_CHANGE notifier sequence causing the
arp table to be sometimes spuriously cleared (including manual arp
entries marked permanent), upon network link carrier changes.
The changed argument for the notifier was applied only to a single
caller of NETDEV_CHANGE, missing among others netdev_state_change().
So upon net_carrier events induced by the network, which are
triggering a call to netdev_state_change(), arp_netdev_event() would
decide whether to clear or not arp cache based on random/junk stack
values (a kind of read buffer overflow).
Fixes: be9efd3653 ("net: pass changed flags along with NETDEV_CHANGE event")
Fixes: 6c8b4e3ff8 ("arp: flush arp cache on IFF_NOARP change")
Signed-off-by: Loic Prylli <loicp@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- fix the check for SMP configuration with using CONFIG_SMP
not just SMP
- fix the number of pwm-cells for exynos4 pwm
- fix ftrace for exynos_mct
- register exynos_mct for stable udely
- fix secondary boot addr for secure mode for exynos SoCs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJTuyiZAAoJEA0Cl+kVi2xqDCQQAI59MYn7mOSxQ4egjR65SFXc
5g0yQIGsfWw1+FXDr1X64Okq5HjY8YHTbkyo9nzjNcmABwHK/oJXWVpJuk4b61e6
eKA5hgiSa1grvz4uzW1ZR+pRooEOn7sJe3OYcesPrsbnsXBLzmV+9HJ2x657asCx
Ran010mw+QNfyOikARFIWaVB9REbK1n5mcKAoAeW3iFAp94xCH0d5Qj0IiQxAam9
8zdEogfY3+YcB+frOaZH1OzVCZ1wLjDdmv86SwvcixuvPU7Lcr91vDFbc0cE7DVj
pHZtIoMi8RZk3twtMLhAnJz+fNygUGN7kBMW3P42ULkgMxIQMGfqmWvgBpUJ8XO6
2wVZ6WnW6jN1OXyNsNM/yyDtm+hdryaIP+WdMfrol8gRevilNniyPwd83HSKTJg8
HHAazUAZZTS+04x19aBBO2RU5vhHSimbOOsXIlJen4Tz5BBwebDQ38JnKRSElgm1
5w+8BajzVt5YTaW2NJ7T87wb/ytV8/MNKZ58GOzh2EXIbnohKbs0qM1ip0RztWLA
ZvEyTF86+fA55W5wrSb6qfz428hCWkJ1PnPCXVPvffNGsrdOM+ziC8G1fhDVw5TJ
TVoktLhz7kU+1aB7272NbXVI9GaJ8vTl0pMpcN5sHI4NCq3g+8SylfaJt3aW5zcy
kKsxM4bvZyMXstwAIlVo
=jlRt
-----END PGP SIGNATURE-----
Merge tag 'samsung-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes
Merge "Samsung fixes-2 for v3.16" from Kukjin Kim:
- fix the check for SMP configuration with using CONFIG_SMP
not just SMP
- fix the number of pwm-cells for exynos4 pwm
- fix ftrace for exynos_mct
- register exynos_mct for stable udely
- fix secondary boot addr for secure mode for exynos SoCs
* tag 'samsung-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Update secondary boot addr for secure mode
clocksource: exynos_mct: Register the timer for stable udelay
clocksource: exynos_mct: Fix ftrace
ARM: dts: fix pwm-cells in pwm node for exynos4
ARM: EXYNOS: Fix the check for non-smp configuration
Signed-off-by: Olof Johansson <olof@lixom.net>
Pull "Renesas ARM Based SoC Maintainers Updates for v3.17" from Simon Horman:
* Expand ARM/SHMOBILE maintainers entry to cover
DT and defconfig files.
* tag 'renesas-maintainers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: Add DT and defconfigs to MAINTAINERS
Signed-off-by: Olof Johansson <olof@lixom.net>
There's a new version of the Telewell 4G modem working with, but not
recognized by this driver.
Signed-off-by: Bernd Wachter <bernd.wachter@jolla.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
The display in fdo#76483 pulses the hotplug line for link retraining
after we cut power to the main link on the source, even while it's
in D3.
fdo#76483
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Under some complicated circumstances (boot, suspend, resume, attach
second display, suspend, resume, suspend, detach second display,
resume, suspend, attach second display, resume), the fb_set_suspend()
call can somehow result in a modeset being attempted before we're
ready for it and things blow up in fun ways.
Running display init first fixes the issue.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's Apple machines out there which (probably completely arbitrarily)
restrict each output path to a particular head. This causes us to not
be able to locate the output data needed to power on/off the DP output
correctly.
We fix this by passing in a head index we know is valid (as opposed to
"head 0").
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When gcc 4.8 inlines this function, it eats up 16 bytes on the stack
every time. Eventually we hit warnings because our stack grew too
much:
ramnve0.c:1383:1: error: the frame size of 1496 bytes is larger than
1024 bytes
We fix this by preventing inlining for this function.
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This reverts commit 0acf167687.
Breaks the build due to missing reference to phy_resume in
the resulting dwmac-socfpga.o object.
Signed-off-by: David S. Miller <davem@davemloft.net>
deal with a compile warning: comparison between
'enum qe_fltr_largest_external_tbl_lookup_key_size'
and 'enum qe_fltr_tbl_lookup_key_size'
the code:
"if (ug_info->largestexternallookupkeysize ==
QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES)"
is warned because different enum, so modify it.
"enum qe_fltr_largest_external_tbl_lookup_key_size
largestexternallookupkeysize;
enum qe_fltr_tbl_lookup_key_size {
QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES
= 0x3f, /* LookupKey parsed by the Generate LookupKey
CMD is truncated to 8 bytes */
QE_FLTR_TABLE_LOOKUP_KEY_SIZE_16_BYTES
= 0x5f, /* LookupKey parsed by the Generate LookupKey
CMD is truncated to 16 bytes */
};
/* QE FLTR extended filtering Largest External Table Lookup Key Size */
enum qe_fltr_largest_external_tbl_lookup_key_size {
QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_NONE
= 0x0,/* not used */
QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_8_BYTES
= QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES, /* 8 bytes */
QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_16_BYTES
= QE_FLTR_TABLE_LOOKUP_KEY_SIZE_16_BYTES, /* 16 bytes */
};"
Signed-off-by: Zhao Qiang <B45475@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pravin B Shelar says:
====================
Open vSwitch
A set of fixes for net.
First bug is related flow-table management. Second one is in sample
action. Third is related flow stats and last one add gre-err handler for ovs.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
In process_backlog the input_pkt_queue is only checked once for new
packets and quota is artificially reduced to reflect precisely the
number of packets on the input_pkt_queue so that the loop exits
appropriately.
This patches changes the behavior to be more straightforward and
less convoluted. Packets are processed until either the quota
is met or there are no more packets to process.
This patch seems to provide a small, but noticeable performance
improvement. The performance improvement is a result of staying
in the process_backlog loop longer which can reduce number of IPI's.
Performance data using super_netperf TCP_RR with 200 flows:
Before fix:
88.06% CPU utilization
125/190/309 90/95/99% latencies
1.46808e+06 tps
1145382 intrs.sec.
With fix:
87.73% CPU utilization
122/183/296 90/95/99% latencies
1.4921e+06 tps
1021674.30 intrs./sec.
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some older router implementations still send Fragmentation Needed
errors with the Next-Hop MTU field set to zero. This is explicitly
described as an eventuality that hosts must deal with by the
standard (RFC 1191) since older standards specified that those
bits must be zero.
Linux had a generic (for all of IPv4) implementation of the algorithm
described in the RFC for searching a list of MTU plateaus for a good
value. Commit 46517008e1 ("ipv4: Kill ip_rt_frag_needed().")
removed this as part of the changes to remove the routing cache.
Subsequently any Fragmentation Needed packet with a zero Next-Hop
MTU has been discarded without being passed to the per-protocol
handlers or notifying userspace for raw sockets.
When there is a router which does not implement RFC 1191 on an
MTU limited path then this results in stalled connections since
large packets are discarded and the local protocols are not
notified so they never attempt to lower the pMTU.
One example I have seen is an OpenBSD router terminating IPSec
tunnels. It's worth pointing out that this case is distinct from
the BSD 4.2 bug which incorrectly calculated the Next-Hop MTU
since the commit in question dismissed that as a valid concern.
All of the per-protocols handlers implement the simple approach from
RFC 1191 of immediately falling back to the minimum value. Although
this is sub-optimal it is vastly preferable to connections hanging
indefinitely.
Remove the Next-Hop MTU != 0 check and allow such packets
to follow the normal path.
Fixes: 46517008e1 ("ipv4: Kill ip_rt_frag_needed().")
Signed-off-by: Edward Allcutt <edward.allcutt@openmarket.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
As per the user manual, it should be CLK_MAU_EPLL.
The problem surfaced when the bootloader in Peach-pit board set
the EPLL clock as the parent of AUDSS mux. While booting the kernel,
we used to get a system hang during late boot if CLK_MAU_EPLL was
disabled.
Signed-off-by: Tushar Behera <tushar.b@samsung.com>
Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
Reported-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Almost all Exynos-series of SoCs that run in secure mode don't need
additional offset for every CPU, with Exynos4412 being the only
exception.
Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420).
While at it, fix the coding style (space around *).
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Tested-by: Andreas Faerber <afaerber@suse.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Fix backlight control for Acer TravelMate B113 Laptop by adding
it to the video_dmi_table.
A workaround before that was to use acpi_osi=Linux or
acpi_backlight=vendor on boot but even then, only the function-
keys worked.
With this change there is no need for boot parameters and DE's
controls work as well.
Signed-off-by: Martin Kepplinger <martink@posteo.de>
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
With win8 capabiltiy, the ACPI backlight control is broken.
The system also loses backlight setting when resuming from S3.
Add this model to the the ACPI video detect blacklist to make backlight
functionality work.
Although backlight functionality works via video.use_native_backlight=1,
this approach may be safer.
Signed-off-by: Edward Lin <yidi.lin@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Some Thinkpad laptops' firmware will initiate a backlight level change
request through operation region on the events of AC plug/unplug, but
since we are not using firmware's interface to do the backlight setting
on these affected laptops, we do not want the firmware to use some
arbitrary value from its ASL variable to set the backlight level on
AC plug/unplug either.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=76491
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77091
Reported-and-tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Reported-and-tested-by: Anton Gubarkov <anton.gubarkov@gmail.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It seems that some batteries (noticed on DELL JYPJ136) assume
capacity_now = design_capacity when fully charged. This causes
reported capacity to suddenly jump to >full_charge_capacity (and that
means capacity reported to userspace is >100% and incorrect)
values after 99%. This patch detects capacity_now > full_charge_capacity,
notifies userspace (unless it is the known bug where capacity_now ==
design_capacity) and trims the value to full_charge_capacity.
Signed-off-by: Josef Gajdusek <atx@atx.name>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull thermal fixes from Zhang Rui:
"Specifics:
- update Email address of Thermal subsystem maintainer Eduardo
Valentin.
- fix a problem that unloading thermal module results in kernel crash
because a non-exist device file is removed on thermal unload.
- fix a problem that critical trip point is set wrongly on latest
i.MX6 SOC and results in system critical shutdown.
- a couple of fixes to Tmon tool, of-thermal code and ti thermal
driver"
* 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
tmon: set umask to a reasonable value
tmon: Check log file for common secuirty issues
tools/thermal: tmon: fix compilation errors when building statically
thermal: ti-soc-thermal: ti-bandgap.c: Cleaning up wrong address is checked
Thermal: imx: correct critical trip temperature setting
thermal: Bind cooling devices with the correct arguments
thermal: Add braces around suspect code
thermal: hwmon: Make the check for critical temp valid consistent
MAINTAINERS: Update Eduardo Valentin's email address
Pull HID fixes from Jiri Kosina:
"A few tiny HID subsystem fixes for 3.16"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: use multi input quirk for 22b9:2968
HID: sensor-hub: fix potential memory leak
HID: usbhid: quirk for PM1610 and PM1640 Touchscreen.
HID: rmi: Protect PM-only functions by #ifdef CONFIG_PM
HID: sensor-hub: introduce Kconfig dependency on IOMEM
HID: sensor-hub: make dyn_callback_lock IRQ-safe
the errorpath in probe().
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTul7RAAoJEEEQszewGV1zyP4QAMZxc5gVf5zOjyd+EtxuYkiC
lWxR4c8uzet8FQ6J0uMdThG6sK4TTFKNz+rP69DUcRY8EM03fgkgCVkynkWzYftZ
YcgxUAJDNxXygy+GxvfL5qQMQVHCSPfj6knqsOK2b26fwt5Y4u0TbI5NWC/rMe4B
sN0NQTdLxYOBVnYbgDRYCsQ7+2HbwCRsBrShdTgISw49qK2q2EhrbIvbjmFYZBSa
u2cRKYy9MOHSwDd0S/ryIQ4wYiq/MGWtu1RP5zb+1GJzXPDOYhQnwMDsGgqTlIk3
2wMy3T2psvk542pUYm3lxzWc2v39eKzvvwqG9NWrdXml42EcI8FnqnJ34hSBXM8y
dS1laWks9m10RxnOiiDHpa2f85raBDlGou1awHwSrfXQHm+PqNcMgDTgmnIRiIUi
OunLqh3fhYqBisAExzqaagchjpGpCTQTuWS3xgzRdwj6NIZkr7yvDyFfUM0oVPJ/
Yzyl677+I5ppp41YrYLVGGtsj+f2ao+epsz5pD+9uC+HbhMYeo1pJXT3IbEfi5iW
Az7QDNl2qGLpSldKmSYgle6Xoa8UhVJK/+VEiXZ7w20GIWho1vaFCNFPg0bU60jx
lhwejXmpLcuAv3f/jX5BWLKa2sZw2yy9Tg77WnqW1JfFmSnVf5KLI0HryuDIg0Nw
XRhO79nXTrCgj+a4lL5r
=Ya5E
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v3.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Two fixes for the pin control subsystem, both relating to the error
path in probe()
I'm a bit snowed under by mail but these have boiled in linux-next and
should propagate to you"
* tag 'pinctrl-v3.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: berlin: fix an error code in berlin_pinctrl_probe()
pinctrl: sunxi: Fix potential null pointer dereference
The recently merged change (in v3.14-rc6) to ACPI resource detection
(below) causes all zero length ACPI resources to be elided from the
table:
commit b355cee88e
Author: Zhang Rui <rui.zhang@intel.com>
Date: Thu Feb 27 11:37:15 2014 +0800
ACPI / resources: ignore invalid ACPI device resources
This change has caused a regression in (at least) serial port detection
for a number of machines (see LP#1313981 [1]). These seem to represent
their IO regions (presumably incorrectly) as a zero length region.
Reverting the above commit restores these serial devices.
Only elide zero length resources which lie at address 0.
Fixes: b355cee88e (ACPI / resources: ignore invalid ACPI device resources)
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Introduced by commit 561f0ed498 (nfsd4: allow large readdirs).
Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
The revision checking in l2c310_enable() was not correct; we were
masking the part number rather than the revision number. Fix this
to use the correct macro.
Fixes: 4374d64933 ("ARM: l2c: add automatic enable of early BRESP")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Writes into input registers doesn't make sense, even more so since
the writes actually ended up writing into the maximum limit registers.
Drop it.
Cc: stable@vger.kernel.org
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
It is customary to clamp limits instead of bailing out with an error
if a configured limit is out of the range supported by the driver.
This simplifies limit configuration, since the user will not typically
know chip and/or driver specific limits.
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When hot-adding and onlining CPU, kernel panic occurs, showing following
call trace.
BUG: unable to handle kernel paging request at 0000000000001d08
IP: [<ffffffff8114acfd>] __alloc_pages_nodemask+0x9d/0xb10
PGD 0
Oops: 0000 [#1] SMP
...
Call Trace:
[<ffffffff812b8745>] ? cpumask_next_and+0x35/0x50
[<ffffffff810a3283>] ? find_busiest_group+0x113/0x8f0
[<ffffffff81193bc9>] ? deactivate_slab+0x349/0x3c0
[<ffffffff811926f1>] new_slab+0x91/0x300
[<ffffffff815de95a>] __slab_alloc+0x2bb/0x482
[<ffffffff8105bc1c>] ? copy_process.part.25+0xfc/0x14c0
[<ffffffff810a3c78>] ? load_balance+0x218/0x890
[<ffffffff8101a679>] ? sched_clock+0x9/0x10
[<ffffffff81105ba9>] ? trace_clock_local+0x9/0x10
[<ffffffff81193d1c>] kmem_cache_alloc_node+0x8c/0x200
[<ffffffff8105bc1c>] copy_process.part.25+0xfc/0x14c0
[<ffffffff81114d0d>] ? trace_buffer_unlock_commit+0x4d/0x60
[<ffffffff81085a80>] ? kthread_create_on_node+0x140/0x140
[<ffffffff8105d0ec>] do_fork+0xbc/0x360
[<ffffffff8105d3b6>] kernel_thread+0x26/0x30
[<ffffffff81086652>] kthreadd+0x2c2/0x300
[<ffffffff81086390>] ? kthread_create_on_cpu+0x60/0x60
[<ffffffff815f20ec>] ret_from_fork+0x7c/0xb0
[<ffffffff81086390>] ? kthread_create_on_cpu+0x60/0x60
In my investigation, I found the root cause is wq_numa_possible_cpumask.
All entries of wq_numa_possible_cpumask is allocated by
alloc_cpumask_var_node(). And these entries are used without initializing.
So these entries have wrong value.
When hot-adding and onlining CPU, wq_update_unbound_numa() is called.
wq_update_unbound_numa() calls alloc_unbound_pwq(). And alloc_unbound_pwq()
calls get_unbound_pool(). In get_unbound_pool(), worker_pool->node is set
as follow:
3592 /* if cpumask is contained inside a NUMA node, we belong to that node */
3593 if (wq_numa_enabled) {
3594 for_each_node(node) {
3595 if (cpumask_subset(pool->attrs->cpumask,
3596 wq_numa_possible_cpumask[node])) {
3597 pool->node = node;
3598 break;
3599 }
3600 }
3601 }
But wq_numa_possible_cpumask[node] does not have correct cpumask. So, wrong
node is selected. As a result, kernel panic occurs.
By this patch, all entries of wq_numa_possible_cpumask are allocated by
zalloc_cpumask_var_node to initialize them. And the panic disappeared.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Fixes: bce903809a ("workqueue: add wq_numa_tbl_len and wq_numa_possible_cpumask[]")
