Few network drivers really supports frag_list : virtual drivers.
Some drivers wrongly advertise NETIF_F_FRAGLIST feature.
If skb with a frag_list is given to them, packet on the wire will be
corrupt.
Remove this flag, as core networking stack will make sure to
provide packets that can be sent without corruption.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Cc: Anirudha Sarangi <anirudh@xilinx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The behaviour of blackhole and prohibit routes has been corrected by setting
the input and output pointers of the dst variable appropriately. For
blackhole routes, they are set to dst_discard and to ip6_pkt_discard and
ip6_pkt_discard_out respectively for prohibit routes.
ipv6: ip6_pkt_prohibit(_out) should not depend on
CONFIG_IPV6_MULTIPLE_TABLES
We need ip6_pkt_prohibit(_out) available without
CONFIG_IPV6_MULTIPLE_TABLES
Signed-off-by: Kamala R <kamala@aristanetworks.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
On tx submit the driver always dma_map_single() FEC_ENET_TX_FRSIZE (=2048)
bytes. This works because we don't overwrite any memory after the data buffer,
we remove it from cache if it was there. So we hurt performace in case the
mapping of a smaller area makes a difference.
There is also a bug: If the data area starts shortly before the end of
RAM say 0xc7fffa10 and the RAM ends at 0xc8000000 then we have enough
space to fit the data area (according to skb->len) but we would map beyond
end of ram if we are using 2048. In v2.6.31 (against which kernel this patch
made) there is the following check in dma_cache_maint():
|BUG_ON(!virt_addr_valid(start) || !virt_addr_valid(start + size - 1));
Since the area starting at 0xc8000000 is no longer virt_addr_valid() we
BUG() during dma_map_single(). The BUG() statement was removed in v3.5-rc1 as
per 2dc6a016 ("ARM: dma-mapping: use asm-generic/dma-mapping-common.h").
This patch was tested on v2.6.31 and then forward-ported and compile
tested only against the net tree. I think it is still worth fixing
mainline even after the BUG() statement is gone.
Tested-by: Fugang Duan <B38611@freescale.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Fugang Duan <B38611@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When only one port of the two port is pinned out, then dt probe is failing
because second port phy is not found. fixing this by checking the number of
slaves and breaking the loop.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add new supporting declarations to option.c, to support Huawei new
devices with new bInterfaceProtocol value.
Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:
tty_release: ttyUSB1: read/write wait queue active!
It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add
it there - it's likely used by the card reader.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Also rename the function to better reflect what it is doing.
agd5f: fix argument size warning
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Simplify the code and fix race condition seen because
attribute files were created after hwmon device registration.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Copy-paste typo. Value should be 0-2, not 0-1.
Noticed-by: Sylvain BERTRAND <sylware@legeek.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Hi Greg,
Here's one bug fix for 3.13.
usb-net added support for bulk scatter-gather in 3.12, and it triggered a
bug in the xHCI driver. This bug causes xHCI hosts to send an unexpected
short transfer, which will cause the USB ethernet device to stop sending
packets.
The patch is marked for the 3.12 stable kernel. It's a long standing bug,
but the usb-net drivers are the first to trigger it. The only other
driver that does bulk scatter-gather (usb-storage) will not trigger this
bug.
I'm not sure what the effect of the no-op TRBs will be on various xHCI
host controllers, so I would only like to be conservative and only queue
it for 3.13 and 3.12 stable.
Please queue this for 3.13.
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSnPB6AAoJEBMGWMLi1Gc54rYP/jfd+LC3M/SFxeMGwkU5oCr5
+2xs9mUJso0izC+KFXS39pLvqdFiVQ+Jitl0JtIGj6sbjg02jwrPn+cknqKrg1zm
R8gYolnNjEGUBKUk1t7epy/wrR5mtms/XCM6VG+K7Dxd4A0NacncHUjlECBqjm5i
P2NhprvdUtJdtr+Hxmy1Z7MH85swKT0YHt4jnUD1QqIKbKiCGmSZ6ZvhMioDs9xL
ivGbQLMh44vuZxDLk9OcFUCtIUqjdavAbZcFejeq6z+Zyul7SLioOk9OtKtA240E
XvczX13vs73bgKGLuA0lEoi26NhynHkok9sdV317XsgYgiFZL1pd9q5sgmwvjyWO
qMOMSgmwpHLV3YDzl9FGpj04h/eHHkYQQ0US08CMRtIadp6sbVOCtrVNdnLLkuAT
A+HNMXFZO+8l5UxJFTms2lETdKNaQmG2qH7ur4m+TIiy54wEdwySHrR8XpyBEZZo
tmFsD+RFhy5YT2Y+OVsxJDwUsxDcxFF8at2BWOYH6yefguSndebC9ReqPiKwynQn
h4cf1308jcQUwU+gwCLxTp6ZTXFiZXPwFfJlk8z5/rXvbI8mNeoUxaPJCTb0cI0Z
J10sm7+P5DEP4KveB0ChviHsb4D2auDqs8JedMjzi4soI/UPIaOKdPuDmwAYBnvA
FOIoeJgkGoIBgmlIxwHI
=kO2u
-----END PGP SIGNATURE-----
Merge tag 'for-usb-linus-2013-12-02' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
Sarah writes:
xhci: Regression fix for 3.13.
Hi Greg,
Here's one bug fix for 3.13.
usb-net added support for bulk scatter-gather in 3.12, and it triggered a
bug in the xHCI driver. This bug causes xHCI hosts to send an unexpected
short transfer, which will cause the USB ethernet device to stop sending
packets.
The patch is marked for the 3.12 stable kernel. It's a long standing bug,
but the usb-net drivers are the first to trigger it. The only other
driver that does bulk scatter-gather (usb-storage) will not trigger this
bug.
I'm not sure what the effect of the no-op TRBs will be on various xHCI
host controllers, so I would only like to be conservative and only queue
it for 3.13 and 3.12 stable.
Please queue this for 3.13.
Sarah Sharp
drivers/built-in.o: In function `gp2ap020a00f_thresh_event_handler':
powercap_sys.c:(.text+0x15f90c): undefined reference to `irq_work_queue'
make[1]: *** [vmlinux] Error 1
make[1]: Target `uImage' not remade because of errors.
make: *** [sub-make] Error 2
make: Target `uImage' not remade because of errors.
You need the IRQ work support, but GP2AP020A00F is not selecting this
symbol.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In the original HID sensor hub firmwares all Named array enums were
to 0-based. But the most recent hub implemented as 1-based,
because of the implementation by one of the major OS vendor.
Using logical minimum for the field as the base of enum. So we add
logical minimum to the selector values before setting those fields.
Some sensor hub FWs already changed logical minimum from 0 to 1
to reflect this and hope every other vendor will follow.
There is no easy way to add a common HID quirk for NAry elements,
even if the standard specifies these field as NAry, the collection
used to describe selectors is still just "logical".
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Exporting logical minimum and maximum of HID fields as part of the
hid sensor attribute info. This can be used for range checking and
to calculate enumeration base for NAry fields of HID sensor hub.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Modify tg3_chip_reset() and tg3_close() to check if the PCI network
adapter device is accessible at all in order to skip poking it or
trying to handle a carrier loss in vain when that's not the case.
Introduce a special PCI helper function pci_device_is_present()
for this purpose.
Of course, this uncovers the lack of the appropriate RTNL locking
in tg3_suspend() and tg3_resume(), so add that locking in there
too.
These changes prevent tg3 from burning a CPU at 100% load level for
solid several seconds after the Thunderbolt link is disconnected from
a Matrox DS1 docking station.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
when dealing with a RA message, if accept_ra_defrtr is false,
the kernel will not add the default route, and then deal with
the following route information options. Unfortunately, those
options maybe contain default route, so let's judge the
accept_ra_defrtr before calling rt6_route_rcv.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull LED subsystem bugfix from Bryan Wu.
* 'leds-fixes-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
leds: pwm: Fix for deferred probe in DT booted mode
Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
can only occur at a boundary between underlying USB frames (512 bytes for
high speed devices).
If this isn't done the USB frames aren't formatted correctly and, for example,
the USB3 ethernet ax88179_178a card will stop sending (while still receiving)
when running a netperf tcp transmit test with (say) and 8k buffer.
This should be a candidate for stable, the ax88179_178a driver defaults to
gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
Notes from Sarah:
Discussion: http://marc.info/?l=linux-usb&m=138384509604981&w=2
This patch fixes a long-standing xHCI driver bug that was revealed by a
change in 3.12 in the usb-net driver. Commit
638c5115a7 "USBNET: support DMA SG" added
support to use bulk endpoint scatter-gather (urb->sg). Only the USB
ethernet drivers trigger this bug, because the mass storage driver sends
sg list entries in page-sized chunks.
This patch only fixes the issue for bulk endpoint scatter-gather. The
problem will still occur for periodic endpoints, because hosts will
interpret no-op transfers as a request to skip a service interval, which
is not what we want.
Luckily, the USB core isn't set up for scatter-gather on isochronous
endpoints, and no USB drivers use scatter-gather for interrupt
endpoints. Document this known limitation so that developers won't try
to use urb->sg for interrupt endpoints until this issue is fixed. The
more comprehensive fix would be to allow link TRBs in the middle of the
endpoint ring and revert this patch, but that fix would touch too much
code to be allowed in for stable.
This patch should be backported to kernels as old as 3.12, that contain
the commit 638c5115a7 "USBNET: support DMA
SG". Without this patch, the USB network device gets wedged, and stops
sending packets. Mark Lord confirms this patch fixes the regression:
http://marc.info/?l=linux-netdev&m=138487107625966&w=2
Signed-off-by: David Laight <david.laight@aculab.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Mark Lord <mlord@pobox.com>
Cc: stable@vger.kernel.org
We need to make sure that the error code from devm_of_pwm_get() is the one
the module returns in case of failure.
Restructure the code to make this possible for DT booted case.
With this patch the driver can ask for deferred probing when the board is
booted with DT.
Fixes for example omap4-sdp board's keyboard backlight led.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
In commit 7314e613d5 ("Fix a few incorrectly checked
[io_]remap_pfn_range() calls") the uio driver started more properly
checking the passed-in user mapping arguments against the size of the
actual uio driver data.
That in turn exposed that some driver authors apparently didn't realize
that mmap can only work on a page granularity, and had tried to use it
with smaller mappings, with the new size check catching that out.
So since it's not just the user mmap() arguments that can be confused,
make the uio mmap code also verify that the uio driver has the memory
allocated at page boundaries in order for mmap to work. If the device
memory isn't properly aligned, we return
[ENODEV]
The fildes argument refers to a file whose type is not supported by mmap().
as per the open group documentation on mmap.
Reported-by: Holger Brunck <holger.brunck@keymile.com>
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/net/ethernet/smsc/smsc911x.c is expecting supplies named
"vdd33a" and "vddvario". Currently the shared DTS file provides
"vmmc" and "vmmc_aux", and the supply lookup will fail:
smsc911x 2c000000.ethernet: Looking up vdd33a-supply from device tree
smsc911x 2c000000.ethernet: Looking up vdd33a-supply property in node /ocp/gpmc@6e000000/ethernet@gpmc failed
smsc911x 2c000000.ethernet: Looking up vddvario-supply from device tree
smsc911x 2c000000.ethernet: Looking up vddvario-supply property in node /ocp/gpmc@6e000000/ethernet@gpmc failed
Fix it!
Looks like commmit 6b2978ac40 (ARM: dts: Shared file for omap GPMC
connected smsc911x) made the problem more visible by moving the smc911x
configuration from the omap3-igep0020.dts file to the generic file.
But it seems we've had this problem since commit d72b441501
(ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support).
Tested on OMAP3 Overo platform.
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
[tony@atomide.com: updated comments for the commits causing the problem]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit 'cd8abed' "ARM: OMAP2+: Powerdomain: Remove the need to
always have a voltdm associated to a pwrdm" leads to the following
Smatch complaint:
arch/arm/mach-omap2/powerdomain.c:131 _pwrdm_register()
error: we previously assumed 'arch_pwrdm' could be null (see line 105)
So, fix the unchecked dereference of arch_pwrdm.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This adds typical McBSP2-TWL4030 audio description to the legacy
Beagle Board.
Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Mux mode for wlan/sdmmc5 should be MODE0 in pinmux_wl12xx_pins and
Enable Pull up on sdmmc5_clk to detect SDIO card.
This fixes WLAN on omap4-sdp that got broken in v3.10 when we
moved omap4 to boot using device tree only as I did not have
the WL12XX card in my omap4 SDP to test with. The commit that
attempted to make WL12XX working on omap4 SDP was 775d2418f3
(ARM: dts: Fix muxing and regulator for wl12xx on the SDIO
bus for blaze).
Signed-off-by: Balaji T K <balajitk@ti.com>
[tony@atomide.com: updated comments for the regression]
Signed-off-by: Tony Lindgren <tony@atomide.com>
pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core
and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core.
Fix the following error message:
pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_wl12xx_pins 56x
SDIO card is not detected after moving pin mux to omap4_pmx_core since
sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO card.
This fixes a regression where WLAN did not work after a warm reset
or after one up/down cycle that happened when we move omap4 to boot
using device tree only. For reference, the kernel bug is described at:
https://bugzilla.kernel.org/show_bug.cgi?id=63821
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Balaji T K <balajitk@ti.com>
[tony@atomide.com: update comments to describe the regression]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Bug report from: wenxiong@linux.vnet.ibm.com
The issue is happened in dual controller configuration. We got the
sysfs warnings when rmmod the ipr module.
enclosure_unregister() in drivers/msic/enclosure.c, call device_unregister()
for each componment deivce, device_unregister() ->device_del()->kobject_del()
->sysfs_remove_dir(). In sysfs_remove_dir(), set kobj->sd = NULL.
For each componment device,
enclosure_component_release()->enclosure_remove_links()->sysfs_remove_link()
in which checking kobj->sd again, it has been set as NULL when doing
device_unregister. So we saw all these sysfs WARNING.
Tested-by: wenxiong@linux.vnet.ibm.com
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
When multiple vectors are used, the vector variable is over written,
resulting in unhandled operation for those vectors.
This fix prevents the problem by maitaining HBA instance and
vector values for each irq.
[jejb: checkpatch fixes]
Signed-off-by: Nikith.Ganigarakoppal@pmcs.com
Signed-off-by: Anandkumar.Santhanam@pmcs.com
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Setting the phy state for hard reset response.
After sending hard reset for a device ,phy down event sets
the phy state to zero but for phy up event it will not set
the phy state again.This will cause problem to successive
hard resets.
Signed-off-by: Nikith.Ganigarakoppal@pmcs.com
Signed-off-by: Anandkumar.Santhanam@pmcs.com
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
In case of direct attached SATA device delay is not enough.
It will give crash for set device state command response and
wait_for_completion is the best solution for this.
Signed-off-by: Nikith.Ganigarakoppal@pmcs.com
Signed-off-by: Anandkumar.Santhanam@pmcs.com
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Pull irq fixes from Thomas Gleixner:
- Correction of fuzzy and fragile IRQ_RETVAL macro
- IRQ related resume fix affecting only XEN
- ARM/GIC fix for chained GIC controllers
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip: Gic: fix boot for chained gics
irq: Enable all irqs unconditionally in irq_resume
genirq: Correct fuzzy and fragile IRQ_RETVAL() definition
Pull scheduler fixes from Ingo Molnar:
"Various smaller fixlets, all over the place"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/doc: Fix generation of device-drivers
sched: Expose preempt_schedule_irq()
sched: Fix a trivial typo in comments
sched: Remove unused variable in 'struct sched_domain'
sched: Avoid NULL dereference on sd_busy
sched: Check sched_domain before computing group power
MAINTAINERS: Update file patterns in the lockdep and scheduler entries
Pull perf fixes from Ingo Molnar:
"Misc kernel and tooling fixes"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tools lib traceevent: Fix conversion of pointer to integer of different size
perf/trace: Properly use u64 to hold event_id
perf: Remove fragile swevent hlist optimization
ftrace, perf: Avoid infinite event generation loop
tools lib traceevent: Fix use of multiple options in processing field
perf header: Fix possible memory leaks in process_group_desc()
perf header: Fix bogus group name
perf tools: Tag thread comm as overriden
- Fix lazy flushing in case m2p override fails.
- Fix module compile issues with ARM/Xen
- Add missing call to DMA map page for Xen SWIOTLB for ARM.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQEcBAABAgAGBQJSnJuAAAoJEFjIrFwIi8fJj7sIAJQgSEMWJcEOBJ3lujfbhhKr
9GYfyNILfBjaOcH3LkA354U0JB3y4vON/xz6ONzMO4X7Jj6oUzACeEluq2iexlji
VDxqtnDJGS/82TcIN5xOVKRZbIqZ0xdRjK2f4h7AU9lIoIk+SJEJIycG1RGqqrmr
0nv39lUMjQhXNDhUjyt7e6JQj5GHrP0hzp5ngEQGcquPKbHXUInlwkB/kCH3zwju
2kEYQyKSWFoZCVtIBDeHplcZw9r/zWyOHBxjWOVoI/KZk8k+6d2breC3hv0lrhvU
qkJwzJcKZGlFdiCVHLbo3sTHf0NvvfF+qBCv7JbsymYaQc5SkrATmQ/DAUOssg0=
=emSu
-----END PGP SIGNATURE-----
Merge tag 'stable/for-linus-3.13-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull Xen bug-fixes from Konrad Rzeszutek Wilk:
"Fixes to patches that went in this merge window along with a latent
bug:
- Fix lazy flushing in case m2p override fails.
- Fix module compile issues with ARM/Xen
- Add missing call to DMA map page for Xen SWIOTLB for ARM"
* tag 'stable/for-linus-3.13-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/gnttab: leave lazy MMU mode in the case of a m2p override failure
xen/arm: p2m_init and p2m_lock should be static
arm/xen: Export phys_to_mach to fix Xen module link errors
swiotlb-xen: add missing xen_dma_map_page call
Building brcmfmac for sparc64 gave the following warning:
CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.o
bcmsdh_sdmmc.c: In function 'brcmf_sdioh_request_byte':
bcmsdh_sdmmc.c:89:6: warning: 'err_ret' may be used uninitialized
in this function [-Wuninitialized]
Inspecting the code it indeed had a path of execution in
which the return value was used uninitialized. This patch
fixes that code path.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Franky Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If kmalloc fails wcn36xx_smd_rsp_process will attempt to dereference
a NULL pointer. There might be a better error recovery then just
printing an error, but printing an error message is better then the
current behaviour.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Code in ath9k_hw_set_clockrate function indicates that ah->curchan
(and thus chan local variable) may be NULL. If that is indeed the
case, IS_CHAN_HT40(chan) check has to be performed only in branch
where chan is not NULL. Moving the code under already existing
if condition fixes this issue.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The EEPROM parameter to determine whether the bias
strength values for XLNA have to be applied is part
of the miscConfiguration field and not featureEnable.
Cc: stable@vger.kernel.org
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bit 5 in the miscConfiguration field of the base EEPROM
header denotes whether QuickDrop is enabled or not. Fix
the incorrect usage of BIT(1) and also make sure that
this is done only for the required chips.
Cc: stable@vger.kernel.org
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A smattering of driver specific fixes here, including a bunch for a
long standing common pattern in the error handling paths, and a fix for
an embarrassing thinko in the new devm master registration code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAABAgAGBQJSnIjfAAoJELSic+t+oim9PtEP/2++PEgqY6yb8udNYarfgsJ8
Zi2WgwFehz0DyfR4/CIOzhpFcCKZ0e58vvD/m2Y1psjrT5aXk9ynrT5Twax4K2a9
jQejFCRJFxPhLUbBCxeJ3OB48ka41wQTJPecU4pVZt6yIPbAqlkEDWiOxioB2I2j
b4J/C1JJwf4TwOIAWEJ/9tNrsdYwqd8jaW2FZPKY5J+G7G6U226wXozoDfCkXat3
GAnSvJrkw5jaYsRM34NJquYeXDBxHA+RIByqKP3x+mCvQM8o2AA8/Sbzg7tn14U+
seZVasQ6pTQuBLI1xm+OfQc1+7jq3fJYIr/6CaOsAvlvUA41MS/tYAr/N5oKC4OK
98EgH7pf1RgEKHCy4hLtQekiUSJOhZcdpnBpz4UZvvD9ho5eCFszmH6cKNSG7v1s
lESZra3VYQ7ovAy/bJJq4tzDEnliXUCdGYlOR6w2sTvUwrBe/lqDRN2qtUk7fZjj
ON7ETme+8ZX4/n46U2jvDfzwRNMP/5hyjkA2T6xEQ8+MP3gWgvbfDDseZbt+gga3
OvDZpB57DjYw8/htTSR2LK3uikcK0IefLdXb4VpO7N3pPfoYmv4KWhEChh3CNa6p
hIaMSPlO56Mc5CrdhSfHUHXgTQPOZLJpgAMKT8YeQOIiQFzna5/LHFYGu6thVYXG
MjrDqbXo4Z1KAKmFQFZN
=DNnX
-----END PGP SIGNATURE-----
Merge tag 'spi-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A smattering of driver specific fixes here, including a bunch for a
long standing common pattern in the error handling paths, and a fix
for an embarrassing thinko in the new devm master registration code"
* tag 'spi-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi/pxa2xx: Restore private register bits.
spi/qspi: Fix qspi remove path.
spi/qspi: cleanup pm_runtime error check.
spi/qspi: set correct platform drvdata in ti_qspi_probe()
spi/pxa2xx: add new ACPI IDs
spi: core: invert success test in devm_spi_register_master
spi: spi-mxs: fix reference leak to master in mxs_spi_remove()
spi: bcm63xx: fix reference leak to master in bcm63xx_spi_remove()
spi: txx9: fix reference leak to master in txx9spi_remove()
spi: mpc512x: fix reference leak to master in mpc512x_psc_spi_do_remove()
spi: rspi: use platform drvdata correctly in rspi_remove()
spi: bcm2835: fix reference leak to master in bcm2835_spi_remove()
Pull networking updates from David Miller:
"Here is a pile of bug fixes that accumulated while I was in Europe"
1) In fixing kernel leaks to userspace during copying of socket
addresses, we broke a case that used to work, namely the user
providing a buffer larger than the in-kernel generic socket address
structure. This broke Ruby amongst other things. Fix from Dan
Carpenter.
2) Fix regression added by byte queue limit support in 8139cp driver,
from Yang Yingliang.
3) The addition of MSG_SENDPAGE_NOTLAST buggered up a few sendpage
implementations, they should just treat it the same as MSG_MORE.
Fix from Richard Weinberger and Shawn Landden.
4) Handle icmpv4 errors received on ipv6 SIT tunnels correctly, from
Oussama Ghorbel. In particular we should send an ICMPv6 unreachable
in such situations.
5) Fix some regressions in the recent genetlink fixes, in particular
get the pmcraid driver to use the new safer interfaces correctly.
From Johannes Berg.
6) macvtap was converted to use a per-cpu set of statistics, but some
code was still bumping tx_dropped elsewhere. From Jason Wang.
7) Fix build failure of xen-netback due to missing include on some
architectures, from Andy Whitecroft.
8) macvtap double counts received packets in statistics, fix from Vlad
Yasevich.
9) Fix various cases of using *_STATS_BH() when *_STATS() is more
appropriate. From Eric Dumazet and Hannes Frederic Sowa.
10) Pktgen ipsec mode doesn't update the ipv4 header length and checksum
properly after encapsulation. Fix from Fan Du.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (61 commits)
net/mlx4_en: Remove selftest TX queues empty condition
{pktgen, xfrm} Update IPv4 header total len and checksum after tranformation
virtio_net: make all RX paths handle erors consistently
virtio_net: fix error handling for mergeable buffers
virtio_net: Fixed a trivial typo (fitler --> filter)
netem: fix gemodel loss generator
netem: fix loss 4 state model
netem: missing break in ge loss generator
net/hsr: Support iproute print_opt ('ip -details ...')
net/hsr: Very small fix of comment style.
MAINTAINERS: Added net/hsr/ maintainer
ipv6: fix possible seqlock deadlock in ip6_finish_output2
ixgbe: Make ixgbe_identify_qsfp_module_generic static
ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default
ixgbe: ixgbe_fwd_ring_down needs to be static
e1000: fix possible reset_task running after adapter down
e1000: fix lockdep warning in e1000_reset_task
e1000: prevent oops when adapter is being closed and reset simultaneously
igb: Fixed Wake On LAN support
inet: fix possible seqlock deadlocks
...
Simple fix to set the correct current limit for SD0/1/6.
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Fixes: bc407334e9 (regulator: as3722: add regulator driver for AMS AS3722)
Cc: stable@vger.kernel.org
The pipe code was trying (and failing) to be very careful about freeing
the pipe info only after the last access, with a pattern like:
spin_lock(&inode->i_lock);
if (!--pipe->files) {
inode->i_pipe = NULL;
kill = 1;
}
spin_unlock(&inode->i_lock);
__pipe_unlock(pipe);
if (kill)
free_pipe_info(pipe);
where the final freeing is done last.
HOWEVER. The above is actually broken, because while the freeing is
done at the end, if we have two racing processes releasing the pipe
inode info, the one that *doesn't* free it will decrement the ->files
count, and unlock the inode i_lock, but then still use the
"pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".
This is *very* hard to trigger in practice, since the race window is
very small, and adding debug options seems to just hide it by slowing
things down.
Simon originally reported this way back in July as an Oops in
kmem_cache_allocate due to a single bit corruption (due to the final
"spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
allocation that had re-used the free'd pipe-info), it's taken this long
to figure out.
Since the 'pipe->files' accesses aren't even protected by the pipe lock
(we very much use the inode lock for that), the simple solution is to
just drop the pipe lock early. And since there were two users of this
pattern, create a helper function for it.
Introduced commit ba5bb14733 ("pipe: take allocation and freeing of
pipe_inode_info out of ->i_mutex").
Reported-by: Simon Kirby <sim@hostway.ca>
Reported-by: Ian Applegate <ia@cloudflare.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org # v3.10+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With git commit 79c74ecbeb
"s390/time,vdso: convert to the new update_vsyscall interface"
the new update_vsyscall function already does the sum of xtime
and wall_to_monotonic. The old update_vsyscall function only
copied the wall_to_monotonic offset. The vdso code needs to be
modified to take this into consideration.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
It seems that AD1986A cannot manage the dynamic pin on/off for
auto-muting, but rather gets confused. Since each output has own amp,
let's use it instead.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971
Cc: <stable@vger.kernel.org> [v3.11+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ad_vmaster_eapd_hook() needs to handle the inverted EAPD case
properly, too. Otherwise the output gets broken on Lenovo N100 with
AD1986A codec.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971
Signed-off-by: Takashi Iwai <tiwai@suse.de>
