ACPICA commit 07fffd02607685b655ed92ee15c160e6a810b60b

The acpi_debug_trace() is the mechanism known as ACPI method tracing that is
used by Linux as ACPICA debugging message reducer. This facility can be
controlled through Linux ACPI subsystem - /sys/module/acpi/parameters.
This facility requires CONFIG_ACPI_DEBUG to be enabled to see ACPICA trace
logs in the kernel dmesg output.

This patch enhances acpi_debug_trace() to make it not only a message reducer,
but a real tracer to trace AML interpreter execution. Note that in addition
to the AML tracer enabling, this patch also updates the facility with the
following enhancements:
1. Allow a full path to be specified by the acpi_debug_trace() API.
2. Allow any method rather than just the entrance of acpi_evaluate_object()
   to be traced.
3. All interpreter ACPI_LV_TRACE_POINT messages are collected for
   ACPI_EXECUTER layer.

The Makefile of drivers/acpi/acpica is also updated to include exdebug.o
and the duplicated stubs are removed after that.

Note that since this patch has enhanced the method tracing facility, Linux
need also be updated after applying this patch. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/07fffd02Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 71299ec8b49054daace0df50268e8e055654ca37

This patch adds trace point at the following point:
 1. Begin/end of a control method execution;
 2. Begin/end of an opcode execution.

The trace point feature can be enabled by defining ACPI_DEBUG_OUTPUT
and specifying a debug level that includes ACPI_LV_TRACDE_POINT and the
debug layers that include ACPI_PARSER and ACPI_DISPACTCHER.

In order to make aml_op_name of union acpi_parse_object usable for tracer, it is
enabled for ACPI_DEBUG_OUTPUT in this patch. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/71299ec8Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit c8275e243b58fd4adfc0362bd704af41ed14bc75

This patch moves parts of acpi_dm_dump_method_info() to the dispatcher
component.

This patch also makes the new function dependent on ACPI_DEBUG_OUTPUT
compile-stage definition so that it can be used by the trace facility.

acpi_dm_dump_method_info() traverses method stack when an exception is
encountered. Such traversal is needed to support method tracing for the
exceptions. When an exception is encountered, the end indications of the
aborted methods should be logged in order not to break the user space
analysis tool. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/c8275e24Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 6e0229bb156d71675f2e07dc7960adb7ec0a60ea

This patch adds functions to return normalized full path instead of
"external path". The external path contains trailing "_" for each
name segment while the normalized full path doesn't contain the
trailing "_".

Currently this function is used by the method tracing users to specify a
none trailing "_" attached name path. Lv Zheng.

Note that we need to validate and switch all Linux kernel acpi_get_name()
users to use the new name type before removing the old name type from
ACPICA.

Link: https://github.com/acpica/acpica/commit/6e0229bbSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Reviewed-by: NRuiyi Zhang <ruiyi_zhang@hotmail.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 9dcd124e914e87495fbd1786d9484b962e0823e0

This patch adds back pointing reference of the namespace node for a method
operand. The namespace node then can be used in
acpi_ds_terminate_control_method() to obtain method full path to be used by
tracing facilities. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/9dcd124eSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit afb52611dbe7403551f93504d3798534f5c343f4

This patch cleans up the code of assigning the AML address to the
union acpi_operand_object.

The idea behind this cleanup is:
The AML address of the union acpi_operand_object should always be determined at
the point where the object is encountered. It should be started from the
first byte of the object. For example, the opcode of the object, the name
string of the user_term object, or the first byte of the packaged object
(where a pkg_length is prefixed). So it's not cleaner to have it assigned
here and there in the entire ACPICA source tree.

There are some special cases for the internal opcodes, before cleaning up
the internal opcodes, we should also determine the rules for the AML
addresses of the internal opcodes:
1. INT_NAMEPATH_OP: the address of the first byte for the name_string.
2. INT_METHODCALL_OP: the address of the first byte for the name_string.
3. INT_BYTELIST_OP: the address of the first byte for the byte_data list.
4. INT_EVAL_SUBTREE_OP: the address of the first byte for the
                        Region/Package/Buffer/bank_field/Field arguments.
5. INT_NAMEDFIELD_OP: the address to the name_seg.
6. INT_RESERVEDFIELD_OP: the address to the 0x00 prefix.
7. INT_ACCESSFIELD_OP: the address to the 0x01 prefix.
8. INT_CONNECTION_OP: the address to the 0x02 prefix.
9: INT_EXTACCESSFIELD_OP: the address to the 0x03 prefix.
10.INT_RETURN_VALUE_OP: the address of the replaced operand.
11.computational_data: the address to the
                      Byte/Word/Dword/Qword/string_prefix.

Before cleaning up the internal root scope of the aml_walk, turning it into
the term_list, we need to remember the aml_start address as the "Aml"
attribute for the union acpi_operand_object created by acpi_ps_create_scope_op().

Finally, we can delete some redundant AML address assignment in psloop.c.

Link: https://github.com/acpica/acpica/commit/afb52611Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 61b360074fde2bb8282722579410f5d1fb12f84d

This patch converts aml_offset in union acpi_operand_object to AML address.

AML offset is actually only used by the debugger, using AML address is more
direct and efficient during the parsing stage so that we don't need to
calculate the offset during the parsing stage and will not have
difficulities in converting it into other offset attributes.

Sometimes, aml_offset is not an indication of the offset from the table
header but the offset from the entry of a list of terms, which requires
additional efforts to convert it into an offset from the table header. By
using AML address directly, there is no such difficulty.
Thus this patch also deletes a logic in disassembler that is trying to
convert the aml_offset from
  "offset from the start address of Method/Package/Buffer"
into the
  "offset from the start address of the ACPI table"
(Sample code deletion can be seen in acpi_dm_deferred_parse(), but the
function is not in the Linux kernel). Lv Zheng.

Link: https://github.com/acpica/acpica/commit/61b36007Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit d254405814495058276c0c2f9d96794d15a6c91c

This patch converts aml_offset in struct acpi_walk_state to AML address.

AML offset is actually only used by the debugger, using AML address is more
direct and efficient during the parsing stage so that we don't need to
calculate it during the parsing stage.

On the other hand, we can see several issues in the current parser logic
around the aml_offset:
1. union acpi_operand_object.Common.aml_offset is redundantly assigned in
   acpi_ps_parse_loop().
2. aml_offset is not an indication of the offset from the table header but
   the offset from the entry of a list of objects. Sometimes, it indicates
   an entry for a Method/Package/Buffer, which makes it difficult to be
   reversely calculated to a table header offset.
3. When being used with method tracers (for example, Linux function trace),
   it's better to have AML address logged instead of the AML offset because
   the address is the only attribute that can uniquely identify the opcode.
This patch is required to solve the above issues. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/d2544058Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch reduces divergences in parser/namespace components so that the
follow-up linuxized ACPICA upstream commits can be directly merged.
Including the fix to an indent issue reported and fixed by Zhouyi Zhou.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NZhouyi Zhou <yizhouzhou@ict.ac.cn>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Switch to my kernel.org alias instead of a badly named gmail address,
which I rarely use.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some modules call config_item_init_type_name() and config_group_init_type_name()
with parameter "name" directly controlled by userspace.  These two
functions call config_item_set_name() with this name used as a format
string, which can be used to leak information such as content of the
stack to userspace.

For example, make_netconsole_target() in netconsole module calls
config_item_init_type_name() with the name of a newly-created directory.
This means that the following commands give some unexpected output, with
configfs mounted in /sys/kernel/config/ and on a system with a
configured eth0 ethernet interface:

    # modprobe netconsole
    # mkdir /sys/kernel/config/netconsole/target_%lx
    # echo eth0 > /sys/kernel/config/netconsole/target_%lx/dev_name
    # echo 1 > /sys/kernel/config/netconsole/target_%lx/enabled
    # echo eth0 > /sys/kernel/config/netconsole/target_%lx/dev_name
    # dmesg |tail -n1
    [  142.697668] netconsole: target (target_ffffffffc0ae8080) is
    enabled, disable to update parameters

The directory name is correct but %lx has been interpreted in the
internal item name, displayed here in the error message used by
store_dev_name() in drivers/net/netconsole.c.

To fix this, update every caller of config_item_set_name to use "%s"
when operating on untrusted input.

This issue was found using -Wformat-security gcc flag, once a __printf
attribute has been added to config_item_set_name().
Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NJoel Becker <jlbec@evilplan.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Remove the 'flags' variable in order to fix the following warning:

drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

rtc_sysfs_add_device checks if device can wakeup before creating the
wakealarm file in sysfs. Thus the driver must set wakeup capability
before registering the rtc device.
Signed-off-by: NWei-Ning Huang <wnhuang@google.com>
Acked-by: NEddie Huang <eddie.huang@mediatek.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The GICv3 ITS architecture allows a given [DevID, EventID] pair to be
translated to a [LPI, Collection] pair, where DevID is the device writing
the MSI, EventID is the payload being written, LPI is the actual
interrupt number, and Collection is roughly equivalent to a target CPU.

Each LPI can be mapped to a separate collection, but the ITS driver
insists on maintaining the collection on a device basis, instead of doing
it on a per interrupt basis.

This is obviously flawed, and this patch fixes it by adding a per interrupt
index that indicates which collection number is in use.
Reported-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org	# 4.1, 4.0
Link: http://lkml.kernel.org/r/1437126402-11677-1-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Calls to set_memory_wb() incure heavy TLB flush and IPI cost. To
minimize those wait until pool grow beyond batch size before
draining the pool.
Signed-off-by: NJérôme Glisse <jglisse@redhat.com>
Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-and-Tested-by: NMichel Dänzer <michel@daenzer.net>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Current code never allowed the page pool to actualy fill in anyway.
This fix it, so that we only start freeing page from the pool when
we go over the pool size.

Changed since v1:
  - Move the page batching optimization to its separate patch.

Changed since v2:
  - Do not remove code part of the batching optimization with
    this patch.
  - Better commit message.
Signed-off-by: NJérôme Glisse <jglisse@redhat.com>
Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-and-Tested-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If no work was performed then prealloc_data_structs() wasn't ever called
so there isn't any need to call prealloc_free_structs().
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

Refactor writeback_some_dirty_blocks() to avoid prealloc_data_structs()
if the policy doesn't have any dirty blocks ready for writeback.
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

All methods that queue work call wake_worker() as you'd expect.
E.g. cell_defer, defer_bio, quiesce_migration (which is called by
writeback, promote, demote_then_promote, invalidate, discard, etc).
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

Something (ATOM BIOS?) seems to be clobbering the LB_INTERRUPT_MASK
register while the CRTC is off, which caused e.g. glxgears or
gnome-shell to hang after a modeset.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>

This has been a source of confusion.  Make it debug only.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

So the selected forced level shows up properly in sysfs.
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This is necessary to properly reset the min/max limits before
clamping them otherwise we may get improper clamping depending
on what what was the last forced level.
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Always respect the harvest configuration as is.
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

v2: squash in later fix
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If we run into a part with a harvest configuration where the entire
IP block is unusable, just disable the IP block.

v2: fix logic as noted by Christian
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>

Just to make sure userspace don't send nonsense to the kernel.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>

Port of amdgpu patch 9298e52f.
Signed-off-by: NChristian König <christian.koenig@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This can be the case when the GPU is powered off, e.g. via vgaswitcheroo
or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin
flushes the TLB after setting rdev->gart.ptr to non-NULL.

Fixes panic on powering off R7xx GPUs.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

There is currently no way to see that the needs_check flag has been set
in the metadata.  Display 'needs_check' in the cache status if it is set
in the cache metadata.

Also, update cache documentation.
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

There is currently no way to see that the needs_check flag has been set
in the metadata.  Display 'needs_check' in the thin-pool status if it is
set in the thinp metadata.

Also, update thinp documentation.
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

This fixes an issue where running out of data space would cause the
thin-pool's metadata to become read-only.  There was no reason to make
metadata read-only -- calling set_pool_mode() with PM_READ_ONLY was a
misguided way to error all queued and future write IOs.  We can
accomplish the same by degrading from PM_OUT_OF_DATA_SPACE to
PM_OUT_OF_DATA_SPACE with error_if_no_space enabled.

Otherwise, the use of PM_READ_ONLY could cause a race where commit() was
started before the PM_READ_ONLY transition but dm_pool_commit_metadata()
would go on to fail because the block manager had transitioned to
read-only.  The return of -EPERM from dm_pool_commit_metadata(), due to
attempting to commit while in read-only mode, caused the thin-pool to
set 'needs_check' because a metadata_operation_failed().  This needless
cascade of failures makes life for users more difficult than needed.
Reported-by: NVivek Goyal <vgoyal@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

Commit 1e6f2416 changed the scsi sysfs 'queue_depth' code to
rejects depths higher than the scsi host template setting. But lots
of hosts set this to 1, and update the settings in the scsi host
when the controller/devices probing happens.

This breaks (at least) mpt2sas and mpt3sas runtime setting of queue
depth, returning EINVAL for all settings but '1'. And once it's set to
1, there's no way to go back up.

Cc: stable@vger.kernel.org
Fixes: 1e6f2416 "scsi: don't allow setting of queue_depth bigger than can_queue"
Signed-off-by: NJens Axboe <axboe@fb.com>
Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

pca953x interrupt controller functionality is implemented using
nested threaded IRQs which require parent_irq to be configured
properly otherwise below warning can be seen if IRQ core
will try re-schedule nested IRQ:

------------[ cut here ]------------
WARNING: CPU: 1 PID: 12 at kernel/irq/manage.c:696 irq_nested_primary_handler+0x30/0x38()
Primary handler called for nested irq 301
Modules linked in: uinput ipv6 smsc95xx usbnet mii imx2_wdt etnaviv(C) matrix_keypad matrix_keymap ar1021_i2c
CPU: 1 PID: 12 Comm: ksoftirqd/1 Tainted: G        WC    4.1.1 #9
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<c0013298>] (dump_backtrace) from [<c0013488>] (show_stack+0x20/0x24)
[<c0013468>] (show_stack) from [<c05743c4>] (dump_stack+0x70/0xc0)
[<c0574354>] (dump_stack) from [<c002b7b8>] (warn_slowpath_common+0x88/0xc0)
[<c002b730>] (warn_slowpath_common) from [<c002b8ac>] (warn_slowpath_fmt+0x40/0x48)
[<c002b870>] (warn_slowpath_fmt) from [<c0075798>] (irq_nested_primary_handler+0x30/0x38)
[<c0075768>] (irq_nested_primary_handler) from [<c0075200>] (handle_irq_event_percpu+0x70/0x2d0)
[<c0075190>] (handle_irq_event_percpu) from [<c00754ac>] (handle_irq_event+0x4c/0x6c)
[<c0075460>] (handle_irq_event) from [<c0078204>] (handle_simple_irq+0xa4/0xc8)
[<c0078160>] (handle_simple_irq) from [<c0077cd4>] (resend_irqs+0x50/0x7c)
[<c0077c84>] (resend_irqs) from [<c002f99c>] (tasklet_action+0x94/0x140)
[<c002f908>] (tasklet_action) from [<c002eea8>] (__do_softirq+0xa0/0x3c8)
[<c002ee08>] (__do_softirq) from [<c002f208>] (run_ksoftirqd+0x38/0x54)
[<c002f1d0>] (run_ksoftirqd) from [<c004b1e4>] (smpboot_thread_fn+0x1f8/0x2f0)
[<c004afec>] (smpboot_thread_fn) from [<c0047744>] (kthread+0xe8/0x104)
[<c004765c>] (kthread) from [<c000fac8>] (ret_from_fork+0x14/0x2c)
---[ end trace 96052cda48865769 ]---

The issue was reported and described in details by Lothar Waßmann and
Christian Gmeiner in https://lkml.org/lkml/2014/9/9/123.

Fix it by adding missed call of gpiochip_set_chained_irqchip()
so GPIO IRQ chip helpers will set parent_irq for nested IRQs
properly.
Reported-by: NLothar Waßmann <LW@KARO-electronics.de>
Tested-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Two SLES11 SP3 servers encountered similar crashes simultaneously
following some kind of SAN/tape target issue:

...
qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 --  1 2002.
qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 --  1 2002.
qla2xxx [0000:81:00.0]-8009:3: DEVICE RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800f:3: DEVICE RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-8009:3: TARGET RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800f:3: TARGET RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-8012:3: BUS RESET ISSUED nexus=3:0:2.
qla2xxx [0000:81:00.0]-802b:3: BUS RESET SUCCEEDED nexus=3:0:2.
qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
qla2xxx [0000:81:00.0]-8018:3: ADAPTER RESET ISSUED nexus=3:0:2.
qla2xxx [0000:81:00.0]-00af:3: Performing ISP error recovery - ha=ffff88bf04d18000.
 rport-3:0-0: blocked FC remote port time out: removing target and saving binding
qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
qla2xxx [0000:81:00.0]-8017:3: ADAPTER RESET SUCCEEDED nexus=3:0:2.
 rport-2:0-0: blocked FC remote port time out: removing target and saving binding
sg_rq_end_io: device detached
BUG: unable to handle kernel NULL pointer dereference at 00000000000002a8
IP: [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
PGD 7e6586f067 PUD 7e5af06067 PMD 0 [1739975.390354] Oops: 0002 [#1] SMP
CPU 0
...
Supported: No, Proprietary modules are loaded [1739975.390463]
Pid: 27965, comm: ABCD Tainted: PF           X 3.0.101-0.29-default #1 HP ProLiant DL580 Gen8
RIP: 0010:[<ffffffff8133b268>]  [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
RSP: 0018:ffff8839dc1e7c68  EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff883f0592fc00 RCX: 0000000000000090
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000138
RBP: 0000000000000138 R08: 0000000000000010 R09: ffffffff81bd39d0
R10: 00000000000009c0 R11: ffffffff81025790 R12: 0000000000000001
R13: ffff883022212b80 R14: 0000000000000004 R15: ffff883022212b80
FS:  00007f8e54560720(0000) GS:ffff88407f800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000002a8 CR3: 0000007e6ced6000 CR4: 00000000001407f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ABCD (pid: 27965, threadinfo ffff8839dc1e6000, task ffff883592e0c640)
Stack:
 ffff883f0592fc00 00000000fffffffa 0000000000000001 ffff883022212b80
 ffff883eff772400 ffffffffa03fa309 0000000000000000 0000000000000000
 ffffffffa04003a0 ffff883f063196c0 ffff887f0379a930 ffffffff8115ea1e
Call Trace:
 [<ffffffffa03fa309>] st_open+0x129/0x240 [st]
 [<ffffffff8115ea1e>] chrdev_open+0x13e/0x200
 [<ffffffff811588a8>] __dentry_open+0x198/0x310
 [<ffffffff81167d74>] do_last+0x1f4/0x800
 [<ffffffff81168fe9>] path_openat+0xd9/0x420
 [<ffffffff8116946c>] do_filp_open+0x4c/0xc0
 [<ffffffff8115a00f>] do_sys_open+0x17f/0x250
 [<ffffffff81468d92>] system_call_fastpath+0x16/0x1b
 [<00007f8e4f617fd0>] 0x7f8e4f617fcf
Code: eb d3 90 48 83 ec 28 40 f6 c6 04 48 89 6c 24 08 4c 89 74 24 20 48 89 fd 48 89 1c 24 4c 89 64 24 10 41 89 f6 4c 89 6c 24 18 74 11 <f0> ff 8f 70 01 00 00 0f 94 c0 45 31 ed 84 c0 74 2b 4c 8d a5 a0
RIP  [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
 RSP <ffff8839dc1e7c68>
CR2: 00000000000002a8

Analysis reveals the cause of the crash to be due to STp->device
being NULL. The pointer was NULLed via scsi_tape_put(STp) when it
calls scsi_tape_release(). In st_open() we jump to err_out after
scsi_block_when_processing_errors() completes and returns the
device as offline (sdev_state was SDEV_DEL):

1180 /* Open the device. Needs to take the BKL only because of incrementing the SCSI host
1181    module count. */
1182 static int st_open(struct inode *inode, struct file *filp)
1183 {
1184         int i, retval = (-EIO);
1185         int resumed = 0;
1186         struct scsi_tape *STp;
1187         struct st_partstat *STps;
1188         int dev = TAPE_NR(inode);
1189         char *name;
...
1217         if (scsi_autopm_get_device(STp->device) < 0) {
1218                 retval = -EIO;
1219                 goto err_out;
1220         }
1221         resumed = 1;
1222         if (!scsi_block_when_processing_errors(STp->device)) {
1223                 retval = (-ENXIO);
1224                 goto err_out;
1225         }
...
1264  err_out:
1265         normalize_buffer(STp->buffer);
1266         spin_lock(&st_use_lock);
1267         STp->in_use = 0;
1268         spin_unlock(&st_use_lock);
1269         scsi_tape_put(STp); <-- STp->device = 0 after this
1270         if (resumed)
1271                 scsi_autopm_put_device(STp->device);
1272         return retval;

The ref count for the struct scsi_tape had already been reduced
to 1 when the .remove method of the st module had been called.
The kref_put() in scsi_tape_put() caused scsi_tape_release()
to be called:

0266 static void scsi_tape_put(struct scsi_tape *STp)
0267 {
0268         struct scsi_device *sdev = STp->device;
0269
0270         mutex_lock(&st_ref_mutex);
0271         kref_put(&STp->kref, scsi_tape_release); <-- calls this
0272         scsi_device_put(sdev);
0273         mutex_unlock(&st_ref_mutex);
0274 }

In scsi_tape_release() the struct scsi_device in the struct
scsi_tape gets set to NULL:

4273 static void scsi_tape_release(struct kref *kref)
4274 {
4275         struct scsi_tape *tpnt = to_scsi_tape(kref);
4276         struct gendisk *disk = tpnt->disk;
4277
4278         tpnt->device = NULL; <<<---- where the dev is nulled
4279
4280         if (tpnt->buffer) {
4281                 normalize_buffer(tpnt->buffer);
4282                 kfree(tpnt->buffer->reserved_pages);
4283                 kfree(tpnt->buffer);
4284         }
4285
4286         disk->private_data = NULL;
4287         put_disk(disk);
4288         kfree(tpnt);
4289         return;
4290 }

Although the problem was reported on SLES11.3 the problem appears
in linux-next as well.

The crash is fixed by reordering the code so we no longer access
the struct scsi_tape after the kref_put() is done on it in st_open().
Signed-off-by: NShane Seymour <shane.seymour@hp.com>
Signed-off-by: NDarren Lavender <darren.lavender@hp.com>
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.com>
Acked-by: NKai Mäkisara <kai.makisara@kolumbus.fi>
Cc: stable@vger.kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

OMAP GPIO driver allowed to be built as loadable module, but it
doesn't set owner field in GPIO chip structure. As result,
module_get/put() API is not working and it's possible to unload
OMAP driver while in use:

  omap_gpio 48051000.gpio: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED

Hence, add missing configuration.

Cc: Tony Lindgren <tony@atomide.com>
Fixes: cac089f9 ('gpio: omap: Allow building as a loadable module')
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In case the gpiochip doesn't have the .dev field set, as is the case
in here, it is not possible to reference this device in DT as a GPIO
controller. A good example of this problem is that gpio-leds can not
be used when connected to this chip, the gpio-leds driver bails out
with -EPROBE_DEFER.

Fix this problem by setting the .dev field of the gpio_chip to the
parent i2c device.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mans Rullgard <mans@mansr.com>
Cc: Olaf Mandel <o.mandel@menlosystems.com>
Cc: Semen Protsenko <semen.protsenko@globallogic.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>