| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit ab262666018de6f4e206b021386b93ed0c164316.
As Johan says, this driver needs a lot more work and these changes are
only going in the wrong direction:
https://lkml.kernel.org/r/20190523091839.GC568@localhost
Reported-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/14a565fc1e14a5ec6cc6a6710deb878ae8305f22.1585905873.git.michal.simek@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 5e9bd2d70ae7c00a95a22994abf1eef728649e64.
As Johan says, this driver needs a lot more work and these changes are
only going in the wrong direction:
https://lkml.kernel.org/r/20190523091839.GC568@localhost
Reported-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/310999ab5342f788a7bc1b0e68294d4f052cad07.1585905873.git.michal.simek@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
RGB RAPIDFIRE
The Corsair K70 RGB RAPIDFIRE needs the USB_QUIRK_DELAY_INIT and
USB_QUIRK_DELAY_CTRL_MSG to function or it will randomly not
respond on boot, just like other Corsair keyboards
Signed-off-by: Jonathan Cox <jonathan@jdcox.net>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200410212427.2886-1-jonathan@jdcox.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The usb_get_maximum_speed() function is part of the usb-common module,
so enable it by selecting the corresponding Kconfig symbol.
While at it, also make sure to depend on USB_SUPPORT because USB_PHY
requires that. This can lead to Kconfig conflicts if USB_SUPPORT is not
enabled while attempting to enable PHY_TEGRA_XUSB.
Reported-by: kbuild test robot <lkp@intel.com>
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200330101038.2422389-1-thierry.reding@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
After PORT_RESET, the port is set to the appropriate
default_state. Ignore processing CC changes here as this
could cause the port to be switched into sink states
by default.
echo source > /sys/class/typec/port0/port_type
Before:
[ 154.528547] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms
[ 154.528560] CC1: 0 -> 0, CC2: 3 -> 0 [state PORT_RESET, polarity 0, disconnected]
[ 154.528564] state change PORT_RESET -> SNK_UNATTACHED
After:
[ 151.068814] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS]
[ 151.072440] CC1: 3 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, disconnected]
[ 151.172117] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms]
[ 151.172136] pending state change PORT_RESET_WAIT_OFF -> SRC_UNATTACHED @ 870 ms [rev3 NONE_AMS]
[ 152.060106] state change PORT_RESET_WAIT_OFF -> SRC_UNATTACHED [delayed 870 ms]
[ 152.060118] Start toggling
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20200402215947.176577-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
For userspace functions using OS Descriptors, if a function also supplies
Extended Property descriptors currently the counts and lengths stored in
the ms_os_descs_ext_prop_{count,name_len,data_len} variables are not
getting reset to 0 during an unbind or when the epfiles are closed. If
the same function is re-bound and the descriptors are re-written, this
results in those count/length variables to monotonically increase
causing the VLA allocation in _ffs_func_bind() to grow larger and larger
at each bind/unbind cycle and eventually fail to allocate.
Fix this by clearing the ms_os_descs_ext_prop count & lengths to 0 in
ffs_data_reset().
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable@vger.kernel.org
Signed-off-by: Udipto Goswami <ugoswami@codeaurora.org>
Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
Reviewed-by: Manu Gautam <mgautam@codeaurora.org>
Link: https://lore.kernel.org/r/20200402044521.9312-1-sallenki@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Immediate submission in case of a babbling device can lead
to a busy loop. Introducing a delayed work.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Tested-by: Jonas Karlsson <jonas.karlsson@actia.se>
Link: https://lore.kernel.org/r/20200415151358.32664-2-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Suspend increments a counter, then kills the URBs,
then kills the scheduled work. The scheduled work, however,
may reschedule the URBs. Fix this by having the work
check the counter.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Tested-by: Jonas Karlsson <jonas.karlsson@actia.se>
Link: https://lore.kernel.org/r/20200415151358.32664-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
A SCSI error handler and block runtime PM must not allocate
memory with GFP_KERNEL. Furthermore they must not wait for
tasks allocating memory with GFP_KERNEL.
That means that they cannot share a workqueue with arbitrary tasks.
Fix this for UAS using a private workqueue.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Fixes: f9dc024a2da1f ("uas: pre_reset and suspend: Fix a few races")
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200415141750.811-2-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Once a device is gone, the internal state does not matter anymore.
There is no need to spam the logs.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Fixes: 326349f824619 ("uas: add dead request list")
Link: https://lore.kernel.org/r/20200415141750.811-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If queue->size check in raw_event_queue_fetch() fails (which normally
shouldn't happen, that check is a fail-safe), the function returns
without reenabling interrupts. This patch fixes that issue, along with
propagating the cause of failure to the function caller.
Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Link: https://lore.kernel.org/r/9f7ce7a1472cfb9447f6c5a494186fa1f2670f6f.1586270396.git.andreyknvl@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The copy_to/from_user() functions return the number of bytes remaining
but we want to return negative error codes. I changed a couple checks
in raw_ioctl_ep_read() and raw_ioctl_ep0_read() to show that we still
we returning zero on error.
Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Link: https://lore.kernel.org/r/20200406145119.GG68494@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Since commit ef441dd6af91 ("usb: typec: mux: Allow the muxes to be named")
the typec_switch_desc and typec_mux_desc structs contain a name field.
The pi3usb30532 driver allocates these structs on the stack and so far did
not explicitly zero the mem used for the structs. This causes the new name
fields to point to a random memory address, which in my test case happens
to be a valid address leading to "interesting" mux / switch names:
[root@localhost ~]# ls -l /sys/class/typec_mux/
total 0
lrwxrwxrwx. 1 root root 0 Apr 14 12:55 ''$'\r''-switch' -> ...
lrwxrwxrwx. 1 root root 0 Apr 14 12:55 ''$'\320\302\006''2'$'...
Explicitly initialize the structs to zero when declaring them on the stack
so that any unused fields get set to 0, fixing this.
Fixes: ef441dd6af91 ("usb: typec: mux: Allow the muxes to be named")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200414133313.131802-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This fixes a bug that causes the USB3 early console to freeze after
printing a single line on AMD machines because it can't parse the
Transfer TRB properly.
The spec at
https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf
says in section "4.5.1 Device Context Index" that the Context Index,
also known as Endpoint ID according to
section "1.6 Terms and Abbreviations", is normally computed as
`DCI = (Endpoint Number * 2) + Direction`, which matches the current
definitions of XDBC_EPID_OUT and XDBC_EPID_IN.
However, the numbering in a Debug Capability Context data structure is
supposed to be different:
Section "7.6.3.2 Endpoint Contexts and Transfer Rings" explains that a
Debug Capability Context data structure has the endpoints mapped to indices
0 and 1.
Change XDBC_EPID_OUT/XDBC_EPID_IN to the spec-compliant values, add
XDBC_EPID_OUT_INTEL/XDBC_EPID_IN_INTEL with Intel's incorrect values, and
let xdbc_handle_tx_event() handle both.
I have verified that with this patch applied, the USB3 early console works
on both an Intel and an AMD machine.
Fixes: aeb9dd1de98c ("usb/early: Add driver for xhci debug capability")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Link: https://lore.kernel.org/r/20200401074619.8024-1-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
FuzzUSB (a variant of syzkaller) found a free-while-still-in-use bug
in the USB scatter-gather library:
BUG: KASAN: use-after-free in atomic_read
include/asm-generic/atomic-instrumented.h:26 [inline]
BUG: KASAN: use-after-free in usb_hcd_unlink_urb+0x5f/0x170
drivers/usb/core/hcd.c:1607
Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27
CPU: 1 PID: 27 Comm: kworker/u4:1 Not tainted 5.5.11 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1ubuntu1 04/01/2014
Workqueue: scsi_tmf_2 scmd_eh_abort_handler
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xce/0x128 lib/dump_stack.c:118
print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374
__kasan_report+0x153/0x1cb mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:639
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x152/0x1b0 mm/kasan/generic.c:192
__kasan_check_read+0x11/0x20 mm/kasan/common.c:95
atomic_read include/asm-generic/atomic-instrumented.h:26 [inline]
usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607
usb_unlink_urb+0x72/0xb0 drivers/usb/core/urb.c:657
usb_sg_cancel+0x14e/0x290 drivers/usb/core/message.c:602
usb_stor_stop_transport+0x5e/0xa0 drivers/usb/storage/transport.c:937
This bug occurs when cancellation of the S-G transfer races with
transfer completion. When that happens, usb_sg_cancel() may continue
to access the transfer's URBs after usb_sg_wait() has freed them.
The bug is caused by the fact that usb_sg_cancel() does not take any
sort of reference to the transfer, and so there is nothing to prevent
the URBs from being deallocated while the routine is trying to use
them. The fix is to take such a reference by incrementing the
transfer's io->count field while the cancellation is in progres and
decrementing it afterward. The transfer's URBs are not deallocated
until io->complete is triggered, which happens when io->count reaches
zero.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Kyungtae Kim <kt0755@gmail.com>
CC: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2003281615140.14837-100000@netrider.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
conf.listen_interval can sometimes be zero causing wake_up_count
to wrap around up to many beacons too late causing
CTRL-EVENT-BEACON-LOSS as in.
wpa_supplicant[795]: message repeated 45 times: [..CTRL-EVENT-BEACON-LOSS ]
Fixes: 43c93d9bf5e2 ("staging: vt6656: implement power saving code.")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/fce47bb5-7ca6-7671-5094-5c6107302f2b@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Although the vSGIs are not directly visible to the host, they still
get moved around by the CPU hotplug, for example. This results in
the kernel moaning on the console, such as:
genirq: irq_chip GICv4.1-sgi did not update eff. affinity mask of irq 38
Updating the effective affinity on set_affinity() fixes it.
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
When a vPE is made resident, the GIC starts parsing the virtual pending
table to deliver pending interrupts. This takes place asynchronously,
and can at times take a long while. Long enough that the vcpu enters
the guest and hits WFI before any interrupt has been signaled yet.
The vcpu then exits, blocks, and now gets a doorbell. Rince, repeat.
In order to avoid the above, a (optional on GICv4, mandatory on v4.1)
feature allows the GIC to feedback to the hypervisor whether it is
done parsing the VPT by clearing the GICR_VPENDBASER.Dirty bit.
The hypervisor can then wait until the GIC is ready before actually
running the vPE.
Plug the detection code as well as polling on vPE schedule. While
at it, tidy-up the kernel message that displays the GICv4 optional
features.
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
The controller always supports link recovery for device in SS and SSP.
Remove the speed limit check. Also, when the device is in RESUME or
RESET state, it means the controller received the resume/reset request.
The driver must send the link recovery to acknowledge the request. They
are valid states for the driver to send link recovery.
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Fixes: ee5cd41c9117 ("usb: dwc3: Update speed checks for SuperSpeedPlus")
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
|
|
Currently the calculation of max packet size limit for IN endpoints is
too restrictive. This prevents a matching of a capable hardware endpoint
during configuration. Below is the minimum recommended HW configuration
to support a particular endpoint setup from the databook:
For OUT endpoints, the databook recommended the minimum RxFIFO size to
be at least 3x MaxPacketSize + 3x setup packets size (8 bytes each) +
clock crossing margin (16 bytes).
For IN endpoints, the databook recommended the minimum TxFIFO size to be
at least 3x MaxPacketSize for endpoints that support burst. If the
endpoint doesn't support burst or when the device is operating in USB
2.0 mode, a minimum TxFIFO size of 2x MaxPacketSize is recommended.
Base on these recommendations, we can calculate the MaxPacketSize limit
of each endpoint. This patch revises the IN endpoint MaxPacketSize limit
and also sets the MaxPacketSize limit for OUT endpoints.
Reference: Databook 3.30a section 3.2.2 and 3.2.3
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
|
|
Change the macro name DWC3_GTXFIFOSIZ_TXFDEF to DWC3_GTXFIFOSIZ_TXFDEP
to match with the register name GTXFIFOSIZ.TXFDEP.
Fixes: 457e84b6624b ("usb: dwc3: gadget: dynamically re-size TxFifos")
Fixes: 0cab8d26d6e5 ("usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields")
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
|
|
When building with Clang + -Wtautological-pointer-compare:
drivers/usb/gadget/udc/bdc/bdc_ep.c:543:28: warning: comparison of
address of 'req->queue' equal to a null pointer is always false
[-Wtautological-pointer-compare]
if (req == NULL || &req->queue == NULL || &req->usb_req == NULL)
~~~~~^~~~~ ~~~~
drivers/usb/gadget/udc/bdc/bdc_ep.c:543:51: warning: comparison of
address of 'req->usb_req' equal to a null pointer is always false
[-Wtautological-pointer-compare]
if (req == NULL || &req->queue == NULL || &req->usb_req == NULL)
~~~~~^~~~~~~ ~~~~
2 warnings generated.
As it notes, these statements will always evaluate to false so remove
them.
Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC")
Link: https://github.com/ClangBuiltLinux/linux/issues/749
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
|
|
For skcipher algorithms, the input, output HW S/G tables
look like this: [IV, src][dst, IV]
Now, we can have 2 conditions here:
- there is no IV;
- src and dst are equal (in-place encryption) and scattered
and the error is an "off-by-one" in the HW S/G table.
This issue was seen with KASAN:
BUG: KASAN: slab-out-of-bounds in skcipher_edesc_alloc+0x95c/0x1018
Read of size 4 at addr ffff000022a02958 by task cryptomgr_test/321
CPU: 2 PID: 321 Comm: cryptomgr_test Not tainted
5.6.0-rc1-00165-ge4ef8383-dirty #4
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load4+0x90/0xb0
skcipher_edesc_alloc+0x95c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0x178/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Allocated by task 321:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
skcipher_edesc_alloc+0x21c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0x178/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff000022a02800
which belongs to the cache dma-kmalloc-512 of size 512
The buggy address is located 344 bytes inside of
512-byte region [ffff000022a02800, ffff000022a02a00)
The buggy address belongs to the page:
page:fffffe00006a8000 refcount:1 mapcount:0 mapping:ffff00093200c400
index:0x0 compound_mapcount: 0
flags: 0xffff00000010200(slab|head)
raw: 0ffff00000010200 dead000000000100 dead000000000122 ffff00093200c400
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff000022a02800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff000022a02880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff000022a02900: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
^
ffff000022a02980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff000022a02a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Fixes: 334d37c9e263 ("crypto: caam - update IV using HW support")
Cc: <stable@vger.kernel.org> # v5.3+
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Here's the KASAN report:
BUG: KASAN: use-after-free in rsa_pub_done+0x70/0xe8
Read of size 1 at addr ffff000023082014 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc1-00162-gfcb90d5 #60
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load1+0x5c/0x68
rsa_pub_done+0x70/0xe8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
irq_exit+0x114/0x128
__handle_domain_irq+0x80/0xe0
gic_handle_irq+0x50/0xa0
el1_irq+0xb8/0x180
cpuidle_enter_state+0xa4/0x490
cpuidle_enter+0x48/0x70
call_cpuidle+0x44/0x70
do_idle+0x304/0x338
cpu_startup_entry+0x24/0x40
rest_init+0xf8/0x10c
arch_call_rest_init+0xc/0x14
start_kernel+0x774/0x7b4
Allocated by task 263:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
rsa_edesc_alloc+0x2cc/0xe10
caam_rsa_enc+0x9c/0x5f0
test_akcipher_one+0x78c/0x968
alg_test_akcipher+0x78/0xf8
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Freed by task 0:
save_stack+0x24/0xb0
__kasan_slab_free+0x10c/0x188
kasan_slab_free+0x10/0x18
kfree+0x7c/0x298
rsa_pub_done+0x68/0xe8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
The buggy address belongs to the object at ffff000023082000
which belongs to the cache dma-kmalloc-256 of size 256
The buggy address is located 20 bytes inside of
256-byte region [ffff000023082000, ffff000023082100)
The buggy address belongs to the page:
page:fffffe00006c2080 refcount:1 mapcount:0 mapping:ffff00093200c200 index:0x0 compound_mapcount: 0
flags: 0xffff00000010200(slab|head)
raw: 0ffff00000010200 dead000000000100 dead000000000122 ffff00093200c200
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff000023081f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff000023081f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff000023082000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff000023082080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff000023082100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Fixes: bf53795025a2 ("crypto: caam - add crypto_engine support for RSA algorithms")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Here's the KASAN report:
BUG: KASAN: use-after-free in ahash_done+0xdc/0x3b8
Read of size 1 at addr ffff00002303f010 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc1-00162-gfcb90d5 #59
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load1+0x5c/0x68
ahash_done+0xdc/0x3b8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
irq_exit+0x114/0x128
__handle_domain_irq+0x80/0xe0
gic_handle_irq+0x50/0xa0
el1_irq+0xb8/0x180
cpuidle_enter_state+0xa4/0x490
cpuidle_enter+0x48/0x70
call_cpuidle+0x44/0x70
do_idle+0x304/0x338
cpu_startup_entry+0x24/0x40
rest_init+0xf8/0x10c
arch_call_rest_init+0xc/0x14
start_kernel+0x774/0x7b4
Allocated by task 263:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
ahash_edesc_alloc+0x58/0x1f8
ahash_final_no_ctx+0x94/0x6e8
ahash_final+0x24/0x30
crypto_ahash_op+0x58/0xb0
crypto_ahash_final+0x30/0x40
do_ahash_op+0x2c/0xa0
test_ahash_vec_cfg+0x894/0x9e0
test_hash_vec_cfg+0x6c/0x88
test_hash_vec+0xfc/0x1e0
__alg_test_hash+0x1ac/0x368
alg_test_hash+0xf8/0x1c8
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Freed by task 0:
save_stack+0x24/0xb0
__kasan_slab_free+0x10c/0x188
kasan_slab_free+0x10/0x18
kfree+0x7c/0x298
ahash_done+0xd4/0x3b8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
The buggy address belongs to the object at ffff00002303f000
which belongs to the cache dma-kmalloc-128 of size 128
The buggy address is located 16 bytes inside of
128-byte region [ffff00002303f000, ffff00002303f080)
The buggy address belongs to the page:
page:fffffe00006c0fc0 refcount:1 mapcount:0 mapping:ffff00093200c000 index:0x0
flags: 0xffff00000000200(slab)
raw: 0ffff00000000200 dead000000000100 dead000000000122 ffff00093200c000
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff00002303ef00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff00002303ef80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff00002303f000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff00002303f080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff00002303f100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Fixes: 21b014f038d3 ("crypto: caam - add crypto_engine support for HASH algorithms")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Here's the KASAN report:
BUG: KASAN: use-after-free in aead_crypt_done+0x60/0xd8
Read of size 1 at addr ffff00002303f014 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc1-00162-gfcb90d5 #58
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load1+0x5c/0x68
aead_crypt_done+0x60/0xd8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
irq_exit+0x114/0x128
__handle_domain_irq+0x80/0xe0
gic_handle_irq+0x50/0xa0
el1_irq+0xb8/0x180
_raw_spin_unlock_irq+0x2c/0x78
finish_task_switch+0xa4/0x2f8
__schedule+0x3a4/0x890
schedule_idle+0x28/0x50
do_idle+0x22c/0x338
cpu_startup_entry+0x24/0x40
rest_init+0xf8/0x10c
arch_call_rest_init+0xc/0x14
start_kernel+0x774/0x7b4
Allocated by task 263:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
aead_edesc_alloc+0x1b4/0xbf0
ipsec_gcm_encrypt+0xd4/0x140
crypto_aead_encrypt+0x50/0x68
test_aead_vec_cfg+0x498/0xec0
test_aead_vec+0x110/0x200
alg_test_aead+0xfc/0x680
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Freed by task 0:
save_stack+0x24/0xb0
__kasan_slab_free+0x10c/0x188
kasan_slab_free+0x10/0x18
kfree+0x7c/0x298
aead_crypt_done+0x58/0xd8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
The buggy address belongs to the object at ffff00002303f000
which belongs to the cache dma-kmalloc-128 of size 128
The buggy address is located 20 bytes inside of
128-byte region [ffff00002303f000, ffff00002303f080)
The buggy address belongs to the page:
page:fffffe00006c0fc0 refcount:1 mapcount:0 mapping:ffff00093200c000 index:0x0
flags: 0xffff00000000200(slab)
raw: 0ffff00000000200 dead000000000100 dead000000000122 ffff00093200c000
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff00002303ef00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff00002303ef80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff00002303f000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff00002303f080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff00002303f100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Fixes: 1c2402266713 ("crypto: caam - add crypto_engine support for AEAD algorithms")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Here's the KASAN report:
BUG: KASAN: use-after-free in skcipher_crypt_done+0xe8/0x1a8
Read of size 1 at addr ffff00002304001c by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc1-00162-gfcb90d5 #57
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load1+0x5c/0x68
skcipher_crypt_done+0xe8/0x1a8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
irq_exit+0x114/0x128
__handle_domain_irq+0x80/0xe0
gic_handle_irq+0x50/0xa0
el1_irq+0xb8/0x180
_raw_spin_unlock_irq+0x2c/0x78
finish_task_switch+0xa4/0x2f8
__schedule+0x3a4/0x890
schedule_idle+0x28/0x50
do_idle+0x22c/0x338
cpu_startup_entry+0x24/0x40
rest_init+0xf8/0x10c
arch_call_rest_init+0xc/0x14
start_kernel+0x774/0x7b4
Allocated by task 263:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
skcipher_edesc_alloc+0x21c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0xf8/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Freed by task 0:
save_stack+0x24/0xb0
__kasan_slab_free+0x10c/0x188
kasan_slab_free+0x10/0x18
kfree+0x7c/0x298
skcipher_crypt_done+0xe0/0x1a8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
The buggy address belongs to the object at ffff000023040000
which belongs to the cache dma-kmalloc-512 of size 512
The buggy address is located 28 bytes inside of
512-byte region [ffff000023040000, ffff000023040200)
The buggy address belongs to the page:
page:fffffe00006c1000 refcount:1 mapcount:0 mapping:ffff00093200c400 index:0x0 compound_mapcount: 0
flags: 0xffff00000010200(slab|head)
raw: 0ffff00000010200 dead000000000100 dead000000000122 ffff00093200c400
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff00002303ff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff00002303ff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff000023040000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff000023040080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff000023040100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Fixes: ee38767f152a ("crypto: caam - support crypto_engine framework for SKCIPHER algorithms")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Add missing module firmware for turings.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Ben Skeggs <skeggsb@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ <CACAvsv4njTRpiNqOC54iRjpd=nu3pBG8i_fp8o_dp7AZE6hFWA@mail.gmail.com
|
|
ASB was failing to load on Turing GPUs when firmware is being loaded
from initramfs, leaving the GPU in an odd state and causing suspend/
resume to fail.
Add missing MODULE_FIRMWARE() lines for initramfs generators.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: <stable@vger.kernel.org> # 5.6
|
|
git://people.freedesktop.org/~agd5f/linux into drm-fixes
amd-drm-fixes-5.7-2020-04-15:
amdgpu:
- gfx10 fix
- SMU7 overclocking fix
- RAS fix
- GPU reset fix
- Fix a regression in a previous s/r fix
- Add a gfxoff quirk
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200415221631.3924-1-alexander.deucher@amd.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull EFI fixes from Ingo Molnar:
"Misc EFI fixes, including the boot failure regression caused by the
BSS section not being cleared by the loaders"
* tag 'efi-urgent-2020-04-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi/x86: Revert struct layout change to fix kexec boot regression
efi/x86: Don't remap text<->rodata gap read-only for mixed mode
efi/x86: Fix the deletion of variables in mixed mode
efi/libstub/file: Merge file name buffers to reduce stack usage
Documentation/x86, efi/x86: Clarify EFI handover protocol and its requirements
efi/arm: Deal with ADR going out of range in efi_enter_kernel()
efi/x86: Always relocate the kernel for EFI handover entry
efi/x86: Move efi stub globals from .bss to .data
efi/libstub/x86: Remove redundant assignment to pointer hdr
efi/cper: Use scnprintf() for avoiding potential buffer overflow
|
|
Fix the following sparse warning:
drivers/net/ethernet/dec/tulip/tulip_core.c:1280:28: warning: symbol
'early_486_chipsets' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
To rehash a previous explanation given in commit 1c44ce560b4d ("net:
mscc: ocelot: fix vlan_filtering when enslaving to bridge before link is
up"), the switch driver operates the in a mode where a single VLAN can
be transmitted as untagged on a particular egress port. That is the
"native VLAN on trunk port" use case.
The configuration for this native VLAN is driven in 2 ways:
- Set the egress port rewriter to strip the VLAN tag for the native
VID (as it is egress-untagged, after all).
- Configure the ingress port to drop untagged and priority-tagged
traffic, if there is no native VLAN. The intention of this setting is
that a trunk port with no native VLAN should not accept untagged
traffic.
Since both of the above configurations for the native VLAN should only
be done if VLAN awareness is requested, they are actually done from the
ocelot_port_vlan_filtering function, after the basic procedure of
toggling the VLAN awareness flag of the port.
But there's a problem with that simplistic approach: we are trying to
juggle with 2 independent variables from a single function:
- Native VLAN of the port - its value is held in port->vid.
- VLAN awareness state of the port - currently there are some issues
here, more on that later*.
The actual problem can be seen when enslaving the switch ports to a VLAN
filtering bridge:
0. The driver configures a pvid of zero for each port, when in
standalone mode. While the bridge configures a default_pvid of 1 for
each port that gets added as a slave to it.
1. The bridge calls ocelot_port_vlan_filtering with vlan_aware=true.
The VLAN-filtering-dependent portion of the native VLAN
configuration is done, considering that the native VLAN is 0.
2. The bridge calls ocelot_vlan_add with vid=1, pvid=true,
untagged=true. The native VLAN changes to 1 (change which gets
propagated to hardware).
3. ??? - nobody calls ocelot_port_vlan_filtering again, to reapply the
VLAN-filtering-dependent portion of the native VLAN configuration,
for the new native VLAN of 1. One can notice that after toggling "ip
link set dev br0 type bridge vlan_filtering 0 && ip link set dev br0
type bridge vlan_filtering 1", the new native VLAN finally makes it
through and untagged traffic finally starts flowing again. But
obviously that shouldn't be needed.
So it is clear that 2 independent variables need to both re-trigger the
native VLAN configuration. So we introduce the second variable as
ocelot_port->vlan_aware.
*Actually both the DSA Felix driver and the Ocelot driver already had
each its own variable:
- Ocelot: ocelot_port_private->vlan_aware
- Felix: dsa_port->vlan_filtering
but the common Ocelot library needs to work with a single, common,
variable, so there is some refactoring done to move the vlan_aware
property from the private structure into the common ocelot_port
structure.
Fixes: 97bb69e1e36e ("net: mscc: ocelot: break apart ocelot_vlan_port_apply")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
A couple of fixes:
* FTM responder policy netlink validation fix
(but the only user validates again later)
* kernel-doc fixes
* a fix for a race in mac80211 radio registration vs. userspace
* a mesh channel switch fix
* a fix for a syzbot reported kasprintf() issue
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
DMA transfer could be completed, but CPU (which handles DMA interrupt)
may get too busy and can't handle the interrupt in a timely manner,
despite of DMA IRQ being raised. In this case the DMA state needs to
synchronized before terminating DMA transfer in order not to miss the
DMA transfer completion.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Boot CPU0 always handle I2C interrupt and under some rare circumstances
(like running KASAN + NFS root) it may stuck in uninterruptible state for
a significant time. In this case we will get timeout if I2C transfer is
running on a sibling CPU, despite of IRQ being raised. In order to handle
this rare condition, the IRQ status needs to be checked after completion
timeout.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
The DMA transfer might finish just after checking the state with
dma_cookie_status, but before the lock is acquired. Not checking
for an empty list in xilinx_dma_tx_status may result in reading
random data or data corruption when desc is written to. This can
be reliably triggered by using dma_sync_wait to wait for DMA
completion.
Signed-off-by: Sebastian von Ohr <vonohr@smaract.com>
Tested-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/20200303130518.333-1-vonohr@smaract.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The mutex_unlock() is missed on error path of psil_get_ep_config()
which causes deadlock, so add missed mutex_unlock().
Fixes: 8c6bb62f6b4a ("dmaengine: ti: k3 PSI-L remote endpoint configuration")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20200408185501.30776-1-grygorii.strashko@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
If PCI_MSI is not set, building fais:
drivers/dma/hisi_dma.c: In function ‘hisi_dma_free_irq_vectors’:
drivers/dma/hisi_dma.c:138:2: error: implicit declaration of function ‘pci_free_irq_vectors’;
did you mean ‘pci_alloc_irq_vectors’? [-Werror=implicit-function-declaration]
pci_free_irq_vectors(data);
^~~~~~~~~~~~~~~~~~~~
Make HISI_DMA depends on PCI_MSI to fix this.
Fixes: e9f08b65250d ("dmaengine: hisilicon: Add Kunpeng DMA engine support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200328114133.17560-1-yuehaibing@huawei.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
siw_fastreg_mr() invokes siw_mem_id2obj(), which returns a local reference
of the siw_mem object to "mem" with increased refcnt. When
siw_fastreg_mr() returns, "mem" becomes invalid, so the refcount should be
decreased to keep refcount balanced.
The issue happens in one error path of siw_fastreg_mr(). When "base_mr"
equals to NULL but "mem" is not NULL, the function forgets to decrease the
refcnt increased by siw_mem_id2obj() and causes a refcnt leak.
Reorganize the flow so that the goto unwind can be used as expected.
Fixes: b9be6f18cf9e ("rdma/siw: transmit path")
Link: https://lore.kernel.org/r/1586939949-69856-1-git-send-email-xiyuyang19@fudan.edu.cn
Reported-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
|
|
All in-tree users have been converted to the new i2c_new_scanned_device
function, so remove this deprecated one.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
device_property_read_u32() returns errno or 0, so we should use the
integer variable 'ret' and not the u32 'val' to hold the retval.
Fixes: 0560ad576268 ("i2c: altera: Add Altera I2C Controller driver")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Thor Thayer <thor.thayer@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
We already set DPM_FLAG_SMART_PREPARE, so we completely skip all
callbacks (other then prepare) where possible, quoting from
dw_i2c_plat_prepare():
/*
* If the ACPI companion device object is present for this device, it
* may be accessed during suspend and resume of other devices via I2C
* operation regions, so tell the PM core and middle layers to avoid
* skipping system suspend/resume callbacks for it in that case.
*/
return !has_acpi_companion(dev);
Also setting the DPM_FLAG_SMART_SUSPEND will cause acpi_subsys_suspend()
to leave the controller runtime-suspended even if dw_i2c_plat_prepare()
returned 0.
Leaving the controller runtime-suspended normally, when the I2C controller
is suspended during the suspend_late phase, is not an issue because
the pm_runtime_get_sync() done by i2c_dw_xfer() will (runtime-)resume it.
But for dw I2C controllers on Bay- and Cherry-Trail devices acpi_lpss.c
leaves the controller alive until the suspend_noirq phase, because it may
be used by the _PS3 ACPI methods of PCI devices and PCI devices are left
powered on until the suspend_noirq phase.
Between the suspend_late and resume_early phases runtime-pm is disabled.
So for any ACPI I2C OPRegion accesses done after the suspend_late phase,
the pm_runtime_get_sync() done by i2c_dw_xfer() is a no-op and the
controller is left runtime-suspended.
i2c_dw_xfer() has a check to catch this condition (rather then waiting
for the I2C transfer to timeout because the controller is suspended).
acpi_subsys_suspend() leaving the controller runtime-suspended in
combination with an ACPI I2C OPRegion access done after the suspend_late
phase triggers this check, leading to the following error being logged
on a Bay Trail based Lenovo Thinkpad 8 tablet:
[ 93.275882] i2c_designware 80860F41:00: Transfer while suspended
[ 93.275993] WARNING: CPU: 0 PID: 412 at drivers/i2c/busses/i2c-designware-master.c:429 i2c_dw_xfer+0x239/0x280
...
[ 93.276252] Workqueue: kacpi_notify acpi_os_execute_deferred
[ 93.276267] RIP: 0010:i2c_dw_xfer+0x239/0x280
...
[ 93.276340] Call Trace:
[ 93.276366] __i2c_transfer+0x121/0x520
[ 93.276379] i2c_transfer+0x4c/0x100
[ 93.276392] i2c_acpi_space_handler+0x219/0x510
[ 93.276408] ? up+0x40/0x60
[ 93.276419] ? i2c_acpi_notify+0x130/0x130
[ 93.276433] acpi_ev_address_space_dispatch+0x1e1/0x252
...
So since on BYT and CHT platforms we want ACPI I2c OPRegion accesses
to work until the suspend_noirq phase, we need the controller to be
runtime-resumed during the suspend phase if it is runtime-suspended
suspended at that time. This means that we must not set the
DPM_FLAG_SMART_SUSPEND on these platforms.
On BYT and CHT we already have a special ACCESS_NO_IRQ_SUSPEND flag
to make sure the controller stays functional until the suspend_noirq
phase. This commit makes the driver not set the DPM_FLAG_SMART_SUSPEND
flag when that flag is set.
Cc: stable@vger.kernel.org
Fixes: b30f2f65568f ("i2c: designware: Set IRQF_NO_SUSPEND flag for all BYT and CHT controllers")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
We are racing to initialize sched->thread here, just always check the
current thread.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Kent Russell <kent.russell@amd.com>
Link: https://patchwork.freedesktop.org/patch/361303/
|
|
Fix the following sparse warning:
drivers/firmware/xilinx/zynqmp-debug.c:38:15: warning: symbol
'firmware_debugfs_root' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200415084311.24857-1-yanaijie@huawei.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
The function “platform_get_irq” can log an error already.
Thus omit a redundant message for the exception handling in the
calling function.
This issue was detected by using the Coccinelle software.
Fixes: 3f68be7d8e96 ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/76f24122-4d3f-7670-9f06-edb4731a0661@web.de
|
|
The firmware driver is optional, but the power driver depends on it,
which needs to be reflected in Kconfig to avoid link errors:
aarch64-linux-ld: drivers/soc/xilinx/zynqmp_power.o: in function `zynqmp_pm_isr':
zynqmp_power.c:(.text+0x284): undefined reference to `zynqmp_pm_invoke_fn'
The firmware driver can probably be allowed for compile-testing as
well, so it's best to drop the dependency on the ZYNQ platform
here and allow building as long as the firmware code is built-in.
Fixes: ab272643d723 ("drivers: soc: xilinx: Add ZynqMP PM driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200408155224.2070880-1-arnd@arndb.de
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
Link: https://lore.kernel.org/r/20200413170501.13381-1-flameeyes@flameeyes.com
Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
If the __copy_from_user function failed we need to call sg_remove_request
in sg_write.
Link: https://lore.kernel.org/r/610618d9-e983-fd56-ed0f-639428343af7@huawei.com
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Wu Bo <wubo40@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Some Google Apex Edge TPU devices have a class code of 0
(PCI_CLASS_NOT_DEFINED). This prevents the PCI core from assigning
resources for the Apex BARs because __dev_sort_resources() ignores
classless devices, host bridges, and IOAPICs.
On x86, firmware typically assigns those resources, so this was not a
problem. But on some architectures, firmware does *not* assign BARs, and
since the PCI core didn't do it either, the Apex device didn't work
correctly:
apex 0000:01:00.0: can't enable device: BAR 0 [mem 0x00000000-0x00003fff 64bit pref] not claimed
apex 0000:01:00.0: error enabling PCI device
f390d08d8b87 ("staging: gasket: apex: fixup undefined PCI class") added a
quirk to fix the class code, but it was in the apex driver, and if the
driver was built as a module, it was too late to help.
Move the quirk to the PCI core, where it will always run early enough that
the PCI core will assign resources if necessary.
Link: https://lore.kernel.org/r/CAEzXK1r0Er039iERnc2KJ4jn7ySNUOG9H=Ha8TD8XroVqiZjgg@mail.gmail.com
Fixes: f390d08d8b87 ("staging: gasket: apex: fixup undefined PCI class")
Reported-by: Luís Mendes <luis.p.mendes@gmail.com>
Debugged-by: Luís Mendes <luis.p.mendes@gmail.com>
Tested-by: Luis Mendes <luis.p.mendes@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Todd Poynor <toddpoynor@google.com>
|
