[PATCH 1/2] Add support for Cadence XSPI controller
This driver uses SPI-MEM framework and is capable to operate with single, dual, quad and octal SPI-NOR memories. Low-level controller work mode (STIG) is utilized to communicate with flash memories. Signed-off-by: Jayshri Pawar Signed-off-by: Konrad Kociolek --- drivers/spi/Kconfig| 11 + drivers/spi/Makefile | 1 + drivers/spi/spi-cadence-xspi.c | 894 + 3 files changed, 906 insertions(+) create mode 100644 drivers/spi/spi-cadence-xspi.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 5cff60d..a699c14 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -212,6 +212,17 @@ config SPI_CADENCE_QUADSPI device with a Cadence QSPI controller and want to access the Flash as an MTD device. +config SPI_CADENCE_XSPI + tristate "Cadence XSPI controller" + depends on (OF || COMPILE_TEST) && HAS_IOMEM + help + Enable support for the Cadence XSPI Flash controller. + + Cadence XSPI is a specialized controller for connecting an SPI + Flash over upto 8bit wide bus. Enable this option if you have a + device with a Cadence XSPI controller and want to access the + Flash as an MTD device. + config SPI_CLPS711X tristate "CLPS711X host SPI controller" depends on ARCH_CLPS711X || COMPILE_TEST diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 6fea582..cb72cd6 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -32,6 +32,7 @@ obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o obj-$(CONFIG_SPI_CADENCE_QUADSPI) += spi-cadence-quadspi.o +obj-$(CONFIG_SPI_CADENCE_XSPI) += spi-cadence-xspi.o obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o diff --git a/drivers/spi/spi-cadence-xspi.c b/drivers/spi/spi-cadence-xspi.c new file mode 100644 index 000..fbf2aec --- /dev/null +++ b/drivers/spi/spi-cadence-xspi.c @@ -0,0 +1,894 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Cadence XSPI flash controller driver + * + * Copyright (C) 2020 Cadence + * + * Author: Konrad Kociolek + * Author: Jayshri Pawar + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define CDNS_XSPI_MAGIC_NUM_VALUE 0x6522 +#define CDNS_XSPI_MAX_BANKS 8 +#define CDNS_XSPI_NAME "cadence-xspi" + +/* + * Note: below are additional auxiliary registers to + * configure XSPI controller pin-strap settings + */ + +/* PHY DQ timing register */ +#define CDNS_XSPI_CCP_PHY_DQ_TIMING 0x +#define CDNS_XSPI_CCP_DATA_SELECT_OE_STARTGENMASK(6, 4) +#define CDNS_XSPI_CCP_DATA_SELECT_OE_END GENMASK(2, 0) +#define CDNS_XSPI_CCP_PHY_DQ_TIMING_INIT_VAL 0x8000 + +/* PHY DQS timing register */ +#define CDNS_XSPI_CCP_PHY_DQS_TIMING 0x0004 +#define CDNS_XSPI_CCP_USE_EXT_LPBCK_DQS BIT(22) +#define CDNS_XSPI_CCP_USE_LPBCK_DQS BIT(21) +#define CDNS_XSPI_CCP_USE_PHONY BIT(20) +#define CDNS_XSPI_CCP_DQS_SELECT_OE_START GENMASK(7, 4) +#define CDNS_XSPI_CCP_DQS_SELECT_OE_END GENMASK(3, 0) + +/* PHY gate loopback control register */ +#define CDNS_XSPI_CCP_PHY_GATE_LPBCK_CTRL 0x0008 +#define CDNS_XSPI_CCP_READ_DATA_DELAY_SEL GENMASK(24, 19) +#define CDNS_XSPI_CCP_GATE_CFG_CLOSE GENMASK(5, 4) +#define CDNS_XSPI_CCP_GATE_CFGGENMASK(3, 0) + +/* PHY DLL slave control register */ +#define CDNS_XSPI_CCP_PHY_DLL_SLAVE_CTRL 0x0010 +#define CDNS_XSPI_CCP_CLK_WR_DELAYGENMASK(15, 8) +#define CDNS_XSPI_CCP_READ_DQS_DELAY GENMASK(7, 0) + +#define CDNS_XSPI_AUX_PHY_ADDONS_REG 0x0040 +#define CDNS_XSPI_AUX_PHY_ADDONS_VALUE0xE0012000 +#define CDNS_XSPI_AUX_DEV_DISC_CONFIG_REG 0x0048 +#define CDNS_XSPI_AUX_DEV_DISC_CONFIG_VALUE 0x +#define CDNS_XSPI_AUX_DRIVING_REG 0x0050 +#define CDNS_XSPI_AUX_CTRL_RESET BIT(0) + +/* DLL PHY control register */ +#define CDNS_XSPI_DLL_PHY_CTRL0x1034 +#define CDNS_XSPI_CCP_DQS_LAST_DATA_DROP_EN BIT(20) + +/* Command registers */ +#define CDNS_XSPI_CMD_REG_0 0x +#define CDNS_XSPI_CMD_REG_1 0x0004 +#define CDNS_XSPI_CMD_REG_2 0x0008 +#define CDNS_XSPI_CMD_REG_3 0x000C +#define CDNS_XSPI_CMD_REG_4 0x0010 +#define CDNS_XSPI_CMD_REG_5 0x0014 + +/* Command status registers */ +#define CDNS_XSPI_CMD_STATUS_REG 0x0044 +#define CDNS_XSPI_CMD_COMPLETED BIT(15) +#define
[PATCH 0/2] Driver for Cadence xSPI flash controller
Command processing Driver uses STIG work mode to communicate with flash memories. In this mode, controller sends low-level instructions to memory. Each instruction is 128-bit width. There is special instruction DataSequence which carries information about data phase. Driver uses Slave DMA interface to transfer data as only this interface can be used in STIG work mode. PHY initialization The initialization of PHY module in Cadence XSPI controller is done by driving external pin-strap signals to controller. Next, driver runs PHY training to find optimal value of read_dqs_delay parameter. Controller checks device discovery status and if it's completed and with no error PHY training passes. Jayshri Pawar (2): Add support for Cadence XSPI controller Add dt-bindings documentation for Cadence XSPI controller .../devicetree/bindings/spi/cdns,xspi.yaml | 164 drivers/spi/Kconfig| 11 + drivers/spi/Makefile | 1 + drivers/spi/spi-cadence-xspi.c | 894 + 4 files changed, 1070 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/cdns,xspi.yaml create mode 100644 drivers/spi/spi-cadence-xspi.c -- 2.7.4
RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken
Alex, I had to revise the patch. Please see attachment. It is actually two more SSIDs affected to that. Best regards, Edgar -Original Message- From: Merger, Edgar [AUTOSOL/MAS/AUGS] Sent: Dienstag, 8. Dezember 2020 09:23 To: 'Deucher, Alexander' ; 'Huang, Ray' ; 'Kuehling, Felix' Cc: 'Will Deacon' ; 'linux-kernel@vger.kernel.org' ; 'linux-...@vger.kernel.org' ; 'io...@lists.linux-foundation.org' ; 'Bjorn Helgaas' ; 'Joerg Roedel' ; 'Zhu, Changfeng' Subject: RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken Applied the patch as in attachment. Verified that ATS for GPU-Device had been disabled. See attachment "dmesg_ATS.log". Was running that build over night successfully. -Original Message- From: Merger, Edgar [AUTOSOL/MAS/AUGS] Sent: Montag, 7. Dezember 2020 05:53 To: Deucher, Alexander ; Huang, Ray ; Kuehling, Felix Cc: Will Deacon ; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; io...@lists.linux-foundation.org; Bjorn Helgaas ; Joerg Roedel ; Zhu, Changfeng Subject: RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken Hi Alex, I believe in the patch file, this + (pdev->subsystem_device == 0x0c19 || +pdev->subsystem_device == 0x0c10)) Has to be changed to: + (pdev->subsystem_device == 0xce19 || +pdev->subsystem_device == 0xcc10)) Because our SSIDs are "ea50:ce19" and "ea50:cc10" respectively and another one would "ea50:cc08". I will apply that patch and feedback the results soon plus the patch file that I actually had applied. -Original Message- From: Deucher, Alexander Sent: Montag, 30. November 2020 19:36 To: Merger, Edgar [AUTOSOL/MAS/AUGS] ; Huang, Ray ; Kuehling, Felix Cc: Will Deacon ; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; io...@lists.linux-foundation.org; Bjorn Helgaas ; Joerg Roedel ; Zhu, Changfeng Subject: RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken [AMD Public Use] > -Original Message- > From: Merger, Edgar [AUTOSOL/MAS/AUGS] > Sent: Thursday, November 26, 2020 4:24 AM > To: Deucher, Alexander ; Huang, Ray > ; Kuehling, Felix > Cc: Will Deacon ; linux-kernel@vger.kernel.org; > linux- p...@vger.kernel.org; io...@lists.linux-foundation.org; Bjorn > Helgaas ; Joerg Roedel ; Zhu, > Changfeng > Subject: RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as > broken > > Alex, > > This is pretty much the same patch as what I have received from Joerg > previously, except that it is tied to the particular Emerson platform > and its derivatives (listed with Subsystem IDs). Right. As per my original point, I don't want to disable ATS on all Picasso chips because doing so would break GPU compute on them, so I'd like to apply this quirk as narrowly as possible. > > Below patch was what Joerg provided me and I successfully tested. > > This diff to the kernel should do that: > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index > f70692ac79c5..3911b0ec57ba 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -5176,6 +5176,8 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, > 0x6900, quirk_amd_harvest_no_ats); > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7312, > quirk_amd_harvest_no_ats); > /* AMD Navi14 dGPU */ > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7340, > quirk_amd_harvest_no_ats); > +/* AMD Raven platform iGPU */ > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x15d8, > +quirk_amd_harvest_no_ats); > #endif /* CONFIG_PCI_ATS */ > > /* Freescale PCIe doesn't support MSI in RC mode */ > > So far I have seen this issue on two instances of this chip, but I > must admit that I did test only two of them to this extent, so I guess > it is not a bad chip in particular, but the chips we use are from the > same production lot, so it might be a systematical problem of that production > lot? > > UEFI-Setup shows: > Processor Family: 17h > Procossor Model: 20h - 2Fh > CPUID: 00820F01 > Microcode Patch Level: 8200103 > > Looking at the chip-die I found that this is a fully qualified IP > Silicon (according to Ryzen Embedded R1000 SOC Interlock). > YE1305C9T20FG > BI2015SUY > 9JB6496P00123 > 2016 AMD > DIFFUSED IN USA > MADE IN CHINA > > Currently used SBIOS is a branch from "EmbeddedPI-FP5 1.2.0.3RC3". > > In the future our SBIOS might merge with EmbeddedPI-FP5_1.2.0.5RC3. > I think it's more likely an sbios issue, so hopefully the new release fixes it. Alex > > > > -Original Message- > From: Deucher, Alexander > Sent: Mittwoch, 25. November 2020 17:08 > To: Merger, Edgar [AUTOSOL/MAS/AUGS] ; > Huang, Ray ; Kuehling, Felix > > Cc: Will Deacon ; linux-kernel@vger.kernel.org; > linux- p...@vger.kernel.org; io...@lists.linux-foundation.org; Bjorn > Helgaas ; Joerg Roedel ; Zhu, > Changfeng > Subject: RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as > broken > > [AMD Public Use] > > >
[PATCH 2/2] Add dt-bindings documentation for Cadence XSPI controller
Add dt-bindings documentation for Cadence XSPI controller to support SPI based flash memories. Signed-off-by: Jayshri Pawar Signed-off-by: Konrad Kociolek --- .../devicetree/bindings/spi/cdns,xspi.yaml | 164 + 1 file changed, 164 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/cdns,xspi.yaml diff --git a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml new file mode 100644 index 000..a7d95b5 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml @@ -0,0 +1,164 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2020 Cadence +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/spi/cdns,xspi.yaml#; +$schema: "http://devicetree.org/meta-schemas/core.yaml#; + +title: Cadence XSPI Controller + +maintainers: + - Jayshri Pawar + - Konrad Kociolek + +description: | + The XSPI controller allows SPI protocol communication in + single, dual, quad or octal wire transmission modes for + read/write access to slaves such as SPI-NOR flash. + +properties: + compatible: +const: cdns,xspi-nor-fpga + + reg: +items: + - description: address and lentgh of the controller register set + - description: address and lentgh of the Slave DMA data port + - description: address and lentgh of the auxiliary registers + + interrupts: +maxItems: 1 + + cdns,dqs-last-data-drop: +type: boolean +description: | + This parameter should be set when the Flash Device being used + issues data on negative edge of Flash clock and returns them with + DQS and the PHY is configured to sample data in DQS mode. + If this param is set the controller internally requests this redundant + data at the end of the transfer cleaning up the PHY FIFO. + + cdns,phy-data-select-oe-start: +$ref: /schemas/types.yaml#/definitions/uint32 +description: | + Adjusts the starting point of the DQ pad output enable window. + Lower numbers pull the rising edge earlier in time and larger + numbers cause the rising edge to be delayed. Each bit changes + the output enable time by a 1/2 cycle resolution. + + cdns,phy-data-select-oe-end: +$ref: /schemas/types.yaml#/definitions/uint32 +description: | + Adjusts the ending point of the DQ pad output enable window. + Lower numbers pull the falling edge earlier in time and larger + numbers cause the falling edge to be delayed. Each bit changes + the output enable time by a 1/2 cycle resolution. + + cdns,phy-dqs-select-oe-start: +$ref: /schemas/types.yaml#/definitions/uint32 +description: | + Adjusts the starting point of the DQS pad output enable window. + Lower numbers pull the rising edge earlier in time and larger + numbers cause the rising edge to be delayed. Each bit changes + the output enable time by a 1/2 cycle resolution. + + cdns,phy-dqs-select-oe-end: +$ref: /schemas/types.yaml#/definitions/uint32 +description: | + Adjusts the ending point of the DQS pad output enable window. + Lower numbers pull the falling edge earlier in time and larger + numbers cause the falling edge to be delayed. Each bit changes + the output enable time by a 1/2 cycle resolution. + + cdns,phy-gate-cfg-close: +$ref: /schemas/types.yaml#/definitions/uint32 +description: | + Normally the gate is closing then all bits of dfi_cebar are high + or when dfi_rd_pre_post_amble and rebar_dfi are high. This parameter + allows to extend the closing of the DQS gate. Recommended zero. + + cdns,phy-gate-cfg: +$ref: /schemas/types.yaml#/definitions/uint32 +description: | + Coarse adjust of gate open time. This value is the number of cycles + to delay the dfi_rddata_en signal prior to opening the gate in + full cycle increments. Decreasing this value pulls the gate earlier + in time. This field should be programmed such that the gate signal + lands in the valid DQS gate window. + + cdns,phy-rd-del-select: +$ref: /schemas/types.yaml#/definitions/uint32 +description: | + Defines the read data delay. Holds the number of cycles to delay + the dfi_rddata_en signal prior to enabling the read FIFO. + After this delay, the read pointers begin incrementing the read FIFO. + + cdns,phy-clk-wr-delay: +$ref: /schemas/types.yaml#/definitions/uint32 +description: | + Controls the clk_wr delay line which adjusts the write DQ bit + timing in 1/256th steps of the clock period in normal DLL + locked mode. In bypass mode this field directly programs + the number of delay elements. + + cdns,phy-use-lpbk-dqs: +type: boolean +description: | + This parameter chooses lpbk_dqs to capture data for reads. + Instead memory DQS will be used. + + cdns,phy-use-ext-lpbk-dqs: +type: boolean +description: | + This
Re: [Ksummit-discuss] crediting bug reports and fixes folded into original patch
On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote: > On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote: > > > If not "Adjusted-by", what about "Tweaked-by", "Helped-by", > > "Corrected-by"? > > Improved-by: / Enhanced-by: / Revisions-by: > I don't think we should give any credit for improvements or enhancements, only for fixes. Complaining about style is its own reward. Having to redo a patch is already a huge headache. Normally, I already considered the reviewer's prefered style and decided I didn't like it. Then to make me redo the patch in an ugly style and say thankyou on top of that??? Forget about it. Plus, as a reviewer I hate reviewing patches over and over. I've argued for years that we should have a Fixes-from: tag. The zero day bot is already encouraging people to add Reported-by tags for this and a lot of people do. regards, dan carpenter
[PATCH v5 00/27] MT8192 IOMMU support
This patch mainly adds support for mt8192 Multimedia IOMMU and SMI. mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation table format. The M4U-SMI HW diagram is as below: EMI | M4U | SMI Common | +---+--+--+--+---+ | | | | .. | | | | | | | | larb0 larb1 larb2 larb4 .. larb19 larb20 disp0 disp1 mdpvdec IPE IPE All the connections are HW fixed, SW can NOT adjust it. Comparing with the preview SoC, this patchset mainly adds two new functions: a) add iova 34 bits support. b) add multi domains support since several HW has the special iova region requirement. change note: v5: a) Add a new patch for the header guard for smi-larb-port.h in [5/27]. b) Add a new patch for error handle for iommu_device_sysfs_add and iommu_device_register[15/27]. c) Add a flag for the iova "ias == 34" case. the previous SoC still keep 32bits to save 16KB*3 lvl1 pgtable memory[13/27]. d) Add include for FIELD_GET build fail. e) In PM power domain patch, add a checking "pm_runtime_enabled" when call pm_runtime_get_sync for non power-domain case. and add a pm_runtime_put_noidle while pm_runtime_get_sync fail case. v4: https://lore.kernel.org/linux-iommu/2020123838.15682-1-yong...@mediatek.com/ a) rebase on v5.10-rc1 b) Move the smi part to a independent patchset. c) Improve v7s code from Robin and Will. d) Add a mediatek iommu entry patch in MAINTAIN. v3: https://lore.kernel.org/linux-iommu/20200930070647.10188-1-yong...@mediatek.com/ a) Fix DT schema issue commented from Rob. b) Fix a v7s issue. Use "_lvl" instead of "_l" in the macro(ARM_V7S_PTES_PER_LVL) since it is called in ARM_V7S_LVL_IDX which has already used "_l". c) Fix a PM suspend issue: Avoid pm suspend in pm runtime case. v2: https://lore.kernel.org/linux-iommu/20200905080920.13396-1-yong...@mediatek.com/ a) Convert IOMMU/SMI dt-binding to DT schema. b) Fix some comment from Pi-Hsun and Nicolas. like use generic_iommu_put_resv_regions. c) Reword some comment, like add how to use domain-id. v1: https://lore.kernel.org/linux-iommu/20200711064846.16007-1-yong...@mediatek.com/ Yong Wu (27): dt-bindings: iommu: mediatek: Convert IOMMU to DT schema dt-bindings: memory: mediatek: Add a common larb-port header file dt-bindings: memory: mediatek: Extend LARB_NR_MAX to 32 dt-bindings: memory: mediatek: Add domain definition dt-bindings: memory: mediatek: Rename header guard for SMI header file dt-bindings: mediatek: Add binding for mt8192 IOMMU iommu/mediatek: Use the common mtk-smi-larb-port.h iommu/io-pgtable-arm-v7s: Use ias to check the valid iova in unmap iommu/io-pgtable-arm-v7s: Extend PA34 for MediaTek iommu/io-pgtable-arm-v7s: Clarify LVL_SHIFT/BITS macro iommu/io-pgtable-arm-v7s: Add cfg as a param in some macros iommu/io-pgtable-arm-v7s: Quad lvl1 pgtable for MediaTek iommu/mediatek: Add a flag for iova_34 bit case iommu/mediatek: Move hw_init into attach_device iommu/mediatek: Add fail handle for sysfs_add and device_register iommu/mediatek: Add device link for smi-common and m4u iommu/mediatek: Add pm runtime callback iommu/mediatek: Add power-domain operation iommu/mediatek: Add iova reserved function iommu/mediatek: Add single domain iommu/mediatek: Support master use iova over 32bit iommu/mediatek: Support up to 34bit iova in tlb flush iommu/mediatek: Support report iova 34bit translation fault in ISR iommu/mediatek: Add support for multi domain iommu/mediatek: Adjust the structure iommu/mediatek: Add mt8192 support MAINTAINERS: Add entry for MediaTek IOMMU .../bindings/iommu/mediatek,iommu.txt | 105 --- .../bindings/iommu/mediatek,iommu.yaml| 183 +++ MAINTAINERS | 9 + drivers/iommu/io-pgtable-arm-v7s.c| 56 ++-- drivers/iommu/mtk_iommu.c | 289 +++--- drivers/iommu/mtk_iommu.h | 11 +- drivers/memory/mtk-smi.c | 8 + include/dt-bindings/memory/mt2701-larb-port.h | 4 +- include/dt-bindings/memory/mt2712-larb-port.h | 6 +- include/dt-bindings/memory/mt6779-larb-port.h | 6 +- include/dt-bindings/memory/mt8167-larb-port.h | 6 +- include/dt-bindings/memory/mt8173-larb-port.h | 6 +- include/dt-bindings/memory/mt8183-larb-port.h | 6 +- include/dt-bindings/memory/mt8192-larb-port.h | 240 +++ .../dt-bindings/memory/mtk-smi-larb-port.h| 22 ++ include/linux/io-pgtable.h| 4 +- include/soc/mediatek/smi.h| 3 +-
[PATCH v5 01/27] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema
Convert MediaTek IOMMU to DT schema. Signed-off-by: Yong Wu Reviewed-by: Rob Herring --- .../bindings/iommu/mediatek,iommu.txt | 105 --- .../bindings/iommu/mediatek,iommu.yaml| 167 ++ 2 files changed, 167 insertions(+), 105 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt deleted file mode 100644 index ac949f7fe3d4.. --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt +++ /dev/null @@ -1,105 +0,0 @@ -* Mediatek IOMMU Architecture Implementation - - Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U), and -this M4U have two generations of HW architecture. Generation one uses flat -pagetable, and only supports 4K size page mapping. Generation two uses the -ARM Short-Descriptor translation table format for address translation. - - About the M4U Hardware Block Diagram, please check below: - - EMI (External Memory Interface) - | - m4u (Multimedia Memory Management Unit) - | - ++ - || - gals0-rx gals1-rx(Global Async Local Sync rx) - || - || - gals0-tx gals1-tx(Global Async Local Sync tx) - || Some SoCs may have GALS. - ++ - | - SMI Common(Smart Multimedia Interface Common) - | - ++--- - || - | gals-rxThere may be GALS in some larbs. - || - || - | gals-tx - || - SMI larb0SMI larb1 ... SoCs have several SMI local arbiter(larb). - (display) (vdec) - || - || - +-+-+ +++ - | | | ||| - | | |... ||| ... There are different ports in each larb. - | | | ||| -OVL0 RDMA0 WDMA0 MC PP VLD - - As above, The Multimedia HW will go through SMI and M4U while it -access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain -smi local arbiter and smi common. It will control whether the Multimedia -HW should go though the m4u for translation or bypass it and talk -directly with EMI. And also SMI help control the power domain and clocks for -each local arbiter. - Normally we specify a local arbiter(larb) for each multimedia HW -like display, video decode, and camera. And there are different ports -in each larb. Take a example, There are many ports like MC, PP, VLD in the -video decode local arbiter, all these ports are according to the video HW. - In some SoCs, there may be a GALS(Global Async Local Sync) module between -smi-common and m4u, and additional GALS module between smi-larb and -smi-common. GALS can been seen as a "asynchronous fifo" which could help -synchronize for the modules in different clock frequency. - -Required properties: -- compatible : must be one of the following string: - "mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW. - "mediatek,mt2712-m4u" for mt2712 which uses generation two m4u HW. - "mediatek,mt6779-m4u" for mt6779 which uses generation two m4u HW. - "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses -generation one m4u HW. - "mediatek,mt8167-m4u" for mt8167 which uses generation two m4u HW. - "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW. - "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW. -- reg : m4u register base and size. -- interrupts : the interrupt of m4u. -- clocks : must contain one entry for each clock-names. -- clock-names : Only 1 optional clock: - - "bclk": the block clock of m4u. - Here is the list which require this "bclk": - - mt2701, mt2712, mt7623 and mt8173. - Note that m4u use the EMI clock which always has been enabled before kernel - if there is no this "bclk". -- mediatek,larbs : List of phandle to the local arbiters in the current Socs. - Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort - according to the local arbiter index, like larb0, larb1, larb2... -- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW. - Specifies the mtk_m4u_id as defined in - dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623 - dt-binding/memory/mt2712-larb-port.h for mt2712, - dt-binding/memory/mt6779-larb-port.h for mt6779, - dt-binding/memory/mt8167-larb-port.h for mt8167, - dt-binding/memory/mt8173-larb-port.h for mt8173, and -
[PATCH 0/4] hwmon: aspeed2600-pwm-tacho: Add driver support
Aspeed AST2600 is a server management SoC which has 16 PWM channels and 16 fan tacho channel. This series of patch provides AST2600 PWM/Fan tacho support in hwmon class. The driver provides a sysfs interface, and user can configure PWM duty cycle and read current FAN speed in RPM. Troy Lee (4): dt-bindings: hwmon: Add Aspeed AST2600 PWM/Fan ARM: dts: aspeed: Add Aspeed AST2600 PWM/Fan node in devicetree hwmon: Add Aspeed AST2600 support hwmon: Support Aspeed AST2600 PWM/Fan tachometer .../bindings/hwmon/aspeed2600-pwm-tacho.txt | 69 ++ Documentation/hwmon/aspeed_pwm_tachometer.rst | 24 + Documentation/hwmon/index.rst |1 + arch/arm/boot/dts/aspeed-ast2600-evb.dts | 149 +++ arch/arm/boot/dts/aspeed-g6.dtsi | 10 + drivers/hwmon/Kconfig | 10 + drivers/hwmon/Makefile|1 + drivers/hwmon/aspeed2600-pwm-tacho.c | 1053 + 8 files changed, 1317 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed2600-pwm-tacho.txt create mode 100644 Documentation/hwmon/aspeed_pwm_tachometer.rst create mode 100644 drivers/hwmon/aspeed2600-pwm-tacho.c -- 2.17.1
[PATCH v5 05/27] dt-bindings: memory: mediatek: Rename header guard for SMI header file
Only rename the header guard for all the SoC larb port header file. No funtional change. Suggested-by: Krzysztof Kozlowski Signed-off-by: Yong Wu --- include/dt-bindings/memory/mt2701-larb-port.h | 4 ++-- include/dt-bindings/memory/mt2712-larb-port.h | 4 ++-- include/dt-bindings/memory/mt6779-larb-port.h | 4 ++-- include/dt-bindings/memory/mt8167-larb-port.h | 4 ++-- include/dt-bindings/memory/mt8173-larb-port.h | 4 ++-- include/dt-bindings/memory/mt8183-larb-port.h | 4 ++-- 6 files changed, 12 insertions(+), 12 deletions(-) diff --git a/include/dt-bindings/memory/mt2701-larb-port.h b/include/dt-bindings/memory/mt2701-larb-port.h index 2d85c2ec6cfd..25d03526f142 100644 --- a/include/dt-bindings/memory/mt2701-larb-port.h +++ b/include/dt-bindings/memory/mt2701-larb-port.h @@ -4,8 +4,8 @@ * Author: Honghui Zhang */ -#ifndef _MT2701_LARB_PORT_H_ -#define _MT2701_LARB_PORT_H_ +#ifndef _DT_BINDINGS_MEMORY_MT2701_LARB_PORT_H_ +#define _DT_BINDINGS_MEMORY_MT2701_LARB_PORT_H_ /* * Mediatek m4u generation 1 such as mt2701 has flat m4u port numbers, diff --git a/include/dt-bindings/memory/mt2712-larb-port.h b/include/dt-bindings/memory/mt2712-larb-port.h index b6b2c6bf4459..5c7f303f078c 100644 --- a/include/dt-bindings/memory/mt2712-larb-port.h +++ b/include/dt-bindings/memory/mt2712-larb-port.h @@ -3,8 +3,8 @@ * Copyright (c) 2017 MediaTek Inc. * Author: Yong Wu */ -#ifndef __DTS_IOMMU_PORT_MT2712_H -#define __DTS_IOMMU_PORT_MT2712_H +#ifndef _DT_BINDINGS_MEMORY_MT2712_LARB_PORT_H_ +#define _DT_BINDINGS_MEMORY_MT2712_LARB_PORT_H_ #include diff --git a/include/dt-bindings/memory/mt6779-larb-port.h b/include/dt-bindings/memory/mt6779-larb-port.h index 60f57f54393e..bc93757df2bf 100644 --- a/include/dt-bindings/memory/mt6779-larb-port.h +++ b/include/dt-bindings/memory/mt6779-larb-port.h @@ -4,8 +4,8 @@ * Author: Chao Hao */ -#ifndef _DTS_IOMMU_PORT_MT6779_H_ -#define _DTS_IOMMU_PORT_MT6779_H_ +#ifndef _DT_BINDINGS_MEMORY_MT6779_LARB_PORT_H_ +#define _DT_BINDINGS_MEMORY_MT6779_LARB_PORT_H_ #include diff --git a/include/dt-bindings/memory/mt8167-larb-port.h b/include/dt-bindings/memory/mt8167-larb-port.h index fcb9a49ec60e..8570aab09db8 100644 --- a/include/dt-bindings/memory/mt8167-larb-port.h +++ b/include/dt-bindings/memory/mt8167-larb-port.h @@ -5,8 +5,8 @@ * Author: Honghui Zhang * Author: Fabien Parent */ -#ifndef __DTS_IOMMU_PORT_MT8167_H -#define __DTS_IOMMU_PORT_MT8167_H +#ifndef _DT_BINDINGS_MEMORY_MT8167_LARB_PORT_H_ +#define _DT_BINDINGS_MEMORY_MT8167_LARB_PORT_H_ #include diff --git a/include/dt-bindings/memory/mt8173-larb-port.h b/include/dt-bindings/memory/mt8173-larb-port.h index d8c99c946053..1b568973fc2d 100644 --- a/include/dt-bindings/memory/mt8173-larb-port.h +++ b/include/dt-bindings/memory/mt8173-larb-port.h @@ -3,8 +3,8 @@ * Copyright (c) 2015-2016 MediaTek Inc. * Author: Yong Wu */ -#ifndef __DTS_IOMMU_PORT_MT8173_H -#define __DTS_IOMMU_PORT_MT8173_H +#ifndef _DT_BINDINGS_MEMORY_MT8173_LARB_PORT_H_ +#define _DT_BINDINGS_MEMORY_MT8173_LARB_PORT_H_ #include diff --git a/include/dt-bindings/memory/mt8183-larb-port.h b/include/dt-bindings/memory/mt8183-larb-port.h index 275c095a6fd6..3095630bb190 100644 --- a/include/dt-bindings/memory/mt8183-larb-port.h +++ b/include/dt-bindings/memory/mt8183-larb-port.h @@ -3,8 +3,8 @@ * Copyright (c) 2018 MediaTek Inc. * Author: Yong Wu */ -#ifndef __DTS_IOMMU_PORT_MT8183_H -#define __DTS_IOMMU_PORT_MT8183_H +#ifndef _DT_BINDINGS_MEMORY_MT8183_LARB_PORT_H_ +#define _DT_BINDINGS_MEMORY_MT8183_LARB_PORT_H_ #include -- 2.18.0
[PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
This patch adds decriptions for mt8192 IOMMU and SMI. mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation table format. The M4U-SMI HW diagram is as below: EMI | M4U | SMI Common | +---+--+--+--+---+ | | | | .. | | | | | | | | larb0 larb1 larb2 larb4 .. larb19 larb20 disp0 disp1 mdpvdec IPE IPE All the connections are HW fixed, SW can NOT adjust it. mt8192 M4U support 0~16GB iova range. we preassign different engines into different iova ranges: domain-id module iova-range larbs 0 disp0 ~ 4G larb0/1 1 vcodec 4G ~ 8G larb4/5/7 2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20 3 CCU00x4000_ ~ 0x43ff_ larb13: port 9/10 4 CCU10x4400_ ~ 0x47ff_ larb14: port 4/5 The iova range for CCU0/1(camera control unit) is HW requirement. Signed-off-by: Yong Wu Reviewed-by: Rob Herring --- .../bindings/iommu/mediatek,iommu.yaml| 18 +- include/dt-bindings/memory/mt8192-larb-port.h | 240 ++ 2 files changed, 257 insertions(+), 1 deletion(-) create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index ba6626347381..0f26fe14c8e2 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -76,6 +76,7 @@ properties: - mediatek,mt8167-m4u # generation two - mediatek,mt8173-m4u # generation two - mediatek,mt8183-m4u # generation two + - mediatek,mt8192-m4u # generation two - description: mt7623 generation one items: @@ -115,7 +116,11 @@ properties: dt-binding/memory/mt6779-larb-port.h for mt6779, dt-binding/memory/mt8167-larb-port.h for mt8167, dt-binding/memory/mt8173-larb-port.h for mt8173, - dt-binding/memory/mt8183-larb-port.h for mt8183. + dt-binding/memory/mt8183-larb-port.h for mt8183, + dt-binding/memory/mt8192-larb-port.h for mt8192. + + power-domains: +maxItems: 1 required: - compatible @@ -133,11 +138,22 @@ allOf: - mediatek,mt2701-m4u - mediatek,mt2712-m4u - mediatek,mt8173-m4u + - mediatek,mt8192-m4u then: required: - clocks + - if: + properties: +compatible: + enum: +- mediatek,mt8192-m4u + +then: + required: +- power-domains + additionalProperties: false examples: diff --git a/include/dt-bindings/memory/mt8192-larb-port.h b/include/dt-bindings/memory/mt8192-larb-port.h new file mode 100644 index ..ec1ac2ba7094 --- /dev/null +++ b/include/dt-bindings/memory/mt8192-larb-port.h @@ -0,0 +1,240 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2020 MediaTek Inc. + * + * Author: Chao Hao + * Author: Yong Wu + */ +#ifndef _DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_ +#define _DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_ + +#include + +/* + * MM IOMMU: + * domain 0: display: larb0, larb1. + * domain 1: vcodec: larb4, larb5, larb7. + * domain 2: CAM/MDP: larb2, larb9, larb11, larb13, larb14, larb16, + * larb17, larb18, larb19, larb20, + * domain 3: CCU0: larb13 - port9/10. + * domain 4: CCU1: larb14 - port4/5. + * + * larb3/6/8/10/12/15 is null. + */ + +/* larb0 */ +#define M4U_PORT_L0_DISP_POSTMASK0 MTK_M4U_DOM_ID(0, 0, 0) +#define M4U_PORT_L0_OVL_RDMA0_HDR MTK_M4U_DOM_ID(0, 0, 1) +#define M4U_PORT_L0_OVL_RDMA0 MTK_M4U_DOM_ID(0, 0, 2) +#define M4U_PORT_L0_DISP_RDMA0 MTK_M4U_DOM_ID(0, 0, 3) +#define M4U_PORT_L0_DISP_WDMA0 MTK_M4U_DOM_ID(0, 0, 4) +#define M4U_PORT_L0_DISP_FAKE0 MTK_M4U_DOM_ID(0, 0, 5) + +/* larb1 */ +#define M4U_PORT_L1_OVL_2L_RDMA0_HDR MTK_M4U_DOM_ID(0, 1, 0) +#define M4U_PORT_L1_OVL_2L_RDMA2_HDR MTK_M4U_DOM_ID(0, 1, 1) +#define M4U_PORT_L1_OVL_2L_RDMA0 MTK_M4U_DOM_ID(0, 1, 2) +#define M4U_PORT_L1_OVL_2L_RDMA2 MTK_M4U_DOM_ID(0, 1, 3) +#define M4U_PORT_L1_DISP_MDP_RDMA4 MTK_M4U_DOM_ID(0, 1, 4) +#define M4U_PORT_L1_DISP_RDMA4 MTK_M4U_DOM_ID(0, 1, 5) +#define M4U_PORT_L1_DISP_UFBC_WDMA0MTK_M4U_DOM_ID(0, 1, 6) +#define M4U_PORT_L1_DISP_FAKE1 MTK_M4U_DOM_ID(0, 1, 7) + +/* larb2 */ +#define
Re: [PATCH v1 1/1] scsi: ufs: Fix ufs power down/on specs violation
On 2020-12-09 15:09, Ziqi Chen wrote:
As per specs, e.g, JESD220E chapter 7.2, while powering
off/on the ufs device, RST_N signal and REF_CLK signal
should be between VSS(Ground) and VCCQ/VCCQ2.
Power down:
1. Assert RST_N low
2. Turn-off REF_CLK
3. Turn-off VCC
4. Turn-off VCCQ/VCCQ2.
power on:
1. Turn-on VCC
2. Turn-on VCCQ/VCCQ2
3. Turn-On REF_CLK
4. Deassert RST_N high.
Signed-off-by: Ziqi Chen
---
drivers/scsi/ufs/ufs-qcom.c | 14 ++
drivers/scsi/ufs/ufshcd.c | 19 +--
drivers/scsi/ufs/ufshcd.h | 4 ++--
3 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 1e434cc..5ed3a63d 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -582,6 +582,9 @@ static int ufs_qcom_suspend(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
ufs_qcom_disable_lane_clks(host);
phy_power_off(phy);
+ if (hba->vops && hba->vops->device_reset)
+ hba->vops->device_reset(hba, false);
+
} else if (!ufs_qcom_is_link_active(hba)) {
ufs_qcom_disable_lane_clks(host);
}
@@ -1400,10 +1403,11 @@ static void ufs_qcom_dump_dbg_regs(struct
ufs_hba *hba)
/**
* ufs_qcom_device_reset() - toggle the (optional) device reset line
* @hba: per-adapter instance
+ * @toggle: need pulling up or not
*
* Toggles the (optional) reset line to reset the attached device.
*/
-static int ufs_qcom_device_reset(struct ufs_hba *hba)
+static int ufs_qcom_device_reset(struct ufs_hba *hba, bool toggle)
{
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
@@ -1416,10 +1420,12 @@ static int ufs_qcom_device_reset(struct ufs_hba
*hba)
* be on the safe side.
*/
gpiod_set_value_cansleep(host->device_reset, 1);
- usleep_range(10, 15);
- gpiod_set_value_cansleep(host->device_reset, 0);
- usleep_range(10, 15);
+ if (toggle) {
+ usleep_range(10, 15);
+ gpiod_set_value_cansleep(host->device_reset, 0);
+ usleep_range(10, 15);
+ }
return 0;
}
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 92d433d..5ab1c02 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8633,8 +8633,6 @@ static int ufshcd_suspend(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
if (ret)
goto set_dev_active;
- ufshcd_vreg_set_lpm(hba);
-
disable_clks:
/*
* Call vendor specific suspend callback. As these callbacks may
access
@@ -8664,6 +8662,7 @@ static int ufshcd_suspend(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
/* Put the host controller in low power mode if possible */
ufshcd_hba_vreg_set_lpm(hba);
+ ufshcd_vreg_set_lpm(hba);
goto out;
set_link_active:
@@ -8729,18 +8728,18 @@ static int ufshcd_resume(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
old_link_state = hba->uic_link_state;
ufshcd_hba_vreg_set_hpm(hba);
+ ret = ufshcd_vreg_set_hpm(hba);
+ if (ret)
+ goto out;
+
/* Make sure clocks are enabled before accessing controller */
ret = ufshcd_setup_clocks(hba, true);
if (ret)
- goto out;
+ goto disable_vreg;
/* enable the host irq as host controller would be active soon */
ufshcd_enable_irq(hba);
- ret = ufshcd_vreg_set_hpm(hba);
- if (ret)
- goto disable_irq_and_vops_clks;
-
/*
* Call vendor specific resume callback. As these callbacks may
access
* vendor specific host controller register space call them when the
@@ -8748,7 +8747,7 @@ static int ufshcd_resume(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
*/
ret = ufshcd_vops_resume(hba, pm_op);
if (ret)
- goto disable_vreg;
+ goto disable_irq_and_vops_clks;
/* For DeepSleep, the only supported option is to have the link off
*/
WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) &&
!ufshcd_is_link_off(hba));
@@ -8815,8 +8814,6 @@ static int ufshcd_resume(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
ufshcd_link_state_transition(hba, old_link_state, 0);
vendor_suspend:
ufshcd_vops_suspend(hba, pm_op);
-disable_vreg:
- ufshcd_vreg_set_lpm(hba);
disable_irq_and_vops_clks:
ufshcd_disable_irq(hba);
if (hba->clk_scaling.is_allowed)
@@ -8827,6 +8824,8 @@ static int ufshcd_resume(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
trace_ufshcd_clk_gating(dev_name(hba->dev),
hba->clk_gating.state);
}
+disable_vreg:
+ ufshcd_vreg_set_lpm(hba);
out:
hba->pm_op_in_progress = 0;
if (ret)
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 61344c4..47c7dab6 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -323,7 +323,7 @@
[PATCH v5 09/27] iommu/io-pgtable-arm-v7s: Extend PA34 for MediaTek
MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34.
Signed-off-by: Yong Wu
Acked-by: Will Deacon
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 9 +++--
drivers/iommu/mtk_iommu.c | 2 +-
include/linux/io-pgtable.h | 4 ++--
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index e880745ab1e8..4d0aa079470f 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -112,9 +112,10 @@
#define ARM_V7S_TEX_MASK 0x7
#define ARM_V7S_ATTR_TEX(val) (((val) & ARM_V7S_TEX_MASK) <<
ARM_V7S_TEX_SHIFT)
-/* MediaTek extend the two bits for PA 32bit/33bit */
+/* MediaTek extend the bits below for PA 32bit/33bit/34bit */
#define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
#define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
+#define ARM_V7S_ATTR_MTK_PA_BIT34 BIT(5)
/* *well, except for TEX on level 2 large pages, of course :( */
#define ARM_V7S_CONT_PAGE_TEX_SHIFT6
@@ -194,6 +195,8 @@ static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int
lvl,
pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
if (paddr & BIT_ULL(33))
pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ if (paddr & BIT_ULL(34))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT34;
return pte;
}
@@ -218,6 +221,8 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int
lvl,
paddr |= BIT_ULL(32);
if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
paddr |= BIT_ULL(33);
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT34)
+ paddr |= BIT_ULL(34);
return paddr;
}
@@ -754,7 +759,7 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct
io_pgtable_cfg *cfg,
if (cfg->ias > ARM_V7S_ADDR_BITS)
return NULL;
- if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
+ if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 35 : ARM_V7S_ADDR_BITS))
return NULL;
if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6451d83753e1..ec3c87d4b172 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -320,7 +320,7 @@ static int mtk_iommu_domain_finalise(struct
mtk_iommu_domain *dom)
IO_PGTABLE_QUIRK_ARM_MTK_EXT,
.pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
.ias = 32,
- .oas = 34,
+ .oas = 35,
.tlb = _iommu_flush_ops,
.iommu_dev = data->dev,
};
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 4cde111e425b..1ae0757f4f94 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -77,8 +77,8 @@ struct io_pgtable_cfg {
* TLB maintenance when mapping as well as when unmapping.
*
* IO_PGTABLE_QUIRK_ARM_MTK_EXT: (ARM v7s format) MediaTek IOMMUs extend
-* to support up to 34 bits PA where the bit32 and bit33 are
-* encoded in the bit9 and bit4 of the PTE respectively.
+* to support up to 35 bits PA where the bit32, bit33 and bit34 are
+* encoded in the bit9, bit4 and bit5 of the PTE respectively.
*
* IO_PGTABLE_QUIRK_NON_STRICT: Skip issuing synchronous leaf TLBIs
* on unmap, for DMA domains using the flush queue mechanism for
--
2.18.0
[PATCH v5 10/27] iommu/io-pgtable-arm-v7s: Clarify LVL_SHIFT/BITS macro
The current _ARM_V7S_LVL_BITS/ARM_V7S_LVL_SHIFT use a formula to calculate the corresponding value for level1 and level2 to pretend the code sane. Actually their level1 and level2 values are different from each other. This patch only clarify the two macro. No functional change. Suggested-by: Robin Murphy Signed-off-by: Yong Wu Reviewed-by: Robin Murphy --- drivers/iommu/io-pgtable-arm-v7s.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c index 4d0aa079470f..58cc201c10a3 100644 --- a/drivers/iommu/io-pgtable-arm-v7s.c +++ b/drivers/iommu/io-pgtable-arm-v7s.c @@ -44,13 +44,11 @@ /* * We have 32 bits total; 12 bits resolved at level 1, 8 bits at level 2, - * and 12 bits in a page. With some carefully-chosen coefficients we can - * hide the ugly inconsistencies behind these macros and at least let the - * rest of the code pretend to be somewhat sane. + * and 12 bits in a page. */ #define ARM_V7S_ADDR_BITS 32 -#define _ARM_V7S_LVL_BITS(lvl) (16 - (lvl) * 4) -#define ARM_V7S_LVL_SHIFT(lvl) (ARM_V7S_ADDR_BITS - (4 + 8 * (lvl))) +#define _ARM_V7S_LVL_BITS(lvl) ((lvl) == 1 ? 12 : 8) +#define ARM_V7S_LVL_SHIFT(lvl) ((lvl) == 1 ? 20 : 12) #define ARM_V7S_TABLE_SHIFT10 #define ARM_V7S_PTES_PER_LVL(lvl) (1 << _ARM_V7S_LVL_BITS(lvl)) -- 2.18.0
[PATCH v5 11/27] iommu/io-pgtable-arm-v7s: Add cfg as a param in some macros
Add "cfg" as a parameter for some macros. This is a preparing patch for
mediatek extend the lvl1 pgtable. No functional change.
Signed-off-by: Yong Wu
Acked-by: Will Deacon
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 36 +++---
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 58cc201c10a3..0b3c5b904ddc 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -47,21 +47,21 @@
* and 12 bits in a page.
*/
#define ARM_V7S_ADDR_BITS 32
-#define _ARM_V7S_LVL_BITS(lvl) ((lvl) == 1 ? 12 : 8)
+#define _ARM_V7S_LVL_BITS(lvl, cfg)((lvl) == 1 ? 12 : 8)
#define ARM_V7S_LVL_SHIFT(lvl) ((lvl) == 1 ? 20 : 12)
#define ARM_V7S_TABLE_SHIFT10
-#define ARM_V7S_PTES_PER_LVL(lvl) (1 << _ARM_V7S_LVL_BITS(lvl))
-#define ARM_V7S_TABLE_SIZE(lvl)
\
- (ARM_V7S_PTES_PER_LVL(lvl) * sizeof(arm_v7s_iopte))
+#define ARM_V7S_PTES_PER_LVL(lvl, cfg) (1 << _ARM_V7S_LVL_BITS(lvl, cfg))
+#define ARM_V7S_TABLE_SIZE(lvl, cfg)
\
+ (ARM_V7S_PTES_PER_LVL(lvl, cfg) * sizeof(arm_v7s_iopte))
#define ARM_V7S_BLOCK_SIZE(lvl)(1UL << ARM_V7S_LVL_SHIFT(lvl))
#define ARM_V7S_LVL_MASK(lvl) ((u32)(~0U << ARM_V7S_LVL_SHIFT(lvl)))
#define ARM_V7S_TABLE_MASK ((u32)(~0U << ARM_V7S_TABLE_SHIFT))
-#define _ARM_V7S_IDX_MASK(lvl) (ARM_V7S_PTES_PER_LVL(lvl) - 1)
-#define ARM_V7S_LVL_IDX(addr, lvl) ({ \
+#define _ARM_V7S_IDX_MASK(lvl, cfg)(ARM_V7S_PTES_PER_LVL(lvl, cfg) - 1)
+#define ARM_V7S_LVL_IDX(addr, lvl, cfg)({
\
int _l = lvl; \
- ((u32)(addr) >> ARM_V7S_LVL_SHIFT(_l)) & _ARM_V7S_IDX_MASK(_l); \
+ ((u32)(addr) >> ARM_V7S_LVL_SHIFT(_l)) & _ARM_V7S_IDX_MASK(_l, cfg); \
})
/*
@@ -237,7 +237,7 @@ static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
struct device *dev = cfg->iommu_dev;
phys_addr_t phys;
dma_addr_t dma;
- size_t size = ARM_V7S_TABLE_SIZE(lvl);
+ size_t size = ARM_V7S_TABLE_SIZE(lvl, cfg);
void *table = NULL;
if (lvl == 1)
@@ -283,7 +283,7 @@ static void __arm_v7s_free_table(void *table, int lvl,
{
struct io_pgtable_cfg *cfg = >iop.cfg;
struct device *dev = cfg->iommu_dev;
- size_t size = ARM_V7S_TABLE_SIZE(lvl);
+ size_t size = ARM_V7S_TABLE_SIZE(lvl, cfg);
if (!cfg->coherent_walk)
dma_unmap_single(dev, __arm_v7s_dma_addr(table), size,
@@ -427,7 +427,7 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
arm_v7s_iopte *tblp;
size_t sz = ARM_V7S_BLOCK_SIZE(lvl);
- tblp = ptep - ARM_V7S_LVL_IDX(iova, lvl);
+ tblp = ptep - ARM_V7S_LVL_IDX(iova, lvl, cfg);
if (WARN_ON(__arm_v7s_unmap(data, NULL, iova + i * sz,
sz, lvl, tblp) != sz))
return -EINVAL;
@@ -480,7 +480,7 @@ static int __arm_v7s_map(struct arm_v7s_io_pgtable *data,
unsigned long iova,
int num_entries = size >> ARM_V7S_LVL_SHIFT(lvl);
/* Find our entry at the current level */
- ptep += ARM_V7S_LVL_IDX(iova, lvl);
+ ptep += ARM_V7S_LVL_IDX(iova, lvl, cfg);
/* If we can install a leaf entry at this level, then do so */
if (num_entries)
@@ -553,7 +553,7 @@ static void arm_v7s_free_pgtable(struct io_pgtable *iop)
struct arm_v7s_io_pgtable *data = io_pgtable_to_data(iop);
int i;
- for (i = 0; i < ARM_V7S_PTES_PER_LVL(1); i++) {
+ for (i = 0; i < ARM_V7S_PTES_PER_LVL(1, >iop.cfg); i++) {
arm_v7s_iopte pte = data->pgd[i];
if (ARM_V7S_PTE_IS_TABLE(pte, 1))
@@ -605,9 +605,9 @@ static size_t arm_v7s_split_blk_unmap(struct
arm_v7s_io_pgtable *data,
if (!tablep)
return 0; /* Bytes unmapped */
- num_ptes = ARM_V7S_PTES_PER_LVL(2);
+ num_ptes = ARM_V7S_PTES_PER_LVL(2, cfg);
num_entries = size >> ARM_V7S_LVL_SHIFT(2);
- unmap_idx = ARM_V7S_LVL_IDX(iova, 2);
+ unmap_idx = ARM_V7S_LVL_IDX(iova, 2, cfg);
pte = arm_v7s_prot_to_pte(arm_v7s_pte_to_prot(blk_pte, 1), 2, cfg);
if (num_entries > 1)
@@ -649,7 +649,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable
*data,
if (WARN_ON(lvl > 2))
return 0;
- idx = ARM_V7S_LVL_IDX(iova, lvl);
+ idx = ARM_V7S_LVL_IDX(iova, lvl, >cfg);
ptep += idx;
do {
pte[i] = READ_ONCE(ptep[i]);
@@ -735,7 +735,7 @@ static phys_addr_t arm_v7s_iova_to_phys(struct
io_pgtable_ops
[PATCH v5 13/27] iommu/mediatek: Add a flag for iova_34 bit case
Add a HW flag for if the HW support 34bit IOVA. the previous SoC still use 32bit. normally the lvl1 pgtable size is 16KB when ias == 32. if ias == 34, lvl1 pgtable size is 16KB * 4. The purpose of this patch is to save 16KB*3 continuous memory for the previous SoC. Signed-off-by: Yong Wu --- drivers/iommu/mtk_iommu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index ec3c87d4b172..1bc5e881951c 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -112,6 +112,7 @@ #define HAS_SUB_COMM BIT(5) #define WR_THROT_ENBIT(6) #define HAS_LEGACY_IVRP_PADDR BIT(7) +#define IOVA_34_EN BIT(8) #define MTK_IOMMU_HAS_FLAG(pdata, _x) \ pdata)->flags) & (_x)) == (_x)) @@ -319,7 +320,7 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom) IO_PGTABLE_QUIRK_TLBI_ON_MAP | IO_PGTABLE_QUIRK_ARM_MTK_EXT, .pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap, - .ias = 32, + .ias = MTK_IOMMU_HAS_FLAG(data->plat_data, IOVA_34_EN) ? 34 : 32, .oas = 35, .tlb = _iommu_flush_ops, .iommu_dev = data->dev, -- 2.18.0
[PATCH v5 17/27] iommu/mediatek: Add pm runtime callback
This patch adds pm runtime callback.
In pm runtime case, all the registers backup/restore and bclk are
controlled in the pm_runtime callback, then pm_suspend is not needed in
this case.
runtime PM is disabled when suspend, thus we call
pm_runtime_status_suspended instead of pm_runtime_suspended.
And, m4u doesn't have its special pm runtime domain in previous SoC, in
this case dev->power.runtime_status is RPM_SUSPENDED defaultly, thus add
a "dev->pm_domain" checking for the SoC that has pm runtime domain.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 5614015e5b96..6fe3ee2b2bf5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -808,7 +808,7 @@ static int mtk_iommu_remove(struct platform_device *pdev)
return 0;
}
-static int __maybe_unused mtk_iommu_suspend(struct device *dev)
+static int __maybe_unused mtk_iommu_runtime_suspend(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
struct mtk_iommu_suspend_reg *reg = >reg;
@@ -826,7 +826,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device
*dev)
return 0;
}
-static int __maybe_unused mtk_iommu_resume(struct device *dev)
+static int __maybe_unused mtk_iommu_runtime_resume(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
struct mtk_iommu_suspend_reg *reg = >reg;
@@ -853,7 +853,25 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
return 0;
}
+static int __maybe_unused mtk_iommu_suspend(struct device *dev)
+{
+ /* runtime PM is disabled when suspend in pm_runtime case. */
+ if (dev->pm_domain && pm_runtime_status_suspended(dev))
+ return 0;
+
+ return mtk_iommu_runtime_suspend(dev);
+}
+
+static int __maybe_unused mtk_iommu_resume(struct device *dev)
+{
+ if (dev->pm_domain && pm_runtime_status_suspended(dev))
+ return 0;
+
+ return mtk_iommu_runtime_resume(dev);
+}
+
static const struct dev_pm_ops mtk_iommu_pm_ops = {
+ SET_RUNTIME_PM_OPS(mtk_iommu_runtime_suspend, mtk_iommu_runtime_resume,
NULL)
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_iommu_suspend, mtk_iommu_resume)
};
--
2.18.0
[PATCH v5 16/27] iommu/mediatek: Add device link for smi-common and m4u
In the lastest SoC, M4U has its special power domain. thus, If the engine
begin to work, it should help enable the power for M4U firstly.
Currently if the engine work, it always enable the power/clocks for
smi-larbs/smi-common. This patch adds device_link for smi-common and M4U.
then, if smi-common power is enabled, the M4U power also is powered on
automatically.
Normally M4U connect with several smi-larbs and their smi-common always
are the same, In this patch it get smi-common dev from the first smi-larb
device(i==0), then add the device_link only while m4u has power-domain.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 30 --
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 09c8c58feb78..5614015e5b96 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -706,7 +707,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return larb_nr;
for (i = 0; i < larb_nr; i++) {
- struct device_node *larbnode;
+ struct device_node *larbnode, *smicomm_node;
struct platform_device *plarbdev;
u32 id;
@@ -732,6 +733,26 @@ static int mtk_iommu_probe(struct platform_device *pdev)
component_match_add_release(dev, , release_of,
compare_of, larbnode);
+ if (i != 0)
+ continue;
+ smicomm_node = of_parse_phandle(larbnode, "mediatek,smi", 0);
+ if (!smicomm_node)
+ return -EINVAL;
+
+ plarbdev = of_find_device_by_node(smicomm_node);
+ of_node_put(smicomm_node);
+ data->smicomm_dev = >dev;
+ }
+
+ if (dev->pm_domain) {
+ struct device_link *link;
+
+ link = device_link_add(data->smicomm_dev, dev,
+ DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
+ if (!link) {
+ dev_err(dev, "Unable link %s.\n",
dev_name(data->smicomm_dev));
+ return -EINVAL;
+ }
}
platform_set_drvdata(pdev, data);
@@ -739,7 +760,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
ret = iommu_device_sysfs_add(>iommu, dev, NULL,
"mtk-iommu.%pa", );
if (ret)
- return ret;
+ goto out_link_remove;
iommu_device_set_ops(>iommu, _iommu_ops);
iommu_device_set_fwnode(>iommu, >dev.of_node->fwnode);
@@ -763,6 +784,9 @@ static int mtk_iommu_probe(struct platform_device *pdev)
iommu_device_unregister(>iommu);
out_sysfs_remove:
iommu_device_sysfs_remove(>iommu);
+out_link_remove:
+ if (dev->pm_domain)
+ device_link_remove(data->smicomm_dev, dev);
return ret;
}
@@ -777,6 +801,8 @@ static int mtk_iommu_remove(struct platform_device *pdev)
bus_set_iommu(_bus_type, NULL);
clk_disable_unprepare(data->bclk);
+ if (pdev->dev.pm_domain)
+ device_link_remove(data->smicomm_dev, >dev);
devm_free_irq(>dev, data->irq, data);
component_master_del(>dev, _iommu_com_ops);
return 0;
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index d0c93652bdbe..5e03a029c4dc 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -68,6 +68,7 @@ struct mtk_iommu_data {
struct iommu_device iommu;
const struct mtk_iommu_plat_data *plat_data;
+ struct device *smicomm_dev;
struct dma_iommu_mapping*mapping; /* For mtk_iommu_v1.c */
--
2.18.0
[PATCH v5 19/27] iommu/mediatek: Add iova reserved function
For multiple iommu_domains, we need to reserve some iova regions. Take a
example, If the default iova region is 0 ~ 4G, but the 0x4000_ ~
0x43ff_ is only for the special CCU0 domain. Thus we should exclude
this region for the default iova region.
This patch adds iova reserved flow. It's a preparing patch for supporting
multi-domain.
Signed-off-by: Anan sun
Signed-off-by: Chao Hao
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 28
drivers/iommu/mtk_iommu.h | 5 +
2 files changed, 33 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 0e9c03cbab32..6a909efc984f 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -157,6 +157,11 @@ static LIST_HEAD(m4ulist); /* List all the M4U HWs */
#define for_each_m4u(data) list_for_each_entry(data, , list)
+struct mtk_iommu_iova_region {
+ dma_addr_t iova_base;
+ unsigned long long size;
+};
+
/*
* There may be 1 or 2 M4U HWs, But we always expect they are in the same
domain
* for the performance.
@@ -553,6 +558,27 @@ static int mtk_iommu_of_xlate(struct device *dev, struct
of_phandle_args *args)
return iommu_fwspec_add_ids(dev, args->args, 1);
}
+static void mtk_iommu_get_resv_regions(struct device *dev,
+ struct list_head *head)
+{
+ struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
+ const struct mtk_iommu_iova_region *resv;
+ struct iommu_resv_region *region;
+ int prot = IOMMU_WRITE | IOMMU_READ;
+ unsigned int i;
+
+ for (i = 0; i < data->plat_data->iova_region_nr; i++) {
+ resv = data->plat_data->iova_region + i;
+
+ region = iommu_alloc_resv_region(resv->iova_base, resv->size,
+prot, IOMMU_RESV_RESERVED);
+ if (!region)
+ return;
+
+ list_add_tail(>list, head);
+ }
+}
+
static const struct iommu_ops mtk_iommu_ops = {
.domain_alloc = mtk_iommu_domain_alloc,
.domain_free= mtk_iommu_domain_free,
@@ -567,6 +593,8 @@ static const struct iommu_ops mtk_iommu_ops = {
.release_device = mtk_iommu_release_device,
.device_group = mtk_iommu_device_group,
.of_xlate = mtk_iommu_of_xlate,
+ .get_resv_regions = mtk_iommu_get_resv_regions,
+ .put_resv_regions = generic_iommu_put_resv_regions,
.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M,
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 5e03a029c4dc..e867cd3aeeac 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -45,10 +45,15 @@ enum mtk_iommu_plat {
M4U_MT8183,
};
+struct mtk_iommu_iova_region;
+
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
u32 flags;
u32 inv_sel_reg;
+
+ unsigned intiova_region_nr;
+ const struct mtk_iommu_iova_region *iova_region;
unsigned char larbid_remap[MTK_LARB_COM_MAX][MTK_LARB_SUBCOM_MAX];
};
--
2.18.0
[PATCH v5 21/27] iommu/mediatek: Support master use iova over 32bit
After extending v7s, our pagetable already support iova reach
16GB(34bit). the master got the iova via dma_alloc_attrs may reach
34bits, but its HW register still is 32bit. then how to set the
bit32/bit33 iova? this depend on a SMI larb setting(bank_sel).
we separate whole 16GB iova to four banks:
bank: 0: 0~4G; 1: 4~8G; 2: 8-12G; 3: 12-16G;
The bank number is (iova >> 32).
We will preassign which bank the larbs belong to. currently we don't
have a interface for master to adjust its bank number.
Each a bank is a iova_region which is a independent iommu-domain.
the iova range for each iommu-domain can't cross 4G.
Signed-off-by: Yong Wu
Acked-by: Krzysztof Kozlowski
---
drivers/iommu/mtk_iommu.c | 12 +---
drivers/memory/mtk-smi.c | 7 +++
include/soc/mediatek/smi.h | 1 +
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c3a6712c497b..f206275230b3 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -309,17 +309,23 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
struct device *dev, bool enable)
{
struct mtk_smi_larb_iommu*larb_mmu;
- unsigned int larbid, portid;
+ unsigned int larbid, portid, domid;
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ const struct mtk_iommu_iova_region *region;
int i;
for (i = 0; i < fwspec->num_ids; ++i) {
larbid = MTK_M4U_TO_LARB(fwspec->ids[i]);
portid = MTK_M4U_TO_PORT(fwspec->ids[i]);
+ domid = MTK_M4U_TO_DOM(fwspec->ids[i]);
+
larb_mmu = >larb_imu[larbid];
+ region = data->plat_data->iova_region + domid;
+ larb_mmu->bank[portid] = upper_32_bits(region->iova_base);
- dev_dbg(dev, "%s iommu port: %d\n",
- enable ? "enable" : "disable", portid);
+ dev_dbg(dev, "%s iommu for larb(%s) port %d dom %d bank %d.\n",
+ enable ? "enable" : "disable", dev_name(larb_mmu->dev),
+ portid, domid, larb_mmu->bank[portid]);
if (enable)
larb_mmu->mmu |= MTK_SMI_MMU_EN(portid);
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 2beb67908f3c..2094e4b4eb10 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -44,6 +44,10 @@
/* mt2712 */
#define SMI_LARB_NONSEC_CON(id)(0x380 + ((id) * 4))
#define F_MMU_EN BIT(0)
+#define BANK_SEL(id) ({ \
+ u32 _id = (id) & 0x3; \
+ (_id << 8 | _id << 10 | _id << 12 | _id << 14); \
+})
/* SMI COMMON */
#define SMI_BUS_SEL0x220
@@ -88,6 +92,7 @@ struct mtk_smi_larb { /* larb: local arbiter */
const struct mtk_smi_larb_gen *larb_gen;
int larbid;
u32 *mmu;
+ unsigned char *bank;
};
static int mtk_smi_clk_enable(const struct mtk_smi *smi)
@@ -154,6 +159,7 @@ mtk_smi_larb_bind(struct device *dev, struct device
*master, void *data)
if (dev == larb_mmu[i].dev) {
larb->larbid = i;
larb->mmu = _mmu[i].mmu;
+ larb->bank = larb_mmu[i].bank;
return 0;
}
}
@@ -172,6 +178,7 @@ static void mtk_smi_larb_config_port_gen2_general(struct
device *dev)
for_each_set_bit(i, (unsigned long *)larb->mmu, 32) {
reg = readl_relaxed(larb->base + SMI_LARB_NONSEC_CON(i));
reg |= F_MMU_EN;
+ reg |= BANK_SEL(larb->bank[i]);
writel(reg, larb->base + SMI_LARB_NONSEC_CON(i));
}
}
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 9371bf572ab8..4cf445dbbdaa 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -16,6 +16,7 @@
struct mtk_smi_larb_iommu {
struct device *dev;
unsigned int mmu;
+ unsigned char bank[32];
};
/*
--
2.18.0
Re: [BUG] SPI broken for SPI based panel drivers
Hi, On Sat, 5 Dec 2020 08:04:25 +0100 "H. Nikolaus Schaller" wrote: > Hi Linus, > > > Am 05.12.2020 um 01:25 schrieb Linus Walleij : > > > > On Fri, Dec 4, 2020 at 5:52 PM H. Nikolaus Schaller > > wrote: > > > >> But what I don't know is if I can omit spi-cs-high and have to keep > >> ACTIVE_HIGH (my revert patch) or also change to ACTIVE_LOW (my additional > >> patch). This is arbitrary and someone has to decide what it should be. > > (...) > >> I'd prefer if you or maybe Linus could submit such a patch and I am happy > >> to review it. > > > > It seems really ill-advised to have me do that since I have not > > managed very well to deal with this. Clearly better developers > > are needed. But I can review a patch and see if it makes me > > smarter :) Hmm, if those developers are not available, then probably finding those bugs has to be time-optimized, like establishing better automatic display testing. > > I find it interesting that so far nobody wants to take responsibility > for a decision and to write down the behaviour really should be. Coding > is the second step then. > well, the interesting people are not involved yet (DTML) because no patch is sent. > Anyways you did not cite the really important part of my mail. So let me > copy it back. Here it is again: > > > What I can do is to provide just a skeleton for the table that you or Linus > > can fix/fill in and make a patch out of it. Is attached and the ??? is > > something you should discuss and define. > > Please take the attached diff, comment it here and define the question marks > according to your intention and then make a patch for the YAML bindings out > of it. (I can't do because I don't know your intentions and what to write into > the commit message). > Well, I the easiest step forward is just to document clearer how things behave now, so the commit message is just something like "Behavior of CS signal is not clearly documented, clarify the documentation". And then send the patch to the proper mailing lists including devicetree folks. Regards, Andreas > As soon as we have settled this, we can check if code is correct and really > define if my device tree fits and which change it needs exactly. > > BR and thanks, > Nikolaus > > [slightly edited] > > diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml > b/Documentation/devicetree/bindings/spi/spi-controller.yaml > index 1b56d5e40f1f..4f8755dabecc 100644 > --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml > +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml > @@ -42,6 +42,30 @@ properties: > cs2 : 1 0 > cs3 : 2 0 > > + The second flag of a gpio descriptor can be GPIO_ACTIVE_HIGH/0 > + or GPIO_ACTIVE_LOW/1. > + > + There is a special rule set for combining the second flag of an > + cs-gpio with the optional spi-cs-high flag for SPI slaves. > + > + Each table entry defines how the CS pin is physically driven > + (not considering potential gpio inversions by pinmux): > + > + device node | cs-gpio | CS pin state active | Note > + +===+=+= > + spi-cs-high | - | H | > + - | - | L | > + spi-cs-high | ACTIVE_HIGH | H | > + - | ACTIVE_HIGH | L (or H ???)| 1 > + spi-cs-high | ACTIVE_LOW| H (or L ???)| 2 > + - | ACTIVE_LOW| L | > + > + Notes: > + 1) should print a warning about polarity inversion > + because here it would be wise to define the gpio as ACTIVE_LOW > + 2) could print a warning about polarity inversion > + because ACTIVE_LOW is overridden by spi-cs-high > + 3) Effectively this rule defines that the ACTIVE level of the > + gpio has to be ignored > + > num-cs: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > > >
[PATCH v5 27/27] MAINTAINERS: Add entry for MediaTek IOMMU
I am the author of MediaTek iommu driver, and will to maintain and develop it further. Add myself to cover these items. Signed-off-by: Yong Wu Reviewed-by: Chun-Kuang Hu --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e73636b75f29..462a87ee19c8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11056,6 +11056,15 @@ S: Maintained F: Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt F: drivers/i2c/busses/i2c-mt65xx.c +MEDIATEK IOMMU DRIVER +M: Yong Wu +L: io...@lists.linux-foundation.org +L: linux-media...@lists.infradead.org (moderated for non-subscribers) +S: Supported +F: Documentation/devicetree/bindings/iommu/mediatek* +F: drivers/iommu/mtk-iommu* +F: include/dt-bindings/memory/mt*-larb-port.h + MEDIATEK JPEG DRIVER M: Rick Chang M: Bin Liu -- 2.18.0
[PATCH v5 14/27] iommu/mediatek: Move hw_init into attach_device
In attach device, it will update the pagetable base address register.
Move the hw_init function also here. Then it only need call
pm_runtime_get/put one time here if m4u has power domain.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 1bc5e881951c..39478cfbe0f1 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -126,6 +126,8 @@ struct mtk_iommu_domain {
static const struct iommu_ops mtk_iommu_ops;
+static int mtk_iommu_hw_init(const struct mtk_iommu_data *data);
+
/*
* In M4U 4GB mode, the physical address is remapped as below:
*
@@ -381,12 +383,16 @@ static int mtk_iommu_attach_device(struct iommu_domain
*domain,
{
struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+ int ret;
if (!data)
return -ENODEV;
/* Update the pgtable base address register of the M4U HW */
if (!data->m4u_dom) {
+ ret = mtk_iommu_hw_init(data);
+ if (ret)
+ return ret;
data->m4u_dom = dom;
writel(dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK,
data->base + REG_MMU_PT_BASE_ADDR);
@@ -730,10 +736,6 @@ static int mtk_iommu_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
- ret = mtk_iommu_hw_init(data);
- if (ret)
- return ret;
-
ret = iommu_device_sysfs_add(>iommu, dev, NULL,
"mtk-iommu.%pa", );
if (ret)
--
2.18.0
[PATCH v5 26/27] iommu/mediatek: Add mt8192 support
Add mt8192 iommu support.
For multi domain, Add 1M gap for the vdec domain size. That is because
vdec HW has a end address register which require (start_addr +
len) rather than (start_addr + len - 1). Take a example, if the start_addr
is 0xfff0, size is 0x10, then the end_address is 0xfff0 +
0x10 = 0x1 . but the register only is 32bit. thus HW will get
the end address is 0. To avoid this issue, I add 1M gap for this.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 22 ++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 92c1e2f0af89..799adf7b39d3 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -174,6 +174,16 @@ static const struct mtk_iommu_iova_region single_domain[]
= {
{.iova_base = 0,.size = SZ_4G},
};
+static const struct mtk_iommu_iova_region mt8192_multi_dom[] = {
+ { .iova_base = 0x0, .size = SZ_4G}, /* disp: 0 ~ 4G
*/
+ #if IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT)
+ { .iova_base = SZ_4G, .size = SZ_4G - SZ_1M}, /* vdec: 4G ~
8G gap: 1M */
+ { .iova_base = SZ_4G * 2, .size = SZ_4G - SZ_1M}, /* CAM/MDP: 8G
~ 12G */
+ { .iova_base = 0x24000ULL, .size = 0x400}, /* CCU0 */
+ { .iova_base = 0x24400ULL, .size = 0x400}, /* CCU1 */
+ #endif
+};
+
/*
* There may be 1 or 2 M4U HWs, But we always expect they are in the same
domain
* for the performance.
@@ -1035,12 +1045,24 @@ static const struct mtk_iommu_plat_data mt8183_data = {
.larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
};
+static const struct mtk_iommu_plat_data mt8192_data = {
+ .m4u_plat = M4U_MT8192,
+ .flags = HAS_BCLK | HAS_SUB_COMM | OUT_ORDER_WR_EN |
+ WR_THROT_EN | IOVA_34_EN,
+ .inv_sel_reg= REG_MMU_INV_SEL_GEN2,
+ .iova_region= mt8192_multi_dom,
+ .iova_region_nr = ARRAY_SIZE(mt8192_multi_dom),
+ .larbid_remap = {{0}, {1}, {4, 5}, {7}, {2}, {9, 11, 19, 20},
+ {0, 14, 16}, {0, 13, 18, 17}},
+};
+
static const struct of_device_id mtk_iommu_of_ids[] = {
{ .compatible = "mediatek,mt2712-m4u", .data = _data},
{ .compatible = "mediatek,mt6779-m4u", .data = _data},
{ .compatible = "mediatek,mt8167-m4u", .data = _data},
{ .compatible = "mediatek,mt8173-m4u", .data = _data},
{ .compatible = "mediatek,mt8183-m4u", .data = _data},
+ { .compatible = "mediatek,mt8192-m4u", .data = _data},
{}
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index b54862307128..e96b1b8639f4 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -43,6 +43,7 @@ enum mtk_iommu_plat {
M4U_MT8167,
M4U_MT8173,
M4U_MT8183,
+ M4U_MT8192,
};
struct mtk_iommu_iova_region;
--
2.18.0
Re: [PATCH v1 bpf-next 03/11] tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.
From: Martin KaFai Lau Date: Tue, 8 Dec 2020 19:09:03 -0800 > On Tue, Dec 08, 2020 at 05:17:48PM +0900, Kuniyuki Iwashima wrote: > > From: Martin KaFai Lau > > Date: Mon, 7 Dec 2020 23:34:41 -0800 > > > On Tue, Dec 08, 2020 at 03:31:34PM +0900, Kuniyuki Iwashima wrote: > > > > From: Martin KaFai Lau > > > > Date: Mon, 7 Dec 2020 12:33:15 -0800 > > > > > On Thu, Dec 03, 2020 at 11:14:24PM +0900, Kuniyuki Iwashima wrote: > > > > > > From: Eric Dumazet > > > > > > Date: Tue, 1 Dec 2020 16:25:51 +0100 > > > > > > > On 12/1/20 3:44 PM, Kuniyuki Iwashima wrote: > > > > > > > > This patch lets reuseport_detach_sock() return a pointer of > > > > > > > > struct sock, > > > > > > > > which is used only by inet_unhash(). If it is not NULL, > > > > > > > > inet_csk_reqsk_queue_migrate() migrates > > > > > > > > TCP_ESTABLISHED/TCP_SYN_RECV > > > > > > > > sockets from the closing listener to the selected one. > > > > > > > > > > > > > > > > Listening sockets hold incoming connections as a linked list of > > > > > > > > struct > > > > > > > > request_sock in the accept queue, and each request has > > > > > > > > reference to a full > > > > > > > > socket and its listener. In inet_csk_reqsk_queue_migrate(), we > > > > > > > > only unlink > > > > > > > > the requests from the closing listener's queue and relink them > > > > > > > > to the head > > > > > > > > of the new listener's queue. We do not process each request and > > > > > > > > its > > > > > > > > reference to the listener, so the migration completes in O(1) > > > > > > > > time > > > > > > > > complexity. However, in the case of TCP_SYN_RECV sockets, we > > > > > > > > take special > > > > > > > > care in the next commit. > > > > > > > > > > > > > > > > By default, the kernel selects a new listener randomly. In > > > > > > > > order to pick > > > > > > > > out a different socket every time, we select the last element > > > > > > > > of socks[] as > > > > > > > > the new listener. This behaviour is based on how the kernel > > > > > > > > moves sockets > > > > > > > > in socks[]. (See also [1]) > > > > > > > > > > > > > > > > Basically, in order to redistribute sockets evenly, we have to > > > > > > > > use an eBPF > > > > > > > > program called in the later commit, but as the side effect of > > > > > > > > such default > > > > > > > > selection, the kernel can redistribute old requests evenly to > > > > > > > > new listeners > > > > > > > > for a specific case where the application replaces listeners by > > > > > > > > generations. > > > > > > > > > > > > > > > > For example, we call listen() for four sockets (A, B, C, D), > > > > > > > > and close the > > > > > > > > first two by turns. The sockets move in socks[] like below. > > > > > > > > > > > > > > > > socks[0] : A <-. socks[0] : D socks[0] : D > > > > > > > > socks[1] : B | => socks[1] : B <-. => socks[1] : C > > > > > > > > socks[2] : C | socks[2] : C --' > > > > > > > > socks[3] : D --' > > > > > > > > > > > > > > > > Then, if C and D have newer settings than A and B, and each > > > > > > > > socket has a > > > > > > > > request (a, b, c, d) in their accept queue, we can redistribute > > > > > > > > old > > > > > > > > requests evenly to new listeners. > > > > > > > > > > > > > > > > socks[0] : A (a) <-. socks[0] : D (a + d) socks[0] > > > > > > > > : D (a + d) > > > > > > > > socks[1] : B (b) | => socks[1] : B (b) <-. => socks[1] > > > > > > > > : C (b + c) > > > > > > > > socks[2] : C (c) | socks[2] : C (c) --' > > > > > > > > socks[3] : D (d) --' > > > > > > > > > > > > > > > > Here, (A, D) or (B, C) can have different application settings, > > > > > > > > but they > > > > > > > > MUST have the same settings at the socket API level; otherwise, > > > > > > > > unexpected > > > > > > > > error may happen. For instance, if only the new listeners have > > > > > > > > TCP_SAVE_SYN, old requests do not have SYN data, so the > > > > > > > > application will > > > > > > > > face inconsistency and cause an error. > > > > > > > > > > > > > > > > Therefore, if there are different kinds of sockets, we must > > > > > > > > attach an eBPF > > > > > > > > program described in later commits. > > > > > > > > > > > > > > > > Link: > > > > > > > > https://lore.kernel.org/netdev/CAEfhGiyG8Y_amDZ2C8dQoQqjZJMHjTY76b=KBkTKcBtA=dh...@mail.gmail.com/ > > > > > > > > Reviewed-by: Benjamin Herrenschmidt > > > > > > > > Signed-off-by: Kuniyuki Iwashima > > > > > > > > --- > > > > > > > > include/net/inet_connection_sock.h | 1 + > > > > > > > > include/net/sock_reuseport.h | 2 +- > > > > > > > > net/core/sock_reuseport.c | 10 +- > > > > > > > > net/ipv4/inet_connection_sock.c| 30 > > > > > > > > ++ > > > > > > > > net/ipv4/inet_hashtables.c | 9 +++-- > > > > > > > > 5 files changed, 48 insertions(+), 4 deletions(-) > > > > > > > >
[PATCH v5 25/27] iommu/mediatek: Adjust the structure
Add "struct mtk_iommu_data *" in the "struct mtk_iommu_domain",
reduce the call mtk_iommu_get_m4u_data().
No functional change.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 160690d56bd2..92c1e2f0af89 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -126,6 +126,7 @@ struct mtk_iommu_domain {
struct io_pgtable_cfg cfg;
struct io_pgtable_ops *iop;
+ struct mtk_iommu_data *data;
struct iommu_domain domain;
};
@@ -353,7 +354,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom)
{
- struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
+ struct mtk_iommu_data *data = dom->data;
/* Use the exist domain as there is only one m4u pgtable here. */
if (data->m4u_dom) {
@@ -402,6 +403,7 @@ static struct iommu_domain *mtk_iommu_domain_alloc(unsigned
type)
if (iommu_get_dma_cookie(>domain))
goto free_dom;
+ dom->data = data;
if (mtk_iommu_domain_finalise(dom))
goto put_dma_cookie;
@@ -482,10 +484,9 @@ static int mtk_iommu_map(struct iommu_domain *domain,
unsigned long iova,
phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
- struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
/* The "4GB mode" M4U physically can not use the lower remap of Dram. */
- if (data->enable_4GB)
+ if (dom->data->enable_4GB)
paddr |= BIT_ULL(32);
/* Synchronize with the tlb_lock */
@@ -503,31 +504,32 @@ static size_t mtk_iommu_unmap(struct iommu_domain *domain,
static void mtk_iommu_flush_iotlb_all(struct iommu_domain *domain)
{
- mtk_iommu_tlb_flush_all(mtk_iommu_get_m4u_data());
+ struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+
+ mtk_iommu_tlb_flush_all(dom->data);
}
static void mtk_iommu_iotlb_sync(struct iommu_domain *domain,
struct iommu_iotlb_gather *gather)
{
- struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
+ struct mtk_iommu_domain *dom = to_mtk_domain(domain);
size_t length = gather->end - gather->start;
if (gather->start == ULONG_MAX)
return;
mtk_iommu_tlb_flush_range_sync(gather->start, length, gather->pgsize,
- data);
+ dom->data);
}
static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
dma_addr_t iova)
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
- struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
phys_addr_t pa;
pa = dom->iop->iova_to_phys(dom->iop, iova);
- if (data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE)
+ if (dom->data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE)
pa &= ~BIT_ULL(32);
return pa;
--
2.18.0
Re: [PATCH] vdpa/mlx5: Use write memory barrier after updating CQ index
On Wed, Dec 09, 2020 at 08:58:46AM +0200, Eli Cohen wrote:
> On Wed, Dec 09, 2020 at 01:46:22AM -0500, Michael S. Tsirkin wrote:
> > On Wed, Dec 09, 2020 at 08:02:30AM +0200, Eli Cohen wrote:
> > > On Tue, Dec 08, 2020 at 04:45:04PM -0500, Michael S. Tsirkin wrote:
> > > > On Sun, Dec 06, 2020 at 12:57:19PM +0200, Eli Cohen wrote:
> > > > > Make sure to put write memory barrier after updating CQ consumer index
> > > > > so the hardware knows that there are available CQE slots in the queue.
> > > > >
> > > > > Failure to do this can cause the update of the RX doorbell record to
> > > > > get
> > > > > updated before the CQ consumer index resulting in CQ overrun.
> > > > >
> > > > > Change-Id: Ib0ae4c118cce524c9f492b32569179f3c1f04cc1
> > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
> > > > > devices")
> > > > > Signed-off-by: Eli Cohen
> > > >
> > > > Aren't both memory writes?
> > >
> > > Not sure what exactly you mean here.
> >
> > Both updates are CPU writes into RAM that hardware then reads
> > using DMA.
> >
>
> You mean why I did not put a memory barrier right after updating the
> recieve doorbell record?
Sorry about being unclear. I just tried to give justification for why
dma_wmb seems more appropriate than wmb here. If you need to
order memory writes wrt writes to card, that is different, but generally
writeX and friends will handle the ordering for you, except when
using relaxed memory mappings - then wmb is generally necessary.
> I thought about this and I think it is not required. Suppose it takes a
> very long time till the hardware can actually see this update. The worst
> effect would be that the hardware will drop received packets if it does
> sees none available due to the delayed update. Eventually it will see
> the update and will continue working.
>
> If I put a memory barrier, I put some delay waiting for the CPU to flush
> the write before continuing. I tried both options while checking packet
> rate on couldn't see noticable difference in either case.
makes sense.
> > > > And given that, isn't dma_wmb() sufficient here?
> > >
> > > I agree that dma_wmb() is more appropriate here.
> > >
> > > >
> > > >
> > > > > ---
> > > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 5 +
> > > > > 1 file changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > index 1f4089c6f9d7..295f46eea2a5 100644
> > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > @@ -478,6 +478,11 @@ static int mlx5_vdpa_poll_one(struct
> > > > > mlx5_vdpa_cq *vcq)
> > > > > static void mlx5_vdpa_handle_completions(struct mlx5_vdpa_virtqueue
> > > > > *mvq, int num)
> > > > > {
> > > > > mlx5_cq_set_ci(>cq.mcq);
> > > > > +
> > > > > + /* make sure CQ cosumer update is visible to the hardware
> > > > > before updating
> > > > > + * RX doorbell record.
> > > > > + */
> > > > > + wmb();
> > > > > rx_post(>vqqp, num);
> > > > > if (mvq->event_cb.callback)
> > > > > mvq->event_cb.callback(mvq->event_cb.private);
> > > > > --
> > > > > 2.27.0
> > > >
> >
[PATCH v5 15/27] iommu/mediatek: Add fail handle for sysfs_add and device_register
Add fail handle for iommu_device_sysfs_add and iommu_device_register.
Fixes: b16c0170b53c ("iommu/mediatek: Make use of iommu_device_register
interface")
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 39478cfbe0f1..09c8c58feb78 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -746,7 +746,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
ret = iommu_device_register(>iommu);
if (ret)
- return ret;
+ goto out_sysfs_remove;
spin_lock_init(>tlb_lock);
list_add_tail(>list, );
@@ -754,7 +754,16 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (!iommu_present(_bus_type))
bus_set_iommu(_bus_type, _iommu_ops);
- return component_master_add_with_match(dev, _iommu_com_ops, match);
+ ret = component_master_add_with_match(dev, _iommu_com_ops, match);
+ if (ret)
+ goto out_dev_unreg;
+ return ret;
+
+out_dev_unreg:
+ iommu_device_unregister(>iommu);
+out_sysfs_remove:
+ iommu_device_sysfs_remove(>iommu);
+ return ret;
}
static int mtk_iommu_remove(struct platform_device *pdev)
--
2.18.0
[PATCH v5 23/27] iommu/mediatek: Support report iova 34bit translation fault in ISR
If the iova is over 32bit, the fault status register bit is a little
different.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 164479e1f5c5..ed771133643d 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -3,6 +3,7 @@
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu
*/
+#include
#include
#include
#include
@@ -89,6 +90,9 @@
#define F_REG_MMU1_FAULT_MASK GENMASK(13, 7)
#define REG_MMU0_FAULT_VA 0x13c
+#define F_MMU_INVAL_VA_31_12_MASK GENMASK(31, 12)
+#define F_MMU_INVAL_VA_34_32_MASK GENMASK(11, 9)
+#define F_MMU_INVAL_PA_34_32_MASK GENMASK(8, 6)
#define F_MMU_FAULT_VA_WRITE_BIT BIT(1)
#define F_MMU_FAULT_VA_LAYER_BIT BIT(0)
@@ -264,8 +268,9 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
{
struct mtk_iommu_data *data = dev_id;
struct mtk_iommu_domain *dom = data->m4u_dom;
- u32 int_state, regval, fault_iova, fault_pa;
unsigned int fault_larb, fault_port, sub_comm = 0;
+ u32 int_state, regval, va34_32, pa34_32;
+ u64 fault_iova, fault_pa;
bool layer, write;
/* Read error info from registers */
@@ -281,6 +286,14 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
}
layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
+ if (MTK_IOMMU_HAS_FLAG(data->plat_data, IOVA_34_EN)) {
+ va34_32 = FIELD_GET(F_MMU_INVAL_VA_34_32_MASK, fault_iova);
+ pa34_32 = FIELD_GET(F_MMU_INVAL_PA_34_32_MASK, fault_iova);
+ fault_iova = fault_iova & F_MMU_INVAL_VA_31_12_MASK;
+ fault_iova |= (u64)va34_32 << 32;
+ fault_pa |= (u64)pa34_32 << 32;
+ }
+
fault_port = F_MMU_INT_ID_PORT_ID(regval);
if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_SUB_COMM)) {
fault_larb = F_MMU_INT_ID_COMM_ID(regval);
@@ -294,7 +307,7 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
dev_err_ratelimited(
data->dev,
- "fault type=0x%x iova=0x%x pa=0x%x larb=%d port=%d
layer=%d %s\n",
+ "fault type=0x%x iova=0x%llx pa=0x%llx larb=%d port=%d
layer=%d %s\n",
int_state, fault_iova, fault_pa, fault_larb, fault_port,
layer, write ? "write" : "read");
}
--
2.18.0
[PATCH v5 18/27] iommu/mediatek: Add power-domain operation
In the previous SoC, the M4U HW is in the EMI power domain which is
always on. the latest M4U is in the display power domain which may be
turned on/off, thus we have to add pm_runtime interface for it.
When the engine work, the engine always enable the power and clocks for
smi-larb/smi-common, then the M4U's power will always be powered on
automatically via the device link with smi-common.
Note: we don't enable the M4U power in iommu_map/unmap for tlb flush.
If its power already is on, of course it is ok. if the power is off,
the main tlb will be reset while M4U power on, thus the tlb flush while
m4u power off is unnecessary, just skip it.
There will be one case that pm runctime status is not expected when tlb
flush. After boot, the display may call dma_alloc_attrs before it call
pm_runtime_get(disp-dev), then the m4u's pm status is not active inside
the dma_alloc_attrs. Since it only happens after boot, the tlb is clean
at that time, I also think this is ok.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 41 +--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6fe3ee2b2bf5..0e9c03cbab32 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -184,6 +184,8 @@ static void mtk_iommu_tlb_flush_all(void *cookie)
struct mtk_iommu_data *data = cookie;
for_each_m4u(data) {
+ if (!pm_runtime_active(data->dev))
+ continue;
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
data->base + data->plat_data->inv_sel_reg);
writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
@@ -200,6 +202,10 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long
iova, size_t size,
u32 tmp;
for_each_m4u(data) {
+ /* skip tlb flush when pm is not active. */
+ if (!pm_runtime_active(data->dev))
+ continue;
+
spin_lock_irqsave(>tlb_lock, flags);
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
data->base + data->plat_data->inv_sel_reg);
@@ -384,6 +390,8 @@ static int mtk_iommu_attach_device(struct iommu_domain
*domain,
{
struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+ struct device *m4udev = data->dev;
+ bool pm_enabled = pm_runtime_enabled(m4udev);
int ret;
if (!data)
@@ -391,12 +399,25 @@ static int mtk_iommu_attach_device(struct iommu_domain
*domain,
/* Update the pgtable base address register of the M4U HW */
if (!data->m4u_dom) {
+ if (pm_enabled) {
+ ret = pm_runtime_get_sync(m4udev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(m4udev);
+ return ret;
+ }
+ }
ret = mtk_iommu_hw_init(data);
- if (ret)
+ if (ret) {
+ if (pm_enabled)
+ pm_runtime_put(m4udev);
return ret;
+ }
data->m4u_dom = dom;
writel(dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK,
data->base + REG_MMU_PT_BASE_ADDR);
+
+ if (pm_enabled)
+ pm_runtime_put(m4udev);
}
mtk_iommu_config(data, dev, true);
@@ -747,10 +768,13 @@ static int mtk_iommu_probe(struct platform_device *pdev)
if (dev->pm_domain) {
struct device_link *link;
+ pm_runtime_enable(dev);
+
link = device_link_add(data->smicomm_dev, dev,
DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
if (!link) {
dev_err(dev, "Unable link %s.\n",
dev_name(data->smicomm_dev));
+ pm_runtime_disable(dev);
return -EINVAL;
}
}
@@ -785,8 +809,10 @@ static int mtk_iommu_probe(struct platform_device *pdev)
out_sysfs_remove:
iommu_device_sysfs_remove(>iommu);
out_link_remove:
- if (dev->pm_domain)
+ if (dev->pm_domain) {
device_link_remove(data->smicomm_dev, dev);
+ pm_runtime_disable(dev);
+ }
return ret;
}
@@ -801,8 +827,10 @@ static int mtk_iommu_remove(struct platform_device *pdev)
bus_set_iommu(_bus_type, NULL);
clk_disable_unprepare(data->bclk);
- if (pdev->dev.pm_domain)
+ if (pdev->dev.pm_domain) {
device_link_remove(data->smicomm_dev, >dev);
+ pm_runtime_disable(>dev);
+ }
devm_free_irq(>dev, data->irq, data);
component_master_del(>dev, _iommu_com_ops);
return 0;
@@ -834,6
[PATCH v5 20/27] iommu/mediatek: Add single domain
Defaultly the iova range is 0-4G. here we add a single-domain(0-4G)
for the previous SoC. this also is a preparing patch for supporting
multi-domains.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6a909efc984f..c3a6712c497b 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -162,6 +162,10 @@ struct mtk_iommu_iova_region {
unsigned long long size;
};
+static const struct mtk_iommu_iova_region single_domain[] = {
+ {.iova_base = 0,.size = SZ_4G},
+};
+
/*
* There may be 1 or 2 M4U HWs, But we always expect they are in the same
domain
* for the performance.
@@ -936,6 +940,8 @@ static const struct mtk_iommu_plat_data mt2712_data = {
.m4u_plat = M4U_MT2712,
.flags= HAS_4GB_MODE | HAS_BCLK | HAS_VLD_PA_RNG,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
.larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
};
@@ -943,6 +949,8 @@ static const struct mtk_iommu_plat_data mt6779_data = {
.m4u_plat = M4U_MT6779,
.flags = HAS_SUB_COMM | OUT_ORDER_WR_EN | WR_THROT_EN,
.inv_sel_reg = REG_MMU_INV_SEL_GEN2,
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
.larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
};
@@ -950,6 +958,8 @@ static const struct mtk_iommu_plat_data mt8167_data = {
.m4u_plat = M4U_MT8167,
.flags= RESET_AXI | HAS_LEGACY_IVRP_PADDR,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
.larbid_remap = {{0}, {1}, {2}}, /* Linear mapping. */
};
@@ -958,6 +968,8 @@ static const struct mtk_iommu_plat_data mt8173_data = {
.flags= HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
HAS_LEGACY_IVRP_PADDR,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
.larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
};
@@ -965,6 +977,8 @@ static const struct mtk_iommu_plat_data mt8183_data = {
.m4u_plat = M4U_MT8183,
.flags= RESET_AXI,
.inv_sel_reg = REG_MMU_INV_SEL_GEN1,
+ .iova_region = single_domain,
+ .iova_region_nr = ARRAY_SIZE(single_domain),
.larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
};
--
2.18.0
[PATCH v5 24/27] iommu/mediatek: Add support for multi domain
Some HW IP(ex: CCU) require the special iova range. That means the
iova got from dma_alloc_attrs for that devices must locate in his
special range. In this patch, we allocate a special iova_range for
each a special requirement and create each a iommu domain for each
a iova_range.
meanwhile we still use one pagetable which support 16GB iova.
After this patch, If the iova range of a master is over 4G, the master
should:
a) Declare its special dma_ranges in its dtsi node. For example, If we
preassign the iova 4G-8G for vcodec, then the vcodec dtsi node should
add this:
/*
* iova start at 0x1__, pa still start at 0x4000_
* size is 0x1__.
*/
dma-ranges = <0x1 0x0 0x0 0x4000 0x1 0x0>; /* 4G ~ 8G */
Note: we don't have a actual bus concept here. the master doesn't have its
special parent node, thus this dma-ranges can only be put in the master's
node.
b) Update the dma_mask:
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(33));
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 47 +++
drivers/iommu/mtk_iommu.h | 3 ++-
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index ed771133643d..160690d56bd2 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -355,6 +355,14 @@ static int mtk_iommu_domain_finalise(struct
mtk_iommu_domain *dom)
{
struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
+ /* Use the exist domain as there is only one m4u pgtable here. */
+ if (data->m4u_dom) {
+ dom->iop = data->m4u_dom->iop;
+ dom->cfg = data->m4u_dom->cfg;
+ dom->domain.pgsize_bitmap = data->m4u_dom->cfg.pgsize_bitmap;
+ return 0;
+ }
+
dom->cfg = (struct io_pgtable_cfg) {
.quirks = IO_PGTABLE_QUIRK_ARM_NS |
IO_PGTABLE_QUIRK_NO_PERMS |
@@ -380,6 +388,8 @@ static int mtk_iommu_domain_finalise(struct
mtk_iommu_domain *dom)
static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type)
{
+ struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
+ const struct mtk_iommu_iova_region *region;
struct mtk_iommu_domain *dom;
if (type != IOMMU_DOMAIN_DMA)
@@ -395,8 +405,9 @@ static struct iommu_domain *mtk_iommu_domain_alloc(unsigned
type)
if (mtk_iommu_domain_finalise(dom))
goto put_dma_cookie;
- dom->domain.geometry.aperture_start = 0;
- dom->domain.geometry.aperture_end = DMA_BIT_MASK(32);
+ region = data->plat_data->iova_region + data->cur_domid;
+ dom->domain.geometry.aperture_start = region->iova_base;
+ dom->domain.geometry.aperture_end = region->iova_base + region->size -
1;
dom->domain.geometry.force_aperture = true;
return >domain;
@@ -548,19 +559,31 @@ static void mtk_iommu_release_device(struct device *dev)
static struct iommu_group *mtk_iommu_device_group(struct device *dev)
{
struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct iommu_group *group;
+ int domid;
if (!data)
return ERR_PTR(-ENODEV);
- /* All the client devices are in the same m4u iommu-group */
- if (!data->m4u_group) {
- data->m4u_group = iommu_group_alloc();
- if (IS_ERR(data->m4u_group))
+ domid = MTK_M4U_TO_DOM(fwspec->ids[0]);
+ if (domid >= data->plat_data->iova_region_nr) {
+ dev_err(dev, "iommu domain id(%d/%d) is error.\n", domid,
+ data->plat_data->iova_region_nr);
+ return ERR_PTR(-EINVAL);
+ }
+
+ group = data->m4u_group[domid];
+ if (!group) {
+ group = iommu_group_alloc();
+ if (IS_ERR(group))
dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+ data->m4u_group[domid] = group;
} else {
- iommu_group_ref_get(data->m4u_group);
+ iommu_group_ref_get(group);
}
- return data->m4u_group;
+ data->cur_domid = domid;
+ return group;
}
static int mtk_iommu_of_xlate(struct device *dev, struct of_phandle_args *args)
@@ -589,14 +612,20 @@ static void mtk_iommu_get_resv_regions(struct device *dev,
struct list_head *head)
{
struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
- const struct mtk_iommu_iova_region *resv;
+ const struct mtk_iommu_iova_region *resv, *curdom;
struct iommu_resv_region *region;
int prot = IOMMU_WRITE | IOMMU_READ;
unsigned int i;
+ curdom = data->plat_data->iova_region + data->cur_domid;
for (i = 0; i < data->plat_data->iova_region_nr; i++) {
resv = data->plat_data->iova_region + i;
+ /* Only
[PATCH v5 22/27] iommu/mediatek: Support up to 34bit iova in tlb flush
If the iova is 34bit, the iova[32][33] is the bit0/1 in the tlb flush
register. Add a new macro for this.
there is a minor change unrelated with this patch. it also use the new
macro.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index f206275230b3..164479e1f5c5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -129,6 +129,9 @@ static const struct iommu_ops mtk_iommu_ops;
static int mtk_iommu_hw_init(const struct mtk_iommu_data *data);
+#define MTK_IOMMU_ADDR(addr) ({unsigned long _addr = addr; \
+ (lower_32_bits(_addr) | upper_32_bits(_addr)); })
+
/*
* In M4U 4GB mode, the physical address is remapped as below:
*
@@ -219,8 +222,9 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long
iova, size_t size,
writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
data->base + data->plat_data->inv_sel_reg);
- writel_relaxed(iova, data->base + REG_MMU_INVLD_START_A);
- writel_relaxed(iova + size - 1,
+ writel_relaxed(MTK_IOMMU_ADDR(iova),
+ data->base + REG_MMU_INVLD_START_A);
+ writel_relaxed(MTK_IOMMU_ADDR(iova + size - 1),
data->base + REG_MMU_INVLD_END_A);
writel_relaxed(F_MMU_INV_RANGE,
data->base + REG_MMU_INVALIDATE);
@@ -648,8 +652,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_LEGACY_IVRP_PADDR))
regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
else
- regval = lower_32_bits(data->protect_base) |
-upper_32_bits(data->protect_base);
+ regval = MTK_IOMMU_ADDR(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
if (data->enable_4GB &&
--
2.18.0
[PATCH v5 07/27] iommu/mediatek: Use the common mtk-smi-larb-port.h
Use the common larb-port header in the source code.
Signed-off-by: Yong Wu
Acked-by: Krzysztof Kozlowski
---
drivers/iommu/mtk_iommu.c | 7 ---
drivers/iommu/mtk_iommu.h | 1 +
drivers/memory/mtk-smi.c | 1 +
include/soc/mediatek/smi.h | 2 --
4 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c072cee532c2..6451d83753e1 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -103,13 +103,6 @@
#define MTK_PROTECT_PA_ALIGN 256
-/*
- * Get the local arbiter ID and the portid within the larb arbiter
- * from mtk_m4u_id which is defined by MTK_M4U_ID.
- */
-#define MTK_M4U_TO_LARB(id)(((id) >> 5) & 0xf)
-#define MTK_M4U_TO_PORT(id)((id) & 0x1f)
-
#define HAS_4GB_MODE BIT(0)
/* HW will use the EMI clock if there isn't the "bclk". */
#define HAS_BCLK BIT(1)
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index df32b3e3408b..d0c93652bdbe 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#define MTK_LARB_COM_MAX 8
#define MTK_LARB_SUBCOM_MAX4
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index ac350f8d1e20..2beb67908f3c 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
/* mt8173 */
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 5a34b87d89e3..9371bf572ab8 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -11,8 +11,6 @@
#ifdef CONFIG_MTK_SMI
-#define MTK_LARB_NR_MAX16
-
#define MTK_SMI_MMU_EN(port) BIT(port)
struct mtk_smi_larb_iommu {
--
2.18.0
[PATCH v5 12/27] iommu/io-pgtable-arm-v7s: Quad lvl1 pgtable for MediaTek
The standard input iova bits is 32. MediaTek quad the lvl1 pagetable
(4 * lvl1). No change for lvl2 pagetable. Then the iova bits can reach
34bit.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 0b3c5b904ddc..5601dc8bf810 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -45,9 +45,10 @@
/*
* We have 32 bits total; 12 bits resolved at level 1, 8 bits at level 2,
* and 12 bits in a page.
+ * MediaTek extend 2 bits to reach 34bits, 14 bits at lvl1 and 8 bits at lvl2.
*/
#define ARM_V7S_ADDR_BITS 32
-#define _ARM_V7S_LVL_BITS(lvl, cfg)((lvl) == 1 ? 12 : 8)
+#define _ARM_V7S_LVL_BITS(lvl, cfg)((lvl) == 1 ? ((cfg)->ias - 20) : 8)
#define ARM_V7S_LVL_SHIFT(lvl) ((lvl) == 1 ? 20 : 12)
#define ARM_V7S_TABLE_SHIFT10
@@ -61,7 +62,7 @@
#define _ARM_V7S_IDX_MASK(lvl, cfg)(ARM_V7S_PTES_PER_LVL(lvl, cfg) - 1)
#define ARM_V7S_LVL_IDX(addr, lvl, cfg)({
\
int _l = lvl; \
- ((u32)(addr) >> ARM_V7S_LVL_SHIFT(_l)) & _ARM_V7S_IDX_MASK(_l, cfg); \
+ ((addr) >> ARM_V7S_LVL_SHIFT(_l)) & _ARM_V7S_IDX_MASK(_l, cfg); \
})
/*
@@ -754,7 +755,7 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct
io_pgtable_cfg *cfg,
{
struct arm_v7s_io_pgtable *data;
- if (cfg->ias > ARM_V7S_ADDR_BITS)
+ if (cfg->ias > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
return NULL;
if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 35 : ARM_V7S_ADDR_BITS))
--
2.18.0
[PATCH 4/4] hwmon: Support Aspeed AST2600 PWM/Fan tachometer
Add Aspeed AST2600 PWM/Fan tacho driver. AST2600 has 16 PWM channel and
16 FAN tacho channel.
Signed-off-by: Troy Lee
---
drivers/hwmon/Kconfig| 10 +
drivers/hwmon/Makefile |1 +
drivers/hwmon/aspeed2600-pwm-tacho.c | 1053 ++
3 files changed, 1064 insertions(+)
create mode 100644 drivers/hwmon/aspeed2600-pwm-tacho.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 9aa89d7d4193..097c01430259 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -400,6 +400,16 @@ config SENSORS_ASPEED
This driver can also be built as a module. If so, the module
will be called aspeed_pwm_tacho.
+config SENSORS_ASPEED2600_PWM_TACHO
+tristate "ASPEED AST2600 PWM and Fan Tachometer"
+depends on THERMAL || THERMAL=n
+help
+ This driver provides support for ASPEED AST2600 PWM
+ and Fan Tacho controllers.
+
+ This driver can also be built as a module. If so, the module
+ will be called aspeed2600-pwm-tacho.
+
config SENSORS_ATXP1
tristate "Attansic ATXP1 VID controller"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index ae41ee71a71b..10be45768d36 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_SENSORS_ARM_SCPI)+= scpi-hwmon.o
obj-$(CONFIG_SENSORS_AS370)+= as370-hwmon.o
obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o
obj-$(CONFIG_SENSORS_ASPEED) += aspeed-pwm-tacho.o
+obj-$(CONFIG_SENSORS_ASPEED2600_PWM_TACHO) += aspeed2600-pwm-tacho.o
obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o
obj-$(CONFIG_SENSORS_AXI_FAN_CONTROL) += axi-fan-control.o
obj-$(CONFIG_SENSORS_BT1_PVT) += bt1-pvt.o
diff --git a/drivers/hwmon/aspeed2600-pwm-tacho.c
b/drivers/hwmon/aspeed2600-pwm-tacho.c
new file mode 100644
index ..083eb3b253ff
--- /dev/null
+++ b/drivers/hwmon/aspeed2600-pwm-tacho.c
@@ -0,0 +1,1053 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) ASPEED Technology Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 or later as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+/**
+ * PWM HW register offset define
+ */
+//PWM Control Register
+#define ASPEED_PWM_CTRL_CH(ch) ((ch * 0x10) + 0x00)
+//PWM Duty Cycle Register
+#define ASPEED_PWM_DUTY_CYCLE_CH(ch) ((ch * 0x10) + 0x04)
+//TACH Control Register
+#define ASPEED_TACHO_CTRL_CH(ch) ((ch * 0x10) + 0x08)
+//TACH Status Register
+#define ASPEED_TACHO_STS_CH(x) ((x * 0x10) + 0x0C)
+/**
+ * PWM register Bit field
+ */
+/*PWM_CTRL */
+#define PWM_LOAD_SEL_AS_WDT_BIT (19)//load selection as WDT
+#define PWM_DUTY_LOAD_AS_WDT_EN BIT(18) //enable PWM duty load as WDT
+#define PWM_DUTY_SYNC_DIS BIT(17) //disable PWM duty sync
+#define PWM_CLK_ENABLE BIT(16) //enable PWM clock
+#define PWM_LEVEL_OUTPUT BIT(15) //output PWM level
+#define PWM_INVERSE BIT(14) //inverse PWM pin
+#define PWM_OPEN_DRAIN_EN BIT(13) //enable open-drain
+#define PWM_PIN_ENBIT(12) //enable PWM pin
+#define PWM_CLK_DIV_H_MASK(0xf << 8) //PWM clock division H bit
[3:0]
+#define PWM_CLK_DIV_L_MASK(0xff) //PWM clock division H bit [3:0]
+/* [19] */
+#define LOAD_SEL_FALLING 0
+#define LOAD_SEL_RIGING 1
+
+/*PWM_DUTY_CYCLE */
+#define PWM_PERIOD_BIT(24)//pwm
period bit [7:0]
+#define PWM_PERIOD_BIT_MASK (0xff << 24)//pwm period
bit [7:0]
+#define PWM_RISING_FALLING_AS_WDT_BIT (16)
+#define PWM_RISING_FALLING_AS_WDT_MASK (0xff << 16) //pwm rising/falling
point bit [7:0] as WDT
+#define PWM_RISING_FALLING_MASK (0x)
+#define PWM_FALLING_POINT_BIT (8) //pwm falling point bit
[7:0]
+#define PWM_RISING_POINT_BIT (0) //pwm rising point bit
[7:0]
+/* [31:24] */
+#define DEFAULT_PWM_PERIOD 0xff
+
+/*PWM_TACHO_CTRL */
+#define TACHO_IER BIT(31)
//enable tacho interrupt
+#define TACHO_INVERS_LIMITBIT(30) //inverse tacho
limit comparison
+#define TACHO_LOOPBACKBIT(29) //tacho
loopback
+#define TACHO_ENABLE BIT(28) //{enable tacho}
+#define
[PATCH v5 08/27] iommu/io-pgtable-arm-v7s: Use ias to check the valid iova in unmap
Use the ias for the valid iova checking in arm_v7s_unmap. This is a
preparing patch for supporting iova 34bit for MediaTek.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index a688f22cbe3b..e880745ab1e8 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -717,7 +717,7 @@ static size_t arm_v7s_unmap(struct io_pgtable_ops *ops,
unsigned long iova,
{
struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
- if (WARN_ON(upper_32_bits(iova)))
+ if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias)))
return 0;
return __arm_v7s_unmap(data, gather, iova, size, 1, data->pgd);
--
2.18.0
Re: [PATCH next v2 2/3] printk: change @clear_seq to atomic64_t
On Wed, Dec 09, 2020 at 05:34:19AM +0900, Sergey Senozhatsky wrote:
> On (20/12/04 10:12), Petr Mladek wrote:
> > On Tue 2020-12-01 21:59:40, John Ogness wrote:
> > > Currently @clear_seq access is protected by @logbuf_lock. Once
> > > @logbuf_lock is removed some other form of synchronization will be
> > > required. Change the type of @clear_seq to atomic64_t to provide the
> > > synchronization.
> > >
> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > index fc5e3a7d6d89..e9018c4e1b66 100644
> > > --- a/kernel/printk/printk.c
> > > +++ b/kernel/printk/printk.c
> > > @@ -3412,7 +3418,7 @@ EXPORT_SYMBOL_GPL(kmsg_dump_get_buffer);
> > > */
> > > void kmsg_dump_rewind_nolock(struct kmsg_dumper *dumper)
> > > {
> > > - dumper->cur_seq = clear_seq;
> > > + dumper->cur_seq = atomic64_read(_seq);
> >
> > Sigh, atomic64_read() uses a spin lock in the generic implementation
> > that is used on some architectures.
>
> Oh... So on those archs prb is not lockless in fact, it actually
> takes the spin_lock each time we read the descriptor state?
Yeah, many 32bit archs cannot natively do 64bit atomics and get to use
the horrible hashed spinlock crap.
But it gets even worse, we have a few architectures that cannot do
atomics _at_all_ and _always_ use the horrible hashed spinlock crap for
all atomics, even native word length ones.
I consider these architectures broken crap, and they work mostly by
accident than anything else, but we have them :/ The good new is that
they don't have NMIs either, so that helps.
BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
This stopped happening a while ago, let's close this to get notifications about new instances. One of likely candidates: #syz fix: net: partially revert dynamic lockdep key changes
[PATCH v5 02/27] dt-bindings: memory: mediatek: Add a common larb-port header file
Put all the macros about smi larb/port togethers, this is a preparing patch for extending LARB_NR and adding new dom-id support. Signed-off-by: Yong Wu Acked-by: Rob Herring Acked-by: Krzysztof Kozlowski --- include/dt-bindings/memory/mt2712-larb-port.h | 2 +- include/dt-bindings/memory/mt6779-larb-port.h | 2 +- include/dt-bindings/memory/mt8167-larb-port.h | 2 +- include/dt-bindings/memory/mt8173-larb-port.h | 2 +- include/dt-bindings/memory/mt8183-larb-port.h | 2 +- include/dt-bindings/memory/mtk-smi-larb-port.h | 15 +++ 6 files changed, 20 insertions(+), 5 deletions(-) create mode 100644 include/dt-bindings/memory/mtk-smi-larb-port.h diff --git a/include/dt-bindings/memory/mt2712-larb-port.h b/include/dt-bindings/memory/mt2712-larb-port.h index 6f9aa7349cef..b6b2c6bf4459 100644 --- a/include/dt-bindings/memory/mt2712-larb-port.h +++ b/include/dt-bindings/memory/mt2712-larb-port.h @@ -6,7 +6,7 @@ #ifndef __DTS_IOMMU_PORT_MT2712_H #define __DTS_IOMMU_PORT_MT2712_H -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#include #define M4U_LARB0_ID 0 #define M4U_LARB1_ID 1 diff --git a/include/dt-bindings/memory/mt6779-larb-port.h b/include/dt-bindings/memory/mt6779-larb-port.h index 2ad0899fbf2f..60f57f54393e 100644 --- a/include/dt-bindings/memory/mt6779-larb-port.h +++ b/include/dt-bindings/memory/mt6779-larb-port.h @@ -7,7 +7,7 @@ #ifndef _DTS_IOMMU_PORT_MT6779_H_ #define _DTS_IOMMU_PORT_MT6779_H_ -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#include #define M4U_LARB0_ID0 #define M4U_LARB1_ID1 diff --git a/include/dt-bindings/memory/mt8167-larb-port.h b/include/dt-bindings/memory/mt8167-larb-port.h index 000fb299a408..fcb9a49ec60e 100644 --- a/include/dt-bindings/memory/mt8167-larb-port.h +++ b/include/dt-bindings/memory/mt8167-larb-port.h @@ -8,7 +8,7 @@ #ifndef __DTS_IOMMU_PORT_MT8167_H #define __DTS_IOMMU_PORT_MT8167_H -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#include #define M4U_LARB0_ID 0 #define M4U_LARB1_ID 1 diff --git a/include/dt-bindings/memory/mt8173-larb-port.h b/include/dt-bindings/memory/mt8173-larb-port.h index 9f31ccfeca21..d8c99c946053 100644 --- a/include/dt-bindings/memory/mt8173-larb-port.h +++ b/include/dt-bindings/memory/mt8173-larb-port.h @@ -6,7 +6,7 @@ #ifndef __DTS_IOMMU_PORT_MT8173_H #define __DTS_IOMMU_PORT_MT8173_H -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#include #define M4U_LARB0_ID 0 #define M4U_LARB1_ID 1 diff --git a/include/dt-bindings/memory/mt8183-larb-port.h b/include/dt-bindings/memory/mt8183-larb-port.h index 2c579f305162..275c095a6fd6 100644 --- a/include/dt-bindings/memory/mt8183-larb-port.h +++ b/include/dt-bindings/memory/mt8183-larb-port.h @@ -6,7 +6,7 @@ #ifndef __DTS_IOMMU_PORT_MT8183_H #define __DTS_IOMMU_PORT_MT8183_H -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#include #define M4U_LARB0_ID 0 #define M4U_LARB1_ID 1 diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h new file mode 100644 index ..53354cf4f6e3 --- /dev/null +++ b/include/dt-bindings/memory/mtk-smi-larb-port.h @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2020 MediaTek Inc. + * Author: Yong Wu + */ +#ifndef __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_ +#define __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_ + +#define MTK_LARB_NR_MAX16 + +#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) +#define MTK_M4U_TO_LARB(id)(((id) >> 5) & 0xf) +#define MTK_M4U_TO_PORT(id)((id) & 0x1f) + +#endif -- 2.18.0
[PATCH v5 04/27] dt-bindings: memory: mediatek: Add domain definition
In the latest SoC, there are several HW IP require a sepecial iova range, mainly CCU and VPU has this requirement. Take CCU as a example, CCU require its iova locate in the range(0x4000_ ~ 0x43ff_). In this patch we add a domain definition for the special port. In the example of CCU, If we preassign CCU port in domain1, then iommu driver will prepare a independent iommu domain of the special iova range for it, then the iova got from dma_alloc_attrs(ccu-dev) will locate in its special range. This is a preparing patch for multi-domain support. Signed-off-by: Yong Wu Acked-by: Krzysztof Kozlowski Acked-by: Rob Herring --- include/dt-bindings/memory/mtk-smi-larb-port.h | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h index 7d64103209af..2d4c973c174f 100644 --- a/include/dt-bindings/memory/mtk-smi-larb-port.h +++ b/include/dt-bindings/memory/mtk-smi-larb-port.h @@ -7,9 +7,16 @@ #define __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_ #define MTK_LARB_NR_MAX32 +#define MTK_M4U_DOM_NR_MAX 8 + +#define MTK_M4U_DOM_ID(domid, larb, port) \ + (((domid) & 0x7) << 16 | (((larb) & 0x1f) << 5) | ((port) & 0x1f)) + +/* The default dom id is 0. */ +#define MTK_M4U_ID(larb, port) MTK_M4U_DOM_ID(0, larb, port) -#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) #define MTK_M4U_TO_LARB(id)(((id) >> 5) & 0x1f) #define MTK_M4U_TO_PORT(id)((id) & 0x1f) +#define MTK_M4U_TO_DOM(id) (((id) >> 16) & 0x7) #endif -- 2.18.0
Re: BUG: MAX_LOCKDEP_KEYS too low!
On Sun, Oct 27, 2019 at 4:31 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:65921376 Merge branch 'net-fix-nested-device-bugs' > git tree: net > console output: https://syzkaller.appspot.com/x/log.txt?x=1637fdc0e0 > kernel config: https://syzkaller.appspot.com/x/.config?x=e0ac4d9b35046343 > dashboard link: https://syzkaller.appspot.com/bug?extid=692f39f040c1f415567b > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+692f39f040c1f4155...@syzkaller.appspotmail.com This stopped happening a while ago, let's close this to get notifications about new instances. One of likely candidates: #syz fix: net: partially revert dynamic lockdep key changes > BUG: MAX_LOCKDEP_KEYS too low! > turning off the locking correctness validator. > CPU: 0 PID: 15175 Comm: syz-executor.5 Not tainted 5.4.0-rc3+ #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x172/0x1f0 lib/dump_stack.c:113 > register_lock_class.cold+0x1b/0x27 kernel/locking/lockdep.c:1222 > __lock_acquire+0xf4/0x4a00 kernel/locking/lockdep.c:3837 > lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4487 > __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] > _raw_spin_lock_bh+0x33/0x50 kernel/locking/spinlock.c:175 > spin_lock_bh include/linux/spinlock.h:343 [inline] > netif_addr_lock_bh include/linux/netdevice.h:4055 [inline] > __dev_mc_add+0x2e/0xd0 net/core/dev_addr_lists.c:765 > dev_mc_add+0x20/0x30 net/core/dev_addr_lists.c:783 > igmp6_group_added+0x3b5/0x460 net/ipv6/mcast.c:672 > __ipv6_dev_mc_inc+0x727/0xa60 net/ipv6/mcast.c:931 > ipv6_dev_mc_inc+0x20/0x30 net/ipv6/mcast.c:938 > ipv6_add_dev net/ipv6/addrconf.c:456 [inline] > ipv6_add_dev+0xa3d/0x10b0 net/ipv6/addrconf.c:363 > addrconf_notify+0x97d/0x23b0 net/ipv6/addrconf.c:3491 > notifier_call_chain+0xc2/0x230 kernel/notifier.c:95 > __raw_notifier_call_chain kernel/notifier.c:396 [inline] > raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:403 > call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1668 > call_netdevice_notifiers_extack net/core/dev.c:1680 [inline] > call_netdevice_notifiers net/core/dev.c:1694 [inline] > register_netdevice+0x950/0xeb0 net/core/dev.c:9114 > ieee80211_if_add+0xf51/0x1730 net/mac80211/iface.c:1881 > ieee80211_register_hw+0x36e6/0x3ac0 net/mac80211/main.c:1256 > mac80211_hwsim_new_radio+0x20d9/0x4360 > drivers/net/wireless/mac80211_hwsim.c:3031 > hwsim_new_radio_nl+0x9e3/0x1070 drivers/net/wireless/mac80211_hwsim.c:3586 > genl_family_rcv_msg+0x74b/0xf90 net/netlink/genetlink.c:629 > genl_rcv_msg+0xca/0x170 net/netlink/genetlink.c:654 > netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 > genl_rcv+0x29/0x40 net/netlink/genetlink.c:665 > netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] > netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328 > netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917 > sock_sendmsg_nosec net/socket.c:637 [inline] > sock_sendmsg+0xd7/0x130 net/socket.c:657 > ___sys_sendmsg+0x803/0x920 net/socket.c:2311 > __sys_sendmsg+0x105/0x1d0 net/socket.c:2356 > __do_sys_sendmsg net/socket.c:2365 [inline] > __se_sys_sendmsg net/socket.c:2363 [inline] > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363 > do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x459f39 > Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fd0af43ac78 EFLAGS: 0246 ORIG_RAX: 002e > RAX: ffda RBX: 0003 RCX: 00459f39 > RDX: RSI: 2180 RDI: 0003 > RBP: 0075bf20 R08: R09: > R10: R11: 0246 R12: 7fd0af43b6d4 > R13: 004c82f8 R14: 004de3f0 R15: > kobject: 'batman_adv' (9392522f): kobject_add_internal: > parent: 'wlan1810', set: '' > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion
[PATCH 2/4] ARM: dts: aspeed: Add Aspeed AST2600 PWM/Fan node in devicetree
Create a common node in aspeed-g6.dtsi and add fan nodes for ast2600-evb
dts file.
Signed-off-by: Troy Lee
---
arch/arm/boot/dts/aspeed-ast2600-evb.dts | 149 +++
arch/arm/boot/dts/aspeed-g6.dtsi | 10 ++
2 files changed, 159 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
index 89be13197780..51e00cf60749 100644
--- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
+++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
@@ -23,6 +23,155 @@
};
};
+_tacho {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwm0_default _tach0_default
+ _pwm1_default _tach1_default
+ _pwm2_default _tach2_default
+ _pwm3_default _tach3_default
+ _pwm4_default _tach4_default
+ _pwm5_default _tach5_default
+ _pwm6_default _tach6_default
+ _pwm7_default _tach7_default
+ _pwm8g1_default _tach8_default
+ _pwm9g1_default _tach9_default
+ _pwm10g1_default _tach10_default
+ _pwm11g1_default _tach11_default
+ _pwm12g1_default _tach12_default
+ _pwm13g1_default _tach13_default
+ _pwm14g1_default _tach14_default
+ _pwm15g1_default _tach15_default>;
+
+ fan@0 {
+ reg = <0x00>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x00>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@1 {
+ reg = <0x01>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x01>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@2 {
+ reg = <0x02>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x02>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@3 {
+ reg = <0x03>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x03>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@4 {
+ reg = <0x04>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x04>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@5 {
+ reg = <0x05>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x05>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@6 {
+ reg = <0x06>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x06>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@7 {
+ reg = <0x07>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x07>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@8 {
+ reg = <0x08>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x08>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@9 {
+ reg = <0x09>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x09>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@10 {
+ reg = <0x0a>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x0a>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@11 {
+ reg = <0x0b>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x0b>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@12 {
+ reg = <0x0c>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x0c>;
+ aspeed,pulse-pr = <2>;
+ };
+
+ fan@13 {
+ reg = <0x0d>;
+
[PATCH v5 03/27] dt-bindings: memory: mediatek: Extend LARB_NR_MAX to 32
Extend the max larb number definition as mt8192 has larb_nr over 16. Signed-off-by: Yong Wu Acked-by: Rob Herring Acked-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml | 2 +- include/dt-bindings/memory/mtk-smi-larb-port.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index b9946809fc2b..ba6626347381 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -99,7 +99,7 @@ properties: mediatek,larbs: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 -maxItems: 16 +maxItems: 32 description: | List of phandle to the local arbiters in the current Socs. Refer to bindings/memory-controllers/mediatek,smi-larb.yaml. It must sort diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h b/include/dt-bindings/memory/mtk-smi-larb-port.h index 53354cf4f6e3..7d64103209af 100644 --- a/include/dt-bindings/memory/mtk-smi-larb-port.h +++ b/include/dt-bindings/memory/mtk-smi-larb-port.h @@ -6,10 +6,10 @@ #ifndef __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_ #define __DT_BINDINGS_MEMORY_MTK_MEMORY_PORT_H_ -#define MTK_LARB_NR_MAX16 +#define MTK_LARB_NR_MAX32 #define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) -#define MTK_M4U_TO_LARB(id)(((id) >> 5) & 0xf) +#define MTK_M4U_TO_LARB(id)(((id) >> 5) & 0x1f) #define MTK_M4U_TO_PORT(id)((id) & 0x1f) #endif -- 2.18.0
[PATCH 1/4] dt-bindings: hwmon: Add Aspeed AST2600 PWM/Fan
For supporting a new AST2600 PWM/Fan hwmon driver, we add a new binding.
Signed-off-by: Troy Lee
---
.../bindings/hwmon/aspeed2600-pwm-tacho.txt | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/hwmon/aspeed2600-pwm-tacho.txt
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed2600-pwm-tacho.txt
b/Documentation/devicetree/bindings/hwmon/aspeed2600-pwm-tacho.txt
new file mode 100644
index ..61b11914352f
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed2600-pwm-tacho.txt
@@ -0,0 +1,69 @@
+ASPEED AST2600 PWM and Fan Tacho controller device driver
+
+The ASPEED PWM controller can support upto 16 PWM outputs. The ASPEED Fan Tacho
+controller can support upto 16 Fan tachometer inputs.
+
+There can be upto 16 fans supported. Each fan can have one PWM output and
+one Fan tach inputs.
+
+Required properties for pwm-tacho node:
+- #address-cells : should be 1.
+
+- #size-cells : should be 0.
+
+- #cooling-cells: should be 2.
+
+- reg : address and length of the register set for the device.
+
+- pinctrl-names : a pinctrl state named "default" must be defined.
+
+- pinctrl-0 : phandle referencing pin configuration of the PWM ports.
+
+- compatible : should be "aspeed,ast2600-pwm-tachometer".
+
+- clocks : phandle to clock provider with the clock number in the second cell
+
+- resets : phandle to reset controller with the reset number in the second cell
+
+fan subnode format:
+===
+Under fan subnode there can upto 16 child nodes, with each child node
+representing a fan. There are 16 fans each fan can have one PWM port and one
+Fan tach inputs.
+For PWM port can be configured cooling-levels to create cooling device.
+Cooling device could be bound to a thermal zone for the thermal control.
+
+Required properties for each child node:
+- reg : should specify PWM source port.
+ integer value in the range 0x00 to 0x0f with 0x00 indicating PWM port 0
+ and 0x0f indicating PWM port F.
+
+- cooling-levels: PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states.
+
+- aspeed,fan-tach-ch : should specify the Fan tach input channel.
+integer value in the range 0 through 15, with 0 indicating
+ Fan tach channel 0 and 15 indicating Fan tach channel 15.
+ Atleast one Fan tach input channel is required.
+
+- aspeed,target-pwm : Specify the frequency of PWM. The value range from 24 to
+ 78. Default value will be set to 25000.
+
+- aspeed,pulse-pr : Specify tacho pulse per revolution of the fan. A general
+ parameter of pulse-pr is 2.
+
+Examples:
+
+_tacho {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwm0_default _tach0_default>;
+
+ fan@0 {
+ reg = <0x00>;
+ aspeed,target-pwm = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x00>;
+ aspeed,pulse-pr = <2>;
+ };
+};
--
2.17.1
[PATCH 3/4] hwmon: Add Aspeed AST2600 support
Updating index.rst and adding aspeed_pwm_tachometer.rst to address the driver. Signed-off-by: Troy Lee --- Documentation/hwmon/aspeed_pwm_tachometer.rst | 24 +++ Documentation/hwmon/index.rst | 1 + 2 files changed, 25 insertions(+) create mode 100644 Documentation/hwmon/aspeed_pwm_tachometer.rst diff --git a/Documentation/hwmon/aspeed_pwm_tachometer.rst b/Documentation/hwmon/aspeed_pwm_tachometer.rst new file mode 100644 index ..301448002e6e --- /dev/null +++ b/Documentation/hwmon/aspeed_pwm_tachometer.rst @@ -0,0 +1,24 @@ +Kernel driver aspeed_pwm_tachometer +=== + +Supported chips: + ASPEED AST2600 + +Authors: + Ryan Chen + +Description: + +This driver implements support for ASPEED AST2600 PWM and Fan Tacho +controller. The PWM controller supports upto 16 PWM outputs. The Fan tacho +controller supports up to 16 tachometer inputs. + +The driver provides the following sensor accesses in sysfs: + +=== === = +fanX_input ro provide current fan rotation value in RPM as reported + by the fan to the device. + +pwmX rw get or set PWM fan control value. This is an integer + value between 0(off) and 255(full speed). +=== === = diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 89e1a824021f..26d277c1d211 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -43,6 +43,7 @@ Hardware Monitoring Kernel Drivers asb100 asc7621 aspeed-pwm-tacho + aspeed_pwm_tachometer bcm54140 bel-pfe bt1-pvt -- 2.17.1
[PATCH 0/3] tools/virtio: support aarch64 cross compiling
From: Peng Fan Not sure whether this is correct fix for aarch64 build, just a try. I still need to drop -Werror to make it build, but not included in this patchset. Peng Fan (3): tools/virtio: include asm/bug.h tools/virtio: add krealloc_array tools/virtio: add barrier for aarch64 tools/virtio/asm/barrier.h | 10 ++ tools/virtio/linux/bug.h| 2 ++ tools/virtio/linux/kernel.h | 13 +++-- 3 files changed, 23 insertions(+), 2 deletions(-) -- 2.28.0
[PATCH 2/3] tools/virtio: add krealloc_array
From: Peng Fan
krealloc_array is used in drivers/vhost/vringh.c, add it to avoid build
failure.
Drop WARN_ON_ONCE, because duplicated with the one in bug.h
Signed-off-by: Peng Fan
---
tools/virtio/linux/kernel.h | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/tools/virtio/linux/kernel.h b/tools/virtio/linux/kernel.h
index 315e85cabeda..0b493542e61a 100644
--- a/tools/virtio/linux/kernel.h
+++ b/tools/virtio/linux/kernel.h
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
#include
@@ -117,6 +118,16 @@ static inline void free_page(unsigned long addr)
# define unlikely(x) (__builtin_expect(!!(x), 0))
# endif
+static inline void *krealloc_array(void *p, size_t new_n, size_t new_size,
gfp_t gfp)
+{
+ size_t bytes;
+
+ if (unlikely(check_mul_overflow(new_n, new_size, )))
+ return NULL;
+
+ return krealloc(p, bytes, gfp);
+}
+
#define pr_err(format, ...) fprintf (stderr, format, ## __VA_ARGS__)
#ifdef DEBUG
#define pr_debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__)
@@ -126,8 +137,6 @@ static inline void free_page(unsigned long addr)
#define dev_err(dev, format, ...) fprintf (stderr, format, ## __VA_ARGS__)
#define dev_warn(dev, format, ...) fprintf (stderr, format, ## __VA_ARGS__)
-#define WARN_ON_ONCE(cond) (unlikely(cond) ? fprintf (stderr, "WARNING\n") : 0)
-
#define min(x, y) ({ \
typeof(x) _min1 = (x); \
typeof(y) _min2 = (y); \
--
2.28.0
[PATCH 3/3] tools/virtio: add barrier for aarch64
From: Peng Fan
Add barrier for aarch64 for cross compiling, and most are from Linux Kernel.
Signed-off-by: Peng Fan
---
tools/virtio/asm/barrier.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/virtio/asm/barrier.h b/tools/virtio/asm/barrier.h
index 04d563fc9b95..468435ed64e6 100644
--- a/tools/virtio/asm/barrier.h
+++ b/tools/virtio/asm/barrier.h
@@ -16,6 +16,16 @@
# define mb() abort()
# define dma_rmb() abort()
# define dma_wmb() abort()
+#elif defined(__aarch64__)
+#define dmb(opt) asm volatile("dmb " #opt : : : "memory")
+#define virt_mb() __sync_synchronize()
+#define virt_rmb() dmb(ishld)
+#define virt_wmb() dmb(ishst)
+#define virt_store_mb(var, value) do { WRITE_ONCE(var, value); dmb(ish); }
while (0)
+/* Weak barriers should be used. If not - it's a bug */
+# define mb() abort()
+# define dma_rmb() abort()
+# define dma_wmb() abort()
#else
#error Please fill in barrier macros
#endif
--
2.28.0
Re: [RFC PATCH v7] sched/fair: select idle cpu from idle cpumask for task wakeup
Le mercredi 09 déc. 2020 à 14:24:04 (+0800), Aubrey Li a écrit :
> Add idle cpumask to track idle cpus in sched domain. Every time
> a CPU enters idle, the CPU is set in idle cpumask to be a wakeup
> target. And if the CPU is not in idle, the CPU is cleared in idle
> cpumask during scheduler tick to ratelimit idle cpumask update.
>
> When a task wakes up to select an idle cpu, scanning idle cpumask
> has lower cost than scanning all the cpus in last level cache domain,
> especially when the system is heavily loaded.
>
> Benchmarks including hackbench, schbench, uperf, sysbench mysql
> and kbuild were tested on a x86 4 socket system with 24 cores per
> socket and 2 hyperthreads per core, total 192 CPUs, no regression
> found.
>
> v6->v7:
> - place the whole idle cpumask mechanism under CONFIG_SMP.
>
> v5->v6:
> - decouple idle cpumask update from stop_tick signal, set idle CPU
> in idle cpumask every time the CPU enters idle
>
> v4->v5:
> - add update_idle_cpumask for s2idle case
> - keep the same ordering of tick_nohz_idle_stop_tick() and update_
> idle_cpumask() everywhere
>
> v3->v4:
> - change setting idle cpumask from every idle entry to tickless idle
> if cpu driver is available.
> - move clearing idle cpumask to scheduler_tick to decouple nohz mode.
>
> v2->v3:
> - change setting idle cpumask to every idle entry, otherwise schbench
> has a regression of 99th percentile latency.
> - change clearing idle cpumask to nohz_balancer_kick(), so updating
> idle cpumask is ratelimited in the idle exiting path.
> - set SCHED_IDLE cpu in idle cpumask to allow it as a wakeup target.
>
> v1->v2:
> - idle cpumask is updated in the nohz routines, by initializing idle
> cpumask with sched_domain_span(sd), nohz=off case remains the original
> behavior.
>
> Cc: Peter Zijlstra
> Cc: Mel Gorman
> Cc: Vincent Guittot
> Cc: Qais Yousef
> Cc: Valentin Schneider
> Cc: Jiang Biao
> Cc: Tim Chen
> Signed-off-by: Aubrey Li
> ---
> include/linux/sched/topology.h | 13 +
> kernel/sched/core.c| 2 ++
> kernel/sched/fair.c| 51 +-
> kernel/sched/idle.c| 5
> kernel/sched/sched.h | 4 +++
> kernel/sched/topology.c| 3 +-
> 6 files changed, 76 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
> index 820511289857..b47b85163607 100644
> --- a/include/linux/sched/topology.h
> +++ b/include/linux/sched/topology.h
> @@ -65,8 +65,21 @@ struct sched_domain_shared {
> atomic_tref;
> atomic_tnr_busy_cpus;
> int has_idle_cores;
> + /*
> + * Span of all idle CPUs in this domain.
> + *
> + * NOTE: this field is variable length. (Allocated dynamically
> + * by attaching extra space to the end of the structure,
> + * depending on how many CPUs the kernel has booted up with)
> + */
> + unsigned long idle_cpus_span[];
> };
>
> +static inline struct cpumask *sds_idle_cpus(struct sched_domain_shared *sds)
> +{
> + return to_cpumask(sds->idle_cpus_span);
> +}
> +
> struct sched_domain {
> /* These fields must be setup */
> struct sched_domain __rcu *parent; /* top domain must be null
> terminated */
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index c4da7e17b906..c4c51ff3402a 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4011,6 +4011,7 @@ void scheduler_tick(void)
>
> #ifdef CONFIG_SMP
> rq->idle_balance = idle_cpu(cpu);
> + update_idle_cpumask(cpu, false);
Test rq->idle_balance here instead of adding the test in update_idle_cpumask
which is only
relevant for this situation.
if (!rq->idle_balance)
update_idle_cpumask(cpu, false);
> trigger_load_balance(rq);
> #endif
> }
> @@ -7186,6 +7187,7 @@ void __init sched_init(void)
> rq->idle_stamp = 0;
> rq->avg_idle = 2*sysctl_sched_migration_cost;
> rq->max_idle_balance_cost = sysctl_sched_migration_cost;
> + rq->last_idle_state = 1;
>
> INIT_LIST_HEAD(>cfs_tasks);
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c0c4d9ad7da8..7306f8886120 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6146,7 +6146,12 @@ static int select_idle_cpu(struct task_struct *p,
> struct sched_domain *sd, int t
>
> time = cpu_clock(this);
>
> - cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
> + /*
> + * sched_domain_shared is set only at shared cache level,
> + * this works only because select_idle_cpu is called with
> + * sd_llc.
> + */
> + cpumask_and(cpus, sds_idle_cpus(sd->shared), p->cpus_ptr);
>
> for_each_cpu_wrap(cpu, cpus, target) {
> if (!--nr)
> @@ -6806,6 +6811,50 @@ balance_fair(struct rq *rq, struct task_struct *prev,
> struct rq_flags *rf)
>
> return
[PATCH 1/3] tools/virtio: include asm/bug.h
From: Peng Fan WARN_ON is used in drivers/vhost/vringh.c, to avoid build failure, need include asm/bug.h Signed-off-by: Peng Fan --- tools/virtio/linux/bug.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/virtio/linux/bug.h b/tools/virtio/linux/bug.h index b14c2c3b6b85..813baf13f62a 100644 --- a/tools/virtio/linux/bug.h +++ b/tools/virtio/linux/bug.h @@ -2,6 +2,8 @@ #ifndef BUG_H #define BUG_H +#include + #define BUG_ON(__BUG_ON_cond) assert(!(__BUG_ON_cond)) #define BUILD_BUG_ON(x) -- 2.28.0
[PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation
1. When the x25 module gets loaded, layer 2 may already be running and
connected. In this case, although we are in X25_LINK_STATE_0, we still
need to handle the Restart Request received, rather than ignore it.
2. When we are in X25_LINK_STATE_2, we have already sent a Restart Request
and is waiting for the Restart Confirmation with t20timer. t20timer will
restart itself repeatedly forever so it will always be there, as long as we
are in State 2. So we don't need to check x25_t20timer_pending again.
Fixes: d023b2b9ccc2 ("net/x25: fix restart request/confirm handling")
Cc: Martin Schiller
Signed-off-by: Xie He
---
net/x25/x25_link.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/net/x25/x25_link.c b/net/x25/x25_link.c
index f92073f3cb11..57a81100c5da 100644
--- a/net/x25/x25_link.c
+++ b/net/x25/x25_link.c
@@ -58,11 +58,6 @@ static inline void x25_stop_t20timer(struct x25_neigh *nb)
del_timer(>t20timer);
}
-static inline int x25_t20timer_pending(struct x25_neigh *nb)
-{
- return timer_pending(>t20timer);
-}
-
/*
* This handles all restart and diagnostic frames.
*/
@@ -70,17 +65,20 @@ void x25_link_control(struct sk_buff *skb, struct x25_neigh
*nb,
unsigned short frametype)
{
struct sk_buff *skbn;
- int confirm;
switch (frametype) {
case X25_RESTART_REQUEST:
switch (nb->state) {
+ case X25_LINK_STATE_0:
+ /* This can happen when the x25 module just gets loaded
+* and doesn't know layer 2 has already connected
+*/
+ nb->state = X25_LINK_STATE_3;
+ x25_transmit_restart_confirmation(nb);
+ break;
case X25_LINK_STATE_2:
- confirm = !x25_t20timer_pending(nb);
x25_stop_t20timer(nb);
nb->state = X25_LINK_STATE_3;
- if (confirm)
- x25_transmit_restart_confirmation(nb);
break;
case X25_LINK_STATE_3:
/* clear existing virtual calls */
@@ -94,13 +92,8 @@ void x25_link_control(struct sk_buff *skb, struct x25_neigh
*nb,
case X25_RESTART_CONFIRMATION:
switch (nb->state) {
case X25_LINK_STATE_2:
- if (x25_t20timer_pending(nb)) {
- x25_stop_t20timer(nb);
- nb->state = X25_LINK_STATE_3;
- } else {
- x25_transmit_restart_request(nb);
- x25_start_t20timer(nb);
- }
+ x25_stop_t20timer(nb);
+ nb->state = X25_LINK_STATE_3;
break;
case X25_LINK_STATE_3:
/* clear existing virtual calls */
--
2.27.0
Re: [PATCH next v2 2/3] printk: change @clear_seq to atomic64_t
On Tue, Dec 08, 2020 at 11:36:44PM +0106, John Ogness wrote: > For the state variable we chose atomic_long_t instead of atomic64_t for > this reason. atomic_long_t operations are available atomically on all > architectures. Please put on your eye cancer gear and inspect the atomic implementation of PA-RISC, Sparc32, feh, I forgot who else. Those SMP capable architectures are gifted with just one XCHG like atomic instruction :/ Anyway, as said in the other email, they also don't have NMIs so it mostly works.
Re: [PATCH v2 sl-b 1/5] mm: Add mem_dump_obj() to print source of memory block
Your two new exports don't actually seem to get used in modular code at all in this series.
Re: [PATCH v1 1/3] gpio: gpio-hisi: Add HiSilicon GPIO support
On 2020/12/7 7:12, Linus Walleij wrote:
Hi Luo!
thanks for your patch! I see that Andy already provided a crowd
of comments, here are some more!
On Wed, Dec 2, 2020 at 10:32 AM Luo Jiaxing wrote:
+config GPIO_HISI
+ tristate "HISILICON GPIO controller driver"
+ depends on (ARM64 && ACPI) || COMPILE_TEST
+ select GPIO_GENERIC
Thanks for using the generic driver!
+#include
+#include
+#include
+#include
+#include
+
+#include "gpiolib.h"
+#include "gpiolib-acpi.h"
No GPIO drivers should include these files. If you need
gpiolib.h then describe in a comment right above the include
why you have to do this.
I don't know about gpiolig-acpi.h but not unless Andy
says it is OK it is not OK.
sure
+#define HISI_GPIO_SWPORT_DR_SET_WX 0x0
+#define HISI_GPIO_SWPORT_DR_CLR_WX 0x4
+#define HISI_GPIO_SWPORT_DDR_SET_WX0x10
+#define HISI_GPIO_SWPORT_DDR_CLR_WX0x14
+#define HISI_GPIO_SWPORT_DDR_ST_WX 0x18
+#define HISI_GPIO_INTEN_SET_WX 0x20
+#define HISI_GPIO_INTEN_CLR_WX 0x24
+#define HISI_GPIO_INTMASK_SET_WX 0x30
+#define HISI_GPIO_INTMASK_CLR_WX 0x34
+#define HISI_GPIO_INTTYPE_EDGE_SET_WX 0x40
+#define HISI_GPIO_INTTYPE_EDGE_CLR_WX 0x44
+#define HISI_GPIO_INT_POLARITY_SET_WX 0x50
+#define HISI_GPIO_INT_POLARITY_CLR_WX 0x54
+#define HISI_GPIO_DEBOUNCE_SET_WX 0x60
+#define HISI_GPIO_DEBOUNCE_CLR_WX 0x64
+#define HISI_GPIO_INTSTATUS_WX 0x70
+#define HISI_GPIO_PORTA_EOI_WX 0x78
+#define HISI_GPIO_EXT_PORT_WX 0x80
+#define HISI_GPIO_INTCOMB_MASK_WX 0xa0
+#define HISI_GPIO_INT_DEDGE_SET0xb0
+#define HISI_GPIO_INT_DEDGE_CLR0xb4
+#define HISI_GPIO_INT_DEDGE_ST 0xb8
Nice idea with the double edge register! Hats off to the hardware
engineer who created this simple yet powerful GPIO.
+#define HISI_GPIO_REG_SIZE 0x4
+#define HISI_GPIO_REG_MAX 0x100
+#define HISI_GPIO_PIN_NUM_MAX 32
This seems like a bit surplus definitions, I prefer to just inline
these. Some use cases will go away after you start using
bgpio_init().
sure, will be set as inline
+struct hisi_gpio {
+ struct device *dev;
+ void __iomem*reg_base;
+ unsigned intpin_num;
I prefer "line_num", the reason I usually use the term "lines"
rather than "pins" is that some GPIO lines are internal in
chips and do not always go out to external pins.
yes, you are right.
+ struct gpio_chipchip;
+ struct irq_chip irq_chip;
+ int irq;
Do you need to keep irq around in the state?
irq is used in several functions, such as hisi_gpio_init_irq and
hisi_gpio_probe.
Although these functions can be combined, but the readability of the
logic is affected.
Therefore, Irq needs to be saved.
+static inline u32 hisi_gpio_read_reg(struct gpio_chip *chip,
+unsigned int off)
+{
+ struct hisi_gpio *hisi_gpio =
+ container_of(chip, struct hisi_gpio, chip);
+
+ return chip->read_reg(hisi_gpio->reg_base + off);
+}
+
+static inline void hisi_gpio_write_reg(struct gpio_chip *chip,
+ unsigned int off, u32 val)
+{
+ struct hisi_gpio *hisi_gpio =
+ container_of(chip, struct hisi_gpio, chip);
+
+ chip->write_reg(hisi_gpio->reg_base + off, val);
+}
OK it is a bit of reusing the register accessors inside the
GPIO chip generic MMIO abstraction, but to me it is really
better if you just address the registers directly.
The indirections through read_reg/write_reg doesn't
really buy you anything.
yes, you are right, I can directly use readl() and writel() here
+static void hisi_gpio_set_debounce(struct gpio_chip *chip, unsigned int off,
+ u32 debounce)
+{
+ unsigned long mask = BIT(off);
+
+ if (debounce)
+ hisi_gpio_write_reg(chip, HISI_GPIO_DEBOUNCE_SET_WX, mask);
+ else
+ hisi_gpio_write_reg(chip, HISI_GPIO_DEBOUNCE_CLR_WX, mask);
+}
So debounce is just on/off? No ability to set "how much" or a timer?
Someone must be guessing inside the block that a certain number
of ms is perfect(TM) debouncing or is there a register for this that
you are not showing us? Like register 0x68 or 0x6c...
Yes. In our hardware design, debounce timer are fixed as several clock
cycles。
and cannot be modified by the driver.
The 0x68 register is a status register, which is used to query whether
debounce is enabled.
No drivers check status of debounce, so I didn't show it.
+static int hisi_gpio_get_direction(struct gpio_chip *chip, unsigned int gpio)
+static int hisi_gpio_direction_output(struct gpio_chip *chip,
+ unsigned int gpio,
+ int val)
+static int hisi_gpio_direction_input(struct gpio_chip *chip,
+
Re: [f2fs-dev] [PATCH v4] f2fs: compress: support chksum
On 12/09, Chao Yu wrote: > On 2020/12/9 12:28, Chao Yu wrote: > > On 2020/12/9 11:54, Jaegeuk Kim wrote: > > > Ah, could you please write another patch to adjust the new changes? > > > > No problem, will drop "f2fs: compress:support chksum" based on your dev > > branch, and > > apply all compress related patches on top of dev branch. > > Jaegeuk, could you please > - drop "f2fs: compress:support chksum", What I mean is keeping the old version in dev branch as is, since it gives another conflicts when dropping it. That can add another bug at this point. Can I get a separate patch to fix any issues in that original patch? > - manually fix conflict when applying "f2fs: add compress_mode mount option" > - and then apply last my resent patches. > > Thanks,
Re: [PATCH v1 2/2] scsi: ufs: Clean up some lines from ufshcd_hba_exit()
Hi Can,
On Tue, 2020-12-08 at 22:58 -0800, Can Guo wrote:
> ufshcd_hba_exit() is always called after ufshcd_exit_clk_scaling() and
> ufshcd_exit_clk_gating(), so no need to suspend clock scaling again in
> ufshcd_hba_exit().
>
> Signed-off-by: Can Guo
> ---
> drivers/scsi/ufs/ufshcd.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 12266bd..0a5b197 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -7765,6 +7765,7 @@ static void ufshcd_async_scan(void *data,
> async_cookie_t cookie)
> if (ret) {
> pm_runtime_put_sync(hba->dev);
> ufshcd_exit_clk_scaling(hba);
> + ufshcd_exit_clk_gating(hba);
How about moving above two lines to ufshcd_hba_exit()?
Otherwise looks good to me!
Reviewed-by: Stanley Chu
> ufshcd_hba_exit(hba);
> }
> }
> @@ -8203,10 +8204,6 @@ static void ufshcd_hba_exit(struct ufs_hba *hba)
> if (hba->is_powered) {
> ufshcd_variant_hba_exit(hba);
> ufshcd_setup_vreg(hba, false);
> - ufshcd_suspend_clkscaling(hba);
> - if (ufshcd_is_clkscaling_supported(hba))
> - if (hba->devfreq)
> - ufshcd_suspend_clkscaling(hba);
> ufshcd_setup_clocks(hba, false);
> ufshcd_setup_hba_vreg(hba, false);
> hba->is_powered = false;
Re: [f2fs-dev] [PATCH v3] f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE
On 12/09, Chao Yu wrote: > On 2020/12/3 14:56, Daeho Jeong wrote: > > From: Daeho Jeong > > + f2fs_balance_fs(F2FS_I_SB(inode), true); > > Trivial cleanup: > > f2fs_balance_fs(sbi, true); > > > + f2fs_balance_fs(F2FS_I_SB(inode), true); > > Ditto, > > Jaegeuk could fix this directly? Let's fix this later, since I'd like to freeze -next branch as much as possible. > > Thanks, > > > ___ > Linux-f2fs-devel mailing list > linux-f2fs-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [PATCH] ALSA: hda/realtek - Enable headset mic of ASUS Q524UQK with ALC255
On Wed, 09 Dec 2020 05:57:30 +0100, Chris Chiu wrote: > > The ASUS laptop Q524UQK with ALC255 codec can't detect the headset > microphone until ALC255_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied. > > Signed-off-by: Chris Chiu > Signed-off-by: Jian-Hong Pan Applied now. Thanks. Takashi
Re: [PATCH bpf-next v2 1/3] bpf: Expose bpf_get_socket_cookie to tracing programs
On 12/8/20 8:30 PM, Florent Revest wrote:
On Fri, 2020-12-04 at 20:03 +0100, Daniel Borkmann wrote:
On 12/4/20 7:56 PM, Daniel Borkmann wrote:
On 12/3/20 10:33 PM, Florent Revest wrote:
This creates a new helper proto because the existing
bpf_get_socket_cookie_sock_proto has a ARG_PTR_TO_CTX argument
and only
works for BPF programs where the context is a sock.
This helper could also be useful to other BPF program types such
as LSM.
Signed-off-by: Florent Revest
---
include/uapi/linux/bpf.h | 7 +++
kernel/trace/bpf_trace.c | 4
net/core/filter.c | 7 +++
tools/include/uapi/linux/bpf.h | 7 +++
4 files changed, 25 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index c3458ec1f30a..3e0e33c43998 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1662,6 +1662,13 @@ union bpf_attr {
* Return
* A 8-byte long non-decreasing number.
*
+ * u64 bpf_get_socket_cookie(void *sk)
+ * Description
+ * Equivalent to **bpf_get_socket_cookie**\ () helper
that accepts
+ * *sk*, but gets socket from a BTF **struct sock**.
+ * Return
+ * A 8-byte long non-decreasing number.
I would not mention this here since it's not fully correct and we
should avoid users taking non-decreasing granted in their progs.
The only assumption you can make is that it can be considered a
unique number. See also [0] with reverse counter..
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=92acdc58ab11af66fcaef485433fde61b5e32fac
Ah this is a good point, thank you! I will send a v3 with an extra
patch that s/non-decreasing/unique/ in the other descriptions. I had
not given it any extra thought, I just stupidly copied/pasted existing
descriptions. :)
One more thought, in case you plan to use this from sleepable
context, you would need to use sock_gen_cookie() variant in the BPF
helper instead.
Out of curiosity, why don't we just always call sock_gen_cookie? Is it
to avoid the performance impact of increasing the preempt counter and
introducing a memory barriers ?
Yes, all the other contexts where the existing helpers are used already have
preemption disabled, so the extra preempt_{disable,enable}() is unnecessary
overhead given we want the cookie generation be efficient.
Thanks,
Daniel
Re: [PATCH RESEND v2] virtio-input: add multi-touch support
On Tue, Dec 08, 2020 at 11:01:50PM +0200, Vasyl Vavrychuk wrote:
> From: Mathias Crombez
> Cc: sta...@vger.kernel.org
I don't believe this is appropriate for stable, looks like
a new feature to me.
>
> Without multi-touch slots allocated, ABS_MT_SLOT events will be lost by
> input_handle_abs_event.
>
> Signed-off-by: Mathias Crombez
> Signed-off-by: Vasyl Vavrychuk
> Tested-by: Vasyl Vavrychuk
> ---
> v2: fix patch corrupted by corporate email server
>
> drivers/virtio/Kconfig| 11 +++
> drivers/virtio/virtio_input.c | 8
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 7b41130d3f35..2cfd5b01d96d 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -111,6 +111,17 @@ config VIRTIO_INPUT
>
>If unsure, say M.
>
> +config VIRTIO_INPUT_MULTITOUCH_SLOTS
> + depends on VIRTIO_INPUT
> + int "Number of multitouch slots"
> + range 0 64
> + default 10
> + help
> + Define the number of multitouch slots used. Default to 10.
> + This parameter is unused if there is no multitouch capability.
> +
> + 0 will disable the feature.
> +
Most people won't be using this config so the defaults matter. So why 10? 10
fingers?
And where does 64 come from?
> config VIRTIO_MMIO
> tristate "Platform bus driver for memory mapped virtio devices"
> depends on HAS_IOMEM && HAS_DMA
> diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c
> index f1f6208edcf5..13f3d90e6c30 100644
> --- a/drivers/virtio/virtio_input.c
> +++ b/drivers/virtio/virtio_input.c
> @@ -7,6 +7,7 @@
>
> #include
> #include
> +#include
>
> struct virtio_input {
> struct virtio_device *vdev;
> @@ -205,6 +206,7 @@ static int virtinput_probe(struct virtio_device *vdev)
> unsigned long flags;
> size_t size;
> int abs, err;
> + bool is_mt = false;
>
> if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
> return -ENODEV;
> @@ -287,9 +289,15 @@ static int virtinput_probe(struct virtio_device *vdev)
> for (abs = 0; abs < ABS_CNT; abs++) {
> if (!test_bit(abs, vi->idev->absbit))
> continue;
> + if (input_is_mt_value(abs))
> + is_mt = true;
> virtinput_cfg_abs(vi, abs);
> }
> }
> + if (is_mt)
> + input_mt_init_slots(vi->idev,
> + CONFIG_VIRTIO_INPUT_MULTITOUCH_SLOTS,
> + INPUT_MT_DIRECT);
Do we need the number in config space maybe? And maybe with a feature
bit so host can find out whether guest supports MT?
>
> virtio_device_ready(vdev);
> vi->ready = true;
> --
> 2.23.0
Re: [PATCH v1 2/2] scsi: ufs: Clean up some lines from ufshcd_hba_exit()
On 2020-12-09 16:22, Stanley Chu wrote:
Hi Can,
On Tue, 2020-12-08 at 22:58 -0800, Can Guo wrote:
ufshcd_hba_exit() is always called after ufshcd_exit_clk_scaling() and
ufshcd_exit_clk_gating(), so no need to suspend clock scaling again in
ufshcd_hba_exit().
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 12266bd..0a5b197 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7765,6 +7765,7 @@ static void ufshcd_async_scan(void *data,
async_cookie_t cookie)
if (ret) {
pm_runtime_put_sync(hba->dev);
ufshcd_exit_clk_scaling(hba);
+ ufshcd_exit_clk_gating(hba);
How about moving above two lines to ufshcd_hba_exit()?
Otherwise looks good to me!
Reviewed-by: Stanley Chu
You read my mind - I thought about that too, but in ufshcd_init(),
they are separately called on different error out paths.
11232 exit_gating:
11233 ufshcd_exit_clk_scaling(hba);
11234 ufshcd_exit_clk_gating(hba);
11235 out_disable:
11236 hba->is_irq_enabled = false;
11237 ufshcd_hba_exit(hba);
Thanks,
Can Guo.
ufshcd_hba_exit(hba);
}
}
@@ -8203,10 +8204,6 @@ static void ufshcd_hba_exit(struct ufs_hba
*hba)
if (hba->is_powered) {
ufshcd_variant_hba_exit(hba);
ufshcd_setup_vreg(hba, false);
- ufshcd_suspend_clkscaling(hba);
- if (ufshcd_is_clkscaling_supported(hba))
- if (hba->devfreq)
- ufshcd_suspend_clkscaling(hba);
ufshcd_setup_clocks(hba, false);
ufshcd_setup_hba_vreg(hba, false);
hba->is_powered = false;
[PATCH] PCI: Remove pci_try_set_mwi
pci_set_mwi() and pci_try_set_mwi() do exactly the same, just that the former one is declared as __must_check. However also some callers of pci_set_mwi() have a comment that it's an optional feature. I don't think there's much sense in this separation and the use of __must_check. Therefore remove pci_try_set_mwi() and remove the __must_check attribute from pci_set_mwi(). I don't expect either function to be used in new code anyway. Signed-off-by: Heiner Kallweit --- patch applies on top of pci/misc for v5.11 --- Documentation/PCI/pci.rst | 5 + drivers/ata/pata_cs5530.c | 2 +- drivers/ata/sata_mv.c | 2 +- drivers/dma/dw/pci.c | 2 +- drivers/dma/hsu/pci.c | 2 +- drivers/ide/cs5530.c | 2 +- drivers/mfd/intel-lpss-pci.c | 2 +- drivers/net/ethernet/adaptec/starfire.c | 2 +- drivers/net/ethernet/alacritech/slicoss.c | 2 +- drivers/net/ethernet/dec/tulip/tulip_core.c | 5 + drivers/net/ethernet/sun/cassini.c| 4 ++-- drivers/net/wireless/intersil/p54/p54pci.c| 2 +- .../intersil/prism54/islpci_hotplug.c | 3 +-- .../wireless/realtek/rtl818x/rtl8180/dev.c| 2 +- drivers/pci/pci.c | 19 --- drivers/scsi/3w-9xxx.c| 4 ++-- drivers/scsi/3w-sas.c | 4 ++-- drivers/scsi/csiostor/csio_init.c | 2 +- drivers/scsi/lpfc/lpfc_init.c | 2 +- drivers/scsi/qla2xxx/qla_init.c | 8 drivers/scsi/qla2xxx/qla_mr.c | 2 +- drivers/tty/serial/8250/8250_lpss.c | 2 +- drivers/usb/chipidea/ci_hdrc_pci.c| 2 +- drivers/usb/gadget/udc/amd5536udc_pci.c | 2 +- drivers/usb/gadget/udc/net2280.c | 2 +- drivers/usb/gadget/udc/pch_udc.c | 2 +- include/linux/pci.h | 5 ++--- 27 files changed, 33 insertions(+), 60 deletions(-) diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index 814b40f83..120362cc9 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -226,10 +226,7 @@ If the PCI device can use the PCI Memory-Write-Invalidate transaction, call pci_set_mwi(). This enables the PCI_COMMAND bit for Mem-Wr-Inval and also ensures that the cache line size register is set correctly. Check the return value of pci_set_mwi() as not all architectures -or chip-sets may support Memory-Write-Invalidate. Alternatively, -if Mem-Wr-Inval would be nice to have but is not required, call -pci_try_set_mwi() to have the system do its best effort at enabling -Mem-Wr-Inval. +or chip-sets may support Memory-Write-Invalidate. Request MMIO/IOP resources diff --git a/drivers/ata/pata_cs5530.c b/drivers/ata/pata_cs5530.c index ad75d02b6..8654b3ae1 100644 --- a/drivers/ata/pata_cs5530.c +++ b/drivers/ata/pata_cs5530.c @@ -214,7 +214,7 @@ static int cs5530_init_chip(void) } pci_set_master(cs5530_0); - pci_try_set_mwi(cs5530_0); + pci_set_mwi(cs5530_0); /* * Set PCI CacheLineSize to 16-bytes: diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c index 664ef658a..ee37755ea 100644 --- a/drivers/ata/sata_mv.c +++ b/drivers/ata/sata_mv.c @@ -4432,7 +4432,7 @@ static int mv_pci_init_one(struct pci_dev *pdev, mv_print_info(host); pci_set_master(pdev); - pci_try_set_mwi(pdev); + pci_set_mwi(pdev); return ata_host_activate(host, pdev->irq, mv_interrupt, IRQF_SHARED, IS_GEN_I(hpriv) ? _sht : _sht); } diff --git a/drivers/dma/dw/pci.c b/drivers/dma/dw/pci.c index 1142aa6f8..1c20b7485 100644 --- a/drivers/dma/dw/pci.c +++ b/drivers/dma/dw/pci.c @@ -30,7 +30,7 @@ static int dw_pci_probe(struct pci_dev *pdev, const struct pci_device_id *pid) } pci_set_master(pdev); - pci_try_set_mwi(pdev); + pci_set_mwi(pdev); ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(32)); if (ret) diff --git a/drivers/dma/hsu/pci.c b/drivers/dma/hsu/pci.c index 07cc7320a..420dd3706 100644 --- a/drivers/dma/hsu/pci.c +++ b/drivers/dma/hsu/pci.c @@ -73,7 +73,7 @@ static int hsu_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) } pci_set_master(pdev); - pci_try_set_mwi(pdev); + pci_set_mwi(pdev); ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(32)); if (ret) diff --git a/drivers/ide/cs5530.c b/drivers/ide/cs5530.c index 5bb46e713..5d2c421ab 100644 --- a/drivers/ide/cs5530.c +++ b/drivers/ide/cs5530.c @@ -168,7 +168,7 @@ static int init_chipset_cs5530(struct pci_dev *dev) */ pci_set_master(cs5530_0); - pci_try_set_mwi(cs5530_0); + pci_set_mwi(cs5530_0); /* * Set PCI CacheLineSize to 16-bytes: diff --git
Re: [PATCH 3/5] ALSA: hda/ca0132 - Add 8051 exram helper functions.
On Tue, 08 Dec 2020 22:25:43 +0100,
Connor McAdams wrote:
>
> +static void chipio_8051_write_exram(struct hda_codec *codec,
> + unsigned int addr, unsigned int data, bool use_mutex)
> +{
> + struct ca0132_spec *spec = codec->spec;
> + unsigned int tmp;
> +
> + if (use_mutex)
> + mutex_lock(>chipio_mutex);
This can be better to split to two functions: a core helper function
without mutex and a helper function to take the mutex lock and call
the former function. Applying the lock conditionally is often
error-prone.
thanks,
Takashi
Re: [PATCH 22/22] xlink-core: factorize xlink_ioctl function by creating sub-functions for each ioctl command
On Tue, 2020-12-01 at 14:35 -0800, mgr...@linux.intel.com wrote:
> Refactor the too large IOCTL function to call helper functions.
[]
> diff --git a/drivers/misc/xlink-core/xlink-ioctl.c
> b/drivers/misc/xlink-core/xlink-ioctl.c
[]
> +int ioctl_write_data(unsigned long arg)
> +{
> + struct xlink_handle devh= {0};
> + struct xlinkwritedata wr = {0};
> + int rc = 0;
> +
> + if (copy_from_user(, (void __user *)arg,
> +sizeof(struct xlinkwritedata)))
> + return -EFAULT;
> + if (copy_from_user(, (void __user *)wr.handle,
> +sizeof(struct xlink_handle)))
> + return -EFAULT;
> + if (wr.size <= XLINK_MAX_DATA_SIZE) {
> + rc = xlink_write_data_user(, wr.chan, wr.pmessage,
> +wr.size);
> + if (copy_to_user((void __user *)wr.return_code, (void *),
> + sizeof(rc)))
> + return -EFAULT;
> + } else {
> + return -EFAULT;
> + }
Please reverse the test to reduce indentation
if (wr.size > XLINK_MAX_DATA_SIZE)
return -EFAULT;
rc = xlink_write_data_user(, wr.chan, wr.pmessage, wr.size);
if (copy_to_user((void __user *)wr.return_code, (void *),
sizeof(rc)))
return -EFAULT;
return rc;
The last 3 lines here are repeated multiple times in many functions.
It might be sensible to add something like:
int copy_result_to_user(u32 *where, int rc)
{
if (copy_to_user((void __user *)where, , sizeof(rc)))
return -EFAULT;
return rc;
}
so this could be written
rc = xlink_write_data_user(, wr.chan, wr.pmessage, wr.size);
return copy_result_to_user(wr.return_code, rc);
IMO: return_code isn't a great name for a pointer as it rather
indicates a value not an address and there's an awful lot of
casting to __user in all this code that perhaps should be marked
in the struct definitions rather than inside the function uses.
> +}
> +
> +int ioctl_write_control_data(unsigned long arg)
> +{
> + struct xlink_handle devh= {0};
All of these initializations with {0} should use {} instead as
the first element of whatever struct is not guaranteed to be
assignable as an int and gcc/clang guarantee 0 initialization
> + struct xlinkwritedata wr = {0};
> + u8 volbuf[XLINK_MAX_BUF_SIZE];
> + int rc = 0;
> +
> + if (copy_from_user(, (void __user *)arg,
> +sizeof(struct xlinkwritedata)))
> + return -EFAULT;
> + if (copy_from_user(, (void __user *)wr.handle,
> +sizeof(struct xlink_handle)))
> + return -EFAULT;
> + if (wr.size <= XLINK_MAX_CONTROL_DATA_SIZE) {
> + if (copy_from_user(volbuf, (void __user *)wr.pmessage,
> +wr.size))
> + return -EFAULT;
> + rc = xlink_write_control_data(, wr.chan, volbuf,
> + wr.size);
> + if (copy_to_user((void __user *)wr.return_code,
> + (void *), sizeof(rc)))
> + return -EFAULT;
> + } else {
> + return -EFAULT;
Same test reversal and deindentation please.
> + }
> + return rc;
> +}
> +
Re: [f2fs-dev] [PATCH v4] f2fs: compress: support chksum
On 2020/12/9 16:23, Jaegeuk Kim wrote: On 12/09, Chao Yu wrote: On 2020/12/9 12:28, Chao Yu wrote: On 2020/12/9 11:54, Jaegeuk Kim wrote: Ah, could you please write another patch to adjust the new changes? No problem, will drop "f2fs: compress:support chksum" based on your dev branch, and apply all compress related patches on top of dev branch. Jaegeuk, could you please - drop "f2fs: compress:support chksum", What I mean is keeping the old version in dev branch as is, since it gives another conflicts when dropping it. That can add another bug at this point. Can I get a separate patch to fix any issues in that original patch? Oops... Thanks, - manually fix conflict when applying "f2fs: add compress_mode mount option" - and then apply last my resent patches. Thanks, .
Re: [PATCH] iov_iter: optimise bvec iov_iter_advance()
On Thu, Dec 03, 2020 at 11:48:56AM +, Pavel Begunkov wrote: > It's inlined and the on-stack iter is completely optimised out. Frankly, > I'd rather not open-code bvec_iter_advance(), at least for this chunk to > be findable from bvec.h, e.g. grep bvec_iter and bvec_for_each. Though, > I don't like myself that preamble/postamble. Ok. I still think we at least want a separate helper instead of bloating the main iov_iter_advance.
Re: [PATCH 1/3] powerpc/smp: Parse ibm,thread-groups with multiple properties
* Gautham R Shenoy [2020-12-08 22:55:40]: > > > > NIT: > > tglx mentions in one of his recent comments to try keep a reverse fir tree > > ordering of variables where possible. > > I suppose you mean moving the longer local variable declarations to to > the top and shorter ones to the bottom. Thanks. Will fix this. > Yes. > > > + } > > > + > > > + if (!tg) > > > + return -EINVAL; > > > + > > > + cpu_group_start = get_cpu_thread_group_start(cpu, tg); > > > > This whole hunk should be moved to a new function and called before > > init_cpu_cache_map. It will simplify the logic to great extent. > > I suppose you are referring to the part where we select the correct > tg. Yeah, that can move to a different helper. > Yes, I would prefer if we could call this new helper outside init_cpu_cache_map. > > > > > > - zalloc_cpumask_var_node(_cpu(cpu_l1_cache_map, cpu), > > > - GFP_KERNEL, cpu_to_node(cpu)); > > > + mask = _cpu(cpu_l1_cache_map, cpu); > > > + > > > + zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu)); > > > > > > > This hunk (and the next hunk) should be moved to next patch. > > > > The next patch is only about introducing THREAD_GROUP_SHARE_L2. Hence > I put in any other code in this patch, since it seems to be a logical > place to collate whatever we have in a generic form. > While I am fine with it, having a pointer that always points to the same mask looks wierd. -- Thanks and Regards Srikar Dronamraju
Re: [PATCH 1/2] iov: introduce ITER_BVEC_FLAG_FIXED
Ok, seems like the patches made it to the lists, while oyu only
send the cover letter to my address which is very strange.
> diff --git a/include/linux/uio.h b/include/linux/uio.h
> index 72d88566694e..af626eb970cf 100644
> --- a/include/linux/uio.h
> +++ b/include/linux/uio.h
> @@ -18,6 +18,8 @@ struct kvec {
> };
>
> enum iter_type {
> + ITER_BVEC_FLAG_FIXED = 2,
> +
> /* iter types */
> ITER_IOVEC = 4,
> ITER_KVEC = 8,
This is making the iter type even more of a mess than it already is.
I think we at least need placeholders for 0/1 here and an explicit
flags namespace, preferably after the types.
Then again I'd much prefer if we didn't even add the flag or at best
just add it for a short-term transition and move everyone over to the
new scheme. Otherwise the amount of different interfaces and supporting
code keeps exploding.
> @@ -29,8 +31,9 @@ enum iter_type {
> struct iov_iter {
> /*
>* Bit 0 is the read/write bit, set if we're writing.
> - * Bit 1 is the BVEC_FLAG_NO_REF bit, set if type is a bvec and
> - * the caller isn't expecting to drop a page reference when done.
> + * Bit 1 is the BVEC_FLAG_FIXED bit, set if type is a bvec and the
> + * caller ensures that page references and memory baking bvec won't
> + * go away until callees finish with them.
>*/
> unsigned int type;
I think the comment needs to move to the enum.
Re: [BUG] SPI broken for SPI based panel drivers
On Sat, Dec 5, 2020 at 8:07 AM H. Nikolaus Schaller wrote: > I find it interesting that so far nobody wants to take responsibility > for a decision (...) What causes some consternation in this discussion is the appeal to higher authority. The kernel community in general does not like authority/responsibility by way of formal hierarchy. Have you read this document? Especially point 1) Decisions: https://www.kernel.org/doc/html/latest/process/management-style.html (We can have a meta-discussion about this but it is not really your point I believe.) > > What I can do is to provide just a skeleton for the table that you or Linus > > can fix/fill in and make a patch out of it. Is attached and the ??? is > > something you should discuss and define. > > Please take the attached diff, comment it here and define the question marks > according to your intention and then make a patch for the YAML bindings out > of it. (I can't do because I don't know your intentions and what to write into > the commit message). I'll comment what I know, then you can send a proper patch to Mark. But you really need more people than me to look at this. > + device node | cs-gpio | CS pin state active | Note > + +===+=+= > + spi-cs-high | - | H | > + - | - | L | > + spi-cs-high | ACTIVE_HIGH | H | > + - | ACTIVE_HIGH | L (or H ???)| 1 When using GPIO descriptors it will be enforced to ACTIVE_LOW (L) with an explicit warning in dmesg, see drivers/gpio/gpiolib-of.c When using legacy GPIOs, will be enforced ACTIVE_LOW by the SPI core. > + spi-cs-high | ACTIVE_LOW| H (or L ???)| 2 When using GPIO descriptors it will be enforced to ACTIVE_HIGH (H) with an explicit warning in dmesg, see drivers/gpio/gpiolib-of.c > + 3) Effectively this rule defines that the ACTIVE level of the > + gpio has to be ignored Nr 3 isn't tagged in the table. Yours, Linus Walleij
Re: [PATCH 3/3] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
* Gautham R Shenoy [2020-12-08 23:26:47]: > > The drawback of this is even if cpus 0,2,4,6 are released L1 cache will not > > be released. Is this as expected? > > cacheinfo populates the cache->shared_cpu_map on the basis of which > CPUs share the common device-tree node for a particular cache. There > is one l1-cache object in the device-tree for a CPU node corresponding > to a big-core. That the L1 is further split between the threads of the > core is shown using ibm,thread-groups. > Yes. > The ideal thing would be to add a "group_leader" field to "struct > cache" so that we can create separate cache objects , one per thread > group. I will take a stab at this in the v2. > I am not saying this needs to be done immediately. We could add a TODO and get it done later. Your patch is not making it worse. Its just that there is still something more left to be done. -- Thanks and Regards Srikar Dronamraju
Re: [PATCH] PCI: Remove pci_try_set_mwi
Heiner Kallweit writes: > pci_set_mwi() and pci_try_set_mwi() do exactly the same, just that the > former one is declared as __must_check. However also some callers of > pci_set_mwi() have a comment that it's an optional feature. I don't > think there's much sense in this separation and the use of > __must_check. Therefore remove pci_try_set_mwi() and remove the > __must_check attribute from pci_set_mwi(). > I don't expect either function to be used in new code anyway. > > Signed-off-by: Heiner Kallweit > --- > patch applies on top of pci/misc for v5.11 > drivers/net/wireless/intersil/p54/p54pci.c| 2 +- > .../intersil/prism54/islpci_hotplug.c | 3 +-- > .../wireless/realtek/rtl818x/rtl8180/dev.c| 2 +- For drivers/wireless: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/2] block: no-copy bvec for direct IO
> + /* > + * In practice groups of pages tend to be accessed/reclaimed/refaulted > + * together. To not go over bvec for those who didn't set BIO_WORKINGSET > + * approximate it by looking at the first page and inducing it to the > + * whole bio > + */ > + if (unlikely(PageWorkingset(iter->bvec->bv_page))) > + bio_set_flag(bio, BIO_WORKINGSET); IIRC the feedback was that we do not need to deal with BIO_WORKINGSET at all for direct I/O. > + bio_set_flag(bio, BIO_NO_PAGE_REF); > + > + iter->count = 0; > + return 0; > +} This helper should go into bio.c, next to bio_iov_iter_get_pages. And please convert the other callers of bio_iov_iter_get_pages to this scheme as well.
[PATCH 0/3] pinctrl: Added ZynqMP pinctrl driver
Added support for Xilinx ZynqMP pinctrl driver support and also updated the Xilinx firmware driver to support pinctrl functionality. This driver will query the pin information from the firmware and allow configuring the pins as per the request. Sai Krishna Potthuri (3): firmware: xilinx: Added pinctrl support dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver pinctrl: Added Xilinx ZynqMP pinctrl driver support .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 329 ++ drivers/firmware/xilinx/zynqmp.c | 114 ++ drivers/pinctrl/Kconfig | 13 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-zynqmp.c | 1031 + include/dt-bindings/pinctrl/pinctrl-zynqmp.h | 29 + include/linux/firmware/xlnx-zynqmp.h | 90 ++ 7 files changed, 1607 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h -- 2.17.1
[PATCH 1/3] firmware: xilinx: Added pinctrl support
Add pinctrl support to query platform specific information (pins)
from firmware.
Signed-off-by: Sai Krishna Potthuri
---
drivers/firmware/xilinx/zynqmp.c | 114 +++
include/linux/firmware/xlnx-zynqmp.h | 90 +
2 files changed, 204 insertions(+)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index efb8a66efc68..299c3d5a9ebd 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -784,6 +784,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
}
EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
+/**
+ * zynqmp_pm_pinctrl_request - Request Pin from firmware
+ * @pin: Pin number to request
+ *
+ * This function requests pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+ return zynqmp_pm_invoke_fn(PM_PINCTRL_REQUEST, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_request);
+
+/**
+ * zynqmp_pm_pinctrl_release - Inform firmware that Pin control is released
+ * @pin: Pin number to release
+ *
+ * This function release pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_release(const u32 pin)
+{
+ return zynqmp_pm_invoke_fn(PM_PINCTRL_RELEASE, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_release);
+
+/**
+ * zynqmp_pm_pinctrl_get_function - Read function id set for the given pin
+ * @pin: Pin number
+ * @id: Buffer to store function ID
+ *
+ * This function provides the function currently set for the given pin.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_pinctrl_get_function(const u32 pin, u32 *id)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!id)
+ return -EINVAL;
+
+ ret = zynqmp_pm_invoke_fn(PM_PINCTRL_GET_FUNCTION, pin, 0,
+ 0, 0, ret_payload);
+ *id = ret_payload[1];
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_function);
+
+/**
+ * zynqmp_pm_pinctrl_set_function - Set requested function for the pin
+ * @pin: Pin number
+ * @id: Function ID to set
+ *
+ * This function sets requested function for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_function(const u32 pin, const u32 id)
+{
+ return zynqmp_pm_invoke_fn(PM_PINCTRL_SET_FUNCTION, pin, id,
+ 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_function);
+
+/**
+ * zynqmp_pm_pinctrl_get_config - Get configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to get
+ * @value: Buffer to store parameter value
+ *
+ * This function gets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+u32 *value)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!value)
+ return -EINVAL;
+
+ ret = zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_GET, pin, param,
+ 0, 0, ret_payload);
+ *value = ret_payload[1];
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_config);
+
+/**
+ * zynqmp_pm_pinctrl_set_config - Set configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to set
+ * @value: Parameter value to set
+ *
+ * This function sets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+u32 value)
+{
+ return zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_SET, pin,
+ param, value, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_config);
+
/**
* zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
*master has initialized its own power management
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..75aa6a5afa28 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -74,6 +74,12 @@ enum pm_api_id {
PM_FPGA_LOAD,
PM_FPGA_GET_STATUS,
PM_GET_CHIPID = 24,
+ PM_PINCTRL_REQUEST = 28,
+ PM_PINCTRL_RELEASE = 29,
+ PM_PINCTRL_GET_FUNCTION = 30,
+ PM_PINCTRL_SET_FUNCTION = 31,
+ PM_PINCTRL_CONFIG_PARAM_GET = 32,
+ PM_PINCTRL_CONFIG_PARAM_SET = 33,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -125,6 +131,12 @@ enum pm_query_id {
PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
PM_QID_CLOCK_GET_PARENTS,
PM_QID_CLOCK_GET_ATTRIBUTES,
+ PM_QID_PINCTRL_GET_NUM_PINS = 6,
+
[PATCH 3/3] pinctrl: Added Xilinx ZynqMP pinctrl driver support
Added pinctrl driver for Xilinx ZynqMP platform.
This driver queries pin information from firmware and registers
pin control accordingly.
Signed-off-by: Sai Krishna Potthuri
---
drivers/pinctrl/Kconfig | 13 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-zynqmp.c | 1031 ++
3 files changed, 1045 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 815095326e2d..25d3c7208975 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
help
This selects the pinctrl driver for Xilinx Zynq.
+config PINCTRL_ZYNQMP
+ bool "Pinctrl driver for Xilinx ZynqMP"
+ depends on ARCH_ZYNQMP
+ select PINMUX
+ select GENERIC_PINCONF
+ help
+ This selects the pinctrl driver for Xilinx ZynqMP platform.
+ This driver will query the pin information from the firmware
+ and allow configuring the pins.
+ Configuration can include the mux function to select on those
+ pin(s)/group(s), and various pin configuration parameters
+ such as pull-up, slew rate, etc.
+
config PINCTRL_INGENIC
bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f53933b2ff02..7e058739f0d5 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X) += pinctrl-tb10x.o
obj-$(CONFIG_PINCTRL_ST) += pinctrl-st.o
obj-$(CONFIG_PINCTRL_STMFX)+= pinctrl-stmfx.o
obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
+obj-$(CONFIG_PINCTRL_ZYNQMP)+= pinctrl-zynqmp.o
obj-$(CONFIG_PINCTRL_INGENIC) += pinctrl-ingenic.o
obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
obj-$(CONFIG_PINCTRL_OCELOT) += pinctrl-ocelot.o
diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
new file mode 100644
index ..0694cd6fc753
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -0,0 +1,1031 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP pin controller
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Sai Krishna Potthuri
+ * Rajan Vaja
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "core.h"
+#include "pinctrl-utils.h"
+
+#define ZYNQMP_PIN_PREFIX "MIO"
+#define PINCTRL_GET_FUNC_NAME_RESP_LEN 16
+#define MAX_FUNC_NAME_LEN 16
+#define MAX_GROUP_PIN 50
+#define END_OF_FUNCTIONS "END_OF_FUNCTIONS"
+#define NUM_GROUPS_PER_RESP6
+
+#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN 12
+#define PINCTRL_GET_PIN_GROUPS_RESP_LEN12
+#define NA_GROUP -1
+#define RESERVED_GROUP -2
+
+/**
+ * struct zynqmp_pmux_function - a pinmux function
+ * @name: Name of the pinmux function
+ * @groups:List of pingroups for this function
+ * @ngroups: Number of entries in @groups
+ * @node:` Firmware node matching with for function
+ *
+ * This structure holds information about pin control function
+ * and function group names supporting that function.
+ */
+struct zynqmp_pmux_function {
+ char name[MAX_FUNC_NAME_LEN];
+ const char * const *groups;
+ unsigned int ngroups;
+};
+
+/**
+ * struct zynqmp_pinctrl - driver data
+ * @pctrl: Pinctrl device
+ * @groups:Pingroups
+ * @ngroups: Number of @groups
+ * @funcs: Pinmux functions
+ * @nfuncs:Number of @funcs
+ *
+ * This struct is stored as driver data and used to retrieve
+ * information regarding pin control functions, groups and
+ * group pins.
+ */
+struct zynqmp_pinctrl {
+ struct pinctrl_dev *pctrl;
+ const struct zynqmp_pctrl_group *groups;
+ unsigned int ngroups;
+ const struct zynqmp_pmux_function *funcs;
+ unsigned int nfuncs;
+};
+
+/**
+ * struct zynqmp_pctrl_group - Pin control group info
+ * @name: Group name
+ * @pins: Group pin numbers
+ * @npins: Number of pins in group
+ */
+struct zynqmp_pctrl_group {
+ const char *name;
+ unsigned int pins[MAX_GROUP_PIN];
+ unsigned int npins;
+};
+
+/**
+ * enum zynqmp_pin_config_param - possible pin configuration parameters
+ * @PIN_CONFIG_IOSTANDARD: if the pin can select an IO standard,
+ * the argument to this parameter (on a
+ * custom format) tells the driver which
+ * alternative IO standard to use
+ * @PIN_CONFIG_SCHMITTCMOS:this parameter (on a custom format) allows
+ * to select schmitt or cmos input for MIO pins
+ */
+enum zynqmp_pin_config_param {
+ PIN_CONFIG_IOSTANDARD = PIN_CONFIG_END + 1,
+ PIN_CONFIG_SCHMITTCMOS,
[PATCH 2/3] dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver
Added documentation and dt-bindings file which contains MIO pin configuration defines for Xilinx ZynqMP pinctrl driver. Signed-off-by: Sai Krishna Potthuri --- .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 329 ++ include/dt-bindings/pinctrl/pinctrl-zynqmp.h | 29 ++ 2 files changed, 358 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml new file mode 100644 index ..dd0c8c12714f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml @@ -0,0 +1,329 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP Pinctrl + +maintainers: + - Sai Krishna Potthuri + - Rajan Vaja + +description: | + Please refer to pinctrl-bindings.txt in this directory for details of the + common pinctrl bindings used by client devices, including the meaning of the + phrase "pin configuration node". + + ZynqMP's pin configuration nodes act as a container for an arbitrary number of + subnodes. Each of these subnodes represents some desired configuration for a + pin, a group, or a list of pins or groups. This configuration can include the + mux function to select on those pin(s)/group(s), and various pin configuration + parameters, such as pull-up, slew rate, etc. + + Each configuration node can consist of multiple nodes describing the pinmux and + pinconf options. Those nodes can be pinmux nodes or pinconf nodes. + + The name of each subnode is not important; all subnodes should be enumerated + and processed purely based on their content. + +properties: + compatible: +const: xlnx,zynqmp-pinctrl + +patternProperties: + '^(.*-)?(default|gpio)$': +type: object +patternProperties: + '^(.*-)?mux$': +type: object +description: + Pinctrl node's client devices use subnodes for pin muxes, + which in turn use below standard properties. +$ref: pinmux-node.yaml# + +properties: + groups: +description: + List of groups to select (either this or "pins" must be + specified), available groups for this subnode. +enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp, + ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp, + gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp, + mdio1_1_grp, mdio2_0_grp, mdio3_0_grp, + qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp, + spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp, + spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp, + spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp, + spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp, + spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp, + spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp, + spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp, + spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp, + spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp, + spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp, + spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp, + spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp, + spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp, + spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp, + spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp, + spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp, + sdio0_0_grp, sdio0_1_grp, sdio0_2_grp, + sdio0_3_grp, sdio0_4_grp, sdio0_5_grp, + sdio0_6_grp, sdio0_7_grp, sdio0_8_grp, + sdio0_9_grp, sdio0_10_grp, sdio0_11_grp, + sdio0_12_grp, sdio0_13_grp, sdio0_14_grp, + sdio0_15_grp, sdio0_16_grp, sdio0_17_grp, + sdio0_18_grp, sdio0_19_grp, sdio0_20_grp, + sdio0_21_grp, sdio0_22_grp, sdio0_23_grp, + sdio0_24_grp, sdio0_25_grp, sdio0_26_grp, + sdio0_27_grp, sdio0_28_grp, sdio0_29_grp, + sdio0_30_grp, sdio0_31_grp, sdio0_32_grp, + sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp, + sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp, + sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp, + sdio1_0_grp, sdio1_1_grp, sdio1_2_grp, + sdio1_3_grp, sdio1_4_grp, sdio1_5_grp, + sdio1_6_grp, sdio1_7_grp, sdio1_8_grp, + sdio1_9_grp, sdio1_10_grp, sdio1_11_grp, +
Re: [f2fs-dev] [PATCH v4] f2fs: compress: support chksum
On 2020/12/9 16:31, Chao Yu wrote:
On 2020/12/9 16:23, Jaegeuk Kim wrote:
On 12/09, Chao Yu wrote:
On 2020/12/9 12:28, Chao Yu wrote:
On 2020/12/9 11:54, Jaegeuk Kim wrote:
Ah, could you please write another patch to adjust the new changes?
No problem, will drop "f2fs: compress:support chksum" based on your dev branch,
and
apply all compress related patches on top of dev branch.
Jaegeuk, could you please
- drop "f2fs: compress:support chksum",
What I mean is keeping the old version in dev branch as is, since it gives
another conflicts when dropping it. That can add another bug at this point.
Can I get a separate patch to fix any issues in that original patch?
Oops...
The diff is as below:
From 1ad86c640d3a295292960f6b90802cc5a9be7a0d Mon Sep 17 00:00:00 2001
From: Chao Yu
Date: Wed, 9 Dec 2020 16:36:58 +0800
Subject: [PATCH] fix_chksum
Signed-off-by: Chao Yu
---
fs/f2fs/compress.c | 3 +--
fs/f2fs/compress.h | 0
2 files changed, 1 insertion(+), 2 deletions(-)
create mode 100644 fs/f2fs/compress.h
diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index f05d409fd0ed..4bcbacfe3325 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -796,7 +796,7 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
ret = cops->decompress_pages(dic);
- if (!ret && fi->i_compress_flag & 1 << COMPRESS_CHKSUM) {
+ if (!ret && (fi->i_compress_flag & 1 << COMPRESS_CHKSUM)) {
u32 provided = le32_to_cpu(dic->cbuf->chksum);
u32 calculated = f2fs_crc32(sbi, dic->cbuf->cdata, dic->clen);
@@ -809,7 +809,6 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
provided, calculated);
}
set_sbi_flag(sbi, SBI_NEED_FSCK);
- WARN_ON_ONCE(1);
}
}
diff --git a/fs/f2fs/compress.h b/fs/f2fs/compress.h
new file mode 100644
index ..e69de29bb2d1
--
2.29.2
Thanks,
- manually fix conflict when applying "f2fs: add compress_mode mount option"
- and then apply last my resent patches.
Thanks,
.
___
Linux-f2fs-devel mailing list
linux-f2fs-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
.
Re: [PATCH] gpio: eic-sprd: break loop when getting NULL device resource
On Wed, Dec 9, 2020 at 6:51 AM Chunyan Zhang wrote:
> EIC controller have unfixed numbers of banks on different Spreadtrum SoCs,
> and each bank has its own base address, the loop of getting there base
> address in driver should break if the resource gotten via
> platform_get_resource() is NULL already. The later ones would be all NULL
> even if the loop continues.
>
> Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
> Signed-off-by: Chunyan Zhang
Patch applied for fixes!
Yours,
Linus Walleij
[tip: x86/urgent] membarrier: Explicitly sync remote cores when SYNC_CORE is requested
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 758c9373d84168dc7d039cf85a0e920046b17b41
Gitweb:
https://git.kernel.org/tip/758c9373d84168dc7d039cf85a0e920046b17b41
Author:Andy Lutomirski
AuthorDate:Thu, 03 Dec 2020 21:07:05 -08:00
Committer: Thomas Gleixner
CommitterDate: Wed, 09 Dec 2020 09:37:43 +01:00
membarrier: Explicitly sync remote cores when SYNC_CORE is requested
membarrier() does not explicitly sync_core() remote CPUs; instead, it
relies on the assumption that an IPI will result in a core sync. On x86,
this may be true in practice, but it's not architecturally reliable. In
particular, the SDM and APM do not appear to guarantee that interrupt
delivery is serializing. While IRET does serialize, IPI return can
schedule, thereby switching to another task in the same mm that was
sleeping in a syscall. The new task could then SYSRET back to usermode
without ever executing IRET.
Make this more robust by explicitly calling sync_core_before_usermode()
on remote cores. (This also helps people who search the kernel tree for
instances of sync_core() and sync_core_before_usermode() -- one might be
surprised that the core membarrier code doesn't currently show up in a
such a search.)
Fixes: 70216e18e519 ("membarrier: Provide core serializing command,
*_SYNC_CORE")
Signed-off-by: Andy Lutomirski
Signed-off-by: Thomas Gleixner
Reviewed-by: Mathieu Desnoyers
Cc: sta...@vger.kernel.org
Link:
https://lore.kernel.org/r/776b448d5f7bd6b12690707f5ed67bcda7f1d427.1607058304.git.l...@kernel.org
---
kernel/sched/membarrier.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index 7d98ef5..1c278df 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -38,6 +38,23 @@ static void ipi_mb(void *info)
smp_mb(); /* IPIs should be serializing but paranoid. */
}
+static void ipi_sync_core(void *info)
+{
+ /*
+* The smp_mb() in membarrier after all the IPIs is supposed to
+* ensure that memory on remote CPUs that occur before the IPI
+* become visible to membarrier()'s caller -- see scenario B in
+* the big comment at the top of this file.
+*
+* A sync_core() would provide this guarantee, but
+* sync_core_before_usermode() might end up being deferred until
+* after membarrier()'s smp_mb().
+*/
+ smp_mb(); /* IPIs should be serializing but paranoid. */
+
+ sync_core_before_usermode();
+}
+
static void ipi_rseq(void *info)
{
/*
@@ -162,6 +179,7 @@ static int membarrier_private_expedited(int flags, int
cpu_id)
if (!(atomic_read(>membarrier_state) &
MEMBARRIER_STATE_PRIVATE_EXPEDITED_SYNC_CORE_READY))
return -EPERM;
+ ipi_func = ipi_sync_core;
} else if (flags == MEMBARRIER_FLAG_RSEQ) {
if (!IS_ENABLED(CONFIG_RSEQ))
return -EINVAL;
[tip: x86/urgent] membarrier: Add an actual barrier before rseq_preempt()
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 2ecedd7569080fd05c1a457e8af2165afecfa29f
Gitweb:
https://git.kernel.org/tip/2ecedd7569080fd05c1a457e8af2165afecfa29f
Author:Andy Lutomirski
AuthorDate:Thu, 03 Dec 2020 21:07:04 -08:00
Committer: Thomas Gleixner
CommitterDate: Wed, 09 Dec 2020 09:37:43 +01:00
membarrier: Add an actual barrier before rseq_preempt()
It seems that most RSEQ membarrier users will expect any stores done before
the membarrier() syscall to be visible to the target task(s). While this
is extremely likely to be true in practice, nothing actually guarantees it
by a strict reading of the x86 manuals. Rather than providing this
guarantee by accident and potentially causing a problem down the road, just
add an explicit barrier.
Fixes: 70216e18e519 ("membarrier: Provide core serializing command,
*_SYNC_CORE")
Signed-off-by: Andy Lutomirski
Signed-off-by: Thomas Gleixner
Reviewed-by: Mathieu Desnoyers
Cc: sta...@vger.kernel.org
Link:
https://lore.kernel.org/r/d3e7197e034fa4852afcf370ca49c30496e58e40.1607058304.git.l...@kernel.org
---
kernel/sched/membarrier.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index e23e74d..7d98ef5 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -40,6 +40,14 @@ static void ipi_mb(void *info)
static void ipi_rseq(void *info)
{
+ /*
+* Ensure that all stores done by the calling thread are visible
+* to the current task before the current task resumes. We could
+* probably optimize this away on most architectures, but by the
+* time we've already sent an IPI, the cost of the extra smp_mb()
+* is negligible.
+*/
+ smp_mb();
rseq_preempt(current);
}
[tip: x86/urgent] membarrier: Execute SYNC_CORE on the calling thread
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: e45cdc71d1fa5ac3a57b23acc31eb959e4f60135
Gitweb:
https://git.kernel.org/tip/e45cdc71d1fa5ac3a57b23acc31eb959e4f60135
Author:Andy Lutomirski
AuthorDate:Thu, 03 Dec 2020 21:07:06 -08:00
Committer: Thomas Gleixner
CommitterDate: Wed, 09 Dec 2020 09:37:43 +01:00
membarrier: Execute SYNC_CORE on the calling thread
membarrier()'s MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE is documented as
syncing the core on all sibling threads but not necessarily the calling
thread. This behavior is fundamentally buggy and cannot be used safely.
Suppose a user program has two threads. Thread A is on CPU 0 and thread B
is on CPU 1. Thread A modifies some text and calls
membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE).
Then thread B executes the modified code. If, at any point after
membarrier() decides which CPUs to target, thread A could be preempted and
replaced by thread B on CPU 0. This could even happen on exit from the
membarrier() syscall. If this happens, thread B will end up running on CPU
0 without having synced.
In principle, this could be fixed by arranging for the scheduler to issue
sync_core_before_usermode() whenever switching between two threads in the
same mm if there is any possibility of a concurrent membarrier() call, but
this would have considerable overhead. Instead, make membarrier() sync the
calling CPU as well.
As an optimization, this avoids an extra smp_mb() in the default
barrier-only mode and an extra rseq preempt on the caller.
Fixes: 70216e18e519 ("membarrier: Provide core serializing command,
*_SYNC_CORE")
Signed-off-by: Andy Lutomirski
Signed-off-by: Thomas Gleixner
Reviewed-by: Mathieu Desnoyers
Link:
https://lore.kernel.org/r/250ded637696d490c69bef1877148db86066881c.1607058304.git.l...@kernel.org
---
kernel/sched/membarrier.c | 51 --
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index 1c278df..9d8df34 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -194,7 +194,8 @@ static int membarrier_private_expedited(int flags, int
cpu_id)
return -EPERM;
}
- if (atomic_read(>mm_users) == 1 || num_online_cpus() == 1)
+ if (flags != MEMBARRIER_FLAG_SYNC_CORE &&
+ (atomic_read(>mm_users) == 1 || num_online_cpus() == 1))
return 0;
/*
@@ -213,8 +214,6 @@ static int membarrier_private_expedited(int flags, int
cpu_id)
if (cpu_id >= nr_cpu_ids || !cpu_online(cpu_id))
goto out;
- if (cpu_id == raw_smp_processor_id())
- goto out;
rcu_read_lock();
p = rcu_dereference(cpu_rq(cpu_id)->curr);
if (!p || p->mm != mm) {
@@ -229,16 +228,6 @@ static int membarrier_private_expedited(int flags, int
cpu_id)
for_each_online_cpu(cpu) {
struct task_struct *p;
- /*
-* Skipping the current CPU is OK even through we can be
-* migrated at any point. The current CPU, at the point
-* where we read raw_smp_processor_id(), is ensured to
-* be in program order with respect to the caller
-* thread. Therefore, we can skip this CPU from the
-* iteration.
-*/
- if (cpu == raw_smp_processor_id())
- continue;
p = rcu_dereference(cpu_rq(cpu)->curr);
if (p && p->mm == mm)
__cpumask_set_cpu(cpu, tmpmask);
@@ -246,12 +235,38 @@ static int membarrier_private_expedited(int flags, int
cpu_id)
rcu_read_unlock();
}
- preempt_disable();
- if (cpu_id >= 0)
+ if (cpu_id >= 0) {
+ /*
+* smp_call_function_single() will call ipi_func() if cpu_id
+* is the calling CPU.
+*/
smp_call_function_single(cpu_id, ipi_func, NULL, 1);
- else
- smp_call_function_many(tmpmask, ipi_func, NULL, 1);
- preempt_enable();
+ } else {
+ /*
+* For regular membarrier, we can save a few cycles by
+* skipping the current cpu -- we're about to do smp_mb()
+* below, and if we migrate to a different cpu, this cpu
+* and the new cpu will execute a full barrier in the
+* scheduler.
+*
+* For SYNC_CORE, we do need a barrier on the current cpu --
+* otherwise, if we are migrated and replaced by a different
+* task in the same mm just before, during,
[tip: x86/urgent] x86/membarrier: Get rid of a dubious optimization
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: a493d1ca1a03b532871f1da27f8dbda2b28b04c4
Gitweb:
https://git.kernel.org/tip/a493d1ca1a03b532871f1da27f8dbda2b28b04c4
Author:Andy Lutomirski
AuthorDate:Thu, 03 Dec 2020 21:07:03 -08:00
Committer: Thomas Gleixner
CommitterDate: Wed, 09 Dec 2020 09:37:42 +01:00
x86/membarrier: Get rid of a dubious optimization
sync_core_before_usermode() had an incorrect optimization. If the kernel
returns from an interrupt, it can get to usermode without IRET. It just has
to schedule to a different task in the same mm and do SYSRET. Fortunately,
there were no callers of sync_core_before_usermode() that could have had
in_irq() or in_nmi() equal to true, because it's only ever called from the
scheduler.
While at it, clarify a related comment.
Fixes: 70216e18e519 ("membarrier: Provide core serializing command,
*_SYNC_CORE")
Signed-off-by: Andy Lutomirski
Signed-off-by: Thomas Gleixner
Reviewed-by: Mathieu Desnoyers
Cc: sta...@vger.kernel.org
Link:
https://lore.kernel.org/r/5afc7632be1422f91eaf76111b5b8580a086.1607058304.git.l...@kernel.org
---
arch/x86/include/asm/sync_core.h | 9 +
arch/x86/mm/tlb.c| 10 --
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/sync_core.h b/arch/x86/include/asm/sync_core.h
index 0fd4a9d..ab7382f 100644
--- a/arch/x86/include/asm/sync_core.h
+++ b/arch/x86/include/asm/sync_core.h
@@ -98,12 +98,13 @@ static inline void sync_core_before_usermode(void)
/* With PTI, we unconditionally serialize before running user code. */
if (static_cpu_has(X86_FEATURE_PTI))
return;
+
/*
-* Return from interrupt and NMI is done through iret, which is core
-* serializing.
+* Even if we're in an interrupt, we might reschedule before returning,
+* in which case we could switch to a different thread in the same mm
+* and return using SYSRET or SYSEXIT. Instead of trying to keep
+* track of our need to sync the core, just sync right away.
*/
- if (in_irq() || in_nmi())
- return;
sync_core();
}
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 11666ba..569ac1d 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -474,8 +474,14 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
mm_struct *next,
/*
* The membarrier system call requires a full memory barrier and
* core serialization before returning to user-space, after
-* storing to rq->curr. Writing to CR3 provides that full
-* memory barrier and core serializing instruction.
+* storing to rq->curr, when changing mm. This is because
+* membarrier() sends IPIs to all CPUs that are in the target mm
+* to make them issue memory barriers. However, if another CPU
+* switches to/from the target mm concurrently with
+* membarrier(), it can cause that CPU not to receive an IPI
+* when it really should issue a memory barrier. Writing to CR3
+* provides that full memory barrier and core serializing
+* instruction.
*/
if (real_prev == next) {
VM_WARN_ON(this_cpu_read(cpu_tlbstate.ctxs[prev_asid].ctx_id) !=
Re: [BUG] SPI broken for SPI based panel drivers
Hi Andreas, > Am 09.12.2020 um 09:04 schrieb Andreas Kemnade : > > Hi, > > On Sat, 5 Dec 2020 08:04:25 +0100 > "H. Nikolaus Schaller" wrote: > >> Hi Linus, >> >>> Am 05.12.2020 um 01:25 schrieb Linus Walleij : >>> >>> On Fri, Dec 4, 2020 at 5:52 PM H. Nikolaus Schaller >>> wrote: >>> But what I don't know is if I can omit spi-cs-high and have to keep ACTIVE_HIGH (my revert patch) or also change to ACTIVE_LOW (my additional patch). This is arbitrary and someone has to decide what it should be. >>> (...) I'd prefer if you or maybe Linus could submit such a patch and I am happy to review it. >>> >>> It seems really ill-advised to have me do that since I have not >>> managed very well to deal with this. Clearly better developers >>> are needed. But I can review a patch and see if it makes me >>> smarter :) > > Hmm, if those developers are not available, then probably finding > those bugs has to be time-optimized, like establishing better automatic > display testing. Well, I don't think we need automatic display testing. We just need to test if any SPI CS behaves correctly according to some specification. Then all displays and other chips will work - unless they have a bug in their DT. Basically it would need a software unit-test going through all 6 variants of having spi-cs-high and gpiod and parameters and looking if the chip (maybe some SPI EEPROM with known SPI polarity) responds or not. This can be done with hardware SPI controllers and spi-gpio. And it can be re-run each time something significant in gpiolib or spi-gpio is changed. > >> >> I find it interesting that so far nobody wants to take responsibility >> for a decision and to write down the behaviour really should be. Coding >> is the second step then. >> > well, the interesting people are not involved yet (DTML) because no > patch is sent. Well, I think we (gpiolib maintainers, spi maintainers and users of it) are the right ones to define the truth table. This is not primarily a DT issue, it is a matter of what we want to have and then it is cast it into DT (documentation). So I am not sure if delegation to someone else solves it. > >> Anyways you did not cite the really important part of my mail. So let me >> copy it back. Here it is again: >> >>> What I can do is to provide just a skeleton for the table that you or Linus >>> can fix/fill in and make a patch out of it. Is attached and the ??? is >>> something you should discuss and define. >> >> Please take the attached diff, comment it here and define the question marks >> according to your intention and then make a patch for the YAML bindings out >> of it. (I can't do because I don't know your intentions and what to write >> into >> the commit message). >> > Well, I the easiest step forward is just to document clearer how things > behave now, so the commit message is just something like > > "Behavior of CS signal is not clearly documented, clarify the > documentation". And then send the patch to the proper mailing lists > including devicetree folks. Ok, that looks like a good solution to get out of the deadlock. BR and thanks, Nikolaus > > Regards, > Andreas > >> As soon as we have settled this, we can check if code is correct and really >> define if my device tree fits and which change it needs exactly. >> >> BR and thanks, >> Nikolaus >> >> [slightly edited] >> >> diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml >> b/Documentation/devicetree/bindings/spi/spi-controller.yaml >> index 1b56d5e40f1f..4f8755dabecc 100644 >> --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml >> +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml >> @@ -42,6 +42,30 @@ properties: >>cs2 : 1 0 >>cs3 : 2 0 >> >> + The second flag of a gpio descriptor can be GPIO_ACTIVE_HIGH/0 >> + or GPIO_ACTIVE_LOW/1. >> + >> + There is a special rule set for combining the second flag of an >> + cs-gpio with the optional spi-cs-high flag for SPI slaves. >> + >> + Each table entry defines how the CS pin is physically driven >> + (not considering potential gpio inversions by pinmux): >> + >> + device node | cs-gpio | CS pin state active | Note >> + +===+=+= >> + spi-cs-high | - | H | >> + - | - | L | >> + spi-cs-high | ACTIVE_HIGH | H | >> + - | ACTIVE_HIGH | L (or H ???)| 1 >> + spi-cs-high | ACTIVE_LOW| H (or L ???)| 2 >> + - | ACTIVE_LOW| L | >> + >> + Notes: >> + 1) should print a warning about polarity inversion >> + because here it would be wise to define the gpio as ACTIVE_LOW >> + 2) could print a warning about polarity inversion >> + because ACTIVE_LOW is
[PATCH RESEND v2 2/5] f2fs: compress: support compress level
Expand 'compress_algorithm' mount option to accept parameter as format of
:, by this way, it gives a way to allow user to do more
specified config on lz4 and zstd compression level, then f2fs compression
can provide higher compress ratio.
In order to set compress level for lz4 algorithm, it needs to set
CONFIG_LZ4HC_COMPRESS and CONFIG_F2FS_FS_LZ4HC config to enable lz4hc
compress algorithm.
CR and performance number on lz4/lz4hc algorithm:
dd if=enwik9 of=compressed_file conv=fsync
Original blocks:244382
lz4 lz4hc-9
compressed blocks 170647 163270
compress ratio 69.8% 66.8%
speed 16.4207 s, 60.9 MB/s26.7299 s, 37.4 MB/s
compress ratio = after / before
Signed-off-by: Chao Yu
---
Documentation/filesystems/f2fs.rst | 5 +++
fs/f2fs/Kconfig| 10 +
fs/f2fs/compress.c | 41 +++--
fs/f2fs/f2fs.h | 9
fs/f2fs/super.c| 71 +-
include/linux/f2fs_fs.h| 3 ++
6 files changed, 134 insertions(+), 5 deletions(-)
diff --git a/Documentation/filesystems/f2fs.rst
b/Documentation/filesystems/f2fs.rst
index 5fa45fd8e4af..cd1e5b826ba3 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -249,6 +249,11 @@ checkpoint=%s[:%u[%]] Set to "disable" to turn off
checkpointing. Set to "enabl
This space is reclaimed once checkpoint=enable.
compress_algorithm=%s Control compress algorithm, currently f2fs supports
"lzo",
"lz4", "zstd" and "lzo-rle" algorithm.
+compress_algorithm=%s:%d Control compress algorithm and its compress level,
now, only
+"lz4" and "zstd" support compress level config.
+algorithm level range
+lz43 - 16
+zstd 1 - 22
compress_log_size=%uSupport configuring compress cluster size, the size
will
be 4KB * (1 << %u), 16KB is minimum size, also it's
default size.
diff --git a/fs/f2fs/Kconfig b/fs/f2fs/Kconfig
index d13c5c6a9787..63c1fc1a0e3b 100644
--- a/fs/f2fs/Kconfig
+++ b/fs/f2fs/Kconfig
@@ -119,6 +119,16 @@ config F2FS_FS_LZ4
help
Support LZ4 compress algorithm, if unsure, say Y.
+config F2FS_FS_LZ4HC
+ bool "LZ4HC compression support"
+ depends on F2FS_FS_COMPRESSION
+ depends on F2FS_FS_LZ4
+ select LZ4HC_COMPRESS
+ default y
+ help
+ Support LZ4HC compress algorithm, LZ4HC has compatible on-disk
+ layout with LZ4, if unsure, say Y.
+
config F2FS_FS_ZSTD
bool "ZSTD compression support"
depends on F2FS_FS_COMPRESSION
diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 446dd41a7bad..8840f5f41bf1 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -254,8 +254,14 @@ static const struct f2fs_compress_ops f2fs_lzo_ops = {
#ifdef CONFIG_F2FS_FS_LZ4
static int lz4_init_compress_ctx(struct compress_ctx *cc)
{
- cc->private = f2fs_kvmalloc(F2FS_I_SB(cc->inode),
- LZ4_MEM_COMPRESS, GFP_NOFS);
+ unsigned int size = LZ4_MEM_COMPRESS;
+
+#ifdef CONFIG_F2FS_FS_LZ4HC
+ if (F2FS_I(cc->inode)->i_compress_flag >> COMPRESS_LEVEL_OFFSET)
+ size = LZ4HC_MEM_COMPRESS;
+#endif
+
+ cc->private = f2fs_kvmalloc(F2FS_I_SB(cc->inode), size, GFP_NOFS);
if (!cc->private)
return -ENOMEM;
@@ -274,10 +280,34 @@ static void lz4_destroy_compress_ctx(struct compress_ctx
*cc)
cc->private = NULL;
}
+#ifdef CONFIG_F2FS_FS_LZ4HC
+static int lz4hc_compress_pages(struct compress_ctx *cc)
+{
+ unsigned char level = F2FS_I(cc->inode)->i_compress_flag >>
+ COMPRESS_LEVEL_OFFSET;
+ int len;
+
+ if (level)
+ len = LZ4_compress_HC(cc->rbuf, cc->cbuf->cdata, cc->rlen,
+ cc->clen, level, cc->private);
+ else
+ len = LZ4_compress_default(cc->rbuf, cc->cbuf->cdata, cc->rlen,
+ cc->clen, cc->private);
+ if (!len)
+ return -EAGAIN;
+
+ cc->clen = len;
+ return 0;
+}
+#endif
+
static int lz4_compress_pages(struct compress_ctx *cc)
{
int len;
+#ifdef CONFIG_F2FS_FS_LZ4HC
+ return lz4hc_compress_pages(cc);
+#endif
len = LZ4_compress_default(cc->rbuf, cc->cbuf->cdata, cc->rlen,
cc->clen, cc->private);
if (!len)
@@ -327,8 +357,13 @@ static int zstd_init_compress_ctx(struct compress_ctx *cc)
ZSTD_CStream *stream;
void *workspace;
unsigned int workspace_size;
+ unsigned char level =
[PATCH RESEND v2 4/5] f2fs: introduce a new per-sb directory in sysfs
Add a new directory 'stat' in path of /sys/fs/f2fs//, later
we can add new readonly stat sysfs file into this directory, it will
make directory less mess.
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h | 5 +++-
fs/f2fs/sysfs.c | 69 +
2 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index fbaef39e51df..cb94f650ec3d 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1549,9 +1549,12 @@ struct f2fs_sb_info {
unsigned int node_io_flag;
/* For sysfs suppport */
- struct kobject s_kobj;
+ struct kobject s_kobj; /* /sys/fs/f2fs/ */
struct completion s_kobj_unregister;
+ struct kobject s_stat_kobj; /* /sys/fs/f2fs//stat
*/
+ struct completion s_stat_kobj_unregister;
+
/* For shrinker support */
struct list_head s_list;
int s_ndevs;/* number of devices */
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index 989a649cfa8b..ebca0b4961e8 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -711,6 +711,11 @@ static struct attribute *f2fs_feat_attrs[] = {
};
ATTRIBUTE_GROUPS(f2fs_feat);
+static struct attribute *f2fs_stat_attrs[] = {
+ NULL,
+};
+ATTRIBUTE_GROUPS(f2fs_stat);
+
static const struct sysfs_ops f2fs_attr_ops = {
.show = f2fs_attr_show,
.store = f2fs_attr_store,
@@ -739,6 +744,44 @@ static struct kobject f2fs_feat = {
.kset = _kset,
};
+static ssize_t f2fs_stat_attr_show(struct kobject *kobj,
+ struct attribute *attr, char *buf)
+{
+ struct f2fs_sb_info *sbi = container_of(kobj, struct f2fs_sb_info,
+ s_stat_kobj);
+ struct f2fs_attr *a = container_of(attr, struct f2fs_attr, attr);
+
+ return a->show ? a->show(a, sbi, buf) : 0;
+}
+
+static ssize_t f2fs_stat_attr_store(struct kobject *kobj, struct attribute
*attr,
+ const char *buf, size_t len)
+{
+ struct f2fs_sb_info *sbi = container_of(kobj, struct f2fs_sb_info,
+ s_stat_kobj);
+ struct f2fs_attr *a = container_of(attr, struct f2fs_attr, attr);
+
+ return a->store ? a->store(a, sbi, buf, len) : 0;
+}
+
+static void f2fs_stat_kobj_release(struct kobject *kobj)
+{
+ struct f2fs_sb_info *sbi = container_of(kobj, struct f2fs_sb_info,
+ s_stat_kobj);
+ complete(>s_stat_kobj_unregister);
+}
+
+static const struct sysfs_ops f2fs_stat_attr_ops = {
+ .show = f2fs_stat_attr_show,
+ .store = f2fs_stat_attr_store,
+};
+
+static struct kobj_type f2fs_stat_ktype = {
+ .default_groups = f2fs_stat_groups,
+ .sysfs_ops = _stat_attr_ops,
+ .release= f2fs_stat_kobj_release,
+};
+
static int __maybe_unused segment_info_seq_show(struct seq_file *seq,
void *offset)
{
@@ -945,11 +988,15 @@ int f2fs_register_sysfs(struct f2fs_sb_info *sbi)
init_completion(>s_kobj_unregister);
err = kobject_init_and_add(>s_kobj, _sb_ktype, NULL,
"%s", sb->s_id);
- if (err) {
- kobject_put(>s_kobj);
- wait_for_completion(>s_kobj_unregister);
- return err;
- }
+ if (err)
+ goto put_sb_kobj;
+
+ sbi->s_stat_kobj.kset = _kset;
+ init_completion(>s_stat_kobj_unregister);
+ err = kobject_init_and_add(>s_stat_kobj, _stat_ktype,
+ >s_kobj, "stat");
+ if (err)
+ goto put_stat_kobj;
if (f2fs_proc_root)
sbi->s_proc = proc_mkdir(sb->s_id, f2fs_proc_root);
@@ -965,6 +1012,13 @@ int f2fs_register_sysfs(struct f2fs_sb_info *sbi)
victim_bits_seq_show, sb);
}
return 0;
+put_stat_kobj:
+ kobject_put(>s_stat_kobj);
+ wait_for_completion(>s_stat_kobj_unregister);
+put_sb_kobj:
+ kobject_put(>s_kobj);
+ wait_for_completion(>s_kobj_unregister);
+ return err;
}
void f2fs_unregister_sysfs(struct f2fs_sb_info *sbi)
@@ -976,6 +1030,11 @@ void f2fs_unregister_sysfs(struct f2fs_sb_info *sbi)
remove_proc_entry("victim_bits", sbi->s_proc);
remove_proc_entry(sbi->sb->s_id, f2fs_proc_root);
}
+
+ kobject_del(>s_stat_kobj);
+ kobject_put(>s_stat_kobj);
+ wait_for_completion(>s_stat_kobj_unregister);
+
kobject_del(>s_kobj);
kobject_put(>s_kobj);
wait_for_completion(>s_kobj_unregister);
--
2.29.2
[PATCH RESEND v2 1/5] f2fs: compress: add compress_inode to cache compressed blocks
Support to use address space of inner inode to cache compressed block,
in order to improve cache hit ratio of random read.
Signed-off-by: Chao Yu
---
Documentation/filesystems/f2fs.rst | 3 +
fs/f2fs/compress.c | 198 +++--
fs/f2fs/data.c | 29 -
fs/f2fs/debug.c| 13 ++
fs/f2fs/f2fs.h | 34 -
fs/f2fs/gc.c | 1 +
fs/f2fs/inode.c| 21 ++-
fs/f2fs/segment.c | 6 +-
fs/f2fs/super.c| 19 ++-
include/linux/f2fs_fs.h| 1 +
10 files changed, 305 insertions(+), 20 deletions(-)
diff --git a/Documentation/filesystems/f2fs.rst
b/Documentation/filesystems/f2fs.rst
index dae15c96e659..5fa45fd8e4af 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -268,6 +268,9 @@ compress_mode=%s Control file compression mode. This
supports "fs" and "user"
choosing the target file and the timing. The user can
do manual
compression/decompression on the compression enabled
files using
ioctls.
+compress_cache Support to use address space of a filesystem managed
inode to
+cache compressed block, in order to improve cache hit
ratio of
+random read.
inlinecrypt When possible, encrypt/decrypt the contents of
encrypted
files using the blk-crypto framework rather than
filesystem-layer encryption. This allows the use of
diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 4bcbacfe3325..446dd41a7bad 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -12,9 +12,11 @@
#include
#include
#include
+#include
#include "f2fs.h"
#include "node.h"
+#include "segment.h"
#include
static struct kmem_cache *cic_entry_slab;
@@ -721,25 +723,14 @@ static int f2fs_compress_pages(struct compress_ctx *cc)
return ret;
}
-void f2fs_decompress_pages(struct bio *bio, struct page *page, bool verity)
+void f2fs_do_decompress_pages(struct decompress_io_ctx *dic, bool verity)
{
- struct decompress_io_ctx *dic =
- (struct decompress_io_ctx *)page_private(page);
- struct f2fs_sb_info *sbi = F2FS_I_SB(dic->inode);
struct f2fs_inode_info *fi= F2FS_I(dic->inode);
const struct f2fs_compress_ops *cops =
f2fs_cops[fi->i_compress_algorithm];
int ret;
int i;
- dec_page_count(sbi, F2FS_RD_DATA);
-
- if (bio->bi_status || PageError(page))
- dic->failed = true;
-
- if (atomic_dec_return(>pending_pages))
- return;
-
trace_f2fs_decompress_pages_start(dic->inode, dic->cluster_idx,
dic->cluster_size, fi->i_compress_algorithm);
@@ -797,6 +788,7 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
ret = cops->decompress_pages(dic);
if (!ret && (fi->i_compress_flag & 1 << COMPRESS_CHKSUM)) {
+ struct f2fs_sb_info *sbi = F2FS_I_SB(dic->inode);
u32 provided = le32_to_cpu(dic->cbuf->chksum);
u32 calculated = f2fs_crc32(sbi, dic->cbuf->cdata, dic->clen);
@@ -830,6 +822,30 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
f2fs_free_dic(dic);
}
+void f2fs_cache_compressed_page(struct f2fs_sb_info *sbi, struct page *page,
+ nid_t ino, block_t blkaddr);
+void f2fs_decompress_pages(struct bio *bio, struct page *page,
+ bool verity, unsigned int ofs)
+{
+ struct decompress_io_ctx *dic =
+ (struct decompress_io_ctx *)page_private(page);
+ struct f2fs_sb_info *sbi = F2FS_I_SB(dic->inode);
+ block_t blkaddr;
+
+ dec_page_count(sbi, F2FS_RD_DATA);
+
+ if (bio->bi_status || PageError(page))
+ dic->failed = true;
+
+ blkaddr = SECTOR_TO_BLOCK(bio->bi_iter.bi_sector) + ofs;
+ f2fs_cache_compressed_page(sbi, page, dic->inode->i_ino, blkaddr);
+
+ if (atomic_dec_return(>pending_pages))
+ return;
+
+ f2fs_do_decompress_pages(dic, verity);
+}
+
static bool is_page_in_cluster(struct compress_ctx *cc, pgoff_t index)
{
if (cc->cluster_idx == NULL_CLUSTER)
@@ -1600,6 +1616,164 @@ void f2fs_decompress_end_io(struct page **rpages,
}
}
+const struct address_space_operations f2fs_compress_aops = {
+ .releasepage = f2fs_release_page,
+ .invalidatepage = f2fs_invalidate_page,
+};
+
+struct address_space *COMPRESS_MAPPING(struct f2fs_sb_info *sbi)
+{
+ return sbi->compress_inode->i_mapping;
+}
+
+void f2fs_invalidate_compress_page(struct f2fs_sb_info *sbi, block_t blkaddr)
+{
+
[PATCH RESEND v2 3/5] f2fs: compress: deny setting unsupported compress algorithm
If kernel doesn't support certain kinds of compress algorithm, deny to set
them as compress algorithm of f2fs via 'compress_algorithm=%s' mount option.
Signed-off-by: Chao Yu
---
fs/f2fs/super.c | 16
1 file changed, 16 insertions(+)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 7c5c880a97be..fe077ef88768 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -936,9 +936,14 @@ static int parse_options(struct super_block *sb, char
*options, bool is_remount)
if (!name)
return -ENOMEM;
if (!strcmp(name, "lzo")) {
+#ifdef CONFIG_F2FS_FS_LZO
F2FS_OPTION(sbi).compress_algorithm =
COMPRESS_LZO;
+#else
+ f2fs_info(sbi, "kernel doesn't support lzo
compression");
+#endif
} else if (!strncmp(name, "lz4", 3)) {
+#ifdef CONFIG_F2FS_FS_LZ4
ret = f2fs_compress_set_level(sbi, name,
COMPRESS_LZ4);
if (ret) {
@@ -947,7 +952,11 @@ static int parse_options(struct super_block *sb, char
*options, bool is_remount)
}
F2FS_OPTION(sbi).compress_algorithm =
COMPRESS_LZ4;
+#else
+ f2fs_info(sbi, "kernel doesn't support lz4
compression");
+#endif
} else if (!strncmp(name, "zstd", 4)) {
+#ifdef CONFIG_F2FS_FS_ZSTD
ret = f2fs_compress_set_level(sbi, name,
COMPRESS_ZSTD);
if (ret) {
@@ -956,9 +965,16 @@ static int parse_options(struct super_block *sb, char
*options, bool is_remount)
}
F2FS_OPTION(sbi).compress_algorithm =
COMPRESS_ZSTD;
+#else
+ f2fs_info(sbi, "kernel doesn't support zstd
compression");
+#endif
} else if (!strcmp(name, "lzo-rle")) {
+#ifdef CONFIG_F2FS_FS_LZORLE
F2FS_OPTION(sbi).compress_algorithm =
COMPRESS_LZORLE;
+#else
+ f2fs_info(sbi, "kernel doesn't support lzorle
compression");
+#endif
} else {
kfree(name);
return -EINVAL;
--
2.29.2
[PATCH RESEND v2 5/5] f2fs: introduce sb_status sysfs node
Introduce /sys/fs/f2fs//stat/sb_status to show superblock
status in real time as below:
IS_DIRTY: no
IS_CLOSE: no
IS_SHUTDOWN:no
IS_RECOVERED: no
IS_RESIZEFS:no
NEED_FSCK: no
POR_DOING: no
NEED_SB_WRITE: no
NEED_CP:no
CP_DISABLED:no
CP_DISABLED_QUICK: no
QUOTA_NEED_FLUSH: no
QUOTA_SKIP_FLUSH: no
QUOTA_NEED_REPAIR: no
Signed-off-by: Chao Yu
---
Documentation/ABI/testing/sysfs-fs-f2fs | 5
fs/f2fs/sysfs.c | 36 +
2 files changed, 41 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 3dfee94e0618..57ab839dc3a2 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -377,3 +377,8 @@ Description:This gives a control to limit the bio
size in f2fs.
Default is zero, which will follow underlying block layer limit,
whereas, if it has a certain bytes value, f2fs won't submit a
bio larger than that size.
+
+What: /sys/fs/f2fs//stat/sb_status
+Date: December 2020
+Contact: "Chao Yu"
+Description: Show status of f2fs superblock in real time.
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index ebca0b4961e8..1b85e6d16a94 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -101,6 +101,40 @@ static ssize_t lifetime_write_kbytes_show(struct f2fs_attr
*a,
sbi->sectors_written_start) >> 1)));
}
+#defineSB_STATUS(s)(s ? "yes" : "no")
+static ssize_t sb_status_show(struct f2fs_attr *a,
+ struct f2fs_sb_info *sbi, char *buf)
+{
+ return sprintf(buf, "IS_DIRTY: %s\n"
+ "IS_CLOSE: %s\n"
+ "IS_SHUTDOWN: %s\n"
+ "IS_RECOVERED: %s\n"
+ "IS_RESIZEFS: %s\n"
+ "NEED_FSCK: %s\n"
+ "POR_DOING: %s\n"
+ "NEED_SB_WRITE: %s\n"
+ "NEED_CP: %s\n"
+ "CP_DISABLED: %s\n"
+ "CP_DISABLED_QUICK: %s\n"
+ "QUOTA_NEED_FLUSH: %s\n"
+ "QUOTA_SKIP_FLUSH: %s\n"
+ "QUOTA_NEED_REPAIR: %s\n",
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_IS_DIRTY)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_IS_CLOSE)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_IS_SHUTDOWN)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_IS_RECOVERED)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_IS_RESIZEFS)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_NEED_FSCK)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_POR_DOING)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_NEED_SB_WRITE)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_NEED_CP)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_CP_DISABLED)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_CP_DISABLED_QUICK)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_QUOTA_NEED_FLUSH)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)),
+ SB_STATUS(is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)));
+}
+
static ssize_t features_show(struct f2fs_attr *a,
struct f2fs_sb_info *sbi, char *buf)
{
@@ -711,7 +745,9 @@ static struct attribute *f2fs_feat_attrs[] = {
};
ATTRIBUTE_GROUPS(f2fs_feat);
+F2FS_GENERAL_RO_ATTR(sb_status);
static struct attribute *f2fs_stat_attrs[] = {
+ ATTR_LIST(sb_status),
NULL,
};
ATTRIBUTE_GROUPS(f2fs_stat);
--
2.29.2
Re: [PATCH v3 09/15] remoteproc: Introduce function rproc_detach()
On 12/9/20 1:53 AM, Mathieu Poirier wrote:
> On Tue, Dec 08, 2020 at 07:35:18PM +0100, Arnaud POULIQUEN wrote:
>> Hi Mathieu,
>>
>>
>> On 11/26/20 10:06 PM, Mathieu Poirier wrote:
>>> Introduce function rproc_detach() to enable the remoteproc
>>> core to release the resources associated with a remote processor
>>> without stopping its operation.
>>>
>>> Signed-off-by: Mathieu Poirier
>>> Reviewed-by: Peng Fan
>>> ---
>>> drivers/remoteproc/remoteproc_core.c | 65 +++-
>>> include/linux/remoteproc.h | 1 +
>>> 2 files changed, 65 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/remoteproc/remoteproc_core.c
>>> b/drivers/remoteproc/remoteproc_core.c
>>> index 928b3f975798..f5adf05762e9 100644
>>> --- a/drivers/remoteproc/remoteproc_core.c
>>> +++ b/drivers/remoteproc/remoteproc_core.c
>>> @@ -1667,7 +1667,7 @@ static int rproc_stop(struct rproc *rproc, bool
>>> crashed)
>>> /*
>>> * __rproc_detach(): Does the opposite of rproc_attach()
>>> */
>>> -static int __maybe_unused __rproc_detach(struct rproc *rproc)
>>> +static int __rproc_detach(struct rproc *rproc)
>>> {
>>> struct device *dev = >dev;
>>> int ret;
>>> @@ -1910,6 +1910,69 @@ void rproc_shutdown(struct rproc *rproc)
>>> }
>>> EXPORT_SYMBOL(rproc_shutdown);
>>>
>>> +/**
>>> + * rproc_detach() - Detach the remote processor from the
>>> + * remoteproc core
>>> + *
>>> + * @rproc: the remote processor
>>> + *
>>> + * Detach a remote processor (previously attached to with rproc_actuate()).
>>> + *
>>> + * In case @rproc is still being used by an additional user(s), then
>>> + * this function will just decrement the power refcount and exit,
>>> + * without disconnecting the device.
>>> + *
>>> + * Function rproc_detach() calls __rproc_detach() in order to let a remote
>>> + * processor know that services provided by the application processor are
>>> + * no longer available. From there it should be possible to remove the
>>> + * platform driver and even power cycle the application processor (if the
>>> HW
>>> + * supports it) without needing to switch off the remote processor.
>>> + */
>>> +int rproc_detach(struct rproc *rproc)
>>> +{
>>> + struct device *dev = >dev;
>>> + int ret;
>>> +
>>> + ret = mutex_lock_interruptible(>lock);
>>> + if (ret) {
>>> + dev_err(dev, "can't lock rproc %s: %d\n", rproc->name, ret);
>>> + return ret;
>>> + }
>>> +
>>> + if (rproc->state != RPROC_RUNNING && rproc->state != RPROC_ATTACHED) {
>>> + ret = -EPERM;
>>> + goto out;
>>> + }
>>> +
>>> + /* if the remote proc is still needed, bail out */
>>> + if (!atomic_dec_and_test(>power)) {
>>> + ret = -EBUSY;
>>> + goto out;
>>> + }
>>> +
>>> + ret = __rproc_detach(rproc);
>>> + if (ret) {
>>> + atomic_inc(>power);
>>> + goto out;
>>> + }
>>> +
>>> + /* clean up all acquired resources */
>>> + rproc_resource_cleanup(rproc);
>>
>> I started to test the series, I found 2 problems testing in STM32P1 board.
>>
>> 1) the resource_table pointer is unmapped if the firmware has been booted by
>> the
>> Linux, generating a crash in rproc_free_vring.
>> I attached a fix at the end of the mail.
>>
>
> I have reproduced the condition on my side and confirm that your solution is
> correct. See below for a minor comment.
>
>> 2) After the detach, the rproc state is "detached"
>> but it is no longer possible to re-attach to it correctly.
>> Neither if the firmware is standalone, nor if it has been booted
>> by the Linux.
>>
>
> Did you update your FW image? If so, I need to run the same one.
>
>> I did not investigate, but the issue is probably linked to the resource
>> table address which is set to NULL.
>>
>> So we either have to fix the problem in order to attach or forbid the
>> transition.
>>
>>
>> Regards,
>> Arnaud
>>
>>> +
>>> + rproc_disable_iommu(rproc);
>>> +
>>> + /*
>>> +* Set the remote processor's table pointer to NULL. Since mapping
>>> +* of the resource table to a virtual address is done in the platform
>>> +* driver, unmapping should also be done there.
>>> +*/
>>> + rproc->table_ptr = NULL;
>>> +out:
>>> + mutex_unlock(>lock);
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL(rproc_detach);
>>> +
>>> /**
>>> * rproc_get_by_phandle() - find a remote processor by phandle
>>> * @phandle: phandle to the rproc
>>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>>> index da15b77583d3..329c1c071dcf 100644
>>> --- a/include/linux/remoteproc.h
>>> +++ b/include/linux/remoteproc.h
>>> @@ -656,6 +656,7 @@ rproc_of_resm_mem_entry_init(struct device *dev, u32
>>> of_resm_idx, size_t len,
>>>
>>> int rproc_boot(struct rproc *rproc);
>>> void rproc_shutdown(struct rproc *rproc);
>>> +int rproc_detach(struct rproc *rproc);
>>> int rproc_set_firmware(struct rproc *rproc, const char *fw_name);
>>> void rproc_report_crash(struct rproc *rproc, enum
Re: [Ksummit-discuss] crediting bug reports and fixes folded into original patch
On 12/9/20 8:58 AM, Dan Carpenter wrote: > On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote: >> On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote: >> >> > If not "Adjusted-by", what about "Tweaked-by", "Helped-by", >> > "Corrected-by"? >> >> Improved-by: / Enhanced-by: / Revisions-by: >> > > I don't think we should give any credit for improvements or enhancements, Well, some are actually useful and not about reviewer's preferred style :) But if an author redoes the patch as a result, it's their choice to mention useful improvements in the next version's change log. > only for fixes. Complaining about style is its own reward. Right, let's focus on fixes and reports of bugs, that would have resulted in a standalone commit, but don't. > Having to redo a patch is already a huge headache. Normally, I already > considered the reviewer's prefered style and decided I didn't like it. > Then to make me redo the patch in an ugly style and say thankyou on > top of that??? Forget about it. Plus, as a reviewer I hate reviewing > patches over and over. > > I've argued for years that we should have a Fixes-from: tag. The zero Standardizing the Fixes-from: tag (or any better name) would be a forward progress, yes. > day bot is already encouraging people to add Reported-by tags for this > and a lot of people do. "Reported-by:" becomes ambiguous once the bugfix for the reported issue in the patch is folded, as it's no longer clear whether the bot reported the original issue the patch is fixing, or a bug in the fix. So we should have a different variant. "Fixes-reported-by:" so it has the same prefix? > regards, > dan carpenter >
Re: [PATCH v3 14/15] remoteproc: Properly deal with detach request
On 11/26/20 10:06 PM, Mathieu Poirier wrote:
> This patch introduces the capability to detach a remote processor
> that has been attached to or booted by the remoteproc core. For
> that to happen a rproc::ops::detach() operation need to be
> available.
>
> Signed-off-by: Mathieu Poirier
> Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
> drivers/remoteproc/remoteproc_cdev.c | 6 ++
> drivers/remoteproc/remoteproc_sysfs.c | 6 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_cdev.c
> b/drivers/remoteproc/remoteproc_cdev.c
> index 61541bc7d26c..f7645f289563 100644
> --- a/drivers/remoteproc/remoteproc_cdev.c
> +++ b/drivers/remoteproc/remoteproc_cdev.c
> @@ -43,6 +43,12 @@ static ssize_t rproc_cdev_write(struct file *filp, const
> char __user *buf, size_
> return -EINVAL;
>
> ret = rproc_shutdown(rproc);
> + } else if (!strncmp(cmd, "detach", len)) {
> + if (rproc->state != RPROC_RUNNING &&
> + rproc->state != RPROC_ATTACHED)
> + return -EINVAL;
> +
> + ret = rproc_detach(rproc);
> } else {
> dev_err(>dev, "Unrecognized option\n");
> ret = -EINVAL;
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c
> b/drivers/remoteproc/remoteproc_sysfs.c
> index 7d281cfe3e03..5a239df5877e 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -207,6 +207,12 @@ static ssize_t state_store(struct device *dev,
> return -EINVAL;
>
> ret = rproc_shutdown(rproc);
> + } else if (sysfs_streq(buf, "detach")) {
> + if (rproc->state != RPROC_RUNNING &&
> + rproc->state != RPROC_ATTACHED)
> + return -EINVAL;
> +
> + ret = rproc_detach(rproc);
> } else {
> dev_err(>dev, "Unrecognised option: %s\n", buf);
> ret = -EINVAL;
>
Re: [BUG] SPI broken for SPI based panel drivers
Hi Linus, > Am 09.12.2020 um 09:38 schrieb Linus Walleij : > > On Sat, Dec 5, 2020 at 8:07 AM H. Nikolaus Schaller > wrote: > >> I find it interesting that so far nobody wants to take responsibility >> for a decision > (...) > > >>> What I can do is to provide just a skeleton for the table that you or Linus >>> can fix/fill in and make a patch out of it. Is attached and the ??? is >>> something you should discuss and define. >> >> Please take the attached diff, comment it here and define the question marks >> according to your intention and then make a patch for the YAML bindings out >> of it. (I can't do because I don't know your intentions and what to write >> into >> the commit message). > > I'll comment what I know, then you can send a proper patch to > Mark. But you really need more people than me to look at this. > >> + device node | cs-gpio | CS pin state active | Note >> + +===+=+= >> + spi-cs-high | - | H | >> + - | - | L | >> + spi-cs-high | ACTIVE_HIGH | H | >> + - | ACTIVE_HIGH | L (or H ???)| 1 > > When using GPIO descriptors it will be enforced to ACTIVE_LOW (L) with an > explicit warning in dmesg, see drivers/gpio/gpiolib-of.c Ok, so in this line the L is ok. > > When using legacy GPIOs, will be enforced ACTIVE_LOW by the SPI > core. > >> + spi-cs-high | ACTIVE_LOW| H (or L ???)| 2 > > When using GPIO descriptors it will be enforced to ACTIVE_HIGH (H) with an > explicit warning in dmesg, see drivers/gpio/gpiolib-of.c Ok, so my assumption about H is right and not the part in parenthesis with ???. > >> + 3) Effectively this rule defines that the ACTIVE level of the >> + gpio has to be ignored > > Nr 3 isn't tagged in the table. Well, it was thought as a third but general note. Maybe should have been a *) or omitted since the table stands for itself. > > Yours, > Linus Walleij So let me prepare a patch with fixes for this. BR and thanks, Nikolaus
[PATCH] f2fs: fix shift-out-of-bounds in sanity_check_raw_super()
syzbot reported a bug which could cause shift-out-of-bounds issue,
fix it.
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x107/0x163 lib/dump_stack.c:120
ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
__ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395
sanity_check_raw_super fs/f2fs/super.c:2812 [inline]
read_raw_super_block fs/f2fs/super.c:3267 [inline]
f2fs_fill_super.cold+0x16c9/0x16f6 fs/f2fs/super.c:3519
mount_bdev+0x34d/0x410 fs/super.c:1366
legacy_get_tree+0x105/0x220 fs/fs_context.c:592
vfs_get_tree+0x89/0x2f0 fs/super.c:1496
do_new_mount fs/namespace.c:2896 [inline]
path_mount+0x12ae/0x1e70 fs/namespace.c:3227
do_mount fs/namespace.c:3240 [inline]
__do_sys_mount fs/namespace.c:3448 [inline]
__se_sys_mount fs/namespace.c:3425 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3425
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Reported-by: syzbot+ca9a785f8ac472085...@syzkaller.appspotmail.com
Signed-off-by: Chao Yu
---
fs/f2fs/super.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index bf96f5776f99..c0b2ea596b07 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -2869,7 +2869,6 @@ static int sanity_check_raw_super(struct f2fs_sb_info
*sbi,
block_t total_sections, blocks_per_seg;
struct f2fs_super_block *raw_super = (struct f2fs_super_block *)
(bh->b_data + F2FS_SUPER_OFFSET);
- unsigned int blocksize;
size_t crc_offset = 0;
__u32 crc = 0;
@@ -2896,10 +2895,10 @@ static int sanity_check_raw_super(struct f2fs_sb_info
*sbi,
}
/* Currently, support only 4KB block size */
- blocksize = 1 << le32_to_cpu(raw_super->log_blocksize);
- if (blocksize != F2FS_BLKSIZE) {
- f2fs_info(sbi, "Invalid blocksize (%u), supports only 4KB",
- blocksize);
+ if (le32_to_cpu(raw_super->log_blocksize) != F2FS_BLKSIZE_BITS) {
+ f2fs_info(sbi, "Invalid log_blocksize (%u), supports only %u",
+ le32_to_cpu(raw_super->log_blocksize),
+ F2FS_BLKSIZE_BITS);
return -EFSCORRUPTED;
}
--
2.29.2
Re: [patch] close_range.2: new page documenting close_range(2)
Hello Stephen Thank you for writing this page! Some comments/questions below. On Tue, 8 Dec 2020 at 22:51, Stephen Kitt wrote: > > This documents close_range(2) based on information in > 278a5fbaed89dacd04e9d052f4594ffd0e0585de and > 60997c3d45d9a67daf01c56d805ae4fec37e0bd8. (Thanks for noting these commit IDs.) > Signed-off-by: Stephen Kitt > --- > man2/close_range.2 | 112 + > 1 file changed, 112 insertions(+) > create mode 100644 man2/close_range.2 > > diff --git a/man2/close_range.2 b/man2/close_range.2 > new file mode 100644 > index 0..62167d9b0 > --- /dev/null > +++ b/man2/close_range.2 > @@ -0,0 +1,112 @@ > +.\" Copyright (c) 2020 Stephen Kitt > +.\" > +.\" %%%LICENSE_START(VERBATIM) > +.\" Permission is granted to make and distribute verbatim copies of this > +.\" manual provided the copyright notice and this permission notice are > +.\" preserved on all copies. > +.\" > +.\" Permission is granted to copy and distribute modified versions of this > +.\" manual under the conditions for verbatim copying, provided that the > +.\" entire resulting derived work is distributed under the terms of a > +.\" permission notice identical to this one. > +.\" > +.\" Since the Linux kernel and libraries are constantly changing, this > +.\" manual page may be incorrect or out-of-date. The author(s) assume no > +.\" responsibility for errors or omissions, or for damages resulting from > +.\" the use of the information contained herein. The author(s) may not > +.\" have taken the same level of care in the production of this manual, > +.\" which is licensed free of charge, as they might when working > +.\" professionally. > +.\" > +.\" Formatted or processed versions of this manual, if unaccompanied by > +.\" the source, must acknowledge the copyright and authors of this work. > +.\" %%%LICENSE_END > +.\" > +.TH CLOSE_RANGE 2 2020-12-08 "Linux" "Linux Programmer's Manual" > +.SH NAME > +close_range \- close all file descriptors in a given range > +.SH SYNOPSIS > +.nf > +.B #include > +.PP > +.BI "int close_range(int " first ", int " last ", unsigned int " flags ); > +.fi > +.SH DESCRIPTION > +The > +.BR close_range () > +system call closes all open file descriptors from > +.I first > +to > +.IR last > +(included). > +.PP > +Errors closing a given file descriptor are currently ignored. > +.PP > +.I flags > +can be set to > +.B CLOSE_RANGE_UNSHARE > +to unshare the range of file descriptors from any other processes, > +.I instead > +of closing them. Really "instead of closing them"? I had supposed that rather that this should be "before closing them". That's also how the kernel code reads to me, from a quick glance. > +.SH RETURN VALUE > +On success, > +.BR close_range () > +return 0. s/return/returns/ > +On error, \-1 is returned and > +.I errno > +is set to indicate the cause of the error. > +.SH ERRORS > +.TP > +.B EINVAL > +.I flags > +is not valid, or > +.I first > +is greater than > +.IR last . > +.TP > +.B EMFILE > +The per-process limit on the number of open file descriptors has been reached > +(see the description of > +.BR RLIMIT_NOFILE > +in > +.BR getrlimit (2)). Given that we are simply closing FDs, how can EMFILE occur? > +.TP > +.B ENOMEM > +Insufficient kernel memory was available. > +.SH VERSIONS > +.BR close_range () > +first appeared in Linux 5.9. > +.SH CONFORMING TO > +.BR close_range () > +is available on Linux and FreeBSD. Here, I think it would be better to write: close_range() is a nonstandard function that is also present on FreeBSD. > +.SH NOTES > +Currently, there is no glibc wrapper for this system call; call it using > +.BR syscall (2). > +.SH USE CASES > +.\" 278a5fbaed89dacd04e9d052f4594ffd0e0585de > +.\" 60997c3d45d9a67daf01c56d805ae4fec37e0bd8 > +.SS Closing file descriptors before exec > +File descriptors can be closed safely using > +.PP > +.in +4n > +.EX > +/* we don't want anything past stderr here */ > +close_range(3, ~0U, CLOSE_RANGE_UNSHARE); > +execve(); > +.EE > +.in > +.PP .PP is not necessary before a new subsection (.SS). > +.SS Closing all open file descriptors > +This is commonly implemented (on Linux) by listing open file Is it really true that this is common? I suspect not. It's slow, and relies on /proc being present. I would have thought that more common is something like: int maxfd = sysconf(_SC_OPEN_MAX); if (maxfd == -1)/* Limit is indeterminate... */ maxfd = 16384; /* so take a guess */ for (fd = 0; fd < maxfd; fd++) close(fd); I think it's fine to mention the use of a /proc as an (inferior and) alternative way of doing this. I'm just not sure that "commonly" is correct. > +descriptors in > +.B /proc/self/fd/ > +and calling > +.BR close (2) > +on each one. > +.BR close_range () > +can take care of this without requiring > +.B /proc > +and with a single system call, which provides significant performance >
Re: [External] Re: [PATCH v7 05/15] mm/bootmem_info: Introduce {free,prepare}_vmemmap_page()
On 09.12.20 08:36, Muchun Song wrote:
> On Mon, Dec 7, 2020 at 8:39 PM David Hildenbrand wrote:
>>
>> On 30.11.20 16:18, Muchun Song wrote:
>>> In the later patch, we can use the free_vmemmap_page() to free the
>>> unused vmemmap pages and initialize a page for vmemmap page using
>>> via prepare_vmemmap_page().
>>>
>>> Signed-off-by: Muchun Song
>>> ---
>>> include/linux/bootmem_info.h | 24
>>> 1 file changed, 24 insertions(+)
>>>
>>> diff --git a/include/linux/bootmem_info.h b/include/linux/bootmem_info.h
>>> index 4ed6dee1adc9..239e3cc8f86c 100644
>>> --- a/include/linux/bootmem_info.h
>>> +++ b/include/linux/bootmem_info.h
>>> @@ -3,6 +3,7 @@
>>> #define __LINUX_BOOTMEM_INFO_H
>>>
>>> #include
>>> +#include
>>>
>>> /*
>>> * Types for free bootmem stored in page->lru.next. These have to be in
>>> @@ -22,6 +23,29 @@ void __init register_page_bootmem_info_node(struct
>>> pglist_data *pgdat);
>>> void get_page_bootmem(unsigned long info, struct page *page,
>>> unsigned long type);
>>> void put_page_bootmem(struct page *page);
>>> +
>>> +static inline void free_vmemmap_page(struct page *page)
>>> +{
>>> + VM_WARN_ON(!PageReserved(page) || page_ref_count(page) != 2);
>>> +
>>> + /* bootmem page has reserved flag in the reserve_bootmem_region */
>>> + if (PageReserved(page)) {
>>> + unsigned long magic = (unsigned long)page->freelist;
>>> +
>>> + if (magic == SECTION_INFO || magic == MIX_SECTION_INFO)
>>> + put_page_bootmem(page);
>>> + else
>>> + WARN_ON(1);
>>> + }
>>> +}
>>> +
>>> +static inline void prepare_vmemmap_page(struct page *page)
>>> +{
>>> + unsigned long section_nr = pfn_to_section_nr(page_to_pfn(page));
>>> +
>>> + get_page_bootmem(section_nr, page, SECTION_INFO);
>>> + mark_page_reserved(page);
>>> +}
>>
>> Can you clarify in the description when exactly these functions are
>> called and on which type of pages?
>>
>> Would indicating "bootmem" in the function names make it clearer what we
>> are dealing with?
>>
>> E.g., any memory allocated via the memblock allocator and not via the
>> buddy will be makred reserved already in the memmap. It's unclear to me
>> why we need the mark_page_reserved() here - can you enlighten me? :)
>
> Sorry for ignoring this question. Because the vmemmap pages are allocated
> from the bootmem allocator which is marked as PG_reserved. For those bootmem
> pages, we should call put_page_bootmem for free. You can see that we
> clear the PG_reserved in the put_page_bootmem. In order to be consistent,
> the prepare_vmemmap_page also marks the page as PG_reserved.
I don't think that really makes sense.
After put_page_bootmem() put the last reference, it clears PG_reserved
and hands the page over to the buddy via free_reserved_page(). From that
point on, further get_page_bootmem() would be completely wrong and
dangerous.
Both, put_page_bootmem() and get_page_bootmem() rely on the fact that
they are dealing with memblock allcoations - marked via PG_reserved. If
prepare_vmemmap_page() would be called on something that's *not* coming
from the memblock allocator, it would be completely broken - or am I
missing something?
AFAIKT, there should rather be a BUG_ON(!PageReserved(page)) in
prepare_vmemmap_page() - or proper handling to deal with !memblock
allocations.
And as I said, indicating "bootmem" as part of the function names might
make it clearer that this is not for getting any vmemmap pages (esp.
allocated when hotplugging memory).
--
Thanks,
David / dhildenb
Re: Howto listen to/handle gpio state changes ? Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult wrote: > I've been looking for some more direct notification callback for gpio > consumers: here the consumer would register itself as a listener on > some gpio_desc and called back when something changes (with data what > exactly changed, eg. "gpio #3 input switched to high"). > > Seems we currently just have the indirect path via interrupts. I don't know how indirect it is, it seems pretty direct to me. The subsystem was designed in response to how the hardware in front of the developers worked. So far we have had: - Cascaded interrupts - Dedicated (hieararchical) interrupts - Message Signalled Interrupts And if you now bring something else to the show then it's not like the subsystem was designed for some abstract quality such as generic notification of events that occurred, all practical instances have been around actual IRQs and that is why it is using struct irq_chip. What we need to understand is if your new usecase is an outlier so it is simplest modeled by a "mock" irq_chip or we have to design something new altogether like notifications on changes. I suspect irq_chip would be best because all drivers using GPIOs for interrupts are expecting interrupts, and it would be an enormous task to change them all and really annoying to create a new mechanism on the side. Yours, Linus Walleij
Re: [RFC PATCH] RFC: drivers: gpio: helper for generic pin IRQ handling
On 08.12.20 15:19, Andy Shevchenko wrote: Hi, > Have you able to test them all? Not yet. It's still an *RFC*, I just like to discuss whether the whole idea makes sense at all. In case we come to the consensus that we should do it, I'm going to split up the patch and rework everything more carefully (for now, it's just a draft for illustrating the general idea) I'd also like to hear your opinion on whether we can consolidate these things even more, eg. using struct gpio_chip's irq data (enabled by CONFIG_GPIOLIB_IRQCHIP) instead of own fields. An interesting question here is how to do that w/o gpiolib assuming they've been managed by it - for example gpiochip_remove (which cleans up the IRQ stuff) is called by gpiochip_remove(), so we have to make sure that the driver clears the corresponding fields before gpiochip_remove() is called. So far so good. BUT: gpiochip_remove() is also called in error paths, when registration fails in the middle, and there the driver cannot act properly. Maybe introduce a flag for telling gpiolib that it should leave these fields alone and let the driver do everything ? > As the PCA953x case showed us this is not so simple, Can you tell me more about it ? (BTW haven't touched it in my patch) > besides the name > which sucks — we don't *raise* and IRQ we *handle* it. right, the naming was bad, forgot to correct that before sending. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [External] Re: [PATCH v7 04/15] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate
On 07.12.20 14:11, Muchun Song wrote:
> On Mon, Dec 7, 2020 at 8:36 PM David Hildenbrand wrote:
>>
>> On 30.11.20 16:18, Muchun Song wrote:
>>> Every HugeTLB has more than one struct page structure. The 2M HugeTLB
>>> has 512 struct page structure and 1G HugeTLB has 4096 struct page
>>> structures. We __know__ that we only use the first
>>> 4(HUGETLB_CGROUP_MIN_ORDER)
>>> struct page structures to store metadata associated with each HugeTLB.
>>>
>>> There are a lot of struct page structures(8 page frames for 2MB HugeTLB
>>> page and 4096 page frames for 1GB HugeTLB page) associated with each
>>> HugeTLB page. For tail pages, the value of compound_head is the same.
>>> So we can reuse first page of tail page structures. We map the virtual
>>> addresses of the remaining pages of tail page structures to the first
>>> tail page struct, and then free these page frames. Therefore, we need
>>> to reserve two pages as vmemmap areas.
>>>
>>> So we introduce a new nr_free_vmemmap_pages field in the hstate to
>>> indicate how many vmemmap pages associated with a HugeTLB page that we
>>> can free to buddy system.
>>>
>>> Signed-off-by: Muchun Song
>>> Acked-by: Mike Kravetz
>>> ---
>>> include/linux/hugetlb.h | 3 ++
>>> mm/Makefile | 1 +
>>> mm/hugetlb.c| 3 ++
>>> mm/hugetlb_vmemmap.c| 129
>>>
>>> mm/hugetlb_vmemmap.h| 20
>>> 5 files changed, 156 insertions(+)
>>> create mode 100644 mm/hugetlb_vmemmap.c
>>> create mode 100644 mm/hugetlb_vmemmap.h
>>>
>>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>>> index ebca2ef02212..4efeccb7192c 100644
>>> --- a/include/linux/hugetlb.h
>>> +++ b/include/linux/hugetlb.h
>>> @@ -492,6 +492,9 @@ struct hstate {
>>> unsigned int nr_huge_pages_node[MAX_NUMNODES];
>>> unsigned int free_huge_pages_node[MAX_NUMNODES];
>>> unsigned int surplus_huge_pages_node[MAX_NUMNODES];
>>> +#ifdef CONFIG_HUGETLB_PAGE_FREE_VMEMMAP
>>> + unsigned int nr_free_vmemmap_pages;
>>> +#endif
>>> #ifdef CONFIG_CGROUP_HUGETLB
>>> /* cgroup control files */
>>> struct cftype cgroup_files_dfl[7];
>>> diff --git a/mm/Makefile b/mm/Makefile
>>> index ed4b88fa0f5e..056801d8daae 100644
>>> --- a/mm/Makefile
>>> +++ b/mm/Makefile
>>> @@ -71,6 +71,7 @@ obj-$(CONFIG_FRONTSWAP) += frontswap.o
>>> obj-$(CONFIG_ZSWAP) += zswap.o
>>> obj-$(CONFIG_HAS_DMA)+= dmapool.o
>>> obj-$(CONFIG_HUGETLBFS) += hugetlb.o
>>> +obj-$(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP) += hugetlb_vmemmap.o
>>> obj-$(CONFIG_NUMA) += mempolicy.o
>>> obj-$(CONFIG_SPARSEMEM) += sparse.o
>>> obj-$(CONFIG_SPARSEMEM_VMEMMAP) += sparse-vmemmap.o
>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>> index 1f3bf1710b66..25f9e8e9fc4a 100644
>>> --- a/mm/hugetlb.c
>>> +++ b/mm/hugetlb.c
>>> @@ -42,6 +42,7 @@
>>> #include
>>> #include
>>> #include "internal.h"
>>> +#include "hugetlb_vmemmap.h"
>>>
>>> int hugetlb_max_hstate __read_mostly;
>>> unsigned int default_hstate_idx;
>>> @@ -3206,6 +3207,8 @@ void __init hugetlb_add_hstate(unsigned int order)
>>> snprintf(h->name, HSTATE_NAME_LEN, "hugepages-%lukB",
>>> huge_page_size(h)/1024);
>>>
>>> + hugetlb_vmemmap_init(h);
>>> +
>>> parsed_hstate = h;
>>> }
>>>
>>> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
>>> new file mode 100644
>>> index ..51152e258f39
>>> --- /dev/null
>>> +++ b/mm/hugetlb_vmemmap.c
>>> @@ -0,0 +1,129 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Free some vmemmap pages of HugeTLB
>>> + *
>>> + * Copyright (c) 2020, Bytedance. All rights reserved.
>>> + *
>>> + * Author: Muchun Song
>>> + *
>>> + * The struct page structures (page structs) are used to describe a
>>> physical
>>> + * page frame. By default, there is a one-to-one mapping from a page frame
>>> to
>>> + * it's corresponding page struct.
>>> + *
>>> + * The HugeTLB pages consist of multiple base page size pages and is
>>> supported
>>> + * by many architectures. See hugetlbpage.rst in the Documentation
>>> directory
>>> + * for more details. On the x86 architecture, HugeTLB pages of size 2MB
>>> and 1GB
>>> + * are currently supported. Since the base page size on x86 is 4KB, a 2MB
>>> + * HugeTLB page consists of 512 base pages and a 1GB HugeTLB page consists
>>> of
>>> + * 4096 base pages. For each base page, there is a corresponding page
>>> struct.
>>> + *
>>> + * Within the HugeTLB subsystem, only the first 4 page structs are used to
>>> + * contain unique information about a HugeTLB page.
>>> HUGETLB_CGROUP_MIN_ORDER
>>> + * provides this upper limit. The only 'useful' information in the
>>> remaining
>>> + * page structs is the compound_head field, and this field is the same for
>>> all
>>> + * tail pages.
>>> + *
>>> + * By removing redundant page structs for HugeTLB pages, memory can
>>> returned to
>>> + * the buddy
Re: [Ksummit-discuss] crediting bug reports and fixes folded into original patch
On Wed, 2020-12-09 at 10:58 +0300, Dan Carpenter wrote: > On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote: > > On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote: > > > > > If not "Adjusted-by", what about "Tweaked-by", "Helped-by", > > > "Corrected-by"? > > > > Improved-by: / Enhanced-by: / Revisions-by: > > > > I don't think we should give any credit for improvements or enhancements, > only for fixes. Hey Dan. I do. If a patch isn't comprehensive and a reviewer notices some missing coverage or algorithmic performance enhancement, I think that should be noted. > Complaining about style is its own reward. I believe I've said multiple times that style changes shouldn't require additional commentary added to a patch. I'm not making any suggestion to comment for style, only logic or defect reduction/improvements as described above. > Having to redo a patch is already a huge headache. Normally, I already > considered the reviewer's prefered style and decided I didn't like it. Example please. We both seem to prefer consistent style. > Then to make me redo the patch in an ugly style and say thank you on > top of that??? Forget about it. Not a thing I've asked for. > Plus, as a reviewer I hate reviewing patches over and over. interdiff could be improved. > I've argued for years that we should have a Fixes-from: tag. The zero > day bot is already encouraging people to add Reported-by tags for this > and a lot of people do. It's still a question of what fixes means in any context. https://www.google.com/search?q=%27fixes-from%3A%27%20carpenter%20site%3Alore.kernel.org gives: It looks like there aren't many great matches for your search And I'm rather in favor of letting people make up their own -by: uses and not being too concerned about the specific whatever word or phrase used. Postel's law and such.
Re: [RESEND PATCH v3 1/4] iommu/iova: Add free_all_cpu_cached_iovas()
On 2020/11/17 18:25, John Garry wrote:
> Add a helper function to free the CPU rcache for all online CPUs.
>
> There also exists a function of the same name in
> drivers/iommu/intel/iommu.c, but the parameters are different, and there
> should be no conflict.
>
> Signed-off-by: John Garry
> ---
> drivers/iommu/iova.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index 30d969a4c5fd..81b7399dd5e8 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -227,6 +227,14 @@ static int __alloc_and_insert_iova_range(struct
> iova_domain *iovad,
> return -ENOMEM;
> }
>
> +static void free_all_cpu_cached_iovas(struct iova_domain *iovad)
> +{
> + unsigned int cpu;
> +
> + for_each_online_cpu(cpu)
> + free_cpu_cached_iovas(cpu, iovad);
> +}
> +
> static struct kmem_cache *iova_cache;
> static unsigned int iova_cache_users;
> static DEFINE_MUTEX(iova_cache_mutex);
> @@ -422,15 +430,12 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned
> long size,
> retry:
> new_iova = alloc_iova(iovad, size, limit_pfn, true);
> if (!new_iova) {
> - unsigned int cpu;
> -
> if (!flush_rcache)
> return 0;
>
> /* Try replenishing IOVAs by flushing rcache. */
> flush_rcache = false;
> - for_each_online_cpu(cpu)
> - free_cpu_cached_iovas(cpu, iovad);
> + free_all_cpu_cached_iovas(iovad);
> goto retry;
> }
>
Reviewed-by: Zhen Lei
>
