[PATCH 08/10] phy: tegra: Add PCIe PIPE2UPHY support
Synopsys DesignWare core based PCIe controllers in Tegra 194 SoC interface
with Universal PHY (UPHY) module through a PIPE2UPHY (P2U) module.
For each PCIe lane of a controller, there is a P2U unit instantiated at
hardware level. This driver provides support for the programming required
for each P2U that is going to be used for a PCIe controller.
Signed-off-by: Vidya Sagar
---
drivers/phy/tegra/Kconfig | 7 ++
drivers/phy/tegra/Makefile| 1 +
drivers/phy/tegra/pcie-p2u-tegra194.c | 138 ++
3 files changed, 146 insertions(+)
create mode 100644 drivers/phy/tegra/pcie-p2u-tegra194.c
diff --git a/drivers/phy/tegra/Kconfig b/drivers/phy/tegra/Kconfig
index a3b1de953fb7..1460c060fa70 100644
--- a/drivers/phy/tegra/Kconfig
+++ b/drivers/phy/tegra/Kconfig
@@ -6,3 +6,10 @@ config PHY_TEGRA_XUSB
To compile this driver as a module, choose M here: the module will
be called phy-tegra-xusb.
+
+config PHY_TEGRA194_PCIE_P2U
+tristate "NVIDIA Tegra P2U PHY Driver"
+depends on ARCH_TEGRA
+select GENERIC_PHY
+help
+ Enable this to support the P2U (PIPE to UPHY) that is part of Tegra
19x SOCs.
diff --git a/drivers/phy/tegra/Makefile b/drivers/phy/tegra/Makefile
index 898589238fd9..f85b2c86643d 100644
--- a/drivers/phy/tegra/Makefile
+++ b/drivers/phy/tegra/Makefile
@@ -4,3 +4,4 @@ phy-tegra-xusb-y += xusb.o
phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_124_SOC) += xusb-tegra124.o
phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_132_SOC) += xusb-tegra124.o
phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_210_SOC) += xusb-tegra210.o
+obj-$(CONFIG_PHY_TEGRA194_PCIE_P2U) += pcie-p2u-tegra194.o
diff --git a/drivers/phy/tegra/pcie-p2u-tegra194.c
b/drivers/phy/tegra/pcie-p2u-tegra194.c
new file mode 100644
index ..bb2412ec4765
--- /dev/null
+++ b/drivers/phy/tegra/pcie-p2u-tegra194.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * P2U (PIPE to UPHY) driver for Tegra T194 SoC
+ *
+ * Copyright (C) 2018 NVIDIA Corporation.
+ *
+ * Author: Vidya Sagar
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define P2U_PERIODIC_EQ_CTRL_GEN3 0xc0
+#define P2U_PERIODIC_EQ_CTRL_GEN3_PERIODIC_EQ_EN BIT(0)
+#define P2U_PERIODIC_EQ_CTRL_GEN3_INIT_PRESET_EQ_TRAIN_EN BIT(1)
+#define P2U_PERIODIC_EQ_CTRL_GEN4 0xc4
+#define P2U_PERIODIC_EQ_CTRL_GEN4_INIT_PRESET_EQ_TRAIN_EN BIT(1)
+
+#define P2U_RX_DEBOUNCE_TIME 0xa4
+#define P2U_RX_DEBOUNCE_TIME_DEBOUNCE_TIMER_MASK 0x
+#define P2U_RX_DEBOUNCE_TIME_DEBOUNCE_TIMER_VAL160
+
+struct tegra_p2u {
+ void __iomem*base;
+};
+
+static int tegra_p2u_power_off(struct phy *x)
+{
+ return 0;
+}
+
+static int tegra_p2u_power_on(struct phy *x)
+{
+ u32 val;
+ struct tegra_p2u *phy = phy_get_drvdata(x);
+
+ val = readl(phy->base + P2U_PERIODIC_EQ_CTRL_GEN3);
+ val &= ~P2U_PERIODIC_EQ_CTRL_GEN3_PERIODIC_EQ_EN;
+ val |= P2U_PERIODIC_EQ_CTRL_GEN3_INIT_PRESET_EQ_TRAIN_EN;
+ writel(val, phy->base + P2U_PERIODIC_EQ_CTRL_GEN3);
+
+ val = readl(phy->base + P2U_PERIODIC_EQ_CTRL_GEN4);
+ val |= P2U_PERIODIC_EQ_CTRL_GEN4_INIT_PRESET_EQ_TRAIN_EN;
+ writel(val, phy->base + P2U_PERIODIC_EQ_CTRL_GEN4);
+
+ val = readl(phy->base + P2U_RX_DEBOUNCE_TIME);
+ val &= ~P2U_RX_DEBOUNCE_TIME_DEBOUNCE_TIMER_MASK;
+ val |= P2U_RX_DEBOUNCE_TIME_DEBOUNCE_TIMER_VAL;
+ writel(val, phy->base + P2U_RX_DEBOUNCE_TIME);
+
+ return 0;
+}
+
+static int tegra_p2u_init(struct phy *x)
+{
+ return 0;
+}
+
+static int tegra_p2u_exit(struct phy *x)
+{
+ return 0;
+}
+
+static const struct phy_ops ops = {
+ .init = tegra_p2u_init,
+ .exit = tegra_p2u_exit,
+ .power_on = tegra_p2u_power_on,
+ .power_off = tegra_p2u_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int tegra_p2u_probe(struct platform_device *pdev)
+{
+ struct tegra_p2u *phy;
+ struct phy *generic_phy;
+ struct phy_provider *phy_provider;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+
+ phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy)
+ return -ENOMEM;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "base");
+ phy->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(phy->base))
+ return PTR_ERR(phy->base);
+
+ platform_set_drvdata(pdev, phy);
+
+ generic_phy = devm_phy_create(dev, NULL, &ops);
+ if (IS_ERR(generic_phy))
+ return PTR_ERR(generic_phy);
+
+ phy_set_drvdata(generic_phy, phy);
+
+ phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
+
+ return 0;
+}
+
+s
[PATCH 05/10] dt-bindings: PCI: tegra: Add device tree support for T194
Add support for Tegra194 PCIe controllers. These controllers are based on Synopsys DesignWare core IP. Signed-off-by: Vidya Sagar --- .../bindings/pci/nvidia,tegra194-pcie.txt | 209 + .../devicetree/bindings/phy/phy-tegra194-p2u.txt | 34 2 files changed, 243 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt create mode 100644 Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt new file mode 100644 index ..31527283a0cd --- /dev/null +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt @@ -0,0 +1,209 @@ +NVIDIA Tegra PCIe controller (Synopsys DesignWare Core based) + +This PCIe host controller is based on the Synopsis Designware PCIe IP +and thus inherits all the common properties defined in designware-pcie.txt. + +Required properties: +- compatible: For Tegra19x, must contain "nvidia,tegra194-pcie". +- device_type: Must be "pci" +- reg: A list of physical base address and length for each set of controller + registers. Must contain an entry for each entry in the reg-names property. +- reg-names: Must include the following entries: + "appl": Controller's application logic registers + "window1": This is the aperture of controller available under 4GB boundary + (i.e. within 32-bit space). This aperture is typically used for + accessing config space of root port itself and also the connected + endpoints (by appropriately programming internal Address + Translation Unit's (iATU) out bound region) and also to map + prefetchable/non-prefetchable BARs. + "config": As per the definition in designware-pcie.txt + "atu_dma": iATU and DMA register. This is where the iATU (internal Address + Translation Unit) registers of the PCIe core are made available + fow SW access. + "dbi": The aperture where root port's own configuration registers are + available + "window2": This is the larger (compared to window1) aperture available above + 4GB boundary (i.e. in 64-bit space). This is typically used for + mapping prefetchable/non-prefetchable BARs of endpoints +- interrupts: A list of interrupt outputs of the controller. Must contain an + entry for each entry in the interrupt-names property. +- interrupt-names: Must include the following entries: + "intr": The Tegra interrupt that is asserted for controller interrupts + "msi": The Tegra interrupt that is asserted when an MSI is received +- bus-range: Range of bus numbers associated with this controller +- #address-cells: Address representation for root ports (must be 3) + - cell 0 specifies the bus and device numbers of the root port: +[23:16]: bus number +[15:11]: device number + - cell 1 denotes the upper 32 address bits and should be 0 + - cell 2 contains the lower 32 address bits and is used to translate to the +CPU address space +- #size-cells: Size representation for root ports (must be 2) +- ranges: Describes the translation of addresses for root ports and standard + PCI regions. The entries must be 7 cells each, where the first three cells + correspond to the address as described for the #address-cells property + above, the fourth and fifth cells are for the physical CPU address to + translate to and the sixth and seventh cells are as described for the + #size-cells property above. + - Entries setup the mapping for the standard I/O, memory and +prefetchable PCI regions. The first cell determines the type of region +that is setup: +- 0x8100: I/O memory region +- 0x8200: non-prefetchable memory region +- 0xc200: prefetchable memory region + Please refer to the standard PCI bus binding document for a more detailed + explanation. +- #interrupt-cells: Size representation for interrupts (must be 1) +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties + Please refer to the standard PCI bus binding document for a more detailed + explanation. +- clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - core_clk +- resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names: Must include the following entries: + - core_apb_rst + - core_rst +- phys: Must contain a phandle to P2U PHY for each entry in phy-names. +- phy-names: Must include an entry for each active lane. + "pcie-p2u-N": where N ranges from 0 to one less than the total number of lanes +- Controller dependent register offsets + - nvidia,event-cntr-ctrl: EVENT_COUNTER_CONTROL reg offset + 0x168 - FPGA + 0x1a8 - C1, C2 and C3 + 0x1c4 - C4 + 0x1d8 - C0 and C5 + - nvidia,e
[PATCH 06/10] arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT
Add P2U (PIPE to UPHY) and PCIe controller nodes to device tree.
The Tegra194 SoC contains six PCIe controllers and twenty P2U instances
grouped into two different PHY bricks namely High-Speed IO (HSIO-12 P2Us)
and NVIDIA High Speed (NVHS-8 P2Us) respectively.
Signed-off-by: Vidya Sagar
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 473 +++
1 file changed, 473 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index c77ca211fa8f..266a3058fa66 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1054,4 +1054,477 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
interrupt-parent = <&gic>;
};
+
+ hsio-p2u {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ p2u_0: p2u@03e1 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03e1 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_1: p2u@03e2 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03e2 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_2: p2u@03e3 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03e3 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_3: p2u@03e4 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03e4 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_4: p2u@03e5 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03e5 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_5: p2u@03e6 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03e6 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_6: p2u@03e7 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03e7 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_7: p2u@03e8 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03e8 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_8: p2u@03e9 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03e9 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_9: p2u@03ea {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03ea 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_10: p2u@03f3 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03f3 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_11: p2u@03f4 {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03f4 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ };
+
+ nvhs-p2u {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ p2u_12: p2u@03eb {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03eb 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_13: p2u@03ec {
+ compatible = "nvidia,tegra194-phy-p2u";
+ reg = <0x0 0x03ec 0x0 0x0001>;
+ reg-names = "base";
+
+ #phy-cells = <0>;
+ };
+ p2u_14: p2u@03ed {
+
[PATCH 04/10] PCI: Add #defines for PCIe spec r4.0 features
Add #defines for the Data Link Feature and Physical Layer 16.0 GT/s features. Signed-off-by: Vidya Sagar --- include/uapi/linux/pci_regs.h | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h index 5c98133f2c94..3e01b55d548d 100644 --- a/include/uapi/linux/pci_regs.h +++ b/include/uapi/linux/pci_regs.h @@ -705,7 +705,9 @@ #define PCI_EXT_CAP_ID_DPC 0x1D/* Downstream Port Containment */ #define PCI_EXT_CAP_ID_L1SS0x1E/* L1 PM Substates */ #define PCI_EXT_CAP_ID_PTM 0x1F/* Precision Time Measurement */ -#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PTM +#define PCI_EXT_CAP_ID_DLF 0x25/* Data Link Feature */ +#define PCI_EXT_CAP_ID_PL 0x26/* Physical Layer 16.0 GT/s */ +#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PL #define PCI_EXT_CAP_DSN_SIZEOF 12 #define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40 @@ -1045,4 +1047,22 @@ #define PCI_L1SS_CTL1_LTR_L12_TH_SCALE0xe000 /* LTR_L1.2_THRESHOLD_Scale */ #define PCI_L1SS_CTL2 0x0c/* Control 2 Register */ +/* Data Link Feature */ +#define PCI_DLF_CAP0x04/* Capabilities Register */ +#define PCI_DLF_LOCAL_DLF_SUP_MASK0x007f /* Local Data Link Feature Supported */ +#define PCI_DLF_EXCHANGE_ENABLE 0x8000 /* Data Link Feature Exchange Enable */ +#define PCI_DLF_STS0x08/* Status Register */ +#define PCI_DLF_REMOTE_DLF_SUP_MASK 0x007f /* Remote Data Link Feature Supported */ +#define PCI_DLF_REMOTE_DLF_SUP_VALID 0x8000 /* Remote Data Link Feature Support Valid */ + +/* Physical Layer 16.0 GT/s */ +#define PCI_PL_16GT_CAP0x04/* Capabilities Register */ +#define PCI_PL_16GT_CTRL 0x08/* Control Register */ +#define PCI_PL_16GT_STS0x0c/* Status Register */ +#define PCI_PL_16GT_LDPM_STS 0x10/* Local Data Parity Mismatch Status Register */ +#define PCI_PL_16GT_FRDPM_STS 0x14/* First Retimer Data Parity Mismatch Status Register */ +#define PCI_PL_16GT_SRDPM_STS 0x18/* Second Retimer Data Parity Mismatch Status Register */ +#define PCI_PL_16GT_RSVD 0x1C/* Reserved */ +#define PCI_PL_16GT_LE_CTRL0x20/* Lane Equalization Control Register */ + #endif /* LINUX_PCI_REGS_H */ -- 2.7.4
[PATCH 03/10] PCI: dwc: Move config space capability search API
move PCIe config space capability search API to common designware file
as this can be used by both host and ep mode codes.
It also adds extended capability search APIs.
Signed-off-by: Vidya Sagar
---
drivers/pci/controller/dwc/pcie-designware-ep.c | 37 +
drivers/pci/controller/dwc/pcie-designware.c| 73 +
drivers/pci/controller/dwc/pcie-designware.h| 3 +
3 files changed, 78 insertions(+), 35 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 24f5a775ad34..b9d9c9a4ba6d 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -40,39 +40,6 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
pci_barno bar)
__dw_pcie_ep_reset_bar(pci, bar, 0);
}
-static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie *pci, u8 cap_ptr,
- u8 cap)
-{
- u8 cap_id, next_cap_ptr;
- u16 reg;
-
- reg = dw_pcie_readw_dbi(pci, cap_ptr);
- next_cap_ptr = (reg & 0xff00) >> 8;
- cap_id = (reg & 0x00ff);
-
- if (!next_cap_ptr || cap_id > PCI_CAP_ID_MAX)
- return 0;
-
- if (cap_id == cap)
- return cap_ptr;
-
- return __dw_pcie_ep_find_next_cap(pci, next_cap_ptr, cap);
-}
-
-static u8 dw_pcie_ep_find_capability(struct dw_pcie *pci, u8 cap)
-{
- u8 next_cap_ptr;
- u16 reg;
-
- reg = dw_pcie_readw_dbi(pci, PCI_CAPABILITY_LIST);
- next_cap_ptr = (reg & 0x00ff);
-
- if (!next_cap_ptr)
- return 0;
-
- return __dw_pcie_ep_find_next_cap(pci, next_cap_ptr, cap);
-}
-
static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
struct pci_epf_header *hdr)
{
@@ -591,9 +558,9 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
dev_err(dev, "Failed to reserve memory for MSI/MSI-X\n");
return -ENOMEM;
}
- ep->msi_cap = dw_pcie_ep_find_capability(pci, PCI_CAP_ID_MSI);
+ ep->msi_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
- ep->msix_cap = dw_pcie_ep_find_capability(pci, PCI_CAP_ID_MSIX);
+ ep->msix_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSIX);
dw_pcie_setup(pci);
diff --git a/drivers/pci/controller/dwc/pcie-designware.c
b/drivers/pci/controller/dwc/pcie-designware.c
index 31f6331ca46f..164a63b7688a 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -20,6 +20,79 @@
#define PCIE_PHY_DEBUG_R1_LINK_UP (0x1 << 4)
#define PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING (0x1 << 29)
+static u8 __dw_pcie_find_next_cap(struct dw_pcie *pci, u8 cap_ptr,
+ u8 cap)
+{
+ u8 cap_id, next_cap_ptr;
+ u16 reg;
+
+ reg = dw_pcie_readw_dbi(pci, cap_ptr);
+ next_cap_ptr = (reg & 0xff00) >> 8;
+ cap_id = (reg & 0x00ff);
+
+ if (!next_cap_ptr || cap_id > PCI_CAP_ID_MAX)
+ return 0;
+
+ if (cap_id == cap)
+ return cap_ptr;
+
+ return __dw_pcie_find_next_cap(pci, next_cap_ptr, cap);
+}
+
+u8 dw_pcie_find_capability(struct dw_pcie *pci, u8 cap)
+{
+ u8 next_cap_ptr;
+ u16 reg;
+
+ reg = dw_pcie_readw_dbi(pci, PCI_CAPABILITY_LIST);
+ next_cap_ptr = (reg & 0x00ff);
+
+ if (!next_cap_ptr)
+ return 0;
+
+ return __dw_pcie_find_next_cap(pci, next_cap_ptr, cap);
+}
+
+static int dw_pcie_find_next_ext_capability(struct dw_pcie *pci, int start,
+ int cap)
+{
+ u32 header;
+ int ttl;
+ int pos = PCI_CFG_SPACE_SIZE;
+
+ /* minimum 8 bytes per capability */
+ ttl = (PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) / 8;
+
+ if (start)
+ pos = start;
+
+ header = dw_pcie_readl_dbi(pci, pos);
+ /*
+* If we have no capabilities, this is indicated by cap ID,
+* cap version and next pointer all being 0.
+*/
+ if (header == 0)
+ return 0;
+
+ while (ttl-- > 0) {
+ if (PCI_EXT_CAP_ID(header) == cap && pos != start)
+ return pos;
+
+ pos = PCI_EXT_CAP_NEXT(header);
+ if (pos < PCI_CFG_SPACE_SIZE)
+ break;
+
+ header = dw_pcie_readl_dbi(pci, pos);
+ }
+
+ return 0;
+}
+
+int dw_pcie_find_ext_capability(struct dw_pcie *pci, int cap)
+{
+ return dw_pcie_find_next_ext_capability(pci, 0, cap);
+}
+
int dw_pcie_read(void __iomem *addr, int size, u32 *val)
{
if (!IS_ALIGNED((uintptr_t)addr, size)) {
diff --git a/drivers/pci/controller/dwc/pcie-designware.h
b/drivers/pci/controller/dwc/pcie-designware.h
index 70007276bc93..47996f433a57 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
[PATCH 01/10] PCI: save pci_bus pointer in pcie_port structure
save pci_bus pointer created by PCIe sub-system's
pci_scan_root_bus_bridge() to be used by host controller drivers for post
processing. Tegra host controller driver needs it for the following
reasons
- to derive pci_host_bridge structure from pci_bus which is used to
configure iATU's outbound regions for different windows accesses
- to traverse and configure downstream hierarchy. One such case is,
configuring all immediate downstream devices to D0 state before transiting
link to L2 state. Saving pci_bus pointer seems the best method compared to
deriving it by other means.
Signed-off-by: Vidya Sagar
---
drivers/pci/controller/dwc/pcie-designware-host.c | 1 +
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
b/drivers/pci/controller/dwc/pcie-designware-host.c
index 25087d3c9a82..15add3cf3945 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -494,6 +494,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
goto error;
bus = bridge->bus;
+ pp->bus = bus;
if (pp->ops->scan_bus)
pp->ops->scan_bus(pp);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h
b/drivers/pci/controller/dwc/pcie-designware.h
index 377f4c0b52da..70007276bc93 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -175,6 +175,7 @@ struct pcie_port {
struct resource *busn;
int irq;
const struct dw_pcie_host_ops *ops;
+ struct pci_bus *bus;
int msi_irq;
struct irq_domain *irq_domain;
struct irq_domain *msi_domain;
--
2.7.4
[PATCH 02/10] PCI: perform dbi regs write lock towards the end
Remove multiple write enable and disable sequences of dbi registers as Tegra194 implements writes to BAR-0 register (offset: 0x10) controlled by DBI write-lock enable bit thereby not allowing any further writes to BAR-0 register in config space to take place. Hence disabling write permission only towards the end. Signed-off-by: Vidya Sagar --- drivers/pci/controller/dwc/pcie-designware-host.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c index 15add3cf3945..e17213f2217e 100644 --- a/drivers/pci/controller/dwc/pcie-designware-host.c +++ b/drivers/pci/controller/dwc/pcie-designware-host.c @@ -670,7 +670,6 @@ void dw_pcie_setup_rc(struct pcie_port *pp) val &= 0x00ff; val |= 0x0100; dw_pcie_writel_dbi(pci, PCI_INTERRUPT_LINE, val); - dw_pcie_dbi_ro_wr_dis(pci); /* Setup bus numbers */ val = dw_pcie_readl_dbi(pci, PCI_PRIMARY_BUS); @@ -710,8 +709,6 @@ void dw_pcie_setup_rc(struct pcie_port *pp) dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0); - /* Enable write permission for the DBI read-only register */ - dw_pcie_dbi_ro_wr_en(pci); /* Program correct class for RC */ dw_pcie_wr_own_conf(pp, PCI_CLASS_DEVICE, 2, PCI_CLASS_BRIDGE_PCI); /* Better disable write permission right after the update */ -- 2.7.4
[PATCH 00/10] Add Tegra194 PCIe support
Tegra194 has six PCIe controllers based on Synopsys DesignWare core. There are two Universal PHY (UPHY) blocks with each supporting 12(HSIO: Hisg Speed IO) and 8(NVHS: NVIDIA High Speed) lanes respectively. Controllers:0~4 use UPHY lanes from HSIO brick whereas Controller:5 uses UPHY lanes from NVHS brick. Lane mapping in HSIO UPHY brick to each PCIe controller (0~4) is controlled in XBAR module by BPMP-FW. Since PCIe core has PIPE interface, a glue module called PIPE-to-UPHY (P2U) is used to connect each UPHY lane (applicable to both HSIO and NVHS UPHY bricks) to PCIe controller This patch series - Adds support for P2U PHY driver - Adds support for PCIe host controller - Adds device tree nodes each PCIe controllers - Enables nodes applicable to p2972- platform - Adds helper APIs in Designware core driver to get capability regs offset - Adds defines for new feature registers of PCIe spec revision 4 - Makes changes in DesignWare core driver to get Tegra194 PCIe working Testing done on P2972- platform - Able to get PCIe link up with on-board Marvel eSATA controller - Able to get PCIe link up with NVMe cards connected to M.2 Key-M slot - Able to do data transfers with both SATA drives and NVMe cards Note - Enabling x8 slot on P2972- platform requires pinmux driver for Tegra194. It is being worked on currently and hence Controller:5 (i.e. x8 slot) is disabled in this patch series. A future patch series would enable this. Vidya Sagar (10): PCI: save pci_bus pointer in pcie_port structure PCI: perform dbi regs write lock towards the end PCI: dwc: Move config space capability search API PCI: Add #defines for PCIe spec r4.0 features dt-bindings: PCI: tegra: Add device tree support for T194 arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT arm64: tegra: Enable PCIe slots in P2972- board phy: tegra: Add PCIe PIPE2UPHY support PCI: tegra: Add Tegra194 PCIe support arm64: Add Tegra194 PCIe driver to defconfig .../bindings/pci/nvidia,tegra194-pcie.txt | 209 +++ .../devicetree/bindings/phy/phy-tegra194-p2u.txt | 34 + arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi |2 +- arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts | 50 + arch/arm64/boot/dts/nvidia/tegra194.dtsi | 473 + arch/arm64/configs/defconfig |1 + drivers/pci/controller/dwc/Kconfig | 10 + drivers/pci/controller/dwc/Makefile|1 + drivers/pci/controller/dwc/pcie-designware-ep.c| 37 +- drivers/pci/controller/dwc/pcie-designware-host.c |4 +- drivers/pci/controller/dwc/pcie-designware.c | 73 + drivers/pci/controller/dwc/pcie-designware.h |4 + drivers/pci/controller/dwc/pcie-tegra194.c | 1862 drivers/phy/tegra/Kconfig |7 + drivers/phy/tegra/Makefile |1 + drivers/phy/tegra/pcie-p2u-tegra194.c | 138 ++ include/uapi/linux/pci_regs.h | 22 +- 17 files changed, 2888 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt create mode 100644 Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt create mode 100644 drivers/pci/controller/dwc/pcie-tegra194.c create mode 100644 drivers/phy/tegra/pcie-p2u-tegra194.c -- 2.7.4
Re: [PATCH 5/5] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
On Fri 2019-03-22 17:29:30, Sakari Ailus wrote:
> Add support for %pfw conversion specifier (with "f" and "P" modifiers) to
> support printing full path of the node, including its name ("f") and only
> the node's name ("P") in the printk family of functions. The two flags
> have equivalent functionality to existing %pOF with the same two modifiers
> ("f" and "P") on OF based systems. The ability to do the same on ACPI
> based systems is added by this patch.
>
> On ACPI based systems the resulting strings look like
>
> \_SB.PCI0.CIO2.port@1.endpoint@0
>
> where the nodes are separated by a dot (".") and the first three are
> ACPI device nodes and the latter two ACPI data nodes.
>
> Depends-on: ("vsprintf: Remove support for %pF and %pf in favour of %pS and
> %ps")
Reusing obsolete modifiers is dangerous from many reasons:
+ people might miss the change of the meaning
+ backporting mistakes
+ 3rd party modules
It might be acceptable if the long term gain is bigger
than a short time difficulties. But it would be better
to it a safe way when possible.
Fortunately, we could keep the backward compatibility
for "%pf" and handle only "%pfw*" with the fwnode api.
Best Regards,
Petr
Re: [PATCH v2] x86/syscalls: Mark expected switch fall-throughs
On 03/23, Thomas Gleixner wrote:
>
> On Thu, 28 Feb 2019, Gustavo A. R. Silva wrote:
>
> > arch/x86/include/asm/syscall.h | 28
> > 1 file changed, 28 insertions(+)
>
> Second thoughts. So this adds 28 /* fall through */ comments. Now I
> appreciate the effort, but can we pretty please look at the code in
> question and figure out whether the implementation makes sense in the first
> place before adding falltrough comments blindly?
>
> The whole exercise can be simplified. Untested patch below.
>
> Looking at that stuff makes me wonder about two things:
>
> 1) The third argument of get/set(), i.e. the argument offset, is 0 on all
> call sites. Do we need it at all?
Probably "maxargs" can be removed too, Steven sent the patches a long ago, see
https://lore.kernel.org/lkml/20161107212634.529267...@goodmis.org/
> 2) syscall_set_arguments() has been introduced in 2008 and we still have
> no caller. Instead of polishing it, can it be removed completely or are
> there plans to actually use it?
I think it can die.
>
> Thanks,
>
> tglx
>
> 8<
>
> arch/x86/include/asm/syscall.h | 174
> +++--
> 1 file changed, 64 insertions(+), 110 deletions(-)
>
> --- a/arch/x86/include/asm/syscall.h
> +++ b/arch/x86/include/asm/syscall.h
> @@ -114,126 +114,80 @@ static inline int syscall_get_arch(void)
>
> #else /* CONFIG_X86_64 */
>
> +static inline unsigned long syscall_get_argreg(struct pt_regs *regs,
> +unsigned int idx)
> +{
> + switch (idx) {
> + case 0: return regs->di;
> + case 1: return regs->si;
> + case 2: return regs->dx;
> + case 3: return regs->r10;
> + case 4: return regs->r8;
> + case 5: return regs->r9;
> +#ifdef CONFIG_IA32_EMULATION
> + case 6: return regs->bx;
> + case 7: return regs->cx;
> + case 8: return regs->dx;
> + case 9: return regs->si;
> + case 10: return regs->di;
> + case 11: return regs->bp;
> +#endif
> + }
> + return 0;
> +}
> +
> static inline void syscall_get_arguments(struct task_struct *task,
>struct pt_regs *regs,
> - unsigned int i, unsigned int n,
> + unsigned int idx, unsigned int cnt,
>unsigned long *args)
> {
> -# ifdef CONFIG_IA32_EMULATION
> - if (task->thread_info.status & TS_COMPAT)
> - switch (i) {
> - case 0:
> - if (!n--) break;
> - *args++ = regs->bx;
> - case 1:
> - if (!n--) break;
> - *args++ = regs->cx;
> - case 2:
> - if (!n--) break;
> - *args++ = regs->dx;
> - case 3:
> - if (!n--) break;
> - *args++ = regs->si;
> - case 4:
> - if (!n--) break;
> - *args++ = regs->di;
> - case 5:
> - if (!n--) break;
> - *args++ = regs->bp;
> - case 6:
> - if (!n--) break;
> - default:
> - BUG();
> - break;
> - }
> - else
> -# endif
> - switch (i) {
> - case 0:
> - if (!n--) break;
> - *args++ = regs->di;
> - case 1:
> - if (!n--) break;
> - *args++ = regs->si;
> - case 2:
> - if (!n--) break;
> - *args++ = regs->dx;
> - case 3:
> - if (!n--) break;
> - *args++ = regs->r10;
> - case 4:
> - if (!n--) break;
> - *args++ = regs->r8;
> - case 5:
> - if (!n--) break;
> - *args++ = regs->r9;
> - case 6:
> - if (!n--) break;
> - default:
> - BUG();
> - break;
> - }
> + if (WARN_ON((idx + cnt) > 6))
> + return;
> +
> + if (IS_ENABLED(CONFIG_IA32_EMULATION) &&
> + task->thread_info.status & TS_COMPAT)
> + idx += 6;
> +
> + for (; cnt > 0; cnt--)
> + *args++ = syscall_get_argreg(regs, idx++);
> +}
> +
> +static inline void syscall_set_argreg(struct pt_regs *regs,
> + unsigned int idx,
> + unsigned long val)
> +{
> + switch (idx) {
> + case 0: regs->di = val; break;
> + case 1: regs->si = val; break;
> + case 2: regs->dx = val; break;
> + case 3: regs->r10 = val; break;
> + case 4: regs->r8 = val; break;
> + case 5:
Re: [PATCH v2 2/2] tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped
Le 19/03/2019 à 14:20, Razvan Stefanescu a écrit :
> In half-duplex operation, RX should be started after TX completes.
>
> If DMA is used, there is a case when the DMA transfer completes but the
> TX FIFO is not emptied, so the RX cannot be restarted just yet.
>
> Use a boolean variable to store this state and rearm TX interrupt mask
> to be signaled again that the transfer finished. In interrupt transmit
> handler this variable is used to start RX. A warning message is generated
> if RX is activated before TX fifo is cleared.
>
> Fixes: b389f173aaa1 ("tty/serial: atmel: RS485 half duplex w/DMA: enable
> RX after TX is done")
> Signed-off-by: Razvan Stefanescu
Acked-by: Richard Genoud
NB: backport on kernel older than 4.20 will fail because of the iso7816
variables fidi_min/fidi_max.
> ---
> Changelog:
> v2:
> - start RX and display warning in case of error
> - add fix info
>
> drivers/tty/serial/atmel_serial.c | 25 ++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c
> b/drivers/tty/serial/atmel_serial.c
> index b4b89a16a41b..5b2f859c327c 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -166,6 +166,8 @@ struct atmel_uart_port {
> unsigned intpending_status;
> spinlock_t lock_suspended;
>
> + boolhd_start_rx;/* can start RX during
> half-duplex operation */
> +
> /* ISO7816 */
> unsigned intfidi_min;
> unsigned intfidi_max;
> @@ -933,8 +935,13 @@ static void atmel_complete_tx_dma(void *arg)
> if (!uart_circ_empty(xmit))
> atmel_tasklet_schedule(atmel_port, &atmel_port->tasklet_tx);
> else if (atmel_uart_is_half_duplex(port)) {
> - /* DMA done, stop TX, start RX for RS485 */
> - atmel_start_rx(port);
> + /*
> + * DMA done, re-enable TXEMPTY and signal that we can stop
> + * TX and start RX for RS485
> + */
> + atmel_port->hd_start_rx = true;
> + atmel_uart_writel(port, ATMEL_US_IER,
> + atmel_port->tx_done_mask);
> }
>
> spin_unlock_irqrestore(&port->lock, flags);
> @@ -1378,9 +1385,20 @@ atmel_handle_transmit(struct uart_port *port, unsigned
> int pending)
> struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>
> if (pending & atmel_port->tx_done_mask) {
> - /* Either PDC or interrupt transmission */
> atmel_uart_writel(port, ATMEL_US_IDR,
> atmel_port->tx_done_mask);
> +
> + /* Start RX if flag was set and FIFO is empty */
> + if (atmel_port->hd_start_rx) {
> + if (!(atmel_uart_readl(port, ATMEL_US_CSR)
> + & ATMEL_US_TXEMPTY))
> + dev_warn(port->dev, "Should start RX, but TX
> fifo is not empty\n");
> +
> + atmel_port->hd_start_rx = false;
> + atmel_start_rx(port);
> + return;
> + }
> +
> atmel_tasklet_schedule(atmel_port, &atmel_port->tasklet_tx);
> }
> }
>
Re: [PATCH ghak109 V1] audit: link integrity evm_write_xattrs record to syscall event
On Wed, 2019-03-20 at 20:50 -0400, Richard Guy Briggs wrote:
> On 2019-03-20 19:48, Paul Moore wrote:
> > On Sat, Mar 16, 2019 at 8:10 AM Richard Guy Briggs wrote:
> > > In commit fa516b66a1bf ("EVM: Allow runtime modification of the set of
> > > verified xattrs"), the call to audit_log_start() is missing a context to
> > > link it to an audit event. Since this event is in user context, add
> > > the process' syscall context to the record.
> > >
> > > In addition, the orphaned keyword "locked" appears in the record.
> > > Normalize this by changing it to "xattr=(locked)".
> > >
> > > Please see the github issue
> > > https://github.com/linux-audit/audit-kernel/issues/109
> > >
> > > Signed-off-by: Richard Guy Briggs
> > > ---
> > > security/integrity/evm/evm_secfs.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/security/integrity/evm/evm_secfs.c
> > > b/security/integrity/evm/evm_secfs.c
> > > index 015aea8fdf1e..4171d174e9da 100644
> > > --- a/security/integrity/evm/evm_secfs.c
> > > +++ b/security/integrity/evm/evm_secfs.c
> > > @@ -192,7 +192,8 @@ static ssize_t evm_write_xattrs(struct file *file,
> > > const char __user *buf,
> > > if (count > XATTR_NAME_MAX)
> > > return -E2BIG;
> > >
> > > - ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_INTEGRITY_EVM_XATTR);
> > > + ab = audit_log_start(audit_context(), GFP_KERNEL,
> > > +AUDIT_INTEGRITY_EVM_XATTR);
> >
> > This part is fine.
> >
> > > if (!ab)
> > > return -ENOMEM;
> > >
> > > @@ -222,7 +223,7 @@ static ssize_t evm_write_xattrs(struct file *file,
> > > const char __user *buf,
> > > inode_lock(inode);
> > > err = simple_setattr(evm_xattrs, &newattrs);
> > > inode_unlock(inode);
> > > - audit_log_format(ab, "locked");
> > > + audit_log_format(ab, "xattr=(locked)");
> >
> > Two things come to mind:
> >
> > * While we can clearly trust the string above, should we be logging
> > the xattr field value as an untrusted string so it is consistent with
> > how we record other xattr names?
>
> That would be a question for Steve.
>
> > * I'm not sure you can ever have parens in a xattr (I would hope not),
> > but if we are going to use the xattr field, perhaps we should simply
> > stick with the name as provided (".") so we don't ever run afoul of
> > xattr names? I'm curious to hear what the IMA/EVM folks think of
> > this.
>
> The legal xaddr names start with XATTR_SECURITY_PREFIX which is
> "security." so there is no danger of collision with legal names, but I
> suppose someone could try to use "(locked)" as a name which would look
> identical but fail with a different res= number. I think I prefer your
> idea of printing the given value verbatim.
I really don't have a preference - "locked", "(locked)", "." or "(.)".
Any of them is fine.
Thanks!
Mimi
Re: [RFC PATCH 1/2] dt-bindings: spi: Add device tree binding documentation for Zynq QSPI controller
On Thu, 28 Feb 2019 12:31:53 +0530, Naga Sureshkumar Relli wrote: > This patch adds the dts binding document for Zynq SOC QSPI > controller. > > Signed-off-by: Naga Sureshkumar Relli > --- > .../devicetree/bindings/spi/spi-zynq-qspi.txt | 25 > ++ > 1 file changed, 25 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt > Reviewed-by: Rob Herring
Re: [PATCH -next] x86/apic: Reduce print level of CPU limit announcement
On Tue, Mar 26, 2019 at 3:41 PM Leon Romanovsky wrote:
>
> On Tue, Mar 26, 2019 at 01:29:54PM +0100, Rafael J. Wysocki wrote:
> > On Tue, Mar 26, 2019 at 1:02 PM Leon Romanovsky wrote:
> > >
> > > From: Leon Romanovsky
> > >
> > > Kernel is booted with less possible CPUs (possible_cpus kernel boot
> > > option) than available CPUs will have prints like this:
> > >
> > > [1.131039] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor
> > > 55/0x1f ignored.
> > > [1.132228] ACPI: Unable to map lapic to logical cpu number
> > >
> > > Those warnings are printed for every not-enabled CPU and on the systems
> > > with large number of such CPUs, we see a lot of those prints for default
> > > print level.
> > >
> > > Simple conversion of those prints to be in debug level removes them
> > > while leaving the option to debug system.
> >
> > But generally dynamic debug must be enabled in order for pr_debug()
> > prints to be visible which is kind of cumbersome to do via the command
> > line.
>
> It is doable and documented pretty well, which is uncommon :)
> https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html#debug-messages-during-boot-process
I know.
That's what I mean by "kind of cumbersome", because you need to know
which debug messages to enable upfront.
> >
> > > Signed-off-by: Leon Romanovsky
> > > ---
> > > arch/x86/kernel/acpi/boot.c | 2 +-
> > > arch/x86/kernel/apic/apic.c | 6 +++---
> > > 2 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > > index 8dcbf6890714..3ef8ab89c02d 100644
> > > --- a/arch/x86/kernel/acpi/boot.c
> > > +++ b/arch/x86/kernel/acpi/boot.c
> > > @@ -770,7 +770,7 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t
> > > physid, u32 acpi_id,
> > >
> > > cpu = acpi_register_lapic(physid, acpi_id, ACPI_MADT_ENABLED);
> > > if (cpu < 0) {
> > > - pr_info(PREFIX "Unable to map lapic to logical cpu
> > > number\n");
> > > + pr_debug(PREFIX "Unable to map lapic to logical cpu
> > > number\n");
> >
> > And this one is printed sometimes when something really goes wrong
> > which may be really hard to debug otherwise, so there is value in the
> > info level here.
> >
> > Would it be possible to avoid printing it just in some cases?
>
> This can do the trick:
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 3ef8ab89c02d..00212b3991e0 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -770,7 +770,10 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t
> physid, u32 acpi_id,
>
> cpu = acpi_register_lapic(physid, acpi_id, ACPI_MADT_ENABLED);
> if (cpu < 0) {
> - pr_debug(PREFIX "Unable to map lapic to logical cpu
> number\n");
> + if (cpu == -ENOENT)
> + pr_debug(PREFIX "Unable to map lapic to logical cpu
> number\n");
I don't think it is necessary to print this in the -ENOENT case, as
there is a message for that case that will be printed anyway.
> + else
> + pr_info(PREFIX "Unable to map lapic to logical cpu
> number\n");
> return cpu;
> }
>
Re: tools bugs: make clean deletes files in the git tree
On 3/26/19 4:45 AM, Adrian Hunter wrote: Hi Doing: make -C tools clean Results in: git diff --stat tools/pci/pcitest.sh | 72 tools/testing/selftests/livepatch/test-callbacks.sh | 587 tools/testing/selftests/livepatch/test-livepatch.sh | 168 tools/testing/selftests/livepatch/test-shadow-vars.sh | 60 - 4 files changed, 887 deletions(-) i.e. 'make clean' seems to be deleting files that are in the git tree. Regards Adrian Hi Adrian -- thanks for the report. I will fixup the livepatch selftests Makefile and post a patch shortly. -- Joe
Re: [PATCH][next] RDMA/nes: remove redundant check on udata
On Sat, Mar 02, 2019 at 11:06:36PM +, Colin King wrote:
> From: Colin Ian King
>
> The non-null check on udata is redundant as this check was performed
> just a few statements earlier and the check is always true as udata
> must be non-null at this point. Remove redundant the check on udata
> and the redundant else part that can never be executed.
>
> Detected by CoverityScan, CID#1477317 ("Logically dead code")
>
> Signed-off-by: Colin Ian King
> ---
> drivers/infiniband/hw/nes/nes_verbs.c | 73 +--
> 1 file changed, 34 insertions(+), 39 deletions(-)
Applied to for-next
Thanks,
Jason
Re: [PATCH v2 1/2] tty/serial: atmel: Add is_half_duplex helper
Le 19/03/2019 à 14:20, Razvan Stefanescu a écrit :
> Use a helper function to check that a port needs to use half duplex
> communication, replacing several occurrences of multi-line bit checking.
>
> Fixes: b389f173aaa1 ("tty/serial: atmel: RS485 half duplex w/DMA: enable
> RX after TX is done")
> Signed-off-by: Razvan Stefanescu
Acked-by: Richard Genoud
NB: backport on kernel older than 4.20 will fail because of the
SER_ISO7816_ENABLED flag.
> ---
> Changelog:
> v2:
> - remove extra check
> - add fix info
>
> drivers/tty/serial/atmel_serial.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c
> b/drivers/tty/serial/atmel_serial.c
> index 05147fe24343..b4b89a16a41b 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -231,6 +231,13 @@ static inline void atmel_uart_write_char(struct
> uart_port *port, u8 value)
> __raw_writeb(value, port->membase + ATMEL_US_THR);
> }
>
> +static inline int atmel_uart_is_half_duplex(struct uart_port *port)
> +{
> + return ((port->rs485.flags & SER_RS485_ENABLED) &&
> + !(port->rs485.flags & SER_RS485_RX_DURING_TX)) ||
> + (port->iso7816.flags & SER_ISO7816_ENABLED);
> +}
> +
> #ifdef CONFIG_SERIAL_ATMEL_PDC
> static bool atmel_use_pdc_rx(struct uart_port *port)
> {
> @@ -608,10 +615,9 @@ static void atmel_stop_tx(struct uart_port *port)
> /* Disable interrupts */
> atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
>
> - if (((port->rs485.flags & SER_RS485_ENABLED) &&
> - !(port->rs485.flags & SER_RS485_RX_DURING_TX)) ||
> - port->iso7816.flags & SER_ISO7816_ENABLED)
> + if (atmel_uart_is_half_duplex(port))
> atmel_start_rx(port);
> +
> }
>
> /*
> @@ -628,9 +634,7 @@ static void atmel_start_tx(struct uart_port *port)
> return;
>
> if (atmel_use_pdc_tx(port) || atmel_use_dma_tx(port))
> - if (((port->rs485.flags & SER_RS485_ENABLED) &&
> - !(port->rs485.flags & SER_RS485_RX_DURING_TX)) ||
> - port->iso7816.flags & SER_ISO7816_ENABLED)
> + if (atmel_uart_is_half_duplex(port))
> atmel_stop_rx(port);
>
> if (atmel_use_pdc_tx(port))
> @@ -928,9 +932,7 @@ static void atmel_complete_tx_dma(void *arg)
>*/
> if (!uart_circ_empty(xmit))
> atmel_tasklet_schedule(atmel_port, &atmel_port->tasklet_tx);
> - else if (((port->rs485.flags & SER_RS485_ENABLED) &&
> - !(port->rs485.flags & SER_RS485_RX_DURING_TX)) ||
> - port->iso7816.flags & SER_ISO7816_ENABLED) {
> + else if (atmel_uart_is_half_duplex(port)) {
> /* DMA done, stop TX, start RX for RS485 */
> atmel_start_rx(port);
> }
> @@ -1508,9 +1510,7 @@ static void atmel_tx_pdc(struct uart_port *port)
> atmel_uart_writel(port, ATMEL_US_IER,
> atmel_port->tx_done_mask);
> } else {
> - if (((port->rs485.flags & SER_RS485_ENABLED) &&
> - !(port->rs485.flags & SER_RS485_RX_DURING_TX)) ||
> - port->iso7816.flags & SER_ISO7816_ENABLED) {
> + if (atmel_uart_is_half_duplex(port)) {
> /* DMA done, stop TX, start RX for RS485 */
> atmel_start_rx(port);
> }
>
[PATCH v2] mfd: Add support for Merrifield Basin Cove PMIC
Add an mfd driver for Intel Merrifield Basin Cove PMIC.
Signed-off-by: Andy Shevchenko
---
- corrected name of Power Source detection driver
drivers/mfd/Kconfig | 11 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/intel_soc_pmic_mrfld.c | 157 +++
include/linux/mfd/intel_soc_pmic_mrfld.h | 81
4 files changed, 250 insertions(+)
create mode 100644 drivers/mfd/intel_soc_pmic_mrfld.c
create mode 100644 include/linux/mfd/intel_soc_pmic_mrfld.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0ce2d8dfc5f1..2adf9d393029 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -572,6 +572,17 @@ config INTEL_SOC_PMIC_CHTDC_TI
Select this option for supporting Dollar Cove (TI version) PMIC
device that is found on some Intel Cherry Trail systems.
+config INTEL_SOC_PMIC_MRFLD
+ tristate "Support for Intel Merrifield Basin Cove PMIC"
+ depends on GPIOLIB
+ depends on ACPI
+ depends on INTEL_SCU_IPC
+ select MFD_CORE
+ select REGMAP_IRQ
+ help
+ Select this option for supporting Basin Cove PMIC device
+ that is found on Intel Merrifield systems.
+
config MFD_INTEL_LPSS
tristate
select COMMON_CLK
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b4569ed7f3f3..1b746bd01ac5 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -234,6 +234,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o
obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o
+obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD) += intel_soc_pmic_mrfld.o
obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
diff --git a/drivers/mfd/intel_soc_pmic_mrfld.c
b/drivers/mfd/intel_soc_pmic_mrfld.c
new file mode 100644
index ..1f21a51f6e26
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_mrfld.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device access for Basin Cove PMIC
+ *
+ * Copyright (c) 2018, Intel Corporation.
+ * Author: Andy Shevchenko
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/*
+ * Level 2 IRQs
+ *
+ * Firmware on the systems with Basin Cove PMIC services Level 1 IRQs
+ * without an assistance. Thus, each of the Level 1 IRQ is represented
+ * as a separate RTE in IOAPIC.
+ */
+static struct resource irq_level2_resources[] = {
+ DEFINE_RES_IRQ(0), /* power button */
+ DEFINE_RES_IRQ(0), /* TMU */
+ DEFINE_RES_IRQ(0), /* thermal */
+ DEFINE_RES_IRQ(0), /* BCU */
+ DEFINE_RES_IRQ(0), /* ADC */
+ DEFINE_RES_IRQ(0), /* charger */
+ DEFINE_RES_IRQ(0), /* GPIO */
+};
+
+static const struct mfd_cell bcove_dev[] = {
+ {
+ .name = "mrfld_bcove_pwrbtn",
+ .num_resources = 1,
+ .resources = &irq_level2_resources[0],
+ }, {
+ .name = "mrfld_bcove_tmu",
+ .num_resources = 1,
+ .resources = &irq_level2_resources[1],
+ }, {
+ .name = "mrfld_bcove_thermal",
+ .num_resources = 1,
+ .resources = &irq_level2_resources[2],
+ }, {
+ .name = "mrfld_bcove_bcu",
+ .num_resources = 1,
+ .resources = &irq_level2_resources[3],
+ }, {
+ .name = "mrfld_bcove_adc",
+ .num_resources = 1,
+ .resources = &irq_level2_resources[4],
+ }, {
+ .name = "mrfld_bcove_charger",
+ .num_resources = 1,
+ .resources = &irq_level2_resources[5],
+ }, {
+ .name = "mrfld_bcove_pwrsrc",
+ .num_resources = 1,
+ .resources = &irq_level2_resources[5],
+ }, {
+ .name = "mrfld_bcove_gpio",
+ .num_resources = 1,
+ .resources = &irq_level2_resources[6],
+ },
+ { .name = "mrfld_bcove_region", },
+};
+
+static int regmap_ipc_byte_reg_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ u8 ipc_out;
+ int ret;
+
+ ret = intel_scu_ipc_ioread8(reg, &ipc_out);
+ if (ret)
+ return ret;
+
+ *val = ipc_out;
+ return 0;
+}
+
+static int regmap_ipc_byte_reg_write(void *context, unsigned int reg,
+unsigned int val)
+{
+ u8 ipc_in = val;
+ int ret;
+
+ ret = intel_scu_ipc_iowrite8(reg, ipc_in);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static const struct regmap_config bcove_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = 0xff,
+ .reg_write = regmap_ipc_byte_reg_wr
Re: [PATCH] KVM: x86: nVMX: allow RSM to restore VMXE CR4 flag
> On 26 Mar 2019, at 15:48, Vitaly Kuznetsov wrote: > > Liran Alon writes: > >>> On 26 Mar 2019, at 15:07, Vitaly Kuznetsov wrote: >>> - Instread of putting the temporary HF_SMM_MASK drop to >>> rsm_enter_protected_mode() (as was suggested by Liran), move it to >>> emulator_set_cr() modifying its interface. emulate.c seems to be >>> vcpu-specifics-free at this moment, we may want to keep it this way. >>> - It seems that Hyper-V+UEFI on KVM is still broken, I'm observing sporadic >>> hangs even with this patch. These hangs, however, seem to be unrelated to >>> rsm. >> >> Feel free to share details on these hangs ;) >> > > You've asked for it) > > The immediate issue I'm observing is some sort of a lockup which is easy > to trigger with e.g. "-usb -device usb-tablet" on Qemu command line; it > seems we get too many interrupts and combined with preemtion timer for > L2 we're not making any progress: > > kvm_userspace_exit: reason KVM_EXIT_IOAPIC_EOI (26) > kvm_set_irq: gsi 18 level 1 source 0 > kvm_msi_set_irq: dst 0 vec 177 (Fixed|physical|level) > kvm_apic_accept_irq: apicid 0 vec 177 (Fixed|edge) > kvm_fpu: load > kvm_entry:vcpu 0 > kvm_exit: reason VMRESUME rip 0xf8848115 info 0 0 > kvm_entry:vcpu 0 > kvm_exit: reason PREEMPTION_TIMER rip 0xf800f4448e01 info 0 0 > kvm_nested_vmexit:rip f800f4448e01 reason PREEMPTION_TIMER info1 0 > info2 0 int_info 0 int_info_err 0 > kvm_nested_vmexit_inject: reason EXTERNAL_INTERRUPT info1 0 info2 0 int_info > 80b1 int_info_err 0 > kvm_entry:vcpu 0 > kvm_exit: reason APIC_ACCESS rip 0xf881fe11 info 10b0 0 > kvm_apic: apic_write APIC_EOI = 0x0 > kvm_eoi: apicid 0 vector 177 > kvm_fpu: unload > kvm_userspace_exit: reason KVM_EXIT_IOAPIC_EOI (26) > ... > (and the pattern repeats) > > Maybe it is a usb-only/Qemu-only problem, maybe not. > > -- > Vitaly The trace of kvm_apic_accept_irq should indicate that __apic_accept_irq() was called to inject an interrupt to L1 guest. (I know that now we are running in L1 because next exit is a VMRESUME). However, it is surprising to see that on next entry to guest, no interrupt was injected by vmx_inject_irq(). It may be because L1 guest is currently running with interrupt disabled and therefore only an IRQ-window was requested. (Too bad we don’t have a trace for this…) Next, we got an exit from L1 guest on VMRESUME. As part of it’s handling, active VMCS was changed from vmcs01 to vmcs02. I believe the immediate exit later on preemption-timer was because the immediate-exit-request mechanism was invoked which is now implemented by setting a VMX preemption-timer with value of 0 (Thanks to Sean). (See vmx_vcpu_run() -> vmx_update_hv_timer() -> vmx_arm_hv_timer(vmx, 0)). (Note that the pending interrupt was evaluated because of a recent patch of mine to nested_vmx_enter_non_root_mode() to request KVM_REQ_EVENT when vmcs01 have requested an IRQ-window) Therefore when entering L2, you immediately get an exit on PREEMPTION_TIMER which will cause eventually L0 to call vmx_check_nested_events() which notices now the pending interrupt that should have been injected before to L1 and now exit from L2 to L1 on EXTERNAL_INTERRUPT on vector 0xb1. Then L1 handles the interrupt by performing an EOI to LAPIC which propagate an EOI to IOAPIC which immediately re-inject the interrupt (after clearing the remote_irr) as the irq-line is still set. i.e. QEMU’s ioapic_eoi_broadcast() calls ioapic_service() immediate after it clears remote-irr for this pin. Also note that in trace we see only a single kvm_set_irq to level 1 but we don’t see immediately another kvm_set_irq to level 0. This should indicate that in QEMU’s IOAPIC redirection-table, this pin is configured as level-triggered interrupt. However, the trace of kvm_apic_accept_irq indicates that this interrupt is raised as an edge-triggered interrupt. To sum up: 1) I would create a patch to add a trace to vcpu_enter_guest() when calling enable_smi_window() / enable_nmi_window() / enable_irq_window(). 2) It is worth investigating why MSI trigger-mode is edge-triggered instead of level-triggered. 3) If this is indeed a level-triggered interrupt, it is worth investigating how the interrupt source behaves. i.e. What cause this device to lower the irq-line? (As we don’t see any I/O Port or MMIO access by L1 guest interrupt-handler before performing the EOI) 4) Does this issue reproduce also when running with kernel-irqchip? (Instead of split-irqchip) -Liran
New feature/ABI review process [was Re: [RESEND PATCH v6 04/12] x86/fsgsbase/64:..]
Andi, On Mon, 25 Mar 2019, Andi Kleen wrote: > >So on user space to kernel space transitions swapping in kernel GS should > >simply do: > > userGS = RDGSBASE() > > WRGSBASE(kernelGS) > > This would also need to find kernelGS first, by doing RDPID and then > reading it from memory in the right index > (which might be a full cache miss if you're unlucky) I'm well aware of that. > SWAPGS will be a lot faster, especially in these rare worst cases > because it has all its state inside the CPU. The well known 'will/might/could/should' word weaseling is not solving anything. If you want to advocate the more complex design of mixed SWAPGS/FSGSBASE then provide numbers and not hand-waving. Numbers of real-world workloads, not numbers of artificial test cases which exercise the rare worst case. Yes, it's extra work and it's well spent. If the numbers are not significantly different then the simpler and consistent design is a clear win. According to the changelog on which I reacted you seem to have investigated that already. Let me cite it again: > Accessing user GSBASE needs a couple of SWAPGS operations. It is > avoidable if the user GSBASE is saved at kernel entry, being updated as > changes, and restored back at kernel exit. However, it seems to spend > more cycles for savings and restorations. Little or no benefit was > measured from experiments. So little or no benefit was measured. I don't see how that maps to your 'SWAPGS will be a lot faster' claim. One of those claims is obviously wrong. Aside of this needs more than numbers: 1) Proper documentation how the mixed bag is managed. 2) Extensive comments explaining the subtle inner workings and caveats. 3) Proper changelogs. You have a track record of not caring much about either of these, but I very much care for good reasons. I've been bitten by glued on and half baked patches from Intel in the past 10 years so many times, that I'm simply refusing to take anything which is not properly structured and documented. Especially not when it is touching sensitive areas like this and also has an impact on the user space ABI. > BTW you managed to only review after Chang went on a long vacation. I'm terribly sorry about that. I'll try to adjust my own schedules and workflow to Intel employees vacation plans in the future. > > I don't understand why it takes that long to review these changes > It's one of the largest performance improvements for the context > switch and the NMI in many years plus gives a new free register > to user space, but it only makes progress at a glacial pace. > The original patches for this were posted in 2016. > Care to look at the real history of this: 11/2015: First patch-set posted by you, which was rejected on technical grounds So this so important feature was in limbo for 20 months until Luto picked it up again. That's surely the fault of the x86 maintainers, right? 07/2017: Discussion about ABI considerations initiated by Andy Lutomirksi. And it takes another 8 month until patches come around: 03/19/2018: V1 from Chang. Reviewed within days 2 month gap caused by Intel: 05/31/2018: V2 Request from Andy to split the set 06/04/2018: Base-V1 The first chunk of changes. 06/06/2018: Base-V2 Slight modifications 06/07/2018: Base-V3 Slight modifications. Review on 08/18 06/20/2018: Base-V4 Review on 06/22 06/27/2018: Base-V5 2 month gap caused by busy maintainers. You know what they were busy with at that time, right? Chasing subtle bugs in the so perfect L1TF patches which were thrown over the fence by you and dealing with the Intel induced speculation crap to have a consistent and maintainable mitigation including proper documentation. 08/23/2018: Base-V5 Resend. Review on 9/14 09/18/2018: Base-V6. Merged 10/08 10/23/2018: Full-V3. Review immediate 10/24/2018: Regression detected caused by Base-V6 The so perfect base patch set caused a regression and it takes more than a month to fix it properly: 10/30/2018: Fix-V1. Broken 10/31/2018: Fix-V2. Broken 11/01/2018: Fix-V3. Broken 11/14/2018: Fix-V4. Broken 11/15/2018: Fix-V5. Broken 11/26/2018: Fix-V6. Finally 2 months to address the Full-V3 feedback: 01/16/2019: Full-V4. Change request 02/01/2019: Full-V5. Review immediate 02/13/2019: Full-V6. 1 month gap caused by busy maintainers. Ash on my main... 03/15/2019: Full-V6 resend So just to put this straight: Out of 40 month since the first post in 11/2015: 20 months nothing happened from Intel side 8 months consumed to produce the next set 1 month to fix a regression 2 months consumed to react on review feedback -- 31 months versus: 2 months maintainers dealing with Intel crap 1 month maintainers being busy The rest is the usual review/re-post ping pong delay which sums up, but from the larger gaps more than 75% are Intel induced and 7% main
Re: [PATCH] phy: qcom: qmp: Add SDM845 PCIe QMP PHY support
On Mon, Feb 25, 2019 at 10:59:19PM -0800, Bjorn Andersson wrote: > qcom_qmp_phy_init() is extended to support the additional register > writes needed in PCS MISC and the appropriate sequences and resources > are defined for SDM845. > > Signed-off-by: Bjorn Andersson > --- > .../devicetree/bindings/phy/qcom-qmp-phy.txt | 7 + Please split bindings. > drivers/phy/qualcomm/phy-qcom-qmp.c | 160 ++ > drivers/phy/qualcomm/phy-qcom-qmp.h | 12 ++ > 3 files changed, 179 insertions(+) > > diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt > b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt > index 5d181fc3cc18..dd2725a9d3f7 100644 > --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt > +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt > @@ -11,6 +11,7 @@ Required properties: > "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, > "qcom,msm8998-qmp-usb3-phy" for USB3 QMP V3 phy on msm8998, > "qcom,msm8998-qmp-ufs-phy" for UFS QMP phy on msm8998, > +"qcom,sdm845-qmp-pcie-phy" for PCIe phy on sdm845, > "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845, > "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845, > "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845. > @@ -48,6 +49,10 @@ Required properties: > "aux", "cfg_ahb", "ref". > For "qcom,msm8998-qmp-ufs-phy" must contain: > "ref", "ref_aux". > + For "qcom,sdm845-qmp-usb3-phy" must contain: > + "aux", "cfg_ahb", "ref", "refgen". > + For "qcom,sdm845-qmp-usb3-phy" must contain: > + "aux", "cfg_ahb", "ref", "com_aux". Copy-n-paste error? > For "qcom,sdm845-qmp-usb3-phy" must contain: > "aux", "cfg_ahb", "ref", "com_aux". > For "qcom,sdm845-qmp-usb3-uni-phy" must contain: > @@ -70,6 +75,8 @@ Required properties: > For "qcom,msm8998-qmp-usb3-phy" must contain > "phy", "common". > For "qcom,msm8998-qmp-ufs-phy": no resets are listed. > + For "qcom,sdm845-qmp-pcie-phy" must contain: > + "phy". > For "qcom,sdm845-qmp-usb3-phy" must contain: > "phy", "common". > For "qcom,sdm845-qmp-usb3-uni-phy" must contain:
Re: Bad file pattern in MAINTAINERS section 'KEYS-TRUSTED'
Hi James, On 03/26/2019 09:25 AM, James Bottomley wrote: Looking at the contents of linux/keys/trusted.h, it looks like the wrong decision to move it. The contents are way too improperly named and duplicative to be in a standard header. It's mostly actually TPM code including a redefinition of the tpm_buf structure, so it doesn't even seem to be necessary for trusted keys. The reason this was done was because asym_tpm.c needed a bunch of the same functionality already provided by trusted.c, e.g. TSS_authmac and friends. If you want to fix this as a bug, I'd move it back again, but long term I think it should simply be combined with trusted.c because nothing else can include it sanely anyway. Ideally I'd like to see the TPM subsystem expose these functions using some proper API / library abstraction. David Howells had an RFC patch set that tried to address some of this a while back. Not sure if that went anywhere. Regards, -Denis
Re: [PATCH 1/2] dt-bindings: extcon: Add support for fsa9480 switch
On Mon, Feb 25, 2019 at 05:58:21PM +0100, Paweł Chmiel wrote:
> From: Tomasz Figa
>
> This patch adds documentation for binding of extcont Fairchild
> Semiconductor FSA9480 microusb switch.
> This usb port accessory detector and switch, can be found for example in
> some Samsung s5pv210 based phones.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Paweł Chmiel
> ---
> .../bindings/extcon/extcon-fsa9480.txt| 21 +++
> 1 file changed, 21 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
> b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
> new file mode 100644
> index ..ebced7b18eb5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
> @@ -0,0 +1,21 @@
> +FAIRCHILD SEMICONDUCTOR FSA9480 MICROUSB SWITCH
> +
> +The FSA9480 is a USB port accessory detector and switch. The FSA9480 is fully
> +controlled using I2C and enables USB data, stereo and mono audio, video,
> +microphone, and UART data to use a common connector port.
> +
> +Required properties:
> + - compatible : Must be "fcs,fsa9480"
> + - reg : Specifies i2c slave address. Must be 0x25.
> + - interrupt-parent : Phandle to interrupt controller to which interrupt
> + signal of the chip is connected.
Remove this as it is implicit.
> + - interrupts : Should contain one entry specifying interrupt signal of
> + interrupt parent to which interrupt pin of the chip is connected.
> +
> + Example:
> + musb@25 {
> + compatible = "fcs,fsa9480";
> + reg = <0x25>;
> + interrupt-parent = <&gph2>;
> + interrupts = <7 0>;
> + };
> \ No newline at end of file
Fix this.
> --
> 2.17.1
>
Re: [PATCH 0/4] clk/ARM: exynos: Add ADC to Exynos5410 (Odroid XU)
On 2/12/19 18:50, Krzysztof Kozlowski wrote: > The DTS patch depends on bindings header with clock ID. I will take it > through samsung-soc for consecutive release. > Krzysztof Kozlowski (4): > dt-bindings: clock: exynos: Put CLK_UART3 in order > dt-bindings: clock: exynos: Add ADC clock ID to Exynos5410 > clk: samsung: exynos5410: Add gate clock for ADC > ARM: dts: exynos: Add ADC node to Exynos5410 and Odroid XU I have applied first 3 patches to clk/samsung tree, thanks! With prefix in summary line of the first 2 commits changed to "clk: samsung: dt-bindings:". -- Regards Sylwester
[PATCH net-next v3 1/2] net: phy: marvell10g: implement suspend/resume callbacks
This patch adds the suspend/resume callbacks for Marvell 10G PHYs. The
three PCS (base-t, base-r and 1000base-x) are set in low power (the PCS
are powered down) when the PHY isn't used.
Signed-off-by: Antoine Tenart
Reviewed-by: Andrew Lunn
---
drivers/net/phy/marvell10g.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 100b401b1f4a..b56cd35182d5 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -226,11 +226,25 @@ static int mv3310_probe(struct phy_device *phydev)
static int mv3310_suspend(struct phy_device *phydev)
{
+ phy_modify_mmd(phydev, MDIO_MMD_PCS, MV_PCS_BASE_T + MDIO_CTRL1,
+ MDIO_CTRL1_LPOWER, MDIO_CTRL1_LPOWER);
+ phy_modify_mmd(phydev, MDIO_MMD_PCS, MV_PCS_BASE_R + MDIO_CTRL1,
+ MDIO_CTRL1_LPOWER, MDIO_CTRL1_LPOWER);
+ phy_modify_mmd(phydev, MDIO_MMD_PCS, MV_PCS_1000BASEX + MDIO_CTRL1,
+ MDIO_CTRL1_LPOWER, MDIO_CTRL1_LPOWER);
+
return 0;
}
static int mv3310_resume(struct phy_device *phydev)
{
+ phy_modify_mmd(phydev, MDIO_MMD_PCS, MV_PCS_BASE_T + MDIO_CTRL1,
+ MDIO_CTRL1_LPOWER, 0);
+ phy_modify_mmd(phydev, MDIO_MMD_PCS, MV_PCS_BASE_R + MDIO_CTRL1,
+ MDIO_CTRL1_LPOWER, 0);
+ phy_modify_mmd(phydev, MDIO_MMD_PCS, MV_PCS_1000BASEX + MDIO_CTRL1,
+ MDIO_CTRL1_LPOWER, 0);
+
return mv3310_hwmon_config(phydev, true);
}
--
2.20.1
[PATCH net-next v3 2/2] net: phy: marvell10g: add the suspend/resume callbacks for the 88x2210
When the 88x2110 PHY support was added, the suspend and resume callbacks
were forgotten. This patch adds them to the 88x2110 PHY callback
definition.
Signed-off-by: Antoine Tenart
Reviewed-by: Andrew Lunn
---
drivers/net/phy/marvell10g.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index b56cd35182d5..08dd2ea08236 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -488,6 +488,8 @@ static struct phy_driver mv3310_drivers[] = {
.name = "mv88x2110",
.get_features = genphy_c45_pma_read_abilities,
.probe = mv3310_probe,
+ .suspend= mv3310_suspend,
+ .resume = mv3310_resume,
.soft_reset = genphy_no_soft_reset,
.config_init= mv3310_config_init,
.config_aneg= mv3310_config_aneg,
--
2.20.1
Re: [PATCH v19,RESEND 16/27] x86/sgx: Add the Linux SGX Enclave Driver
On Tue, Mar 26, 2019 at 01:40:57PM +0100, Thomas Gleixner wrote: > On Tue, 26 Mar 2019, Huang, Kai wrote: > > On Wed, 2019-03-20 at 18:21 +0200, Jarkko Sakkinen wrote: > > > 13 files changed, 1657 insertions(+), 2 deletions(-) > > > create mode 100644 arch/x86/include/uapi/asm/sgx.h > > > create mode 100644 arch/x86/kernel/cpu/sgx/driver/Makefile > > > create mode 100644 arch/x86/kernel/cpu/sgx/driver/driver.h > > > create mode 100644 arch/x86/kernel/cpu/sgx/driver/ioctl.c > > > create mode 100644 arch/x86/kernel/cpu/sgx/driver/main.c > > > create mode 100644 arch/x86/kernel/cpu/sgx/encl.c > > > create mode 100644 arch/x86/kernel/cpu/sgx/encl.h > > > > Shouldn't the driver be located somewhere under drivers/, but not under > > arch/x86? > > > > I don't think x86 maintainers should have the burden to review every code > > change made to SGX driver? > > I rather prefer to have it in x86. Why? Because driver code has a tendency > to get under the radar. And having everything under arch/x86 will likely reduce the maintenance burden for everyone: - Doesn't require taking changes through multiple trees or coordinating acks from multiple maintainers. - Significantly reduces the number of functions, macros, structs and variables that needs to be exposed in asm/sgx.h (actually eliminates it entirely at this point) which allows for sane code organization as opposed to dumping everything in one big header. - Mostly avoids bikeshedding over whether something is architectural or belongs in the so called driver.
Re: [RFC PATCH v2 1/1] mm/vmap: keep track of free blocks for vmap allocation
Hello, Roman.
> >
> > So, does it mean that this function always returns two following elements?
> > Can't it return a single element using the return statement instead?
> > The second one can be calculated as ->next?
> >
> Yes, they follow each other and if you return "prev" for example you can
> easily
> refer to next. But you will need to access "next" anyway. I would rather keep
> implementation, because it strictly clear what it return when you look at this
> function.
>
> But if there are some objections and we can simplify, let's discuss :)
>
> > > + }
> > > + } else {
> > > + /*
> > > + * The red-black tree where we try to find VA neighbors
> > > + * before merging or inserting is empty, i.e. it means
> > > + * there is no free vmap space. Normally it does not
> > > + * happen but we handle this case anyway.
> > > + */
> > > + *prev = *next = &free_vmap_area_list;
> >
> > And for example, return NULL in this case.
> >
> Then we will need to check in the __merge_or_add_vmap_area() that
> next/prev are not NULL and not head. But i do not like current implementation
> as well, since it is hardcoded to specific list head.
>
Like you said, it is more clever to return only one element, for example next.
After that just simply access to the previous one. If nothing is found return
NULL.
static inline struct list_head *
__get_va_next_sibling(struct rb_node *parent, struct rb_node **link)
{
struct list_head *list;
if (likely(parent)) {
list = &rb_entry(parent, struct vmap_area, rb_node)->list;
return (&parent->rb_right == link ? list->next:list);
}
/*
* The red-black tree where we try to find VA neighbors
* before merging or inserting is empty, i.e. it means
* there is no free vmap space. Normally it does not
* happen but we handle this case anyway.
*/
return NULL;
}
...
static inline void
__merge_or_add_vmap_area(struct vmap_area *va,
struct rb_root *root, struct list_head *head)
{
...
/*
* Get next node of VA to check if merging can be done.
*/
next = __get_va_next_sibling(parent, link);
if (unlikely(next == NULL))
goto insert;
...
}
Agree with your point and comment.
Thanks!
--
Vlad Rezki
Re: [PATCH -tip v3 04/10] x86/kprobes: Prohibit probing on IRQ handlers directly
On Mon, 25 Mar 2019 17:23:34 -0400
Steven Rostedt wrote:
> On Wed, 13 Feb 2019 01:12:44 +0900
> Masami Hiramatsu wrote:
>
> > Prohibit probing on IRQ handlers in irqentry_text because
> > if it interrupts user mode, at that point we haven't changed
> > to kernel space yet and which eventually leads a double fault.
> > E.g.
> >
> > # echo p apic_timer_interrupt > kprobe_events
>
> Hmm, this breaks one of my tests (which I probe on do_IRQ).
OK, it seems this patch is a bit redundant, because
I found that these interrupt handler issue has been fixed
by Andrea's commit before merge this patch.
commit a50480cb6d61d5c5fc13308479407b628b6bc1c5
Author: Andrea Righi
Date: Thu Dec 6 10:56:48 2018 +0100
kprobes/x86: Blacklist non-attachable interrupt functions
These interrupt functions are already non-attachable by kprobes.
Blacklist them explicitly so that they can show up in
/sys/kernel/debug/kprobes/blacklist and tools like BCC can use this
additional information.
This description is a bit odd (maybe his patch is after mine?) I think
while updating this series, the patches were merged out of order.
Anyway, with above patch, the core problematic probe points are blacklisted.
>
> It's been working for years.
>
>
> > # echo 1 > events/kprobes/enable
> > PANIC: double fault, error_code: 0x0
> > CPU: 1 PID: 814 Comm: less Not tainted 4.20.0-rc3+ #30
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
> > RIP: 0010:error_entry+0x12/0xf0
> > [snip]
> > Call Trace:
> >
> > ? native_iret+0x7/0x7
> > ? async_page_fault+0x8/0x30
> > ? trace_hardirqs_on_thunk+0x1c/0x1c
> > ? error_entry+0x7c/0xf0
> > ? async_page_fault+0x8/0x30
> > ? native_iret+0x7/0x7
> > ? int3+0xa/0x20
> > ? trace_hardirqs_on_thunk+0x1c/0x1c
> > ? error_entry+0x7c/0xf0
> > ? int3+0xa/0x20
> > ? apic_timer_interrupt+0x1/0x20
> >
> > Kernel panic - not syncing: Machine halted.
> > Kernel Offset: disabled
>
> I'm not able to reproduce this (by removing this commit).
I ensured that if I revert both of this patch and Andrea's patch,
I can reproduce this with probing on apic_timer_interrupt().
> I'm thinking something else may have changed, as I've been tracing
> interrupt entries for years, and interrupting userspace while doing
> this.
>
> I've even added probes where ftrace isn't (where it uses an int3) and
> still haven't hit a problem.
>
> I think this patch is swatting a symptom of a bug and not addressing
> the bug itself. Can you send me the config that triggers this?
Yes, it seems you're right. Andrea's commit specifically fixed the
issue and mine is redundant. (I'm not sure why do_IRQ is in
__irqentry_text...)
So, Ingo, please revert this, since this bug already has been fixed by
commit a50480cb6d61 ("kprobes: x86_64: blacklist non-attachable interrupt
functions")
BTW, for further error investigation, I attached my kconfig which is
usually I'm testing (some options can be changed) on Qemu.
I'm using my mini-container shellscript ( https://github.com/mhiramat/mincs
) which supports qemu-container.
Thank you,
--
Masami Hiramatsu
.config
Description: Binary data
Re: [PATCH] spi: tegra20-slink: change chip select action order
On Tue, Mar 26, 2019 at 03:30:50PM +0100, Randolph Maaßen wrote:
> To transfer via SPI the tegra20-slink driver first sets the command
> register, which contains the chip select value, and after that the
> command2 register, which contains the chip select line. This leads to a
> small spike in the chip selct 0 line between the set of the value and
> the selection of the chip select line.
>
> This commit changes the order of the register writes so that first the
> chip select line is chosen and then the value is set, removing the
> spike.
>
> Signed-off-by: Randolph Maaßen
> ---
> drivers/spi/spi-tegra20-slink.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
Looks good to me. Adding Sowjanya who has been looking into SPI
recently.
Thierry
> diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
> index 1427f343b39a..6d4679126213 100644
> --- a/drivers/spi/spi-tegra20-slink.c
> +++ b/drivers/spi/spi-tegra20-slink.c
> @@ -717,9 +717,6 @@ static int tegra_slink_start_transfer_one(struct
> spi_device *spi,
> command2 = tspi->command2_reg;
> command2 &= ~(SLINK_RXEN | SLINK_TXEN);
>
> - tegra_slink_writel(tspi, command, SLINK_COMMAND);
> - tspi->command_reg = command;
> -
> tspi->cur_direction = 0;
> if (t->rx_buf) {
> command2 |= SLINK_RXEN;
> @@ -729,9 +726,18 @@ static int tegra_slink_start_transfer_one(struct
> spi_device *spi,
> command2 |= SLINK_TXEN;
> tspi->cur_direction |= DATA_DIR_TX;
> }
> +
> + /*
> + * Writing to the command2 register bevore the command register prevents
> + * a spike in chip_select line 0. This selects the chip_select line
> + * before changing the chip_select value.
> + */
> tegra_slink_writel(tspi, command2, SLINK_COMMAND2);
> tspi->command2_reg = command2;
>
> + tegra_slink_writel(tspi, command, SLINK_COMMAND);
> + tspi->command_reg = command;
> +
> if (total_fifo_words > SLINK_FIFO_DEPTH)
> ret = tegra_slink_start_dma_based_transfer(tspi, t);
> else
> --
> 2.11.0
>
signature.asc
Description: PGP signature
Applied "ASoC: add fsl_audmix DT binding documentation" to the asoc tree
The patch
ASoC: add fsl_audmix DT binding documentation
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d0d9071b724123ebde89bdf6b52b86c3289abe85 Mon Sep 17 00:00:00 2001
From: Viorel Suman
Date: Tue, 22 Jan 2019 11:14:27 +
Subject: [PATCH] ASoC: add fsl_audmix DT binding documentation
Add the DT binding documentation for NXP Audio Mixer
CPU DAI driver.
Signed-off-by: Viorel Suman
Signed-off-by: Mark Brown
---
.../devicetree/bindings/sound/fsl,audmix.txt | 54 +++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,audmix.txt
diff --git a/Documentation/devicetree/bindings/sound/fsl,audmix.txt
b/Documentation/devicetree/bindings/sound/fsl,audmix.txt
new file mode 100644
index ..45f807ec21a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,audmix.txt
@@ -0,0 +1,54 @@
+NXP Audio Mixer (AUDMIX).
+
+The Audio Mixer is a on-chip functional module that allows mixing of two
+audio streams into a single audio stream. Audio Mixer has two input serial
+audio interfaces. These are driven by two Synchronous Audio interface
+modules (SAI). Each input serial interface carries 8 audio channels in its
+frame in TDM manner. Mixer mixes audio samples of corresponding channels
+from two interfaces into a single sample. Before mixing, audio samples of
+two inputs can be attenuated based on configuration. The output of the
+Audio Mixer is also a serial audio interface. Like input interfaces it has
+the same TDM frame format. This output is used to drive the serial DAC TDM
+interface of audio codec and also sent to the external pins along with the
+receive path of normal audio SAI module for readback by the CPU.
+
+The output of Audio Mixer can be selected from any of the three streams
+ - serial audio input 1
+ - serial audio input 2
+ - mixed audio
+
+Mixing operation is independent of audio sample rate but the two audio
+input streams must have same audio sample rate with same number of channels
+in TDM frame to be eligible for mixing.
+
+Device driver required properties:
+=
+ - compatible : Compatible list, contains "fsl,imx8qm-audmix"
+
+ - reg: Offset and length of the register set for the
device.
+
+ - clocks : Must contain an entry for each entry in clock-names.
+
+ - clock-names: Must include the "ipg" for register access.
+
+ - power-domains : Must contain the phandle to AUDMIX power domain node
+
+ - dais : Must contain a list of phandles to AUDMIX connected
+ DAIs. The current implementation requires two phandles
+ to SAI interfaces to be provided, the first SAI in the
+ list being used to route the AUDMIX output.
+
+ - model : Must contain machine driver name which will configure
+ and instantiate the appropriate audio card.
+
+Device driver configuration example:
+==
+ audmix: audmix@5984 {
+compatible = "fsl,imx8qm-audmix";
+reg = <0x0 0x5984 0x0 0x1>;
+clocks = <&clk IMX8QXP_AUD_AUDMIX_IPG>;
+clock-names = "ipg";
+power-domains = <&pd_audmix>;
+dais = <&sai4>, <&sai5>;
+model = "imx-audmix";
+ };
--
2.20.1
[PATCH v6 1/1] gpio: add driver for Mellanox BlueField GPIO controller
This patch adds support for the GPIO controller used by Mellanox
BlueField SOCs.
Reviewed-by: David Woods
Signed-off-by: Shravan Kumar Ramani
---
drivers/gpio/Kconfig | 7 +++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-mlxbf.c | 153 ++
3 files changed, 161 insertions(+)
create mode 100644 drivers/gpio/gpio-mlxbf.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 3f50526..0d9ddff 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1316,6 +1316,13 @@ config GPIO_MERRIFIELD
help
Say Y here to support Intel Merrifield GPIO.
+config GPIO_MLXBF
+ tristate "Mellanox BlueField SoC GPIO"
+ depends on (MELLANOX_PLATFORM && ARM64 && ACPI) || COMPILE_TEST
+ select GPIO_GENERIC
+ help
+ Say Y here if you want GPIO support on Mellanox BlueField SoC.
+
config GPIO_ML_IOH
tristate "OKI SEMICONDUCTOR ML7213 IOH GPIO support"
depends on X86 || COMPILE_TEST
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 54d5527..db8d854 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_GPIO_MENZ127)+= gpio-menz127.o
obj-$(CONFIG_GPIO_MERRIFIELD) += gpio-merrifield.o
obj-$(CONFIG_GPIO_MC33880) += gpio-mc33880.o
obj-$(CONFIG_GPIO_MC9S08DZ60) += gpio-mc9s08dz60.o
+obj-$(CONFIG_GPIO_MLXBF) += gpio-mlxbf.o
obj-$(CONFIG_GPIO_ML_IOH) += gpio-ml-ioh.o
obj-$(CONFIG_GPIO_MM_LANTIQ) += gpio-mm-lantiq.o
obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o
diff --git a/drivers/gpio/gpio-mlxbf.c b/drivers/gpio/gpio-mlxbf.c
new file mode 100644
index 000..d428f42
--- /dev/null
+++ b/drivers/gpio/gpio-mlxbf.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Number of pins on BlueField */
+#define MLXBF_GPIO_NR 54
+
+/* Pad Electrical Controls. */
+#define MLXBF_GPIO_PAD_CONTROL_FIRST_WORD 0x0700
+#define MLXBF_GPIO_PAD_CONTROL_1_FIRST_WORD 0x0708
+#define MLXBF_GPIO_PAD_CONTROL_2_FIRST_WORD 0x0710
+#define MLXBF_GPIO_PAD_CONTROL_3_FIRST_WORD 0x0718
+
+#define MLXBF_GPIO_PIN_DIR_I 0x1040
+#define MLXBF_GPIO_PIN_DIR_O 0x1048
+#define MLXBF_GPIO_PIN_STATE 0x1000
+#define MLXBF_GPIO_SCRATCHPAD 0x20
+
+#ifdef CONFIG_PM
+struct mlxbf_gpio_context_save_regs {
+ u64 scratchpad;
+ u64 pad_control[MLXBF_GPIO_NR];
+ u64 pin_dir_i;
+ u64 pin_dir_o;
+};
+#endif
+
+/* Device state structure. */
+struct mlxbf_gpio_state {
+ struct gpio_chip gc;
+
+ /* Memory Address */
+ void __iomem *base;
+
+#ifdef CONFIG_PM
+ struct mlxbf_gpio_context_save_regs csave_regs;
+#endif
+};
+
+static int mlxbf_gpio_probe(struct platform_device *pdev)
+{
+ struct mlxbf_gpio_state *gs;
+ struct device *dev = &pdev->dev;
+ struct gpio_chip *gc;
+ int ret;
+
+ gs = devm_kzalloc(&pdev->dev, sizeof(*gs), GFP_KERNEL);
+ if (!gs)
+ return -ENOMEM;
+
+ gs->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(gs->base))
+ return PTR_ERR(gs->base);
+
+ gc = &gs->gc;
+ ret = bgpio_init(gc, dev, 8,
+gs->base + MLXBF_GPIO_PIN_STATE,
+NULL,
+NULL,
+gs->base + MLXBF_GPIO_PIN_DIR_O,
+gs->base + MLXBF_GPIO_PIN_DIR_I,
+0);
+ if (ret)
+ return -ENODEV;
+
+ gc->owner = THIS_MODULE;
+ gc->ngpio = MLXBF_GPIO_NR;
+
+ ret = devm_gpiochip_add_data(dev, &gs->gc, gs);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed adding memory mapped gpiochip\n");
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, gs);
+ dev_info(&pdev->dev, "registered Mellanox BlueField GPIO");
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int mlxbf_gpio_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct mlxbf_gpio_state *gs = platform_get_drvdata(pdev);
+
+ gs->csave_regs.scratchpad = readq(gs->base + MLXBF_GPIO_SCRATCHPAD);
+ gs->csave_regs.pad_control[0] =
+ readq(gs->base + MLXBF_GPIO_PAD_CONTROL_FIRST_WORD);
+ gs->csave_regs.pad_control[1] =
+ readq(gs->base + MLXBF_GPIO_PAD_CONTROL_1_FIRST_WORD);
+ gs->csave_regs.pad_control[2] =
+ readq(gs->base + MLXBF_GPIO_PAD_CONTROL_2_FIRST_WORD);
+ gs->csave_regs.pad_control[3] =
+ readq(gs->base + MLXBF_GPIO_PAD_CONTROL_3_FIRST_WORD);
+ gs->csave_regs.pin_dir_i = readq(gs->base + MLXBF_GPIO_PIN_DIR_I);
+ gs->csave_regs.pin_dir_o = readq(gs->base + MLXBF_GPIO_PIN_DIR_O);
+
+ return 0;
+}
+
+static int mlxbf_gpio_resume(struct platform_device *pdev)
+{
+ struct mlxbf_gpio_state *gs = platform_get_drvdata(pdev);
+
Applied "regulator: act8865: Convert to regulator core's simplified DT parsing code" to the regulator tree
The patch
regulator: act8865: Convert to regulator core's simplified DT parsing code
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 253c9c79adbcf79350cb1ae1c801f8df00186455 Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Fri, 22 Mar 2019 14:38:19 +0800
Subject: [PATCH] regulator: act8865: Convert to regulator core's simplified DT
parsing code
Use regulator core's simplified DT parsing code to simply the driver
implementation. With this conversion, also move the NULL test against pdata
in act8865_get_regulator_data() to the caller. This makes it clear the
code path to explicitly set init_data is for non-DT case only.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/act8865-regulator.c | 143 --
1 file changed, 19 insertions(+), 124 deletions(-)
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index e0239cf3f56d..af8f201e67d7 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -245,6 +245,8 @@ static struct regulator_ops act8865_ldo_ops = {
#define ACT88xx_REG(_name, _family, _id, _vsel_reg, _supply) \
[_family##_ID_##_id] = {\
.name = _name,\
+ .of_match = of_match_ptr(_name), \
+ .regulators_node= of_match_ptr("regulators"), \
.supply_name= _supply, \
.id = _family##_ID_##_id, \
.type = REGULATOR_VOLTAGE,\
@@ -265,6 +267,8 @@ static const struct regulator_desc act8600_regulators[] = {
ACT88xx_REG("DCDC3", ACT8600, DCDC3, VSET, "vp3"),
{
.name = "SUDCDC_REG4",
+ .of_match = of_match_ptr("SUDCDC_REG4"),
+ .regulators_node = of_match_ptr("regulators"),
.id = ACT8600_ID_SUDCDC4,
.ops = &act8865_ops,
.type = REGULATOR_VOLTAGE,
@@ -283,6 +287,8 @@ static const struct regulator_desc act8600_regulators[] = {
ACT88xx_REG("LDO8", ACT8600, LDO8, VSET, "inl"),
{
.name = "LDO_REG9",
+ .of_match = of_match_ptr("LDO_REG9"),
+ .regulators_node = of_match_ptr("regulators"),
.id = ACT8600_ID_LDO9,
.ops = &act8865_ldo_ops,
.type = REGULATOR_VOLTAGE,
@@ -294,6 +300,8 @@ static const struct regulator_desc act8600_regulators[] = {
},
{
.name = "LDO_REG10",
+ .of_match = of_match_ptr("LDO_REG10"),
+ .regulators_node = of_match_ptr("regulators"),
.id = ACT8600_ID_LDO10,
.ops = &act8865_ldo_ops,
.type = REGULATOR_VOLTAGE,
@@ -348,110 +356,6 @@ static const struct of_device_id act8865_dt_ids[] = {
{ }
};
MODULE_DEVICE_TABLE(of, act8865_dt_ids);
-
-static struct of_regulator_match act8846_matches[] = {
- [ACT8846_ID_REG1] = { .name = "REG1" },
- [ACT8846_ID_REG2] = { .name = "REG2" },
- [ACT8846_ID_REG3] = { .name = "REG3" },
- [ACT8846_ID_REG4] = { .name = "REG4" },
- [ACT8846_ID_REG5] = { .name = "REG5" },
- [ACT8846_ID_REG6] = { .name = "REG6" },
- [ACT8846_ID_REG7] = { .name = "REG7" },
- [ACT8846_ID_REG8] = { .name = "REG8" },
- [ACT8846_ID_REG9] = { .name = "REG9" },
- [ACT8846_ID_REG10] = { .name = "REG10" },
- [ACT8846_ID_REG11] = { .name = "REG11" },
- [ACT8846_ID_REG12] = { .name = "REG12" },
-};
-
-static struct of_regulator_match act8865_matches[] = {
- [ACT8865_ID_DCDC1] = { .name = "DCDC_REG1"},
- [ACT8865_ID_DCDC2] = { .name = "DCDC_REG2"},
- [ACT8865_ID_DCDC3] = { .name = "DCDC_REG3"},
- [ACT8865_ID_LDO1] = { .name = "LDO_REG1"},
- [ACT8865_ID_LDO2] = { .name = "LDO_REG2"},
- [ACT8865_ID_LDO3] = { .n
Applied "regulator: act8865: Constify regulator_ops" to the regulator tree
The patch
regulator: act8865: Constify regulator_ops
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7cae255d2757eb085736be082df3ef4140846bc9 Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Fri, 22 Mar 2019 14:38:20 +0800
Subject: [PATCH] regulator: act8865: Constify regulator_ops
The act8865_ops and act8865_ldo_ops never need to be modified,
make them const so compiler can put them to .rodata.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/act8865-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index af8f201e67d7..19d9ee2dac1f 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -226,7 +226,7 @@ static const struct regulator_linear_range
act8600_sudcdc_voltage_ranges[] = {
REGULATOR_LINEAR_RANGE(4140, 248, 255, 0),
};
-static struct regulator_ops act8865_ops = {
+static const struct regulator_ops act8865_ops = {
.list_voltage = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
@@ -236,7 +236,7 @@ static struct regulator_ops act8865_ops = {
.is_enabled = regulator_is_enabled_regmap,
};
-static struct regulator_ops act8865_ldo_ops = {
+static const struct regulator_ops act8865_ldo_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
--
2.20.1
Applied "spi: stm32-qspi: add spi_master_put in release function" to the spi tree
The patch
spi: stm32-qspi: add spi_master_put in release function
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a88eceb17ac7e8dc4ad9995681af61c8371668f4 Mon Sep 17 00:00:00 2001
From: Ludovic Barre
Date: Mon, 25 Mar 2019 18:01:39 +0100
Subject: [PATCH] spi: stm32-qspi: add spi_master_put in release function
This patch adds spi_master_put in release function
to drop the controller's refcount.
Signed-off-by: Ludovic Barre
Signed-off-by: Mark Brown
---
drivers/spi/spi-stm32-qspi.c | 46 ++--
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index 7879a523583c..9875139ef0cf 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -93,6 +93,7 @@ struct stm32_qspi_flash {
struct stm32_qspi {
struct device *dev;
+ struct spi_controller *ctrl;
void __iomem *io_base;
void __iomem *mm_base;
resource_size_t mm_size;
@@ -400,6 +401,7 @@ static void stm32_qspi_release(struct stm32_qspi *qspi)
writel_relaxed(0, qspi->io_base + QSPI_CR);
mutex_destroy(&qspi->lock);
clk_disable_unprepare(qspi->clk);
+ spi_master_put(qspi->ctrl);
}
static int stm32_qspi_probe(struct platform_device *pdev)
@@ -416,43 +418,54 @@ static int stm32_qspi_probe(struct platform_device *pdev)
return -ENOMEM;
qspi = spi_controller_get_devdata(ctrl);
+ qspi->ctrl = ctrl;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "qspi");
qspi->io_base = devm_ioremap_resource(dev, res);
- if (IS_ERR(qspi->io_base))
- return PTR_ERR(qspi->io_base);
+ if (IS_ERR(qspi->io_base)) {
+ ret = PTR_ERR(qspi->io_base);
+ goto err;
+ }
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "qspi_mm");
qspi->mm_base = devm_ioremap_resource(dev, res);
- if (IS_ERR(qspi->mm_base))
- return PTR_ERR(qspi->mm_base);
+ if (IS_ERR(qspi->mm_base)) {
+ ret = PTR_ERR(qspi->mm_base);
+ goto err;
+ }
qspi->mm_size = resource_size(res);
- if (qspi->mm_size > STM32_QSPI_MAX_MMAP_SZ)
- return -EINVAL;
+ if (qspi->mm_size > STM32_QSPI_MAX_MMAP_SZ) {
+ ret = -EINVAL;
+ goto err;
+ }
irq = platform_get_irq(pdev, 0);
ret = devm_request_irq(dev, irq, stm32_qspi_irq, 0,
dev_name(dev), qspi);
if (ret) {
dev_err(dev, "failed to request irq\n");
- return ret;
+ goto err;
}
init_completion(&qspi->data_completion);
qspi->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(qspi->clk))
- return PTR_ERR(qspi->clk);
+ if (IS_ERR(qspi->clk)) {
+ ret = PTR_ERR(qspi->clk);
+ goto err;
+ }
qspi->clk_rate = clk_get_rate(qspi->clk);
- if (!qspi->clk_rate)
- return -EINVAL;
+ if (!qspi->clk_rate) {
+ ret = -EINVAL;
+ goto err;
+ }
ret = clk_prepare_enable(qspi->clk);
if (ret) {
dev_err(dev, "can not enable the clock\n");
- return ret;
+ goto err;
}
rstc = devm_reset_control_get_exclusive(dev, NULL);
@@ -475,14 +488,11 @@ static int stm32_qspi_probe(struct platform_device *pdev)
ctrl->dev.of_node = dev->of_node;
ret = devm_spi_register_master(dev, ctrl);
- if (ret)
- goto err_spi_register;
-
- return 0;
+ if (!ret)
+ return 0;
-err_spi_register:
+err:
stm32_qspi_release(qspi);
-
return ret;
}
--
2.20.1
Applied "spi: stm32-qspi: add dma support" to the spi tree
The patch
spi: stm32-qspi: add dma support
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 245308c6217027c0d7fc8c3cf2bf95858c704d7b Mon Sep 17 00:00:00 2001
From: Ludovic Barre
Date: Mon, 25 Mar 2019 18:01:40 +0100
Subject: [PATCH] spi: stm32-qspi: add dma support
This patch adds the dma support for the stm32-qspi hardware.
The memory buffer constraints (lowmem, vmalloc, kmap) are taken into
account by framework. In read mode, the memory map is preferred vs
dma (due to better throughput). If the dma transfer fails the buffer
is sent by polling.
Signed-off-by: Ludovic Barre
Signed-off-by: Mark Brown
---
drivers/spi/spi-stm32-qspi.c | 136 ++-
1 file changed, 135 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index 9875139ef0cf..11a89aa15d56 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -5,6 +5,8 @@
*/
#include
#include
+#include
+#include
#include
#include
#include
@@ -84,6 +86,7 @@
#define STM32_FIFO_TIMEOUT_US 3
#define STM32_BUSY_TIMEOUT_US 10
#define STM32_ABT_TIMEOUT_US 10
+#define STM32_COMP_TIMEOUT_MS 1000
struct stm32_qspi_flash {
struct stm32_qspi *qspi;
@@ -94,6 +97,7 @@ struct stm32_qspi_flash {
struct stm32_qspi {
struct device *dev;
struct spi_controller *ctrl;
+ phys_addr_t phys_base;
void __iomem *io_base;
void __iomem *mm_base;
resource_size_t mm_size;
@@ -103,6 +107,10 @@ struct stm32_qspi {
struct completion data_completion;
u32 fmode;
+ struct dma_chan *dma_chtx;
+ struct dma_chan *dma_chrx;
+ struct completion dma_completion;
+
u32 cr_reg;
u32 dcr_reg;
@@ -181,6 +189,81 @@ static int stm32_qspi_tx_mm(struct stm32_qspi *qspi,
return 0;
}
+static void stm32_qspi_dma_callback(void *arg)
+{
+ struct completion *dma_completion = arg;
+
+ complete(dma_completion);
+}
+
+static int stm32_qspi_tx_dma(struct stm32_qspi *qspi,
+const struct spi_mem_op *op)
+{
+ struct dma_async_tx_descriptor *desc;
+ enum dma_transfer_direction dma_dir;
+ struct dma_chan *dma_ch;
+ struct sg_table sgt;
+ dma_cookie_t cookie;
+ u32 cr, t_out;
+ int err;
+
+ if (op->data.dir == SPI_MEM_DATA_IN) {
+ dma_dir = DMA_DEV_TO_MEM;
+ dma_ch = qspi->dma_chrx;
+ } else {
+ dma_dir = DMA_MEM_TO_DEV;
+ dma_ch = qspi->dma_chtx;
+ }
+
+ /*
+* spi_map_buf return -EINVAL if the buffer is not DMA-able
+* (DMA-able: in vmalloc | kmap | virt_addr_valid)
+*/
+ err = spi_controller_dma_map_mem_op_data(qspi->ctrl, op, &sgt);
+ if (err)
+ return err;
+
+ desc = dmaengine_prep_slave_sg(dma_ch, sgt.sgl, sgt.nents,
+ dma_dir, DMA_PREP_INTERRUPT);
+ if (!desc) {
+ err = -ENOMEM;
+ goto out_unmap;
+ }
+
+ cr = readl_relaxed(qspi->io_base + QSPI_CR);
+
+ reinit_completion(&qspi->dma_completion);
+ desc->callback = stm32_qspi_dma_callback;
+ desc->callback_param = &qspi->dma_completion;
+ cookie = dmaengine_submit(desc);
+ err = dma_submit_error(cookie);
+ if (err)
+ goto out;
+
+ dma_async_issue_pending(dma_ch);
+
+ writel_relaxed(cr | CR_DMAEN, qspi->io_base + QSPI_CR);
+
+ t_out = sgt.nents * STM32_COMP_TIMEOUT_MS;
+ if (!wait_for_completion_interruptible_timeout(&qspi->dma_completion,
+ msecs_to_jiffies(t_out)))
+ err = -ETIMEDOUT;
+
+ if (dma_async_is_tx_complete(dma_ch, cookie,
+NULL, NULL) != DMA_COMPLETE)
+ err = -ETIMEDOUT;
+
+ if (err)
+ dmaengine_terminate_all(dma_ch);
+
+out:
+ writel_relaxed(cr & ~CR_DMAEN, qspi->io_base + QSPI_CR);
+out_unmap:
+ spi_controller_dma_unmap_mem_op_data(qspi->ctrl, op, &sgt);
+
+ retu
Applied "regulator: da9063: convert header to SPDX" to the regulator tree
The patch regulator: da9063: convert header to SPDX has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 5de219ccc1a7e1dab98848de53166e15af44bbff Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Mon, 25 Mar 2019 21:31:55 +0100 Subject: [PATCH] regulator: da9063: convert header to SPDX Covnert the header of the source file to SPDX. Signed-off-by: Wolfram Sang Signed-off-by: Mark Brown --- drivers/regulator/da9063-regulator.c | 22 -- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c index c5d1ae5265ab..6f9ce1a6e44d 100644 --- a/drivers/regulator/da9063-regulator.c +++ b/drivers/regulator/da9063-regulator.c @@ -1,18 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0+ +// +// Regulator driver for DA9063 PMIC series +// +// Copyright 2012 Dialog Semiconductors Ltd. +// Copyright 2013 Philipp Zabel, Pengutronix +// +// Author: Krystian Garbaciak -/* - * Regulator driver for DA9063 PMIC series - * - * Copyright 2012 Dialog Semiconductors Ltd. - * Copyright 2013 Philipp Zabel, Pengutronix - * - * Author: Krystian Garbaciak - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - */ #include #include #include -- 2.20.1
Applied "regulator: tps65217: Fix off-by-one for latest seletor of tps65217_uv1_ranges" to the regulator tree
The patch
regulator: tps65217: Fix off-by-one for latest seletor of tps65217_uv1_ranges
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0b5e200cc7ee339694693a6d89816b66ccbd663a Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Sun, 24 Mar 2019 14:00:04 +0800
Subject: [PATCH] regulator: tps65217: Fix off-by-one for latest seletor of
tps65217_uv1_ranges
According to the datasheet the latest seletor 11 b = 3.3 V.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/tps65217-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/tps65217-regulator.c
b/drivers/regulator/tps65217-regulator.c
index d84fab616abf..546fb5cf2023 100644
--- a/drivers/regulator/tps65217-regulator.c
+++ b/drivers/regulator/tps65217-regulator.c
@@ -61,7 +61,7 @@ static const struct regulator_linear_range
tps65217_uv1_ranges[] = {
REGULATOR_LINEAR_RANGE(155, 25, 30, 5),
REGULATOR_LINEAR_RANGE(185, 31, 52, 5),
REGULATOR_LINEAR_RANGE(300, 53, 55, 10),
- REGULATOR_LINEAR_RANGE(330, 56, 62, 0),
+ REGULATOR_LINEAR_RANGE(330, 56, 63, 0),
};
static const struct regulator_linear_range tps65217_uv2_ranges[] = {
--
2.20.1
Applied "ASoC: fsl: Add Audio Mixer CPU DAI driver" to the asoc tree
The patch
ASoC: fsl: Add Audio Mixer CPU DAI driver
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From be1df61cf06efb355c90702e46b8d46f055acb4e Mon Sep 17 00:00:00 2001
From: Viorel Suman
Date: Tue, 22 Jan 2019 11:14:26 +
Subject: [PATCH] ASoC: fsl: Add Audio Mixer CPU DAI driver
This patch implements Audio Mixer CPU DAI driver for NXP iMX8 SOCs.
The Audio Mixer is a on-chip functional module that allows mixing of
two audio streams into a single audio stream.
Audio Mixer datasheet is available here:
https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
Signed-off-by: Viorel Suman
Signed-off-by: Mark Brown
---
sound/soc/fsl/Kconfig | 7 +
sound/soc/fsl/Makefile | 3 +
sound/soc/fsl/fsl_audmix.c | 576 +
sound/soc/fsl/fsl_audmix.h | 102 +++
4 files changed, 688 insertions(+)
create mode 100644 sound/soc/fsl/fsl_audmix.c
create mode 100644 sound/soc/fsl/fsl_audmix.h
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 7b1d9970be8b..0af2e056d211 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -24,6 +24,13 @@ config SND_SOC_FSL_SAI
This option is only useful for out-of-tree drivers since
in-tree drivers select it automatically.
+config SND_SOC_FSL_AUDMIX
+ tristate "Audio Mixer (AUDMIX) module support"
+ select REGMAP_MMIO
+ help
+ Say Y if you want to add Audio Mixer (AUDMIX)
+ support for the NXP iMX CPUs.
+
config SND_SOC_FSL_SSI
tristate "Synchronous Serial Interface module (SSI) support"
select SND_SOC_IMX_PCM_DMA if SND_IMX_SOC != n
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 3c0ff315b971..4172d5a3e36c 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -12,6 +12,7 @@ snd-soc-p1022-rdk-objs := p1022_rdk.o
obj-$(CONFIG_SND_SOC_P1022_RDK) += snd-soc-p1022-rdk.o
# Freescale SSI/DMA/SAI/SPDIF Support
+snd-soc-fsl-audmix-objs := fsl_audmix.o
snd-soc-fsl-asoc-card-objs := fsl-asoc-card.o
snd-soc-fsl-asrc-objs := fsl_asrc.o fsl_asrc_dma.o
snd-soc-fsl-sai-objs := fsl_sai.o
@@ -22,6 +23,8 @@ snd-soc-fsl-esai-objs := fsl_esai.o
snd-soc-fsl-micfil-objs := fsl_micfil.o
snd-soc-fsl-utils-objs := fsl_utils.o
snd-soc-fsl-dma-objs := fsl_dma.o
+
+obj-$(CONFIG_SND_SOC_FSL_AUDMIX) += snd-soc-fsl-audmix.o
obj-$(CONFIG_SND_SOC_FSL_ASOC_CARD) += snd-soc-fsl-asoc-card.o
obj-$(CONFIG_SND_SOC_FSL_ASRC) += snd-soc-fsl-asrc.o
obj-$(CONFIG_SND_SOC_FSL_SAI) += snd-soc-fsl-sai.o
diff --git a/sound/soc/fsl/fsl_audmix.c b/sound/soc/fsl/fsl_audmix.c
new file mode 100644
index ..3356cb617713
--- /dev/null
+++ b/sound/soc/fsl/fsl_audmix.c
@@ -0,0 +1,576 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NXP AUDMIX ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ * Copyright 2017 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "fsl_audmix.h"
+
+#define SOC_ENUM_SINGLE_S(xreg, xshift, xtexts) \
+ SOC_ENUM_SINGLE(xreg, xshift, ARRAY_SIZE(xtexts), xtexts)
+
+static const char
+ *tdm_sel[] = { "TDM1", "TDM2", },
+ *mode_sel[] = { "Disabled", "TDM1", "TDM2", "Mixed", },
+ *width_sel[] = { "16b", "18b", "20b", "24b", "32b", },
+ *endis_sel[] = { "Disabled", "Enabled", },
+ *updn_sel[] = { "Downward", "Upward", },
+ *mask_sel[] = { "Unmask", "Mask", };
+
+static const struct soc_enum fsl_audmix_enum[] = {
+/* FSL_AUDMIX_CTR enums */
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_MIXCLK_SHIFT, tdm_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_OUTSRC_SHIFT, mode_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_OUTWIDTH_SHIFT, width_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_MASKRTDF_SHIFT, mask_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_MASKCKDF_SHIFT, mask_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_SYNCMODE_SHIFT, endis_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_CTR, FSL_AUDMIX_CTR_SYNCSRC_SHIFT, tdm_sel),
+/* FSL_AUDMIX_ATCR0 enums */
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_ATCR0, 0, endis_sel),
+SOC_ENUM_SINGLE_S(FSL_AUDMIX_ATCR0, 1, updn_sel),
+/* FSL_AUDMIX_ATCR1 en
Applied "regulator: sc2731: Constify regulators" to the regulator tree
The patch
regulator: sc2731: Constify regulators
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 883ce2421ed7fc1aaf94ff58d099e9a843345dfa Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Tue, 26 Mar 2019 07:57:39 +0800
Subject: [PATCH] regulator: sc2731: Constify regulators
The regulators array should never need to be modified, make it const so
compiler can put it to .rodata.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/sc2731-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/sc2731-regulator.c
b/drivers/regulator/sc2731-regulator.c
index eb2bdf060b7b..0f21f95c8981 100644
--- a/drivers/regulator/sc2731-regulator.c
+++ b/drivers/regulator/sc2731-regulator.c
@@ -146,7 +146,7 @@ static const struct regulator_ops sc2731_regu_linear_ops = {
.vsel_mask = vmask,\
}
-static struct regulator_desc regulators[] = {
+static const struct regulator_desc regulators[] = {
SC2731_REGU_LINEAR(BUCK_CPU0, SC2731_POWER_PD_SW,
SC2731_DCDC_CPU0_PD_MASK, SC2731_DCDC_CPU0_VOL,
SC2731_DCDC_CPU0_VOL_MASK, 3125, 40, 1996875),
--
2.20.1
[PATCH v6 0/1] gpio: add driver for Mellanox BlueField GPIO
Changes since v5: Use devm_platform_ioremap_resource(). Shravan Kumar Ramani (1): gpio: add driver for Mellanox BlueField GPIO controller drivers/gpio/Kconfig | 7 +++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio-mlxbf.c | 153 ++ 3 files changed, 161 insertions(+) create mode 100644 drivers/gpio/gpio-mlxbf.c -- 2.1.2
Re: [PATCH -next] x86/apic: Reduce print level of CPU limit announcement
On Tue, Mar 26, 2019 at 01:29:54PM +0100, Rafael J. Wysocki wrote:
> On Tue, Mar 26, 2019 at 1:02 PM Leon Romanovsky wrote:
> >
> > From: Leon Romanovsky
> >
> > Kernel is booted with less possible CPUs (possible_cpus kernel boot
> > option) than available CPUs will have prints like this:
> >
> > [1.131039] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor
> > 55/0x1f ignored.
> > [1.132228] ACPI: Unable to map lapic to logical cpu number
> >
> > Those warnings are printed for every not-enabled CPU and on the systems
> > with large number of such CPUs, we see a lot of those prints for default
> > print level.
> >
> > Simple conversion of those prints to be in debug level removes them
> > while leaving the option to debug system.
>
> But generally dynamic debug must be enabled in order for pr_debug()
> prints to be visible which is kind of cumbersome to do via the command
> line.
It is doable and documented pretty well, which is uncommon :)
https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html#debug-messages-during-boot-process
>
> > Signed-off-by: Leon Romanovsky
> > ---
> > arch/x86/kernel/acpi/boot.c | 2 +-
> > arch/x86/kernel/apic/apic.c | 6 +++---
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > index 8dcbf6890714..3ef8ab89c02d 100644
> > --- a/arch/x86/kernel/acpi/boot.c
> > +++ b/arch/x86/kernel/acpi/boot.c
> > @@ -770,7 +770,7 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t
> > physid, u32 acpi_id,
> >
> > cpu = acpi_register_lapic(physid, acpi_id, ACPI_MADT_ENABLED);
> > if (cpu < 0) {
> > - pr_info(PREFIX "Unable to map lapic to logical cpu
> > number\n");
> > + pr_debug(PREFIX "Unable to map lapic to logical cpu
> > number\n");
>
> And this one is printed sometimes when something really goes wrong
> which may be really hard to debug otherwise, so there is value in the
> info level here.
>
> Would it be possible to avoid printing it just in some cases?
This can do the trick:
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 3ef8ab89c02d..00212b3991e0 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -770,7 +770,10 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid,
u32 acpi_id,
cpu = acpi_register_lapic(physid, acpi_id, ACPI_MADT_ENABLED);
if (cpu < 0) {
- pr_debug(PREFIX "Unable to map lapic to logical cpu number\n");
+ if (cpu == -ENOENT)
+ pr_debug(PREFIX "Unable to map lapic to logical cpu
number\n");
+ else
+ pr_info(PREFIX "Unable to map lapic to logical cpu
number\n");
return cpu;
}
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 8c2a487b5216..2704a2c57df1 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2299,7 +2299,7 @@ int generic_processor_info(int apicid, int version)
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
disabled_cpus++;
- return -ENODEV;
+ return -ENOENT;
}
if (num_processors >= nr_cpu_ids) {>
> > return cpu;
> > }
> >
> > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> > index b7bcdd781651..8c2a487b5216 100644
> > --- a/arch/x86/kernel/apic/apic.c
> > +++ b/arch/x86/kernel/apic/apic.c
> > @@ -2305,9 +2305,9 @@ int generic_processor_info(int apicid, int version)
> > if (num_processors >= nr_cpu_ids) {
> > int thiscpu = max + disabled_cpus;
> >
> > - pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
> > - "reached. Processor %d/0x%x ignored.\n",
> > - max, thiscpu, apicid);
> > + pr_debug(
> > + "APIC: NR_CPUS/possible_cpus limit of %i reached.
> > Processor %d/0x%x ignored.\n",
> > + max, thiscpu, apicid);
>
> I completely agree with this change, though.
Thanks
>
> >
> > disabled_cpus++;
> > return -EINVAL;
> > --
signature.asc
Description: PGP signature
Re: [PATCH v2 2/8] kbuild: Support for Symbols.list creation
On 3/20/19 4:08 PM, Miroslav Benes wrote:
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index fd03d60f6c5a..1e28ad21314c 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -247,6 +247,11 @@ cmd_gen_ksymdeps = \
$(CONFIG_SHELL) $(srctree)/scripts/gen_ksymdeps.sh $@ >>
$(dot-target).cmd
endif
+ifdef CONFIG_LIVEPATCH
+cmd_livepatch = $(if $(LIVEPATCH_$(basetarget).o), \
+ $(shell touch $(MODVERDIR)/$(basetarget).livepatch))
+endif
+
define rule_cc_o_c
$(call cmd,checksrc)
$(call cmd_and_fixdep,cc_o_c)
@@ -283,6 +288,7 @@ $(single-used-m): $(obj)/%.o: $(src)/%.c
$(recordmcount_source) $(objtool_dep) F
$(call if_changed_rule,cc_o_c)
@{ echo $(@:.o=.ko); echo $@; \
$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
+ $(call cmd_livepatch)
quiet_cmd_cc_lst_c = MKLST $@
cmd_cc_lst_c = $(CC) $(c_flags) -g -c -o $*.o $< && \
Since cmd_livepatch is only called for single-used-m, does this mean
that we can only klp-convert single object file livepatch modules?
I stumbled upon this when trying to create a self-test module that
incorporated two object files. I tried adding a $(call cmd_livepatch)
in the recipe for $(obj)/%.o, but that didn't help. My kbuild foo
wasn't good enough to figure this one out.
I looked at my original code and it is a bit different there. I placed it
under rule_cc_o_c right after objtool command. If I remember correctly
this is the correct recipe for .c->.o. Unfortunately I forgot the details
and there is of course nothing about it in my notes.
Does it help?
Joao, is there a reason you moved it elsewhere?
Hi,
Unfortunately I can't remember why the chunk was moved to where it is in
this version of the patch, sorry. Yet, I did try to move this into the
rule cc_o_c and it seemed to work with not damage.
Joe, would you kindly verify and squash properly the patch below, which
places cmd_livepatch in rule_cc_o_c?
Thank you.
Subject: [PATCH] Move cmd_klp_convert to the right place
Signed-off-by: Joao Moreira
---
scripts/Makefile.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 1e28ad21314c..5f66106a47d6 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -260,6 +260,7 @@ define rule_cc_o_c
$(call cmd,objtool)
$(call cmd,modversions_c)
$(call cmd,record_mcount)
+ $(call cmd,livepatch)
endef
define rule_as_o_S
@@ -288,7 +289,6 @@ $(single-used-m): $(obj)/%.o: $(src)/%.c
$(recordmcount_source) $(objtool_dep) F
$(call if_changed_rule,cc_o_c)
@{ echo $(@:.o=.ko); echo $@; \
$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
- $(call cmd_livepatch)
quiet_cmd_cc_lst_c = MKLST $@
cmd_cc_lst_c = $(CC) $(c_flags) -g -c -o $*.o $< && \
--
2.16.4
Miroslav
[PATCH] spi: tegra20-slink: change chip select action order
To transfer via SPI the tegra20-slink driver first sets the command
register, which contains the chip select value, and after that the
command2 register, which contains the chip select line. This leads to a
small spike in the chip selct 0 line between the set of the value and
the selection of the chip select line.
This commit changes the order of the register writes so that first the
chip select line is chosen and then the value is set, removing the
spike.
Signed-off-by: Randolph Maaßen
---
drivers/spi/spi-tegra20-slink.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 1427f343b39a..6d4679126213 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -717,9 +717,6 @@ static int tegra_slink_start_transfer_one(struct spi_device
*spi,
command2 = tspi->command2_reg;
command2 &= ~(SLINK_RXEN | SLINK_TXEN);
- tegra_slink_writel(tspi, command, SLINK_COMMAND);
- tspi->command_reg = command;
-
tspi->cur_direction = 0;
if (t->rx_buf) {
command2 |= SLINK_RXEN;
@@ -729,9 +726,18 @@ static int tegra_slink_start_transfer_one(struct
spi_device *spi,
command2 |= SLINK_TXEN;
tspi->cur_direction |= DATA_DIR_TX;
}
+
+ /*
+* Writing to the command2 register bevore the command register prevents
+* a spike in chip_select line 0. This selects the chip_select line
+* before changing the chip_select value.
+*/
tegra_slink_writel(tspi, command2, SLINK_COMMAND2);
tspi->command2_reg = command2;
+ tegra_slink_writel(tspi, command, SLINK_COMMAND);
+ tspi->command_reg = command;
+
if (total_fifo_words > SLINK_FIFO_DEPTH)
ret = tegra_slink_start_dma_based_transfer(tspi, t);
else
--
2.11.0
Re: [PATCH 3/3] rcu: validate arguments for rcu tracepoints
On Tue, Mar 26, 2019 at 09:40:07AM +0800, Yafang Shao wrote:
> When CONFIG_RCU_TRACE is not set, all these tracepoints are define as
> do-nothing macro.
> We'd better make those inline functions that take proper arguments.
>
> As RCU_TRACE() is defined as do-nothing marco as well when
> CONFIG_RCU_TRACE is not set, so we can clean it up.
>
> Signed-off-by: Yafang Shao
With the naming changes suggested by Steven:
Acked-by: Paul E. McKenney
This area of the code should be relatively free from conflicts, so please
feel free to take it with the tracing updates.
> ---
> include/trace/events/rcu.h | 84
> +-
> kernel/rcu/rcu.h | 9 ++---
> kernel/rcu/tree.c | 8 ++---
> 3 files changed, 60 insertions(+), 41 deletions(-)
>
> diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
> index f0c4d10..357e1b6 100644
> --- a/include/trace/events/rcu.h
> +++ b/include/trace/events/rcu.h
> @@ -750,36 +750,60 @@
>
> #else /* #ifdef CONFIG_RCU_TRACE */
>
> -#define trace_rcu_grace_period(rcuname, gp_seq, gpevent) do { } while (0)
> -#define trace_rcu_future_grace_period(rcuname, gp_seq, gp_seq_req, \
> - level, grplo, grphi, event) \
> - do { } while (0)
> -#define trace_rcu_grace_period_init(rcuname, gp_seq, level, grplo, grphi, \
> - qsmask) do { } while (0)
> -#define trace_rcu_exp_grace_period(rcuname, gqseq, gpevent) \
> - do { } while (0)
> -#define trace_rcu_exp_funnel_lock(rcuname, level, grplo, grphi, gpevent) \
> - do { } while (0)
> -#define trace_rcu_nocb_wake(rcuname, cpu, reason) do { } while (0)
> -#define trace_rcu_preempt_task(rcuname, pid, gp_seq) do { } while (0)
> -#define trace_rcu_unlock_preempted_task(rcuname, gp_seq, pid) do { } while
> (0)
> -#define trace_rcu_quiescent_state_report(rcuname, gp_seq, mask, qsmask,
> level, \
> - grplo, grphi, gp_tasks) do { } \
> - while (0)
> -#define trace_rcu_fqs(rcuname, gp_seq, cpu, qsevent) do { } while (0)
> -#define trace_rcu_dyntick(polarity, oldnesting, newnesting, dyntick) do { }
> while (0)
> -#define trace_rcu_callback(rcuname, rhp, qlen_lazy, qlen) do { } while (0)
> -#define trace_rcu_kfree_callback(rcuname, rhp, offset, qlen_lazy, qlen) \
> - do { } while (0)
> -#define trace_rcu_batch_start(rcuname, qlen_lazy, qlen, blimit) \
> - do { } while (0)
> -#define trace_rcu_invoke_callback(rcuname, rhp) do { } while (0)
> -#define trace_rcu_invoke_kfree_callback(rcuname, rhp, offset) do { } while
> (0)
> -#define trace_rcu_batch_end(rcuname, callbacks_invoked, cb, nr, iit, risk) \
> - do { } while (0)
> -#define trace_rcu_torture_read(rcutorturename, rhp, secs, c_old, c) \
> - do { } while (0)
> -#define trace_rcu_barrier(name, s, cpu, cnt, done) do { } while (0)
> +TRACE_EVENT_NONE(rcu_grace_period,
> + TP_PROTO(const char *rcuname, unsigned long gp_seq,
> + const char *gpevent));
> +TRACE_EVENT_NONE(rcu_future_grace_period,
> + TP_PROTO(const char *rcuname, unsigned long gp_seq,
> + unsigned long gp_seq_req, u8 level, int grplo,
> + int grphi, const char *gpevent));
> +TRACE_EVENT_NONE(rcu_grace_period_init,
> + TP_PROTO(const char *rcuname, unsigned long gp_seq, u8 level,
> + int grplo, int grphi, unsigned long qsmask));
> +TRACE_EVENT_NONE(rcu_exp_grace_period,
> + TP_PROTO(const char *rcuname, unsigned long gpseq,
> + const char *gpevent));
> +TRACE_EVENT_NONE(rcu_exp_funnel_lock,
> + TP_PROTO(const char *rcuname, u8 level, int grplo, int grphi,
> + const char *gpevent));
> +TRACE_EVENT_NONE(rcu_nocb_wake,
> + TP_PROTO(const char *rcuname, int cpu, const char *reason));
> +TRACE_EVENT_NONE(rcu_preempt_task,
> + TP_PROTO(const char *rcuname, int pid, unsigned long gp_seq));
> +TRACE_EVENT_NONE(rcu_unlock_preempted_task,
> + TP_PROTO(const char *rcuname, unsigned long gp_seq, int pid));
> +TRACE_EVENT_NONE(rcu_quiescent_state_report,
> + TP_PROTO(const char *rcuname, unsigned long gp_seq,
> + unsigned long mask, unsigned long qsmask,
> + u8 level, int grplo, int grphi, int gp_tasks));
> +TRACE_EVENT_NONE(rcu_fqs,
> + TP_PROTO(const char *rcuname, unsigned long gp_seq, int cpu,
> + const char *qsevent));
> +TRACE_EVENT_NONE(rcu_dyntick,
> + TP_PROTO(const char *polarity, long oldnesting, long newnesting,
> + atomic_t dynticks));
> +TRACE_EVENT_NONE(rcu_callback,
> + TP_PROTO(const char *rcuname, struct rcu_head *rhp, long qlen_lazy,
> + long qlen));
> +TRACE_EVENT_NONE(rcu_kfree_callback,
> + TP_PROTO(const char *rcuname, struct rcu_head *rhp,
> + unsigned long offset, long qlen_lazy, long qlen));
> +TRACE_EVENT_NONE(rcu_batch_start,
> + TP_PROTO(const char *rcuname, long qlen_lazy, long ql
Re: [PATCH v2 2/4] mm/sparse: Optimize sparse_add_one_section()
On Tue 26-03-19 22:18:03, Baoquan He wrote: > On 03/26/19 at 03:03pm, Michal Hocko wrote: > > On Tue 26-03-19 21:45:22, Baoquan He wrote: > > > On 03/26/19 at 11:17am, Michal Hocko wrote: > > > > On Tue 26-03-19 18:08:17, Baoquan He wrote: > > > > > On 03/26/19 at 10:29am, Michal Hocko wrote: > > > > > > On Tue 26-03-19 17:02:25, Baoquan He wrote: > > > > > > > Reorder the allocation of usemap and memmap since usemap > > > > > > > allocation > > > > > > > is much simpler and easier. Otherwise hard work is done to make > > > > > > > memmap ready, then have to rollback just because of usemap > > > > > > > allocation > > > > > > > failure. > > > > > > > > > > > > Is this really worth it? I can see that !VMEMMAP is doing memmap > > > > > > size > > > > > > allocation which would be 2MB aka costly allocation but we do not do > > > > > > __GFP_RETRY_MAYFAIL so the allocator backs off early. > > > > > > > > > > In !VMEMMAP case, it truly does simple allocation directly. surely > > > > > usemap which size is 32 is smaller. So it doesn't matter that much > > > > > who's > > > > > ahead or who's behind. However, this benefit a little in VMEMMAP case. > > > > > > > > How does it help there? The failure should be even much less probable > > > > there because we simply fall back to a small 4kB pages and those > > > > essentially never fail. > > > > > > OK, I am fine to drop it. Or only put the section existence checking > > > earlier to avoid unnecessary usemap/memmap allocation? > > > > DO you have any data on how often that happens? Should basically never > > happening, right? > > Oh, you think about it in this aspect. Yes, it rarely happens. > Always allocating firstly can increase efficiency. Then I will just drop > it. OK, let me try once more. Doing a check early is something that makes sense in general. Another question is whether the check is needed at all. So rather than fiddling with its placement I would go whether it is actually failing at all. I suspect it doesn't because the memory hotplug is currently enforced to be section aligned. There are people who would like to allow subsection or section unaligned aware hotplug and then this would be much more relevant but without any solid justification such a patch is not really helpful because it might cause code conflicts with other work or obscure the git blame tracking by an additional hop. In short, if you want to optimize something then make sure you describe what you are optimizing how it helps. -- Michal Hocko SUSE Labs
[PATCH v5 6/6] dt-bindings: fpga: Add bindings for ZynqMP fpga driver
Add documentation to describe Xilinx ZynqMP fpga driver
bindings.
Signed-off-by: Nava kishore Manne
---
Changes for v5:
-Moved pcap node as a child to firwmare
node as suggested by Rob.
Changes for v4:
-Modified binding description as suggested by Moritz Fischer.
Changes for v3:
-Removed PCAP as a child node to the FW and Created
an independent node since PCAP driver is a consumer
not a provider.
.../bindings/fpga/xlnx,zynqmp-pcap-fpga.txt | 25 +++
1 file changed, 25 insertions(+)
create mode 100644
Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
new file mode 100644
index ..3052bf619dd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
@@ -0,0 +1,25 @@
+Devicetree bindings for Zynq Ultrascale MPSoC FPGA Manager.
+The ZynqMP SoC uses the PCAP (Processor configuration Port) to configure the
+Programmable Logic (PL). The configuration uses the firmware interface.
+
+Required properties:
+- compatible: should contain "xlnx,zynqmp-pcap-fpga"
+
+Example for full FPGA configuration:
+
+ fpga-region0 {
+ compatible = "fpga-region";
+ fpga-mgr = <&zynqmp_pcap>;
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ };
+
+ firmware {
+ zynqmp_firmware: zynqmp-firmware {
+ compatible = "xlnx,zynqmp-firmware";
+ method = "smc";
+ zynqmp_pcap: pcap {
+ compatible = "xlnx,zynqmp-pcap-fpga";
+ };
+ };
+ };
--
2.18.0
[PATCH v5 4/6] dt-bindings: pinctrl: Add ZynqMP pin controller bindings
From: Rajan Vaja Add documentation to describe Xilinx ZynqMP pin controller bindings. Signed-off-by: Rajan Vaja Signed-off-by: Jolly Shah Reviewed-by: Rob Herring --- .../bindings/pinctrl/xlnx,zynqmp-pinctrl.txt | 275 ++ 1 file changed, 275 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt new file mode 100644 index ..acf44a5d3778 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt @@ -0,0 +1,275 @@ + Binding for Xilinx ZynqMP Pinctrl + +Required properties: +- compatible: "xlnx,zynqmp-pinctrl" + +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. + +Required properties for pinmux nodes are: + - groups: A list of pinmux groups. + - function: The name of a pinmux function to activate for the specified set + of groups. + +Required properties for configuration nodes: +One of: + - pins: A list of pin names + - groups: A list of pinmux groups. + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pinmux subnode: + groups, function + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pinconf subnode: + groups, pins, bias-disable, bias-pull-up, bias-pull-down, slew-rate + + Valid arguments for 'slew-rate' are 'SLEW_RATE_SLOW' and 'SLEW_RATE_FAST' to + select between slow and fast respectively. + + Valid values for groups are: + 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, + sdio1_12_grp, sdio1_13_grp, sdio1_14_grp, + sdio1_15_grp, sdio1_pc_0_grp, sdio1_cd_0_grp, + sdio1_wp_0_grp, sdio1_pc_1_grp, sdio1_cd_1_grp, + sdio1_wp_1_grp, nand0_0_grp, nand0_ce_0_grp, + nand0_rb_0_grp, nand0_dqs_0_grp, nand0_ce_1_grp, + nand0_rb_1_grp, nand0_dqs_1_grp, can0_0_grp, + can0_1_grp, can0_2_grp, can0_3_grp, + can0_4_grp, can0_5_grp, can0_6_grp, + can0_7_grp, can0_8_grp, can0_9_grp, + can0_10_grp, can0_11_grp, can0_12_grp, + can0_13_grp, can0_14_grp, can0_15_grp, + can0_16_grp, can0_17_grp, can0_18_grp, + can1_0_grp, can1_1_grp, can1_2_grp, + can1_3_grp, can1_4_grp, can1_5_grp, + can1_6_grp, can1_7_grp, can1_8_grp, + can1_9_grp, can1_10_grp, can1_11_grp, + can1_12_grp, can1_13_grp, can1_14_grp, + can1_15_grp, can1_16_grp, can1_17_grp, + can1_18_grp, can1_19_grp, uart0_0_grp, + uart0_1_grp, uart0_2_grp, uart0_3_grp, + uart0_4_grp, ua
[PATCH v5 5/6] dt-bindings: nvmem: Add bindings for ZynqMP nvmem driver
Add documentation to describe Xilinx ZynqMP nvmem driver
bindings.
Signed-off-by: Nava kishore Manne
Reviewed-by: Rob Herring
---
.../bindings/nvmem/xlnx,zynqmp-nvmem.txt | 47 +++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
diff --git a/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
new file mode 100644
index ..2043c8284f8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
@@ -0,0 +1,47 @@
+--
+= Zynq UltraScale+ MPSoC nvmem firmware driver binding =
+--
+The nvmem_firmware node provides access to the hardware related data
+like soc revision, IDCODE... etc, By using the firmware interface.
+
+Required properties:
+- compatible: should be "xlnx,zynqmp-nvmem-fw"
+
+= Data cells =
+Are child nodes of silicon id, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+---
+ Example
+---
+firmware {
+ zynqmp_firmware: zynqmp-firmware {
+ compatible = "xlnx,zynqmp-firmware";
+ method = "smc";
+
+ nvmem_firmware {
+ compatible = "xlnx,zynqmp-nvmem-fw";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* Data cells */
+ soc_revision: soc_revision {
+ reg = <0x0 0x4>;
+ };
+ };
+ };
+};
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+ pcap {
+ ...
+
+ nvmem-cells = <&soc_revision>;
+ nvmem-cell-names = "soc_revision";
+
+ ...
+ };
+
--
2.18.0
[PATCH v5 3/6] dt-bindings: reset: Add bindings for ZynqMP reset driver
Add documentation to describe Xilinx ZynqMP reset driver
bindings.
Signed-off-by: Nava kishore Manne
Signed-off-by: Jolly Shah
Reviewed-by: Rob Herring
---
.../bindings/reset/xlnx,zynqmp-reset.txt | 52 +++
.../dt-bindings/reset/xlnx-zynqmp-resets.h| 130 ++
2 files changed, 182 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
create mode 100644 include/dt-bindings/reset/xlnx-zynqmp-resets.h
diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
new file mode 100644
index ..27a45fe5ecf1
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
@@ -0,0 +1,52 @@
+--
+ = Zynq UltraScale+ MPSoC reset driver binding =
+--
+The Zynq UltraScale+ MPSoC has several different resets.
+
+See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more information
+about zynqmp resets.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required Properties:
+- compatible: "xlnx,zynqmp-reset"
+- #reset-cells:Specifies the number of cells needed to encode reset
+ line, should be 1
+
+---
+Example
+---
+
+firmware {
+ zynqmp_firmware: zynqmp-firmware {
+ compatible = "xlnx,zynqmp-firmware";
+ method = "smc";
+
+ zynqmp_reset: reset-controller {
+ compatible = "xlnx,zynqmp-reset";
+ #reset-cells = <1>;
+ };
+ };
+};
+
+Specifying reset lines connected to IP modules
+==
+
+Device nodes that need access to reset lines should
+specify them as a reset phandle in their corresponding node as
+specified in reset.txt.
+
+For list of all valid reset indicies see
+
+
+Example:
+
+serdes: zynqmp_phy@fd40 {
+ ...
+
+ resets = <&zynqmp_reset ZYNQMP_RESET_SATA>;
+ reset-names = "sata_rst";
+
+ ...
+};
diff --git a/include/dt-bindings/reset/xlnx-zynqmp-resets.h
b/include/dt-bindings/reset/xlnx-zynqmp-resets.h
new file mode 100644
index ..e295fd5d824e
--- /dev/null
+++ b/include/dt-bindings/reset/xlnx-zynqmp-resets.h
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#ifndef _DT_BINDINGS_ZYNQMP_RESETS_H
+#define _DT_BINDINGS_ZYNQMP_RESETS_H
+
+#defineZYNQMP_RESET_PCIE_CFG 0
+#defineZYNQMP_RESET_PCIE_BRIDGE1
+#defineZYNQMP_RESET_PCIE_CTRL 2
+#defineZYNQMP_RESET_DP 3
+#defineZYNQMP_RESET_SWDT_CRF 4
+#defineZYNQMP_RESET_AFI_FM55
+#defineZYNQMP_RESET_AFI_FM46
+#defineZYNQMP_RESET_AFI_FM37
+#defineZYNQMP_RESET_AFI_FM28
+#defineZYNQMP_RESET_AFI_FM19
+#defineZYNQMP_RESET_AFI_FM010
+#defineZYNQMP_RESET_GDMA 11
+#defineZYNQMP_RESET_GPU_PP112
+#defineZYNQMP_RESET_GPU_PP013
+#defineZYNQMP_RESET_GPU14
+#defineZYNQMP_RESET_GT 15
+#defineZYNQMP_RESET_SATA 16
+#defineZYNQMP_RESET_ACPU3_PWRON17
+#defineZYNQMP_RESET_ACPU2_PWRON18
+#defineZYNQMP_RESET_ACPU1_PWRON19
+#defineZYNQMP_RESET_ACPU0_PWRON20
+#defineZYNQMP_RESET_APU_L2 21
+#defineZYNQMP_RESET_ACPU3 22
+#defineZYNQMP_RESET_ACPU2 23
+#defineZYNQMP_RESET_ACPU1 24
+#defineZYNQMP_RESET_ACPU0 25
+#defineZYNQMP_RESET_DDR26
+#defineZYNQMP_RESET_APM_FPD27
+#defineZYNQMP_RESET_SOFT 28
+#defineZYNQMP_RESET_GEM0 29
+#defineZYNQMP_RESET_GEM1 30
+#defineZYNQMP_RESET_GEM2 31
+#defineZYNQMP_RESET_GEM3 32
+#defineZYNQMP_RESET_QSPI 33
+#defineZYNQMP_RESET_UART0 34
+#defineZYNQMP_RESET_UART1 35
+#defineZYNQMP_RESET_SPI0 36
+#defineZYNQMP_RESET_SPI1 37
+#defineZYNQMP_RESET_SDIO0 38
+#defineZYNQMP_RESET_SDIO1 39
+#define
[PATCH v5 1/6] dt-bindings: power: Add ZynqMP power domain bindings
From: Rajan Vaja
Add documentation to describe ZynqMP power domain bindings.
Signed-off-by: Rajan Vaja
Signed-off-by: Jolly Shah
Reviewed-by: Rob Herring
---
.../bindings/power/xlnx,zynqmp-genpd.txt | 34
include/dt-bindings/power/xlnx-zynqmp-power.h | 39 +++
2 files changed, 73 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h
diff --git a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
new file mode 100644
index ..3c7f2378e146
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
@@ -0,0 +1,34 @@
+---
+Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
+---
+The binding for zynqmp-power-controller follow the common
+generic PM domain binding[1].
+
+[1] Documentation/devicetree/bindings/power/power_domain.txt
+
+== Zynq MPSoC Generic PM Domain Node ==
+
+Required property:
+ - Below property should be in zynqmp-firmware node.
+ - #power-domain-cells:Number of cells in a PM domain specifier. Must
be 1.
+
+Power domain ID indexes are mentioned in
+include/dt-bindings/power/xlnx-zynqmp-power.h.
+
+---
+Example
+---
+
+firmware {
+ zynqmp_firmware: zynqmp-firmware {
+ ...
+ #power-domain-cells = <1>;
+ ...
+ };
+};
+
+sata {
+ ...
+ power-domains = <&zynqmp_firmware 2>;
+ ...
+};
diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h
b/include/dt-bindings/power/xlnx-zynqmp-power.h
new file mode 100644
index ..1bc9636098ca
--- /dev/null
+++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#ifndef _DT_BINDINGS_ZYNQMP_POWER_H
+#define _DT_BINDINGS_ZYNQMP_POWER_H
+
+#definePD_USB_00
+#definePD_USB_11
+#definePD_SATA 2
+#definePD_SPI_03
+#definePD_SPI_14
+#definePD_UART_0 5
+#definePD_UART_1 6
+#definePD_ETH_07
+#definePD_ETH_18
+#definePD_ETH_29
+#definePD_ETH_310
+#definePD_I2C_011
+#definePD_I2C_112
+#definePD_DP 13
+#definePD_GDMA 14
+#definePD_ADMA 15
+#definePD_TTC_016
+#definePD_TTC_117
+#definePD_TTC_218
+#definePD_TTC_319
+#definePD_SD_0 20
+#definePD_SD_1 21
+#definePD_NAND 22
+#definePD_QSPI 23
+#definePD_GPIO 24
+#definePD_CAN_025
+#definePD_CAN_126
+#definePD_PCIE 27
+#definePD_GPU 28
+
+#endif
--
2.18.0
[PATCH v5 2/6] dt-bindings: soc: Add ZynqMP PM bindings
From: Rajan Vaja
Add documentation to describe Xilinx ZynqMP power management
bindings.
Signed-off-by: Rajan Vaja
Signed-off-by: Jolly Shah
Reviewed-by: Rob Herring
---
.../power/reset/xlnx,zynqmp-power.txt | 25 +++
1 file changed, 25 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
diff --git
a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
new file mode 100644
index ..d366f1eb623a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
@@ -0,0 +1,25 @@
+
+Device Tree Bindings for the Xilinx Zynq MPSoC Power Management
+
+The zynqmp-power node describes the power management configurations.
+It will control remote suspend/shutdown interfaces.
+
+Required properties:
+ - compatible: Must contain: "xlnx,zynqmp-power"
+ - interrupts: Interrupt specifier
+
+---
+Example
+---
+
+firmware {
+ zynqmp_firmware: zynqmp-firmware {
+ compatible = "xlnx,zynqmp-firmware";
+ method = "smc";
+
+ zynqmp_power: zynqmp-power {
+ compatible = "xlnx,zynqmp-power";
+ interrupts = <0 35 4>;
+ };
+ };
+};
--
2.18.0
[PATCH v5 0/6]dt-bindings: Firmware node binding for ZynqMP core
Base firmware node and clock child node binding are part of mainline kernel.
This patchset adds documentation to describe rest of the firmware child node
bindings.
Complete firmware DT node example is shown below for ease of understanding:
firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
method = "smc";
#power-domain-cells = <1>;
#reset-cells = <1>;
zynqmp_clk: clock-controller {
#clock-cells = <1>;
compatible = "xlnx,zynqmp-clk";
clocks = <&pss_ref_clk>, <&video_clk>,
<&pss_alt_ref_clk>, <&aux_ref_clk>, <>_crx_ref_clk>;
clock-names = "pss_ref_clk", "video_clk",
"pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
};
zynqmp_power: zynqmp-power {
compatible = "xlnx,zynqmp-power";
interrupts = <0 35 4>;
};
zynqmp_reset: reset-controller {
compatible = "xlnx,zynqmp-reset";
#reset-cells = <1>;
};
nvmem_firmware {
compatible = "xlnx,zynqmp-nvmem-fw";
#address-cells = <1>;
#size-cells = <1>;
/* Data cells */
soc_revision: soc_revision {
reg = <0x0 0x4>;
};
};
pinctrl0: pinctrl@ff18 {
compatible = "xlnx,zynqmp-pinctrl";
pinctrl_uart1_default: uart1-default {
mux {
groups = "uart0_4_grp";
function = "uart0";
};
conf {
groups = "uart0_4_grp";
slew-rate = ;
io-standard = ;
};
conf-rx {
pins = "MIO18";
bias-high-impedance;
};
conf-tx {
pins = "MIO19";
bias-disable;
schmitt-cmos = ;
};
};
};
zynqmp_pcap: pcap {
compatible = "xlnx,zynqmp-pcap-fpga";
};
};
};
Nava kishore Manne (3):
dt-bindings: reset: Add bindings for ZynqMP reset driver
dt-bindings: nvmem: Add bindings for ZynqMP nvmem driver
dt-bindings: fpga: Add bindings for ZynqMP fpga driver
Rajan Vaja (3):
dt-bindings: power: Add ZynqMP power domain bindings
dt-bindings: soc: Add ZynqMP PM bindings
dt-bindings: pinctrl: Add ZynqMP pin controller bindings
.../bindings/fpga/xlnx,zynqmp-pcap-fpga.txt | 25 ++
.../bindings/nvmem/xlnx,zynqmp-nvmem.txt | 47 +++
.../bindings/pinctrl/xlnx,zynqmp-pinctrl.txt | 275 ++
.../power/reset/xlnx,zynqmp-power.txt | 25 ++
.../bindings/power/xlnx,zynqmp-genpd.txt | 34 +++
.../bindings/reset/xlnx,zynqmp-reset.txt | 52
include/dt-bindings/power/xlnx-zynqmp-power.h | 39 +++
.../dt-bindings/reset/xlnx-zynqmp-resets.h| 130 +
8 files changed, 627 insertions(+)
create mode 100644
Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
create mode 100644
Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
create mode 100644
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt
create mode 100644
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
create mode 100644
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
create mode 100644
Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h
create mode 100644 include/dt-bindings/reset/xlnx-zynqmp-resets.h
--
2.18.0
Re: [PATCH 5/5] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
On Tue, Mar 26, 2019 at 04:12:43PM +0200, Sakari Ailus wrote:
> Moi,
>
> On Tue, Mar 26, 2019 at 04:06:33PM +0200, Heikki Krogerus wrote:
> > Hi,
> >
> > On Tue, Mar 26, 2019 at 03:13:53PM +0200, Andy Shevchenko wrote:
> > > > > > On ACPI based systems the resulting strings look like
> > > > > >
> > > > > > \_SB.PCI0.CIO2.port@1.endpoint@0
> > > > > >
> > > > > > where the nodes are separated by a dot (".") and the first three are
> > > > > > ACPI device nodes and the latter two ACPI data nodes.
> > > > >
> > > > > Do we support swnode here?
> > > >
> > > > Good question. The swnodes have no hierarchy at the moment (they're only
> > > > created for a struct device as a parent) and they do not have
> > > > human-readable
> > > > names. So I'd say it's not relevant right now. Should these two change,
> > > > support for swnode could (and should) be added later on.
> > >
> > > Heikki, what do you think about this?
> >
> > Well, the swnodes do have hierarchy. That was kind of the whole point
> > of introducing them. They now can also be named using "name" property.
> > See commit 344798206f171c5abea7ab1f9762fa526d7f539d.
>
> Right; I saw the function after initially replying to Andy but I missed
> where the node name came from. :-) Now I know...
>
> I can add support for swnode, too, if you like.
It's up to you.
thanks,
--
heikki
Re: [PATCH 5/5] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
On Tue, Mar 26, 2019 at 04:12:43PM +0200, Sakari Ailus wrote: > On Tue, Mar 26, 2019 at 04:06:33PM +0200, Heikki Krogerus wrote: > > On Tue, Mar 26, 2019 at 03:13:53PM +0200, Andy Shevchenko wrote: > > > > > Do we support swnode here? > > > > > > > > Good question. The swnodes have no hierarchy at the moment (they're only > > > > created for a struct device as a parent) and they do not have > > > > human-readable > > > > names. So I'd say it's not relevant right now. Should these two change, > > > > support for swnode could (and should) be added later on. > > > > > > Heikki, what do you think about this? > > > > Well, the swnodes do have hierarchy. That was kind of the whole point > > of introducing them. They now can also be named using "name" property. > > See commit 344798206f171c5abea7ab1f9762fa526d7f539d. > > Right; I saw the function after initially replying to Andy but I missed > where the node name came from. :-) Now I know... > > I can add support for swnode, too, if you like. Definitely! -- With Best Regards, Andy Shevchenko
Re: [PATCH v19,RESEND 08/27] x86/cpu/intel: Detect SGX support and update caps appropriately
On Tue, Mar 26, 2019 at 05:17:40AM -0700, Huang, Kai wrote:
> On Wed, 2019-03-20 at 18:21 +0200, Jarkko Sakkinen wrote:
> > From: Sean Christopherson
> >
> > Similar to other large Intel features such as VMX and TXT, SGX must be
> > explicitly enabled in IA32_FEATURE_CONTROL MSR to be truly usable.
> > Clear all SGX related capabilities if SGX is not fully enabled in
> > IA32_FEATURE_CONTROL or if the SGX1 instruction set isn't supported
> > (impossible on bare metal, theoretically possible in a VM if the VMM is
> > doing something weird).
> >
> > Like SGX itself, SGX Launch Control must be explicitly enabled via a
> > flag in IA32_FEATURE_CONTROL. Clear the SGX_LC capability if Launch
> > Control is not fully enabled (or obviously if SGX itself is disabled).
> >
> > Note that clearing X86_FEATURE_SGX_LC creates a bit of a conundrum
> > regarding the SGXLEPUBKEYHASH MSRs, as it may be desirable to read the
> > MSRs even if they are not writable, e.g. to query the configured key,
> > but clearing the capability leaves no breadcrum for discerning whether
> > or not the MSRs exist. But, such usage will be rare (KVM is the only
> > known case at this time) and not performance critical, so it's not
> > unreasonable to require the use of rdmsr_safe(). Clearing the cap bit
> > eliminates the need for an additional flag to track whether or not
> > Launch Control is truly enabled, which is what we care about the vast
> > majority of the time.
>
> [Resend. Somehow my last reply doesn't show up in my mailbox so not sure
> whether I sent it
> successfully or not. Sorry if you receving duplicated mails.]
>
> However this is not consistent with HW behavior. If LC feature flag is not
> present, then MSRs should
> have hash of Intel's key, which is not always the case here, when you expose
> SGX to KVM. Enclave in
> KVM guest will get unexpected EINIT error when launing Intel enclave, if on
> HW MSRs are configured
> to 3rd party value but locked to readonly.
Intel doesn't have a singular key. The internal reset value of the LE
pubkey hash MSRs is micro-architectural, i.e. can change without warning
on any given processor. All current processors with SGX support may use
the same reset value, but it's not something that customers should/can
rely on.
That being said, this in no way impacts KVM's ability to virtualize SGX,
e.g. KVM can directly do CPUID and {RD,WR}MSR to probe the capabilities
of the platform as needed.
> My opition is we already have enough cases that violates HW behavior in
> SGX virtualization, let's not have one more.
What are the other cases?
> Besides, why do we "need an additional flag to track whether or not
> Launch Control is truly enabled"? Doesn't driver only need to know whether
> MSRs are writable?
Yes, and that's why we're overloading X86_FEATURE_SGX_LC to be set if
and only if SGX_LC is supported *and* enabled, e.g. so that the kernel
can simply check X86_FEATURE_SGX_LC without having to also probe the MSRs.
Re: Bad file pattern in MAINTAINERS section 'KEYS-TRUSTED'
On Tue, 2019-03-26 at 08:10 -0400, Mimi Zohar wrote: > Hi Jarrko, > > On Tue, 2019-03-26 at 13:37 +0200, Jarkko Sakkinen wrote: > > Mimi, > > > > Can you fix this and I can ack and send PR through my tree? > > Making the "trusted.h" include file public was part of David's "KEYS: > Support TPM-wrapped key and crypto ops" patch set. I wasn't involved > in reviewing or upstreaming this patch set. As I recall, it was > upstreamed rather quickly without much review. As it is TPM related, > it should have at least been posted on the linux-integrity mailing > list. I have no idea if "trusted.h" should have been made public. > > I'm not sure just "fixing" the MAINTAINERS file is the right > solution. I was hoping to look at it later this week. Perhaps you > and James could take a look? Looking at the contents of linux/keys/trusted.h, it looks like the wrong decision to move it. The contents are way too improperly named and duplicative to be in a standard header. It's mostly actually TPM code including a redefinition of the tpm_buf structure, so it doesn't even seem to be necessary for trusted keys. If you want to fix this as a bug, I'd move it back again, but long term I think it should simply be combined with trusted.c because nothing else can include it sanely anyway. James
Re: [PATCH 09/10] ALSA: pcm: Add snd_pcm_ops for snd_pcm_link()
On Tue, 26 Mar 2019 12:25:37 +0100, Timo Wischer wrote: > > On 3/26/19 09:35, Takashi Iwai wrote: > > On Tue, 26 Mar 2019 08:49:33 +0100, > wrote: > > From: Timo Wischer > > snd_pcm_link() can be called by the user as long as the device is not > yet started. Therefore currently a driver which wants to iterate over > the linked substreams has to do this at the start trigger. But the > start > trigger should not block for a long time. Therefore there is no > callback > which can be used to iterate over the linked substreams without > delaying > the start trigger. > This patch introduces a new callback function which will be called > after > the linked substream list was updated by snd_pcm_link(). This callback > function is allowed to block for a longer time without interfering the > synchronized start up of linked substreams. > > Signed-off-by: Timo Wischer > > Well, the idea appears interesting, but I'm afraid that the > implementation is still racy. The place you're calling the new > callback isn't protected, hence the stream can be triggered while > calling it. That is, even during operating your loopback link_changed > callback, another thread is able to start the stream. > > Hi Takashi, > > As far as I got you mean the following scenario: > > * snd_pcm_link() is called for a HW sound card > + loopback_snd_timer_link_changed() The start may happen at this point. > + loopback_snd_timer_open() > + spin_lock_irqsave(&dpcm->cable->lock, flags); > * snd_pcm_start() called for aloop sound card > + loopback_trigger() > + spin_lock(&cable->lock) -> has to wait till loopback_snd_timer_open() > calls spin_unlock_irqrestore() > > So far snd_pcm_start() has to wait for loopback_snd_timer_open(). > > * loopback_snd_timer_open() will continue with > + dpcm->cable->snd_timer.instance = NULL; > + spin_unlock_irqrestore() > * loopback_trigger() can enter the lock > + loopback_snd_timer_start() will fail with -EINVAL due to > (loopback_trigger == NULL) > > At least this will not result into memory corruption due to race or any other > wired behavior. I don't expect the memory corruption, but my point is that dealing with linked streams is still tricky. It was considered for the lightweight coupled start/stop operation, and something intensively depending on the linked status was out of the original design... > But my expectation is that snd_pcm_link(hw, aloop) or snd_pcm_link(aloop, hw) > is only called by the application calling snd_pcm_start(aloop) > because the same aloop device cannot be opened by multiple applications at the > same time. > > Do you see an use case where one application would call snd_pcm_start() in > parallel with snd_pcm_link() (somehow configuring the device)? It's not about the actual application usages but rather against the malicious attacks. Especially aloop is a virtual device that is available allover the places, it may be deployed / attacked easily. > May be we should add an additional synchronization mechanism in pcm_native.c > to avoid call of snd_pcm_link() in parallel with snd_pcm_start(). If it really matters... Honestly speaking, I'm not fully convinced whether we want to deal with this using the PCM link mechanism. What's the motivation for using the linked streams at the first place? That's one of the biggest missing piece in the whole picture. thanks, Takashi
Re:Re: [PATCH v2] mtd: spi-nor: Return error when nor->addr_width does not match the device size
Hi, Vignesh
Thanks for your suggestion. I will send a new patch.
At 2019-03-19 13:22:15, "Vignesh Raghavendra" wrote:
>Hi,
>
>On 13/03/19 7:15 PM, Liu Xiang wrote:
>> In some is25lp256, the DWORD1 of JEDEC Basic Flash Parameter Header
>> is 0xfff920e5. So the DWORD1[18:17] Address Bytes bits are 0b00,
>> means that 3-Byte only addressing. But the device size is larger
>> than 16MB, nor->addr_width must be 4 to access the whole address.
>> An error should be returned when nor->addr_width does not match
>> the device size in spi_nor_parse_bfpt(). Then it can go back to
>> use spi_nor_ids[] for setting the right addr_width.
>>
>> Suggested-by: Boris Brezillon
>> Signed-off-by: Liu Xiang
>> ---
>> drivers/mtd/spi-nor/spi-nor.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index 6e13bbd..63933c7 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -2811,6 +2811,14 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
>> }
>> params->size >>= 3; /* Convert to bytes. */
>>
>> +/*
>> + * If the device exceeds 16MiB, addr_width must be 4.
>> + * addr_width == 3 means the Address Bytes we are
>> + * reading from BFPT is wrong.
>> + */
>
>JESD216 standard does not mandate flash devices >16MiB to always support
>4 byte addressing opcode. So, its okay for flash vendor to support
>>16MiB flash with 3 byte addressing and Bank/extended address register.
>
>> +if (params->size > 0x100 && nor->addr_width == 3)
>> +return -EINVAL;
>> +
>
>Assuming only DWORD1[18:17] bits are wrong, then returning from here
>would mean we miss parsing Sector Erase settings, Quad Enable
>Requirements etc from BFPT which is kind of bad.
>I suggest to move the fix to[1], addr_width indicated in flash_info
>struct of the device can take precedence over SFDP.
>
>[1]https://elixir.bootlin.com/linux/latest/source/drivers/mtd/spi-nor/spi-nor.c#L4106
>
>
>> /* Fast Read settings. */
>> for (i = 0; i < ARRAY_SIZE(sfdp_bfpt_reads); i++) {
>> const struct sfdp_bfpt_read *rd = &sfdp_bfpt_reads[i];
>>
>
>--
>Regards
>Vignesh
Re: [PATCH v2 2/4] mm/sparse: Optimize sparse_add_one_section()
On 03/26/19 at 03:03pm, Michal Hocko wrote: > On Tue 26-03-19 21:45:22, Baoquan He wrote: > > On 03/26/19 at 11:17am, Michal Hocko wrote: > > > On Tue 26-03-19 18:08:17, Baoquan He wrote: > > > > On 03/26/19 at 10:29am, Michal Hocko wrote: > > > > > On Tue 26-03-19 17:02:25, Baoquan He wrote: > > > > > > Reorder the allocation of usemap and memmap since usemap allocation > > > > > > is much simpler and easier. Otherwise hard work is done to make > > > > > > memmap ready, then have to rollback just because of usemap > > > > > > allocation > > > > > > failure. > > > > > > > > > > Is this really worth it? I can see that !VMEMMAP is doing memmap size > > > > > allocation which would be 2MB aka costly allocation but we do not do > > > > > __GFP_RETRY_MAYFAIL so the allocator backs off early. > > > > > > > > In !VMEMMAP case, it truly does simple allocation directly. surely > > > > usemap which size is 32 is smaller. So it doesn't matter that much who's > > > > ahead or who's behind. However, this benefit a little in VMEMMAP case. > > > > > > How does it help there? The failure should be even much less probable > > > there because we simply fall back to a small 4kB pages and those > > > essentially never fail. > > > > OK, I am fine to drop it. Or only put the section existence checking > > earlier to avoid unnecessary usemap/memmap allocation? > > DO you have any data on how often that happens? Should basically never > happening, right? Oh, you think about it in this aspect. Yes, it rarely happens. Always allocating firstly can increase efficiency. Then I will just drop it.
Re: [PATCH v2 3/4] ARM: dts: da850-evm: enable cpufreq
On Fri, Mar 22, 2019 at 8:31 AM Bartosz Golaszewski wrote:
>
> From: Bartosz Golaszewski
>
> Enable cpufreq-dt support for da850-evm. The cvdd is supplied by the
> tps6507 pmic with configurable output voltage, so all operating points
> can be enabled.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/boot/dts/da850-evm.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
> index f04bc3e15332..a0a1b3dccf37 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -191,6 +191,18 @@
> };
> };
>
> +&cpu {
> + cpu-supply = <&vdcdc3_reg>;
> +};
> +
> +&opp_375 {
> + status = "okay";
> +};
> +
> +&opp_456 {
> + status = "okay";
> +};
I pulled part number for the processor used in the da850evm that Logic
PD produces, and it shows a imit of 375MHz. I cross-referenced the
processor part number with the description from a distributor, and the
part number also lists 375MHz, so I think we should leave 456
disabled.
adam
> +
> &sata {
> status = "okay";
> };
> --
> 2.20.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 5/5] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
Moi,
On Tue, Mar 26, 2019 at 04:06:33PM +0200, Heikki Krogerus wrote:
> Hi,
>
> On Tue, Mar 26, 2019 at 03:13:53PM +0200, Andy Shevchenko wrote:
> > > > > On ACPI based systems the resulting strings look like
> > > > >
> > > > > \_SB.PCI0.CIO2.port@1.endpoint@0
> > > > >
> > > > > where the nodes are separated by a dot (".") and the first three are
> > > > > ACPI device nodes and the latter two ACPI data nodes.
> > > >
> > > > Do we support swnode here?
> > >
> > > Good question. The swnodes have no hierarchy at the moment (they're only
> > > created for a struct device as a parent) and they do not have
> > > human-readable
> > > names. So I'd say it's not relevant right now. Should these two change,
> > > support for swnode could (and should) be added later on.
> >
> > Heikki, what do you think about this?
>
> Well, the swnodes do have hierarchy. That was kind of the whole point
> of introducing them. They now can also be named using "name" property.
> See commit 344798206f171c5abea7ab1f9762fa526d7f539d.
Right; I saw the function after initially replying to Andy but I missed
where the node name came from. :-) Now I know...
I can add support for swnode, too, if you like.
--
Terveisin,
Sakari Ailus
sakari.ai...@linux.intel.com
Re: [PATCH] libata: fix using DMA buffers on stack
On 3/25/19 9:07 PM, raymond pang wrote: > When CONFIG_VMAP_STACK=y, __pa() returns incorrect physical address for > a stack virtual address. Stack DMA buffers must be avoided. The patch looks fine, but it's white space mangled so it won't apply. Additionally, you don't need to use kzfree, just use kfree. -- Jens Axboe
Re: [PATCH 5/5] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
Hi Andy, On Tue, Mar 26, 2019 at 03:55:57PM +0200, Andy Shevchenko wrote: > On Tue, Mar 26, 2019 at 03:39:47PM +0200, Sakari Ailus wrote: > > On Tue, Mar 26, 2019 at 03:13:53PM +0200, Andy Shevchenko wrote: > > > On Sun, Mar 24, 2019 at 08:17:46PM +0200, Sakari Ailus wrote: > > > > The patch series by Petr I mentioned takes care about OF case. But it > > > doesn't > > > have covered yours by obvious reasons. > > > > Do you happen to have a pointer to it? > > Petr, can you share what is the state of affairs with that series? > > > The behaviour on others is different indeed, you're generally printing a > > single item at a time. The question rather is, whether we want to be > > compatible with %pOF going forward or not. I'd prefer that, so using the > > fwnode API would be easier. > > I would prefer to mimic %pOF and actually to deprecate it in favour of %pfw. > But it's just mine opinion. I'm skeptical about getting support on it. IMHO code that only deals with OF specifically is better to continue to use %pOF. You'd have of_fwnode_handle() in places where you just had the name of the node previously. What could be done though is to unify the implementations; that's something which the set does a little of already. Cc Rob, too. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH v11 6/8] rtc: bd70528: Initial support for ROHM bd70528 RTC
On Mon, 2019-03-25 at 18:04 +0100, Alexandre Belloni wrote: > On 25/03/2019 14:06:42+0200, Matti Vaittinen wrote: > > Support RTC block in ROHM bd70528 power management IC. Support > > getting and setting the time and date as well as arming an alarm > > which can also be used to wake the PMIC from standby state. > > > > HW supports wake interrupt only for the next 24 hours (sec, minute > > and hour information only) so we limit also the alarm interrupt to > > this 24 hours for the sake of consistency. > > > > Signed-off-by: Matti Vaittinen > > Acked-by: Alexandre Belloni > > > + r->time.hour |= BD70528_MASK_RTC_HOUR_24H; > > + r->day |= bin2bcd(t->tm_mday); > > + r->week |= bin2bcd(t->tm_wday); > > + r->month |= bin2bcd(t->tm_mon + 1); > > + r->year = bin2bcd(t->tm_year-100); > > If you ever have to resend, please add spaces around that - Good catch, thanks! I wonder why I didn't get checkpatch warning... I should've had one. (I usually do run checkpatch). Anyways, I'll add spaces if I need to respin the series. Br, Matti Vaittinen
Re: [PATCH 5/5] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
Hi,
On Tue, Mar 26, 2019 at 03:13:53PM +0200, Andy Shevchenko wrote:
> > > > On ACPI based systems the resulting strings look like
> > > >
> > > > \_SB.PCI0.CIO2.port@1.endpoint@0
> > > >
> > > > where the nodes are separated by a dot (".") and the first three are
> > > > ACPI device nodes and the latter two ACPI data nodes.
> > >
> > > Do we support swnode here?
> >
> > Good question. The swnodes have no hierarchy at the moment (they're only
> > created for a struct device as a parent) and they do not have human-readable
> > names. So I'd say it's not relevant right now. Should these two change,
> > support for swnode could (and should) be added later on.
>
> Heikki, what do you think about this?
Well, the swnodes do have hierarchy. That was kind of the whole point
of introducing them. They now can also be named using "name" property.
See commit 344798206f171c5abea7ab1f9762fa526d7f539d.
thanks,
--
heikki
RE: [PATCH v4 6/6] dt-bindings: fpga: Add bindings for ZynqMP fpga driver
Hi Rob, Thanks for the response. Please find my response inline. > -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Tuesday, March 26, 2019 12:49 AM > To: Nava kishore Manne > Cc: at...@kernel.org; m...@kernel.org; mark.rutl...@arm.com; Michal Simek > ; Rajan Vaja ; Jolly Shah > ; linux-f...@vger.kernel.org; devicet...@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > chinnikishore...@gmail.com > Subject: Re: [PATCH v4 6/6] dt-bindings: fpga: Add bindings for ZynqMP fpga > driver > > On Thu, Mar 14, 2019 at 07:31:22PM +0530, Nava kishore Manne wrote: > > Add documentation to describe Xilinx ZynqMP fpga driver bindings. > > > > Signed-off-by: Nava kishore Manne > > --- > > Changes for v4: > > -Modified binding description as suggested by Moritz Fischer. > > Changes for v3: > > -Removed PCAP as a child node to the FW and Created > > an independent node since PCAP driver is a consumer > > not a provider. > > Huh? > > It was the fpga-regions that I suggested should perhaps be at the top-level. > As > long as pcap is a function exposed by the firmware it should be a child of it. > Thanks for providing the clarification. Will address the above comments in the next version. Regards, Navakishore.
Re: [PATCH v11 6/8] rtc: bd70528: Initial support for ROHM bd70528 RTC
On 26/03/2019 13:51:40+, Vaittinen, Matti wrote: > On Mon, 2019-03-25 at 18:04 +0100, Alexandre Belloni wrote: > > On 25/03/2019 14:06:42+0200, Matti Vaittinen wrote: > > > Support RTC block in ROHM bd70528 power management IC. Support > > > getting and setting the time and date as well as arming an alarm > > > which can also be used to wake the PMIC from standby state. > > > > > > HW supports wake interrupt only for the next 24 hours (sec, minute > > > and hour information only) so we limit also the alarm interrupt to > > > this 24 hours for the sake of consistency. > > > > > > Signed-off-by: Matti Vaittinen > > > > Acked-by: Alexandre Belloni > > > > > + r->time.hour |= BD70528_MASK_RTC_HOUR_24H; > > > + r->day |= bin2bcd(t->tm_mday); > > > + r->week |= bin2bcd(t->tm_wday); > > > + r->month |= bin2bcd(t->tm_mon + 1); > > > + r->year = bin2bcd(t->tm_year-100); > > > > If you ever have to resend, please add spaces around that - > > Good catch, thanks! I wonder why I didn't get checkpatch warning... I > should've had one. (I usually do run checkpatch). > checkpatch --strict would tell you. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v2 2/4] mm/sparse: Optimize sparse_add_one_section()
On Tue 26-03-19 21:45:22, Baoquan He wrote: > On 03/26/19 at 11:17am, Michal Hocko wrote: > > On Tue 26-03-19 18:08:17, Baoquan He wrote: > > > On 03/26/19 at 10:29am, Michal Hocko wrote: > > > > On Tue 26-03-19 17:02:25, Baoquan He wrote: > > > > > Reorder the allocation of usemap and memmap since usemap allocation > > > > > is much simpler and easier. Otherwise hard work is done to make > > > > > memmap ready, then have to rollback just because of usemap allocation > > > > > failure. > > > > > > > > Is this really worth it? I can see that !VMEMMAP is doing memmap size > > > > allocation which would be 2MB aka costly allocation but we do not do > > > > __GFP_RETRY_MAYFAIL so the allocator backs off early. > > > > > > In !VMEMMAP case, it truly does simple allocation directly. surely > > > usemap which size is 32 is smaller. So it doesn't matter that much who's > > > ahead or who's behind. However, this benefit a little in VMEMMAP case. > > > > How does it help there? The failure should be even much less probable > > there because we simply fall back to a small 4kB pages and those > > essentially never fail. > > OK, I am fine to drop it. Or only put the section existence checking > earlier to avoid unnecessary usemap/memmap allocation? DO you have any data on how often that happens? Should basically never happening, right? -- Michal Hocko SUSE Labs
Re: [PATCH] perf machine: Update kernel map address and re-order properly
Hello,
On Tue, Mar 26, 2019 at 6:12 PM liwei (GF) wrote:
>
> Hi Arnaldo,
>
> Please shoot a glance at this modification, i think this issue is influential.
>
> On 2019/2/28 19:28, Jiri Olsa Wrote:
> > On Thu, Feb 28, 2019 at 05:20:03PM +0800, Wei Li wrote:
> >> Since commit 1fb87b8e9599 ("perf machine: Don't search for active kernel
> >> start in __machine__create_kernel_maps"), the
> >> __machine__create_kernel_maps()
> >> just create a map what start and end are both zero. Though the address
> >> will be
> >> updated later, the order of map in the rbtree may be incorrect.
> >>
> >> The commit ee05d21791db ("perf machine: Set main kernel end address
> >> properly")
> >> fixed the logic in machine__create_kernel_maps(), but it's still wrong in
> >> function machine__process_kernel_mmap_event().
> >>
> >> To reproduce this issue, we need an environment which the module address
> >> is before the kernel text segment. I tested it on an aarch64 machine with
> >> kernel 4.19.25:
> >
> > so that was the missing piece.. nice
> >
> >>
> >> [root@localhost hulk]# grep _stext /proc/kallsyms
> >> 08081000 T _stext
> >> [root@localhost hulk]# grep _etext /proc/kallsyms
> >> 0978 R _etext
> >> [root@localhost hulk]# tail /proc/modules
> >> hisi_sas_v2_hw 77824 0 - Live 0x0191d000
> >> nvme_core 126976 7 nvme, Live 0x018b6000
> >> mdio 20480 1 ixgbe, Live 0x018ab000
> >> hisi_sas_main 106496 1 hisi_sas_v2_hw, Live 0x01861000
> >> hns_mdio 20480 2 - Live 0x01822000
> >> hnae 28672 3 hns_dsaf,hns_enet_drv, Live 0x01815000
> >> dm_mirror 40960 0 - Live 0x01804000
> >> dm_region_hash 32768 1 dm_mirror, Live 0x017f5000
> >> dm_log 32768 2 dm_mirror,dm_region_hash, Live 0x017e7000
> >> dm_mod 315392 17 dm_mirror,dm_log, Live 0x0178
> >> [root@localhost hulk]#
> >>
> >> Before fix:
> >>
> >> [root@localhost bin]# perf record sleep 3
> >> [ perf record: Woken up 1 times to write data ]
> >> [ perf record: Captured and wrote 0.011 MB perf.data (9 samples) ]
> >> [root@localhost bin]# perf buildid-list -i perf.data
> >> 4c4e46c971ca935f781e603a09b52a92e8bdfee8 [vdso]
> >> [root@localhost bin]# perf buildid-list -i perf.data -H
> >> /proc/kcore
> >> [root@localhost bin]#
> >>
> >> After fix:
> >>
> >> [root@localhost tools]# ./perf/perf record sleep 3
> >> [ perf record: Woken up 1 times to write data ]
> >> [ perf record: Captured and wrote 0.011 MB perf.data (9 samples) ]
> >> [root@localhost tools]# ./perf/perf buildid-list -i perf.data
> >> 28a6c690262896dbd1b5e1011ed81623e6db0610 [kernel.kallsyms]
> >> 106c14ce6e4acea3453e484dc604d6f08a2f [vdso]
> >> [root@localhost tools]# ./perf/perf buildid-list -i perf.data -H
> >> 28a6c690262896dbd1b5e1011ed81623e6db0610 /proc/kcore
> >>
> >> Signed-off-by: Wei Li
> >
> > Acked-by: Jiri Olsa
Acked-by: Namhyung Kim
Thanks,
Namhyung
Re: [PATCH v2 1/4] ARM: davinci: fix cpufreq registration on da850-evm
On Fri, Mar 22, 2019 at 8:31 AM Bartosz Golaszewski wrote:
>
> From: Bartosz Golaszewski
>
> The system_rev variable is never set on davinci and is always 0, so
> we're using the default max operating point of 300MHz. The cvdd supply
> comes from the tps6507 pmic and the voltage can go all the way to 1.3V
> so the maximum supported rate should be 456MHz.
My understanding is that only certain revisions of the silicon can go
to 456MHz. The L138's Datasheet lists both a 456 and 375 version. I
cannot find a way to read a register to determine which version of the
silicon is available. Maybe Sekhar can confirm.
adam
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/mach-davinci/board-da850-evm.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c
> b/arch/arm/mach-davinci/board-da850-evm.c
> index 1fdc9283a8c5..58b2a485b527 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1155,17 +1155,7 @@ static struct edma_rsv_info *da850_edma_rsv[2] = {
> #ifdef CONFIG_CPU_FREQ
> static __init int da850_evm_init_cpufreq(void)
> {
> - switch (system_rev & 0xF) {
> - case 3:
> - da850_max_speed = 456000;
> - break;
> - case 2:
> - da850_max_speed = 408000;
> - break;
> - case 1:
> - da850_max_speed = 372000;
> - break;
> - }
> + da850_max_speed = 456000;
>
> return da850_register_cpufreq("pll0_sysclk3");
> }
> --
> 2.20.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [RFC PATCH 0/10] Another Approach to Use PMEM as NUMA Node
On Sat 23-03-19 12:44:25, Yang Shi wrote: > > With Dave Hansen's patches merged into Linus's tree > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c221c0b0308fd01d9fb33a16f64d2fd95f8830a4 > > PMEM could be hot plugged as NUMA node now. But, how to use PMEM as NUMA node > effectively and efficiently is still a question. > > There have been a couple of proposals posted on the mailing list [1] [2]. > > The patchset is aimed to try a different approach from this proposal [1] > to use PMEM as NUMA nodes. > > The approach is designed to follow the below principles: > > 1. Use PMEM as normal NUMA node, no special gfp flag, zone, zonelist, etc. > > 2. DRAM first/by default. No surprise to existing applications and default > running. PMEM will not be allocated unless its node is specified explicitly > by NUMA policy. Some applications may be not very sensitive to memory latency, > so they could be placed on PMEM nodes then have hot pages promote to DRAM > gradually. Why are you pushing yourself into the corner right at the beginning? If the PMEM is exported as a regular NUMA node then the only difference should be performance characteristics (module durability which shouldn't play any role in this particular case, right?). Applications which are already sensitive to memory access should better use proper binding already. Some NUMA topologies might have quite a large interconnect penalties already. So this doesn't sound like an argument to me, TBH. > 5. Control memory allocation and hot/cold pages promotion/demotion on per VMA > basis. What does that mean? Anon vs. file backed memory? [...] > 2. Introduce a new mempolicy, called MPOL_HYBRID to keep other mempolicy > semantics intact. We would like to have memory placement control on per > process > or even per VMA granularity. So, mempolicy sounds more reasonable than > madvise. > The new mempolicy is mainly used for launching processes on PMEM nodes then > migrate hot pages to DRAM nodes via NUMA balancing. MPOL_BIND could bind to > PMEM nodes too, but migrating to DRAM nodes would just break the semantic of > it. MPOL_PREFERRED can't constraint the allocation to PMEM nodes. So, it > sounds > a new mempolicy is needed to fulfill the usecase. The above restriction pushes you to invent an API which is not really trivial to get right and it seems quite artificial to me already. > 3. The new mempolicy would promote pages to DRAM via NUMA balancing. IMHO, I > don't think kernel is a good place to implement sophisticated hot/cold page > distinguish algorithm due to the complexity and overhead. But, kernel should > have such capability. NUMA balancing sounds like a good start point. This is what the kernel does all the time. We call it memory reclaim. > 4. Promote twice faulted page. Use PG_promote to track if a page is faulted > twice. This is an optimization to NUMA balancing to reduce the migration > thrashing and overhead for migrating from PMEM. I am sorry, but page flags are an extremely scarce resource and a new flag is extremely hard to get. On the other hand we already do have use-twice detection for mapped page cache (see page_check_references). I believe we can generalize that to anon pages as well. > 5. When DRAM has memory pressure, demote page to PMEM via page reclaim path. > This is quite similar to other proposals. Then NUMA balancing will promote > page to DRAM as long as the page is referenced again. But, the > promotion/demotion still assumes two tier main memory. And, the demotion may > break mempolicy. Yes, this sounds like a good idea to me ;) > 6. Anonymous page only for the time being since NUMA balancing can't promote > unmapped page cache. As long as the nvdimm access is faster than the regular storage then using any node (including pmem one) should be OK. -- Michal Hocko SUSE Labs
[PATCH v3 1/2] iio: Add driver for TLA202x ADCs
Basic driver for Texas Instruments TLA202x series ADCs. Input
channels are configurable from the device tree. Input scaling
is supported. Trigger buffer support is not yet implemented.
Signed-off-by: Ibtsam Ul-Haq
---
Changes in v3:
- Added locking when setting SCALE
- Removed deep-indented goto in read_raw
- Other minor points mentioned in v2 review
---
Changes in v2:
- changed commit message
- Added mutex to protect channel selection
- Removed redundant mutex around i2c transfers
- Removed PROCESSED channel output
- Added SCALE info
- Removed Continuous Mode since continuous read not supported
- Removed SAMP_FREQ info since continuous read not supported
---
---
drivers/iio/adc/Kconfig | 11 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/ti-tla2024.c | 460 +++
3 files changed, 472 insertions(+)
create mode 100644 drivers/iio/adc/ti-tla2024.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 5762565..8c214c8 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -816,6 +816,17 @@ config TI_AM335X_ADC
To compile this driver as a module, choose M here: the module will be
called ti_am335x_adc.
+config TI_TLA2024
+ tristate "Texas Instruments TLA2024/TLA2022/TLA2021 ADC driver"
+ depends on OF
+ depends on I2C
+ help
+ Say yes here to build support for Texas Instruments TLA2024,
+ TLA2022 or TLA2021 I2C Analog to Digital Converters.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ti-tla2024.
+
config TI_TLC4541
tristate "Texas Instruments TLC4541 ADC driver"
depends on SPI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 9874e05..819f35b 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_TI_ADS7950) += ti-ads7950.o
obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
obj-$(CONFIG_TI_TLC4541) += ti-tlc4541.o
+obj-$(CONFIG_TI_TLA2024) += ti-tla2024.o
obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
obj-$(CONFIG_VF610_ADC) += vf610_adc.o
diff --git a/drivers/iio/adc/ti-tla2024.c b/drivers/iio/adc/ti-tla2024.c
new file mode 100644
index 000..f0eed4a
--- /dev/null
+++ b/drivers/iio/adc/ti-tla2024.c
@@ -0,0 +1,460 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Texas Instruments TLA2021/TLA2022/TLA2024 12-bit ADC driver
+ *
+ * Copyright (C) 2019 Koninklijke Philips N.V.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define TLA2024_DATA 0x00
+#define TLA2024_DATA_RES_MASK GENMASK(15, 4)
+#define TLA2024_DATA_RES_SHIFT 4
+
+#define TLA2024_CONF 0x01
+#define TLA2024_CONF_OS_MASK BIT(15)
+#define TLA2024_CONF_OS_SHIFT 15
+#define TLA2024_CONF_MUX_MASK GENMASK(14, 12)
+#define TLA2024_CONF_MUX_SHIFT 12
+#define TLA2024_CONF_PGA_MASK GENMASK(11, 9)
+#define TLA2024_CONF_PGA_SHIFT 9
+#define TLA2024_CONF_MODE_MASK BIT(8)
+#define TLA2024_CONF_MODE_SHIFT 8
+#define TLA2024_CONF_DR_MASK GENMASK(7, 5)
+#define TLA2024_CONF_DR_SHIFT 5
+
+#define TLA2024_CONV_RETRY 10
+
+struct tla202x_model {
+ unsigned int mux_available;
+ unsigned int pga_available;
+};
+
+struct tla2024 {
+ struct i2c_client *i2c;
+ struct tla202x_model *model;
+ struct mutex lock;
+ u8 used_mux_channels;
+};
+
+struct tla2024_channel {
+ int ainp;
+ int ainn;
+ const char *datasheet_name;
+ bool differential;
+};
+
+static const struct tla2024_channel tla2024_all_channels[] = {
+ {0, 1, "AIN0-AIN1", 1},
+ {0, 3, "AIN0-AIN3", 1},
+ {1, 3, "AIN1-AIN3", 1},
+ {2, 3, "AIN2-AIN3", 1},
+ {0, -1, "AIN0", 0},
+ {1, -1, "AIN1", 0},
+ {2, -1, "AIN2", 0},
+ {3, -1, "AIN3", 0},
+};
+
+static int tla2024_find_chan_idx(u32 ainp_in, u32 ainn_in, u16 *idx)
+{
+ u16 i;
+
+ for (i = 0; i < ARRAY_SIZE(tla2024_all_channels); i++) {
+ if ((tla2024_all_channels[i].ainp == ainp_in) &&
+ (tla2024_all_channels[i].ainn == ainn_in)) {
+ *idx = i;
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+
+#define TLA202x_MODEL(_mux, _pga) \
+ { \
+ .mux_available = (_mux),\
+ .pga_available = (_pga),\
+ }
+
+enum tla2024_model_id {
+ TLA2021 = 0,
+ TLA2022 = 1,
+ TLA2024 = 2,
+};
+
+static struct tla202x_model tla202x_models[] = {
+ [TLA2021] = TLA202x_MODEL(0, 0),
+ [TLA2022] = TLA202x_MODEL(0, 1),
+ [TLA2024] = TLA202x_MODEL(1, 1),
+};
+
+static const int tla2024_scale[] = { /* scale, int plus micro */
+ 3, 0, 2, 0, 1, 0, 0, 50, 0, 25, 0, 125000 };
+
+static int tla2024_get(struct tla2024 *priv, u8 addr, u16 mask,
+
Re: [PATCH v2] x86/boot: Use EFI setup data if provided
On Mon, Mar 25, 2019 at 11:10:01PM +, Junichi Nomura wrote: > efi_get_rsdp_addr() and kexec_get_rsdp_addr() could be implemented > like this (sorry about the pseudo code): This doesn't look like what I suggested: > So efi_get_rsdp_addr() needs to be refactored in such a way so that at > least the loop towards the end gets carved out into a separate function > - __efi_get_rsdp_addr() or so - which gets config_tables, nr_tables and > size as arguments and finds the RSDP address in the kexec-ed kernel. You need to carve out the loop at the end and make it into a separate __efi_get_rsdp_addr() function which gets the physical or the virtual address. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v2 2/4] mm/sparse: Optimize sparse_add_one_section()
On Tue, Mar 26, 2019 at 09:45:22PM +0800, Baoquan He wrote:
> On 03/26/19 at 11:17am, Michal Hocko wrote:
> > On Tue 26-03-19 18:08:17, Baoquan He wrote:
> > > On 03/26/19 at 10:29am, Michal Hocko wrote:
> > > > On Tue 26-03-19 17:02:25, Baoquan He wrote:
> > > > > Reorder the allocation of usemap and memmap since usemap allocation
> > > > > is much simpler and easier. Otherwise hard work is done to make
> > > > > memmap ready, then have to rollback just because of usemap allocation
> > > > > failure.
> > > >
> > > > Is this really worth it? I can see that !VMEMMAP is doing memmap size
> > > > allocation which would be 2MB aka costly allocation but we do not do
> > > > __GFP_RETRY_MAYFAIL so the allocator backs off early.
> > >
> > > In !VMEMMAP case, it truly does simple allocation directly. surely
> > > usemap which size is 32 is smaller. So it doesn't matter that much who's
> > > ahead or who's behind. However, this benefit a little in VMEMMAP case.
> >
> > How does it help there? The failure should be even much less probable
> > there because we simply fall back to a small 4kB pages and those
> > essentially never fail.
>
> OK, I am fine to drop it. Or only put the section existence checking
> earlier to avoid unnecessary usemap/memmap allocation?
>
>
> From 7594b86ebf5d6fcc8146eca8fc5625f1961a15b1 Mon Sep 17 00:00:00 2001
> From: Baoquan He
> Date: Tue, 26 Mar 2019 18:48:39 +0800
> Subject: [PATCH] mm/sparse: Check section's existence earlier in
> sparse_add_one_section()
>
> No need to allocate usemap and memmap if section has been present.
> And can clean up the handling on failure.
>
> Signed-off-by: Baoquan He
> ---
> mm/sparse.c | 21 -
> 1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 363f9d31b511..f564b531e0f7 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -714,7 +714,13 @@ int __meminit sparse_add_one_section(int nid, unsigned
> long start_pfn,
> ret = sparse_index_init(section_nr, nid);
> if (ret < 0 && ret != -EEXIST)
> return ret;
> - ret = 0;
> +
> + ms = __pfn_to_section(start_pfn);
> + if (ms->section_mem_map & SECTION_MARKED_PRESENT) {
> + ret = -EEXIST;
> + goto out;
return -EEXIST; ?
> + }
> +
> memmap = kmalloc_section_memmap(section_nr, nid, altmap);
> if (!memmap)
> return -ENOMEM;
> @@ -724,12 +730,6 @@ int __meminit sparse_add_one_section(int nid, unsigned
> long start_pfn,
> return -ENOMEM;
> }
>
> - ms = __pfn_to_section(start_pfn);
> - if (ms->section_mem_map & SECTION_MARKED_PRESENT) {
> - ret = -EEXIST;
> - goto out;
> - }
> -
> /*
>* Poison uninitialized struct pages in order to catch invalid flags
>* combinations.
> @@ -739,12 +739,7 @@ int __meminit sparse_add_one_section(int nid, unsigned
> long start_pfn,
> section_mark_present(ms);
> sparse_init_one_section(ms, section_nr, memmap, usemap);
>
> -out:
> - if (ret < 0) {
> - kfree(usemap);
> - __kfree_section_memmap(memmap, altmap);
> - }
> - return ret;
> + return 0;
> }
>
> #ifdef CONFIG_MEMORY_HOTREMOVE
> --
> 2.17.2
>
--
Sincerely yours,
Mike.
[PATCH v3 2/2] dt-bindings: iio: Add bindings for TI TLA202x ADCs
This adds devicetree bindings for TI TLA202x ADCs.
Signed-off-by: Ibtsam Ul-Haq
---
.../devicetree/bindings/iio/adc/ti-tla2024.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-tla2024.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/ti-tla2024.txt
b/Documentation/devicetree/bindings/iio/adc/ti-tla2024.txt
new file mode 100644
index 000..a4934df
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti-tla2024.txt
@@ -0,0 +1,45 @@
+Texas Instruments' TLA2021/TLA2022/TLA2024 12-bit ADC driver
+
+Required properties:
+
+- compatible: should be one of:
+ "ti,tla2024"
+ "ti,tla2022"
+ "ti,tla2021"
+
+- reg: should contain the I2C Address of the device
+
+Required subnodes:
+
+The ADC channels are configured as subnodes of the ADC.
+The channels can be single-ended or differential, the input pins are
+also set in the subnode.
+
+Possible channels in TLA2024:
+ single: <0>, <1>, <2>, <3>
+ differential: <0 1>, <0 3>, <1 3>, <2 3>
+
+In TLA2021/TLA2022 only the differential channel <0 1> is allowed.
+
+Example:
+
+tla2024_0: adc0@49 {
+ compatible = "ti,tla2024";
+ reg = <0x49>;
+
+ v0@0 {
+ single-channel = <0>;
+ };
+
+ v1@1 {
+ single-channel = <1>;
+ };
+
+ v23@2 {
+ diff-channels = <2 3>;
+ };
+
+ v01@3 {
+ diff-channels = <0 1>;
+ };
+};
--
2.7.4
Re: [PATCH 5/5] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
On Tue, Mar 26, 2019 at 03:39:47PM +0200, Sakari Ailus wrote: > On Tue, Mar 26, 2019 at 03:13:53PM +0200, Andy Shevchenko wrote: > > On Sun, Mar 24, 2019 at 08:17:46PM +0200, Sakari Ailus wrote: > > The patch series by Petr I mentioned takes care about OF case. But it > > doesn't > > have covered yours by obvious reasons. > > Do you happen to have a pointer to it? Petr, can you share what is the state of affairs with that series? > The behaviour on others is different indeed, you're generally printing a > single item at a time. The question rather is, whether we want to be > compatible with %pOF going forward or not. I'd prefer that, so using the > fwnode API would be easier. I would prefer to mimic %pOF and actually to deprecate it in favour of %pfw. But it's just mine opinion. I'm skeptical about getting support on it. -- With Best Regards, Andy Shevchenko
Re: [PATCH V3 01/23] perf/x86: Support outputting XMM registers
On 3/26/2019 9:47 AM, Thomas Gleixner wrote:
On Tue, 26 Mar 2019, Liang, Kan wrote:
On 3/25/2019 8:11 PM, Thomas Gleixner wrote:
-#define REG_RESERVED (~((1ULL << PERF_REG_X86_MAX) - 1ULL))
+#define REG_RESERVED 0
What's the point of having this around?
I once thought it may be kept for future extension if we have more regs.
But, yes, we should remove it completely for now.
Thanks,
Kan
int perf_reg_validate(u64 mask)
{
if (!mask || mask & REG_RESERVED)
return -EINVAL;
mask & 0 == 0, right? So which bits are you checking here?
Thanks,
tglx
Re: [PATCH] cpu/hotplug: Create SMT sysfs interface for all arches
On Tue, 26 Mar 2019, Josh Poimboeuf wrote: > On Sun, Mar 24, 2019 at 09:13:18PM +0100, Thomas Gleixner wrote: > > Second thoughts. I'm not really convinced that changing the meaning of > > notsupported and in fact overloading it, is the right thing to do. > > notsupported means now: > > > > CPU does not support it - OR - architecture does not support it > > > > That's not pretty and we are surely not short of state space. There are > > several options for handling this: > > > > 1) Do not expose the state file, just expose the active file > > > > 2) Expose the state file, but return -ENOTSUPP or some other sensible error > > code > > > > 3) Expose the state file and let show return 'notimplemented' which is > > more accurate. That wouldn't even require to expand the state space > > enum. It just can be returned unconditionally. > > Makes sense. I like #3. I can post another version. Yes, please. Thanks, tglx
Re: CONFIG_DEBUG_VIRTUAL breaks boot on x86-32
Does this still happen on 5.1-rc2? Do you have idea as to what max_low_pfn() gets set to on your system at boot time? From the screen shot I'm guessing it MIGHT be 0x373fe, but it's hard to know for sure. > On Mar 21, 2019, at 2:22 PM, Meelis Roos wrote: > > I tried to debug another problem and turned on most debug options for memory. > The resulting kernel failed to boot. > > Bisecting the configurations led to CONFIG_DEBUG_VIRTUAL - if I turned it on > in addition to some other debug options, the machine crashed with > > kernel BUG at arch/x86/mm/physaddr.c:79! > > Screenshot at http://kodu.ut.ee/~mroos/debug_virtual-boot-hang-1.jpg > > The machine was Athlon XP with VIA KT600 chipset and 2G RAM. > > -- > Meelis Roos >
Re: [RFC PATCH v4 0/8] This patch-set is to enable Guest CET support
On Mon, Mar 18, 2019 at 11:03:43PM +0800, Yang Weijiang wrote: > Control-flow Enforcement Technology (CET) provides protection against > return/jump-oriented programming (ROP) attacks. To make kvm Guest OS own > the capability, this patch-set is required. It enables CET related CPUID > report, xsaves/xrstors, vmx entry configuration etc. for Guest OS. > > PATCH 1: Define CET VMCS fields and bits. > PATCH 2/3 : Report CET feature support in CPUID. > PATCH 4: Fix xsaves size calculation issue. > PATCH 5: Pass through CET MSRs to Guest. > PATCH 6: Set Guest CET state auto loading bit. > PATCH 7: Load Guest fpu state when accessing CET XSAVES managed MSRs. > PATCH 8: Add CET MSR user space access interface. > > Changelog: > > v4: > - Add Sean's patch for loading Guest fpu state before access XSAVES >managed CET MSRs. > - Melt down CET bits setting into CPUID configuration patch. > - Add VMX interface to query Host XSS. > - Check Host and Guest XSS support bits before set Guest XSS. > - Make Guest SHSTK and IBT feature enabling independent. > - Do not report CET support to Guest when Host CET feature is >Disabled. > > v3: > - Modified patches to make Guest CET independent to Host enabling. > - Added patch 8 to add user space access for Guest CET MSR access. > - Modified code comments and patch description to reflect changes. > > v2: > - Re-ordered patch sequence, combined one patch. > - Added more description for CET related VMCS fields. > - Added Host CET capability check while enabling Guest CET loading bit. > - Added Host CET capability check while reporting Guest CPUID(EAX=7, >EXC=0). > - Modified code in reporting Guest CPUID(EAX=D,ECX>=1), make it clearer. > - Added Host and Guest XSS mask check while setting bits for Guest XSS. > > > Sean Christopherson (1): > KVM:x86: load guest fpu state when accessing MSRs managed by XSAVES > > Yang Weijiang (7): > KVM:VMX: Define CET VMCS fields and bits > KVM:CPUID: Add CET CPUID support for Guest > KVM:CPUID: Fix xsaves area size calculation for CPUID.(EAX=0xD,ECX=1). > KVM:VMX: Pass through host CET related MSRs to Guest. > KVM:VMX: Load Guest CET via VMCS when CET is enabled in Guest > KVM:x86: Allow Guest to set supported bits in XSS > KVM:x86: Add user-space read/write interface for CET MSRs > > arch/x86/include/asm/kvm_host.h | 5 +- > arch/x86/include/asm/msr-index.h | 2 + > arch/x86/include/asm/vmx.h | 8 +++ > arch/x86/kvm/cpuid.c | 53 ++-- > arch/x86/kvm/vmx.c | 86 ++-- > arch/x86/kvm/x86.c | 32 +++- > arch/x86/kvm/x86.h | 4 ++ > 7 files changed, 167 insertions(+), 23 deletions(-) > > -- > 2.17.1 Hi, Paolo and Sean, Do you have any comments on v4 patches?
Re: [PATCH v2] arm64: dts: rockchip: add rk3399 UART DMAs
Hello Robin, Sorry for inconvenience. Since I don't adhere enabling DMA for UARTs, please revert my patch if you need. BTW, there are DMA properties in RK3328 device-tree like as this patch. RK3328 UART DMA could not work correctly too...?? Best Regards, Katsuhiro Suzuki On 2019/03/26 20:48, Robin Murphy wrote: On 25/03/2019 12:34, Heiko Stuebner wrote: Am Donnerstag, 21. März 2019, 17:22:44 CET schrieb Katsuhiro Suzuki: Add UART dma channels as specified by the rk3399 TRM. Refer: RK3399 TRM V1.4: Chapter 12 DMA Controller Signed-off-by: Katsuhiro Suzuki applied for 5.2 As a heads-up, I did manage to try my board with this patch applied over the weekend, and it makes probing the bluetooth adapter fail with communication errors, so I'm not sure the 8250 and pl330 drivers are really cooperating well enough :( Robin.
Re: [RESEND PATCH v6 06/11] mfd: max77650: new core mfd driver
pt., 22 mar 2019 o 10:12 Pavel Machek napisał(a): > > On Mon 2019-03-18 18:42:23, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > Add the core mfd driver for max77650 PMIC. We define five sub-devices > > for which the drivers will be added in subsequent patches. > > > > Signed-off-by: Bartosz Golaszewski > > --- > > drivers/mfd/Kconfig | 14 +++ > > drivers/mfd/Makefile | 1 + > > drivers/mfd/max77650.c | 234 +++ > > include/linux/mfd/max77650.h | 59 + > > 4 files changed, 308 insertions(+) > > create mode 100644 drivers/mfd/max77650.c > > create mode 100644 include/linux/mfd/max77650.h > > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > > index 0ce2d8dfc5f1..ade04e124aa0 100644 > > --- a/drivers/mfd/Kconfig > > +++ b/drivers/mfd/Kconfig > > @@ -733,6 +733,20 @@ config MFD_MAX77620 > > provides common support for accessing the device; additional drivers > > must be enabled in order to use the functionality of the device. > > > > +config MFD_MAX77650 > > + tristate "Maxim MAX77650/77651 PMIC Support" > > + depends on I2C > > + depends on OF || COMPILE_TEST > > This says it will compile ok in !OF case. Will it? > It will compile because the stubs for OF functions will be provided - it just won't work, because they won't be implemented. Bart > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] KVM: x86: nVMX: allow RSM to restore VMXE CR4 flag
Liran Alon writes:
>> On 26 Mar 2019, at 15:07, Vitaly Kuznetsov wrote:
>>
>> Commit 5bea5123cbf0 ("KVM: VMX: check nested state and CR4.VMXE against
>> SMM") introduced a check to vmx_set_cr4() forbidding to set VMXE from SMM.
>> The check is correct, however, there is a special case when RSM is called
>> to leave SMM: rsm_enter_protected_mode() is called with HF_SMM_MASK still
>> set and in case VMXE was set before entering SMM we're failing to return.
>>
>> Resolve the issue by temporary dropping HF_SMM_MASK around set_cr4() calls
>> when ops->set_cr() is called from RSM.
>>
>> Reported-by: Jon Doron
>> Suggested-by: Liran Alon
>> Fixes: 5bea5123cbf0 ("KVM: VMX: check nested state and CR4.VMXE against SMM")
>> Signed-off-by: Vitaly Kuznetsov
>
> Patch looks good to me.
> Reviewed-by: Liran Alon
Thanks!
>
>> ---
>> - Instread of putting the temporary HF_SMM_MASK drop to
>> rsm_enter_protected_mode() (as was suggested by Liran), move it to
>> emulator_set_cr() modifying its interface. emulate.c seems to be
>> vcpu-specifics-free at this moment, we may want to keep it this way.
>> - It seems that Hyper-V+UEFI on KVM is still broken, I'm observing sporadic
>> hangs even with this patch. These hangs, however, seem to be unrelated to
>> rsm.
>
> Feel free to share details on these hangs ;)
>
You've asked for it)
The immediate issue I'm observing is some sort of a lockup which is easy
to trigger with e.g. "-usb -device usb-tablet" on Qemu command line; it
seems we get too many interrupts and combined with preemtion timer for
L2 we're not making any progress:
kvm_userspace_exit: reason KVM_EXIT_IOAPIC_EOI (26)
kvm_set_irq: gsi 18 level 1 source 0
kvm_msi_set_irq: dst 0 vec 177 (Fixed|physical|level)
kvm_apic_accept_irq: apicid 0 vec 177 (Fixed|edge)
kvm_fpu: load
kvm_entry:vcpu 0
kvm_exit: reason VMRESUME rip 0xf8848115 info 0 0
kvm_entry:vcpu 0
kvm_exit: reason PREEMPTION_TIMER rip 0xf800f4448e01 info 0 0
kvm_nested_vmexit:rip f800f4448e01 reason PREEMPTION_TIMER info1 0
info2 0 int_info 0 int_info_err 0
kvm_nested_vmexit_inject: reason EXTERNAL_INTERRUPT info1 0 info2 0 int_info
80b1 int_info_err 0
kvm_entry:vcpu 0
kvm_exit: reason APIC_ACCESS rip 0xf881fe11 info 10b0 0
kvm_apic: apic_write APIC_EOI = 0x0
kvm_eoi: apicid 0 vector 177
kvm_fpu: unload
kvm_userspace_exit: reason KVM_EXIT_IOAPIC_EOI (26)
...
(and the pattern repeats)
Maybe it is a usb-only/Qemu-only problem, maybe not.
--
Vitaly
Re: [PATCH V3 01/23] perf/x86: Support outputting XMM registers
On Tue, 26 Mar 2019, Liang, Kan wrote:
> On 3/25/2019 8:11 PM, Thomas Gleixner wrote:
>
> -#define REG_RESERVED (~((1ULL << PERF_REG_X86_MAX) - 1ULL))
> +#define REG_RESERVED 0
What's the point of having this around?
> int perf_reg_validate(u64 mask)
> {
> if (!mask || mask & REG_RESERVED)
> return -EINVAL;
mask & 0 == 0, right? So which bits are you checking here?
Thanks,
tglx
[PATCH] Staging: emxx_udc: emxx_udc: Fixed a coding style error
Removed unnecessary parentheses. Signed-off-by: Will Cunningham --- drivers/staging/emxx_udc/emxx_udc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c index a913d40f0801..80a906742cdc 100644 --- a/drivers/staging/emxx_udc/emxx_udc.c +++ b/drivers/staging/emxx_udc/emxx_udc.c @@ -136,7 +136,7 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req) struct usb_ctrlrequest *p_ctrl; struct nbu2ss_udc *udc; - if ((!_ep) || (!_req)) + if (!_ep || !_req) return; udc = (struct nbu2ss_udc *)_req->context; -- 2.19.2
Re: [PATCH v2 2/4] mm/sparse: Optimize sparse_add_one_section()
On 03/26/19 at 11:17am, Michal Hocko wrote:
> On Tue 26-03-19 18:08:17, Baoquan He wrote:
> > On 03/26/19 at 10:29am, Michal Hocko wrote:
> > > On Tue 26-03-19 17:02:25, Baoquan He wrote:
> > > > Reorder the allocation of usemap and memmap since usemap allocation
> > > > is much simpler and easier. Otherwise hard work is done to make
> > > > memmap ready, then have to rollback just because of usemap allocation
> > > > failure.
> > >
> > > Is this really worth it? I can see that !VMEMMAP is doing memmap size
> > > allocation which would be 2MB aka costly allocation but we do not do
> > > __GFP_RETRY_MAYFAIL so the allocator backs off early.
> >
> > In !VMEMMAP case, it truly does simple allocation directly. surely
> > usemap which size is 32 is smaller. So it doesn't matter that much who's
> > ahead or who's behind. However, this benefit a little in VMEMMAP case.
>
> How does it help there? The failure should be even much less probable
> there because we simply fall back to a small 4kB pages and those
> essentially never fail.
OK, I am fine to drop it. Or only put the section existence checking
earlier to avoid unnecessary usemap/memmap allocation?
>From 7594b86ebf5d6fcc8146eca8fc5625f1961a15b1 Mon Sep 17 00:00:00 2001
From: Baoquan He
Date: Tue, 26 Mar 2019 18:48:39 +0800
Subject: [PATCH] mm/sparse: Check section's existence earlier in
sparse_add_one_section()
No need to allocate usemap and memmap if section has been present.
And can clean up the handling on failure.
Signed-off-by: Baoquan He
---
mm/sparse.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 363f9d31b511..f564b531e0f7 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -714,7 +714,13 @@ int __meminit sparse_add_one_section(int nid, unsigned
long start_pfn,
ret = sparse_index_init(section_nr, nid);
if (ret < 0 && ret != -EEXIST)
return ret;
- ret = 0;
+
+ ms = __pfn_to_section(start_pfn);
+ if (ms->section_mem_map & SECTION_MARKED_PRESENT) {
+ ret = -EEXIST;
+ goto out;
+ }
+
memmap = kmalloc_section_memmap(section_nr, nid, altmap);
if (!memmap)
return -ENOMEM;
@@ -724,12 +730,6 @@ int __meminit sparse_add_one_section(int nid, unsigned
long start_pfn,
return -ENOMEM;
}
- ms = __pfn_to_section(start_pfn);
- if (ms->section_mem_map & SECTION_MARKED_PRESENT) {
- ret = -EEXIST;
- goto out;
- }
-
/*
* Poison uninitialized struct pages in order to catch invalid flags
* combinations.
@@ -739,12 +739,7 @@ int __meminit sparse_add_one_section(int nid, unsigned
long start_pfn,
section_mark_present(ms);
sparse_init_one_section(ms, section_nr, memmap, usemap);
-out:
- if (ret < 0) {
- kfree(usemap);
- __kfree_section_memmap(memmap, altmap);
- }
- return ret;
+ return 0;
}
#ifdef CONFIG_MEMORY_HOTREMOVE
--
2.17.2
[PATCH v2] devantech-srf04.yaml: transform DT binding to YAML
devantech-srf04.yaml: yaml devicetree binding for iio ultrasonic
proximity driver of devantech srf04
use devantech-srf04.txt, transform binding into yaml and remove the
outdated DT documentation
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/devantech-srf04.txt | 28 --
.../bindings/iio/proximity/devantech-srf04.yaml| 59 ++
2 files changed, 59 insertions(+), 28 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
create mode 100644
Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
diff --git
a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
deleted file mode 100644
index d4dc7a227e2e..
--- a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Devantech SRF04 ultrasonic range finder
- Bit-banging driver using two GPIOs
-
-Required properties:
- - compatible: Should be "devantech,srf04"
-
- - trig-gpios: Definition of the GPIO for the triggering (output)
- This GPIO is set for about 10 us by the driver to tell the
- device it should initiate the measurement cycle.
-
- - echo-gpios: Definition of the GPIO for the echo (input)
- This GPIO is set by the device as soon as an ultrasonic
- burst is sent out and reset when the first echo is
- received.
- Thus this GPIO is set while the ultrasonic waves are doing
- one round trip.
- It needs to be an GPIO which is able to deliver an
- interrupt because the time between two interrupts is
- measured in the driver.
- See Documentation/devicetree/bindings/gpio/gpio.txt for
- information on how to specify a consumer gpio.
-
-Example:
-srf04@0 {
- compatible = "devantech,srf04";
- trig-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
- echo-gpios = <&gpio2 6 GPIO_ACTIVE_HIGH>;
-};
diff --git
a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
new file mode 100644
index ..e7aab785c97d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/devantech-srf04.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devantech SRF04 ultrasonic range finder
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ Bit-banging driver using two GPIOs:
+ - trigger-gpio is raised by the driver to start sending out an ultrasonic
+burst
+ - echo-gpio is held high by the sensor after sending ultrasonic burst
+until it is received once again
+
+ Specifications about the driver can be found at:
+ http://www.robot-electronics.co.uk/htm/srf04tech.htm
+
+properties:
+ compatible:
+items:
+ - const: devantech,srf04
+
+ trig-gpios:
+description:
+ Definition of the GPIO for the triggering (output) This GPIO is set
+ for about 10 us by the driver to tell the device it should initiate
+ the measurement cycle.
+maxItems: 1
+
+ echo-gpios:
+description:
+ Definition of the GPIO for the echo (input)
+ This GPIO is set by the device as soon as an ultrasonic burst is sent
+ out and reset when the first echo is received.
+ Thus this GPIO is set while the ultrasonic waves are doing one round
+ trip.
+ It needs to be an GPIO which is able to deliver an interrupt because
+ the time between two interrupts is measured in the driver.
+ See Documentation/devicetree/bindings/gpio/gpio.txt for information
+ on how to specify a consumer gpio.
+maxItems: 1
+
+required:
+ - compatible
+ - trig-gpios
+ - echo-gpios
+
+examples:
+ - |
+#include
+proximity {
+compatible = "devantech,srf04";
+trig-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+echo-gpios = <&gpio2 6 GPIO_ACTIVE_HIGH>;
+};
--
2.11.0
Re: [PATCH] arm64: dts: rockchip: decrease rising edge time of UART2
Hello Tony, Robin, I continue to investigate UART TX rising time problem. Recently, I found one of cause of this problem. In my environment, this problem occurred on linux-next only. U-Boot does not face it. So I compared settings between U-Boot and linux-next. After I found GRF_IO_VSEL (address 0xff77e640) register is differ. Would you tell me what value is stored into this register? My RockPro64, initially 0x is set but 0x0003 is set during linux boot. UART TX rising time becomes fine if set both bit 1 and bit 3 or clear both bits. Best Regards, On 2019/03/04 22:59, Katsuhiro Suzuki wrote: Hello Tony, Robin, On 2019/03/04 5:41, Tony McKahan wrote: On Sun, Mar 3, 2019 at 2:51 PM Robin Murphy wrote: On 2019-03-03 6:45 pm, Tony McKahan wrote: Hello Katsushiro, On Sun, Mar 3, 2019 at 12:31 PM Katsuhiro Suzuki wrote: Hello Tony, On 2019/03/04 0:13, Tony McKahan wrote: On Sun, Mar 3, 2019 at 9:04 AM Katsuhiro Suzuki wrote: Hello Heiko, Thank you for comments. On 2019/03/03 22:19, Heiko Stuebner wrote: Hi, Am Sonntag, 3. März 2019, 13:27:05 CET schrieb Katsuhiro Suzuki: This patch increases drive strength of UART2 from 3mA to 12mA for getting more faster rising edge. RockPro64 is using a very high speed rate (1.5Mbps) for UART2. In this setting, a bit width of UART is about 667ns. In my environment (RockPro64 UART2 with FTDI FT232RL UART-USB converter), falling time of RockPro64 UART2 is 40ns, but riging time is over 650ns. So UART receiver will get wrong data, because receiver read intermediate data of rising edge. Rising time becomes 300ns from 650ns if apply this patch. This is not perfect solution but better than now. Signed-off-by: Katsuhiro Suzuki --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) your changing a core rk3399 property here, so I'd really like to get input from other board stakeholders on this before applying a core change. Could you either include the submitters of other rk3399-boards in the recipient list so that they're aware or limit the change to rockpro64 for the time being (aka overriding the property in the board-dts) please? OK, I'm adding other boards members. by ./scripts/get_maintainer.pl arch/arm64/boot/dts/rockchip/rk3399-*.dts RockPro64 directly connect UART2 pins of RK3399 to external connector. I think maybe other RK3399 boards are facing same problem, but I cannot check it because I have RockPro64 only... I'm happy if someone tell me other boards situation. I'm pulling out other rockchip boards momentarily to see what kind of population we have. Note these are not all running 5.x kernels, however none of them have the UART2 drive levels modified to my knowledge, and regardless, none show over 100 ns. board: rise/fall rk3399-roc-pc: 90ns/90ns rk3399-rockpro64 V2.0: 90ns/45ns rk3399-rockpro64 V2.1: 40ns/41ns I'm having to eyeball off a 20MHz analog scope (thank goodness for "yes" being able to generate a nice periodic signal), but for my NanoPC-T4 with a cheap eBay FT232R adapter both rise and fall times are certainly <100ns. FWIW I've not noticed any issues with letting the Bluetooth interface on UART0 run flat-out at 4Mbaud either. Robin, Thanks a lot. Your results show that cold solder (or some electric parts on board) of my RockPro64 is broken or something wrong. Please make sure there's not a large amount of flux or something around the terminals on your board, that seems excessively high. Thank you for valuable information. For more deeply discussion, I tried other conditions and watch the rise/fall times. 1) Not connect The rise/fall times are 40ns/5ns when nothing connect (impedance is very high) to external pin of RockPro64. What UART device are you using with RockPro64? If you use some device with RockPro64 and board shows rise/fall times = 90ns/45ns, my device is not suitable for RockPro64 by some reason. So it's better to drop my patch. The adapter is an FTDI FT232RL breakout board, attached with some generic Dupont connector jumpers. Interesting your RockPro is showing this symptom, perhaps there is a cold solder joint somewhere introducing resistance? 2) Other SoC I have other SoC board rk3328-rock64, Rock64 shows rise/fall times = 90ns/80ns when same UART-USB device is connected to UART pin. I measured similar on my Rock64 as well. Tony, thanks for your info about environment. It seems my RockPro64 problem. I don't have enough electronic knowledge, but try to check my RockPro64 as much as I can. I think it shows rk3399's (or RockPro64's?) drive strength is a little weak. So it's better to increase the drive strength of UART of rk3399. I do not think this is a bad idea generally, it simply allows for more available current from the interface. I'll let others be the judge of that, however. There may be RK3399 users who would care about the possible EMI impact, so it's probably stil
Re: [PATCH 5/5] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
Hi Andy,
On Tue, Mar 26, 2019 at 03:13:53PM +0200, Andy Shevchenko wrote:
> On Sun, Mar 24, 2019 at 08:17:46PM +0200, Sakari Ailus wrote:
> > On Fri, Mar 22, 2019 at 07:21:14PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 22, 2019 at 05:29:30PM +0200, Sakari Ailus wrote:
> > > > Add support for %pfw conversion specifier (with "f" and "P" modifiers)
> > > > to
> > > > support printing full path of the node, including its name ("f") and
> > > > only
> > > > the node's name ("P") in the printk family of functions. The two flags
> > > > have equivalent functionality to existing %pOF with the same two
> > > > modifiers
> > > > ("f" and "P") on OF based systems. The ability to do the same on ACPI
> > > > based systems is added by this patch.
> > >
> > > Do we encourage people to use it instead of %pOF cases where it is
> > > suitable?
> >
> > For code that is used on both OF and ACPI based systems, I think so. But if
> > you have something that is only used on OF, %pOF is better --- it has more
> > functionality that seems quite OF specific. In general I think the ability
> > to print a node's full name is way more important on OF. On ACPI you don't
> > need it so often --- which is probably the reason it hasn't been supported.
>
> But if code is going to support ACPI and DT and at the same time use %pOF
> extensions that are not covered by %pfw it would be inconsistent somehow.
What you mostly need are the full name and the name of a given node. I
wasn't sure whether adding more would have been relevant, and at least it
is likely to have few if any users, so I didn't add that yet. Do not that
it can be implemented later on if it's needed --- that's also why the
modifiers are aligned with %pOF.
>
> > > > On ACPI based systems the resulting strings look like
> > > >
> > > > \_SB.PCI0.CIO2.port@1.endpoint@0
> > > >
> > > > where the nodes are separated by a dot (".") and the first three are
> > > > ACPI device nodes and the latter two ACPI data nodes.
> > >
> > > Do we support swnode here?
> >
> > Good question. The swnodes have no hierarchy at the moment (they're only
> > created for a struct device as a parent) and they do not have human-readable
> > names. So I'd say it's not relevant right now. Should these two change,
> > support for swnode could (and should) be added later on.
>
> Heikki, what do you think about this?
>
> > > > + if ((unsigned long)fwnode < PAGE_SIZE)
> > > > + return string(buf, end, "(null)", spec);
> > >
> > > Just put there a NULL pointer, we would not like to maintain duplicated
> > > strings
> > > over the kernel.
> > >
> > > I remember Petr has a patch series related to address space check, though
> > > I
> > > don't remember the status of affairs.
> >
> > This bit has been actually adopted from the OF counterpart. If there are
> > improvements in this area, then I'd just change both at the same time.
>
> The patch series by Petr I mentioned takes care about OF case. But it doesn't
> have covered yours by obvious reasons.
Do you happen to have a pointer to it?
>
> > > > + for (pass = false; strspn(fmt, modifiers); fmt++, pass = true) {
> > >
> > > I don't see test cases.
> > >
> > > What would we get out of %pfwfffPPPfff?
> > >
> > > Hint: I'm expecting above to be equivalent to %pfwf
> >
> > I guess it's a matter of expectations. :-)
>
> Common sense and basic expectations from all of %p extensions.
>
> > Again this works the same way
> > than the OF counterpart.
>
> OF lacks of testing apparently.
>
> > Right now there's little to print (just the name
> > and the full name), but if support is added for more, then this mechanism is
> > fully relevant again.
> >
> > The alternative would be to remove that now and add it back if it's needed
> > again. I have a slight preference towards keeping it extensible (i.e. as
> > it's now).
>
> See how other helpers do parse this.
The behaviour on others is different indeed, you're generally printing a
single item at a time. The question rather is, whether we want to be
compatible with %pOF going forward or not. I'd prefer that, so using the
fwnode API would be easier.
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
Re: [PATCH 2/4] signal: Make flush_sigqueue() use free_q to release memory
On 03/25, Christopher Lameter wrote: > > On Fri, 22 Mar 2019, Matthew Wilcox wrote: > > > Only for SLAB and SLUB. SLOB requires that you pass a pointer to the > > slab cache; it has no way to look up the slab cache from the object. > > Well then we could either fix SLOB to conform to the others or add a > kmem_cache_free_rcu() variant. Speaking of struct sigqueue we can simply use call_rcu() but see my previous email, I am not sure this is the best option. Oleg.
Re: [PATCH v2 3/6] device property: Add a function to obtain a node's prefix
Hi Andy,
On Tue, Mar 26, 2019 at 03:16:26PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2019 at 02:41:03PM +0200, Sakari Ailus wrote:
> > The prefix is used for printing purpose before a node, and it also works
> > as a separator between two nodes.
> >
>
> One nit below.
>
> > +static const char *
> > +acpi_fwnode_get_name_prefix(const struct fwnode_handle *fwnode)
> > +{
> > + struct fwnode_handle *parent;
> > +
>
> > + parent = fwnode_get_parent(fwnode);
> > + /* Root node. */
>
> I guess a comment could be easier to read if it goes before parent assignment
> line.
Only if the comments are changed accordingly. What we're doing here is
trying to figure out whether this is the root node. I can do that for v3.
>
> > + if (!parent)
> > + return "";
> > +
> > + parent = fwnode_get_next_parent(parent);
> > + /* Second node from the root; no prefix here either. */
>
> Ditto.
>
> > + if (!parent)
> > + return "";
> > +
> > + fwnode_handle_put(parent);
> > +
> > + /* ACPI device or data node. */
> > + return ".";
> > +}
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
Re: [PATCH] cpu/hotplug: Create SMT sysfs interface for all arches
On Sun, Mar 24, 2019 at 09:13:18PM +0100, Thomas Gleixner wrote: > On Fri, 1 Mar 2019, Josh Poimboeuf wrote: > > Make the /sys/devices/system/cpu/smt/* files available on all arches, so > > user space has a consistent way to detect whether SMT is enabled. > > > > The 'control' file now shows 'notsupported' for architectures which > > don't yet have CONFIG_HOTPLUG_SMT. > > I'm slowly crawling through my backlog ... > > > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu > > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu > > @@ -514,7 +514,8 @@ Description:Control Symetric Multi Threading (SMT) > > "on" SMT is enabled > > "off" SMT is disabled > > "forceoff" SMT is force disabled. Cannot be > > changed. > > -"notsupported" SMT is not supported by the CPU > > +"notsupported" Runtime SMT toggling is not currently > > + supported for the architecture > > Second thoughts. I'm not really convinced that changing the meaning of > notsupported and in fact overloading it, is the right thing to do. > notsupported means now: > > CPU does not support it - OR - architecture does not support it > > That's not pretty and we are surely not short of state space. There are > several options for handling this: > > 1) Do not expose the state file, just expose the active file > > 2) Expose the state file, but return -ENOTSUPP or some other sensible error > code > > 3) Expose the state file and let show return 'notimplemented' which is > more accurate. That wouldn't even require to expand the state space > enum. It just can be returned unconditionally. Makes sense. I like #3. I can post another version. -- Josh
Re: [LINUX PATCH v13] rawnand: pl353: Add basic driver for arm pl353 smc nand interface
On Sat, Feb 09, 2019 at 12:07:27PM +0530, Naga Sureshkumar Relli wrote:
> +static void pl353_nfc_force_byte_access(struct nand_chip *chip,
> + bool force_8bit)
> +{
> + struct pl353_nand_controller *xnfc =
> + container_of(chip, struct pl353_nand_controller, chip);
This `xnfc' variable is never used anywhere inside this function.
> +/**
> + * pl353_nand_exec_op_cmd - Send command to NAND device
> + * @chip:Pointer to the NAND chip info structure
> + * @subop: Pointer to array of instructions
> + * Return: Always return zero
> + */
> +static int pl353_nand_exec_op_cmd(struct nand_chip *chip,
> + const struct nand_subop *subop)
> +{
> + struct mtd_info *mtd = nand_to_mtd(chip);
> + const struct nand_op_instr *instr;
> + struct pl353_nfc_op nfc_op = {};
> + struct pl353_nand_controller *xnfc =
> + container_of(chip, struct pl353_nand_controller, chip);
> + unsigned long cmd_phase_data = 0, end_cmd_valid = 0;
> + unsigned long cmd_phase_addr, data_phase_addr, end_cmd;
> + unsigned int op_id, len, offset;
> + bool reading;
> +
> + pl353_nfc_parse_instructions(chip, subop, &nfc_op);
> + instr = nfc_op.data_instr;
> + op_id = nfc_op.data_instr_idx;
> +
> + offset = nand_subop_get_data_start_off(subop, op_id);
This `offset' variable is never used anywhere inside this function. The
call is unnecessary and should be removed.
Beyond being useless, it also is harmful. When applying this patch on
top of a v5.1-rc2, this can be found in dmesg:
| [ cut here ]
| WARNING: CPU: 0 PID: 1 at .../linux/drivers/mtd/nand/raw/nand_base.c:2299
nand_subop_get_data_start_off+0x30/0x6c
| CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc2-dirty #3
| Hardware name: Xilinx Zynq Platform
| [] (unwind_backtrace) from [] (show_stack+0x18/0x1c)
| [] (show_stack) from [] (dump_stack+0xa0/0xcc)
| [] (dump_stack) from [] (__warn+0x10c/0x128)
| [] (__warn) from [] (warn_slowpath_null+0x48/0x50)
| [] (warn_slowpath_null) from []
(nand_subop_get_data_start_off+0x30/0x6c)
| [] (nand_subop_get_data_start_off) from []
(pl353_nand_exec_op_cmd+0x94/0x2f0)
| [] (pl353_nand_exec_op_cmd) from []
(nand_op_parser_exec_op+0x460/0x4cc)
| [] (nand_op_parser_exec_op) from []
(nand_reset_op+0x134/0x1a0)
| [] (nand_reset_op) from [] (nand_reset+0x60/0xbc)
| [] (nand_reset) from [] (nand_scan_with_ids+0x288/0x1600)
| [] (nand_scan_with_ids) from []
(pl353_nand_probe+0xf8/0x1a0)
| [] (pl353_nand_probe) from []
(platform_drv_probe+0x3c/0x74)
| [] (platform_drv_probe) from [] (really_probe+0x278/0x400)
| [] (really_probe) from [] (bus_for_each_drv+0x68/0x9c)
| [] (bus_for_each_drv) from [] (__device_attach+0xa8/0x11c)
| [] (__device_attach) from [] (bus_probe_device+0x90/0x98)
| [] (bus_probe_device) from [] (device_add+0x3b4/0x5f0)
| [] (device_add) from []
(of_platform_device_create_pdata+0x98/0xc8)
| [] (of_platform_device_create_pdata) from []
(pl353_smc_probe+0x194/0x234)
| [] (pl353_smc_probe) from [] (amba_probe+0x60/0x74)
| [] (amba_probe) from [] (really_probe+0x278/0x400)
| [] (really_probe) from [] (device_driver_attach+0x60/0x68)
| [] (device_driver_attach) from []
(__driver_attach+0x88/0x180)
| [] (__driver_attach) from [] (bus_for_each_dev+0x60/0x9c)
| [] (bus_for_each_dev) from [] (bus_add_driver+0x10c/0x208)
| [] (bus_add_driver) from [] (driver_register+0x80/0x114)
| [] (driver_register) from [] (do_one_initcall+0x164/0x374)
| [] (do_one_initcall) from []
(kernel_init_freeable+0x394/0x474)
| [] (kernel_init_freeable) from [] (kernel_init+0x14/0x100)
| [] (kernel_init) from [] (ret_from_fork+0x14/0x28)
| Exception stack(0xdd8c9fb0 to 0xdd8c9ff8)
| 9fa0:
| 9fc0:
| 9fe0: 0013
| irq event stamp: 414355
| hardirqs last enabled at (414361): [] console_unlock+0x4c4/0x690
| hardirqs last disabled at (414366): [] console_unlock+0xdc/0x690
| softirqs last enabled at (414350): [] __do_softirq+0x454/0x544
| softirqs last disabled at (414345): [] irq_exit+0x124/0x128
| ---[ end trace 3be9247df2f8dfb5 ]---
After removing the call (and the variable), this particular problem goes away.
> +/**
> + * pl353_nand_probe - Probe method for the NAND driver
> + * @pdev:Pointer to the platform_device structure
> + *
> + * This function initializes the driver data structures and the hardware.
> + * The NAND driver has dependency with the pl353_smc memory controller
> + * driver for initializing the NAND timing parameters, bus width, ECC modes,
> + * control and status information.
> + *
> + * Return: 0 on success or error value on failure
> + */
> +static int pl353_nand_probe(struct platform_device *pdev)
> +{
> + struct pl353_nand_controller *xnfc;
> + struct mtd_info *mtd;
> +
Re: [PATCH v2 6/6] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
Hi Andy, Rasmus,
Thanks for the comments.
On Tue, Mar 26, 2019 at 03:24:50PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2019 at 02:11:35PM +0100, Rasmus Villemoes wrote:
> > On 26/03/2019 13.41, Sakari Ailus wrote:
> > > Add support for %pfw conversion specifier (with "f" and "P" modifiers) to
> > > support printing full path of the node, including its name ("f") and only
> > > the node's name ("P") in the printk family of functions. The two flags
> > > have equivalent functionality to existing %pOF with the same two modifiers
> > > ("f" and "P") on OF based systems. The ability to do the same on ACPI
> > > based systems is added by this patch.
>
> > > + for (pass = false; strspn(fmt, modifiers); fmt++, pass = true) {
> > > + if (pass) {
> > > + if (buf < end)
> > > + *buf = ':';
> > > + buf++;
> > > + }
> > > +
> > > + switch (*fmt) {
> > > + case 'f': /* full_name */
> > > + buf = fwnode_gen_full_name(fwnode, buf, end);
> > > + break;
> > > + case 'P': /* name */
> > > + buf = string(buf, end, fwnode_get_name(fwnode),
> > > + str_spec);
> > > + break;
> > > + default:
> > > + break;
> > > + }
> > > + }
> >
> > This seems awfully complicated. Why would anyone ever pass more than one
> > of 'f' and 'P'? Why not just
> >
> > switch(*fmt) {
> > case 'P':
> >...
> > case 'f':
> > default:
> >...
> > }
> >
> > which avoids the loop and the strcspn. Or, drop the default: case and
> > don't have logic at all for falling back to 'f' if neither is present.
There are just two modifiers supported now ('f' and 'P') but should more be
needed in the future, we'd need the loop again. This is basically modelled
after %pOF implementation.
I can simplify this if you both still think that's the way to go, and
make the implementations diverge.
> >
> > > + return widen_string(buf, buf - buf_start, end, spec);
> > > +}
>
> My point as well (as per sent comments against previous version).
> Sakari, can you add test cases at the same time?
>
> > > return device_node_string(buf, end, ptr, spec, fmt + 1);
>
> > > + return fwnode_string(buf, end, ptr, spec, fmt + 1);
> >
> > Why not pass fmt+2; we know that fmt+1 points at a 'w'. Just to avoid
> > doing the fmt++ inside fwnode_string().
>
> I guess in order to be consistent with existing %pOF case. But wouldn't be
> better to fix %pOF for that sooner or later?
Agreed.
--
Sakari Ailus
sakari.ai...@linux.intel.com
RE: [PATCH 2/2] arm64: dts: imx8qxp: Add EDMA0/EDMA1 nodes
> From: Daniel Baluta
> Sent: Tuesday, March 26, 2019 5:43 PM
>
> i.MX8QXP contains a total of 4 EDMA controllers of which two are primarily
> for audio components and the other two are for non-audio periperhals.
>
> This patch adds the EDMA0/EDMA1 nodes used by audio peripherals.
>
> EDMA0 contains channels for:
> * ASRC0
> * ESAI0
> * SPDIF0
> * SAI0, SAI1, SAI2, SAI3
>
> EDMA1 contains channels for:
> * ASRC1
> * SAI4, SAI5
>
> See chapter Audio DMA Memory Maps (2.2.3) from i.MX8QXP RM [1]
>
> This patch is based on the dtsi file initially submitted by Teo Hall in i.MX
> NXP
> internal tree.
>
> [1] https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
>
> Cc: Teo Hall
> Signed-off-by: Daniel Baluta
> ---
> arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 72
> ++
> 1 file changed, 72 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> index 0cb939861a60..9e959deb2499 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -182,6 +182,78 @@
> #clock-cells = <1>;
> };
>
> + edma0: dma-controller@591f {
> + compatible = "fsl,imx8qm-edma";
Should this be "fsl,imx8qxp-edma"?
or
"fsl,imx8qxp-edma", "fsl,imx8qm-edma"?
Regards
Dong Aisheng
> + reg = <0x5920 0x1>, /* asrc0 pair A input req
> */
> + <0x5921 0x1>, /* asrc0 pair B input req
> */
> + <0x5922 0x1>, /* asrc0 pair C input req
> */
> + <0x5923 0x1>, /* asrc0 pair A output
> req */
> + <0x5924 0x1>, /* asrc0 pair B output
> req */
> + <0x5925 0x1>, /* asrc0 pair C output
> req */
> + <0x5926 0x1>, /* esai0 rx */
> + <0x5927 0x1>, /* esai0 tx */
> + <0x5928 0x1>, /* spdif0 rx */
> + <0x5929 0x1>, /* spdif0 tx */
> + <0x592c 0x1>, /* sai0 rx */
> + <0x592d 0x1>, /* sai0 tx */
> + <0x592e 0x1>, /* sai1 rx */
> + <0x592f 0x1>, /* sai1 tx */
> + #dma-cells = <3>;
> + shared-interrupt;
> + dma-channels = <14>;
> + interrupts = ,/*
> asrc 0
> */
> + ,
> + ,
> + ,
> + ,
> + ,
> + , /*
> esai0 */
> + ,
> + , /*
> spdif0 */
> + ,
> + , /*
> sai0 */
> + ,
> + , /*
> sai1 */
> + ,
> + interrupt-names = "edma0-chan0-rx", "edma0-chan1-rx", /*
> asrc0 */
> + "edma0-chan2-rx", "edma0-chan3-tx",
> + "edma0-chan4-tx", "edma0-chan5-tx",
> + "edma0-chan6-rx", "edma0-chan7-tx",
> /* esai0 */
> + "edma0-chan8-rx", "edma0-chan9-tx",
> /* spdif0 */
> + "edma0-chan12-rx", "edma0-chan13-tx",
> /* sai0 */
> + "edma0-chan14-rx", "edma0-chan15-tx",
> /* sai1 */
> + };
> +
> + edma1: dma-controller@599F {
> + compatible = "fsl,imx8qm-edma";
> + reg = <0x0 0x59A0 0x0 0x1>, /* asrc1 */
> + <0x0 0x59A1 0x0 0x1>,
> + <0x0 0x59A2 0x0 0x1>,
> + <0x0 0x59A3 0x0 0x1>,
> + <0x0 0x59A4 0x0 0x1>,
> + <0x0 0x59A5 0x0 0x1>,
> + <0x0 0x59A8 0x0 0x1>, /* sai4 rx */
> + <0x0 0x59A9 0x0 0x1>, /* sai4 tx */
> + <0x0 0x59AA 0x0 0x1>; /* sai5 tx */
> + #dma-cells = <3>;
> + shared-interrupt;
> + dma-channels = <9>;
> + interrupts = , /* asrc
> 1 */
> + ,
> + ,
> + ,
> + ,
>
Re: [PATCH 2/4] signal: Make flush_sigqueue() use free_q to release memory
Sorry, I am sick and can't work, hopefully I'll return tomorrow.
On 03/22, Christopher Lameter wrote:
>
> On Fri, 22 Mar 2019, Waiman Long wrote:
>
> > I am looking forward to it.
>
> There is also alrady rcu being used in these paths. kfree_rcu() would not
> be enough? It is an estalished mechanism that is mature and well
> understood.
But why do we want to increase the number of rcu callbacks in flight?
For the moment, lets discuss the exiting tasks only. The only reason why
flush_sigqueue(&tsk->pending) needs spin_lock_irq() is the race with
release_posix_timer()->sigqueue_free() from another thread which can remove
a SIGQUEUE_PREALLOC'ed sigqueue from list. With the simple patch below
flush_sigqueue() can be called lockless with irqs enabled.
However, this change is not enough, we need to do something similar with
do_sigaction()->flush_sigqueue_mask(), and this is less simple.
So I won't really argue with kfree_rcu() but I am not sure this is the best
option.
Oleg.
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -85,6 +85,17 @@ static void __unhash_process(struct task_struct *p, bool
group_dead)
list_del_rcu(&p->thread_node);
}
+// Rename me and move into signal.c
+void remove_prealloced(struct sigpending *queue)
+{
+ struct sigqueue *q, *t;
+
+ list_for_each_entry_safe(q, t, &queue->list, list) {
+ if (q->flags & SIGQUEUE_PREALLOC)
+ list_del_init(&q->list);
+ }
+}
+
/*
* This function expects the tasklist_lock write-locked.
*/
@@ -160,16 +171,15 @@ static void __exit_signal(struct task_struct *tsk)
* Do this under ->siglock, we can race with another thread
* doing sigqueue_free() if we have SIGQUEUE_PREALLOC signals.
*/
- flush_sigqueue(&tsk->pending);
+ if (!group_dead)
+ remove_prealloced(&tsk->pending);
tsk->sighand = NULL;
spin_unlock(&sighand->siglock);
__cleanup_sighand(sighand);
clear_tsk_thread_flag(tsk, TIF_SIGPENDING);
- if (group_dead) {
- flush_sigqueue(&sig->shared_pending);
+ if (group_dead)
tty_kref_put(tty);
- }
}
static void delayed_put_task_struct(struct rcu_head *rhp)
@@ -221,6 +231,11 @@ void release_task(struct task_struct *p)
write_unlock_irq(&tasklist_lock);
cgroup_release(p);
release_thread(p);
+
+ flush_sigqueue(&p->pending);
+ if (thread_group_leader(p))
+ flush_sigqueue(&p->signal->shared_pending);
+
call_rcu(&p->rcu, delayed_put_task_struct);
p = leader;
[PATCH v2 2/2] dt-bindings: phy-qcom-qmp: Add qcom,msm8998-qmp-pcie-phy
Add compatible string for QMP PCIe phy on msm8998. Signed-off-by: Marc Gonzalez --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt index 5d181fc3cc18..6000ae34b12b 100644 --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt @@ -11,6 +11,7 @@ Required properties: "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, "qcom,msm8998-qmp-usb3-phy" for USB3 QMP V3 phy on msm8998, "qcom,msm8998-qmp-ufs-phy" for UFS QMP phy on msm8998, + "qcom,msm8998-qmp-pcie-phy" for PCIe QMP phy on msm8998, "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845, "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845, "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845. @@ -48,6 +49,8 @@ Required properties: "aux", "cfg_ahb", "ref". For "qcom,msm8998-qmp-ufs-phy" must contain: "ref", "ref_aux". + For "qcom,msm8998-qmp-pcie-phy" must contain: + "aux", "cfg_ahb", "ref". For "qcom,sdm845-qmp-usb3-phy" must contain: "aux", "cfg_ahb", "ref", "com_aux". For "qcom,sdm845-qmp-usb3-uni-phy" must contain: @@ -70,6 +73,8 @@ Required properties: For "qcom,msm8998-qmp-usb3-phy" must contain "phy", "common". For "qcom,msm8998-qmp-ufs-phy": no resets are listed. + For "qcom,msm8998-qmp-pcie-phy" must contain: + "phy", "common", "cfg". For "qcom,sdm845-qmp-usb3-phy" must contain: "phy", "common". For "qcom,sdm845-qmp-usb3-uni-phy" must contain: -- 2.17.1
Re: [PATCH v2 6/6] lib/vsprintf: Add %pfw conversion specifier for printing fwnode names
On Tue, Mar 26, 2019 at 02:11:35PM +0100, Rasmus Villemoes wrote:
> On 26/03/2019 13.41, Sakari Ailus wrote:
> > Add support for %pfw conversion specifier (with "f" and "P" modifiers) to
> > support printing full path of the node, including its name ("f") and only
> > the node's name ("P") in the printk family of functions. The two flags
> > have equivalent functionality to existing %pOF with the same two modifiers
> > ("f" and "P") on OF based systems. The ability to do the same on ACPI
> > based systems is added by this patch.
> > + for (pass = false; strspn(fmt, modifiers); fmt++, pass = true) {
> > + if (pass) {
> > + if (buf < end)
> > + *buf = ':';
> > + buf++;
> > + }
> > +
> > + switch (*fmt) {
> > + case 'f': /* full_name */
> > + buf = fwnode_gen_full_name(fwnode, buf, end);
> > + break;
> > + case 'P': /* name */
> > + buf = string(buf, end, fwnode_get_name(fwnode),
> > +str_spec);
> > + break;
> > + default:
> > + break;
> > + }
> > + }
>
> This seems awfully complicated. Why would anyone ever pass more than one
> of 'f' and 'P'? Why not just
>
> switch(*fmt) {
> case 'P':
>...
> case 'f':
> default:
>...
> }
>
> which avoids the loop and the strcspn. Or, drop the default: case and
> don't have logic at all for falling back to 'f' if neither is present.
>
> > + return widen_string(buf, buf - buf_start, end, spec);
> > +}
My point as well (as per sent comments against previous version).
Sakari, can you add test cases at the same time?
> > return device_node_string(buf, end, ptr, spec, fmt + 1);
> > + return fwnode_string(buf, end, ptr, spec, fmt + 1);
>
> Why not pass fmt+2; we know that fmt+1 points at a 'w'. Just to avoid
> doing the fmt++ inside fwnode_string().
I guess in order to be consistent with existing %pOF case. But wouldn't be
better to fix %pOF for that sooner or later?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2] PCI: al: Add Amazon Annapurna Labs PCIe host controller driver
On Tue, 2019-03-26 at 12:17 +, Lorenzo Pieralisi wrote: > [+Zhou, Gustavo] > > On Tue, Mar 26, 2019 at 12:00:55PM +0200, Jonathan Chocron wrote: > > Adding support for Amazon's Annapurna Labs PCIe driver. > > The HW controller is based on DesignWare's IP. > > > > The HW doesn't support accessing the Root Port's config space via > > ECAM, so we obtain its base address via an AMZN0001 device. > > > > Furthermore, the DesignWare PCIe controller doesn't filter out > > config transactions sent to devices 1 and up on its bus, so they > > are filtered by the driver. > > All subordinate buses do support ECAM access. > > > > Implementing specific PCI config access functions involves: > > - Adding an init function to obtain the Root Port's base address > >from an AMZN0001 device. > > - Adding a new entry in the mcfg quirk array > > > > Co-developed-by: Vladimir Aerov > > Signed-off-by: Jonathan Chocron > > Signed-off-by: Vladimir Aerov > > Reviewed-by: Benjamin Herrenschmidt > > Reviewed-by: David Woodhouse > > Review tags should be given on public mailing lists for public > review and I have not seen them (they were already there in v1) so > you should drop them. We did that internally. You really don't want me telling engineers to post to the list *first* without running things by me to get the basics right. Not to start with, at least. Reviewed-by: David Woodhouse > > Changes from v1: > > - Fix commit message comments (incl. using AMZN0001 > > instead of PNP0C02) > > - Use the usual multi-line comment style > > > > MAINTAINERS | 6 +++ > > drivers/acpi/pci_mcfg.c | 12 + > > drivers/pci/controller/dwc/Makefile | 1 + > > drivers/pci/controller/dwc/pcie-al.c | 93 > > > > include/linux/pci-ecam.h | 1 + > > 5 files changed, 113 insertions(+) > > create mode 100644 drivers/pci/controller/dwc/pcie-al.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 32d76a90..7a17017f9f82 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -11769,6 +11769,12 @@ T: git > > git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git/ > > S: Supported > > F: drivers/pci/controller/ > > > > +PCIE DRIVER FOR ANNAPURNA LABS > > +M: Jonathan Chocron > > +L: linux-...@vger.kernel.org > > +S: Maintained > > +F: drivers/pci/controller/dwc/pcie-al.c > > I do not think we need a maintainer file for that see below, and > actually this quirk should be handled by DWC maintainers since it is a > DWC quirk, not a platform one. Many of the others already have this, it seems. It's also fine to drop it, and include it when we add the rest of the Alpine SOC support and a MAINTAINERS entry for that. smime.p7s Description: S/MIME cryptographic signature
