BINDER_TYPE_PTR objects point to memory areas in the
source process to be copied into the target buffer
as part of a transaction. This implements a scatter-
gather model where non-contiguous memory in a source
process is "gathered" into a contiguous region in
the target buffer.
The data can include pointers that must be fixed up
to correctly point to the copied data. To avoid making
source process pointers visible to the target process,
this patch defers the copy until the fixups are known
and then copies and fixeups are done together.
There is a special case of BINDER_TYPE_FDA which applies
the fixup later in the target process context. In this
case the user data is skipped (so no untranslated fds
become visible to the target).
Reviewed-by: Martijn Coenen <maco@android.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211130185152.437403-5-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is to prepare for an up coming patch where we read
pre-translated fds from the sender buffer and translate them before
copying them to the target. It does not change run time.
The patch adds two new parameters to binder_translate_fd_array() to
hold the sender buffer and sender buffer parent. These parameters let
us call copy_from_user() directly from the sender instead of using
binder_alloc_copy_from_buffer() to copy from the target. Also the patch
adds some new alignment checks. Previously the alignment checks would
have been done in a different place, but this lets us print more
useful error messages.
Reviewed-by: Martijn Coenen <maco@android.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211130185152.437403-4-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Transactions are copied from the sender to the target
first and objects like BINDER_TYPE_PTR and BINDER_TYPE_FDA
are then fixed up. This means there is a short period where
the sender's version of these objects are visible to the
target prior to the fixups.
Instead of copying all of the data first, copy data only
after any needed fixups have been applied.
Fixes: 457b9a6f09 ("Staging: android: add binder driver")
Reviewed-by: Martijn Coenen <maco@android.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211130185152.437403-3-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If a memory copy function fails to copy the whole buffer,
a positive integar with the remaining bytes is returned.
In binder_translate_fd_array() this can result in an fd being
skipped due to the failed copy, but the loop continues
processing fds since the early return condition expects a
negative integer on error.
Fix by returning "ret > 0 ? -EINVAL : ret" to handle this case.
Fixes: bb4a2e48d5 ("binder: return errors from buffer copy functions")
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211130185152.437403-2-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
binder.c file comment produce warning with checkpatch as below:
WARNING: Possible repeated word: 'for'
Remove the repeated word from the comment avoid this warning.
Signed-off-by: Ajith P V <ajithpv.linux@gmail.com>
Link: https://lore.kernel.org/r/20211125122218.6767-1-ajithpv.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We don't want to be retrying task_work creation failure if there's
an actual signal pending for the parent task. If we do, then we can
enter an infinite loop of perpetually retrying and each retry failing
with -ERESTARTNOINTR because a signal is pending.
Fixes: 3146cba99a ("io-wq: make worker creation resilient against signals")
Reported-by: Florian Fischer <florian.fl.fischer@fau.de>
Link: https://lore.kernel.org/io-uring/20211202165606.mqryio4yzubl7ms5@pasture/
Tested-by: Florian Fischer <florian.fl.fischer@fau.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Using MKWORD() on a byte-sized variable results in OOB read. Expand the
size of the reserved area so both MKWORD and MKBYTE continue to work
without overflow. Silences this warning on a -Warray-bounds build:
drivers/char/mwave/3780i.h:346:22: error: array subscript 'short unsigned int[0]' is partly outside array bounds of 'DSP_ISA_SLAVE_CONTROL[1]' [-Werror=array-bounds]
346 | #define MKWORD(var) (*((unsigned short *)(&var)))
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/char/mwave/3780i.h:356:40: note: in definition of macro 'OutWordDsp'
356 | #define OutWordDsp(index,value) outw(value,usDspBaseIO+index)
| ^~~~~
drivers/char/mwave/3780i.c:373:41: note: in expansion of macro 'MKWORD'
373 | OutWordDsp(DSP_IsaSlaveControl, MKWORD(rSlaveControl));
| ^~~~~~
drivers/char/mwave/3780i.c:358:31: note: while referencing 'rSlaveControl'
358 | DSP_ISA_SLAVE_CONTROL rSlaveControl;
| ^~~~~~~~~~~~~
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20211203084206.3104326-1-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make multi-line comment style aligned.
While at it, drop filename from the file.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125213203.86693-11-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Split headers to three groups and sort alphabetically in each of them.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125213203.86693-9-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the similar way as it's done for EEPROM, factor out
a new helper function for FRAM.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125213203.86693-8-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's obvious that custom approach of getting power of 2 number with
int_pow() kinda interesting. Replace it and some others approaches
by using a simple BIT() operation.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125213203.86693-7-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no need to copy twice the same data. Drop needless local
variable.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125213203.86693-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Access to platform data via dev_get_platdata() getter to make code cleaner.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125213203.86693-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
device_property_read_u32() may return different error codes.
Unshadow them in the at25_fw_to_chip() to give better error
report.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125213203.86693-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently some values are compared against the contents of the chip structure
and most are from its updated copy in at25->chip. Use the latter one everywhere
in ->probe().
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125213203.86693-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Obviously the byte_len value should be checked from the chip
and not from at25->chip.
Fixes: fd307a4ad3 ("nvmem: prepare basics for FRAM support")
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125212729.86585-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Even if we know that we are going to fill everything later on
it's bad style and fragile to copy garbage from the stack to
the data structure that will be used in the driver.
Fixes: fd307a4ad3 ("nvmem: prepare basics for FRAM support")
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125212729.86585-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit f60e707490 ("misc: at25: Make use of device property API")
made a good job by enabling the driver for non-OF platforms, but the
recent commit 604288bc61 ("nvmem: eeprom: at25: fix type compiler warnings")
brought that back.
Restore greatness of the driver once again.
Fixes: eab61fb1cc ("nvmem: eeprom: at25: fram discovery simplification")
Fixes: fd307a4ad3 ("nvmem: prepare basics for FRAM support")
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211125212729.86585-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit fd307a4ad3 ("nvmem: prepare basics for FRAM support") added
support for FRAM devices such as the Cypress FM25V. During testing, it
was found that the FRAM detects properly, however reads and writes fail.
Upon further investigation, two problem were found in at25_probe() routine.
1) In the case of an FRAM device without platform data, eg.
fram == true && spi->dev.platform_data == NULL
the stack local variable "struct spi_eeprom chip" is not initialized
fully, prior to being copied into at25->chip. The chip.flags field in
particular can cause problems.
2) The byte_len of FRAM is computed from its ID register, and is stored
into the stack local "struct spi_eeprom chip" structure. This happens
after the same structure has been copied into at25->chip. As a result,
at25->chip.byte_len does not contain the correct length of the device.
In turn this can cause checks at beginning of at25_ee_read() to fail
(or equally, it could allow reads beyond the end of the device length).
Fix both of these issues by eliminating the on-stack struct spi_eeprom.
Instead use the one inside at25_data structure, which starts of zeroed.
Fixes: fd307a4ad3 ("nvmem: prepare basics for FRAM support")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Link: https://lore.kernel.org/r/20211108181627.645638-1-ralph.siemsen@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The buffer list is sorted and this is not being considered while
calculating packet size. This would lead to improper copy length
calculation for non-dmaheap buffers which would eventually cause
sending improper buffers to DSP.
Fixes: c68cfb718c ("misc: fastrpc: Add support for context Invoke method")
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Jeya R <jeyr@codeaurora.org>
Link: https://lore.kernel.org/r/1637771481-4299-1-git-send-email-jeyr@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For some reason I forgot to add myself as maintainer when we
upstreamed FastRPC patches.
Add myself and Amol from Qualcomm as maintainers for Qualcomm FastRPC driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20211124142325.27108-1-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is a small window in time during resume where the hardware
flow control signal RTS can be asserted (which allows a sender to
resume sending data to the UART) but the baud rate has not yet
been restored. This will cause corrupted data and FRAMING, OVERRUN
and BREAK errors. This is happening because the MCTRL register is
shadowed in uart_port struct and is later used during resume to set
the MCTRL register during both serial8250_do_startup() and
uart_resume_port(). Unfortunately, serial8250_do_startup()
happens before the UART baud rate is restored. The fix is to clear
the shadowed mctrl value at the end of suspend and restore it at the
end of resume.
Fixes: 41a469482d ("serial: 8250: Add new 8250-core based Broadcom STB driver")
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Link: https://lore.kernel.org/r/20211201201402.47446-1-alcooperx@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 7120a447c7 ("drm/ttm: Double check mem_type of BO while eviction")
made ttm_bo_evict_swapout_allowable() function actually check the
placement, but we always used a dummy placement in ttm_bo_swapout.
Fix this by using the real placement instead.
Signed-off-by: Christian König <christian.koenig@amd.com>
Fixes: 7120a447c7 ("drm/ttm: Double check mem_type of BO while eviction")
Reviewed-by: Pan, Xinhui <Xinhui.Pan@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211202103828.44573-1-christian.koenig@amd.com
In cdnsp_endpoint_init(), cdnsp_ring_alloc() is assigned to pep->ring
and there is a dereference of it in cdnsp_endpoint_init(), which could
lead to a NULL pointer dereference on failure of cdnsp_ring_alloc().
Fix this bug by adding a check of pep->ring.
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_USB_CDNSP_GADGET=y show no new warnings,
and our static analyzer no longer warns about this code.
Fixes: 3d82904559 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
Cc: stable <stable@vger.kernel.org>
Acked-by: Pawel Laszczak <pawell@cadence.com>
Acked-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Link: https://lore.kernel.org/r/20211130172700.206650-1-zhou1615@umn.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is another branded 8153 device that doesn't work well with LPM:
r8152 2-2.1:1.0 enp0s13f0u2u1: Stop submitting intr, status -71
Disable LPM to resolve the issue.
Signed-off-by: Ole Ernst <olebowle@gmx.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211127090546.52072-1-olebowle@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Turns out some xHC controllers require all 64 bits in the CRCR register
to be written to execute a command abort.
The lower 32 bits containing the command abort bit is written first.
In case the command ring stops before we write the upper 32 bits then
hardware may use these upper bits to set the commnd ring dequeue pointer.
Solve this by making sure the upper 32 bits contain a valid command
ring dequeue pointer.
The original patch that only wrote the first 32 to stop the ring went
to stable, so this fix should go there as well.
Fixes: ff0e50d356 ("xhci: Fix command ring pointer corruption while aborting a command")
Cc: stable@vger.kernel.org
Tested-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211126122340.1193239-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
qdiscs/fq_pie requires CONFIG_NET_SCH_FQ_PIE, otherwise tc will fail
to create a fq_pie qdisc.
It fixes following issue:
# not ok 57 83be - Create FQ-PIE with invalid number of flows
# Command exited with 2, expected 0
# Error: Specified qdisc not found.
Signed-off-by: Li Zhijian <zhijianx.li@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mark the summary result as FAIL to prevent from confusing the selftest
framework if some of them are failed.
Previously, the selftest framework always treats it as *ok* even though
some of them are failed actually. That's because the script tdc.sh always
return 0.
# All test results:
#
# 1..97
# ok 1 83be - Create FQ-PIE with invalid number of flows
# ok 2 8b6e - Create RED with no flags
[...snip]
# ok 6 5f15 - Create RED with flags ECN, harddrop
# ok 7 53e8 - Create RED with flags ECN, nodrop
# ok 8 d091 - Fail to create RED with only nodrop flag
# ok 9 af8e - Create RED with flags ECN, nodrop, harddrop
# not ok 10 ce7d - Add mq Qdisc to multi-queue device (4 queues)
# Could not match regex pattern. Verify command output:
# qdisc mq 1: root
# qdisc fq_codel 0: parent 1:4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
# qdisc fq_codel 0: parent 1:3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
[...snip]
# ok 96 6979 - Change quantum of a strict ETS band
# ok 97 9a7d - Change ETS strict band without quantum
#
#
#
#
ok 1 selftests: tc-testing: tdc.sh <<< summary result
CC: Philip Li <philip.li@intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Li Zhijian <zhijianx.li@intel.com>
Acked-by: Davide Caratti <dcaratti@redhat.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For Foxconn T99W175 device(sdx55 platform) in some host platform,
it would be unavailable once the host execute the err handler.
After checking, it's caused by the delay time too short to
get a successful reset.
Please see my test evidence as bewlow(BTW, I add some extra test logs
in function mhi_pci_reset_prepare and mhi_pci_reset_done):
When MHI_POST_RESET_DELAY_MS equals to 500ms:
Nov 4 14:30:03 jbd-ThinkEdge kernel: [ 146.222477] mhi mhi0: Device MHI is not in valid state
Nov 4 14:30:03 jbd-ThinkEdge kernel: [ 146.222628] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare reset
Nov 4 14:30:03 jbd-ThinkEdge kernel: [ 146.222631] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare mhi_soc_reset
Nov 4 14:30:03 jbd-ThinkEdge kernel: [ 146.222632] mhi mhi0: mhi_soc_reset write soc to reset
Nov 4 14:30:05 jbd-ThinkEdge kernel: [ 147.839993] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_done
Nov 4 14:30:05 jbd-ThinkEdge kernel: [ 147.902063] mhi-pci-generic 0000:2d:00.0: reset failed
When MHI_POST_RESET_DELAY_MS equals to 1000ms or 1500ms:
Nov 4 19:07:26 jbd-ThinkEdge kernel: [ 157.067857] mhi mhi0: Device MHI is not in valid state
Nov 4 19:07:26 jbd-ThinkEdge kernel: [ 157.068029] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare reset
Nov 4 19:07:26 jbd-ThinkEdge kernel: [ 157.068032] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare mhi_soc_reset
Nov 4 19:07:26 jbd-ThinkEdge kernel: [ 157.068034] mhi mhi0: mhi_soc_reset write soc to reset
Nov 4 19:07:29 jbd-ThinkEdge kernel: [ 159.607006] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_done
Nov 4 19:07:29 jbd-ThinkEdge kernel: [ 159.607152] mhi mhi0: Requested to power ON
Nov 4 19:07:51 jbd-ThinkEdge kernel: [ 181.302872] mhi mhi0: Failed to reset MHI due to syserr state
Nov 4 19:07:51 jbd-ThinkEdge kernel: [ 181.303011] mhi-pci-generic 0000:2d:00.0: failed to power up MHI controller
When MHI_POST_RESET_DELAY_MS equals to 2000ms:
Nov 4 17:51:08 jbd-ThinkEdge kernel: [ 147.180527] mhi mhi0: Failed to transition from PM state: Linkdown or Error Fatal Detect to: SYS ERROR Process
Nov 4 17:51:08 jbd-ThinkEdge kernel: [ 147.180535] mhi mhi0: Device MHI is not in valid state
Nov 4 17:51:08 jbd-ThinkEdge kernel: [ 147.180722] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare reset
Nov 4 17:51:08 jbd-ThinkEdge kernel: [ 147.180725] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare mhi_soc_reset
Nov 4 17:51:08 jbd-ThinkEdge kernel: [ 147.180727] mhi mhi0: mhi_soc_reset write soc to reset
Nov 4 17:51:11 jbd-ThinkEdge kernel: [ 150.230787] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_done
Nov 4 17:51:11 jbd-ThinkEdge kernel: [ 150.230928] mhi mhi0: Requested to power ON
Nov 4 17:51:11 jbd-ThinkEdge kernel: [ 150.231173] mhi mhi0: Power on setup success
Nov 4 17:51:14 jbd-ThinkEdge kernel: [ 153.254747] mhi mhi0: Wait for device to enter SBL or Mission mode
I also tried big data like 3000, and it worked as well. 500ms may not be
enough for all support mhi device. We shall increase it to 2000ms
at least.
Link: https://lore.kernel.org/r/20211108113127.3938-1-slark_xiao@163.com
[mani: massaged commit message little bit, added Fixes tag and CCed stable]
Fixes: 8ccc3279fc ("mhi: pci_generic: Add support for reset")
Cc: stable@vger.kernel.org
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Slark Xiao <slark_xiao@163.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20211126104951.35685-2-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes spurious wakeups from s0ix on Lenovo ThinkPad X1 Cargon Gen 9 on
lid close.
These wakeups are generated by interrupts from the ISH on changes to the
lid status.
By disabling the wake IRQ from the ISH we inhibit these spurious
wakeups while keeping the resume from LID open through the ACPI
interrupt.
Reports on the Lenovo forums indicate that Lenovo ThinkPad X1 Yoga Gen6
is also affected.
Fixes: ae02e5d40d ("HID: intel-ish-hid: ipc layer")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214855
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20211130060117.3026-1-linux@weissschuh.net
The prodikeys HID driver only controls USB devices, yet did not have a
dependancy on USB_HID. This causes build errors on some configurations
like nios2 when building due to new changes to the prodikeys driver.
Reported-by: kernel test robot <lkp@intel.com>
Cc: stable@vger.kernel.org
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20211203081231.2856936-1-gregkh@linuxfoundation.org
The chicony HID driver only controls USB devices, yet did not have a
dependancy on USB_HID. This causes build errors on some configurations
like sparc when building due to new changes to the chicony driver.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: stable@vger.kernel.org
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20211203075927.2829218-1-gregkh@linuxfoundation.org
The trampoline_pgd only maps the 0xfffffff000000000-0xffffffffffffffff
range of kernel memory (with 4-level paging). This range contains the
kernel's text+data+bss mappings and the module mapping space but not the
direct mapping and the vmalloc area.
This is enough to get the application processors out of real-mode, but
for code that switches back to real-mode the trampoline_pgd is missing
important parts of the address space. For example, consider this code
from arch/x86/kernel/reboot.c, function machine_real_restart() for a
64-bit kernel:
#ifdef CONFIG_X86_32
load_cr3(initial_page_table);
#else
write_cr3(real_mode_header->trampoline_pgd);
/* Exiting long mode will fail if CR4.PCIDE is set. */
if (boot_cpu_has(X86_FEATURE_PCID))
cr4_clear_bits(X86_CR4_PCIDE);
#endif
/* Jump to the identity-mapped low memory code */
#ifdef CONFIG_X86_32
asm volatile("jmpl *%0" : :
"rm" (real_mode_header->machine_real_restart_asm),
"a" (type));
#else
asm volatile("ljmpl *%0" : :
"m" (real_mode_header->machine_real_restart_asm),
"D" (type));
#endif
The code switches to the trampoline_pgd, which unmaps the direct mapping
and also the kernel stack. The call to cr4_clear_bits() will find no
stack and crash the machine. The real_mode_header pointer below points
into the direct mapping, and dereferencing it also causes a crash.
The reason this does not crash always is only that kernel mappings are
global and the CR3 switch does not flush those mappings. But if theses
mappings are not in the TLB already, the above code will crash before it
can jump to the real-mode stub.
Extend the trampoline_pgd to contain all kernel mappings to prevent
these crashes and to make code which runs on this page-table more
robust.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20211202153226.22946-5-joro@8bytes.org
Boris reported that in one of his randconfig builds, objtool got
infinitely stuck. Turns out there's trivial list corruption in the
pv_ops tracking when a function is both in a static table and in a code
assignment.
Avoid re-adding function to the pv_ops[] lists when they're already on
it.
Fixes: db2b0c5d7b ("objtool: Support pv_opsindirect calls for noinstr")
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Link: https://lkml.kernel.org/r/20211202204534.GA16608@worktop.programming.kicks-ass.net
Clang warns:
drivers/fpga/stratix10-soc.c:431:9: warning: variable 'ret' is uninitialized when used here [-Wuninitialized]
return ret;
^~~
ret is only assigned in an error path now so just return 0 directly.
Fixes: 4ba0b2c294 ("fpga: mgr: Use standard dev_release for class driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1517
Reviewed-by: Russ Weight <russell.h.weight@intel.com>
Reviewed-by: Tom Rix <trix@redhat.com>
Acked-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Calling scsi_remove_host() before scsi_add_host() results in a crash:
BUG: kernel NULL pointer dereference, address: 0000000000000108
RIP: 0010:device_del+0x63/0x440
Call Trace:
device_unregister+0x17/0x60
scsi_remove_host+0xee/0x2a0
pm8001_pci_probe+0x6ef/0x1b90 [pm80xx]
local_pci_probe+0x3f/0x90
We cannot call scsi_remove_host() in pm8001_alloc() because scsi_add_host()
has not been called yet at that point in time.
Function call tree:
pm8001_pci_probe()
|
`- pm8001_pci_alloc()
| |
| `- pm8001_alloc()
| |
| `- scsi_remove_host()
|
`- scsi_add_host()
Link: https://lore.kernel.org/r/20211201041627.1592487-1-ipylypiv@google.com
Fixes: 05c6c029a4 ("scsi: pm80xx: Increase number of supported queues")
Reviewed-by: Vishakha Channapattan <vishakhavc@google.com>
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently rp_filter tests in fib_tests.sh:fib_rp_filter_test() are
failing. ping sockets are bound to dummy1 using the "-I" option
(SO_BINDTODEVICE), but socket lookup is failing when receiving ping
replies, since the routing table thinks they belong to dummy0.
For example, suppose ping is using a SOCK_RAW socket for ICMP messages.
When receiving ping replies, in __raw_v4_lookup(), sk->sk_bound_dev_if
is 3 (dummy1), but dif (skb_rtable(skb)->rt_iif) says 2 (dummy0), so the
raw_sk_bound_dev_eq() check fails. Similar things happen in
ping_lookup() for SOCK_DGRAM sockets.
These tests used to pass due to a bug [1] in iputils, where "ping -I"
actually did not bind ICMP message sockets to device. The bug has been
fixed by iputils commit f455fee41c07 ("ping: also bind the ICMP socket
to the specific device") in 2016, which is why our rp_filter tests
started to fail. See [2] .
Fixing the tests while keeping everything in one netns turns out to be
nontrivial. Rework the tests and build the following topology:
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ network namespace 1 (ns1) │ │ network namespace 2 (ns2) │
│ │ │ │
│ ┌────┐ ┌─────┐ │ │ ┌─────┐ ┌────┐ │
│ │ lo │<───>│veth1│<────────┼────┼─>│veth2│<──────────>│ lo │ │
│ └────┘ ├─────┴──────┐ │ │ ├─────┴──────┐ └────┘ │
│ │192.0.2.1/24│ │ │ │192.0.2.1/24│ │
│ └────────────┘ │ │ └────────────┘ │
└─────────────────────────────┘ └─────────────────────────────┘
Consider sending an ICMP_ECHO packet A in ns2. Both source and
destination IP addresses are 192.0.2.1, and we use strict mode rp_filter
in both ns1 and ns2:
1. A is routed to lo since its destination IP address is one of ns2's
local addresses (veth2);
2. A is redirected from lo's egress to veth2's egress using mirred;
3. A arrives at veth1's ingress in ns1;
4. A is redirected from veth1's ingress to lo's ingress, again, using
mirred;
5. In __fib_validate_source(), fib_info_nh_uses_dev() returns false,
since A was received on lo, but reverse path lookup says veth1;
6. However A is not dropped since we have relaxed this check for lo in
commit 66f8209547 ("fib: relax source validation check for loopback
packets");
Making sure A is not dropped here in this corner case is the whole point
of having this test.
7. As A reaches the ICMP layer, an ICMP_ECHOREPLY packet, B, is
generated;
8. Similarly, B is redirected from lo's egress to veth1's egress (in
ns1), then redirected once again from veth2's ingress to lo's
ingress (in ns2), using mirred.
Also test "ping 127.0.0.1" from ns2. It does not trigger the relaxed
check in __fib_validate_source(), but just to make sure the topology
works with loopback addresses.
Tested with ping from iputils 20210722-41-gf9fb573:
$ ./fib_tests.sh -t rp_filter
IPv4 rp_filter tests
TEST: rp_filter passes local packets [ OK ]
TEST: rp_filter passes loopback packets [ OK ]
[1] https://github.com/iputils/iputils/issues/55
[2] f455fee41c
Reported-by: Hangbin Liu <liuhangbin@gmail.com>
Fixes: adb701d6cf ("selftests: add a test case for rp_filter")
Reviewed-by: Cong Wang <cong.wang@bytedance.com>
Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
Acked-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20211201004720.6357-1-yepeilin.cs@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace builtin_platform_driver_probe with module_platform_driver_probe
because CONFIG_CLK_IMX8QXP can be set to =m (kernel module).
Fixes: e0d0d4d86c ("clk: imx8qxp: Support building i.MX8QXP clock driver as module")
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/20210904235418.2442-1-miles.chen@mediatek.com
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
In the event that the bootloader has configured the Trion PLL as source
for the display clocks, e.g. for the continuous splashscreen, then there
will also be RCGs that are clocked by this instance.
Reconfiguring, and in particular disabling the output of, the PLL will
cause issues for these downstream RCGs and has been shown to prevent
them from being re-parented.
Follow downstream and skip configuration if it's determined that the PLL
is already running.
Fixes: 59128c20a6 ("clk: qcom: clk-alpha-pll: Add support for controlling Lucid PLLs")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20211123162508.153711-1-bjorn.andersson@linaro.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The function mux_get_parent() uses qcom_find_src_index() to find the
parent clock index, which is incorrect: qcom_find_src_index() uses src
enum for the lookup, while mux_get_parent() should use cfg field (which
corresponds to the register value). Add qcom_find_cfg_index() function
doing this kind of lookup and use it for mux parent lookup.
Fixes: df96401649 ("clk: qcom: add parent map for regmap mux")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211115233407.1046179-1-dmitry.baryshkov@linaro.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
drm fixes for 5.16-rc4
dma-buf:
- memory leak fix
msm:
- kasan found memory overwrite
- mmap flags
- fencing error bug
- ioctl NULL ptr
- uninit var
- devfreqless devices fix
- dsi lanes fix
- dp: avoid unpowered aux xfers
amdgpu:
- IP discovery based enumeration fixes
- vkms fixes
- DSC fixes for DP MST
- Audio fix for hotplug with tiled displays
- Misc display fixes
- DP tunneling fix
- DP fix
- Aldebaran fix
amdkfd:
- Locking fix
- Static checker fix
- Fix double free
i915:
- backlight regression
- Intel HDR backlight detection fix
- revert TGL workaround that caused hangs
virtio-gpu:
- switch back to drm_poll
vc4:
- memory leak
- error check fix
- HVS modesetting fixes
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmGpOTQACgkQDHTzWXnE
hr6IcQ/9ER8UJPyOFEbbBkTOxTShkv2O4eMoP4nuReepAnoTTbNbrs+IvSesUgwb
xbD22mytTmsxoPGDgK9X2W1JvyoHmsNjnNcy0eBF/34MU2AeRDJg8KqtwY3oIOaY
do0q2VptW2Zujy5lKJJV6lukjO6W4JhgLWq3KlS/P7wyVbe5nRcBbOo2sFJ1WS2l
AKtkJqzquAoDzhChN5TnNTey06WsXGION8yDD/cyxBBzvL0C5vUw8q+AKNvM5sm6
spHxj1Kz9wu2pMeZC/6wxzJnf/Go2im1Bal7wcrBaSZcFXVyH5Llp24TWlqj5PQL
oEDhlUym5AwEMvlldAE6jwDPLt71tFnSpLQwKcrgPQbRMeXTrnP2Y7mJPYfWZiiY
UHwlYXURJtq6BAEn00W+SZ1TeTjkODWl5/m+Ci4+u4h//Mbk0fdU7w1JZPzEHaOy
dqmmxXhqgUbCgi6lrCTcLrZcZFCHq9GdZkyK76QrYAQTB5Tz/txl2d3TWFZ2N+fW
uZbwNvjDhi1wubmJcwSUIItbjZTdIsIQ845EbevoTw9FIanLfA+XQhafYYGwUyMb
i7ZO6pqYiH2/OZDguQJDmvGLdd0VwS9QyMBj/meFA9FZFujV0Vrzoz6Vj6a13Gcv
q+/YL1FzPhMKs3g1P1quFHqhyvp+aZV/+2NalGWdBAGfcN1TIr8=
=xcZd
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2021-12-03-1' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Bit of an uptick in patch count this week, though it's all relatively
small overall.
I suspect msm has been queuing up a few fixes to skew it here.
Otherwise amdgpu has a scattered bunch of small fixes, and then some
vc4, i915.
virtio-gpu changes an rc1 introduced uAPI mistake, and makes it
operate more like other drivers. This should be fine as no userspace
relies on the behaviour yet.
Summary:
dma-buf:
- memory leak fix
msm:
- kasan found memory overwrite
- mmap flags
- fencing error bug
- ioctl NULL ptr
- uninit var
- devfreqless devices fix
- dsi lanes fix
- dp: avoid unpowered aux xfers
amdgpu:
- IP discovery based enumeration fixes
- vkms fixes
- DSC fixes for DP MST
- Audio fix for hotplug with tiled displays
- Misc display fixes
- DP tunneling fix
- DP fix
- Aldebaran fix
amdkfd:
- Locking fix
- Static checker fix
- Fix double free
i915:
- backlight regression
- Intel HDR backlight detection fix
- revert TGL workaround that caused hangs
virtio-gpu:
- switch back to drm_poll
vc4:
- memory leak
- error check fix
- HVS modesetting fixes"
* tag 'drm-fixes-2021-12-03-1' of git://anongit.freedesktop.org/drm/drm: (41 commits)
Revert "drm/i915: Implement Wa_1508744258"
drm/amdkfd: process_info lock not needed for svm
drm/amdgpu: adjust the kfd reset sequence in reset sriov function
drm/amd/display: add connector type check for CRC source set
drm/amdkfd: fix double free mem structure
drm/amdkfd: set "r = 0" explicitly before goto
drm/amd/display: Add work around for tunneled MST.
drm/amd/display: Fix for the no Audio bug with Tiled Displays
drm/amd/display: Clear DPCD lane settings after repeater training
drm/amd/display: Allow DSC on supported MST branch devices
drm/amdgpu: Don't halt RLC on GFX suspend
drm/amdgpu: fix the missed handling for SDMA2 and SDMA3
drm/amdgpu: check atomic flag to differeniate with legacy path
drm/amdgpu: cancel the correct hrtimer on exit
drm/amdgpu/sriov/vcn: add new vcn ip revision check case for SIENNA_CICHLID
drm/i915/dp: Perform 30ms delay after source OUI write
dma-buf: system_heap: Use 'for_each_sgtable_sg' in pages free flow
drm/i915: Add support for panels with VESA backlights with PWM enable/disable
drm/vc4: kms: Fix previous HVS commit wait
drm/vc4: kms: Don't duplicate pending commit
...
