date:20201124

This is one of sub-device driver for Advantech embedded controller
AHC1EC0. This driver provide watchdog functionality for Advantech
related applications to restart the system.

Signed-off-by: Shihlun Lin 
---
 drivers/watchdog/Kconfig   |   8 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/ahc1ec0-wdt.c | 489 +
 3 files changed, 498 insertions(+)
 create mode 100644 drivers/watchdog/ahc1ec0-wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index fd7968635e6d..82084e5af35e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1634,6 +1634,14 @@ config NIC7018_WDT
  To compile this driver as a module, choose M here: the module will be
  called nic7018_wdt.
 
+config AHC1EC0_WDT
+   tristate "Advantech EC Watchdog Function"
+   depends on MFD_AHC1EC0
+   help
+ This is sub-device for Advantech embedded controller AHC1EC0. This
+ driver provide watchdog functionality for Advantech related
+ applications to restart the system.
+
 # M68K Architecture
 
 config M54xx_WATCHDOG
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 071a2e50be98..93d15eed1f7c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -145,6 +145,7 @@ obj-$(CONFIG_INTEL_MID_WATCHDOG) += intel-mid_wdt.o
 obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o
 obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
 obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
+obj-$(CONFIG_AHC1EC0_WDT) += ahc1ec0-wdt.o
 obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
 
 # M68K Architecture
diff --git a/drivers/watchdog/ahc1ec0-wdt.c b/drivers/watchdog/ahc1ec0-wdt.c
new file mode 100644
index ..3799b99f6423
--- /dev/null
+++ b/drivers/watchdog/ahc1ec0-wdt.c
@@ -0,0 +1,489 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Watchdog Driver for Advantech controlling EC chip AHC1EC0
+ *
+ * Copyright (C) 2020, Advantech Automation Corp.
+ *
+ * Change Log:
+ * Version 1.00 <10/10/2014> Sun.Lang
+ *- Initial version
+ *  Version 1.01 <12/30/2015> Jiangwei.Zhu
+ *- Modify adv_watchdog_init function to install the driver to
+ *- the support devices.
+ *  Version 1.02 <03/04/2016> Jiangwei.Zhu
+ *- Support UNO-1372G-E3AE, TPC-1782H-433AE, APAX-5580-433AE
+ *  Version 1.03 <05/09/2016> Ji.Xu
+ *- Support EC watchdog mini-board on UNO-3083G/3085G-D44E/D64E
+ *- APAX-5580-473AE/4C3AE.
+ *- Modify the timeout unit to 1 second.
+ *- Modify the device name check method to fuzzy matching.
+ *  Version 1.04 <06/28/2017> Ji.Xu
+ *- Support EC UNO-2271G-E2xAE.
+ *- Support EC UNO-2271G-E02xAE.
+ *- Support EC UNO-2473G-JxAE.
+ *- Support proc filesystem.
+ *  Version 1.05 <09/20/2017> Ji.Xu
+ *- Support EC UNO-2484G-633xAE.
+ *- Support EC UNO-2484G-653xAE.
+ *- Support EC UNO-2484G-673xAE.
+ *- Support EC UNO-2484G-733xAE.
+ *- Support EC UNO-2484G-753xAE.
+ *- Support EC UNO-2484G-773xAE.
+ *  Version 1.06 <10/26/2017> Ji.Xu
+ *- Support EC UNO-3283G-674AE
+ *- Support EC UNO-3285G-674AE
+ *  Version 1.07 <11/16/2017> Zhang.Yang
+ *- Support EC UNO-1372G-J021AE/J031AE
+ *- Support EC UNO-2372G
+ *  Version 1.08 <02/02/2018> Ji.Xu
+ *- Support EC TPC-B500-6??AE
+ *- Support EC TPC-5???T-6??AE
+ *- Support EC TPC-5???W-6??AE
+ *  Version 1.09 <03/20/2018> Ji.Xu
+ *- Support for compiling in kernel-4.10 and below.
+ *  Version 1.10 <02/20/2019> Ji.Xu
+ *- Support EC UNO-420
+ *- Support EC TPC-B200-???AE
+ *- Support EC TPC-2???T-???AE
+ *- Support EC TPC-2???W-???AE
+ *  Version 1.11 <08/30/2019> Yao.Kang
+ *   - Support 32-bit programs on 64-bit kernel
+ *  Version 1.12 <12/03/2019> Jianfeng.dai
+ *   - Support support UNO-2372G watchdog
+ *  Version 1.13 <04/24/2020> Yao.Kang
+ *   - Support support UNO-2473G
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADVANTECH_EC_WDT_VER"1.12"
+#define ADVANTECH_EC_WDT_DATE   "04/24/2020"
+
+#define PROCFS_MAX_SIZE 128
+
+static char adv_expect_close;
+static unsigned long advwdt_is_open;
+static unsigned short timeout = 450;
+static unsigned int major;
+struct mutex lock_ioctl;
+
+struct adv_wdt_info {
+   unsigned char chip_name[32];
+   unsigned char is_enable[8];
+   unsigned long current_timeout;
+};
+
+static struct adv_wdt_info wdt_data = {
+   .chip_name = "Advantech Embedded Controller",
+   .is_enable = "No",
+   .current_timeout = 45,
+};
+
+static int wdt_proc_read(struct seq_file *m, void *p);
+
+static void

[RESEND PATCH v4 4/6] mfd: ahc1ec0: Add support for Advantech embedded controller

AHC1EC0 is the embedded controller driver for Advantech industrial
products. This provides sub-devices such as hwmon and watchdog, and also
expose functions for sub-devices to read/write the value to embedded
controller.

Signed-off-by: Shihlun Lin 
---
 drivers/mfd/Kconfig |   10 +
 drivers/mfd/Makefile|2 +
 drivers/mfd/ahc1ec0.c   | 1405 +++
 include/linux/mfd/ahc1ec0.h |  338 +
 4 files changed, 1755 insertions(+)
 create mode 100644 drivers/mfd/ahc1ec0.c
 create mode 100644 include/linux/mfd/ahc1ec0.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8b99a13669bf..1cc40217f798 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2166,5 +2166,15 @@ config MFD_INTEL_M10_BMC
  additional drivers must be enabled in order to use the functionality
  of the device.
 
+config MFD_AHC1EC0
+   tristate "Advantech Embedded Controller Module"
+   depends on X86
+   select MFD_CORE
+   help
+ This is the core function that for Advantech EC drivers. It
+ includes the sub-devices such as hwmon, watchdog, etc. And also
+ provides expose functions for sub-devices to read/write the value
+ to embedded controller.
+
 endmenu
 endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 1780019d2474..80a9a2bdc3ba 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -267,3 +267,5 @@ obj-$(CONFIG_MFD_KHADAS_MCU)+= khadas-mcu.o
 obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
 obj-$(CONFIG_MFD_SIMPLE_MFD_I2C)   += simple-mfd-i2c.o
 obj-$(CONFIG_MFD_INTEL_M10_BMC)   += intel-m10-bmc.o
+
+obj-$(CONFIG_MFD_AHC1EC0)  += ahc1ec0.o
diff --git a/drivers/mfd/ahc1ec0.c b/drivers/mfd/ahc1ec0.c
new file mode 100644
index ..768d2063bed1
--- /dev/null
+++ b/drivers/mfd/ahc1ec0.c
@@ -0,0 +1,1405 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Base driver for Advantech controlling EC chip AHC1EC0
+ *
+ * Copyright (C) 2020, Advantech Automation Corp.
+ *
+ * Change Log:
+ *  Version 1.00 <10/10/2014> Sun.Lang
+ *  - Initial version
+ *  Version 1.01 <11/05/2015> Jiangwei.Zhu
+ *  - Modify read_ad_value() function.
+ *  - Add smbus_read_byte() function.
+ *  - Add smbus_write_byte() function.
+ *  - Add wait_smbus_protocol_finish() function.
+ *  Version 1.02 <03/04/2016> Jiangwei.Zhu
+ *  - Add smbus_read_word() function.
+ *  Version 1.03 <01/22/2017> Ji.Xu
+ *  - Add detect to Advantech porduct name "ECU".
+ *  Version 1.04 <09/20/2017> Ji.Xu
+ *  - Update to support detect Advantech product name in UEFI
+ *BIOS(DMI).
+ *  Version 1.05 <11/02/2017> Ji.Xu
+ *  - Fixed issue: Cache coherency error when exec 
'ioremap_uncache()'
+ *in kernel-4.10.
+ *  Version 2.00 <11/04/2020> Shihlun.Lin
+ *  - Update: Replace ioremap_nocache() with ioremap_uc() since
+ *ioremap_uc() was used on the entire PCI BAR.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADVANTECH_EC_NAME  "ahc1ec0"
+#define ADVANTECH_EC_MFD_VER"2.0.0"
+#define ADVANTECH_EC_MFD_DATE   "11/04/2020"
+
+struct mutex lock;
+
+enum {
+   ADVEC_SUBDEV_BRIGHTNESS = 0,
+   ADVEC_SUBDEV_EEPROM,
+   ADVEC_SUBDEV_GPIO,
+   ADVEC_SUBDEV_HWMON,
+   ADVEC_SUBDEV_LED,
+   ADVEC_SUBDEV_WDT,
+   ADVEC_SUBDEV_MAX,
+};
+
+static int wait_ibf(void)
+{
+   int i;
+
+   for (i = 0; i < EC_MAX_TIMEOUT_COUNT; i++) {
+   if ((inb(EC_COMMAND_PORT) & 0x02) == 0)
+   return 0;
+
+   udelay(EC_UDELAY_TIME);
+   }
+
+   return -ETIMEDOUT;
+}
+
+/* Wait OBF (Output buffer full) set */
+static int wait_obf(void)
+{
+   int i;
+
+   for (i = 0; i < EC_MAX_TIMEOUT_COUNT; i++) {
+   if ((inb(EC_COMMAND_PORT) & 0x01) != 0)
+   return 0;
+
+   udelay(EC_UDELAY_TIME);
+   }
+
+   return -ETIMEDOUT;
+}
+
+/* Read data from EC HW ram */
+static int read_hw_ram(uchar addr, uchar *data)
+{
+   int ret;
+
+   mutex_lock();
+
+   /* Step 0. Wait IBF clear */
+   ret = wait_ibf();
+   if (ret)
+   goto error;
+
+   /* Step 1. Send "read EC HW ram" command to EC Command port */
+   outb(EC_HW_RAM_READ, EC_COMMAND_PORT);
+
+   /* Step 2. Wait IBF clear */
+   ret = wait_ibf();
+   if (ret)
+   goto error;
+
+   /* Step 3. Send "EC HW ram" address to EC Data port */
+   outb(addr, EC_STATUS_PORT);
+
+   /* Step 4. Wait OBF set */
+   ret = wait_obf();
+   if (ret)
+   goto error;
+
+   /* Step 5. Get "EC HW ram"

[RESEND PATCH v4 3/6] dt-bindings: mfd: ahc1ec0.yaml: Add Advantech embedded controller - AHC1EC0

Add DT binding schema for Advantech embedded controller AHC1EC0.

Signed-off-by: Shihlun Lin 
---
 .../devicetree/bindings/mfd/ahc1ec0.yaml  | 70 +++
 1 file changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/ahc1ec0.yaml

diff --git a/Documentation/devicetree/bindings/mfd/ahc1ec0.yaml 
b/Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
new file mode 100644
index ..a73d1cf65a4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ahc1ec0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech Embedded Controller (AHC1EC0)
+
+maintainers:
+  - Shihlun Lin 
+  - Campion Kang 
+
+description: |
+  AHC1EC0 is one of the embedded controllers used by Advantech to provide 
several
+  functions such as watchdog, hwmon, brightness, etc. Advantech related 
applications
+  can control the whole system via these functions.
+
+properties:
+  compatible:
+const: advantech,ahc1ec0
+
+  advantech,sub-dev-nb:
+description:
+  The number of sub-devices specified in the platform.
+$ref: /schemas/types.yaml#/definitions/uint32
+maxItems: 1
+
+  advantech,sub-dev:
+description:
+  A list of the sub-devices supported in the platform. Defines for the
+  appropriate values can found in dt-bindings/mfd/ahc1ec0.h.
+$ref: "/schemas/types.yaml#/definitions/uint32-array"
+minItems: 1
+maxItems: 6
+
+  advantech,hwmon-profile:
+description:
+  The number of sub-devices specified in the platform. Defines for the
+  hwmon profiles can found in dt-bindings/mfd/ahc1ec0.
+$ref: /schemas/types.yaml#/definitions/uint32
+maxItems: 1
+
+required:
+  - compatible
+  - advantech,sub-dev-nb
+  - advantech,sub-dev
+
+if:
+  properties:
+advantech,sub-dev:
+  contains:
+const: 0x3
+then:
+  required:
+- advantech,hwmon-profile
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+ahc1ec0 {
+compatible = "advantech,ahc1ec0";
+
+advantech,sub-dev-nb = <2>;
+advantech,sub-dev = ;
+
+advantech,hwmon-profile = ;
+};
-- 
2.17.1

[RESEND PATCH v4 1/6] MAINTAINERS: Add Advantech embedded controller entry

Add Advantech embedded controller entry

Signed-off-by: Shihlun Lin 
---
 MAINTAINERS | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 94ac10a153c7..c1fe5233b469 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -562,6 +562,17 @@ S: Maintained
 F: Documentation/scsi/advansys.rst
 F: drivers/scsi/advansys.c
 
+ADVANTECH EMBEDDED CONTROLLER DRIVER
+M: Shihlun Lin 
+M: Campion Kang 
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
+F: drivers/mfd/ahc1ec0-hwmon.c
+F: drivers/mfd/ahc1ec0-wdt.c
+F: drivers/mfd/ahc1ec0.c
+F: include/dt-bindings/mfd/ahc1ec0.h
+
 ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346)
 M: Michael Hennerich 
 S: Supported

base-commit: 3d5e28bff7ad55aea081c1af516cc1c94a5eca7d
-- 
2.17.1

RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken

2020-11-24 Thread Merger, Edgar [AUTOSOL/MAS/AUGS]

I see that problem only on systems that use a R1305G APU

sudo cat /sys/kernel/debug/dri/0/amdgpu_firmware_info

shows

VCE feature version: 0, firmware version: 0x
UVD feature version: 0, firmware version: 0x
MC feature version: 0, firmware version: 0x
ME feature version: 50, firmware version: 0x00a3
PFP feature version: 50, firmware version: 0x00bb
CE feature version: 50, firmware version: 0x004f
RLC feature version: 1, firmware version: 0x0049
RLC SRLC feature version: 1, firmware version: 0x0001
RLC SRLG feature version: 1, firmware version: 0x0001
RLC SRLS feature version: 1, firmware version: 0x0001
MEC feature version: 50, firmware version: 0x01b5
MEC2 feature version: 50, firmware version: 0x01b5
SOS feature version: 0, firmware version: 0x
ASD feature version: 0, firmware version: 0x2130
TA XGMI feature version: 0, firmware version: 0x
TA RAS feature version: 0, firmware version: 0x
SMC feature version: 0, firmware version: 0x2527
SDMA0 feature version: 41, firmware version: 0x00a9
VCN feature version: 0, firmware version: 0x0110901c
DMCU feature version: 0, firmware version: 0x0001
VBIOS version: 113-RAVEN2-117

We are also using V1404I APU on the same boards and I haven´t seen the issue on 
those boards

These boards give me slightly different info: sudo cat 
/sys/kernel/debug/dri/0/amdgpu_firmware_info
 
VCE feature version: 0, firmware version: 0x
UVD feature version: 0, firmware version: 0x
MC feature version: 0, firmware version: 0x
ME feature version: 47, firmware version: 0x00a2
PFP feature version: 47, firmware version: 0x00b9
CE feature version: 47, firmware version: 0x004e
RLC feature version: 1, firmware version: 0x0213
RLC SRLC feature version: 1, firmware version: 0x0001
RLC SRLG feature version: 1, firmware version: 0x0001
RLC SRLS feature version: 1, firmware version: 0x0001
MEC feature version: 47, firmware version: 0x01ab
MEC2 feature version: 47, firmware version: 0x01ab
SOS feature version: 0, firmware version: 0x
ASD feature version: 0, firmware version: 0x2113
TA XGMI feature version: 0, firmware version: 0x
TA RAS feature version: 0, firmware version: 0x
SMC feature version: 0, firmware version: 0x1e5b
SDMA0 feature version: 41, firmware version: 0x00a9
VCN feature version: 0, firmware version: 0x0110901c
DMCU feature version: 0, firmware version: 0x
VBIOS version: 113-RAVEN-116




00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root 
Complex
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 
00h-1fh) PCIe Dummy Host Bridge
00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP 
Bridge [6:0]
00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Zeppelin Switch Upstream 
(PCIE SW.US)
00:01.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP 
Bridge [6:0]
00:01.5 PCI bridge: Advanced Micro Devices, Inc. [AMD] Zeppelin Switch Upstream 
(PCIE SW.US)
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 
00h-1fh) PCIe Dummy Host Bridge
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal 
PCIe GPP Bridge 0 to Bus A
00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal 
PCIe GPP Bridge 0 to Bus B
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: 
Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: 
Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: 
Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: 
Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: 
Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: 
Function 5
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: 
Function 6
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: 
Function 7
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 
PCI Express Gigabit Ethernet Controller (rev 0e)
01:00.1 Serial controller: Realtek Semiconductor Co., Ltd. Device 816a (rev 0e)
01:00.2 Serial controller: Realtek Semiconductor Co., Ltd. Device 816b (rev 0e)
01:00.3 IPMI Interface: Realtek Semiconductor Co., Ltd. Device 816c (rev 0e)
01:00.4 USB controller: Realtek Semiconductor Co., Ltd. Device 816d (rev 0e)
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection 
(rev 03)
03:00.0 PCI bridge: Pericom Semiconductor PI7C9X2G608GP PCIe2

[rcu:for-mingo] BUILD SUCCESS 50df51d12c3175573de9c94968639bdd625ec549

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  for-mingo
branch HEAD: 50df51d12c3175573de9c94968639bdd625ec549  Merge branch 
'lkmm.2020.11.06a' into HEAD

elapsed time: 727m

configs tested: 154
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
powerpc  tqm8xx_defconfig
m68k   m5475evb_defconfig
mips   jazz_defconfig
c6xevmc6474_defconfig
powerpc  makalu_defconfig
sh ap325rxa_defconfig
arm at91_dt_defconfig
m68kmvme147_defconfig
shdreamcast_defconfig
powerpc kmeter1_defconfig
m68k   m5249evb_defconfig
sparcalldefconfig
arm  colibri_pxa270_defconfig
arm  ixp4xx_defconfig
arc haps_hs_smp_defconfig
mipsar7_defconfig
arm lubbock_defconfig
parisc   allyesconfig
shsh7757lcr_defconfig
arcvdk_hs38_defconfig
powerpc  pasemi_defconfig
mips db1xxx_defconfig
arm  prima2_defconfig
powerpc  storcenter_defconfig
arm ezx_defconfig
arm   aspeed_g4_defconfig
powerpcge_imp3a_defconfig
mips   ip27_defconfig
powerpcsocrates_defconfig
sh   se7724_defconfig
powerpc mpc8313_rdb_defconfig
s390 alldefconfig
sh sh7710voipgw_defconfig
armpleb_defconfig
x86_64   alldefconfig
armneponset_defconfig
shmigor_defconfig
s390defconfig
mips  maltaaprp_defconfig
parisc   alldefconfig
mips  rm200_defconfig
sh   sh7770_generic_defconfig
powerpcgamecube_defconfig
armtrizeps4_defconfig
powerpc mpc836x_mds_defconfig
arm   imx_v4_v5_defconfig
arm ebsa110_defconfig
powerpcfsp2_defconfig
mipsmalta_kvm_guest_defconfig
powerpc  ep88xc_defconfig
mips  ath25_defconfig
microblaze  defconfig
powerpc mpc834x_mds_defconfig
arcnsimosci_defconfig
powerpc  walnut_defconfig
powerpc sbc8548_defconfig
sh  rsk7203_defconfig
mips cu1000-neo_defconfig
arm   milbeaut_m10v_defconfig
armshmobile_defconfig
sh   j2_defconfig
pariscgeneric-64bit_defconfig
ia64zx1_defconfig
sh  ul2_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a004-20201124
i386

Re: [PATCH v4 1/2] usb: typec: Consolidate sysfs ABI documentation

2020-11-24 Thread Heikki Krogerus

On Tue, Nov 24, 2020 at 12:32:35PM -0800, Prashant Malani wrote:
> Hi,
> 
> On Tue, Nov 24, 2020 at 12:10:31PM -0800, Prashant Malani wrote:
> > Both partner and cable have identity VDOs. These are listed separately
> > in the Documentation/ABI/testing/sysfs-class-typec. Factor these out
> > into a common location to avoid the duplication.
> > 
> > Signed-off-by: Prashant Malani 
> > Acked-by: Heikki Krogerus 
> I copied the Acked-by line from v3 [1] as is, but looks like there was a
> typo there and the email address should be
> "heikki.kroge...@linux.intel.com".
> 
> Please let me know if it's fine as is or whether I should send another
> patchset.

It is fine. Thanks for taking care of that :-)

Br,

> [1]
> https://lore.kernel.org/linux-usb/20201110105225.gh1224...@kuha.fi.intel.com/

Br,

-- 
heikki

[rcu:for-mingo-rcu] BUILD SUCCESS 7fc91fc8450655e7ba941d61663afcaf65cefb78

 allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20201124
x86_64   randconfig-a003-20201124
x86_64   randconfig-a004-20201124
x86_64   randconfig-a005-20201124
x86_64   randconfig-a001-20201124
x86_64   randconfig-a002-20201124
i386 randconfig-a004-20201124
i386 randconfig-a003-20201124
i386 randconfig-a002-20201124
i386 randconfig-a005-20201124
i386 randconfig-a001-20201124
i386 randconfig-a006-20201124
i386 randconfig-a004-20201125
i386 randconfig-a003-20201125
i386 randconfig-a002-20201125
i386 randconfig-a005-20201125
i386 randconfig-a001-20201125
i386 randconfig-a006-20201125
x86_64   randconfig-a015-20201125
x86_64   randconfig-a011-20201125
x86_64   randconfig-a014-20201125
x86_64   randconfig-a016-20201125
x86_64   randconfig-a012-20201125
x86_64   randconfig-a013-20201125
i386 randconfig-a012-20201124
i386 randconfig-a013-20201124
i386 randconfig-a011-20201124
i386 randconfig-a016-20201124
i386 randconfig-a014-20201124
i386 randconfig-a015-20201124
i386 randconfig-a012-20201125
i386 randconfig-a013-20201125
i386 randconfig-a011-20201125
i386 randconfig-a016-20201125
i386 randconfig-a014-20201125
i386 randconfig-a015-20201125
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a006-20201125
x86_64   randconfig-a003-20201125
x86_64   randconfig-a004-20201125
x86_64   randconfig-a005-20201125
x86_64   randconfig-a002-20201125
x86_64   randconfig-a001-20201125
x86_64   randconfig-a015-20201124
x86_64   randconfig-a011-20201124
x86_64   randconfig-a014-20201124
x86_64   randconfig-a016-20201124
x86_64   randconfig-a012-20201124
x86_64   randconfig-a013-20201124

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [RFC PATCH v3.1 00/27] Add support UHS-II for GL9755

2020-11-24 Thread AKASHI Takahiro

Gentle ping;

On Fri, Nov 06, 2020 at 11:26:59AM +0900, AKASHI Takahiro wrote:
> This is an interim snapshot of our next version, v4, for enabling
> UHS-II on MMC/SD.
> 
> It is focused on 'sdhci' side to address Adrian's comments regarding
> "modularising" sdhci-uhs2.c.
> The whole aim of this version is to get early feedback from Adrian (and
> others) on this issue. Without any consensus about the code structure,

Any comments so far?

-Takahiro Akashi

> it would make little sense to go further ahead on sdhci side.
> (Actually, Adrian has made no comments other than "modularising" so far.)
> 
> I heavily reworked/refactored sdhci-uhs2.c and re-organised the patch
> set to meet what I believe Adrian expects; no UHS-II related code in
> Legacy (UHS-I) code or sdhci.c.
> 
> Nevertheless, almost of all changes I made are trivial and straightforward
> in this direction, and I believe that there is no logic changed since v3
> except sdhci_uhs2_irq(), as ops->irq hook, where we must deal with UHS-II
> command sequences in addition to UHS-II errors. So I added extra handlings.
> 
> I admit that there is plenty of room for improvements (for example,
> handling host->flags), but again the focal point here is how sdhci-uhs2.c
> should be built as a module.
> 
> Please review this series (particularly Patch#8-#26 and #27) from this
> viewpoint in the first place.
> (Ben is working on 'host' side but there is no change on 'host' side
> in this submission except a minor tweak.)
> 
> Thanks,
> -Takahiro Akashi
> 
> -- original cover letter from v3 --
> Summary
> ===
> These patches[1] support UHS-II and fix GL9755 UHS-II compatibility.
> 
> About UHS-II, roughly deal with the following three parts:
> 1) A UHS-II detection and initialization:
> - Host setup to support UHS-II (Section 3.13.1 Host Controller Setup Sequence
>   [2]).
> - Detect a UHS-II I/F (Section 3.13.2 Card Interface Detection Sequence[2]).
> - In step(9) of Section 3.13.2 in [2], UHS-II initialization is include 
> Section
>   3.13.3 UHS-II Card Initialization and Section 3.13.4 UHS-II Setting Register
>   Setup Sequence.
> 
> 2) Send Legacy SD command through SD-TRAN
> - Encapsulated SD packets are defined in SD-TRAN in order to ensure Legacy SD
>   compatibility and preserve Legacy SD infrastructures (Section 7.1.1 Packet
>   Types and Format Overview[3]).
> - Host issue a UHS-II CCMD packet or a UHS-II DCMD (Section 3.13.5 UHS-II
>   CCMD Packet issuing and Section 3.13.6 UHS-II DCMD Packet issuing[2]).
> 
> 3) UHS-II Interrupt
> - Except for UHS-II error interrupts, most interrupts share the original
>   interrupt registers.
> 
> Patch structure
> ===
> patch#1-#7: for core
> patch#8-#17: for sdhci
> patch#18-#21: for GL9755
> 
> Tests
> =
> Ran 'dd' command to evaluate the performance:
> (SanDisk UHS-II card on GL9755 controller)
>  ReadWrite
> UHS-II disabled (UHS-I): 88.3MB/s 60.7MB/s
> UHS-II enabled :  206MB/s   80MB/s
> 
> TODO
> 
> - replace some define with BIT macro
> 
> Reference
> =
> [1] https://gitlab.com/ben.chuang/linux-uhs2-gl9755.git
> [2] SD Host Controller Simplified Specification 4.20
> [3] UHS-II Simplified Addendum 1.02
> 
> Changes in v3 (Jul. 10, 2020)
> * rebased to v5.8-rc4
> * add copyright notice
> * reorganize the patch set and split some commits into smaller ones
> * separate uhs-2 headers from others
> * correct wrong spellings
> * fix most of checkpatch warnings/errors
> * remove all k[cz]alloc() from the code
> * guard sdhci-uhs2 specific code with
>   'if (IS_ENABLED(CONFIG_MMC_SDHCI_UHS2))'
> * make sdhci-uhs2.c as a module
> * trivial changes, including
>   - rename back sdhci-core.c to sdhci.c
>   - allow vendor code to disable uhs2 if v4_mode == 0
>   in __sdhci_add_host()
>   - merge uhs2_power_up() into mmc_power_up()
>   - remove flag_uhs2 from mmc_attach_sd()
>   - add function descriptions to EXPORT'ed functions
>   - other minor code optimization
> 
> Changes in v2 (Jan. 9, 2020)
> * rebased to v5.5-rc5
> 
> AKASHI Takahiro (23):
>   mmc: core: UHS-II support, modify power-up sequence
>   mmc: core: UHS-II support, skip set_chip_select()
>   mmc: core: UHS-II support, skip TMODE setup in some cases
>   mmc: core: UHS-II support, generate UHS-II SD command packet
>   mmc: core: UHS-II support, set APP_CMD bit if necessary
>   mmc: sdhci: add a kernel configuration for enabling UHS-II support
>   mmc: sdhci: add UHS-II related definitions in headers
>   mmc: sdhci: add UHS-II module
>   mmc: sdhci-uhs2: dump UHS-II registers
>   mmc: sdhci-uhs2: add reset function
>   mmc: sdhci-uhs2: add set_power() to support vdd2
>   mmc: sdhci-uhs2: skip signal_voltage_switch()
>   mmc: sdhci-uhs2: add set_timeout()
>   mmc: sdhci-uhs2: add set_ios()
>   mmc: sdhci-uhs2: add detect_init() to detect the interface
>   mmc: sdhci-uhs2: add clock operations
>   mmc: sdhci-uhs2: add set_reg() to initialise the interface
>   mmc:

[PATCH v2] phy: mediatek: Make PHY_MTK_{XSPHY,TPHY} depend on HAS_IOMEM and OF_ADDRESS to fix build errors

2020-11-24 Thread Tiezhu Yang

devm_ioremap_resource() will be not built in lib/devres.c if
CONFIG_HAS_IOMEM is not set, of_address_to_resource() will be
not built in drivers/of/address.c if CONFIG_OF_ADDRESS is not
set, and then there exists two build errors about undefined
reference to "devm_ioremap_resource" and "of_address_to_resource"
in phy-mtk-xsphy.c under COMPILE_TEST and CONFIG_PHY_MTK_XSPHY,
make PHY_MTK_XSPHY depend on HAS_IOMEM and OF_ADDRESS to fix it.

The above issue is reported by kernel test robot ,
through the discussion in the v1 patch, as Chunfeng said we need
also do this for config PHY_MTK_TPHY:

drivers/phy/mediatek/phy-mtk-tphy.c:1157:   retval = 
of_address_to_resource(child_np, 0, );
drivers/phy/mediatek/phy-mtk-tphy.c:1123:   tphy->sif_base = 
devm_ioremap_resource(dev, sif_res);
drivers/phy/mediatek/phy-mtk-tphy.c:1164:   instance->port_base = 
devm_ioremap_resource(>dev, );

Reported-by: kernel test robot 
Signed-off-by: Tiezhu Yang 
Acked-by: Randy Dunlap 
---
 drivers/phy/mediatek/Kconfig | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index 50c5e93..f44800b 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -5,7 +5,8 @@
 config PHY_MTK_TPHY
tristate "MediaTek T-PHY Driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on OF
+   depends on OF && OF_ADDRESS
+   depends on HAS_IOMEM
select GENERIC_PHY
help
  Say 'Y' here to add support for MediaTek T-PHY driver,
@@ -29,7 +30,8 @@ config PHY_MTK_UFS
 config PHY_MTK_XSPHY
tristate "MediaTek XS-PHY Driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on OF
+   depends on OF && OF_ADDRESS
+   depends on HAS_IOMEM
select GENERIC_PHY
help
  Enable this to support the SuperSpeedPlus XS-PHY transceiver for
-- 
2.1.0

Re: [PATCH net-next 1/2] dt-bindings: net: nfc: s3fwrn5: Support a UART interface

2020-11-24 Thread Krzysztof Kozlowski

On Wed, 25 Nov 2020 at 04:08, Bongsu Jeon  wrote:
>
> On 11/24/20, k...@kernel.org  wrote:
> > On Tue, Nov 24, 2020 at 08:39:40PM +0900, Bongsu Jeon wrote:
> >> On Mon, Nov 23, 2020 at 5:02 PM k...@kernel.org  wrote:
> >> >
> >> > On Mon, Nov 23, 2020 at 04:55:26PM +0900, Bongsu Jeon wrote:
> >  > >  examples:
> >> > >- |
> >> > >  #include 
> >> > > @@ -71,3 +81,17 @@ examples:
> >> > >  wake-gpios = < 2 GPIO_ACTIVE_HIGH>;
> >> > >  };
> >> > >  };
> >> > > +  # UART example on Raspberry Pi
> >> > > +  - |
> >> > > + {
> >> > > +status = "okay";
> >> > > +
> >> > > +s3fwrn82_uart {
> >> >
> >> > Just "bluetooth" to follow Devicetree specification.
> >> Sorry. I don't understand this comment.
> >> Could you explain it?
> >> Does it mean i need to refer to the net/broadcom-bluetooth.txt?
> >
> > The node name should be "bluetooth", not "s3fwrn82_uart", because of
> > Devicetree naming convention - node names should represent generic class
> > of a device.
> >
> Actually, RN82 is the nfc device.
> So, is it okay to use the name as nfc instead of Bluetooth?

Oops, of course, nfc, I don't know why the Bluetooth stuck in my mind.

Best regards,
Krzysztof

Re: [RFC] perf/x86: Fix a warning on x86_pmu_stop()

2020-11-24 Thread Peter Zijlstra

On Tue, Nov 24, 2020 at 12:19:34AM -0800, Stephane Eranian wrote:
> Hi,
> 
> Another remark on the PEBS drainage code, it seems to me like a test
> is not quite correct:
> intel_pmu_drain_pebs_nhm()
> {
> ...
>if (p->status != (1ULL << bit)) {
> for_each_set_bit(i, (unsigned long *)_status, 
> size)
> error[i]++;
> continue;
> }
> 
> The kernel cannot disambiguate when 2+ PEBS counters overflow at the
> same time. This is what the comment for this code suggests.
> However, I see the comparison is done with the unfiltered p->status
> which is a copy of  IA32_PERF_GLOBAL_STATUS at the time of
> the sample. This register contains more than the PEBS counter overflow
> bits. It also includes many other bits which could also be set.
> 
> Shouldn't this test use pebs_status instead (which covers only the
> PEBS counters)?

Hmm, yes, think so.

[PATCH v2] mtd: physmap: physmap-bt1-rom: Fix __iomem addrspace removal warning

2020-11-24 Thread Serge Semin

sparse is unhappy with us casting the __iomem address space pointer to
a type with no address space attribute specified:

"sparse warnings: (new ones prefixed by >>)"
>> drivers/mtd/maps/physmap-bt1-rom.c:78:18: sparse: sparse: cast removes 
>> address space '__iomem' of expression

Indeed we perform the __iomem-less type casting but to an integer
variable. The integer variable isn't dereferenced then, so the casting is
safe and won't cause any problem. But in order to make sparse happy and
keep the code coherent let's fix the warning by converting the local
"shift" and "chunk" variables to the "unsigned int" type (since their
value won't ever exceed three) and cast the __iomem-pointers to uintptr_t.
Add the same fix to the bt1_rom_map_read() method for unification.

Fixes: b3e79e7682e0 ("mtd: physmap: Add Baikal-T1 physically mapped ROM 
support")
Link: https://lore.kernel.org/lkml/202011021254.xc70baqt-...@intel.com/
Signed-off-by: Serge Semin 
Reported-by: kernel test robot 
Cc: Alexey Malahov 
Cc: Pavel Parkhomenko 

---

Link: https://lore.kernel.org/lkml/20201120113929.0aff2...@canb.auug.org.au/
Changelog v2:
- Cast the pointers to uintptr_t instead of unsiged int so not to
  cause the "cast from pointer to integer of different size" warning on
  64-bits platforms.
---
 drivers/mtd/maps/physmap-bt1-rom.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/maps/physmap-bt1-rom.c 
b/drivers/mtd/maps/physmap-bt1-rom.c
index 27cfe1c63a2e..a35450002284 100644
--- a/drivers/mtd/maps/physmap-bt1-rom.c
+++ b/drivers/mtd/maps/physmap-bt1-rom.c
@@ -31,12 +31,12 @@ static map_word __xipram bt1_rom_map_read(struct map_info 
*map,
  unsigned long ofs)
 {
void __iomem *src = map->virt + ofs;
-   unsigned long shift;
+   unsigned int shift;
map_word ret;
u32 data;
 
/* Read data within offset dword. */
-   shift = (unsigned long)src & 0x3;
+   shift = (uintptr_t)src & 0x3;
data = readl_relaxed(src - shift);
if (!shift) {
ret.x[0] = data;
@@ -60,7 +60,7 @@ static void __xipram bt1_rom_map_copy_from(struct map_info 
*map,
   ssize_t len)
 {
void __iomem *src = map->virt + from;
-   ssize_t shift, chunk;
+   unsigned int shift, chunk;
u32 data;
 
if (len <= 0 || from >= map->size)
@@ -75,7 +75,7 @@ static void __xipram bt1_rom_map_copy_from(struct map_info 
*map,
 * up into the next three stages: unaligned head, aligned body,
 * unaligned tail.
 */
-   shift = (ssize_t)src & 0x3;
+   shift = (uintptr_t)src & 0x3;
if (shift) {
chunk = min_t(ssize_t, 4 - shift, len);
data = readl_relaxed(src - shift);
-- 
2.29.2

Re: [PATCH v6 4/4] soc: imx8m: change to use platform driver

2020-11-24 Thread Krzysztof Kozlowski

On Wed, 25 Nov 2020 at 01:44, Adam Ford  wrote:
>
> On Mon, Nov 23, 2020 at 8:04 PM Alice Guo  wrote:
> >
> > Directly reading ocotp register depends on that bootloader enables ocotp
> > clk, which is not always effective, so change to use nvmem API. Using
> > nvmem API requires to support driver defer probe and thus change
> > soc-imx8m.c to use platform driver.
> >
> > The other reason is that directly reading ocotp register causes kexec
> > kernel hang because the 1st kernel running will disable unused clks
> > after kernel boots up, and then ocotp clk will be disabled even if
> > bootloader enables it. When kexec kernel, ocotp clk needs to be enabled
> > before reading ocotp registers, and nvmem API with platform driver
> > supported can accomplish this.
> >
> > Signed-off-by: Alice Guo 
> > ---
> >
> The patch reads V6, but the change log only shows V2.  Can you
> elaborate on what has changed between V2 and V6?
>
> adam
>
> > v2: remove the subject prefix "LF-2571-4"
> > v3: Keep the original way which uses device_initcall to read soc unique
> > ID, and add the other way which uses module_platform_driver and
> > nvmem API, so that it will not break the old version DTBs.
> > v4: delete "__maybe_unused"
> > delete MODULE_DEVICE_TABLE(of, imx8m_soc_match);
> > rename match table, "fsl,imx8mm/n/q/p" is actually a machine
> > compabile and "fsl,imx8mm/n/q/p-soc" is a compabile of soc@0
> > delete "flag" and change to determine whether the pointer is NULL
> > ues of_find_matching_node_and_match()
> > delete of_match_ptr()
> > v5: add cleanup part "of_node_put"
> > add note to explain that why device_initcall still exists
> > v6: none

Hi Adam,

It says up to v6, just in unnatural order... I was also surprised.

Best regards,
Krzysztof

Re: [PATCH] media: ov8856: Remove 3280x2464 mode

2020-11-24 Thread Tomasz Figa

Hi Bingbu,

On Wed, Nov 25, 2020 at 1:15 PM Bingbu Cao  wrote:
>
>
>
> On 11/24/20 6:20 PM, Robert Foss wrote:
> > On Tue, 24 Nov 2020 at 10:42, Bingbu Cao  wrote:
> >>
> >> Hi, Robert
> >>
> >> I remember that the full size of ov8856 image sensor is 3296x2480 and we 
> >> can get the 3280x2464
> >> frames based on current settings.
> >>
> >> Do you have any issues with this mode?
> >
> > As far as I can tell using the 3280x2464 mode actually yields an
> > output resolution that is 3264x2448.
> >
> > What does your hardware setup look like? And which revision of the
> > sensor are you using?
> >
>
> Robert, the sensor revision I am using is v1.1. I just checked the actual 
> output pixels on our
> hardware, the output resolution with 2464 mode is 3280x2464, no black pixels.
>
> As Tomasz said, some ISP has the requirement of extra pixel padding, From the 
> ov8856 datasheet,
> the central 3264x2448 pixels are *suggested* to be output from the pixel 
> array and the boundary
> pixels can be used for additional processing. In my understanding, the 32 
> dummy lines are not
> black lines.

The datasheet says that only 3264x2448 are active pixels. What pixel
values are you seeing outside of that central area? In the datasheet,
those look like "optically black" pixels, which are not 100% black,
but rather as if the sensor cells didn't receive any light - noise can
be still there.

Best regards,
Tomasz

Re: [PATCH 1/2] genirq: add an affinity parameter to irq_create_mapping()

2020-11-24 Thread Laurent Vivier

On 24/11/2020 23:19, Thomas Gleixner wrote:
> On Tue, Nov 24 2020 at 21:03, Laurent Vivier wrote:
>> This parameter is needed to pass it to irq_domain_alloc_descs().
>>
>> This seems to have been missed by
>> o06ee6d571f0e ("genirq: Add affinity hint to irq allocation")
> 
> No, this has not been missed at all. There was and is no reason to do
> this.
> 
>> This is needed to implement proper support for multiqueue with
>> pseries.
> 
> And because pseries needs this _all_ callers need to be changed?
> 
>>  123 files changed, 171 insertions(+), 146 deletions(-)
> 
> Lots of churn for nothing. 99% of the callers will never need that.
> 
> What's wrong with simply adding an interface which takes that parameter,
> make the existing one an inline wrapper and and leave the rest alone?

Nothing. I'm going to do like that.

Thank you for your comment.

Laurent

[PATCH 0/4] Check codeSigning extended key usage extension

NIAP PP_OS certification requests that the OS shall validate the
CodeSigning extended key usage extension field for integrity
verifiction of exectable code:

https://www.niap-ccevs.org/MMO/PP/-442-/
FIA_X509_EXT.1.1

This patchset adds the logic for parsing the codeSigning EKU extension
field in X.509. And checking the CodeSigning EKU when verifying
signature of kernel module or kexec PE binary in PKCS#7.

v3:
- Add codeSigning EKU to x509.genkey key generation config.
- Add openssl command option example for generating CodeSign EKU to
  module-signing.rst document. 

v2:
Changed the help wording in the Kconfig.

Lee, Chun-Yi (4):
  X.509: Add CodeSigning extended key usage parsing
  PKCS#7: Check codeSigning EKU for kernel module and kexec pe
verification
  modsign: Add codeSigning EKU when generating X.509 key generation
config
  Documentation/admin-guide/module-signing.rst: add openssl command
option example for CodeSign EKU

 Documentation/admin-guide/module-signing.rst |  6 +
 certs/Makefile   |  1 +
 certs/system_keyring.c   |  2 +-
 crypto/asymmetric_keys/Kconfig   |  9 +++
 crypto/asymmetric_keys/pkcs7_trust.c | 37 +---
 crypto/asymmetric_keys/x509_cert_parser.c| 24 ++
 include/crypto/pkcs7.h   |  3 ++-
 include/crypto/public_key.h  |  1 +
 include/linux/oid_registry.h |  5 
 9 files changed, 83 insertions(+), 5 deletions(-)

-- 
2.16.4

[PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU

Add an openssl command option example for generating CodeSign extended
key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU be enabled.

Signed-off-by: "Lee, Chun-Yi" 
---
 Documentation/admin-guide/module-signing.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/admin-guide/module-signing.rst 
b/Documentation/admin-guide/module-signing.rst
index f8b584179cff..bc184124d646 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -170,6 +170,12 @@ generate the public/private key files::
   -config x509.genkey -outform PEM -out kernel_key.pem \
   -keyout kernel_key.pem
 
+When ``CONFIG_CHECK_CODESIGN_EKU`` option be enabled, the following openssl
+command option should be added for generating CodeSign extended key usage in
+X.509::
+
+-addext "extendedKeyUsage=codeSigning"
+
 The full pathname for the resulting kernel_key.pem file can then be specified
 in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein 
will
 be used instead of an autogenerated keypair.
-- 
2.16.4

[PATCH 3/4] modsign: Add codeSigning EKU when generating X.509 key generation config

Add codeSigning EKU to the X.509 key generation config for the build time
autogenerated kernel key.

Signed-off-by: "Lee, Chun-Yi" 
---
 certs/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/certs/Makefile b/certs/Makefile
index f4c25b67aad9..1ef4d6ca43b7 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -88,6 +88,7 @@ $(obj)/x509.genkey:
@echo >>$@ "keyUsage=digitalSignature"
@echo >>$@ "subjectKeyIdentifier=hash"
@echo >>$@ "authorityKeyIdentifier=keyid"
+   @echo >>$@ "extendedKeyUsage=codeSigning"
 endif # CONFIG_MODULE_SIG_KEY
 
 $(eval $(call config_filename,MODULE_SIG_KEY))
-- 
2.16.4

[PATCH v2 2/4] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification

This patch adds the logic for checking the CodeSigning extended
key usage when verifying signature of kernel module or
kexec PE binary in PKCS#7.

Signed-off-by: "Lee, Chun-Yi" 
---
 certs/system_keyring.c   |  2 +-
 crypto/asymmetric_keys/Kconfig   |  9 +
 crypto/asymmetric_keys/pkcs7_trust.c | 37 +---
 include/crypto/pkcs7.h   |  3 ++-
 4 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 798291177186..4104f5465d8a 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -242,7 +242,7 @@ int verify_pkcs7_message_sig(const void *data, size_t len,
goto error;
}
}
-   ret = pkcs7_validate_trust(pkcs7, trusted_keys);
+   ret = pkcs7_validate_trust(pkcs7, trusted_keys, usage);
if (ret < 0) {
if (ret == -ENOKEY)
pr_devel("PKCS#7 signature not signed with a trusted 
key\n");
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 1f1f004dc757..1754812df989 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -96,4 +96,13 @@ config SIGNED_PE_FILE_VERIFICATION
  This option provides support for verifying the signature(s) on a
  signed PE binary.
 
+config CHECK_CODESIGN_EKU
+   bool "Check codeSigning extended key usage"
+   depends on PKCS7_MESSAGE_PARSER=y
+   depends on SYSTEM_DATA_VERIFICATION
+   help
+ This option provides support for checking the codeSigning extended
+ key usage when verifying the signature in PKCS#7. It affects kernel
+ module verification and kexec PE binary verification.
+
 endif # ASYMMETRIC_KEY_TYPE
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c 
b/crypto/asymmetric_keys/pkcs7_trust.c
index 61af3c4d82cc..1d2318ff63db 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -16,12 +16,36 @@
 #include 
 #include "pkcs7_parser.h"
 
+#ifdef CONFIG_CHECK_CODESIGN_EKU
+static bool check_codesign_eku(struct key *key,
+enum key_being_used_for usage)
+{
+   struct public_key *public_key = key->payload.data[asym_crypto];
+
+   switch (usage) {
+   case VERIFYING_MODULE_SIGNATURE:
+   case VERIFYING_KEXEC_PE_SIGNATURE:
+   return !!(public_key->eku & EKU_codeSigning);
+   default:
+   break;
+   }
+   return true;
+}
+#else
+static bool check_codesign_eku(struct key *key,
+enum key_being_used_for usage)
+{
+   return true;
+}
+#endif
+
 /**
  * Check the trust on one PKCS#7 SignedInfo block.
  */
 static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7,
struct pkcs7_signed_info *sinfo,
-   struct key *trust_keyring)
+   struct key *trust_keyring,
+   enum key_being_used_for usage)
 {
struct public_key_signature *sig = sinfo->sig;
struct x509_certificate *x509, *last = NULL, *p;
@@ -112,6 +136,12 @@ static int pkcs7_validate_trust_one(struct pkcs7_message 
*pkcs7,
return -ENOKEY;
 
 matched:
+   if (!check_codesign_eku(key, usage)) {
+   pr_warn("sinfo %u: The signer %x key is not CodeSigning\n",
+   sinfo->index, key_serial(key));
+   key_put(key);
+   return -ENOKEY;
+   }
ret = verify_signature(key, sig);
key_put(key);
if (ret < 0) {
@@ -156,7 +186,8 @@ static int pkcs7_validate_trust_one(struct pkcs7_message 
*pkcs7,
  * May also return -ENOMEM.
  */
 int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
-struct key *trust_keyring)
+struct key *trust_keyring,
+enum key_being_used_for usage)
 {
struct pkcs7_signed_info *sinfo;
struct x509_certificate *p;
@@ -167,7 +198,7 @@ int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
p->seen = false;
 
for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
-   ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring);
+   ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring, 
usage);
switch (ret) {
case -ENOKEY:
continue;
diff --git a/include/crypto/pkcs7.h b/include/crypto/pkcs7.h
index 38ec7f5f9041..b3b48240ba73 100644
--- a/include/crypto/pkcs7.h
+++ b/include/crypto/pkcs7.h
@@ -30,7 +30,8 @@ extern int pkcs7_get_content_data(const struct pkcs7_message 
*pkcs7,
  * pkcs7_trust.c
  */
 extern int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
-   struct key *trust_keyring);
+   struct key *trust_keyring,
+

[PATCH v2 1/4] X.509: Add CodeSigning extended key usage parsing

This patch adds the logic for parsing the CodeSign extended key usage
extension in X.509. The parsing result will be set to the eku flag
which is carried by public key. It can be used in the PKCS#7
verification.

Signed-off-by: "Lee, Chun-Yi" 
---
 crypto/asymmetric_keys/x509_cert_parser.c | 24 
 include/crypto/public_key.h   |  1 +
 include/linux/oid_registry.h  |  5 +
 3 files changed, 30 insertions(+)

diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
b/crypto/asymmetric_keys/x509_cert_parser.c
index 52c9b455fc7d..65721313b265 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -497,6 +497,8 @@ int x509_process_extension(void *context, size_t hdrlen,
struct x509_parse_context *ctx = context;
struct asymmetric_key_id *kid;
const unsigned char *v = value;
+   int i = 0;
+   enum OID oid;
 
pr_debug("Extension: %u\n", ctx->last_oid);
 
@@ -526,6 +528,28 @@ int x509_process_extension(void *context, size_t hdrlen,
return 0;
}
 
+   if (ctx->last_oid == OID_extKeyUsage) {
+   if (v[0] != ((ASN1_UNIV << 6) | ASN1_CONS_BIT | ASN1_SEQ) ||
+   v[1] != vlen - 2)
+   return -EBADMSG;
+   i += 2;
+
+   while (i < vlen) {
+   /* A 10 bytes EKU OID Octet blob =
+* ASN1_OID + size byte + 8 bytes OID */
+   if (v[i] != ASN1_OID || v[i + 1] != 8 || (i + 10) > 
vlen)
+   return -EBADMSG;
+
+   oid = look_up_OID(v + i + 2, v[i + 1]);
+   if (oid == OID_codeSigning) {
+   ctx->cert->pub->eku |= EKU_codeSigning;
+   }
+   i += 10;
+   }
+   pr_debug("extKeyUsage: %d\n", ctx->cert->pub->eku);
+   return 0;
+   }
+
return 0;
 }
 
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index 948c5203ca9c..07a1b28460a2 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -29,6 +29,7 @@ struct public_key {
bool key_is_private;
const char *id_type;
const char *pkey_algo;
+   unsigned int eku : 9;  /* Extended Key Usage (9-bit) */
 };
 
 extern void public_key_free(struct public_key *key);
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index 4462ed2c18cd..e20e8eb53b21 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -113,9 +113,14 @@ enum OID {
OID_SM2_with_SM3,   /* 1.2.156.10197.1.501 */
OID_sm3WithRSAEncryption,   /* 1.2.156.10197.1.504 */
 
+   /* Extended key purpose OIDs [RFC 5280] */
+   OID_codeSigning,/* 1.3.6.1.5.5.7.3.3 */
+
OID__NR
 };
 
+#define EKU_codeSigning(1 << 2)
+
 extern enum OID look_up_OID(const void *data, size_t datasize);
 extern int sprint_oid(const void *, size_t, char *, size_t);
 extern int sprint_OID(enum OID, char *, size_t);
-- 
2.16.4

[PATCH] PCI: Fix pci_create_slot() memory leak

2020-11-24 Thread Jubin Zhong

After commit 8a94644b440e ("PCI: Fix pci_create_slot() reference count
leak"), kobject_put() is called instead of kfree() if
kobject_init_and_add() fails. However, we still need to free the slot
memory before overwriting it as ERR_PTR(err).

This partially reverts the commit 8a94644b440e.

Fixes: 8a94644b440e ("PCI: Fix pci_create_slot() reference count leak")
Signed-off-by: Jubin Zhong 
---
 drivers/pci/slot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
index 3861505..a4be62e 100644
--- a/drivers/pci/slot.c
+++ b/drivers/pci/slot.c
@@ -268,7 +268,6 @@ struct pci_slot *pci_create_slot(struct pci_bus *parent, 
int slot_nr,
slot_name = make_slot_name(name);
if (!slot_name) {
err = -ENOMEM;
-   kfree(slot);
goto err;
}
 
@@ -296,6 +295,7 @@ struct pci_slot *pci_create_slot(struct pci_bus *parent, 
int slot_nr,
mutex_unlock(_slot_mutex);
return slot;
 err:
+   kfree(slot);
slot = ERR_PTR(err);
goto out;
 }
-- 
1.8.5.6

Re: [RFC] perf/x86: Fix a warning on x86_pmu_stop()

2020-11-24 Thread Namhyung Kim

On Tue, Nov 24, 2020 at 5:10 PM Peter Zijlstra  wrote:
>
> On Tue, Nov 24, 2020 at 02:01:39PM +0900, Namhyung Kim wrote:
>
> > Yes, it's not about __intel_pmu_pebs_event().  I'm looking at
> > intel_pmu_drain_pebs_nhm() specifically.  There's code like
> >
> > /* log dropped samples number */
> > if (error[bit]) {
> > perf_log_lost_samples(event, error[bit]);
> >
> > if (perf_event_account_interrupt(event))
> > x86_pmu_stop(event, 0);
> > }
> >
> > if (counts[bit]) {
> > __intel_pmu_pebs_event(event, iregs, base,
> >top, bit, counts[bit],
> >setup_pebs_fixed_sample_data);
> > }
> >
> > There's a path to x86_pmu_stop() when an error bit is on.
>
> That would seem to suggest you try something like this:
>
> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
> index 31b9e58b03fe..8c6ee8be8b6e 100644
> --- a/arch/x86/events/intel/ds.c
> +++ b/arch/x86/events/intel/ds.c
> @@ -1945,7 +1945,7 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs 
> *iregs, struct perf_sample_d
> if (error[bit]) {
> perf_log_lost_samples(event, error[bit]);
>
> -   if (perf_event_account_interrupt(event))
> +   if (iregs && perf_event_account_interrupt(event))
> x86_pmu_stop(event, 0);
> }
>

That would work too and much simpler!

Thanks,
Namhyung

[PATCH v2 3/3] MIPS: dts: mscc: add reset support for Luton and Jaguar2

Allow Luton and Jaguar2 SoCs to use reset feature by adding the reset
node.

Signed-off-by: Gregory CLEMENT 
---
 arch/mips/boot/dts/mscc/jaguar2.dtsi | 5 +
 arch/mips/boot/dts/mscc/luton.dtsi   | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/mips/boot/dts/mscc/jaguar2.dtsi 
b/arch/mips/boot/dts/mscc/jaguar2.dtsi
index 42b2b0a51ddc..7032fe550277 100644
--- a/arch/mips/boot/dts/mscc/jaguar2.dtsi
+++ b/arch/mips/boot/dts/mscc/jaguar2.dtsi
@@ -60,6 +60,11 @@ cpu_ctrl: syscon@7000 {
reg = <0x7000 0x2c>;
};
 
+   reset@71010008 {
+   compatible = "mscc,jaguar2-chip-reset";
+   reg = <0x71010008 0x4>;
+   };
+
intc: interrupt-controller@7070 {
compatible = "mscc,jaguar2-icpu-intr";
reg = <0x7070 0x94>;
diff --git a/arch/mips/boot/dts/mscc/luton.dtsi 
b/arch/mips/boot/dts/mscc/luton.dtsi
index 2a170b84c5a9..4a26c2874386 100644
--- a/arch/mips/boot/dts/mscc/luton.dtsi
+++ b/arch/mips/boot/dts/mscc/luton.dtsi
@@ -56,6 +56,11 @@ cpu_ctrl: syscon@1000 {
reg = <0x1000 0x2c>;
};
 
+   reset@00070090 {
+   compatible = "mscc,luton-chip-reset";
+   reg = <0x70090 0x4>;
+   };
+
intc: interrupt-controller@1084 {
compatible = "mscc,luton-icpu-intr";
reg = <0x1084 0x70>;
-- 
2.29.2

[PATCH v2 0/3] Add reset support in ocelot driver for new platforms

Hello,

This series extends reset support for 2 other MIPS based SoCs: Luton
and Jaguar 2.

Patches 1 and 2 should be merged through the reset subsystem, while
the device tree changes in patches 3 should go through the mips
subsystem.

In this second series I removed the microchip,reset-switch-core
property support waiting for finding a butter solution for it.

Changelog:

 v1 -> v2:
 - Add binding documentation for the 2 new SoC
 - Fix compatible string in name device tree node
 - Add Acked-by from Alexande

Gregory

Gregory CLEMENT (3):
  dt-bindings: reset: ocelot: Add Luton and Jaguar2 support
  power: reset: ocelot: Add support 2 other MIPS based SoCs
  MIPS: dts: mscc: add reset support for Luton and Jaguar2

 .../bindings/power/reset/ocelot-reset.txt |  4 ++-
 arch/mips/boot/dts/mscc/jaguar2.dtsi  |  5 
 arch/mips/boot/dts/mscc/luton.dtsi|  5 
 drivers/power/reset/ocelot-reset.c| 30 +--
 4 files changed, 40 insertions(+), 4 deletions(-)

-- 
2.29.2

[PATCH v2 1/3] dt-bindings: reset: ocelot: Add Luton and Jaguar2 support

This adds the support for 2 others MIPS based VCore III SoCs: Luton
and Jaguar2.

Signed-off-by: Gregory CLEMENT 
---
 .../devicetree/bindings/power/reset/ocelot-reset.txt  | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt 
b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
index 4d530d815484..c5de7b555feb 100644
--- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
+++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
@@ -7,7 +7,9 @@ The reset registers are both present in the MSCC vcoreiii MIPS 
and
 microchip Sparx5 armv8 SoC's.
 
 Required Properties:
- - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
+
+ - compatible: "mscc,ocelot-chip-reset", "mscc,luton-chip-reset",
+   "mscc,jaguar2-chip-reset" or "microchip,sparx5-chip-reset"
 
 Example:
reset@1070008 {
-- 
2.29.2

[PATCH v2 2/3] power: reset: ocelot: Add support 2 other MIPS based SoCs

This adds reset support for Luton and Jaguar2 in the ocelot-reset
driver. They are both MIPS based belonging to the Vcore III family.

Acked-by: Alexandre Belloni 
Signed-off-by: Gregory CLEMENT 
---
 drivers/power/reset/ocelot-reset.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/power/reset/ocelot-reset.c 
b/drivers/power/reset/ocelot-reset.c
index f74e1dbb4ba3..8caa90cb58fc 100644
--- a/drivers/power/reset/ocelot-reset.c
+++ b/drivers/power/reset/ocelot-reset.c
@@ -29,6 +29,8 @@ struct ocelot_reset_context {
struct notifier_block restart_handler;
 };
 
+#define BIT_OFF_INVALID32
+
 #define SOFT_CHIP_RST BIT(0)
 
 #define ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL  0x24
@@ -50,9 +52,11 @@ static int ocelot_restart_handle(struct notifier_block *this,
   ctx->props->vcore_protect, 0);
 
/* Make the SI back to boot mode */
-   regmap_update_bits(ctx->cpu_ctrl, ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL,
-  IF_SI_OWNER_MASK << if_si_owner_bit,
-  IF_SI_OWNER_SIBM << if_si_owner_bit);
+   if (if_si_owner_bit != BIT_OFF_INVALID)
+   regmap_update_bits(ctx->cpu_ctrl,
+  ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL,
+  IF_SI_OWNER_MASK << if_si_owner_bit,
+  IF_SI_OWNER_SIBM << if_si_owner_bit);
 
pr_emerg("Resetting SoC\n");
 
@@ -96,6 +100,20 @@ static int ocelot_reset_probe(struct platform_device *pdev)
return err;
 }
 
+static const struct reset_props reset_props_jaguar2 = {
+   .syscon  = "mscc,ocelot-cpu-syscon",
+   .protect_reg = 0x20,
+   .vcore_protect   = BIT(2),
+   .if_si_owner_bit = 6,
+};
+
+static const struct reset_props reset_props_luton = {
+   .syscon  = "mscc,ocelot-cpu-syscon",
+   .protect_reg = 0x20,
+   .vcore_protect   = BIT(2),
+   .if_si_owner_bit = BIT_OFF_INVALID, /* n/a */
+};
+
 static const struct reset_props reset_props_ocelot = {
.syscon  = "mscc,ocelot-cpu-syscon",
.protect_reg = 0x20,
@@ -112,6 +130,12 @@ static const struct reset_props reset_props_sparx5 = {
 
 static const struct of_device_id ocelot_reset_of_match[] = {
{
+   .compatible = "mscc,jaguar2-chip-reset",
+   .data = _props_jaguar2
+   }, {
+   .compatible = "mscc,luton-chip-reset",
+   .data = _props_luton
+   }, {
.compatible = "mscc,ocelot-chip-reset",
.data = _props_ocelot
}, {
-- 
2.29.2

Re: [PATCH v4] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML

2020-11-24 Thread Ioana Ciornei

On Mon, Nov 23, 2020 at 11:00:35AM +0200, Laurentiu Tudor wrote:
> From: Ionut-robert Aron 
> 
> Convert fsl,qoriq-mc to YAML in order to automate the verification
> process of dts files. In addition, update MAINTAINERS accordingly
> and, while at it, add some missing files.
> 
> Signed-off-by: Ionut-robert Aron 
> [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema]
> Signed-off-by: Laurentiu Tudor 

Acked-by: Ioana Ciornei 


> ---
> Changes in v4:
>  - use $ref to point to fsl,qoriq-mc-dpmac binding
> 
> Changes in v3:
>  - dropped duplicated "fsl,qoriq-mc-dpmac" schema and replaced with
>reference to it
>  - fixed a dt_binding_check warning
> 
> Changes in v2:
>  - fixed errors reported by yamllint
>  - dropped multiple unnecessary quotes
>  - used schema instead of text in description
>  - added constraints on dpmac reg property
> 
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 --
>  .../bindings/misc/fsl,qoriq-mc.yaml   | 186 +
>  .../ethernet/freescale/dpaa2/overview.rst |   5 +-
>  MAINTAINERS   |   4 +-
>  4 files changed, 193 insertions(+), 198 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>  create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> deleted file mode 100644
> index 7b486d4985dc..
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ /dev/null
> @@ -1,196 +0,0 @@
> -* Freescale Management Complex
> -
> -The Freescale Management Complex (fsl-mc) is a hardware resource
> -manager that manages specialized hardware objects used in
> -network-oriented packet processing applications. After the fsl-mc
> -block is enabled, pools of hardware resources are available, such as
> -queues, buffer pools, I/O interfaces. These resources are building
> -blocks that can be used to create functional hardware objects/devices
> -such as network interfaces, crypto accelerator instances, L2 switches,
> -etc.
> -
> -For an overview of the DPAA2 architecture and fsl-mc bus see:
> -Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
> -
> -As described in the above overview, all DPAA2 objects in a DPRC share the
> -same hardware "isolation context" and a 10-bit value called an ICID
> -(isolation context id) is expressed by the hardware to identify
> -the requester.
> -
> -The generic 'iommus' property is insufficient to describe the relationship
> -between ICIDs and IOMMUs, so an iommu-map property is used to define
> -the set of possible ICIDs under a root DPRC and how they map to
> -an IOMMU.
> -
> -For generic IOMMU bindings, see
> -Documentation/devicetree/bindings/iommu/iommu.txt.
> -
> -For arm-smmu binding, see:
> -Documentation/devicetree/bindings/iommu/arm,smmu.yaml.
> -
> -The MSI writes are accompanied by sideband data which is derived from the 
> ICID.
> -The msi-map property is used to associate the devices with both the ITS
> -controller and the sideband data which accompanies the writes.
> -
> -For generic MSI bindings, see
> -Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> -
> -For GICv3 and GIC ITS bindings, see:
> -Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml.
> -
> -Required properties:
> -
> -- compatible
> -Value type: 
> -Definition: Must be "fsl,qoriq-mc".  A Freescale Management Complex
> -compatible with this binding must have Block Revision
> -Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in
> -the MC control register region.
> -
> -- reg
> -Value type: 
> -Definition: A standard property.  Specifies one or two regions
> -defining the MC's registers:
> -
> -   -the first region is the command portal for the
> -this machine and must always be present
> -
> -   -the second region is the MC control registers. This
> -region may not be present in some scenarios, such
> -as in the device tree presented to a virtual machine.
> -
> -- ranges
> -Value type: 
> -Definition: A standard property.  Defines the mapping between the 
> child
> -MC address space and the parent system address space.
> -
> -The MC address space is defined by 3 components:
> - 
> -
> -Valid values for region type are
> -   0x0 - MC portals
> -   0x1 - QBMAN portals
> -
> -- #address-cells
> -Value type: 
> -Definition: Must be 3.  (see definition in 'ranges' property)
> -
> -- #size-cells
> -Value type: 
> -

[RESEND PATCH v4 5/6] hwmon: ahc1ec0-hwmon: Add sub-device hwmon for Advantech embedded controller

This is one of sub-device driver for Advantech embedded controller
AHC1EC0. This driver provides sysfs ABI for Advantech related
applications to monitor the system status.

Signed-off-by: Shihlun Lin 
---
 drivers/hwmon/Kconfig |8 +
 drivers/hwmon/Makefile|1 +
 drivers/hwmon/ahc1ec0-hwmon.c | 1504 +
 3 files changed, 1513 insertions(+)
 create mode 100644 drivers/hwmon/ahc1ec0-hwmon.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index a850e4f0e0bd..577dd1dd60ee 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2095,6 +2095,14 @@ config SENSORS_INTEL_M10_BMC_HWMON
  sensors monitor various telemetry data of different components on the
  card, e.g. board temperature, FPGA core temperature/voltage/current.
 
+config SENSORS_AHC1EC0_HWMON
+   tristate "Advantech EC Hardware Monitor Function"
+   depends on MFD_AHC1EC0
+   help
+ This is sub-device for Advantech embedded controller AHC1EC0. This
+ driver provides the sysfs attributes for applications to monitor
+ the system status.
+
 if ACPI
 
 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 9db2903b61e5..e06ddc314b4a 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_SENSORS_ADT7411) += adt7411.o
 obj-$(CONFIG_SENSORS_ADT7462)  += adt7462.o
 obj-$(CONFIG_SENSORS_ADT7470)  += adt7470.o
 obj-$(CONFIG_SENSORS_ADT7475)  += adt7475.o
+obj-$(CONFIG_SENSORS_AHC1EC0_HWMON)+= ahc1ec0-hwmon.o
 obj-$(CONFIG_SENSORS_AMD_ENERGY) += amd_energy.o
 obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
 obj-$(CONFIG_SENSORS_ARM_SCMI) += scmi-hwmon.o
diff --git a/drivers/hwmon/ahc1ec0-hwmon.c b/drivers/hwmon/ahc1ec0-hwmon.c
new file mode 100644
index ..d71eb8e01422
--- /dev/null
+++ b/drivers/hwmon/ahc1ec0-hwmon.c
@@ -0,0 +1,1504 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * HWMON Driver for Advantech controlling EC chip AHC1EC0
+ *
+ * Copyright (C) 2020, Advantech Automation Corp.
+ *
+ * Change Log:
+ * Version 1.00 <11/05/2015> Jiangwei.Zhu
+ *   - Initial version
+ * Version 1.01 <03/04/2016> Jiangwei.Zhu
+ *   - Support UNO-1372G-E3AE, TPC-1782H-433AE, APAX-5580-433AE
+ * Version 1.02 <05/09/2016> Ji.Xu
+ *   - Support APAX-5580-473AE/4C3AE
+ *   - Modify the device name check method to fuzzy matching.
+ * Version 1.03 <05/09/2017> Ji.Xu
+ *   - Support UNO-2271G-E2xAE
+ *   - Support UNO-2271G-E02xAE
+ *   - Support ECU-4784
+ *   - Support UNO-2473G-JxAE
+ * Version 1.04 <09/20/2017> Ji.Xu
+ *   - Support UNO-2484G-633xAE
+ *   - Support UNO-2484G-653xAE
+ *   - Support UNO-2484G-673xAE
+ *   - Support UNO-2484G-733xAE
+ *   - Support UNO-2484G-753xAE
+ *   - Support UNO-2484G-773xAE
+ * Version 1.05 <10/26/2017> Ji.Xu
+ *   - Support PR/VR4
+ *   - Support UNO-3283G-674AE
+ *   - Support UNO-3285G-674AE
+ * Version 1.06 <11/16/2017> Zhang.Yang
+ *   - Support UNO-1372G-J021AE/J031AE
+ *   - Support UNO-2372G
+ * Version 1.07 <02/02/2018> Ji.Xu
+ *   - Convert the driver to use new hwmon API after kernel version 4.10.0
+ *   - Support EC TPC-B500-6??AE
+ *   - Support EC TPC-5???T-6??AE
+ * Version 1.08 <02/20/2019> Ji.Xu
+ *   - Support EC UNO-420
+ *   - Support EC TPC-B200-???AE
+ *   - Support EC TPC-2???T-???AE
+ *   - Support EC TPC-2???W-???AE
+ * Version 1.09 <04/24/2020> Yao.Kang
+ *   - Support EC UNO-2473G
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADVANTECH_EC_HWMON_VER "1.09"
+#define ADVANTECH_EC_HWMON_DATE"04/24/2020"
+
+/* Addresses to scan */
+static const unsigned short normal_i2c[] = { 0x2d, 0x2e, I2C_CLIENT_END };
+
+enum chips { f75373, f75375, f75387 };
+
+/* Fintek F75375 registers  */
+#define F75375_REG_CONFIG0 0x0
+#define F75375_REG_CONFIG1 0x1
+#define F75375_REG_CONFIG2 0x2
+#define F75375_REG_CONFIG3 0x3
+#define F75375_REG_ADDR0x4
+#define F75375_REG_INTR0x31
+#define F75375_CHIP_ID 0x5A
+#define F75375_REG_VERSION 0x5C
+#define F75375_REG_VENDOR  0x5D
+
+#define F75375_REG_TEMP(nr)(0x14 + (nr))
+#define F75387_REG_TEMP11_LSB(nr)  (0x1c + (nr))
+#define F75375_REG_TEMP_HIGH(nr)   (0x28 + (nr) * 2)
+#define F75375_REG_TEMP_HYST(nr)   (0x29 + (nr) * 2)
+
+/*
+ * Data structures and manipulation thereof
+ */
+
+struct f75375_data {
+   unsigned short addr;
+   struct device *hwmon_dev;
+
+   const char *name;
+

Re: [PATCH RESEND] checkpatch: Do not check git commit description style when backport the upstream commit

2020-11-24 Thread Greg KH

On Tue, Nov 24, 2020 at 08:24:15PM -0800, Joe Perches wrote:
> On Wed, 2020-11-25 at 12:08 +0800, Tiezhu Yang wrote:
> > On 11/25/2020 11:51 AM, Joe Perches wrote:
> > > On Wed, 2020-11-25 at 11:35 +0800, Tiezhu Yang wrote:
> > > > When backport the upstream commit to the internal LTS kernel version,
> > > > we usually use the following description [1] [2]:
> > > > 
> > > > [ Upstream commit cc6528bc9a0c901c83b8220a2e2617f3354d6dd9 ]
> > > > or
> > > > commit c51f8f88d705e06bd696d7510aff22b33eb8e638 upstream.
> > > Internal to what?
> > > 
> > > If it's your own internal build system, I think you should
> > > keep your own local patch to checkpatch.
> > > 
> > > I don't see why the kernel version should accept it.
> > > 
> > > Is this style used by anyone else?
> > 
> > AFAIK, this style is only used in the stable tree, for example:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.9.y=c68a9ca7ca33f1020cca97e4e935c2154bec37c7
> 
> Greg?/Sasha?
> 
> https://lore.kernel.org/lkml/995e0acb-c219-ea00-f078-7582516e2...@loongson.cn/T/#m2f3d87bd985bf3d4d7b63f1fa4f0490baa01119b
> 
> Is this in your scripts?

My scripts put this into a patch when applying it to the stable tree,
and so do Sasha's.  I don't know why checkpatch would care about this as
that's not used for this workflow at all.

> Is this something you want/use?

I wouldn't use it, and I doubt anyone else would.

thanks,

greg k-h

答复: [PATCH v3 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm

2020-11-24 Thread yumeng (J)

Ok, I think I can make a patch to keep them at "include/crypto" .

-邮件原件-
发件人: Stephan Mueller [mailto:smuel...@chronox.de] 
发送时间: 2020年11月19日 4:25
收件人: yumeng (J) ; herb...@gondor.apana.org.au; 
da...@davemloft.net
抄送: linux-cry...@vger.kernel.org; Xu Zaibo ; Wangzhou (B) 
; linux-kernel@vger.kernel.org
主题: Re: [PATCH v3 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm

Am Mittwoch, den 18.11.2020, 11:47 +0800 schrieb Meng Yu:

Hi Meng,

> Enable 'ECDH' algorithm in Kunpeng 930.
> 
> Signed-off-by: Meng Yu 
> Reviewed-by: Zaibo Xu 
> ---
>  drivers/crypto/hisilicon/hpre/hpre.h    |   2 +-
>  drivers/crypto/hisilicon/hpre/hpre_crypto.c | 802
> +++-
>  drivers/crypto/hisilicon/hpre/hpre_main.c   |   1 +
>  3 files changed, 800 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
> b/drivers/crypto/hisilicon/hpre/hpre.h
> index 02193e1..50e6b2e 100644
> --- a/drivers/crypto/hisilicon/hpre/hpre.h
> +++ b/drivers/crypto/hisilicon/hpre/hpre.h
> @@ -83,6 +83,7 @@ enum hpre_alg_type {
> HPRE_ALG_KG_CRT = 0x3,
> HPRE_ALG_DH_G2 = 0x4,
> HPRE_ALG_DH = 0x5,
> +   HPRE_ALG_ECC_MUL = 0xD,
>  };
>  
>  struct hpre_sqe {
> @@ -104,5 +105,4 @@ struct hisi_qp *hpre_create_qp(u8 type);
>  int hpre_algs_register(struct hisi_qm *qm);
>  void hpre_algs_unregister(struct hisi_qm *qm);
>  
> -
>  #endif
> diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> index 712bea9..b7814ce 100644
> --- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> +++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> @@ -2,6 +2,7 @@
>  /* Copyright (c) 2019 HiSilicon Limited. */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -36,6 +37,342 @@ struct hpre_ctx;
>  #define HPRE_DFX_SEC_TO_US 100
>  #define HPRE_DFX_US_TO_NS  1000
>  
> +/* HPRE support 7 curves (include curve P192 and P256 in ecdh.h) */ 
> +#define HPRE_ECC_CURVE_NIST_P128   0X0003 #define 
> +HPRE_ECC_CURVE_NIST_P320   0X0004 #define 
> +HPRE_ECC_CURVE_NIST_P384   0X0005 #define 
> +HPRE_ECC_CURVE_NIST_P521   0X0006 #define 
> +HPRE_ECC_CURVE_NIST_P224   0X0007
> +
> +/* size in bytes of the n prime */
> +#define HPRE_ECC_NIST_P128_N_SIZE  16 #define 
> +HPRE_ECC_NIST_P192_N_SIZE  24 #define HPRE_ECC_NIST_P224_N_SIZE  
> +28 #define HPRE_ECC_NIST_P256_N_SIZE  32 #define 
> +HPRE_ECC_NIST_P320_N_SIZE  40 #define HPRE_ECC_NIST_P384_N_SIZE  
> +48 #define HPRE_ECC_NIST_P521_N_SIZE  66
> +
> +/* size in bytes */
> +#define HPRE_ECC_HW256_KSZ_B   32
> +#define HPRE_ECC_HW384_KSZ_B   48
> +#define HPRE_ECC_HW576_KSZ_B   72
> +
> +#define HPRE_ECDH_MAX_SZ   HPRE_ECC_HW576_KSZ_B
> +
> +struct curve_param_desc {
> +   __u32 id;
> +   const unsigned char *p;
> +   const unsigned char *a;
> +   const unsigned char *b;
> +   const unsigned char *gx;
> +   const unsigned char *gy;
> +   const unsigned char *n;
> +};
> +
> +/* ECC CURVE PARAMS */
> +/* 128 bits */
> +static const unsigned char ecdh_p128_p[] = {
> +   0xFF, 0xFF, 0xFF, 0xFD, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
> +0xFF,
> 0xFF,
> +   0xFF, 0xFF, 0xFF, 0xFF
> +};
> +static const unsigned char ecdh_p128_a[] = {
> +   0xFF, 0xFF, 0xFF, 0xFD, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
> +0xFF,
> 0xFF,
> +   0xFF, 0xFF, 0xFF, 0xFC
> +};
> +static const unsigned char ecdh_p128_b[] = {
> +   0xE8, 0x75, 0x79, 0xC1, 0x10, 0x79, 0xF4, 0x3D, 0xD8, 0x24, 
> +0x99,
> 0x3C,
> +   0x2C, 0xEE, 0x5E, 0xD3
> +};
> +static const unsigned char ecdh_p128_x[] = {
> +   0x16, 0x1F, 0xF7, 0x52, 0x8B, 0x89, 0x9B, 0x2D, 0x0C, 0x28, 
> +0x60,
> 0x7C,
> +   0xA5, 0x2C, 0x5B, 0x86
> +};
> +static const unsigned char ecdh_p128_y[] = {
> +   0xcf, 0x5a, 0xc8, 0x39, 0x5b, 0xaf, 0xeb, 0x13, 0xc0, 0x2d, 
> +0xa2,
> 0x92,
> +   0xdd, 0xed, 0x7a, 0x83
> +};
> +static const unsigned char ecdh_p128_n[] = {
> +   0xFF, 0xFF, 0xFF, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x75, 0xA3, 
> +0x0D,
> 0x1B,
> +   0x90, 0x38, 0xA1, 0x15
> +};
> +
> +/* 192 bits */
> +static const unsigned char ecdh_p192_p[] = {
> +   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
> +0xFF,
> 0xFF,
> +   0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
> +0xFF,
> 0xFF
> +};
> +static const unsigned char ecdh_p192_a[] = {
> +   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
> +0xFF,
> 0xFF,
> +   0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
> +0xFF,
> 0xFC
> +};
> +static const unsigned char ecdh_p192_b[] = {
> +   0x64, 0x21, 0x05, 0x19, 0xE5, 0x9C, 0x80, 0xE7, 0x0F, 0xA7, 
> +0xE9,
> 0xAB,
> +   0x72, 0x24, 0x30, 0x49, 0xFE, 0xB8, 0xDE, 0xEC, 0xC1, 0x46, 
> +0xB9,
> 0xB1
> +};
> +static const unsigned char ecdh_p192_x[] = {
> +   0x18, 0x8D, 0xA8, 0x0E, 0xB0, 0x30, 0x90, 0xF6, 0x7C, 0xBF, 
> +0x20,
> 0xEB,
> +

[PATCH v2] phram: Allow the user to set the erase page size.

2020-11-24 Thread Guohua Zhong

Permit the user to specify the erase page size as a parameter.
This solves two problems:

- phram can access images made by mkfs.jffs2.  mkfs.jffs2 won't
create images with erase sizes less than 8KiB; many architectures
define PAGE_SIZE as 4KiB.

- Allows more effective use of small capacity devices.  JFFS2
needs somewhere between 2 and 5 empty pages for garbage collection;
and for an NVRAM part with only 32KiB of space, a smaller erase page
allows much better utilization in applications where garbage collection
is important.

Signed-off-by: Patrick O'Grady 
Reviewed-by: Joern Engel 
Link: 
https://lore.kernel.org/lkml/CAJ7m5OqYv_=JB9NhHsqBsa8YU0DFRoP7C+W10PY22wonAGJK=a...@mail.gmail.com/
[Guohua Zhong: fix token array index out of bounds and update patch for kernel 
master branch]
Signed-off-by: Guohua Zhong 
Reported-by: kernel test robot 

---
v2:
 fix build error which is reported by kernel test robot

v1: https://lore.kernel.org/lkml/20201124061053.10812-1-zhongguoh...@huawei.com/
 1.fix token array index out of bounds
 2.update patch for kernel master branch
---
 drivers/mtd/devices/phram.c | 52 +
 1 file changed, 34 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
index 087b5e86d1bf..1729b94b2abf 100644
--- a/drivers/mtd/devices/phram.c
+++ b/drivers/mtd/devices/phram.c
@@ -6,14 +6,14 @@
  * Usage:
  *
  * one commend line parameter per device, each in the form:
- *   phram=,,
+ *   phram=,,[,]
  *  may be up to 63 characters.
- *  and  can be octal, decimal or hexadecimal.  If followed
+ * , , and  can be octal, decimal or hexadecimal.  If 
followed
  * by "ki", "Mi" or "Gi", the numbers will be interpreted as kilo, mega or
- * gigabytes.
+ * gigabytes.  is optional and defaults to PAGE_SIZE.
  *
  * Example:
- * phram=swap,64Mi,128Mi phram=test,900Mi,1Mi
+ * phram=swap,64Mi,128Mi phram=test,900Mi,1Mi,64Ki
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct phram_mtd_list {
struct mtd_info mtd;
@@ -88,7 +89,7 @@ static void unregister_devices(void)
}
 }
 
-static int register_device(char *name, phys_addr_t start, size_t len)
+static int register_device(char *name, phys_addr_t start, size_t len, uint32_t 
erasesize)
 {
struct phram_mtd_list *new;
int ret = -ENOMEM;
@@ -115,7 +116,7 @@ static int register_device(char *name, phys_addr_t start, 
size_t len)
new->mtd._write = phram_write;
new->mtd.owner = THIS_MODULE;
new->mtd.type = MTD_RAM;
-   new->mtd.erasesize = PAGE_SIZE;
+   new->mtd.erasesize = erasesize;
new->mtd.writesize = 1;
 
ret = -EAGAIN;
@@ -204,22 +205,23 @@ static inline void kill_final_newline(char *str)
 static int phram_init_called;
 /*
  * This shall contain the module parameter if any. It is of the form:
- * - phram=,, for module case
- * - phram.phram=,, for built-in case
- * We leave 64 bytes for the device name, 20 for the address and 20 for the
- * size.
- * Example: phram.phram=rootfs,0xa000,512Mi
+ * - phram=,,[,] for module case
+ * - phram.phram=,,[,] for built-in case
+ * We leave 64 bytes for the device name, 20 for the address , 20 for the
+ * size and 20 for the erasesize.
+ * Example: phram.phram=rootfs,0xa000,512Mi,65536
  */
-static char phram_paramline[64 + 20 + 20];
+static char phram_paramline[64 + 20 + 20 + 20];
 #endif
 
 static int phram_setup(const char *val)
 {
-   char buf[64 + 20 + 20], *str = buf;
-   char *token[3];
+   char buf[64 + 20 + 20 + 20], *str = buf;
+   char *token[4];
char *name;
uint64_t start;
uint64_t len;
+   uint64_t erasesize = PAGE_SIZE;
int i, ret;
 
if (strnlen(val, sizeof(buf)) >= sizeof(buf))
@@ -228,7 +230,7 @@ static int phram_setup(const char *val)
strcpy(str, val);
kill_final_newline(str);
 
-   for (i = 0; i < 3; i++)
+   for (i = 0; i < 4; i++)
token[i] = strsep(, ",");
 
if (str)
@@ -253,11 +255,25 @@ static int phram_setup(const char *val)
goto error;
}
 
-   ret = register_device(name, start, len);
+   if (token[3]) {
+   ret = parse_num64(, token[3]);
+   if (ret) {
+   parse_err("illegal erasesize\n");
+   goto error;
+   }
+   }
+
+   if (len == 0 || erasesize == 0 || erasesize > len
+   || erasesize > UINT_MAX || do_div(len, (uint32_t)erasesize) != 0) {
+   parse_err("illegal erasesize or len\n");
+   goto error;
+   }
+
+   ret = register_device(name, start, len, (uint32_t)erasesize);
if (ret)
goto error;
 
-   pr_info("%s device: %#llx at %#llx\n", name, len, start);
+   pr_info("%s device: %#llx at %#llx for erasesize %#llx\n", name, len, 
start, erasesize);

[PATCH v1 7/8] powerpc/32s: Use SPRN_SPRG_SCRATCH2 in DSI prolog

Use SPRN_SPRG_SCRATCH2 as an alternative scratch register in
the early part of DSI prolog in order to avoid clobbering
SPRN_SPRG_SCRATCH0/1 used by other prologs.

The 603 doesn't like a jump from DataLoadTLBMiss to the 10 nops
that are now in the beginning of DSI exception as a result of
the feature section. To workaround this, add a jump as alternative.
It also avoids fetching 10 nops for nothing.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/reg.h   |  1 +
 arch/powerpc/kernel/head_book3s_32.S | 24 
 2 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index a37ce826f6f6..acd334ee3936 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1203,6 +1203,7 @@
 #ifdef CONFIG_PPC_BOOK3S_32
 #define SPRN_SPRG_SCRATCH0 SPRN_SPRG0
 #define SPRN_SPRG_SCRATCH1 SPRN_SPRG1
+#define SPRN_SPRG_SCRATCH2 SPRN_SPRG2
 #define SPRN_SPRG_603_LRU  SPRN_SPRG4
 #endif
 
diff --git a/arch/powerpc/kernel/head_book3s_32.S 
b/arch/powerpc/kernel/head_book3s_32.S
index 51eef7b82f9c..22d670263222 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -288,9 +288,9 @@ MachineCheck:
DO_KVM  0x300
 DataAccess:
 #ifdef CONFIG_VMAP_STACK
-   mtspr   SPRN_SPRG_SCRATCH0,r10
-   mfspr   r10, SPRN_SPRG_THREAD
 BEGIN_MMU_FTR_SECTION
+   mtspr   SPRN_SPRG_SCRATCH2,r10
+   mfspr   r10, SPRN_SPRG_THREAD
stw r11, THR11(r10)
mfspr   r10, SPRN_DSISR
mfcrr11
@@ -304,19 +304,11 @@ BEGIN_MMU_FTR_SECTION
 .Lhash_page_dsi_cont:
mtcrr11
lwz r11, THR11(r10)
-END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE)
-   mtspr   SPRN_SPRG_SCRATCH1,r11
-   mfspr   r11, SPRN_DAR
-   stw r11, DAR(r10)
-   mfspr   r11, SPRN_DSISR
-   stw r11, DSISR(r10)
-   mfspr   r11, SPRN_SRR0
-   stw r11, SRR0(r10)
-   mfspr   r11, SPRN_SRR1  /* check whether user or kernel */
-   stw r11, SRR1(r10)
-   mfcrr10
-   andi.   r11, r11, MSR_PR
-
+   mfspr   r10, SPRN_SPRG_SCRATCH2
+MMU_FTR_SECTION_ELSE
+   b   1f
+ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_HPTE_TABLE)
+1: EXCEPTION_PROLOG_0 handle_dar_dsisr=1
EXCEPTION_PROLOG_1
b   handle_page_fault_tramp_1
 #else  /* CONFIG_VMAP_STACK */
@@ -760,7 +752,7 @@ fast_hash_page_return:
/* DSI */
mtcrr11
lwz r11, THR11(r10)
-   mfspr   r10, SPRN_SPRG_SCRATCH0
+   mfspr   r10, SPRN_SPRG_SCRATCH2
RFI
 
 1: /* ISI */
-- 
2.25.0

[PATCH v1 8/8] powerpc/32: Use SPRN_SPRG_SCRATCH2 in exception prologs

Use SPRN_SPRG_SCRATCH2 as a third scratch register in
exception prologs in order to simplify them and avoid
data going back and forth from/to CR.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/head_32.h | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/kernel/head_32.h b/arch/powerpc/kernel/head_32.h
index 5e3393122d29..a1ee1e12241e 100644
--- a/arch/powerpc/kernel/head_32.h
+++ b/arch/powerpc/kernel/head_32.h
@@ -40,7 +40,7 @@
 
 .macro EXCEPTION_PROLOG_1 for_rtas=0
 #ifdef CONFIG_VMAP_STACK
-   mr  r11, r1
+   mtspr   SPRN_SPRG_SCRATCH2,r1
subir1, r1, INT_FRAME_SIZE  /* use r1 if kernel */
beq 1f
mfspr   r1,SPRN_SPRG_THREAD
@@ -61,15 +61,10 @@
 
 .macro EXCEPTION_PROLOG_2 handle_dar_dsisr=0
 #ifdef CONFIG_VMAP_STACK
-   mtcrr10
-   li  r10, MSR_KERNEL & ~(MSR_IR | MSR_RI) /* can take DTLB miss */
-   mtmsr   r10
+   li  r11, MSR_KERNEL & ~(MSR_IR | MSR_RI) /* can take DTLB miss */
+   mtmsr   r11
isync
-#else
-   stw r10,_CCR(r11)   /* save registers */
-#endif
-   mfspr   r10, SPRN_SPRG_SCRATCH0
-#ifdef CONFIG_VMAP_STACK
+   mfspr   r11, SPRN_SPRG_SCRATCH2
stw r11,GPR1(r1)
stw r11,0(r1)
mr  r11, r1
@@ -78,14 +73,12 @@
stw r1,0(r11)
tovirt(r1, r11) /* set new kernel sp */
 #endif
+   stw r10,_CCR(r11)   /* save registers */
stw r12,GPR12(r11)
stw r9,GPR9(r11)
-   stw r10,GPR10(r11)
-#ifdef CONFIG_VMAP_STACK
-   mfcrr10
-   stw r10, _CCR(r11)
-#endif
+   mfspr   r10,SPRN_SPRG_SCRATCH0
mfspr   r12,SPRN_SPRG_SCRATCH1
+   stw r10,GPR10(r11)
stw r12,GPR11(r11)
mflrr10
stw r10,_LINK(r11)
@@ -99,7 +92,6 @@
stw r10, _DSISR(r11)
.endif
lwz r9, SRR1(r12)
-   andi.   r10, r9, MSR_PR
lwz r12, SRR0(r12)
 #else
mfspr   r12,SPRN_SRR0
-- 
2.25.0

[PATCH v1 3/8] powerpc/32s: Fix an FTR_SECTION_ELSE

An FTR_SECTION_ELSE is in the middle of
BEGIN_MMU_FTR_SECTION/ALT_MMU_FTR_SECTION_END_IFSET

Change it to MMU_FTR_SECTION_ELSE

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/head_book3s_32.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/head_book3s_32.S 
b/arch/powerpc/kernel/head_book3s_32.S
index 27767f3e7ec1..236a95d163be 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -332,7 +332,7 @@ BEGIN_MMU_FTR_SECTION
rlwinm  r3, r5, 32 - 15, 21, 21 /* DSISR_STORE -> _PAGE_RW */
bl  hash_page
b   handle_page_fault_tramp_1
-FTR_SECTION_ELSE
+MMU_FTR_SECTION_ELSE
b   handle_page_fault_tramp_2
 ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_HPTE_TABLE)
 #endif /* CONFIG_VMAP_STACK */
-- 
2.25.0

[PATCH v1 5/8] powerpc/603: Use SPRN_SDR1 to store the pgdir phys address

On the 603, SDR1 is not used.

In order to free SPRN_SPRG2, use SPRN_SDR1 to store the pgdir
phys addr.

But only some bits of SDR1 can be used (0x01ff).
As the pgdir is 4k aligned, rotate it by 4 bits to the left.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/reg.h   |  1 -
 arch/powerpc/kernel/head_book3s_32.S | 31 +---
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index f877a576b338..a37ce826f6f6 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1203,7 +1203,6 @@
 #ifdef CONFIG_PPC_BOOK3S_32
 #define SPRN_SPRG_SCRATCH0 SPRN_SPRG0
 #define SPRN_SPRG_SCRATCH1 SPRN_SPRG1
-#define SPRN_SPRG_PGDIRSPRN_SPRG2
 #define SPRN_SPRG_603_LRU  SPRN_SPRG4
 #endif
 
diff --git a/arch/powerpc/kernel/head_book3s_32.S 
b/arch/powerpc/kernel/head_book3s_32.S
index 236a95d163be..51eef7b82f9c 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -457,8 +457,9 @@ InstructionTLBMiss:
lis r1, TASK_SIZE@h /* check if kernel address */
cmplw   0,r1,r3
 #endif
-   mfspr   r2, SPRN_SPRG_PGDIR
+   mfspr   r2, SPRN_SDR1
li  r1,_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_EXEC
+   rlwinm  r2, r2, 28, 0xf000
 #ifdef CONFIG_MODULES
bgt-112f
lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha   /* if kernel address, 
use */
@@ -519,8 +520,9 @@ DataLoadTLBMiss:
mfspr   r3,SPRN_DMISS
lis r1, TASK_SIZE@h /* check if kernel address */
cmplw   0,r1,r3
-   mfspr   r2, SPRN_SPRG_PGDIR
+   mfspr   r2, SPRN_SDR1
li  r1, _PAGE_PRESENT | _PAGE_ACCESSED
+   rlwinm  r2, r2, 28, 0xf000
bgt-112f
lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha   /* if kernel address, 
use */
addir2, r2, (swapper_pg_dir - PAGE_OFFSET)@l/* kernel page 
table */
@@ -595,8 +597,9 @@ DataStoreTLBMiss:
mfspr   r3,SPRN_DMISS
lis r1, TASK_SIZE@h /* check if kernel address */
cmplw   0,r1,r3
-   mfspr   r2, SPRN_SPRG_PGDIR
+   mfspr   r2, SPRN_SDR1
li  r1, _PAGE_RW | _PAGE_DIRTY | _PAGE_PRESENT | _PAGE_ACCESSED
+   rlwinm  r2, r2, 28, 0xf000
bgt-112f
lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha   /* if kernel address, 
use */
addir2, r2, (swapper_pg_dir - PAGE_OFFSET)@l/* kernel page 
table */
@@ -889,9 +892,12 @@ __secondary_start:
tophys(r4,r2)
addir4,r4,THREAD/* phys address of our thread_struct */
mtspr   SPRN_SPRG_THREAD,r4
+BEGIN_MMU_FTR_SECTION
lis r4, (swapper_pg_dir - PAGE_OFFSET)@h
ori r4, r4, (swapper_pg_dir - PAGE_OFFSET)@l
-   mtspr   SPRN_SPRG_PGDIR, r4
+   rlwinm  r4, r4, 4, 0x01ff
+   mtspr   SPRN_SDR1, r4
+END_MMU_FTR_SECTION_IFCLR(MMU_FTR_HPTE_TABLE)
 
/* enable MMU and jump to start_secondary */
li  r4,MSR_KERNEL
@@ -931,11 +937,13 @@ load_up_mmu:
tlbia   /* Clear all TLB entries */
sync/* wait for tlbia/tlbie to finish */
TLBSYNC /* ... on all CPUs */
+BEGIN_MMU_FTR_SECTION
/* Load the SDR1 register (hash table base & size) */
lis r6,_SDR1@ha
tophys(r6,r6)
lwz r6,_SDR1@l(r6)
mtspr   SPRN_SDR1,r6
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE)
 
 /* Load the BAT registers with the values set up by MMU_init. */
lis r3,BATS@ha
@@ -991,9 +999,12 @@ start_here:
tophys(r4,r2)
addir4,r4,THREAD/* init task's THREAD */
mtspr   SPRN_SPRG_THREAD,r4
+BEGIN_MMU_FTR_SECTION
lis r4, (swapper_pg_dir - PAGE_OFFSET)@h
ori r4, r4, (swapper_pg_dir - PAGE_OFFSET)@l
-   mtspr   SPRN_SPRG_PGDIR, r4
+   rlwinm  r4, r4, 4, 0x01ff
+   mtspr   SPRN_SDR1, r4
+END_MMU_FTR_SECTION_IFCLR(MMU_FTR_HPTE_TABLE)
 
/* stack */
lis r1,init_thread_union@ha
@@ -1073,16 +1084,22 @@ _ENTRY(switch_mmu_context)
li  r0,NUM_USER_SEGMENTS
mtctr   r0
 
-   lwz r4, MM_PGD(r4)
 #ifdef CONFIG_BDI_SWITCH
/* Context switch the PTE pointer for the Abatron BDI2000.
 * The PGDIR is passed as second argument.
 */
+   lwz r4, MM_PGD(r4)
lis r5, abatron_pteptrs@ha
stw r4, abatron_pteptrs@l + 0x4(r5)
+#endif
+BEGIN_MMU_FTR_SECTION
+#ifndef CONFIG_BDI_SWITCH
+   lwz r4, MM_PGD(r4)
 #endif
tophys(r4, r4)
-   mtspr   SPRN_SPRG_PGDIR, r4
+   rlwinm  r4, r4, 4, 0x01ff
+   mtspr   SPRN_SDR1, r4
+END_MMU_FTR_SECTION_IFCLR(MMU_FTR_HPTE_TABLE)
li  r4,0
isync
 3:
-- 
2.25.0

[PATCH v1 6/8] powerpc/32: Simplify EXCEPTION_PROLOG_1 macro

Make code more readable with a clear CONFIG_VMAP_STACK
section and a clear non CONFIG_VMAP_STACK section.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/head_32.h | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/head_32.h b/arch/powerpc/kernel/head_32.h
index 7c767765071d..5e3393122d29 100644
--- a/arch/powerpc/kernel/head_32.h
+++ b/arch/powerpc/kernel/head_32.h
@@ -46,18 +46,16 @@
mfspr   r1,SPRN_SPRG_THREAD
lwz r1,TASK_STACK-THREAD(r1)
addir1, r1, THREAD_SIZE - INT_FRAME_SIZE
+1:
+   mtcrf   0x7f, r1
+   bt  32 - THREAD_ALIGN_SHIFT, stack_overflow
 #else
subir11, r1, INT_FRAME_SIZE /* use r1 if kernel */
beq 1f
mfspr   r11,SPRN_SPRG_THREAD
lwz r11,TASK_STACK-THREAD(r11)
addir11, r11, THREAD_SIZE - INT_FRAME_SIZE
-#endif
-1:
-   tophys_novmstack r11, r11
-#ifdef CONFIG_VMAP_STACK
-   mtcrf   0x7f, r1
-   bt  32 - THREAD_ALIGN_SHIFT, stack_overflow
+1: tophys(r11, r11)
 #endif
 .endm
 
-- 
2.25.0

[PATCH v1 4/8] powerpc/32s: Don't use SPRN_SPRG_PGDIR in hash_page

SPRN_SPRG_PGDIR is there mainly to speedup SW TLB miss handlers
for powerpc 603.

We need to free SPRN_SPRG2 to reduce the mess with CONFIG_VMAP_STACK.

In hash_page(), reading PGDIR from thread_struct will be in the noise
performance wise.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/mm/book3s32/hash_low.S | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/mm/book3s32/hash_low.S 
b/arch/powerpc/mm/book3s32/hash_low.S
index 48415c857d80..aca353d1c5f4 100644
--- a/arch/powerpc/mm/book3s32/hash_low.S
+++ b/arch/powerpc/mm/book3s32/hash_low.S
@@ -65,13 +65,14 @@ _GLOBAL(hash_page)
/* Get PTE (linux-style) and check access */
lis r0, TASK_SIZE@h /* check if kernel address */
cmplw   0,r4,r0
+   mfspr   r8,SPRN_SPRG_THREAD /* current task's THREAD (phys) */
ori r3,r3,_PAGE_USER|_PAGE_PRESENT /* test low addresses as user */
-   mfspr   r5, SPRN_SPRG_PGDIR /* phys page-table root */
+   lwz r5,PGDIR(r8)/* virt page-table root */
blt+112f/* assume user more likely */
-   lis r5, (swapper_pg_dir - PAGE_OFFSET)@ha   /* if kernel address, 
use */
-   addir5 ,r5 ,(swapper_pg_dir - PAGE_OFFSET)@l/* kernel page 
table */
+   lis r5,swapper_pg_dir@ha/* if kernel address, use */
+   addir5,r5,swapper_pg_dir@l  /* kernel page table */
rlwimi  r3,r9,32-12,29,29   /* MSR_PR -> _PAGE_USER */
-112:
+112:   tophys(r5, r5)
 #ifndef CONFIG_PTE_64BIT
rlwimi  r5,r4,12,20,29  /* insert top 10 bits of address */
lwz r8,0(r5)/* get pmd entry */
-- 
2.25.0

[PATCH v1 1/8] powerpc/32s: Always map kernel text and rodata with BATs

Since commit 2b279c0348af ("powerpc/32s: Allow mapping with BATs with
DEBUG_PAGEALLOC"), there is no real situation where mapping without
BATs is required.

In order to simplify memory handling, always map kernel text
and rodata with BATs even when "nobats" kernel parameter is set.

Also fix the 603 TLB miss exceptions that don't require anymore
kernel page table if DEBUG_PAGEALLOC.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/head_book3s_32.S | 4 ++--
 arch/powerpc/mm/book3s32/mmu.c   | 8 +++-
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/kernel/head_book3s_32.S 
b/arch/powerpc/kernel/head_book3s_32.S
index a0dda2a1f2df..27767f3e7ec1 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -453,13 +453,13 @@ InstructionTLBMiss:
  */
/* Get PTE (linux-style) and check access */
mfspr   r3,SPRN_IMISS
-#if defined(CONFIG_MODULES) || defined(CONFIG_DEBUG_PAGEALLOC)
+#ifdef CONFIG_MODULES
lis r1, TASK_SIZE@h /* check if kernel address */
cmplw   0,r1,r3
 #endif
mfspr   r2, SPRN_SPRG_PGDIR
li  r1,_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_EXEC
-#if defined(CONFIG_MODULES) || defined(CONFIG_DEBUG_PAGEALLOC)
+#ifdef CONFIG_MODULES
bgt-112f
lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha   /* if kernel address, 
use */
addir2, r2, (swapper_pg_dir - PAGE_OFFSET)@l/* kernel page 
table */
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index a59e7ec98180..5c60dcade90a 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -157,11 +157,9 @@ unsigned long __init mmu_mapin_ram(unsigned long base, 
unsigned long top)
unsigned long done;
unsigned long border = (unsigned long)__init_begin - PAGE_OFFSET;
 
-   if (__map_without_bats) {
-   pr_debug("RAM mapped without BATs\n");
-   return base;
-   }
-   if (debug_pagealloc_enabled()) {
+
+   if (debug_pagealloc_enabled() || __map_without_bats) {
+   pr_debug_once("Read-Write memory mapped without BATs\n");
if (base >= border)
return base;
if (top >= border)
-- 
2.25.0

[PATCH v1 2/8] powerpc/32s: Don't hash_preload() kernel text

We now always map kernel text with BATs. Neither need to preload
hash with kernel text addresses nor ensure they are never evicted.

This is more or less a revert of commit ee4f2ea48674 ("[POWERPC] Fix
32-bit mm operations when not using BATs")

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/mm/book3s32/hash_low.S | 18 +-
 arch/powerpc/mm/book3s32/mmu.c  |  2 +-
 arch/powerpc/mm/mmu_decl.h  |  2 --
 arch/powerpc/mm/pgtable_32.c|  4 
 4 files changed, 2 insertions(+), 24 deletions(-)

diff --git a/arch/powerpc/mm/book3s32/hash_low.S 
b/arch/powerpc/mm/book3s32/hash_low.S
index b2c912e517b9..48415c857d80 100644
--- a/arch/powerpc/mm/book3s32/hash_low.S
+++ b/arch/powerpc/mm/book3s32/hash_low.S
@@ -411,30 +411,14 @@ END_FTR_SECTION_IFCLR(CPU_FTR_NEED_COHERENT)
 * and we know there is a definite (although small) speed
 * advantage to putting the PTE in the primary PTEG, we always
 * put the PTE in the primary PTEG.
-*
-* In addition, we skip any slot that is mapping kernel text in
-* order to avoid a deadlock when not using BAT mappings if
-* trying to hash in the kernel hash code itself after it has
-* already taken the hash table lock. This works in conjunction
-* with pre-faulting of the kernel text.
-*
-* If the hash table bucket is full of kernel text entries, we'll
-* lockup here but that shouldn't happen
 */
 
-1: lis r4, (next_slot - PAGE_OFFSET)@ha/* get next evict slot 
*/
+   lis r4, (next_slot - PAGE_OFFSET)@ha/* get next evict slot 
*/
lwz r6, (next_slot - PAGE_OFFSET)@l(r4)
addir6,r6,HPTE_SIZE /* search for candidate */
andi.   r6,r6,7*HPTE_SIZE
stw r6,next_slot@l(r4)
add r4,r3,r6
-   LDPTE   r0,HPTE_SIZE/2(r4)  /* get PTE second word */
-   clrrwi  r0,r0,12
-   lis r6,etext@h
-   ori r6,r6,etext@l   /* get etext */
-   tophys(r6,r6)
-   cmplcr0,r0,r6   /* compare and try again */
-   blt 1b
 
 #ifndef CONFIG_SMP
/* Store PTE in PTEG */
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index 5c60dcade90a..23f60e97196e 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -302,7 +302,7 @@ void __init setbat(int index, unsigned long virt, 
phys_addr_t phys,
 /*
  * Preload a translation in the hash table
  */
-void hash_preload(struct mm_struct *mm, unsigned long ea)
+static void hash_preload(struct mm_struct *mm, unsigned long ea)
 {
pmd_t *pmd;
 
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 1b6d39e9baed..0ad6d476d01d 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -91,8 +91,6 @@ void print_system_hash_info(void);
 
 #ifdef CONFIG_PPC32
 
-void hash_preload(struct mm_struct *mm, unsigned long ea);
-
 extern void mapin_ram(void);
 extern void setbat(int index, unsigned long virt, phys_addr_t phys,
   unsigned int size, pgprot_t prot);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 079159e97bca..6e0083e7f008 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -112,10 +112,6 @@ static void __init __mapin_ram_chunk(unsigned long offset, 
unsigned long top)
ktext = ((char *)v >= _stext && (char *)v < etext) ||
((char *)v >= _sinittext && (char *)v < _einittext);
map_kernel_page(v, p, ktext ? PAGE_KERNEL_TEXT : PAGE_KERNEL);
-#ifdef CONFIG_PPC_BOOK3S_32
-   if (ktext)
-   hash_preload(_mm, v);
-#endif
v += PAGE_SIZE;
p += PAGE_SIZE;
}
-- 
2.25.0

Re: [PATCH] stmmac: pci: Add support for LS7A bridge chip

2020-11-24 Thread Zhi Li


Hi Jiaxun,

It's my fault, I didn't know to send mail to the mailing list.

We will discuss your suggestions and correct the errors in the code.

I will send a new patch to the mailing list.

Thanks.

-Lizhi


On 11/23/2020 06:31 PM, Jiaxun Yang wrote:

Hi Lizhi,

You didn't send the patch to any mail list, is this intentional?

在 2020/11/23 18:03, lizhi01 写道:

Add gmac driver to support LS7A bridge chip.

Signed-off-by: lizhi01 
---
  arch/mips/configs/loongson3_defconfig  |   4 +-
  drivers/net/ethernet/stmicro/stmmac/Kconfig|   8 +
  drivers/net/ethernet/stmicro/stmmac/Makefile   |   1 +
  .../net/ethernet/stmicro/stmmac/dwmac-loongson.c   | 194 
+

  4 files changed, 206 insertions(+), 1 deletion(-)
  create mode 100644 
drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c


diff --git a/arch/mips/configs/loongson3_defconfig 
b/arch/mips/configs/loongson3_defconfig

index 38a817e..2e8d2be 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -225,7 +225,9 @@ CONFIG_R8169=y
  # CONFIG_NET_VENDOR_SILAN is not set
  # CONFIG_NET_VENDOR_SIS is not set
  # CONFIG_NET_VENDOR_SMSC is not set
-# CONFIG_NET_VENDOR_STMICRO is not set
+CONFIG_NET_VENDOR_STMICR=y
+CONFIG_STMMAC_ETH=y
+CONFIG_DWMAC_LOONGSON=y
  # CONFIG_NET_VENDOR_SUN is not set
  # CONFIG_NET_VENDOR_TEHUTI is not set
  # CONFIG_NET_VENDOR_TI is not set
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig 
b/drivers/net/ethernet/stmicro/stmmac/Kconfig

index 53f14c5..30117cb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -230,6 +230,14 @@ config DWMAC_INTEL
This selects the Intel platform specific bus support for the
stmmac driver. This driver is used for Intel Quark/EHL/TGL.
  +config DWMAC_LOONGSON
+tristate "Intel GMAC support"
+depends on STMMAC_ETH && PCI
+depends on COMMON_CLK
+help
+  This selects the Intel platform specific bus support for the
+  stmmac driver.


Intel ???


+
  config STMMAC_PCI
  tristate "STMMAC PCI bus support"
  depends on STMMAC_ETH && PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile 
b/drivers/net/ethernet/stmicro/stmmac/Makefile

index 24e6145..11ea4569 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -34,4 +34,5 @@ dwmac-altr-socfpga-objs := altr_tse_pcs.o 
dwmac-socfpga.o

obj-$(CONFIG_STMMAC_PCI)+= stmmac-pci.o
  obj-$(CONFIG_DWMAC_INTEL)+= dwmac-intel.o
+obj-$(CONFIG_DWMAC_LOONGSON)+= dwmac-loongson.o
  stmmac-pci-objs:= stmmac_pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c

new file mode 100644
index 000..765412e
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2020, Loongson Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "stmmac.h"
+
+struct stmmac_pci_info {
+int (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data 
*plat);

+};
+
+static void common_default_data(struct plat_stmmacenet_data *plat)
+{
+plat->clk_csr = 2;
+plat->has_gmac = 1;
+plat->force_sf_dma_mode = 1;
+
+plat->mdio_bus_data->needs_reset = true;
+
+plat->multicast_filter_bins = HASH_TABLE_SIZE;
+
+plat->unicast_filter_entries = 1;
+
+plat->maxmtu = JUMBO_LEN;
+
+plat->tx_queues_to_use = 1;
+plat->rx_queues_to_use = 1;
+
+plat->tx_queues_cfg[0].use_prio = false;
+plat->rx_queues_cfg[0].use_prio = false;
+
+plat->rx_queues_cfg[0].pkt_route = 0x0;
+}
+
+static int loongson_default_data(struct pci_dev *pdev, struct 
plat_stmmacenet_data *plat)

+{
+common_default_data(plat);
+
+plat->bus_id = pci_dev_id(pdev);
+plat->phy_addr = -1;
+plat->interface = PHY_INTERFACE_MODE_GMII;
+
+plat->dma_cfg->pbl = 32;
+plat->dma_cfg->pblx8 = true;
+
+plat->multicast_filter_bins = 256;
+
+return 0;
+}



You can merge common and Loongson config as the driver is solely used 
by Loongson.


The callback is not necessary as well...



+
+static const struct stmmac_pci_info loongson_pci_info = {
+.setup = loongson_default_data,
+};
+
+static int loongson_gmac_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)

+{
+struct stmmac_pci_info *info = (struct stmmac_pci_info 
*)id->driver_data;

+struct plat_stmmacenet_data *plat;
+struct stmmac_resources res;
+int ret, i, lpi_irq;
+struct device_node *np;
+
+plat = devm_kzalloc(>dev, sizeof(struct 
plat_stmmacenet_data), GFP_KERNEL);

+if (!plat)
+return -ENOMEM;
+
+plat->mdio_bus_data = devm_kzalloc(>dev, sizeof(struct 
stmmac_mdio_bus_data), GFP_KERNEL);

+if (!plat->mdio_bus_data) {
+kfree(plat);
+return -ENOMEM;
+}
+
+plat->dma_cfg =

[RESEND PATCH v4 2/6] mfd: ahc1ec0: Add Advantech EC include file used by dt-bindings

This files defines the sud-device types and hwmon profiles support by
Advantech embedded controller.

Signed-off-by: Shihlun Lin 
---
 include/dt-bindings/mfd/ahc1ec0.h | 25 +
 1 file changed, 25 insertions(+)
 create mode 100644 include/dt-bindings/mfd/ahc1ec0.h

diff --git a/include/dt-bindings/mfd/ahc1ec0.h 
b/include/dt-bindings/mfd/ahc1ec0.h
new file mode 100644
index ..389a7a7f8f02
--- /dev/null
+++ b/include/dt-bindings/mfd/ahc1ec0.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Device Tree defines for Advantech Embedded Controller (AHC1EC0)
+ */
+
+#ifndef _DT_BINDINGS_MFD_AHC1EC0_H
+#define _DT_BINDINGS_MFD_AHC1EC0_H
+
+/* Sub-device Definitions */
+#define AHC1EC0_SUBDEV_BRIGHTNESS 0x0
+#define AHC1EC0_SUBDEV_EEPROM 0x1
+#define AHC1EC0_SUBDEV_GPIO   0x2
+#define AHC1EC0_SUBDEV_HWMON  0x3
+#define AHC1EC0_SUBDEV_LED0x4
+#define AHC1EC0_SUBDEV_WDT0x5
+
+/* HWMON Profile Definitions */
+#define AHC1EC0_HWMON_PRO_TEMPLATE 0x0
+#define AHC1EC0_HWMON_PRO_TPC5XXX  0x1
+#define AHC1EC0_HWMON_PRO_PRVR40x2
+#define AHC1EC0_HWMON_PRO_UNO2271G 0x3
+#define AHC1EC0_HWMON_PRO_UNO1172A 0x4
+#define AHC1EC0_HWMON_PRO_UNO1372G 0x5
+
+#endif /* _DT_BINDINGS_MFD_AHC1EC0_H */
-- 
2.17.1

Re: [PATCH v2 2/2] siox: Make remove callback return void

2020-11-24 Thread Uwe Kleine-König

On Tue, Nov 24, 2020 at 09:58:45PM +0100, Thorsten Scherer wrote:
> Hello,
> 
> On Tue, Nov 24, 2020 at 03:18:34PM +0100, Uwe Kleine-König wrote:
> > The driver core ignores the return value of the remove callback, so
> > don't give siox drivers the chance to provide a value.
> >
> > All siox drivers only allocate devm-managed resources in
> > .probe, so there is no .remove callback to fix.
> >
> > Signed-off-by: Uwe Kleine-König 
> > ---
> >  drivers/siox/siox-core.c | 5 ++---
> >  include/linux/siox.h | 2 +-
> >  2 files changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
> > index b56cdcb52967..1794ff0106bc 100644
> > --- a/drivers/siox/siox-core.c
> > +++ b/drivers/siox/siox-core.c
> > @@ -525,12 +525,11 @@ static int siox_remove(struct device *dev)
> 
> Shouldn't this return void?

This is the callback used for struct device_driver::remove (and after
patch 2 struct bus_type::remove) which still has to return int. But in
the long run I want to change these to void, too.

Best regards and thanks for your feedback
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-24 Thread James Bottomley

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James

[PATCHv10 7/9] drm/msm/a6xx: Add support for using system cache on MMU500 based targets

From: Jordan Crouse 

GPU targets with an MMU-500 attached have a slightly different process for
enabling system cache. Use the compatible string on the IOMMU phandle
to see if an MMU-500 is attached and modify the programming sequence
accordingly.

Signed-off-by: Jordan Crouse 
Signed-off-by: Sai Prakash Ranjan 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 +--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h |  1 +
 2 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 95c98c642876..3f8b92da8cba 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1042,6 +1042,8 @@ static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
 
 static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
 {
+   struct adreno_gpu *adreno_gpu = _gpu->base;
+   struct msm_gpu *gpu = _gpu->base;
u32 cntl1_regval = 0;
 
if (IS_ERR(a6xx_gpu->llc_mmio))
@@ -1055,11 +1057,17 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
   (gpu_scid << 15) | (gpu_scid << 20);
}
 
+   /*
+* For targets with a MMU500, activate the slice but don't program the
+* register.  The XBL will take care of that.
+*/
if (!llcc_slice_activate(a6xx_gpu->htw_llc_slice)) {
-   u32 gpuhtw_scid = llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
+   if (!a6xx_gpu->have_mmu500) {
+   u32 gpuhtw_scid = 
llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
 
-   gpuhtw_scid &= 0x1f;
-   cntl1_regval |= FIELD_PREP(GENMASK(29, 25), gpuhtw_scid);
+   gpuhtw_scid &= 0x1f;
+   cntl1_regval |= FIELD_PREP(GENMASK(29, 25), 
gpuhtw_scid);
+   }
}
 
if (cntl1_regval) {
@@ -1067,13 +1075,20 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
 * Program the slice IDs for the various GPU blocks and GPU MMU
 * pagetables
 */
-   a6xx_llc_write(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1, 
cntl1_regval);
-
-   /*
-* Program cacheability overrides to not allocate cache lines on
-* a write miss
-*/
-   a6xx_llc_rmw(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 
0xF, 0x03);
+   if (a6xx_gpu->have_mmu500)
+   gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL1, GENMASK(24, 0),
+   cntl1_regval);
+   else {
+   a6xx_llc_write(a6xx_gpu,
+   REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1, 
cntl1_regval);
+
+   /*
+* Program cacheability overrides to not allocate cache
+* lines on a write miss
+*/
+   a6xx_llc_rmw(a6xx_gpu,
+   REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 0xF, 
0x03);
+   }
}
 }
 
@@ -1086,10 +1101,21 @@ static void a6xx_llc_slices_destroy(struct a6xx_gpu 
*a6xx_gpu)
 static void a6xx_llc_slices_init(struct platform_device *pdev,
struct a6xx_gpu *a6xx_gpu)
 {
+   struct device_node *phandle;
+
a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem", "gpu_cx");
if (IS_ERR(a6xx_gpu->llc_mmio))
return;
 
+   /*
+* There is a different programming path for targets with an mmu500
+* attached, so detect if that is the case
+*/
+   phandle = of_parse_phandle(pdev->dev.of_node, "iommus", 0);
+   a6xx_gpu->have_mmu500 = (phandle &&
+   of_device_is_compatible(phandle, "arm,mmu-500"));
+   of_node_put(phandle);
+
a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
 
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 9e6079af679c..e793d329e77b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -32,6 +32,7 @@ struct a6xx_gpu {
void __iomem *llc_mmio;
void *llc_slice;
void *htw_llc_slice;
+   bool have_mmu500;
 };
 
 #define to_a6xx_gpu(x) container_of(x, struct a6xx_gpu, base)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv10 9/9] iommu: arm-smmu-impl: Add a space before open parenthesis

Fix the checkpatch warning for space required before the open
parenthesis.

Signed-off-by: Sai Prakash Ranjan 
Acked-by: Will Deacon 
---
 drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 26e2734eb4d7..136872e77195 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -12,7 +12,7 @@
 
 static int arm_smmu_gr0_ns(int offset)
 {
-   switch(offset) {
+   switch (offset) {
case ARM_SMMU_GR0_sCR0:
case ARM_SMMU_GR0_sACR:
case ARM_SMMU_GR0_sGFSR:
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv10 8/9] iommu: arm-smmu-impl: Use table to list QCOM implementations

Use table and of_match_node() to match qcom implementation
instead of multiple of_device_compatible() calls for each
QCOM SMMU implementation.

Signed-off-by: Sai Prakash Ranjan 
Acked-by: Will Deacon 
---
 drivers/iommu/arm/arm-smmu/arm-smmu-impl.c |  9 +
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 -
 drivers/iommu/arm/arm-smmu/arm-smmu.h  |  1 -
 3 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 7fed89c9d18a..26e2734eb4d7 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -214,14 +214,7 @@ struct arm_smmu_device *arm_smmu_impl_init(struct 
arm_smmu_device *smmu)
if (of_device_is_compatible(np, "nvidia,tegra194-smmu"))
return nvidia_smmu_impl_init(smmu);
 
-   if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
-   of_device_is_compatible(np, "qcom,sc7180-smmu-500") ||
-   of_device_is_compatible(np, "qcom,sm8150-smmu-500") ||
-   of_device_is_compatible(np, "qcom,sm8250-smmu-500"))
-   return qcom_smmu_impl_init(smmu);
-
-   if (of_device_is_compatible(smmu->dev->of_node, "qcom,adreno-smmu"))
-   return qcom_adreno_smmu_impl_init(smmu);
+   smmu = qcom_smmu_impl_init(smmu);
 
if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
smmu->impl = _mmu500_impl;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index d0636c803a36..add1859b2899 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -318,12 +318,23 @@ static struct arm_smmu_device *qcom_smmu_create(struct 
arm_smmu_device *smmu,
return >smmu;
 }
 
+static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
+   { .compatible = "qcom,sc7180-smmu-500" },
+   { .compatible = "qcom,sdm845-smmu-500" },
+   { .compatible = "qcom,sm8150-smmu-500" },
+   { .compatible = "qcom,sm8250-smmu-500" },
+   { }
+};
+
 struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
 {
-   return qcom_smmu_create(smmu, _smmu_impl);
-}
+   const struct device_node *np = smmu->dev->of_node;
 
-struct arm_smmu_device *qcom_adreno_smmu_impl_init(struct arm_smmu_device 
*smmu)
-{
-   return qcom_smmu_create(smmu, _adreno_smmu_impl);
+   if (of_match_node(qcom_smmu_impl_of_match, np))
+   return qcom_smmu_create(smmu, _smmu_impl);
+
+   if (of_device_is_compatible(np, "qcom,adreno-smmu"))
+   return qcom_smmu_create(smmu, _adreno_smmu_impl);
+
+   return smmu;
 }
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h 
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index cb7ca3a444c9..d2a2d1bc58ba 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -523,7 +523,6 @@ static inline void arm_smmu_writeq(struct arm_smmu_device 
*smmu, int page,
 struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu);
 struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu);
 struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu);
-struct arm_smmu_device *qcom_adreno_smmu_impl_init(struct arm_smmu_device 
*smmu);
 
 void arm_smmu_write_context_bank(struct arm_smmu_device *smmu, int idx);
 int arm_mmu500_reset(struct arm_smmu_device *smmu);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv10 4/9] iommu/arm-smmu: Move non-strict mode to use io_pgtable_domain_attr

Now that we have a struct io_pgtable_domain_attr with quirks,
use that for non_strict mode as well thereby removing the need
for more members of arm_smmu_domain in the future.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 15 +--
 drivers/iommu/arm/arm-smmu/arm-smmu.h |  1 -
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 4b9b10fe50ed..d8979bb71fc0 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -786,9 +786,6 @@ static int arm_smmu_init_domain_context(struct iommu_domain 
*domain,
goto out_clear_smmu;
}
 
-   if (smmu_domain->non_strict)
-   pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
-
if (smmu_domain->pgtbl_cfg.quirks)
pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;
 
@@ -1526,9 +1523,12 @@ static int arm_smmu_domain_get_attr(struct iommu_domain 
*domain,
break;
case IOMMU_DOMAIN_DMA:
switch (attr) {
-   case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-   *(int *)data = smmu_domain->non_strict;
+   case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE: {
+   bool non_strict = smmu_domain->pgtbl_cfg.quirks &
+ IO_PGTABLE_QUIRK_NON_STRICT;
+   *(int *)data = non_strict;
return 0;
+   }
default:
return -ENODEV;
}
@@ -1578,7 +1578,10 @@ static int arm_smmu_domain_set_attr(struct iommu_domain 
*domain,
case IOMMU_DOMAIN_DMA:
switch (attr) {
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-   smmu_domain->non_strict = *(int *)data;
+   if (*(int *)data)
+   smmu_domain->pgtbl_cfg.quirks |= 
IO_PGTABLE_QUIRK_NON_STRICT;
+   else
+   smmu_domain->pgtbl_cfg.quirks &= 
~IO_PGTABLE_QUIRK_NON_STRICT;
break;
default:
ret = -ENODEV;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h 
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index bb5a419f240f..cb7ca3a444c9 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -368,7 +368,6 @@ struct arm_smmu_domain {
const struct iommu_flush_ops*flush_ops;
struct arm_smmu_cfg cfg;
enum arm_smmu_domain_stage  stage;
-   boolnon_strict;
struct mutexinit_mutex; /* Protects smmu pointer */
spinlock_t  cb_lock; /* Serialises ATS1* ops and 
TLB syncs */
struct iommu_domain domain;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv10 6/9] drm/msm/a6xx: Add support for using system cache(LLC)

From: Sharat Masetty 

The last level system cache can be partitioned to 32 different
slices of which GPU has two slices preallocated. One slice is
used for caching GPU buffers and the other slice is used for
caching the GPU SMMU pagetables. This talks to the core system
cache driver to acquire the slice handles, configure the SCID's
to those slices and activates and deactivates the slices upon
GPU power collapse and restore.

Some support from the IOMMU driver is also needed to make use
of the system cache to set the right TCR attributes. GPU then
has the ability to override a few cacheability parameters which
it does to override write-allocate to write-no-allocate as the
GPU hardware does not benefit much from it.

DOMAIN_ATTR_IO_PGTABLE_CFG is another domain level attribute used
by the IOMMU driver for pagetable configuration which will be used
to set a quirk initially to set the right attributes to cache the
hardware pagetables into the system cache.

Signed-off-by: Sharat Masetty 
[saiprakash.ranjan: fix to set attr before device attach to iommu and rebase]
Signed-off-by: Sai Prakash Ranjan 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   | 83 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h   |  4 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 17 +
 3 files changed, 104 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 948f3656c20c..95c98c642876 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -8,7 +8,9 @@
 #include "a6xx_gpu.h"
 #include "a6xx_gmu.xml.h"
 
+#include 
 #include 
+#include 
 
 #define GPU_PAS_ID 13
 
@@ -1022,6 +1024,79 @@ static irqreturn_t a6xx_irq(struct msm_gpu *gpu)
return IRQ_HANDLED;
 }
 
+static void a6xx_llc_rmw(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 mask, u32 or)
+{
+   return msm_rmw(a6xx_gpu->llc_mmio + (reg << 2), mask, or);
+}
+
+static void a6xx_llc_write(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 value)
+{
+   return msm_writel(value, a6xx_gpu->llc_mmio + (reg << 2));
+}
+
+static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
+{
+   llcc_slice_deactivate(a6xx_gpu->llc_slice);
+   llcc_slice_deactivate(a6xx_gpu->htw_llc_slice);
+}
+
+static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
+{
+   u32 cntl1_regval = 0;
+
+   if (IS_ERR(a6xx_gpu->llc_mmio))
+   return;
+
+   if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
+   u32 gpu_scid = llcc_get_slice_id(a6xx_gpu->llc_slice);
+
+   gpu_scid &= 0x1f;
+   cntl1_regval = (gpu_scid << 0) | (gpu_scid << 5) | (gpu_scid << 
10) |
+  (gpu_scid << 15) | (gpu_scid << 20);
+   }
+
+   if (!llcc_slice_activate(a6xx_gpu->htw_llc_slice)) {
+   u32 gpuhtw_scid = llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
+
+   gpuhtw_scid &= 0x1f;
+   cntl1_regval |= FIELD_PREP(GENMASK(29, 25), gpuhtw_scid);
+   }
+
+   if (cntl1_regval) {
+   /*
+* Program the slice IDs for the various GPU blocks and GPU MMU
+* pagetables
+*/
+   a6xx_llc_write(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1, 
cntl1_regval);
+
+   /*
+* Program cacheability overrides to not allocate cache lines on
+* a write miss
+*/
+   a6xx_llc_rmw(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 
0xF, 0x03);
+   }
+}
+
+static void a6xx_llc_slices_destroy(struct a6xx_gpu *a6xx_gpu)
+{
+   llcc_slice_putd(a6xx_gpu->llc_slice);
+   llcc_slice_putd(a6xx_gpu->htw_llc_slice);
+}
+
+static void a6xx_llc_slices_init(struct platform_device *pdev,
+   struct a6xx_gpu *a6xx_gpu)
+{
+   a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem", "gpu_cx");
+   if (IS_ERR(a6xx_gpu->llc_mmio))
+   return;
+
+   a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
+   a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
+
+   if (IS_ERR(a6xx_gpu->llc_slice) && IS_ERR(a6xx_gpu->htw_llc_slice))
+   a6xx_gpu->llc_mmio = ERR_PTR(-EINVAL);
+}
+
 static int a6xx_pm_resume(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1038,6 +1113,8 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
 
msm_gpu_resume_devfreq(gpu);
 
+   a6xx_llc_activate(a6xx_gpu);
+
return 0;
 }
 
@@ -1048,6 +1125,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
 
trace_msm_gpu_suspend(0);
 
+   a6xx_llc_deactivate(a6xx_gpu);
+
devfreq_suspend_device(gpu->devfreq.devfreq);
 
return a6xx_gmu_stop(a6xx_gpu);
@@ -1091,6 +1170,8 @@ static void a6xx_destroy(struct msm_gpu *gpu)
drm_gem_object_put(a6xx_gpu->shadow_bo);
}
 
+   a6xx_llc_slices_destroy(a6xx_gpu);
+
a6xx_gmu_remove(a6xx_gpu);

[PATCHv10 3/9] iommu/arm-smmu: Add support for pagetable config domain attribute

Add support for domain attribute DOMAIN_ATTR_IO_PGTABLE_CFG
to get/set pagetable configuration data which initially will
be used to set quirks and later can be extended to include
other pagetable configuration data.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 20 
 drivers/iommu/arm/arm-smmu/arm-smmu.h |  1 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 0f28a8614da3..4b9b10fe50ed 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -789,6 +789,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain 
*domain,
if (smmu_domain->non_strict)
pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
 
+   if (smmu_domain->pgtbl_cfg.quirks)
+   pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;
+
pgtbl_ops = alloc_io_pgtable_ops(fmt, _cfg, smmu_domain);
if (!pgtbl_ops) {
ret = -ENOMEM;
@@ -1511,6 +1514,12 @@ static int arm_smmu_domain_get_attr(struct iommu_domain 
*domain,
case DOMAIN_ATTR_NESTING:
*(int *)data = (smmu_domain->stage == 
ARM_SMMU_DOMAIN_NESTED);
return 0;
+   case DOMAIN_ATTR_IO_PGTABLE_CFG: {
+   struct io_pgtable_domain_attr *pgtbl_cfg = data;
+   *pgtbl_cfg = smmu_domain->pgtbl_cfg;
+
+   return 0;
+   }
default:
return -ENODEV;
}
@@ -1551,6 +1560,17 @@ static int arm_smmu_domain_set_attr(struct iommu_domain 
*domain,
else
smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
break;
+   case DOMAIN_ATTR_IO_PGTABLE_CFG: {
+   struct io_pgtable_domain_attr *pgtbl_cfg = data;
+
+   if (smmu_domain->smmu) {
+   ret = -EPERM;
+   goto out_unlock;
+   }
+
+   smmu_domain->pgtbl_cfg = *pgtbl_cfg;
+   break;
+   }
default:
ret = -ENODEV;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h 
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 04288b6fc619..bb5a419f240f 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -364,6 +364,7 @@ enum arm_smmu_domain_stage {
 struct arm_smmu_domain {
struct arm_smmu_device  *smmu;
struct io_pgtable_ops   *pgtbl_ops;
+   struct io_pgtable_domain_attr   pgtbl_cfg;
const struct iommu_flush_ops*flush_ops;
struct arm_smmu_cfg cfg;
enum arm_smmu_domain_stage  stage;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv10 0/9] System Cache support for GPU and required SMMU support

Some hardware variants contain a system cache or the last level
cache(llc). This cache is typically a large block which is shared
by multiple clients on the SOC. GPU uses the system cache to cache
both the GPU data buffers(like textures) as well the SMMU pagetables.
This helps with improved render performance as well as lower power
consumption by reducing the bus traffic to the system memory.

The system cache architecture allows the cache to be split into slices
which then be used by multiple SOC clients. This patch series is an
effort to enable and use two of those slices preallocated for the GPU,
one for the GPU data buffers and another for the GPU SMMU hardware
pagetables.

Patch 1 - Patch 7 adds system cache support in SMMU and GPU driver.
Patch 8 and 9 are minor cleanups for arm-smmu impl.

Changes in v10:
 * Fix non-strict mode domain attr handling (Will)
 * Split the domain attribute patch into two (Will)

Changes in v9:
 * Change name from domain_attr_io_pgtbl_cfg to io_pgtable_domain_attr (Will)
 * Modify comment for the quirk as suggested (Will)
 * Compare with IO_PGTABLE_QUIRK_NON_STRICT for non-strict mode (Will)

Changes in v8:
 * Introduce a generic domain attribute for pagetable config (Will)
 * Rename quirk to more generic IO_PGTABLE_QUIRK_ARM_OUTER_WBWA (Will)
 * Move non-strict mode to use new struct domain_attr_io_pgtbl_config (Will)

Changes in v7:
 * Squash Jordan's patch to support MMU500 targets
 * Rebase on top of for-joerg/arm-smmu/updates and Jordan's short series for 
adreno-smmu impl

Changes in v6:
 * Move table to arm-smmu-qcom (Robin)

Changes in v5:
 * Drop cleanup of blank lines since it was intentional (Robin)
 * Rebase again on top of msm-next-pgtables as it moves pretty fast

Changes in v4:
 * Drop IOMMU_SYS_CACHE prot flag
 * Rebase on top of 
https://gitlab.freedesktop.org/drm/msm/-/tree/msm-next-pgtables

Changes in v3:
 * Fix domain attribute setting to before iommu_attach_device()
 * Fix few code style and checkpatch warnings
 * Rebase on top of Jordan's latest split pagetables and per-instance
   pagetables support

Changes in v2:
 * Addressed review comments and rebased on top of Jordan's split
   pagetables series

Jordan Crouse (1):
  drm/msm/a6xx: Add support for using system cache on MMU500 based
targets

Sai Prakash Ranjan (6):
  iommu/io-pgtable: Add a domain attribute for pagetable configuration
  iommu/io-pgtable-arm: Add support to use system cache
  iommu/arm-smmu: Add support for pagetable config domain attribute
  iommu/arm-smmu: Move non-strict mode to use io_pgtable_domain_attr
  iommu: arm-smmu-impl: Use table to list QCOM implementations
  iommu: arm-smmu-impl: Add a space before open parenthesis

Sharat Masetty (2):
  drm/msm: rearrange the gpu_rmw() function
  drm/msm/a6xx: Add support for using system cache(LLC)

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  | 109 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   5 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|  17 
 drivers/gpu/drm/msm/msm_drv.c  |   8 ++
 drivers/gpu/drm/msm/msm_drv.h  |   1 +
 drivers/gpu/drm/msm/msm_gpu.h  |   5 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-impl.c |  11 +--
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c |  21 +++-
 drivers/iommu/arm/arm-smmu/arm-smmu.c  |  33 ++-
 drivers/iommu/arm/arm-smmu/arm-smmu.h  |   3 +-
 drivers/iommu/io-pgtable-arm.c |  10 +-
 include/linux/io-pgtable.h |   8 ++
 include/linux/iommu.h  |   1 +
 13 files changed, 205 insertions(+), 27 deletions(-)


base-commit: a29bbb0861f487a5e144dc997a9f71a36c7a2404
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv10 2/9] iommu/io-pgtable-arm: Add support to use system cache

Add a quirk IO_PGTABLE_QUIRK_ARM_OUTER_WBWA to override
the outer-cacheability attributes set in the TCR for a
non-coherent page table walker when using system cache.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/io-pgtable-arm.c | 10 --
 include/linux/io-pgtable.h |  4 
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index a7a9bc08dcd1..7c9ea9d7874a 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -761,7 +761,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, 
void *cookie)
 
if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
IO_PGTABLE_QUIRK_NON_STRICT |
-   IO_PGTABLE_QUIRK_ARM_TTBR1))
+   IO_PGTABLE_QUIRK_ARM_TTBR1 |
+   IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
return NULL;
 
data = arm_lpae_alloc_pgtable(cfg);
@@ -773,10 +774,15 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, 
void *cookie)
tcr->sh = ARM_LPAE_TCR_SH_IS;
tcr->irgn = ARM_LPAE_TCR_RGN_WBWA;
tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
+   if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)
+   goto out_free_data;
} else {
tcr->sh = ARM_LPAE_TCR_SH_OS;
tcr->irgn = ARM_LPAE_TCR_RGN_NC;
-   tcr->orgn = ARM_LPAE_TCR_RGN_NC;
+   if (!(cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
+   tcr->orgn = ARM_LPAE_TCR_RGN_NC;
+   else
+   tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
}
 
tg1 = cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 215fd9d69540..fb4d5a763e0c 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -86,6 +86,9 @@ struct io_pgtable_cfg {
 *
 * IO_PGTABLE_QUIRK_ARM_TTBR1: (ARM LPAE format) Configure the table
 *  for use in the upper half of a split address space.
+*
+* IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the outer-cacheability
+*  attributes set in the TCR for a non-coherent page-table walker.
 */
#define IO_PGTABLE_QUIRK_ARM_NS BIT(0)
#define IO_PGTABLE_QUIRK_NO_PERMS   BIT(1)
@@ -93,6 +96,7 @@ struct io_pgtable_cfg {
#define IO_PGTABLE_QUIRK_ARM_MTK_EXTBIT(3)
#define IO_PGTABLE_QUIRK_NON_STRICT BIT(4)
#define IO_PGTABLE_QUIRK_ARM_TTBR1  BIT(5)
+   #define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA BIT(6)
unsigned long   quirks;
unsigned long   pgsize_bitmap;
unsigned intias;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] bus: fsl-mc: added missing fields to dprc_rsp_get_obj_region structure

2020-11-24 Thread Ioana Ciornei

On Tue, Nov 24, 2020 at 01:12:00PM +0200, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor 
> 
> 'type' and 'flags' fields were missing from dprc_rsp_get_obj_region
> structure therefore the MC Bus driver was not receiving proper flags
> from MC like DPRC_REGION_CACHEABLE.
> 
> Signed-off-by: Cristian Sovaiala 
> Signed-off-by: Laurentiu Tudor 

Reviewed-by: Ioana Ciornei 

> ---
>  drivers/bus/fsl-mc/dprc.c   | 2 ++
>  drivers/bus/fsl-mc/fsl-mc-private.h | 5 +++--
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bus/fsl-mc/dprc.c b/drivers/bus/fsl-mc/dprc.c
> index 57b097caf255..27b0a01bad9b 100644
> --- a/drivers/bus/fsl-mc/dprc.c
> +++ b/drivers/bus/fsl-mc/dprc.c
> @@ -576,6 +576,8 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
>   rsp_params = (struct dprc_rsp_get_obj_region *)cmd.params;
>   region_desc->base_offset = le64_to_cpu(rsp_params->base_offset);
>   region_desc->size = le32_to_cpu(rsp_params->size);
> + region_desc->type = rsp_params->type;
> + region_desc->flags = le32_to_cpu(rsp_params->flags);
>   if (dprc_major_ver > 6 || (dprc_major_ver == 6 && dprc_minor_ver >= 3))
>   region_desc->base_address = le64_to_cpu(rsp_params->base_addr);
>   else
> diff --git a/drivers/bus/fsl-mc/fsl-mc-private.h 
> b/drivers/bus/fsl-mc/fsl-mc-private.h
> index 85ca5fdee581..c932387641fa 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-private.h
> +++ b/drivers/bus/fsl-mc/fsl-mc-private.h
> @@ -211,12 +211,13 @@ struct dprc_cmd_get_obj_region {
>  
>  struct dprc_rsp_get_obj_region {
>   /* response word 0 */
> - __le64 pad;
> + __le64 pad0;
>   /* response word 1 */
>   __le64 base_offset;
>   /* response word 2 */
>   __le32 size;
> - __le32 pad2;
> + u8 type;
> + u8 pad2[3];
>   /* response word 3 */
>   __le32 flags;
>   __le32 pad3;
> -- 
> 2.17.1
>

[PATCHv10 1/9] iommu/io-pgtable: Add a domain attribute for pagetable configuration

Add a new iommu domain attribute DOMAIN_ATTR_IO_PGTABLE_CFG
for pagetable configuration which initially will be used to
set quirks like for system cache aka last level cache to be
used by client drivers like GPU to set right attributes for
caching the hardware pagetables into the system cache and
later can be extended to include other page table configuration
data.

Signed-off-by: Sai Prakash Ranjan 
---
 include/linux/io-pgtable.h | 4 
 include/linux/iommu.h  | 1 +
 2 files changed, 5 insertions(+)

diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 4cde111e425b..215fd9d69540 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -208,6 +208,10 @@ struct io_pgtable {
 
 #define io_pgtable_ops_to_pgtable(x) container_of((x), struct io_pgtable, ops)
 
+struct io_pgtable_domain_attr {
+   unsigned long quirks;
+};
+
 static inline void io_pgtable_tlb_flush_all(struct io_pgtable *iop)
 {
iop->cfg.tlb->tlb_flush_all(iop->cookie);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b95a6f8db6ff..ffaa389ea128 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -118,6 +118,7 @@ enum iommu_attr {
DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_NESTING,/* two stages of translation */
DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
+   DOMAIN_ATTR_IO_PGTABLE_CFG,
DOMAIN_ATTR_MAX,
 };
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv10 5/9] drm/msm: rearrange the gpu_rmw() function

From: Sharat Masetty 

The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.

Signed-off-by: Sharat Masetty 
Reviewed-by: Jordan Crouse 
Signed-off-by: Sai Prakash Ranjan 
---
 drivers/gpu/drm/msm/msm_drv.c | 8 
 drivers/gpu/drm/msm/msm_drv.h | 1 +
 drivers/gpu/drm/msm/msm_gpu.h | 5 +
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 49685571dc0e..a1e22b974b77 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -180,6 +180,14 @@ u32 msm_readl(const void __iomem *addr)
return val;
 }
 
+void msm_rmw(void __iomem *addr, u32 mask, u32 or)
+{
+   u32 val = msm_readl(addr);
+
+   val &= ~mask;
+   msm_writel(val | or, addr);
+}
+
 struct msm_vblank_work {
struct work_struct work;
int crtc_id;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b9dd8f8f4887..655b3b0424a1 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -478,6 +478,7 @@ void __iomem *msm_ioremap_quiet(struct platform_device 
*pdev, const char *name,
const char *dbgname);
 void msm_writel(u32 data, void __iomem *addr);
 u32 msm_readl(const void __iomem *addr);
+void msm_rmw(void __iomem *addr, u32 mask, u32 or);
 
 struct msm_gpu_submitqueue;
 int msm_submitqueue_init(struct drm_device *drm, struct msm_file_private *ctx);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 6c9e1fdc1a76..b2b419277953 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -246,10 +246,7 @@ static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
 
 static inline void gpu_rmw(struct msm_gpu *gpu, u32 reg, u32 mask, u32 or)
 {
-   uint32_t val = gpu_read(gpu, reg);
-
-   val &= ~mask;
-   gpu_write(gpu, reg, val | or);
+   msm_rmw(gpu->mmio + (reg << 2), mask, or);
 }
 
 static inline u64 gpu_read64(struct msm_gpu *gpu, u32 lo, u32 hi)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCHv9 2/8] iommu/arm-smmu: Add domain attribute for pagetable configuration


On 2020-11-25 03:11, Will Deacon wrote:

On Mon, Nov 23, 2020 at 10:35:55PM +0530, Sai Prakash Ranjan wrote:

Add iommu domain attribute for pagetable configuration which
initially will be used to set quirks like for system cache aka
last level cache to be used by client drivers like GPU to set
right attributes for caching the hardware pagetables into the
system cache and later can be extended to include other page
table configuration data.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 20 
 drivers/iommu/arm/arm-smmu/arm-smmu.h |  1 +
 include/linux/io-pgtable.h|  4 
 include/linux/iommu.h |  1 +
 4 files changed, 26 insertions(+)


Given that we're heading for a v10 to address my comments on patch 3,
then I guess you may as well split this into two patches so that I can
share just the atttibute with Rob rather than the driver parts.

Please keep it all as one series though, with the common parts at the
beginning, and I'll figure it out.



Ok I will split up and send v10.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [RFC] dcss: fix attaching to sn56dsi86 bridge

2020-11-24 Thread Laurentiu Palcu

Hi Lukas,

On Tue, Nov 24, 2020 at 06:19:57PM +0100, Lukas F. Hartmann wrote:
> The sn56dsi86 DSI to eDP bridge driver does not support attaching
> without a drm connector.

I think the SN65DSI86 driver is exactly what you should focus on, so
that it works when connector is optional. The ADV7511/ADV7533/ADV7535
driver provides the best example on how it should be done.

Thanks,
laurentiu

> This patch makes the attachment work. Required for the display chain
> in MNT Reform 2.0 (DCSS->NWL DSI->SN56DSI86->EDP).
> 
> Signed-off-by: Lukas F. Hartmann 
> ---
>  drivers/gpu/drm/imx/dcss/dcss-kms.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c 
> b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> index 135a62366..4967f828b 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> @@ -82,6 +82,7 @@ static int dcss_kms_bridge_connector_init(struct 
> dcss_kms_dev *kms)
>   struct drm_crtc *crtc = (struct drm_crtc *)>crtc;
>   struct drm_panel *panel;
>   struct drm_bridge *bridge;
> + struct drm_connector_list_iter iter;
>   int ret;
> 
>   ret = drm_of_find_panel_or_bridge(ddev->dev->of_node, 0, 0,
> @@ -104,19 +105,19 @@ static int dcss_kms_bridge_connector_init(struct 
> dcss_kms_dev *kms)
>   return ret;
>   }
> 
> - ret = drm_bridge_attach(encoder, bridge, NULL,
> - DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> + ret = drm_bridge_attach(encoder, bridge, NULL, 0);
>   if (ret < 0) {
>   dev_err(ddev->dev, "Unable to attach bridge %pOF\n",
>   bridge->of_node);
>   return ret;
>   }
> 
> - kms->connector = drm_bridge_connector_init(ddev, encoder);
> - if (IS_ERR(kms->connector)) {
> - dev_err(ddev->dev, "Unable to create bridge connector.\n");
> - return PTR_ERR(kms->connector);
> - }
> + /*
> +  * This hack to look up the connector is copied from mxsfb.
> +  */
> + drm_connector_list_iter_begin(ddev, );
> + kms->connector = drm_connector_list_iter_next();
> + drm_connector_list_iter_end();
> 
>   drm_connector_attach_encoder(kms->connector, encoder);
> 
> --
> 2.28.0

RE: [PATCH v3 00/10] Introduced new Cadence USBSSP DRD Driver.

2020-11-24 Thread Peter Chen



> >>>
> >>> The device side of USBSS DRD controller is compliant with XHCI.
> >>> The architecture for device side is almost the same as for host
> >>> side, and most of the XHCI specification can be used to understand
> >>> how this controller operates.
> >>>
> >>> This controller and driver support Full Speed, Hight Speed, Supper
> >>> Speed and Supper Speed Plus USB protocol.
> >>>
> >>> The prefix cdnsp used in driver has chosen by analogy to cdn3 driver.
> >>> The last letter of this acronym means PLUS. The formal name of
> >>> controller is USBSSP but it's to generic so I've decided to use CDNSP.
> >>>
> >>> The patch 1: adds support for DRD CDNSP.
> >>> The patch 2: separates common code that can be reusable by cdnsp driver.
> >>> The patch 3: moves reusable code to separate module.
> >>> The patch 4: changes prefixes in reusable code from cdns3 to common
> cdns.
> >>> The patch 5: adopts gadget_dev pointer in cdns structure to make possible
> >>>  use it in both drivers.
> >>> The patches 6-8: add the main part of driver and has been intentionally
> >>>  split into 3 part. In my opinion such division should not
> >>>  affect understanding and reviewing the driver, and cause
> that
> >>>  main patch (7/8) is little smaller. Patch 6 introduces main
> >>>  header file for driver, 7 is the main part that implements
> all
> >>>  functionality of driver and 8 introduces tracepoints.
> >>> The patch 9: Adds cdns3 prefixes to files related with USBSS driver.
> >>> the patch 10: Adds USBSSP DRD IP driver entry to MAINTAINERS file.
> >>>
> >>> Changlog from v2:
> >>> - removed not used pdev parameter from cdnsp_read/wite_64 functions
> >>> - fixed incorrect value assigned to CDNSP_ENDPOINTS_NUM (32 -> 31)
> >>> - replaced some constant value with CDNSP_ENDPOINTS_NUM macro
> >>> - replaced 'true' with '1' in bits description in cdnsp-gadget.h
> >>> file
> >>> - fixed some typos
> >>> - some other less important changes suggested by Peter Chen
> >>
> >>Hi Pawel,
> >>
> >>I have updated my -next tree as the latest usb-next tree which
> >>v5.10-rc4 is included, would you please rebase my tree and send again,
> >>I could apply your patches and test, if test could pass, I will apply it to 
> >>my
> -next tree.
> >>You don't need to rebase again since it is a huge patch set, will take
> >>some efforts for rebase.
> >>
> >
> >I'll try to post it tomorrow.
> 
> Can I send the new version CDNSP or I should wait for completion
> 'Re: [PATCH] Revert "usb: cdns3: core: quit if it uses role switch class"' and
> applying the appropriate fix to your repo ?
> 
 
Please wait that fix, thanks.

Peter

[PATCH bpf v2 0/2] xsk: fix for xsk_poll writeable

2020-11-24 Thread Xuan Zhuo

Thanks for magnus very much.

V2:
   #2 patch made some changes following magnus' opinions.

Xuan Zhuo (2):
  xsk: replace datagram_poll by sock_poll_wait
  xsk: change the tx writeable condition

 net/xdp/xsk.c   | 20 
 net/xdp/xsk_queue.h |  6 ++
 2 files changed, 22 insertions(+), 4 deletions(-)

--
1.8.3.1

[PATCH bpf v2 2/2] xsk: change the tx writeable condition

2020-11-24 Thread Xuan Zhuo

Modify the tx writeable condition from the queue is not full to the
number of present tx queues is less than the half of the total number
of queues. Because the tx queue not full is a very short time, this will
cause a large number of EPOLLOUT events, and cause a large number of
process wake up.

Signed-off-by: Xuan Zhuo 
---
 net/xdp/xsk.c   | 16 +---
 net/xdp/xsk_queue.h |  6 ++
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index 0df8651..22e35e9 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -211,6 +211,14 @@ static int __xsk_rcv(struct xdp_sock *xs, struct xdp_buff 
*xdp, u32 len,
return 0;
 }
 
+static bool xsk_tx_writeable(struct xdp_sock *xs)
+{
+   if (xskq_cons_present_entries(xs->tx) > xs->tx->nentries / 2)
+   return false;
+
+   return true;
+}
+
 static bool xsk_is_bound(struct xdp_sock *xs)
 {
if (READ_ONCE(xs->state) == XSK_BOUND) {
@@ -296,7 +304,8 @@ void xsk_tx_release(struct xsk_buff_pool *pool)
rcu_read_lock();
list_for_each_entry_rcu(xs, >xsk_tx_list, tx_list) {
__xskq_cons_release(xs->tx);
-   xs->sk.sk_write_space(>sk);
+   if (xsk_tx_writeable(xs))
+   xs->sk.sk_write_space(>sk);
}
rcu_read_unlock();
 }
@@ -499,7 +508,8 @@ static int xsk_generic_xmit(struct sock *sk)
 
 out:
if (sent_frame)
-   sk->sk_write_space(sk);
+   if (xsk_tx_writeable(xs))
+   sk->sk_write_space(sk);
 
mutex_unlock(>mutex);
return err;
@@ -556,7 +566,7 @@ static __poll_t xsk_poll(struct file *file, struct socket 
*sock,
 
if (xs->rx && !xskq_prod_is_empty(xs->rx))
mask |= EPOLLIN | EPOLLRDNORM;
-   if (xs->tx && !xskq_cons_is_full(xs->tx))
+   if (xs->tx && xsk_tx_writeable(xs))
mask |= EPOLLOUT | EPOLLWRNORM;
 
return mask;
diff --git a/net/xdp/xsk_queue.h b/net/xdp/xsk_queue.h
index b936c46..b655004 100644
--- a/net/xdp/xsk_queue.h
+++ b/net/xdp/xsk_queue.h
@@ -307,6 +307,12 @@ static inline bool xskq_cons_is_full(struct xsk_queue *q)
q->nentries;
 }
 
+static inline __u64 xskq_cons_present_entries(struct xsk_queue *q)
+{
+   /* No barriers needed since data is not accessed */
+   return READ_ONCE(q->ring->producer) - READ_ONCE(q->ring->consumer);
+}
+
 /* Functions for producers */
 
 static inline u32 xskq_prod_nb_free(struct xsk_queue *q, u32 max)
-- 
1.8.3.1

[PATCH bpf v2 1/2] xsk: replace datagram_poll by sock_poll_wait

2020-11-24 Thread Xuan Zhuo

datagram_poll will judge the current socket status (EPOLLIN, EPOLLOUT)
based on the traditional socket information (eg: sk_wmem_alloc), but
this does not apply to xsk. So this patch uses sock_poll_wait instead of
datagram_poll, and the mask is calculated by xsk_poll.

Signed-off-by: Xuan Zhuo 
---
 net/xdp/xsk.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index b014197..0df8651 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -534,11 +534,13 @@ static int xsk_sendmsg(struct socket *sock, struct msghdr 
*m, size_t total_len)
 static __poll_t xsk_poll(struct file *file, struct socket *sock,
 struct poll_table_struct *wait)
 {
-   __poll_t mask = datagram_poll(file, sock, wait);
+   __poll_t mask = 0;
struct sock *sk = sock->sk;
struct xdp_sock *xs = xdp_sk(sk);
struct xsk_buff_pool *pool;
 
+   sock_poll_wait(file, sock, wait);
+
if (unlikely(!xsk_is_bound(xs)))
return mask;
 
-- 
1.8.3.1

Re: possible deadlock in _destroy_id

2020-11-24 Thread Leon Romanovsky

On Wed, Nov 18, 2020 at 09:37:56AM -0400, Jason Gunthorpe wrote:
> On Wed, Nov 18, 2020 at 03:10:21AM -0800, syzbot wrote:
>
> > HEAD commit:20529233 Add linux-next specific files for 20201118
> > git tree:   linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13093cf250
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=2c4fb58b6526b3c1
> > dashboard link: https://syzkaller.appspot.com/bug?extid=1bc48bf7f78253f664a9
> > compiler:   gcc (GCC) 10.1.0-syz 20200507
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
>
> Oh? Is this because the error injection is too random?
>
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+1bc48bf7f78253f66...@syzkaller.appspotmail.com
> >
> > iwpm_register_pid: Unable to send a nlmsg (client = 2)
> > infiniband syz1: RDMA CMA: cma_listen_on_dev, error -98
> > 
> > WARNING: possible recursive locking detected
> > 5.10.0-rc4-next-20201118-syzkaller #0 Not tainted
> > syz-executor.5/12844 is trying to acquire lock:
> > 8c684748 (lock#6){+.+.}-{3:3}, at: cma_release_dev 
> > drivers/infiniband/core/cma.c:476 [inline]
> > 8c684748 (lock#6){+.+.}-{3:3}, at: _destroy_id+0x299/0xa00 
> > drivers/infiniband/core/cma.c:1852
> >
> > but task is already holding lock:
> > 8c684748 (lock#6){+.+.}-{3:3}, at: cma_add_one+0x55c/0xce0 
> > drivers/infiniband/core/cma.c:4902
>
> Leon, this is caused by
>
> commit c80a0c52d85c49a910d0dc0e342e8d8898677dc0
> Author: Leon Romanovsky 
> Date:   Wed Nov 4 16:40:07 2020 +0200
>
> RDMA/cma: Add missing error handling of listen_id
>
> Don't silently continue if rdma_listen() fails but destroy previously
> created CM_ID and return an error to the caller.
>
> rdma_destroy_id() can't be called while holding the global lock
>
> This is quite hard to fix. I came up with this ugly thing:
>
> From 8e6568f99fbe4bf734cc4e5dcda987e4ae118bdd Mon Sep 17 00:00:00 2001
> From: Jason Gunthorpe 
> Date: Wed, 18 Nov 2020 09:33:23 -0400
> Subject: [PATCH] RDMA/cma: Fix deadlock on  in rdma_cma_listen_on_all()
>  error unwind
>
> rdma_detroy_id() cannot be called under  - we must instead keep the
> error'd ID around until  can be released, then destory it.
>
> This is complicated by the usual way listen IDs are destroyed through
> cma_process_remove() which can run at any time and will asynchronously
> destroy the same ID.
>
> Remove the ID from visiblity of cma_process_remove() before going down the
> destroy path outside the locking.
>
> Fixes: c80a0c52d85c ("RDMA/cma: Add missing error handling of listen_id")
> Reported-by: syzbot+1bc48bf7f78253f66...@syzkaller.appspotmail.com
> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/infiniband/core/cma.c | 25 ++---
>  1 file changed, 18 insertions(+), 7 deletions(-)
>

Thanks,
Reviewed-by: Leon Romanovsky

[PATCH] soc: qcom: pdr: Fix error return code in pdr_register_listener

Fix to return the error code -EREMOTEIO from pdr_register_listener
rather than 0.

Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Reported-by: Hulk Robot 
Signed-off-by: Qinglang Miao 
---
 drivers/soc/qcom/pdr_interface.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
index 088dc99f7..3da12ec2a 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -153,6 +153,7 @@ static int pdr_register_listener(struct pdr_handle *pdr,
if (resp.resp.result != QMI_RESULT_SUCCESS_V01) {
pr_err("PDR: %s register listener failed: 0x%x\n",
   pds->service_path, resp.resp.error);
+   ret = -EREMOTEIO;
return ret;
}
 
-- 
2.23.0

[PATCH] soundwire: Fix error return code in sdw_compute_port_params

Fix to return the error code -EINVAL in sdw_compute_port_params
instead of 0.

Fixes: 9026118f20e2 ("soundwire: Add generic bandwidth allocation algorithm")
Reported-by: Hulk Robot 
Signed-off-by: Qinglang Miao 
---
 drivers/soundwire/generic_bandwidth_allocation.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/soundwire/generic_bandwidth_allocation.c 
b/drivers/soundwire/generic_bandwidth_allocation.c
index 0bdef38c9..ad857ac62 100644
--- a/drivers/soundwire/generic_bandwidth_allocation.c
+++ b/drivers/soundwire/generic_bandwidth_allocation.c
@@ -283,8 +283,10 @@ static int sdw_compute_port_params(struct sdw_bus *bus)
if (ret < 0)
return ret;
 
-   if (group.count == 0)
+   if (group.count == 0) {
+   ret = -EINVAL;
goto out;
+   }
 
params = kcalloc(group.count, sizeof(*params), GFP_KERNEL);
if (!params) {
-- 
2.23.0

[PATCH] platform/x86: dell-smbios-base: Fix error return code in dell_smbios_init

Fix to return the error code -ENODEV when fails to init wmi and
smm.

Fixes: 41e36f2f85af ("platform/x86: dell-smbios: Link all dell-smbios-* modules 
together")
Reported-by: Hulk Robot 
Signed-off-by: Qinglang Miao 
---
 drivers/platform/x86/dell-smbios-base.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/dell-smbios-base.c 
b/drivers/platform/x86/dell-smbios-base.c
index 2e2cd5659..3a1dbf199 100644
--- a/drivers/platform/x86/dell-smbios-base.c
+++ b/drivers/platform/x86/dell-smbios-base.c
@@ -594,6 +594,7 @@ static int __init dell_smbios_init(void)
if (wmi && smm) {
pr_err("No SMBIOS backends available (wmi: %d, smm: %d)\n",
wmi, smm);
+   ret = -ENODEV;
goto fail_create_group;
}
 
-- 
2.23.0

[PATCH] fpga: dfl: add missing platform_device_put in build_info_create_dev

platform_device_put is missing when it fails to set fdev->id. Set
a temp value to do sanity check.

Fixes: 543be3d8c999 ("fpga: add device feature list support")
Reported-by: Hulk Robot 
Signed-off-by: Qinglang Miao 
---
 drivers/fpga/dfl.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index b450870b7..8958f0860 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -877,10 +877,13 @@ build_info_create_dev(struct build_feature_devs_info 
*binfo,
 
INIT_LIST_HEAD(>sub_features);
 
-   fdev->id = dfl_id_alloc(type, >dev);
-   if (fdev->id < 0)
-   return fdev->id;
+   int tmp_id = dfl_id_alloc(type, >dev);
+   if (tmp_id < 0) {
+   platform_device_put(fdev);
+   return tmp_id;
+   }
 
+   fdev->id = tmp_id;
fdev->dev.parent = >cdev->region->dev;
fdev->dev.devt = dfl_get_devt(dfl_devs[type].devt_type, fdev->id);
 
-- 
2.23.0

[PATCH] xfs: check the return value of krealloc() in xfs_uuid_mount

krealloc() may fail to expand the memory space. Add sanity checks to it,
and WARN() if that really happened.

Fixes: 771915c4f688 ("xfs: remove kmem_realloc()")
Reported-by: Hulk Robot 
Signed-off-by: Qinglang Miao 
---
 fs/xfs/xfs_mount.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 150ee5cb8..c07f48c32 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -80,9 +80,13 @@ xfs_uuid_mount(
}
 
if (hole < 0) {
-   xfs_uuid_table = krealloc(xfs_uuid_table,
+   uuid_t *if_xfs_uuid_table;
+   if_xfs_uuid_table = krealloc(xfs_uuid_table,
(xfs_uuid_table_size + 1) * sizeof(*xfs_uuid_table),
GFP_KERNEL | __GFP_NOFAIL);
+   if (!if_xfs_uuid_table)
+   goto out_duplicate;
+   xfs_uuid_table = if_xfs_uuid_table;
hole = xfs_uuid_table_size++;
}
xfs_uuid_table[hole] = *uuid;
-- 
2.23.0

[PATCH] scsi: aic94xx: Fix error return code in asd_process_ms

Fix to return the error code -EINVAL when size == 0 after
asd_find_flash_de instead of zero.

Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
Reported-by: Hulk Robot 
Signed-off-by: Qinglang Miao 
---
 drivers/scsi/aic94xx/aic94xx_sds.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/aic94xx/aic94xx_sds.c 
b/drivers/scsi/aic94xx/aic94xx_sds.c
index 105adba55..3aad00458 100644
--- a/drivers/scsi/aic94xx/aic94xx_sds.c
+++ b/drivers/scsi/aic94xx/aic94xx_sds.c
@@ -860,8 +860,10 @@ static int asd_process_ms(struct asd_ha_struct *asd_ha,
goto out;
}
 
-   if (size == 0)
+   if (size == 0) {
+   err = -EINVAL;
goto out;
+   }
 
err = -ENOMEM;
manuf_sec = kmalloc(size, GFP_KERNEL);
@@ -989,8 +991,10 @@ static int asd_process_ctrl_a_user(struct asd_ha_struct 
*asd_ha,
goto out_process;
}
 
-   if (size == 0)
+   if (size == 0) {
+   err = -EINVAL;
goto out;
+   }
 
err = -ENOMEM;
el = kmalloc(size, GFP_KERNEL);
-- 
2.23.0

Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock_skip on reserved pages

2020-11-24 Thread David Hildenbrand



> Am 25.11.2020 um 06:34 schrieb Andrea Arcangeli :
> 
> Hello,
> 
>> On Mon, Nov 23, 2020 at 02:01:16PM +0100, Vlastimil Babka wrote:
>>> On 11/21/20 8:45 PM, Andrea Arcangeli wrote:
>>> A corollary issue was fixed in
>>> 39639000-39814fff : Unknown E820 type
>>> 
>>> pfn 0x7a200 -> 0x7a20 min_pfn hit non-RAM:
>>> 
>>> 7a17b000-7a216fff : Unknown E820 type
>> 
>> It would be nice to also provide a /proc/zoneinfo and how exactly the 
>> "zone_spans_pfn" was violated. I assume we end up below zone's 
>> start_pfn, but is it true?
> 
> Agreed, I was about to grab that info along with all page struct
> around the pfn 0x7a200 and phys address 0x7a216fff.
> 
> # grep -A1 E820 /proc/iomem
> 7a17b000-7a216fff : Unknown E820 type
> 7a217000-7bff : System RAM
> 
> DMA  zone_start_pfn 1zone_end_pfn() 4096 contiguous 1 
> 
> DMA32zone_start_pfn 4096 zone_end_pfn() 1048576  contiguous 0 
> 
> Normal   zone_start_pfn 1048576  zone_end_pfn() 4715392  contiguous 1 
> 
> Movable  zone_start_pfn 0zone_end_pfn() 0contiguous 0 
> 
> 
> 500222 0x7a1fe000 0x1fff1000 reserved True
> 500223 0x7a1ff000 0x1fff1000 reserved True
> 
> # I suspect "highest pfn" was somewhere in the RAM range
> # 0x7a217000-0x7a40 and the pageblock_start_pfn(pfn)
> # made highest point to pfn 0x7a200 physaddr 0x7a20
> # below, which is reserved indeed since it's non-RAM
> # first number is pfn hex(500224) == 0x7a200
> 
> pfnphysaddr   page->flags
> 500224 0x7a20 0x1fff1000 reserved True
> 500225 0x7a201000 0x1fff1000 reserved True
> *snip*
> 500245 0x7a215000 0x1fff1000 reserved True
> 500246 0x7a216000 0x1fff1000 reserved True
> 500247 0x7a217000 0x3fff reserved False
> 500248 0x7a218000 0x3fff reserved False
> 
> All RAM pages non-reserved are starting at 0x7a217000 as expected.
> 
> The non-RAM page_zonenum(pfn_to_page(0x7a200)) points to ZONE_DMA and 
> page_zone(page) below was the DMA zone despite the pfn of 0x7a200 is
> in DMA32.
> 
>VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page);
> 
> So the patch I sent earlier should prevent the above BUG_ON by not
> setting highest to 0x7a200 when pfn is in the phys RAM range
> 0x7a217000-0x7a40, because pageblock_pfn_to_page will notice that
> the zone is the wrong one.
> 
>if (page_zone(start_page) != zone)
>return NULL;
> 
> However the real bug seems that reserved pages have a zero zone_id in
> the page->flags when it should have the real zone id/nid. The patch I
> sent earlier to validate highest would only be needed to deal with
> pfn_valid.
> 
> Something must have changed more recently than v5.1 that caused the
> zoneid of reserved pages to be wrong, a possible candidate for the
> real would be this change below:
> 
> +   __init_single_page(pfn_to_page(pfn), pfn, 0, 0);
> 

Before that change, the memmap of memory holes were only zeroed out. So the 
zones/nid was 0, however, pages were not reserved and had a refcount of zero - 
resulting in other issues.

Most pfn walkers shouldn‘t mess with reserved pages and simply skip them. That 
would be the right fix here.

> Even if it may not be it, at the light of how the reserved page
> zoneid/nid initialized went wrong, the above line like it's too flakey
> to stay.
> 
> It'd be preferable if the pfn_valid fails and the
> pfn_to_section_nr(pfn) returns an invalid section for the intermediate
> step. Even better memset 0xff over the whole page struct until the
> second stage comes around.

I recently discussed with Baoquan to
1. Using a new pagetype to mark memory holes
2. Using special nid/zid to mark memory holes

Setting the memmap to 0xff would be even more dangerous - pfn_zone() might 
simply BUG_ON.

> 
> Whenever pfn_valid is true, it's better that the zoneid/nid is correct
> all times, otherwise if the second stage fails we end up in a bug with
> weird side effects.

Memory holes with a valid memmap might not have a zone/nid. For now, skipping 
reserved pages should be good enough, no?

> 
> Maybe it's not the above that left a zero zoneid though, I haven't
> tried to bisect it yet to look how the page->flags looked like on a
> older kernel that didn't seem to reproduce this crash, I'm just
> guessing.
> 
> Thanks,
> Andrea

linux-next: manual merge of the seccomp tree with the csky tree

2020-11-24 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the seccomp tree got a conflict in:

  arch/csky/include/asm/Kbuild

between commit:

  fed76f8679a6 ("csky: Add QUEUED_SPINLOCKS supported")

from the csky tree and commit:

  6e9ae6f98809 ("csky: Enable seccomp architecture tracking")

from the seccomp tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/csky/include/asm/Kbuild
index f814d46d347f,93372255984d..
--- a/arch/csky/include/asm/Kbuild
+++ b/arch/csky/include/asm/Kbuild
@@@ -3,9 -3,6 +3,8 @@@ generic-y += asm-offsets.
  generic-y += gpio.h
  generic-y += kvm_para.h
  generic-y += local64.h
 +generic-y += mcs_spinlock.h
  generic-y += qrwlock.h
 +generic-y += qspinlock.h
- generic-y += seccomp.h
  generic-y += user.h
  generic-y += vmlinux.lds.h


pgphpzzae6Jnn.pgp
Description: OpenPGP digital signature

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

Le 21/05/2020 à 12:38, Christophe Leroy a écrit :

Le 21/05/2020 à 09:02, Michael Ellerman a écrit :

Arnd Bergmann writes:

+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman wrote:

Benjamin Herrenschmidt writes:

On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:

Benjamin Herrenschmidt writes:

IBM still put 40x cores inside POWER chips no ?

Oh yeah that's true. I guess most folks don't know that, or that they
run RHEL on them.

Is there a reason for not having those dts files in mainline then?
If nothing else, it would document what machines are still being
used with future kernels.

Sorry that part was a joke :D Those chips don't run Linux.

Nice to know :)

What's the plan then, do we still want to keep 40x in the kernel ?

If yes, is it ok to drop the oldies anyway as done in my series
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=172630 ?

(Note that this series will conflict with my series on hugepages on 8xx due to the
PTE_ATOMIC_UPDATES stuff. I can rebase the 40x modernisation series on top of the 8xx hugepages
series if it is worth it)

Do we still want to keep 40x in the kernel ? We don't even have a running 40x QEMU machine as far as
I know.

I'm asking because I'd like to drop the non CONFIG_VMAP_STACK code to simplify and ease stuff (code
that works with vmalloc'ed stacks also works with stacks in linear memory), but I can't do it
because 40x doesn't have VMAP_STACK and should I implement it for 40x, I have to means to test it.

So it would ease things if we could drop 40x completely, unless someone there has a 40x platform to
test stuff.

Thanks
Christophe

Re: [PATCH] phy/mediatek: Make PHY_MTK_XSPHY depend on HAS_IOMEM and OF_ADDRESS to fix build errors

2020-11-24 Thread Tiezhu Yang


On 11/25/2020 02:27 PM, Chunfeng Yun wrote:

On Tue, 2020-11-24 at 19:31 -0800, Randy Dunlap wrote:

On 11/24/20 6:24 PM, Chunfeng Yun wrote:

Hi Tiezhu,

On Tue, 2020-11-24 at 17:47 +0800, Tiezhu Yang wrote:

devm_ioremap_resource() will be not built in lib/devres.c if
CONFIG_HAS_IOMEM is not set, of_address_to_resource() will be
not built in drivers/of/address.c if CONFIG_OF_ADDRESS is not
set, and then there exists two build errors about undefined
reference to "devm_ioremap_resource" and "of_address_to_resource"
in phy-mtk-xsphy.c under COMPILE_TEST and CONFIG_PHY_MTK_XSPHY,
make PHY_MTK_XSPHY depend on HAS_IOMEM and OF_ADDRESS to fix it.

Reported-by: kernel test robot 
Signed-off-by: Tiezhu Yang 
---
  drivers/phy/mediatek/Kconfig | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index 50c5e93..66df045 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -30,6 +30,8 @@ config PHY_MTK_XSPHY
tristate "MediaTek XS-PHY Driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
depends on OF

Hi Tiezhu,

Would you please help to put OF and OF_ADDRESS into one line as
following:
depends on OF && OF_ADDRESS.

Also please help to add them for PHY_MTK_TPHY.
And change the tile 'phy/mediatek: ...' as 'phy: mediatek: ...'


OK, no problem, I will do it.

Thanks,
Tiezhu



Thank you



+   depends on HAS_IOMEM
+   depends on OF_ADDRESS

Why not add them into deconfig but here? In fact I don't know which way
is better and follow the kernel rule.

Vinod and Kishon, do you have any suggestion about this?

Putting them into a defconfig won't prevent random build errors
while putting them here will (or at least should).

hi Randy,

Got it, thank you


select GENERIC_PHY
help
  Enable this to support the SuperSpeedPlus XS-PHY transceiver for

The patch LGTM.

Acked-by: Randy Dunlap 

thanks.

Re: [PATCH] phy/mediatek: Make PHY_MTK_XSPHY depend on HAS_IOMEM and OF_ADDRESS to fix build errors

2020-11-24 Thread Chunfeng Yun

On Tue, 2020-11-24 at 19:31 -0800, Randy Dunlap wrote:
> On 11/24/20 6:24 PM, Chunfeng Yun wrote:
> > Hi Tiezhu,
> > 
> > On Tue, 2020-11-24 at 17:47 +0800, Tiezhu Yang wrote:
> >> devm_ioremap_resource() will be not built in lib/devres.c if
> >> CONFIG_HAS_IOMEM is not set, of_address_to_resource() will be
> >> not built in drivers/of/address.c if CONFIG_OF_ADDRESS is not
> >> set, and then there exists two build errors about undefined
> >> reference to "devm_ioremap_resource" and "of_address_to_resource"
> >> in phy-mtk-xsphy.c under COMPILE_TEST and CONFIG_PHY_MTK_XSPHY,
> >> make PHY_MTK_XSPHY depend on HAS_IOMEM and OF_ADDRESS to fix it.
> >>
> >> Reported-by: kernel test robot 
> >> Signed-off-by: Tiezhu Yang 
> >> ---
> >>  drivers/phy/mediatek/Kconfig | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> >> index 50c5e93..66df045 100644
> >> --- a/drivers/phy/mediatek/Kconfig
> >> +++ b/drivers/phy/mediatek/Kconfig
> >> @@ -30,6 +30,8 @@ config PHY_MTK_XSPHY
> >>tristate "MediaTek XS-PHY Driver"
> >>depends on ARCH_MEDIATEK || COMPILE_TEST
> >>depends on OF
Hi Tiezhu,

Would you please help to put OF and OF_ADDRESS into one line as
following:
depends on OF && OF_ADDRESS.

Also please help to add them for PHY_MTK_TPHY.
And change the tile 'phy/mediatek: ...' as 'phy: mediatek: ...'

Thank you


> >> +  depends on HAS_IOMEM
> >> +  depends on OF_ADDRESS
> > Why not add them into deconfig but here? In fact I don't know which way
> > is better and follow the kernel rule.
> > 
> > Vinod and Kishon, do you have any suggestion about this?
> 
> Putting them into a defconfig won't prevent random build errors
> while putting them here will (or at least should).
hi Randy,

Got it, thank you

> 
> >>select GENERIC_PHY
> >>help
> >>  Enable this to support the SuperSpeedPlus XS-PHY transceiver for
> > 
> 
> The patch LGTM.
> 
> Acked-by: Randy Dunlap 
> 
> thanks.

Re: [LKP] Re: [mm/memcg] bd0b230fe1: will-it-scale.per_process_ops -22.7% regression

2020-11-24 Thread Feng Tang

On Fri, Nov 20, 2020 at 07:44:24PM +0800, Feng Tang wrote:
> On Fri, Nov 13, 2020 at 03:34:36PM +0800, Feng Tang wrote:
> > > I would rather focus on a more effective mem_cgroup layout. It is very
> > > likely that we are just stumbling over two counters here.
> > > 
> > > Could you try to add cache alignment of counters after memory and see
> > > which one makes the difference? I do not expect memsw to be the one
> > > because that one is used together with the main counter. But who knows
> > > maybe the way it crosses the cache line has the exact effect. Hard to
> > > tell without other numbers.
> > 
> > I added some alignments change around the 'memsw', but neither of them can
> > restore the -22.7%. Following are some log showing how the alignments
> > are:
> > 
> > tl: memcg=0x7cd1000 memory=0x7cd10d0 memsw=0x7cd1140 kmem=0x7cd11b0 
> > tcpmem=0x7cd1220
> > t2: memcg=0x7cd memory=0x7cd00d0 memsw=0x7cd0140 kmem=0x7cd01c0 
> > tcpmem=0x7cd0230
> > 
> > So both of the 'memsw' are aligned, but t2's 'kmem' is aligned while
> > t1's is not.
> > 
> > I will check more on the perf data about detailed hotspots.
> 
> Some more check updates about it:
> 
> Waiman's patch is effectively removing one 'struct page_counter' between
> 'memory' and "memsw'. And the mem_cgroup is: 
> 
> struct mem_cgroup {
> 
>   ...
> 
>   struct page_counter memory; /* Both v1 & v2 */
> 
>   union {
>   struct page_counter swap;   /* v2 only */
>   struct page_counter memsw;  /* v1 only */
>   };
> 
>   /* Legacy consumer-oriented counters */
>   struct page_counter kmem;   /* v1 only */
>   struct page_counter tcpmem; /* v1 only */
> 
>   ...
>   ...
> 
>   MEMCG_PADDING(_pad1_);
> 
>   atomic_tmoving_account;
>   struct task_struct  *move_lock_task;
>   
>   ...
> };
> 
> 
> I do experiments by inserting a 'page_counter' between 'memory'
> and the 'MEMCG_PADDING(_pad1_)', no matter where I put it, the
> benchmark result can be recovered from 145K to 185K, which is
> really confusing, as adding a 'page_counter' right before the
> '_pad1_' doesn't change cache alignment of any members.

I think we finally found the trick :), further debugging shows it
is not related to the alignment inside one cacheline, but the
adjacency of 2 adjacent cacheliens (2N and 2N+1, one pair of 128 bytes).

For structure mem_cgroup, member 'vmstats_local', 'vmstats_percpu'
sit in one cacheline, while 'vmstats[]' sits in the next cacheline,
and when 'adjacent cacheline prefetch" is enabled, if these 2 lines
sit in one pair (128 btyes), say 2N and 2N+1, then there seems to
be some kind of false sharing, and if they sit in 2 pairs, say
2N-1 and 2N then it's fine.

And with the following patch to relayout these members, the regression
is restored and event better. while reducing 64 bytes of sizeof
'struct mem_cgroup'

parent_commit   Waiman's_commit +relayout patch

result  187K145K200K

Also, if we disable the hw prefetch feature, the Waiman's commit
and its parent commit will have no performance difference.

Thanks,
Feng

>From 2e63af34fa4853b2dd9669867c37a3cf07f7a505 Mon Sep 17 00:00:00 2001
From: Feng Tang 
Date: Wed, 25 Nov 2020 13:22:21 +0800
Subject: [PATCH] mm: memcg: relayout structure mem_cgroup to avoid cache
 interfereing

0day reported one -22.7% regression for will-it-scale page_fault2
case [1] on a 4 sockets 144 CPU platform, and bisected to it to be
caused by Waiman's optimization (commit bd0b230fe1) of saving one
'struct page_counter' space for 'struct mem_cgroup'.

Initially we thought it was due to the cache alignment change introduced
by the patch, but further debug shows that it is due to some hot data
members ('vmstats_local', 'vmstats_percpu', 'vmstats') sit in 2 adjacent
cacheline (2N and 2N+1 cacheline), and when adjacent cache line prefetch
is enabled, it triggers an "extended level" of cache false sharing for
2 adjacent cache lines.

So exchange the 2 member blocks, while keeping mostly the original
cache alignment, which can restore and even enhance the performance,
and save 64 bytes of space for 'struct mem_cgroup' (from 2880 to 2816,
with 0day's default RHEL-8.3 kernel config)

[1]. https://lore.kernel.org/lkml/20201102091543.GM31092@shao2-debian/

Fixes: bd0b230fe145 ("mm/memcg: unify swap and memsw page counters")
Reported-by: kernel test robot 
Signed-off-by: Feng Tang 
---
 include/linux/memcontrol.h | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index e391e3c..a2d50b0 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -282,20 +282,6 @@ struct mem_cgroup {

MEMCG_PADDING(_pad1_);

-   /*
-* set > 0 if pages under this cgroup are moving to other cgroup.
-*/
-   atomic_t

Re: linux-next boot error: WARNING in prepare_kswapd_sleep

2020-11-24 Thread Alex Shi




在 2020/11/25 上午1:59, Lorenzo Stoakes 写道:
> On Tue, 24 Nov 2020 at 07:54, syzbot
>  wrote:
>> syzbot found the following issue on:
>>
>> HEAD commit:d9137320 Add linux-next specific files for 20201124
> 
> This appears to be a product of 4b2904f3 ("mm/memcg: add missed
> warning in mem_cgroup_lruvec") adding a VM_WARN_ON_ONCE() to
> mem_cgroup_lruvec, which when invoked from a function other than
> mem_cgroup_page_lruvec() can in fact be called with the condition
> false.
> If we move the check back into mem_cgroup_page_lruvec() it resolves
> the issue. I enclose a simple version of this below, happy to submit
> as a proper patch if this is the right approach:
> 
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 87ed56dc75f9..27cc40a490b2 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -618,7 +618,6 @@ static inline struct lruvec
> *mem_cgroup_lruvec(struct mem_cgroup *memcg,
> goto out;
> }
> 
> -   VM_WARN_ON_ONCE(!memcg);
> if (!memcg)
> memcg = root_mem_cgroup;
> 
> @@ -645,6 +644,7 @@ static inline struct lruvec
> *mem_cgroup_lruvec(struct mem_cgroup *memcg,
>  static inline struct lruvec *mem_cgroup_page_lruvec(struct page *page,
> struct pglist_data *pgdat)
>  {
> +   VM_WARN_ON_ONCE_PAGE(!page_memcg(page), page);
> return mem_cgroup_lruvec(page_memcg(page), pgdat);
>  }
> 

Acked.

Right. Would you like to remove the bad commit 4b2904f3 ("mm/memcg: add missed
 warning in mem_cgroup_lruvec") and replace yours.

and further more, could you like try another patch?

Thanks
Alex

>From 073b222bd06a96c39656b0460c705e48c7eedafc Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Wed, 25 Nov 2020 14:06:33 +0800
Subject: [PATCH] mm/memcg: bail out early when !memcg in mem_cgroup_lruvec

In some scenarios, we call NULL memcg in mem_cgroup_lruvec(NULL, pgdat)
so we could get out early to skip unnecessary check.

Also warning if both parameter are NULL.

Signed-off-by: Alex Shi 
---
 include/linux/memcontrol.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 3a995bb3157f..5e4da83eb9ce 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -613,7 +613,9 @@ static inline struct lruvec *mem_cgroup_lruvec(struct 
mem_cgroup *memcg,
struct mem_cgroup_per_node *mz;
struct lruvec *lruvec;
 
-   if (mem_cgroup_disabled()) {
+   VM_WARN_ON_ONCE(!memcg && !pgdat);
+
+   if (mem_cgroup_disabled() || !memcg) {
lruvec = >__lruvec;
goto out;
}
-- 
2.29.GIT

WARNING: modpost: vmlinux.o(.text.unlikely+0x1d0d8): Section mismatch in reference from the function ingenic_tcu_setup_cevt() to the function .init.text:ingenic_tcu_get_clock()

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   127c501a03d5db8b833e953728d3bcf53c8832a9
commit: 1b7efaa6154960396f414551841f1886d99b6872 Merge tag 'timers-v5.9' of 
https://git.linaro.org/people/daniel.lezcano/linux into timers/core
date:   4 months ago
config: mips-randconfig-r032-20201125 (attached as .config)
compiler: mips64el-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b7efaa6154960396f414551841f1886d99b6872
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 1b7efaa6154960396f414551841f1886d99b6872
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> WARNING: modpost: vmlinux.o(.text.unlikely+0x1d0d8): Section mismatch in 
>> reference from the function ingenic_tcu_setup_cevt() to the function 
>> .init.text:ingenic_tcu_get_clock()
The function ingenic_tcu_setup_cevt() references
the function __init ingenic_tcu_get_clock().
This is often because ingenic_tcu_setup_cevt lacks a __init
annotation or the annotation of ingenic_tcu_get_clock is wrong.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH] riscv: defconfig: k210: Disable CONFIG_VT

2020-11-24 Thread Damien Le Moal

On 2020/11/25 3:57, Geert Uytterhoeven wrote:
> There is no need to enable Virtual Terminal support in the Canaan
> Kendryte K210 defconfigs, as no terminal devices are supported and
> enabled.  Hence disable CONFIG_VT, and remove the no longer needed
> override for CONFIG_VGA_CONSOLE.
> 
> This reduces kernel size by ca. 65 KiB.

Indeed, nice saving. Just tested, and all is good.

Can I squash this patch into the 2 defconfig update patches of the series,
adding your signed-off-by ? Or would you prefer that I keep it as a separate 
patch ?

> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> Against k210-sysctl-v15
> ---
>  arch/riscv/configs/nommu_k210_defconfig| 2 +-
>  arch/riscv/configs/nommu_k210_sdcard_defconfig | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/riscv/configs/nommu_k210_defconfig 
> b/arch/riscv/configs/nommu_k210_defconfig
> index df89d53bd125679b..9262223037e43479 100644
> --- a/arch/riscv/configs/nommu_k210_defconfig
> +++ b/arch/riscv/configs/nommu_k210_defconfig
> @@ -48,6 +48,7 @@ CONFIG_DEVTMPFS_MOUNT=y
>  # CONFIG_INPUT_KEYBOARD is not set
>  # CONFIG_INPUT_MOUSE is not set
>  # CONFIG_SERIO is not set
> +# CONFIG_VT is not set
>  # CONFIG_LEGACY_PTYS is not set
>  # CONFIG_LDISC_AUTOLOAD is not set
>  # CONFIG_HW_RANDOM is not set
> @@ -67,7 +68,6 @@ CONFIG_GPIO_SIFIVE=y
>  CONFIG_POWER_RESET=y
>  CONFIG_POWER_RESET_SYSCON=y
>  # CONFIG_HWMON is not set
> -# CONFIG_VGA_CONSOLE is not set
>  # CONFIG_HID is not set
>  # CONFIG_USB_SUPPORT is not set
>  CONFIG_NEW_LEDS=y
> diff --git a/arch/riscv/configs/nommu_k210_sdcard_defconfig 
> b/arch/riscv/configs/nommu_k210_sdcard_defconfig
> index 3d2cb4747e7f85b7..4cd1715dd0cf3747 100644
> --- a/arch/riscv/configs/nommu_k210_sdcard_defconfig
> +++ b/arch/riscv/configs/nommu_k210_sdcard_defconfig
> @@ -41,6 +41,7 @@ CONFIG_DEVTMPFS_MOUNT=y
>  # CONFIG_INPUT_KEYBOARD is not set
>  # CONFIG_INPUT_MOUSE is not set
>  # CONFIG_SERIO is not set
> +# CONFIG_VT is not set
>  # CONFIG_LEGACY_PTYS is not set
>  # CONFIG_LDISC_AUTOLOAD is not set
>  # CONFIG_HW_RANDOM is not set
> @@ -60,7 +61,6 @@ CONFIG_GPIO_SIFIVE=y
>  CONFIG_POWER_RESET=y
>  CONFIG_POWER_RESET_SYSCON=y
>  # CONFIG_HWMON is not set
> -# CONFIG_VGA_CONSOLE is not set
>  # CONFIG_HID is not set
>  # CONFIG_USB_SUPPORT is not set
>  CONFIG_MMC=y
> 


-- 
Damien Le Moal
Western Digital Research

[PATCH] arm64: dts: qcom: c630: Expose LID events

2020-11-24 Thread Bjorn Andersson

The LID state can be read from GPIO 124 and the "tablet mode" from GPIO
95, expose these to the system using gpio-keys and mark the falling edge
of the LID state as a wakeup-source - to wake the system from suspend.

Signed-off-by: Bjorn Andersson 
---
 .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts 
b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
index bb314973eb0c..f956dbf664c1 100644
--- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
+++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
@@ -8,6 +8,8 @@
 /dts-v1/;
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -21,6 +23,27 @@ / {
aliases {
hsuart0 = 
};
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_active>, <_pin_active>;
+
+   lid {
+   gpios = < 124 GPIO_ACTIVE_HIGH>;
+   linux,input-type = ;
+   linux,code = ;
+   wakeup-source;
+   wakeup-event-action = ;
+   };
+
+   mode {
+   gpios = < 95 GPIO_ACTIVE_HIGH>;
+   linux,input-type = ;
+   linux,code = ;
+   };
+   };
 };
 
 _pas {
@@ -466,6 +489,22 @@ wcd_intr_default: wcd_intr_default {
bias-pull-down;
drive-strength = <2>;
};
+
+   lid_pin_active: lid-pin {
+   pins = "gpio124";
+   function = "gpio";
+
+   input-enable;
+   bias-disable;
+   };
+
+   mode_pin_active: mode-pin {
+   pins = "gpio95";
+   function = "gpio";
+
+   input-enable;
+   bias-disable;
+   };
 };
 
  {
-- 
2.29.2

RE: [PATCH v3 00/10] Introduced new Cadence USBSSP DRD Driver.

2020-11-24 Thread Pawel Laszczak

Peter,

>
>>On 20-11-19 15:12:57, Pawel Laszczak wrote:
>>> This patch introduce new Cadence USBSS DRD driver to linux kernel.
>>>
>>> The Cadence USBSS DRD Controller is a highly configurable IP Core which
>>> can be instantiated as Dual-Role Device (DRD), Peripheral Only and
>>> Host Only (XHCI)configurations.
>>>
>>> The current driver has been validated with FPGA burned. We have support
>>> for PCIe bus, which is used on FPGA prototyping.
>>>
>>> The host side of USBSS-DRD controller is compliance with XHCI
>>> specification, so it works with standard XHCI Linux driver.
>>>
>>> The device side of USBSS DRD controller is compliant with XHCI.
>>> The architecture for device side is almost the same as for host side,
>>> and most of the XHCI specification can be used to understand how
>>> this controller operates.
>>>
>>> This controller and driver support Full Speed, Hight Speed, Supper Speed
>>> and Supper Speed Plus USB protocol.
>>>
>>> The prefix cdnsp used in driver has chosen by analogy to cdn3 driver.
>>> The last letter of this acronym means PLUS. The formal name of controller
>>> is USBSSP but it's to generic so I've decided to use CDNSP.
>>>
>>> The patch 1: adds support for DRD CDNSP.
>>> The patch 2: separates common code that can be reusable by cdnsp driver.
>>> The patch 3: moves reusable code to separate module.
>>> The patch 4: changes prefixes in reusable code from cdns3 to common cdns.
>>> The patch 5: adopts gadget_dev pointer in cdns structure to make possible
>>>  use it in both drivers.
>>> The patches 6-8: add the main part of driver and has been intentionally
>>>  split into 3 part. In my opinion such division should not
>>>  affect understanding and reviewing the driver, and cause that
>>>  main patch (7/8) is little smaller. Patch 6 introduces main
>>>  header file for driver, 7 is the main part that implements all
>>>  functionality of driver and 8 introduces tracepoints.
>>> The patch 9: Adds cdns3 prefixes to files related with USBSS driver.
>>> the patch 10: Adds USBSSP DRD IP driver entry to MAINTAINERS file.
>>>
>>> Changlog from v2:
>>> - removed not used pdev parameter from cdnsp_read/wite_64 functions
>>> - fixed incorrect value assigned to CDNSP_ENDPOINTS_NUM (32 -> 31)
>>> - replaced some constant value with CDNSP_ENDPOINTS_NUM macro
>>> - replaced 'true' with '1' in bits description in cdnsp-gadget.h file
>>> - fixed some typos
>>> - some other less important changes suggested by Peter Chen
>>
>>Hi Pawel,
>>
>>I have updated my -next tree as the latest usb-next tree which v5.10-rc4
>>is included, would you please rebase my tree and send again, I could apply 
>>your
>>patches and test, if test could pass, I will apply it to my -next tree.
>>You don't need to rebase again since it is a huge patch set, will take some
>>efforts for rebase.
>>
>
>I'll try to post it tomorrow.

Can I send the new version CDNSP or I should wait for completion
'Re: [PATCH] Revert "usb: cdns3: core: quit if it uses role switch class"' and 
applying the appropriate fix to your repo ?



Thanks
Pawel

Re: Ubuntu mainline kernel builds now failing not able to find module.lds file

2020-11-24 Thread Salvatore Bonaccorso

Hi Steve,

On Fri, Oct 30, 2020 at 12:43:24AM -0500, Steve French wrote:
> I typically build cifs.ko for testing using the latest Ubuntu mainline
> build - but building a module in the 5.10-rc1 kernel - while booted to
> the 5.10-rc1 ubuntu mainlinekerel - e.g. "make C=1 -C
> /usr/src/linux-headers-`uname -r` M=`pwd` modules
> CF=-D__CHECK_ENDIAN__"
> which has worked for years - no longer works.
> 
> make: Entering directory '/usr/src/linux-headers-5.10.0-051000rc1-generic'
> make[2]: *** No rule to make target 'scripts/module.lds', needed by
> '/home/smfrench/cifs-2.6/fs/cifs/cifs.ko'.  Stop.
> make[1]: *** [scripts/Makefile.modpost:117: __modpost] Error 2
> make: *** [Makefile:1703: modules] Error 2
> make: Leaving directory '/usr/src/linux-headers-5.10.0-051000rc1-generic'
> 
> I don't see a file in scripts/module.lds in
> /usr/src/linux-headers-5.10.0-051000rc1-generic/scripts directory
> 
> copying from scripts/module.lds in the 5.10-rc1 git tree to
> /usr/src/linux-headers-5.10.0-051000rc1-generic/scripts fixed the
> problem but was wondering if this is just a packaging problem with
> Ubuntu (missing a file in the kernel headers package for their
> mainline daily builds?)

There is 596b0474d3d9 ("kbuild: preprocess module linker script") in
v5.10-rc1 causing this. So likely the packaging will need some
adjustment to cope with that change?

Have you by chance verified it is not a problem with the upstream
targets?

Regards,
Salvatore

Re: [PATCH net-next 1/2] soc: qcom: ipa: Constify static qmi structs

2020-11-24 Thread Kalle Valo

Jakub Kicinski  writes:

> On Mon, 23 Nov 2020 00:40:30 +0100 Rikard Falkeborn wrote:
>> These are only used as input arguments to qmi_handle_init() which
>> accepts const pointers to both qmi_ops and qmi_msg_handler. Make them
>> const to allow the compiler to put them in read-only memory.
>> 
>> Signed-off-by: Rikard Falkeborn 
>
> I can take this one if Alex acks it.
>
> The other patch is probably best handled by Kalle.

Yes, patch 2 is in my queue.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: drivers/soundwire/qcom.c:767: undefined reference to `slimbus_bus'

2020-11-24 Thread Vinod Koul

Hi Randy,

On 04-11-20, 19:32, Randy Dunlap wrote:
> On 11/2/20 11:47 AM, kernel test robot wrote:
> > All errors (new ones prefixed by >>):
> > 
> >or1k-linux-ld: drivers/soundwire/qcom.o: in function `qcom_swrm_probe':
> >>> drivers/soundwire/qcom.c:767: undefined reference to `slimbus_bus'
> >>> or1k-linux-ld: drivers/soundwire/qcom.c:771: undefined reference to 
> >>> `slimbus_bus'
> > 
> > 09309093d5e8f87 Jonathan Marek   2020-09-08  770  #if 
> > IS_ENABLED(CONFIG_SLIMBUS)
> > 02efb49aa805cee Srinivas Kandagatla  2020-01-13 @771if 
> > (dev->parent->bus == _bus) {
> > 5bd773242f75da3 Jonathan Marek   2020-09-05  772  #else
> > 5bd773242f75da3 Jonathan Marek   2020-09-05  773if (false) {
> > 5bd773242f75da3 Jonathan Marek   2020-09-05  774  #endif
> 
> config SOUNDWIRE_QCOM
>   tristate "Qualcomm SoundWire Master driver"
>   imply SLIMBUS
>   depends on SND_SOC
> 
> The kernel config that was attached has:
> CONFIG_SOUNDWIRE_QCOM=y
> CONFIG_SLIMBUS=m
> 
> I expected that "imply" would make SLIMBUS=y since SOUNDWIRE_QCOM=y,
> but I guess that's not the case. :(
> 
> Any ideas about what to do here?

Sorry to have missed this earlier. I did some digging and found the
Kconfig code to be correct, but not the driver code. Per the
Documentation if we are using imply we should use IS_REACHABLE() rather
than IS_ENABLED.

This seems to take care of build failure for me on arm64 and x64 builds.

Can you confirm with below patch:

---><8---

From: Vinod Koul 
Date: Wed, 25 Nov 2020 11:15:22 +0530
Subject: [PATCH] soundwire: qcom: Fix build failure when slimbus is module

Commit 5bd773242f75 ("soundwire: qcom: avoid dependency on
CONFIG_SLIMBUS") removed hard dependency on Slimbus for qcom driver but
it results in build failure when:
CONFIG_SOUNDWIRE_QCOM=y
CONFIG_SLIMBUS=m

drivers/soundwire/qcom.o: In function `qcom_swrm_probe':
qcom.c:(.text+0xf44): undefined reference to `slimbus_bus'

Fix this by using IS_REACHABLE() in driver which is recommended to be
sued with imply.

Fixes: 5bd773242f75 ("soundwire: qcom: avoid dependency on CONFIG_SLIMBUS")
Reported-by: kernel test robot 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/qcom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
index fbca4ebf63e9..6d22df01f354 100644
--- a/drivers/soundwire/qcom.c
+++ b/drivers/soundwire/qcom.c
@@ -799,7 +799,7 @@ static int qcom_swrm_probe(struct platform_device *pdev)
data = of_device_get_match_data(dev);
ctrl->rows_index = sdw_find_row_index(data->default_rows);
ctrl->cols_index = sdw_find_col_index(data->default_cols);
-#if IS_ENABLED(CONFIG_SLIMBUS)
+#if IS_REACHABLE(CONFIG_SLIMBUS)
if (dev->parent->bus == _bus) {
 #else
if (false) {
-- 
2.26.2

-- 
~Vinod

[PATCH] slimbus: qcom-ngd-ctrl: Avoid sending power requests without QMI

2020-11-24 Thread Bjorn Andersson

Attempting to send a power request during PM operations, when the QMI
handle isn't initialized results in a NULL pointer dereference. So check
if the QMI handle has been initialized before attempting to post the
power requests.

Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver")
Signed-off-by: Bjorn Andersson 
---
 drivers/slimbus/qcom-ngd-ctrl.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
index d8decb345e9d..c502e9e93965 100644
--- a/drivers/slimbus/qcom-ngd-ctrl.c
+++ b/drivers/slimbus/qcom-ngd-ctrl.c
@@ -1229,6 +1229,9 @@ static int qcom_slim_ngd_runtime_resume(struct device 
*dev)
struct qcom_slim_ngd_ctrl *ctrl = dev_get_drvdata(dev);
int ret = 0;
 
+   if (!ctrl->qmi.handle)
+   return 0;
+
if (ctrl->state >= QCOM_SLIM_NGD_CTRL_ASLEEP)
ret = qcom_slim_ngd_power_up(ctrl);
if (ret) {
@@ -1616,6 +1619,9 @@ static int __maybe_unused 
qcom_slim_ngd_runtime_suspend(struct device *dev)
struct qcom_slim_ngd_ctrl *ctrl = dev_get_drvdata(dev);
int ret = 0;
 
+   if (!ctrl->qmi.handle)
+   return 0;
+
ret = qcom_slim_qmi_power_request(ctrl, false);
if (ret && ret != -EBUSY)
dev_info(ctrl->dev, "slim resource not idle:%d\n", ret);
-- 
2.29.2

Re: [PATCHv9 3/8] iommu/arm-smmu: Move non-strict mode to use io_pgtable_domain_attr


On 2020-11-25 03:09, Will Deacon wrote:

On Mon, Nov 23, 2020 at 10:35:56PM +0530, Sai Prakash Ranjan wrote:

Now that we have a struct io_pgtable_domain_attr with quirks,
use that for non_strict mode as well thereby removing the need
for more members of arm_smmu_domain in the future.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 8 +++-
 drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 -
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu.c

index 4b9b10fe50ed..f56f266ebdf7 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -786,9 +786,6 @@ static int arm_smmu_init_domain_context(struct 
iommu_domain *domain,

goto out_clear_smmu;
}

-   if (smmu_domain->non_strict)
-   pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
-
if (smmu_domain->pgtbl_cfg.quirks)
pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;

@@ -1527,7 +1524,8 @@ static int arm_smmu_domain_get_attr(struct 
iommu_domain *domain,

case IOMMU_DOMAIN_DMA:
switch (attr) {
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-   *(int *)data = smmu_domain->non_strict;
+   if (smmu_domain->pgtbl_cfg.quirks & 
IO_PGTABLE_QUIRK_NON_STRICT)
+   *(int *)data = smmu_domain->pgtbl_cfg.quirks;


I still don't think this is right :(
We need to set *data to 1 or 0 depending on whether or not the 
non-strict

quirk is set, i.e:

	bool non_strict = smmu_domain->pgtbl_cfg.quirks & 
IO_PGTABLE_QUIRK_NON_STRICT;

*(int *)data = non_strict;

Your code above leaves *data uninitialised if non_strict is not set.


Ugh sorry, I should have looked at this some more before hurrying up
to post, will fix it.




return 0;
default:
return -ENODEV;
@@ -1578,7 +1576,7 @@ static int arm_smmu_domain_set_attr(struct 
iommu_domain *domain,

case IOMMU_DOMAIN_DMA:
switch (attr) {
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-   smmu_domain->non_strict = *(int *)data;
+   smmu_domain->pgtbl_cfg.quirks |= 
IO_PGTABLE_QUIRK_NON_STRICT;


And this is broken because if *data is 0, then you _set_ the quirk, 
which is

the opposite of what we should be doing.

In other words, although the implementation has changed, the semantics 
have

not.



Will fix this to have quirk set only when *data = 1 and unset in case of 
0.


Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock_skip on reserved pages

2020-11-24 Thread Andrea Arcangeli

Hello,

On Mon, Nov 23, 2020 at 02:01:16PM +0100, Vlastimil Babka wrote:
> On 11/21/20 8:45 PM, Andrea Arcangeli wrote:
> > A corollary issue was fixed in
> > 39639000-39814fff : Unknown E820 type
> > 
> > pfn 0x7a200 -> 0x7a20 min_pfn hit non-RAM:
> > 
> > 7a17b000-7a216fff : Unknown E820 type
> 
> It would be nice to also provide a /proc/zoneinfo and how exactly the 
> "zone_spans_pfn" was violated. I assume we end up below zone's 
> start_pfn, but is it true?

Agreed, I was about to grab that info along with all page struct
around the pfn 0x7a200 and phys address 0x7a216fff.

# grep -A1 E820 /proc/iomem
7a17b000-7a216fff : Unknown E820 type
7a217000-7bff : System RAM

DMA  zone_start_pfn 1zone_end_pfn() 4096 contiguous 1   

DMA32zone_start_pfn 4096 zone_end_pfn() 1048576  contiguous 0   

Normal   zone_start_pfn 1048576  zone_end_pfn() 4715392  contiguous 1   

Movable  zone_start_pfn 0zone_end_pfn() 0contiguous 0   

500222 0x7a1fe000 0x1fff1000 reserved True
500223 0x7a1ff000 0x1fff1000 reserved True

# I suspect "highest pfn" was somewhere in the RAM range
# 0x7a217000-0x7a40 and the pageblock_start_pfn(pfn)
# made highest point to pfn 0x7a200 physaddr 0x7a20
# below, which is reserved indeed since it's non-RAM
# first number is pfn hex(500224) == 0x7a200

pfnphysaddr   page->flags
500224 0x7a20 0x1fff1000 reserved True
500225 0x7a201000 0x1fff1000 reserved True
*snip*
500245 0x7a215000 0x1fff1000 reserved True
500246 0x7a216000 0x1fff1000 reserved True
500247 0x7a217000 0x3fff reserved False
500248 0x7a218000 0x3fff reserved False

All RAM pages non-reserved are starting at 0x7a217000 as expected.

The non-RAM page_zonenum(pfn_to_page(0x7a200)) points to ZONE_DMA and 
page_zone(page) below was the DMA zone despite the pfn of 0x7a200 is
in DMA32.

VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page);

So the patch I sent earlier should prevent the above BUG_ON by not
setting highest to 0x7a200 when pfn is in the phys RAM range
0x7a217000-0x7a40, because pageblock_pfn_to_page will notice that
the zone is the wrong one.

if (page_zone(start_page) != zone)
return NULL;

However the real bug seems that reserved pages have a zero zone_id in
the page->flags when it should have the real zone id/nid. The patch I
sent earlier to validate highest would only be needed to deal with
pfn_valid.

Something must have changed more recently than v5.1 that caused the
zoneid of reserved pages to be wrong, a possible candidate for the
real would be this change below:

+   __init_single_page(pfn_to_page(pfn), pfn, 0, 0);

Even if it may not be it, at the light of how the reserved page
zoneid/nid initialized went wrong, the above line like it's too flakey
to stay.

It'd be preferable if the pfn_valid fails and the
pfn_to_section_nr(pfn) returns an invalid section for the intermediate
step. Even better memset 0xff over the whole page struct until the
second stage comes around.

Whenever pfn_valid is true, it's better that the zoneid/nid is correct
all times, otherwise if the second stage fails we end up in a bug with
weird side effects.

Maybe it's not the above that left a zero zoneid though, I haven't
tried to bisect it yet to look how the page->flags looked like on a
older kernel that didn't seem to reproduce this crash, I'm just
guessing.

Thanks,
Andrea

RE: [PATCH v2 3/3] Input: adp5589-keys - add basic devicetree support

2020-11-24 Thread Ardelean, Alexandru



> -Original Message-
> From: Lars-Peter Clausen 
> Sent: Tuesday, November 24, 2020 10:43 AM
> To: Ardelean, Alexandru ; linux-
> in...@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: dmitry.torok...@gmail.com
> Subject: Re: [PATCH v2 3/3] Input: adp5589-keys - add basic devicetree support
> 
> [External]
> 
> On 11/24/20 9:22 AM, Alexandru Ardelean wrote:
> > error = devm_add_action_or_reset(>dev,
> > adp5589_clear_config, @@ -1078,6 +1098,13 @@ static int __maybe_unused
> > adp5589_resume(struct device *dev)
> >
> >   static SIMPLE_DEV_PM_OPS(adp5589_dev_pm_ops, adp5589_suspend,
> > adp5589_resume);
> >
> > +static const struct of_device_id adp5589_of_match[] = {
> > +   { .compatible = "adi,adp5585", .data =
> _chip_info_tbl[ADP5585_01] },
> > +   { .compatible = "adi,adp5585-02", .data =
> _chip_info_tbl[ADP5585_02] },
> > +   { .compatible = "adi,adp5589", .data =
> > +_chip_info_tbl[ADP5589] },
> 
> I think we need to add these to
> Documentation/devicetree/bindings/trivial-devices.yaml
> 

Ack
Will send a V3 in the next few days.

[PATCH] arm64: dts: meson: update the Khadas VIM3/3L LED bindings

2020-11-24 Thread Christian Hewitt

Update the VIM3/3L common dtsi to use the new function/color bindings.

Suggested-by: Artem Lapkin 
Signed-off-by: Christian Hewitt 
---
This supersedes a previous submission from Art [0] and uses the updated
LED bindings suggested by Neil.

[0] 
https://patchwork.kernel.org/project/linux-amlogic/patch/20200925033017.1790973-4-...@khadas.com/

 arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
index 87bd8c9516f2..8f8656262ae7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -42,14 +43,16 @@
leds {
compatible = "gpio-leds";
 
-   led-white {
-   label = "vim3:white:sys";
+   white {
+   color = ;
+   function = LED_FUNCTION_STATUS;
gpios = <_ao GPIOAO_4 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "heartbeat";
};
 
-   led-red {
-   label = "vim3:red";
+   red {
+   color = ;
+   function = LED_FUNCTION_STATUS;
gpios = <_expander 5 GPIO_ACTIVE_HIGH>;
};
};
-- 
2.17.1

Re: [RFC 07/11] coresight: sink: Add TRBE driver

2020-11-24 Thread Anshuman Khandual




On 11/12/20 3:43 PM, Suzuki K Poulose wrote:
> On 11/10/20 12:45 PM, Anshuman Khandual wrote:
>> Trace Buffer Extension (TRBE) implements a trace buffer per CPU which is
>> accessible via the system registers. The TRBE supports different addressing
>> modes including CPU virtual address and buffer modes including the circular
>> buffer mode. The TRBE buffer is addressed by a base pointer (TRBBASER_EL1),
>> an write pointer (TRBPTR_EL1) and a limit pointer (TRBLIMITR_EL1). But the
>> access to the trace buffer could be prohibited by a higher exception level
>> (EL3 or EL2), indicated by TRBIDR_EL1.P. The TRBE can also generate a CPU
>> private interrupt (PPI) on address translation errors and when the buffer
>> is full. Overall implementation here is inspired from the Arm SPE driver.
>>
>> Signed-off-by: Anshuman Khandual 
>> ---
>>   Documentation/trace/coresight/coresight-trbe.rst |  36 ++
>>   arch/arm64/include/asm/sysreg.h  |   2 +
>>   drivers/hwtracing/coresight/Kconfig  |  11 +
>>   drivers/hwtracing/coresight/Makefile |   1 +
>>   drivers/hwtracing/coresight/coresight-trbe.c | 766 
>> +++
>>   drivers/hwtracing/coresight/coresight-trbe.h | 525 
>>   6 files changed, 1341 insertions(+)
>>   create mode 100644 Documentation/trace/coresight/coresight-trbe.rst
>>   create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
>>   create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h
>>
>> diff --git a/Documentation/trace/coresight/coresight-trbe.rst 
>> b/Documentation/trace/coresight/coresight-trbe.rst
>> new file mode 100644
>> index 000..4320a8b
>> --- /dev/null
>> +++ b/Documentation/trace/coresight/coresight-trbe.rst
>> @@ -0,0 +1,36 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +==
>> +Trace Buffer Extension (TRBE).
>> +==
>> +
>> +    :Author:   Anshuman Khandual 
>> +    :Date: November 2020
>> +
>> +Hardware Description
>> +
>> +
>> +Trace Buffer Extension (TRBE) is a percpu hardware which captures in system
>> +memory, CPU traces generated from a corresponding percpu tracing unit. This
>> +gets plugged in as a coresight sink device because the corresponding trace
>> +genarators (ETE), are plugged in as source device.
>> +
>> +Sysfs files and directories
>> +---
>> +
>> +The TRBE devices appear on the existing coresight bus alongside the other
>> +coresight devices::
>> +
>> +    >$ ls /sys/bus/coresight/devices
>> +    trbe0  trbe1  trbe2 trbe3
>> +
>> +The ``trbe`` named TRBEs are associated with a CPU.::
>> +
>> +    >$ ls /sys/bus/coresight/devices/trbe0/
>> +    irq align dbm
>> +
>> +*Key file items are:-*
>> +   * ``irq``: TRBE maintenance interrupt number
>> +   * ``align``: TRBE write pointer alignment
>> +   * ``dbm``: TRBE updates memory with access and dirty flags
>> +
>> diff --git a/arch/arm64/include/asm/sysreg.h 
>> b/arch/arm64/include/asm/sysreg.h
>> index 14cb156..61136f6 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -97,6 +97,7 @@
>>   #define SET_PSTATE_UAO(x)    __emit_inst(0xd500401f | PSTATE_UAO | 
>> ((!!x) << PSTATE_Imm_shift))
>>   #define SET_PSTATE_SSBS(x)    __emit_inst(0xd500401f | PSTATE_SSBS | 
>> ((!!x) << PSTATE_Imm_shift))
>>   #define SET_PSTATE_TCO(x)    __emit_inst(0xd500401f | PSTATE_TCO | 
>> ((!!x) << PSTATE_Imm_shift))
>> +#define TSB_CSYNC    __emit_inst(0xd503225f)
>>     #define __SYS_BARRIER_INSN(CRm, op2, Rt) \
>>   __emit_inst(0xd500 | sys_insn(0, 3, 3, (CRm), (op2)) | ((Rt) & 
>> 0x1f))
>> @@ -865,6 +866,7 @@
>>   #define ID_AA64MMFR2_CNP_SHIFT    0
>>     /* id_aa64dfr0 */
>> +#define ID_AA64DFR0_TRBE_SHIFT    44
>>   #define ID_AA64DFR0_TRACE_FILT_SHIFT    40
>>   #define ID_AA64DFR0_DOUBLELOCK_SHIFT    36
>>   #define ID_AA64DFR0_PMSVER_SHIFT    32
>> diff --git a/drivers/hwtracing/coresight/Kconfig 
>> b/drivers/hwtracing/coresight/Kconfig
>> index c119824..0f5e101 100644
>> --- a/drivers/hwtracing/coresight/Kconfig
>> +++ b/drivers/hwtracing/coresight/Kconfig
>> @@ -156,6 +156,17 @@ config CORESIGHT_CTI
>>     To compile this driver as a module, choose M here: the
>>     module will be called coresight-cti.
>>   +config CORESIGHT_TRBE
>> +    bool "Trace Buffer Extension (TRBE) driver"
>> +    depends on ARM64
>> +    help
>> +  This driver provides support for percpu Trace Buffer Extension (TRBE).
>> +  TRBE always needs to be used along with it's corresponding percpu ETE
>> +  component. ETE generates trace data which is then captured with TRBE.
>> +  Unlike traditional sink devices, TRBE is a CPU feature accessible via
>> +  system registers. But it's explicit dependency with trace unit (ETE)
>> +  requires it to be plugged in as a coresight sink device.
>> +
>>   config CORESIGHT_CTI_INTEGRATION_REGS
>>

Re: [PATCH v3 17/17] x86/hyperv: handle IO-APIC when running as root