summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-12-22sfc: Check null pointer of rx_queue->page_ringJiasheng Jiang
Because of the possible failure of the kcalloc, it should be better to set rx_queue->page_ptr_mask to 0 when it happens in order to maintain the consistency. Fixes: 5a6681e22c14 ("sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Link: https://lore.kernel.org/r/20211220135603.954944-1-jiasheng@iscas.ac.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-22Merge tag 'for-linus-5.16-3' of git://github.com/cminyard/linux-ipmiLinus Torvalds
Pull IPMI fixes from Corey Minyard: "Fix some IPMI crashes Some crash fixes have come in dealing with various error handling issues. They have sat in next for 5 days or more without issue, and they are fairly critical" * tag 'for-linus-5.16-3' of git://github.com/cminyard/linux-ipmi: ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module ipmi: fix initialization when workqueue allocation fails ipmi: bail out if init_srcu_struct fails ipmi: ssif: initialize ssif_info->client early
2021-12-22Merge branch 'linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix a regression in the qat driver" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: qat - do not handle PFVF sources for qat_4xxx
2021-12-22mt76: mt7921: fix a possible race enabling/disabling runtime-pmLorenzo Bianconi
Fix a possible race enabling/disabling runtime-pm between mt7921_pm_set() and mt7921_poll_rx() since mt7921_pm_wake_work() always schedules rx-napi callback and it will trigger mt7921_pm_power_save_work routine putting chip to in low-power state during mt7921_pm_set processing. Suggested-by: Deren Wu <deren.wu@mediatek.com> Tested-by: Deren Wu <deren.wu@mediatek.com> Fixes: 1d8efc741df8 ("mt76: mt7921: introduce Runtime PM support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/0f3e075a2033dc05f09dab4059e5be8cbdccc239.1640094847.git.lorenzo@kernel.org
2021-12-22wilc1000: Add reset/enable GPIO support to SPI driverDavid Mosberger-Tang
For the SDIO driver, the RESET/ENABLE pins of WILC1000 are controlled through the SDIO power sequence driver. This commit adds analogous support for the SPI driver. Specifically, during initialization, the chip will be ENABLEd and taken out of RESET and during deinitialization, the chip will be placed back into RESET and disabled (both to reduce power consumption and to ensure the WiFi radio is off). Both RESET and ENABLE GPIOs are optional. However, if the ENABLE GPIO is specified, then the RESET GPIO should normally also be specified as otherwise there is no way to ensure proper timing of the ENABLE/RESET sequence. Signed-off-by: David Mosberger-Tang <davidm@egauge.net> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211221212531.4011609-2-davidm@egauge.net
2021-12-22wilc1000: Convert static "chipid" variable to device-local variableDavid Mosberger-Tang
Move "chipid" variable into the per-driver structure so the code doesn't break if more than one wilc1000 module is present. Signed-off-by: David Mosberger-Tang <davidm@egauge.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211221210538.4011227-1-davidm@egauge.net
2021-12-22rtw89: 8852a: correct bit definition of dfs_enChung-Hsuan Hung
Since there are other protections in the set channel flow, fortunately old wrong setting won't affect the performance. Signed-off-by: Chung-Hsuan Hung <hsuan8331@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211221024800.23814-1-pkshih@realtek.com
2021-12-22rtw88: don't consider deep PS mode when transmitting packetChin-Yen Lee
In original flow, driver needs to ensure chip leave deep ps mode before transmitting any packet, and don't enter deep ps mode beofre PCIE DMA is finished. Now with the support of 8822ce's hardware setting and firmware after v9.9.11, these limits are removed. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211221020230.20764-1-pkshih@realtek.com
2021-12-22Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo
ath.git patches for v5.17. Major changes: ath11k * qca6390/wcn6855: report signal and tx bitrate * qca6390: rfkill support * qca6390/wcn6855: regdb.bin support ath5k * switch to rate table based lookup
2021-12-22ath11k: Fix unexpected return buffer manager error for QCA6390Baochen Qiang
We are seeing below error on QCA6390: ... [70211.671189] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22 [70212.696154] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22 [70213.092941] ath11k_pci 0000:72:00.0: failed to parse rx error in wbm_rel ring desc -22 ... The reason is that, with commit 734223d78428 ("ath11k: change return buffer manager for QCA6390"), ath11k expects the return buffer manager (RBM) field of descriptor configured as HAL_RX_BUF_RBM_SW1_BM when parsing error frames from WBM2SW3_RELEASE ring. This is a wrong change cause the RBM field is set as HAL_RX_BUF_RBM_SW3_BM. The same issue also applies to REO2TCL ring though we have not got any error reported. Fix it by changing RBM from HAL_RX_BUF_RBM_SW1_BM to HAL_RX_BUF_RBM_SW3_BM for these two rings. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Fixes: 734223d78428 ("ath11k: change return buffer manager for QCA6390") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211222013536.582527-1-quic_bqiang@quicinc.com
2021-12-22PM: runtime: Simplify locking in pm_runtime_put_suppliers()Rafael J. Wysocki
Notice that pm_runtime_put_suppliers() cannot be called with disabled interrupts, because it may sleep (due to the device links read locking in the non-SRCU case), and so it can use spin_lock_irq() and spin_unlock_irq() for the locking. Update the function accordingly and while at it move the "put" local variable in it into the inner block where it is used. This change is not expected to have any visible functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-12-22Merge back PM core changes for v5.17.Rafael J. Wysocki
2021-12-22cpufreq: intel_pstate: Update cpuinfo.max_freq on HWP_CAP changesRafael J. Wysocki
With HWP enabled, when the turbo range of performance levels is disabled by the platform firmware, the CPU capacity is given by the "guaranteed performance" field in MSR_HWP_CAPABILITIES which is generally dynamic. When it changes, the kernel receives an HWP notification interrupt handled by notify_hwp_interrupt(). When the "guaranteed performance" value changes in the above configuration, the CPU performance scaling needs to be adjusted so as to use the new CPU capacity in computations, which means that the cpuinfo.max_freq value needs to be updated for that CPU. Accordingly, modify intel_pstate_notify_work() to read MSR_HWP_CAPABILITIES and update cpuinfo.max_freq to reflect the new configuration (this update can be carried out even if the configuration doesn't actually change, because it simply doesn't matter then and it takes less time to update it than to do extra checks to decide whether or not a change has really occurred). Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-12-22ACPI: CPPC: Amend documentation in the commentsAndy Shevchenko
Currently it's too hard to read the _CPC structure as it's commented. Reshuffle indentation and style to make it readable. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-12-22software node: fix wrong node passed to find nargs_propClément Léger
nargs_prop refers to a property located in the reference that is found within the nargs property. Use the correct reference node in call to property_entry_read_int_array() to retrieve the correct nargs value. Fixes: b06184acf751 ("software node: Add software_node_get_reference_args()") Signed-off-by: Clément Léger <clement.leger@bootlin.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Daniel Scally <djrscally@gmail.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-12-22mtd: rawnand: gpmi: Use platform_get_irq_byname() to get the interruptLad Prabhakar
platform_get_resource_byname(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypasses the hierarchical setup and messes up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq_byname(). Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211221212609.31290-3-prabhakar.mahadev-lad.rj@bp.renesas.com
2021-12-22mtd: rawnand: omap_elm: Use platform_get_irq() to get the interruptLad Prabhakar
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypasses the hierarchical setup and messes up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq(). Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211221212609.31290-2-prabhakar.mahadev-lad.rj@bp.renesas.com
2021-12-22x86/MCE/AMD, EDAC/mce_amd: Support non-uniform MCA bank type enumerationYazen Ghannam
AMD systems currently lay out MCA bank types such that the type of bank number "i" is either the same across all CPUs or is Reserved/Read-as-Zero. For example: Bank # | CPUx | CPUy 0 LS LS 1 RAZ UMC 2 CS CS 3 SMU RAZ Future AMD systems will lay out MCA bank types such that the type of bank number "i" may be different across CPUs. For example: Bank # | CPUx | CPUy 0 LS LS 1 RAZ UMC 2 CS NBIO 3 SMU RAZ Change the structures that cache MCA bank types to be per-CPU and update smca_get_bank_type() to handle this change. Move some SMCA-specific structures to amd.c from mce.h, since they no longer need to be global. Break out the "count" for bank types from struct smca_hwid, since this should provide a per-CPU count rather than a system-wide count. Apply the "const" qualifier to the struct smca_hwid_mcatypes array. The values in this array should not change at runtime. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20211216162905.4132657-3-yazen.ghannam@amd.com
2021-12-22x86/MCE/AMD, EDAC/mce_amd: Add new SMCA bank typesYazen Ghannam
Add HWID and McaType values for new SMCA bank types, and add their error descriptions to edac_mce_amd. The "PHY" bank types all have the same error descriptions, and the NBIF and SHUB bank types have the same error descriptions. So reuse the same arrays where appropriate. [ bp: Remove useless comments over hwid types. ] Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20211216162905.4132657-2-yazen.ghannam@amd.com
2021-12-22Merge tag 'arm-soc/for-5.17/drivers' of https://github.com/Broadcom/stblinux ↵Arnd Bergmann
into arm/dt This pull request contains Broadcom SoCs drivers changes for v5.17, please pull the following changes: - Wan adds a missing of_node_put() in the power management driver for MIPS SoCs. * tag 'arm-soc/for-5.17/drivers' of https://github.com/Broadcom/stblinux: soc: bcm: brcmstb: Add of_node_put() in pm-mips Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-12-22mtd: rawnand: omap2: Select GPMC device driver for ARCH_K3Roger Quadros
The GPMC device driver is required for NAND controller to work on K3 Architecture. Select it if required. Signed-off-by: Roger Quadros <rogerq@kernel.org> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20211221131757.2030-5-rogerq@kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-12-22memory: omap-gpmc: Use a compatible match table when checking for NAND ↵Roger Quadros
controller As more compatibles can be added to the GPMC NAND controller driver use a compatible match table. Signed-off-by: Roger Quadros <rogerq@kernel.org> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20211221131757.2030-4-rogerq@kernel.org [krzysztof: remove "is_nand" variable] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-12-22gnss: usb: add support for Sierra Wireless XM1210Johan Hovold
Add support for the USB interface of the Sierra Wireless XM1210 receiver. Note that the device only supports NMEA. Bus 002 Device 003: ID 1199:b000 Sierra Wireless, Inc. Sierra Wireless_GNSS Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1199 Sierra Wireless, Inc. idProduct 0xb000 bcdDevice 0.01 iManufacturer 1 Sierra-wireless iProduct 2 Sierra Wireless_GNSS iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0020 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 50mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 0 bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 255 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 255 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered Reported-by: Marc Ferland <ferlandm@amotus.ca> Link: https://lore.kernel.org/r/20211027200223.72701-1-ferlandm@amotus.ca Link: https://lore.kernel.org/r/20211220111901.23206-3-johan@kernel.org Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Marc Ferland <ferlandm@amotus.ca> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-12-22gnss: add USB supportJohan Hovold
Add a generic driver for GNSS receivers with a USB interface with two bulk endpoints. The driver currently assumes that the device protocol is NMEA (only) but this can be generalised later as needed. Link: https://lore.kernel.org/r/20211220111901.23206-2-johan@kernel.org Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Marc Ferland <ferlandm@amotus.ca> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-12-22thunderbolt: Rename Intel TB_VSE_CAP_IECS capabilityGil Fine
Rename the VSC capability: TB_VSE_CAP_IECS to TB_VSE_CAP_CP_LP to follow the Intel devices namings as appear in the datasheet. This capability is used for controlling CLx (Low Power states of the link). Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-12-22thunderbolt: Implement TMU time disruption for Intel Titan RidgeGil Fine
Intel Titan Ridge based routers have slightly different flow for time disruption than USB4 compliant routers. This makes it work on Titan Ridge too. Needed to enable link low power states on Titan Ridge. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-12-22thunderbolt: Move usb4_switch_wait_for_bit() to switch.cGil Fine
Currently usb4_switch_wait_for_bit() used only in usb4.c Moving to switch.c to call it from other files. Also change the prefix to "tb_" to follow to the naming convention. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-12-22thunderbolt: Add CL0s support for USB4 routersGil Fine
In this patch we add enabling of CL0s - a low power state of the link. Low power states (called collectively CLx) are used to reduce transmitter and receiver power when a high-speed lane is idle. For now, we add support only for first low power state: CL0s. We enable it, if both sides of the link support it, and only for the first hop router. (i.e. the first device that connected to the host router). This is needed for better thermal management. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-12-22thunderbolt: Add TMU uni-directional modeGil Fine
Up until Titan Ridge (Thunderbolt 3) device routers only supported bi-directional mode. In this patch we add to TMU a uni-directional mode. The uni-directional mode is needed for enabling of low power state of the link (CLx). Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-12-22efi: apply memblock cap after memblock_add()Pingfan Liu
On arm64, during kdump kernel saves vmcore, it runs into the following bug: ... [ 15.148919] usercopy: Kernel memory exposure attempt detected from SLUB object 'kmem_cache_node' (offset 0, size 4096)! [ 15.159707] ------------[ cut here ]------------ [ 15.164311] kernel BUG at mm/usercopy.c:99! [ 15.168482] Internal error: Oops - BUG: 0 [#1] SMP [ 15.173261] Modules linked in: xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce sbsa_gwdt ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm drm nvme nvme_core xgene_hwmon i2c_designware_platform i2c_designware_core dm_mirror dm_region_hash dm_log dm_mod overlay squashfs zstd_decompress loop [ 15.206186] CPU: 0 PID: 542 Comm: cp Not tainted 5.16.0-rc4 #1 [ 15.212006] Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F12 (SCP: 1.5.20210426) 05/13/2021 [ 15.221125] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.228073] pc : usercopy_abort+0x9c/0xa0 [ 15.232074] lr : usercopy_abort+0x9c/0xa0 [ 15.236070] sp : ffff8000121abba0 [ 15.239371] x29: ffff8000121abbb0 x28: 0000000000003000 x27: 0000000000000000 [ 15.246494] x26: 0000000080000400 x25: 0000ffff885c7000 x24: 0000000000000000 [ 15.253617] x23: 000007ff80400000 x22: ffff07ff80401000 x21: 0000000000000001 [ 15.260739] x20: 0000000000001000 x19: ffff07ff80400000 x18: ffffffffffffffff [ 15.267861] x17: 656a626f2042554c x16: 53206d6f72662064 x15: 6574636574656420 [ 15.274983] x14: 74706d6574746120 x13: 2129363930342065 x12: 7a6973202c302074 [ 15.282105] x11: ffffc8b041d1b148 x10: 00000000ffff8000 x9 : ffffc8b04012812c [ 15.289228] x8 : 00000000ffff7fff x7 : ffffc8b041d1b148 x6 : 0000000000000000 [ 15.296349] x5 : 0000000000000000 x4 : 0000000000007fff x3 : 0000000000000000 [ 15.303471] x2 : 0000000000000000 x1 : ffff07ff8c064800 x0 : 000000000000006b [ 15.310593] Call trace: [ 15.313027] usercopy_abort+0x9c/0xa0 [ 15.316677] __check_heap_object+0xd4/0xf0 [ 15.320762] __check_object_size.part.0+0x160/0x1e0 [ 15.325628] __check_object_size+0x2c/0x40 [ 15.329711] copy_oldmem_page+0x7c/0x140 [ 15.333623] read_from_oldmem.part.0+0xfc/0x1c0 [ 15.338142] __read_vmcore.constprop.0+0x23c/0x350 [ 15.342920] read_vmcore+0x28/0x34 [ 15.346309] proc_reg_read+0xb4/0xf0 [ 15.349871] vfs_read+0xb8/0x1f0 [ 15.353088] ksys_read+0x74/0x100 [ 15.356390] __arm64_sys_read+0x28/0x34 ... This bug introduced by commit b261dba2fdb2 ("arm64: kdump: Remove custom linux,usable-memory-range handling"), which moves memblock_cap_memory_range() to fdt, but it breaches the rules that memblock_cap_memory_range() should come after memblock_add() etc as said in commit e888fa7bb882 ("memblock: Check memory add/cap ordering"). As a consequence, the virtual address set up by copy_oldmem_page() does not bail out from the test of virt_addr_valid() in check_heap_object(), and finally hits the BUG_ON(). Since memblock allocator has no idea about when the memblock is fully populated, while efi_init() is aware, so tackling this issue by calling the interface early_init_dt_check_for_usable_mem_range() exposed by of/fdt. Fixes: b261dba2fdb2 ("arm64: kdump: Remove custom linux,usable-memory-range handling") Signed-off-by: Pingfan Liu <kernelfans@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Nick Terrell <terrelln@fb.com> Cc: linux-arm-kernel@lists.infradead.org To: devicetree@vger.kernel.org To: linux-efi@vger.kernel.org Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211215021348.8766-1-kernelfans@gmail.com
2021-12-22of: fdt: Aggregate the processing of "linux,usable-memory-range"Zhen Lei
Currently, we parse the "linux,usable-memory-range" property in early_init_dt_scan_chosen(), to obtain the specified memory range of the crash kernel. We then reserve the required memory after early_init_dt_scan_memory() has identified all available physical memory. Because the two pieces of code are separated far, the readability and maintainability are reduced. So bring them together. Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> (change the prototype of early_init_dt_check_for_usable_mem_range(), in order to use it outside) Signed-off-by: Pingfan Liu <kernelfans@gmail.com> Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com> Acked-by: John Donnelly <john.p.donnelly@oracle.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org To: devicetree@vger.kernel.org To: linux-efi@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
2021-12-22driver core: platform: document registration-failure requirementJohan Hovold
Add an explicit comment to document that the reference initialised by platform_device_register() needs to be released by a call to platform_device_put() also when registration fails (cf. device_register()). Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211222104213.5673-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-22vdpa/mlx5: Use auxiliary_device driver data helpersDavid E. Box
Use auxiliary_get_drvdata and auxiliary_set_drvdata helpers. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20211221235852.323752-5-david.e.box@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-22net/mlx5e: Use auxiliary_device driver data helpersDavid E. Box
Use auxiliary_get_drvdata and auxiliary_set_drvdata helpers. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20211221235852.323752-4-david.e.box@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-22soundwire: intel: Use auxiliary_device driver data helpersDavid E. Box
Use auxiliary_get_drvdata and auxiliary_set_drvdata helpers. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20211221235852.323752-3-david.e.box@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-22RDMA/irdma: Use auxiliary_device driver data helpersDavid E. Box
Use auxiliary_get_drvdata and auxiliary_set_drvdata helpers. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20211221235852.323752-2-david.e.box@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-22platform/x86/intel: Move intel_pmt from MFD to Auxiliary BusDavid E. Box
Intel Platform Monitoring Technology (PMT) support is indicated by presence of an Intel defined PCIe Designated Vendor Specific Extended Capabilities (DVSEC) structure with a PMT specific ID. The current MFD implementation creates child devices for each PMT feature, currently telemetry, watcher, and crashlog. However DVSEC structures may also be used by Intel to indicate support for other features. The Out Of Band Management Services Module (OOBMSM) uses DVSEC to enumerate several features, including PMT. In order to support them it is necessary to modify the intel_pmt driver to handle the creation of the child devices more generically. To that end, modify the driver to create child devices for any VSEC/DVSEC features on supported devices (indicated by PCI ID). Additionally, move the implementation from MFD to the Auxiliary bus. VSEC/DVSEC features are really multifunctional PCI devices, not platform devices as MFD was designed for. Auxiliary bus gives more flexibility by allowing the definition of custom structures that can be shared between associated auxiliary devices and the parent device. Also, rename the driver from intel_pmt to intel_vsec to better reflect the purpose. This series also removes the current runtime pm support which was not complete to begin with. None of the current devices require runtime pm. However the support will be replaced when a device is added that requires it. Reviewed-by: Mark Gross <markgross@kernel.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20211208015015.891275-4-david.e.box@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-22spi: ar934x: fix transfer and word delaysOskari Lemmela
Add missing delay between transferred messages and words. Signed-off-by: Oskari Lemmela <oskari@lemmela.net> Link: https://lore.kernel.org/r/20211222055958.1383233-3-oskari@lemmela.net Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-22spi: uniphier: Fix a bug that doesn't point to private data correctlyKunihiko Hayashi
In uniphier_spi_remove(), there is a wrong code to get private data from the platform device, so the driver can't be removed properly. The driver should get spi_master from the platform device and retrieve the private data from it. Cc: <stable@vger.kernel.org> Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC") Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1640148492-32178-1-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-22memory: omap-gpmc: Add support for GPMC on AM64 SoCRoger Quadros
The TI's AM64 SoC has the GPMC module. Add compatible for it. Traditionally GPMC external addresses have always been mapped to first 1GB physical address. However newer platforms, can have it mapped at different locations. Support this address provision via device tree. Signed-off-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20211221131757.2030-3-rogerq@kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-12-22memory: omap-gpmc: Use platform_get_irq() to get the interruptLad Prabhakar
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypasses the hierarchical setup and messes up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq(). Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by: Roger Quadros <rogerq@ti.com> Link: https://lore.kernel.org/r/20211221203916.18588-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-12-22Merge tag 'iio-for-5.17a' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next Jonathan writes: 1st set of IIO new device support, features and cleanup for 5.17 Includes some fixes that were either late breaking, low priority or complex enough to not be good to rush in late in the cycle. Tree rebased today to fix up some trivial issues + pull in a fix that was previously on the fixes-togreg branch. Vast majority have been in linux-next for some time now. New device support * adi,ad7293 - New driver and bindings for this Power Amplifier drain current controller. A complex device with various related monitoring functions. * adi,ad75513R - New driver and bindings for this combined ADC and DAC device. - A few follow up fixes. * adi,admv8818 - New driver (and type) for this 2-18GHz filter device. Includes bindings and ABI documentation to allow clk_notifier based auto adjustment of the filters in appropriate applications. * liteon,ltr501 - Support for the ltr303. ID and chip specific info table. * xilinx,ams - New generic firmware function fwnode_iomap() as used in this driver. - New driver and bindings for this ADC and on-chip sensors as found in various Xilinx devices. Core * Introduced IIO_VAL_INT_64 which uses val and val2 in IIO callbacks to form a 64 bit integer when higher precision needed. * Allow IIO_ENUM_AVAILABLE to be used with different shared values. * Fix a long term issue with scheduling whilst atomic when iio_trig_poll() is called but no trigger consumers are actually enabled and hence the trigger may be reenabled from the interrupt handler. Seen in the wild on the tsc2046. * Mark iio_device_type const. * buffer: Use a separate index variable to simplify code. * buffer-dma: Clear out unused struct iio_buffer_block * buffer-dmaengine: Switch to cheaper round_down() as power of 2 values. Tests/tools * format_value - Check against NULL returns from allocations in tests. - Add IIO_VAL_INT_64 test case. * event_monitor - Flush the output after event to given more consistent latency when tool output piped to other programs. Driver Features * axp20x - Add support for NTC thermistor channel and document TS pin binding. * arm,scmi - Add reading of raw channel values (using IIO_VAL_INT_64) * liteon,ltr501 - Add proximity-near-level support and dt-binding. Tree wide cleanup * Remove no-op trigger ops from multiple drivers. * Stop using dev_get_drvdata() on the iio_dev->dev in various drivers and then stop assigning it to allow this to be used for other purposes. We can always get to the indio_dev using dev_to_iio_dev() which is a container_of() based approach. Also cleanup up some related unnecessary convoluted cases. - atmel,at91-sam5d2 - nxp,imx7d - meas,ms5611 - st,st_sensors * Where available (or easy to introduce) use the scan_type.* values in place of a second copy for read_raw and similar paths. - adi,ad7266 - bosch,bma220 - fsl,mac3110 - fsl,mma7455 - fsl,mpl3115 - kionix,kcjk-1013 - sensortek,stk8ba50 - sensortek,stk8312 - ti,adc12138 - ti,ads1015 - vti,sca3000 - xilinx,xadc-core * Switch drives over to generic firmware properties including appropriate header changes to avoid including of.h - Various DACs had false CONFIG_OF dependencies. - dpot-dac - envelope-detector - adi,ad5755 - adi,ad5758 - capella,cm3605 - maxim,max9611 - microchip,mcp41010 - microchip,mcp3911 - ti,adc12138 * Trivial clang warning fixes for W=1 warnings. Driver specific cleanup and minor fixes * adi,ad7606 - Comment fixes. * ams,ad3935 - Drop pointless cast to the same type. * atmel,at91-sama5d2 - Fix wrong cast of iio_dev->dev to platform_device that happened to be harmless. * fsl,mma7660 - Stop i2c remove() function returning an error code. Part of a rework to eventually stop returning anything from these. * fsl,mma8452 - Use correct type for local irqreturn_t. * nxp,imx8mq - Maintainer email address update. * nxp,lpc18xx_adc - Ensure clk_prepare_enable() called before clk_get_rate(). - Switch of.h for mod_devicetable.h to reflect no of specific functions, just the id table. * renesas,rzg2l - Drop a dev_err() that just duplicates error printed in platform_get_irq() * sgx,vz89x - Drop pointless cast. * st,lsm6dsx - Make it possible to disable the sensorhub from DT to avoid a corner case where the address of a slave device many be accidentally modified. * st,stm32-adc - Stop leaking an of_node in an error path. * st,stmp2 - Avoid wrong sized type for bit field which could result in over-reading (harmless). Precursor to enabling -Warray-bounds. * ti,adc081c - Put back some ACPI support for non standards compliant ADC081C ID because it is known to be in the wild on some Aaeon boards. * ti,ads8688 - Cleanup redundant local ret variable assignment. * ti,ina2xx-adc - Use helper macro kthread_run() to replace some boilerplate. - Avoid double reference counting. - Drop pointless cast. * xilinx,xadc - Make the IRQ optional as not always wired to the host system. * tag 'iio-for-5.17a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (103 commits) iio: adc: ti-adc081c: Partial revert of removal of ACPI IDs iio:addac:ad74413r: Fix uninitialized ret in a path that won't be hit. MAINTAINERS: Add maintainer for xilinx-ams dt-bindings: iio: adc: Add Xilinx AMS binding documentation iio: adc: Add Xilinx AMS driver device property: Add fwnode_iomap() iio:accel:kxcjk-1013: Mark struct __maybe_unused to avoid warning. iio:accel:bmc150: Mark structure __maybe_unused as only needed with for pm ops. iio:dummy: Drop set but unused variable len. iio:magn:ak8975: Suppress clang W=1 warning about pointer to enum conversion. iio:imu:inv_mpu6050: Suppress clang W=1 warning about pointer to enum conversion. iio:imu:inv_icm42600: Suppress clang W=1 warning about pointer to enum conversion. iio:dac:mcp4725: Suppress clang W=1 warning about pointer to enum conversion. iio:amplifiers:hmc425a: Suppress clang W=1 warning about pointer to enum conversion. iio:adc:ti-ads1015: Suppress clang W=1 warning about pointer to enum conversion. iio:adc:rcar: Suppress clang W=1 warning about pointer to enum conversion. iio:adc:ina2xx-adc: Suppress clang W=1 warning about pointer to enum conversion. iio:accel:bma180: Suppress clang W=1 warning about pointer to enum conversion. drivers:iio:dac: Add AD3552R driver support dt-bindings: iio: dac: Add adi,ad3552r.yaml ...
2021-12-22backlight: qcom-wled: Respect enabled-strings in set_brightnessMarijn Suijten
The hardware is capable of controlling any non-contiguous sequence of LEDs specified in the DT using qcom,enabled-strings as u32 array, and this also follows from the DT-bindings documentation. The numbers specified in this array represent indices of the LED strings that are to be enabled and disabled. Its value is appropriately used to setup and enable string modules, but completely disregarded in the set_brightness paths which only iterate over the number of strings linearly. Take an example where only string 2 is enabled with qcom,enabled_strings=<2>: this string is appropriately enabled but subsequent brightness changes would have only touched the zero'th brightness register because num_strings is 1 here. This is simply addressed by looking up the string for this index in the enabled_strings array just like the other codepaths that iterate over num_strings. Likewise enabled_strings is now also used in the autodetection path for consistent behaviour: when a list of strings is specified in DT only those strings will be probed for autodetection, analogous to how the number of strings that need to be probed is already bound by qcom,num-strings. After all autodetection uses the set_brightness helpers to set an initial value, which could otherwise end up changing brightness on a different set of strings. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Fixes: 03b2b5e86986 ("backlight: qcom-wled: Add support for WLED4 peripheral") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20211115203459.1634079-10-marijn.suijten@somainline.org
2021-12-22backlight: qcom-wled: Remove unnecessary double whitespaceMarijn Suijten
Remove redundant spaces inside for loop conditions. No other double spaces were found that are not part of indentation with `[^\s] `. Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20211115203459.1634079-9-marijn.suijten@somainline.org
2021-12-22backlight: qcom-wled: Provide enabled_strings default for WLED 4 and 5Marijn Suijten
Only WLED 3 sets a sensible default that allows operating this driver with just qcom,num-strings in the DT; WLED 4 and 5 require qcom,enabled-strings to be provided otherwise enabled_strings remains zero-initialized, resulting in every string-specific register write (currently only the setup and config functions, brightness follows in a future patch) to only configure the zero'th string multiple times. Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20211115203459.1634079-8-marijn.suijten@somainline.org
2021-12-22backlight: qcom-wled: Remove unnecessary 4th default string in WLED3Marijn Suijten
The previous commit improves num_strings parsing to not go over the maximum of 3 strings for WLED3 anymore. Likewise this default index for a hypothetical 4th string is invalid and could access registers that are not mapped to the desired purpose. Removing this value gets rid of undesired confusion and avoids the possibility of accessing registers at this offset even if the 4th array element is used by accident. Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20211115203459.1634079-7-marijn.suijten@somainline.org
2021-12-22backlight: qcom-wled: Override default length with qcom,enabled-stringsMarijn Suijten
The length of qcom,enabled-strings as property array is enough to determine the number of strings to be enabled, without needing to set qcom,num-strings to override the default number of strings when less than the default (which is also the maximum) is provided in DT. This also introduces an extra warning when qcom,num-strings is set, denoting that it is not necessary to set both anymore. It is usually more concise to set just qcom,num-length when a zero-based, contiguous range of strings is needed (the majority of the cases), or to only set qcom,enabled-strings when a specific set of indices is desired. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20211115203459.1634079-6-marijn.suijten@somainline.org
2021-12-22backlight: qcom-wled: Fix off-by-one maximum with default num_stringsMarijn Suijten
When not specifying num-strings in the DT the default is used, but +1 is added to it which turns WLED3 into 4 and WLED4/5 into 5 strings instead of 3 and 4 respectively, causing out-of-bounds reads and register read/writes. This +1 exists for a deficiency in the DT parsing code, and is simply omitted entirely - solving this oob issue - by parsing the property separately much like qcom,enabled-strings. This also enables more stringent checks on the maximum value when qcom,enabled-strings is provided in the DT, by parsing num-strings after enabled-strings to allow it to check against (and in a subsequent patch override) the length of enabled-strings: it is invalid to set num-strings higher than that. The DT currently utilizes it to get around an incorrect fixed read of four elements from that array (has been addressed in a prior patch) by setting a lower num-strings where desired. Fixes: 93c64f1ea1e8 ("leds: add Qualcomm PM8941 WLED driver") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-By: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20211115203459.1634079-5-marijn.suijten@somainline.org
2021-12-22backlight: qcom-wled: Use cpu_to_le16 macro to perform conversionMarijn Suijten
The kernel already provides appropriate primitives to perform endianness conversion which should be used in favour of manual bit-wrangling. Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20211115203459.1634079-4-marijn.suijten@somainline.org
2021-12-22backlight: qcom-wled: Pass number of elements to read to read_u32_arrayMarijn Suijten
of_property_read_u32_array takes the number of elements to read as last argument. This does not always need to be 4 (sizeof(u32)) but should instead be the size of the array in DT as read just above with of_property_count_elems_of_size. To not make such an error go unnoticed again the driver now bails accordingly when of_property_read_u32_array returns an error. Surprisingly the indentation of newlined arguments is lining up again after prepending `rc = `. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20211115203459.1634079-3-marijn.suijten@somainline.org
generated by cgit (git 2.34.1) at 2025-09-22 01:48:04 +0000