This patch add ios->drv_type for mmc_ios_show to show the
card's driver type.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use of_property_read_u32 instead of of_get_property with return value
checks and endianness conversion.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Drivers needs to export the OF id table and this be built into
the module or udev won't have the necessary information to autoload
the driver module when the device is registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The goto is correct and the unreachable "return -EINVAL" should be
removed.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sdhci_init() will clear all irqs and set the needed irqs. So
logically sdhci_init() should be called before request irq.
If not, some irqs may be triggled and handled wrongly. Take
the following into consideration, after request irq, if
SDIO card interrupt enabled, a sd card in the sd slot will
trigger a mass of interrupt(SDHCI_INT_CARD_INT), because at
this time, the vmmc-regulator still not restore, no voltage
supply for the sd card, so the pin of data0~data3 change and
keep low, interrupt(SDHCI_INT_CARD_INT) will rise up ceaselessly.
Due to we already reguest irq, system will be busy in handling
this endless irq, can't response to other event.
So we should call sdhci_init() before request irq in sd resume.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The driver prints if the data width is 8-bit but it's using a
binary OR instead of a binary AND so it will always report as
"is_8bit=Y" regardless of the flags in host->mmc->caps.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The gpiod_get() function expands to gpiod_get_index() with index 0
so it's better to use it since is easier to read and more concise.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
As there are no users of the __mmc_switch() API, except for the mmc core
itself, let's convert it from an exported function into an internal.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
They aren't needed and are just creating null statements so remove it.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It's not needed an is just creating a null statement, so remove it.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
As mmc_claim_host() invokes pm_runtime_get_sync() for the mmc host device,
it's important that the host is kept claimed for *all* accesses to it via
the host_ops callbacks.
In some code paths for SDIO, particularly related to the PM support,
mmc_power_off|up() is invoked without keeping the host claimed. Let's fix
these.
Moreover, mmc_start|stop_host() also invokes mmc_power_off|up() without
claiming the host, let's fix these as well.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Add an entry to the sdhci_acpi_uids list to detect the SD card
reader on the Asus X205Ta laptop.
dstd table:
Device (SDHC)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "PNP0FFF") // _HID: Hardware ID
Name (_CID, "PNP0D40" /* SDA Standard Compliant SD Host Controller */)
Name (_DDN, "Intel(R) SD Card Controller - 80860F16") // _DDN: DOS Dev
Name (_UID, 0x03) // _UID: Unique ID
Name (RDEP, Package (0x02)
Signed-off-by: Michele Curti <michele.curti@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.
The of_node_put is duplicated in front of each error return, because the
function contains a later error return that is beyond the end of the
for_each_child_of_node and thus doesn't need of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
// <smpl>
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
(
return child;
|
+ of_node_put(child);
? return ...;
)
...
}
@@
expression root,e;
local idexpression child;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
// </smpl>
Additionally, concatenated a string in an affected line to avoid introducing
a checkpatch warning.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 6894258eda broke drivers that pass NULL as the device pointer
to dma_alloc. The reason is that arch_dma_alloc_attrs() now calls
dma_alloc_coherent_gfp_flags() which in turn calls
dma_alloc_coherent_mask(), where the device pointer is dereferenced
unconditionally.
Fix things by moving the ISA DMA fallback device assignment before the
call to dma_alloc_coherent_gfp_flags().
Fixes: 6894258eda ("dma-mapping: consolidate dma_{alloc,free}_{attrs,coherent}")
Reported-and-tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Christoph Hellwig <hch@lst.de>
Link: http://lkml.kernel.org/r/1445807503-8920-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Claudiu Manoil says:
====================
gianfar: Misc. fixes and updates
Various fixes for some older issues, including having a
MAINTAINERS entry for this driver.
I'd recommend applying them on top of net, thanks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The Rx BSY error interrupt indicates that a frame was
received and discarded due to lack of buffers, so it's
a rx ring overflow condition and has nothing to do with
with bad rx packets. Use the right counter.
BSY conditions happen when the SoC is under performance
stress. Doing *more* work in stress situations by trying
to schedule NAPI is not a good idea as the stressed system
becomes still more stressed. The Rx interrupt is already
at work making sure the NAPI is scheduled.
So calling gfar_receive() here does not help. This issue
was present since day 1.
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Under one unusual circumstance it's possible to wrongly set
FILREN without enabling PRSDEP as well in the RCTRL register,
against the hardware specifications. With the default config
this does not happen because the default Rx offloads (Rx csum
and Rx VLAN) properly enable PRSDEP. But if anyone disables
all these offloads (via ethtool), we get a wrong configuration
were the Rx flow classification and hashing, and other Filer
based features (e.g. wake-on-filer interrupt) won't work.
This patch fixes the issue.
Also, account for Rx FCB insertion which happens every time
PRSDEP is set.
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
RQFCR_AND is duplicated.
Add missing space as well.
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David Daney says:
====================
net: thunderx: Support pass-2 revision hardware.
With the availability of a new revision of the ThunderX NIC hardware a
few changes to the driver are required. With these, the driver works
on all currently available hardware revisions.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support for ThunderX pass2 CPI and MPI configuration changes.
MPI_ALG is not enabled i.e MCAM parsing is disabled.
Signed-off-by: Thanneeru Srinivasulu <tsrinivasulu@caviumnetworks.com>
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The test for pass-1 silicon was incorrect, it should be for all
revisions less than 8. Also the revision is already present in the
pci_dev, so there is no need to read and keep a private copy.
Remove rev_id and code to read it from struct nicpf. Create new
static inline function pass1_silicon() to be used to testing the
silicon version. Use pass1_silicon() for revision checks, this will
be more widely used in follow on patches.
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In some silicon revisions, the soft reset clobbers PCI config space,
so quit doing the reset.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The LIC doesn't deal with the different types of interrupts itself
but needs to forward calls to set the appropriate type to its parent
IRQ controller.
Without this fix all IRQs routed through the LIC will stay at the
initial EDGE type, while most of them should actually be level triggered.
Fixes: 1eec582158 "irqchip: tegra: Add Tegra210 support"
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: <stable@vger.kernel.org> # 4.1
Link: http://lkml.kernel.org/r/1445787552-13062-1-git-send-email-dev@lynxeye.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Commit d17cab4451 ("irqchip: Kill off set_irq_flags usage") changed
the code of armada_370_xp_mpic_irq_map() from using set_irq_flags() to
irq_set_probe().
While the commit log seems to imply that there are no functional
changes, there are indeed functional changes introduced by this
commit: the IRQ_NOAUTOEN flag is no longer cleared. This functional
change causes a regression on Armada XP, which no longer works
properly after suspend/resume because per-CPU interrupts remain
disabled.
Due to how the hardware registers work, the irq-armada-370-xp cannot
simply save/restore a bunch of registers at suspend/resume to make
sure that the interrupts remain in the same state after
resuming. Therefore, it relies on the kernel to say whether the
interrupt is disabled or not, using the irqd_irq_disabled()
function. This was all working fine while the IRQ_NOAUTOEN flag was
cleared.
With the change introduced by Rob Herring in d17cab4451, the
IRQ_NOAUTOEN flag is now set for all interrupts. irqd_irq_disabled()
returns false for per-CPU interrupts, and therefore our per-CPU
interrupts are no longer re-enabled after resume.
This commit works around this problem by clearing again the
IRQ_NOAUTOEN flags, so that we are back to the situation we had before
commit d17cab4451. This work around is proposed as a minimal fix
for the problem, while a better long-term solution is being worked on.
Fixes: d17cab4451 "irqchip: Kill off set_irq_flags usage"
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1445435295-19956-1-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
When CONFIG_DEBUG_VIRTUAL is enabled, all accesses to __pa(address) are
monitored to see whether address falls in direct mapping or kernel text
mapping (see Documentation/x86/x86_64/mm.txt for details), if it does
not, the kernel panics. During 1:1 mapping of EFI runtime services we access
virtual addresses which are == physical addresses, thus the 1:1 mapping
and these addresses do not fall in either of the above two regions and
hence when passed as arguments to __pa() kernel panics as reported by
Dave Hansen here https://lkml.kernel.org/r/5462999A.7090706@intel.com.
So, before calling __pa() virtual addresses should be validated which
results in skipping call to split_page_count() and that should be fine
because it is used to keep track of everything *but* 1:1 mappings.
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Reported-by: Dave Hansen <dave.hansen@intel.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Glenn P Williamson <glenn.p.williamson@intel.com>
Cc: Ravi Shankar <ravi.v.shankar@intel.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
New features:
- Show ordered command line options when -h is used or when an
unknown options is specified (Arnaldo Carvalho de Melo)
- If options are passed after -h, show just its descriptions, not
all options (Arnaldo Carvalho de Melo)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWKtbAAAoJENZQFvNTUqpAl8sP/0zdmfJFPIYN2R8UuR3R+Eyx
Es7m6a3CjVJl3jaki3tlBaH6inPkb1T9EBSx1GxPVnHt9hzzpf9nWnmiNy75ZTkQ
cHkCYCGTkcAMHIcc3ANsyOMc1RJ151zsCCpolF6Lk4WIbN/FWX1Xf5dIs6zlxxMF
QUxMMOL/bGR/8QR/oYQ4Zko+E1SMsPSTGwWyGS1LO2G4AY9NbGDh3dLK77Lb5rRH
7dblrlmwT0WhUJRI/Ph84efG0CsHgH7e69a8uDEMPoNWOorAIHwvvpIQw2YcXcgb
TYx3Y8YQe3SAuuenl06usLbMB3NBxVkC3mgGPwdeMcqak11wPZESTpdabQML0XSI
IPxbofIHKifYo8YyIPFd/f0VO/qtQZILZsGP4M16opNFwP5WNApj2LRGCuZ3r1p/
Fo1n4wih7GfAO8zA0QGxgNESbPSSmweM6QLulZrAYJEf9RUXhoE5+//YUO9to/GC
3eNPxVsJCeBnJopH4FbSqr1FHKgu5pzneWX6lv0NiPzOSi17V6FVQrIX/e4rOsor
apMX85mX0r51W8mejuOPAEhcaDdFUVqnoSOyb69bdHdFjwQ+vPemFlpYEhIv2DiQ
khqJG6or/dJUjkF1pIRF33Eyr43r3yWu0Plu5pCjSm5vXfNHLVuqJNkMGoZlP3dR
QK1uTL37s2aUKKvTR1i7
=bJOf
-----END PGP SIGNATURE-----
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
Pull perf/core improvements from Arnaldo Carvalho de Melo:
New user-visible features:
- Show ordered command line options when -h is used or when an
unknown option is specified. (Arnaldo Carvalho de Melo)
- If options are passed after -h, show just its descriptions, not
all options. (Arnaldo Carvalho de Melo)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
I'm not sure whether this patch comes in too late, but it would be good to
have it in. It stabilizes command submission in case of command buffer errors.
* 'vmwgfx-fixes-4.3' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Stabilize the command buffer submission code
Two regression fixes and a memory leak fix for amdgpu and radeon.
* 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: don't try to recreate sysfs entries on resume
drm/radeon: don't try to recreate sysfs entries on resume
drm/amdgpu: stop leaking page flip fence
In Linux 3.9 we introduce a new 'far' layout for RAID10 which was
supposed to rotate the replicas differently and so provide better
resilience. In particular it could survive more combinations of 2
drive failures.
Unfortunately. due to a coding error, this some did what was wanted,
sometimes improved less than we hoped, and sometimes - in very
unlikely circumstances - put multiple replicas on the same device so
the redundancy was harmed.
No public user-space tool has created arrays using this layout so it
is very unlikely that zero-redundancy arrays actually exist. Probably
no arrays using any form of the new layout exist. But we cannot be
certain.
So use another bit in the 'layout' number and introduce a bug-fixed
version of the layout.
Also when assembling an array, if it has a zero-redundancy layout,
give a warning.
Reported-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.com>
When a write fails and a bad-block-list is present, we can
update the bad-block-list instead of writing the data. If
this succeeds then it is OK clear the relevant bitmap-bit as
no further 'sync' of the block is needed.
However if writing the bad-block-list fails then we need to
treat the write as failed and particularly must not clear
the bitmap bit. Otherwise the device can be re-added (after
any hardware connection issues are resolved) and because the
relevant bit in the bitmap is clear, that block will not be
resynced. This leads to data corruption.
We already delay the final bio_endio() on the write until
the bad-block-list is written so that when the write
returns: either that data is safe, the bad-block record is
safe, or the fact that the device is faulty is safe.
However we *don't* delay the clearing of the bitmap, so the
bitmap bit can be recorded as cleared before we know if the
bad-block-list was written safely.
So: delay that until the write really is safe.
i.e. move the call to close_write() until just before
calling bio_endio(), and recheck the 'is array degraded'
status before making that call.
This bug goes back to v3.1 when bad-block-lists were
introduced, though it only affects arrays created with
mdadm-3.3 or later as only those have bad-block lists.
Backports will require at least
Commit: 95af587e95 ("md/raid10: ensure device failure recorded before write request returns.")
as well. I'll send that to 'stable' separately.
Note that of the two tests of R10BIO_WriteError that this
patch adds, the first is certain to fail and the second is
certain to succeed. However doing it this way makes the
patch more obviously correct. I will tidy the code up in a
future merge window.
Reported-by: Nate Dailey <nate.dailey@stratus.com>
Fixes: bd870a16c5 ("md/raid10: Handle write errors by updating badblock log.")
Signed-off-by: NeilBrown <neilb@suse.com>
When a write fails and a bad-block-list is present, we can
update the bad-block-list instead of writing the data. If
this succeeds then it is OK clear the relevant bitmap-bit as
no further 'sync' of the block is needed.
However if writing the bad-block-list fails then we need to
treat the write as failed and particularly must not clear
the bitmap bit. Otherwise the device can be re-added (after
any hardware connection issues are resolved) and because the
relevant bit in the bitmap is clear, that block will not be
resynced. This leads to data corruption.
We already delay the final bio_endio() on the write until
the bad-block-list is written so that when the write
returns: either that data is safe, the bad-block record is
safe, or the fact that the device is faulty is safe.
However we *don't* delay the clearing of the bitmap, so the
bitmap bit can be recorded as cleared before we know if the
bad-block-list was written safely.
So: delay that until the write really is safe.
i.e. move the call to close_write() until just before
calling bio_endio(), and recheck the 'is array degraded'
status before making that call.
This bug goes back to v3.1 when bad-block-lists were
introduced, though it only affects arrays created with
mdadm-3.3 or later as only those have bad-block lists.
Backports will require at least
Commit: 55ce74d4bf ("md/raid1: ensure device failure recorded before write request returns.")
as well. I'll send that to 'stable' separately.
Note that of the two tests of R1BIO_WriteError that this
patch adds, the first is certain to fail and the second is
certain to succeed. However doing it this way makes the
patch more obviously correct. I will tidy the code up in a
future merge window.
Reported-and-tested-by: Nate Dailey <nate.dailey@stratus.com>
Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
Fixes: cd5ff9a16f ("md/raid1: Handle write errors by updating badblock log.")
Signed-off-by: NeilBrown <neilb@suse.com>
Some tools have a lot of options, so, providing a way to show help just
for some of them may come handy:
$ perf report -h --tui
Usage: perf report [<options>]
--tui Use the TUI interface
$ perf report -h --tui --showcpuutilization -b -c
Usage: perf report [<options>]
-b, --branch-stack use branch records for per branch histogram filling
-c, --comms <comm[,comm...]>
only consider symbols in these comms
--showcpuutilization
Show sample percentage for different cpu modes
--tui Use the TUI interface
$
Using it with perf bash completion is also handy, just make sure you
source the needed file:
$ . ~/git/linux/tools/perf/perf-completion.sh
Then press tab/tab after -- to see a list of options, put them after -h
and only the options chosen will have its help presented:
$ perf report -h --
--asm-raw --demangle-kernel --group
--kallsyms --pretty --stdio
--branch-history --disassembler-style --gtk
--max-stack --showcpuutilization --symbol-filter
--branch-stack --dsos --header
--mem-mode --show-info --symbols
--call-graph --dump-raw-trace --header-only
--modules --show-nr-samples --symfs
--children --exclude-other --hide-unresolved
--objdump --show-ref-call-graph --threads
--column-widths --fields --ignore-callees
--parent --show-total-period --tid
--comms --field-separator --input
--percentage --socket-filter --tui
--cpu --force --inverted
--percent-limit --sort --verbose
--demangle --full-source-path --itrace
--pid --source --vmlinux
$ perf report -h --socket-filter
Usage: perf report [<options>]
--socket-filter <n>
only show processor socket that match with this filter
Suggested-by: Ingo Molnar <mingo@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Chandler Carruth <chandlerc@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-83mcdd3wj0379jcgea8w0fxa@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When asking for a listing of the options, be it using -h or when an
unknown option is passed, order it by one-letter options, then the ones
having just long names.
Suggested-by: Ingo Molnar <mingo@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Chandler Carruth <chandlerc@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-41qh68t35n4ehrpsuazp1dx8@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Here are 3 xhci driver fixes for reported issues for 4.3-rc7
All have been in linux-next for a while with no problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlYqpLcACgkQMUfUDdst+ylc+QCeKeLrR9st7HlULaq1Nxn5HMUE
nFwAn1rb/bF3IjtsJvY4a6owwIIiqzLD
=Vg7+
-----END PGP SIGNATURE-----
Merge tag 'usb-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are three xhci driver fixes for reported issues for 4.3-rc7
All have been in linux-next for a while with no problems"
* tag 'usb-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
xhci: Add spurious wakeup quirk for LynxPoint-LP controllers
xhci: handle no ping response error properly
xhci: don't finish a TD if we get a short transfer event mid TD
Here are two fixes that resolve reported issues, one with the 8250
driver, and the other with the generic fbcon driver.
Both have been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlYqpWsACgkQMUfUDdst+yn4KgCgh7vFSjdHZa2wgKUz+kIgySRb
CK0An2+SwlC4Z8lQAYGhF2XEBjEcTc2b
=I32U
-----END PGP SIGNATURE-----
Merge tag 'tty-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are two fixes that resolve reported issues, one with the 8250
driver, and the other with the generic fbcon driver.
Both have been in linux-next for a while"
* tag 'tty-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
fbcon: initialize blink interval before calling fb_set_par
Revert "serial: 8250_dma: don't bother DMA with small transfers"
Here are 4 iio driver fixes for 4.3-rc7, fixing some reported issues.
All of these have been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlYqpboACgkQMUfUDdst+ynA4wCdHD56pe0cNCX4yNrcLMlXqVSK
7tUAoIMVLgr3Q8NOWhfGEyKIV5WBDd4U
=bEcI
-----END PGP SIGNATURE-----
Merge tag 'staging-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are four iio driver fixes for 4.3-rc7, fixing some reported
issues. All of these have been in linux-next for a while"
* tag 'staging-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
iio: mxs-lradc: Fix temperature offset
iio: accel: sca3000: memory corruption in sca3000_read_first_n_hw_rb()
iio: st_accel: fix interrupt handling on LIS3LV02
iio: adc: twl4030: Fix ADC[3:6] readings
6 serious fixes:
1) Hold the mutex around the find and corresponding update of our gid
2) The ifa list is rcu protected, copy its contents under rcu to avoid
using a freed structure
3) On error, netdev might be null, so check it before trying to release it
4) On init, if workqueue alloc fails, fail init
5) The new demux patches exposed a bug in mlx5 and ipath drivers, we need
to use the payload P_Key to determine the P_Key the packet arrived on
because the hardware doesn't tell us the truth
6) Due to a couple convoluted error flows, it is possible for the CM to
trigger a use_after_free and a double_free of rb nodes. Add two
checks to prevent that. This code has worked for 10+ years. It is
likely that some of the recent changes have caused this issue to
surface. The current patch will protect us from nasty events for
now while we track down why this is just now showing up.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWJ+zYAAoJELgmozMOVy/dpvIP/iDBxRy0tw8jRdJQNF7EUZ5S
a40aXun/J7Ywl6znvWG/WepDriMDe/9n9qIll8ObZtn7VuNlCZhp/7fx0Bn+fVnR
c4j1cIdhWeja7Wg1xI6K75kXzae8hIwn8aombaFwf4NhUH6qkqGMt72Wp0Y9KeIv
d903VyDwEJgETLAgUPaS1STurEuYcQocESvuer66Qp704Q+EhSbYKf9UgiRT6bOm
36ilI5vxtpPeDpI/YT4ubyD2R7r6XPTGRGs3R6/3W6vRaGLNJ6jq4+Fhthx137G2
NoddGmBdxemt2u0hWwLKcMGb5JNFbOoHuOrJmH9AZO6OyIH8XzILeEiXosdRjX/d
U7OC29fE1Ge5wBNwwm+rJx79HgOVyu1vc5AlcE8vbtImIugJT8OzNIbZoAMcm8CB
RUieyn78PGrkZ1KjCbVpiJ7u6S07LBLq/GqPHTnZ7aen3klP3pm8rAfskM7quEvf
UD3kFP3kFQKZ8PG0Q27XtkKixoBU0vie9YgF2ZLBbEfJpJDKT9HF3lr1nP2AjN2a
23FxUMzFCncE2ewA7tXwbHkCY7x5zn/Og0xdbRKdw/q/EvVu9VLZz/eTASLT+we0
v3YZQdkdSnU0rwULZY+26h1PeHba/aoeoN6x/tmlKLQvaCfhkAsoXDl+MGfY4oLk
1f5iWBgn4kseBXg+N/c9
=fpXl
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
Pull infiniband fixes from Doug Ledford:
"It's late in the game, I know, but these fixes seemed important enough
to warrant a late pull request. They all involve oopses or use after
frees or corruptions.
Six serious fixes:
- Hold the mutex around the find and corresponding update of our gid
- The ifa list is rcu protected, copy its contents under rcu to avoid
using a freed structure
- On error, netdev might be null, so check it before trying to
release it
- On init, if workqueue alloc fails, fail init
- The new demux patches exposed a bug in mlx5 and ipath drivers, we
need to use the payload P_Key to determine the P_Key the packet
arrived on because the hardware doesn't tell us the truth
- Due to a couple convoluted error flows, it is possible for the CM
to trigger a use_after_free and a double_free of rb nodes. Add two
checks to prevent that. This code has worked for 10+ years. It is
likely that some of the recent changes have caused this issue to
surface. The current patch will protect us from nasty events for
now while we track down why this is just now showing up"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
IB/cm: Fix rb-tree duplicate free and use-after-free
IB/cma: Use inner P_Key to determine netdev
IB/ucma: check workqueue allocation before usage
IB/cma: Potential NULL dereference in cma_id_from_event
IB/core: Fix use after free of ifa
IB/core: Fix memory corruption in ib_cache_gid_set_default_gid
properly store flags in DM cache metadata's superblock).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWKneZAAoJEMUj8QotnQNahVIIAKNJ5kkOLTtlZqKeio0b6DmE
utvbNIbcesuBkg4rA67kDBgrTpxFiwaIyC5CBc9dEKzjJY9L+gJ59nXbLWKKu9N1
qBQOlnuYx/fdREDe00HObwZ7Fiw9ofBU71hdrZsHtntHHULEOBqFvnynglZA33Nb
vtBiupwO84uMY9eQdBhZudIb+F3PFF5uBkLfwlhaDmCugUdA9bivz0/P+7x6/Lt5
R25+3D0gF2gXU060An2ZBJaenkSMPYBoWGtpK6TJkQzlNMODc8y9opt0hsEwIJT8
A7TsJRXkjWPPA+DlVlqUd3yWpMKlBaC8o+TB1HvpfGqqCxiZQm7PgxNX8d/yd+E=
=7+lz
-----END PGP SIGNATURE-----
Merge tag 'dm-4.3-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
"Three stable fixes (two in btree code used by DM thinp and one to
properly store flags in DM cache metadata's superblock)"
* tag 'dm-4.3-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm cache: the CLEAN_SHUTDOWN flag was not being set
dm btree: fix leak of bufio-backed block in btree_split_beneath error path
dm btree remove: fix a bug when rebalancing nodes after removal
Pull block layer fixes from Jens Axboe:
"A final set of fixes for 4.3.
It is (again) bigger than I would have liked, but it's all been
through the testing mill and has been carefully reviewed by multiple
parties. Each fix is either a regression fix for this cycle, or is
marked stable. You can scold me at KS. The pull request contains:
- Three simple fixes for NVMe, fixing regressions since 4.3. From
Arnd, Christoph, and Keith.
- A single xen-blkfront fix from Cathy, fixing a NULL dereference if
an error is returned through the staste change callback.
- Fixup for some bad/sloppy code in nbd that got introduced earlier
in this cycle. From Markus Pargmann.
- A blk-mq tagset use-after-free fix from Junichi.
- A backing device lifetime fix from Tejun, fixing a crash.
- And finally, a set of regression/stable fixes for cgroup writeback
from Tejun"
* 'for-linus' of git://git.kernel.dk/linux-block:
writeback: remove broken rbtree_postorder_for_each_entry_safe() usage in cgwb_bdi_destroy()
NVMe: Fix memory leak on retried commands
block: don't release bdi while request_queue has live references
nvme: use an integer value to Linux errno values
blk-mq: fix use-after-free in blk_mq_free_tag_set()
nvme: fix 32-bit build warning
writeback: fix incorrect calculation of available memory for memcg domains
writeback: memcg dirty_throttle_control should be initialized with wb->memcg_completions
writeback: bdi_writeback iteration must not skip dying ones
writeback: fix bdi_writeback iteration in wakeup_dirtytime_writeback()
writeback: laptop_mode_timer_fn() needs rcu_read_lock() around bdi_writeback iteration
nbd: Add locking for tasks
xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)
Pull Ceph fixes from Sage Weil:
"Two fixes.
One is a stopgap to prevent a stack blowout when users have a deep
chain of image clones. (We'll rewrite this code to be non-recursive
for the next window, but in the meantime this is a simple fix that
avoids a crash.)
The second fixes a refcount underflow"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
rbd: prevent kernel stack blow up on rbd map
rbd: don't leak parent_spec in rbd_dev_probe_parent()
