summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-07-08RDMA/cxgb4: Clean up connection on ARP errorHariprasad S
Based on origninal work by Steve Wise <swise@opengridcomputing.com> Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
2014-07-08RDMA/cxgb4: Fix skb_leak in reject_cr()Hariprasad S
Based on origninal work by Steve Wise <swise@opengridcomputing.com> Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Roland Dreier <roland@purestorage.com>
2014-07-08isdn: hisax: l3ni1.c: Fix for possible null pointer dereferenceRickard Strandqvist
There is otherwise a risk of a possible null pointer dereference. Was largely found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
2014-07-08tipc: fix bug in multicast/broadcast message reassemblyJon Paul Maloy
Since commit 37e22164a8a3c39bdad45aa463b1e69a1fdf4110 ("tipc: rename and move message reassembly function") reassembly of long broadcast messages has been broken. This is because we test for a non-NULL return value of the *buf parameter as criteria for succesful reassembly. However, this parameter is left defined even after reception of the first fragment, when reassebly is still incomplete. This leads to a kernel crash as soon as a the first fragment of a long broadcast message is received. We fix this with this commit, by implementing a stricter behavior of the function and its return values. This commit should be applied to both net and net-next. Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-08irqchip: gic: Add support for cortex a7 compatible stringMatthias Brugger
Patch 0a68214b "ARM: DT: Add binding for GIC virtualization extentions (VGIC)" added the "arm,cortex-a7-gic" compatible string, but the corresponding IRQCHIP_DECLARE was never added to the gic driver. To let real Cortex-A7 SoCs use it, add the necessary declaration to the device driver. Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lkml.kernel.org/r/1404388732-28890-1-git-send-email-matthias.bgg@gmail.com Fixes: 0a68214b76ca ("ARM: DT: Add binding for GIC virtualization extentions (VGIC)") Cc: <stable@vger.kernel.org> # v3.5+ Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-07-08Merge tag 'iio-fixes-for-3.16c' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: Third round of iio fixes for the 3.16 cycle. * Lots of hid sensors component drivers had a bug due to a local variable whose name suggested it was returned from the read_raw function not infact being returned (ret vs ret_type). Fixed and unused ret removed. * Block a possible race condition in tcs3472 by locking around some dependant i2c messages. * Fix bug in the am335x driver fifo setup that occurs if the final channel enabled takes certain values.
2014-07-08MAINTAINERS: change IEEE 802.15.4 maintainerAlexander Aring
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>
2014-07-08iio: ti_am335x_adc: Fix: Use same step id at FIFOs both endsJan Kardell
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
2014-07-08Merge tag 'hwmon-for-linus' of ↵Linus Torvalds
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
2014-07-08nfs: only show Posix ACLs in listxattr if actually presentChristoph Hellwig
The big ACL switched nfs to use generic_listxattr, which calls all existing ->list handlers. Add a custom .listxattr implementation that only lists the ACLs if they actually are present on the given inode. Signed-off-by: Christoph Hellwig <hch@lst.de> Reported-by: Philippe Troin <phil@fifi.org> Tested-by: Philippe Troin <phil@fifi.org> Fixes: 013cdf1088d7 (nfs: use generic posix ACL infrastructure ...) Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2014-07-08Merge branch 'xen-netfront'David S. Miller
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>
2014-07-08xen-netfront: call netif_carrier_off() only once when disconnectingDavid Vrabel
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>
2014-07-08xen-netfront: don't nest queue locks in xennet_connect()David Vrabel
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>
2014-07-08arm64: implement TASK_SIZE_OFColin Cross
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>
2014-07-08arm64: export __cpu_{clear,copy}_user_page functionsMark Salter
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>
2014-07-08ahci_xgene: fix the dma state machine lockup for the IDENTIFY DEVICE PIO ↵Suman Tripathi
mode command. 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>
2014-07-08libahci: export ahci_qc_issue() and ahci_start_fix_rx()Suman Tripathi
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>
2014-07-08ARM: mvebu: Fix coherency bus notifiers by using separate notifiersEzequiel Garcia
Currently, the coherency fabric support registers two bus notifiers; one for platform, one for pci bus types, with the same notifier block. However, this is illegal and can cause serious issues: the notifier block is also a link in the notifier list and cannot be inserted twice. This commit fixes this by using different notifier blocks (with the same notifier callback) to set the platform and pci bus types notifiers. Fixes: b0063aad5dd8 ("ARM: mvebu: use hardware I/O coherency also for PCI devices") Reported-by: Paolo Pisati <p.pisati@gmail.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Link: https://lkml.kernel.org/r/1404826657-6977-1-git-send-email-ezequiel.garcia@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-07-08ARM: mvebu: Fix the operand list in the inline asm of ↵Gregory CLEMENT
armada_370_xp_pmsu_idle_enter In the inline asm part of the function armada_370_xp_pmsu_idle_enter() the input operand was used. The intent here was to let the compiler choose this register so it could do the optimization it needed. However an input operand is not supposed to be modified by the inline asm code. This can lead to improper generated instructions. In some case generated instruction the compiler made the choice to reuse the same register to store the return value. But in the assembly part this register was modified, so it can lead to return an wrong value. The fix is to use a clobber. Thanks to this the compiler will know that the value of this register will be modified. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1404483736-16938-1-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-07-08ALSA: hda - Add new GPU codec ID 0x10de0070 to snd-hdaAaron Plattner
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>
2014-07-08alarmtimer: Fix bug where relative alarm timers were treated as absoluteJohn Stultz
Sharvil noticed with the posix timer_settime interface, using the CLOCK_REALTIME_ALARM or CLOCK_BOOTTIME_ALARM clockid, if the users tried to specify a relative time timer, it would incorrectly be treated as absolute regardless of the state of the flags argument. This patch corrects this, properly checking the absolute/relative flag, as well as adds further error checking that no invalid flag bits are set. Reported-by: Sharvil Nanavati <sharvil@google.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Sharvil Nanavati <sharvil@google.com> Cc: stable <stable@vger.kernel.org> #3.0+ Link: http://lkml.kernel.org/r/1404767171-6902-1-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-07-08ARM: OMAP2+: Remove non working OMAP HDMI audio initializationJyri Sarha
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>
2014-07-08Merge tag 'for-v3.16-rc/omap-fixes-b' of ↵Tony Lindgren
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/
2014-07-07tcp: fix false undo corner casesYuchung Cheng
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>
2014-07-07net/mlx4_en: Don't configure the HW vxlan parser when vxlan offloading isn't setOr Gerlitz
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>
2014-07-07igmp: fix the problem when mc leave groupdingtianhong
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>
2014-07-07ARM: imx: fix shared gate clockShawn Guo
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: f9f28cdf2167 ("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>
2014-07-07net: Fix NETDEV_CHANGE notifier usage causing spurious arp flushLoic Prylli
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: be9efd365328 ("net: pass changed flags along with NETDEV_CHANGE event") Fixes: 6c8b4e3ff81b ("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>
2014-07-07Merge tag 'samsung-fixes-2' of ↵Olof Johansson
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>
2014-07-07Merge tag 'renesas-maintainers-for-v3.17' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes 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>
2014-07-07net: qmi_wwan: Add ID for Telewell TW-LTE 4G v2Bernd Wachter
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>
2014-07-08drm/nouveau/ram: fix test for gpio presenceBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-07-08drm/nouveau/dp: workaround broken displayBen Skeggs
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>
2014-07-08drm/nouveau/dp: fix required link bandwidth calculationsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-07-08drm/nouveau/kms: restore fbcon after display has been resumedBen Skeggs
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>
2014-07-08drm/nv50-/kms: pass a non-zero value for head to sor dpms methodsBen Skeggs
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>
2014-07-08drm/nouveau/fb: Prevent inlining of ramfuc_regStéphane Marchesin
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>
2014-07-08drm/gk104/ram: bash mpll bit 31 onBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-07-07Revert "net: stmmac: add platform init/exit for Altera's ARM socfpga"David S. Miller
This reverts commit 0acf16768740776feffac506ce93b1c06c059ac6. 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>
2014-07-07powerpc/ucc_geth: deal with a compile warningZhao Qiang
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>
2014-07-07Merge branch 'net_ovs_fixes' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/pshelar/openvswitch 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>
2014-07-07net: Performance fix for process_backlogTom Herbert
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>
2014-07-07ipv4: icmp: Fix pMTU handling for rare caseEdward Allcutt
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 46517008e116 ("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: 46517008e116 ("ipv4: Kill ip_rt_frag_needed().") Signed-off-by: Edward Allcutt <edward.allcutt@openmarket.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-08ARM: dts: Update the parent for Audss clocks in Exynos5420Tushar Behera
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>
2014-07-08ARM: EXYNOS: Update secondary boot addr for secure modeSachin Kamat
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>
2014-07-07ACPI / video: Add Acer TravelMate B113 to native backlight blacklistMartin Kepplinger
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>
2014-07-07ACPI / video: Add Dell Inspiron 5737 to the blacklistEdward Lin
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>
2014-07-07ACPI / i915: ignore firmware requests for backlight changeAaron Lu
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>
2014-07-07ACPI / battery: fix wrong value of capacity_now reported when fully chargedJosef Gajdusek
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>
2014-07-07Merge branch 'for-rc' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux 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
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-05 09:05:52 +0000