Re: [PATCH] pstore: fix crypto dependencies of 842/zstd compression
hi ,
On 2018/12/17 16:16, kbuild test robot wrote:
> Hi liaoweixiong,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on kees/for-next/pstore]
> [also build test ERROR on v4.20-rc7 next-20181214]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/liaoweixiong/pstore-fix-crypto-dependencies-of-842-zstd-compression/20181214-222645
> base: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git
> for-next/pstore
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>fs/pstore/platform.o: In function `zbufsize_zstd':
>>> platform.c:(.text+0x30a): undefined reference to `ZSTD_compressBound'
Yes, i reproduced it. I had made a new patch in version 2.
On new patch, i try to trun sub-options of compression back to 'bool'
for more rigorous.
Commit info like this:
On commit 58eb5b670747 ("pstore: fix crypto dependencies"),
dependency bug was fixed by selecting the crypto core rather than
turned compression sub-options to 'tristate'.
In addition, these options are used to enable/disable compression. They
are not modules, and mean nothing when set to 'M'.
So, this patch is going to turn them back to 'bool'.
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
Re: [PATCH v1 1/1] MAINTAINERS: update list of qcom drivers
Amit Kucheria writes: > Several drivers didn't have a specific maintainer (other than the > subsystem maintainer). Switch to using the 'qcom' and 'msm' regex > patterns to capture all of them and add exceptions to the couple of > drivers that contain 'msm' but are not related to qcom hardware. > > Thanks to Marc for the idea to use the N regex. > > Signed-off-by: Amit Kucheria > --- > MAINTAINERS | 14 -- > 1 file changed, 4 insertions(+), 10 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3318f30903b2..c9376030f77a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1929,20 +1929,14 @@ M:Andy Gross > M: David Brown > L: linux-arm-...@vger.kernel.org > S: Maintained > -F: Documentation/devicetree/bindings/soc/qcom/ > -F: arch/arm/boot/dts/qcom-*.dts > -F: arch/arm/boot/dts/qcom-*.dtsi > -F: arch/arm/mach-qcom/ > -F: arch/arm64/boot/dts/qcom/* > +N: qcom > +N: msm IMHO this is pretty fragile in the long term. For example only due to historical reasons qualcomm wireless drivers currently under ath directory but who knows if at some point we switch using qcom (or qualcomm) directory. Also the wireless drivers might easily have filenames containing strings like "msm" or "qcom" (which I assume would match with "N" rules above). -- Kalle Valo
[PATCH v8 2/2] PCI: amlogic: Add the Amlogic Meson PCIe controller driver
From: Yue Wang The Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI core. This patch adds the driver support for Meson PCIe controller. Signed-off-by: Yue Wang Signed-off-by: Hanjie Lin --- MAINTAINERS| 7 + drivers/pci/controller/dwc/Kconfig | 10 + drivers/pci/controller/dwc/Makefile| 1 + drivers/pci/controller/dwc/pci-meson.c | 595 + 4 files changed, 613 insertions(+) create mode 100644 drivers/pci/controller/dwc/pci-meson.c diff --git a/MAINTAINERS b/MAINTAINERS index 7fe120f..21ed916 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11600,6 +11600,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git/ S: Supported F: drivers/pci/controller/ +PCIE DRIVER FOR AMLOGIC MESON +M: Yue Wang +L: linux-...@vger.kernel.org +L: linux-amlo...@lists.infradead.org +S: Maintained +F: drivers/pci/controller/dwc/pci-meson.c + PCIE DRIVER FOR AXIS ARTPEC M: Jesper Nilsson L: linux-arm-ker...@axis.com diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig index 91b0194..7800322 100644 --- a/drivers/pci/controller/dwc/Kconfig +++ b/drivers/pci/controller/dwc/Kconfig @@ -193,4 +193,14 @@ config PCIE_HISI_STB help Say Y here if you want PCIe controller support on HiSilicon STB SoCs +config PCI_MESON + bool "MESON PCIe controller" + depends on PCI_MSI_IRQ_DOMAIN + select PCIE_DW_HOST + help + Say Y here if you want to enable PCI controller support on Amlogic + SoCs. The PCI controller on Amlogic is based on DesignWare hardware + and therefore the driver re-uses the DesignWare core functions to + implement the driver. + endmenu diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile index fcf91ea..e05a015 100644 --- a/drivers/pci/controller/dwc/Makefile +++ b/drivers/pci/controller/dwc/Makefile @@ -14,6 +14,7 @@ obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o obj-$(CONFIG_PCIE_HISI_STB) += pcie-histb.o +obj-$(CONFIG_PCI_MESON) += pci-meson.o # The following drivers are for devices that use the generic ACPI # pci_root.c driver but don't support standard ECAM config access. diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c new file mode 100644 index 000..7993f9d --- /dev/null +++ b/drivers/pci/controller/dwc/pci-meson.c @@ -0,0 +1,595 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * PCIe host controller driver for Amlogic MESON SoCs + * + * Copyright (c) 2018 Amlogic, inc. + * Author: Yue Wang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "pcie-designware.h" + +#define to_meson_pcie(x) dev_get_drvdata((x)->dev) + +/* External local bus interface registers */ +#define PLR_OFFSET 0x700 +#define PCIE_PORT_LINK_CTRL_OFF(PLR_OFFSET + 0x10) +#define FAST_LINK_MODE BIT(7) +#define LINK_CAPABLE_MASK GENMASK(21, 16) +#define LINK_CAPABLE_X1BIT(16) + +#define PCIE_GEN2_CTRL_OFF (PLR_OFFSET + 0x10c) +#define NUM_OF_LANES_MASK GENMASK(12, 8) +#define NUM_OF_LANES_X1BIT(8) +#define DIRECT_SPEED_CHANGEBIT(17) + +#define TYPE1_HDR_OFFSET 0x0 +#define PCIE_STATUS_COMMAND(TYPE1_HDR_OFFSET + 0x04) +#define PCI_IO_EN BIT(0) +#define PCI_MEM_SPACE_EN BIT(1) +#define PCI_BUS_MASTER_EN BIT(2) + +#define PCIE_BASE_ADDR0(TYPE1_HDR_OFFSET + 0x10) +#define PCIE_BASE_ADDR1(TYPE1_HDR_OFFSET + 0x14) + +#define PCIE_CAP_OFFSET0x70 +#define PCIE_DEV_CTRL_DEV_STUS (PCIE_CAP_OFFSET + 0x08) +#define PCIE_CAP_MAX_PAYLOAD_MASK GENMASK(7, 5) +#define PCIE_CAP_MAX_PAYLOAD_SIZE(x) ((x) << 5) +#define PCIE_CAP_MAX_READ_REQ_MASK GENMASK(14, 12) +#define PCIE_CAP_MAX_READ_REQ_SIZE(x) ((x) << 12) + +/* PCIe specific config registers */ +#define PCIE_CFG0 0x0 +#define APP_LTSSM_ENABLE BIT(7) + +#define PCIE_CFG_STATUS12 0x30 +#define IS_SMLH_LINK_UP(x) ((x) & (1 << 6)) +#define IS_RDLH_LINK_UP(x) ((x) & (1 << 16)) +#define IS_LTSSM_UP(x) x) >> 10) & 0x1f) == 0x11) + +#define PCIE_CFG_STATUS17 0x44 +#define PM_CURRENT_STATE(x)(((x) >> 7) & 0x1) + +#define WAIT_LINKUP_TIMEOUT4000 +#define PORT_CLK_RATE 1UL +#define MAX_PAYLOAD_SIZE 256 +#define MAX_READ_REQ_SIZE 256 +#define MESON_PCIE_PHY_POWERUP 0x1c +#define PCIE_RESET_DELAY 500 +#defin
[PATCH v8 1/2] dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller
From: Yue Wang
The Amlogic Meson PCIe host controller is based on the Synopsys DesignWare
PCI core. This patch adds documentation for the DT bindings in Meson PCIe
controller.
Signed-off-by: Yue Wang
Signed-off-by: Hanjie Lin
Reviewed-by: Rob Herring
---
.../devicetree/bindings/pci/amlogic,meson-pcie.txt | 70 ++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
new file mode 100644
index 000..12b18f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
@@ -0,0 +1,70 @@
+Amlogic Meson AXG DWC PCIE SoC controller
+
+Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI
core.
+It shares common functions with the PCIe DesignWare core driver and
+inherits common properties defined in
+Documentation/devicetree/bindings/pci/designware-pci.txt.
+
+Additional properties are described here:
+
+Required properties:
+- compatible:
+ should contain "amlogic,axg-pcie" to identify the core.
+- reg:
+ should contain the configuration address space.
+- reg-names: Must be
+ - "elbi"External local bus interface registers
+ - "cfg" Meson specific registers
+ - "phy" Meson PCIE PHY registers
+ - "config" PCIe configuration space
+- reset-gpios: The GPIO to generate PCIe PERST# assert and deassert signal.
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Must include the following entries:
+ - "pclk" PCIe GEN 100M PLL clock
+ - "port" PCIe_x(A or B) RC clock gate
+ - "general"PCIe Phy clock
+ - "mipi" PCIe_x(A or B) 100M ref clock gate
+- resets: phandle to the reset lines.
+- reset-names: must contain "phy" "port" and "apb"
+ - "phy" Share PHY reset
+ - "port"Port A or B reset
+ - "apb" Share APB reset
+- device_type:
+ should be "pci". As specified in designware-pcie.txt
+
+
+Example configuration:
+
+ pcie: pcie@f980 {
+ compatible = "amlogic,axg-pcie", "snps,dw-pcie";
+ reg = <0x0 0xf980 0x0 0x40
+ 0x0 0xff646000 0x0 0x2000
+ 0x0 0xff644000 0x0 0x2000
+ 0x0 0xf9f0 0x0 0x10>;
+ reg-names = "elbi", "cfg", "phy", "config";
+ reset-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>;
+ interrupts = ;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 179
IRQ_TYPE_EDGE_RISING>;
+ bus-range = <0x0 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x8200 0 0 0x0 0xf9c0 0 0x0030>;
+
+ clocks = <&clkc CLKID_USB
+ &clkc CLKID_MIPI_ENABLE
+ &clkc CLKID_PCIE_A
+ &clkc CLKID_PCIE_CML_EN0>;
+ clock-names = "general",
+ "mipi",
+ "pclk",
+ "port";
+ resets = <&reset RESET_PCIE_PHY>,
+ <&reset RESET_PCIE_A>,
+ <&reset RESET_PCIE_APB>;
+ reset-names = "phy",
+ "port",
+ "apb";
+ };
--
2.7.4
[PATCH v8 0/2 RESEND] add the Amlogic Meson PCIe controller driver
The Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI core. This patchset add the driver and dt-bindings of the controller. Changes since v7: [6] - include files in alphabetical order - get rid of unused MACROs and variables - optimize meson_pcie_link_up() while loop - correct cover-letter version Changes since v6: [5] - fix bad usage of ERR_PTR(ENXIO) - fix meson_pcie_rd_own_conf() when read PCI_CLASS_DEVICE reg Changes since v5: [4] - update MAINTAINER file in alphabetical order - remove meaningless comment - use ERR_PTR function instead of (void *) cast - use is_power_of_2(size) instead of size & (size - 1) - add comment for PCI_CLASS_REVISION register operation Changes since v4: [3] - fix kbuild test robot and compile warnings Changes since v3: [2] - modify subject format - update Kconfig - update MAINTAINER file - add comment and error handle for meson_pcie_get_mem_shared() - drop useless initialization code - add comment for meson_size_to_payload() - optimize meson_pcie_establish_link() return code - optimize meson_pcie_enable_interrupts() redundant function - drop device_attch related code - drop dw_pcie_ops read_dbi and write_dbi function - add error handle for meson_add_pcie_port() when probe Changes since v2: [1] - abandon phy driver, move reset to the controller - use devm_add_action_or_reset() to use clock res - format correcting Changes since v1: [0] - use gpio lib instead open code - move 'apb' and 'port' reset from phy driver - format correcting [0] : https://lkml.kernel.org/r/1534227522-186798-1-git-send-email-hanjie@amlogic.com [1] : https://lkml.kernel.org/r/1535096165-45827-1-git-send-email-hanjie@amlogic.com [2] : https://lkml.kernel.org/r/1537509820-52040-1-git-send-email-hanjie@amlogic.com [3] : https://lkml.kernel.org/r/1538999834-156423-3-git-send-email-hanjie@amlogic.com [4] : https://lkml.kernel.org/r/1539049990-30810-1-git-send-email-hanjie@amlogic.com [5] : https://lkml.kernel.org/r/1542876836-191355-1-git-send-email-hanjie@amlogic.com [6] : https://lkml.kernel.org/r/1544097760-85834-1-git-send-email-hanjie@amlogic.com Yue Wang (2): dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller PCI: amlogic: Add the Amlogic Meson PCIe controller driver .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 70 +++ MAINTAINERS| 7 + drivers/pci/controller/dwc/Kconfig | 10 + drivers/pci/controller/dwc/Makefile| 1 + drivers/pci/controller/dwc/pci-meson.c | 595 + 5 files changed, 683 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt create mode 100644 drivers/pci/controller/dwc/pci-meson.c -- 2.7.4
[PATCH v6 04/11] ARM: dts: Add devicetree for RDA8810PL SoC
Add initial device tree for RDA8810PL SoC from RDA Microelectronics.
Signed-off-by: Andreas Färber
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/boot/dts/rda8810pl.dtsi | 86
1 file changed, 86 insertions(+)
create mode 100644 arch/arm/boot/dts/rda8810pl.dtsi
diff --git a/arch/arm/boot/dts/rda8810pl.dtsi b/arch/arm/boot/dts/rda8810pl.dtsi
new file mode 100644
index ..15547b138977
--- /dev/null
+++ b/arch/arm/boot/dts/rda8810pl.dtsi
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * RDA8810PL SoC
+ *
+ * Copyright (c) 2017 Andreas Färber
+ * Copyright (c) 2018 Manivannan Sadhasivam
+ */
+
+/ {
+ compatible = "rda,8810pl";
+ interrupt-parent = <&intc>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a5";
+ reg = <0x0>;
+ };
+ };
+
+ sram@10 {
+ compatible = "mmio-sram";
+ reg = <0x10 0x1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ };
+
+ apb@2080 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x2080 0x10>;
+
+ intc: interrupt-controller@0 {
+ compatible = "rda,8810pl-intc";
+ reg = <0x0 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
+ apb@2090 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x2090 0x10>;
+ };
+
+ apb@20a0 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x20a0 0x10>;
+
+ uart1: serial@0 {
+ compatible = "rda,8810pl-uart";
+ reg = <0x0 0x1000>;
+ status = "disabled";
+ };
+
+ uart2: serial@1 {
+ compatible = "rda,8810pl-uart";
+ reg = <0x1 0x1000>;
+ status = "disabled";
+ };
+
+ uart3: serial@9 {
+ compatible = "rda,8810pl-uart";
+ reg = <0x9 0x1000>;
+ status = "disabled";
+ };
+ };
+
+ l2: cache-controller@2110 {
+ compatible = "arm,pl310-cache";
+ reg = <0x2110 0x1000>;
+ cache-unified;
+ cache-level = <2>;
+ };
+};
--
2.17.1
[PATCH v6 00/11] Add initial RDA8810PL SoC and Orange Pi boards support
Hello, This patchset adds initial RDA8810PL SoC and Orange Pi boards (2G IoT and i96) support. RDA8810PL is an ARM Cortex A5 based SoC with Vivante's GC860 GPU. The SoC has been added as a new ARM sub architecture with myself and Andreas as the maintainers. More information about the boards can be found in below links: 1. Orange Pi 2G-IoT - http://www.orangepi.org/OrangePi2GIOT/ 2. Orange Pi i96 - https://www.96boards.org/product/orangepi-i96/ This patchset is based on the initial revision sent out by Andreas long back (http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/515951.html). I have extended his patchset with proper irqchip and UART drivers. Now, boards can boot into initramfs with console at UART2. Thanks, Mani Changes in v6: * Fixed the MAINTAINERS patch commit message Changes in v5: * Dropped timer and irqchip patches since they got applied * Dropped Andreas from MAINTAINERS as per his request Changes in v4: * Added Rob's Reviewed-by tags for vendor and SoC patches. * Moved platform Kconfig changes from timer and irqchip drivers to SoC support patch. * Added Marc's Reviewed-by tag for irqchip driver. * Addressed Rob's review comments for bindings patches. * Added the newly created linux-unisoc mailing list to MAINTAINERS entry. * Dropped overseas.sa...@unisoc.com mail address as it is bouncing back. * Modified the DTS subject prefix to ARM: from arm: Changes in v3: As per Marc's review: * Removed unused header and defines from irqchip driver. * Removed setting flow handlers from set_type callback. * Minor code cleanups. As per Arnd's review: * Modified the UART indexes to start from 1 to match the SoC numbering * Enabled exposed UARTs (all 3 on both boards) * Modified the serial aliases as per board numbering * Added Greg's Reviewed-by tag for serial driver. Changes in v2: * Used readl/writel_relaxed calls for both irqchip and timer drivers as per Marc's review. * Implemented the logic to prevent counter wrapping during read as suggested by Marc. * Used the timer-of API as per Daniel's suggestion. * Added description about the timer in both commit log and driver. * Changed the Vendor name for RDA to Unisoc Communications Inc. * Removed the soc node level and cleaned up devicetrees as per Rob's review. * Merged interrupt controller DT patch to SoC. * Moved aliases to board dts as per Arnd's suggestion. * Removed RDA Micro support mail address and used Unisoc one and added my missing signed off by tag as per Andreas's comments. Andreas Färber (4): dt-bindings: Add RDA Micro vendor prefix dt-bindings: arm: Document RDA8810PL and reference boards ARM: Prepare RDA8810PL SoC dt-bindings: serial: Document RDA Micro UART Manivannan Sadhasivam (7): ARM: dts: Add devicetree for RDA8810PL SoC ARM: dts: Add devicetree for OrangePi 2G IoT board ARM: dts: Add devicetree for OrangePi i96 board ARM: dts: rda8810pl: Add timer support ARM: dts: rda8810pl: Add interrupt support for UART tty: serial: Add RDA8810PL UART driver MAINTAINERS: Add entry for RDA Micro SoC architecture .../admin-guide/kernel-parameters.txt | 6 + Documentation/devicetree/bindings/arm/rda.txt | 17 + .../bindings/serial/rda,8810pl-uart.txt | 17 + .../devicetree/bindings/vendor-prefixes.txt | 1 + MAINTAINERS | 14 + arch/arm/Kconfig | 2 + arch/arm/Makefile | 1 + arch/arm/boot/dts/Makefile| 3 + .../boot/dts/rda8810pl-orangepi-2g-iot.dts| 50 ++ arch/arm/boot/dts/rda8810pl-orangepi-i96.dts | 50 ++ arch/arm/boot/dts/rda8810pl.dtsi | 99 +++ arch/arm/mach-rda/Kconfig | 9 + arch/arm/mach-rda/Makefile| 1 + drivers/tty/serial/Kconfig| 19 + drivers/tty/serial/Makefile | 1 + drivers/tty/serial/rda-uart.c | 831 ++ include/uapi/linux/serial_core.h | 3 + 17 files changed, 1124 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/rda.txt create mode 100644 Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt create mode 100644 arch/arm/boot/dts/rda8810pl-orangepi-2g-iot.dts create mode 100644 arch/arm/boot/dts/rda8810pl-orangepi-i96.dts create mode 100644 arch/arm/boot/dts/rda8810pl.dtsi create mode 100644 arch/arm/mach-rda/Kconfig create mode 100644 arch/arm/mach-rda/Makefile create mode 100644 drivers/tty/serial/rda-uart.c -- 2.17.1
[PATCH v6 01/11] dt-bindings: Add RDA Micro vendor prefix
From: Andreas Färber Add vendor prefix for RDA Micro which now merged into Unisoc Communications Inc. Signed-off-by: Andreas Färber Signed-off-by: Manivannan Sadhasivam Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 4b1a2a8fcc16..37826fac7684 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -320,6 +320,7 @@ ralink Mediatek/Ralink Technology Corp. ramtronRamtron International raspberrypiRaspberry Pi Foundation raydiumRaydium Semiconductor Corp. +rdaUnisoc Communications, Inc. realtek Realtek Semiconductor Corp. renesasRenesas Electronics Corporation richtekRichtek Technology Corporation -- 2.17.1
[PATCH v6 02/11] dt-bindings: arm: Document RDA8810PL and reference boards
From: Andreas Färber Add bindings for RDA Micro RDA8810PL SoC and below reference boards: 1. Orange Pi 2G-IoT - http://www.orangepi.org/OrangePi2GIOT/ 2. Orange Pi i96 - https://www.96boards.org/product/orangepi-i96/ Cc: zhao_ste...@263.net Signed-off-by: Andreas Färber Signed-off-by: Manivannan Sadhasivam Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/rda.txt | 17 + 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/rda.txt diff --git a/Documentation/devicetree/bindings/arm/rda.txt b/Documentation/devicetree/bindings/arm/rda.txt new file mode 100644 index ..43c80762c428 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/rda.txt @@ -0,0 +1,17 @@ +RDA Micro platforms device tree bindings + + +RDA8810PL SoC += + +Required root node properties: + + - compatible : must contain "rda,8810pl" + + +Boards: + +Root node property compatible must contain, depending on board: + + - Orange Pi 2G-IoT: "xunlong,orangepi-2g-iot" + - Orange Pi i96: "xunlong,orangepi-i96" -- 2.17.1
[PATCH v6 03/11] ARM: Prepare RDA8810PL SoC
From: Andreas Färber Introduce ARCH_RDA and mach-rda for RDA Micro SoCs. Signed-off-by: Andreas Färber Signed-off-by: Manivannan Sadhasivam --- arch/arm/Kconfig | 2 ++ arch/arm/Makefile | 1 + arch/arm/mach-rda/Kconfig | 9 + arch/arm/mach-rda/Makefile | 1 + 4 files changed, 13 insertions(+) create mode 100644 arch/arm/mach-rda/Kconfig create mode 100644 arch/arm/mach-rda/Makefile diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 91be74d8df65..084f0983e6b2 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -804,6 +804,8 @@ source "arch/arm/plat-pxa/Kconfig" source "arch/arm/mach-qcom/Kconfig" +source "arch/arm/mach-rda/Kconfig" + source "arch/arm/mach-realview/Kconfig" source "arch/arm/mach-rockchip/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 05a91d8b89f3..10056ccdb8be 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -202,6 +202,7 @@ machine-$(CONFIG_ARCH_ORION5X) += orion5x machine-$(CONFIG_ARCH_PICOXCELL) += picoxcell machine-$(CONFIG_ARCH_PXA) += pxa machine-$(CONFIG_ARCH_QCOM)+= qcom +machine-$(CONFIG_ARCH_RDA) += rda machine-$(CONFIG_ARCH_REALVIEW)+= realview machine-$(CONFIG_ARCH_ROCKCHIP)+= rockchip machine-$(CONFIG_ARCH_RPC) += rpc diff --git a/arch/arm/mach-rda/Kconfig b/arch/arm/mach-rda/Kconfig new file mode 100644 index ..1ea753f57b2d --- /dev/null +++ b/arch/arm/mach-rda/Kconfig @@ -0,0 +1,9 @@ +menuconfig ARCH_RDA + bool "RDA Micro SoCs" + depends on ARCH_MULTI_V7 + select COMMON_CLK + select GENERIC_IRQ_CHIP + select RDA_INTC + select RDA_TIMER + help + This enables support for the RDA Micro 8810PL SoC family. diff --git a/arch/arm/mach-rda/Makefile b/arch/arm/mach-rda/Makefile new file mode 100644 index ..6bea3d3a2dd7 --- /dev/null +++ b/arch/arm/mach-rda/Makefile @@ -0,0 +1 @@ +obj- += dummy.o -- 2.17.1
[PATCH v6 05/11] ARM: dts: Add devicetree for OrangePi 2G IoT board
Add initial devicetree support for OrangePi 2G IoT board from Xunlong.
Signed-off-by: Andreas Färber
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/boot/dts/Makefile| 2 +
.../boot/dts/rda8810pl-orangepi-2g-iot.dts| 50 +++
2 files changed, 52 insertions(+)
create mode 100644 arch/arm/boot/dts/rda8810pl-orangepi-2g-iot.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b0e966d625b9..a0fdad8f10dd 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -806,6 +806,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8974-sony-xperia-castor.dtb \
qcom-msm8974-sony-xperia-honami.dtb \
qcom-mdm9615-wp8548-mangoh-green.dtb
+dtb-$(CONFIG_ARCH_RDA) += \
+ rda8810pl-orangepi-2g-iot.dtb
dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb \
arm-realview-pb11mp.dtb \
diff --git a/arch/arm/boot/dts/rda8810pl-orangepi-2g-iot.dts
b/arch/arm/boot/dts/rda8810pl-orangepi-2g-iot.dts
new file mode 100644
index ..98e34248ae80
--- /dev/null
+++ b/arch/arm/boot/dts/rda8810pl-orangepi-2g-iot.dts
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ * Copyright (c) 2018 Manivannan Sadhasivam
+ */
+
+/dts-v1/;
+
+#include "rda8810pl.dtsi"
+
+/ {
+ compatible = "xunlong,orangepi-2g-iot", "rda,8810pl";
+ model = "Orange Pi 2G-IoT";
+
+ aliases {
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial2:921600n8";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x8000 0x1000>;
+ };
+
+ uart_clk: uart-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <921600>;
+ #clock-cells = <0>;
+ };
+};
+
+&uart1 {
+ status = "okay";
+ clocks = <&uart_clk>;
+};
+
+&uart2 {
+ status = "okay";
+ clocks = <&uart_clk>;
+};
+
+&uart3 {
+ status = "okay";
+ clocks = <&uart_clk>;
+};
--
2.17.1
[PATCH v6 08/11] dt-bindings: serial: Document RDA Micro UART
From: Andreas Färber
Add an initial binding for the UART in RDA Micro RDA8810PL SoC.
Signed-off-by: Andreas Färber
Signed-off-by: Manivannan Sadhasivam
---
.../bindings/serial/rda,8810pl-uart.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
diff --git a/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
new file mode 100644
index ..a08df97a69e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
@@ -0,0 +1,17 @@
+RDA Micro UART
+
+Required properties:
+- compatible : "rda,8810pl-uart" for RDA8810PL SoCs.
+- reg: Offset and length of the register set for the device.
+- interrupts : Should contain UART interrupt.
+- clocks : Phandle to the input clock.
+
+
+Example:
+
+ uart2: serial@20a9 {
+ compatible = "rda,8810pl-uart";
+ reg = <0x20a9 0x1000>;
+ interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uart_clk>;
+ };
--
2.17.1
[PATCH v6 07/11] ARM: dts: rda8810pl: Add timer support
Add timer support for RDA Micro RDA8810PL SoC.
Signed-off-by: Andreas Färber
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/boot/dts/rda8810pl.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/rda8810pl.dtsi b/arch/arm/boot/dts/rda8810pl.dtsi
index 15547b138977..84baa4c0a14c 100644
--- a/arch/arm/boot/dts/rda8810pl.dtsi
+++ b/arch/arm/boot/dts/rda8810pl.dtsi
@@ -6,6 +6,8 @@
* Copyright (c) 2018 Manivannan Sadhasivam
*/
+#include
+
/ {
compatible = "rda,8810pl";
interrupt-parent = <&intc>;
@@ -50,6 +52,14 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x2090 0x10>;
+
+ timer@1 {
+ compatible = "rda,8810pl-timer";
+ reg = <0x1 0x1000>;
+ interrupts = <16 IRQ_TYPE_LEVEL_HIGH>,
+<17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hwtimer", "ostimer";
+ };
};
apb@20a0 {
--
2.17.1
[PATCH v6 09/11] ARM: dts: rda8810pl: Add interrupt support for UART
Add interrupt support for UART in RDA Micro RDA8810PL SoC.
Signed-off-by: Andreas Färber
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/boot/dts/rda8810pl.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/rda8810pl.dtsi b/arch/arm/boot/dts/rda8810pl.dtsi
index 84baa4c0a14c..19cde895bf65 100644
--- a/arch/arm/boot/dts/rda8810pl.dtsi
+++ b/arch/arm/boot/dts/rda8810pl.dtsi
@@ -71,18 +71,21 @@
uart1: serial@0 {
compatible = "rda,8810pl-uart";
reg = <0x0 0x1000>;
+ interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
uart2: serial@1 {
compatible = "rda,8810pl-uart";
reg = <0x1 0x1000>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
uart3: serial@9 {
compatible = "rda,8810pl-uart";
reg = <0x9 0x1000>;
+ interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
};
--
2.17.1
[PATCH 2/2] mfd: tps65218.c: Add input voltage options
These options apply to all regulators in this chip.
strict-supply-voltage:
Set STRICT flag in CONFIG1
under-voltage-limit:
Select 2.75, 2.95, 3.25 or 3.35 V UVLO in CONFIG1
under-voltage-hysteresis:
Select 200mV or 400mV UVLOHYS in CONFIG2
Signed-off-by: Christian Hohnstaedt
---
drivers/mfd/tps65218.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 8bcdecf..f5e559b 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -211,6 +211,50 @@ static const struct of_device_id of_tps65218_match_table[]
= {
};
MODULE_DEVICE_TABLE(of, of_tps65218_match_table);
+static void tps65218_options(struct tps65218 *tps)
+{
+ struct device *dev = tps->dev;
+ struct device_node *np = dev->of_node;
+ u32 pval;
+
+ if (!of_property_read_u32(np, "strict-supply-voltage", &pval)) {
+ tps65218_update_bits(tps, TPS65218_REG_CONFIG1,
+ TPS65218_CONFIG1_STRICT,
+ pval ? TPS65218_CONFIG1_STRICT : 0,
+ TPS65218_PROTECT_L1);
+ dev_dbg(dev, "tps65218 strict-supply-voltage: %d\n", pval);
+ }
+ if (!of_property_read_u32(np, "under-voltage-hysteresis", &pval)) {
+ if (pval != 40 && pval != 20) {
+ dev_err(dev,
+"under-voltage-hysteresis must be %d or %d\n",
+20, 40);
+ } else {
+ tps65218_update_bits(tps, TPS65218_REG_CONFIG2,
+ TPS65218_CONFIG2_UVLOHYS,
+ pval == 40 ? TPS65218_CONFIG2_UVLOHYS : 0,
+ TPS65218_PROTECT_L1);
+ }
+ dev_dbg(dev, "tps65218 under-voltage-hysteresis: %d\n", pval);
+ }
+ if (!of_property_read_u32(np, "under-voltage-limit", &pval)) {
+ int i, vals[] = { 275, 295, 325, 335 };
+
+ for (i = 0; i < ARRAY_SIZE(vals); i++) {
+ if (pval == vals[i] * 1)
+ break;
+ }
+ if (i < ARRAY_SIZE(vals)) {
+ tps65218_update_bits(tps, TPS65218_REG_CONFIG1,
+ TPS65218_CONFIG1_UVLO_MASK, i,
+ TPS65218_PROTECT_L1);
+ } else {
+ dev_err(dev, "Invalid under-voltage-limit: %d\n", pval);
+ }
+ dev_dbg(dev, "tps65218 under-voltage-limit: %d=%d\n", pval, i);
+ }
+}
+
static int tps65218_probe(struct i2c_client *client,
const struct i2c_device_id *ids)
{
@@ -249,6 +293,8 @@ static int tps65218_probe(struct i2c_client *client,
tps->rev = chipid & TPS65218_CHIPID_REV_MASK;
+ tps65218_options(tps);
+
ret = mfd_add_devices(tps->dev, PLATFORM_DEVID_AUTO, tps65218_cells,
ARRAY_SIZE(tps65218_cells), NULL, 0,
regmap_irq_get_domain(tps->irq_data));
--
2.7.4
[PATCH v6 10/11] tty: serial: Add RDA8810PL UART driver
Add UART driver for RDA Micro RDA8810PL SoC. Signed-off-by: Andreas Färber Signed-off-by: Manivannan Sadhasivam Reviewed-by: Greg Kroah-Hartman --- .../admin-guide/kernel-parameters.txt | 6 + drivers/tty/serial/Kconfig| 19 + drivers/tty/serial/Makefile | 1 + drivers/tty/serial/rda-uart.c | 831 ++ include/uapi/linux/serial_core.h | 3 + 5 files changed, 860 insertions(+) create mode 100644 drivers/tty/serial/rda-uart.c diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 81d1d5a74728..07078880f7fd 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1020,6 +1020,12 @@ specified address. The serial port must already be setup and configured. Options are not yet supported. + rda, + Start an early, polled-mode console on a serial port + of an RDA Micro SoC, such as RDA8810PL, at the + specified address. The serial port must already be + setup and configured. Options are not yet supported. + smh Use ARM semihosting calls for early console. s3c2410, diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 32886c304641..67b9bf3b500e 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1529,6 +1529,25 @@ config SERIAL_OWL_CONSOLE Say 'Y' here if you wish to use Actions Semiconductor S500/S900 UART as the system console. +config SERIAL_RDA + bool "RDA Micro serial port support" + depends on ARCH_RDA || COMPILE_TEST + select SERIAL_CORE + help + This driver is for RDA8810PL SoC's UART. + Say 'Y' here if you wish to use the on-board serial port. + Otherwise, say 'N'. + +config SERIAL_RDA_CONSOLE + bool "Console on RDA Micro serial port" + depends on SERIAL_RDA=y + select SERIAL_CORE_CONSOLE + select SERIAL_EARLYCON + default y + help + Say 'Y' here if you wish to use the RDA8810PL UART as the system + console. Only earlycon is implemented currently. + endmenu config SERIAL_MCTRL_GPIO diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile index daac675612df..8c303736b7e8 100644 --- a/drivers/tty/serial/Makefile +++ b/drivers/tty/serial/Makefile @@ -89,6 +89,7 @@ obj-$(CONFIG_SERIAL_MVEBU_UART) += mvebu-uart.o obj-$(CONFIG_SERIAL_PIC32) += pic32_uart.o obj-$(CONFIG_SERIAL_MPS2_UART) += mps2-uart.o obj-$(CONFIG_SERIAL_OWL) += owl-uart.o +obj-$(CONFIG_SERIAL_RDA) += rda-uart.o # GPIOLIB helpers for modem control lines obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o diff --git a/drivers/tty/serial/rda-uart.c b/drivers/tty/serial/rda-uart.c new file mode 100644 index ..284623eefaeb --- /dev/null +++ b/drivers/tty/serial/rda-uart.c @@ -0,0 +1,831 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * RDA8810PL serial device driver + * + * Copyright RDA Microelectronics Company Limited + * Copyright (c) 2017 Andreas Färber + * Copyright (c) 2018 Manivannan Sadhasivam + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RDA_UART_PORT_NUM 3 +#define RDA_UART_DEV_NAME "ttyRDA" + +#define RDA_UART_CTRL 0x00 +#define RDA_UART_STATUS0x04 +#define RDA_UART_RXTX_BUFFER 0x08 +#define RDA_UART_IRQ_MASK 0x0c +#define RDA_UART_IRQ_CAUSE 0x10 +#define RDA_UART_IRQ_TRIGGERS 0x14 +#define RDA_UART_CMD_SET 0x18 +#define RDA_UART_CMD_CLR 0x1c + +/* UART_CTRL Bits */ +#define RDA_UART_ENABLEBIT(0) +#define RDA_UART_DBITS_8 BIT(1) +#define RDA_UART_TX_SBITS_2BIT(2) +#define RDA_UART_PARITY_EN BIT(3) +#define RDA_UART_PARITY(x) (((x) & 0x3) << 4) +#define RDA_UART_PARITY_ODDRDA_UART_PARITY(0) +#define RDA_UART_PARITY_EVEN RDA_UART_PARITY(1) +#define RDA_UART_PARITY_SPACE RDA_UART_PARITY(2) +#define RDA_UART_PARITY_MARK RDA_UART_PARITY(3) +#define RDA_UART_DIV_MODE BIT(20) +#define RDA_UART_IRDA_EN BIT(21) +#define RDA_UART_DMA_ENBIT(22) +#define RDA_UART_FLOW_CNT_EN BIT(23) +#define RDA_UART_LOOP_BACK_EN BIT(24) +#define RDA_UART_RX_LOCK_ERR BIT(25) +#define RDA_UART_RX_BREAK_LEN(x) (((x) & 0xf) << 28) + +/* UART_STATUS Bits */ +#define RDA_UART_RX_FIFO(x)(((x) & 0x7f) << 0) +#define RDA_UART_RX_FIFO_MASK (0x7f << 0) +#define RDA_UART_TX_FIFO(x)(((x) & 0x1f) << 8) +#define RDA_UART_TX_FIFO_MASK (0x1f << 8) +#define RDA_UART_
[PATCH v6 11/11] MAINTAINERS: Add entry for RDA Micro SoC architecture
Add MAINTAINERS entry for RDA Micro SoC architecture with myself as the maintainer. Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6c3fbbb361f8..7f2ae2ed53f4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1945,6 +1945,20 @@ M: Lennert Buytenhek L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained +ARM/RDA MICRO ARCHITECTURE +M: Manivannan Sadhasivam +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: linux-uni...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: arch/arm/boot/dts/rda8810pl-* +F: drivers/clocksource/timer-rda.c +F: drivers/irqchip/irq-rda-intc.c +F: drivers/tty/serial/rda-uart.c +F: Documentation/devicetree/bindings/arm/rda.txt +F: Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.txt +F: Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt +F: Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt + ARM/REALTEK ARCHITECTURE M: Andreas Färber L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 2.17.1
[PATCH 0/2] Add input voltage configuration for TPS65218
This patch allows to configure input-voltage settings of the TPS65218 regulator via device tree. Christian Hohnstaedt (2): dt-bindings: regulator: extend tps65218 bindings mfd: tps65218.c: Add input voltage options .../devicetree/bindings/regulator/tps65218.txt | 10 + drivers/mfd/tps65218.c | 46 ++ 2 files changed, 56 insertions(+) -- 2.7.4
[PATCH v6 06/11] ARM: dts: Add devicetree for OrangePi i96 board
Add initial devicetree for Orange Pi i96 board from Xunlong. It
is one of the 96Boards IoT Edition board.
Signed-off-by: Andreas Färber
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/rda8810pl-orangepi-i96.dts | 50
2 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/rda8810pl-orangepi-i96.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a0fdad8f10dd..cfb08ea33872 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -807,7 +807,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8974-sony-xperia-honami.dtb \
qcom-mdm9615-wp8548-mangoh-green.dtb
dtb-$(CONFIG_ARCH_RDA) += \
- rda8810pl-orangepi-2g-iot.dtb
+ rda8810pl-orangepi-2g-iot.dtb \
+ rda8810pl-orangepi-i96.dtb
dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb \
arm-realview-pb11mp.dtb \
diff --git a/arch/arm/boot/dts/rda8810pl-orangepi-i96.dts
b/arch/arm/boot/dts/rda8810pl-orangepi-i96.dts
new file mode 100644
index ..728f76931b99
--- /dev/null
+++ b/arch/arm/boot/dts/rda8810pl-orangepi-i96.dts
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ * Copyright (c) 2018 Manivannan Sadhasivam
+ */
+
+/dts-v1/;
+
+#include "rda8810pl.dtsi"
+
+/ {
+ compatible = "xunlong,orangepi-i96", "rda,8810pl";
+ model = "Orange Pi i96";
+
+ aliases {
+ serial0 = &uart2;
+ serial1 = &uart1;
+ serial2 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial2:921600n8";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x8000 0x1000>;
+ };
+
+ uart_clk: uart-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <921600>;
+ #clock-cells = <0>;
+ };
+};
+
+&uart1 {
+ status = "okay";
+ clocks = <&uart_clk>;
+};
+
+&uart2 {
+ status = "okay";
+ clocks = <&uart_clk>;
+};
+
+&uart3 {
+ status = "okay";
+ clocks = <&uart_clk>;
+};
--
2.17.1
[PATCH 1/2] dt-bindings: regulator: extend tps65218 bindings
Add input voltage configuration options
Signed-off-by: Christian Hohnstaedt
---
Documentation/devicetree/bindings/regulator/tps65218.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
index 02f0e9b..a9ee377 100644
--- a/Documentation/devicetree/bindings/regulator/tps65218.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -16,12 +16,22 @@ Required properties:
regulator-dcdc5, regulator-dcdc6, regulator-ldo1, regulator-ls3.
Each regulator is defined using the standard binding for regulators.
+Optional properties:
+ If any of these properties is absent, the setting will not be touched.
+- strict-supply-voltage: <1|0> Set/Reset STRICT flag in CONFIG1
+- under-voltage-limit: Select 2.75, 2.95, 3.25 or 3.35V as UVLO in CONFIG1
+- under-voltage-hysteresis: Select 200mV or 400mV UVLOHYS in CONFIG2
+
Example:
tps65218: tps65218@24 {
reg = <0x24>;
compatible = "ti,tps65218";
interrupts = ; /* NMIn */
interrupt-controller;
+ strict-supply-voltage = <1>;
+ under-voltage-hysteresis = <40>;
+ under-voltage-limit = <335>;
+
#interrupt-cells = <2>;
dcdc1: regulator-dcdc1 {
--
2.7.4
Re: [PATCH 05/14] mm, compaction: Skip pageblocks with reserved pages
On 12/15/18 12:03 AM, Mel Gorman wrote: > Reserved pages are set at boot time, tend to be clustered and almost > never become unreserved. When isolating pages for migrating, skip > the entire pageblock is one PageReserved page is encountered on the > grounds that it is highly probable the entire pageblock is reserved. Agreed, but maybe since it's highly probable and not certain, this skipping should not be done on the highest compaction priority? > The impact depends on the machine and timing but both thpscale and > thpfioscale when using MADV_HUGEPAGE show a reduction of scanning and > fault latency on a 1-socket machine. The 2-socket results were too > noisy to draw any meaningful conclusion but it's safe to assume less > scanning is useful. > > 1-socket thpfioscale >4.20.0-rc6 4.20.0-rc6 >mmotm-20181210noreserved-v1r4 > Amean fault-base-1 1481.32 ( 0.00%) 1443.63 ( 2.54%) > Amean fault-huge-1 1118.17 ( 0.00%) 981.30 * 12.24%* > Amean fault-both-1 1176.43 ( 0.00%) 1052.64 * 10.52%* > > Compaction migrate scanned 3860713 3294284 > Compaction free scanned 613786341 433423502 > Kcompactd migrate scanned 408711 291915 > Kcompactd free scanned 242509759 217164988 > > Signed-off-by: Mel Gorman > --- > mm/compaction.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/mm/compaction.c b/mm/compaction.c > index 3afa4e9188b6..8134dba47584 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -827,6 +827,13 @@ isolate_migratepages_block(struct compact_control *cc, > unsigned long low_pfn, > goto isolate_success; > } > > + /* > + * A reserved page is never freed and tend to be > + * clustered in the same pageblocks. Skip the block. > + */ > + if (PageReserved(page)) > + low_pfn = end_pfn; > + > goto isolate_fail; > } > >
Re: [PATCH v2 03/12] PCI: aardvark: Add PHY support
Hi Baruch, Baruch Siach wrote on Mon, 17 Dec 2018 20:27:42 +0200: > Hi Miquel, > > Miquel Raynal writes: > > Marek Behun wrote on Fri, 14 Dec 2018 01:57:12 > > +0100: > > > >> On Fri, 14 Dec 2018 01:47:01 +0100 > >> Marek Behun wrote: > >> > >> > are there already patches for the A37xx comphy driver? > > > > Please try the latest patches on top of phy -next (with PHY interface > > mode), available there [1]. You can pick only the COMPHY patches, but > > keep them over the phy -next branch. > > > > Please note that for the SMC calls to succeed you must use a recent > > ATF. Personally I used to work with the 'atf-v1.5-devel' branch of > > Marvell's misl-atf repository but it is not available anymore. If you > > already have a clone, then you are good to go, otherwise it might be > > great if someone from Marvell could share a public Github link? > > The latest ATF from Marvell is at the 'atf-v1.5-armada-18.09' branch at > > https://github.com/MarvellEmbeddedProcessors/atf-marvell Indeed, but I don't see A3700 COMPHY support there (only CP110's), I think it will be merged into 18.12 release (will happen this month). Thanks, Miquèl
Re: [PATCH] scripts/tags: Add more declarations
On 18.12.2018 00:09, Matthew Wilcox wrote: > On Mon, Dec 17, 2018 at 03:41:46PM +0300, Kirill Tkhai wrote: >> -'/\> + >> '/\> '/\ > I don't know anything about regexes this complex or tags, but couldn't this > be '/\ DEFINE_THINGIES? I think, we can, but before this it's needed to change arguments order in macroses like DEFINE_PER_CPU(), and to check, whether tags won't be polluted something not needed (such wrong defines will be generated anyway, but if there will be not too many, than it's OK).
Re: [PATCH] Input: elantech - Disable elan-i2c for P52 and P72
On Wed, Dec 12, 2018 at 04:42:05PM +0100, Benjamin Tissoires wrote:
> The current implementation of elan_i2c is known to not support those
> 2 laptops.
>
> A proper fix is to tweak both elantech and elan_i2c to transmit the
> correct information from PS/2, which would make a bad candidate for
> stable.
>
> So to give us some time for fixing the root of the problem, disable
> elan_i2c for the devices we know are not behaving properly.
>
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> Link: https://bugs.archlinux.org/task/59714
> Fixes: df077237cf55 Input: elantech - detect new ICs and setup Host Notify
> for them
>
> Cc: sta...@vger.kernel.org # v4.18+
> Signed-off-by: Benjamin Tissoires
Acked-by: Peter Hutterer
Cheers,
Peter
> ---
> drivers/input/mouse/elantech.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 2d95e8d93cc7..830ae9f07045 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1767,6 +1767,18 @@ static int elantech_smbus =
> IS_ENABLED(CONFIG_MOUSE_ELAN_I2C_SMBUS) ?
> module_param_named(elantech_smbus, elantech_smbus, int, 0644);
> MODULE_PARM_DESC(elantech_smbus, "Use a secondary bus for the Elantech
> device.");
>
> +static const char * const i2c_blacklist_pnp_ids[] = {
> + /*
> + * these are known to not be working properly as bits are missing
> + * in elan_i2c
> + */
> + "LEN2131", /* ThinkPad P52 w/ NFC */
> + "LEN2132", /* ThinkPad P52 */
> + "LEN2133", /* ThinkPad P72 w/ NFC */
> + "LEN2134", /* ThinkPad P72 */
> + NULL
> +};
> +
> static int elantech_create_smbus(struct psmouse *psmouse,
>struct elantech_device_info *info,
>bool leave_breadcrumbs)
> @@ -1802,10 +1814,12 @@ static int elantech_setup_smbus(struct psmouse
> *psmouse,
>
> if (elantech_smbus == ELANTECH_SMBUS_NOT_SET) {
> /*
> - * New ICs are enabled by default.
> + * New ICs are enabled by default, unless mentioned in
> + * i2c_blacklist_pnp_ids.
>* Old ICs are up to the user to decide.
>*/
> - if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
> + if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version) ||
> + psmouse_matches_pnp_id(psmouse, i2c_blacklist_pnp_ids))
> return -ENXIO;
> }
>
> --
> 2.19.2
>
Re: [PATCH v2 0/7] x86/kvm/hyper-v: Implement KVM_GET_SUPPORTED_HV_CPUID
Paolo Bonzini writes: > On 17/12/18 11:30, Vitaly Kuznetsov wrote: >>> Queued, thanks. I moved this above the direct EOI series so that >>> KVM_CAP_HYPERV_STIMER_DIRECT need not exist at any point of the history. >>> >> Thanks! Just to make sure (and to conclude our discussion with Roman): >> with your Qemu maintainer hat on, do you agree with the design decision >> that KVM_GET_SUPPORTED_HV_CPUID's output value changes when >> KVM_CAP_HYPERV_ENLIGHTENED_VMCS gets enabled? This differs from >> KVM_GET_SUPPORTED_CPUID (where we always list all feature bits even if >> they require explicit enablement)? > > It doesn't really matter, since the old capability cannot be removed. > If you want to change it with a patch on top, that's also okay with me. Ok, let's leave it as it is: maybe some other userspace (which doesn't use legacy capabilities) will be grateful :-) -- Vitaly
Re: [PATCH v2 2/3] sched/fair: trigger asym_packing during idle load balance
On Mon, 17 Dec 2018 at 17:59, Valentin Schneider
wrote:
>
> Hi Vincent,
>
> On 14/12/2018 16:01, Vincent Guittot wrote:
> > newly idle load balance is not always triggered when a cpu becomes idle.
> > This prevent the scheduler to get a chance to migrate task for asym packing.
> > Enable active migration because of asym packing during idle load balance
> > too.
> >
> > Signed-off-by: Vincent Guittot
> > ---
> > kernel/sched/fair.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index c215f7a..9591e7a 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -8861,7 +8861,7 @@ static int need_active_balance(struct lb_env *env)
> > {
> > struct sched_domain *sd = env->sd;
> >
> > - if (env->idle == CPU_NEWLY_IDLE) {
> > + if (env->idle != CPU_NOT_IDLE) {
> >
> > /*
> >* ASYM_PACKING needs to force migrate tasks from busy but
> >
>
> That change looks fine. However, you're mentioning newidle load_balance()
> not being triggered - you'd want to set root_domain->overload for any
> newidle pull to happen, probably with something like this:
It's not needed in this case because the dst cpu is already the target
cpu and the migration will happen during this idle load balance.
Setting root_domain->overload is useful only if you want another cpu
to pull the task during another coming load_balance (newly or normal
idle ones) which is not the case here.
>
> -8<-
> @@ -8398,6 +8408,9 @@ static inline void update_sd_lb_stats(struct lb_env
> *env, struct sd_lb_stats *sd
> sg = sg->next;
> } while (sg != env->sd->groups);
>
> + if (check_asym_packing(env, sds))
> + sg_status |= SG_OVERLOAD;
> +
> #ifdef CONFIG_NO_HZ_COMMON
> if ((env->flags & LBF_NOHZ_AGAIN) &&
> cpumask_subset(nohz.idle_cpus_mask, sched_domain_span(env->sd))) {
> ->8-
>
> It's similar to what is done for misfit, although that's yet another
> 'twisted' use of that flag which we might want to rename (I suggested
> something like 'need_idle_balance' a while back but it wasn't really
> popular).
Re: [PATCH v2 03/12] PCI: aardvark: Add PHY support
Hi Marek, Marek Behun wrote on Mon, 17 Dec 2018 22:34:30 +0100: > Miquel, > > I tried the patches and they are working, with the exception of Compex > WLE900X card, but we know that this card is problematic. How did you test them? I am surprised that COMPHY calls worked for you out of the box. I am not sure you have A3700 COMPHY support in your ATF but it probably work because U-Boot is doing the initial configuration. > I am interesting if there is a known way to turn of the comphy on > A3720, or at least change the SGMII mode from 1Gbps to 2.5Gbps and > back. Marvell documentation does not provide this information and the > code in ATF providing the SMC calls does not do this either. > Do you know how this can be achieved? The driver already handles these calls (see [1]), making use of them is just a matter of hacking into drivers (in your case, I suppose it is mvneta) and add phy_set_mode()/phy_power_on() calls. [1] https://github.com/miquelraynal/linux/blob/marvell/phy-next/pm/drivers/phy/marvell/phy-mvebu-a3700-comphy.c#L189 Thanks, Miquèl
[PATCH 1/2] fsl_hypervisor: dereferencing error pointers in ioctl
The strndup_user() function returns error pointers on error, and then
in the error handling we pass the error pointers to kfree(). It will
cause an Oops.
Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management
driver")
Signed-off-by: Dan Carpenter
---
drivers/virt/fsl_hypervisor.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
index 8ba726e600e9..7b7f8e9a2801 100644
--- a/drivers/virt/fsl_hypervisor.c
+++ b/drivers/virt/fsl_hypervisor.c
@@ -331,8 +331,8 @@ static long ioctl_dtprop(struct fsl_hv_ioctl_prop __user
*p, int set)
struct fsl_hv_ioctl_prop param;
char __user *upath, *upropname;
void __user *upropval;
- char *path = NULL, *propname = NULL;
- void *propval = NULL;
+ char *path, *propname;
+ void *propval;
int ret = 0;
/* Get the parameters from the user. */
@@ -344,32 +344,30 @@ static long ioctl_dtprop(struct fsl_hv_ioctl_prop __user
*p, int set)
upropval = (void __user *)(uintptr_t)param.propval;
path = strndup_user(upath, FH_DTPROP_MAX_PATHLEN);
- if (IS_ERR(path)) {
- ret = PTR_ERR(path);
- goto out;
- }
+ if (IS_ERR(path))
+ return PTR_ERR(path);
propname = strndup_user(upropname, FH_DTPROP_MAX_PATHLEN);
if (IS_ERR(propname)) {
ret = PTR_ERR(propname);
- goto out;
+ goto err_free_path;
}
if (param.proplen > FH_DTPROP_MAX_PROPLEN) {
ret = -EINVAL;
- goto out;
+ goto err_free_propname;
}
propval = kmalloc(param.proplen, GFP_KERNEL);
if (!propval) {
ret = -ENOMEM;
- goto out;
+ goto err_free_propname;
}
if (set) {
if (copy_from_user(propval, upropval, param.proplen)) {
ret = -EFAULT;
- goto out;
+ goto err_free_propval;
}
param.ret = fh_partition_set_dtprop(param.handle,
@@ -388,7 +386,7 @@ static long ioctl_dtprop(struct fsl_hv_ioctl_prop __user
*p, int set)
if (copy_to_user(upropval, propval, param.proplen) ||
put_user(param.proplen, &p->proplen)) {
ret = -EFAULT;
- goto out;
+ goto err_free_propval;
}
}
}
@@ -396,10 +394,12 @@ static long ioctl_dtprop(struct fsl_hv_ioctl_prop __user
*p, int set)
if (put_user(param.ret, &p->ret))
ret = -EFAULT;
-out:
- kfree(path);
+err_free_propval:
kfree(propval);
+err_free_propname:
kfree(propname);
+err_free_path:
+ kfree(path);
return ret;
}
--
2.17.1
Re: [PATCH v6 3/6] acpi/numa: Set the memory-side-cache size in memblocks
Hi Keith, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.20-rc7 next-20181217] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dan-Williams/mm-Randomize-free-memory/20181218-130230 reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) mm/memblock.c:840: warning: Excess function parameter 'direct' description in 'memblock_set_sidecache' >> mm/memblock.c:840: warning: Function parameter or member 'direct_mapped' not >> described in 'memblock_set_sidecache' mm/memblock.c:840: warning: Excess function parameter 'direct' description in 'memblock_set_sidecache' include/linux/rcutree.h:1: warning: no structured comments found kernel/rcu/tree.c:684: warning: Excess function parameter 'irq' description in 'rcu_nmi_exit' include/linux/srcu.h:175: warning: Function parameter or member 'p' not described in 'srcu_dereference_notrace' include/linux/srcu.h:175: warning: Function parameter or member 'sp' not described in 'srcu_dereference_notrace' include/linux/gfp.h:1: warning: no structured comments found include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.ibss' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.connect' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.keys' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.ie' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.ie_len' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.ssid' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.default_key' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.default_mgmt_key' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.prev_bssid_valid' not described in 'wireless_dev' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand functi
[PATCH 2/2] fsl_hypervisor: prevent integer overflow in ioctl
The "param.count" value is a u64 thatcomes from the user. The code
later in the function assumes that param.count is at least one and if
it's not then it leads to an Oops when we dereference the ZERO_SIZE_PTR.
Also the addition can have an integer overflow which would lead us to
allocate a smaller "pages" array than required. I can't immediately
tell what the possible run times implications are, but it's safest to
prevent the overflow.
Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management
driver")
Signed-off-by: Dan Carpenter
---
drivers/virt/fsl_hypervisor.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
index 7b7f8e9a2801..1bbd910d4ddb 100644
--- a/drivers/virt/fsl_hypervisor.c
+++ b/drivers/virt/fsl_hypervisor.c
@@ -215,6 +215,9 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user
*p)
* hypervisor.
*/
lb_offset = param.local_vaddr & (PAGE_SIZE - 1);
+ if (param.count == 0 ||
+ param.count > U64_MAX - lb_offset - PAGE_SIZE + 1)
+ return -EINVAL;
num_pages = (param.count + lb_offset + PAGE_SIZE - 1) >> PAGE_SHIFT;
/* Allocate the buffers we need */
--
2.17.1
[PATCH -next] x86/xen: Fix read buffer overflow
Fix smatch warning:
arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
buffer overflow 'early_idt_handler_array' 32 <= 32
Fixes: 42b3a4cb5609 ("x86/xen: Support early interrupts in xen pv guests")
Signed-off-by: YueHaibing
---
arch/x86/xen/enlighten_pv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 2f6787f..81f200d 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -646,7 +646,7 @@ static bool __ref get_trap_addr(void **addr, unsigned int
ist)
if (nr == ARRAY_SIZE(trap_array) &&
*addr >= (void *)early_idt_handler_array[0] &&
- *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS]) {
+ *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS - 1])
{
nr = (*addr - (void *)early_idt_handler_array[0]) /
EARLY_IDT_HANDLER_SIZE;
*addr = (void *)xen_early_idt_handler_array[nr];
--
2.7.0
Re: [PATCH] RISC-V: Make BSS section as the last section in vmlinux.lds.S
On Mon, Dec 17, 2018 at 6:29 PM Nick Kossifidis wrote: > > Στις 2018-12-17 11:36, Anup Patel έγραψε: > > On Mon, Nov 26, 2018 at 11:42 AM Anup Patel > > wrote: > >> > >> The objcopy only emits loadable sections when creating flat kernel > >> Image. To have minimal possible size of flat kernel Image, we should > >> have all non-loadable sections after loadable sections. > >> > >> Currently, execption table section (loadable section) is after BSS > >> section (non-loadable section) in the RISC-V vmlinux.lds.S. This > >> is not optimal for having minimal flat kernel Image size hence this > >> patch makes BSS section as the last section in RISC-V vmlinux.lds.S. > >> > >> In addition, we make BSS section aligned to 16byte instead of PAGE > >> aligned which further reduces flat kernel Image size by few KBs. > >> > >> The flat kernel Image size of Linux-4.20-rc4 using GCC 8.2.0 is > >> 8819980 bytes with current RISC-V vmlinux.lds.S and it reduces to > >> 7991740 bytes with this patch applied using GCC 8.2.0. In summary, > >> this patch reduces Linux-4.20-rc4 flat kernel Image size by 809 KB. > >> > >> Signed-off-by: Anup Patel > >> --- > >> arch/riscv/kernel/vmlinux.lds.S | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/riscv/kernel/vmlinux.lds.S > >> b/arch/riscv/kernel/vmlinux.lds.S > >> index 65df1dfdc303..cc99eed44931 100644 > >> --- a/arch/riscv/kernel/vmlinux.lds.S > >> +++ b/arch/riscv/kernel/vmlinux.lds.S > >> @@ -74,8 +74,6 @@ SECTIONS > >> *(.sbss*) > >> } > >> > >> - BSS_SECTION(PAGE_SIZE, PAGE_SIZE, 0) > >> - > >> EXCEPTION_TABLE(0x10) > >> NOTES > >> > >> @@ -83,6 +81,8 @@ SECTIONS > >> *(.rel.dyn*) > >> } > >> > >> + BSS_SECTION(0x10, 0x10, 0x10) > >> + > >> _end = .; > >> > >> STABS_DEBUG > >> -- > >> 2.17.1 > >> > > > > Hi All, > > > > Any comment on this patch? > > > > Regards, > > Anup > > > > Just a note on coding style, you should be using a macro instead of 0x10 > so that those who read the code can understand what it is and also a few > comments since searching through the commit logs to understand why you > used it isn't optimal. RISC-V can support 32bit, 64bit and 128bit machine-word sizes. The 0x10 number is the machine-word size in bytes for 128bit RISC-V CPU (i.e. maximum machine-word size). I will add a macro MAX_BYTES_PER_LONG in vmlinux.lds.S and use it in-place of 0x10 Regards, Anup
Re: [PATCH v2 03/12] PCI: aardvark: Add PHY support
Hello, Miquel Raynal wrote on Tue, 18 Dec 2018 09:18:17 +0100: > Hi Marek, > > Marek Behun wrote on Mon, 17 Dec 2018 22:34:30 > +0100: > > > Miquel, > > > > I tried the patches and they are working, with the exception of Compex > > WLE900X card, but we know that this card is problematic. > > How did you test them? I am surprised that COMPHY calls worked for you > out of the box. I am not sure you have A3700 COMPHY support in your ATF > but it probably work because U-Boot is doing the initial configuration. Let me correct myself: actually the feature is already mainline! See [2]. It will be added to Marvell's BSP by the end of the year. So if you are running a recent mainline ATF you are good to go! > > > I am interesting if there is a known way to turn of the comphy on > > A3720, or at least change the SGMII mode from 1Gbps to 2.5Gbps and > > back. Marvell documentation does not provide this information and the > > code in ATF providing the SMC calls does not do this either. > > Do you know how this can be achieved? > > The driver already handles these calls (see [1]), making use of > them is just a matter of hacking into drivers (in your case, I > suppose it is mvneta) and add phy_set_mode()/phy_power_on() calls. > > [1] > https://github.com/miquelraynal/linux/blob/marvell/phy-next/pm/drivers/phy/marvell/phy-mvebu-a3700-comphy.c#L189 > > > Thanks, > Miquèl [2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/marvell/comphy/phy-comphy-3700.c Thanks, Miquèl
[RESEND PATCH V3 4/5] arm64/mm: Enable HugeTLB migration
Let arm64 subscribe to generic HugeTLB page migration framework. Right now this only works on the following PMD and PUD level HugeTLB page sizes with various kernel base page size combinations. CONT PTEPMDCONT PMDPUD ------ 4K: NA 2M NA 1G 16K:NA32M NA 64K:NA 512M NA Reviewed-by: Naoya Horiguchi Reviewed-by: Steve Capper Acked-by: Catalin Marinas Signed-off-by: Anshuman Khandual --- arch/arm64/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index ea2ab03..57d0c4bf 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1359,6 +1359,10 @@ config SYSVIPC_COMPAT def_bool y depends on COMPAT && SYSVIPC +config ARCH_ENABLE_HUGEPAGE_MIGRATION + def_bool y + depends on HUGETLB_PAGE && MIGRATION + menu "Power management options" source "kernel/power/Kconfig" -- 2.7.4
[RESEND PATCH V3 2/5] mm/hugetlb: Enable PUD level huge page migration
Architectures like arm64 have PUD level HugeTLB pages for certain configs
(1GB huge page is PUD based on ARM64_4K_PAGES base page size) that can be
enabled for migration. It can be achieved through checking for PUD_SHIFT
order based HugeTLB pages during migration.
Reviewed-by: Naoya Horiguchi
Reviewed-by: Steve Capper
Acked-by: Michal Hocko
Signed-off-by: Anshuman Khandual
---
include/linux/hugetlb.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 1b858d7..70bcd89 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -497,7 +497,8 @@ static inline bool hugepage_migration_supported(struct
hstate *h)
{
#ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
if ((huge_page_shift(h) == PMD_SHIFT) ||
- (huge_page_shift(h) == PGDIR_SHIFT))
+ (huge_page_shift(h) == PUD_SHIFT) ||
+ (huge_page_shift(h) == PGDIR_SHIFT))
return true;
else
return false;
--
2.7.4
[RESEND PATCH V3 0/5] arm64/mm: Enable HugeTLB migration
This patch series enables HugeTLB migration support for all supported huge page sizes at all levels including contiguous bit implementation. Following HugeTLB migration support matrix has been enabled with this patch series. All permutations have been tested except for the 16GB. CONT PTEPMDCONT PMDPUD ------ 4K: 64K 2M 32M 1G 16K: 2M32M 1G 64K: 2M 512M 16G First the series adds migration support for PUD based huge pages. It then adds a platform specific hook to query an architecture if a given huge page size is supported for migration while also providing a default fallback option preserving the existing semantics which just checks for (PMD|PUD|PGDIR)_SHIFT macros. The last two patches enables HugeTLB migration on arm64 and subscribe to this new platform specific hook by defining an override. The second patch differentiates between movability and migratability aspects of huge pages and implements hugepage_movable_supported() which can then be used during allocation to decide whether to place the huge page in movable zone or not. This is just a resend for the previous version (V3) after the rebase on current mainline kernel. Also added all the tags previous version had received. Changes in V3: - Re-ordered patches 1 and 2 per Michal - s/Movability/Migratability/ in unmap_and_move_huge_page() per Naoya Changes in V2: (https://lkml.org/lkml/2018/10/12/190) - Added a new patch which differentiates migratability and movability of huge pages and implements hugepage_movable_supported() function as suggested by Michal Hocko. Anshuman Khandual (5): mm/hugetlb: Distinguish between migratability and movability mm/hugetlb: Enable PUD level huge page migration mm/hugetlb: Enable arch specific huge page size support for migration arm64/mm: Enable HugeTLB migration arm64/mm: Enable HugeTLB migration for contiguous bit HugeTLB pages arch/arm64/Kconfig | 4 arch/arm64/include/asm/hugetlb.h | 5 + arch/arm64/mm/hugetlbpage.c | 20 + include/linux/hugetlb.h | 48 +--- mm/hugetlb.c | 2 +- mm/migrate.c | 2 +- 6 files changed, 76 insertions(+), 5 deletions(-) -- 2.7.4
[RESEND PATCH V3 1/5] mm/hugetlb: Distinguish between migratability and movability
During huge page allocation it's migratability is checked to determine if
it should be placed under movable zones with GFP_HIGHUSER_MOVABLE. But the
movability aspect of the huge page could depend on other factors than just
migratability. Movability in itself is a distinct property which should not
be tied with migratability alone.
This differentiates these two and implements an enhanced movability check
which also considers huge page size to determine if it is feasible to be
placed under a movable zone. At present it just checks for gigantic pages
but going forward it can incorporate other enhanced checks.
Reviewed-by: Steve Capper
Reviewed-by: Naoya Horiguchi
Suggested-by: Michal Hocko
Acked-by: Michal Hocko
Signed-off-by: Anshuman Khandual
---
include/linux/hugetlb.h | 30 ++
mm/hugetlb.c| 2 +-
mm/migrate.c| 2 +-
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 087fd5f4..1b858d7 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -506,6 +506,31 @@ static inline bool hugepage_migration_supported(struct
hstate *h)
#endif
}
+/*
+ * Movability check is different as compared to migration check.
+ * It determines whether or not a huge page should be placed on
+ * movable zone or not. Movability of any huge page should be
+ * required only if huge page size is supported for migration.
+ * There wont be any reason for the huge page to be movable if
+ * it is not migratable to start with. Also the size of the huge
+ * page should be large enough to be placed under a movable zone
+ * and still feasible enough to be migratable. Just the presence
+ * in movable zone does not make the migration feasible.
+ *
+ * So even though large huge page sizes like the gigantic ones
+ * are migratable they should not be movable because its not
+ * feasible to migrate them from movable zone.
+ */
+static inline bool hugepage_movable_supported(struct hstate *h)
+{
+ if (!hugepage_migration_supported(h))
+ return false;
+
+ if (hstate_is_gigantic(h))
+ return false;
+ return true;
+}
+
static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
struct mm_struct *mm, pte_t *pte)
{
@@ -602,6 +627,11 @@ static inline bool hugepage_migration_supported(struct
hstate *h)
return false;
}
+static inline bool hugepage_movable_supported(struct hstate *h)
+{
+ return false;
+}
+
static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
struct mm_struct *mm, pte_t *pte)
{
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 705a3e9c..795f745 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -919,7 +919,7 @@ static struct page *dequeue_huge_page_nodemask(struct
hstate *h, gfp_t gfp_mask,
/* Movability of hugepages depends on migration support. */
static inline gfp_t htlb_alloc_mask(struct hstate *h)
{
- if (hugepage_migration_supported(h))
+ if (hugepage_movable_supported(h))
return GFP_HIGHUSER_MOVABLE;
else
return GFP_HIGHUSER;
diff --git a/mm/migrate.c b/mm/migrate.c
index f7e4bfd..3020a06 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1262,7 +1262,7 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
struct anon_vma *anon_vma = NULL;
/*
-* Movability of hugepages depends on architectures and hugepage size.
+* Migratability of hugepages depends on architectures and their size.
* This check is necessary because some callers of hugepage migration
* like soft offline and memory hotremove don't walk through page
* tables or check whether the hugepage is pmd-based or not before
--
2.7.4
[RESEND PATCH V3 3/5] mm/hugetlb: Enable arch specific huge page size support for migration
Architectures like arm64 have HugeTLB page sizes which are different than
generic sizes at PMD, PUD, PGD level and implemented via contiguous bits.
At present these special size HugeTLB pages cannot be identified through
macros like (PMD|PUD|PGDIR)_SHIFT and hence chosen not be migrated.
Enabling migration support for these special HugeTLB page sizes along with
the generic ones (PMD|PUD|PGD) would require identifying all of them on a
given platform. A platform specific hook can precisely enumerate all huge
page sizes supported for migration. Instead of comparing against standard
huge page orders let hugetlb_migration_support() function call a platform
hook arch_hugetlb_migration_support(). Default definition for the platform
hook maintains existing semantics which checks standard huge page order.
But an architecture can choose to override the default and provide support
for a comprehensive set of huge page sizes.
Reviewed-by: Naoya Horiguchi
Reviewed-by: Steve Capper
Acked-by: Michal Hocko
Signed-off-by: Anshuman Khandual
---
include/linux/hugetlb.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 70bcd89..4cc3871 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -493,18 +493,29 @@ static inline pgoff_t basepage_index(struct page *page)
extern int dissolve_free_huge_page(struct page *page);
extern int dissolve_free_huge_pages(unsigned long start_pfn,
unsigned long end_pfn);
-static inline bool hugepage_migration_supported(struct hstate *h)
-{
+
#ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
+#ifndef arch_hugetlb_migration_supported
+static inline bool arch_hugetlb_migration_supported(struct hstate *h)
+{
if ((huge_page_shift(h) == PMD_SHIFT) ||
(huge_page_shift(h) == PUD_SHIFT) ||
(huge_page_shift(h) == PGDIR_SHIFT))
return true;
else
return false;
+}
+#endif
#else
+static inline bool arch_hugetlb_migration_supported(struct hstate *h)
+{
return false;
+}
#endif
+
+static inline bool hugepage_migration_supported(struct hstate *h)
+{
+ return arch_hugetlb_migration_supported(h);
}
/*
--
2.7.4
[RESEND PATCH V3 5/5] arm64/mm: Enable HugeTLB migration for contiguous bit HugeTLB pages
Let arm64 subscribe to the previously added framework in which architecture
can inform whether a given huge page size is supported for migration. This
just overrides the default function arch_hugetlb_migration_supported() and
enables migration for all possible HugeTLB page sizes on arm64. With this,
HugeTLB migration support on arm64 now covers all possible HugeTLB options.
CONT PTEPMDCONT PMDPUD
------
4K:64K 2M32M 1G
16K:2M 32M 1G
64K:2M512M16G
Reviewed-by: Naoya Horiguchi
Reviewed-by: Steve Capper
Acked-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
arch/arm64/include/asm/hugetlb.h | 5 +
arch/arm64/mm/hugetlbpage.c | 20
2 files changed, 25 insertions(+)
diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h
index fb66098..c6a07a3 100644
--- a/arch/arm64/include/asm/hugetlb.h
+++ b/arch/arm64/include/asm/hugetlb.h
@@ -20,6 +20,11 @@
#include
+#ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
+#define arch_hugetlb_migration_supported arch_hugetlb_migration_supported
+extern bool arch_hugetlb_migration_supported(struct hstate *h);
+#endif
+
#define __HAVE_ARCH_HUGE_PTEP_GET
static inline pte_t huge_ptep_get(pte_t *ptep)
{
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index f58ea50..e445500 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -27,6 +27,26 @@
#include
#include
+#ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
+bool arch_hugetlb_migration_supported(struct hstate *h)
+{
+ size_t pagesize = huge_page_size(h);
+
+ switch (pagesize) {
+#ifdef CONFIG_ARM64_4K_PAGES
+ case PUD_SIZE:
+#endif
+ case PMD_SIZE:
+ case CONT_PMD_SIZE:
+ case CONT_PTE_SIZE:
+ return true;
+ }
+ pr_warn("%s: unrecognized huge page size 0x%lx\n",
+ __func__, pagesize);
+ return false;
+}
+#endif
+
int pmd_huge(pmd_t pmd)
{
return pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT);
--
2.7.4
Re: [PATCH v3 2/6] irqchip: sifive-plic: Add struct plic_hw for global PLIC HW details
On Mon, Dec 17, 2018 at 11:54 PM Christoph Hellwig wrote:
>
> > +struct plic_hw {
> > + u32 nr_irqs;
> > + u32 nr_handlers;
> > + u32 nr_mapped;
> > + void __iomem*regs;
> > + struct irq_domain *irqdomain;
> > +};
> > +
> > +static struct plic_hw plic;
>
> Please use local variables instead of a single instance struct.
> And only add these variables in the patches where you actually need
> them.
I am sure it will be useful in-future but for now I will
remove the struct instance.
Regards,
Anup
Re: [PATCH v2 18/19] mailbox: stm32-ipcc: Use device-managed registration API
On 12/17/18 4:02 PM, Thierry Reding wrote:
From: Thierry Reding
Get rid of some boilerplate driver removal code by using the newly added
device-managed registration API.
Cc: Fabien Dessenne
Cc: Ludovic Barre
Reviewed-by: Ludovic Barre
Regards,
Ludo
Signed-off-by: Thierry Reding
---
drivers/mailbox/stm32-ipcc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mailbox/stm32-ipcc.c b/drivers/mailbox/stm32-ipcc.c
index 533b0da5235d..a338bd4cd7db 100644
--- a/drivers/mailbox/stm32-ipcc.c
+++ b/drivers/mailbox/stm32-ipcc.c
@@ -299,7 +299,7 @@ static int stm32_ipcc_probe(struct platform_device *pdev)
for (i = 0; i < ipcc->controller.num_chans; i++)
ipcc->controller.chans[i].con_priv = (void *)i;
- ret = mbox_controller_register(&ipcc->controller);
+ ret = devm_mbox_controller_register(dev, &ipcc->controller);
if (ret)
goto err_irq_wkp;
@@ -329,8 +329,6 @@ static int stm32_ipcc_remove(struct platform_device *pdev)
{
struct stm32_ipcc *ipcc = platform_get_drvdata(pdev);
- mbox_controller_unregister(&ipcc->controller);
-
if (ipcc->wkp)
dev_pm_clear_wake_irq(&pdev->dev);
Re: [PATCH v2 10/19] mailbox: sti: Use device-managed registration API
On Mon, 17 Dec 2018, Thierry Reding wrote: > From: Thierry Reding > > Get rid of some boilerplate driver removal code by using the newly added > device-managed registration API. > > Cc: Lee Jones > Signed-off-by: Thierry Reding > --- > drivers/mailbox/mailbox-sti.c | 13 + > 1 file changed, 1 insertion(+), 12 deletions(-) Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3 1/6] irqchip: sifive-plic: Pre-compute context hart base and enable base
On Mon, Dec 17, 2018 at 11:55 PM Christoph Hellwig wrote: > > On Fri, Nov 30, 2018 at 01:32:02PM +0530, Anup Patel wrote: > > This patch does following optimizations: > > 1. Pre-compute hart base for each context handler > > 2. Pre-compute enable base for each context handler > > 3. Have enable lock for each context handler instead > > of global plic_toggle_lock > > All of which is pretty obvious from reading the patch. The big question > that needs to be answered in the changelog is why you do that. To compute enable_base and hart_base is two integer additions and one integer multiplication. This micro-optimization simply avoids this repeated operations. Regards, Anup
Re: [PATCH -next] x86/xen: Fix read buffer overflow
On 18/12/2018 09:19, YueHaibing wrote:
> Fix smatch warning:
>
> arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
> buffer overflow 'early_idt_handler_array' 32 <= 32
>
> Fixes: 42b3a4cb5609 ("x86/xen: Support early interrupts in xen pv guests")
> Signed-off-by: YueHaibing
> ---
> arch/x86/xen/enlighten_pv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 2f6787f..81f200d 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -646,7 +646,7 @@ static bool __ref get_trap_addr(void **addr, unsigned int
> ist)
>
> if (nr == ARRAY_SIZE(trap_array) &&
> *addr >= (void *)early_idt_handler_array[0] &&
> - *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS]) {
> + *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS - 1])
> {
> nr = (*addr - (void *)early_idt_handler_array[0]) /
>EARLY_IDT_HANDLER_SIZE;
> *addr = (void *)xen_early_idt_handler_array[nr];
>
No, this patch is wrong.
early_idt_handler_array is a 2-dimensional array:
const char
early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_SIZE];
So above code doesn't do an out of bounds array access, but checks for
*addr being in the array or outside of it (note the "<" used for the
test).
Juergen
Re: [RESEND PATCH v5 1/3] x86/fpu: track AVX-512 usage of tasks
Aubrey, On Tue, 18 Dec 2018, Aubrey Li wrote: RESEND Please don't do that. This is not a resend because you changed something, so it's new version. Usually I ignore resends when I have the original submission already lined up for review. Thanks, tglx
[RESEND PATCH v2 0/8] Input: sx8654 - reset-gpio, sx865[056] support, etc.
Add reset-gpio, sx8654[056] and common of_touchscreen functions support for the sx8654 driver. Changes RESEND v2: - added "Reviewed-by: Rob Herring " tags Changes v2: - use devm_gpiod_get_optional in probe instead of in #ifdef CONFIG_OF - convert flags to BIT() in a separate patch - replace hrtimer with "regular" timer - use of_device_get_match_data instead of of_match_device - add driver data to i2c_device_id table for non-DT fallback - fix sequence of common touchscreen initialization - div. minor stlye changes Richard Leitner (8): dt-bindings: input: touchscreen: sx8654: add reset-gpio property Input: sx8654 - add reset-gpio support dt-bindings: input: touchscreen: sx8654: add compatible models Input: sx8654 - add sx8655 and sx8656 to compatibles dt-bindings: input: touchscreen: sx8654: add sx8650 to comatibles Input: sx8654 - add sx8650 support Input: sx8654 - use common of_touchscreen functions Input: sx8654 - convert #defined flags to BIT(x) .../bindings/input/touchscreen/sx8654.txt | 10 +- drivers/input/touchscreen/sx8654.c | 245 ++--- 2 files changed, 229 insertions(+), 26 deletions(-) -- 2.11.0
[RESEND PATCH v2 2/8] Input: sx8654 - add reset-gpio support
The sx8654 features a NRST input which may be connected to a GPIO.
Therefore add support for hard-resetting the sx8654 via this NRST.
If the reset-gpio property is provided the sx8654 is resetted via NRST
instead of the soft-reset via I2C.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 40 +++---
1 file changed, 37 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/sx8654.c
b/drivers/input/touchscreen/sx8654.c
index ed29db3ec731..238f56b1581b 100644
--- a/drivers/input/touchscreen/sx8654.c
+++ b/drivers/input/touchscreen/sx8654.c
@@ -33,6 +33,8 @@
#include
#include
#include
+#include
+#include
/* register addresses */
#define I2C_REG_TOUCH0 0x00
@@ -74,6 +76,7 @@
struct sx8654 {
struct input_dev *input;
struct i2c_client *client;
+ struct gpio_desc *gpio_reset;
};
static irqreturn_t sx8654_irq(int irq, void *handle)
@@ -124,6 +127,27 @@ static irqreturn_t sx8654_irq(int irq, void *handle)
return IRQ_HANDLED;
}
+static int sx8654_reset(struct sx8654 *ts)
+{
+ int err;
+
+ if (ts->gpio_reset) {
+ gpiod_set_value_cansleep(ts->gpio_reset, 1);
+ udelay(2); /* Tpulse > 1µs */
+ gpiod_set_value_cansleep(ts->gpio_reset, 0);
+
+ return 0;
+ }
+
+ dev_dbg(&ts->client->dev, "NRST unavailable, try softreset\n");
+ err = i2c_smbus_write_byte_data(ts->client, I2C_REG_SOFTRESET,
+ SOFTRESET_VALUE);
+ if (err)
+ return err;
+ else
+ return 0;
+}
+
static int sx8654_open(struct input_dev *dev)
{
struct sx8654 *sx8654 = input_get_drvdata(dev);
@@ -186,6 +210,17 @@ static int sx8654_probe(struct i2c_client *client,
if (!sx8654)
return -ENOMEM;
+ sx8654->gpio_reset = devm_gpiod_get_optional(&client->dev, "reset",
+GPIOD_OUT_HIGH);
+ if (IS_ERR(sx8654->gpio_reset)) {
+ error = PTR_ERR(sx8654->gpio_reset);
+ if (error != -EPROBE_DEFER)
+ dev_err(&client->dev, "unable to get reset-gpio: %d\n",
+ error);
+ return error;
+ }
+ dev_dbg(&client->dev, "got GPIO reset pin\n");
+
input = devm_input_allocate_device(&client->dev);
if (!input)
return -ENOMEM;
@@ -206,10 +241,9 @@ static int sx8654_probe(struct i2c_client *client,
input_set_drvdata(sx8654->input, sx8654);
- error = i2c_smbus_write_byte_data(client, I2C_REG_SOFTRESET,
- SOFTRESET_VALUE);
+ error = sx8654_reset(sx8654);
if (error) {
- dev_err(&client->dev, "writing softreset value failed");
+ dev_err(&client->dev, "reset failed");
return error;
}
--
2.11.0
[RESEND PATCH v2 1/8] dt-bindings: input: touchscreen: sx8654: add reset-gpio property
Document the reset-gpio property for the sx8654 touchscreen controller
driver.
Signed-off-by: Richard Leitner
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
index 4886c4aa2906..ca521d8f7d65 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
@@ -5,6 +5,9 @@ Required properties:
- reg: i2c slave address
- interrupts: touch controller interrupt
+Optional properties:
+ - reset-gpios: GPIO specification for the NRST input
+
Example:
sx8654@48 {
@@ -12,4 +15,5 @@ Example:
reg = <0x48>;
interrupt-parent = <&gpio6>;
interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
};
--
2.11.0
Re: [PATCH v7 11/25] arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking
HI Julien,
Thanks a lot for your reply, since I'm working on this patch in ARM
(32 bits), so I have to dig into the details.
Julien Thierry 於 2018年12月17日 週一 下午5:26寫道：
>
> Hi Jian-Lin,
>
> Thanks for looking at this.
>
> On 16/12/2018 14:47, Jian-Lin Chen wrote:
> > From: Jian-Lin Chen
> >
> >
> > On Wed, 12 Dec 2018 at 17:48, Julien Thierry wrote:
> >> static inline void arch_local_irq_enable(void)
> >> {
> >> - asm volatile(
> >> - "msrdaifclr, #2 // arch_local_irq_enable"
> >> - :
> >> + unsigned long unmasked = GIC_PRIO_IRQON;
> >> +
> >
> > Should we need a WARN_ON() to check if the daif_I bit is masked, or
> > explicitly unmasked I bit here?
> >
>
> While I would agree, adding the WARN_ON() will add some non-negligible
> overhead, especially if we need to read the daif flags to check it.
>
> Since these functions are called often in the whole system and using PMR
> already makes things a bit slower, I'd prefer to avoid checks in here.
Ok, so we have to find a better place to check it.
I have no idea so far...
>
> > If I bit was masked and someone calls arch_local_irq_enable(), they still
> > couldn't recieve any interrupt.
> >
> >
> >> + asm volatile(ALTERNATIVE(
> >> + "msrdaifclr, #2 // arch_local_irq_enable\n"
> >> + "nop",
> >> + "msr_s " __stringify(SYS_ICC_PMR_EL1) ",%0\n"
> >> + "dsbsy",
> >> + ARM64_HAS_IRQ_PRIO_MASKING)
> >> :
> >> + : "r" (unmasked)
> >> : "memory");
> >> }
> >>
> >> static inline void arch_local_irq_disable(void)
> >> {
> >> - asm volatile(
> >> - "msrdaifset, #2 // arch_local_irq_disable"
> >> - :
> >> + unsigned long masked = GIC_PRIO_IRQOFF;
> >> +
> >> + asm volatile(ALTERNATIVE(
> >> + "msrdaifset, #2 // arch_local_irq_disable",
> >> + "msr_s " __stringify(SYS_ICC_PMR_EL1) ", %0",
> >
> > May be a "dsb sy" here?
>
> So, we need a "dsb sy" when unmasking interrupts because this ensures
> the redistributor sees the latest PMR value and starts forwarding lower
> priority interrupts again.
>
> When we disable interrupts however, the GIC CPU interface guarantees
> that no interrupts of lower priority than the current value of PMR will
> be taken. So we don't really need the redistributor to immediately see
> the new value of PMR as the logic in the GIC CPU interface is good
> enough for our goal.
>
Got it, thanks for the detail!
> Thanks,
>
> --
> Julien Thierry
Re: [PATCH v3 4/6] irqchip: sifive-plic: Add warning in plic_init() if handler already present
On Mon, Dec 17, 2018 at 11:58 PM Christoph Hellwig wrote:
>
> On Fri, Nov 30, 2018 at 01:32:05PM +0530, Anup Patel wrote:
> > We have two enteries (one for M-mode and another for S-mode) in the
> > interrupts-extended DT property of PLIC DT node for each HART. It is
> > expected that firmware/bootloader will set M-mode HWIRQ line of each
> > HART to 0x (i.e. -1) in interrupts-extended DT property
> > because Linux runs in S-mode only.
> >
> > If firmware/bootloader is buggy then it will not correctly update
> > interrupts-extended DT property which might result in a plic_handler
> > configured twice. This patch adds a warning in plic_init() if a
> > plic_handler is already marked present. This warning provides us
> > a hint about incorrectly updated interrupts-extended DT property.
> >
> > Signed-off-by: Anup Patel
> > ---
> > drivers/irqchip/irq-sifive-plic.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/irqchip/irq-sifive-plic.c
> > b/drivers/irqchip/irq-sifive-plic.c
> > index d4433399eb89..3d4f205f8abe 100644
> > --- a/drivers/irqchip/irq-sifive-plic.c
> > +++ b/drivers/irqchip/irq-sifive-plic.c
> > @@ -234,6 +234,11 @@ static int __init plic_init(struct device_node *node,
> >
> > cpu = riscv_hartid_to_cpuid(hartid);
> > handler = per_cpu_ptr(&plic_handlers, cpu);
> > + if (handler->present) {
> > + pr_warn("handler not available for context %d.\n", i);
> > + continue;
> > + }
>
> Shouldn't this be something like "handler already present.."
OK, I will re-phrase it.
>
> Otherwise this looks fine:
>
> Reviewed-by: Christoph Hellwig
Regards,
Anup
Re: [RESEND PATCH v5 1/3] x86/fpu: track AVX-512 usage of tasks
On 2018/12/18 16:33, Thomas Gleixner wrote: > Aubrey, > > On Tue, 18 Dec 2018, Aubrey Li wrote: > > RESEND > > Please don't do that. This is not a resend because you changed something, > so it's new version. Usually I ignore resends when I have the original > submission already lined up for review. oh, okay, I'll send another version, sorry for the trouble... Thanks, -Aubrey
Re: [PATCH 05/13] clk: qcom: apcs-msm8916: get parent clock names from DT
On 12/18/18 00:37, Stephen Boyd wrote: Quoting Jorge Ramirez-Ortiz (2018-12-17 01:46:22) Allow accessing the parent clock names required for the driver operation by using the device tree node. This permits extending the driver to other platforms without having to modify its source code. For backwards compatibility leave previous values as default. Why do we need to maintain backwards compatibility? Isn't is required that the nodes have clocks properties? this driver -apcs clock controller- uses platform data (not DT) and therefore it uses the DT from the parent node (mailbox). And for the mailbox the clock property is optional. So the APCS clock controller requires that the parent provides at least one clock but the clock is not mandatory in the parent DT node. For instance in the case of the msm8916, the parent only provides one clock, just the pll. am I required to modify that platform instead of maintaining backwards compatibility?
[RESEND PATCH v2 3/8] dt-bindings: input: touchscreen: sx8654: add compatible models
As the sx865[456] share the same datasheet and differ only in the presence of a "capacitive proximity detection circuit" and a "haptics motor driver for LRA/ERM" add them to the compatbiles. As the driver doesn't implement these features it should be no problem. Signed-off-by: Richard Leitner Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt index ca521d8f7d65..a538678424dd 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt @@ -1,7 +1,10 @@ * Semtech SX8654 I2C Touchscreen Controller Required properties: -- compatible: must be "semtech,sx8654" +- compatible: must be one of the following, depending on the model: + "semtech,sx8654" + "semtech,sx8655" + "semtech,sx8656" - reg: i2c slave address - interrupts: touch controller interrupt -- 2.11.0
[RESEND PATCH v2 4/8] Input: sx8654 - add sx8655 and sx8656 to compatibles
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/input/touchscreen/sx8654.c
b/drivers/input/touchscreen/sx8654.c
index 238f56b1581b..afa4da138fe9 100644
--- a/drivers/input/touchscreen/sx8654.c
+++ b/drivers/input/touchscreen/sx8654.c
@@ -293,6 +293,8 @@ static int sx8654_probe(struct i2c_client *client,
#ifdef CONFIG_OF
static const struct of_device_id sx8654_of_match[] = {
{ .compatible = "semtech,sx8654", },
+ { .compatible = "semtech,sx8655", },
+ { .compatible = "semtech,sx8656", },
{ },
};
MODULE_DEVICE_TABLE(of, sx8654_of_match);
@@ -300,6 +302,8 @@ MODULE_DEVICE_TABLE(of, sx8654_of_match);
static const struct i2c_device_id sx8654_id_table[] = {
{ "semtech_sx8654", 0 },
+ { "semtech_sx8655", 0 },
+ { "semtech_sx8656", 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, sx8654_id_table);
--
2.11.0
Re: [PATCH v2] mfd: cros_ec: Add commands to control codec
+Benson, Guenter, Scott On Fri, Dec 14, 2018 at 8:22 PM Lee Jones wrote: > > On Fri, 14 Dec 2018, Lee Jones wrote: > > > On Thu, 06 Dec 2018, Cheng-Yi Chiang wrote: > > > > > Add EC host commands to control codec on EC. > > > > > > Signed-off-by: Cheng-Yi Chiang > > > --- > > > V2 fixed the wrong ancestor issue so the patch can be applied cleanly on > > > mfd tree. > > > Codec driver that uses these commands will be sent separately. > > > Thanks! > > > > > > include/linux/mfd/cros_ec_commands.h | 94 > > > 1 file changed, 94 insertions(+) > > > > Would be good to have this reviewed by some more Chrome people. > > See this for reference: > > https://lore.kernel.org/patchwork/patch/1024985/ Hi Benson and Guenter, Could you please review this patch ? The corresponding implementation at EC side by Scott is at https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1356185 Thanks a lot! > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog
Re: [f2fs-dev] [PATCH 1/3] f2fs: use kvmalloc, if kmalloc is failed
On 2018/12/14 13:01, Jaegeuk Kim wrote: > One report says memalloc failure during mount. > > (unwind_backtrace) from [] (show_stack+0x10/0x14) > (show_stack) from [] (dump_stack+0x8c/0xa0) > (dump_stack) from [] (warn_alloc+0xc4/0x160) > (warn_alloc) from [] (__alloc_pages_nodemask+0x3f4/0x10d0) > (__alloc_pages_nodemask) from [] (kmalloc_order_trace+0x2c/0x120) > (kmalloc_order_trace) from [] (build_node_manager+0x35c/0x688) > (build_node_manager) from [] (f2fs_fill_super+0xf0c/0x16cc) > (f2fs_fill_super) from [] (mount_bdev+0x15c/0x188) > (mount_bdev) from [] (f2fs_mount+0x18/0x20) > (f2fs_mount) from [] (mount_fs+0x158/0x19c) > (mount_fs) from [] (vfs_kern_mount+0x78/0x134) > (vfs_kern_mount) from [] (do_mount+0x474/0xca4) > (do_mount) from [] (SyS_mount+0x94/0xbc) > (SyS_mount) from [] (ret_fast_syscall+0x0/0x48) > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,
Re: [PATCH 0/2][resend] irqchip: irq-renesas-xxx: convert to SPDX identifiers
On 18/12/2018 06:02, Kuninori Morimoto wrote: > > Hi Thomas, Jason, Marc > > I have posted these and 2weeks passed. > Nothing happen, thus, I re-post again You may want to check linux/next. As far as I can see, the two patches are there already. Thanks, M.-- Jazz is not dead. It just smells funny...
Re: [PATCH 05/14] mm, compaction: Skip pageblocks with reserved pages
On Tue, Dec 18, 2018 at 09:08:02AM +0100, Vlastimil Babka wrote: > On 12/15/18 12:03 AM, Mel Gorman wrote: > > Reserved pages are set at boot time, tend to be clustered and almost > > never become unreserved. When isolating pages for migrating, skip > > the entire pageblock is one PageReserved page is encountered on the > > grounds that it is highly probable the entire pageblock is reserved. > > Agreed, but maybe since it's highly probable and not certain, this > skipping should not be done on the highest compaction priority? > I don't think that's necessary at this time. For the most part, you are talking about one partial pageblock at best given how the early memory allocator works so it would only ever be useful for a high-order kernel allocation. Second, one of compactions primary problems is inefficient scanning where viable pageblocks are easily skipped over or only partially scanned which is something I'm still looking at. Lastly, maximum priority compaction is rarely hit in practice as far as I can tell. -- Mel Gorman SUSE Labs
Re: [f2fs-dev] [PATCH 2/3] f2fs: correct wrong spelling, issing_*
On 2018/12/14 13:01, Jaegeuk Kim wrote: > Let's use "queued" instead of "issuing". > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,
Re: [PATCH] printk: Add caller information to printk() output.
On Tue 2018-12-18 06:05:04, Tetsuo Handa wrote: > >From 91f85d2bd494df2f73c605d8b4747e8cc0a61ae2 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Tue, 18 Dec 2018 05:53:04 +0900 > Subject: [PATCH] printk: Add caller information to printk() output. > > Sometimes we want to print a series of printk() messages to consoles > without being disturbed by concurrent printk() from interrupts and/or > other threads. But we can't enforce printk() callers to use their local > buffers because we need to ask them to make too much changes. Also, even > buffering up to one line inside printk() might cause failing to emit > an important clue under critical situation. > > Therefore, instead of trying to help buffering, let's try to help > reconstructing messages by saving caller information as of calling > log_store() and adding it as "[T$thread_id]" or "[C$processor_id]" > upon printing to consoles. > > Some examples for console output: > > [1.222773][T1] x86: Booting SMP configuration: > [2.779635][T1] pci :00:01.0: PCI bridge to [bus 01] > [5.069193][ T268] Fusion MPT base driver 3.04.20 > [9.316504][C2] random: fast init done > [ 13.413336][ T3355] Initialized host personality > > Some examples for /dev/kmsg output: > > 6,496,1222773,-,caller=T1;x86: Booting SMP configuration: > 6,968,2779635,-,caller=T1;pci :00:01.0: PCI bridge to [bus 01] >SUBSYSTEM=pci >DEVICE=+pci::00:01.0 > 6,1353,5069193,-,caller=T268;Fusion MPT base driver 3.04.20 > 5,1526,9316504,-,caller=C2;random: fast init done > 6,1575,13413336,-,caller=T3355;Initialized host personality > > Note that this patch changes max length of messages which can be printed > by printk() or written to /dev/kmsg interface from 992 bytes to 976 bytes, > based on an assumption that userspace won't try to write messages hitting > that border line to /dev/kmsg interface. > > Cc: Sergey Senozhatsky > Cc: Steven Rostedt > Cc: Dmitry Vyukov > Cc: Linus Torvalds > Cc: Andrew Morton > Signed-off-by: Tetsuo Handa > Signed-off-by: Petr Mladek Sergey, are you okay with this squashed patch, please? Best Regards, Petr
[RESEND PATCH v2 5/8] dt-bindings: input: touchscreen: sx8654: add sx8650 to comatibles
As the sx8650 is quite similar to the sx8654 support for it will be added in the driver. Therefore add it to the compatibles. Signed-off-by: Richard Leitner Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt index a538678424dd..0ebe6dd043c7 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt @@ -2,6 +2,7 @@ Required properties: - compatible: must be one of the following, depending on the model: + "semtech,sx8650" "semtech,sx8654" "semtech,sx8655" "semtech,sx8656" -- 2.11.0
[RESEND PATCH v2 8/8] Input: sx8654 - convert #defined flags to BIT(x)
Some of the #defined register values are one-bit flags. Convert them to use the BIT(x) macro instead of 1 byte hexadecimal values. This improves readability and clarifies the intent. Signed-off-by: Richard Leitner --- drivers/input/touchscreen/sx8654.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/input/touchscreen/sx8654.c b/drivers/input/touchscreen/sx8654.c index b7b263ed52af..3746ea855f94 100644 --- a/drivers/input/touchscreen/sx8654.c +++ b/drivers/input/touchscreen/sx8654.c @@ -36,6 +36,7 @@ #include #include #include +#include /* register addresses */ #define I2C_REG_TOUCH0 0x00 @@ -46,7 +47,7 @@ #define I2C_REG_SOFTRESET 0x3f #define I2C_REG_SX8650_STAT0x05 -#define SX8650_STAT_CONVIRQ0x80 +#define SX8650_STAT_CONVIRQBIT(7) /* commands */ #define CMD_READ_REGISTER 0x40 @@ -56,8 +57,8 @@ #define SOFTRESET_VALUE0xde /* bits for I2C_REG_IRQSRC */ -#define IRQ_PENTOUCH_TOUCHCONVDONE 0x08 -#define IRQ_PENRELEASE 0x04 +#define IRQ_PENTOUCH_TOUCHCONVDONE BIT(7) +#define IRQ_PENRELEASE BIT(6) /* bits for RegTouch1 */ #define CONDIRQ0x20 @@ -65,8 +66,8 @@ #define FILT_7SA 0x03 /* bits for I2C_REG_CHANMASK */ -#define CONV_X 0x80 -#define CONV_Y 0x40 +#define CONV_X BIT(7) +#define CONV_Y BIT(6) /* coordinates rate: higher nibble of CTRL0 register */ #define RATE_MANUAL0x00 -- 2.11.0
[RESEND PATCH v2 7/8] Input: sx8654 - use common of_touchscreen functions
of_touchscreen.c provides a common interface for a axis invertion and
swapping of touchscreens. Therefore use it in the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/sx8654.c
b/drivers/input/touchscreen/sx8654.c
index 4939863efbef..b7b263ed52af 100644
--- a/drivers/input/touchscreen/sx8654.c
+++ b/drivers/input/touchscreen/sx8654.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
/* register addresses */
#define I2C_REG_TOUCH0 0x00
@@ -101,6 +102,7 @@ struct sx8654 {
spinlock_t lock; /* for input reporting from irq/timer */
struct timer_list timer;
+ struct touchscreen_properties props;
const struct sx865x_data *data;
};
@@ -178,8 +180,7 @@ static irqreturn_t sx8650_irq(int irq, void *handle)
chdata);
}
- input_report_abs(ts->input, ABS_X, x);
- input_report_abs(ts->input, ABS_Y, y);
+ touchscreen_report_pos(ts->input, &ts->props, x, y, false);
input_report_key(ts->input, BTN_TOUCH, 1);
input_sync(ts->input);
dev_dbg(dev, "point(%4d,%4d)\n", x, y);
@@ -226,8 +227,8 @@ static irqreturn_t sx8654_irq(int irq, void *handle)
x = ((data[0] & 0xf) << 8) | (data[1]);
y = ((data[2] & 0xf) << 8) | (data[3]);
- input_report_abs(sx8654->input, ABS_X, x);
- input_report_abs(sx8654->input, ABS_Y, y);
+ touchscreen_report_pos(sx8654->input, &sx8654->props, x, y,
+ false);
input_report_key(sx8654->input, BTN_TOUCH, 1);
input_sync(sx8654->input);
@@ -377,6 +378,8 @@ static int sx8654_probe(struct i2c_client *client,
input_set_abs_params(input, ABS_X, 0, MAX_12BIT, 0, 0);
input_set_abs_params(input, ABS_Y, 0, MAX_12BIT, 0, 0);
+ touchscreen_parse_properties(input, false, &sx8654->props);
+
sx8654->client = client;
sx8654->input = input;
--
2.11.0
[RESEND PATCH v2 6/8] Input: sx8654 - add sx8650 support
The sx8654 and sx8650 are quite similar, therefore add support for the
sx8650 within the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 193 +
1 file changed, 173 insertions(+), 20 deletions(-)
diff --git a/drivers/input/touchscreen/sx8654.c
b/drivers/input/touchscreen/sx8654.c
index afa4da138fe9..4939863efbef 100644
--- a/drivers/input/touchscreen/sx8654.c
+++ b/drivers/input/touchscreen/sx8654.c
@@ -29,7 +29,7 @@
#include
#include
-#include
+#include
#include
#include
#include
@@ -44,9 +44,11 @@
#define I2C_REG_IRQSRC 0x23
#define I2C_REG_SOFTRESET 0x3f
+#define I2C_REG_SX8650_STAT0x05
+#define SX8650_STAT_CONVIRQ0x80
+
/* commands */
#define CMD_READ_REGISTER 0x40
-#define CMD_MANUAL 0xc0
#define CMD_PENTRG 0xe0
/* value for I2C_REG_SOFTRESET */
@@ -58,6 +60,7 @@
/* bits for RegTouch1 */
#define CONDIRQ0x20
+#define RPDNT_100K 0x00
#define FILT_7SA 0x03
/* bits for I2C_REG_CHANMASK */
@@ -71,14 +74,122 @@
/* power delay: lower nibble of CTRL0 register */
#define POWDLY_1_1MS 0x0b
+/* for sx8650, as we have no pen release IRQ there: timeout in ns following the
+ * last PENIRQ after which we assume the pen is lifted.
+ */
+#define SX8650_PENIRQ_TIMEOUT msecs_to_jiffies(10)
+
#define MAX_12BIT ((1 << 12) - 1)
+#define MAX_I2C_READ_LEN 10 /* see datasheet section 5.1.5 */
+
+/* channel definition */
+#define CH_X 0x00
+#define CH_Y 0x01
+
+struct sx865x_data {
+ u8 cmd_manual;
+ u8 chan_mask;
+ u8 has_irq_penrelease;
+ u8 has_reg_irqmask;
+ irq_handler_t irqh;
+};
struct sx8654 {
struct input_dev *input;
struct i2c_client *client;
struct gpio_desc *gpio_reset;
+
+ spinlock_t lock; /* for input reporting from irq/timer */
+ struct timer_list timer;
+
+ const struct sx865x_data *data;
};
+static inline void sx865x_penrelease(struct sx8654 *ts)
+{
+ struct input_dev *input_dev = ts->input;
+
+ input_report_key(input_dev, BTN_TOUCH, 0);
+ input_sync(input_dev);
+}
+
+static void sx865x_penrelease_timer_handler(struct timer_list *t)
+{
+ struct sx8654 *ts = from_timer(ts, t, timer);
+ unsigned long flags;
+
+ spin_lock_irqsave(&ts->lock, flags);
+ sx865x_penrelease(ts);
+ spin_unlock_irqrestore(&ts->lock, flags);
+ dev_dbg(&ts->client->dev, "penrelease by timer\n");
+}
+
+static irqreturn_t sx8650_irq(int irq, void *handle)
+{
+ struct sx8654 *ts = handle;
+ struct device *dev = &ts->client->dev;
+ int len, i;
+ unsigned long flags;
+ u8 stat;
+ u16 x, y;
+ u8 data[MAX_I2C_READ_LEN];
+ u16 ch;
+ u16 chdata;
+ u8 readlen = hweight32(ts->data->chan_mask) * 2;
+
+ stat = i2c_smbus_read_byte_data(ts->client, CMD_READ_REGISTER
+ | I2C_REG_SX8650_STAT);
+
+ if (!(stat & SX8650_STAT_CONVIRQ)) {
+ dev_dbg(dev, "%s ignore stat [0x%02x]", __func__, stat);
+ return IRQ_HANDLED;
+ }
+
+ len = i2c_master_recv(ts->client, data, readlen);
+ if (len != readlen) {
+ dev_dbg(dev, "ignore short recv (%d)\n", len);
+ return IRQ_HANDLED;
+ }
+
+ spin_lock_irqsave(&ts->lock, flags);
+
+ x = 0;
+ y = 0;
+ for (i = 0; (i + 1) < len; i++) {
+ chdata = data[i] << 8;
+ i++;
+ chdata += data[i];
+
+ if (unlikely(chdata == 0x)) {
+ dev_dbg(dev, "invalid qualified data @ %d\n", i);
+ continue;
+ } else if (unlikely(chdata & 0x8000)) {
+ dev_warn(dev, "hibit @ %d [0x%04x]\n", i, chdata);
+ continue;
+ }
+
+ ch = chdata >> 12;
+ if (ch == CH_X)
+ x = chdata & MAX_12BIT;
+ else if (ch == CH_Y)
+ y = chdata & MAX_12BIT;
+ else
+ dev_warn(dev, "unknown channel %d [0x%04x]\n", ch,
+chdata);
+ }
+
+ input_report_abs(ts->input, ABS_X, x);
+ input_report_abs(ts->input, ABS_Y, y);
+ input_report_key(ts->input, BTN_TOUCH, 1);
+ input_sync(ts->input);
+ dev_dbg(dev, "point(%4d,%4d)\n", x, y);
+
+ mod_timer(&ts->timer, jiffies + SX8650_PENIRQ_TIMEOUT);
+ spin_unlock_irqrestore(&ts->lock, flags);
+
+ return IRQ_HANDLED;
+}
+
static irqreturn_t sx8654_irq(int irq, void *handle)
{
struct sx86
Re: linux-next: Signed-off-by missing for commit in the printk tree
On Tue 2018-12-18 07:08:07, Stephen Rothwell wrote:
> Hi Petr,
>
> Commit
>
> 503283fa006d ("printk: Add caller information to printk() output.")
>
> is missing a Signed-off-by from its committer.
>
> Moreover, that patch appears twice in the tree (the other time properly
> signed-off),
Thanks a lot for the report. I have fixed it.
Sigh, I guess that I left there the duplicated patch from testing.
It is pity that git did not complain. I need to be more careful.
Best Regards,
Petr
Re: [RFC PATCH 1/3] config: provide a fragment to enable gdb for qemu
On Thu, 13 Dec 2018 at 13:40, Mark Brown wrote: > > On Thu, Dec 13, 2018 at 01:29:08PM +0100, Anders Roxell wrote: > > Adding a fragment to make it easier to know what options is needed to > > build a kernel to get the that you can debug in qemu. > > > @@ -0,0 +1,7 @@ > > +# Enable debug info for gdb > > +# CONFIG_COMPILE_TEST is not set > > +CONFIG_DEBUG_INFO=y > > +CONFIG_GDB_SCRIPTS=y > > Is this specifically for qemu or is this just good for debugging with > GDB in general (eg, via JTAG)? I haven't tried, and I don't have a JTAG so I could test it =/ Cheers, Anders
Re: [Xen-devel] [PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation
On 12/17/18 5:26 PM, Boris Ostrovsky wrote: On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote: On 12/17/18 4:52 PM, Boris Ostrovsky wrote: On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote: Hello, Juergen, Boris! As this DRM part of the series is the only one which needs ack/nack (and it might take quite some time to complete) could we please merge the patches 1 and 3 now that already have ack/r-b? TBH I am not sure it makes sense to do this without the second patch. Refactoring (and IIUIC this series is purely refactoring --- is it not?) is done to reduce amount of code, and with only first and third patch we end up with quite a significant increase in the number of LoC. (I am going purely by diffstat) Of course, the other reason for refactoring is to eliminate code duplication, but without second patch that will not happen. Agree, but this is the basis for the new pv camera frontend I am working on now [1], so even if we do not remove the code from DRM then we at least do not add it to the camera driver Since 1 and 3 are already ACKed you should be able to start the camera series with these two patches as pre-requisites even if patch 2 is still stalled by the time your camera code is posted (which I assume will be 4.22 or later). Agreed, maybe by that time DRM part will also get its r-b/ack -boris -boris Thank you, Oleksandr [1] https://github.com/andr2000/linux/blob/camera_front_v1/drivers/media/xen/Kconfig#L6
Re: [f2fs-dev] [PATCH 3/3] f2fs: flush stale issued discard candidates
On 2018/12/14 13:01, Jaegeuk Kim wrote:
> Sometimes, I could observe # of issuing_discard to be 1 which blocks
> background
> jobs due to is_idle()=false.
> The only way to get out of it was to trigger gc_urgent. This patch avoids that
> by checking any candidates as done in the list.
Well, as below code, once we issued discard commands, we will wait all
queued discard end their IO, so do you know what flow can cause such
condition...?
issued = __issue_discard_cmd(sbi, &dpolicy);
if (issued > 0) {
__wait_all_discard_cmd(sbi, &dpolicy);
Or, I doubt that 'issued' statistical info could be wrong.
Thanks,
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/segment.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 49ea9009ab5a..acbbc924e518 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1651,6 +1651,10 @@ static int issue_discard_thread(void *data)
> if (dcc->discard_wake)
> dcc->discard_wake = 0;
>
> + /* clean up pending candidates before going to sleep */
> + if (atomic_read(&dcc->queued_discard))
> + __wait_all_discard_cmd(sbi, NULL);
> +
> if (try_to_freeze())
> continue;
> if (f2fs_readonly(sbi->sb))
>
[PATCH v2] VSOCK: Send reset control packet when socket is partially bound
If a server side socket is bound to an address, but not in the listening
state yet, incoming connection requests should receive a reset control
packet in response. However, the function used to send the reset
silently drops the reset packet if the sending socket isn't bound
to a remote address (as is the case for a bound socket not yet in
the listening state). This change fixes this by using the src
of the incoming packet as destination for the reset packet in
this case.
Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Reviewed-by: Adit Ranadive
Reviewed-by: Vishnu Dasa
Signed-off-by: Jorgen Hansen
---
v1 -> v2:
- Changed order of local variables
net/vmw_vsock/vmci_transport.c | 67 +++---
1 file changed, 50 insertions(+), 17 deletions(-)
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index 0ae3614..5cf8935 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -264,6 +264,31 @@ vmci_transport_send_control_pkt_bh(struct sockaddr_vm *src,
}
static int
+vmci_transport_alloc_send_control_pkt(struct sockaddr_vm *src,
+ struct sockaddr_vm *dst,
+ enum vmci_transport_packet_type type,
+ u64 size,
+ u64 mode,
+ struct vmci_transport_waiting_info *wait,
+ u16 proto,
+ struct vmci_handle handle)
+{
+ struct vmci_transport_packet *pkt;
+ int err;
+
+ pkt = kmalloc(sizeof(*pkt), GFP_KERNEL);
+ if (!pkt)
+ return -ENOMEM;
+
+ err = __vmci_transport_send_control_pkt(pkt, src, dst, type, size,
+ mode, wait, proto, handle,
+ true);
+ kfree(pkt);
+
+ return err;
+}
+
+static int
vmci_transport_send_control_pkt(struct sock *sk,
enum vmci_transport_packet_type type,
u64 size,
@@ -272,9 +297,7 @@ vmci_transport_send_control_pkt(struct sock *sk,
u16 proto,
struct vmci_handle handle)
{
- struct vmci_transport_packet *pkt;
struct vsock_sock *vsk;
- int err;
vsk = vsock_sk(sk);
@@ -284,17 +307,10 @@ vmci_transport_send_control_pkt(struct sock *sk,
if (!vsock_addr_bound(&vsk->remote_addr))
return -EINVAL;
- pkt = kmalloc(sizeof(*pkt), GFP_KERNEL);
- if (!pkt)
- return -ENOMEM;
-
- err = __vmci_transport_send_control_pkt(pkt, &vsk->local_addr,
- &vsk->remote_addr, type, size,
- mode, wait, proto, handle,
- true);
- kfree(pkt);
-
- return err;
+ return vmci_transport_alloc_send_control_pkt(&vsk->local_addr,
+&vsk->remote_addr,
+type, size, mode,
+wait, proto, handle);
}
static int vmci_transport_send_reset_bh(struct sockaddr_vm *dst,
@@ -312,12 +328,29 @@ static int vmci_transport_send_reset_bh(struct
sockaddr_vm *dst,
static int vmci_transport_send_reset(struct sock *sk,
struct vmci_transport_packet *pkt)
{
+ struct sockaddr_vm *dst_ptr;
+ struct sockaddr_vm dst;
+ struct vsock_sock *vsk;
+
if (pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST)
return 0;
- return vmci_transport_send_control_pkt(sk,
- VMCI_TRANSPORT_PACKET_TYPE_RST,
- 0, 0, NULL, VSOCK_PROTO_INVALID,
- VMCI_INVALID_HANDLE);
+
+ vsk = vsock_sk(sk);
+
+ if (!vsock_addr_bound(&vsk->local_addr))
+ return -EINVAL;
+
+ if (vsock_addr_bound(&vsk->remote_addr)) {
+ dst_ptr = &vsk->remote_addr;
+ } else {
+ vsock_addr_init(&dst, pkt->dg.src.context,
+ pkt->src_port);
+ dst_ptr = &dst;
+ }
+ return vmci_transport_alloc_send_control_pkt(&vsk->local_addr, dst_ptr,
+VMCI_TRANSPORT_PACKET_TYPE_RST,
+0, 0, NULL, VSOCK_PROTO_INVALID,
+VMCI_INVALID_HANDLE);
}
static int vmci_transport_send_negotiate(struct sock *sk, size_t size)
--
2.6.2
Re: WARNING in __rcu_read_unlock
On Tue, Dec 18, 2018 at 12:18 AM Stefano Brivio wrote:
>
> On Mon, 17 Dec 2018 16:53:36 +0100
> Dmitry Vyukov wrote:
>
> > On Mon, Dec 17, 2018 at 4:24 PM Stefano Brivio wrote:
> > >
> > > On Mon, 17 Dec 2018 06:57:35 -0800
> > > Eric Dumazet wrote:
> > >
> > > > Might be cause by commit b8a51b38e4d4dec3e379d52c0fe1a66827f7cf1e
> > > > fou, fou6: ICMP error handlers for FoU and GUE
> > >
> > > This:
> > >
> > > diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
> > > index 0d0ad19ecb87..20a6de26d146 100644
> > > --- a/net/ipv4/fou.c
> > > +++ b/net/ipv4/fou.c
> > > @@ -1008,6 +1008,9 @@ static int gue_err_proto_handler(int proto, struct
> > > sk_buff *skb, u32 info)
> > > {
> > > const struct net_protocol *ipprot =
> > > rcu_dereference(inet_protos[proto]);
> > >
> > > + if (ipprot == IPPROTO_UDP)
> > > + return -EINVAL;
> > > +
> > > if (ipprot && ipprot->err_handler) {
> > > if (!ipprot->err_handler(skb, info))
> > > return 0;
> > >
> > > should fix the issue, but I still have to run tests and make sure we
> > > don't hit similar cases.
> >
> > Please don't forget to add a regression test for it too ;)
>
> Where would you suggest to add this? The only selftest that goes
I dunno. But there must be some place for such tests, right?
> through this path currently is net/pmtu.sh, but as configuration of an
> actual UDP-in-GUE tunnel is currently not supported, I would really
> need to forge that specific packet, so that doesn't seem to be a good
> fit.
>
> Won't syzbot add this to some list of reproducers that are checked in
> the future?
It won't. Also fuzzing is complementary to testing, not a replacement:
https://twitter.com/dvyukov/status/1074719682962358272
Re: [PATCH V2] livepatch: fix non-static warnings
On Mon, 17 Dec 2018, Joe Lawrence wrote:
> On 12/17/2018 07:03 AM, Miroslav Benes wrote:
> > Hi,
> >
> > I'm sorry for being late to the party.
> >
> > On Sun, 16 Dec 2018, Nicholas Mc Guire wrote:
> >
> >> Sparse reported warnings about non-static symbols. For the variables
> >> a simple static attribute is fine - for those symbols referenced by
> >> livepatch via klp_func the symbol-names must be unmodified in the
> >> symbol table - to resolve this the __noclone attribute is used
> >> for the shared statically declared functions.
> >>
> >> Signed-off-by: Nicholas Mc Guire
> >> Suggested-by: Joe Lawrence
> >> Link: https://lkml.org/lkml/2018/12/13/827
> >
> > A nit, but I'd reorder the tags. Link, Suggested-by:, Signed-off-by:. Also
> > it would be great if you used https://lkml.kernel.org/r/${Msg-ID}
> > redirection.
> >
> >> ---
> >>
> >> V2: not all static functions shared need to carry the __noclone
> >> attribute only those that need to be resolved at runtime by
> >> livepatch - so drop the unnecessary __noclone attributes as
> >> well as the Note on __noclone as suggested by Joe Lawrence
> >> - thanks !
> >
> > I talked to Martin Jambor (GCC) and he suggested __attribute__((used)). It
> > should be better than __noclone, which was reportedly implemented only for
> > testing purposes (which is why it does not imply noinline, although
> > inlining internally uses cloning). Newer gcc also has "noipa" attribute,
> > but "used" would definitely be safe.
> >
> > Sorry for not responding earlier.
> >
>
> Hi Miroslav,
>
> Thanks for following up on this. "noipa" would have been nice to use,
> but as you say, is a newer gcc attribute.
>
> Regarding "used" vs. "noclone", can we assume that "used" implies that
> the function name remains unchanged?
I am not sure. I'd argue that it does imply that, but it could just be
a consequence without any guarantees. My understanding is that gcc cannot
assume about a symbol and its references. So it should be preserved as is.
> The gcc online doc [1] speaks about ensuring that "code must be
> emitted". This reads like it solves our
> static-function-not-directly-referenced problem, but isn't explicit
> about naming.
Correct.
> used
>
> This attribute, attached to a function, means that code must be
> emitted for the function even if it appears that the function is not
> referenced. This is useful, for example, when the function is
> referenced only in inline assembly.
>
> Perhaps it's equivalent to a "I want to keep this function and leave
> it's symbols alone" attribute. FWIW, I modified Nicholas' change on my
> box to use "used" and it worked as Martin advertised, so it would get my
> Ack.
>
> I'm just being picky about its documentation and how we should note its
> usage in the v3 patch. Think that s/__noclone/used/g of the v2 commit
> message would be sufficient?
We could rephrase it. After all it is not only about symbol names in the
symbol table. The traceable/patchable code has to be present...
"Sparse reported warnings about non-static symbols. For the variables
a simple static attribute is fine - for the functions referenced by
livepatch via klp_func the symbol-names must be unmodified in the
symbol table and the patchable code has to be emitted.
Attach __used attribute to the shared statically declared functions."
?
Miroslav
Dear
Dear,i am lisa jaster,it would be great to know you,i have a very important and confidential matter that i want to discuss with you,reply me back for more discus. Regards, Lisa Jaster.
Re: [PATCH v3 3/6] irqchip: sifive-plic: More flexible plic_irq_toggle()
On Mon, Dec 17, 2018 at 11:57 PM Christoph Hellwig wrote:
>
> > -static inline void plic_toggle(struct plic_handler *handler,
> > - int hwirq, int enable)
> > +static void plic_toggle(struct plic_handler *handler, int hwirq, int
> > enable)
> > {
> > u32 __iomem *reg = handler->enable_base + (hwirq / 32) * sizeof(u32);
> > u32 hwirq_mask = 1 << (hwirq % 32);
> > @@ -92,27 +91,27 @@ static inline void plic_toggle(struct plic_handler
> > *handler,
> > raw_spin_unlock(&handler->enable_lock);
> > }
> >
> > -static inline void plic_irq_toggle(struct irq_data *d, int enable)
> > +static void plic_irq_toggle(const struct cpumask *mask, int hwirq, int
> > enable)
>
> It also removes inline statements which seems rather unrelated to
> the patch description.
Actually these functions should not be inline because plic_toggle() uses
raw_spin_lock() and plic_irq_toggle() uses for-loop.
>
> Also the actual addintion of the single cpumask argument is simple
> enough that it should probably go into the patch that makes use of it.
OK, I will have separate patch for removing "inline" and move addition
of cpumask argument to last patch.
Regards,
Anup
Re: [PATCH v14 10/11] livepatch: Remove ordering and refuse loading conflicting patches
On Mon 2018-12-17 10:27:29, Josh Poimboeuf wrote: > On Mon, Dec 17, 2018 at 05:07:09PM +0100, Petr Mladek wrote: > > On Thu 2018-12-13 17:06:52, Josh Poimboeuf wrote: > > > On Thu, Nov 29, 2018 at 10:44:30AM +0100, Petr Mladek wrote: > > > > The atomic replace and cumulative patches were introduced as a more > > > > secure > > > > way to handle dependent patches. They simplify the logic: > > > > > > > > + Any new cumulative patch is supposed to take over shadow variables > > > > and changes made by callbacks from previous livepatches. > > > > > > > > + All replaced patches are discarded and the modules can be unloaded. > > > > As a result, there is only one scenario when a cumulative livepatch > > > > gets disabled. > > > > > > > > The different handling of "normal" and cumulative patches might cause > > > > confusion. It would make sense to keep only one mode. On the other hand, > > > > it would be rude to enforce using the cumulative livepatches even for > > > > trivial and independent (hot) fixes. > > > > > > > > This patch removes the stack of patches. The list of enabled patches > > > > is still needed but the ordering is not longer enforced. > > > > > > > > Note that it is not possible to catch all possible dependencies. It is > > > > the responsibility of the livepatch authors to decide. > > > > > > > > Nevertheless this patch prevents having two patches for the same > > > > function > > > > enabled at the same time after the transition finishes. It might help > > > > to catch obvious mistakes. But more importantly, we do not need to > > > > handle situation when a patch in the middle of the function stack > > > > (ops->func_stack) is being removed. > > > > > > I'm not sure about this patch. I like the removal of the stacking. But > > > do we really want to enforce no dependencies between non-cumulative > > > patches? It can be done correctly if the user is careful. > > > > > > Maybe we should just let users do it if they want to. And then that > > > also would mean less code for us to maintain. > > > > > > And as usual, I apologize if I'm either contradicting or repeating past > > > versions of myself. :-) > > > > This patch was actually motivated by you. On some conference, we > > discussed how to automatize the creation of livepatches. You wanted > > to make livepatching more safe in general (by tools, by checks, ...). > > Also you always wanted to make things easier and reduce possible > > scenarios. I thought that this might be in line with your wishes. > > > > The problem with this patch is that it forces people to use > > cumulative patches. I am not sure if everyone is ready for it. > > > > I do not resist on it. But I still think that it makes sense. > > I do remember suggesting the removal of the stacking. I think that's a > good idea. > > I don't remember suggesting the other part: trying to detect and prevent > dependencies for non-replace users. If I did suggest that, which is > very possible, I apologize for being wishy-washy :-) You remember it correctly. You proposed only the removing of the stacking. The preventing dependent patches was my idea. I thought that it might be in line with your vision. I was wrong ;-) > The way I currently see it, there are two classes of users: cumulative > and non-cumulative. IMO we should accept both as reasonable > possiblities. > > Cumulative users will use 'replace'. Non-cumulative users will do > whatever they want, and we shouldn't try to restrict them. > > So I would propose that we remove the stacking, and not try to enforce > patch dependencies in any way. OK, I will remove the restriction in v15. Best Regards, Petr
Re: [PATCH v2] mfd: cros_ec: Add commands to control codec
On Tue, 18 Dec 2018, Cheng-yi Chiang wrote: > +Benson, Guenter, Scott > > On Fri, Dec 14, 2018 at 8:22 PM Lee Jones wrote: > > > > On Fri, 14 Dec 2018, Lee Jones wrote: > > > > > On Thu, 06 Dec 2018, Cheng-Yi Chiang wrote: > > > > > > > Add EC host commands to control codec on EC. > > > > > > > > Signed-off-by: Cheng-Yi Chiang > > > > --- > > > > V2 fixed the wrong ancestor issue so the patch can be applied cleanly > > > > on mfd tree. > > > > Codec driver that uses these commands will be sent separately. > > > > Thanks! > > > > > > > > include/linux/mfd/cros_ec_commands.h | 94 > > > > 1 file changed, 94 insertions(+) > > > > > > Would be good to have this reviewed by some more Chrome people. > > > > See this for reference: > > > > https://lore.kernel.org/patchwork/patch/1024985/ > > Hi Benson and Guenter, > Could you please review this patch ? You haven't sent them the patch. Please resubmit as a [RESEND] and add them as recipients. > The corresponding implementation at EC side by Scott is at > https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1356185 > > Thanks a lot! > > > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] printk: Add caller information to printk() output.
On (12/18/18 06:05), Tetsuo Handa wrote:
> +#ifdef CONFIG_PRINTK_CALLER
> +static size_t print_caller(u32 id, char *buf)
> +{
> + char from[12];
> +
> + snprintf(from, sizeof(from), "%c%u",
> + id & 0x8000 ? 'C' : 'T', id & ~0x8000);
> + return sprintf(buf, "[%6s]", from);
> +}
A nitpick:
s/from/caller/g :)
> + Selecting this option causes "thread id" (if in task context) or
> + "processor id" (if not in task context) of the printk() messages
> + to be added.
Would the following wording be a bit simpler?
"Selecting this option causes printk() to add a caller "thread id" (if
in task context) or a caller "processor id" (if not in task context)
to every message."
-ss
Re: [RFC v2] regmap: regmap-irq: Add main status register support
On Mon, Dec 17, 2018 at 05:32:44PM +, Mark Brown wrote: > On Fri, Dec 14, 2018 at 04:08:12PM +0200, Matti Vaittinen wrote: > > > This is draft for approach proposed by Mark here: > > http://lkml.iu.edu/hypermail/linux/kernel/1812.1/07117.html > > > Pretty untested and diff is done against tree where the level active IRQ > > support for regmap-irq was added. So please consider this just as a RFC > > introducing the concept. I will format correct and better tested patch if > > this is the preferred way to go. > > Hrm, so the parsing code is indeed quite complicated. I suspect it > could be simplified if instead of trying to allocate just what's used it > was a bit more wasteful and allocated the biggest arrays we might need > but I'm not sure how much that'd really help so yeah, doing it the other > way around might be better. It might get a little bit simpler but not much I think. And the driver interface could be a little bit simpler if we drop the support for giving the "main bit mapping" as an array and only support giving the main bits in the struct regmap_irqs. Then the num_main_status_bits, num_main_regs and sub_reg_offsets could be made internal to regmap-irq. OTOH dropping num_main_regs would add up one more thing requiring dynamic allocation as we could not compute the number of main register bits in advance. I will proceed with the RFC v1 approach. Nothing prevents us from implementing the v2 later if there is use-cases for that. But it will take a while before I get this thing tested and user for it. Additionally I guess we do need a bui-in from Lee as most of this kind of devices with many sub blocks are likely to be represented as MFD devices. I guess I should have included him in the recipient list for the RFCs :/ Thanks for all the support this far! Br, Matti Vaittinen -- Matti Vaittinen ROHM Semiconductors ~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
Re: [PATCH] printk: Add caller information to printk() output.
On (12/18/18 09:39), Petr Mladek wrote: > > Sergey, are you okay with this squashed patch, please? > Yeah. There are several minor nitpicks, but here is my Acked-by: Sergey Senozhatsky One final question - can syzbot folks confirm that the patch helps? Just curious. -ss
Re: [RFC PATCH v2] regmap: regmap-irq/gpio-max77620: add level-irq support
On Mon, Dec 17, 2018 at 06:07:22PM +, Mark Brown wrote: > On Mon, Dec 17, 2018 at 10:42:48AM +0200, Matti Vaittinen wrote: > > On Thu, Dec 13, 2018 at 06:20:26PM +, Mark Brown wrote: > > > > I can't remember and can't find any record of any discussion of it which > > > is odd, might've been on IRC or something. Let's just remove it and see > > > what breaks, since we generally provide the type along with the request > > > for the interrupt I'm not sure how often the default actually gets used. > > > Possibly safer as a second patch though in case there is a good reason > > > that I missed so we can easily revert it. > > > So how do you see this - should the regmap_add_irq_chip read the current > > type setting information from HW and populate the cached type values > > based on the current HW configuration? (I think that would be corect > > thing to do). > > Yes. I'll go with this then. I'll try sending the patch removing the default edge configuration still today. > > > > It > > > does look safe to me but it's possible I missed something. Equally it > > > only seems to be some quite old Tegra systems using the max77620 so > > > perhaps mainline usage of affected devices is limited anyway... > > > Right. This makes me wonder if there is some other preferred approach on > > this... How other drivers are doing the type configurations? Why they > > are not using regmap-irq? Am I missing something? But what comes to > > changing the regmap-irq type-setting this is definitely a good news =) > > I suspect a lot of devices lack configurability or have never actually > done anything where configurability would matter - probably the biggest > use of regmap-irq is interrupts internal to a chip where there's no real > need for that, and even where there are GPIOs I'd be surprised if many > of them were actually used as interrupts rather than dumb outputs or > something given that most embedded systems have an abundance of GPIOs > directly on the SoC which are much better. Thanks for the explanation =) This makes sense. -- Matti Vaittinen ROHM Semiconductors ~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
Re: [PATCH V2] livepatch: fix non-static warnings
On Mon, 17 Dec 2018, Nicholas Mc Guire wrote:
> On Mon, Dec 17, 2018 at 10:44:36AM -0500, Joe Lawrence wrote:
> > On 12/17/2018 07:03 AM, Miroslav Benes wrote:
> > > Hi,
> > >
> > > I'm sorry for being late to the party.
> > >
> > > On Sun, 16 Dec 2018, Nicholas Mc Guire wrote:
> > >
> > >> Sparse reported warnings about non-static symbols. For the variables
> > >> a simple static attribute is fine - for those symbols referenced by
> > >> livepatch via klp_func the symbol-names must be unmodified in the
> > >> symbol table - to resolve this the __noclone attribute is used
> > >> for the shared statically declared functions.
> > >>
> > >> Signed-off-by: Nicholas Mc Guire
> > >> Suggested-by: Joe Lawrence
> > >> Link: https://lkml.org/lkml/2018/12/13/827
> > >
> > > A nit, but I'd reorder the tags. Link, Suggested-by:, Signed-off-by:.
> > > Also
> > > it would be great if you used https://lkml.kernel.org/r/${Msg-ID}
> > > redirection.
> > >
> > >> ---
> > >>
> > >> V2: not all static functions shared need to carry the __noclone
> > >> attribute only those that need to be resolved at runtime by
> > >> livepatch - so drop the unnecessary __noclone attributes as
> > >> well as the Note on __noclone as suggested by Joe Lawrence
> > >> - thanks !
> > >
> > > I talked to Martin Jambor (GCC) and he suggested __attribute__((used)).
> > > It
> > > should be better than __noclone, which was reportedly implemented only
> > > for
> > > testing purposes (which is why it does not imply noinline, although
> > > inlining internally uses cloning). Newer gcc also has "noipa" attribute,
> > > but "used" would definitely be safe.
> > >
> > > Sorry for not responding earlier.
> > >
> >
> > Hi Miroslav,
> >
> > Thanks for following up on this. "noipa" would have been nice to use,
> > but as you say, is a newer gcc attribute.
> >
> > Regarding "used" vs. "noclone", can we assume that "used" implies that
> > the function name remains unchanged?
> >
> > The gcc online doc [1] speaks about ensuring that "code must be
> > emitted". This reads like it solves our
> > static-function-not-directly-referenced problem, but isn't explicit
> > about naming.
> >
> > used
> >
> > This attribute, attached to a function, means that code must be
> > emitted for the function even if it appears that the function is not
> > referenced. This is useful, for example, when the function is
> > referenced only in inline assembly.
> >
> > Perhaps it's equivalent to a "I want to keep this function and leave
> > it's symbols alone" attribute. FWIW, I modified Nicholas' change on my
> > box to use "used" and it worked as Martin advertised, so it would get my
> > Ack.
> >
> > I'm just being picky about its documentation and how we should note its
> > usage in the v3 patch. Think that s/__noclone/used/g of the v2 commit
> > message would be sufficient?
> >
> should that then not be __used as this is provided in compiler_attributes.h
> see also: https://lkml.org/lkml/2018/9/20/909
Yes, __used is better.
> also would it be reasonable to maybe add something like:
> #define __livepatch __attribute__((__noclone__, __noinline__))
> in compiler_attributes.h ? it would make it imediately clear that the
> attributes
> are related to the way lp works internally.
No, I don't think so. The samples (and selftests) are special in that we
would like to provide minimal examples (or testcases). GCC is in the way
due to its optimizations. It is not the case with the common code (the
problem there is a bit different. Some optimizations are just dangerous
for livepatching. However that is tangential to this patch and will be
solved elsewhere).
Thanks,
Miroslav
[RESEND v2] mfd: cros_ec: Add commands to control codec
Add EC host commands to control codec on EC.
Signed-off-by: Cheng-Yi Chiang
---
include/linux/mfd/cros_ec_commands.h | 94
1 file changed, 94 insertions(+)
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index 9a9631f0559e2..fc91082d4c357 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -2790,6 +2790,100 @@ struct ec_response_battery_vendor_param {
uint32_t value;
} __packed;
+/*/
+/* Commands for I2S recording on audio codec. */
+
+#define EC_CMD_CODEC_I2S 0x00BC
+
+enum ec_codec_i2s_subcmd {
+ EC_CODEC_SET_SAMPLE_DEPTH = 0x0,
+ EC_CODEC_SET_GAIN = 0x1,
+ EC_CODEC_GET_GAIN = 0x2,
+ EC_CODEC_I2S_ENABLE = 0x3,
+ EC_CODEC_I2S_SET_CONFIG = 0x4,
+ EC_CODEC_I2S_SET_TDM_CONFIG = 0x5,
+ EC_CODEC_I2S_SET_BCLK = 0x6,
+};
+
+enum ec_sample_depth_value {
+ EC_CODEC_SAMPLE_DEPTH_16 = 0,
+ EC_CODEC_SAMPLE_DEPTH_24 = 1,
+};
+
+enum ec_i2s_config {
+ EC_DAI_FMT_I2S = 0,
+ EC_DAI_FMT_RIGHT_J = 1,
+ EC_DAI_FMT_LEFT_J = 2,
+ EC_DAI_FMT_PCM_A = 3,
+ EC_DAI_FMT_PCM_B = 4,
+ EC_DAI_FMT_PCM_TDM = 5,
+};
+
+struct ec_param_codec_i2s {
+ /*
+* enum ec_codec_i2s_subcmd
+*/
+ uint8_t cmd;
+ union {
+ /*
+* EC_CODEC_SET_SAMPLE_DEPTH
+* Value should be one of ec_sample_depth_value.
+*/
+ uint8_t depth;
+
+ /*
+* EC_CODEC_SET_GAIN
+* Value should be 0~43 for both channels.
+*/
+ struct ec_param_codec_i2s_set_gain {
+ uint8_t left;
+ uint8_t right;
+ } __packed gain;
+
+ /*
+* EC_CODEC_I2S_ENABLE
+* 1 to enable, 0 to disable.
+*/
+ uint8_t i2s_enable;
+
+ /*
+* EC_CODEC_I2S_SET_COFNIG
+* Value should be one of ec_i2s_config.
+*/
+ uint8_t i2s_config;
+
+ /*
+* EC_CODEC_I2S_SET_TDM_CONFIG
+* Value should be one of ec_i2s_config.
+*/
+ struct ec_param_codec_i2s_tdm {
+ /*
+* 0 to 496
+*/
+ int16_t ch0_delay;
+ /*
+* -1 to 496
+*/
+ int16_t ch1_delay;
+ uint8_t adjacent_to_ch0;
+ uint8_t adjacent_to_ch1;
+ } __packed tdm_param;
+
+ /*
+* EC_CODEC_I2S_SET_BCLK
+*/
+ uint32_t bclk;
+ };
+} __packed;
+
+/*
+ * For subcommand EC_CODEC_GET_GAIN.
+ */
+struct ec_response_codec_gain {
+ uint8_t left;
+ uint8_t right;
+} __packed;
+
/*/
/* System commands */
--
2.20.1.415.g653613c723-goog
Re: [PATCH v3 1/5] dt-bindings: leds: Add pattern initialization from Device Tree
On Mon, 17 Dec 2018 at 23:40, Rob Herring wrote: > > On Wed, Dec 12, 2018 at 12:16:42PM +0100, Krzysztof Kozlowski wrote: > > Document new linux,trigger-pattern property for initialization of LED > > pattern trigger. > > > > Signed-off-by: Krzysztof Kozlowski > > --- > > Documentation/devicetree/bindings/leds/common.txt | 36 > > +++ > > 1 file changed, 36 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/leds/common.txt > > b/Documentation/devicetree/bindings/leds/common.txt > > index aa1399814a2a..3daccd4ea8a3 100644 > > --- a/Documentation/devicetree/bindings/leds/common.txt > > +++ b/Documentation/devicetree/bindings/leds/common.txt > > @@ -37,6 +37,42 @@ Optional properties for child nodes: > > "ide-disk" - LED indicates IDE disk activity (deprecated), > >in new implementations use "disk-activity" > > "timer" - LED flashes at a fixed, configurable rate > > + "pattern" - LED alters the brightness for the specified duration with > > one > > + software timer (requires "led-pattern" property) > > + > > +- led-pattern : String with default pattern for certain triggers. Each > > trigger > > +may parse this string differently: > > +- one-shot : two numbers specifying delay on and delay off, > > +- timer : two numbers specifying delay on and delay off, > > I misunderstood that these triggers applied to this. Is there any point > to supporting these modes? I am not sure whether I explained this clearly enough, so let me be more specific. The "led-pattern" is a string with pattern which will be interpreted differently, based on LED trigger. One-shot and timer triggers expect two numbers. Pattern trigger expects full pattern. > Aren't they just a subset or simplification > of a pattern? Yes, they are. > > Can we control the timer frequency from DT? The pattern could address > that limitation. No, currently we cannot. This patch with pattern solves that issue. > > > +- pattern : The pattern is given by a series of tuples, of > > Don't you need one-shot vs. repeat modes for patterns too? Repeat mode is defined by trigger. One-shot is one time. Timer and patter triggers are repeating. > > I could imagine you'd want a pattern for any trigger. In general I think that only these three triggers require such initialization through pattern. Other triggers - like heartbeat or activity - have they own bindings (or do not need any). Following Pavel's suggestion, I could convert it to array of integers which still should be suitable for these and any future triggers operating on numbers. Best regards, Krzysztof
Re: [PATCH 06/14] mm, migrate: Immediately fail migration of a page with no migration handler
On 12/15/18 12:03 AM, Mel Gorman wrote: > Pages with no migration handler use a fallback hander which sometimes > works and sometimes persistently fails such as blockdev pages. Migration > will retry a number of times on these persistent pages which is wasteful > during compaction. This patch will fail migration immediately unless the > caller is in MIGRATE_SYNC mode which indicates the caller is willing to > wait while being persistent. Right. > This is not expected to help THP allocation success rates but it does > reduce latencies slightly. > > 1-socket thpfioscale > 4.20.0-rc6 4.20.0-rc6 >noreserved-v1r4 failfast-v1r4 > Amean fault-both-1 0.00 ( 0.00%)0.00 * 0.00%* > Amean fault-both-3 2276.15 ( 0.00%) 3867.54 * -69.92%* This is rather weird. > Amean fault-both-5 4992.20 ( 0.00%) 5313.20 ( -6.43%) > Amean fault-both-7 7373.30 ( 0.00%) 7039.11 ( 4.53%) > Amean fault-both-1211911.52 ( 0.00%)11328.29 ( 4.90%) > Amean fault-both-1817209.42 ( 0.00%)16455.34 ( 4.38%) > Amean fault-both-2420943.71 ( 0.00%)20448.94 ( 2.36%) > Amean fault-both-3022703.00 ( 0.00%)21655.07 ( 4.62%) > Amean fault-both-3222461.41 ( 0.00%)21415.35 ( 4.66%) > > The 2-socket results are not materially different. Scan rates are > similar as expected. > > Signed-off-by: Mel Gorman Acked-by: Vlastimil Babka > --- > mm/migrate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index df17a710e2c7..0e27a10429e2 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -885,7 +885,7 @@ static int fallback_migrate_page(struct address_space > *mapping, >*/ > if (page_has_private(page) && > !try_to_release_page(page, GFP_KERNEL)) > - return -EAGAIN; > + return mode == MIGRATE_SYNC ? -EAGAIN : -EBUSY; > > return migrate_page(mapping, newpage, page, mode); > } >
Re: [RFC PATCH 1/3] config: provide a fragment to enable gdb for qemu
On Tue, Dec 18, 2018 at 9:45 AM Anders Roxell wrote: > > On Thu, 13 Dec 2018 at 13:40, Mark Brown wrote: > > > > On Thu, Dec 13, 2018 at 01:29:08PM +0100, Anders Roxell wrote: > > > Adding a fragment to make it easier to know what options is needed to > > > build a kernel to get the that you can debug in qemu. > > > > > @@ -0,0 +1,7 @@ > > > +# Enable debug info for gdb > > > +# CONFIG_COMPILE_TEST is not set > > > +CONFIG_DEBUG_INFO=y > > > +CONFIG_GDB_SCRIPTS=y > > > > Is this specifically for qemu or is this just good for debugging with > > GDB in general (eg, via JTAG)? > > I haven't tried, and I don't have a JTAG so I could test it =/ The DEBUG_INFO=y and (as a dependency for that) CONFIG_COMPILE_TEST are definitely needed for all GDB operation. I would assume that the scripts also work with any other gdb environment, but haven't tried either. For CONFIG_RANDOMIZE_BASE, I'm not actually sure if that helps or not. I think I originally suggested to Anders to turn that off when he was analyzing a bug, but I don't know if it helped or if it works just as well without that. Arnd
Re: [-next] lots of messages due to "mm, memory_hotplug: be more verbose for memory offline failures"
On Tue 18-12-18 08:55:38, Heiko Carstens wrote:
> On Mon, Dec 17, 2018 at 05:39:49PM +0100, Michal Hocko wrote:
> > On Mon 17-12-18 17:03:50, Michal Hocko wrote:
> > > On Mon 17-12-18 16:59:22, Heiko Carstens wrote:
> > > > Hi Michal,
> > > >
> > > > with linux-next as of today on s390 I see tons of messages like
> > > >
> > > > [ 20.536664] page dumped because: has_unmovable_pages
> > > > [ 20.536792] page:03d081ff4080 count:1 mapcount:0
> > > > mapping:8ff88600 index:0x0 compound_mapcount: 0
> > > > [ 20.536794] flags: 0x3fffe010200(slab|head)
> > > > [ 20.536795] raw: 03fffe010200 0100 0200
> > > > 8ff88600
> > > > [ 20.536796] raw: 00200041 0001
> > > >
> > > > [ 20.536797] page dumped because: has_unmovable_pages
> > > > [ 20.536814] page:03d0823b count:1 mapcount:0
> > > > mapping: index:0x0
> > > > [ 20.536815] flags: 0x7fffe00()
> > > > [ 20.536817] raw: 07fffe00 0100 0200
> > > >
> > > > [ 20.536818] raw: 0001
> > > >
> > > >
> > > > bisect points to b323c049a999 ("mm, memory_hotplug: be more verbose for
> > > > memory offline failures")
> > > > which is the first commit with which the messages appear.
> > >
> > > I would bet this is CMA allocator. How much is tons? Maybe we want a
> > > rate limit or the other user is not really interested in them at all?
>
> Yes, the system in question has a 4NB CMA area. "tons" translates to several
> hundred.
OK, I guess these messages on their own without a wider context are not
that helpful. It is still surprising to see slab pages or non-movable
pages in the CMA area. The later might be an CMA allocation I guess but
slab pages shouldn't be there at all AFAIU.
> > In other words, this should silence those messages.
>
> Yes, with the patch below applied the messages don't appear anymore.
OK, I will post an official patch. Even if CMA allocator decides to
report failures it can simply add the flag.
Thanks!
> > diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
> > index 4ae347cbc36d..4eb26d278046 100644
> > --- a/include/linux/page-isolation.h
> > +++ b/include/linux/page-isolation.h
> > @@ -30,8 +30,11 @@ static inline bool is_migrate_isolate(int migratetype)
> > }
> > #endif
> >
> > +#define SKIP_HWPOISON 0x1
> > +#define REPORT_FAILURE 0x2
> > +
> > bool has_unmovable_pages(struct zone *zone, struct page *page, int count,
> > -int migratetype, bool skip_hwpoisoned_pages);
> > +int migratetype, int flags);
> > void set_pageblock_migratetype(struct page *page, int migratetype);
> > int move_freepages_block(struct zone *zone, struct page *page,
> > int migratetype, int *num_movable);
> > @@ -44,10 +47,14 @@ int move_freepages_block(struct zone *zone, struct page
> > *page,
> > * For isolating all pages in the range finally, the caller have to
> > * free all pages in the range. test_page_isolated() can be used for
> > * test it.
> > + *
> > + * The following flags are allowed (they can be combined in a bit mask)
> > + * SKIP_HWPOISON - ignore hwpoison pages
> > + * REPORT_FAILURE - report details about the failure to isolate the range
> > */
> > int
> > start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
> > -unsigned migratetype, bool skip_hwpoisoned_pages);
> > +unsigned migratetype, int flags);
> >
> > /*
> > * Changes MIGRATE_ISOLATE to MIGRATE_MOVABLE.
> > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > index c82193db4be6..8537429d33a6 100644
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -1226,7 +1226,7 @@ static bool is_pageblock_removable_nolock(struct page
> > *page)
> > if (!zone_spans_pfn(zone, pfn))
> > return false;
> >
> > - return !has_unmovable_pages(zone, page, 0, MIGRATE_MOVABLE, true);
> > + return !has_unmovable_pages(zone, page, 0, MIGRATE_MOVABLE,
> > SKIP_HWPOISON);
> > }
> >
> > /* Checks if this range of memory is likely to be hot-removable. */
> > @@ -1577,7 +1577,8 @@ static int __ref __offline_pages(unsigned long
> > start_pfn,
> >
> > /* set above range as isolated */
> > ret = start_isolate_page_range(start_pfn, end_pfn,
> > - MIGRATE_MOVABLE, true);
> > + MIGRATE_MOVABLE,
> > + SKIP_HWPOISON | REPORT_FAILURE);
> > if (ret) {
> > mem_hotplug_done();
> > reason = "failure to isolate range";
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index ec2c7916dc2d..ee4043419791 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -7754,8 +7754,7 @@ void *__init all
Re: [PATCH v5 3/5] mm: Shuffle initial free memory to improve memory-side-cache utilization
On Mon, Dec 17, 2018 at 11:56:36AM -0800, Dan Williams wrote:
> On Sun, Dec 16, 2018 at 4:43 AM Mike Rapoport wrote:
> >
> > On Fri, Dec 14, 2018 at 05:48:46PM -0800, Dan Williams wrote:
> > > Randomization of the page allocator improves the average utilization of
> > > a direct-mapped memory-side-cache. Memory side caching is a platform
> > > capability that Linux has been previously exposed to in HPC
> > > (high-performance computing) environments on specialty platforms. In
> > > that instance it was a smaller pool of high-bandwidth-memory relative to
> > > higher-capacity / lower-bandwidth DRAM. Now, this capability is going to
> > > be found on general purpose server platforms where DRAM is a cache in
> > > front of higher latency persistent memory [1].
> [..]
> > > diff --git a/mm/memblock.c b/mm/memblock.c
> > > index 185bfd4e87bb..fd617928ccc1 100644
> > > --- a/mm/memblock.c
> > > +++ b/mm/memblock.c
> > > @@ -834,8 +834,16 @@ int __init_memblock
> > > memblock_set_sidecache(phys_addr_t base, phys_addr_t size,
> > > return ret;
> > >
> > > for (i = start_rgn; i < end_rgn; i++) {
> > > - type->regions[i].cache_size = cache_size;
> > > - type->regions[i].direct_mapped = direct_mapped;
> > > + struct memblock_region *r = &type->regions[i];
> > > +
> > > + r->cache_size = cache_size;
> > > + r->direct_mapped = direct_mapped;
> >
> > I think this change can be merged into the previous patch
>
> Ok, will do.
>
> > > + /*
> > > + * Enable randomization for amortizing direct-mapped
> > > + * memory-side-cache conflicts.
> > > + */
> > > + if (r->size > r->cache_size && r->direct_mapped)
> > > + page_alloc_shuffle_enable();
> >
> > It seems that this is the only use for ->direct_mapped in the memblock
> > code. Wouldn't cache_size != 0 suffice? I.e., in the code that sets the
> > memblock region attributes, the cache_size can be set to 0 for the non
> > direct mapped caches, isn't it?
> >
>
> The HMAT specification allows for other cache-topologies, so it's not
> sufficient to just look for non-zero size when a platform implements a
> set-associative cache. The expectation is that a set-associative cache
> would not need the kernel to perform memory randomization to improve
> the cache utilization.
>
> The check for memory size > cache-size is a sanity check for a
> platform BIOS or system configuration that mis-reports or mis-sizes
> the cache.
Apparently I didn't explain my point well.
The acpi_numa_memory_affinity_init() already knows whether the cache is
direct mapped or a set-associative. It can just skip calling
memblock_set_sidecache() for the set-associative case.
Another thing I've noticed only now, is that memory randomization is
enabled if there is at least one memory region with a direct mapped side
cache attached and once the randomization is on the cache size and the
mapping mode do not matter. So, I think it's not necessary to store them in
the memory region at all.
--
Sincerely yours,
Mike.
Re: [PATCH v4 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses
On Mon, Dec 17, 2018 at 07:43:26PM +0530, Balakrishna Godavarthi wrote:
> wcn3990 requires a power pulse to turn ON/OFF along with
> regulators. Sometimes we are observing the power pulses are sent
> out with some time delay, due to queuing these commands. This is
> causing synchronization issues with chip, which intern delay the
> chip setup or may end up with communication issues.
>
> Signed-off-by: Balakrishna Godavarthi
> ---
> v4:
> * used serdev_device_write_buf() instead of serdev_device_write()
>
> v3:
> * no change.
> v2:
> * Updated function qca_send_power_pulse()
> * addressed reviewer comments.
>
> v1:
> * initial patch
>
> ---
> drivers/bluetooth/hci_qca.c | 37 +
> 1 file changed, 13 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index f036c8f98ea3..d8bc77c8c9b9 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1013,11 +1013,9 @@ static inline void host_set_baudrate(struct hci_uart
> *hu, unsigned int speed)
> hci_uart_set_baudrate(hu, speed);
> }
>
> -static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
> +static int qca_send_power_pulse(struct hci_uart *hu, u8 cmd)
> {
> - struct hci_uart *hu = hci_get_drvdata(hdev);
> - struct qca_data *qca = hu->priv;
> - struct sk_buff *skb;
> + int ret;
>
> /* These power pulses are single byte command which are sent
>* at required baudrate to wcn3990. On wcn3990, we have an external
> @@ -1029,19 +1027,16 @@ static int qca_send_power_pulse(struct hci_dev *hdev,
> u8 cmd)
>* save power. Disabling hardware flow control is mandatory while
>* sending power pulses to SoC.
>*/
> - bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
> -
> - skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
> - if (!skb)
> - return -ENOMEM;
> -
> + bt_dev_dbg(hu->hdev, "sending power pulse %02x to SoC", cmd);
> hci_uart_set_flow_control(hu, true);
> + ret = serdev_device_write_buf(hu->serdev, &cmd, sizeof(cmd));
> + if (ret < 0) {
> + bt_dev_err(hu->hdev, "failed to send power pulse %02x to SoC",
> +cmd);
> + return ret;
> + }
As I mentioned earlier, serdev_device_write_buf() can buffer less than
sizeof(cmd) bytes if the tty driver's write buffer is full (and return
the number of bytes buffered).
How you want to deal with that is up to you and the bluetooth
maintainers, but I think you want to at least log it even if you choose
to ignore it.
Johan
Re: [LKP] [lkp-robot] [brd] 316ba5736c: aim7.jobs-per-min -11.2% regression
Hi, All
Do we have special reason to keep this patch (316ba5736c9:brd: Mark as
non-rotational).
which leads to a performance regression when BRD is used as a disk on btrfs.
On 2018/7/10 下午1:27, kemi wrote:
> Hi, SeongJae
> Do you have any input for this regression? thanks
>
> On 2018年06月04日 13:52, kernel test robot wrote:
>>
>> Greeting,
>>
>> FYI, we noticed a -11.2% regression of aim7.jobs-per-min due to commit:
>>
>>
>> commit: 316ba5736c9caa5dbcd84085989862d2df57431d ("brd: Mark as
>> non-rotational")
>> https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git
>> for-4.18/block
>>
>> in testcase: aim7
>> on test machine: 40 threads Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz with
>> 384G memory
>> with following parameters:
>>
>> disk: 1BRD_48G
>> fs: btrfs
>> test: disk_rw
>> load: 1500
>> cpufreq_governor: performance
>>
>> test-description: AIM7 is a traditional UNIX system level benchmark suite
>> which is used to test and measure the performance of multiuser system.
>> test-url: https://sourceforge.net/projects/aimbench/files/aim-suite7/
>>
>>
>>
>> Details are as below:
>> -->
>>
>> =
>> compiler/cpufreq_governor/disk/fs/kconfig/load/rootfs/tbox_group/test/testcase:
>>
>> gcc-7/performance/1BRD_48G/btrfs/x86_64-rhel-7.2/1500/debian-x86_64-2016-08-31.cgz/lkp-ivb-ep01/disk_rw/aim7
>>
>> commit:
>> 522a777566 ("block: consolidate struct request timestamp fields")
>> 316ba5736c ("brd: Mark as non-rotational")
>>
>> 522a777566f56696 316ba5736c9caa5dbcd8408598
>> --
>> %stddev %change %stddev
>> \ |\
>> 28321 -11.2% 25147aim7.jobs-per-min
>> 318.19 +12.6% 358.23aim7.time.elapsed_time
>> 318.19 +12.6% 358.23aim7.time.elapsed_time.max
>>1437526 ± 2% +14.6%1646849 ± 2%
>> aim7.time.involuntary_context_switches
>> 11986 +14.2% 13691aim7.time.system_time
>> 73.06 ± 2% -3.6% 70.43aim7.time.user_time
>>2449470 ± 2% -25.0%1837521 ± 4%
>> aim7.time.voluntary_context_switches
>> 20.25 ± 58% +1681.5% 360.75 ±109% numa-meminfo.node1.Mlocked
>> 456062 -16.3% 381859softirqs.SCHED
>> 9015 ± 7% -21.3% 7098 ± 22% meminfo.CmaFree
>> 47.50 ± 58% +1355.8% 691.50 ± 92% meminfo.Mlocked
>> 5.24 ± 3% -1.23.99 ± 2% mpstat.cpu.idle%
>> 0.61 ± 2% -0.10.52 ± 2% mpstat.cpu.usr%
>> 16627 +12.8% 18762 ± 4% slabinfo.Acpi-State.active_objs
>> 16627 +12.9% 18775 ± 4% slabinfo.Acpi-State.num_objs
>> 57.00 ± 2% +17.5% 67.00vmstat.procs.r
>> 20936 -24.8% 15752 ± 2% vmstat.system.cs
>> 45474-1.7% 44681vmstat.system.in
>> 6.50 ± 59% +1157.7% 81.75 ± 75% numa-vmstat.node0.nr_mlock
>> 242870 ± 3% +13.2% 274913 ± 7% numa-vmstat.node0.nr_written
>> 2278 ± 7% -22.6% 1763 ± 21% numa-vmstat.node1.nr_free_cma
>> 4.75 ± 58% +1789.5% 89.75 ±109% numa-vmstat.node1.nr_mlock
>> 88018135 ± 3% -48.9% 44980457 ± 7% cpuidle.C1.time
>>1398288 ± 3% -51.1% 683493 ± 9% cpuidle.C1.usage
>>3499814 ± 2% -38.5%2153158 ± 5% cpuidle.C1E.time
>> 52722 ± 4% -45.6% 28692 ± 6% cpuidle.C1E.usage
>>9865857 ± 3% -40.1%5905155 ± 5% cpuidle.C3.time
>> 69656 ± 2% -42.6% 39990 ± 5% cpuidle.C3.usage
>> 590856 ± 2% -12.3% 517910cpuidle.C6.usage
>> 46160 ± 7% -53.7% 21372 ± 11% cpuidle.POLL.time
>> 1716 ± 7% -46.6% 916.25 ± 14% cpuidle.POLL.usage
>> 197656+4.1% 205732proc-vmstat.nr_active_file
>> 191867+4.1% 199647proc-vmstat.nr_dirty
>> 509282+1.6% 517318proc-vmstat.nr_file_pages
>> 2282 ± 8% -24.4% 1725 ± 22% proc-vmstat.nr_free_cma
>> 357.50 +10.6% 395.25 ± 2% proc-vmstat.nr_inactive_file
>> 11.50 ± 58% +1397.8% 172.25 ± 93% proc-vmstat.nr_mlock
>> 970355 ± 4% +14.6%549 ± 8% proc-vmstat.nr_written
>> 197984+4.1% 206034proc-vmstat.nr_zone_active_file
>> 357.50 +10.6% 395.25 ± 2%
>> proc-vmstat.nr_zone_inactive_file
>> 192282+4.1% 200126
>> proc-vmstat.nr_zone_write_pending
>>7901465 ± 3% -14.0%6795016 ± 16% proc-vmstat.pgalloc_movable
>> 886101 +10.2% 976329proc-vmstat.pgfault
>> 2.169e+12
Re: [PATCH v2 06/19] mailbox: hi3660: Use device-managed registration API
On Mon, Dec 17, 2018 at 04:02:04PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Get rid of some boilerplate driver removal code by using the newly added
> device-managed registration API.
Tested-by: Leo Yan
> Cc: Kevin Wangtao
> Cc: Kaihua Zhong
> Cc: Ruyi Wang
> Cc: Leo Yan
> Signed-off-by: Thierry Reding
> ---
> drivers/mailbox/hi3660-mailbox.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/mailbox/hi3660-mailbox.c
> b/drivers/mailbox/hi3660-mailbox.c
> index f9aed5d8f9f1..53f4bc2488c5 100644
> --- a/drivers/mailbox/hi3660-mailbox.c
> +++ b/drivers/mailbox/hi3660-mailbox.c
> @@ -265,7 +265,7 @@ static int hi3660_mbox_probe(struct platform_device *pdev)
> for (ch = 0; ch < MBOX_CHAN_MAX; ch++)
> chan[ch].con_priv = (void *)ch;
>
> - err = mbox_controller_register(&mbox->controller);
> + err = devm_mbox_controller_register(dev, &mbox->controller);
> if (err) {
> dev_err(dev, "Failed to register mailbox %d\n", err);
> return err;
> @@ -276,17 +276,8 @@ static int hi3660_mbox_probe(struct platform_device
> *pdev)
> return 0;
> }
>
> -static int hi3660_mbox_remove(struct platform_device *pdev)
> -{
> - struct hi3660_mbox *mbox = platform_get_drvdata(pdev);
> -
> - mbox_controller_unregister(&mbox->controller);
> - return 0;
> -}
> -
> static struct platform_driver hi3660_mbox_driver = {
> .probe = hi3660_mbox_probe,
> - .remove = hi3660_mbox_remove,
> .driver = {
> .name = "hi3660-mbox",
> .of_match_table = hi3660_mbox_of_match,
> --
> 2.19.1
>
Re: [PATCH v2 07/19] mailbox: hi6220: Use device-managed registration API
On Mon, Dec 17, 2018 at 04:02:05PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Get rid of some boilerplate driver removal code by using the newly added
> device-managed registration API.
Reviewed-by: Leo Yan
> Cc: Leo Yan
> Signed-off-by: Thierry Reding
> ---
> drivers/mailbox/hi6220-mailbox.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/mailbox/hi6220-mailbox.c
> b/drivers/mailbox/hi6220-mailbox.c
> index 4fa9803cd204..c32cbfaf223a 100644
> --- a/drivers/mailbox/hi6220-mailbox.c
> +++ b/drivers/mailbox/hi6220-mailbox.c
> @@ -349,7 +349,7 @@ static int hi6220_mbox_probe(struct platform_device *pdev)
> mbox->controller.txpoll_period = 5;
> }
>
> - err = mbox_controller_register(&mbox->controller);
> + err = devm_mbox_controller_register(dev, &mbox->controller);
> if (err) {
> dev_err(dev, "Failed to register mailbox %d\n", err);
> return err;
> @@ -360,14 +360,6 @@ static int hi6220_mbox_probe(struct platform_device
> *pdev)
> return 0;
> }
>
> -static int hi6220_mbox_remove(struct platform_device *pdev)
> -{
> - struct hi6220_mbox *mbox = platform_get_drvdata(pdev);
> -
> - mbox_controller_unregister(&mbox->controller);
> - return 0;
> -}
> -
> static struct platform_driver hi6220_mbox_driver = {
> .driver = {
> .name = "hi6220-mbox",
> @@ -375,7 +367,6 @@ static struct platform_driver hi6220_mbox_driver = {
> .of_match_table = hi6220_mbox_of_match,
> },
> .probe = hi6220_mbox_probe,
> - .remove = hi6220_mbox_remove,
> };
>
> static int __init hi6220_mbox_init(void)
> --
> 2.19.1
>
Re: [PATCH 0/7] ARM: hacks for link-time optimization
On Mon, Dec 17, 2018 at 04:08:00PM -0800, Andi Kleen wrote: > On Mon, Dec 17, 2018 at 11:50:20PM +0100, Peter Zijlstra wrote: > > On Tue, Feb 20, 2018 at 10:59:47PM +0100, Arnd Bergmann wrote: > > > Hi Nico, all, > > > > > > I was playing with ARM link-time optimization handling earlier this > > > month, and eventually got it to build cleanly with randconfig kernels, > > > but ended up with a lot of ugly hacks to actually pull it off. > > > > How are we dealing with the fact that LTO can break RCU in very subtle > > and scary ways? > > > > Do we have a compiler guy on board that has given us a compiler switch > > that kills that optimization (and thereby guarantees that behaviour for > > future compilers etc..) ? > > Can you actually define what optimization you are worred about? > > If there are optimizations that cause problems they likely happen > even without LTO inside files. The only difference with LTO is that it > does them between files too. In particular turning an address-dependency into a control-dependency, which is something allowed by the C language, since it doesn't recognise these concepts as such. The 'optimization' is allowed currently, but LTO will make it much more likely since it will have a much wider view of things. Esp. when combined with PGO. Specifically; if you have something like: int idx; struct object objs[2]; the statement: val = objs[idx & 1].ponies; which you 'need' to be translated like: struct object *obj = objs; obj += (idx & 1); val = obj->ponies; Such that the load of obj->ponies depends on the load of idx. However our dear compiler is allowed to make it: if (idx & 1) obj = &objs[1]; else obj = &objs[0]; val = obj->ponies; Because C doesn't recognise this as being different. However this is utterly broken, because in this translation we can speculate the load of obj->ponies such that it no longer depends on the load of idx, which breaks RCU. Note that further 'optimization' is possible and the compiler could even make it: if (idx & 1) val = objs[1].ponies; else val = objs[0].ponies; Now, granted, this is a fairly artificial example, but it does illustrate the exact problem. The more the compiler can see of the complete program, the more likely it can make inferrences like this, esp. when coupled with PGO. Now, we're (usually) very careful to wrap things in READ_ONCE() and rcu_dereference() and the like, which makes it harder on the compiler (because 'volatile' is special), but nothing really stops it from doing this. Paul has been trying to beat clue into the language people, but given he's been at it for 10 years now, and there's no resolution, I figure we ought to get compiler implementations to give us a knob.
[PATCH] f2fs: fix block address for __check_sit_bitmap
From: Qiuyang Sun Should use lstart (logical start address) instead of start (in dev) here. This fixes a bug in multi-device scenarios. Signed-off-by: Qiuyang Sun --- fs/f2fs/segment.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 204d31e..1a11e7e 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -1150,7 +1150,7 @@ static int __submit_discard_cmd(struct f2fs_sb_info *sbi, list_move_tail(&dc->list, wait_list); /* sanity check on discard range */ - __check_sit_bitmap(sbi, start, start + len); + __check_sit_bitmap(sbi, lstart, lstart + len); bio->bi_private = dc; bio->bi_end_io = f2fs_submit_discard_endio; -- 1.8.3.1
[RFC][PATCH] printk: increase devkmsg write() ratelimit
Hello, RFC A painful subject: I just noticed that stock systemd (no systemd debugging enabled) on my x86 box write()-s during shutdown to devkmsg more than before, so old devkmsg ratelimits do not apply: $ sudo journalctl -n 4 -f | grep "kernel: printk: systemd-shutdow" kernel: printk: systemd-shutdow: 35 output lines suppressed due to ratelimiting kernel: printk: systemd-shutdow: 31 output lines suppressed due to ratelimiting kernel: printk: systemd-shutdow: 35 output lines suppressed due to ratelimiting kernel: printk: systemd-shutdow: 36 output lines suppressed due to ratelimiting kernel: printk: systemd-shutdow: 36 output lines suppressed due to ratelimiting kernel: printk: systemd-shutdow: 36 output lines suppressed due to ratelimiting kernel: printk: systemd-shutdow: 36 output lines suppressed due to ratelimiting kernel: printk: systemd-shutdow: 35 output lines suppressed due to ratelimiting I know that there is a "kernel.printk_devkmsg" interface; do we expect every systemd-enabled distro to find that out and to tweak kernel.printk_devkmsg or shall we change the default devkmsg ratelimit instead? = Every time I reboot my systemd x86_64 box: kernel: printk: systemd-shutdow: 36 output lines suppressed due to ratelimiting Apparently, the default ratelimit - 10 messages max, 5 * HZ interval - is a bit too restrictive these days, can't help it; so increase it to "50 messages, same interval" (which is not awfully a lot). Signed-off-by: Sergey Senozhatsky --- kernel/printk/printk.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 84e54250840a..0ed54f90f208 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -998,7 +998,8 @@ static int devkmsg_open(struct inode *inode, struct file *file) if (!user) return -ENOMEM; - ratelimit_default_init(&user->rs); + ratelimit_state_init(&user->rs, DEFAULT_RATELIMIT_INTERVAL, + 5 * DEFAULT_RATELIMIT_BURST); ratelimit_set_flags(&user->rs, RATELIMIT_MSG_ON_RELEASE); mutex_init(&user->lock); -- 2.20.1
Re: [PATCH v1 03/13] powerpc/mm/32s: rework mmu_mapin_ram()
On 12/18/2018 03:05 AM, Jonathan Neuschäfer wrote: On Mon, Dec 17, 2018 at 10:29:18AM +0100, Christophe Leroy wrote: With patches 1-3: [0.00] setbat(0, c000, , 0100, 311) [0.00] setbat(2, c100, 0100, 0080, 311) [0.00] setbat(4, d000, 1000, 0200, 791) What we see is that BAT0 is not used in the origin. I have always wondered the reason, maybe there is something odd behind and BAT0 shall no ne used. Could you try and modify find_free_bat() so that it starts at b = 1 instead of b = 0 ? In this case, setbat is called with index 2, 3, and 4, but the Wii still doesn't boot. According to arch/powerpc/include/asm/book3s/32/hash.h, - 0x591 = _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT - 0x311 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_COHERENT | _PAGE_PRESENT - 0x791 = _PAGE_RW | _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT Yes, patch 1 added _PAGE_EXEC which explains this 0x200. Do you confirm it still works well with only patch 1 ? Patch 1 alone boots to userspace. Ok, thanks for testing. The only difference I see then are the flags. Everything else is seems identical. I know you tried already, but would you mind trying once more with the following change ? diff --git b/arch/powerpc/mm/ppc_mmu_32.c a/arch/powerpc/mm/ppc_mmu_32.c index 61c10ee00ba2..628fba23 100644 --- b/arch/powerpc/mm/ppc_mmu_32.c +++ a/arch/powerpc/mm/ppc_mmu_32.c @@ -119,7 +119,7 @@ unsigned long __init mmu_mapin_ram(unsigned long base, unsigned long top) if (size < 128 << 10) break; - setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); + setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X); base += size; } I think we may have some code trying to modify the kernel text without using code patching functions. Thanks, Christophe Jonathan
Re: objtool warnings for kernel/trace/trace_selftest_dynamic.o
On Mon, Dec 17, 2018 at 03:59:50PM -0800, Andi Kleen wrote: > BTW I have a user base for LTO and so far noone has reported any issues > like this. Because ordering issues are immediately obvious and easy to debug no doubt.
Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629
On Mon, 2018-12-17 at 15:46 +, Lorenzo Pieralisi wrote: > On Mon, Dec 17, 2018 at 08:32:47AM -0600, Bjorn Helgaas wrote: > > On Mon, Dec 17, 2018 at 04:19:39PM +0800, Jianjun Wang wrote: > > > On Thu, 2018-12-13 at 08:55 -0600, Bjorn Helgaas wrote: > > > > On Thu, Dec 06, 2018 at 09:09:13AM +0800, Jianjun Wang wrote: > > > > > The read value of BAR0 is 0x_, it's size will be calculated > > > > > as 4GB > > > > > in arm64 but bogus alignment values at arm32, the pcie device and > > > > > devices > > > > > behind this bridge will not be enabled. Fix it's BAR0 resource size to > > > > > guarantee the pcie devices will be enabled correctly. > > > > > > > > So this is a hardware erratum? Per spec, a memory BAR has bit 0 > > > > hardwired > > > > to 0, and an IO BAR has bit 1 hardwired to 0. > > > > > > Yes, it only works properly on 64bit platform. > > > > I don't understand. BARs are supposed to work the same regardless of > > whether it's a 32- or 64-bit platform. If this is a workaround for a > > hardware defect, please just say that explicitly. > > I do not understand this either. First thing to do is to describe the > problem properly so that we can actually find a solution to it. > > Lorenzo This BAR0 is a 64-bit memory BAR, the HW default values for this BAR is 0x___ and it could not be changed except by config write operation. The calculated BAR size will be 0 in 32-bit platform since the phys_addr_t is a 32bit value in 32-bit platform. Actually MediaTek's HW does not using this BAR0, just omit it when assign resource is totally fine. When assign the resource for each device, software will check the resource alignment first, and the resource of length zero will be regarded as a bogus alignment resource, it will be ignored and won't claim a resource parent for it. When drivers try to enable the PCIe devices, the software will enable it's resources, but it will return an error number when found a unclaimed resource, in that case, the flow of enable devices will be interrupted and PCIe devices won't work properly. Thanks.
Re: [PATCH v1 1/1] MAINTAINERS: update list of qcom drivers
On 18/12/2018 08:42, Kalle Valo wrote: > Amit Kucheria wrote: > >> Several drivers didn't have a specific maintainer (other than the >> subsystem maintainer). Switch to using the 'qcom' and 'msm' regex >> patterns to capture all of them and add exceptions to the couple of >> drivers that contain 'msm' but are not related to qcom hardware. >> >> Thanks to Marc for the idea to use the N regex. >> >> Signed-off-by: Amit Kucheria >> --- >> MAINTAINERS | 14 -- >> 1 file changed, 4 insertions(+), 10 deletions(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 3318f30903b2..c9376030f77a 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -1929,20 +1929,14 @@ M: Andy Gross >> M: David Brown >> L: linux-arm-...@vger.kernel.org >> S: Maintained >> -F: Documentation/devicetree/bindings/soc/qcom/ >> -F: arch/arm/boot/dts/qcom-*.dts >> -F: arch/arm/boot/dts/qcom-*.dtsi >> -F: arch/arm/mach-qcom/ >> -F: arch/arm64/boot/dts/qcom/* >> +N: qcom >> +N: msm > > IMHO this is pretty fragile in the long term. For example only due to > historical reasons qualcomm wireless drivers currently under ath > directory but who knows if at some point we switch using qcom (or > qualcomm) directory. I am failing to follow your logic. (IIUC, you are talking about drivers/net/wireless/ath/ath10k) The fact that the "qcom" or "msm" nomenclature is not used for this driver now just means that an explicit F entry is required. The fact that it could be renamed in the future just means that the entry would need to be updated or folded into a more generic matching pattern. What am I missing? > Also the wireless drivers might easily have filenames containing > strings like "msm" or "qcom" (which I assume would match with "N" > rules above). Any driver (not just wireless) might match "msm" or "qcom". These could be excluded with an X directive (as the proposed patch does, in fact). Regards.
Re: [PATCH v2] drbd: Avoid Clang warning about pointless switch statment
On Mon, Dec 17, 2018 at 10:29:38AM -0700, Jens Axboe wrote: > > Hi Lars and Philipp, > > > > Could you please make sure that this patch and the other one I sent make > > it into 4.21/5.0? I am not sure when you were planning on sending the > > pull request to Jens that you mentioned in the other thread but I've > > noticed most maintainers typically send their requests for the impending > > merge window around -rc7 or so and I wanted to make sure it was on your > > radar. I'm sorry. >From my point of view, "fixing the pointless switch" is just "pointless", so it (again) fell through. I get it that it is important to others, and getting rid of Clang warnings is a good thing. So sorry again. > It needs to get here now, but drbd hasn't really sent anything in for > about a year, Last actual fix was 2018-06-25 64dafbc9530c drbd: fix access after free so almost six month, yes. > so I'm starting to doubt how maintained it is at this > point. Oh, it is maintained. It is just happens to be "stable". We don't add new features there, and I'm currently not aware of any misbehavior. I'll prepare a pull request containing this, the other Clang warning patch from Nathan, and possibly other small stuff that accumulated, if I can find any, and send that out later today. Thanks for the reminder, Lars
Re: [PATCH 2/2] livepatch: check kzalloc return values
On Fri, 14 Dec 2018, Nicholas Mc Guire wrote:
> kzalloc() return should always be checked - notably in example code
> where this may be seen as reference. On failure of allocation in
> livepatch_fix1_dummy_alloc() respectively dummy_alloc() previous
> allocation is freed (thanks to Petr Mladek for
> catching this) and NULL returned.
>
> Signed-off-by: Nicholas Mc Guire
> Fixes: 439e7271dc2b ("livepatch: introduce shadow variable API")
Applied to for-4.21/upstream, thanks.
--
Jiri Kosina
SUSE Labs
Re: [PATCH 07/14] mm, compaction: Always finish scanning of a full pageblock
On 12/15/18 12:03 AM, Mel Gorman wrote: > When compaction is finishing, it uses a flag to ensure the pageblock is > complete. However, in general it makes sense to always complete migration > of a pageblock. Minimally, skip information is based on a pageblock and > partially scanned pageblocks may incur more scanning in the future. The > pageblock skip handling also becomes more strict later in the series and > the hint is more useful if a complete pageblock was always scanned. > > The impact here is potentially on latencies as more scanning is done > but it's not a consistent win or loss as the scanning is not always a > high percentage of the pageblock and sometimes it is offset by future > reductions in scanning. Hence, the results are not presented this time as > it's a mix of gains/losses without any clear pattern. However, completing > scanning of the pageblock is important for later patches. > > Signed-off-by: Mel Gorman Acked-by: Vlastimil Babka
