aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-sqlite.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-08-06ARM: dts: sti: remove clk_ignore_unused from bootargs for stih418-b2199Patrice Chotard1-1/+0
Remove clk_ignore_unused from bootargs as it's no more needed. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: remove clk_ignore_unused from bootargs for stih410-b2120Patrice Chotard1-1/+0
Remove clk_ignore_unused from bootargs as it's no more needed. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: remove clk_ignore_unused from bootargs for stih407-b2120Patrice Chotard1-1/+0
Remove clk_ignore_unused from bootargs as it's no more needed. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: Introduce 4KOpen (stih418-b2264) boardAlain Volmat2-1/+153
4KOpen (B2264) is a board based on the STMicroelectronics STiH418 soc: - 2GB DDR - HDMI - Ethernet 1000-BaseT - PCIe (mini PCIe connector) - MicroSD slot - USB2 and USB3 connectors - Sata - 40 pins GPIO header Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: add the thermal sensor node within stih418Alain Volmat1-0/+8
The STiH418 embedded the same sensor as the STiH410. This commit adds the corresponding node, relying on the st_thermal driver. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: disable rng11 on the stih418 platformAlain Volmat1-0/+4
The rng11 is not available on the STiH418 hence is disabled in the stih418.dtsi Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: add the spinor controller node within stih407-familyAlain Volmat1-0/+15
The STiH407 family (and further versions STiH410/STiH418) embedded a serial flash controller allowing fast access to SPI-NOR. This commit adds the corresponding node, relying on the st-spi-fsm drivers. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: update clkgen-fsyn entries in stih418-clockAlain Volmat1-23/+3
The clkgen-fsyn driver now embed the clock names (assuming the right compatible is used). Remove all clock-output-names property and update when necessary the compatible. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: update clkgen-fsyn entries in stih410-clockAlain Volmat1-24/+3
The clkgen-fsyn driver now embed the clock names (assuming the right compatible is used). Remove all clock-output-names property and update when necessary the compatible. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: update clkgen-fsyn entries in stih407-clockAlain Volmat1-24/+3
The clkgen-fsyn driver now embed the clock names (assuming the right compatible is used). Remove all clock-output-names property and update when necessary the compatible. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: update clkgen-pll entries in stih418-clockAlain Volmat1-11/+3
The clkgen-pll driver now embed the clock names (assuming the right compatible is used). Remove all clock-output-names property and update when necessary the compatible. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: update clkgen-pll entries in stih410-clockAlain Volmat1-13/+3
The clkgen-pll driver now embed the clock names (assuming the right compatible is used). Remove all clock-output-names property and update when necessary the compatible. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: update clkgen-pll entries in stih407-clockAlain Volmat1-13/+3
The clkgen-pll driver now embed the clock names (assuming the right compatible is used). Remove all clock-output-names property and update when necessary the compatible. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: update flexgen compatible within stih410-clockAlain Volmat1-89/+6
With the introduction of new flexgen compatible within the clk-flexgen driver, remove the clock-output-names entry from the flexgen nodes and set the new proper compatible corresponding. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: update flexgen compatible within stih407-clockAlain Volmat1-79/+6
With the introduction of new flexgen compatible within the clk-flexgen driver, remove the clock-output-names entry from the flexgen nodes and set the new proper compatible corresponding. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-06ARM: dts: sti: update flexgen compatible within stih418-clockAlain Volmat1-91/+5
With the introduction of new flexgen compatible within the clk-flexgen driver, remove the clock-output-names entry from the flexgen nodes and set the new proper compatible corresponding. Signed-off-by: Alain Volmat <avolmat@me.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-08-03ARM: dts: am57xx: Add PRUSS MDIO controller nodesSuman Anna6-0/+60
The PRUSSs on AM57xx SoCs contain an MDIO controller that can be used to control external PHYs associated with the Industrial Ethernet peripherals within each PRUSS. The MDIO module used within the PRU-ICSS is an instance of the MDIO Controller used in TI Davinci SoCs. The same bus frequency of 1 MHz is chosen as the regular MDIO node. The nodes are added in the common am57-pruss.dtsi file and enabled by default, but are disabled in all the existing AM57xx board dts files. These nodes need pinctrl lines, and so should be enabled only on boards where they are actually wired and pinned out for PRUSS Ethernet. Any new board dts file should disable these if they are not sure. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-03ARM: dts: am57xx: Add PRU-ICSS nodesSuman Anna1-1/+157
Add the DT nodes for the PRU-ICSS1 and PRU-ICSS2 processor subsystems that are present on AM57xx family of SoCs. Each PRU-ICSS instance is represented by a pruss node and other child nodes. The two PRU-ICSSs are identical to each other. They are not supported on DRA7xx SoCs in general, so the nodes are added under the respective interconnect target module nodes in a common am57-pruss.dtsi file. The file is already included only in the AM57xx related board files. The PRU-ICSSs on AM57xx are very similar to the PRUSS in AM33xx and AM437x except for variations in the RAM sizes and the number of interrupts coming into the MPU INTC. The interrupt events into the PRU-ICSS also requires programming of the corresponding crossbars properly. The PRUSS subsystem node contains the entire address space. The various sub-modules of the PRU-ICSS are represented as individual child nodes (so platform devices themselves) of the PRUSS subsystem node. These include the two 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), and the CFG sub-module are represented as syscon nodes. The PRUSS CFG module has a clock mux for IEP clock, this clk node is added under the CFG child node 'clocks'. The default source for this mux clock is the ICSS_IEP_CLK clock. The DT nodes use all standard properties. The regs property in the PRU nodes define the addresses for the Instruction RAM, the Debug and Control sub-modules for that PRU core. The firmware for each PRU core is defined through a 'firmware-name' property. The default names for the firmware images for each PRU core are defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): PRU-ICSS1 PRU0 Core: am57xx-pru1_0-fw PRU-ICSS1 PRU1 Core: am57xx-pru1_1-fw PRU-ICSS2 PRU0 Core: am57xx-pru2_0-fw PRU-ICSS2 PRU1 Core: am57xx-pru2_1-fw Note: 1. There are few more sub-modules like the Industrial Ethernet Peripheral (IEPs), MDIO, UART, eCAP that do not have bindings and so will be added in the future. 2. The PRUSS INTC on AM57xx SoCs also connect the host interrupts 6 and 7 as possible DMA events, so use the 'ti,irqs-reserved' property in derivative board dts files _if_ any of them should not be handled by the host OS. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-03ARM: dts: am4372: Add PRUSS MDIO controller nodeAndrew F. Davis6-0/+30
The PRU-ICSS1 instance on AM437x SoCs has a MDIO sub-module that can be used to control external PHYs associated with the Industrial Ethernet peripherals within the PRUSS. The MDIO module used within this PRU-ICSS is an instance of the MDIO Controller used in TI Davinci SoCs. The same bus frequency of 1 MHz is chosen as the regular MDIO node. Note that there is no MDIO node added to the smaller PRU-ICSS0 instance as the MDIO pins are not pinned out. The node is added and enabled in the common am4372.dtsi file by default, and disabled in all the existing AM437x board dts files. This node needs pinctrl lines, and so should be enabled only on boards where they are actually wired and pinned out for PRUSS Ethernet. Any new board dts file should disable these if they are not sure. Signed-off-by: Andrew F. Davis <afd@ti.com> [s-anna@ti.com: fix reg address, add commit description] Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-03ARM: dts: am4372: Add the PRU-ICSS0 DT nodeSuman Anna1-0/+77
The AM4376+ SoCs have a second smaller PRU-ICSS subsystem (PRUSS0) in addition to the primary PRUSS1 instance. The PRUSS0 has less DRAM per PRU, and no Shared DRAM among other minor differences. The IEP and MII_RT modules even though present within the IP are not pinned out. This PRUSS0 instance has a weird SoC integration. It shares the same L3 OCP interconnect interface with PRUSS1, and also shares its reset line and clocks. Any external accesses from PRUSS0 requires the PRUSS1's PRUSS_SYSCFG register to be programmed properly. That said, it is its own IP instance (a cut-down version), and so it has been added as an independent node (sibling node to PRUSS1 node) and a child node of the corresponding PRUSS target module interconnect node. This allows the PRUSS0 instance to be enabled/disabled independently of the PRUSS1 instance. The nodes are added under the corresponding interconnect target module node in the common am4372 dtsi file. The PRU-ICSS instances are not supported on AM4372 SoC though in the AM437x family, so the interconnect target module node should be disabled in any derivative board dts file that uses AM4372 SoCs. The individual PRUSS node can be disabled in the corresponding board dts file if desired. The default names for the firmware images for each PRU core are defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): PRU-ICSS0 PRU0 Core: am437x-pru0_0-fw PRU-ICSS0 PRU1 Core: am437x-pru0_1-fw Note: 1. There are few more sub-modules like the Industrial Ethernet Peripheral (IEP), eCAP, UART, that do not have bindings and so will be added in the future. Only UART is pinned out, so others should be added in disabled state if added. 2. The PRUSS0 INTC on AM437x SoCs routes the host interrupt 5 to the other PRUSS1, so it is already marked reserved through the 'ti,irqs-reserved' property. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-03ARM: dts: am4372: Add the PRU-ICSS1 DT nodeSuman Anna1-0/+78
Add the DT node for the PRU-ICSS1 instance on the AM437x family of SoCs. Each PRU-ICSS instance is represented by a pruss node and other child nodes. The nodes are added under the interconnect target module node in the common am4372 dtsi file. The PRU-ICSS instances are supported only on AM4376+ SoCs though in the AM437x family, so the interconnect target module node should be disabled in any derivative board dts file that uses AM4372 SoCs. The PRU-ICSS1 on AM437x is very similar to the PRUSS in AM33xx, except for variations in the RAM sizes, bus addresses and the number of interrupts coming into the MPU INTC (host interrupt 5 is routed to the other PRUSS instead of MPU). The PRUSS subsystem node contains the entire address space. The various sub-modules of the PRU-ICSS are represented as individual child nodes (so platform devices themselves) of the PRUSS subsystem node. These include the two 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), and the CFG sub-module are represented as syscon nodes. The PRUSS CFG module has a clock mux for IEP clock, this clk node is added under the CFG child node 'clocks'. The default source for this mux clock is the PRU_ICSS_IEP_GCLK clock. The DT nodes use all standard properties. The regs property in the PRU nodes define the addresses for the Instruction RAM, the Debug and Control sub-modules for that PRU core. The firmware for each PRU core is defined through a 'firmware-name' property. The default names for the firmware images for each PRU core are defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): PRU-ICSS1 PRU0 Core: am437x-pru1_0-fw PRU-ICSS1 PRU1 Core: am437x-pru1_1-fw Note: 1. There are few more sub-modules like the Industrial Ethernet Peripheral (IEP), MDIO, UART, eCAP that do not have bindings and so will be added in the future. 2. The PRUSS INTC on AM437x SoCs also connect the host interrupt 0 to ADC0 and ADC1; 6 and 7 as possible DMA events, so use the 'ti,irqs-reserved' property in derivative board dts files _if_ any of them should not be handled by the host OS. Host interrupt 5 is already marked reserved as it is connected to the other PRUSS instance. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-03ARM: dts: am335x-icev2: Enable PRU-ICSS moduleSuman Anna1-0/+4
The PRU-ICSS target module node was left in disabled state in the base am33xx-l4.dtsi file. PRU-ICSS is supported on the AM335x ICEv2 board, so enable this node to support PRUSS on this board. The PRUSS node and most of its child nodes are already enabled in the base dts file, and so become effective automatically with the enabling of this PRU-ICSS target module node. The corresponding PRU nodes can be disabled later on if there are no use-cases defined to use a particular PRU core or the whole PRU-ICSS subsystem itself if both its PRU cores are unused. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-03ARM: dts: am335x-evmsk: Enable PRU-ICSS moduleSuman Anna1-0/+4
The PRU-ICSS target module node was left in disabled state in the base am33xx-l4.dtsi file. PRU-ICSS is supported on the AM335x SK EVM board, so enable this node to support PRUSS on this board. The PRUSS node and most of its child nodes are already enabled in the base dts file, and so become effective automatically with the enabling of this PRU-ICSS target module node. The corresponding PRU nodes can be disabled later on if there are no use-cases defined to use a particular PRU core or the whole PRU-ICSS subsystem itself if both its PRU cores are unused. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-03ARM: dts: am335x-evm: Enable PRU-ICSS moduleSuman Anna1-0/+4
The PRU-ICSS target module node was left in disabled state in the base am33xx-l4.dtsi file. PRU-ICSS is supported on the AM335x EVM, so enable this node on the AM335x EVM. The PRUSS node and most of its child nodes are already enabled in the base dts file, and so become effective automatically with the enabling of this PRU-ICSS target module node. The corresponding PRU nodes can be disabled later on if there are no use-cases defined to use a particular PRU core or the whole PRU-ICSS subsystem itself if both its PRU cores are unused. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-03ARM: dts: am335x-bone-common: Enable PRU-ICSS nodeSuman Anna1-0/+4
The PRU-ICSS target module node was left in disabled state in the base am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone boards as they mostly use a AM3358 or a AM3359 SoC which do contain the PRU-ICSS IP. The PRUSS node and most of its child nodes are already enabled in the base dts file, and so become effective automatically with the enabling of this PRU-ICSS target-module node. The corresponding PRU nodes can be disabled later on if there are no use-cases defined to use a particular PRU core or the whole PRU-ICSS subsystem itself if both its PRU cores are unused. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-03ARM: dts: am33xx-l4: Add PRUSS MDIO controller nodeSuman Anna1-0/+11
The PRUSS on AM335x SoCs has a MDIO sub-module that can be used to control external PHYs associated with the Industrial Ethernet peripherals within the PRUSS. The MDIO module used within the PRU-ICSS is an instance of the MDIO Controller used in TI Davinci SoCs. The same bus frequency of 1 MHz is chosen as the regular MDIO node. The node is added to the common am33xx-l4.dtsi file and is disabled. This needs to be enabled in the respective board files using the relevant AM335x SoCs supporting PRUSS and where the ethernet is pinned out and connected properly. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-03ARM: dts: am33xx-l4: Add PRUSS nodeSuman Anna1-0/+71
Add the DT nodes for the PRU-ICSS on AM33xx family of SoCs. The AM33xx SoCs contain a single PRU-ICSS instance and is represented by a pruss node and other child nodes. PRU-ICSS is supported only on AM3356+ SoCs though in the AM33xx family, so the nodes are added under the corresponding disabled interconnect target module node in the common am33xx-l4 dtsi file. The target module node should be enabled in only those derivative board files that use a SoC containing PRU-ICSS. The PRUSS subsystem node contains the entire address space. The various sub-modules of the PRU-ICSS are represented as individual child nodes (so platform devices themselves) of the PRUSS subsystem node. These include the two 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), and the CFG sub-module are represented as syscon nodes. The PRUSS CFG module has a clock mux for IEP clock, this clk node is added under the CFG child node 'clocks'. The default source for this mux clock is the PRU_ICSS_IEP_GCLK clock. The DT nodes use all standard properties. The regs property in the PRU nodes define the addresses for the Instruction RAM, the Debug and Control sub-modules for that PRU core. The firmware for each PRU core is defined through a 'firmware-name' property. The default names for the firmware images for each PRU core are defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): PRU-ICSS PRU0 Core: am335x-pru1_0-fw PRU-ICSS PRU1 Core: am335x-pru1_1-fw Note: 1. There are few more sub-modules like the Industrial Ethernet Peripheral (IEP), MDIO, UART, eCAP that do not have bindings and so will be added in the future. 2. The PRUSS INTC on AM335x SoCs also connect the host interrupts 0 to TSC_ADC; 6 and 7 as possible DMA events, so use the 'ti,irqs-reserved' property in derivative board dts files _if_ any of them should not be handled by the host OS. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-08-02ARM: dts: owl-s500-roseapplepi: Add ethernet supportCristian Ciocaltea1-0/+45
Add pinctrl configuration for enabling the Ethernet MAC on RoseapplePi SBC. Additionally, provide the necessary properties for the generic S500 ethernet node in order to setup PHY and MDIO. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/d0e1fbf81984127f0352eb740c7129424b5e40f9.1623401998.git.cristian.ciocaltea@gmail.com Link: https://lore.kernel.org/r/20210628072817.8269-3-mani@kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-02ARM: dts: owl-s500: Add ethernet supportCristian Ciocaltea1-0/+10
Add Ethernet MAC device tree node for Actions Semi S500 SoC. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/222ee0c2cb431619f558dce9726585ac92f65e00.1623401998.git.cristian.ciocaltea@gmail.com Link: https://lore.kernel.org/r/20210628072817.8269-2-mani@kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-02ARM: dts: at91: use the right property for shutdown controllerNicolas Ferre7-7/+7
The wrong property "atmel,shdwc-debouncer" was used to specify the debounce delay for the shutdown controler. Replace it with the documented and implemented property "debounce-delay-us", as mentioned in v4 driver submission. See: https://lore.kernel.org/r/1458134390-23847-3-git-send-email-nicolas.ferre@atmel.com/ Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Reported-by: Clément Léger <clement.leger@bootlin.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20210730172729.28093-1-nicolas.ferre@microchip.com/
2021-08-01Linux 5.14-rc4Linus Torvalds1-1/+1
2021-08-02ARM: dts: ux500: Adjust operating points to realityLinus Walleij4-13/+22
The operating points should correspond to the actual frequencies supported for the CPU. Other patches have fixed so these are rounded and reported properly, this fixes the device trees to match. The Codina variant has a lower frequency than other devices so indicate this in the device tree. Cc: phone-devel@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-07-30pipe: make pipe writes always wake up readersLinus Torvalds1-5/+5
Since commit 1b6b26ae7053 ("pipe: fix and clarify pipe write wakeup logic") we have sanitized the pipe write logic, and would only try to wake up readers if they needed it. In particular, if the pipe already had data in it before the write, there was no point in trying to wake up a reader, since any existing readers must have been aware of the pre-existing data already. Doing extraneous wakeups will only cause potential thundering herd problems. However, it turns out that some Android libraries have misused the EPOLL interface, and expected "edge triggered" be to "any new write will trigger it". Even if there was no edge in sight. Quoting Sandeep Patil: "The commit 1b6b26ae7053 ('pipe: fix and clarify pipe write wakeup logic') changed pipe write logic to wakeup readers only if the pipe was empty at the time of write. However, there are libraries that relied upon the older behavior for notification scheme similar to what's described in [1] One such library 'realm-core'[2] is used by numerous Android applications. The library uses a similar notification mechanism as GNU Make but it never drains the pipe until it is full. When Android moved to v5.10 kernel, all applications using this library stopped working. The library has since been fixed[3] but it will be a while before all applications incorporate the updated library" Our regression rule for the kernel is that if applications break from new behavior, it's a regression, even if it was because the application did something patently wrong. Also note the original report [4] by Michal Kerrisk about a test for this epoll behavior - but at that point we didn't know of any actual broken use case. So add the extraneous wakeup, to approximate the old behavior. [ I say "approximate", because the exact old behavior was to do a wakeup not for each write(), but for each pipe buffer chunk that was filled in. The behavior introduced by this change is not that - this is just "every write will cause a wakeup, whether necessary or not", which seems to be sufficient for the broken library use. ] It's worth noting that this adds the extraneous wakeup only for the write side, while the read side still considers the "edge" to be purely about reading enough from the pipe to allow further writes. See commit f467a6a66419 ("pipe: fix and clarify pipe read wakeup logic") for the pipe read case, which remains that "only wake up if the pipe was full, and we read something from it". Link: https://lore.kernel.org/lkml/CAHk-=wjeG0q1vgzu4iJhW5juPkTsjTYmiqiMUYAebWW+0bam6w@mail.gmail.com/ [1] Link: https://github.com/realm/realm-core [2] Link: https://github.com/realm/realm-core/issues/4666 [3] Link: https://lore.kernel.org/lkml/CAKgNAkjMBGeAwF=2MKK758BhxvW58wYTgYKB2V-gY1PwXxrH+Q@mail.gmail.com/ [4] Link: https://lore.kernel.org/lkml/20210729222635.2937453-1-sspatil@android.com/ Reported-by: Sandeep Patil <sspatil@android.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-30Revert "perf map: Fix dso->nsinfo refcounting"Arnaldo Carvalho de Melo1-2/+0
This makes 'perf top' abort in some cases, and the right fix will involve surgery that is too much to do at this stage, so revert for now and fix it in the next merge window. This reverts commit 2d6b74baa7147251c30a46c4996e8cc224aa2dc5. Cc: Riccardo Mancini <rickyman7@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Krister Johansen <kjlx@templeofstupid.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-07-30mm/memcg: fix NULL pointer dereference in memcg_slab_free_hook()Wang Hai1-1/+1
When I use kfree_rcu() to free a large memory allocated by kmalloc_node(), the following dump occurs. BUG: kernel NULL pointer dereference, address: 0000000000000020 [...] Oops: 0000 [#1] SMP [...] Workqueue: events kfree_rcu_work RIP: 0010:__obj_to_index include/linux/slub_def.h:182 [inline] RIP: 0010:obj_to_index include/linux/slub_def.h:191 [inline] RIP: 0010:memcg_slab_free_hook+0x120/0x260 mm/slab.h:363 [...] Call Trace: kmem_cache_free_bulk+0x58/0x630 mm/slub.c:3293 kfree_bulk include/linux/slab.h:413 [inline] kfree_rcu_work+0x1ab/0x200 kernel/rcu/tree.c:3300 process_one_work+0x207/0x530 kernel/workqueue.c:2276 worker_thread+0x320/0x610 kernel/workqueue.c:2422 kthread+0x13d/0x160 kernel/kthread.c:313 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 When kmalloc_node() a large memory, page is allocated, not slab, so when freeing memory via kfree_rcu(), this large memory should not be used by memcg_slab_free_hook(), because memcg_slab_free_hook() is is used for slab. Using page_objcgs_check() instead of page_objcgs() in memcg_slab_free_hook() to fix this bug. Link: https://lkml.kernel.org/r/20210728145655.274476-1-wanghai38@huawei.com Fixes: 270c6a71460e ("mm: memcontrol/slab: Use helpers to access slab page's memcg_data") Signed-off-by: Wang Hai <wanghai38@huawei.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Roman Gushchin <guro@fb.com> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Muchun Song <songmuchun@bytedance.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-30slub: fix unreclaimable slab stat for bulk freeShakeel Butt1-10/+12
SLUB uses page allocator for higher order allocations and update unreclaimable slab stat for such allocations. At the moment, the bulk free for SLUB does not share code with normal free code path for these type of allocations and have missed the stat update. So, fix the stat update by common code. The user visible impact of the bug is the potential of inconsistent unreclaimable slab stat visible through meminfo and vmstat. Link: https://lkml.kernel.org/r/20210728155354.3440560-1-shakeelb@google.com Fixes: 6a486c0ad4dc ("mm, sl[ou]b: improve memory accounting") Signed-off-by: Shakeel Butt <shakeelb@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Roman Gushchin <guro@fb.com> Reviewed-by: Muchun Song <songmuchun@bytedance.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-30mm/migrate: fix NR_ISOLATED corruption on 64-bitAneesh Kumar K.V1-1/+1
Similar to commit 2da9f6305f30 ("mm/vmscan: fix NR_ISOLATED_FILE corruption on 64-bit") avoid using unsigned int for nr_pages. With unsigned int type the large unsigned int converts to a large positive signed long. Symptoms include CMA allocations hanging forever due to alloc_contig_range->...->isolate_migratepages_block waiting forever in "while (unlikely(too_many_isolated(pgdat)))". Link: https://lkml.kernel.org/r/20210728042531.359409-1-aneesh.kumar@linux.ibm.com Fixes: c5fc5c3ae0c8 ("mm: migrate: account THP NUMA migration counters correctly") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reported-by: Michael Ellerman <mpe@ellerman.id.au> Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Yang Shi <shy828301@gmail.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: David Hildenbrand <david@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-30mm: memcontrol: fix blocking rstat function called from atomic cgroup1 thresholding codeJohannes Weiner1-1/+2
Dan Carpenter reports: The patch 2d146aa3aa84: "mm: memcontrol: switch to rstat" from Apr 29, 2021, leads to the following static checker warning: kernel/cgroup/rstat.c:200 cgroup_rstat_flush() warn: sleeping in atomic context mm/memcontrol.c 3572 static unsigned long mem_cgroup_usage(struct mem_cgroup *memcg, bool swap) 3573 { 3574 unsigned long val; 3575 3576 if (mem_cgroup_is_root(memcg)) { 3577 cgroup_rstat_flush(memcg->css.cgroup); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is from static analysis and potentially a false positive. The problem is that mem_cgroup_usage() is called from __mem_cgroup_threshold() which holds an rcu_read_lock(). And the cgroup_rstat_flush() function can sleep. 3578 val = memcg_page_state(memcg, NR_FILE_PAGES) + 3579 memcg_page_state(memcg, NR_ANON_MAPPED); 3580 if (swap) 3581 val += memcg_page_state(memcg, MEMCG_SWAP); 3582 } else { 3583 if (!swap) 3584 val = page_counter_read(&memcg->memory); 3585 else 3586 val = page_counter_read(&memcg->memsw); 3587 } 3588 return val; 3589 } __mem_cgroup_threshold() indeed holds the rcu lock. In addition, the thresholding code is invoked during stat changes, and those contexts have irqs disabled as well. If the lock breaking occurs inside the flush function, it will result in a sleep from an atomic context. Use the irqsafe flushing variant in mem_cgroup_usage() to fix this. Link: https://lkml.kernel.org/r/20210726150019.251820-1-hannes@cmpxchg.org Fixes: 2d146aa3aa84 ("mm: memcontrol: switch to rstat") Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Chris Down <chris@chrisdown.name> Reviewed-by: Rik van Riel <riel@surriel.com> Acked-by: Michal Hocko <mhocko@suse.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-30ocfs2: issue zeroout to EOF blocksJunxiao Bi1-39/+60
For punch holes in EOF blocks, fallocate used buffer write to zero the EOF blocks in last cluster. But since ->writepage will ignore EOF pages, those zeros will not be flushed. This "looks" ok as commit 6bba4471f0cc ("ocfs2: fix data corruption by fallocate") will zero the EOF blocks when extend the file size, but it isn't. The problem happened on those EOF pages, before writeback, those pages had DIRTY flag set and all buffer_head in them also had DIRTY flag set, when writeback run by write_cache_pages(), DIRTY flag on the page was cleared, but DIRTY flag on the buffer_head not. When next write happened to those EOF pages, since buffer_head already had DIRTY flag set, it would not mark page DIRTY again. That made writeback ignore them forever. That will cause data corruption. Even directio write can't work because it will fail when trying to drop pages caches before direct io, as it found the buffer_head for those pages still had DIRTY flag set, then it will fall back to buffer io mode. To make a summary of the issue, as writeback ingores EOF pages, once any EOF page is generated, any write to it will only go to the page cache, it will never be flushed to disk even file size extends and that page is not EOF page any more. The fix is to avoid zero EOF blocks with buffer write. The following code snippet from qemu-img could trigger the corruption. 656 open("6b3711ae-3306-4bdd-823c-cf1c0060a095.conv.2", O_RDWR|O_DIRECT|O_CLOEXEC) = 11 ... 660 fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2275868672, 327680 <unfinished ...> 660 fallocate(11, 0, 2275868672, 327680) = 0 658 pwrite64(11, " Link: https://lkml.kernel.org/r/20210722054923.24389-2-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-30ocfs2: fix zero out valid dataJunxiao Bi1-2/+2
If append-dio feature is enabled, direct-io write and fallocate could run in parallel to extend file size, fallocate used "orig_isize" to record i_size before taking "ip_alloc_sem", when ocfs2_zeroout_partial_cluster() zeroout EOF blocks, i_size maybe already extended by ocfs2_dio_end_io_write(), that will cause valid data zeroed out. Link: https://lkml.kernel.org/r/20210722054923.24389-1-junxiao.bi@oracle.com Fixes: 6bba4471f0cc ("ocfs2: fix data corruption by fallocate") Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Jun Piao <piaojun@huawei.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-30lib/test_string.c: move string selftest in the Runtime Testing menuMatteo Croce2-3/+3
STRING_SELFTEST is presented in the "Library routines" menu. Move it in Kernel hacking > Kernel Testing and Coverage > Runtime Testing together with other similar tests found in lib/ --- Runtime Testing <*> Test functions located in the hexdump module at runtime <*> Test string functions (NEW) <*> Test functions located in the string_helpers module at runtime <*> Test strscpy*() family of functions at runtime <*> Test kstrto*() family of functions at runtime <*> Test printf() family of functions at runtime <*> Test scanf() family of functions at runtime Link: https://lkml.kernel.org/r/20210719185158.190371-1-mcroce@linux.microsoft.com Signed-off-by: Matteo Croce <mcroce@microsoft.com> Cc: Peter Rosin <peda@axentia.se> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-30gve: Update MAINTAINERS listCatherine Sullivan1-3/+3
The team maintaining the gve driver has undergone some changes, this updates the MAINTAINERS file accordingly. Signed-off-by: Catherine Sullivan <csully@google.com> Signed-off-by: Jon Olson <jonolson@google.com> Signed-off-by: David Awogbemila <awogbemila@google.com> Signed-off-by: Jeroen de Borst <jeroendb@google.com> Link: https://lore.kernel.org/r/20210729155258.442650-1-csully@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-07-30arch: Kconfig: clean up obsolete use of HAVE_IDELukas Bulwahn13-18/+0
The arch-specific Kconfig files use HAVE_IDE to indicate if IDE is supported. As IDE support and the HAVE_IDE config vanishes with commit b7fb14d3ac63 ("ide: remove the legacy ide driver"), there is no need to mention HAVE_IDE in all those arch-specific Kconfig files. The issue was identified with ./scripts/checkkconfigsymbols.py. Fixes: b7fb14d3ac63 ("ide: remove the legacy ide driver") Suggested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20210728182115.4401-1-lukas.bulwahn@gmail.com Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-07-30ARM: dts: stm32: Update AV96 adv7513 node per dtbs_checkMarek Vasut1-4/+2
Swap reg and reg-names order and drop adi,input-justification and adi,input-style to fix the following dtbs_check warnings: arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: adi,input-justification: False schema does not allow ['evenly'] arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: adi,input-style: False schema does not allow [[1]] arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: reg-names:1: 'edid' was expected arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: reg-names:2: 'cec' was expected Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-07-30ARM: dts: stm32: Set {bitclock,frame}-master phandles on ST DKxMarek Vasut1-4/+4
Fix the following dtbs_check warning: cs42l51@4a: port:endpoint@0:frame-master: True is not of type 'array' cs42l51@4a: port:endpoint@0:bitclock-master: True is not of type 'array' Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-07-30ARM: dts: stm32: Add coprocessor detach mbox on stm32mp15x-dkx boardsArnaud Pouliquen1-2/+2
To support the detach feature, add a new mailbox channel to inform the remote processor on a detach. This signal allows the remote processor firmware to stop IPC communication and to reinitialize the resources for a re-attach. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-07-30ARM: dts: stm32: Add coprocessor detach mbox on stm32mp157c-ed1 boardArnaud Pouliquen1-2/+2
To support the detach feature, add a new mailbox channel to inform the remote processor on a detach. This signal allows the remote processor firmware to stop IPC communication and to reinitialize the resources for a re-attach. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-07-30ARM: dts: stm32: Add usbphyc_port1 supply on DHCOM SoMMarek Vasut1-0/+4
The port is unused, but shares the same supply with port0, so fill the DT property in. This fixes the following dtbs_check warning: arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dt.yaml: usbphyc@5a006000: usb-phy@1: 'phy-supply' is a required property Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: kernel@dh-electronics.com Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-07-30ARM: dts: stm32: Add backlight and panel supply on DHCOM SoMMarek Vasut1-0/+17
Fix the following dtbs_check warning: arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: display-bl: 'power-supply' is a required property arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: panel: 'power-supply' is a required property Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: kernel@dh-electronics.com Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2021-07-30ARM: dts: stm32: Set {bitclock,frame}-master phandles on DHCOM SoMMarek Vasut1-4/+4
Fix the following dtbs_check warning: arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: codec@a: port:endpoint@0:frame-master: True is not of type 'array' arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: codec@a: port:endpoint@0:bitclock-master: True is not of type 'array' Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: kernel@dh-electronics.com Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>