[PATCH -next] staging/speakup: Switch to kmemdup_nul()

[Yang Yingliang]

Use kmemdup_nul() helper instead of open-coding to
simplify the code.

Reported-by: Hulk Robot 
Signed-off-by: Yang Yingliang 
---
 drivers/accessibility/speakup/i18n.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/accessibility/speakup/i18n.c 
b/drivers/accessibility/speakup/i18n.c
index ee240d36f947..46bd50f3c3a4 100644
--- a/drivers/accessibility/speakup/i18n.c
+++ b/drivers/accessibility/speakup/i18n.c
@@ -548,12 +548,10 @@ ssize_t spk_msg_set(enum msg_index_t index, char *text, 
size_t length)
if ((index < MSG_FIRST_INDEX) || (index >= MSG_LAST_INDEX))
return -EINVAL;
 
-   newstr = kmalloc(length + 1, GFP_KERNEL);
+   newstr = kmemdup_nul(text, length, GFP_KERNEL);
if (!newstr)
return -ENOMEM;
 
-   memcpy(newstr, text, length);
-   newstr[length] = '\0';
if (index >= MSG_FORMATTED_START &&
index <= MSG_FORMATTED_END &&
!fmt_validate(speakup_default_msgs[index], newstr)) {
-- 
2.25.1

Re: [PATCH RESEND] arm64: dts: qcom: Add support for OnePlus 5/5T

[Martin Botka]

On Mon, Mar 22, 2021 at 18:16, Jami Kettunen  
wrote:

Add device trees for OnePlus 5 (cheeseburger) and 5T (dumpling)
MSM8998 SoC smartphones with initial support included for:

- UFS internal storage
- USB peripheral mode
- Display
- Touch
- Bluetooth
- Hall effect sensor
- Power and volume buttons
- Capacitive keypad button backlight (on cheeseburger)

Signed-off-by: Jami Kettunen 
Reviewed-by: Konrad Dybcio 
---
 arch/arm64/boot/dts/qcom/Makefile |   2 +
 .../dts/qcom/msm8998-oneplus-cheeseburger.dts |  42 ++
 .../boot/dts/qcom/msm8998-oneplus-common.dtsi | 519 
++

 .../dts/qcom/msm8998-oneplus-dumpling.dts |  25 +
 4 files changed, 588 insertions(+)
 create mode 100644 
arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts
 create mode 100644 
arch/arm64/boot/dts/qcom/msm8998-oneplus-common.dtsi
 create mode 100644 
arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts


diff --git a/arch/arm64/boot/dts/qcom/Makefile 
b/arch/arm64/boot/dts/qcom/Makefile

index 549a7a2151d4..1beb73f564f7 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -27,6 +27,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= 
msm8998-asus-novago-tp370ql.dtb

 dtb-$(CONFIG_ARCH_QCOM)+= msm8998-hp-envy-x2.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8998-lenovo-miix-630.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8998-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= msm8998-oneplus-cheeseburger.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= msm8998-oneplus-dumpling.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-1000.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-4000.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= qrb5165-rb5.dtb
diff --git 
a/arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts 
b/arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts

new file mode 100644
index ..13b6b8ad4679
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * OnePlus 5 (cheeseburger) device tree
+ *
+ * Copyright (c) 2021, Jami Kettunen 
+ */
+
+#include 
+#include "msm8998-oneplus-common.dtsi"
+
+/ {
+   model = "OnePlus 5";
+   compatible = "oneplus,cheeseburger", "qcom,msm8998";
+   /* Required for bootloader to select correct board */
+   qcom,board-id = <8 0 16859 23>;
+
+   /* Capacitive keypad button backlight */
+   leds {
+   compatible = "gpio-leds";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_backlight_default>;
+
+   button-backlight {
+   gpios = <_gpio 5 GPIO_ACTIVE_HIGH>;
+   color = ;
+   function = LED_FUNCTION_KBD_BACKLIGHT;
+   default-state = "off";
+   };
+   };
+};
+
+_gpio {
+   button_backlight_default: button-backlight-default {
+   pinconf {
+   pins = "gpio5";
+   function = "normal";
+   bias-pull-down;
+   qcom,drive-strength = ;
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8998-oneplus-common.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998-oneplus-common.dtsi

new file mode 100644
index ..1de4d19ed143
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-oneplus-common.dtsi
@@ -0,0 +1,519 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * OnePlus 5(T) (cheeseburger / dumpling) common device tree source 
based on msm8998-mtp.dtsi

+ *
+ * Copyright (c) 2021, Jami Kettunen 
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include "msm8998.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+#include "pm8005.dtsi"
+
+/ {
+   /* Required for bootloader to select correct board */
+   qcom,msm-id = <292 0x20001>; /* 8998 v2.1 */
+
+   chosen {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+		/* Use display framebuffer setup by the UEFI XBL bootloader for 
simplefb */

+   framebuffer0: framebuffer@9d40 {
+   compatible = "simple-framebuffer";
+   reg = <0x0 0x9d40 0x0 0x240>;
+   width = <1080>;
+   height = <1920>;
+   stride = <(1080 * 4)>;
+   format = "a8r8g8b8";
+   };
+   };
+
+   reserved-memory {
+   /* Bootloader display framebuffer region */
+   cont_splash_mem: memory@9d40 {
+   reg = <0x0 0x9d40 0x0 0x240>;
+   no-map;
+   };
+
+   /* For getting crash logs using Android downstream kernels */
+   ramoops@ac00 {
+   compatible = "ramoops";
+   reg = <0x0 0xac00 0x0 0x20>;
+   console-size = 

Re: [PATCH 15/32] MAINTAINERS: update atmel,sama5d2-adc.yaml reference

[Jonathan Cameron]

On Thu,  1 Apr 2021 14:17:35 +0200
Mauro Carvalho Chehab  wrote:

> Changeset 58ff1b519753 ("dt-bindings:iio:adc:atmel,sama5d2-adc: txt to yaml 
> conversion")
> renamed: Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> to: Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml.
> 
> Update its cross-reference accordingly.
> 
> Fixes: 58ff1b519753 ("dt-bindings:iio:adc:atmel,sama5d2-adc: txt to yaml 
> conversion")
> Signed-off-by: Mauro Carvalho Chehab 
Applied

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 576d1bcabb20..89ed435ca6c3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11930,7 +11930,7 @@ MICROCHIP SAMA5D2-COMPATIBLE ADC DRIVER
>  M:   Eugen Hristev 
>  L:   linux-...@vger.kernel.org
>  S:   Supported
> -F:   Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> +F:   Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
>  F:   drivers/iio/adc/at91-sama5d2_adc.c
>  F:   include/dt-bindings/iio/adc/at91-sama5d2_adc.h
>  

[PATCH RFC 2/3] fpga: support loading from a pre-allocated buffer

[Nava kishore Manne]

Some systems are memory constrained but they need to load very
large Configuration files. The FPGA subsystem allows drivers to
request this Configuration image be loaded from the filesystem,
but this requires that the entire configuration data be loaded
into kernel memory first before it's provided to the driver.
This can lead to a situation where we map the configuration
data twice, once to load the configuration data into kernel
memory and once to copy the configuration data into the final
resting place which is nothing but a dma-able continuous buffer.

This creates needless memory pressure and delays due to multiple
copies. Let's add a dmabuf handling support to the fpga manager
framework that allows drivers to load the Configuration data
directly from a pre-allocated buffer. This skips the intermediate
step of allocating a buffer in kernel memory to hold the
Configuration data.

Signed-off-by: Nava kishore Manne 
---
 drivers/fpga/fpga-mgr.c   | 126 +-
 drivers/fpga/of-fpga-region.c |   3 +
 include/linux/fpga/fpga-mgr.h |   6 +-
 3 files changed, 132 insertions(+), 3 deletions(-)

diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index b85bc47c91a9..13faed61af62 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -8,6 +8,8 @@
  * With code from the mailing list:
  * Copyright (C) 2013 Xilinx, Inc.
  */
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -306,6 +308,51 @@ static int fpga_mgr_buf_load(struct fpga_manager *mgr,
return rc;
 }
 
+/**
+ * fpga_mgr_buf_load - load fpga from image in dma buffer
+ * @mgr:fpga manager
+ * @info:   fpga image info
+ *
+ * Step the low level fpga manager through the device-specific steps of getting
+ * an FPGA ready to be configured, writing the image to it, then doing whatever
+ * post-configuration steps necessary.  This code assumes the caller got the
+ * mgr pointer from of_fpga_mgr_get() and checked that it is not an error code.
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+static int fpga_dmabuf_load(struct fpga_manager *mgr,
+   struct fpga_image_info *info)
+{
+   struct dma_buf_attachment *attach;
+   struct sg_table *sgt;
+   int ret;
+
+   /* create attachment for dmabuf with the user device */
+   attach = dma_buf_attach(mgr->dmabuf, >dev);
+   if (IS_ERR(attach)) {
+   pr_err("failed to attach dmabuf\n");
+   ret = PTR_ERR(attach);
+   goto fail_put;
+   }
+
+   sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+   if (IS_ERR(sgt)) {
+   ret = PTR_ERR(sgt);
+   goto fail_detach;
+   }
+
+   info->sgt = sgt;
+   ret = fpga_mgr_buf_load_sg(mgr, info, info->sgt);
+   dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+
+fail_detach:
+   dma_buf_detach(mgr->dmabuf, attach);
+fail_put:
+   dma_buf_put(mgr->dmabuf);
+
+   return ret;
+}
+
 /**
  * fpga_mgr_firmware_load - request firmware and load to fpga
  * @mgr:   fpga manager
@@ -358,6 +405,8 @@ static int fpga_mgr_firmware_load(struct fpga_manager *mgr,
  */
 int fpga_mgr_load(struct fpga_manager *mgr, struct fpga_image_info *info)
 {
+   if (info->flags & FPGA_MGR_CONFIG_DMA_BUF)
+   return fpga_dmabuf_load(mgr, info);
if (info->sgt)
return fpga_mgr_buf_load_sg(mgr, info, info->sgt);
if (info->buf && info->count)
@@ -549,6 +598,62 @@ void fpga_mgr_unlock(struct fpga_manager *mgr)
 }
 EXPORT_SYMBOL_GPL(fpga_mgr_unlock);
 
+static int fpga_dmabuf_fd_get(struct file *file, char __user *argp)
+{
+   struct fpga_manager *mgr =  (struct fpga_manager *)(file->private_data);
+   int buffd;
+
+   if (copy_from_user(, argp, sizeof(buffd)))
+   return -EFAULT;
+
+   mgr->dmabuf = dma_buf_get(buffd);
+   if (IS_ERR_OR_NULL(mgr->dmabuf))
+   return -EINVAL;
+
+   return 0;
+}
+
+static int fpga_device_open(struct inode *inode, struct file *file)
+{
+   struct miscdevice *miscdev = file->private_data;
+   struct fpga_manager *mgr = container_of(miscdev,
+   struct fpga_manager, miscdev);
+
+   file->private_data = mgr;
+
+   return 0;
+}
+
+static int fpga_device_release(struct inode *inode, struct file *file)
+{
+   return 0;
+}
+
+static long fpga_device_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+   char __user *argp = (char __user *)arg;
+   int err;
+
+   switch (cmd) {
+   case FPGA_IOCTL_LOAD_DMA_BUFF:
+   err = fpga_dmabuf_fd_get(file, argp);
+   break;
+   default:
+   err = -ENOTTY;
+   }
+
+   return err;
+}
+
+static const struct file_operations fpga_fops = {
+   .owner  = THIS_MODULE,
+   .open   = fpga_device_open,
+   

Re: [PATCH] staging: fbtft: change snprintf() to scnprintf()

[Greg KH]

On Fri, Apr 02, 2021 at 09:05:01AM +, Carlis wrote:
> From: Xuezhi Zhang 
> 
> show() must not use snprintf() when formatting the value to
> be returned to user space.

Why not?  The code is just fine as-is.

> 
> Signed-off-by: Xuezhi Zhang 
> ---
>  drivers/staging/fbtft/fbtft-sysfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/fbtft/fbtft-sysfs.c 
> b/drivers/staging/fbtft/fbtft-sysfs.c
> index 26e52cc2de64..7df92db648d6 100644
> --- a/drivers/staging/fbtft/fbtft-sysfs.c
> +++ b/drivers/staging/fbtft/fbtft-sysfs.c
> @@ -199,7 +199,7 @@ static ssize_t show_debug(struct device *device,
>   struct fb_info *fb_info = dev_get_drvdata(device);
>   struct fbtft_par *par = fb_info->par;
>  
> - return snprintf(buf, PAGE_SIZE, "%lu\n", par->debug);
> + return scnprintf(buf, PAGE_SIZE, "%lu\n", par->debug);

If you really want to "fix" this, please just use sysfs_emit().  This
change as-is, does nothing.

thanks,

greg k-h

[PATCH RFC 0/3] Adds support to allow the bitstream configuration from pre-allocated dma-buffer

[Nava kishore Manne]

Nava kishore Manne (3):
  fpga: region: Add fpga-region property 'fpga-config-from-dmabuf'
  fpga: support loading from a pre-allocated buffer
  fpga: zynqmp: Use the scatterlist interface

 .../devicetree/bindings/fpga/fpga-region.txt  |   2 +
 drivers/fpga/fpga-mgr.c   | 126 +-
 drivers/fpga/of-fpga-region.c |   3 +
 drivers/fpga/zynqmp-fpga.c|  35 +
 include/linux/fpga/fpga-mgr.h |   6 +-
 5 files changed, 169 insertions(+), 3 deletions(-)

-- 
2.18.0

Re: [PATCH 1/1] Bluetooth: btusb: Enable quirk boolean flag for Mediatek Chip.

[Marcel Holtmann]

Hi Mark,

> Adding support LE scatternet and WBS for Mediatek Chip
> 
> Signed-off-by: mark-yw.chen 
> ---
> drivers/bluetooth/btusb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

Re: [PATCH v6 4/5] drm/bridge: anx7625: add HDCP support

[Xin Ji]

On Fri, Apr 02, 2021 at 11:59:39AM +0300, Laurent Pinchart wrote:
> Hi Xin,
> 
> On Fri, Apr 02, 2021 at 10:27:08AM +0800, Xin Ji wrote:
> > On Mon, Mar 29, 2021 at 02:02:08PM -0400, Sean Paul wrote:
> > > On Mon, Mar 29, 2021 at 6:27 AM Xin Ji  wrote:
> > > >
> > > > On Thu, Mar 25, 2021 at 02:19:23PM -0400, Sean Paul wrote:
> > > > > On Fri, Mar 19, 2021 at 2:35 AM Xin Ji  wrote:
> > > > > >
> > > > > > Add HDCP feature, enable HDCP function through chip internal key
> > > > > > and downstream's capability.
> > > > > >
> > > > > > Signed-off-by: Xin Ji 
> > > > > > ---
> > > 
> > > /snip
> > > 
> > > > > >  static void anx7625_dp_start(struct anx7625_data *ctx)
> > > > > >  {
> > > > > > int ret;
> > > > > > @@ -643,6 +787,9 @@ static void anx7625_dp_start(struct 
> > > > > > anx7625_data *ctx)
> > > > > > return;
> > > > > > }
> > > > > >
> > > > > > +   /* HDCP config */
> > > > > > +   anx7625_hdcp_setting(ctx);
> > > > >
> > > > > You should really use the "Content Protection" property to
> > > > > enable/disable HDCP instead of force-enabling it at all times.
> > > >
> > > > Hi Sean, it's hard to implement "Content Protection" property, we have
> > > > implemented HDCP in firmware, it is not compatible with it. We don't
> > > > have interface to get Downstream Cert.
> > > > Thanks,
> > > > Xin
> > > 
> > > Hi Xin,
> > > I'm sorry, I don't understand what you mean when you say you don't
> > > have an interface to get Downstream Cert.
> > > 
> > > The Content Protection property is just a means through which
> > > userspace can turn on and turn off HDCP when it needs. As far as I can
> > > tell, your patch turns on HDCP when the display is enabled and leaves
> > > it on until it is disabled. This is undesirable since it forces HDCP
> > > on the user.
> > > 
> > > Is it impossible to enable/disable HDCP outside of display
> > > enable/disable on your hardware?
> >
> > Hi Sean, I have commit a test patch on google review site, can you
> > please help to review it? I'll use Connector's ".atomic_check()"
> > interface to detect Content Protection property change.
> > (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium-review.googlesource.com%2Fc%2Fchromiumos%2Fthird_party%2Fkernel%2F%2B%2F2674580data=04%7C01%7Cxji%40analogixsemi.com%7Cd778885f3d0d4b4358a908d8f5b5c273%7Cb099b0b4f26c4cf59a0fd5be9acab205%7C0%7C0%7C637529508334886979%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vo8zP8SAhLrQk0%2FWh1OhXHAZzLU9lJ4NLaYddI6t2ZU%3Dreserved=0)
> 
> Please note that upstream review happens on mailing lists, not in
> gerrit. Internal reviews for Chrome OS development are certainly fine
> there, but that will not mean the patch will then be accepted upstream
> as-is, it will still need to go through the upstream review process,
> without any shortcut. I strongly recommend using an upstream-first
> strategy, with public review.
Hi Laurent Pinchart, OK, got it, thanks for the note.

Thanks,
Xin
> 
> > > > > > +
> > > > > > if (ctx->pdata.is_dpi)
> > > > > > ret = anx7625_dpi_config(ctx);
> > > > > > else
> > > 
> > > /snip
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Re: [PATCH 11/32] MAINTAINERS: update invensense,mpu3050.yaml reference

[Jonathan Cameron]

On Thu,  1 Apr 2021 14:17:31 +0200
Mauro Carvalho Chehab  wrote:

> Changeset 749787477ae4 ("dt-bindings:iio:gyro:invensense,mpu3050: txt to yaml 
> format conversion.")
> renamed: 
> Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.txt
> to: Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml.
> 
> Update its cross-reference accordingly.
> 
> Fixes: 749787477ae4 ("dt-bindings:iio:gyro:invensense,mpu3050: txt to yaml 
> format conversion.")
> Signed-off-by: Mauro Carvalho Chehab 

Applied

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5110f47ebf85..ce675a0b3819 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9414,7 +9414,7 @@ INVENSENSE MPU-3050 GYROSCOPE DRIVER
>  M:   Linus Walleij 
>  L:   linux-...@vger.kernel.org
>  S:   Maintained
> -F:   Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.txt
> +F:   Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml
>  F:   drivers/iio/gyro/mpu3050*
>  
>  IOC3 ETHERNET DRIVER

Re: [PATCH 10/32] MAINTAINERS: update voltage-divider.yaml reference

[Jonathan Cameron]

On Thu,  1 Apr 2021 14:17:30 +0200
Mauro Carvalho Chehab  wrote:

> Changeset 6f633bc91ac1 ("dt-bindings:iio:afe:voltage-divider: txt to yaml 
> conversion")
> renamed: Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
> to: Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml.
> 
> Update its cross-reference accordingly.
> 
> Fixes: 6f633bc91ac1 ("dt-bindings:iio:afe:voltage-divider: txt to yaml 
> conversion")
> Signed-off-by: Mauro Carvalho Chehab 

Applied.

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 71950316c736..5110f47ebf85 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8797,7 +8797,7 @@ L:  linux-...@vger.kernel.org
>  S:   Maintained
>  F:   Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
>  F:   Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml
> -F:   Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
> +F:   Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml
>  F:   drivers/iio/afe/iio-rescale.c
>  
>  IKANOS/ADI EAGLE ADSL USB DRIVER

[PATCH] USB:ohci:fix ohci interruption problem

[Longfang Liu]

The operating method of the system entering S4 sleep mode:
echo disk > /sys/power/state

When OHCI enters the S4 sleep state, the USB sleep process will call
check_root_hub_suspend() and ohci_bus_suspend() instead of
ohci_suspend() and ohci_bus_suspend(), this causes the OHCI interrupt
to not be closed.

At this time, if just one device interrupt is reported. Since rh_state
has been changed to OHCI_RH_SUSPENDED after ohci_bus_suspend(), the
driver will not process and close this device interrupt. It will cause
the entire system to be stuck during sleep, causing the device to
fail to respond.

When the abnormal interruption reaches 100,000 times, the system will
forcibly close the interruption and make the device unusable.

Because the root cause of the problem is that ohci_suspend is not
called to perform normal interrupt shutdown operations when the system
enters S4 sleep mode.

Therefore, our solution is to specify freeze interface in this mode to
perform normal suspend_common() operations, and call ohci_suspend()
after check_root_hub_suspend() is executed through the suspend_common()
operation.
After using this solution, it is verified by the stress test of sleep
wake up in S4 mode for a long time that this problem no longer occurs.

Signed-off-by: Longfang Liu 
---
 drivers/usb/core/hcd-pci.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 1547aa6..78a56cd 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -509,6 +509,11 @@ static int resume_common(struct device *dev, int event)
 
 #ifdef CONFIG_PM_SLEEP
 
+static int hcd_pci_freeze(struct device *dev)
+{
+   return suspend_common(dev, device_may_wakeup(dev));
+}
+
 static int hcd_pci_suspend(struct device *dev)
 {
return suspend_common(dev, device_may_wakeup(dev));
@@ -605,8 +610,8 @@ const struct dev_pm_ops usb_hcd_pci_pm_ops = {
.suspend_noirq  = hcd_pci_suspend_noirq,
.resume_noirq   = hcd_pci_resume_noirq,
.resume = hcd_pci_resume,
-   .freeze = check_root_hub_suspended,
-   .freeze_noirq   = check_root_hub_suspended,
+   .freeze = hcd_pci_freeze,
+   .freeze_noirq   = hcd_pci_freeze,
.thaw_noirq = NULL,
.thaw   = NULL,
.poweroff   = hcd_pci_suspend,
-- 
2.8.1

[PATCH v3] writeback: fix obtain a reference to a freeing memcg css

[Muchun Song]

The caller of wb_get_create() should pin the memcg, because
wb_get_create() relies on this guarantee. The rcu read lock
only can guarantee that the memcg css returned by css_from_id()
cannot be released, but the reference of the memcg can be zero.

  rcu_read_lock()
  memcg_css = css_from_id()
  wb_get_create(memcg_css)
  cgwb_create(memcg_css)
  // css_get can change the ref counter from 0 back to 1
  css_get(memcg_css)
  rcu_read_unlock()

Fix it by holding a reference to the css before calling
wb_get_create(). This is not a problem I encountered in the
real world. Just the result of a code review.

Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and 
use it for stat updates")
Signed-off-by: Muchun Song 
Acked-by: Michal Hocko 
---
Changelog in v3:
 1. Do not change GFP_ATOMIC.
 2. Update commit log.

 Thanks for Michal's review and suggestions.

Changelog in v2:
 1. Replace GFP_ATOMIC with GFP_NOIO suggested by Matthew.


 fs/fs-writeback.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 3ac002561327..dedde99da40d 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -506,9 +506,14 @@ static void inode_switch_wbs(struct inode *inode, int 
new_wb_id)
/* find and pin the new wb */
rcu_read_lock();
memcg_css = css_from_id(new_wb_id, _cgrp_subsys);
-   if (memcg_css)
-   isw->new_wb = wb_get_create(bdi, memcg_css, GFP_ATOMIC);
+   if (memcg_css && !css_tryget(memcg_css))
+   memcg_css = NULL;
rcu_read_unlock();
+   if (!memcg_css)
+   goto out_free;
+
+   isw->new_wb = wb_get_create(bdi, memcg_css, GFP_ATOMIC);
+   css_put(memcg_css);
if (!isw->new_wb)
goto out_free;
 
-- 
2.11.0

Re: [PATCH 09/32] MAINTAINERS: update current-sense-shunt.yaml reference

[Jonathan Cameron]

On Thu,  1 Apr 2021 14:17:29 +0200
Mauro Carvalho Chehab  wrote:

> Changeset ce66e52b6c16 ("dt-bindings:iio:afe:current-sense-shunt: txt to yaml 
> conversion.")
> renamed: Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
> to: Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml.
> 
> Update its cross-reference accordingly.
> 
> Fixes: ce66e52b6c16 ("dt-bindings:iio:afe:current-sense-shunt: txt to yaml 
> conversion.")
> Signed-off-by: Mauro Carvalho Chehab 

Applied.

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c7168833da8f..71950316c736 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8796,7 +8796,7 @@ M:  Peter Rosin 
>  L:   linux-...@vger.kernel.org
>  S:   Maintained
>  F:   Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
> -F:   Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
> +F:   Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml
>  F:   Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
>  F:   drivers/iio/afe/iio-rescale.c
>  

Re: [PATCH RESEND] random: remove dead code left over from blocking pool

[Herbert Xu]

Eric Biggers  wrote:
> From: Eric Biggers 
> 
> Remove some dead code that was left over following commit 90ea1c6436d2
> ("random: remove the blocking pool").
> 
> Cc: linux-cry...@vger.kernel.org
> Cc: Andy Lutomirski 
> Cc: Jann Horn 
> Cc: Theodore Ts'o 
> Reviewed-by: Andy Lutomirski 
> Acked-by: Ard Biesheuvel 
> Signed-off-by: Eric Biggers 
> ---
> drivers/char/random.c | 17 ++-
> include/trace/events/random.h | 83 ---
> 2 files changed, 3 insertions(+), 97 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 08/32] MAINTAINERS: update current-sense-amplifier.yaml reference

[Jonathan Cameron]

On Thu,  1 Apr 2021 14:17:28 +0200
Mauro Carvalho Chehab  wrote:

> Changeset fbac26b9ad21 ("dt-bindings:iio:afe:current-sense-amplifier: txt to 
> yaml conversion.")
> renamed: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt
> to: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml.
> 
> Update its cross-reference accordingly.
> 
> Fixes: fbac26b9ad21 ("dt-bindings:iio:afe:current-sense-amplifier: txt to 
> yaml conversion.")
> Signed-off-by: Mauro Carvalho Chehab 
Applied.

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 82220a72eba2..c7168833da8f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8795,7 +8795,7 @@ IIO UNIT CONVERTER
>  M:   Peter Rosin 
>  L:   linux-...@vger.kernel.org
>  S:   Maintained
> -F:   Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt
> +F:   Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
>  F:   Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
>  F:   Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
>  F:   drivers/iio/afe/iio-rescale.c

Re: [PATCH V1 1/2] soc: qcom: aoss: Expose send for generic usecase

[kernel test robot]

Hi Deepak,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.12-rc5 next-20210401]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Deepak-Kumar-Singh/soc-qcom-aoss-Expose-send-for-generic-usecase/20210402-141935
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
1678e493d530e7977cce34e59a86bb86f3c5631e
config: powerpc64-randconfig-r001-20210401 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
b23a314146956dd29b719ab537608ced736fc036)
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
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/799aeefaad3e944f54af76e20156de53331f5d3d
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Deepak-Kumar-Singh/soc-qcom-aoss-Expose-send-for-generic-usecase/20210402-141935
git checkout 799aeefaad3e944f54af76e20156de53331f5d3d
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 
ARCH=powerpc64 

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

All errors (new ones prefixed by >>):

>> drivers/soc/qcom/qcom_aoss.c:16:10: fatal error: 
>> 'linux/soc/qcom/qcom_aoss.h' file not found
   #include 
^~~~
   1 error generated.


vim +16 drivers/soc/qcom/qcom_aoss.c

  > 16  #include 
17  

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


.config.gz
Description: application/gzip

Re: OT: Processor recommendation for RAID6

[Paul Menzel]

Dear Linux folks,


Am 08.04.19 um 18:34 schrieb Paul Menzel:


On 04/08/19 12:33, Paul Menzel wrote:


Can you share your experiences, which processors you choose for
your RAID6 systems? I am particularly interested in Intel
alternatives? Are AMD EPYC processors good alternatives for file
servers? What about ARM and POWER?

We currently use the HBA  Adaptec Smart Storage PQI 12G SAS/PCIe 3
(rev 01), Dell systems and rotating disks.

For example, Dell PowerEdge R730 with 40x E5-2687W v3 @ 3.10GHz,
192 GB of memory, Linux 4.14.87 and XFS file system. (The processor
looks too powerful for the system. At least the processor usage
is at most at one or two thread.)

```
[0.394710] raid6: sse2x1   gen() 11441 MB/s
[0.416710] raid6: sse2x1   xor()  8099 MB/s
[0.438713] raid6: sse2x2   gen() 13359 MB/s
[0.460710] raid6: sse2x2   xor()  8910 MB/s
[0.482712] raid6: sse2x4   gen() 16128 MB/s
[0.504710] raid6: sse2x4   xor() 10009 MB/s
[0.526710] raid6: avx2x1   gen() 22242 MB/s
[0.548709] raid6: avx2x1   xor() 15406 MB/s
[0.570710] raid6: avx2x2   gen() 25699 MB/s
[0.592710] raid6: avx2x2   xor() 16521 MB/s
[0.614709] raid6: avx2x4   gen() 29847 MB/s
[0.636710] raid6: avx2x4   xor() 18617 MB/s
[0.642001] raid6: using algorithm avx2x4 gen() 29847 MB/s
[0.648000] raid6:  xor() 18617 MB/s, rmw enabled
[0.654001] raid6: using avx2x2 recovery algorithm
```


[…]


Maybe some more data. AVX512 from Intel processors really seems to
make a difference in the Linux tests. But also

### Intel Xeon W-2145 (3.7 GHz) with Linux 4.19.19

```
$ dmesg | grep -e raid6 -e smpboot
[0.118880] smpboot: Allowing 16 CPUs, 0 hotplug CPUs
[0.379291] smpboot: CPU0: Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz (family: 
0x6, model: 0x55, stepping: 0x4)
[0.398245] smpboot: Max logical packages: 1
[0.398618] smpboot: Total of 16 processors activated (118400.00 BogoMIPS)
[0.426597] raid6: sse2x1   gen() 13144 MB/s
[0.443601] raid6: sse2x1   xor()  9962 MB/s
[0.460602] raid6: sse2x2   gen() 16863 MB/s
[0.477606] raid6: sse2x2   xor() 11425 MB/s
[0.494609] raid6: sse2x4   gen() 19089 MB/s
[0.511613] raid6: sse2x4   xor() 11988 MB/s
[0.528614] raid6: avx2x1   gen() 26285 MB/s
[0.545617] raid6: avx2x1   xor() 19335 MB/s
[0.562620] raid6: avx2x2   gen() 33953 MB/s
[0.579624] raid6: avx2x2   xor() 21255 MB/s
[0.596627] raid6: avx2x4   gen() 38492 MB/s
[0.613629] raid6: avx2x4   xor() 19722 MB/s
[0.630633] raid6: avx512x1 gen() 37621 MB/s
[0.647636] raid6: avx512x1 xor() 21017 MB/s
[0.664639] raid6: avx512x2 gen() 46859 MB/s
[0.681642] raid6: avx512x2 xor() 26173 MB/s
[0.698645] raid6: avx512x4 gen() 54210 MB/s
[0.715648] raid6: avx512x4 xor() 28041 MB/s
[0.716019] raid6: using algorithm avx512x4 gen() 54210 MB/s
[0.716244] raid6:  xor() 28041 MB/s, rmw enabled
[0.716648] raid6: using avx512x2 recovery algorithm
```

### AMD EPYC Linux 4.19.19 (up to 2.6 GHz according to `lscpu`)

```
$ dmesg | grep -e raid6 -e smpboot
[0.00] smpboot: Allowing 128 CPUs, 0 hotplug CPUs
[0.122478] smpboot: CPU0: AMD EPYC 7601 32-Core Processor (family: 0x17, 
model: 0x1, stepping: 0x2)
[0.364480] smpboot: Max logical packages: 2
[0.366489] smpboot: Total of 128 processors activated (561529.72 BogoMIPS)
[0.503630] raid6: sse2x1   gen()  6136 MB/s
[0.524630] raid6: sse2x1   xor()  5931 MB/s
[0.545627] raid6: sse2x2   gen() 12941 MB/s
[0.566628] raid6: sse2x2   xor()  8173 MB/s
[0.587629] raid6: sse2x4   gen() 13089 MB/s
[0.608627] raid6: sse2x4   xor()  7318 MB/s
[0.629627] raid6: avx2x1   gen() 15164 MB/s
[0.650626] raid6: avx2x1   xor() 10990 MB/s
[0.671627] raid6: avx2x2   gen() 20316 MB/s
[0.692625] raid6: avx2x2   xor() 11886 MB/s
[0.713625] raid6: avx2x4   gen() 20726 MB/s
[0.734628] raid6: avx2x4   xor() 10095 MB/s
[0.739479] raid6: using algorithm avx2x4 gen() 20726 MB/s
[0.745479] raid6:  xor() 10095 MB/s, rmw enabled
[0.750479] raid6: using avx2x2 recovery algorithm
```

Are these values a good benchmark for comparing processors?


After two years, yes they are. I created 16 10 GB files in `/dev/shm`, 
set them up as loop devices, and created a RAID6. For resync speed it 
makes difference.


2 x AMD EPYC 7601 32-Core Processor:34671K/sec
2 x Intel Xeon Gold 6248 CPU @ 2.50GHz: 87533K/sec

So, the current state of affairs seems to be, that AVX512 instructions 
do help for software RAIDs, if you want fast rebuild/resync times. 
Getting, for example, a four core/eight thread Intel Xeon Gold 5222 
might be useful.


Now, the question remains, if AMD processors could make it up with 
higher performance, or better optimized code, or if AVX512 instructions 
are a must,


[…]


Kind regards,

Paul


PS: Here are the commands on the AMD EPYC system:

```
$ for i in $(seq 1 16); do truncate -s 10G /dev/shm/vdisk$i.img; done
$ 

Re: [PATCH 07/32] MAINTAINERS: update envelope-detector.yaml reference

[Jonathan Cameron]

On Thu,  1 Apr 2021 14:17:27 +0200
Mauro Carvalho Chehab  wrote:

> Changeset 66a6dcc20e63 ("dt-bindings:iio:adc:envelope-detector: txt to yaml 
> conversion.")
> renamed: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
> to: Documentation/devicetree/bindings/iio/adc/envelope-detector.yaml.
> 
> Update its cross-reference accordingly.
> 
> Fixes: 66a6dcc20e63 ("dt-bindings:iio:adc:envelope-detector: txt to yaml 
> conversion.")
> Signed-off-by: Mauro Carvalho Chehab 

Applied.

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 52ce258fab37..82220a72eba2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8761,7 +8761,7 @@ M:  Peter Rosin 
>  L:   linux-...@vger.kernel.org
>  S:   Maintained
>  F:   Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
> -F:   Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
> +F:   Documentation/devicetree/bindings/iio/adc/envelope-detector.yaml
>  F:   drivers/iio/adc/envelope-detector.c
>  
>  IIO MULTIPLEXER

Re: [PATCH] Bluetooth: Check inquiry status before sending one

[Marcel Holtmann]

Hi Archie,

> There is a possibility where HCI_INQUIRY flag is set but we still
> send HCI_OP_INQUIRY anyway.
> 
> Such a case can be reproduced by connecting to an LE device while
> active scanning. When the device is discovered, we initiate a
> connection, stop LE Scan, and send Discovery MGMT with status
> disabled, but we don't cancel the inquiry.
> 
> Signed-off-by: Archie Pusaka 
> Reviewed-by: Sonny Sasaka 
> ---
> 
> net/bluetooth/hci_request.c | 3 +++
> 1 file changed, 3 insertions(+)

patch has been applied to bluetooth-next tree.

Regards

Marcel

[PATCH v1 0/2] scsi: pm8001: tiny clean up patches

[Luo Jiaxing]

Several error is reported by checkpatch.pl, here are two patches to clean
them up.

Luo Jiaxing (2):
  scsi: pm8001: clean up for white space
  scsi: pm8001: clean up for open brace

 drivers/scsi/pm8001/pm8001_ctl.c |  8 +++-
 drivers/scsi/pm8001/pm8001_hwi.c | 14 +++---
 drivers/scsi/pm8001/pm8001_sas.c | 20 ++--
 drivers/scsi/pm8001/pm8001_sas.h |  2 +-
 drivers/scsi/pm8001/pm80xx_hwi.c | 14 +++---
 5 files changed, 28 insertions(+), 30 deletions(-)

-- 
2.7.4

[PATCH v1 1/2] scsi: pm8001: clean up for white space

[Luo Jiaxing]

Many error are found like below when run checkpatch.pl

ERROR: space prohibited before that ',' (ctx:WxW)
+int pm8001_mpi_general_event(struct pm8001_hba_info *pm8001_ha , void *piomb);

It all about white space, so fix them.

Signed-off-by: Jianqin Xie 
Signed-off-by: Luo Jiaxing 
---
 drivers/scsi/pm8001/pm8001_ctl.c |  2 +-
 drivers/scsi/pm8001/pm8001_hwi.c | 14 +++---
 drivers/scsi/pm8001/pm8001_sas.c | 20 ++--
 drivers/scsi/pm8001/pm8001_sas.h |  2 +-
 drivers/scsi/pm8001/pm80xx_hwi.c | 14 +++---
 5 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/scsi/pm8001/pm8001_ctl.c b/drivers/scsi/pm8001/pm8001_ctl.c
index 12035ba..ffb4387 100644
--- a/drivers/scsi/pm8001/pm8001_ctl.c
+++ b/drivers/scsi/pm8001/pm8001_ctl.c
@@ -371,7 +371,7 @@ static ssize_t pm8001_ctl_aap_log_show(struct device *cdev,
struct pm8001_hba_info *pm8001_ha = sha->lldd_ha;
int i;
 #define AAP1_MEMMAP(r, c) \
-   (*(u32 *)((u8*)pm8001_ha->memoryMap.region[AAP1].virt_ptr + (r) * 32 \
+   (*(u32 *)((u8 *)pm8001_ha->memoryMap.region[AAP1].virt_ptr + (r) * 32 \
+ (c)))
 
char *str = buf;
diff --git a/drivers/scsi/pm8001/pm8001_hwi.c b/drivers/scsi/pm8001/pm8001_hwi.c
index 49bf2f7..6887fa3 100644
--- a/drivers/scsi/pm8001/pm8001_hwi.c
+++ b/drivers/scsi/pm8001/pm8001_hwi.c
@@ -1826,7 +1826,7 @@ static void pm8001_send_read_log(struct pm8001_hba_info 
*pm8001_ha,
  * that the task has been finished.
  */
 static void
-mpi_ssp_completion(struct pm8001_hba_info *pm8001_ha , void *piomb)
+mpi_ssp_completion(struct pm8001_hba_info *pm8001_ha, void *piomb)
 {
struct sas_task *t;
struct pm8001_ccb_info *ccb;
@@ -2058,7 +2058,7 @@ mpi_ssp_completion(struct pm8001_hba_info *pm8001_ha , 
void *piomb)
 }
 
 /*See the comments for mpi_ssp_completion */
-static void mpi_ssp_event(struct pm8001_hba_info *pm8001_ha , void *piomb)
+static void mpi_ssp_event(struct pm8001_hba_info *pm8001_ha, void *piomb)
 {
struct sas_task *t;
unsigned long flags;
@@ -2294,9 +2294,9 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha, 
void *piomb)
(status != IO_UNDERFLOW)) {
if (!((t->dev->parent) &&
(dev_is_expander(t->dev->parent->dev_type {
-   for (i = 0 , j = 4; j <= 7 && i <= 3; i++ , j++)
+   for (i = 0, j = 4; j <= 7 && i <= 3; i++, j++)
sata_addr_low[i] = pm8001_ha->sas_addr[j];
-   for (i = 0 , j = 0; j <= 3 && i <= 3; i++ , j++)
+   for (i = 0, j = 0; j <= 3 && i <= 3; i++, j++)
sata_addr_hi[i] = pm8001_ha->sas_addr[j];
memcpy(_sata_addr_low, sata_addr_low,
sizeof(sata_addr_low));
@@ -2625,7 +2625,7 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha, 
void *piomb)
 }
 
 /*See the comments for mpi_ssp_completion */
-static void mpi_sata_event(struct pm8001_hba_info *pm8001_ha , void *piomb)
+static void mpi_sata_event(struct pm8001_hba_info *pm8001_ha, void *piomb)
 {
struct sas_task *t;
struct task_status_struct *ts;
@@ -3602,7 +3602,7 @@ int pm8001_mpi_fw_flash_update_resp(struct 
pm8001_hba_info *pm8001_ha,
return 0;
 }
 
-int pm8001_mpi_general_event(struct pm8001_hba_info *pm8001_ha , void *piomb)
+int pm8001_mpi_general_event(struct pm8001_hba_info *pm8001_ha, void *piomb)
 {
u32 status;
int i;
@@ -3685,7 +3685,7 @@ int pm8001_mpi_task_abort_resp(struct pm8001_hba_info 
*pm8001_ha, void *piomb)
  * @pm8001_ha: our hba card information
  * @piomb: IO message buffer
  */
-static int mpi_hw_event(struct pm8001_hba_info *pm8001_ha, void* piomb)
+static int mpi_hw_event(struct pm8001_hba_info *pm8001_ha, void *piomb)
 {
unsigned long flags;
struct hw_event_resp *pPayload =
diff --git a/drivers/scsi/pm8001/pm8001_sas.c b/drivers/scsi/pm8001/pm8001_sas.c
index a98d449..43b77ac 100644
--- a/drivers/scsi/pm8001/pm8001_sas.c
+++ b/drivers/scsi/pm8001/pm8001_sas.c
@@ -877,8 +877,8 @@ static void pm8001_dev_gone_notify(struct domain_device 
*dev)
   pm8001_dev->device_id, pm8001_dev->dev_type);
if (atomic_read(_dev->running_req)) {
spin_unlock_irqrestore(_ha->lock, flags);
-   pm8001_exec_internal_task_abort(pm8001_ha, pm8001_dev ,
-   dev, 1, 0);
+   pm8001_exec_internal_task_abort(pm8001_ha, pm8001_dev,
+   dev, 1, 0);
while (atomic_read(_dev->running_req))
msleep(20);
spin_lock_irqsave(_ha->lock, flags);
@@ -1013,8 +1013,8 @@ int pm8001_I_T_nexus_reset(struct domain_device *dev)
goto out;
}
msleep(2000);

Re: [PATCH 06/32] MAINTAINERS: update dpot-dac.yaml reference

[Jonathan Cameron]

On Thu,  1 Apr 2021 14:17:26 +0200
Mauro Carvalho Chehab  wrote:

> Changeset 06d2ff6fe11e ("dt-bindings:iio:dac:dpot-dac: yaml conversion.")
> renamed: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
> to: Documentation/devicetree/bindings/iio/dac/dpot-dac.yaml.
> 
> Update its cross-reference accordingly.
> 
> Fixes: 06d2ff6fe11e ("dt-bindings:iio:dac:dpot-dac: yaml conversion.")
> Signed-off-by: Mauro Carvalho Chehab 

Applied.

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1985d75d59c7..52ce258fab37 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8753,7 +8753,7 @@ M:  Peter Rosin 
>  L:   linux-...@vger.kernel.org
>  S:   Maintained
>  F:   Documentation/ABI/testing/sysfs-bus-iio-dac-dpot-dac
> -F:   Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
> +F:   Documentation/devicetree/bindings/iio/dac/dpot-dac.yaml
>  F:   drivers/iio/dac/dpot-dac.c
>  
>  IIO ENVELOPE DETECTOR

[PATCH v1 2/2] scsi: pm8001: clean up for open brace

[Luo Jiaxing]

There are few error about open brace is reported by checkpatch.pl:

ERROR: that open brace { should be on the previous line
+static struct error_fw flash_error_table[] =
+{

So fix them all.

Signed-off-by: Jianqin Xie 
Signed-off-by: Luo Jiaxing 
---
 drivers/scsi/pm8001/pm8001_ctl.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/pm8001/pm8001_ctl.c b/drivers/scsi/pm8001/pm8001_ctl.c
index ffb4387..8802fe4 100644
--- a/drivers/scsi/pm8001/pm8001_ctl.c
+++ b/drivers/scsi/pm8001/pm8001_ctl.c
@@ -647,8 +647,7 @@ struct flash_command {
  int code;
 };
 
-static struct flash_command flash_command_table[] =
-{
+static struct flash_command flash_command_table[] = {
  {"set_nvmd",FLASH_CMD_SET_NVMD},
  {"update",  FLASH_CMD_UPDATE},
  {"",FLASH_CMD_NONE} /* Last entry should be NULL. */
@@ -659,8 +658,7 @@ struct error_fw {
  int err_code;
 };
 
-static struct error_fw flash_error_table[] =
-{
+static struct error_fw flash_error_table[] = {
  {"Failed to open fw image file",  FAIL_OPEN_BIOS_FILE},
  {"image header mismatch", FLASH_UPDATE_HDR_ERR},
  {"image offset mismatch", FLASH_UPDATE_OFFSET_ERR},
-- 
2.7.4

[PATCH v4 18/18] arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree

[Hector Martin]

This currently supports:

* SMP (via spin-tables)
* AIC IRQs
* Serial (with earlycon)
* Framebuffer

A number of properties are dynamic, and based on system firmware
decisions that vary from version to version. These are expected
to be filled in by the loader.

Signed-off-by: Hector Martin 
---
 MAINTAINERS  |   1 +
 arch/arm64/boot/dts/Makefile |   1 +
 arch/arm64/boot/dts/apple/Makefile   |   2 +
 arch/arm64/boot/dts/apple/t8103-j274.dts |  45 
 arch/arm64/boot/dts/apple/t8103.dtsi | 135 +++
 5 files changed, 184 insertions(+)
 create mode 100644 arch/arm64/boot/dts/apple/Makefile
 create mode 100644 arch/arm64/boot/dts/apple/t8103-j274.dts
 create mode 100644 arch/arm64/boot/dts/apple/t8103.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index e27332ec1f12..9ac46317840b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1647,6 +1647,7 @@ C:irc://chat.freenode.net/asahi-dev
 T: git https://github.com/AsahiLinux/linux.git
 F: Documentation/devicetree/bindings/arm/apple.yaml
 F: Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
+F: arch/arm64/boot/dts/apple/
 F: drivers/irqchip/irq-apple-aic.c
 F: include/dt-bindings/interrupt-controller/apple-aic.h
 
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index f1173cd93594..639e01a4d855 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -6,6 +6,7 @@ subdir-y += amazon
 subdir-y += amd
 subdir-y += amlogic
 subdir-y += apm
+subdir-y += apple
 subdir-y += arm
 subdir-y += bitmain
 subdir-y += broadcom
diff --git a/arch/arm64/boot/dts/apple/Makefile 
b/arch/arm64/boot/dts/apple/Makefile
new file mode 100644
index ..cbbd701ebf05
--- /dev/null
+++ b/arch/arm64/boot/dts/apple/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_APPLE) += t8103-j274.dtb
diff --git a/arch/arm64/boot/dts/apple/t8103-j274.dts 
b/arch/arm64/boot/dts/apple/t8103-j274.dts
new file mode 100644
index ..e0f6775b9878
--- /dev/null
+++ b/arch/arm64/boot/dts/apple/t8103-j274.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Apple Mac mini (M1, 2020)
+ *
+ * target-type: J274
+ *
+ * Copyright The Asahi Linux Contributors
+ */
+
+/dts-v1/;
+
+#include "t8103.dtsi"
+
+/ {
+   compatible = "apple,j274", "apple,t8103", "apple,arm-platform";
+   model = "Apple Mac mini (M1, 2020)";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   stdout-path = "serial0";
+
+   framebuffer0: framebuffer@0 {
+   compatible = "apple,simple-framebuffer", 
"simple-framebuffer";
+   reg = <0 0 0 0>; /* To be filled by loader */
+   /* Format properties will be added by loader */
+   status = "disabled";
+   };
+   };
+
+   memory@8 {
+   device_type = "memory";
+   reg = <0x8 0 0x2 0>; /* To be filled by loader */
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/apple/t8103.dtsi 
b/arch/arm64/boot/dts/apple/t8103.dtsi
new file mode 100644
index ..ff2bcb64bb13
--- /dev/null
+++ b/arch/arm64/boot/dts/apple/t8103.dtsi
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Apple T8103 "M1" SoC
+ *
+ * Other names: H13G, "Tonga"
+ *
+ * Copyright The Asahi Linux Contributors
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "apple,t8103", "apple,arm-platform";
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   compatible = "apple,icestorm";
+   device_type = "cpu";
+   reg = <0x0 0x0>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0>; /* To be filled by loader */
+   };
+
+   cpu1: cpu@1 {
+   compatible = "apple,icestorm";
+   device_type = "cpu";
+   reg = <0x0 0x1>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0>; /* To be filled by loader */
+   };
+
+   cpu2: cpu@2 {
+   compatible = "apple,icestorm";
+   device_type = "cpu";
+   reg = <0x0 0x2>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0 0>; /* To be filled by loader */
+   };
+
+   cpu3: cpu@3 {
+   compatible = "apple,icestorm";
+   device_type = "cpu";
+   reg = <0x0 

[PATCH v4 17/18] dt-bindings: display: Add apple,simple-framebuffer

[Hector Martin]

Apple SoCs run firmware that sets up a simplefb-compatible framebuffer
for us. Add a compatible for it, and two missing supported formats.

Reviewed-by: Rob Herring 
Reviewed-by: Linus Walleij 
Signed-off-by: Hector Martin 
---
 .../devicetree/bindings/display/simple-framebuffer.yaml  | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml 
b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
index eaf8c54fcf50..c2499a7906f5 100644
--- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
+++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
@@ -54,6 +54,7 @@ properties:
   compatible:
 items:
   - enum:
+  - apple,simple-framebuffer
   - allwinner,simple-framebuffer
   - amlogic,simple-framebuffer
   - const: simple-framebuffer
@@ -84,9 +85,13 @@ properties:
   Format of the framebuffer:
 * `a8b8g8r8` - 32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, 
d[7:0]=r
 * `r5g6b5` - 16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b
+* `x2r10g10b10` - 32-bit pixels, d[29:20]=r, d[19:10]=g, d[9:0]=b
+* `x8r8g8b8` - 32-bit pixels, d[23:16]=r, d[15:8]=g, d[7:0]=b
 enum:
   - a8b8g8r8
   - r5g6b5
+  - x2r10g10b10
+  - x8r8g8b8
 
   display:
 $ref: /schemas/types.yaml#/definitions/phandle
-- 
2.30.0

Re: [PATCH v1 2/3] drivers: char: ipmi: Add Aspeed SSIF BMC driver

[Quan Nguyen]

On 31/03/2021 14:21, Joel Stanley wrote:

On Mon, 29 Mar 2021 at 12:18, Quan Nguyen  wrote:


The SMBus system interface (SSIF) IPMI BMC driver can be used to perform
in-band IPMI communication with their host in management (BMC) side.

This commits adds support specifically for Aspeed AST2500 which commonly
used as Board Management Controllers.

Signed-off-by: Quan Nguyen 


I don't have any SSIF or IPMI related feedback on your patch, but some
general things I noticed when reading it.



Thank you, Joel,
I'm really appreciate your comments for this patch series.

And, as there is a compilation error detected by kernel robot test, I 
was hurry to send out v2 just to fix that just before your email 
arrived. So I'd like to address all comments in my upcoming v3.




---
  drivers/char/ipmi/Kconfig   |  22 +
  drivers/char/ipmi/Makefile  |   2 +
  drivers/char/ipmi/ssif_bmc.c| 645 
  drivers/char/ipmi/ssif_bmc.h|  92 
  drivers/char/ipmi/ssif_bmc_aspeed.c | 132 ++
  5 files changed, 893 insertions(+)
  create mode 100644 drivers/char/ipmi/ssif_bmc.c
  create mode 100644 drivers/char/ipmi/ssif_bmc.h
  create mode 100644 drivers/char/ipmi/ssif_bmc_aspeed.c


It would make sense to split the aspeed implementation into a separate
patch form the ssif framework.


Yes, will do in next version


+++ b/drivers/char/ipmi/ssif_bmc.c
@@ -0,0 +1,645 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * The driver for BMC side of SSIF interface
+ *
+ * Copyright (c) 2021, Ampere Computing LLC
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .


You should omit the licence text; it is replaced by the SPDX tags.


My bad, will remove in next version


+static int send_ssif_bmc_response(struct ssif_bmc_ctx *ssif_bmc, bool 
non_blocking)
+{
+   unsigned long flags;
+   int ret;
+
+   if (!non_blocking) {
+retry:
+   ret = wait_event_interruptible(ssif_bmc->wait_queue,
+  !ssif_bmc->response_in_progress);
+   if (ret)
+   return ret;
+   }
+
+   spin_lock_irqsave(_bmc->lock, flags);


What's the lock doing here? We've just waited for response_in_progress
to be false, so we then take the lock to check what value it is?
Should it also be sending some data in this function?

The lock is to make sure ssif_bmc->response_in_progress are completely 
processed, ie: when the lock already released.
My concern is that reference to that value without acquiring lock may 
not be true as it is under other possess.


In fact, the lock here is for the whole data pointed by ssif_bmc 
pointer. Hence, every reference/modify to this data must be done with 
the lock acquired.



+   if (ssif_bmc->response_in_progress) {
+   spin_unlock_irqrestore(_bmc->lock, flags);
+   if (non_blocking)
+   return -EAGAIN;
+
+   goto retry;


The goto threw me, so I tried re-writing it without. Again, I don't
quite follow what the spinlock is doing.

while (1) {
 if (blocking) {
 ret = wait_event_interruptible();
 if (ret)
  return ret;
 }

  spin_lock_irqsave()
  if (ssif_bmc->response_in_progress) {
  spin_lock_irqrestore()
  if (!blocking)
  return -EAGAIN;
  } else {
 spin_lock_irqrestore()
 break;
  }
}


I'm afraid we would need to re-acquire the lock before modifying 
ssif_bmc->is_singlepart_read and ssif_bmc->response_in_progress below.



+   }
+
+   /*
+* Check the response data length from userspace to determine the type
+* of the response message whether it is single-part or multi-part.
+*/
+   ssif_bmc->is_singlepart_read =
+   (ssif_msg_len(_bmc->response) <= 
(MAX_PAYLOAD_PER_TRANSACTION + 1)) ?
+   true : false; /* 1: byte of length */


I don't follow the 1: byte of length comment, what is it telling me?

The ternary operator is a bit messy here, I'd go for a good old if statement.

The comment indeed does not provide any info here. Will change back to 
if else statement and add more meaningful comment if necessary in next 
version.



+
+   ssif_bmc->response_in_progress = true;
+   spin_unlock_irqrestore(_bmc->lock, flags);
+
+   return 0;
+}



+/* 

[PATCH v4 16/18] arm64: Kconfig: Introduce CONFIG_ARCH_APPLE

[Hector Martin]

This adds a Kconfig option to toggle support for Apple ARM SoCs.
At this time this targets the M1 and later "Apple Silicon" Mac SoCs.

Signed-off-by: Hector Martin 
---
 arch/arm64/Kconfig.platforms | 7 +++
 arch/arm64/configs/defconfig | 1 +
 2 files changed, 8 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index cdfd5fed457f..df320a13915a 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -36,6 +36,13 @@ config ARCH_ALPINE
  This enables support for the Annapurna Labs Alpine
  Soc family.
 
+config ARCH_APPLE
+   bool "Apple Silicon SoC family"
+   select APPLE_AIC
+   help
+ This enables support for Apple's in-house ARM SoC family, starting
+ with the Apple M1.
+
 config ARCH_BCM2835
bool "Broadcom BCM2835 family"
select TIMER_OF
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d612f633b771..54fb257e55f7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_ARCH_ACTIONS=y
 CONFIG_ARCH_AGILEX=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_ALPINE=y
+CONFIG_ARCH_APPLE=y
 CONFIG_ARCH_BCM2835=y
 CONFIG_ARCH_BCM4908=y
 CONFIG_ARCH_BCM_IPROC=y
-- 
2.30.0

[PATCH v4 15/18] irqchip/apple-aic: Add support for the Apple Interrupt Controller

[Hector Martin]

This is the root interrupt controller used on Apple ARM SoCs such as the
M1. This irqchip driver performs multiple functions:

* Handles both IRQs and FIQs

* Drives the AIC peripheral itself (which handles IRQs)

* Dispatches FIQs to downstream hard-wired clients (currently the ARM
  timer).

* Implements a virtual IPI multiplexer to funnel multiple Linux IPIs
  into a single hardware IPI

Signed-off-by: Hector Martin 
---
 MAINTAINERS |   2 +
 drivers/irqchip/Kconfig |   8 +
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/irq-apple-aic.c | 837 
 include/linux/cpuhotplug.h  |   1 +
 5 files changed, 849 insertions(+)
 create mode 100644 drivers/irqchip/irq-apple-aic.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b26a7e23c512..e27332ec1f12 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1647,6 +1647,8 @@ C:irc://chat.freenode.net/asahi-dev
 T: git https://github.com/AsahiLinux/linux.git
 F: Documentation/devicetree/bindings/arm/apple.yaml
 F: Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
+F: drivers/irqchip/irq-apple-aic.c
+F: include/dt-bindings/interrupt-controller/apple-aic.h
 
 ARM/ARTPEC MACHINE SUPPORT
 M: Jesper Nilsson 
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 15536e321df5..d3a14f304ec8 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -577,4 +577,12 @@ config MST_IRQ
help
  Support MStar Interrupt Controller.
 
+config APPLE_AIC
+   bool "Apple Interrupt Controller (AIC)"
+   depends on ARM64
+   default ARCH_APPLE
+   help
+ Support for the Apple Interrupt Controller found on Apple Silicon 
SoCs,
+ such as the M1.
+
 endmenu
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c59b95a0532c..eb6a515f0f64 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -113,3 +113,4 @@ obj-$(CONFIG_LOONGSON_PCH_MSI)  += 
irq-loongson-pch-msi.o
 obj-$(CONFIG_MST_IRQ)  += irq-mst-intc.o
 obj-$(CONFIG_SL28CPLD_INTC)+= irq-sl28cpld.o
 obj-$(CONFIG_MACH_REALTEK_RTL) += irq-realtek-rtl.o
+obj-$(CONFIG_APPLE_AIC)+= irq-apple-aic.o
diff --git a/drivers/irqchip/irq-apple-aic.c b/drivers/irqchip/irq-apple-aic.c
new file mode 100644
index ..ed16b6cc00d7
--- /dev/null
+++ b/drivers/irqchip/irq-apple-aic.c
@@ -0,0 +1,837 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright The Asahi Linux Contributors
+ *
+ * Based on irq-lpc32xx:
+ *   Copyright 2015-2016 Vladimir Zapolskiy 
+ * Based on irq-bcm2836:
+ *   Copyright 2015 Broadcom
+ */
+
+/*
+ * AIC is a fairly simple interrupt controller with the following features:
+ *
+ * - 896 level-triggered hardware IRQs
+ *   - Single mask bit per IRQ
+ *   - Per-IRQ affinity setting
+ *   - Automatic masking on event delivery (auto-ack)
+ *   - Software triggering (ORed with hw line)
+ * - 2 per-CPU IPIs (meant as "self" and "other", but they are
+ *   interchangeable if not symmetric)
+ * - Automatic prioritization (single event/ack register per CPU, lower IRQs =
+ *   higher priority)
+ * - Automatic masking on ack
+ * - Default "this CPU" register view and explicit per-CPU views
+ *
+ * In addition, this driver also handles FIQs, as these are routed to the same
+ * IRQ vector. These are used for Fast IPIs (TODO), the ARMv8 timer IRQs, and
+ * performance counters (TODO).
+ *
+ * Implementation notes:
+ *
+ * - This driver creates two IRQ domains, one for HW IRQs and internal FIQs,
+ *   and one for IPIs.
+ * - Since Linux needs more than 2 IPIs, we implement a software IRQ controller
+ *   and funnel all IPIs into one per-CPU IPI (the second "self" IPI is 
unused).
+ * - FIQ hwirq numbers are assigned after true hwirqs, and are per-cpu.
+ * - DT bindings use 3-cell form (like GIC):
+ *   - <0 nr flags> - hwirq #nr
+ *   - <1 nr flags> - FIQ #nr
+ * - nr=0  Physical HV timer
+ * - nr=1  Virtual HV timer
+ * - nr=2  Physical guest timer
+ * - nr=3  Virtual guest timer
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/*
+ * AIC registers (MMIO)
+ */
+
+#define AIC_INFO   0x0004
+#define AIC_INFO_NR_HW GENMASK(15, 0)
+
+#define AIC_CONFIG 0x0010
+
+#define AIC_WHOAMI 0x2000
+#define AIC_EVENT  0x2004
+#define AIC_EVENT_TYPE GENMASK(31, 16)
+#define AIC_EVENT_NUM  GENMASK(15, 0)
+
+#define AIC_EVENT_TYPE_HW  1
+#define AIC_EVENT_TYPE_IPI 4
+#define AIC_EVENT_IPI_OTHER1
+#define AIC_EVENT_IPI_SELF 2
+
+#define AIC_IPI_SEND   0x2008
+#define AIC_IPI_ACK0x200c
+#define AIC_IPI_MASK_SET   0x2024
+#define AIC_IPI_MASK_CLR   0x2028
+
+#define 

[PATCH v4 14/18] dt-bindings: interrupt-controller: Add DT bindings for apple-aic

[Hector Martin]

AIC is the Apple Interrupt Controller found on Apple ARM SoCs, such as
the M1.

Reviewed-by: Linus Walleij 
Reviewed-by: Rob Herring 
Signed-off-by: Hector Martin 
---
 .../interrupt-controller/apple,aic.yaml   | 88 +++
 MAINTAINERS   |  1 +
 .../interrupt-controller/apple-aic.h  | 15 
 3 files changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
 create mode 100644 include/dt-bindings/interrupt-controller/apple-aic.h

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml 
b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
new file mode 100644
index ..cf6c091a07b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/apple,aic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple Interrupt Controller
+
+maintainers:
+  - Hector Martin 
+
+description: |
+  The Apple Interrupt Controller is a simple interrupt controller present on
+  Apple ARM SoC platforms, including various iPhone and iPad devices and the
+  "Apple Silicon" Macs.
+
+  It provides the following features:
+
+  - Level-triggered hardware IRQs wired to SoC blocks
+- Single mask bit per IRQ
+- Per-IRQ affinity setting
+- Automatic masking on event delivery (auto-ack)
+- Software triggering (ORed with hw line)
+  - 2 per-CPU IPIs (meant as "self" and "other", but they are interchangeable
+if not symmetric)
+  - Automatic prioritization (single event/ack register per CPU, lower IRQs =
+higher priority)
+  - Automatic masking on ack
+  - Default "this CPU" register view and explicit per-CPU views
+
+  This device also represents the FIQ interrupt sources on platforms using AIC,
+  which do not go through a discrete interrupt controller.
+
+allOf:
+  - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+  compatible:
+items:
+  - const: apple,t8103-aic
+  - const: apple,aic
+
+  interrupt-controller: true
+
+  '#interrupt-cells':
+const: 3
+description: |
+  The 1st cell contains the interrupt type:
+- 0: Hardware IRQ
+- 1: FIQ
+
+  The 2nd cell contains the interrupt number.
+- HW IRQs: interrupt number
+- FIQs:
+  - 0: physical HV timer
+  - 1: virtual HV timer
+  - 2: physical guest timer
+  - 3: virtual guest timer
+
+  The 3rd cell contains the interrupt flags. This is normally
+  IRQ_TYPE_LEVEL_HIGH (4).
+
+  reg:
+description: |
+  Specifies base physical address and size of the AIC registers.
+maxItems: 1
+
+required:
+  - compatible
+  - '#interrupt-cells'
+  - interrupt-controller
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+aic: interrupt-controller@23b10 {
+compatible = "apple,t8103-aic", "apple,aic";
+#interrupt-cells = <3>;
+interrupt-controller;
+reg = <0x2 0x3b10 0x0 0x8000>;
+};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index bee9a57e6cec..b26a7e23c512 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1646,6 +1646,7 @@ B:https://github.com/AsahiLinux/linux/issues
 C: irc://chat.freenode.net/asahi-dev
 T: git https://github.com/AsahiLinux/linux.git
 F: Documentation/devicetree/bindings/arm/apple.yaml
+F: Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
 
 ARM/ARTPEC MACHINE SUPPORT
 M: Jesper Nilsson 
diff --git a/include/dt-bindings/interrupt-controller/apple-aic.h 
b/include/dt-bindings/interrupt-controller/apple-aic.h
new file mode 100644
index ..604f2bb30ac0
--- /dev/null
+++ b/include/dt-bindings/interrupt-controller/apple-aic.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0+ OR MIT */
+#ifndef _DT_BINDINGS_INTERRUPT_CONTROLLER_APPLE_AIC_H
+#define _DT_BINDINGS_INTERRUPT_CONTROLLER_APPLE_AIC_H
+
+#include 
+
+#define AIC_IRQ0
+#define AIC_FIQ1
+
+#define AIC_TMR_HV_PHYS0
+#define AIC_TMR_HV_VIRT1
+#define AIC_TMR_GUEST_PHYS 2
+#define AIC_TMR_GUEST_VIRT 3
+
+#endif
-- 
2.30.0

[PATCH v4 13/18] arm64: Move ICH_ sysreg bits from arm-gic-v3.h to sysreg.h

[Hector Martin]

These definitions are in arm-gic-v3.h for historical reasons which no
longer apply. Move them to sysreg.h so the AIC driver can use them, as
it needs to peek into vGIC registers to deal with the GIC maintentance
interrupt.

Acked-by: Marc Zyngier 
Acked-by: Will Deacon 
Signed-off-by: Hector Martin 
---
 arch/arm64/include/asm/sysreg.h| 60 ++
 include/linux/irqchip/arm-gic-v3.h | 56 
 2 files changed, 60 insertions(+), 56 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index d4a5fca984c3..609dc42ec8c8 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -1032,6 +1032,66 @@
 #define TRFCR_ELx_ExTREBIT(1)
 #define TRFCR_ELx_E0TREBIT(0)
 
+
+/* GIC Hypervisor interface registers */
+/* ICH_MISR_EL2 bit definitions */
+#define ICH_MISR_EOI   (1 << 0)
+#define ICH_MISR_U (1 << 1)
+
+/* ICH_LR*_EL2 bit definitions */
+#define ICH_LR_VIRTUAL_ID_MASK ((1ULL << 32) - 1)
+
+#define ICH_LR_EOI (1ULL << 41)
+#define ICH_LR_GROUP   (1ULL << 60)
+#define ICH_LR_HW  (1ULL << 61)
+#define ICH_LR_STATE   (3ULL << 62)
+#define ICH_LR_PENDING_BIT (1ULL << 62)
+#define ICH_LR_ACTIVE_BIT  (1ULL << 63)
+#define ICH_LR_PHYS_ID_SHIFT   32
+#define ICH_LR_PHYS_ID_MASK(0x3ffULL << ICH_LR_PHYS_ID_SHIFT)
+#define ICH_LR_PRIORITY_SHIFT  48
+#define ICH_LR_PRIORITY_MASK   (0xffULL << ICH_LR_PRIORITY_SHIFT)
+
+/* ICH_HCR_EL2 bit definitions */
+#define ICH_HCR_EN (1 << 0)
+#define ICH_HCR_UIE(1 << 1)
+#define ICH_HCR_NPIE   (1 << 3)
+#define ICH_HCR_TC (1 << 10)
+#define ICH_HCR_TALL0  (1 << 11)
+#define ICH_HCR_TALL1  (1 << 12)
+#define ICH_HCR_EOIcount_SHIFT 27
+#define ICH_HCR_EOIcount_MASK  (0x1f << ICH_HCR_EOIcount_SHIFT)
+
+/* ICH_VMCR_EL2 bit definitions */
+#define ICH_VMCR_ACK_CTL_SHIFT 2
+#define ICH_VMCR_ACK_CTL_MASK  (1 << ICH_VMCR_ACK_CTL_SHIFT)
+#define ICH_VMCR_FIQ_EN_SHIFT  3
+#define ICH_VMCR_FIQ_EN_MASK   (1 << ICH_VMCR_FIQ_EN_SHIFT)
+#define ICH_VMCR_CBPR_SHIFT4
+#define ICH_VMCR_CBPR_MASK (1 << ICH_VMCR_CBPR_SHIFT)
+#define ICH_VMCR_EOIM_SHIFT9
+#define ICH_VMCR_EOIM_MASK (1 << ICH_VMCR_EOIM_SHIFT)
+#define ICH_VMCR_BPR1_SHIFT18
+#define ICH_VMCR_BPR1_MASK (7 << ICH_VMCR_BPR1_SHIFT)
+#define ICH_VMCR_BPR0_SHIFT21
+#define ICH_VMCR_BPR0_MASK (7 << ICH_VMCR_BPR0_SHIFT)
+#define ICH_VMCR_PMR_SHIFT 24
+#define ICH_VMCR_PMR_MASK  (0xffUL << ICH_VMCR_PMR_SHIFT)
+#define ICH_VMCR_ENG0_SHIFT0
+#define ICH_VMCR_ENG0_MASK (1 << ICH_VMCR_ENG0_SHIFT)
+#define ICH_VMCR_ENG1_SHIFT1
+#define ICH_VMCR_ENG1_MASK (1 << ICH_VMCR_ENG1_SHIFT)
+
+/* ICH_VTR_EL2 bit definitions */
+#define ICH_VTR_PRI_BITS_SHIFT 29
+#define ICH_VTR_PRI_BITS_MASK  (7 << ICH_VTR_PRI_BITS_SHIFT)
+#define ICH_VTR_ID_BITS_SHIFT  23
+#define ICH_VTR_ID_BITS_MASK   (7 << ICH_VTR_ID_BITS_SHIFT)
+#define ICH_VTR_SEIS_SHIFT 22
+#define ICH_VTR_SEIS_MASK  (1 << ICH_VTR_SEIS_SHIFT)
+#define ICH_VTR_A3V_SHIFT  21
+#define ICH_VTR_A3V_MASK   (1 << ICH_VTR_A3V_SHIFT)
+
 #ifdef __ASSEMBLY__
 
.irp
num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30
diff --git a/include/linux/irqchip/arm-gic-v3.h 
b/include/linux/irqchip/arm-gic-v3.h
index f6d092fdb93d..81cbf85f73de 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -575,67 +575,11 @@
 #define ICC_SRE_EL1_DFB(1U << 1)
 #define ICC_SRE_EL1_SRE(1U << 0)
 
-/*
- * Hypervisor interface registers (SRE only)
- */
-#define ICH_LR_VIRTUAL_ID_MASK ((1ULL << 32) - 1)
-
-#define ICH_LR_EOI (1ULL << 41)
-#define ICH_LR_GROUP   (1ULL << 60)
-#define ICH_LR_HW  (1ULL << 61)
-#define ICH_LR_STATE   (3ULL << 62)
-#define ICH_LR_PENDING_BIT (1ULL << 62)
-#define ICH_LR_ACTIVE_BIT  (1ULL << 63)
-#define ICH_LR_PHYS_ID_SHIFT   32
-#define ICH_LR_PHYS_ID_MASK(0x3ffULL << ICH_LR_PHYS_ID_SHIFT)
-#define ICH_LR_PRIORITY_SHIFT  48
-#define ICH_LR_PRIORITY_MASK   (0xffULL << ICH_LR_PRIORITY_SHIFT)
-
 /* These are for GICv2 emulation only */
 #define GICH_LR_VIRTUALID  (0x3ffUL << 0)
 #define GICH_LR_PHYSID_CPUID_SHIFT (10)
 #define GICH_LR_PHYSID_CPUID   (7UL << GICH_LR_PHYSID_CPUID_SHIFT)
 
-#define ICH_MISR_EOI   (1 << 0)
-#define ICH_MISR_U (1 << 1)
-
-#define ICH_HCR_EN (1 << 0)
-#define ICH_HCR_UIE(1 << 1)
-#define ICH_HCR_NPIE   (1 << 3)
-#define ICH_HCR_TC (1 << 10)
-#define ICH_HCR_TALL0  (1 << 11)
-#define ICH_HCR_TALL1 

[PATCH v4 12/18] of/address: Add infrastructure to declare MMIO as non-posted

[Hector Martin]

This implements the 'nonposted-mmio' boolean property. Placing this
property in a bus marks all direct child devices as requiring
non-posted MMIO mappings. If no such property is found, the default
is posted MMIO.

of_mmio_is_nonposted() performs this check to determine if a given
device has requested non-posted MMIO.

of_address_to_resource() uses this to set the IORESOURCE_MEM_NONPOSTED
flag on resources that require non-posted MMIO.

of_iomap() and of_io_request_and_map() then use this flag to pick the
correct ioremap() variant.

This mechanism is currently restricted to builds that support Apple ARM
platforms, as an optimization.

Reviewed-by: Linus Walleij 
Signed-off-by: Hector Martin 
---
 drivers/of/address.c   | 43 --
 include/linux/of_address.h |  1 +
 2 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 73ddf2540f3f..6485cc536e81 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -847,6 +847,9 @@ static int __of_address_to_resource(struct device_node *dev,
return -EINVAL;
memset(r, 0, sizeof(struct resource));
 
+   if (of_mmio_is_nonposted(dev))
+   flags |= IORESOURCE_MEM_NONPOSTED;
+
r->start = taddr;
r->end = taddr + size - 1;
r->flags = flags;
@@ -896,7 +899,10 @@ void __iomem *of_iomap(struct device_node *np, int index)
if (of_address_to_resource(np, index, ))
return NULL;
 
-   return ioremap(res.start, resource_size());
+   if (res.flags & IORESOURCE_MEM_NONPOSTED)
+   return ioremap_np(res.start, resource_size());
+   else
+   return ioremap(res.start, resource_size());
 }
 EXPORT_SYMBOL(of_iomap);
 
@@ -928,7 +934,11 @@ void __iomem *of_io_request_and_map(struct device_node 
*np, int index,
if (!request_mem_region(res.start, resource_size(), name))
return IOMEM_ERR_PTR(-EBUSY);
 
-   mem = ioremap(res.start, resource_size());
+   if (res.flags & IORESOURCE_MEM_NONPOSTED)
+   mem = ioremap_np(res.start, resource_size());
+   else
+   mem = ioremap(res.start, resource_size());
+
if (!mem) {
release_mem_region(res.start, resource_size());
return IOMEM_ERR_PTR(-ENOMEM);
@@ -1094,3 +1104,32 @@ bool of_dma_is_coherent(struct device_node *np)
return false;
 }
 EXPORT_SYMBOL_GPL(of_dma_is_coherent);
+
+/**
+ * of_mmio_is_nonposted - Check if device uses non-posted MMIO
+ * @np:device node
+ *
+ * Returns true if the "nonposted-mmio" property was found for
+ * the device's bus.
+ *
+ * This is currently only enabled on builds that support Apple ARM devices, as
+ * an optimization.
+ */
+bool of_mmio_is_nonposted(struct device_node *np)
+{
+   struct device_node *parent;
+   bool nonposted;
+
+   if (!IS_ENABLED(CONFIG_ARCH_APPLE))
+   return false;
+
+   parent = of_get_parent(np);
+   if (!parent)
+   return false;
+
+   nonposted = of_property_read_bool(parent, "nonposted-mmio");
+
+   of_node_put(parent);
+   return nonposted;
+}
+EXPORT_SYMBOL_GPL(of_mmio_is_nonposted);
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 88bc943405cd..88f6333fee6c 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -62,6 +62,7 @@ extern struct of_pci_range *of_pci_range_parser_one(
struct of_pci_range_parser *parser,
struct of_pci_range *range);
 extern bool of_dma_is_coherent(struct device_node *np);
+extern bool of_mmio_is_nonposted(struct device_node *np);
 #else /* CONFIG_OF_ADDRESS */
 static inline void __iomem *of_io_request_and_map(struct device_node *device,
  int index, const char *name)
-- 
2.30.0

Re: [PATCH 05/32] MAINTAINERS: update st,hts221.yaml reference

[Jonathan Cameron]

On Thu,  1 Apr 2021 14:17:25 +0200
Mauro Carvalho Chehab  wrote:

> Changeset 9a6ac3138258 ("dt-bindings:iio:humidity:st,hts221 yaml conversion.")
> renamed: Documentation/devicetree/bindings/iio/humidity/hts221.txt
> to: Documentation/devicetree/bindings/iio/humidity/st,hts221.yaml.
> 
> Update its cross-reference accordingly.
> 
> Fixes: 9a6ac3138258 ("dt-bindings:iio:humidity:st,hts221 yaml conversion.")
> Signed-off-by: Mauro Carvalho Chehab 
Applied
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index de9637196526..1985d75d59c7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8287,7 +8287,7 @@ M:  Lorenzo Bianconi 
>  L:   linux-...@vger.kernel.org
>  S:   Maintained
>  W:   http://www.st.com/
> -F:   Documentation/devicetree/bindings/iio/humidity/hts221.txt
> +F:   Documentation/devicetree/bindings/iio/humidity/st,hts221.yaml
>  F:   drivers/iio/humidity/hts221*
>  
>  HUAWEI ETHERNET DRIVER

[PATCH v4 11/18] asm-generic/io.h: implement pci_remap_cfgspace using ioremap_np

[Hector Martin]

Now that we have ioremap_np(), we can make pci_remap_cfgspace() default
to it, falling back to ioremap() on platforms where it is not available.

Remove the arm64 implementation, since that is now redundant. Future
cleanups should be able to do the same for other arches, and eventually
make the generic pci_remap_cfgspace() unconditional.

Signed-off-by: Hector Martin 
---
 arch/arm64/include/asm/io.h | 10 --
 include/linux/io.h  | 21 +
 2 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 953b8703af60..7fd836bea7eb 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -171,16 +171,6 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, 
size_t size);
 #define ioremap_wc(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_NORMAL_NC))
 #define ioremap_np(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRnE))
 
-/*
- * PCI configuration space mapping function.
- *
- * The PCI specification disallows posted write configuration transactions.
- * Add an arch specific pci_remap_cfgspace() definition that is implemented
- * through nGnRnE device memory attribute as recommended by the ARM v8
- * Architecture reference manual Issue A.k B2.8.2 "Device memory".
- */
-#define pci_remap_cfgspace(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRnE))
-
 /*
  * io{read,write}{16,32,64}be() macros
  */
diff --git a/include/linux/io.h b/include/linux/io.h
index d718354ed3e1..6f6b9233f2c3 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -82,20 +82,25 @@ void devm_memunmap(struct device *dev, void *addr);
 #ifdef CONFIG_PCI
 /*
  * The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
- * Posting") mandate non-posted configuration transactions. There is
- * no ioremap API in the kernel that can guarantee non-posted write
- * semantics across arches so provide a default implementation for
- * mapping PCI config space that defaults to ioremap(); arches
- * should override it if they have memory mapping implementations that
- * guarantee non-posted writes semantics to make the memory mapping
- * compliant with the PCI specification.
+ * Posting") mandate non-posted configuration transactions. This default
+ * implementation attempts to use the ioremap_np() API to provide this
+ * on arches that support it, and falls back to ioremap() on those that
+ * don't. Overriding this function is deprecated; arches that properly
+ * support non-posted accesses should implement ioremap_np() instead, which
+ * this default implementation can then use to return mappings compliant with
+ * the PCI specification.
  */
 #ifndef pci_remap_cfgspace
 #define pci_remap_cfgspace pci_remap_cfgspace
 static inline void __iomem *pci_remap_cfgspace(phys_addr_t offset,
   size_t size)
 {
-   return ioremap(offset, size);
+   void __iomem *ret = ioremap_np(offset, size);
+
+   if (!ret)
+   ret = ioremap(offset, size);
+
+   return ret;
 }
 #endif
 #endif
-- 
2.30.0

[PATCH v4 10/18] arm64: Implement ioremap_np() to map MMIO as nGnRnE

[Hector Martin]

This is used on Apple ARM platforms, which require most MMIO
(except PCI devices) to be mapped as nGnRnE.

Acked-by: Marc Zyngier 
Acked-by: Will Deacon 
Signed-off-by: Hector Martin 
---
 arch/arm64/include/asm/io.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 5ea8656a2030..953b8703af60 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -169,6 +169,7 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, 
size_t size);
 
 #define ioremap(addr, size)__ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_wc(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_NORMAL_NC))
+#define ioremap_np(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRnE))
 
 /*
  * PCI configuration space mapping function.
-- 
2.30.0

[PATCH v4 09/18] docs: driver-api: device-io: Document ioremap() variants & access funcs

[Hector Martin]

This documents the newly introduced ioremap_np() along with all the
other common ioremap() variants, and some higher-level abstractions
available.

Reviewed-by: Linus Walleij 
Signed-off-by: Hector Martin 
---
 Documentation/driver-api/device-io.rst | 218 +
 1 file changed, 218 insertions(+)

diff --git a/Documentation/driver-api/device-io.rst 
b/Documentation/driver-api/device-io.rst
index b20864b3ddc7..e9f04b1815d1 100644
--- a/Documentation/driver-api/device-io.rst
+++ b/Documentation/driver-api/device-io.rst
@@ -284,6 +284,224 @@ insl, insw, insb, outsl, outsw, outsb
   first byte in the FIFO register corresponds to the first byte in the memory
   buffer regardless of the architecture.
 
+Device memory mapping modes
+===
+
+Some architectures support multiple modes for mapping device memory.
+ioremap_*() variants provide a common abstraction around these
+architecture-specific modes, with a shared set of semantics.
+
+ioremap() is the most common mapping type, and is applicable to typical device
+memory (e.g. I/O registers). Other modes can offer weaker or stronger
+guarantees, if supported by the architecture. From most to least common, they
+are as follows:
+
+ioremap()
+-
+
+The default mode, suitable for most memory-mapped devices, e.g. control
+registers. Memory mapped using ioremap() has the following characteristics:
+
+* Uncached - CPU-side caches are bypassed, and all reads and writes are handled
+  directly by the device
+* No speculative operations - the CPU may not issue a read or write to this
+  memory, unless the instruction that does so has been reached in committed
+  program flow.
+* No reordering - The CPU may not reorder accesses to this memory mapping with
+  respect to each other. On some architectures, this relies on barriers in
+  readl_relaxed()/writel_relaxed().
+* No repetition - The CPU may not issue multiple reads or writes for a single
+  program instruction.
+* No write-combining - Each I/O operation results in one discrete read or write
+  being issued to the device, and multiple writes are not combined into larger
+  writes. This may or may not be enforced when using __raw I/O accessors or
+  pointer dereferences.
+* Non-executable - The CPU is not allowed to speculate instruction execution
+  from this memory (it probably goes without saying, but you're also not
+  allowed to jump into device memory).
+
+On many platforms and buses (e.g. PCI), writes issued through ioremap()
+mappings are posted, which means that the CPU does not wait for the write to
+actually reach the target device before retiring the write instruction.
+
+On many platforms, I/O accesses must be aligned with respect to the access
+size; failure to do so will result in an exception or unpredictable results.
+
+ioremap_wc()
+
+
+Maps I/O memory as normal memory with write combining. Unlike ioremap(),
+
+* The CPU may speculatively issue reads from the device that the program
+  didn't actually execute, and may choose to basically read whatever it wants.
+* The CPU may reorder operations as long as the result is consistent from the
+  program's point of view.
+* The CPU may write to the same location multiple times, even when the program
+  issued a single write.
+* The CPU may combine several writes into a single larger write.
+
+This mode is typically used for video framebuffers, where it can increase
+performance of writes. It can also be used for other blocks of memory in
+devices (e.g. buffers or shared memory), but care must be taken as accesses are
+not guaranteed to be ordered with respect to normal ioremap() MMIO register
+accesses without explicit barriers.
+
+On a PCI bus, it is usually safe to use ioremap_wc() on MMIO areas marked as
+``IORESOURCE_PREFETCH``, but it may not be used on those without the flag.
+For on-chip devices, there is no corresponding flag, but a driver can use
+ioremap_wc() on a device that is known to be safe.
+
+ioremap_wt()
+
+
+Maps I/O memory as normal memory with write-through caching. Like ioremap_wc(),
+but also,
+
+* The CPU may cache writes issued to and reads from the device, and serve reads
+  from that cache.
+
+This mode is sometimes used for video framebuffers, where drivers still expect
+writes to reach the device in a timely manner (and not be stuck in the CPU
+cache), but reads may be served from the cache for efficiency. However, it is
+rarely useful these days, as framebuffer drivers usually perform writes only,
+for which ioremap_wc() is more efficient (as it doesn't needlessly trash the
+cache). Most drivers should not use this.
+
+ioremap_np()
+
+
+Like ioremap(), but explicitly requests non-posted write semantics. On some
+architectures and buses, ioremap() mappings have posted write semantics, which
+means that writes can appear to "complete" from the point of view of the
+CPU before the written data actually arrives at the target device. Writes are

[PATCH v4 08/18] docs: driver-api: device-io: Document I/O access functions

[Hector Martin]

From: Arnd Bergmann 

This adds more detailed descriptions of the various read/write
primitives available for use with I/O memory/ports.

Reviewed-by: Linus Walleij 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Hector Martin 
---
 Documentation/driver-api/device-io.rst | 138 +
 1 file changed, 138 insertions(+)

diff --git a/Documentation/driver-api/device-io.rst 
b/Documentation/driver-api/device-io.rst
index 764963876d08..b20864b3ddc7 100644
--- a/Documentation/driver-api/device-io.rst
+++ b/Documentation/driver-api/device-io.rst
@@ -146,6 +146,144 @@ There are also equivalents to memcpy. The ins() and
 outs() functions copy bytes, words or longs to the given
 port.
 
+__iomem pointer tokens
+==
+
+The data type for an MMIO address is an ``__iomem`` qualified pointer, such as
+``void __iomem *reg``. On most architectures it is a regular pointer that
+points to a virtual memory address and can be offset or dereferenced, but in
+portable code, it must only be passed from and to functions that explicitly
+operated on an ``__iomem`` token, in particular the ioremap() and
+readl()/writel() functions. The 'sparse' semantic code checker can be used to
+verify that this is done correctly.
+
+While on most architectures, ioremap() creates a page table entry for an
+uncached virtual address pointing to the physical MMIO address, some
+architectures require special instructions for MMIO, and the ``__iomem`` 
pointer
+just encodes the physical address or an offsettable cookie that is interpreted
+by readl()/writel().
+
+Differences between I/O access functions
+
+
+readq(), readl(), readw(), readb(), writeq(), writel(), writew(), writeb()
+
+  These are the most generic accessors, providing serialization against other
+  MMIO accesses and DMA accesses as well as fixed endianness for accessing
+  little-endian PCI devices and on-chip peripherals. Portable device drivers
+  should generally use these for any access to ``__iomem`` pointers.
+
+  Note that posted writes are not strictly ordered against a spinlock, see
+  Documentation/driver-api/io_ordering.rst.
+
+readq_relaxed(), readl_relaxed(), readw_relaxed(), readb_relaxed(),
+writeq_relaxed(), writel_relaxed(), writew_relaxed(), writeb_relaxed()
+
+  On architectures that require an expensive barrier for serializing against
+  DMA, these "relaxed" versions of the MMIO accessors only serialize against
+  each other, but contain a less expensive barrier operation. A device driver
+  might use these in a particularly performance sensitive fast path, with a
+  comment that explains why the usage in a specific location is safe without
+  the extra barriers.
+
+  See memory-barriers.txt for a more detailed discussion on the precise 
ordering
+  guarantees of the non-relaxed and relaxed versions.
+
+ioread64(), ioread32(), ioread16(), ioread8(),
+iowrite64(), iowrite32(), iowrite16(), iowrite8()
+
+  These are an alternative to the normal readl()/writel() functions, with 
almost
+  identical behavior, but they can also operate on ``__iomem`` tokens returned
+  for mapping PCI I/O space with pci_iomap() or ioport_map(). On architectures
+  that require special instructions for I/O port access, this adds a small
+  overhead for an indirect function call implemented in lib/iomap.c, while on
+  other architectures, these are simply aliases.
+
+ioread64be(), ioread32be(), ioread16be()
+iowrite64be(), iowrite32be(), iowrite16be()
+
+  These behave in the same way as the ioread32()/iowrite32() family, but with
+  reversed byte order, for accessing devices with big-endian MMIO registers.
+  Device drivers that can operate on either big-endian or little-endian
+  registers may have to implement a custom wrapper function that picks one or
+  the other depending on which device was found.
+
+  Note: On some architectures, the normal readl()/writel() functions
+  traditionally assume that devices are the same endianness as the CPU, while
+  using a hardware byte-reverse on the PCI bus when running a big-endian 
kernel.
+  Drivers that use readl()/writel() this way are generally not portable, but
+  tend to be limited to a particular SoC.
+
+hi_lo_readq(), lo_hi_readq(), hi_lo_readq_relaxed(), lo_hi_readq_relaxed(),
+ioread64_lo_hi(), ioread64_hi_lo(), ioread64be_lo_hi(), ioread64be_hi_lo(),
+hi_lo_writeq(), lo_hi_writeq(), hi_lo_writeq_relaxed(), lo_hi_writeq_relaxed(),
+iowrite64_lo_hi(), iowrite64_hi_lo(), iowrite64be_lo_hi(), iowrite64be_hi_lo()
+
+  Some device drivers have 64-bit registers that cannot be accessed atomically
+  on 32-bit architectures but allow two consecutive 32-bit accesses instead.
+  Since it depends on the particular device which of the two halves has to be
+  accessed first, a helper is provided for each combination of 64-bit accessors
+  with either low/high or high/low word ordering. A device driver must include
+  either  or  to
+  get the function definitions along 

[PATCH v4 07/18] asm-generic/io.h: Add a non-posted variant of ioremap()

[Hector Martin]

ARM64 currently defaults to posted MMIO (nGnRE), but some devices
require the use of non-posted MMIO (nGnRnE). Introduce a new ioremap()
variant to handle this case. ioremap_np() returns NULL on arches that
do not implement this variant.

sparc64 is the only architecture that needs to be touched directly,
because it includes neither of the generic io.h or iomap.h headers.

This adds the IORESOURCE_MEM_NONPOSTED flag, which maps to this
variant and marks a given resource as requiring non-posted mappings.
This is implemented in the resource system because it is a SoC-level
requirement, so existing drivers do not need special-case code to pick
this ioremap variant.

Then this is implemented in devres by introducing devm_ioremap_np(),
and making devm_ioremap_resource() automatically select this variant
when the resource has the IORESOURCE_MEM_NONPOSTED flag set.

Acked-by: Marc Zyngier 
Signed-off-by: Hector Martin 
---
 .../driver-api/driver-model/devres.rst|  1 +
 arch/sparc/include/asm/io_64.h|  4 
 include/asm-generic/io.h  | 22 ++-
 include/asm-generic/iomap.h   |  9 
 include/linux/io.h|  2 ++
 include/linux/ioport.h|  1 +
 lib/devres.c  | 22 +++
 7 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/Documentation/driver-api/driver-model/devres.rst 
b/Documentation/driver-api/driver-model/devres.rst
index cd8b6e657b94..2f45877a539d 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -309,6 +309,7 @@ IOMAP
   devm_ioremap()
   devm_ioremap_uc()
   devm_ioremap_wc()
+  devm_ioremap_np()
   devm_ioremap_resource() : checks resource, requests memory region, ioremaps
   devm_ioremap_resource_wc()
   devm_platform_ioremap_resource() : calls devm_ioremap_resource() for 
platform device
diff --git a/arch/sparc/include/asm/io_64.h b/arch/sparc/include/asm/io_64.h
index 9bb27e5c22f1..9fbfc9574432 100644
--- a/arch/sparc/include/asm/io_64.h
+++ b/arch/sparc/include/asm/io_64.h
@@ -409,6 +409,10 @@ static inline void __iomem *ioremap(unsigned long offset, 
unsigned long size)
 #define ioremap_uc(X,Y)ioremap((X),(Y))
 #define ioremap_wc(X,Y)ioremap((X),(Y))
 #define ioremap_wt(X,Y)ioremap((X),(Y))
+static inline void __iomem *ioremap_np(unsigned long offset, unsigned long 
size)
+{
+   return NULL;
+}
 
 static inline void iounmap(volatile void __iomem *addr)
 {
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index c6af40ce03be..082e0c96db6e 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -942,7 +942,9 @@ static inline void *phys_to_virt(unsigned long address)
  *
  * ioremap_wc() and ioremap_wt() can provide more relaxed caching attributes
  * for specific drivers if the architecture choses to implement them.  If they
- * are not implemented we fall back to plain ioremap.
+ * are not implemented we fall back to plain ioremap. Conversely, ioremap_np()
+ * can provide stricter non-posted write semantics if the architecture
+ * implements them.
  */
 #ifndef CONFIG_MMU
 #ifndef ioremap
@@ -993,6 +995,24 @@ static inline void __iomem *ioremap_uc(phys_addr_t offset, 
size_t size)
 {
return NULL;
 }
+
+/*
+ * ioremap_np needs an explicit architecture implementation, as it
+ * requests stronger semantics than regular ioremap(). Portable drivers
+ * should instead use one of the higher-level abstractions, like
+ * devm_ioremap_resource(), to choose the correct variant for any given
+ * device and bus. Portable drivers with a good reason to want non-posted
+ * write semantics should always provide an ioremap() fallback in case
+ * ioremap_np() is not available.
+ */
+#ifndef ioremap_np
+#define ioremap_np ioremap_np
+static inline void __iomem *ioremap_np(phys_addr_t offset, size_t size)
+{
+   return NULL;
+}
+#endif
+
 #endif
 
 #ifdef CONFIG_HAS_IOPORT_MAP
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 649224664969..9b3eb6d86200 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -101,6 +101,15 @@ extern void ioport_unmap(void __iomem *);
 #define ioremap_wt ioremap
 #endif
 
+#ifndef ARCH_HAS_IOREMAP_NP
+/* See the comment in asm-generic/io.h about ioremap_np(). */
+#define ioremap_np ioremap_np
+static inline void __iomem *ioremap_np(phys_addr_t offset, size_t size)
+{
+   return NULL;
+}
+#endif
+
 #ifdef CONFIG_PCI
 /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
 struct pci_dev;
diff --git a/include/linux/io.h b/include/linux/io.h
index 8394c56babc2..d718354ed3e1 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -68,6 +68,8 @@ void __iomem *devm_ioremap_uc(struct device *dev, 
resource_size_t offset,
   

[PATCH v4 06/18] arm64: arch_timer: Implement support for interrupt-names

[Hector Martin]

This allows the devicetree to correctly represent the available set of
timers, which varies from device to device, without the need for fake
dummy interrupts for unavailable slots.

Also add the hyp-virt timer/PPI, which is not currently used, but worth
representing.

Reviewed-by: Tony Lindgren 
Reviewed-by: Linus Walleij 
Reviewed-by: Marc Zyngier 
Signed-off-by: Hector Martin 
---
 drivers/clocksource/arm_arch_timer.c | 24 +---
 include/clocksource/arm_arch_timer.h |  1 +
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index d0177824c518..932f95691e27 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -63,6 +63,14 @@ struct arch_timer {
 static u32 arch_timer_rate;
 static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];
 
+static const char *arch_timer_ppi_names[ARCH_TIMER_MAX_TIMER_PPI] = {
+   [ARCH_TIMER_PHYS_SECURE_PPI]= "sec-phys",
+   [ARCH_TIMER_PHYS_NONSECURE_PPI] = "phys",
+   [ARCH_TIMER_VIRT_PPI]   = "virt",
+   [ARCH_TIMER_HYP_PPI]= "hyp-phys",
+   [ARCH_TIMER_HYP_VIRT_PPI]   = "hyp-virt",
+};
+
 static struct clock_event_device __percpu *arch_timer_evt;
 
 static enum arch_timer_ppi_nr arch_timer_uses_ppi = ARCH_TIMER_VIRT_PPI;
@@ -1280,8 +1288,9 @@ static void __init arch_timer_populate_kvm_info(void)
 
 static int __init arch_timer_of_init(struct device_node *np)
 {
-   int i, ret;
+   int i, irq, ret;
u32 rate;
+   bool has_names;
 
if (arch_timers_present & ARCH_TIMER_TYPE_CP15) {
pr_warn("multiple nodes in dt, skipping\n");
@@ -1289,8 +1298,17 @@ static int __init arch_timer_of_init(struct device_node 
*np)
}
 
arch_timers_present |= ARCH_TIMER_TYPE_CP15;
-   for (i = ARCH_TIMER_PHYS_SECURE_PPI; i < ARCH_TIMER_MAX_TIMER_PPI; i++)
-   arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
+
+   has_names = of_property_read_bool(np, "interrupt-names");
+
+   for (i = ARCH_TIMER_PHYS_SECURE_PPI; i < ARCH_TIMER_MAX_TIMER_PPI; i++) 
{
+   if (has_names)
+   irq = of_irq_get_byname(np, arch_timer_ppi_names[i]);
+   else
+   irq = of_irq_get(np, i);
+   if (irq > 0)
+   arch_timer_ppi[i] = irq;
+   }
 
arch_timer_populate_kvm_info();
 
diff --git a/include/clocksource/arm_arch_timer.h 
b/include/clocksource/arm_arch_timer.h
index 1d68d5613dae..73c7139c866f 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -32,6 +32,7 @@ enum arch_timer_ppi_nr {
ARCH_TIMER_PHYS_NONSECURE_PPI,
ARCH_TIMER_VIRT_PPI,
ARCH_TIMER_HYP_PPI,
+   ARCH_TIMER_HYP_VIRT_PPI,
ARCH_TIMER_MAX_TIMER_PPI
 };
 
-- 
2.30.0

Re: [PATCH 0/2] net/Blutooth - Coding style fix

[Marcel Holtmann]

Hi Meng,

> Remove 'return' in void function and fix some coding style
> 
> Meng Yu (2):
>  Bluetooth: Remove 'return' in void function
>  Bluetooth: Coding style fix
> 
> net/bluetooth/6lowpan.c | 5 +
> net/bluetooth/hci_debugfs.c | 8 
> net/bluetooth/hci_event.c   | 2 +-
> net/bluetooth/hci_request.c | 6 ++
> net/bluetooth/l2cap_core.c  | 7 +++
> 5 files changed, 11 insertions(+), 17 deletions(-)

both patches have been applied to bluetooth-next tree.

Regards

Marcel

[PATCH v4 05/18] dt-bindings: timer: arm,arch_timer: Add interrupt-names support

[Hector Martin]

Not all platforms provide the same set of timers/interrupts, and Linux
only needs one (plus kvm/guest ones); some platforms are working around
this by using dummy fake interrupts. Implementing interrupt-names allows
the devicetree to specify an arbitrary set of available interrupts, so
the timer code can pick the right one.

This also adds the hyp-virt timer/interrupt, which was previously not
expressed in the fixed 4-interrupt form.

Reviewed-by: Linus Walleij 
Acked-by: Marc Zyngier 
Reviewed-by: Tony Lindgren 
Signed-off-by: Hector Martin 
---
 .../bindings/timer/arm,arch_timer.yaml| 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml 
b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
index 2c75105c1398..7f5e3af58255 100644
--- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
+++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
@@ -34,11 +34,30 @@ properties:
   - arm,armv8-timer
 
   interrupts:
+minItems: 1
+maxItems: 5
 items:
   - description: secure timer irq
   - description: non-secure timer irq
   - description: virtual timer irq
   - description: hypervisor timer irq
+  - description: hypervisor virtual timer irq
+
+  interrupt-names:
+oneOf:
+  - minItems: 2
+items:
+  - const: phys
+  - const: virt
+  - const: hyp-phys
+  - const: hyp-virt
+  - minItems: 3
+items:
+  - const: sec-phys
+  - const: phys
+  - const: virt
+  - const: hyp-phys
+  - const: hyp-virt
 
   clock-frequency:
 description: The frequency of the main counter, in Hz. Should be present
-- 
2.30.0

[PATCH v4 04/18] arm64: cputype: Add CPU implementor & types for the Apple M1 cores

[Hector Martin]

The implementor will be used to condition the FIQ support quirk.

The specific CPU types are not used at the moment, but let's add them
for documentation purposes.

Acked-by: Will Deacon 
Signed-off-by: Hector Martin 
---
 arch/arm64/include/asm/cputype.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index ef5b040dee44..6231e1f0abe7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -59,6 +59,7 @@
 #define ARM_CPU_IMP_NVIDIA 0x4E
 #define ARM_CPU_IMP_FUJITSU0x46
 #define ARM_CPU_IMP_HISI   0x48
+#define ARM_CPU_IMP_APPLE  0x61
 
 #define ARM_CPU_PART_AEM_V80xD0F
 #define ARM_CPU_PART_FOUNDATION0xD00
@@ -99,6 +100,9 @@
 
 #define HISI_CPU_PART_TSV110   0xD01
 
+#define APPLE_CPU_PART_M1_ICESTORM 0x022
+#define APPLE_CPU_PART_M1_FIRESTORM0x023
+
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
 #define MIDR_CORTEX_A72 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A72)
@@ -127,6 +131,8 @@
 #define MIDR_NVIDIA_CARMEL MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, 
NVIDIA_CPU_PART_CARMEL)
 #define MIDR_FUJITSU_A64FX MIDR_CPU_MODEL(ARM_CPU_IMP_FUJITSU, 
FUJITSU_CPU_PART_A64FX)
 #define MIDR_HISI_TSV110 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV110)
+#define MIDR_APPLE_M1_ICESTORM MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE, 
APPLE_CPU_PART_M1_ICESTORM)
+#define MIDR_APPLE_M1_FIRESTORM MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE, 
APPLE_CPU_PART_M1_FIRESTORM)
 
 /* Fujitsu Erratum 010001 affects A64FX 1.0 and 1.1, (v0r0 and v1r0) */
 #define MIDR_FUJITSU_ERRATUM_010001MIDR_FUJITSU_A64FX
-- 
2.30.0

[PATCH v4 03/18] dt-bindings: arm: cpus: Add apple,firestorm & icestorm compatibles

[Hector Martin]

These are the CPU cores in the "Apple Silicon" M1 SoC.

Reviewed-by: Rob Herring 
Signed-off-by: Hector Martin 
---
 Documentation/devicetree/bindings/arm/cpus.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml 
b/Documentation/devicetree/bindings/arm/cpus.yaml
index 26b886b20b27..c299423dc7cb 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -85,6 +85,8 @@ properties:
 
   compatible:
 enum:
+  - apple,icestorm
+  - apple,firestorm
   - arm,arm710t
   - arm,arm720t
   - arm,arm740t
-- 
2.30.0

[PATCH v4 02/18] dt-bindings: arm: apple: Add bindings for Apple ARM platforms

[Hector Martin]

This introduces bindings for all three 2020 Apple M1 devices:

* apple,j274 - Mac mini (M1, 2020)
* apple,j293 - MacBook Pro (13-inch, M1, 2020)
* apple,j313 - MacBook Air (M1, 2020)

Reviewed-by: Linus Walleij 
Reviewed-by: Rob Herring 
Signed-off-by: Hector Martin 
---
 .../devicetree/bindings/arm/apple.yaml| 64 +++
 MAINTAINERS   | 10 +++
 2 files changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/apple.yaml

diff --git a/Documentation/devicetree/bindings/arm/apple.yaml 
b/Documentation/devicetree/bindings/arm/apple.yaml
new file mode 100644
index ..1e772c85206c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/apple.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/apple.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple ARM Machine Device Tree Bindings
+
+maintainers:
+  - Hector Martin 
+
+description: |
+  ARM platforms using SoCs designed by Apple Inc., branded "Apple Silicon".
+
+  This currently includes devices based on the "M1" SoC, starting with the
+  three Mac models released in late 2020:
+
+  - Mac mini (M1, 2020)
+  - MacBook Pro (13-inch, M1, 2020)
+  - MacBook Air (M1, 2020)
+
+  The compatible property should follow this format:
+
+  compatible = "apple,", "apple,", "apple,arm-platform";
+
+   represents the board/device and comes from the `target-type`
+  property of the root node of the Apple Device Tree, lowercased. It can be
+  queried on macOS using the following command:
+
+  $ ioreg -d2 -l | grep target-type
+
+   is the lowercased SoC ID. Apple uses at least *five* different
+  names for their SoCs:
+
+  - Marketing name ("M1")
+  - Internal name ("H13G")
+  - Codename ("Tonga")
+  - SoC ID ("T8103")
+  - Package/IC part number ("APL1102")
+
+  Devicetrees should use the lowercased SoC ID, to avoid confusion if
+  multiple SoCs share the same marketing name. This can be obtained from
+  the `compatible` property of the arm-io node of the Apple Device Tree,
+  which can be queried as follows on macOS:
+
+  $ ioreg -n arm-io | grep compatible
+
+properties:
+  $nodename:
+const: "/"
+  compatible:
+oneOf:
+  - description: Apple M1 SoC based platforms
+items:
+  - enum:
+  - apple,j274 # Mac mini (M1, 2020)
+  - apple,j293 # MacBook Pro (13-inch, M1, 2020)
+  - apple,j313 # MacBook Air (M1, 2020)
+  - const: apple,t8103
+  - const: apple,arm-platform
+
+additionalProperties: true
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 88ad851fb5da..bee9a57e6cec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1637,6 +1637,16 @@ F:   arch/arm/mach-alpine/
 F: arch/arm64/boot/dts/amazon/
 F: drivers/*/*alpine*
 
+ARM/APPLE MACHINE SUPPORT
+M: Hector Martin 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+W: https://asahilinux.org
+B: https://github.com/AsahiLinux/linux/issues
+C: irc://chat.freenode.net/asahi-dev
+T: git https://github.com/AsahiLinux/linux.git
+F: Documentation/devicetree/bindings/arm/apple.yaml
+
 ARM/ARTPEC MACHINE SUPPORT
 M: Jesper Nilsson 
 M: Lars Persson 
-- 
2.30.0

[PATCH v4 01/18] dt-bindings: vendor-prefixes: Add apple prefix

[Hector Martin]

This is different from the legacy AAPL prefix used on PPC, but
consensus is that we prefer `apple` for these new platforms.

Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Linus Walleij 
Reviewed-by: Rob Herring 
Signed-off-by: Hector Martin 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index f6064d84a424..7b59b6d3f526 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -103,6 +103,8 @@ patternProperties:
 description: Anvo-Systems Dresden GmbH
   "^apm,.*":
 description: Applied Micro Circuits Corporation (APM)
+  "^apple,.*":
+description: Apple Inc.
   "^aptina,.*":
 description: Aptina Imaging
   "^arasan,.*":
-- 
2.30.0

[PATCH v4 00/18] Apple M1 SoC platform bring-up

[Hector Martin]

This series brings up initial support for the Apple M1 SoC, used in the
2020 Mac Mini, MacBook Pro, and MacBook Air models.

The following features are supported in this initial port:

- UART (samsung-style) with earlycon support
- Interrupts, including affinity and IPIs (Apple Interrupt Controller)
- SMP (through standard spin-table support)
- simplefb-based framebuffer
- Devicetree for the Mac Mini (should work for the others too at this
  stage)

See below for an overview of changes since v3.

== Merge notes ==

This patchset has several dependencies:

* Build dep on the FIQ support series in [1].
* Runtime dep on the Samsung TTY changes in tty-next (modulo DT validation).
* Runtime dep on the nVHE changes being reviewed in [2].

A tree containing this patchset on top of the required dependencies is
available at [3][4], for those who want to test it.

This series is expected to be merged by Arnd via the SoC tree.
Maintainers, please ack if you are happy with the patches. We will
coordinate with Arnd and Mark on the FIQ series to make sure all
that goes smoothly.

[1] 
https://lore.kernel.org/linux-arm-kernel/20210315115629.57191-1-mark.rutl...@arm.com/T/
[2] 
https://lore.kernel.org/linux-arm-kernel/20210330173947.999859-1-...@kernel.org/T/
[3] git://github.com/AsahiLinux/linux.git upstream-bringup-v4
[4] https://github.com/AsahiLinux/linux/tree/upstream-bringup-v4

== Testing notes ==

This has been tested on an Apple M1 Mac Mini booting to a framebuffer
and serial console, with SMP and KASLR, with an arm64 defconfig
(+ CONFIG_FB_SIMPLE for the fb). In addition, the AIC driver now supports
running in EL1, tested in UP mode only.

== Patch overview ==

- 01-02 Core platform DT bindings
- 03-04 CPU DT bindings and MIDR defines
- 05-06 Add interrupt-names support to the ARM timer driver
This is used to cleanly express the lack of a secure timer;
platforms in the past have used various hacks like dummy
IRQs here.
- 07-12 ioremap_np() (nGnRnE) support
The fabric in these SoCs only supports nGnRnE accesses for
standard MMIO, except for PCI ranges which use nGnRE. Linux
currently defaults to the latter on ARM64, so this adds a new
ioremap type and DT properties to automatically select it for
drivers using OF and devm abstractions, under buses specified
in DT.
- 13-15 AIC (Apple Interrupt Controller) driver and support defines
This also embeds FIQ handling for this platform.
- 16Introduce CONFIG_ARCH_APPLE & add it to defconfig
- 17simple-framebuffer bindings for Apple (trivial)
- 18Add the initial M1 Mac Mini (j274) devicetree

== About the hardware ==

These machines officially support booting unsigned/user-provided
XNU-like kernels, with a very different boot protocol and devicetree
format. We are developing an initial bootloader, m1n1 [1], to take care
of as many hardware peculiarities as possible and present a standard
Linux arm64 boot protocol and device tree. In the future, I expect that
production setups will add U-Boot and perhaps GRUB into the boot chain,
to make the boot process similar to other ARM64 platforms.

The machines expose their debug UART over USB Type C, triggered with
vendor-specific USB-PD commands. Currently, the easiest way to get a
serial console on these machines is to use a second M1 box and a simple
USB C cable [2]. You can also build a DIY interface using an Arduino, a
FUSB302 chip or board, and a 1.2V UART-TTL adapter [3]. In the coming
weeks we will be designing an open hardware project to provide
serial/debug connectivity to these machines (and, hopefully, also
support other UART-over-Type C setups from other vendors). Please
contact me privately if you are interested in getting an early prototype
version of one of these devices.

We also have WIP/not merged yet support for loading kernels and
interacting via dwc3 usb-gadget, which works with a standard C-C or C-A
cable and any Linux host.

A quickstart guide to booting Linux kernels on these machines is
available at [4], and we are documenting the hardware at [5].

[1] https://github.com/AsahiLinux/m1n1/
[2] https://github.com/AsahiLinux/macvdmtool/
[3] https://github.com/AsahiLinux/vdmtool/
[4] https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart
[5] https://github.com/AsahiLinux/docs/wiki

== Project Blurb ==

Asahi Linux is an open community project dedicated to developing and
maintaining mainline support for Apple Silicon on Linux. Feel free to
drop by #asahi and #asahi-dev on freenode to chat with us, or check
our website for more information on the project:

https://asahilinux.org/

== Changes since v3 ==

* Serial patches have already been merged into tty-next and are
  no longer included
* nVHE fixup patches are being reviewed separately and no longer
  part of this series
* Updated arm,arch-timer bindings to be more restrictive, renamed
  phys-secure to sec-phys
* Reordered ioremap() variants list in device-io.rst
* 

[PATCH] staging: fbtft: change snprintf() to scnprintf()

[Carlis]

From: Xuezhi Zhang 

show() must not use snprintf() when formatting the value to
be returned to user space.

Signed-off-by: Xuezhi Zhang 
---
 drivers/staging/fbtft/fbtft-sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fbtft/fbtft-sysfs.c 
b/drivers/staging/fbtft/fbtft-sysfs.c
index 26e52cc2de64..7df92db648d6 100644
--- a/drivers/staging/fbtft/fbtft-sysfs.c
+++ b/drivers/staging/fbtft/fbtft-sysfs.c
@@ -199,7 +199,7 @@ static ssize_t show_debug(struct device *device,
struct fb_info *fb_info = dev_get_drvdata(device);
struct fbtft_par *par = fb_info->par;
 
-   return snprintf(buf, PAGE_SIZE, "%lu\n", par->debug);
+   return scnprintf(buf, PAGE_SIZE, "%lu\n", par->debug);
 }
 
 static struct device_attribute debug_device_attr =
-- 
2.25.1

Re: [PATCH 01/32] MAINTAINERS: update adi,ad5758.yaml reference

[Jonathan Cameron]

On Thu,  1 Apr 2021 14:17:21 +0200
Mauro Carvalho Chehab  wrote:

> Changeset 1e6536ee349b ("dt-bindings:iio:dac:adi,ad5758 yaml conversion")
> renamed: Documentation/devicetree/bindings/iio/dac/ad5758.txt
> to: Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml.
> 
> Update its cross-reference accordingly.
> 
> Fixes: 1e6536ee349b ("dt-bindings:iio:dac:adi,ad5758 yaml conversion")
> Signed-off-by: Mauro Carvalho Chehab 
Hi Mauro,

Oops. These have been on my todo list for a while to tidy up. I kind
of forgot to check MAINTAINERS whilst doing the conversions.

Ah well, thanks for tidying up.

Applied to the togreg branch of iio.git and pushed out as testing for
autobuilders to probably not notice.

Thanks

Jonathan

p.s. For anything IIO related I'll notice more quickly in general
if linux-...@vger.kernel.org is cc'd.

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 38d823d72e52..4c8a926ef201 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1141,7 +1141,7 @@ W:  
> http://ez.analog.com/community/linux-device-drivers
>  F:   Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523
>  F:   Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
>  F:   Documentation/devicetree/bindings/iio/*/adi,*
> -F:   Documentation/devicetree/bindings/iio/dac/ad5758.txt
> +F:   Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
>  F:   drivers/iio/*/ad*
>  F:   drivers/iio/adc/ltc249*
>  F:   drivers/iio/amplifiers/hmc425a.c

Re: [PATCH RESEND] random: initialize ChaCha20 constants with correct endianness

[Herbert Xu]

On Sun, Mar 21, 2021 at 10:13:47PM -0700, Eric Biggers wrote:
> From: Eric Biggers 
> 
> On big endian CPUs, the ChaCha20-based CRNG is using the wrong
> endianness for the ChaCha20 constants.
> 
> This doesn't matter cryptographically, but technically it means it's not
> ChaCha20 anymore.  Fix it to always use the standard constants.
> 
> Cc: linux-cry...@vger.kernel.org
> Cc: Andy Lutomirski 
> Cc: Jann Horn 
> Cc: Theodore Ts'o 
> Acked-by: Herbert Xu 
> Acked-by: Ard Biesheuvel 
> Signed-off-by: Eric Biggers 
> ---
>  drivers/char/random.c   | 4 ++--
>  include/crypto/chacha.h | 9 +++--
>  2 files changed, 9 insertions(+), 4 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 24/32] MAINTAINERS: update imi,rdacm2x-gmsl.yaml reference

[Laurent Pinchart]

On Fri, Apr 02, 2021 at 12:01:35PM +0300, Laurent Pinchart wrote:
> Hi Mauro,
> 
> Thank you for the patch.
> 
> On Thu, Apr 01, 2021 at 02:17:44PM +0200, Mauro Carvalho Chehab wrote:
> > The file name: Documentation/devicetree/bindings/media/i2c/rdacm2x-gmsl.yaml
> > should be, instead: 
> > Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml.
> 
> While at it, shouldn't we also rename the file to imi,rdacm2x.yaml ?

I spoke too fast, sorry. There are RDACM2x cameras that use FPD-Link III
(RDACM23, 24, 25, 28, 29).

> > Update its cross-reference accordingly.
> > 
> > Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver")
> > Fixes: e9f817689789 ("media: dt-bindings: media: i2c: Add bindings for IMI 
> > RDACM2x")
> > Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Laurent Pinchart 

> > ---
> >  MAINTAINERS | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 1644b6e9697c..b405ee71f730 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -15258,7 +15258,7 @@ M:  Laurent Pinchart 
> > 
> >  M: Niklas Söderlund 
> >  L: linux-me...@vger.kernel.org
> >  S: Maintained
> > -F: Documentation/devicetree/bindings/media/i2c/rdacm2x-gmsl.yaml
> > +F: Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
> >  F: drivers/media/i2c/max9271.c
> >  F: drivers/media/i2c/max9271.h
> >  F: drivers/media/i2c/rdacm21.c

-- 
Regards,

Laurent Pinchart

Re: [PATCH 24/32] MAINTAINERS: update imi,rdacm2x-gmsl.yaml reference

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Thu, Apr 01, 2021 at 02:17:44PM +0200, Mauro Carvalho Chehab wrote:
> The file name: Documentation/devicetree/bindings/media/i2c/rdacm2x-gmsl.yaml
> should be, instead: 
> Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml.

While at it, shouldn't we also rename the file to imi,rdacm2x.yaml ?

> Update its cross-reference accordingly.
> 
> Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver")
> Fixes: e9f817689789 ("media: dt-bindings: media: i2c: Add bindings for IMI 
> RDACM2x")
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1644b6e9697c..b405ee71f730 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15258,7 +15258,7 @@ M:Laurent Pinchart 
> 
>  M:   Niklas Söderlund 
>  L:   linux-me...@vger.kernel.org
>  S:   Maintained
> -F:   Documentation/devicetree/bindings/media/i2c/rdacm2x-gmsl.yaml
> +F:   Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
>  F:   drivers/media/i2c/max9271.c
>  F:   drivers/media/i2c/max9271.h
>  F:   drivers/media/i2c/rdacm21.c

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/3] KVM: X86: Rename DR6_INIT to DR6_ACTIVE_LOW

[Paolo Bonzini]

On 02/04/21 10:53, Xiaoyao Li wrote:




Hi Paolo,

Fenghua's bare metal support is in tip tree now.
https://lore.kernel.org/lkml/20210322135325.682257-1-fenghua...@intel.com/

Will the rest KVM patches get into 5.13 together?


Yes, they will.

Thanks for the notice!

Paolo

Re: [PATCH v6 4/5] drm/bridge: anx7625: add HDCP support

[Laurent Pinchart]

Hi Xin,

On Fri, Apr 02, 2021 at 10:27:08AM +0800, Xin Ji wrote:
> On Mon, Mar 29, 2021 at 02:02:08PM -0400, Sean Paul wrote:
> > On Mon, Mar 29, 2021 at 6:27 AM Xin Ji  wrote:
> > >
> > > On Thu, Mar 25, 2021 at 02:19:23PM -0400, Sean Paul wrote:
> > > > On Fri, Mar 19, 2021 at 2:35 AM Xin Ji  wrote:
> > > > >
> > > > > Add HDCP feature, enable HDCP function through chip internal key
> > > > > and downstream's capability.
> > > > >
> > > > > Signed-off-by: Xin Ji 
> > > > > ---
> > 
> > /snip
> > 
> > > > >  static void anx7625_dp_start(struct anx7625_data *ctx)
> > > > >  {
> > > > > int ret;
> > > > > @@ -643,6 +787,9 @@ static void anx7625_dp_start(struct anx7625_data 
> > > > > *ctx)
> > > > > return;
> > > > > }
> > > > >
> > > > > +   /* HDCP config */
> > > > > +   anx7625_hdcp_setting(ctx);
> > > >
> > > > You should really use the "Content Protection" property to
> > > > enable/disable HDCP instead of force-enabling it at all times.
> > >
> > > Hi Sean, it's hard to implement "Content Protection" property, we have
> > > implemented HDCP in firmware, it is not compatible with it. We don't
> > > have interface to get Downstream Cert.
> > > Thanks,
> > > Xin
> > 
> > Hi Xin,
> > I'm sorry, I don't understand what you mean when you say you don't
> > have an interface to get Downstream Cert.
> > 
> > The Content Protection property is just a means through which
> > userspace can turn on and turn off HDCP when it needs. As far as I can
> > tell, your patch turns on HDCP when the display is enabled and leaves
> > it on until it is disabled. This is undesirable since it forces HDCP
> > on the user.
> > 
> > Is it impossible to enable/disable HDCP outside of display
> > enable/disable on your hardware?
>
> Hi Sean, I have commit a test patch on google review site, can you
> please help to review it? I'll use Connector's ".atomic_check()"
> interface to detect Content Protection property change.
> (https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2674580)

Please note that upstream review happens on mailing lists, not in
gerrit. Internal reviews for Chrome OS development are certainly fine
there, but that will not mean the patch will then be accepted upstream
as-is, it will still need to go through the upstream review process,
without any shortcut. I strongly recommend using an upstream-first
strategy, with public review.

> > > > > +
> > > > > if (ctx->pdata.is_dpi)
> > > > > ret = anx7625_dpi_config(ctx);
> > > > > else
> > 
> > /snip

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 3/3] Input: add driver for the Hycon HY46XX touchpanel series

[Jonathan Neuschäfer]

Hi,

a few remarks below.

On Fri, Apr 02, 2021 at 01:03:58AM +0200, Giulio Benetti wrote:
> This patch adds support for Hycon HY46XX.
> 
> Signed-off-by: Giulio Benetti 
> ---
> V1->V2:
> * removed proximity-sensor-switch property according to previous patch
> As suggested by Dmitry Torokhov
> * moved i2c communaction to regmap use
> * added macro to avoid magic number
> * removed cmd variable that could uninitiliazed since we're using regmap now
> * removed useless byte masking
> * removed useless struct hycon_hy46xx_i2c_chip_data
> * used IRQF_ONESHOT only for isr
> ---


> +config TOUCHSCREEN_HYCON_HY46XX
> + tristate "Hycon hy46xx touchscreen support"
> + depends on I2C
> + help
> +   Say Y here if you have a touchscreen using Hycon hy46xx,
> +   or something similar enough.

The "something similar enough" part doesn't seem relevant, because the
driver only lists HY46xx chips (in the compatible strings), and no chips
that are similar enough to work with the driver, but have a different
part number.

> +static void hycon_hy46xx_get_defaults(struct device *dev, struct 
> hycon_hy46xx_data *tsdata)
> +{
> + bool val_bool;
> + int error;
> + u32 val;
> +
> + error = device_property_read_u32(dev, "threshold", );

This seems to follow the old version of the binding, where
Hycon-specific properties didn't have the "hycon," prefix.
Please check that the driver still works with a devicetree that follows
the newest version of the binding.

> +MODULE_AUTHOR("Giulio Benetti ");

This is a different email address than you used in the DT binding. If
this is intentional, no problem (Just letting you know, in case it's
unintentional).


Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature

Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024

[David Abdurachmanov]

On Fri, Apr 2, 2021 at 11:43 AM Dmitry Vyukov  wrote:
>
> On Fri, Apr 2, 2021 at 6:37 AM Palmer Dabbelt  wrote:
> >
> > On Tue, 30 Mar 2021 13:31:45 PDT (-0700), ma...@orcam.me.uk wrote:
> > > On Mon, 29 Mar 2021, Palmer Dabbelt wrote:
> > >
> > >> > --- /dev/null
> > >> > +++ b/arch/riscv/include/uapi/asm/setup.h
> > >> > @@ -0,0 +1,8 @@
> > >> > +/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
> > >> > +
> > >> > +#ifndef _UAPI_ASM_RISCV_SETUP_H
> > >> > +#define _UAPI_ASM_RISCV_SETUP_H
> > >> > +
> > >> > +#define COMMAND_LINE_SIZE 1024
> > >> > +
> > >> > +#endif /* _UAPI_ASM_RISCV_SETUP_H */
> > >>
> > >> I put this on fixes, but it seemes like this should really be a Kconfig
> > >> enttry.  Either way, ours was quite a bit smaller than most 
> > >> architectures and
> > >> it's great that syzbot has started to find bugs, so I'd rather get this 
> > >> in
> > >> sooner.
> > >
> > >  This macro is exported as a part of the user API so it must not depend on
> > > Kconfig.  Also changing it (rather than say adding COMMAND_LINE_SIZE_V2 or
> > > switching to an entirely new data object that has its dimension set in a
> > > different way) requires careful evaluation as external binaries have and
> > > will have the value it expands to compiled in, so it's a part of the ABI
> > > too.
> >
> > Thanks, I didn't realize this was part of the user BI.  In that case we
> > really can't chage it, so we'll have to sort out some other way do fix
> > whatever is going on.
> >
> > I've dropped this from fixes.
>
> Does increasing COMMAND_LINE_SIZE break user-space binaries? I would
> expect it to work the same way as adding new enum values, or adding
> fields at the end of versioned structs, etc.
> I would assume the old bootloaders/etc will only support up to the
> old, smaller max command line size, while the kernel will support
> larger command line size, which is fine.
> However, if something copies /proc/cmdline into a fixed-size buffer
> and expects that to work, that will break... that's quite unfortunate
> user-space code... is it what we afraid of?
>
> Alternatively, could expose the same COMMAND_LINE_SIZE, but internally
> support a larger command line?

Looking at kernel commit history I see PowerPC switched from 512 to
2048, and I don't see complaints about the ABI on the mailing list.

If COMMAND_LINE_SIZE is used by user space applications and we
increase it there shouldn't be problems. I would expect things to
work, but just get truncated boot args? That is the application will
continue only to look at the initial 512 chars.

https://linuxppc-dev.ozlabs.narkive.com/m4cj8nBa/patch-1-1-powerpc-increase-command-line-size-to-2048-from-512

Re: [PATCH] zero-fill colormap in drivers/video/fbdev/core/fbcmap.c

[Phillip Potter]

On Thu, Apr 01, 2021 at 11:55:50AM +0200, Geert Uytterhoeven wrote:
> On Thu, Apr 1, 2021 at 12:09 AM Phillip Potter  wrote:
> > Use kzalloc() rather than kmalloc() for the dynamically allocated parts
> > of the colormap in fb_alloc_cmap_gfp, to prevent a leak of random kernel
> > data to userspace under certain circumstances.
> >
> > Fixes a KMSAN-found infoleak bug reported by syzbot at:
> > https://syzkaller.appspot.com/bug?id=741578659feabd108ad9e06696f0c1f2e69c4b6e
> >
> > Reported-by: syzbot+47fa9c9c648b76530...@syzkaller.appspotmail.com
> > Signed-off-by: Phillip Potter 
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Dear Geert

Thank you for your review :-)

Regards,
Phil

[PATCH] drm/nouveau: fix potential abnormal lock/unlock

[Bernard Zhao]

Fix coccicheck warning:
drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c:115:3-9: preceding lock on line 
109
drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c:98:2-8: preceding lock on line 
95

As we see, function nvkm_fifo_chan_inst & nvkm_fifo_chan_chid both
use spin_lock_irqsave, but no spin_unlock_irqrestore in if/return
branch, seems like a potential bug?

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c
index 2ed4ff05d207..e3f624d97644 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c
@@ -95,6 +95,7 @@ nvkm_fifo_chan_inst(struct nvkm_fifo *fifo, u64 inst, 
unsigned long *rflags)
spin_lock_irqsave(>lock, flags);
if ((chan = nvkm_fifo_chan_inst_locked(fifo, inst))) {
*rflags = flags;
+   spin_unlock_irqrestore(>lock, flags);
return chan;
}
spin_unlock_irqrestore(>lock, flags);
@@ -112,6 +113,7 @@ nvkm_fifo_chan_chid(struct nvkm_fifo *fifo, int chid, 
unsigned long *rflags)
list_del(>head);
list_add(>head, >chan);
*rflags = flags;
+   spin_unlock_irqrestore(>lock, flags);
return chan;
}
}
-- 
2.31.0

[PATCH] drm/kmb: cleanup coding style a bit

[Bernard Zhao]

Fix coccicheck warning:
drivers/gpu/drm/kmb/kmb_dsi.c:284:3-4: Unneeded semicolon
drivers/gpu/drm/kmb/kmb_dsi.c:304:3-4: Unneeded semicolon
drivers/gpu/drm/kmb/kmb_dsi.c:321:3-4: Unneeded semicolon
drivers/gpu/drm/kmb/kmb_dsi.c:340:3-4: Unneeded semicolon
drivers/gpu/drm/kmb/kmb_dsi.c:364:2-3: Unneeded semicolon

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/kmb/kmb_dsi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c b/drivers/gpu/drm/kmb/kmb_dsi.c
index 4b5d82af84b3..231041b269f5 100644
--- a/drivers/gpu/drm/kmb/kmb_dsi.c
+++ b/drivers/gpu/drm/kmb/kmb_dsi.c
@@ -281,7 +281,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32 
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
-   };
+   }
break;
case DSI_LP_DT_PPS_YCBCR422_16B:
data_type_param.size_constraint_pixels = 2;
@@ -301,7 +301,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32 
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
-   };
+   }
break;
case DSI_LP_DT_LPPS_YCBCR422_20B:
case DSI_LP_DT_PPS_YCBCR422_24B:
@@ -318,7 +318,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32 
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
-   };
+   }
break;
case DSI_LP_DT_PPS_RGB565_16B:
data_type_param.size_constraint_pixels = 1;
@@ -337,7 +337,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32 
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
-   };
+   }
break;
case DSI_LP_DT_PPS_RGB666_18B:
data_type_param.size_constraint_pixels = 4;
@@ -361,7 +361,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32 
data_mode,
default:
DRM_ERROR("DSI: Invalid data_type %d\n", data_type);
return -EINVAL;
-   };
+   }
 
*params = data_type_param;
return 0;
-- 
2.31.0

Re: [PATCH v4 1/2] kunit: support failure from dynamic analysis tools

[Brendan Higgins]

On Thu, Mar 11, 2021 at 7:23 AM Daniel Latypov  wrote:
>
> From: Uriel Guajardo 
>
> Add a kunit_fail_current_test() function to fail the currently running
> test, if any, with an error message.
>
> This is largely intended for dynamic analysis tools like UBSAN and for
> fakes.
> E.g. say I had a fake ops struct for testing and I wanted my `free`
> function to complain if it was called with an invalid argument, or
> caught a double-free. Most return void and have no normal means of
> signalling failure (e.g. super_operations, iommu_ops, etc.).
>
> Key points:
> * Always update current->kunit_test so anyone can use it.
>   * commit 83c4e7a0363b ("KUnit: KASAN Integration") only updated it for
>   CONFIG_KASAN=y
>
> * Create a new header  so non-test code doesn't have
> to include all of  (e.g. lib/ubsan.c)
>
> * Forward the file and line number to make it easier to track down
> failures
>
> * Declare the helper function for nice __printf() warnings about mismatched
> format strings even when KUnit is not enabled.
>
> Example output from kunit_fail_current_test("message"):
> [15:19:34] [FAILED] example_simple_test
> [15:19:34] # example_simple_test: initializing
> [15:19:34] # example_simple_test: lib/kunit/kunit-example-test.c:24: 
> message
> [15:19:34] not ok 1 - example_simple_test
>
> Co-developed-by: Daniel Latypov 
> Signed-off-by: Daniel Latypov 
> Signed-off-by: Uriel Guajardo 
> Reviewed-by: Alan Maguire 

Reviewed-by: Brendan Higgins 

[PATCH] drm/gud: cleanup coding style a bit

[Bernard Zhao]

Fix coccicheck warning:
drivers/gpu/drm/gud/gud_internal.h:89:2-3: Unneeded semicolon
drivers/gpu/drm/gud/gud_internal.h:107:2-3: Unneeded semicolon

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/gud/gud_internal.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gud/gud_internal.h 
b/drivers/gpu/drm/gud/gud_internal.h
index de2f2d2dbc60..b65105585578 100644
--- a/drivers/gpu/drm/gud/gud_internal.h
+++ b/drivers/gpu/drm/gud/gud_internal.h
@@ -86,7 +86,7 @@ static inline u8 gud_from_fourcc(u32 fourcc)
return GUD_PIXEL_FORMAT_XRGB;
case DRM_FORMAT_ARGB:
return GUD_PIXEL_FORMAT_ARGB;
-   };
+   }
 
return 0;
 }
@@ -104,7 +104,7 @@ static inline u32 gud_to_fourcc(u8 format)
return DRM_FORMAT_XRGB;
case GUD_PIXEL_FORMAT_ARGB:
return DRM_FORMAT_ARGB;
-   };
+   }
 
return 0;
 }
-- 
2.31.0

[PATCH] drm/amd: remove not needed conversion to bool

[Bernard Zhao]

Fix coccicheck warning:
drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c:573:39-44: WARNING: conversion to bool 
not needed here
drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c:575:39-44: WARNING: conversion to bool 
not needed here

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c 
b/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
index ab9be5ad5a5f..0734e8ef5e41 100644
--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
@@ -570,9 +570,9 @@ static int mmhub_v2_3_set_clockgating(struct amdgpu_device 
*adev,
return 0;
 
mmhub_v2_3_update_medium_grain_clock_gating(adev,
-   state == AMD_CG_STATE_GATE ? true : false);
+   (state == AMD_CG_STATE_GATE));
mmhub_v2_3_update_medium_grain_light_sleep(adev,
-   state == AMD_CG_STATE_GATE ? true : false);
+   (state == AMD_CG_STATE_GATE));
 
return 0;
 }
-- 
2.31.0

Re: [PATCH v2 1/3] KVM: X86: Rename DR6_INIT to DR6_ACTIVE_LOW

[Xiaoyao Li]

On 2/3/2021 12:05 AM, Paolo Bonzini wrote:

On 02/02/21 16:02, Xiaoyao Li wrote:

On 2/2/2021 10:49 PM, Paolo Bonzini wrote:

On 02/02/21 10:04, Chenyi Qiang wrote:


 #define DR6_FIXED_1    0xfffe0ff0
-#define DR6_INIT    0x0ff0
+/*
+ * DR6_ACTIVE_LOW is actual the result of DR6_FIXED_1 | 
ACTIVE_LOW_BITS.

+ * We can regard all the current FIXED_1 bits as active_low bits even
+ * though in no case they will be turned into 0. But if they are 
defined

+ * in the future, it will require no code change.
+ * At the same time, it can be served as the init/reset value for DR6.
+ */
+#define DR6_ACTIVE_LOW    0x0ff0
 #define DR6_VOLATILE    0x0001e00f



Committed with some changes in the wording of the comment.

Also, DR6_FIXED_1 is (DR6_ACTIVE_LOW & ~DR6_VOLATILE).


Maybe we can add BUILD_BUG_ON() to make sure the correctness?


We can even

#define DR_FIXED_1  (DR6_ACTIVE_LOW & ~DR6_VOLATILE)

directly.  I have pushed this patch to kvm/queue, but the other two will 
have to wait for Fenghua's bare metal support.




Hi Paolo,

Fenghua's bare metal support is in tip tree now.
https://lore.kernel.org/lkml/20210322135325.682257-1-fenghua...@intel.com/

Will the rest KVM patches get into 5.13 together?

Re: [PATCH v10 3/4] mtd: rawnand: Add support for secure regions in NAND memory

[Boris Brezillon]

On Thu, 1 Apr 2021 21:46:22 +0530
Manivannan Sadhasivam  wrote:

> On Thu, Apr 01, 2021 at 05:54:21PM +0200, Boris Brezillon wrote:
> > On Thu,  1 Apr 2021 20:49:54 +0530
> > Manivannan Sadhasivam  wrote:
> >   
> > > @@ -565,6 +608,11 @@ static int nand_block_isreserved(struct mtd_info 
> > > *mtd, loff_t ofs)
> > >  
> > >   if (!chip->bbt)
> > >   return 0;
> > > +
> > > + /* Check if the region is secured */
> > > + if (nand_region_is_secured(chip, ofs, 0))
> > > + return -EIO;  
> > 
> > That would is still wrong, you should never pass a 0 size to
> > nand_region_is_secured().
> >   
> 
> Size doesn't matter here, that's why I passed 0. Maybe 1 would be
> appropriate?

You're checking if a block is reserved, so I think passing the
eraseblock size would make more sense, but I actually don't understand
why you need to check if the region is secure here (looks like
nand_block_isreserved() does not access the flash).

Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024

[Dmitry Vyukov]

On Fri, Apr 2, 2021 at 6:37 AM Palmer Dabbelt  wrote:
>
> On Tue, 30 Mar 2021 13:31:45 PDT (-0700), ma...@orcam.me.uk wrote:
> > On Mon, 29 Mar 2021, Palmer Dabbelt wrote:
> >
> >> > --- /dev/null
> >> > +++ b/arch/riscv/include/uapi/asm/setup.h
> >> > @@ -0,0 +1,8 @@
> >> > +/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
> >> > +
> >> > +#ifndef _UAPI_ASM_RISCV_SETUP_H
> >> > +#define _UAPI_ASM_RISCV_SETUP_H
> >> > +
> >> > +#define COMMAND_LINE_SIZE 1024
> >> > +
> >> > +#endif /* _UAPI_ASM_RISCV_SETUP_H */
> >>
> >> I put this on fixes, but it seemes like this should really be a Kconfig
> >> enttry.  Either way, ours was quite a bit smaller than most architectures 
> >> and
> >> it's great that syzbot has started to find bugs, so I'd rather get this in
> >> sooner.
> >
> >  This macro is exported as a part of the user API so it must not depend on
> > Kconfig.  Also changing it (rather than say adding COMMAND_LINE_SIZE_V2 or
> > switching to an entirely new data object that has its dimension set in a
> > different way) requires careful evaluation as external binaries have and
> > will have the value it expands to compiled in, so it's a part of the ABI
> > too.
>
> Thanks, I didn't realize this was part of the user BI.  In that case we
> really can't chage it, so we'll have to sort out some other way do fix
> whatever is going on.
>
> I've dropped this from fixes.

Does increasing COMMAND_LINE_SIZE break user-space binaries? I would
expect it to work the same way as adding new enum values, or adding
fields at the end of versioned structs, etc.
I would assume the old bootloaders/etc will only support up to the
old, smaller max command line size, while the kernel will support
larger command line size, which is fine.
However, if something copies /proc/cmdline into a fixed-size buffer
and expects that to work, that will break... that's quite unfortunate
user-space code... is it what we afraid of?

Alternatively, could expose the same COMMAND_LINE_SIZE, but internally
support a larger command line?

Re: [PATCH RESEND 0/3] x86/sgx: eextend ioctl

[Jethro Beekman]

On 2021-04-01 20:40, Dave Hansen wrote:
> On 4/1/21 10:49 AM, Raoul Strackx wrote:
>> On 4/1/21 6:11 PM, Dave Hansen wrote:
>>> On 4/1/21 7:56 AM, Raoul Strackx wrote:
 SOLUTION OF THIS PATCH
 This patch adds a new ioctl to enable userspace to execute EEXTEND leaf 
 functions per 256 bytes of enclave memory. This enables enclaves to be 
 build as specified by enclave providers.
>>> I think tying the user ABI to the SGX architecture this closely is a
>>> mistake.
>>>
>>> Do we need another ioctl() or can we just relax the existing add_pages
>>> ioctl() to allow unaligned addresses?
>>>
>> I've considered this. In order to do an EEXTEND without an EADD, we'd
>> need to add a flag DONT_ADD_PAGES flag to `add_pages` ioctl as well. Two
>> separate ioctls, one for adding, another for extending made more sense
>> to me.
> 
> So, we're talking here about pages that have been EEADDED, but for which
> we do not want to include the entire contents of the page?  Do these
> contents always include the beginning of the page, or can the holes be
> anywhere?

Holes can be anywhere, and EEXTEND calls need not be sequential in memory 
address or even relate to the most recently EADDed page.

--
Jethro Beekman | Fortanix




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH v2 2/3] dt-bindings: touchscreen: Add HY46XX bindings

[Jonathan Neuschäfer]

On Fri, Apr 02, 2021 at 01:03:57AM +0200, Giulio Benetti wrote:
> This adds device tree bindings for the Hycon HY46XX touchscreen series.
> 
> Signed-off-by: Giulio Benetti 
> ---
> V1->V2:
> As suggested by Rob Herring:
> * fixed $id: address
> * added "hycon," in front of every custom property
> * changed all possible property to boolean type
> * removed proximity-sensor-switch property since it's not handled in driver
> ---
>  .../input/touchscreen/hycon,hy46xx.yaml   | 120 ++
>  MAINTAINERS   |   6 +
>  2 files changed, 126 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml 
> b/Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml
> new file mode 100644
> index ..71a1dbabcd4f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml
> @@ -0,0 +1,120 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/touchscreen/hycon,hy46xx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: hycon HY46XX series touchscreen controller Bindings

hycon -> Hycon(because it's a name)
Bindings -> bindings  (because it's just a regular word)

> +
> +description: |
> + There are 6 variants of the chip for various touch panel sizes 
> and coverl len material

"coverl len material" looks like a typo. What does it mean?

> +  Glass: 0.3mm--4.0mm
> +  PET/PMMA: 0.2mm--2.0mm
> +   HY4613(B)-N048  < 6"
> +   HY4614(B)-N068  7" .. 10.1"

According to the datasheet I was able to find[1], HY4613-N048 supports
touch panel sizes smaller than 5.3". Did this change in newer
datasheets?

What does the (B) part of the part number mean?


[1]: https://datasheetspdf.com/pdf/1297773/HYCON/HY4613-N048/1

> +   HY4621-NS32  < 5"
> +   HY4623-NS48  5.1" .. 7"
> +  Glass: 0.3mm--8.0mm
> +  PET/PMMA: 0.2mm--4.0mm
> +   HY4633(B)-N048  < 6"
> +   HY4635(B)-N048  < 7" .. 10.1"

The description block seems unusually far indented. I'm not a YAML
expert, but according to the yamllint tool, it would work with much less
indentation:

description: |
  There are 6 variants of the chip for various touch panel sizes and coverl len 
material
   Glass: 0.3mm--4.0mm
[...]


> +  hycon,glove-enable:
> +type: boolean
> +description: Allows enabling or disabling glove setting.

Small nit: Due to the way boolean properties work in DT, you can't
really use the property to disable the glove setting (in order to
disable the setting, you would explicitly not use the property).
Perhaps:

+description: Allows enabling the glove setting.

I don't really know :)


> +
> +  hycon,report-speed:
> +description: Allows setting the report speed(i.e 0x64 => 100Hz).
> +$ref: /schemas/types.yaml#/definitions/uint32
> +minimum: 0
> +maximum: 255

Please add a space before the opening parenthesis:

+description: Allows setting the report speed (i.e 0x64 => 100Hz).

Or perhaps like this:

+description: Allows setting the report speed in Hertz.



Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature

[regression 5.4.97 → 5.10.24]: raid6 avx2x4 speed drops from 18429 MB/s to 6155 MB/s

[Paul Menzel]

Dear Linux folks,


On an two socket AMD EPYC 7601, we noticed a decrease in raid6 avx2x4 
speed shown at the beginning of the boot.


   5.4.955.10.24
--
raid6: avx2x4 gen()   18429 MB/s 6155 MB/s
raid6: avx2x4 xor()6644 MB/s 4274 MB/s
raid6: avx2x2 gen()   17894 MB/s18744 MB/s
raid6: avx2x2 xor()   11642 MB/s11950 MB/s
raid6: avx2x1 gen()   13992 MB/s17112 MB/s
raid6: avx2x1 xor()   10855 MB/s11143 MB/s

We are able to reproduce this with different models: Supermicro 
AS-2023US-TR4/H11DSU-iN and Dell PowerEdge R7425 (with different 
microcode versions).


Can you reproduce this on your systems?

Bisecting is going to be hard, so the systems are in production and also 
take a while to boot. (Maybe kexec would help here.)



Kind regards,

Paul


PS: Some more information:

```
[0.00] Linux version 5.4.97.mx64.368 
(r...@theinternet.molgen.mpg.de) (gcc version 7.5.0 (GCC

)) #1 SMP Wed Feb 10 18:22:50 CET 2021
[…]
[0.00] DMI: Supermicro AS -2023US-TR4/H11DSU-iN, BIOS 1.1 02/07/2018
[…]
[0.630603] raid6: avx2x4   gen() 18429 MB/s
[0.651607] raid6: avx2x4   xor()  6644 MB/s
[0.672605] raid6: avx2x2   gen() 17894 MB/s
[0.693603] raid6: avx2x2   xor() 11642 MB/s
[0.714605] raid6: avx2x1   gen() 13992 MB/s
[0.735604] raid6: avx2x1   xor() 10855 MB/s
[0.756607] raid6: sse2x4   gen() 12246 MB/s
[0.777605] raid6: sse2x4   xor()  5724 MB/s
[0.798605] raid6: sse2x2   gen() 10945 MB/s
[0.819603] raid6: sse2x2   xor()  8097 MB/s
[0.840606] raid6: sse2x1   gen()  5941 MB/s
[0.861606] raid6: sse2x1   xor()  5894 MB/s
[0.866565] raid6: using algorithm avx2x4 gen() 18429 MB/s
[0.871567] raid6:  xor() 6644 MB/s, rmw enabled
[0.877566] raid6: using avx2x2 recovery algorithm
[…]
```


```
[0.00] Linux version 5.10.24.mx64.375 
(r...@theinternet.molgen.mpg.de) (gcc (GCC) 7.5.0, GNU ld (GNU Binutils) 
2.32) #1 SMP Fri Mar 19 12:29:21 CET 2021

[…]
[0.00] DMI: Supermicro AS -2023US-TR4/H11DSU-iN, BIOS 1.1 02/07/2018
[…]
[0.655382] raid6: avx2x4   gen()  6155 MB/s
[0.676382] raid6: avx2x4   xor()  4274 MB/s
[0.697380] raid6: avx2x2   gen() 18744 MB/s
[0.718380] raid6: avx2x2   xor() 11950 MB/s
[0.739380] raid6: avx2x1   gen() 17112 MB/s
[0.760380] raid6: avx2x1   xor() 11143 MB/s
[0.781381] raid6: sse2x4   gen() 11062 MB/s
[0.802380] raid6: sse2x4   xor()  5180 MB/s
[0.823380] raid6: sse2x2   gen() 12467 MB/s
[0.844380] raid6: sse2x2   xor()  7672 MB/s
[0.865381] raid6: sse2x1   gen()  9733 MB/s
[0.886380] raid6: sse2x1   xor()  5717 MB/s
[0.890674] raid6: using algorithm avx2x2 gen() 18744 MB/s
[0.895673] raid6:  xor() 11950 MB/s, rmw enabled
[0.901673] raid6: using avx2x2 recovery algorithm
```

```
$ lscpu
Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Address sizes:   48 bits physical, 48 bits virtual
CPU(s):  128
On-line CPU(s) list: 0-127
Thread(s) per core:  2
Core(s) per socket:  32
Socket(s):   2
NUMA node(s):8
Vendor ID:   AuthenticAMD
CPU family:  23
Model:   1
Model name:  AMD EPYC 7601 32-Core Processor
Stepping:2
Frequency boost: enabled
CPU MHz: 3100.798
CPU max MHz: 2200.
CPU min MHz: 1200.
BogoMIPS:4399.53
Virtualization:  AMD-V
L1d cache:   2 MiB
L1i cache:   4 MiB
L2 cache:32 MiB
L3 cache:128 MiB
NUMA node0 CPU(s):   0-7,64-71
NUMA node1 CPU(s):   8-15,72-79
NUMA node2 CPU(s):   16-23,80-87
NUMA node3 CPU(s):   24-31,88-95
NUMA node4 CPU(s):   32-39,96-103
NUMA node5 CPU(s):   40-47,104-111
NUMA node6 CPU(s):   48-55,112-119
NUMA node7 CPU(s):   56-63,120-127
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf:  Not affected
Vulnerability Mds:   Not affected
Vulnerability Meltdown:  Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass 
disabled via prctl and seccomp
Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers 
and __user pointer sanitization
Vulnerability Spectre v2:Mitigation; Full AMD retpoline, IBPB 
conditional, STIBP disabled, RSB filling

Vulnerability Srbds: Not affected
Vulnerability Tsx async abort:   Not affected
Flags:   fpu vme de pse tsc msr pae mce cx8 apic 
sep mtrr pge mca cmov pat 

[PATCH] tty: pty: Add a blank line after declarations

[Xiaofei Tan]

Add a blank line after declarations, reported by checkpatch.pl.

Signed-off-by: Xiaofei Tan 
---
 drivers/tty/pty.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 5e23745..106265a 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -159,6 +159,7 @@ static int pty_chars_in_buffer(struct tty_struct *tty)
 static int pty_set_lock(struct tty_struct *tty, int __user *arg)
 {
int val;
+
if (get_user(val, arg))
return -EFAULT;
if (val)
@@ -171,6 +172,7 @@ static int pty_set_lock(struct tty_struct *tty, int __user 
*arg)
 static int pty_get_lock(struct tty_struct *tty, int __user *arg)
 {
int locked = test_bit(TTY_PTY_LOCK, >flags);
+
return put_user(locked, arg);
 }
 
@@ -200,6 +202,7 @@ static int pty_set_pktmode(struct tty_struct *tty, int 
__user *arg)
 static int pty_get_pktmode(struct tty_struct *tty, int __user *arg)
 {
int pktmode = tty->packet;
+
return put_user(pktmode, arg);
 }
 
@@ -463,6 +466,7 @@ static int pty_install(struct tty_driver *driver, struct 
tty_struct *tty)
 static void pty_remove(struct tty_driver *driver, struct tty_struct *tty)
 {
struct tty_struct *pair = tty->link;
+
driver->ttys[tty->index] = NULL;
if (pair)
pair->driver->ttys[pair->index] = NULL;
-- 
2.8.1

[PATCH -V2] NUMA balancing: reduce TLB flush via delaying mapping on hint page fault

[Huang Ying]

With NUMA balancing, in hint page fault handler, the faulting page
will be migrated to the accessing node if necessary.  During the
migration, TLB will be shot down on all CPUs that the process has run
on recently.  Because in the hint page fault handler, the PTE will be
made accessible before the migration is tried.  The overhead of TLB
shooting down can be high, so it's better to be avoided if possible.
In fact, if we delay mapping the page until migration, that can be
avoided.  This is what this patch doing.

For the multiple threads applications, it's possible that a page is
accessed by multiple threads almost at the same time.  In the original
implementation, because the first thread will install the accessible
PTE before migrating the page, the other threads may access the page
directly before the page is made inaccessible again during migration.
While with the patch, the second thread will go through the page fault
handler too. And because of the PageLRU() checking in the following
code path,

  migrate_misplaced_page()
numamigrate_isolate_page()
  isolate_lru_page()

the migrate_misplaced_page() will return 0, and the PTE will be made
accessible in the second thread.

This will introduce a little more overhead.  But we think the
possibility for a page to be accessed by the multiple threads at the
same time is low, and the overhead difference isn't too large.  If
this becomes a problem in some workloads, we need to consider how to
reduce the overhead.

To test the patch, we run a test case as follows on a 2-socket Intel
server (1 NUMA node per socket) with 128GB DRAM (64GB per socket).

1. Run a memory eater on NUMA node 1 to use 40GB memory before running
   pmbench.

2. Run pmbench (normal accessing pattern) with 8 processes, and 8
   threads per process, so there are 64 threads in total.  The
   working-set size of each process is 8960MB, so the total working-set
   size is 8 * 8960MB = 70GB.  The CPU of all pmbench processes is bound
   to node 1.  The pmbench processes will access some DRAM on node 0.

3. After the pmbench processes run for 10 seconds, kill the memory
   eater.  Now, some pages will be migrated from node 0 to node 1 via
   NUMA balancing.

Test results show that, with the patch, the pmbench throughput (page
accesses/s) increases 5.5%.  The number of the TLB shootdowns
interrupts reduces 98% (from ~4.7e7 to ~9.7e5) with about 9.2e6
pages (35.8GB) migrated.  From the perf profile, it can be found that
the CPU cycles spent by try_to_unmap() and its callees reduces from
6.02% to 0.47%.  That is, the CPU cycles spent by TLB shooting down
decreases greatly.

Signed-off-by: "Huang, Ying" 
Cc: Peter Zijlstra 
Cc: Mel Gorman 
Cc: Peter Xu 
Cc: Johannes Weiner 
Cc: Vlastimil Babka 
Cc: "Matthew Wilcox" 
Cc: Will Deacon 
Cc: Michel Lespinasse 
Cc: Arjun Roy 
Cc: "Kirill A. Shutemov" 
---
 mm/memory.c | 54 +++--
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index d3273bd69dbb..a00b39e81a25 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4148,29 +4148,17 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
goto out;
}
 
-   /*
-* Make it present again, Depending on how arch implementes non
-* accessible ptes, some can allow access by kernel mode.
-*/
-   old_pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
+   /* Get the normal PTE  */
+   old_pte = ptep_get(vmf->pte);
pte = pte_modify(old_pte, vma->vm_page_prot);
-   pte = pte_mkyoung(pte);
-   if (was_writable)
-   pte = pte_mkwrite(pte);
-   ptep_modify_prot_commit(vma, vmf->address, vmf->pte, old_pte, pte);
-   update_mmu_cache(vma, vmf->address, vmf->pte);
 
page = vm_normal_page(vma, vmf->address, pte);
-   if (!page) {
-   pte_unmap_unlock(vmf->pte, vmf->ptl);
-   return 0;
-   }
+   if (!page)
+   goto out_map;
 
/* TODO: handle PTE-mapped THP */
-   if (PageCompound(page)) {
-   pte_unmap_unlock(vmf->pte, vmf->ptl);
-   return 0;
-   }
+   if (PageCompound(page))
+   goto out_map;
 
/*
 * Avoid grouping on RO pages in general. RO pages shouldn't hurt as
@@ -4180,7 +4168,7 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
 * pte_dirty has unpredictable behaviour between PTE scan updates,
 * background writeback, dirty balancing and application behaviour.
 */
-   if (!pte_write(pte))
+   if (!was_writable)
flags |= TNF_NO_GROUP;
 
/*
@@ -4194,23 +4182,45 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
page_nid = page_to_nid(page);
target_nid = numa_migrate_prep(page, vma, vmf->address, page_nid,
);
-   pte_unmap_unlock(vmf->pte, vmf->ptl);
if (target_nid == NUMA_NO_NODE) {
  

Re: [PATCH] crypto: hisilicon/hpre - delete redundant log

[tanghui20]

On 2021/4/2 15:19, Herbert Xu wrote:

On Sat, Mar 27, 2021 at 04:32:26PM +0800, Hui Tang wrote:

'hpre_cfg_by_dsm' has checked and printed error path, so it is not
necessary at all.

Signed-off-by: Hui Tang 
---
 drivers/crypto/hisilicon/hpre/hpre_main.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c 
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index 8aae921..73ee997 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -384,10 +384,7 @@ static int hpre_set_user_domain_and_cache(struct hisi_qm 
*qm)

/* This setting is only needed by Kunpeng 920. */
if (qm->ver == QM_HW_V2) {
-   ret = hpre_cfg_by_dsm(qm);
-   if (ret)
-   dev_err(dev, "acpi_evaluate_dsm err.\n");
-
+   hpre_cfg_by_dsm(qm);
disable_flr_of_bme(qm);
}


If the return value is non-zero you've just changed what this code
does from returning non-zero to returning zero.  Are you sure about
this?


I am sorry, it should return error immediately when return value of 
'hpre_cfg_by_dsm' is non-zero,
and I will fix it in the next version.

[PATCH v2] drm/i915: Fix invalid access to ACPI _DSM objects

[Takashi Iwai]

intel_dsm_platform_mux_info() tries to parse the ACPI package data
from _DSM for the debug information, but it assumes the fixed format
without checking what values are stored in the elements actually.
When an unexpected value is returned from BIOS, it may lead to GPF or
NULL dereference, as reported recently.

Add the checks of the contents in the returned values and skip the
values for invalid cases.

v1->v2: Check the info contents before dereferencing, too

BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
Cc: 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/display/intel_acpi.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e21fb14d5e07..833d0c1be4f1 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -84,13 +84,31 @@ static void intel_dsm_platform_mux_info(acpi_handle dhandle)
return;
}
 
+   if (!pkg->package.count) {
+   DRM_DEBUG_DRIVER("no connection in _DSM\n");
+   return;
+   }
+
connector_count = >package.elements[0];
DRM_DEBUG_DRIVER("MUX info connectors: %lld\n",
  (unsigned long long)connector_count->integer.value);
for (i = 1; i < pkg->package.count; i++) {
union acpi_object *obj = >package.elements[i];
-   union acpi_object *connector_id = >package.elements[0];
-   union acpi_object *info = >package.elements[1];
+   union acpi_object *connector_id;
+   union acpi_object *info;
+
+   if (obj->type != ACPI_TYPE_PACKAGE || obj->package.count < 2) {
+   DRM_DEBUG_DRIVER("Invalid object for MUX #%d\n", i);
+   continue;
+   }
+
+   connector_id = >package.elements[0];
+   info = >package.elements[1];
+   if (info->type != ACPI_TYPE_BUFFER || info->buffer.length < 4) {
+   DRM_DEBUG_DRIVER("Invalid info for MUX obj #%d\n", i);
+   continue;
+   }
+
DRM_DEBUG_DRIVER("Connector id: 0x%016llx\n",
  (unsigned long long)connector_id->integer.value);
DRM_DEBUG_DRIVER("  port id: %s\n",
-- 
2.26.2

RE: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

[Tian, Kevin]

> From: Jason Gunthorpe 
> Sent: Tuesday, March 30, 2021 9:29 PM
> 
> >
> > First, userspace may use ioasid in a non-SVA scenario where ioasid is
> > bound to specific security context (e.g. a control vq in vDPA) instead of
> > tying to mm. In this case there is no pgtable binding initiated from user
> > space. Instead, ioasid is allocated from /dev/ioasid and then programmed
> > to the intended security context through specific passthrough framework
> > which manages that context.
> 
> This sounds like the exact opposite of what I'd like to see.
> 
> I do not want to see every subsystem gaining APIs to program a
> PASID. All of that should be consolidated in *one place*.
> 
> I do not want to see VDPA and VFIO have two nearly identical sets of
> APIs to control the PASID.
> 
> Drivers consuming a PASID, like VDPA, should consume the PASID and do
> nothing more than authorize the HW to use it.
> 
> quemu should have general code under the viommu driver that drives
> /dev/ioasid to create PASID's and manage the IO mapping according to
> the guest's needs.
> 
> Drivers like VDPA and VFIO should simply accept that PASID and
> configure/authorize their HW to do DMA's with its tag.
> 

I agree with you on consolidating things in one place (especially for the
general SVA support). But here I was referring to an usage without 
pgtable binding (Possibly Jason. W can say more here), where the 
userspace just wants to allocate PASIDs, program/accept PASIDs to 
various workqueues (device specific), and then use MAP/UNMAP 
interface to manage address spaces associated with each PASID. 
I just wanted to point out that the latter two steps are through 
VFIO/VDPA specific interfaces. 

Thanks
Kevin

Re: [PATCH] drm/i915: Fix invalid access to ACPI _DSM objects

[Takashi Iwai]

On Fri, 02 Apr 2021 09:47:49 +0200,
Takashi Iwai wrote:
> 
> intel_dsm_platform_mux_info() tries to parse the ACPI package data
> from _DSM for the debug information, but it assumes the fixed format
> without checking what values are stored in the elements actually.
> When an unexpected value is returned from BIOS, it may lead to GPF or
> NULL dereference, as reported recently.
> 
> Add the checks of the contents in the returned values and skip the
> values for invalid cases.
> 
> BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
> Cc: 
> Signed-off-by: Takashi Iwai 

Scratch this one.  I sent an older version mistakenly.
Will resubmit the right one.


Takashi


> ---
>  drivers/gpu/drm/i915/display/intel_acpi.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index e21fb14d5e07..492ebc0a8257 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -84,6 +84,11 @@ static void intel_dsm_platform_mux_info(acpi_handle 
> dhandle)
>   return;
>   }
>  
> + if (!pkg->package.count) {
> + DRM_DEBUG_DRIVER("no connection in _DSM\n");
> + return;
> + }
> +
>   connector_count = >package.elements[0];
>   DRM_DEBUG_DRIVER("MUX info connectors: %lld\n",
> (unsigned long long)connector_count->integer.value);
> @@ -91,6 +96,13 @@ static void intel_dsm_platform_mux_info(acpi_handle 
> dhandle)
>   union acpi_object *obj = >package.elements[i];
>   union acpi_object *connector_id = >package.elements[0];
>   union acpi_object *info = >package.elements[1];
> +
> + if (obj->type != ACPI_TYPE_PACKAGE || obj->package.count < 2 ||
> + info->type != ACPI_TYPE_BUFFER || info->buffer.length < 4) {
> + DRM_DEBUG_DRIVER("Invalid object for MUX #%d\n", i);
> + continue;
> + }
> +
>   DRM_DEBUG_DRIVER("Connector id: 0x%016llx\n",
> (unsigned long long)connector_id->integer.value);
>   DRM_DEBUG_DRIVER("  port id: %s\n",
> -- 
> 2.26.2
> 

[PATCH] arm/mm: Convert to DEFINE_SHOW_ATTRIBUTE

[zuoqilin1]

From: zuoqilin 

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: zuoqilin 
---
 arch/arm/mm/ptdump_debugfs.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
index 598b636..6a62bce 100644
--- a/arch/arm/mm/ptdump_debugfs.c
+++ b/arch/arm/mm/ptdump_debugfs.c
@@ -12,17 +12,7 @@ static int ptdump_show(struct seq_file *m, void *v)
return 0;
 }
 
-static int ptdump_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
-   .open   = ptdump_open,
-   .read   = seq_read,
-   .llseek = seq_lseek,
-   .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
 
 void ptdump_debugfs_register(struct ptdump_info *info, const char *name)
 {
-- 
1.9.1

[PATCH 2/2] mtd: spi-nor: macronix: Fix name for mx66l51235f

[Tudor Ambarus]

According to macronix website, there is no mx66l51235l part number.
The chip detected as such is actually mx66l51235f. Rename the flash.
Do not update the mx66l51235l name from the spi_nor_dev_ids[], since
there are dt that are using this compatible.

Signed-off-by: Tudor Ambarus 
---
 drivers/mtd/spi-nor/macronix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
index 42c2cf31702e..c8167de55e55 100644
--- a/drivers/mtd/spi-nor/macronix.c
+++ b/drivers/mtd/spi-nor/macronix.c
@@ -72,7 +72,7 @@ static const struct flash_info macronix_parts[] = {
  SECT_4K | SPI_NOR_DUAL_READ |
  SPI_NOR_QUAD_READ) },
{ "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
-   { "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024,
+   { "mx66l51235f", INFO(0xc2201a, 0, 64 * 1024, 1024,
  SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
  SPI_NOR_4B_OPCODES) },
{ "mx66u51235f", INFO(0xc2253a, 0, 64 * 1024, 1024,
-- 
2.25.1

[PATCH 1/2] Revert "mtd: spi-nor: macronix: Add support for mx25l51245g"

[Tudor Ambarus]

This reverts commit 04b8edad262eec0d153005973dfbdd83423c0dcb.

mx25l51245g and mx66l51235l have the same flash ID. The flash
detection returns the first entry in the flash_info array that
matches the flash ID that was read, thus for the 0xc2201a ID,
mx25l51245g was always hit, introducing a regression for
mx66l51235l.

If one wants to differentiate the flash names, a better fix would be
to differentiate between the two at run-time, depending on SFDP,
and choose the correct name from a list of flash names, depending on
the SFDP differentiator.

Fixes: 04b8edad262e ("mtd: spi-nor: macronix: Add support for mx25l51245g")
Cc: sta...@vger.kernel.org
Signed-off-by: Tudor Ambarus 
---
 drivers/mtd/spi-nor/macronix.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
index 6c2680b4cdad..42c2cf31702e 100644
--- a/drivers/mtd/spi-nor/macronix.c
+++ b/drivers/mtd/spi-nor/macronix.c
@@ -72,9 +72,6 @@ static const struct flash_info macronix_parts[] = {
  SECT_4K | SPI_NOR_DUAL_READ |
  SPI_NOR_QUAD_READ) },
{ "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
-   { "mx25l51245g", INFO(0xc2201a, 0, 64 * 1024, 1024,
- SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
- SPI_NOR_4B_OPCODES) },
{ "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024,
  SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
  SPI_NOR_4B_OPCODES) },
-- 
2.25.1

[PATCH 0/2] mtd: spi-nor: macronix: mx25l51245g, mx66l51235l and mx66l51235f

[Tudor Ambarus]

mx25l51245g and mx66l51235l have the same flash ID. The flash
detection returns the first entry in the flash_info array that
matches the flash ID that was read, thus for the 0xc2201a ID,
mx25l51245g was always hit, introducing a regression for
mx66l51235l. Revert mx25l51245g addition. A solution for these
flashes to coexist was proposed.

According to macronix website, there is no mx66l51235l part number.
Rename the part to mx66l51235f.

The difference betwenn mx25l51245g and mx66l51235f flash_info entries
was that mx25l51245g also set SECT_4K. Both flashes support 4K erases,
but the 4K erase should be discovered when parsing BFPT, so there's
no need to set the explicit SECT_4K flag.

Tudor Ambarus (2):
  Revert "mtd: spi-nor: macronix: Add support for mx25l51245g"
  mtd: spi-nor: macronix: Fix name for mx66l51235f

 drivers/mtd/spi-nor/macronix.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

-- 
2.25.1

RE: [PATCH v3 00/10] fsdax,xfs: Add reflink support for fsdax

[ruansy.f...@fujitsu.com]

> -Original Message-
> From: Christoph Hellwig 
> Sent: Friday, April 2, 2021 3:50 PM
> Subject: Re: [PATCH v3 00/10] fsdax,xfs: Add reflink support for fsdax
> 
> Shiyang, Dan:
> 
> given that the whole reflink+dax thing is going to take a while and thus not 
> going
> to happen for this merge window, what about queueing up the cleanup patches
> 1,2 and 3 so that we can reduce the patch load a little?

OK.  I'll send a new version of these 3 patches based on latest comment.


--
Thanks,
Ruan Shiyang.

Re: [PATCH -next] media: ti-vpe: sc: remove redundant dev_err call in sc_create()

[Benoit Parrot]

Yang,

Thank you for the patch.

Yang Yingliang  wrote on Thu [2021-Apr-01 18:30:15 
+0800]:
> There is an error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Yang Yingliang 
> ---
>  drivers/media/platform/ti-vpe/sc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/ti-vpe/sc.c 
> b/drivers/media/platform/ti-vpe/sc.c
> index 98f95082a6fd..0202d278523f 100644
> --- a/drivers/media/platform/ti-vpe/sc.c
> +++ b/drivers/media/platform/ti-vpe/sc.c
> @@ -294,10 +294,8 @@ struct sc_data *sc_create(struct platform_device *pdev, 
> const char *res_name)
>   }
>  
>   sc->base = devm_ioremap_resource(>dev, sc->res);
> - if (IS_ERR(sc->base)) {
> - dev_err(>dev, "failed to ioremap\n");
> + if (IS_ERR(sc->base))
>   return ERR_CAST(sc->base);
> - }

Reviewed-by: Benoit Parrot 

>  
>   return sc;
>  }
> -- 
> 2.25.1
> 

Re: [PATCH -next] media: ti-vpe: csc: remove redundant dev_err call in csc_create()

[Benoit Parrot]

Yang,

Thank you for the patch.

Yang Yingliang  wrote on Thu [2021-Apr-01 18:28:50 
+0800]:
> There is an error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Yang Yingliang 
> ---
>  drivers/media/platform/ti-vpe/csc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/ti-vpe/csc.c 
> b/drivers/media/platform/ti-vpe/csc.c
> index f4e0cf72d1cf..ff15bc589f1b 100644
> --- a/drivers/media/platform/ti-vpe/csc.c
> +++ b/drivers/media/platform/ti-vpe/csc.c
> @@ -267,10 +267,8 @@ struct csc_data *csc_create(struct platform_device 
> *pdev, const char *res_name)
>   }
>  
>   csc->base = devm_ioremap_resource(>dev, csc->res);
> - if (IS_ERR(csc->base)) {
> - dev_err(>dev, "failed to ioremap\n");
> + if (IS_ERR(csc->base))
>   return ERR_CAST(csc->base);
> - }

Reviewed-by: Benoit Parrot 

>  
>   return csc;
>  }
> -- 
> 2.25.1
> 

Re: [PATCH 08/49] staging: rtl8723bs: remove RT_TRACE logs in core/rtw_cmd.c

[Dan Carpenter]

On Thu, Apr 01, 2021 at 11:51:15PM +0200, Fabio Aiuto wrote:
> On Thu, Apr 01, 2021 at 05:32:36PM +0300, Dan Carpenter wrote:
> > On Thu, Apr 01, 2021 at 03:55:37PM +0200, Fabio Aiuto wrote:
> > > 
> > > Hi Dan,
> > > 
> > > I have the following:
> > > 
> > >   if (rtw_createbss_cmd(adapter) != _SUCCESS)
> > > - RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("Error 
> > > =>rtw_createbss_cmd status FAIL\n"));
> > > + ;
> > > 
> > > will I leave
> > > 
> > >   if (rtw_createbss_cmd(adapter) != _SUCCESS)
> > >   ;
> > > 
> > > or just
> > > 
> > >   rtw_createbss_cmd(adapter);
> > > 
> > > ?
> > > 
> > > what's best from the static analysis point of view?
> > > 
> > > smatch and sparse says nothing about that.
> > 
> > rtw_createbss_cmd() can only fail if this allocation fails:
> > 
> > pcmd = rtw_zmalloc(sizeof(struct cmd_obj));
> > 
> > In current kernels, that size of small allocation will never fail.  But
> > we alway write code as if every allocation can fail.
> > 
> > Normally when an allocation fails then we want to return -ENOMEM and
> > clean up.  But this code is an event handler for firmware events and
> > there isn't any real clean up to do.  Since there is nothing we can do
> > then this is basically working and fine.
> > 
> > How I would write this is:
> > 
> > ret = rtw_createbss_cmd(adapter);
> > if (ret != _SUCCESS)
> > goto unlock;
> > }
> > }
> > unlock:
> > spin_unlock_bh(>lock);
> > }
> > 
> > That doesn't change how the code works but it signals to the the reader
> > what your intention is.  If we just remove the error handling then it's
> > ambiguous.
> > 
> > rtw_createbss_cmd(adapter);
> > }
> > }
> > <-- Futurue programmer decides to add code here then figuring
> > that rtw_createbss_cmd() can fail is a problem.
> > 
> > spin_unlock_bh(>lock);
> > }
> > 
> > But for something like this which is maybe more subtle than just a
> > straight delete of lines of code, then consider pulling it out into its
> > own separate patch.  That makes it easier to review.  Put all the stuff
> > that I said in the commit message:
> > 
> > ---
> > [PATCH] tidy up some error handling
> > 
> > The RT_TRACE() output is not useful so we want to delete it.  In this
> > case there is no cleanup for rtw_createbss_cmd() required or even
> > possible.  I've deleted the RT_TRACE() output and added a goto unlock
> > to show that we can't continue if rtw_createbss_cmd() fails.
> > 
> > ---
> > 
> > > 
> > > Checkpatch too seems to ignore it, maybe the first one is good,
> > > but I would like to be sure before sending another over 40 patches
> > > long patchset.
> > 
> > Don't send 40 patches.  Just send 10 at a time until you get a better
> > feel for which ones are going to get applied or not. :P  It's not
> > arbitrary, and I'm definitely not trying to NAK your patches.  Once you
> > learn the rules I hope that it's predictable and straight forward.
> > 
> > regards,
> > dan carpenter
> > 
> 
> Hi Dan,
> 
> sorry again. In this case:
> 
> @@ -828,10 +829,11 @@ void rtw_surveydone_event_callback(struct adapter 
> *adapter, u8 *pbuf)
>  
> pmlmepriv->fw_state = 
> WIFI_ADHOC_MASTER_STATE;
>  
> -   if (rtw_createbss_cmd(adapter) != 
> _SUCCESS)
> -   ;
> -
> pmlmepriv->to_join = false;
> +
> +   ret = rtw_createbss_cmd(adapter);
> +   if (ret != _SUCCESS)
> +   goto unlock;
> }
> }
> 
> I decided to move the set to false of pmlepriv->to_join before 
> the rtw_createbss_cmd(). In old code that statement was executed
> unconditionally and seems not to be tied to the failure of 
> rtw_createbss_cmd().
> 
> The eventual goto would skip this instruction so I moved it
> before.
> 
> What do you think?

So when you're sending patches like this which have the potential to
change the behavior then we want to see your thought process explained a
bit in the message.

For example, when I'm reviewing patches in my email client, then I don't
know if rtw_createbss_cmd() uses pmlmepriv->to_join.  It turns out it
doesn't.  I also don't know what ->to_join is for really.  Your patch
preserves the original logic, but it's not totally clear that the
original code was correct.  See how it's done in rtw_do_join():

drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
   107  rtw_generate_random_ibss(pibss);
   108  
   109  if (rtw_createbss_cmd(padapter) != 
_SUCCESS) {
   110  
RT_TRACE(_module_rtl871x_ioctl_set_c_, _drv_err_, ("***Error =>do_goin: 

Re: [PATCH v2 2/2] iio: temperature: add driver support for ti tmp117

[Lars-Peter Clausen]

On 4/1/21 11:36 AM, Andy Shevchenko wrote:

[...]

+   case IIO_CHAN_INFO_SCALE:
+   /* Conversion from 10s of uC to mC
+* as IIO reports temperature in mC
+*/
+   *val = TMP117_RESOLUTION_10UC / 1;
+   *val2 = (TMP117_RESOLUTION_10UC % 1) * 100;
+   return IIO_VAL_INT_PLUS_MICRO;

You use 1 many times, can you give it an appropriate name (via #define)?

#define TENTHOUSAND 1 ;)

Re: [PATCH v2 2/2] iio: temperature: add driver support for ti tmp117

[Lars-Peter Clausen]

On 4/1/21 11:16 AM, Puranjay Mohan wrote:

TMP117 is a Digital temperature sensor with integrated NV memory.

Add support for tmp117 driver in iio subsystem.
Datasheet:-https://www.ti.com/lit/gpn/tmp117

Signed-off-by: Puranjay Mohan 


Nice and clean driver. Just some comments about the CALIBBIAS.


[...]
+#define TMP117_RESOLUTION_10UC 78125

Isn't the unit here 100 uC?

+#define TMP117_DEVICE_ID   0x0117
+
+struct tmp117_data {
+   struct i2c_client *client;
+};
+
+static int tmp117_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *channel, int *val,
+   int *val2, long mask)
+{
[...]
+   case IIO_CHAN_INFO_CALIBBIAS:
+   ret = i2c_smbus_read_word_swapped(data->client,
+   TMP117_REG_TEMP_OFFSET);
+   if (ret < 0)
+   return ret;
+   *val = ((int16_t)ret * (int32_t)TMP117_RESOLUTION_10UC)
+   / 1;
+   *val2 = ((int16_t)ret * (int32_t)TMP117_RESOLUTION_10UC)
+   % 1;


If I understand this right CALBBIAS is written in one unit, but read in 
another unit. E.g. if you do `echo 100 > ..._calibbias` and then `cat 
..._calibbias` you'd read a different value back.


I think that would be quite unexpected behavior. The unit should be the 
same. Here in the read function you can just return the register value. 
Just make sure to properly sign extend like for the RAW property.



+   return IIO_VAL_INT_PLUS_MICRO;
[...]
+}
+
+static int tmp117_write_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *channel, int val,
+   int val2, long mask)
+{
+   struct tmp117_data *data = iio_priv(indio_dev);
+   s16 off;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_CALIBBIAS:
+   off = (s16)val;
This should have some input validation to avoid writing bogus values to 
the register when the value is out of range. You can either reject out 
of range values or clamp them into the valid range (using the clamp() 
macro).

+   return i2c_smbus_write_word_swapped(data->client,
+   TMP117_REG_TEMP_OFFSET, off);
+
+   default:
+   return -EINVAL;
+   }
+}
+

[...]

[tip: perf/core] perf/x86/intel/uncore: Generic support for the MSR type of uncore blocks

[tip-bot2 for Kan Liang]

The following commit has been merged into the perf/core branch of tip:

Commit-ID: d6c754130435ab786711bed75d04a2388a6b4da8
Gitweb:
https://git.kernel.org/tip/d6c754130435ab786711bed75d04a2388a6b4da8
Author:Kan Liang 
AuthorDate:Wed, 17 Mar 2021 10:59:34 -07:00
Committer: Peter Zijlstra 
CommitterDate: Fri, 02 Apr 2021 10:04:54 +02:00

perf/x86/intel/uncore: Generic support for the MSR type of uncore blocks

The discovery table provides the generic uncore block information for
the MSR type of uncore blocks, e.g., the counter width, the number of
counters, the location of control/counter registers, which is good
enough to provide basic uncore support. It can be used as a fallback
solution when the kernel doesn't support a platform.

The name of the uncore box cannot be retrieved from the discovery table.
uncore_type__ will be used as its name. Save the type ID
and the box ID information in the struct intel_uncore_type.
Factor out uncore_get_pmu_name() to handle different naming methods.

Implement generic support for the MSR type of uncore block.

Some advanced features, such as filters and constraints, cannot be
retrieved from discovery tables. Features that rely on that
information are not be supported here.

Signed-off-by: Kan Liang 
Signed-off-by: Peter Zijlstra (Intel) 
Link: 
https://lkml.kernel.org/r/1616003977-90612-3-git-send-email-kan.li...@linux.intel.com
---
 arch/x86/events/intel/uncore.c   |  45 ++--
 arch/x86/events/intel/uncore.h   |   3 +-
 arch/x86/events/intel/uncore_discovery.c | 126 ++-
 arch/x86/events/intel/uncore_discovery.h |  18 +++-
 4 files changed, 182 insertions(+), 10 deletions(-)

diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index d111370..dabc01f 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -10,7 +10,7 @@ static bool uncore_no_discover;
 module_param(uncore_no_discover, bool, 0);
 MODULE_PARM_DESC(uncore_no_discover, "Don't enable the Intel uncore PerfMon 
discovery mechanism "
 "(default: enable the discovery 
mechanism).");
-static struct intel_uncore_type *empty_uncore[] = { NULL, };
+struct intel_uncore_type *empty_uncore[] = { NULL, };
 struct intel_uncore_type **uncore_msr_uncores = empty_uncore;
 struct intel_uncore_type **uncore_pci_uncores = empty_uncore;
 struct intel_uncore_type **uncore_mmio_uncores = empty_uncore;
@@ -834,6 +834,34 @@ static const struct attribute_group uncore_pmu_attr_group 
= {
.attrs = uncore_pmu_attrs,
 };
 
+static void uncore_get_pmu_name(struct intel_uncore_pmu *pmu)
+{
+   struct intel_uncore_type *type = pmu->type;
+
+   /*
+* No uncore block name in discovery table.
+* Use uncore_type__ as name.
+*/
+   if (!type->name) {
+   if (type->num_boxes == 1)
+   sprintf(pmu->name, "uncore_type_%u", type->type_id);
+   else {
+   sprintf(pmu->name, "uncore_type_%u_%d",
+   type->type_id, type->box_ids[pmu->pmu_idx]);
+   }
+   return;
+   }
+
+   if (type->num_boxes == 1) {
+   if (strlen(type->name) > 0)
+   sprintf(pmu->name, "uncore_%s", type->name);
+   else
+   sprintf(pmu->name, "uncore");
+   } else
+   sprintf(pmu->name, "uncore_%s_%d", type->name, pmu->pmu_idx);
+
+}
+
 static int uncore_pmu_register(struct intel_uncore_pmu *pmu)
 {
int ret;
@@ -860,15 +888,7 @@ static int uncore_pmu_register(struct intel_uncore_pmu 
*pmu)
pmu->pmu.attr_update = pmu->type->attr_update;
}
 
-   if (pmu->type->num_boxes == 1) {
-   if (strlen(pmu->type->name) > 0)
-   sprintf(pmu->name, "uncore_%s", pmu->type->name);
-   else
-   sprintf(pmu->name, "uncore");
-   } else {
-   sprintf(pmu->name, "uncore_%s_%d", pmu->type->name,
-   pmu->pmu_idx);
-   }
+   uncore_get_pmu_name(pmu);
 
ret = perf_pmu_register(>pmu, pmu->name, -1);
if (!ret)
@@ -909,6 +929,10 @@ static void uncore_type_exit(struct intel_uncore_type 
*type)
kfree(type->pmus);
type->pmus = NULL;
}
+   if (type->box_ids) {
+   kfree(type->box_ids);
+   type->box_ids = NULL;
+   }
kfree(type->events_group);
type->events_group = NULL;
 }
@@ -1643,6 +1667,7 @@ static const struct intel_uncore_init_fun snr_uncore_init 
__initconst = {
 };
 
 static const struct intel_uncore_init_fun generic_uncore_init __initconst = {
+   .cpu_init = intel_uncore_generic_uncore_cpu_init,
 };
 
 static const struct x86_cpu_id intel_uncore_match[] __initconst = {
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index 

[tip: perf/core] perf/x86/intel/uncore: Parse uncore discovery tables

[tip-bot2 for Kan Liang]

The following commit has been merged into the perf/core branch of tip:

Commit-ID: edae1f06c2cda41edffc93de6aedc8ba8dc883c3
Gitweb:
https://git.kernel.org/tip/edae1f06c2cda41edffc93de6aedc8ba8dc883c3
Author:Kan Liang 
AuthorDate:Wed, 17 Mar 2021 10:59:33 -07:00
Committer: Peter Zijlstra 
CommitterDate: Fri, 02 Apr 2021 10:04:54 +02:00

perf/x86/intel/uncore: Parse uncore discovery tables

A self-describing mechanism for the uncore PerfMon hardware has been
introduced with the latest Intel platforms. By reading through an MMIO
page worth of information, perf can 'discover' all the standard uncore
PerfMon registers in a machine.

The discovery mechanism relies on BIOS's support. With a proper BIOS,
a PCI device with the unique capability ID 0x23 can be found on each
die. Perf can retrieve the information of all available uncore PerfMons
from the device via MMIO. The information is composed of one global
discovery table and several unit discovery tables.
- The global discovery table includes global uncore information of the
  die, e.g., the address of the global control register, the offset of
  the global status register, the number of uncore units, the offset of
  unit discovery tables, etc.
- The unit discovery table includes generic uncore unit information,
  e.g., the access type, the counter width, the address of counters,
  the address of the counter control, the unit ID, the unit type, etc.
  The unit is also called "box" in the code.
Perf can provide basic uncore support based on this information
with the following patches.

To locate the PCI device with the discovery tables, check the generic
PCI ID first. If it doesn't match, go through the entire PCI device tree
and locate the device with the unique capability ID.

The uncore information is similar among dies. To save parsing time and
space, only completely parse and store the discovery tables on the first
die and the first box of each die. The parsed information is stored in
an
RB tree structure, intel_uncore_discovery_type. The size of the stored
discovery tables varies among platforms. It's around 4KB for a Sapphire
Rapids server.

If a BIOS doesn't support the 'discovery' mechanism, the uncore driver
will exit with -ENODEV. There is nothing changed.

Add a module parameter to disable the discovery feature. If a BIOS gets
the discovery tables wrong, users can have an option to disable the
feature. For the current patchset, the uncore driver will exit with
-ENODEV. In the future, it may fall back to the hardcode uncore driver
on a known platform.

Signed-off-by: Kan Liang 
Signed-off-by: Peter Zijlstra (Intel) 
Link: 
https://lkml.kernel.org/r/1616003977-90612-2-git-send-email-kan.li...@linux.intel.com
---
 arch/x86/events/intel/Makefile   |   2 +-
 arch/x86/events/intel/uncore.c   |  31 +-
 arch/x86/events/intel/uncore_discovery.c | 318 ++-
 arch/x86/events/intel/uncore_discovery.h | 105 +++-
 4 files changed, 448 insertions(+), 8 deletions(-)
 create mode 100644 arch/x86/events/intel/uncore_discovery.c
 create mode 100644 arch/x86/events/intel/uncore_discovery.h

diff --git a/arch/x86/events/intel/Makefile b/arch/x86/events/intel/Makefile
index e67a588..10bde6c 100644
--- a/arch/x86/events/intel/Makefile
+++ b/arch/x86/events/intel/Makefile
@@ -3,6 +3,6 @@ obj-$(CONFIG_CPU_SUP_INTEL) += core.o bts.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= ds.o knc.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= lbr.o p4.o p6.o pt.o
 obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE) += intel-uncore.o
-intel-uncore-objs  := uncore.o uncore_nhmex.o uncore_snb.o 
uncore_snbep.o
+intel-uncore-objs  := uncore.o uncore_nhmex.o uncore_snb.o 
uncore_snbep.o uncore_discovery.o
 obj-$(CONFIG_PERF_EVENTS_INTEL_CSTATE) += intel-cstate.o
 intel-cstate-objs  := cstate.o
diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 33c8180..d111370 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -4,7 +4,12 @@
 #include 
 #include 
 #include "uncore.h"
+#include "uncore_discovery.h"
 
+static bool uncore_no_discover;
+module_param(uncore_no_discover, bool, 0);
+MODULE_PARM_DESC(uncore_no_discover, "Don't enable the Intel uncore PerfMon 
discovery mechanism "
+"(default: enable the discovery 
mechanism).");
 static struct intel_uncore_type *empty_uncore[] = { NULL, };
 struct intel_uncore_type **uncore_msr_uncores = empty_uncore;
 struct intel_uncore_type **uncore_pci_uncores = empty_uncore;
@@ -1637,6 +1642,9 @@ static const struct intel_uncore_init_fun snr_uncore_init 
__initconst = {
.mmio_init = snr_uncore_mmio_init,
 };
 
+static const struct intel_uncore_init_fun generic_uncore_init __initconst = {
+};
+
 static const struct x86_cpu_id intel_uncore_match[] __initconst = {
X86_MATCH_INTEL_FAM6_MODEL(NEHALEM_EP,  _uncore_init),

[tip: perf/core] perf/x86/intel/uncore: Generic support for the PCI type of uncore blocks

[tip-bot2 for Kan Liang]

The following commit has been merged into the perf/core branch of tip:

Commit-ID: 42839ef4a20a4bda415974ff0e7d85ff540fffa4
Gitweb:
https://git.kernel.org/tip/42839ef4a20a4bda415974ff0e7d85ff540fffa4
Author:Kan Liang 
AuthorDate:Wed, 17 Mar 2021 10:59:36 -07:00
Committer: Peter Zijlstra 
CommitterDate: Fri, 02 Apr 2021 10:04:55 +02:00

perf/x86/intel/uncore: Generic support for the PCI type of uncore blocks

The discovery table provides the generic uncore block information
for the PCI type of uncore blocks, which is good enough to provide
basic uncore support.

The PCI BUS and DEVFN information can be retrieved from the box control
field. Introduce the uncore_pci_pmus_register() to register all the
PCICFG type of uncore blocks. The old PCI probe/remove way is dropped.

The PCI BUS and DEVFN information are different among dies. Add box_ctls
to store the box control field of each die.

Add a new BUS notifier for the PCI type of uncore block to support the
hotplug. If the device is "hot remove", the corresponding registered PMU
has to be unregistered. Perf cannot locate the PMU by searching a const
pci_device_id table, because the discovery tables don't provide such
information. Introduce uncore_pci_find_dev_pmu_from_types() to search
the whole uncore_pci_uncores for the PMU.

Implement generic support for the PCI type of uncore block.

Signed-off-by: Kan Liang 
Signed-off-by: Peter Zijlstra (Intel) 
Link: 
https://lkml.kernel.org/r/1616003977-90612-5-git-send-email-kan.li...@linux.intel.com
---
 arch/x86/events/intel/uncore.c   | 91 +--
 arch/x86/events/intel/uncore.h   |  6 +-
 arch/x86/events/intel/uncore_discovery.c | 80 -
 arch/x86/events/intel/uncore_discovery.h |  7 ++-
 4 files changed, 177 insertions(+), 7 deletions(-)

diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 391fa7c..3109082 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -1032,10 +1032,37 @@ static int uncore_pci_get_dev_die_info(struct pci_dev 
*pdev, int *die)
return 0;
 }
 
+static struct intel_uncore_pmu *
+uncore_pci_find_dev_pmu_from_types(struct pci_dev *pdev)
+{
+   struct intel_uncore_type **types = uncore_pci_uncores;
+   struct intel_uncore_type *type;
+   u64 box_ctl;
+   int i, die;
+
+   for (; *types; types++) {
+   type = *types;
+   for (die = 0; die < __uncore_max_dies; die++) {
+   for (i = 0; i < type->num_boxes; i++) {
+   if (!type->box_ctls[die])
+   continue;
+   box_ctl = type->box_ctls[die] + 
type->pci_offsets[i];
+   if (pdev->devfn == 
UNCORE_DISCOVERY_PCI_DEVFN(box_ctl) &&
+   pdev->bus->number == 
UNCORE_DISCOVERY_PCI_BUS(box_ctl) &&
+   pci_domain_nr(pdev->bus) == 
UNCORE_DISCOVERY_PCI_DOMAIN(box_ctl))
+   return >pmus[i];
+   }
+   }
+   }
+
+   return NULL;
+}
+
 /*
  * Find the PMU of a PCI device.
  * @pdev: The PCI device.
  * @ids: The ID table of the available PCI devices with a PMU.
+ *   If NULL, search the whole uncore_pci_uncores.
  */
 static struct intel_uncore_pmu *
 uncore_pci_find_dev_pmu(struct pci_dev *pdev, const struct pci_device_id *ids)
@@ -1045,6 +1072,9 @@ uncore_pci_find_dev_pmu(struct pci_dev *pdev, const 
struct pci_device_id *ids)
kernel_ulong_t data;
unsigned int devfn;
 
+   if (!ids)
+   return uncore_pci_find_dev_pmu_from_types(pdev);
+
while (ids && ids->vendor) {
if ((ids->vendor == pdev->vendor) &&
(ids->device == pdev->device)) {
@@ -1283,6 +1313,48 @@ static void uncore_pci_sub_driver_init(void)
uncore_pci_sub_driver = NULL;
 }
 
+static int uncore_pci_bus_notify(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   return uncore_bus_notify(nb, action, data, NULL);
+}
+
+static struct notifier_block uncore_pci_notifier = {
+   .notifier_call = uncore_pci_bus_notify,
+};
+
+
+static void uncore_pci_pmus_register(void)
+{
+   struct intel_uncore_type **types = uncore_pci_uncores;
+   struct intel_uncore_type *type;
+   struct intel_uncore_pmu *pmu;
+   struct pci_dev *pdev;
+   u64 box_ctl;
+   int i, die;
+
+   for (; *types; types++) {
+   type = *types;
+   for (die = 0; die < __uncore_max_dies; die++) {
+   for (i = 0; i < type->num_boxes; i++) {
+   if (!type->box_ctls[die])
+   continue;
+   box_ctl = type->box_ctls[die] + 
type->pci_offsets[i];
+   

[tip: perf/core] perf/x86/intel/uncore: Rename uncore_notifier to uncore_pci_sub_notifier

[tip-bot2 for Kan Liang]

The following commit has been merged into the perf/core branch of tip:

Commit-ID: 6477dc3934775f82a571fac469fd8c348e611095
Gitweb:
https://git.kernel.org/tip/6477dc3934775f82a571fac469fd8c348e611095
Author:Kan Liang 
AuthorDate:Wed, 17 Mar 2021 10:59:35 -07:00
Committer: Peter Zijlstra 
CommitterDate: Fri, 02 Apr 2021 10:04:54 +02:00

perf/x86/intel/uncore: Rename uncore_notifier to uncore_pci_sub_notifier

Perf will use a similar method to the PCI sub driver to register
the PMUs for the PCI type of uncore blocks. The method requires a BUS
notifier to support hotplug. The current BUS notifier cannot be reused,
because it searches a const id_table for the corresponding registered
PMU. The PCI type of uncore blocks in the discovery tables doesn't
provide an id_table.

Factor out uncore_bus_notify() and add the pointer of an id_table as a
parameter. The uncore_bus_notify() will be reused in the following
patch.

The current BUS notifier is only used by the PCI sub driver. Its name is
too generic. Rename it to uncore_pci_sub_notifier, which is specific for
the PCI sub driver.

Signed-off-by: Kan Liang 
Signed-off-by: Peter Zijlstra (Intel) 
Link: 
https://lkml.kernel.org/r/1616003977-90612-4-git-send-email-kan.li...@linux.intel.com
---
 arch/x86/events/intel/uncore.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index dabc01f..391fa7c 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -1203,7 +1203,8 @@ static void uncore_pci_remove(struct pci_dev *pdev)
 }
 
 static int uncore_bus_notify(struct notifier_block *nb,
-unsigned long action, void *data)
+unsigned long action, void *data,
+const struct pci_device_id *ids)
 {
struct device *dev = data;
struct pci_dev *pdev = to_pci_dev(dev);
@@ -1214,7 +1215,7 @@ static int uncore_bus_notify(struct notifier_block *nb,
if (action != BUS_NOTIFY_DEL_DEVICE)
return NOTIFY_DONE;
 
-   pmu = uncore_pci_find_dev_pmu(pdev, uncore_pci_sub_driver->id_table);
+   pmu = uncore_pci_find_dev_pmu(pdev, ids);
if (!pmu)
return NOTIFY_DONE;
 
@@ -1226,8 +1227,15 @@ static int uncore_bus_notify(struct notifier_block *nb,
return NOTIFY_OK;
 }
 
-static struct notifier_block uncore_notifier = {
-   .notifier_call = uncore_bus_notify,
+static int uncore_pci_sub_bus_notify(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+   return uncore_bus_notify(nb, action, data,
+uncore_pci_sub_driver->id_table);
+}
+
+static struct notifier_block uncore_pci_sub_notifier = {
+   .notifier_call = uncore_pci_sub_bus_notify,
 };
 
 static void uncore_pci_sub_driver_init(void)
@@ -1268,7 +1276,7 @@ static void uncore_pci_sub_driver_init(void)
ids++;
}
 
-   if (notify && bus_register_notifier(_bus_type, _notifier))
+   if (notify && bus_register_notifier(_bus_type, 
_pci_sub_notifier))
notify = false;
 
if (!notify)
@@ -1319,7 +1327,7 @@ static void uncore_pci_exit(void)
if (pcidrv_registered) {
pcidrv_registered = false;
if (uncore_pci_sub_driver)
-   bus_unregister_notifier(_bus_type, 
_notifier);
+   bus_unregister_notifier(_bus_type, 
_pci_sub_notifier);
pci_unregister_driver(uncore_pci_driver);
uncore_types_exit(uncore_pci_uncores);
kfree(uncore_extra_pci_dev);

[tip: perf/core] perf/x86/intel/uncore: Generic support for the MMIO type of uncore blocks

[tip-bot2 for Kan Liang]

The following commit has been merged into the perf/core branch of tip:

Commit-ID: c4c55e362a521d763356b9e02bc9a4348c71a471
Gitweb:
https://git.kernel.org/tip/c4c55e362a521d763356b9e02bc9a4348c71a471
Author:Kan Liang 
AuthorDate:Wed, 17 Mar 2021 10:59:37 -07:00
Committer: Peter Zijlstra 
CommitterDate: Fri, 02 Apr 2021 10:04:55 +02:00

perf/x86/intel/uncore: Generic support for the MMIO type of uncore blocks

The discovery table provides the generic uncore block information
for the MMIO type of uncore blocks, which is good enough to provide
basic uncore support.

The box control field is composed of the BAR address and box control
offset. When initializing the uncore blocks, perf should ioremap the
address from the box control field.

Implement the generic support for the MMIO type of uncore block.

Signed-off-by: Kan Liang 
Signed-off-by: Peter Zijlstra (Intel) 
Link: 
https://lkml.kernel.org/r/1616003977-90612-6-git-send-email-kan.li...@linux.intel.com
---
 arch/x86/events/intel/uncore.c   |  1 +-
 arch/x86/events/intel/uncore.h   |  1 +-
 arch/x86/events/intel/uncore_discovery.c | 98 +++-
 arch/x86/events/intel/uncore_discovery.h |  1 +-
 4 files changed, 101 insertions(+)

diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 3109082..35b3470 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -1755,6 +1755,7 @@ static const struct intel_uncore_init_fun snr_uncore_init 
__initconst = {
 static const struct intel_uncore_init_fun generic_uncore_init __initconst = {
.cpu_init = intel_uncore_generic_uncore_cpu_init,
.pci_init = intel_uncore_generic_uncore_pci_init,
+   .mmio_init = intel_uncore_generic_uncore_mmio_init,
 };
 
 static const struct x86_cpu_id intel_uncore_match[] __initconst = {
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index 76fc898..549cfb2 100644
--- a/arch/x86/events/intel/uncore.h
+++ b/arch/x86/events/intel/uncore.h
@@ -70,6 +70,7 @@ struct intel_uncore_type {
union {
unsigned *msr_offsets;
unsigned *pci_offsets;
+   unsigned *mmio_offsets;
};
unsigned *box_ids;
struct event_constraint unconstrainted;
diff --git a/arch/x86/events/intel/uncore_discovery.c 
b/arch/x86/events/intel/uncore_discovery.c
index 784d7b4..aba9bff 100644
--- a/arch/x86/events/intel/uncore_discovery.c
+++ b/arch/x86/events/intel/uncore_discovery.c
@@ -442,6 +442,90 @@ static struct intel_uncore_ops generic_uncore_pci_ops = {
.read_counter   = intel_generic_uncore_pci_read_counter,
 };
 
+#define UNCORE_GENERIC_MMIO_SIZE   0x4000
+
+static unsigned int generic_uncore_mmio_box_ctl(struct intel_uncore_box *box)
+{
+   struct intel_uncore_type *type = box->pmu->type;
+
+   if (!type->box_ctls || !type->box_ctls[box->dieid] || 
!type->mmio_offsets)
+   return 0;
+
+   return type->box_ctls[box->dieid] + 
type->mmio_offsets[box->pmu->pmu_idx];
+}
+
+static void intel_generic_uncore_mmio_init_box(struct intel_uncore_box *box)
+{
+   unsigned int box_ctl = generic_uncore_mmio_box_ctl(box);
+   struct intel_uncore_type *type = box->pmu->type;
+   resource_size_t addr;
+
+   if (!box_ctl) {
+   pr_warn("Uncore type %d box %d: Invalid box control address.\n",
+   type->type_id, type->box_ids[box->pmu->pmu_idx]);
+   return;
+   }
+
+   addr = box_ctl;
+   box->io_addr = ioremap(addr, UNCORE_GENERIC_MMIO_SIZE);
+   if (!box->io_addr) {
+   pr_warn("Uncore type %d box %d: ioremap error for 0x%llx.\n",
+   type->type_id, type->box_ids[box->pmu->pmu_idx],
+   (unsigned long long)addr);
+   return;
+   }
+
+   writel(GENERIC_PMON_BOX_CTL_INT, box->io_addr);
+}
+
+static void intel_generic_uncore_mmio_disable_box(struct intel_uncore_box *box)
+{
+   if (!box->io_addr)
+   return;
+
+   writel(GENERIC_PMON_BOX_CTL_FRZ, box->io_addr);
+}
+
+static void intel_generic_uncore_mmio_enable_box(struct intel_uncore_box *box)
+{
+   if (!box->io_addr)
+   return;
+
+   writel(0, box->io_addr);
+}
+
+static void intel_generic_uncore_mmio_enable_event(struct intel_uncore_box 
*box,
+struct perf_event *event)
+{
+   struct hw_perf_event *hwc = >hw;
+
+   if (!box->io_addr)
+   return;
+
+   writel(hwc->config, box->io_addr + hwc->config_base);
+}
+
+static void intel_generic_uncore_mmio_disable_event(struct intel_uncore_box 
*box,
+ struct perf_event *event)
+{
+   struct hw_perf_event *hwc = >hw;
+
+   if (!box->io_addr)
+   return;
+
+   writel(0, box->io_addr + hwc->config_base);
+}
+
+static struct intel_uncore_ops 

[tip: perf/core] perf/x86/intel/uncore: Enable IIO stacks to PMON mapping for multi-segment SKX

[tip-bot2 for Alexander Antonov]

The following commit has been merged into the perf/core branch of tip:

Commit-ID: cface0326a6c2ae5c8f47bd466f07624b3e348a7
Gitweb:
https://git.kernel.org/tip/cface0326a6c2ae5c8f47bd466f07624b3e348a7
Author:Alexander Antonov 
AuthorDate:Tue, 23 Mar 2021 18:05:07 +03:00
Committer: Peter Zijlstra 
CommitterDate: Fri, 02 Apr 2021 10:04:55 +02:00

perf/x86/intel/uncore: Enable IIO stacks to PMON mapping for multi-segment SKX

IIO stacks to PMON mapping on Skylake servers is exposed through introduced
early attributes /sys/devices/uncore_iio_/dieX, where dieX is a
file which holds "Segment:Root Bus" for PCIe root port which can
be monitored by that IIO PMON block. These sysfs attributes are disabled
for multiple segment topologies except VMD domains which start at 0x1.
This patch removes the limitation and enables IIO stacks to PMON mapping
for multi-segment Skylake servers by introducing segment-aware
intel_uncore_topology structure and attributing the topology configuration
to the segment in skx_iio_get_topology() function.

Reported-by: kernel test robot 
Signed-off-by: Alexander Antonov 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Kan Liang 
Reviewed-by: Andi Kleen 
Tested-by: Kyle Meyer 
Link: 
https://lkml.kernel.org/r/20210323150507.2013-1-alexander.anto...@linux.intel.com
---
 arch/x86/events/intel/uncore.c   | 12 +-
 arch/x86/events/intel/uncore.h   |  9 +++-
 arch/x86/events/intel/uncore_snbep.c | 60 ---
 3 files changed, 47 insertions(+), 34 deletions(-)

diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 35b3470..a2b68bb 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -53,6 +53,18 @@ int uncore_pcibus_to_dieid(struct pci_bus *bus)
return die_id;
 }
 
+int uncore_die_to_segment(int die)
+{
+   struct pci_bus *bus = NULL;
+
+   /* Find first pci bus which attributes to specified die. */
+   while ((bus = pci_find_next_bus(bus)) &&
+  (die != uncore_pcibus_to_dieid(bus)))
+   ;
+
+   return bus ? pci_domain_nr(bus) : -EINVAL;
+}
+
 static void uncore_free_pcibus_map(void)
 {
struct pci2phy_map *map, *tmp;
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index 549cfb2..96569dc 100644
--- a/arch/x86/events/intel/uncore.h
+++ b/arch/x86/events/intel/uncore.h
@@ -42,6 +42,7 @@ struct intel_uncore_pmu;
 struct intel_uncore_box;
 struct uncore_event_desc;
 struct freerunning_counters;
+struct intel_uncore_topology;
 
 struct intel_uncore_type {
const char *name;
@@ -87,7 +88,7 @@ struct intel_uncore_type {
 * to identify which platform component each PMON block of that type is
 * supposed to monitor.
 */
-   u64 *topology;
+   struct intel_uncore_topology *topology;
/*
 * Optional callbacks for managing mapping of Uncore units to PMONs
 */
@@ -176,6 +177,11 @@ struct freerunning_counters {
unsigned *box_offsets;
 };
 
+struct intel_uncore_topology {
+   u64 configuration;
+   int segment;
+};
+
 struct pci2phy_map {
struct list_head list;
int segment;
@@ -184,6 +190,7 @@ struct pci2phy_map {
 
 struct pci2phy_map *__find_pci2phy_map(int segment);
 int uncore_pcibus_to_dieid(struct pci_bus *bus);
+int uncore_die_to_segment(int die);
 
 ssize_t uncore_event_show(struct device *dev,
  struct device_attribute *attr, char *buf);
diff --git a/arch/x86/events/intel/uncore_snbep.c 
b/arch/x86/events/intel/uncore_snbep.c
index b79951d..acc3c0e 100644
--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -3684,7 +3684,8 @@ static struct intel_uncore_ops skx_uncore_iio_ops = {
 
 static inline u8 skx_iio_stack(struct intel_uncore_pmu *pmu, int die)
 {
-   return pmu->type->topology[die] >> (pmu->pmu_idx * BUS_NUM_STRIDE);
+   return pmu->type->topology[die].configuration >>
+  (pmu->pmu_idx * BUS_NUM_STRIDE);
 }
 
 static umode_t
@@ -3697,19 +3698,14 @@ skx_iio_mapping_visible(struct kobject *kobj, struct 
attribute *attr, int die)
 }
 
 static ssize_t skx_iio_mapping_show(struct device *dev,
-   struct device_attribute *attr, char *buf)
+   struct device_attribute *attr, char *buf)
 {
-   struct pci_bus *bus = pci_find_next_bus(NULL);
-   struct intel_uncore_pmu *uncore_pmu = dev_to_uncore_pmu(dev);
+   struct intel_uncore_pmu *pmu = dev_to_uncore_pmu(dev);
struct dev_ext_attribute *ea = to_dev_ext_attribute(attr);
long die = (long)ea->var;
 
-   /*
-* Current implementation is for single segment configuration hence it's
-* safe to take the segment value from the first available root bus.
-*/
-   return sprintf(buf, "%04x:%02x\n", pci_domain_nr(bus),
-  

Re: [PATCH v6 2/7] powercap/drivers/dtpm: Create a registering system

[Greg KH]

On Fri, Apr 02, 2021 at 12:08:49AM +0200, Daniel Lezcano wrote:
> 
> Hi Greg,
> 
> On 01/04/2021 21:28, Greg KH wrote:
> > On Thu, Apr 01, 2021 at 08:36:49PM +0200, Daniel Lezcano wrote:
> >> A SoC can be differently structured depending on the platform and the
> >> kernel can not be aware of all the combinations, as well as the
> >> specific tweaks for a particular board.
> >>
> >> The creation of the hierarchy must be delegated to userspace.
> > 
> > Why?  Isn't this what DT is for?
> 
> I've always been told the DT describes the hardware. Here we are more
> describing a configuration, that is the reason why I've let the
> userspace to handle that through configfs.

DT does describe how the hardware configuration is to be used.  You are
saying that the hardware description does not work and somehow you need
a magic userspace tool to reconfigure things instead?

> > What "userspace tool" is going to be created to manage all of this?
> > Pointers to that codebase?
> 
> You are certainly aware of most of it but let me give a bit more of context.

No, I am not aware of it at all, thanks :)

> The thermal framework has cooling devices which export their 'state', a
> representation of their performance level, in sysfs. Unfortunately that
> gives access from the user space to act on the performance as a power
> limiter in total conflict with the in-kernel thermal governor decisions.

Why not remove that conflict?

> That is done from thermal daemon the different SoC vendors tweak for
> their platform. Depending on the application running and identified as a
> scenario, the daemon acts proactively on the different cooling devices
> to ensure a skin temperature which is far below the thermal limit of the
> components.

So userspace is going to try to manage power settings in order to keep
thermal values under control?  Has no one learned from our past mistakes
when we used to have to do this 10 years ago and it turned out so bad
that it was just baked into the hardware instead?

{sigh}

> This usage of the cooling devices hijacked the real purpose of the
> thermal framework which is to protect the silicon. Nobody to blame,
> there is no alternative for userspace.

Userspace should not care.

> The use case falls under the power limitation framework prerogative and
> that is the reason why we provided a new framework to limit the power
> based on the powercap framework. The thermal daemon can then use it and
> stop abusing the thermal framework.
> 
> This DTPM framework allows to read the power consumption and set a power
> limit to a device.
> 
> While the powercap simple backend gives a single device entry, DTPM
> aggregates the different devices power by summing their power and their
> limits. The tree representation of the different DTPM nodes describe how
> their limits are set and how the power is computed along the different
> devices.

That's all great, doing this in-kernel is fine, it's now the "userspace
must set this up properly that I'm objecting to as no one will know how
to do this.

> For more info, we did a presentation at ELC [1] and Linux PM
> microconference [2] and there is an article talking about it [3].
> 
> 
> To answer your questions, there is a SoC vendor thermal daemon using
> DTPM and there is a tool created to watch the thermal framework and read
> the DTPM values, it is available at [4]. It is currently under
> development with the goal of doing power rebalancing / capping across
> the different nodes when there is a violation of the parent's power limit.

Crazy ideas aside, your implementation of this is my main objection
here.  You are creating a user/kernel api that you will have to support
for 20+ years, without a real userspace user just yet (from what I can
tell).  That's rough, and is going to mean that this gets messy over
time.

Also there's the whole "tying sysfs to configfs" mess and reference
counting that I object to as well...

> >> The next changes will provide an userspace interface to create
> >> hierarchically the different nodes. Those will be created by name and
> >> found via the list filled by the different subsystem.
> >>
> >> If a specified name is not found in the list, it is assumed to be a
> >> virtual node which will have children and the default is to allocate
> >> such node.
> > 
> > So userspace sets the name?
> > 
> > Why not use the name in the device itself?  I thought I asked that last
> > time...
> 
> I probably missed it, sorry for that.
> 
> When the userspace creates the directory in the configfs, there is a
> lookup with the name in the device list name. If it is found, then the
> device is used, otherwise a virtual node is created instead, its power
> consumption is equal to the sum of the children.
> 
> The different drivers register themselves with their name and the
> associated dtpm structure. The userspace pick in this list to create a
> hierarchy via configfs.
> 
> For example, a big.Little system.
> 
> - little CPUs power limiter will 

Re: [PATCH 2/2] mmc: block: Update ext_csd.cache_ctrl if it was written

[Avri Altman]

>> @@ -571,6 +571,14 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, 
>> struct mmc_blk_data *md,
>>  main_md->part_curr = value & EXT_CSD_PART_CONFIG_ACC_MASK;
>>  }
>>  
>> +/* Make sure to update CACHE_CTRL in case it was changed */

> It might be worth noting that the cache will get turned back
> on if the card is re-initialized, for example suspend/resume or
> hw reset in recovery.
Done.

Thanks,
Avri

RE: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

[Tian, Kevin]

> From: Jason Gunthorpe 
> Sent: Thursday, April 1, 2021 9:47 PM
> 
> On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe 
> > > Sent: Thursday, April 1, 2021 9:16 PM
> > >
> > > On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > > > > From: Jason Gunthorpe 
> > > > > Sent: Thursday, April 1, 2021 7:47 PM
> > > > [...]
> > > > > I'm worried Intel views the only use of PASID in a guest is with
> > > > > ENQCMD, but that is not consistent with the industry. We need to see
> > > > > normal nested PASID support with assigned PCI VFs.
> > > >
> > > > I'm not quire flow here. Intel also allows PASID usage in guest without
> > > > ENQCMD. e.g. Passthru a PF to guest, and use PASID on it without
> > > ENQCMD.
> > >
> > > Then you need all the parts, the hypervisor calls from the vIOMMU, and
> > > you can't really use a vPASID.
> >
> > This is a diagram shows the vSVA setup.
> 
> I'm not talking only about vSVA. Generic PASID support with arbitary
> mappings.
> 
> And how do you deal with the vPASID vs pPASID issue if the system has
> a mix of physical devices and mdevs?
> 

We plan to support two schemes. One is vPASID identity-mapped to
pPASID then the mixed scenario just works, with the limitation of 
lacking of live migration support. The other is non-identity-mapped 
scheme, where live migration is supported but physical devices and 
mdevs should not be mixed in one VM if both expose SVA capability 
(requires some filtering check in Qemu). Although we have some 
idea relaxing this restriction in the non-identity scheme, it requires 
more thinking given how the vSVA uAPI is being refactored.

In both cases the virtual VT-d will report a virtual capability to the guest,
indicating that the guest must request PASID through a vcmd register
instead of creating its own namespace. The vIOMMU returns a vPASID 
to the guest upon request. The vPASID could be directly mapped to a 
pPASID or allocated from a new namespace based on user configuration.

We hope the /dev/ioasid can support both schemes, with the minimal
requirement of allowing userspace to tag a vPASID to a pPASID and
allowing mdev to translate vPASID into pPASID, i.e. not assuming that
the guest will always use pPASID.

Thanks
Kevin

Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug multistate

[Greg KH]

On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> As for the syfs deadlock possible with drivers, this fixes it in a generic 
> way:
> 
> commit fac43d8025727a74f80a183cc5eb74ed902a5d14
> Author: Luis Chamberlain 
> Date:   Sat Mar 27 14:58:15 2021 +
> 
> sysfs: add optional module_owner to attribute
> 
> This is needed as otherwise the owner of the attribute
> or group read/store might have a shared lock used on driver removal,
> and deadlock if we race with driver removal.
> 
> Signed-off-by: Luis Chamberlain 

No, please no.  Module removal is a "best effort", if the system dies
when it happens, that's on you.  I am not willing to expend extra energy
and maintance of core things like sysfs for stuff like this that does
not matter in any system other than a developer's box.

Lock data, not code please.  Trying to tie data structure's lifespans
to the lifespan of code is a tangled mess, and one that I do not want to
add to in any form.

sorry,

greg k-h

Re: [PATCH v2 09/13] KVM: x86/mmu: Allow zap gfn range to operate under the mmu read lock

[Paolo Bonzini]

On 02/04/21 01:37, Ben Gardon wrote:

+void kvm_tdp_mmu_put_root(struct kvm *kvm, struct kvm_mmu_page *root,
+ bool shared)
  {
gfn_t max_gfn = 1ULL << (shadow_phys_bits - PAGE_SHIFT);
  
-	lockdep_assert_held_write(>mmu_lock);

+   kvm_lockdep_assert_mmu_lock_held(kvm, shared);
  
  	if (!refcount_dec_and_test(>tdp_mmu_root_count))

return;
@@ -81,7 +92,7 @@ void kvm_tdp_mmu_put_root(struct kvm *kvm, struct 
kvm_mmu_page *root)
list_del_rcu(>link);
spin_unlock(>arch.tdp_mmu_pages_lock);
  
-	zap_gfn_range(kvm, root, 0, max_gfn, false, false);

+   zap_gfn_range(kvm, root, 0, max_gfn, false, false, shared);
  
  	call_rcu(>rcu_head, tdp_mmu_free_sp_rcu_callback);


Instead of patch 13, would it make sense to delay the zap_gfn_range and 
call_rcu to a work item (either unconditionally, or only if 
shared==false)?  Then the zap_gfn_range would be able to yield and take 
the mmu_lock for read, similar to kvm_tdp_mmu_zap_invalidated_roots.


If done unconditionally, this would also allow removing the "shared" 
argument to kvm_tdp_mmu_put_root, tdp_mmu_next_root and 
for_each_tdp_mmu_root_yield_safe, so I would place that change before 
this patch.


Paolo

Re: [PATCH v3 00/10] fsdax,xfs: Add reflink support for fsdax

[Christoph Hellwig]

Shiyang, Dan:

given that the whole reflink+dax thing is going to take a while and thus
not going to happen for this merge window, what about queueing up the
cleanup patches 1,2 and 3 so that we can reduce the patch load a little?

[PATCH] drm/i915: Fix invalid access to ACPI _DSM objects

[Takashi Iwai]

intel_dsm_platform_mux_info() tries to parse the ACPI package data
from _DSM for the debug information, but it assumes the fixed format
without checking what values are stored in the elements actually.
When an unexpected value is returned from BIOS, it may lead to GPF or
NULL dereference, as reported recently.

Add the checks of the contents in the returned values and skip the
values for invalid cases.

BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
Cc: 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/display/intel_acpi.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e21fb14d5e07..492ebc0a8257 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -84,6 +84,11 @@ static void intel_dsm_platform_mux_info(acpi_handle dhandle)
return;
}
 
+   if (!pkg->package.count) {
+   DRM_DEBUG_DRIVER("no connection in _DSM\n");
+   return;
+   }
+
connector_count = >package.elements[0];
DRM_DEBUG_DRIVER("MUX info connectors: %lld\n",
  (unsigned long long)connector_count->integer.value);
@@ -91,6 +96,13 @@ static void intel_dsm_platform_mux_info(acpi_handle dhandle)
union acpi_object *obj = >package.elements[i];
union acpi_object *connector_id = >package.elements[0];
union acpi_object *info = >package.elements[1];
+
+   if (obj->type != ACPI_TYPE_PACKAGE || obj->package.count < 2 ||
+   info->type != ACPI_TYPE_BUFFER || info->buffer.length < 4) {
+   DRM_DEBUG_DRIVER("Invalid object for MUX #%d\n", i);
+   continue;
+   }
+
DRM_DEBUG_DRIVER("Connector id: 0x%016llx\n",
  (unsigned long long)connector_id->integer.value);
DRM_DEBUG_DRIVER("  port id: %s\n",
-- 
2.26.2

Re: [PATCH 1/2] mmc: block: Issue flush only if allowed

[Avri Altman]

>> @@ -1473,6 +1473,9 @@ static int mmc_blk_cqe_issue_flush(struct mmc_queue 
>> *mq, struct request *req)
>>  struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req);
>>  struct mmc_request *mrq = mmc_blk_cqe_prep_dcmd(mqrq, req);
>>  
>> +if (mmc_card_mmc(mq->card) && !mmc_flush_allowed(mq->card))
>> +return 0;

> Returning 0 means the flush was issued successfully. i.e. it is in
> flight.
>
> Instead, a call to blk_mq_end_request(req, BLK_STS_OK) is needed,
> and mmc_blk_mq_issue_rq() must be amended so that it will return
> MMC_REQ_DONE for this case.
Done.

Thanks,
Avri

Re: [PATCH v3 02/10] fsdax: Factor helper: dax_fault_actor()

[Christoph Hellwig]

> + if (!pmd)
> + return dax_load_hole(xas, mapping, , vmf);
> + else
> + return dax_pmd_load_hole(xas, vmf, iomap, );

> + if (pmd)
> + return vmf_insert_pfn_pmd(vmf, pfn, write);
> + if (write)
> + return vmf_insert_mixed_mkwrite(vmf->vma, vmf->address, pfn);
> + else
> + return vmf_insert_mixed(vmf->vma, vmf->address, pfn);
> +}

No need for else statements after returning.

Otherwise looks good:

Reviewed-by: Christoph Hellwig 

RE: [PATCH net-next 1/2] net: stmmac: enable 2.5Gbps link speed

[Voon, Weifeng]

> > +   /* 2.5G mode only support 2500baseT full duplex only */
> > +   if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
> > +   phylink_set(mac_supported, 2500baseT_Full);
> > +   phylink_set(mask, 10baseT_Half);
> > +   phylink_set(mask, 10baseT_Full);
> > +   phylink_set(mask, 100baseT_Half);
> > +   phylink_set(mask, 100baseT_Full);
> > +   phylink_set(mask, 1000baseT_Half);
> > +   phylink_set(mask, 1000baseT_Full);
> > +   phylink_set(mask, 1000baseKX_Full);
> 
> Why? This seems at odds to the comment above?

> What about 2500baseX_Full ?

The comments explain that the PCS<->PHY link is in 2500BASE-X
and why 10/100/1000 link speed is mutually exclusive with 2500.
But the connected external PHY are twisted pair cable which only
supports 2500baseT_full.

Weifeng

Re: [PATCH] ARM: hisi: use the correct HiSilicon copyright

[Wei Xu]

Hi Hao Fang,

On 2021/3/30 14:51, Hao Fang wrote:
> s/Hisilicon/HiSilicon/
> It should use capital S, according to
> https://www.hisilicon.com/en/terms-of-use.
> 
> Signed-off-by: Hao Fang 

Thanks!
Applied to the hisilicon arm32 SoC tree.

Best Regards,
Wei

> ---
>  arch/arm/mach-hisi/hisilicon.c | 4 ++--
>  arch/arm/mach-hisi/hotplug.c   | 2 +-
>  arch/arm/mach-hisi/platmcpm.c  | 2 +-
>  arch/arm/mach-hisi/platsmp.c   | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
> index 07ea28b..b8d14b3 100644
> --- a/arch/arm/mach-hisi/hisilicon.c
> +++ b/arch/arm/mach-hisi/hisilicon.c
> @@ -1,8 +1,8 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
> - * (Hisilicon's SoC based) flattened device tree enabled machine
> + * (HiSilicon's SoC based) flattened device tree enabled machine
>   *
> - * Copyright (c) 2012-2013 Hisilicon Ltd.
> + * Copyright (c) 2012-2013 HiSilicon Ltd.
>   * Copyright (c) 2012-2013 Linaro Ltd.
>   *
>   * Author: Haojian Zhuang 
> diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
> index 5c5f255..c517941 100644
> --- a/arch/arm/mach-hisi/hotplug.c
> +++ b/arch/arm/mach-hisi/hotplug.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * Copyright (c) 2013 Linaro Ltd.
> - * Copyright (c) 2013 Hisilicon Limited.
> + * Copyright (c) 2013 HiSilicon Limited.
>   */
>  
>  #include 
> diff --git a/arch/arm/mach-hisi/platmcpm.c b/arch/arm/mach-hisi/platmcpm.c
> index f155e32..96a4840 100644
> --- a/arch/arm/mach-hisi/platmcpm.c
> +++ b/arch/arm/mach-hisi/platmcpm.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * Copyright (c) 2013-2014 Linaro Ltd.
> - * Copyright (c) 2013-2014 Hisilicon Limited.
> + * Copyright (c) 2013-2014 HiSilicon Limited.
>   */
>  #include 
>  #include 
> diff --git a/arch/arm/mach-hisi/platsmp.c b/arch/arm/mach-hisi/platsmp.c
> index da7a09c..a56cc64 100644
> --- a/arch/arm/mach-hisi/platsmp.c
> +++ b/arch/arm/mach-hisi/platsmp.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * Copyright (c) 2013 Linaro Ltd.
> - * Copyright (c) 2013 Hisilicon Limited.
> + * Copyright (c) 2013 HiSilicon Limited.
>   * Based on arch/arm/mach-vexpress/platsmp.c, Copyright (C) 2002 ARM Ltd.
>   */
>  #include 
> 

[PATCH] media: Fix compilation error

[Bixuan Cui]

Fix the error:

drivers/staging/media/tegra-video/vi.c:1180:4:
error: implicit declaration of function 'host1x_syncpt_free' 
[-Werror,-Wimplicit-function-declaration]

Fixes: 3028a00c55bf ('gpu: host1x: Cleanup and refcounting for syncpoints')
Reported-by: Hulk Robot 
Signed-off-by: Bixuan Cui 
---
 drivers/staging/media/tegra-video/vi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/tegra-video/vi.c 
b/drivers/staging/media/tegra-video/vi.c
index 7e0cb5529b49..df5ca3596470 100644
--- a/drivers/staging/media/tegra-video/vi.c
+++ b/drivers/staging/media/tegra-video/vi.c
@@ -1177,7 +1177,7 @@ static int tegra_channel_host1x_syncpt_init(struct 
tegra_vi_channel *chan)
mw_sp = host1x_syncpt_request(>client, flags);
if (!mw_sp) {
dev_err(vi->dev, "failed to request memory ack 
syncpoint\n");
-   host1x_syncpt_free(fs_sp);
+   host1x_syncpt_put(fs_sp);
ret = -ENOMEM;
goto free_syncpts;
}
-- 
2.17.1