aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-03-11arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystemsAswath Govindraju1-1/+16
According to latest errata of J721e [1], HS400 mode is not supported in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2 subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode. Also, update the itap delay values for all the MMCSD subsystems according the latest J721e data sheet[2] [1] - https://www.ti.com/lit/er/sprz455/sprz455.pdf [2] - https://www.ti.com/lit/ds/symlink/tda4vm.pdf Fixes: cd48ce86a4d0 ("arm64: dts: ti: k3-j721e-common-proc-board: Add support for SD card UHS modes") Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20210305054104.10153-1-a-govindraju@ti.com
2021-03-11arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entryJan Kiszka1-0/+9
Add the DT entry for a watchdog based on RTI1. On SR1.0 silicon, it requires additional firmware on the MCU R5F cores to handle the expiry, e.g. https://github.com/siemens/k3-rti-wdt. As this firmware will also lock the power domain to protect it against premature shutdown, mark it shared. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Praneeth Bajjuri <praneeth@ti.com> Link: https://lore.kernel.org/r/279c20fa-6e5e-4f88-9cd1-f76297a28a19@web.de
2021-03-09arm64: dts: ti: k3-j721e-main: Add ICSSG nodesSuman Anna1-0/+262
Add the DT nodes for the ICSSG0 and ICSSG1 processor subsystems that are present on the K3 J721E SoCs. The two ICSSGs are identical to each other for the most part, with the ICSSG1 supporting slightly enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance is represented by a PRUSS subsystem node and other child nodes. These nodes are enabled by default. The ICSSGs on K3 J721E SoCs are revised versions of the ICSSG on the first AM65x SR1.0 SoCs. The PRU IRAMs are slightly smaller, and the IP includes two new auxiliary PRU cores called Tx_PRUs. The Tx_PRUs have 6 KB of IRAMs and leverage the same host interrupts as the regular PRU cores. All The ICSSG host interrupts intended towards the main Arm core are also shared with other processors on the SoC, and can be partitioned as per system integration needs. The ICSSG subsystem node contains the entire address space. The various sub-modules of the ICSSG are represented as individual child nodes (so platform devices themselves) of the PRUSS subsystem node. These include the two PRU cores, two RTU cores, two Tx_PRU cores and the interrupt controller. All the Data RAMs are represented within a child node of its own named 'memories' without any compatible. The Real Time Media Independent Interface controller (MII_RT), the Gigabit capable MII_G_RT and the CFG sub-module are represented as syscon nodes. The ICSSG CFG sub-module provides two internal clock muxes, and these are represented as children of the CFG child node 'clocks' by the 'coreclk-mux' and iepclk-mux' clk nodes. The default parents for these mux clocks are also defined using the assigned-clock-parents property. The DT nodes use all standard properties. The regs property in the PRU/RTU/Tx_PRU nodes define the addresses for the Instruction RAM, the Debug and Control sub-modules for that PRU core. The firmware for each PRU/RTU/Tx_PRU core is defined through a 'firmware-name' property. The default names for the firmware images for each PRU, RTU and Tx_PRU cores are defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): ICSSG0 PRU0 Core : j7-pru0_0-fw ; PRU1 Core : j7-pru0_1-fw ICSSG0 RTU0 Core : j7-rtu0_0-fw ; RTU1 Core : j7-rtu0_1-fw ICSSG0 Tx_PRU0 Core : j7-txpru0_0-fw ; Tx_PRU1 Core : j7-txpru0_1-fw ICSSG1 PRU0 Core : j7-pru1_0-fw ; PRU1 Core : j7-pru1_1-fw ICSSG1 RTU0 Core : j7-rtu1_0-fw ; RTU1 Core : j7-rtu1_1-fw ICSSG1 Tx_PRU0 Core : j7-txpru1_0-fw ; Tx_PRU1 Core : j7-txpru1_1-fw Note: 1. The ICSSG INTC on J721E SoCs share all the host interrupts with other processors, so use the 'ti,irqs-reserved' property in derivative board dts files _if_ any of them should not be handled by the host OS. 2. There are few more sub-modules like the Industrial Ethernet Peripherals (IEPs), MDIO, PWM, UART that do not have bindings and so will be added in the future. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210304160712.8452-3-s-anna@ti.com
2021-03-09arm64: dts: ti: k3-am65-main: Add ICSSG nodesSuman Anna1-0/+393
Add the DT nodes for the ICSSG0, ICSSG1 and ICSSG2 processor subsystems that are present on the K3 AM65x SoCs. The three ICSSGs are identical to each other for the most part, with the ICSSG2 supporting slightly enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance is represented by a PRUSS subsystem node. These nodes are enabled by default. The ICSSGs on K3 AM65x SoCs are super-sets of the PRUSS on the AM57xx/ 6AK2G SoCs except for larger Shared Data RAM and the lack of a PRU-ICSS crossbar. They include two auxiliary PRU cores called RTUs and few other additional sub-modules. The interrupt integration is also different on the K3 AM65x SoCs and are propagated through various SoC-level Interrupt Router and Interrupt Aggregator blocks. The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP used on J721E SoCs, and has two new auxiliary PRU cores called Tx_PRUs. The Tx_PRUs have 6 KB of IRAMs and leverage the same host interrupts as the regular PRU cores. The Broadside (BS) RAM within each core is also sized differently w.r.t SR1.0. The ICSSG subsystem node contains the entire address space. The various sub-modules of the ICSSG are represented as individual child nodes (so platform devices themselves) of the PRUSS subsystem node. These include the various PRU cores and the interrupt controller. All the Data RAMs are represented within a child node of its own named 'memories' without any compatible. The Real Time Media Independent Interface controllers (MII_RT and MII_G_RT), and the CFG sub-module are represented as syscon nodes. The ICSSG CFG module has clock muxes for IEP clock and CORE clock, these clk nodes are added under the CFG child node 'clocks'. The default parents for these mux clocks are also assigned. The DT nodes use all standard properties. The regs property in the PRU/RTU/Tx_PRU nodes define the addresses for the Instruction RAM, the Debug and Control sub-modules for that PRU core. The firmware for each PRU/RTU/Tx_PRU core is defined through a 'firmware-name' property. The default names for the firmware images for each PRU, RTU and Tx_PRU cores are defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): ICSSG0 PRU0 Core : am65x-pru0_0-fw ; PRU1 Core : am65x-pru0_1-fw ICSSG0 RTU0 Core : am65x-rtu0_0-fw ; RTU1 Core : am65x-rtu0_1-fw ICSSG0 Tx_PRU0 Core : am65x-txpru0_0-fw ; Tx_PRU1 Core : am65x-txpru0_1-fw ICSSG1 PRU0 Core : am65x-pru1_0-fw ; PRU1 Core : am65x-pru1_1-fw ICSSG1 RTU0 Core : am65x-rtu1_0-fw ; RTU1 Core : am65x-rtu1_1-fw ICSSG1 Tx_PRU0 Core : am65x-txpru1_0-fw ; Tx_PRU1 Core : am65x-txpru1_1-fw ICSSG2 PRU0 Core : am65x-pru2_0-fw ; PRU1 Core : am65x-pru2_1-fw ICSSG2 RTU0 Core : am65x-rtu2_0-fw ; RTU1 Core : am65x-rtu2_1-fw ICSSG2 Tx_PRU0 Core : am65x-txpru2_0-fw ; Tx_PRU1 Core : am65x-txpru2_1-fw Note: 1. The ICSSG nodes are all added as per the SR2.0 device. Any sub-module IP differences need to be handled within the driver using SoC device match logic or separate dts/overlay files (if needs to be supported) with the Tx_PRU nodes expected to be disabled at the minimum. 2. The ICSSG INTC on AM65x SoCs share 5, 6, 7 host interrupts with other processors, so use the 'ti,irqs-reserved' property in derivative board dts files _if_ any of them should not be handled by the host OS. 3. There are few more sub-modules like the Industrial Ethernet Peripherals (IEPs), MDIO, PWM, UART that do not have bindings and so will be added in the future. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210304160712.8452-2-s-anna@ti.com
2021-03-09arm64: dts: ti: k3-am642-sk: Add CPSW DT nodesVignesh Raghavendra1-0/+73
AM642 SK board has 2 CPSW3g ports connected through TI DP83867 PHYs. Add DT entries for the same. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210304211038.12511-5-grygorii.strashko@ti.com
2021-03-09arm64: dts: ti: k3-am642-evm: add CPSW3g DT nodesVignesh Raghavendra1-0/+93
On am642-evm the CPSW3g ext. Port1 is directly connected to TI DP83867 PHY and Port2 is connected to TI DP83869 PHY which is shared with ICSS subsystem. The TI DP83869 PHY MII interface is configured using pinmux for CPSW3g, while MDIO bus is connected through GPIO controllable 2:1 TMUX154E switch (MDIO GPIO MUX) which has to be configured to route MDIO bus from CPSW3g to TI DP83869 PHY. Hence add networking support for am642-evm: - add CPSW3g MDIO and RGMII pinmux entries for both ext. ports; - add CPSW3g nodes; - add mdio-mux-multiplexer DT nodes to represent above topology. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210304211038.12511-4-grygorii.strashko@ti.com
2021-03-09arm64: dts: ti: k3-am64-main: add main CPTS entryGrygorii Strashko1-0/+15
Add DT node for the Main domain CPTS. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210304211038.12511-3-grygorii.strashko@ti.com
2021-03-09arm64: dts: ti: k3-am64-main: Add CPSW DT nodeVignesh Raghavendra2-0/+76
Add CPSW3g DT node with two external ports, MDIO and CPTS support. For CPSW3g DMA channels the ASEL is set to 15 (AM642x per DMA channel coherency feature), so that CPSW DMA channel participates in Coherency and thus avoid need to cache maintenance for SKBs. This improves bidirectional TCP performance by up to 100Mbps (on 1G link). Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210304211038.12511-2-grygorii.strashko@ti.com
2021-03-09arm64: dts: ti: k3-am65-main: Add device_type to pcie*_rc nodesJan Kiszka1-0/+2
This is demanded by the parent binding of ti,am654-pcie-rc, see Documentation/devicetree/bindings/pci/designware-pcie.txt. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/881dfd6c75423efce1d10261909939cd5ef19937.1613071976.git.jan.kiszka@siemens.com
2021-03-09arm64: dts: ti: Add support for AM642 SKLokesh Vutla2-0/+175
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. It supports the following interfaces: * 2 GB LPDDR4 RAM * x2 Gigabit Ethernet interfaces capable of working in switch and MAC mode * x1 USB 3.0 Type-A port * x1 UHS-1 capable µSD card slot * 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837 * 512 Mbit OSPI flash * x2 UART through UART-USB bridge * XDS110 for onboard JTAG debug using USB * Temperature sensors, user push buttons and LEDs * 40-pin Raspberry Pi compatible GPIO header * 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO) * 54-pin header for Programmable Realtime Unit (PRU) IO pins * Interface for remote automation. Includes: * power measurement and reset control * boot mode change Add basic support for AM642 SK. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20210226184251.26451-3-lokeshvutla@ti.com
2021-03-09dt-bindings: arm: ti: Add bindings for AM642 SKLokesh Vutla1-0/+1
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. Add DT binding documentation for AM642 SK. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210226184251.26451-2-lokeshvutla@ti.com
2021-03-09arm64: dts: ti: Add support for AM642 EVMDave Gerlach2-1/+249
The AM642 EValuation Module (EVM) is a board that provides access to various peripherals available on the AM642 SoC, such as PCIe, USB 2.0, CPSW Ethernet, ADC, and more. Introduce support for the AM642 EVM to enable mmc boot, including enabling UART and I2C on the board. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210226144257.5470-6-d-gerlach@ti.com
2021-03-09arm64: dts: ti: k3-am64-main: Enable DMA supportPeter Ujfalusi1-0/+73
Add the nodes for DMSS INTA, BCDMA and PKTDMA to enable the use of the DMAs in the system. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210226144257.5470-5-d-gerlach@ti.com
2021-03-09arm64: dts: ti: Add support for AM642 SoCDave Gerlach4-0/+576
The AM642 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration to enable applications such as Motor Drives, PLC, Remote IO and IoT Gateways. Some highlights of this SoC are: * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F MCUs, and a single Cortex-M4F. * Two Gigabit Industrial Communication Subsystems (ICSSG). * Integrated Ethernet switch supporting up to a total of two external ports. * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other peripherals. * Centralized System Controller for Security, Power, and Resource Management (DMSC). See AM64X Technical Reference Manual (SPRUIM2, Nov 2020) for further details: https://www.ti.com/lit/pdf/spruim2 Introduce basic support for the AM642 SoC to enable ramdisk or MMC boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals under cbass_main and the i2c, spi, and uart MCU domain periperhals under cbass_mcu. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210226144257.5470-4-d-gerlach@ti.com
2021-03-09dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM64Dave Gerlach1-1/+4
Add pinctrl macros for AM64 SoC. These macro definitions are similar to that of previous platforms, but adding new definitions to avoid any naming confusions in the soc dts files. Unlike what checkpatch insists, we do not need parentheses enclosing the values for this macro as we do intend it to generate two separate values as has been done for other similar platforms. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210226144257.5470-3-d-gerlach@ti.com
2021-03-09dt-bindings: arm: ti: Add bindings for AM642 SoCDave Gerlach1-0/+6
The AM642 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration to enable applications such as Motor Drives, PLC, Remote IO and IoT Gateways. Some highlights of this SoC are: * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F MCUs, and a single Cortex-M4F. * Two Gigabit Industrial Communication Subsystems (ICSSG). * Integrated Ethernet switch supporting up to a total of two external ports. * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other peripherals. * Centralized System Controller for Security, Power, and Resource Management (DMSC). See AM64X Technical Reference Manual (SPRUIM2, Nov 2020) for further details: https://www.ti.com/lit/pdf/spruim2 Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210226144257.5470-2-d-gerlach@ti.com
2021-03-05Linux 5.12-rc2Linus Torvalds1-1/+1
2021-03-05RDMA/rxe: Fix errant WARN_ONCE in rxe_completer()Bob Pearson1-32/+23
In rxe_comp.c in rxe_completer() the function free_pkt() did not clear skb which triggered a warning at 'done:' and could possibly at 'exit:'. The WARN_ONCE() calls are not actually needed. The call to free_pkt() is moved to the end to clearly show that all skbs are freed. Fixes: 899aba891cab ("RDMA/rxe: Fix FIXME in rxe_udp_encap_recv()") Link: https://lore.kernel.org/r/20210304192048.2958-1-rpearson@hpe.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-03-05RDMA/rxe: Fix extra deref in rxe_rcv_mcast_pkt()Bob Pearson1-24/+35
rxe_rcv_mcast_pkt() dropped a reference to ib_device when no error occurred causing an underflow on the reference counter. This code is cleaned up to be clearer and easier to read. Fixes: 899aba891cab ("RDMA/rxe: Fix FIXME in rxe_udp_encap_recv()") Link: https://lore.kernel.org/r/20210304192048.2958-1-rpearson@hpe.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-03-05RDMA/rxe: Fix missed IB reference counting in loopbackBob Pearson1-1/+9
When the noted patch below extending the reference taken by rxe_get_dev_from_net() in rxe_udp_encap_recv() until each skb is freed it was not matched by a reference in the loopback path resulting in underflows. Fixes: 899aba891cab ("RDMA/rxe: Fix FIXME in rxe_udp_encap_recv()") Link: https://lore.kernel.org/r/20210304192048.2958-1-rpearson@hpe.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-03-05io_uring: don't restrict issue_flags for io_openatPavel Begunkov1-1/+1
45d189c606292 ("io_uring: replace force_nonblock with flags") did something strange for io_openat() slicing all issue_flags but IO_URING_F_NONBLOCK. Not a bug for now, but better to just forward the flags. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-05io_uring: make SQPOLL thread parking sanerJens Axboe1-35/+30
We have this weird true/false return from parking, and then some of the callers decide to look at that. It can lead to unbalanced parks and sqd locking. Have the callers check the thread status once it's parked. We know we have the lock at that point, so it's either valid or it's NULL. Fix race with parking on thread exit. We need to be careful here with ordering of the sdq->lock and the IO_SQ_THREAD_SHOULD_PARK bit. Rename sqd->completion to sqd->parked to reflect that this is the only thing this completion event doesn. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-05io-wq: kill hashed waitqueue before manager exitsJens Axboe1-4/+5
If we race with shutting down the io-wq context and someone queueing a hashed entry, then we can exit the manager with it armed. If it then triggers after the manager has exited, we can have a use-after-free where io_wqe_hash_wake() attempts to wake a now gone manager process. Move the killing of the hashed write queue into the manager itself, so that we know we've killed it before the task exits. Fixes: e941894eae31 ("io-wq: make buffered file write hashed work map per-ctx") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-05io_uring: clear IOCB_WAITQ for non -EIOCBQUEUED returnJens Axboe1-0/+1
The callback can only be armed, if we get -EIOCBQUEUED returned. It's important that we clear the WAITQ bit for other cases, otherwise we can queue for async retry and filemap will assume that we're armed and return -EAGAIN instead of just blocking for the IO. Cc: stable@vger.kernel.org # 5.9+ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-05io_uring: don't keep looping for more events if we can't flush overflowJens Axboe1-3/+12
It doesn't make sense to wait for more events to come in, if we can't even flush the overflow we already have to the ring. Return -EBUSY for that condition, just like we do for attempts to submit with overflow pending. Cc: stable@vger.kernel.org # 5.11 Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-05io_uring: move to using create_io_thread()Jens Axboe3-109/+54
This allows us to do task creation and setup without needing to use completions to try and synchronize with the starting thread. Get rid of the old io_wq_fork_thread() wrapper, and the 'wq' and 'worker' startup completion events - we can now do setup before the task is running. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-05nvmet: model_number must be immutable once setMax Gurtovoy4-45/+50
In case we have already established connection to nvmf target, it shouldn't be allowed to change the model_number. E.g. if someone will identify ctrl and get model_number of "my_model" later on will change the model_numbel via configfs to "my_new_model" this will break the NVMe specification for "Get Log Page – Persistent Event Log" that refers to Model Number as: "This field contains the same value as reported in the Model Number field of the Identify Controller data structure, bytes 63:24." Although it doesn't mentioned explicitly that this field can't be changed, we can assume it. So allow setting this field only once: using configfs or in the first identify ctrl operation. Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-03-05nvme-fabrics: fix kato initializationMartin George1-1/+4
Currently kato is initialized to NVME_DEFAULT_KATO for both discovery & i/o controllers. This is a problem specifically for non-persistent discovery controllers since it always ends up with a non-zero kato value. Fix this by initializing kato to zero instead, and ensuring various controllers are assigned appropriate kato values as follows: non-persistent controllers - kato set to zero persistent controllers - kato set to NVMF_DEV_DISC_TMO (or any positive int via nvme-cli) i/o controllers - kato set to NVME_DEFAULT_KATO (or any positive int via nvme-cli) Signed-off-by: Martin George <marting@netapp.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-03-05nvme-hwmon: Return error code when registration failsDaniel Wagner1-0/+1
The hwmon pointer wont be NULL if the registration fails. Though the exit code path will assign it to ctrl->hwmon_device. Later nvme_hwmon_exit() will try to free the invalid pointer. Avoid this by returning the error code from hwmon_device_register_with_info(). Fixes: ed7770f66286 ("nvme/hwmon: rework to avoid devm allocation") Signed-off-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-03-05nvme-pci: add quirks for Lexar 256GB SSDPascal Terjan1-0/+3
Add the NVME_QUIRK_NO_NS_DESC_LIST and NVME_QUIRK_IGNORE_DEV_SUBNQN quirks for this buggy device. Reported and tested in https://bugs.mageia.org/show_bug.cgi?id=28417 Signed-off-by: Pascal Terjan <pterjan@google.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-03-05nvme-pci: mark Kingston SKC2000 as not supporting the deepest power stateZoltán Böszörményi1-0/+2
My 2TB SKC2000 showed the exact same symptoms that were provided in 538e4a8c57 ("nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs"), i.e. a complete NVME lockup that needed cold boot to get it back. According to some sources, the A2000 is simply a rebadged SKC2000 with a slightly optimized firmware. Adding the SKC2000 PCI ID to the quirk list with the same workaround as the A2000 made my laptop survive a 5 hours long Yocto bootstrap buildfest which reliably triggered the SSD lockup previously. Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-03-05nvme-pci: mark Seagate Nytro XM1440 as QUIRK_NO_NS_DESC_LIST.Julian Einwag1-1/+2
The kernel fails to fully detect these SSDs, only the character devices are present: [ 10.785605] nvme nvme0: pci function 0000:04:00.0 [ 10.876787] nvme nvme1: pci function 0000:81:00.0 [ 13.198614] nvme nvme0: missing or invalid SUBNQN field. [ 13.198658] nvme nvme1: missing or invalid SUBNQN field. [ 13.206896] nvme nvme0: Shutdown timeout set to 20 seconds [ 13.215035] nvme nvme1: Shutdown timeout set to 20 seconds [ 13.225407] nvme nvme0: 16/0/0 default/read/poll queues [ 13.233602] nvme nvme1: 16/0/0 default/read/poll queues [ 13.239627] nvme nvme0: Identify Descriptors failed (8194) [ 13.246315] nvme nvme1: Identify Descriptors failed (8194) Adding the NVME_QUIRK_NO_NS_DESC_LIST fixes this problem. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205679 Signed-off-by: Julian Einwag <jeinwag-nvme@marcapo.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Keith Busch <kbusch@kernel.org>
2021-03-04scsi: iscsi: Verify lengths on passthrough PDUsChris Leech1-0/+9
Open-iSCSI sends passthrough PDUs over netlink, but the kernel should be verifying that the provided PDU header and data lengths fall within the netlink message to prevent accessing beyond that in memory. Cc: stable@vger.kernel.org Reported-by: Adam Nichols <adam@grimm-co.com> Reviewed-by: Lee Duncan <lduncan@suse.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Chris Leech <cleech@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-04scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZEChris Leech2-83/+90
As the iSCSI parameters are exported back through sysfs, it should be enforcing that they never are more than PAGE_SIZE (which should be more than enough) before accepting updates through netlink. Change all iSCSI sysfs attributes to use sysfs_emit(). Cc: stable@vger.kernel.org Reported-by: Adam Nichols <adam@grimm-co.com> Reviewed-by: Lee Duncan <lduncan@suse.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Chris Leech <cleech@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-04scsi: iscsi: Restrict sessions and handles to admin capabilitiesLee Duncan1-0/+6
Protect the iSCSI transport handle, available in sysfs, by requiring CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting reception of messages to ones sent with CAP_SYS_ADMIN. This disables normal users from being able to end arbitrary iSCSI sessions. Cc: stable@vger.kernel.org Reported-by: Adam Nichols <adam@grimm-co.com> Reviewed-by: Chris Leech <cleech@redhat.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Lee Duncan <lduncan@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-04kernel: provide create_io_thread() helperJens Axboe2-0/+32
Provide a generic helper for setting up an io_uring worker. Returns a task_struct so that the caller can do whatever setup is needed, then call wake_up_new_task() to kick it into gear. Add a kernel_clone_args member, io_thread, which tells copy_process() to mark the task with PF_IO_WORKER. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-04io_uring: reliably cancel linked timeoutsPavel Begunkov1-0/+1
Linked timeouts are fired asynchronously (i.e. soft-irq), and use generic cancellation paths to do its stuff, including poking into io-wq. The problem is that it's racy to access tctx->io_wq, as io_uring_task_cancel() and others may be happening at this exact moment. Mark linked timeouts with REQ_F_INLIFGHT for now, making sure there are no timeouts before io-wq destraction. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-04io_uring: cancel-match based on flagsPavel Begunkov1-2/+2
Instead of going into request internals, like checking req->file->f_op, do match them based on REQ_F_INFLIGHT, it's set only when we want it to be reliably cancelled. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-04dm verity: fix FEC for RS roots unaligned to block sizeMilan Broz1-11/+12
Optional Forward Error Correction (FEC) code in dm-verity uses Reed-Solomon code and should support roots from 2 to 24. The error correction parity bytes (of roots lengths per RS block) are stored on a separate device in sequence without any padding. Currently, to access FEC device, the dm-verity-fec code uses dm-bufio client with block size set to verity data block (usually 4096 or 512 bytes). Because this block size is not divisible by some (most!) of the roots supported lengths, data repair cannot work for partially stored parity bytes. This fix changes FEC device dm-bufio block size to "roots << SECTOR_SHIFT" where we can be sure that the full parity data is always available. (There cannot be partial FEC blocks because parity must cover whole sectors.) Because the optional FEC starting offset could be unaligned to this new block size, we have to use dm_bufio_set_sector_offset() to configure it. The problem is easily reproduced using veritysetup, e.g. for roots=13: # create verity device with RS FEC dd if=/dev/urandom of=data.img bs=4096 count=8 status=none veritysetup format data.img hash.img --fec-device=fec.img --fec-roots=13 | awk '/^Root hash/{ print $3 }' >roothash # create an erasure that should be always repairable with this roots setting dd if=/dev/zero of=data.img conv=notrunc bs=1 count=8 seek=4088 status=none # try to read it through dm-verity veritysetup open data.img test hash.img --fec-device=fec.img --fec-roots=13 $(cat roothash) dd if=/dev/mapper/test of=/dev/null bs=4096 status=noxfer # wait for possible recursive recovery in kernel udevadm settle veritysetup close test With this fix, errors are properly repaired. device-mapper: verity-fec: 7:1: FEC 0: corrected 8 errors ... Without it, FEC code usually ends on unrecoverable failure in RS decoder: device-mapper: verity-fec: 7:1: FEC 0: failed to correct: -74 ... This problem is present in all kernels since the FEC code's introduction (kernel 4.5). It is thought that this problem is not visible in Android ecosystem because it always uses a default RS roots=2. Depends-on: a14e5ec66a7a ("dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size") Signed-off-by: Milan Broz <gmazyland@gmail.com> Tested-by: Jérôme Carretero <cJ-ko@zougloub.eu> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Cc: stable@vger.kernel.org # 4.5+ Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-03-04dm bufio: subtract the number of initial sectors in dm_bufio_get_device_sizeMikulas Patocka1-0/+4
dm_bufio_get_device_size returns the device size in blocks. Before returning the value, we must subtract the nubmer of starting sectors. The number of starting sectors may not be divisible by block size. Note that currently, no target is using dm_bufio_set_sector_offset and dm_bufio_get_device_size simultaneously, so this change has no effect. However, an upcoming dm-verity-fec fix needs this change. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Milan Broz <gmazyland@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-03-04btrfs: zoned: do not account freed region of read-only block group as zone_unusableNaohiro Aota1-1/+6
We migrate zone unusable bytes to read-only bytes when a block group is set to read-only, and account all the free region as bytes_readonly. Thus, we should not increase block_group->zone_unusable when the block group is read-only. Fixes: 169e0da91a21 ("btrfs: zoned: track unusable bytes for zones") Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>
2021-03-04btrfs: zoned: use sector_t for zone sectorsNaohiro Aota1-2/+2
We need to use sector_t for zone_sectors, or it would set the zone size to zero when the size >= 4GB (= 2^24 sectors) by shifting the zone_sectors value by SECTOR_SHIFT. We're assuming zones sizes up to 8GiB. Fixes: 5b316468983d ("btrfs: get zone information of zoned block devices") Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2021-03-04tracing: Fix comment about the trace_event_call flagsSteven Rostedt (VMware)1-9/+2
In the declaration of the struct trace_event_call, the flags has the bits defined in the comment above it. But these bits are also defined by the TRACE_EVENT_FL_* enums just above the declaration of the struct. As the comment about the flags in the struct has become stale and incorrect, just replace it with a reference to the TRACE_EVENT_FL_* enum above. Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2021-03-04tracing: Skip selftests if tracing is disabledSteven Rostedt (VMware)1-0/+6
If tracing is disabled for some reason (traceoff_on_warning, command line, etc), the ftrace selftests are guaranteed to fail, as their results are defined by trace data in the ring buffers. If the ring buffers are turned off, the tests will fail, due to lack of data. Because tracing being disabled is for a specific reason (warning, user decided to, etc), it does not make sense to enable tracing to run the self tests, as the test output may corrupt the reason for the tracing to be disabled. Instead, simply skip the self tests and report that they are being skipped due to tracing being disabled. Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2021-03-04tracing: Fix memory leak in __create_synth_event()Vamshi K Sthambamkadi1-1/+3
kmemleak report: unreferenced object 0xc5a6f708 (size 8): comm "ftracetest", pid 1209, jiffies 4294911500 (age 6.816s) hex dump (first 8 bytes): 00 c1 3d 60 14 83 1f 8a ..=`.... backtrace: [<f0aa4ac4>] __kmalloc_track_caller+0x2a6/0x460 [<7d3d60a6>] kstrndup+0x37/0x70 [<45a0e739>] argv_split+0x1c/0x120 [<c17982f8>] __create_synth_event+0x192/0xb00 [<0708b8a3>] create_synth_event+0xbb/0x150 [<3d1941e1>] create_dyn_event+0x5c/0xb0 [<5cf8b9e3>] trace_parse_run_command+0xa7/0x140 [<04deb2ef>] dyn_event_write+0x10/0x20 [<8779ac95>] vfs_write+0xa9/0x3c0 [<ed93722a>] ksys_write+0x89/0xc0 [<b9ca0507>] __ia32_sys_write+0x15/0x20 [<7ce02d85>] __do_fast_syscall_32+0x45/0x80 [<cb0ecb35>] do_fast_syscall_32+0x29/0x60 [<2467454a>] do_SYSENTER_32+0x15/0x20 [<9beaa61d>] entry_SYSENTER_32+0xa9/0xfc unreferenced object 0xc5a6f078 (size 8): comm "ftracetest", pid 1209, jiffies 4294911500 (age 6.816s) hex dump (first 8 bytes): 08 f7 a6 c5 00 00 00 00 ........ backtrace: [<bbac096a>] __kmalloc+0x2b6/0x470 [<aa2624b4>] argv_split+0x82/0x120 [<c17982f8>] __create_synth_event+0x192/0xb00 [<0708b8a3>] create_synth_event+0xbb/0x150 [<3d1941e1>] create_dyn_event+0x5c/0xb0 [<5cf8b9e3>] trace_parse_run_command+0xa7/0x140 [<04deb2ef>] dyn_event_write+0x10/0x20 [<8779ac95>] vfs_write+0xa9/0x3c0 [<ed93722a>] ksys_write+0x89/0xc0 [<b9ca0507>] __ia32_sys_write+0x15/0x20 [<7ce02d85>] __do_fast_syscall_32+0x45/0x80 [<cb0ecb35>] do_fast_syscall_32+0x29/0x60 [<2467454a>] do_SYSENTER_32+0x15/0x20 [<9beaa61d>] entry_SYSENTER_32+0xa9/0xfc In __create_synth_event(), while iterating field/type arguments, the argv_split() will return array of atleast 2 elements even when zero arguments(argc=0) are passed. for e.g. when there is double delimiter or string ends with delimiter To fix call argv_free() even when argc=0. Link: https://lkml.kernel.org/r/20210304094521.GA1826@cosmos Signed-off-by: Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2021-03-04ring-buffer: Add a little more information and a WARN when time stamp going backwards is detectedSteven Rostedt (VMware)1-3/+7
When the CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS is enabled, and the time stamps are detected as not being valid, it reports information about the write stamp, but does not show the before_stamp which is still useful information. Also, it should give a warning once, such that tests detect this happening. Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2021-03-04ring-buffer: Force before_stamp and write_stamp to be different on discardSteven Rostedt (VMware)1-0/+11
Part of the logic of the new time stamp code depends on the before_stamp and the write_stamp to be different if the write_stamp does not match the last event on the buffer, as it will be used to calculate the delta of the next event written on the buffer. The discard logic depends on this, as the next event to come in needs to inject a full timestamp as it can not rely on the last event timestamp in the buffer because it is unknown due to events after it being discarded. But by changing the write_stamp back to the time before it, it forces the next event to use a full time stamp, instead of relying on it. The issue came when a full time stamp was used for the event, and rb_time_delta() returns zero in that case. The update to the write_stamp (which subtracts delta) made it not change. Then when the event is removed from the buffer, because the before_stamp and write_stamp still match, the next event written would calculate its delta from the write_stamp, but that would be wrong as the write_stamp is of the time of the event that was discarded. In the case that the delta change being made to write_stamp is zero, set the before_stamp to zero as well, and this will force the next event to inject a full timestamp and not use the current write_stamp. Cc: stable@vger.kernel.org Fixes: a389d86f7fd09 ("ring-buffer: Have nested events still record running time stamp") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2021-03-04tracing: Fix help text of TRACEPOINT_BENCHMARK in KconfigRolf Eike Beer1-1/+1
It's "cond_resched()" not "cond_sched()". Link: https://lkml.kernel.org/r/1863065.aFVDpXsuPd@devpool47 Signed-off-by: Rolf Eike Beer <eb@emlix.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2021-03-04tracing: Remove duplicate declaration from trace.hYordan Karadzhov (VMware)1-1/+0
A declaration of function "int trace_empty(struct trace_iterator *iter)" shows up twice in the header file kernel/trace/trace.h Link: https://lkml.kernel.org/r/20210304092348.208033-1-y.karadz@gmail.com Signed-off-by: Yordan Karadzhov (VMware) <y.karadz@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2021-03-04io-wq: ensure all pending work is canceled on exitJens Axboe1-9/+33
If we race on shutting down the io-wq, then we should ensure that any work that was queued after workers shutdown is canceled. Harden the add work check a bit too, checking for IO_WQ_BIT_EXIT and cancel if it's set. Add a WARN_ON() for having any work before we kill the io-wq context. Reported-by: syzbot+91b4b56ead187d35c9d3@syzkaller.appspotmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>