aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-10-17Merge tag 'block-5.15-2021-10-17' of git://git.kernel.dk/linux-blockLinus Torvalds5-35/+38
Pull block fixes from Jens Axboe: "Bigger than usual for this point in time, the majority is fixing some issues around BDI lifetimes with the move from the request_queue to the disk in this release. In detail: - Series on draining fs IO for del_gendisk() (Christoph) - NVMe pull request via Christoph: - fix the abort command id (Keith Busch) - nvme: fix per-namespace chardev deletion (Adam Manzanares) - brd locking scope fix (Tetsuo) - BFQ fix (Paolo)" * tag 'block-5.15-2021-10-17' of git://git.kernel.dk/linux-block: block, bfq: reset last_bfqq_created on group change block: warn when putting the final reference on a registered disk brd: reduce the brd_devices_mutex scope kyber: avoid q->disk dereferences in trace points block: keep q_usage_counter in atomic mode after del_gendisk block: drain file system I/O on del_gendisk block: split bio_queue_enter from blk_queue_enter block: factor out a blk_try_enter_queue helper block: call submit_bio_checks under q_usage_counter nvme: fix per-namespace chardev deletion block/rnbd-clt-sysfs: fix a couple uninitialized variable bugs nvme-pci: Fix abort command id
2021-10-17Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds3-36/+22
Pull virtio fixes from Michael Tsirkin: "Fixes up some issues in rc5" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vhost-vdpa: Fix the wrong input in config_cb VDUSE: fix documentation underline warning Revert "virtio-blk: Add validation for block size in config space" vhost_vdpa: unset vq irq before freeing irq virtio: write back F_VERSION_1 before validate
2021-10-18dmaengine: Remove redundant initialization of variable errColin Ian King1-2/+1
The variable err is being initialized with a value that is never read, it is being updated later on. The assignment is redundant and can be removed and move the declaration into the local scope. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20211015123447.27560-1-colin.king@canonical.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-10-18dmaengine: tegra210-adma: Override ADMA FIFO sizeSameer Pujar1-14/+34
ADMAIF FIFO uses a ring buffer and it is divided amongst the available channels. The default FIFO size (in multiples of 16 words) of ADMAIF TX/RX channels is as below: * On Tegra210, channel 1 to 2 : size = 3 channel 3 to 10: size = 2 * On Tegra186 and later, channel 1 to 4 : size = 3 channel 5 to 20: size = 2 As per recommendation from HW, FIFO size of ADMA channel should be same as the corresponding ADMAIF channel it maps to. FIFO corruption is observed if the sizes do not match. We are using the default FIFO sizes for ADMAIF and there is no plan to support any custom values. Thus at runtime, override the ADMA channel FIFO size value depending on the corresponding ADMAIF channel. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/1631722025-19873-4-git-send-email-spujar@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-10-18dmaengine: tegra210-adma: Add description for 'adma_get_burst_config'Sameer Pujar1-0/+1
Trivial change to add description for 'adma_get_burst_config' in chip data structure. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/1631722025-19873-3-git-send-email-spujar@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-10-18dmaengine: tegra210-adma: Re-order 'has_outstanding_reqs' memberSameer Pujar1-3/+3
The 'has_outstanding_reqs' member description order in structure 'tegra_adma_chip_data' does not match with the corresponding member declaration. The same is true for member assignment in chip data structures declared for Tegra210 and Tegra186. This is a trivial fix to re-order the mentioned member for a better readability. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/1631722025-19873-2-git-send-email-spujar@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-10-17Merge tag 'edac_urgent_for_v5.15_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/rasLinus Torvalds1-1/+1
Pull EDAC fix from Borislav Petkov: - Log the "correct" uncorrectable error count in the armada_xp driver * tag 'edac_urgent_for_v5.15_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/armada-xp: Fix output of uncorrectable error counter
2021-10-17Merge tag 'efi-urgent-for-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds3-4/+4
Pull EFI fixes from Borislav Petkov: "Forwarded from Ard Biesheuvel through the tip tree. Ard will send stuff directly in the near future. Low priority fixes but fixes nonetheless: - update stub diagnostic print that is no longer accurate - avoid statically allocated buffer for CPER error record decoding - avoid sleeping on the efi_runtime semaphore when calling the ResetSystem EFI runtime service" * tag 'efi-urgent-for-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock() efi/cper: use stack buffer for error record decoding efi/libstub: Simplify "Exiting bootservices" message
2021-10-17Merge tag 'driver-core-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-coreLinus Torvalds5-18/+42
Pull driver core fixes from Greg KH: "Here are some small driver core fixes for 5.15-rc6, all of which have been in linux-next for a while with no reported issues. They include: - kernfs negative dentry bugfix - simple pm bus fixes to resolve reported issues" * tag 'driver-core-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: drivers: bus: Delete CONFIG_SIMPLE_PM_BUS drivers: bus: simple-pm-bus: Add support for probing simple bus only devices driver core: Reject pointless SYNC_STATE_ONLY device links kernfs: don't create a negative dentry if inactive node exists
2021-10-17Merge tag 'char-misc-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds12-20/+69
Pull char/misc driver fixes from Greg KH: "Here are some small char/misc driver fixes for 5.15-rc6 for reported issues that include: - habanalabs driver fixes - mei driver fixes and new ids - fpga new device ids - MAINTAINER file updates for fpga subsystem - spi module id table additions and fixes - fastrpc locking fixes - nvmem driver fix All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: eeprom: 93xx46: fix MODULE_DEVICE_TABLE nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells mei: hbm: drop hbm responses on early shutdown mei: me: add Ice Lake-N device id. eeprom: 93xx46: Add SPI device ID table eeprom: at25: Add SPI ID table misc: HI6421V600_IRQ should depend on HAS_IOMEM misc: fastrpc: Add missing lock before accessing find_vma() cb710: avoid NULL pointer subtraction misc: gehc: Add SPI ID table MAINTAINERS: Drop outdated FPGA Manager website MAINTAINERS: Add Hao and Yilun as maintainers habanalabs: fix resetting args in wait for CS IOCTL fpga: ice40-spi: Add SPI device ID table
2021-10-17Merge tag 'staging-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds16-18/+52
Pull staging and IIO driver fixes from Greg KH: "Here are a number of small IIO and staging driver fixes for 5.15-rc6. They include: - vc04_services bugfix for reported problem - r8188eu array underflow fix - iio driver fixes for a lot of tiny reported issues. All of these have been in linux-next for a while with no reported issues" * tag 'staging-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: r8188eu: prevent array underflow in rtw_hal_update_ra_mask() staging: vc04_services: shut up out-of-range warning iio: light: opt3001: Fixed timeout error when 0 lux iio: adis16480: fix devices that do not support sleep mode iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED iio: adis16475: fix deadlock on frequency set iio: ssp_sensors: add more range checking in ssp_parse_dataframe() iio: ssp_sensors: fix error code in ssp_print_mcu_debug() iio: adc: ad7793: Fix IRQ flag iio: adc: ad7780: Fix IRQ flag iio: adc: ad7192: Add IRQ flag iio: adc: aspeed: set driver data when adc probe. iio: adc: rzg2l_adc: add missing clk_disable_unprepare() in rzg2l_adc_pm_runtime_resume() iio: adc: max1027: Fix the number of max1X31 channels iio: adc: max1027: Fix wrong shift with 12-bit devices iio: adc128s052: Fix the error handling path of 'adc128_probe()' iio: adc: rzg2l_adc: Fix -EBUSY timeout error return iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushed iio: dac: ti-dac5571: fix an error code in probe()
2021-10-17Merge tag 'tty-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds1-2/+6
Pull serial driver fix from Greg KH: "Here is a single 8250 Kconfig fix for 5.15-rc6 that resolves a regression that showed up in 5.15-rc1. It has been in linux-next for a while with no reported issues" * tag 'tty-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: serial: 8250: allow disabling of Freescale 16550 compile test
2021-10-17Merge tag 'usb-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds8-22/+70
Pull USB fixes from Greg KH: "Here are some small USB fixes that resolve a number of tiny issues. They include: - new USB serial driver ids - xhci driver fixes for a bunch of issues - musb error path fixes. All of these have been in linux-next for a while with no reported issues" * tag 'usb-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: musb: dsps: Fix the probe error path xhci: Enable trust tx length quirk for Fresco FL11 USB controller xhci: Fix command ring pointer corruption while aborting a command USB: xhci: dbc: fix tty registration race xhci: add quirk for host controllers that don't update endpoint DCS xhci: guard accesses to ep_state in xhci_endpoint_reset() USB: serial: qcserial: add EM9191 QDL support USB: serial: option: add Quectel EC200S-CN module support USB: serial: option: add prod. id for Quectel EG91 USB: serial: option: add Telit LE910Cx composition 0x1204
2021-10-17Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds4-34/+68
Pull input fixes from Dmitry Torokhov: - a new product ID for the xpad joystick driver - fixes to resistive-adc-touch and snvs_pwrkey drivers - a change to touchscreen helpers to make clang happier * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: touchscreen - avoid bitwise vs logical OR warning Input: xpad - add support for another USB ID of Nacon GC-100 Input: resistive-adc-touch - fix division by zero error on z1 == 0 Input: snvs_pwrkey - add clk handling
2021-10-17drm/rockchip: dsi: Disable PLL clock on bind errorBrian Norris1-3/+5
Fix some error handling here noticed in review of other changes. Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver") Signed-off-by: Brian Norris <briannorris@chromium.org> Reported-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210928143413.v3.4.I8bb7a91ecc411d56bc155763faa15f289d7fc074@changeid
2021-10-17drm/rockchip: dsi: Fix unbalanced clock on probe errorBrian Norris1-5/+1
Our probe() function never enabled this clock, so we shouldn't disable it if we fail to probe the bridge. Noted by inspection. Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver") Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210928143413.v3.3.Ie8ceefb51ab6065a1151869b6fcda41a467d4d2c@changeid
2021-10-17drm/rockchip: dsi: Reconfigure hardware on resume()Brian Norris1-0/+37
Since commit 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()"), we perform most HW configuration in the bind() function. This configuration may be lost on suspend/resume, so we need to call it again. That may lead to errors like this after system suspend/resume: dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO panel-kingdisplay-kd097d04 ff960000.mipi.0: failed write init cmds: -110 Tested on Acer Chromebook Tab 10 (RK3399 Gru-Scarlet). Note that early mailing list versions of this driver borrowed Rockchip's downstream/BSP solution, to do HW configuration in mode_set() (which *is* called at the appropriate pre-enable() times), but that was discarded along the way. I've avoided that still, because mode_set() documentation doesn't suggest this kind of purpose as far as I can tell. Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210928143413.v3.2.I4e9d93aadb00b1ffc7d506e3186a25492bf0b732@changeid
2021-10-17drm/rockchip: dsi: Hold pm-runtime across bind/unbindBrian Norris1-18/+19
In commit 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()"), we moved most HW configuration to bind(), but we didn't move the runtime PM management. Therefore, depending on initial boot state, runtime-PM workqueue delays, and other timing factors, we may disable our power domain in between the hardware configuration (bind()) and when we enable the display. This can cause us to lose hardware state and fail to configure our display. For example: dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO panel-innolux-p079zca ff960000.mipi.0: failed to write command 0 or: dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO panel-kingdisplay-kd097d04 ff960000.mipi.0: failed write init cmds: -110 We should match the runtime PM to the lifetime of the bind()/unbind() cycle. Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers built either as modules or built-in. Side notes: it seems one is more likely to see this problem when the panel driver is built into the kernel. I've also seen this problem bisect down to commits that simply changed Kconfig dependencies, because it changed the order in which driver init functions were compiled into the kernel, and therefore the ordering and timing of built-in device probe. Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux to bind()") Link: https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.camel@gmail.com/ Reported-by: <aleksandr.o.makarov@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210928143413.v3.1.Ic2904d37f30013a7f3d8476203ad3733c186827e@changeid
2021-10-17drm/rockchip: vop: Add timeout for DSP holdBrian Norris1-1/+3
If hardware is malfunctioning (e.g., misconfigured clocks?), we can get stuck here forever, holding various DRM locks and eventually locking up the entire system. It's better to complain loudly and move on, than to lock up the system. In local tests, this operation takes less than 20ms. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211008153102.1.I2a5dbaaada35023a9703a8db7af501528fbb6e31@changeid
2021-10-17pinctrl: qcom: spmi-mpp: add support for hierarchical IRQ chipDmitry Baryshkov1-17/+69
spmi-mpp did not have any irqchip support so consumers of this in device tree would need to call gpio[d]_to_irq() in order to get the proper IRQ on the underlying PMIC. IRQ chips in device tree should be usable from the start without the consumer having to make an additional call to get the proper IRQ on the parent. This patch adds hierarchical IRQ chip support to the spmi-mpp code to correct this issue. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211008012524.481877-17-dmitry.baryshkov@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-10-17pinctrl: qcom: spmi-mpp: hardcode IRQ countsDmitry Baryshkov1-15/+10
The probing of this driver calls platform_irq_count, which will setup all of the IRQs that are configured in device tree. In preparation for converting this driver to be a hierarchical IRQ chip, hardcode the IRQ count based on the hardware type so that all the IRQs are not configured immediately and are configured on an as-needed basis later in the boot process. This change will also allow for the removal of the interrupts property later in this patch series once the hierarchical IRQ chip support is in. This patch also removes the generic qcom,spmi-mpp OF match since we don't know the number of pins. All of the existing upstream bindings already include the more-specific binding. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211008012524.481877-16-dmitry.baryshkov@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-10-17pinctrl: qcom: ssbi-mpp: add support for hierarchical IRQ chipDmitry Baryshkov1-18/+93
ssbi-mpp did not have any irqchip support so consumers of this in device tree would need to call gpio[d]_to_irq() in order to get the proper IRQ on the underlying PMIC. IRQ chips in device tree should be usable from the start without the consumer having to make an additional call to get the proper IRQ on the parent. This patch adds hierarchical IRQ chip support to the ssbi-mpp code to correct this issue. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211008012524.481877-15-dmitry.baryshkov@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-10-17pinctrl: qcom: ssbi-mpp: hardcode IRQ countsDmitry Baryshkov1-14/+8
The probing of this driver calls platform_irq_count, which will setup all of the IRQs that are configured in device tree. In preparation for converting this driver to be a hierarchical IRQ chip, hardcode the IRQ count based on the hardware type so that all the IRQs are not configured immediately and are configured on an as-needed basis later in the boot process. This change will also allow for the removal of the interrupts property later in this patch series once the hierarchical IRQ chip support is in. This patch also removes the generic qcom,ssbi-mpp OF match since we don't know the number of pins. All of the existing upstream bindings already include the more-specific binding. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211008012524.481877-14-dmitry.baryshkov@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-10-17pinctrl: samsung: support ExynosAutov9 SoC pinctrlChanho Park3-0/+111
Add pinctrl data for ExynosAuto v9 SoC. - GPA0, GPA1: 10, External wake up interrupt - GPQ0: 2, XbootLDO, Speedy PMIC I/F - GPB0, GPB1, GPB2, GPB3: 29, I2S 7 CH - GPF0, GPF1, GPF2, GPF3,GPF4, GPF5, GPF6, GPF8: 52, FSYS - GPG0, GPG1, GPG2, GPG3: 25, GPIO x 24, SMPL_INT - GPP0, GPP1, GPP2, GPP3, GPP4, GPP5: 48, USI 12 CH Signed-off-by: Chanho Park <chanho61.park@samsung.com> Link: https://lore.kernel.org/r/20211008091443.44625-2-chanho61.park@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211017171912.5044-1-krzysztof.kozlowski@canonical.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-10-17can: peak_usb: pcan_usb_fd_decode_status(): remove unnecessary test on the nullity of a pointerStephane Grosjean1-2/+1
Since alloc_can_err_skb() puts NULL in cf in the case when skb cannot be allocated and can_change_state() handles the case when cf is NULL, the test on the nullity of skb is now unnecessary. Link: https://lore.kernel.org/all/20210929142111.55757-2-s.grosjean@peak-system.com Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-10-17can: peak_usb: pcan_usb_fd_decode_status(): fix back to ERROR_ACTIVE state notificationStephane Grosjean1-3/+2
This corrects the lack of notification of a return to ERROR_ACTIVE state for USB - CANFD devices from PEAK-System. Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters") Link: https://lore.kernel.org/all/20210929142111.55757-1-s.grosjean@peak-system.com Cc: stable@vger.kernel.org Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-10-17can: peak_pci: peak_pci_remove(): fix UAFZheyu Ma1-5/+4
When remove the module peek_pci, referencing 'chan' again after releasing 'dev' will cause UAF. Fix this by releasing 'dev' later. The following log reveals it: [ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537 [ 35.965513 ] Call Trace: [ 35.965718 ] dump_stack_lvl+0xa8/0xd1 [ 35.966028 ] print_address_description+0x87/0x3b0 [ 35.966420 ] kasan_report+0x172/0x1c0 [ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170 [ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20 [ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.968752 ] pci_device_remove+0xa9/0x250 Fixes: e6d9c80b7ca1 ("can: peak_pci: add support of some new PEAK-System PCI cards") Link: https://lore.kernel.org/all/1634192913-15639-1-git-send-email-zheyuma97@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-10-17can: m_can: fix iomap_read_fifo() and iomap_write_fifo()Aswath Govindraju1-2/+12
The read and writes from the fifo are from a buffer, with various fields and data at predefined offsets. So, they should not be done to the same address(or port) in case of val_count greater than 1. Therefore, fix this by using iowrite32()/ioread32() instead of ioread32_rep()/iowrite32_rep(). Also, the write into FIFO must be performed with an offset from the message ram base address. Therefore, fix the base address to mram_base. Fixes: e39381770ec9 ("can: m_can: Disable IRQs on FIFO bus errors") Link: https://lore.kernel.org/all/20210920123344.2320-1-a-govindraju@ti.com Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-10-17can: rcar_can: fix suspend/resumeYoshihiro Shimoda1-8/+12
If the driver was not opened, rcar_can_suspend() should not call clk_disable() because the clock was not enabled. Fixes: fd1159318e55 ("can: add Renesas R-Car CAN driver") Link: https://lore.kernel.org/all/20210924075556.223685-1-yoshihiro.shimoda.uh@renesas.com Cc: stable@vger.kernel.org Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Ayumi Nakamichi <ayumi.nakamichi.kf@renesas.com> Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-10-17drm/v3d: nullify pointer se with a NULLYang Li1-2/+2
Currently a plain integer is being used to nullify the pointer struct v3d_submit_ext *se. Use NULL instead. Cleans up sparse warnings: drivers/gpu/drm/v3d/v3d_gem.c:777:53: warning: Using plain integer as NULL pointer drivers/gpu/drm/v3d/v3d_gem.c:1010:45: warning: Using plain integer as NULL pointer Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/1634282081-72255-1-git-send-email-yang.lee@linux.alibaba.com
2021-10-17clocksource/drivers/arm_arch_timer: Remove any trace of the TVAL programming interfaceMarc Zyngier1-8/+0
TVAL usage is now long gone, get rid of the leftovers. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-11-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-17clocksource/drivers/arm_arch_timer: Work around broken CVAL implementationsMarc Zyngier1-1/+27
The Applied Micro XGene-1 SoC has a busted implementation of the CVAL register: it looks like it is based on TVAL instead of the other way around. The net effect of this implementation blunder is that the maximum deadline you can program in the timer is 32bit wide. Use a MIDR check to notice the broken CPU, and reduce the width of the timer to 32bit. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-10-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-17clocksource/drivers/arm_arch_timer: Advertise 56bit timer to the core codeMarc Zyngier1-1/+1
Proudly tell the code code that we have a timer able to handle 56 bits deltas. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-9-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-17clocksource/drivers/arm_arch_timer: Move MMIO timer programming over to CVALMarc Zyngier1-12/+38
Similarily to the sysreg-based timer, move the MMIO over to using the CVAL registers instead of TVAL. Note that there is no warranty that the 64bit MMIO access will be atomic, but the timer is always disabled at the point where we program CVAL. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-8-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-17clocksource/drivers/arm_arch_timer: Fix MMIO base address vs callback ordering issueMarc Zyngier1-14/+13
The MMIO timer base address gets published after we have registered the callbacks and the interrupt handler, which is... a bit dangerous. Fix this by moving the base address publication to the point where we register the timer, and expose a pointer to the timer structure itself rather than a naked value. Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-7-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-17clocksource/drivers/arm_arch_timer: Move drop _tval from erratum function namesMarc Zyngier1-13/+13
The '_tval' name in the erratum handling function names doesn't make much sense anymore (and they were using CVAL the first place). Drop the _tval tag. Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-6-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-17clocksource/drivers/arm_arch_timer: Move system register timer programming over to CVALMarc Zyngier1-3/+23
In order to cope better with high frequency counters, move the programming of the timers from the countdown timer (TVAL) over to the comparator (CVAL). The programming model is slightly different, as we now need to read the current counter value to have an absolute deadline instead of a relative one. There is a small overhead to this change, which we will address in the following patches. Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-5-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-17clocksource/drivers/arm_arch_timer: Extend write side of timer register accessors to u64Marc Zyngier1-5/+5
The various accessors for the timer sysreg and MMIO registers are currently hardwired to 32bit. However, we are about to introduce the use of the CVAL registers, which require a 64bit access. Upgrade the write side of the accessors to take a 64bit value (the read side is left untouched as we don't plan to ever read back any of these registers). No functional change expected. Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-4-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-17clocksource/drivers/arm_arch_timer: Drop CNT*_TVAL read accessorsMarc Zyngier1-44/+0
The arch timer driver never reads the various TVAL registers, only writes to them. It is thus pointless to provide accessors for them and to implement errata workarounds. Drop these read-side accessors, and add a couple of BUG() statements for the time being. These statements will be removed further down the line. Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-3-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-17clocksource/arm_arch_timer: Add build-time guards for unhandled register accessesMarc Zyngier1-0/+8
As we are about to change the registers that are used by the driver, start by adding build-time checks to ensure that we always handle all registers and access modes. Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-2-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-17drm/panel: Add Sony Tulip Truly NT35521 driverShawn Guo3-0/+563
It adds a DRM panel driver for Sony Tulip Truly NT35521 5.24" 1280x720 DSI panel, which can be found on Sony Xperia M4 Aqua phone. The panel backlight is managed through DSI link. The driver is built using linux-mdss-dsi-panel-driver-generator[1], and additionally modeling the 5V control GPIOs with regulators and adding Backlight GPIO support. [1] https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210809051008.6172-3-shawn.guo@linaro.org
2021-10-17rtc: s3c: remove HAVE_S3C_RTC in favor of direct dependenciesWill McVicker1-8/+2
The config HAVE_S3C_RTC is not really needed since we can simply just add the dependencies directly to RTC_DRV_S3C. Also, one less config to keep track of! Signed-off-by: Will McVicker <willmcvicker@google.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211013212256.3425889-1-willmcvicker@google.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-10-17drm/panel: Add BOE BF060Y8M-AJ0 5.99" AMOLED panel driverAngeloGioacchino Del Regno3-0/+457
This adds support for the BOE BF060Y8M-AJ0 5.99" AMOLED module that can be found in some F(x)Tec Pro1 and Elephone U1 devices. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210901173115.998628-1-angelogioacchino.delregno@somainline.org
2021-10-17drm/panel: Add driver for Novatek NT35950 DSI DriverIC panelsAngeloGioacchino Del Regno3-0/+714
Add a driver for panels using the Novatek NT35950 Display Driver IC, including support for the Sharp LS055D1SX04, found in some Sony Xperia Z5 Premium and XZ Premium smartphones. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210901173127.998901-1-angelogioacchino.delregno@somainline.org
2021-10-17drm/bridge: ti-sn65dsi83: Optimize reset line togglingMarek Vasut1-29/+11
Current code always sets reset line low in .pre_enable callback and holds it low for 10ms. This is sub-optimal and increases the time between enablement of the DSI83 and valid LVDS clock. Rework the reset handling such that the reset line is held low for 10ms both in probe() of the driver and .disable callback, which guarantees that the reset line was always held low for more than 10ms and therefore the reset line timing requirement is satisfied. Furthermore, move the reset handling into .enable callback so the entire DSI83 initialization is now in one place. This reduces DSI83 enablement delay by up to 10ms. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211016210402.171595-1-marex@denx.de
2021-10-17soc: qcom: smp2p: add feature negotiation and ssr ack feature supportChris Lew1-25/+96
This patch adds feature negotiation and ssr ack feature between local host and remote processor. Local host can negotiate on common features supported with remote processor. When ssr ack feature bit is set, the remote processor will tell local host when it is reinitialized. All clients registered for falling edge interrupts will be notified when the smp2p entries are cleared for ssr. Signed-off-by: Chris Lew <clew@codeaurora.org> Signed-off-by: Deepak Kumar Singh <deesin@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1633450403-21281-1-git-send-email-deesin@codeaurora.org
2021-10-17iio: adc: tsc2046: fix scan interval warningOleksij Rempel1-1/+1
Sync if statement with the actual warning. Fixes: 9504db5765e8 ("iio: adc: tsc2046: fix a warning message in tsc2046_adc_update_scan_mode()") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20211007093007.1466-2-o.rempel@pengutronix.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: core: fix double free in iio_device_unregister_sysfs()Yang Yingliang1-0/+1
I got the double free report: BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390 iio_device_unregister_sysfs+0x108/0x13b [industrialio] iio_dev_release+0x9e/0x10e [industrialio] device_release+0xa5/0x240 If __iio_device_register() fails, iio_dev_opaque->groups will be freed in error path in iio_device_unregister_sysfs(), then iio_dev_release() will call iio_device_unregister_sysfs() again, it causes double free. Set iio_dev_opaque->groups to NULL when it's freed to fix this double free. Not this is a local work around for a more general mess around life time management that will get cleaned up and should make this handling unnecesarry. Fixes: 32f171724e5c ("iio: core: rework iio device group creation") Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013030532.956133-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: core: check return value when calling dev_set_name()Yang Yingliang1-1/+7
I got a null-ptr-deref report when doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strlen+0x0/0x20 Call Trace: start_creating+0x199/0x2f0 debugfs_create_dir+0x25/0x430 __iio_device_register+0x4da/0x1b40 [industrialio] __devm_iio_device_register+0x22/0x80 [industrialio] max1027_probe+0x639/0x860 [max1027] spi_probe+0x183/0x210 really_probe+0x285/0xc30 If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: e553f182d55b ("staging: iio: core: Introduce debugfs support...") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Cc: <Stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211012063624.3167460-1-yangyingliang@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-10-17iio: buffer: Fix memory leak in iio_buffer_register_legacy_sysfs_groups()Yang Yingliang1-2/+2
If the second iio_device_register_sysfs_group() fails, 'legacy_buffer_group.attrs' need be freed too or it will cause memory leak: unreferenced object 0xffff888003618280 (size 64): comm "xrun", pid 357, jiffies 4294907259 (age 22.296s) hex dump (first 32 bytes): 80 f6 8c 03 80 88 ff ff 80 fb 8c 03 80 88 ff ff ................ 00 f9 8c 03 80 88 ff ff 80 fc 8c 03 80 88 ff ff ................ backtrace: [<00000000076bfd43>] __kmalloc+0x1a3/0x2f0 [<00000000c32e4886>] iio_buffers_alloc_sysfs_and_mask+0xc31/0x1290 [industrialio] Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211013144242.1685060-1-yangyingliang@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>