Set the parent of the exar gpiochip to its platform device, like other
gpiochips are doing it. In order to keep the relationship discoverable
for ACPI systems, set the platform device companion to the PCI device.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Jan Kiszka [Thu, 25 May 2017 06:25:19 +0000 (08:25 +0200)]
gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards
Commtech adapters need the MPIOs for internal purposes, and the
gpio-exar driver already refused to pick them up. But there is actually
no point in even creating the underlying platform device.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kiszka [Sat, 13 May 2017 07:29:04 +0000 (09:29 +0200)]
serial: uapi: Add support for bus termination
The Siemens IOT2040 comes with a RS485 interface that allows to enable
or disable bus termination via software. Add a bit to the flags field of
serial_rs485 that applications can set in order to request this feature
from the hardware. This seems generic enough to add it for everyone.
Existing driver will simply ignore it when set.
gpio: gpio-wcove: Fix GPIO control register offset calculation
According to Whiskey Cove PMIC GPIO controller specification, for GPIO
pins 0-12, GPIO input and output register control address range from,
0x4e44-0x4e50 for GPIO outputs control register
0x4e51-0x4e5d for GPIO input control register
But, currently when calculating the GPIO register offsets in to_reg()
function, all GPIO pins in the same bank uses the same GPIO control
register address. This logic is incorrect. This patch fixes this
issue.
This patch also adds support to selectively skip register modification
for virtual GPIOs.
In case of Whiskey Cove PMIC, ACPI code may use up 94 virtual GPIOs.
These virtual GPIOs are used by the ACPI code as means to access various
non GPIO bits of PMIC. So for these virtual GPIOs, we don't need to
manipulate the physical GPIO pin register. A similar patch has been
merged recently by Hans for Crystal Cove PMIC GPIO driver. You can
find more details about it in Commit 9a752b4c9ab9 ("gpio: crystalcove:
Do not write regular gpio registers for virtual GPIOs")
Xiaoguang Chen [Thu, 1 Jun 2017 23:27:15 +0000 (07:27 +0800)]
gpio: dwapb: fix missing first irq for edgeboth irq type
dwapb_irq_set_type overwrites polarity register value for
IRQ_TYPE_EDGE_BOTH case. If the polarity of one gpio is 0
by default, then it will set falling edge irq trigger.
and the gpio may requires rising edge irq for the first time,
and it will be missed.
Do not overwrite polarity register for IRQ_TYPE_EDGE_BOTH case
can solve this issue.
Signed-off-by: Xiaoguang Chen <xgchenshy@gmail.com> Tested-by: Jisheng Zhang <jszhang@marvell.com>
[Fix some really weird text encoding problem] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Jan Kiszka [Fri, 9 Jun 2017 18:33:13 +0000 (20:33 +0200)]
gpio: exar: Fix reading of directions and values
First, the logic for translating a register bit to the return code of
exar_get_direction and exar_get_value were wrong. And second, there was
a flip regarding the register bank in exar_get_direction.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Jan Kiszka [Fri, 9 Jun 2017 18:33:11 +0000 (20:33 +0200)]
gpio: exar: Allocate resources on behalf of the platform device
Do not allocate resources on behalf of the parent device but on our own.
Otherwise, cleanup does not properly work if gpio-exar is removed but
not the parent device.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Jan Kiszka [Fri, 9 Jun 2017 18:33:10 +0000 (20:33 +0200)]
gpio-exar/8250-exar: Fix passing in of parent PCI device
This fixes reloading of the GPIO driver for the same platform device
instance as created by the exar UART driver: First of all, the driver
sets drvdata to its own value during probing and does not restore the
original value on exit. But this won't help anyway as the core clears
drvdata after the driver left.
Set the platform device parent instead.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We currently shift bits here and there without actually explaining
what we're doing. Add some helper variables with names indicating
their purpose to improve the code readability.
gpio: mockup: refuse to accept an odd number of GPIO ranges
Currently we ignore the last odd range value, since each chip is
described by two values. Be more strict and require the user to
pass an even number of ranges.
gpio: mockup: improve the debugfs input sanitization
We're currently only checking the first character of the input to the
debugfs event files, so a string like '0sdfdsf' is valid and indicates
a falling edge event.
Be more strict and only allow '0', '1', '0\n' & '1\n'.
While we're at it: move the sanitization code before the irq_enabled
check so that we indicate an error on invalid input even if nobody is
waiting for events.
Gregory CLEMENT [Mon, 12 Jun 2017 15:34:59 +0000 (17:34 +0200)]
gpio: mvebu: Add support for the Armada 7K/8K SoCs
The Armada 7K and 8K SoCs use the same gpio controller as most of the
other mvebu SoCs. However, the main difference is that the GPIO
controller is part of a bigger system controller, and a syscon is used to
control the overall system controller. Therefore, the driver needs to be
adjusted to retrieve the regmap of the syscon to access registers, and
account for the fact that registers are located at a certain offset
within the regmap.
This commit add the support of the syscon and introduce a new variant for
this case.
It was based on the preliminary work of Thomas Petazzoni.
Gregory CLEMENT [Fri, 9 Jun 2017 10:09:17 +0000 (12:09 +0200)]
gpio: mvebu: fix regmap_update_bits usage
In some place in the driver regmap_update_bits was misused. Indeed the
last argument is not the value of the bit (or group of bits) itself but
the mask value inside the register.
So when setting the bit N, then the value must be BIT(N) and not 1.
CC: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Tested-by: Chris Packham <Chris.Packham@alliedtelesis.co.nz> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Soren Brinkmann [Thu, 8 Jun 2017 17:32:07 +0000 (10:32 -0700)]
gpio: zynq: Clarify quirk and provide helper function
The one quirk used in the zynq GPIO driver was called FOO which is not
very descriptive. Rename the quirk to IS_ZYNQ as it indicates whether
the HW is a zynq or zynqmp device to allow handling of device-specific
differences of the HW.
Also provide a helper function to test whether the HW is zynq or zynqmp.
Arnd Bergmann [Tue, 30 May 2017 09:21:05 +0000 (11:21 +0200)]
gpiolib: remove unused variable
This was left behind by a cleanup patch:
drivers/gpio/gpiolib.c: In function 'gpiochip_irqchip_init_valid_mask':
drivers/gpio/gpiolib.c:1474:6: error: unused variable 'i' [-Werror=unused-variable]
Fixes: 923a654c186c ("gpiolib: Re-use bitmap_fill() instead of open coded loop") Reported-by: kbuild test robot <fengguang.wu@intel.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Colin King <colin.king@canonical.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio: mockup: be quiet unless something goes wrong
When inserting and removing the module repeatedly (e.g. when running
the libgpiod test-suite) the kernel log gets clobbered with messages
reporting successful creation of dummy gpiochips.
Remove this message and only emit logs when something bad happens.
All internal symbols except for the direction enum follow the same
convention and use the gpio_mockup prefix. Add the prefix to the
DIR_IN and DIR_OUT definitions as well for consistency across the
file.
The PNP ACPI driver parses ACPI interrupt resource but not
GpioInt resource. When the firmware passes GpioInt resource
for IRQ the PNP ACPI driver ignores it and hence the interrupt for
the particular driver will not work.
One such example is 8042 keyboard which uses PNP driver for obtaining
the interrupt resource. On Intel Braswell project GpioInt is used
instead of interrupt resource and the keyboard driver fails to
register interrupt.
Fix the issue by parsing GpioInt resource type.
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[Fixed a parenthesis coding style thing] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Andy Shevchenko [Tue, 23 May 2017 17:03:21 +0000 (20:03 +0300)]
gpio: acpi: Explain how to get GPIO descriptors in ACPI case
Documentation lacks of explanation how we actually use device properties
for GPIO resources.
Add a section to the documentation about that.
Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Andy Shevchenko [Tue, 23 May 2017 17:03:20 +0000 (20:03 +0300)]
gpio: acpi: Synchronize acpi_find_gpio() and acpi_gpio_count()
If we pass connection ID to the both functions and at the same time
acpi_can_fallback_to_crs() returns false we will get different results,
i.e. the number of GPIO resources returned by acpi_gpio_count() might be
not correct.
Fix this by calling acpi_can_fallback_to_crs() in acpi_gpio_count()
before trying to fallback.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Andy Shevchenko [Tue, 23 May 2017 17:03:19 +0000 (20:03 +0300)]
gpio: acpi: Even more tighten up ACPI GPIO lookups
The commit 10cf4899f8af ("gpiolib: tighten up ACPI legacy gpio lookups")
prevents to getting same resource twice if the driver asks twice using
different connection ID.
But the whole idea of fallback might bring some problems. Imagine the case when
we have two versions of BIOS/hardware where in one _DSD is introduced along
with GPIO resources, but the other one uses just plain GPIO resource for
another purpose
Charles Keepax [Tue, 23 May 2017 14:47:30 +0000 (15:47 +0100)]
gpio: arizona: Add support for GPIOs that need to be maintained
The Arizona devices only maintain the state of output GPIOs whilst the
CODEC is active, this can cause issues if the CODEC suspends whilst
something is relying on the state of one of its GPIOs. However, in
many systems the CODEC GPIOs are used for audio related features
and thus the state of the GPIOs is unimportant whilst the CODEC is
suspended. Often keeping the CODEC resumed in such a system would
incur a power impact that is unacceptable.
Allow the user to select whether a GPIO output should keep the
CODEC resumed, by adding a flag through the second cell of the GPIO
specifier in device tree.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Charles Keepax [Tue, 23 May 2017 14:47:28 +0000 (15:47 +0100)]
gpio: of: Reflect decoupling of open collector and active low/high
Commit 4c0facddb7d8 ("gpio: core: Decouple open drain/source flag with
active low/high") decoupled the open collector outputs from active
low/high but did not update the documentation.
Update the device tree documentation to correctly reflect this new
separation between the two concepts.
Gregory CLEMENT [Wed, 24 May 2017 14:32:06 +0000 (16:32 +0200)]
gpio: mvebu: Select REGMAP_MMIO now that regmap is used
Since the commit "gpio: mvebu: switch to regmap for register access" the
driver use the regmap. Explicitly select the REGMAP_MMIO symbol to fix
build error.
Jayachandran C [Mon, 22 May 2017 08:58:31 +0000 (08:58 +0000)]
gpio: xlp: update GPIO_XLP dependency
Broadcom Vulcan (ARCH_VULCAN) has been discontinued and will be deleted
soon. So, update the GPIO_XLP Kconfig entry to remove the ARCH_VULCAN
dependency.
Also update the documentation to note that Cavium ThunderX2 uses this
driver.
Signed-off-by: Jayachandran C <jnair@caviumnetworks.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Gregory CLEMENT [Fri, 19 May 2017 16:09:23 +0000 (18:09 +0200)]
gpio: mvebu: allow building driver for Armada 7K/8K
The mvebu gpio driver can also be used on arm64 mvebu SoC such as the
Armada 7K/8K. This commit allows to build the driver for them (when only
ARCH_MVEBU is defined)
Thomas Petazzoni [Fri, 19 May 2017 16:09:21 +0000 (18:09 +0200)]
gpio: mvebu: switch to regmap for register access
In order to be able to use this driver with the Armada 7K/8K SoCs, we
need to use the regmap to access the registers. Indeed for these new SoCs,
the gpio node will be part of a syscon.
[gregory.clement@free-electrons.com:
- fixed merge conflcit from 4.10 to 4.12-rc1
- added a commit log]
This moves irq property handling from spi/i2c specific code into
the generic mcp23s08_probe_one. This is possible because the
device properties are named equally.
As a side-effect this drops support for setting the properties via
pdata, which has no mainline users. If boardcode wants to enable
the chip as interrupt controller it can attach the device properties
instead.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Instead of using custom caching, this switches to regmap based
caching. Before the conversion the debugfs file used uncached
values, so that it was easily possible to see power-loss related
problems. The new code will check and recover at this place.
The patch will also ensure, that irqs are not cleared by checking
register status in debugfs.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
mcp23s08 support configuration of the pullups using the
pinconf framework. This removes the custom pullup configuration
from platform data, which has no upstream users.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For hot-pluggable devices adding GPIOs dynamically we need to
assemble and add the gpio lookup tables at probe time in modules,
so that requesting these GPIOs in attached drivers can work.
Export lookup table functions for modules.
Linus Torvalds [Mon, 22 May 2017 01:26:54 +0000 (18:26 -0700)]
x86: fix 32-bit case of __get_user_asm_u64()
The code to fetch a 64-bit value from user space was entirely buggered,
and has been since the code was merged in early 2016 in commit b2f680380ddf ("x86/mm/32: Add support for 64-bit __get_user() on 32-bit
kernels").
Happily the buggered routine is almost certainly entirely unused, since
the normal way to access user space memory is just with the non-inlined
"get_user()", and the inlined version didn't even historically exist.
The normal "get_user()" case is handled by external hand-written asm in
arch/x86/lib/getuser.S that doesn't have either of these issues.
There were two independent bugs in __get_user_asm_u64():
- it still did the STAC/CLAC user space access marking, even though
that is now done by the wrapper macros, see commit 11f1a4b9755f
("x86: reorganize SMAP handling in user space accesses").
This didn't result in a semantic error, it just means that the
inlined optimized version was hugely less efficient than the
allegedly slower standard version, since the CLAC/STAC overhead is
quite high on modern Intel CPU's.
- the double register %eax/%edx was marked as an output, but the %eax
part of it was touched early in the asm, and could thus clobber other
inputs to the asm that gcc didn't expect it to touch.
In particular, that meant that the generated code could look like
this:
mov (%eax),%eax
mov 0x4(%eax),%edx
where the load of %edx obviously was _supposed_ to be from the 32-bit
word that followed the source of %eax, but because %eax was
overwritten by the first instruction, the source of %edx was
basically random garbage.
The fixes are trivial: remove the extraneous STAC/CLAC entries, and mark
the 64-bit output as early-clobber to let gcc know that no inputs should
alias with the output register.
Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: stable@kernel.org # v4.8+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sun, 21 May 2017 22:25:46 +0000 (15:25 -0700)]
Clean up x86 unsafe_get/put_user() type handling
Al noticed that unsafe_put_user() had type problems, and fixed them in
commit a7cc722fff0b ("fix unsafe_put_user()"), which made me look more
at those functions.
It turns out that unsafe_get_user() had a type issue too: it limited the
largest size of the type it could handle to "unsigned long". Which is
fine with the current users, but doesn't match our existing normal
get_user() semantics, which can also handle "u64" even when that does
not fit in a long.
While at it, also clean up the type cast in unsafe_put_user(). We
actually want to just make it an assignment to the expected type of the
pointer, because we actually do want warnings from types that don't
convert silently. And it makes the code more readable by not having
that one very long and complex line.
[ This patch might become stable material if we ever end up back-porting
any new users of the unsafe uaccess code, but as things stand now this
doesn't matter for any current existing uses. ]
Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sun, 21 May 2017 19:06:44 +0000 (12:06 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull misc uaccess fixes from Al Viro:
"Fix for unsafe_put_user() (no callers currently in mainline, but
anyone starting to use it will step into that) + alpha osf_wait4()
infoleak fix"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
osf_wait4(): fix infoleak
fix unsafe_put_user()
Linus Torvalds [Sun, 21 May 2017 18:52:00 +0000 (11:52 -0700)]
Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fix from Thomas Gleixner:
"A single scheduler fix:
Prevent idle task from ever being preempted. That makes sure that
synchronize_rcu_tasks() which is ignoring idle task does not pretend
that no task is stuck in preempted state. If that happens and idle was
preempted on a ftrace trampoline the machine crashes due to
inconsistent state"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/core: Call __schedule() from do_idle() without enabling preemption
Al Viro [Sun, 21 May 2017 17:08:42 +0000 (13:08 -0400)]
fix unsafe_put_user()
__put_user_size() relies upon its first argument having the same type as what
the second one points to; the only other user makes sure of that and
unsafe_put_user() should do the same.
Linus Torvalds [Sun, 21 May 2017 06:39:03 +0000 (23:39 -0700)]
Merge tag 'trace-v4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
- Fix a bug caused by not cleaning up the new instance unique triggers
when deleting an instance. It also creates a selftest that triggers
that bug.
- Fix the delayed optimization happening after kprobes boot up self
tests being removed by freeing of init memory.
- Comment kprobes on why the delay optimization is not a problem for
removal of modules, to keep other developers from searching that
riddle.
- Fix another case of rcu not watching in stack trace tracing.
* tag 'trace-v4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Make sure RCU is watching before calling a stack trace
kprobes: Document how optimized kprobes are removed from module unload
selftests/ftrace: Add test to remove instance with active event triggers
selftests/ftrace: Fix bashisms
ftrace: Remove #ifdef from code and add clear_ftrace_function_probes() stub
ftrace/instances: Clear function triggers when removing instances
ftrace: Simplify glob handling in unregister_ftrace_function_probe_func()
tracing/kprobes: Enforce kprobes teardown after testing
tracing: Move postpone selftests to core from early_initcall
Linus Torvalds [Sat, 20 May 2017 23:12:30 +0000 (16:12 -0700)]
Merge branch 'for-linus' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"A small collection of fixes that should go into this cycle.
- a pull request from Christoph for NVMe, which ended up being
manually applied to avoid pulling in newer bits in master. Mostly
fibre channel fixes from James, but also a few fixes from Jon and
Vijay
- a pull request from Konrad, with just a single fix for xen-blkback
from Gustavo.
- a fuseblk bdi fix from Jan, fixing a regression in this series with
the dynamic backing devices.
- a blktrace fix from Shaohua, replacing sscanf() with kstrtoull().
- a request leak fix for drbd from Lars, fixing a regression in the
last series with the kref changes. This will go to stable as well"
* 'for-linus' of git://git.kernel.dk/linux-block:
nvmet: release the sq ref on rdma read errors
nvmet-fc: remove target cpu scheduling flag
nvme-fc: stop queues on error detection
nvme-fc: require target or discovery role for fc-nvme targets
nvme-fc: correct port role bits
nvme: unmap CMB and remove sysfs file in reset path
blktrace: fix integer parse
fuseblk: Fix warning in super_setup_bdi_name()
block: xen-blkback: add null check to avoid null pointer dereference
drbd: fix request leak introduced by locking/atomic, kref: Kill kref_sub()
Vijay Immanuel [Mon, 8 May 2017 23:38:35 +0000 (16:38 -0700)]
nvmet: release the sq ref on rdma read errors
On rdma read errors, release the sq ref that was taken
when the req was initialized. This avoids a hang in
nvmet_sq_destroy() when the queue is being freed.
Signed-off-by: Vijay Immanuel <vijayi@attalasystems.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
James Smart [Tue, 25 Apr 2017 22:32:01 +0000 (15:32 -0700)]
nvme-fc: stop queues on error detection
Per the recommendation by Sagi on:
http://lists.infradead.org/pipermail/linux-nvme/2017-April/009261.html
Rather than waiting for reset work thread to stop queues and abort the ios,
immediately stop the queues on error detection. Reset thread will restop
the queues (as it's called on other paths), but it does not appear to have
a side effect.
Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
Jon Derrick [Fri, 5 May 2017 20:52:06 +0000 (14:52 -0600)]
nvme: unmap CMB and remove sysfs file in reset path
CMB doesn't get unmapped until removal while getting remapped on every
reset. Add the unmapping and sysfs file removal to the reset path in
nvme_pci_disable to match the mapping path in nvme_pci_enable.
Fixes: 202021c1a ("nvme : Add sysfs entry for NVMe CMBs when appropriate") Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Acked-by: Keith Busch <keith.busch@intel.com> Reviewed-By: Stephen Bates <sbates@raithlin.com> Cc: <stable@vger.kernel.org> # 4.9+ Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
Linus Torvalds [Sat, 20 May 2017 16:02:27 +0000 (09:02 -0700)]
Merge tag 'staging-4.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are a number of staging driver fixes for 4.12-rc2
Most of them are typec driver fixes found by reviewers and users of
the code. There are also some removals of files no longer needed in
the tree due to the ion driver rewrite in 4.12-rc1, as well as some
wifi driver fixes. And to round it out, a MAINTAINERS file update.
All have been in linux-next with no reported issues"
* tag 'staging-4.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (22 commits)
MAINTAINERS: greybus-dev list is members-only
staging: fsl-dpaa2/eth: add ETHERNET dependency
staging: typec: fusb302: refactor resume retry mechanism
staging: typec: fusb302: reset i2c_busy state in error
staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c
staging: rtl8192e: GetTs Fix invalid TID 7 warning.
staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD.
staging: rtl8192e: fix 2 byte alignment of register BSSIDR.
staging: rtl8192e: rtl92e_fill_tx_desc fix write to mapped out memory.
staging: vc04_services: Fix bulk cache maintenance
staging: ccree: remove extraneous spin_unlock_bh() in error handler
staging: typec: Fix sparse warnings about incorrect types
staging: typec: fusb302: do not free gpio from managed resource
staging: typec: tcpm: Fix Port Power Role field in PS_RDY messages
staging: typec: tcpm: Respond to Discover Identity commands
staging: typec: tcpm: Set correct flags in PD request messages
staging: typec: tcpm: Drop duplicate PD messages
staging: typec: fusb302: Fix chip->vbus_present init value
staging: typec: fusb302: Fix module autoload
staging: typec: tcpci: declare private structure as static
...
Linus Torvalds [Sat, 20 May 2017 15:52:34 +0000 (08:52 -0700)]
Merge tag 'usb-4.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are a number of small USB fixes for 4.12-rc2
Most of them come from Johan, in his valiant quest to fix up all
drivers that could be affected by "malicious" USB devices. There's
also some fixes for more "obscure" drivers to handle some of the
vmalloc stack fallout (which for USB drivers, was always the case, but
very few people actually ran those systems...)
Other than that, the normal set of xhci and gadget and musb driver
fixes as well.
All have been in linux-next with no reported issues"
* tag 'usb-4.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (42 commits)
usb: musb: tusb6010_omap: Do not reset the other direction's packet size
usb: musb: Fix trying to suspend while active for OTG configurations
usb: host: xhci-plat: propagate return value of platform_get_irq()
xhci: Fix command ring stop regression in 4.11
xhci: remove GFP_DMA flag from allocation
USB: xhci: fix lock-inversion problem
usb: host: xhci-ring: don't need to clear interrupt pending for MSI enabled hcd
usb: host: xhci-mem: allocate zeroed Scratchpad Buffer
xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton
usb: xhci: trace URB before giving it back instead of after
USB: serial: qcserial: add more Lenovo EM74xx device IDs
USB: host: xhci: use max-port define
USB: hub: fix SS max number of ports
USB: hub: fix non-SS hub-descriptor handling
USB: hub: fix SS hub-descriptor handling
USB: usbip: fix nonconforming hub descriptor
USB: gadget: dummy_hcd: fix hub-descriptor removable fields
doc-rst: fixed kernel-doc directives in usb/typec.rst
USB: core: of: document reference taken by companion helper
USB: ehci-platform: fix companion-device leak
...