| Age | Commit message (Collapse) | Author |
|---|
|
The kernel no longer allows us to pass NULL for the hard handler
without also specifying IRQF_ONESHOT. IRQF_ONESHOT imposes latency
in the exit path that we don't need for MSI interrupts. Long term
we'd like to inject these interrupts from the hard handler when
possible. In the short term, we can create dummy hard handlers
that return us to the previous behavior. Credit to Michael for
original patch.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43328
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
|
|
Signed-off-by: Ilia Katsnelson <k0009000@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
The device should be handled by xpad driver instead of generic HID driver.
Signed-off-by: Yuri Khan <yurivkhan@gmail.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
In rare cases, bnx2x_free_tx_skbs() can unmap the wrong DMA address
when it gets to the last entry of the tx ring. We were not using
the proper macro to skip the last entry when advancing the tx index.
Reported-by: Zongyun Lai <zlai@vmware.com>
Reviewed-by: Jeffrey Huang <huangjw@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Or Gerlitz reported triggering of WARN_ON_ONCE(delta < len); in
skb_try_coalesce()
This warning tracks drivers that incorrectly set skb->truesize
IPoIB indeed allocates a full page to store a fragment, but only
accounts in skb->truesize the used part of the page (frame length)
This patch fixes skb truesize underestimation, and
also fixes a performance issue, because RX skbs have not enough tailroom
to allow IP and TCP stacks to pull their header in skb linear part
without an expensive call to pskb_expand_head()
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Or Gerlitz <ogerlitz@mellanox.com>
Cc: Erez Shitrit <erezsh@mellanox.com>
Cc: Shlomo Pongartz <shlomop@mellanox.com>
Cc: Roland Dreier <roland@purestorage.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In driver reload test there is a memory leak.
The structure vlan_info was not freed when the driver was removed.
It was not released since the nr_vids var is one after last vlan was removed.
The nr_vids is one, since vlan zero is added to the interface when the interface
is being set, but the vlan zero is not deleted at unregister.
Fix - delete vlan zero when we unregister the device.
Signed-off-by: Amir Hanania <amir.hanania@intel.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Included changes:
- fix a bug generated by the wrong interaction between the GW feature and the
Bridge Loop Avoidance
|
|
Fix a boot regression on Mackerel boards with sh_mobile_sdhi
in existing kernels causing:
genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq XXX
caused by 1c6c6952 (genirq: Reject bogus threaded irq requests).
This is backported from Guennadi's patch:
"mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
Reported-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
|
This reverts commit 3d93576e(skip card initialization if
power class selection fails).
Problem has been reported when this is used with eMMC4.41
card with Tegra Platform. Till the issue is root caused,
bus width selection failure should not be treated as fatal.
Reported-by: Marc Dietrich <marvin24@gmx.de>
Signed-Off-by: Venkatraman S <svenkatr@ti.com>
CC: Ulf Hansson <ulf.hansson@stericsson.com>
CC: Subhash Jadavani <subhashj@codeaurora.org>
CC: Saugata Das <saugata.das@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
|
commit 626f9914 added code to initialize gpio_chip.of_node, but if
CONFIG_OF_GPIO is not defined gps-tps65910 fails to build with an
error complaining gpio_chip has no member of_node. I ran into this
while doing a allyesconfig build on linux-next.
Signed-off-by: Gerard Snitselaar <dev@snitselaar.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"Yes, this is a *LATE* GPIO pull request with fixes for v3.5.
Grant moved across the planet and accidentally fell off the grid, so
he asked me to take over the GPIO merges for a while 10 days ago.
Since then I went over the archives and collected this pile of fixes,
and pulled two of them from the TI maintainer Kevin Hilman. Then
waited for them to at least hit linux-next once or twice."
GPIO fixes for v3.5:
- Invalid context restore on bank 0 for OMAP driver in runtime
suspend/resume cycle
- Check for NULL platform data in sta-2x11 driver
- Constrain selection of the V1 MSM GPIO driver to applicable platforms
(Kconfig issue)
- Make sure the correct output value is set in the wm8994 driver
- Export devm_gpio_request_one() so it can be used in modules.
Apparently some in-kernel modules can be configured to use this
leading to breakage.
- Check that the GPIO is valid in the lantiq driver
- Fix the flag bits introduced for v3.5, so they don't overlap
- Fix a device tree intialization bug for imx21-compatible devices
- Carry over the OF node to the TPS65910 GPIO chip struct
* tag 'fixes-for-v3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: tps65910: initialize of_node of gpio_chip
gpio/mxc: make irqs work for fsl,imx21-gpio devices
gpio: fix bits conflict for gpio flags
mips: pci-lantiq: Fix check for valid gpio
gpio: export devm_gpio_request_one
gpiolib: wm8994: Pay attention to the value set when enabling as output
gpio/msm_v1: CONFIG_GPIO_MSM_V1 is only available on three SoCs
gpio-sta2x11: don't use pdata if null
gpio/omap: fix invalid context restore of gpio bank-0
gpio/omap: fix irq loss while in idle with debounce on
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
Pull powerpc fixes from Benjamin Herrenschmidt:
"It looks like my rewrite of our lazy irq scheme is still exposing
"interesting" issues left and right. The previous fixes are now
causing an occasional BUG_ON to trigger (which this patch turns into a
WARN_ON while at it), due to another issue of disconnect of the lazy
irq state vs the processor state in the idle loop on pseries and
cell.
This should fix it properly once for all moving the nasty code to a
common helper function.
There's also couple more fixes for some debug stuff that didn't build
(and helped resolving those problems so it's worth having), along with
a compile fix for newer gcc's."
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
tty/hvc_opal: Fix debug function name
powerpc/numa: Avoid stupid uninitialized warning from gcc
powerpc: Fix build of some debug irq code
powerpc: More fixes for lazy IRQ vs. idle
|
|
This is an old suspend/resume lockup fix:
commit 2780cc4660e1
Author: Len Brown <len.brown@intel.com>
Date: Thu Dec 23 13:43:30 2004 -0500
[ACPI] Fix suspend/resume lockup issue
by leaving Bus Master Arbitration enabled.
The ACPI spec mandates it be disabled only for C3.
http://bugzilla.kernel.org/show_bug.cgi?id=3599
Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The bug snuck back in in commit 2feec47d4c5f (ACPICA: ACPI 5: Support
for new FADT SleepStatus, SleepControl registers, 2012-02-14),
presumably by copy/pasting a copy of the code without that fix for the
legacy case.
On affected machines, after that commit, the machine locks up hard on
resume from suspend. The same fix as seven years ago still works.
Addresses <https://bugzilla.kernel.org/show_bug.cgi?id=43641>.
Reported-bisected-and-tested-by: Octavio Alvarez <alvarezp@alvarezp.com>
Reported-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
This reverts commit 107a84e61cdd3406c842a0e4be7efffd3a05dba6.
Meelis Roos reports a regression since 3.5-rc5 that stops Sun Fire V100
and Sun Netra X1 sparc64 machines from booting, hanging after enabling
serial console. He bisected it to commit 107a84e61cdd.
Rob Herring explains:
"The problem is match combinations of compatible plus name and/or type
fail to match correctly. I have a fix for this, but given how late it
is for 3.5 I think it is best to revert this for now. There could be
other cases that rely on the current although wrong behavior. I will
post an updated version for 3.6."
Bisected-and-reported-by: Meelis Roos <mroos@linux.ee>
Requested-by: Rob Herring <rob.herring@calxeda.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
when the default irq quick handler is used then IRQF_ONESHOT must be set
otherwise the request fails and following error is displayed:
mei 0000:00:16.0: irq 48 for MSI/MSI-X
genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 48
mei 0000:00:16.0: request_threaded_irq failed: irq = 48.
dpm_run_callback(): pci_pm_resume+0x0/0x140 returns -22
PM: Device 0000:00:16.0 failed to resume async: error -22
Reported-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Tested-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Cc: stable <stable@vger.kernel.org> # 3.5
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The helper nfs_fs_mount() will always call nfs4_try_mount with the
mount_info->fill_super argument pointing to nfs_fill_super, which is
NFSv2/v3 only.
Fix is to have nfs4_try_mount replace it with nfs4_fill_super.
The regression was introduced by commit c40f8d1d (NFS: Create a common
fs_mount() function)
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
|
|
Quite a few ASUS computers experience a nasty problem, related to the
EHCI controllers, when going into system suspend. It was observed
that the problem didn't occur if the controllers were not put into the
D3 power state before starting the suspend, and commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers) was created to do this.
It turned out this approach messed up other computers that didn't have
the problem -- it prevented USB wakeup from working. Consequently
commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add
NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it
reverted the earlier commit and added a whitelist of known good board
names.
Now we know the actual cause of the problem. Thanks to AceLan Kao for
tracking it down.
According to him, an engineer at ASUS explained that some of their
BIOSes contain a bug that was added in an attempt to work around a
problem in early versions of Windows. When the computer goes into S3
suspend, the BIOS tries to verify that the EHCI controllers were first
quiesced by the OS. Nothing's wrong with this, but the BIOS does it
by checking that the PCI COMMAND registers contain 0 without checking
the controllers' power state. If the register isn't 0, the BIOS
assumes the controller needs to be quiesced and tries to do so. This
involves making various MMIO accesses to the controller, which don't
work very well if the controller is already in D3. The end result is
a system hang or memory corruption.
Since the value in the PCI COMMAND register doesn't matter once the
controller has been suspended, and since the value will be restored
anyway when the controller is resumed, we can work around the BIOS bug
simply by setting the register to 0 during system suspend. This patch
(as1590) does so and also reverts the second commit mentioned above,
which is now unnecessary.
In theory we could do this for every PCI device. However to avoid
introducing new problems, the patch restricts itself to EHCI host
controllers.
Finally the affected systems can suspend with USB wakeup working
properly.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728
Based-on-patch-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Dâniel Fraga <fragabr@gmail.com>
Tested-by: Javier Marcet <jmarcet@gmail.com>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Cc: stable <stable@vger.kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add support for the 15'' MacBook Pro Retina model (MacBookPro10,1).
Patch originally written by clipcarl (forums.opensuse.org).
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Add support for the 15'' MacBook Pro Retina. The keyboard is
the same as recent models.
The patch needs to be synchronized with the bcm5974 patch for
the trackpad - as usual.
Patch originally written by clipcarl (forums.opensuse.org).
[rydberg@euromail.se: Amended mouse ignore lines]
Signed-off-by: Ryan Bourgeois <bluedragonx@gmail.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
From Tony Lindgren <tony@atomide.com>:
Here is one PM regression fix and a defconfig change to disable
echi-omap because the driver currently causes issues with PM.
This annoys Kevin as it makes it harder for him to validate that
PM is working. The proper fixes for the echi-omap are being
discussed, but looks like it will not be properly working with PM
until in v3.7.
* tag 'omap-fixes-for-v3.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: omap2plus_defconfig: EHCI driver is not stable, disable it
ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
udbg_init_debug_opal() should be udbg_init_debug_opal_raw() as
the caller in arch/powerpc/kernel/udbg.c expects
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
Newer gcc are being a bit blind here (it's pretty obvious we don't
reach the code path using the array if we haven't initialized the
pointer) but none of that is performance critical so let's just
silence it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
There was a typo, checking for CONFIG_TRACE_IRQFLAG instead of
CONFIG_TRACE_IRQFLAGS causing some useful debug code to not be
built
This in turns causes a build error on BookE 64-bit due to incorrect
semicolons at the end of a couple of macros, so let's fix that too
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.4]
|
|
Looks like we still have issues with pSeries and Cell idle code
vs. the lazy irq state. In fact, the reset fixes that went upstream
are exposing the problem more by causing BUG_ON() to trigger (which
this patch turns into a WARN_ON instead).
We need to be careful when using a variant of low power state that
has the side effect of turning interrupts back on, to properly set
all the SW & lazy state to look as if everything is enabled before
we enter the low power state with MSR:EE off as we will return with
MSR:EE on. If not, we have a discrepancy of state which can cause
things to go very wrong later on.
This patch moves the logic into a helper and uses it from the
pseries and cell idle code. The power4/970 idle code already got
things right (in assembly even !) so I'm not touching it. The power7
"bare metal" idle code is subtly different and correct. Remains PA6T
and some hypervisor based Cell platforms which have questionable
code in there, but they are mostly dead platforms so I'll fix them
when I manage to get final answers from the respective maintainers
about how the low power state actually works on them.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.4]
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace into perf/urgent
Pull ftrace ring-buffer fixes from Steve Rostedt.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
commit db83d136d7f753 (gianfar: Fix missing sock reference when
processing TX time stamps) added a potential sk_wmem_alloc imbalance
If the new skb has a different truesize than old one, we can get a
negative sk_wmem_alloc once new skb is orphaned at TX completion.
Now we no longer early orphan skbs in dev_hard_start_xmit(), this
probably can lead to fatal bugs.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Manfred Rudigier <manfred.rudigier@omicron.at>
Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
Cc: Jiajun Wu <b06378@freescale.com>
Cc: Andy Fleming <afleming@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
iterator variable
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. There does not seem to be a meaningful value to
provide to netdev_warn. Replace with pr_warn, since pr_err is used
elsewhere.
This problem was found using Coccinelle (http://coccinelle.lip6.fr/).
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. This seems to be a copy-paste bug from a previous
debugging message, and so the meaningless value is just deleted.
This problem was found using Coccinelle (http://coccinelle.lip6.fr/).
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. The dereferences are just deleted from the
debugging statement.
This problem was found using Coccinelle (http://coccinelle.lip6.fr/).
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
dev->priomap is allocated by extend_netdev_table() called from
update_netdev_tables().
And this is only called if write_priomap() is called.
But if write_priomap() is not called, it seems we can have out of bounds
accesses in cgrp_destroy(), read_priomap() & skb_update_prio()
With help from Gao Feng
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Gao feng <gaofeng@cn.fujitsu.com>
Acked-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The bonding debugfs support has been broken in the presence of network
namespaces since it has been added. The debugfs support does not handle
multiple bonding devices with the same name in different network
namespaces.
I haven't had any bug reports, and I'm not interested in getting any.
Disable the debugfs support when network namespaces are enabled.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
It was recently reported that moving a bonding device between network
namespaces causes warnings from /proc. It turns out after the move we
were trying to add and to remove the /proc/net/bonding entries from the
wrong network namespace.
Move the bonding /proc registration code into the NETDEV_REGISTER and
NETDEV_UNREGISTER events where the proc registration and unregistration
will always happen at the right time.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
For the higher mtu sizes requiring the buffer size greater than 8192,
the buffers are sent or received using multiple dma descriptors/ same
descriptor with option of multi buffer handling.
It was observed during tests that the driver was missing on data
packets during the normal ping operations if the data buffers being used
catered to jumbo frame handling.
The memory barrriers are added in between preparation of dma descriptors
in the jumbo frame handling path to ensure all instructions before
enabling the dma are complete.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
It was observed that during multiple reboots nfs hangs. The status of
receive descriptors shows that all the descriptors were in control of
CPU, and none were assigned to DMA.
Also the DMA status register confirmed that the Rx buffer is
unavailable.
This patch adds the fix for the same by adding the memory barriers to
ascertain that the all instructions before enabling the Rx or Tx DMA are
completed which involves the proper setting of the ownership bit in DMA
descriptors.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"A smallish fix for a lock dependency issue which affects a bunch of
Qualcomm boards that do unusually complicated things with their
regulators, the API is unlikely to be called by any other system."
* tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: Fix recursive mutex lockdep warning
|
|
Don't call v4l2_ctrl_g_ctrl on ctrls which the model cam in question
does not have.
Reported-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[ Taken directly, since Mauro is on vacation ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus
Pull minor virtio-balloon fix from Rusty Russell:
"Theoretical fix, which greatly simplifies upcoming balloon patches
which will go in via some vm tree."
* tag 'virtio-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
virtio-balloon: fix add/get API use
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg
Pull rpmsg fixes from Ohad Ben-Cohen:
"Fixing two (somewhat rare) endpoint-related race issues, both of which
were reported by Fernando Guzman Lugo."
* tag 'rpmsg-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg:
rpmsg: make sure inflight messages don't invoke just-removed callbacks
rpmsg: avoid premature deallocation of endpoints
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc
Pull remoteproc fixes from Ohad Ben-Cohen:
"Two build-related remoteproc fixes for 3.5."
* tag 'remoteproc-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc:
remoteproc: fix missing CONFIG_FW_LOADER configurations
remoteproc/omap: fix randconfig unmet direct dependencies
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock
Pull hwspinlock fix from Ohad Ben-Cohen:
"A single hwspinlock core fix for multiple hwspinlock devices
scenarios, from Shinya Kuribayashi."
* tag 'hwspinlock-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock:
hwspinlock/core: use global ID to register hwspinlocks on multiple devices
|
|
In (the unlikely) case our continuation merge buffer is busy, we unfortunately
can not merge further continuation printk()s into a single record and have to
store them separately, which leads to split-up output of these lines when they
are printed.
Add some flags about newlines and prefix existence to these records and try to
reconstruct the full line again, when the separated records are printed.
Reported-By: Michael Neuling <mikey@neuling.org>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Tested-By: Michael Neuling <mikey@neuling.org>
Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.
This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This is iwlegacy version of:
commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912
Author: Johannes Berg <johannes.berg@intel.com>
Date: Sun Mar 4 08:50:46 2012 -0800
iwlwifi: always monitor for stuck queues
If we only monitor while associated, the following
can happen:
- we're associated, and the queue stuck check
runs, setting the queue "touch" time to X
- we disassociate, stopping the monitoring,
which leaves the time set to X
- almost 2s later, we associate, and enqueue
a frame
- before the frame is transmitted, we monitor
for stuck queues, and find the time set to
X, although it is now later than X + 2000ms,
so we decide that the queue is stuck and
erroneously restart the device
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
On rt2x00_dmastart() we increase index specified by Q_INDEX and on
rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries
between Q_INDEX_DONE and Q_INDEX are those we currently process in the
hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can
submit to the hardware.
According to that fix rt2x00usb_kick_queue(), as we need to submit RX
entries that are not processed by the hardware. It worked before only
for empty queue, otherwise was broken.
Note that for TX queues indexes ordering are ok. We need to kick entries
that have filled skb, but was not submitted to the hardware, i.e.
started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set.
From practical standpoint this fixes RX queue stall, usually reproducible
in AP mode, like for example reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=828824
Reported-and-tested-by: Franco Miceli <fmiceli@plan.ceibal.edu.uy>
Reported-and-tested-by: Tom Horsley <horsley1953@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
> *. CID 709078: Resource leak (RESOURCE_LEAK)
> - drivers/net/wireless/mwifiex/cfg80211.c, line: 935
> Assigning: "bss_cfg" = storage returned from "kzalloc(132UL, 208U)"
> - but was not free
> drivers/net/wireless/mwifiex/cfg80211.c:935
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
If association failed due to internal error (e.g. no
supported rates IE), we call ieee80211_destroy_assoc_data()
with assoc=true, while we actually reject the association.
This results in the BSSID not being zeroed out.
After passing assoc=false, we no longer have to call
sta_info_destroy_addr() explicitly. While on it, move
the "associated" message after the assoc_success check.
Cc: stable@vger.kernel.org [3.4+]
Signed-off-by: Eliad Peller <eliad@wizery.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
llcp_sock_getname can be called without a device attached to the nfc_llcp_sock.
This would lead to the following BUG:
[ 362.341807] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 362.341815] IP: [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
[ 362.341818] PGD 31b35067 PUD 30631067 PMD 0
[ 362.341821] Oops: 0000 [#627] PREEMPT SMP DEBUG_PAGEALLOC
[ 362.341826] CPU 3
[ 362.341827] Pid: 7816, comm: trinity-child55 Tainted: G D W 3.5.0-rc4-next-20120628-sasha-00005-g9f23eb7 #479
[ 362.341831] RIP: 0010:[<ffffffff836258e5>] [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
[ 362.341832] RSP: 0018:ffff8800304fde88 EFLAGS: 00010286
[ 362.341834] RAX: 0000000000000000 RBX: ffff880033cb8000 RCX: 0000000000000001
[ 362.341835] RDX: ffff8800304fdec4 RSI: ffff8800304fdec8 RDI: ffff8800304fdeda
[ 362.341836] RBP: ffff8800304fdea8 R08: 7ebcebcb772b7ffb R09: 5fbfcb9c35bdfd53
[ 362.341838] R10: 4220020c54326244 R11: 0000000000000246 R12: ffff8800304fdec8
[ 362.341839] R13: ffff8800304fdec4 R14: ffff8800304fdec8 R15: 0000000000000044
[ 362.341841] FS: 00007effa376e700(0000) GS:ffff880035a00000(0000) knlGS:0000000000000000
[ 362.341843] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 362.341844] CR2: 0000000000000000 CR3: 0000000030438000 CR4: 00000000000406e0
[ 362.341851] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 362.341856] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 362.341858] Process trinity-child55 (pid: 7816, threadinfo ffff8800304fc000, task ffff880031270000)
[ 362.341858] Stack:
[ 362.341862] ffff8800304fdea8 ffff880035156780 0000000000000000 0000000000001000
[ 362.341865] ffff8800304fdf78 ffffffff83183b40 00000000304fdec8 0000006000000000
[ 362.341868] ffff8800304f0027 ffffffff83729649 ffff8800304fdee8 ffff8800304fdf48
[ 362.341869] Call Trace:
[ 362.341874] [<ffffffff83183b40>] sys_getpeername+0xa0/0x110
[ 362.341877] [<ffffffff83729649>] ? _raw_spin_unlock_irq+0x59/0x80
[ 362.341882] [<ffffffff810f342b>] ? do_setitimer+0x23b/0x290
[ 362.341886] [<ffffffff81985ede>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 362.341889] [<ffffffff8372a539>] system_call_fastpath+0x16/0x1b
[ 362.341921] Code: 84 00 00 00 00 00 b8 b3 ff ff ff 48 85 db 74 54 66 41 c7 04 24 27 00 49 8d 7c 24 12 41 c7 45 00 60 00 00 00 48 8b 83 28 05 00 00 <8b> 00 41 89 44 24 04 0f b6 83 41 05 00 00 41 88 44 24 10 0f b6
[ 362.341924] RIP [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
[ 362.341925] RSP <ffff8800304fde88>
[ 362.341926] CR2: 0000000000000000
[ 362.341928] ---[ end trace 6d450e935ee18bf3 ]---
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
msp has type struct minstrel_ht_sta_priv not struct minstrel_ht_sta.
(This incorporates the fixup originally posted as "mac80211: fix kzalloc
memory corruption introduced in minstrel_ht". -- JWL)
Reported-by: Fengguang Wu <wfg@linux.intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
|
