[PATCH] arm64: dts: meson: shorten audio card names for alsa compatibility

[Christian Hewitt]

This patch shortens all audio card model names by dropping the SoC prefix
(for conformity) and rewording those that are still longer than alsa's 15
character name limit [0] to avoid userspace config issues.

[0] 
https://github.com/torvalds/linux/blob/master/Documentation/sound/alsa-configuration.rst#common-parameters-for-top-sound-card-modules

Signed-off-by: Christian Hewitt 
---
I've been experimenting with alsa conf files to ensure alsa handles
multi-channel audio properly (else channels are messed up) and it's
been bugging me why an Odroid N2 showed surroundXX devices (defined in
a common alsa conf) while a VIM3 only showed sysdefault devices. The
eureka moment is discovering alsa enforces a 15-character limit on
model names, so G12B-ODROID-N2 (14) works while longer names like
G12B-KHADAS-VIM3 (16) truncate to e.g. G12B-KHADAS-VIM causing mismatch
with the strings alsa-lib matches conf(s) against.

VIM3:~ # cat /proc/asound/cards
 0 [G12BKHADASVIM3 ]: G12B-KHADAS-VIM - G12B-KHADAS-VIM3
  G12B-KHADAS-VIM3

I'm using aliases.conf with alsa-lib to map 20+ card names back to
two confs so I _could_ just map the truncated names, but this is not
obvious for users and other maintainers so the better solution is
shortening the names.

 arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts   | 2 +-
 arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts  | 2 +-
 arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts   | 2 +-
 arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts   | 2 +-
 arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi   | 2 +-
 arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts| 2 +-
 arch/arm64/boot/dts/amlogic/meson-gx-libretech-pc.dtsi  | 2 +-
 arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts| 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts  | 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts| 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts  | 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxl-s805x-libretech-ac.dts| 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts  | 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc-v2.dts | 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts| 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts   | 2 +-
 arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi  | 2 +-
 arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts | 2 +-
 arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts| 2 +-
 21 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts 
b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
index b00d0468c753..81269ccc2496 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
@@ -181,7 +181,7 @@
 
sound {
compatible = "amlogic,axg-sound-card";
-   model = "G12A-SEI510";
+   model = "SEI510";
audio-aux-devs = <&tdmout_a>, <&tdmout_b>,
 <&tdmin_a>, <&tdmin_b>;
audio-routing = "TDMOUT_A IN 0", "FRDDR_A OUT 0",
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts 
b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
index 463a72d6bb7c..579f3d02d613 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
@@ -150,7 +150,7 @@
 
sound {
compatible = "amlogic,axg-sound-card";
-   model = "G12A-X96-MAX";
+   model = "X96-MAX";
audio-aux-devs = <&tdmout_b>;
audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
"TDMOUT_B IN 1", "FRDDR_B OUT 1",
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts 
b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
index 0e5c500fb78f..0e331aa5a2d7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
@@ -44,7 +44,7 @@
 
sound {
compatible = "amlogic,axg-sound-card";
-   model = "G12B-GTKING-PRO";
+   model = "GTKING-PRO";
audio-aux-devs = <&tdmout_b>;
audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
"TDMOUT_B IN 1", "FRDDR_B OUT 1",
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts 
b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
index 10b87eb97b14..a7db84a500bb 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
@@ -28,7 +28,7 @@
 
 

Re: Generate the config file for kernel compilation non-interactively in script.

[Randy Dunlap]

On 12/31/20 8:51 PM, Hongyi Zhao wrote:
> Hi,
> 
> I want to build the realtime Linux for ROS 2 according to the
> guidelines here:
> .
> 
> For this purpose, I must enable the rt_preempt relative options in the
> kernel withe the following method interactively:
> 
> $ make menuconfig
> 
> and set the following
> 
> # Enable CONFIG_PREEMPT_RT
>  -> General Setup
>   -> Preemption Model (Fully Preemptible Kernel (Real-Time))
>(X) Fully Preemptible Kernel (Real-Time)
> 
> # Enable CONFIG_HIGH_RES_TIMERS
>  -> General setup
>   -> Timers subsystem
>[*] High Resolution Timer Support
> 
> # Enable CONFIG_NO_HZ_FULL
>  -> General setup
>   -> Timers subsystem
>-> Timer tick handling (Full dynticks system (tickless))
> (X) Full dynticks system (tickless)
> 
> # Set CONFIG_HZ_1000 (note: this is no longer in the General Setup
> menu, go back twice)
>  -> Processor type and features
>   -> Timer frequency (1000 HZ)
>(X) 1000 HZ
> 
> # Set CPU_FREQ_DEFAULT_GOV_PERFORMANCE [=y]
>  ->  Power management and ACPI options
>   -> CPU Frequency scaling
>-> CPU Frequency scaling (CPU_FREQ [=y])
> -> Default CPUFreq governor ( [=y])
>  (X) performance
> 
> But this is very inconvenient for doing the above job in script. Is
> there an alternative method to generate the above configurations for
> kernel compilation  non-interactively in script.

Hi,
You can use scripts/config in the kernel source tree.
Something like this (I don't have RT kernel sources):


scripts/config -e PREEMPT_RT
scripts/config -e HIGH_RES_TIMERS
scripts/config -e NO_HZ_FULL
scripts/config -e HZ_1000
scripts/config -e CPU_FREQ_DEFAULT_GOV_PERFORMANCE


Note that if any of those have other Kconfig dependencies, those Kconfig
symbols will also have to be enabled for this to work.

And then run 'make oldconfig' to update the kernel .config file.


HTH.
-- 
~Randy

[PATCH] platform/x86: ideapad-laptop: Add has_touchpad_switch

[Jiaxun Yang]

Newer ideapads (e.g.: Yoga 14s, 720S 14) comes with I2C HID
Touchpad and do not use EC to switch touchpad. Reading VPCCMD_R_TOUCHPAD
will return zero thus touchpad may be blocked. Writing VPCCMD_W_TOUCHPAD
may cause a spurious key press.

Add has_touchpad_switch to workaround these machines.

Signed-off-by: Jiaxun Yang 
Cc: sta...@vger.kernel.org # 5.4+
---
 drivers/platform/x86/ideapad-laptop.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c
index 7598cd46cf60..b6a4db37d0fc 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -92,6 +92,7 @@ struct ideapad_private {
struct dentry *debug;
unsigned long cfg;
bool has_hw_rfkill_switch;
+   bool has_touchpad_switch;
const char *fnesc_guid;
 };
 
@@ -535,7 +536,9 @@ static umode_t ideapad_is_visible(struct kobject *kobj,
} else if (attr == &dev_attr_fn_lock.attr) {
supported = acpi_has_method(priv->adev->handle, "HALS") &&
acpi_has_method(priv->adev->handle, "SALS");
-   } else
+   } else if (attr == &dev_attr_touchpad.attr)
+   supported = priv->has_touchpad_switch;
+   else
supported = true;
 
return supported ? attr->mode : 0;
@@ -867,6 +870,9 @@ static void ideapad_sync_touchpad_state(struct 
ideapad_private *priv)
 {
unsigned long value;
 
+   if (!priv->has_touchpad_switch)
+   return;
+
/* Without reading from EC touchpad LED doesn't switch state */
if (!read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, &value)) {
/* Some IdeaPads don't really turn off touchpad - they only
@@ -989,6 +995,12 @@ static int ideapad_acpi_add(struct platform_device *pdev)
priv->platform_device = pdev;
priv->has_hw_rfkill_switch = dmi_check_system(hw_rfkill_list);
 
+   /* Most ideapads with I2C HID don't use EC touchpad switch */
+   if (acpi_dev_present("PNP0C50", NULL, -1))
+   priv->has_touchpad_switch = false;
+   else
+   priv->has_touchpad_switch = true;
+
ret = ideapad_sysfs_init(priv);
if (ret)
return ret;
@@ -1006,6 +1018,10 @@ static int ideapad_acpi_add(struct platform_device *pdev)
if (!priv->has_hw_rfkill_switch)
write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1);
 
+   /* The same for Touchpad */
+   if (!priv->has_touchpad_switch)
+   write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1);
+
for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
if (test_bit(ideapad_rfk_data[i].cfgbit, &priv->cfg))
ideapad_register_rfkill(priv, i);
-- 
2.30.0

Re: [PATCH] openrisc: restart: Call common handlers before hanging

[Stafford Horne]

On Sun, Dec 27, 2020 at 07:44:46PM +1030, Joel Stanley wrote:
> Currently openrisc will print a message and then hang in an infinite
> loop when rebooting.
> 
> This patch adopts some code from ARM, which calls the common restart
> infrastructure and hangs after a small delay if the restart infra
> doesn't do anything.
> 
> Signed-off-by: Joel Stanley 
> ---
> Geert has a patch[1] for the litex soc code that adds a restart hander.
> Openrisc doesn't hit that code path, this patch fixes that.
> 
> [1] 
> https://github.com/geertu/linux/commit/7d09dc0797a8208a11eb7c0c2156c1a4c120180f
> 
>  arch/openrisc/kernel/process.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
> index 3c98728cce24..181448f74316 100644
> --- a/arch/openrisc/kernel/process.c
> +++ b/arch/openrisc/kernel/process.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -49,10 +50,16 @@
>   */
>  struct thread_info *current_thread_info_set[NR_CPUS] = { &init_thread_info, 
> };
>  
> -void machine_restart(void)
> +void machine_restart(char *cmd)
>  {
> - printk(KERN_INFO "*** MACHINE RESTART ***\n");
> - __asm__("l.nop 1");
Just a note, this nop with argument 1, is used by the simulators to shutdown.  I
am happy to get rid of this though.  The simulator should be simulating how real
hardware is shut down not doing these tricks.

> + do_kernel_restart(cmd);
As you mentioned this depends on Geert's patch.  Does he plan to submit it soon?

Geert is CCed.

> +
> + /* Give a grace period for failure to restart of 1s */
> + mdelay(1000);
> +
> + /* Whoops - the platform was unable to reboot. Tell the user! */
> + pr_emerg("Reboot failed -- System halted\n");
> + while (1);
>  }
>  
>  /*
> -- 
> 2.29.2

I am queing this for 5.11 anyway is it hurt's nothing without Geert's patch.

-Stafford

[PATCH v2 2/2] scsi: ufs: Protect PM ops and err_handler from user access through sysfs

[Can Guo]

User layer may access sysfs nodes when system PM ops or error handling
is running, which can cause various problems. Rename eh_sem to host_sem
and use it to protect PM ops and error handling from user layer intervene.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufs-sysfs.c | 104 ---
 drivers/scsi/ufs/ufshcd.c|  40 ++---
 drivers/scsi/ufs/ufshcd.h|  10 -
 3 files changed, 123 insertions(+), 31 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index 08e72b7..98a9447 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -154,18 +154,29 @@ static ssize_t auto_hibern8_show(struct device *dev,
 struct device_attribute *attr, char *buf)
 {
u32 ahit;
+   int ret;
struct ufs_hba *hba = dev_get_drvdata(dev);
 
if (!ufshcd_is_auto_hibern8_supported(hba))
return -EOPNOTSUPP;
 
+   down(&hba->host_sem);
+   if (!ufshcd_is_sysfs_allowed(hba)) {
+   ret = -EBUSY;
+   goto out;
+   }
+
pm_runtime_get_sync(hba->dev);
ufshcd_hold(hba, false);
ahit = ufshcd_readl(hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
ufshcd_release(hba);
pm_runtime_put_sync(hba->dev);
 
-   return scnprintf(buf, PAGE_SIZE, "%d\n", ufshcd_ahit_to_us(ahit));
+   ret = scnprintf(buf, PAGE_SIZE, "%d\n", ufshcd_ahit_to_us(ahit));
+
+out:
+   up(&hba->host_sem);
+   return ret;
 }
 
 static ssize_t auto_hibern8_store(struct device *dev,
@@ -174,6 +185,7 @@ static ssize_t auto_hibern8_store(struct device *dev,
 {
struct ufs_hba *hba = dev_get_drvdata(dev);
unsigned int timer;
+   int ret = 0;
 
if (!ufshcd_is_auto_hibern8_supported(hba))
return -EOPNOTSUPP;
@@ -184,9 +196,17 @@ static ssize_t auto_hibern8_store(struct device *dev,
if (timer > UFSHCI_AHIBERN8_MAX)
return -EINVAL;
 
+   down(&hba->host_sem);
+   if (!ufshcd_is_sysfs_allowed(hba)) {
+   ret = -EBUSY;
+   goto out;
+   }
+
ufshcd_auto_hibern8_update(hba, ufshcd_us_to_ahit(timer));
 
-   return count;
+out:
+   up(&hba->host_sem);
+   return ret ? ret : count;
 }
 
 static DEVICE_ATTR_RW(rpm_lvl);
@@ -225,12 +245,21 @@ static ssize_t ufs_sysfs_read_desc_param(struct ufs_hba 
*hba,
if (param_size > 8)
return -EINVAL;
 
+   down(&hba->host_sem);
+   if (!ufshcd_is_sysfs_allowed(hba)) {
+   ret = -EBUSY;
+   goto out;
+   }
+
pm_runtime_get_sync(hba->dev);
ret = ufshcd_read_desc_param(hba, desc_id, desc_index,
param_offset, desc_buf, param_size);
pm_runtime_put_sync(hba->dev);
-   if (ret)
-   return -EINVAL;
+   if (ret) {
+   ret = -EINVAL;
+   goto out;
+   }
+
switch (param_size) {
case 1:
ret = sprintf(sysfs_buf, "0x%02X\n", *desc_buf);
@@ -249,6 +278,8 @@ static ssize_t ufs_sysfs_read_desc_param(struct ufs_hba 
*hba,
break;
}
 
+out:
+   up(&hba->host_sem);
return ret;
 }
 
@@ -591,9 +622,16 @@ static ssize_t _name##_show(struct device *dev,
\
int desc_len = QUERY_DESC_MAX_SIZE; \
u8 *desc_buf;   \
\
+   down(&hba->host_sem);   \
+   if (!ufshcd_is_sysfs_allowed(hba)) {\
+   up(&hba->host_sem); \
+   return -EBUSY;  \
+   }   \
desc_buf = kzalloc(QUERY_DESC_MAX_SIZE, GFP_ATOMIC);\
-   if (!desc_buf)  \
-   return -ENOMEM; \
+   if (!desc_buf) {\
+   up(&hba->host_sem); \
+   return -ENOMEM; \
+   }   \
pm_runtime_get_sync(hba->dev);  \
ret = ufshcd_query_descriptor_retry(hba,\
UPIU_QUERY_OPCODE_READ_DESC, QUERY_DESC_IDN_DEVICE, \
@@ -613,6 +651,7 @@ static ssize_t _name##_show(struct device *dev, 
\
 out:   \
pm_runtime_put_sync(hba->dev);  \
kfree(desc_buf); 

[PATCH v2 1/2] scsi: ufs: Fix a possible NULL pointer issue

[Can Guo]

During system resume/suspend, hba could be NULL. In this case, do not touch
eh_sem.

Fixes: 88a92d6ae4fe ("scsi: ufs: Serialize eh_work with system PM events and 
async scan")

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e221add..34e2541 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8896,8 +8896,11 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
int ret = 0;
ktime_t start = ktime_get();
 
+   if (!hba)
+   return 0;
+
down(&hba->eh_sem);
-   if (!hba || !hba->is_powered)
+   if (!hba->is_powered)
return 0;
 
if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
@@ -8945,10 +8948,8 @@ int ufshcd_system_resume(struct ufs_hba *hba)
int ret = 0;
ktime_t start = ktime_get();
 
-   if (!hba) {
-   up(&hba->eh_sem);
+   if (!hba)
return -EINVAL;
-   }
 
if (!hba->is_powered || pm_runtime_suspended(hba->dev))
/*
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Generate the config file for kernel compilation non-interactively in script.

[Hongyi Zhao]

Hi,

I want to build the realtime Linux for ROS 2 according to the
guidelines here:
.

For this purpose, I must enable the rt_preempt relative options in the
kernel withe the following method interactively:

$ make menuconfig

and set the following

# Enable CONFIG_PREEMPT_RT
 -> General Setup
  -> Preemption Model (Fully Preemptible Kernel (Real-Time))
   (X) Fully Preemptible Kernel (Real-Time)

# Enable CONFIG_HIGH_RES_TIMERS
 -> General setup
  -> Timers subsystem
   [*] High Resolution Timer Support

# Enable CONFIG_NO_HZ_FULL
 -> General setup
  -> Timers subsystem
   -> Timer tick handling (Full dynticks system (tickless))
(X) Full dynticks system (tickless)

# Set CONFIG_HZ_1000 (note: this is no longer in the General Setup
menu, go back twice)
 -> Processor type and features
  -> Timer frequency (1000 HZ)
   (X) 1000 HZ

# Set CPU_FREQ_DEFAULT_GOV_PERFORMANCE [=y]
 ->  Power management and ACPI options
  -> CPU Frequency scaling
   -> CPU Frequency scaling (CPU_FREQ [=y])
-> Default CPUFreq governor ( [=y])
 (X) performance

But this is very inconvenient for doing the above job in script. Is
there an alternative method to generate the above configurations for
kernel compilation  non-interactively in script.

BR,
-- 
Assoc. Prof. Hongyi Zhao 
Theory and Simulation of Materials
Hebei Polytechnic University of Science and Technology engineering
NO. 552 North Gangtie Road, Xingtai, China

[PATCH v2] fs/dax: include to fix build error on ARC

[Randy Dunlap]

fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.

Provide copy_user_page() in  (beside copy_page()) and
add  to fs/dax.c to fix the build error.

../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; 
did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration]

Fixes: cccbce671582 ("filesystem-dax: convert to dax_direct_access()")
Reported-by: kernel test robot 
Signed-off-by: Randy Dunlap 
Cc: Vineet Gupta 
Cc: linux-snps-...@lists.infradead.org
Cc: Dan Williams 
Acked-by: Vineet Gupta 
Cc: Andrew Morton 
Cc: Matthew Wilcox 
Cc: Jan Kara 
Cc: linux-fsde...@vger.kernel.org
Cc: linux-nvd...@lists.01.org
---
v2: rebase, add more Cc:

 arch/arc/include/asm/page.h |1 +
 fs/dax.c|1 +
 2 files changed, 2 insertions(+)

--- lnx-511-rc1.orig/fs/dax.c
+++ lnx-511-rc1/fs/dax.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define CREATE_TRACE_POINTS
--- lnx-511-rc1.orig/arch/arc/include/asm/page.h
+++ lnx-511-rc1/arch/arc/include/asm/page.h
@@ -10,6 +10,7 @@
 #ifndef __ASSEMBLY__
 
 #define clear_page(paddr)  memset((paddr), 0, PAGE_SIZE)
+#define copy_user_page(to, from, vaddr, pg)copy_page(to, from)
 #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE)
 
 struct vm_area_struct;

[PATCH RESEND] ia64: remove duplicate entries in generic_defconfig

[Randy Dunlap]

Fix ia64 generic_defconfig duplicate entries, as warned by:

  + arch/ia64/configs/generic_defconfig: warning: override: reassigning to 
symbol ATA:  => 58
  + arch/ia64/configs/generic_defconfig: warning: override: reassigning to 
symbol ATA_PIIX:  => 59

These 2 symbols still have the same value as in the removed lines.

Fixes: c331649e6371 ("ia64: Use libata instead of the legacy ide driver in 
defconfigs")
Reported-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Andrew Morton 
Cc: Christoph Hellwig 
Cc: Tony Luck 
Cc: linux-i...@vger.kernel.org
Reviewed-by: Christoph Hellwig 
#Cc: Fenghua Yu 
---
 arch/ia64/configs/generic_defconfig |2 --
 1 file changed, 2 deletions(-)

--- lnx-511-rc1.orig/arch/ia64/configs/generic_defconfig
+++ lnx-511-rc1/arch/ia64/configs/generic_defconfig
@@ -55,8 +55,6 @@ CONFIG_CHR_DEV_SG=m
 CONFIG_SCSI_FC_ATTRS=y
 CONFIG_SCSI_SYM53C8XX_2=y
 CONFIG_SCSI_QLOGIC_1280=y
-CONFIG_ATA=y
-CONFIG_ATA_PIIX=y
 CONFIG_SATA_VITESSE=y
 CONFIG_MD=y
 CONFIG_BLK_DEV_MD=m

[PATCH v2] Documentation/admin-guide: kernel-parameters: hyphenate comma-separated

[Randy Dunlap]

Hyphenate "comma separated" when it is used as a compound adjective.
hyphenated.

Signed-off-by: Randy Dunlap 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
v2: rebase & resend

 Documentation/admin-guide/kernel-parameters.txt |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- lnx-511-rc1.orig/Documentation/admin-guide/kernel-parameters.txt
+++ lnx-511-rc1/Documentation/admin-guide/kernel-parameters.txt
@@ -1385,7 +1385,7 @@
 
ftrace_filter=[function-list]
[FTRACE] Limit the functions traced by the function
-   tracer at boot up. function-list is a comma separated
+   tracer at boot up. function-list is a comma-separated
list of functions. This list can be changed at run
time by the set_ftrace_filter file in the debugfs
tracing directory.
@@ -1399,13 +1399,13 @@
ftrace_graph_filter=[function-list]
[FTRACE] Limit the top level callers functions traced
by the function graph tracer at boot up.
-   function-list is a comma separated list of functions
+   function-list is a comma-separated list of functions
that can be changed at run time by the
set_graph_function file in the debugfs tracing 
directory.
 
ftrace_graph_notrace=[function-list]
[FTRACE] Do not trace from the functions specified in
-   function-list.  This list is a comma separated list of
+   function-list.  This list is a comma-separated list of
functions that can be changed at run time by the
set_graph_notrace file in the debugfs tracing directory.
 
@@ -2421,7 +2421,7 @@
when set.
Format: 
 
-   libata.force=   [LIBATA] Force configurations.  The format is comma
+   libata.force=   [LIBATA] Force configurations.  The format is comma-
separated list of "[ID:]VAL" where ID is
PORT[.DEVICE].  PORT and DEVICE are decimal numbers
matching port, link or device.  Basically, it matches
@@ -5145,7 +5145,7 @@
 
stacktrace_filter=[function-list]
[FTRACE] Limit the functions that the stack tracer
-   will trace at boot up. function-list is a comma 
separated
+   will trace at boot up. function-list is a 
comma-separated
list of functions. This list can be changed at run
time by the stack_trace_filter file in the debugfs
tracing directory. Note, this enables stack tracing
@@ -5348,7 +5348,7 @@
trace_event=[event-list]
[FTRACE] Set and start specified trace events in order
to facilitate early boot debugging. The event-list is a
-   comma separated list of trace events to enable. See
+   comma-separated list of trace events to enable. See
also Documentation/trace/events.rst
 
trace_options=[option-list]

[PATCH] [v2]net:ppp: remove disc_data_lock in ppp line discipline

[Gao Yan]

In tty layer, it provides tty->ldisc_sem to protect all tty_ldisc_ops
including ppp_sync_ldisc. So I think tty->ldisc_sem can also
protect tty->disc_data, and the disc_data_lock is not necessary.

Signed-off-by: Gao Yan 
---
 drivers/net/ppp/ppp_async.c   | 11 ++-
 drivers/net/ppp/ppp_synctty.c | 12 ++--
 2 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ppp/ppp_async.c b/drivers/net/ppp/ppp_async.c
index 29a0917a8..20b50facd 100644
--- a/drivers/net/ppp/ppp_async.c
+++ b/drivers/net/ppp/ppp_async.c
@@ -127,17 +127,13 @@ static const struct ppp_channel_ops async_ops = {
  * FIXME: this is no longer true. The _close path for the ldisc is
  * now guaranteed to be sane.
  */
-static DEFINE_RWLOCK(disc_data_lock);
 
 static struct asyncppp *ap_get(struct tty_struct *tty)
 {
-   struct asyncppp *ap;
+   struct asyncppp *ap = tty->disc_data;
 
-   read_lock(&disc_data_lock);
-   ap = tty->disc_data;
if (ap != NULL)
refcount_inc(&ap->refcnt);
-   read_unlock(&disc_data_lock);
return ap;
 }
 
@@ -214,12 +210,9 @@ ppp_asynctty_open(struct tty_struct *tty)
 static void
 ppp_asynctty_close(struct tty_struct *tty)
 {
-   struct asyncppp *ap;
+   struct asyncppp *ap = tty->disc_data;
 
-   write_lock_irq(&disc_data_lock);
-   ap = tty->disc_data;
tty->disc_data = NULL;
-   write_unlock_irq(&disc_data_lock);
if (!ap)
return;
 
diff --git a/drivers/net/ppp/ppp_synctty.c b/drivers/net/ppp/ppp_synctty.c
index 0f338752c..53fb68e29 100644
--- a/drivers/net/ppp/ppp_synctty.c
+++ b/drivers/net/ppp/ppp_synctty.c
@@ -129,17 +129,12 @@ ppp_print_buffer (const char *name, const __u8 *buf, int 
count)
  *
  * FIXME: Fixed in tty_io nowadays.
  */
-static DEFINE_RWLOCK(disc_data_lock);
-
 static struct syncppp *sp_get(struct tty_struct *tty)
 {
-   struct syncppp *ap;
+   struct syncppp *ap = tty->disc_data;
 
-   read_lock(&disc_data_lock);
-   ap = tty->disc_data;
if (ap != NULL)
refcount_inc(&ap->refcnt);
-   read_unlock(&disc_data_lock);
return ap;
 }
 
@@ -213,12 +208,9 @@ ppp_sync_open(struct tty_struct *tty)
 static void
 ppp_sync_close(struct tty_struct *tty)
 {
-   struct syncppp *ap;
+   struct syncppp *ap = tty->disc_data;
 
-   write_lock_irq(&disc_data_lock);
-   ap = tty->disc_data;
tty->disc_data = NULL;
-   write_unlock_irq(&disc_data_lock);
if (!ap)
return;
 
-- 
2.17.1

Re: [PATCH RFC] KVM: arm64: vgic: Decouple the check of the EnableLPIs bit from the ITS LPI translation

[Shenming Lu]

On 2020/12/31 20:22, Marc Zyngier wrote:
> On 2020-12-31 11:58, Shenming Lu wrote:
>> On 2020/12/31 16:57, Marc Zyngier wrote:
>>> Hi Shemming,
>>>
>>> On 2020-12-31 06:28, Shenming Lu wrote:
 When the EnableLPIs bit is set to 0, any ITS LPI requests in the
 Redistributor would be ignored. And this check is independent from
 the ITS LPI translation. So it might be better to move the check
 of the EnableLPIs bit out of the LPI resolving, and also add it
 to the path that uses the translation cache.
>>>
>>> But by doing that, you are moving the overhead of checking for
>>> EnableLPIs from the slow path (translation walk) to the fast
>>> path (cache hit), which seems counter-productive.
>>
>> Oh, I didn't notice the overhead of the checking, I thought it would
>> be negligible...
> 
> It probably doesn't show on a modern box, but some of the slower
> systems might see it. Overall, this is a design decision to keep
> the translation cache as simple and straightforward as possible:
> if anything affects the output of the cache, we invalidate it,
> and that's it.

Ok, get it.

> 
>>
>>>
 Besides it seems that
 by this the invalidating of the translation cache caused by the LPI
 disabling is unnecessary.

 Not sure if I have missed something... Thanks.
>>>
>>> I am certainly missing the purpose of this patch.
>>>
>>> The effect of EnableLPIs being zero is to drop the result of any
>>> translation (a new pending bit) on the floor. Given that, it is
>>> immaterial whether this causes a new translation or hits in the
>>> cache, as the result is still to not pend a new interrupt.
>>>
>>> I get the feeling that you are trying to optimise for the unusual
>>> case where EnableLPIs is 0 *and* you have a screaming device
>>> injecting tons of interrupt. If that is the case, I don't think
>>> this is worth it.
>>
>> In fact, I just found (imagining) that if the EnableLPIs bit is 0,
>> the kvm_vgic_v4_set_forwarding() would fail when performing the LPI
>> translation, but indeed we don't try to pend any interrupts there...
>>
>> By the way, it seems that the LPI disabling would not affect the
>> injection of VLPIs...
> 
> Yes, good point. We could unmap the VPE from all ITS, which would result
> in all translations to be discarded, but this has the really bad side
> effect of *also* preventing the delivery of vSGIs, which isn't what
> you'd expect.
> 
> Overall, I don't think there is a good way to support this, and maybe
> we should just prevent EnableLPIs to be turned off when using direct
> injection. After all, the architecture does allow that for GICv3
> implementations, which is what we emulate.

Agreed, if there is no good way, we could just make the EnableLPIs clearing
unsupported...

Thanks(Happy 2021),
Shenming

> 
> Thanks,
> 
>     M.

[PATCH] mm: memcg: add swapcache stat for memcg v2

[Shakeel Butt]

This patch adds swapcache stat for the cgroup v2. The swapcache
represents the memory that is accounted against both the memory and the
swap limit of the cgroup. The main motivation behind exposing the
swapcache stat is for enabling users to gracefully migrate from cgroup
v1's memsw counter to cgroup v2's memory and swap counters.

Cgroup v1's memsw limit allows users to limit the memory+swap usage of a
workload but without control on the exact proportion of memory and swap.
Cgroup v2 provides separate limits for memory and swap which enables
more control on the exact usage of memory and swap individually for the
workload.

With some little subtleties, the v1's memsw limit can be switched with
the sum of the v2's memory and swap limits. However the alternative for
memsw usage is not yet available in cgroup v2. Exposing per-cgroup
swapcache stat enables that alternative. Adding the memory usage and
swap usage and subtracting the swapcache will approximate the memsw
usage. This will help in the transparent migration of the workloads
depending on memsw usage and limit to v2' memory and swap counters.

Signed-off-by: Shakeel Butt 
---
 Documentation/admin-guide/cgroup-v2.rst |  4 
 drivers/base/node.c |  6 ++
 include/linux/mmzone.h  |  3 +++
 include/linux/swap.h|  6 +-
 mm/memcontrol.c |  1 +
 mm/migrate.c|  4 
 mm/swap_state.c | 28 ++---
 mm/vmstat.c |  3 +++
 8 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/Documentation/admin-guide/cgroup-v2.rst 
b/Documentation/admin-guide/cgroup-v2.rst
index 63521cd36ce5..5923e2c3e0e5 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1299,6 +1299,10 @@ PAGE_SIZE multiple when read back.
Amount of cached filesystem data that was modified and
is currently being written back to disk
 
+ swapcached
+   Amount of swap cached in memory. The swapcache is accounted
+   against both memory and swap usage.
+
  anon_thp
Amount of memory used in anonymous mappings backed by
transparent hugepages
diff --git a/drivers/base/node.c b/drivers/base/node.c
index d02d86aec19f..f449dbb2c746 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -372,14 +372,19 @@ static ssize_t node_read_meminfo(struct device *dev,
struct pglist_data *pgdat = NODE_DATA(nid);
struct sysinfo i;
unsigned long sreclaimable, sunreclaimable;
+   unsigned long swapcached = 0;
 
si_meminfo_node(&i, nid);
sreclaimable = node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B);
sunreclaimable = node_page_state_pages(pgdat, NR_SLAB_UNRECLAIMABLE_B);
+#ifdef CONFIG_SWAP
+   swapcached = node_page_state_pages(pgdat, NR_SWAPCACHE);
+#endif
len = sysfs_emit_at(buf, len,
"Node %d MemTotal:   %8lu kB\n"
"Node %d MemFree:%8lu kB\n"
"Node %d MemUsed:%8lu kB\n"
+   "Node %d SwapCached: %8lu kB\n"
"Node %d Active: %8lu kB\n"
"Node %d Inactive:   %8lu kB\n"
"Node %d Active(anon):   %8lu kB\n"
@@ -391,6 +396,7 @@ static ssize_t node_read_meminfo(struct device *dev,
nid, K(i.totalram),
nid, K(i.freeram),
nid, K(i.totalram - i.freeram),
+   nid, K(swapcached),
nid, K(node_page_state(pgdat, NR_ACTIVE_ANON) +
   node_page_state(pgdat, NR_ACTIVE_FILE)),
nid, K(node_page_state(pgdat, NR_INACTIVE_ANON) +
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 66d68e5d5a0f..fc99e9241846 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -206,6 +206,9 @@ enum node_stat_item {
NR_KERNEL_SCS_KB,   /* measured in KiB */
 #endif
NR_PAGETABLE,   /* used for pagetables */
+#ifdef CONFIG_SWAP
+   NR_SWAPCACHE,
+#endif
NR_VM_NODE_STAT_ITEMS
 };
 
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 5bba15ac5a2e..71166bc10d17 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -408,7 +408,11 @@ extern struct address_space *swapper_spaces[];
 #define swap_address_space(entry)  \
(&swapper_spaces[swp_type(entry)][swp_offset(entry) \
>> SWAP_ADDRESS_SPACE_SHIFT])
-extern unsigned long total_swapcache_pages(void);
+static inline unsigned long total_swapcache_pages(void)
+{
+   return global_node_page_state(NR_SWAPCACHE);
+}
+
 extern void show_swap_cache_info(void);
 ex

Re: checkpatch.pl: Bogus case of DT_SPLIT_BINDING_PATCH

[Joe Perches]

On Thu, 2020-12-31 at 23:04 +0100, Jonathan Neuschäfer wrote:
> Hi,
> 
> I've encountered a case where the DT_SPLIT_BINDING_PATCH warning was
> emitted even though I didn't change anything outside of Documentation/
> devicetree/bindings. I just converted a binding from plain text to YAML.

Rob?  Your code...

> Here's a transcript of checkpatch (from Linux 5.11-rc1)'s output:
> 
>   $ scripts/checkpatch.pl --strict 
> patches-wpcm/0001-dt-bindings-arm-Convert-nuvoton-npcm750-binding-to-Y.patch
>   WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
>   #31:
>   deleted file mode 100644
>   
> 
>   WARNING: DT binding docs and includes should be a separate patch. See: 
> Documentation/devicetree/bindings/submitting-patches.rst
>   
> 
>   WARNING: DT binding docs and includes should be a separate patch. See: 
> Documentation/devicetree/bindings/submitting-patches.rst
>   
> 
>   total: 0 errors, 3 warnings, 0 checks, 21 lines checked
>   
> 
>   NOTE: For some of the reported defects, checkpatch may be able to
> mechanically convert to the typical style using --fix or 
> --fix-inplace.
>   
> 
>   
> patches-wpcm/0001-dt-bindings-arm-Convert-nuvoton-npcm750-binding-to-Y.patch 
> has style problems, please review.
>   
> 
>   NOTE: If any of the errors are false positives, please report
> them to the maintainer, see CHECKPATCH in MAINTAINERS.
> 
> 
> I attached the patch, for reference.
> 
> 
> Best regards,
> Jonathan Neuschäfer

Re: [PATCH] net: remove disc_data_lock in ppp line discipline

[Xie He]

> In tty layer, it use tty->ldisc_sem to proect tty_ldisc_ops.
> So I think tty->ldisc_sem can also protect tty->disc_data;

It might help by CC'ing TTY people, so that we could get this reviewed by
people who are familiar with TTY code.

Greg Kroah-Hartman  (supporter:TTY LAYER)
Jiri Slaby  (supporter:TTY LAYER)

Thanks!

> For examlpe,
> When cpu A is running ppp_synctty_ioctl that hold the tty->ldisc_sem,
> at the same time  if cpu B calls ppp_synctty_close, it will wait until
> cpu A release tty->ldisc_sem. So I think it is unnecessary to have the
> disc_data_lock;
> 
> cpu A   cpu B
> tty_ioctl   tty_reopen
>  ->hold tty->ldisc_sem->hold tty->ldisc_sem(write), failed
>  ->ld->ops->ioctl ->wait...
>  ->release tty->ldisc_sem ->wait...OK,hold tty->ldisc_sem
> ->tty_ldisc_reinit
>   ->tty_ldisc_close
> ->ld->ops->close

IMHO an example might not be necessary. Examples are useful to show
incorrectness. But we cannot show correctness by examples because
examples are not exhaustive.

BTW, there're some typos:
"proect" -> "protect"
"examlpe" -> "example"
"that hold ..." -> "that holds ..."
"cpu A release ..." -> "cpu A releases ..."

>   * FIXME: this is no longer true. The _close path for the ldisc is
>   * now guaranteed to be sane.
>   */

>   *
>   * FIXME: Fixed in tty_io nowadays.
>   */

Since you are removing "disc_data_lock", please update (or remove) these
two comments. Thanks!

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

[Guenter Roeck]

On Thu, Dec 31, 2020 at 08:39:47PM +0800, Campion Kang wrote:
> This is one of sub-device driver for Advantech embedded controller
> AHC1EC0. This driver provides sysfs ABI for Advantech related
> applications to monitor the system status.
> 
> Signed-off-by: Campion Kang 
> ---
>  drivers/hwmon/Kconfig |  10 +

[ ... ]

> + lmsensor_data.hwmon_dev = 
> devm_hwmon_device_register_with_groups(&pdev->dev,
> + "ahc1ec0-hwmon", adv_ec_data, ahc1ec0_groups);

New drivers must use [devm_]hwmon_device_register_with_info() and will
otherwise not be accepted.

Guenter

Re: [RFC][PATCH] afs: Work around strnlen() oops with CONFIG_FORTIFIED_SOURCE=y

[Daniel Axtens]

Hi David,

> CONFIG_FORTIFIED_SOURCE=y now causes an oops in strnlen() from afs (see
> attached patch for an explanation).  Is replacing the use with memchr() the
> right approach?  Or should I be calling __real_strnlen() or whatever it's
> called?

You certainly shouldn't be calling __real_strnlen().

memchr() is probably the right answer if you want a small fix.

However, as Linus suggested, the 'right' answer is to re-engineer your
data structures so that the string operations you do don't overflow
their arrays.

Kind regards,
Daniel

>
> David
> ---
> From: David Howells 
>
> afs: Work around strnlen() oops with CONFIG_FORTIFIED_SOURCE=y
>
> AFS has a structured layout in its directory contents (AFS dirs are
> downloaded as files and parsed locally by the client for lookup/readdir).
> The slots in the directory are defined by union afs_xdr_dirent.  This,
> however, only directly allows a name of a length that will fit into that
> union.  To support a longer name, the next 1-8 contiguous entries are
> annexed to the first one and the name flows across these.
>
> afs_dir_iterate_block() uses strnlen(), limited to the space to the end of
> the page, to find out how long the name is.  This worked fine until
> 6a39e62abbaf.  With that commit, the compiler determines the size of the
> array and asserts that the string fits inside that array.  This is a
> problem for AFS because we *expect* it to overflow one or more arrays.
>
> A similar problem also occurs in afs_dir_scan_block() when a directory file
> is being locally edited to avoid the need to redownload it.  There strlen()
> was being used safely because each page has the last byte set to 0 when the
> file is downloaded and validated (in afs_dir_check_page()).
>
> Fix this by using memchr() instead and hoping no one changes that to check
> the object size.
>
> The issue can be triggered by something like:
>
> touch /afs/example.com/thisisaveryveryverylongname
>
> and it generates a report that looks like:
>
> detected buffer overflow in strnlen
> [ cut here ]
> kernel BUG at lib/string.c:1149!
> ...
> RIP: 0010:fortify_panic+0xf/0x11
> ...
> Call Trace:
>  afs_dir_iterate_block+0x12b/0x35b
>  afs_dir_iterate+0x14e/0x1ce
>  afs_do_lookup+0x131/0x417
>  afs_lookup+0x24f/0x344
>  lookup_open.isra.0+0x1bb/0x27d
>  open_last_lookups+0x166/0x237
>  path_openat+0xe0/0x159
>  do_filp_open+0x48/0xa4
>  ? kmem_cache_alloc+0xf5/0x16e
>  ? __clear_close_on_exec+0x13/0x22
>  ? _raw_spin_unlock+0xa/0xb
>  do_sys_openat2+0x72/0xde
>  do_sys_open+0x3b/0x58
>  do_syscall_64+0x2d/0x3a
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Fixes: 6a39e62abbaf ("lib: string.h: detect intra-object overflow in 
> fortified string functions")
> Reported-by: Marc Dionne 
> Signed-off-by: David Howells 
> cc: Daniel Axtens 
>
> diff --git a/fs/afs/dir.c b/fs/afs/dir.c
> index 9068d5578a26..4fafb4e4d0df 100644
> --- a/fs/afs/dir.c
> +++ b/fs/afs/dir.c
> @@ -350,6 +350,7 @@ static int afs_dir_iterate_block(struct afs_vnode *dvnode,
>unsigned blkoff)
>  {
>   union afs_xdr_dirent *dire;
> + const u8 *p;
>   unsigned offset, next, curr;
>   size_t nlen;
>   int tmp;
> @@ -378,9 +379,15 @@ static int afs_dir_iterate_block(struct afs_vnode 
> *dvnode,
>  
>   /* got a valid entry */
>   dire = &block->dirents[offset];
> - nlen = strnlen(dire->u.name,
> -sizeof(*block) -
> -offset * sizeof(union afs_xdr_dirent));
> + p = memchr(dire->u.name, 0,
> +sizeof(*block) - offset * sizeof(union 
> afs_xdr_dirent));
> + if (!p) {
> + _debug("ENT[%zu.%u]: %u unterminated dirent name",
> +blkoff / sizeof(union afs_xdr_dir_block),
> +offset, next);
> + return afs_bad(dvnode, afs_file_error_dir_over_end);
> + }
> + nlen = p - dire->u.name;
>  
>   _debug("ENT[%zu.%u]: %s %zu \"%s\"",
>  blkoff / sizeof(union afs_xdr_dir_block), offset,
> diff --git a/fs/afs/dir_edit.c b/fs/afs/dir_edit.c
> index 2ffe09abae7f..5ee4e992ed8f 100644
> --- a/fs/afs/dir_edit.c
> +++ b/fs/afs/dir_edit.c
> @@ -111,6 +111,8 @@ static int afs_dir_scan_block(union afs_xdr_dir_block 
> *block, struct qstr *name,
> unsigned int blocknum)
>  {
>   union afs_xdr_dirent *de;
> + const u8 *p;
> + unsigned long offset;
>   u64 bitmap;
>   int d, len, n;
>  
> @@ -135,7 +137,11 @@ static int afs_dir_scan_block(union afs_xdr_dir_block 
> *block, struct qstr *name,
>   continue;
>  
>   /* The block was NUL-terminated by 

WARNING: suspicious RCU usage in xt_obj_to_user

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:f838f8d2 mfd: ab8500-debugfs: Remove extraneous seq_putc
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17074c4750
kernel config:  https://syzkaller.appspot.com/x/.config?x=7a43a64bad3fdb39
dashboard link: https://syzkaller.appspot.com/bug?extid=00399fa030c641ffc5ae
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+00399fa030c641ffc...@syzkaller.appspotmail.com

=
WARNING: suspicious RCU usage
5.10.0-syzkaller #0 Not tainted
-
kernel/sched/core.c:7877 Illegal context switch in RCU-bh read-side critical 
section!

other info that might help us debug this:


rcu_scheduler_active = 2, debug_locks = 0
1 lock held by syz-executor.0/9704:
 #0: 888013794458 (&xt[i].mutex){+.+.}-{3:3}, at: 
xt_find_table_lock+0x41/0x540 net/netfilter/x_tables.c:1206

stack backtrace:
CPU: 0 PID: 9704 Comm: syz-executor.0 Not tainted 5.10.0-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:120
 ___might_sleep+0x229/0x2c0 kernel/sched/core.c:7877
 __might_fault+0x6e/0x180 mm/memory.c:5014
 xt_obj_to_user+0x31/0x110 net/netfilter/x_tables.c:277
 xt_target_to_user+0xa8/0x200 net/netfilter/x_tables.c:323
 copy_entries_to_user net/ipv4/netfilter/arp_tables.c:705 [inline]
 get_entries net/ipv4/netfilter/arp_tables.c:866 [inline]
 do_arpt_get_ctl+0x733/0x8f0 net/ipv4/netfilter/arp_tables.c:1450
 nf_getsockopt+0x72/0xd0 net/netfilter/nf_sockopt.c:116
 ip_getsockopt net/ipv4/ip_sockglue.c:1777 [inline]
 ip_getsockopt+0x164/0x1c0 net/ipv4/ip_sockglue.c:1756
 tcp_getsockopt+0x86/0xd0 net/ipv4/tcp.c:4141
 __sys_getsockopt+0x219/0x4c0 net/socket.c:2156
 __do_sys_getsockopt net/socket.c:2171 [inline]
 __se_sys_getsockopt net/socket.c:2168 [inline]
 __x64_sys_getsockopt+0xba/0x150 net/socket.c:2168
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ef5a
Code: b8 34 01 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 cd 9f fb ff c3 66 2e 0f 1f 
84 00 00 00 00 00 66 90 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 
aa 9f fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:7ffcf91ed728 EFLAGS: 0212 ORIG_RAX: 0037
RAX: ffda RBX: 7ffcf91ed790 RCX: 0045ef5a
RDX: 0061 RSI:  RDI: 0003
RBP: 0003 R08: 7ffcf91ed73c R09: 000a
R10: 7ffcf91ed790 R11: 0212 R12: 7ffcf91ed73c
R13:  R14: 0032 R15: 0003354d


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [PATCH] [sh] fix trivial misannotations

[John Paul Adrian Glaubitz]

On 1/1/21 12:23 AM, Al Viro wrote:
>   Trivial misannotations in
> * get_user() (__gu_addr is a userland pointer there)
> * ip_fast_csum() (sum is __wsum, not unsigned int)
> * csum_and_copy_to_user() (destination is void *, not const void * - mea 
> culpa)
> * __clear_user() (to is a userland pointer)
> * several places in kernel/traps_32.c (regs->pc is a userland pointer when 
> regs is a
> userland pt_regs)
> * math-emu/math.c: READ() and WRITE() casts of address should be to userland 
> pointer.
> 
> No changes in code generation and those take care of the majority of noise 
> from sparse
> on sh builds.
> 
> Signed-off-by: Al Viro 
> ---
> diff --git a/arch/sh/include/asm/checksum_32.h 
> b/arch/sh/include/asm/checksum_32.h
> index 1a391e3a7659..a6501b856f3e 100644
> --- a/arch/sh/include/asm/checksum_32.h
> +++ b/arch/sh/include/asm/checksum_32.h
> @@ -84,7 +84,8 @@ static inline __sum16 csum_fold(__wsum sum)
>   */
>  static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl)
>  {
> - unsigned int sum, __dummy0, __dummy1;
> + __wsum sum;
> + unsigned int __dummy0, __dummy1;
>  
>   __asm__ __volatile__(
>   "mov.l  @%1+, %0\n\t"
> @@ -197,6 +198,6 @@ static inline __wsum csum_and_copy_to_user(const void 
> *src,
>  {
>   if (!access_ok(dst, len))
>   return 0;
> - return csum_partial_copy_generic((__force const void *)src, dst, len);
> + return csum_partial_copy_generic(src, (__force void *)dst, len);
>  }
>  #endif /* __ASM_SH_CHECKSUM_H */
> diff --git a/arch/sh/include/asm/uaccess.h b/arch/sh/include/asm/uaccess.h
> index 73f3b48d4a34..8867bb04b00e 100644
> --- a/arch/sh/include/asm/uaccess.h
> +++ b/arch/sh/include/asm/uaccess.h
> @@ -68,7 +68,7 @@ struct __large_struct { unsigned long buf[100]; };
>  ({   \
>   long __gu_err = -EFAULT;\
>   unsigned long __gu_val = 0; \
> - const __typeof__(*(ptr)) *__gu_addr = (ptr);\
> + const __typeof__(*(ptr)) __user *__gu_addr = (ptr); 
> \
>   if (likely(access_ok(__gu_addr, (size   \
>   __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
>   (x) = (__force __typeof__(*(ptr)))__gu_val; \
> @@ -124,7 +124,7 @@ raw_copy_to_user(void __user *to, const void *from, 
> unsigned long n)
>   * Clear the area and return remaining number of bytes
>   * (on failure.  Usually it's 0.)
>   */
> -__kernel_size_t __clear_user(void *addr, __kernel_size_t size);
> +__kernel_size_t __clear_user(void __user *addr, __kernel_size_t size);
>  
>  #define clear_user(addr,n)   \
>  ({   \
> diff --git a/arch/sh/kernel/traps_32.c b/arch/sh/kernel/traps_32.c
> index b62ad0ba2395..b3c715bc254b 100644
> --- a/arch/sh/kernel/traps_32.c
> +++ b/arch/sh/kernel/traps_32.c
> @@ -490,7 +490,7 @@ asmlinkage void do_address_error(struct pt_regs *regs,
>   inc_unaligned_user_access();
>  
>   oldfs = force_uaccess_begin();
> - if (copy_from_user(&instruction, (insn_size_t *)(regs->pc & ~1),
> + if (copy_from_user(&instruction, (insn_size_t __user 
> *)(regs->pc & ~1),
>  sizeof(instruction))) {
>   force_uaccess_end(oldfs);
>   goto uspace_segv;
> @@ -614,7 +614,7 @@ asmlinkage void do_reserved_inst(void)
>   unsigned short inst = 0;
>   int err;
>  
> - get_user(inst, (unsigned short*)regs->pc);
> + get_user(inst, (unsigned short __user *)regs->pc);
>  
>   err = do_fpu_inst(inst, regs);
>   if (!err) {
> @@ -699,9 +699,9 @@ asmlinkage void do_illegal_slot_inst(void)
>   return;
>  
>  #ifdef CONFIG_SH_FPU_EMU
> - get_user(inst, (unsigned short *)regs->pc + 1);
> + get_user(inst, (unsigned short __user *)regs->pc + 1);
>   if (!do_fpu_inst(inst, regs)) {
> - get_user(inst, (unsigned short *)regs->pc);
> + get_user(inst, (unsigned short __user *)regs->pc);
>   if (!emulate_branch(inst, regs))
>   return;
>   /* fault in branch.*/
> diff --git a/arch/sh/math-emu/math.c b/arch/sh/math-emu/math.c
> index e8be0eca0444..3495a48b7713 100644
> --- a/arch/sh/math-emu/math.c
> +++ b/arch/sh/math-emu/math.c
> @@ -51,8 +51,8 @@
>  #define Rn   (regs->regs[n])
>  #define Rm   (regs->regs[m])
>  
> -#define WRITE(d,a)   ({if(put_user(d, (typeof (d)*)a)) return -EFAULT;})
> -#define READ(d,a)({if(get_user(d, (typeof (d)*)a)) return -EFAULT;})
> +#define WRITE(d,a)   ({if(put_user(d, (typeof (d) __user *)a)) return 
> -EFAULT;})
> +#define READ(d,a)({if(get_user(d, (typeof (d) __user *)a)) return 
> -EFAULT;})
>  
>  #define PACK_S(r,f)  FP_PACK

fs/cifs/inode.c:2882:1: warning: stack frame size of 2096 bytes in function 'cifs_setattr'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f6e1ea19649216156576aeafa784e3b4cee45549
commit: c6cc4c5a72505a0ecefc9b413f16bec512f38078 cifs: handle -EINTR in 
cifs_setattr
date:   3 months ago
config: powerpc-randconfig-r036-20210101 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
6b316febb4388764789677f81f03aff373ec35b2)
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 powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c6cc4c5a72505a0ecefc9b413f16bec512f38078
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout c6cc4c5a72505a0ecefc9b413f16bec512f38078
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

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

All warnings (new ones prefixed by >>):

   In file included from fs/cifs/inode.c:24:
   In file included from include/linux/pagemap.h:11:
   In file included from include/linux/highmem.h:10:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:604:
   arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer 
arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c),
   ^~~
   arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
   __do_##name al; \
   ^~
   :116:1: note: expanded from here
   __do_insw
   ^
   arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw'
   #define __do_insw(p, b, n)  readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
  ~^
   In file included from fs/cifs/inode.c:24:
   In file included from include/linux/pagemap.h:11:
   In file included from include/linux/highmem.h:10:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:604:
   arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer 
arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c),
   ^~~
   arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
   __do_##name al; \
   ^~
   :118:1: note: expanded from here
   __do_insl
   ^
   arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl'
   #define __do_insl(p, b, n)  readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
  ~^
   In file included from fs/cifs/inode.c:24:
   In file included from include/linux/pagemap.h:11:
   In file included from include/linux/highmem.h:10:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:604:
   arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer 
arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c),
   ^~
   arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
   __do_##name al; \
   ^~
   :120:1: note: expanded from here
   __do_outsb
   ^
   arch/powerpc/include/asm/io.h:544:58: note: expanded from macro '__do_outsb'
   #define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
   ~^
   In file included from fs/cifs/inode.c:24:
   In file included from include/linux/pagemap.h:11:
   In file included f

Re: [PATCH v5 2/6] dt: bindings: add mt7621-clk device tree binding documentation

[Sergio Paracuellos]

Hi Rob,

Thanks for the review.

On Thu, Dec 31, 2020 at 11:38 PM Rob Herring  wrote:
>
> On Sun, Dec 20, 2020 at 10:37:20AM +0100, Sergio Paracuellos wrote:
> > Adds device tree binding documentation for clocks in the
> > MT7621 SOC.
> >
> > Signed-off-by: Sergio Paracuellos 
> > ---
> >  .../bindings/clock/mediatek,mt7621-clk.yaml   | 52 +++
> >  1 file changed, 52 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml 
> > b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> > new file mode 100644
> > index ..f58d01bdc82c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> > @@ -0,0 +1,52 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/mediatek,mt7621-clk.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MT7621 Clock Device Tree Bindings
> > +
> > +maintainers:
> > +  - Sergio Paracuellos 
> > +
> > +description: |
> > +  The MT7621 has a PLL controller from where the cpu clock is provided
> > +  as well as derived clocks for the bus and the peripherals. It also
> > +  can gate SoC device clocks.
> > +
> > +  Each clock is assigned an identifier and client nodes use this identifier
> > +  to specify the clock which they consume.
> > +
> > +  All these identifiers could be found in:
> > +  [1]: .
> > +
> > +properties:
> > +  compatible:
> > +const: mediatek,mt7621-clk
> > +
> > +  "#clock-cells":
> > +description:
> > +  The first cell indicates the clock number, see [1] for available
> > +  clocks.
> > +const: 1
> > +
> > +  clock-output-names:
> > +maxItems: 8
> > +
> > +required:
> > +  - compatible
> > +  - '#clock-cells'
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +#include 
> > +
> > +pll {
> > +  compatible = "mediatek,mt7621-clk";
> > +  #clock-cells = <1>;
> > +  clock-output-names = "xtal", "cpu", "bus",
> > +   "50m", "125m", "150m",
> > +   "250m", "270m";
>
> How do you access this h/w. There's nothing defined like 'reg' or
> a parent node or...

Through read write operations defined in
"asm/mach-ralink/ralink_regs.h. Please, see my explanation below.

>
> The suggestion on v4 was to get rid of the child node by merging it with
> the parent like this:
>
> +sysc: sysc@0 {
> +  compatible = "mediatek,mt7621-sysc", "syscon";
> +  reg = <0x0 0x100>;
> +  #clock-cells = <1>;
> +  clock-output-names = "xtal", "cpu", "bus",
> + "50m", "125m", "150m",
> + "250m", "270m";
> +};
>
> Whether you need child nodes or not really depends on what all is in the
> 'mt7621-sysc' h/w block.

All the drivers in this platform make use of arch operations defined
in "asm/mach-ralink/ralink_regs.h". This mediatek,mt7621-sysc is
directly mapped by the architecture
in arch/mips/ralink/mt7621.c in function void __init
ralink_of_remap(void). This is the first address in the virtual space
and from here "rt_sysc_membase" and "rt_memc_membase" are used to
access the hardware control registers through read and write
operations. So "mediatek,mt7621-sysc" cannot be remapped from clock
driver. The benefits I found at first of using the syscon as child
node was to avoid the use of architecture dependant operations but at
the end I realized that we need to access another register which is
not in the syscon block and it is not also well documented so the use
of arch operations is mandatory to make things work. That's why I end
up in just follow the architecture driver style and use this in the
same way, trying to maintain as clean as possible. Is it ok then to
declare it as it is in this way?

>
> Rob

Best regards,
Sergio Paracuellos

[PATCH] [sh] fix trivial misannotations

[Al Viro]

Trivial misannotations in
* get_user() (__gu_addr is a userland pointer there)
* ip_fast_csum() (sum is __wsum, not unsigned int)
* csum_and_copy_to_user() (destination is void *, not const void * - mea culpa)
* __clear_user() (to is a userland pointer)
* several places in kernel/traps_32.c (regs->pc is a userland pointer when regs 
is a
userland pt_regs)
* math-emu/math.c: READ() and WRITE() casts of address should be to userland 
pointer.

No changes in code generation and those take care of the majority of noise from 
sparse
on sh builds.

Signed-off-by: Al Viro 
---
diff --git a/arch/sh/include/asm/checksum_32.h 
b/arch/sh/include/asm/checksum_32.h
index 1a391e3a7659..a6501b856f3e 100644
--- a/arch/sh/include/asm/checksum_32.h
+++ b/arch/sh/include/asm/checksum_32.h
@@ -84,7 +84,8 @@ static inline __sum16 csum_fold(__wsum sum)
  */
 static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl)
 {
-   unsigned int sum, __dummy0, __dummy1;
+   __wsum sum;
+   unsigned int __dummy0, __dummy1;
 
__asm__ __volatile__(
"mov.l  @%1+, %0\n\t"
@@ -197,6 +198,6 @@ static inline __wsum csum_and_copy_to_user(const void *src,
 {
if (!access_ok(dst, len))
return 0;
-   return csum_partial_copy_generic((__force const void *)src, dst, len);
+   return csum_partial_copy_generic(src, (__force void *)dst, len);
 }
 #endif /* __ASM_SH_CHECKSUM_H */
diff --git a/arch/sh/include/asm/uaccess.h b/arch/sh/include/asm/uaccess.h
index 73f3b48d4a34..8867bb04b00e 100644
--- a/arch/sh/include/asm/uaccess.h
+++ b/arch/sh/include/asm/uaccess.h
@@ -68,7 +68,7 @@ struct __large_struct { unsigned long buf[100]; };
 ({ \
long __gu_err = -EFAULT;\
unsigned long __gu_val = 0; \
-   const __typeof__(*(ptr)) *__gu_addr = (ptr);\
+   const __typeof__(*(ptr)) __user *__gu_addr = (ptr); 
\
if (likely(access_ok(__gu_addr, (size   \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__force __typeof__(*(ptr)))__gu_val; \
@@ -124,7 +124,7 @@ raw_copy_to_user(void __user *to, const void *from, 
unsigned long n)
  * Clear the area and return remaining number of bytes
  * (on failure.  Usually it's 0.)
  */
-__kernel_size_t __clear_user(void *addr, __kernel_size_t size);
+__kernel_size_t __clear_user(void __user *addr, __kernel_size_t size);
 
 #define clear_user(addr,n) \
 ({ \
diff --git a/arch/sh/kernel/traps_32.c b/arch/sh/kernel/traps_32.c
index b62ad0ba2395..b3c715bc254b 100644
--- a/arch/sh/kernel/traps_32.c
+++ b/arch/sh/kernel/traps_32.c
@@ -490,7 +490,7 @@ asmlinkage void do_address_error(struct pt_regs *regs,
inc_unaligned_user_access();
 
oldfs = force_uaccess_begin();
-   if (copy_from_user(&instruction, (insn_size_t *)(regs->pc & ~1),
+   if (copy_from_user(&instruction, (insn_size_t __user 
*)(regs->pc & ~1),
   sizeof(instruction))) {
force_uaccess_end(oldfs);
goto uspace_segv;
@@ -614,7 +614,7 @@ asmlinkage void do_reserved_inst(void)
unsigned short inst = 0;
int err;
 
-   get_user(inst, (unsigned short*)regs->pc);
+   get_user(inst, (unsigned short __user *)regs->pc);
 
err = do_fpu_inst(inst, regs);
if (!err) {
@@ -699,9 +699,9 @@ asmlinkage void do_illegal_slot_inst(void)
return;
 
 #ifdef CONFIG_SH_FPU_EMU
-   get_user(inst, (unsigned short *)regs->pc + 1);
+   get_user(inst, (unsigned short __user *)regs->pc + 1);
if (!do_fpu_inst(inst, regs)) {
-   get_user(inst, (unsigned short *)regs->pc);
+   get_user(inst, (unsigned short __user *)regs->pc);
if (!emulate_branch(inst, regs))
return;
/* fault in branch.*/
diff --git a/arch/sh/math-emu/math.c b/arch/sh/math-emu/math.c
index e8be0eca0444..3495a48b7713 100644
--- a/arch/sh/math-emu/math.c
+++ b/arch/sh/math-emu/math.c
@@ -51,8 +51,8 @@
 #define Rn (regs->regs[n])
 #define Rm (regs->regs[m])
 
-#define WRITE(d,a) ({if(put_user(d, (typeof (d)*)a)) return -EFAULT;})
-#define READ(d,a)  ({if(get_user(d, (typeof (d)*)a)) return -EFAULT;})
+#define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return 
-EFAULT;})
+#define READ(d,a)  ({if(get_user(d, (typeof (d) __user *)a)) return 
-EFAULT;})
 
 #define PACK_S(r,f)FP_PACK_SP(&r,f)
 #define UNPACK_S(f,r)  FP_UNPACK_SP(f,&r)
diff --git a/arch/sh/mm/nommu.c b/arch/sh/mm/nommu.c
index 8b4504413c5f..78c4b6e6d33b 100644
--- a/arch/sh/mm/nommu.c
++

net/wireless/pmsr.c:164:12: warning: stack frame size of 2432 bytes in function 'pmsr_parse_peer'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f6e1ea19649216156576aeafa784e3b4cee45549
commit: 44f3625bc61653ea3bde9960298faf2f5518fda5 netlink: export policy in 
extended ACK
date:   3 months ago
config: powerpc-randconfig-r036-20210101 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
6b316febb4388764789677f81f03aff373ec35b2)
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 powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44f3625bc61653ea3bde9960298faf2f5518fda5
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 44f3625bc61653ea3bde9960298faf2f5518fda5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

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

All warnings (new ones prefixed by >>):

   arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer 
arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c),
   ^~~
   arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
   __do_##name al; \
   ^~
   :219:1: note: expanded from here
   __do_insw
   ^
   arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw'
   #define __do_insw(p, b, n)  readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
  ~^
   In file included from net/wireless/pmsr.c:7:
   In file included from include/net/cfg80211.h:13:
   In file included from include/linux/netdevice.h:37:
   In file included from include/linux/ethtool.h:18:
   In file included from include/uapi/linux/ethtool.h:19:
   In file included from include/linux/if_ether.h:19:
   In file included from include/linux/skbuff.h:31:
   In file included from include/linux/dma-mapping.h:11:
   In file included from include/linux/scatterlist.h:9:
   In file included from arch/powerpc/include/asm/io.h:604:
   arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer 
arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c),
   ^~~
   arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
   __do_##name al; \
   ^~
   :221:1: note: expanded from here
   __do_insl
   ^
   arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl'
   #define __do_insl(p, b, n)  readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
  ~^
   In file included from net/wireless/pmsr.c:7:
   In file included from include/net/cfg80211.h:13:
   In file included from include/linux/netdevice.h:37:
   In file included from include/linux/ethtool.h:18:
   In file included from include/uapi/linux/ethtool.h:19:
   In file included from include/linux/if_ether.h:19:
   In file included from include/linux/skbuff.h:31:
   In file included from include/linux/dma-mapping.h:11:
   In file included from include/linux/scatterlist.h:9:
   In file included from arch/powerpc/include/asm/io.h:604:
   arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer 
arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c),
   ^~
   arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
   __do_##name al; \
   ^~
   :223:1: note: expanded from here
   __do_outsb
   ^
   arch/powerpc/include/asm/io.h:544:58: note: expanded from macro '__do_outsb'
   #define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
   ~^
   In file included from net/wireless/pmsr.c:7:
   In file included from include/net/cfg80211.h:13:
   In file included from include/linux/netdevice.h:37:
   In file included from include/linux/ethtool.h:18:
   In file included from include/uapi/linux/ethtool.h:19:
   In file included from include

Re: [GIT PULL] xfs: new code for 5.11

[Darrick J. Wong]

On Tue, Dec 29, 2020 at 10:49:55AM +0300, Dmitrii Tcvetkov wrote:
> >Please pull the following branch containing all the new xfs code for
> >5.11.  In this release we add the ability to set a 'needsrepair' flag
> >indicating that we /know/ the filesystem requires xfs_repair, but other
> >than that, it's the usual strengthening of metadata validation and
> >miscellaneous cleanups.
> >...
> >New code for 5.11:
> >- Introduce a "needsrepair" "feature" to flag a filesystem as needing a
> >  pass through xfs_repair.  This is key to enabling filesystem upgrades
> >  (in xfs_db) that require xfs_repair to make minor adjustments to
> >metadata.
> 
> Hello.
> 
> Most likely I miss something obvious but according to xfs_repair(8):
> BUGS:
> The filesystem to be checked and repaired must have been unmounted
> cleanly  using  normal  system  administration  procedures (the
> umount(8)  command  or  system  shutdown),  not  as  a  result of a
> crash or system reset.  If the filesystem has not been unmounted
> cleanly, mount it and unmount it cleanly before running xfs_repair.
> 
> which is there since commit d321ceac "add libxlog directory"
> Date:   Wed Oct 17 11:00:32 2001 + in xfsprogs-dev[1]. 
> 
> So will be there situation of uncleanly unmounted filesystem with
> "needsrepair" bit set?

No.  If we detect metadata corruption we stop writing metadata
and take the fs offline immediately.  We would not set needsrepair, for
exactly the reasons you outline.

--D

> Will one be able to mount and umount it before running xfs_repair in
> that case?
> 
> [1] git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git

[tip:x86/microcode] BUILD SUCCESS c769dcd423785703f17ca0a99925a7f9d84b3cbc

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/microcode
branch HEAD: c769dcd423785703f17ca0a99925a7f9d84b3cbc  x86/microcode: Make 
microcode_init() static

elapsed time: 724m

configs tested: 64
configs skipped: 64

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm  allyesconfig
arm  allmodconfig
xtensa virt_defconfig
mipsar7_defconfig
arm64   defconfig
powerpc  ppc6xx_defconfig
c6xevmc6474_defconfig
sh  urquell_defconfig
arc  axs103_smp_defconfig
armrealview_defconfig
mips mpc30x_defconfig
sh   se7343_defconfig
xtensa  cadence_csp_defconfig
c6xevmc6457_defconfig
powerpc  pcm030_defconfig
x86_64   alldefconfig
powerpc taishan_defconfig
arm am200epdkit_defconfig
powerpc  makalu_defconfig
s390   zfcpdump_defconfig
xtensaxip_kc705_defconfig
powerpc mpc832x_rdb_defconfig
shedosk7760_defconfig
powerpc  iss476-smp_defconfig
i386 allyesconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
sparc   defconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a016-20201231
i386 randconfig-a015-20201231
i386 randconfig-a014-20201231
i386 randconfig-a012-20201231
i386 randconfig-a011-20201231
i386 randconfig-a013-20201231
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a005-20201231
x86_64   randconfig-a006-20201231
x86_64   randconfig-a001-20201231
x86_64   randconfig-a002-20201231
x86_64   randconfig-a004-20201231
x86_64   randconfig-a003-20201231

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

Re: [PATCH] atomic: remove further references to atomic_ops

[Jonathan Corbet]

On Sun, 20 Dec 2020 07:09:27 +0100
Lukas Bulwahn  wrote:

> Commit f0400a77ebdc ("atomic: Delete obsolete documentation") removed
> ./Documentation/core-api/atomic_ops.rst, but missed to remove further
> references to that file.
> 
> Hence, make htmldocs warns:
> 
>   Documentation/core-api/index.rst:53: WARNING:
>   toctree contains reference to nonexisting document 'core-api/atomic_ops'
> 
> Also, ./scripts/get_maintainer.pl --self-test=patterns warns:
> 
>   warning: no file matchesF:Documentation/core-api/atomic_ops.rst
> 
> Remove further references to ./Documentation/core-api/atomic_ops.rst.
> 
> Fixes: f0400a77ebdc ("atomic: Delete obsolete documentation")
> Signed-off-by: Lukas Bulwahn 
> ---

I've applied this, thanks.

jon

Re: [PATCH 2/4] mfd: qca639x: add support for QCA639x powerup sequence

[Rob Herring]

On Mon, Dec 21, 2020 at 05:08:44PM +0300, Dmitry Baryshkov wrote:
> Hello,
> 
> On Mon, 21 Dec 2020 at 12:02, Lee Jones  wrote:
> >
> > On Sun, 20 Dec 2020, Dmitry Baryshkov wrote:
> >
> > > Qualcomm QCA639x is a family of WiFi + Bluetooth SoCs, with BT part
> > > being controlled through the UART and WiFi being present on PCIe
> > > bus. Both blocks share common power sources. So add mfd device driver
> > > handling power sequencing of QCA6390/1.
> > >
> > > Signed-off-by: Dmitry Baryshkov 
> > > ---
> > >  drivers/mfd/Kconfig|  12 +++
> > >  drivers/mfd/Makefile   |   1 +
> > >  drivers/mfd/qcom-qca639x.c | 168 +
> > >  3 files changed, 181 insertions(+)
> > >  create mode 100644 drivers/mfd/qcom-qca639x.c
> >
> > This is not an MFD, since it utilised neither the MFD API nor
> > of_platform_populate() to register child devices.
> 
> It would use them if the WiFi part was not on a discoverable bus.

PCI nodes have been supported in DT for forever. If you have 
non-discoverable additions to a PCI device, then the PCI device should 
be in DT.

Rob

Re: [PATCH 1/4] dt-bindings: mfd: qcom,qca639x: add binding for QCA639x defvice

[Rob Herring]

On Sun, Dec 20, 2020 at 07:58:42PM +0300, Dmitry Baryshkov wrote:
> Qualcomm QCA639x is a family of WiFi + Bluetooth SoCs, with BT part
> being controlled through the UART and WiFi being present on PCIe bus.
> Both blocks share common power sources. Add binding to describe power
> sequencing required to power up this device.
> 
> Signed-off-by: Dmitry Baryshkov 
> ---
>  .../devicetree/bindings/mfd/qcom,qca639x.yaml | 84 +++
>  1 file changed, 84 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/qcom,qca639x.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mfd/qcom,qca639x.yaml 
> b/Documentation/devicetree/bindings/mfd/qcom,qca639x.yaml
> new file mode 100644
> index ..d43c75da136f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/qcom,qca639x.yaml
> @@ -0,0 +1,84 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/mfd/qcom,qca639x.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: Qualcomm QCA639x WiFi + Bluetoot SoC bindings
> +
> +maintainers:
> +  - Andy Gross 
> +  - Bjorn Andersson 
> +
> +description: |
> +  This binding describes thes Qualcomm QCA6390 or QCA6391 power supplies and
> +  enablement pins.

Humm, this should really be for the whole device. For BT/WiFi chips 
we've gotten away with 2 nodes for each interface. If that doesn't work 
here, then I think this needs to be 1 node for all, not 3 as it seems 
you are doing.

> +
> +properties:
> +  compatible:
> +const: qcom,qca639x

List each device, we don't do wildcards in compatible strings. 

> +
> +  '#power-domain-cells':
> +const: 0
> +
> +  pinctrl-0: true
> +  pinctrl-1: true
> +
> +  pinctrl-names:
> +items:
> +  - const: default
> +  - const: active
> +
> +  vddaon-supply:
> +description:
> +  0.95V always-on LDO power input
> +
> +  vddpmu-supply:
> +description:
> +  0.95V LDO power input to PMU
> +
> +  vddrfa1-supply:
> +description:
> +  0.95V LDO power input to RFA
> +
> +  vddrfa2-supply:
> +description:
> +  1.25V LDO power input to RFA
> +
> +  vddrfa3-supply:
> +description:
> +  2V LDO power input to RFA
> +
> +  vddpcie1-supply:
> +description:
> +  1.25V LDO power input to PCIe part
> +
> +  vddpcie2-supply:
> +description:
> +  2V LDO power input to PCIe part

Do the PCIe supplies have to be on if only the BT part is used?

Supplies are refcounted, so I'd suggest just duplicating the supplies in 
both the BT and PCIe nodes.

> +
> +  vddio-supply:
> +description:
> +  1.8V VIO input
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +qca639x: qca639x {
> +  compatible = "qcom,qca639x";
> +  #power-domain-cells = <0>;
> +
> +  vddaon-supply = <&vreg_s6a_0p95>;
> +  vddpmu-supply = <&vreg_s2f_0p95>;
> +  vddrfa1-supply = <&vreg_s2f_0p95>;
> +  vddrfa2-supply = <&vreg_s8c_1p3>;
> +  vddrfa3-supply = <&vreg_s5a_1p9>;
> +  vddpcie1-supply = <&vreg_s8c_1p3>;
> +  vddpcie2-supply = <&vreg_s5a_1p9>;
> +  vddio-supply = <&vreg_s4a_1p8>;
> +  pinctrl-names = "default", "active";
> +  pinctrl-0 = <&wlan_default_state &bt_default_state>;
> +  pinctrl-1 = <&wlan_active_state &bt_active_state>;
> +};
> +...
> -- 
> 2.29.2
> 

Re: [RFC PATCH] Documentation: doc-guide: fixes to sphinx.rst

[Jonathan Corbet]

On Mon, 28 Dec 2020 15:12:12 -0800
Randy Dunlap  wrote:

> Various fixes to sphinx.rst:
> 
> - eliminate a double-space between 2 words
> - grammar/wording
> - punctuation
> - call rows in a table 'rows' instead of 'columns' (or does Sphinx
>   call everything a column?)
> - It seems that "amdfonts" should be "amsfonts". I can't find any
>   amdfonts.

Applied, thanks.

jon

Re: [PATCH] docs/mm: concepts.rst: Correct the threshold to low watermark

[Jonathan Corbet]

On Sun, 27 Dec 2020 15:15:19 +0800
winnd...@163.com wrote:

> It should be "low watermark" where we wake up kswapd daemon.
> 
> Signed-off-by: Liao Pingfang 
> ---
>  Documentation/admin-guide/mm/concepts.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/mm/concepts.rst 
> b/Documentation/admin-guide/mm/concepts.rst
> index fa0974f..b966fcf 100644
> --- a/Documentation/admin-guide/mm/concepts.rst
> +++ b/Documentation/admin-guide/mm/concepts.rst
> @@ -184,7 +184,7 @@ pages either asynchronously or synchronously, depending 
> on the state
>  of the system. When the system is not loaded, most of the memory is free
>  and allocation requests will be satisfied immediately from the free
>  pages supply. As the load increases, the amount of the free pages goes
> -down and when it reaches a certain threshold (high watermark), an
> +down and when it reaches a certain threshold (low watermark), an

Applied, thanks.

jon

Re: [PATCH] Documentation: admin: early_param()s are also listed in kernel-parameters

[Jonathan Corbet]

On Sat, 26 Dec 2020 09:44:33 -0800
Randy Dunlap  wrote:

> Add info that "early_param()" kernel boot parameters are also listed
> in kernel-parameters.txt.
> 
> Signed-off-by: Randy Dunlap 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> ---
>  Documentation/admin-guide/kernel-parameters.rst |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- linux-next-20201223.orig/Documentation/admin-guide/kernel-parameters.rst
> +++ linux-next-20201223/Documentation/admin-guide/kernel-parameters.rst
> @@ -3,8 +3,8 @@
>  The kernel's command-line parameters
>  
>  
> -The following is a consolidated list of the kernel parameters as
> -implemented by the __setup(), core_param() and module_param() macros
> +The following is a consolidated list of the kernel parameters as implemented
> +by the __setup(), early_param(), core_param() and module_param() macros

Applied, thanks.

jon

Re: [PATCH v2] docs: Fix reST markup when linking to sections

[Jonathan Corbet]

On Mon, 28 Dec 2020 14:46:07 +
Nícolas F. R. A. Prado  wrote:

> During the process of converting the documentation to reST, some links
> were converted using the following wrong syntax (and sometimes using %20
> instead of spaces):
> 
>`Display text <#section-name-in-html>`__
> 
> This syntax isn't valid according to the docutils' spec [1], but more
> importantly, it is specific to HTML, since it uses '#' to link to an
> HTML anchor.
> 
> The right syntax would instead use a docutils hyperlink reference as the
> embedded URI to point to the section [2], that is:
> 
>`Display text `__
> 
> This syntax works in both HTML and PDF.
> 
> The LaTeX toolchain doesn't mind the HTML anchor syntax when generating
> the pdf documentation (make pdfdocs), that is, the build succeeds but
> the links don't work, but that syntax causes errors when trying to build
> using the not-yet-merged rst2pdf:
> 
>ValueError: format not resolved, probably missing URL scheme or undefined 
> destination target for 'Forcing%20Quiescent%20States'
> 
> So, use the correct syntax in order to have it work in all different
> output formats.

Applied, thanks.

jon

Re: [PATCH v5 2/6] dt: bindings: add mt7621-clk device tree binding documentation

[Rob Herring]

On Sun, Dec 20, 2020 at 10:37:20AM +0100, Sergio Paracuellos wrote:
> Adds device tree binding documentation for clocks in the
> MT7621 SOC.
> 
> Signed-off-by: Sergio Paracuellos 
> ---
>  .../bindings/clock/mediatek,mt7621-clk.yaml   | 52 +++
>  1 file changed, 52 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> 
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml 
> b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> new file mode 100644
> index ..f58d01bdc82c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/mediatek,mt7621-clk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MT7621 Clock Device Tree Bindings
> +
> +maintainers:
> +  - Sergio Paracuellos 
> +
> +description: |
> +  The MT7621 has a PLL controller from where the cpu clock is provided
> +  as well as derived clocks for the bus and the peripherals. It also
> +  can gate SoC device clocks.
> +
> +  Each clock is assigned an identifier and client nodes use this identifier
> +  to specify the clock which they consume.
> +
> +  All these identifiers could be found in:
> +  [1]: .
> +
> +properties:
> +  compatible:
> +const: mediatek,mt7621-clk
> +
> +  "#clock-cells":
> +description:
> +  The first cell indicates the clock number, see [1] for available
> +  clocks.
> +const: 1
> +
> +  clock-output-names:
> +maxItems: 8
> +
> +required:
> +  - compatible
> +  - '#clock-cells'
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +pll {
> +  compatible = "mediatek,mt7621-clk";
> +  #clock-cells = <1>;
> +  clock-output-names = "xtal", "cpu", "bus",
> +   "50m", "125m", "150m",
> +   "250m", "270m";

How do you access this h/w. There's nothing defined like 'reg' or 
a parent node or...

The suggestion on v4 was to get rid of the child node by merging it with 
the parent like this:

+sysc: sysc@0 {
+  compatible = "mediatek,mt7621-sysc", "syscon";
+  reg = <0x0 0x100>;
+  #clock-cells = <1>;
+  clock-output-names = "xtal", "cpu", "bus",
+ "50m", "125m", "150m",
+ "250m", "270m";
+};

Whether you need child nodes or not really depends on what all is in the 
'mt7621-sysc' h/w block.

Rob

Re: [PATCH v13 2/6] powerpc: Move arch independent ima kexec functions to drivers/of/kexec.c

[Rob Herring]

On Sat, Dec 19, 2020 at 09:57:09AM -0800, Lakshmi Ramasubramanian wrote:
> The functions defined in "arch/powerpc/kexec/ima.c" handle setting up
> and freeing the resources required to carry over the IMA measurement
> list from the current kernel to the next kernel across kexec system call.
> These functions do not have architecture specific code, but are
> currently limited to powerpc.
> 
> Move setup_ima_buffer() call into of_kexec_setup_new_fdt() defined in
> "drivers/of/kexec.c".
> 
> Move the remaining architecture independent functions from
> "arch/powerpc/kexec/ima.c" to "drivers/of/kexec.c".
> Delete "arch/powerpc/kexec/ima.c" and "arch/powerpc/include/asm/ima.h".
> Remove references to the deleted files in powerpc and in ima.
> 
> Co-developed-by: Prakhar Srivastava 
> Signed-off-by: Prakhar Srivastava 
> Signed-off-by: Lakshmi Ramasubramanian 
> ---
>  arch/powerpc/include/asm/ima.h |  27 
>  arch/powerpc/kexec/Makefile|   7 -
>  arch/powerpc/kexec/file_load.c |   7 -
>  arch/powerpc/kexec/ima.c   | 202 -
>  drivers/of/kexec.c | 235 +
>  include/linux/of.h |   2 +
>  security/integrity/ima/ima.h   |   4 -
>  security/integrity/ima/ima_kexec.c |   1 +
>  8 files changed, 238 insertions(+), 247 deletions(-)
>  delete mode 100644 arch/powerpc/include/asm/ima.h
>  delete mode 100644 arch/powerpc/kexec/ima.c


> diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
> index 66787be081fe..33d97106f176 100644
> --- a/drivers/of/kexec.c
> +++ b/drivers/of/kexec.c
> @@ -11,6 +11,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -59,6 +60,181 @@ static int fdt_find_and_del_mem_rsv(void *fdt, unsigned 
> long start, unsigned lon
>   return -ENOENT;
>  }
>  
> +/**
> + * get_addr_size_cells - Get address and size of root node
> + *
> + * @addr_cells: Return address of the root node
> + * @size_cells: Return size of the root node
> + *
> + * Return: 0 on success, or negative errno on error.
> + */
> +static int get_addr_size_cells(int *addr_cells, int *size_cells)
> +{
> + struct device_node *root;
> +
> + root = of_find_node_by_path("/");
> + if (!root)
> + return -EINVAL;
> +
> + *addr_cells = of_n_addr_cells(root);
> + *size_cells = of_n_size_cells(root);
> +
> + of_node_put(root);
> +
> + return 0;
> +}
> +
> +/**
> + * do_get_kexec_buffer - Get address and size of device tree property
> + *
> + * @prop: Device tree property
> + * @len: Size of @prop
> + * @addr: Return address of the node
> + * @size: Return size of the node
> + *
> + * Return: 0 on success, or negative errno on error.
> + */
> +static int do_get_kexec_buffer(const void *prop, int len, unsigned long 
> *addr,
> +size_t *size)
> +{
> + int ret, addr_cells, size_cells;
> +
> + ret = get_addr_size_cells(&addr_cells, &size_cells);
> + if (ret)
> + return ret;
> +
> + if (len < 4 * (addr_cells + size_cells))
> + return -ENOENT;
> +
> + *addr = of_read_number(prop, addr_cells);
> + *size = of_read_number(prop + 4 * addr_cells, size_cells);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_HAVE_IMA_KEXEC
> +/**
> + * remove_ima_buffer - remove the IMA buffer property and reservation from 
> @fdt
> + *
> + * @fdt: Flattened Device Tree to update
> + * @chosen_node: Offset to the chosen node in the device tree
> + *
> + * The IMA measurement buffer is of no use to a subsequent kernel, so we 
> always
> + * remove it from the device tree.
> + */
> +static void remove_ima_buffer(void *fdt, int chosen_node)
> +{
> + int ret, len;
> + unsigned long addr;
> + size_t size;
> + const void *prop;
> +

Should be able to do this instead of #ifdef:

if (!IS_ENABLED(CONFIG_HAVE_IMA_KEXEC))
return;

Otherwise, I think it looks good.

Rob

Re: [RFC PATCH v1 1/4] media: dt-bindings: rockchip-rga: add more rga compatible properties

[Rob Herring]

On Sat, 19 Dec 2020 12:26:50 +0100, Johan Jonker wrote:
> Add more rga compatible properties.
> 
> "rockchip,px30-rga", "rockchip,rk3288-rga"
> "rockchip,rk3328-rga", "rockchip,rk3288-rga"
> "rockchip,rk3368-rga", "rockchip,rk3288-rga"
> 
> make ARCH=arm64 dt_binding_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/media/rockchip-rga.yaml
> 
> Signed-off-by: Johan Jonker 
> ---
>  Documentation/devicetree/bindings/media/rockchip-rga.yaml | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring 

Gespendet

[Mr. Landolt]

850.000,00 Euro wurden Ihnen gerade gespendet.

checkpatch.pl: Bogus case of DT_SPLIT_BINDING_PATCH

[Jonathan Neuschäfer]

Hi,

I've encountered a case where the DT_SPLIT_BINDING_PATCH warning was
emitted even though I didn't change anything outside of Documentation/
devicetree/bindings. I just converted a binding from plain text to YAML.

Here's a transcript of checkpatch (from Linux 5.11-rc1)'s output:

  $ scripts/checkpatch.pl --strict 
patches-wpcm/0001-dt-bindings-arm-Convert-nuvoton-npcm750-binding-to-Y.patch
  WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
  #31:
  deleted file mode 100644
  
  WARNING: DT binding docs and includes should be a separate patch. See: 
Documentation/devicetree/bindings/submitting-patches.rst
  
  WARNING: DT binding docs and includes should be a separate patch. See: 
Documentation/devicetree/bindings/submitting-patches.rst
  
  total: 0 errors, 3 warnings, 0 checks, 21 lines checked
  
  NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
  
  patches-wpcm/0001-dt-bindings-arm-Convert-nuvoton-npcm750-binding-to-Y.patch 
has style problems, please review.
  
  NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.


I attached the patch, for reference.


Best regards,
Jonathan Neuschäfer
From 3aaf23345633070909e23a05a9f92748e445b3b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jonathan=20Neusch=C3=A4fer?= 
Date: Mon, 28 Dec 2020 01:09:31 +0100
Subject: [PATCH 01/11] dt-bindings: arm: Convert nuvoton,npcm750 binding to
 YAML
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The general trend is to have devicetree bindings in YAML format, to
allow automatic validation of bindings and devicetrees.

Convert the NPCM SoC family's binding to YAML before extending it.

The nuvoton,npcm750-evb compatible string is introduced to keep the
structure of the binding a little simpler.

Signed-off-by: Jonathan Neuschäfer 
---

If someone else (e.g. Brendan Higgins) wants to be listed as the
maintainer, please let me know.
---
 .../devicetree/bindings/arm/npcm/npcm.txt |  6 --
 .../devicetree/bindings/arm/npcm/npcm.yaml| 21 +++
 2 files changed, 21 insertions(+), 6 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.txt
 create mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.yaml

diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.txt 
b/Documentation/devicetree/bindings/arm/npcm/npcm.txt
deleted file mode 100644
index 2d87d9ecea85b..0
--- a/Documentation/devicetree/bindings/arm/npcm/npcm.txt
+++ /dev/null
@@ -1,6 +0,0 @@
-NPCM Platforms Device Tree Bindings

-NPCM750 SoC
-Required root node properties:
-   - compatible = "nuvoton,npcm750";
-
diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml 
b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml
new file mode 100644
index 0..3ecd00803c003
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/npcm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NPCM Platforms Device Tree Bindings
+
+maintainers:
+  - Jonathan Neuschäfer 
+
+properties:
+  $nodename:
+const: '/'
+  compatible:
+oneOf:
+  - description: NPCM750 based boards
+items:
+  - enum:
+- nuvoton,npcm750-evb   # NPCM750 evaluation board
+  - const: nuvoton,npcm750
-- 
2.29.2



signature.asc
Description: PGP signature

Re: [PATCH] xfs: Wake CIL push waiters more reliably

[Dave Chinner]

On Thu, Dec 31, 2020 at 12:48:56PM +0100, Donald Buczek wrote:
> On 30.12.20 23:16, Dave Chinner wrote:
> > On Wed, Dec 30, 2020 at 12:56:27AM +0100, Donald Buczek wrote:
> > > Threads, which committed items to the CIL, wait in the
> > > xc_push_wait waitqueue when used_space in the push context
> > > goes over a limit. These threads need to be woken when the CIL
> > > is pushed.
> > > 
> > > The CIL push worker tries to avoid the overhead of calling
> > > wake_all() when there are no waiters waiting. It does so by
> > > checking the same condition which caused the waits to happen.
> > > This, however, is unreliable, because ctx->space_used can
> > > actually decrease when items are recommitted.
> > 
> > When does this happen?
> > 
> > Do you have tracing showing the operation where the relogged
> > item has actually gotten smaller? By definition, relogging in
> > the CIL should only grow the size of the object in the CIL
> > because it must relog all the existing changes on top of the new
> > changed being made to the object. Hence the CIL reservation
> > should only ever grow.
> 
> I have (very ugly printk based) log (see below), but it only
> shows, that it happened (space_used decreasing), not what caused
> it.
> 
> I only browsed the ( xfs_*_item.c ) code and got the impression
> that the size of a log item is rather dynamic (e.g. number of
> extends in an inode, extended attributes in an inode, continuity
> of chunks in a buffer) and wasn't surprised that a relogged item
> might need less space from time to time.
> 
> > IOWs, returning negative lengths from the formatting code is
> > unexpected and probably a bug and requires further
> > investigation, not papering over the occurrence with broadcast
> > wakeups...
> 
> One could argue that the code is more robust after the change,
> because it wakes up every thread which is waiting on the next push
> to happen when the next push is happening without making
> assumption of why these threads are waiting by duplicating code
> from that waiters side. The proposed waitqueue_active() is inlined
> to two instructions and avoids the call overhead if there are no
> waiters as well.

One could argue that, but one should also understand the design
constraints for a particular algorithm are before suggesting that
their solution is "robust". :)

> 
> # seq 29
> 
> 2020-12-29T20:08:15.652167+01:00 deadbird kernel: [ 1053.860637] XXX trigger 
> cil e374c6f1 ctx 4967d650  ctx->space_used=33554656  , 
> push_seq=29, ctx->sequence=29

So, at 20:08:15 we get a push trigger and the work is queued. But...

.
> 2020-12-29T20:09:04.961088+01:00 deadbird kernel: [ 1103.168964] XXX wake
> cil e374c6f1 ctx 4967d650  ctx->space_used=67109136 >= 
> 67108864, push_seq=29, ctx->sequence=29

It takes the best part of *50 seconds* before the push work actually
runs?

That's  well and truly screwed up - the work should run on that
CPU on the very next time it yeilds the CPU. If we're holding the
CPU without yeilding it for that long, hangcheck and RCU warnings
should be going off...

> # seq 30
> 
> 2020-12-29T20:09:39.305108+01:00 deadbird kernel: [ 1137.514718] XXX trigger 
> cil e374c6f1 ctx c46ab121  ctx->space_used=33554480  , 
> push_seq=30, ctx->sequence=30

20:09:39 for the next trigger,

> 2020-12-29T20:10:20.389104+01:00 deadbird kernel: [ 1178.597976] XXX pushw   
> cil e374c6f1 ctx c46ab121  ctx->space_used=67108924 >= 
> 67108864, push_seq=30, ctx->sequence=30
> 2020-12-29T20:10:20.389117+01:00 deadbird kernel: [ 1178.613792] XXX pushw   
> cil e374c6f1 ctx c46ab121  ctx->space_used=67108924 >= 
> 67108864, push_seq=30, ctx->sequence=30
> 2020-12-29T20:10:20.619077+01:00 deadbird kernel: [ 1178.827935] XXX pushw   
> cil e374c6f1 ctx c46ab121  ctx->space_used=67108924 >= 
> 67108864, push_seq=30, ctx->sequence=30
> 2020-12-29T20:10:21.129074+01:00 deadbird kernel: [ 1179.337996] XXX pushw   
> cil e374c6f1 ctx c46ab121  ctx->space_used=67108924 >= 
> 67108864, push_seq=30, ctx->sequence=30
> 2020-12-29T20:10:21.190101+01:00 deadbird kernel: [ 1179.398869] XXX pushw   
> cil e374c6f1 ctx c46ab121  ctx->space_used=67108924 >= 
> 67108864, push_seq=30, ctx->sequence=30
> 2020-12-29T20:10:21.866096+01:00 deadbird kernel: [ 1180.074325] XXX pushw   
> cil e374c6f1 ctx c46ab121  ctx->space_used=67108924 >= 
> 67108864, push_seq=30, ctx->sequence=30
> 2020-12-29T20:10:22.076095+01:00 deadbird kernel: [ 1180.283748] XXX pushw   
> cil e374c6f1 ctx c46ab121  ctx->space_used=67108924 >= 
> 67108864, push_seq=30, ctx->sequence=30
> 2020-12-29T20:10:22.193070+01:00 deadbird kernel: [ 1180.401590] XXX pushw   
> cil e374c6f1 ctx c46ab121  ctx->space_used=67108924 >= 
> 67108864, push_seq=30, ctx->sequence=30
> 2020-12-29T20:10:22.421082+01:00 deadbird kernel: [ 1180.629682] XXX pushw   
> c

drivers/media/test-drivers/vidtv/vidtv_mux.c:379:13: warning: stack frame size of 2624 bytes in function 'vidtv_mux_tick'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f6e1ea19649216156576aeafa784e3b4cee45549
commit: f90cf6079bf67988f8b1ad1ade70fc89d0080905 media: vidtv: add a bridge 
driver
date:   4 months ago
config: powerpc-randconfig-r036-20210101 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
6b316febb4388764789677f81f03aff373ec35b2)
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 powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f90cf6079bf67988f8b1ad1ade70fc89d0080905
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout f90cf6079bf67988f8b1ad1ade70fc89d0080905
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

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

All warnings (new ones prefixed by >>):

>> drivers/media/test-drivers/vidtv/vidtv_mux.c:379:13: warning: stack frame 
>> size of 2624 bytes in function 'vidtv_mux_tick' [-Wframe-larger-than=]
   static void vidtv_mux_tick(struct work_struct *work)
   ^
   1 warning generated.


vim +/vidtv_mux_tick +379 drivers/media/test-drivers/vidtv/vidtv_mux.c

   378  
 > 379  static void vidtv_mux_tick(struct work_struct *work)
   380  {
   381  struct vidtv_mux *m = container_of(work,
   382 struct vidtv_mux,
   383 mpeg_thread);
   384  u32 nbytes;
   385  u32 npkts;
   386  
   387  while (m->streaming) {
   388  nbytes = 0;
   389  
   390  vidtv_mux_update_clk(m);
   391  
   392  if (vidtv_mux_should_push_pcr(m))
   393  nbytes += vidtv_mux_push_pcr(m);
   394  
   395  if (vidtv_mux_should_push_si(m))
   396  nbytes += vidtv_mux_push_si(m);
   397  
   398  nbytes += vidtv_mux_poll_encoders(m);
   399  nbytes += vidtv_mux_check_mux_rate(m);
   400  
   401  npkts = nbytes / TS_PACKET_LEN;
   402  
   403  /* if the buffer is not aligned there is a bug 
somewhere */
   404  if (nbytes % TS_PACKET_LEN)
   405  pr_err_ratelimited("Misaligned buffer\n");
   406  
   407  if (m->on_new_packets_available_cb)
   408  m->on_new_packets_available_cb(m->priv,
   409 m->mux_buf,
   410 npkts);
   411  
   412  vidtv_mux_clear(m);
   413  
   414  usleep_range(VIDTV_SLEEP_USECS, VIDTV_MAX_SLEEP_USECS);
   415  }
   416  }
   417  

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


.config.gz
Description: application/gzip

[PATCH] percpu: fix clang modpost warning in pcpu_build_alloc_info()

[Dennis Zhou]

This is an unusual situation so I thought it best to explain it in a
separate patch.

"percpu: reduce the number of cpu distance comparisons" introduces a
dependency on cpumask helper functions in __init code. This code
references a struct cpumask annotated __initdata. When the function is
inlined (gcc), everything is fine, but clang decides not to inline these
function calls. This causes modpost to warn about an __initdata access
by a function not annotated with __init [1].

Ways I thought about fixing it:
1. figure out why clang thinks this inlining is too costly.
2. create a wrapper function annotated __init (this).
3. annotate cpumask with __refdata.

Ultimately it comes down to if it's worth saving the cpumask memory and
allowing it to be freed. IIUC, __refdata won't be freed, so option 3 is
just a little wasteful. 1 is out of my depth, leaving 2. I don't feel
great about this behavior being dependent on inlining semantics, but
cpumask helpers are small and probably should be inlined.

modpost complaint:
  WARNING: modpost: vmlinux.o(.text+0x735425): Section mismatch in reference 
from the function cpumask_clear_cpu() to the variable 
.init.data:pcpu_build_alloc_info.mask
  The function cpumask_clear_cpu() references
  the variable __initdata pcpu_build_alloc_info.mask.
  This is often because cpumask_clear_cpu lacks a __initdata
  annotation or the annotation of pcpu_build_alloc_info.mask is wrong.

clang output:
  mm/percpu.c:2724:5: remark: cpumask_clear_cpu not inlined into 
pcpu_build_alloc_info because too costly to inline (cost=725, threshold=325) 
[-Rpass-missed=inline]

[1] https://lore.kernel.org/linux-mm/202012220454.9f6bkz9q-...@intel.com/

Reported-by: kernel test robot 
Signed-off-by: Dennis Zhou 
---
This is on top of percpu#for-5.12.

 mm/percpu.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/mm/percpu.c b/mm/percpu.c
index 80f8f885a990..357977c4cb00 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -2642,6 +2642,18 @@ early_param("percpu_alloc", percpu_alloc_setup);
 
 /* pcpu_build_alloc_info() is used by both embed and page first chunk */
 #if defined(BUILD_EMBED_FIRST_CHUNK) || defined(BUILD_PAGE_FIRST_CHUNK)
+
+/*
+ * This wrapper is to avoid a warning where cpumask_clear_cpu() is not inlined
+ * when compiling with clang causing modpost to warn about accessing __initdata
+ * from a non __init function.  By doing this, we allow the struct cpumask to 
be
+ * freed instead of it taking space by annotating with __refdata.
+ */
+static void __init pcpu_cpumask_clear_cpu(int cpu, struct cpumask *mask)
+{
+   cpumask_clear_cpu(cpu, mask);
+}
+
 /**
  * pcpu_build_alloc_info - build alloc_info considering distances between CPUs
  * @reserved_size: the size of reserved percpu area in bytes
@@ -2713,7 +2725,7 @@ static struct pcpu_alloc_info * __init 
pcpu_build_alloc_info(
cpu = cpumask_first(&mask);
group_map[cpu] = group;
group_cnt[group]++;
-   cpumask_clear_cpu(cpu, &mask);
+   pcpu_cpumask_clear_cpu(cpu, &mask);
 
for_each_cpu(tcpu, &mask) {
if (!cpu_distance_fn ||
@@ -2721,7 +2733,7 @@ static struct pcpu_alloc_info * __init 
pcpu_build_alloc_info(
 cpu_distance_fn(tcpu, cpu) == LOCAL_DISTANCE)) {
group_map[tcpu] = group;
group_cnt[group]++;
-   cpumask_clear_cpu(tcpu, &mask);
+   pcpu_cpumask_clear_cpu(tcpu, &mask);
}
}
}
-- 
2.29.2.729.g45daf8777d-goog

Re: [PATCH] of: property: Add device link support for interrupts

[Rob Herring]

On Mon, Dec 21, 2020 at 09:30:45AM +, Marc Zyngier wrote:
> On 2020-12-18 21:07, Saravana Kannan wrote:
> > Add support for creating device links out of interrupts property.
> > 
> > Cc: Marc Zyngier 
> > Cc: Kevin Hilman 
> > Signed-off-by: Saravana Kannan 
> > ---
> > Rob/Greg,
> > 
> > This might need to go into driver-core to avoid conflict
> > due to fw_devlink refactor series that merged there.
> > 
> > Thanks,
> > Saravana
> > 
> > 
> >  drivers/of/property.c | 17 +
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > index 5f9eed79a8aa..e56a5eae0a0b 100644
> > --- a/drivers/of/property.c
> > +++ b/drivers/of/property.c
> > @@ -1271,6 +1271,22 @@ static struct device_node
> > *parse_iommu_maps(struct device_node *np,
> > return of_parse_phandle(np, prop_name, (index * 4) + 1);
> >  }
> > 
> > +static struct device_node *parse_interrupts(struct device_node *np,
> > +   const char *prop_name, int index)
> > +{
> > +   struct device_node *sup;
> > +
> > +   if (strcmp(prop_name, "interrupts") || index)
> > +   return NULL;
> > +
> > +   of_node_get(np);
> > +   while (np && !(sup = of_parse_phandle(np, "interrupt-parent", 0)))
> > +   np = of_get_next_parent(np);
> > +   of_node_put(np);
> > +
> > +   return sup;
> > +}
> > +
> >  static const struct supplier_bindings of_supplier_bindings[] = {
> > { .parse_prop = parse_clocks, },
> > { .parse_prop = parse_interconnects, },
> > @@ -1296,6 +1312,7 @@ static const struct supplier_bindings
> > of_supplier_bindings[] = {
> > { .parse_prop = parse_pinctrl6, },
> > { .parse_prop = parse_pinctrl7, },
> > { .parse_prop = parse_pinctrl8, },
> > +   { .parse_prop = parse_interrupts, },
> > { .parse_prop = parse_regulators, },
> > { .parse_prop = parse_gpio, },
> > { .parse_prop = parse_gpios, },
> 
> You don't really describe what this is for so I'm only guessing
> from the context. If you want to follow the interrupt hierarchy,
> "interrupt-parent" isn't enough. You also need to track
> things like interrupt-map, or anything that carries a phandle
> to an interrupt controller.

We don't need to follow the hierarchy, we just need the immediate 
dependencies. But you are right that 'interrupt-map' also needs to be 
tracked.

I also noticed that we define 'interrupt-parent' as a dependency to 
parse, but that's wrong. The dependency is where 'interrupts' appears 
and where 'interrupt-parent' appears is irrelevant.

Rob

UBSAN: shift-out-of-bounds in gred_change

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:3db1a3fa Merge tag 'staging-5.11-rc1' of git://git.kernel...
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=155708db50
kernel config:  https://syzkaller.appspot.com/x/.config?x=2ae878fbf640b72b
dashboard link: https://syzkaller.appspot.com/bug?extid=1819b70451246ed8cf57
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=176b78c0d0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1299379750

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1819b70451246ed8c...@syzkaller.appspotmail.com

IPVS: ftp: loaded support on port[0] = 21

UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22
shift exponent 255 is too large for 32-bit type 'int'
CPU: 0 PID: 8465 Comm: syz-executor194 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:120
 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395
 red_set_parms include/net/red.h:252 [inline]
 gred_change_vq net/sched/sch_gred.c:506 [inline]
 gred_change.cold+0xce/0xe2 net/sched/sch_gred.c:702
 qdisc_change net/sched/sch_api.c:1331 [inline]
 tc_modify_qdisc+0xd4e/0x1a30 net/sched/sch_api.c:1633
 rtnetlink_rcv_msg+0x493/0xb40 net/core/rtnetlink.c:5564
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494
 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
 netlink_sendmsg+0x907/0xe10 net/netlink/af_netlink.c:1919
 sock_sendmsg_nosec net/socket.c:652 [inline]
 sock_sendmsg+0xd3/0x130 net/socket.c:672
 sys_sendmsg+0x6e8/0x810 net/socket.c:2336
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2390
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2423
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440e69
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
0b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fff634be6d8 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 004a2730 RCX: 00440e69
RDX:  RSI: 2080 RDI: 0003
RBP: 7fff634be6e0 R08: 000120080522 R09: 000120080522
R10: 000120080522 R11: 0246 R12: 004a2730
R13: 00402390 R14:  R15: 



---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: memory leak in zr364xx_probe

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an 
issue:
BUG: unable to handle kernel NULL pointer dereference in __videobuf_free

zr364xx 4-1:0.0: model 06d6:003b detected
usb 4-1: 320x240 mode selected
zr364xx: start read pipe failed
BUG: kernel NULL pointer dereference, address: 
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 0 P4D 0 
Oops:  [#1] PREEMPT SMP
CPU: 1 PID: 8717 Comm: kworker/1:4 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:__videobuf_free+0x62/0x180 drivers/media/v4l2-core/videobuf-core.c:243
Code: 9d 70 01 00 00 31 ff 83 e3 03 89 de e8 b7 da 4a fe 84 db 0f 85 00 01 00 
00 e8 2a e1 4a fe 48 8b 85 68 01 00 00 bf 03 10 26 12 <44> 8b 20 44 89 e6 e8 d3 
da 4a fe 41 81 fc 03 10 26 12 0f 85 c4 2c
RSP: 0018:c900024ef7b8 EFLAGS: 00010293
RAX:  RBX:  RCX: 82e82989
RDX: 88811813d040 RSI: 82e82996 RDI: 12261003
RBP: 888125921780 R08: 888125ffe008 R09: 08fd
R10:  R11: 3a7878343633727a R12: 0001
R13: 888125921000 R14: c900032b1000 R15: ffa6
FS:  () GS:88813bd0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 000109bb5000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 videobuf_mmap_free+0x1f/0x60 drivers/media/v4l2-core/videobuf-core.c:377
 zr364xx_release+0x26/0xa0 drivers/media/usb/zr364xx/zr364xx.c:1192
 v4l2_device_release drivers/media/v4l2-core/v4l2-device.c:51 [inline]
 kref_put include/linux/kref.h:65 [inline]
 v4l2_device_put+0x82/0xc0 drivers/media/v4l2-core/v4l2-device.c:56
 zr364xx_probe+0x80c/0x823 drivers/media/usb/zr364xx/zr364xx.c:1536
 usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
 really_probe+0x159/0x480 drivers/base/dd.c:554
 driver_probe_device+0x84/0x100 drivers/base/dd.c:738
 __device_attach_driver+0xee/0x110 drivers/base/dd.c:844
 bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431
 __device_attach+0x122/0x250 drivers/base/dd.c:912
 bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491
 device_add+0x5ac/0xc30 drivers/base/core.c:2936
 usb_set_configuration+0x9de/0xb90 drivers/usb/core/message.c:2159
 usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
 usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
 really_probe+0x159/0x480 drivers/base/dd.c:554
 driver_probe_device+0x84/0x100 drivers/base/dd.c:738
 __device_attach_driver+0xee/0x110 drivers/base/dd.c:844
 bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431
 __device_attach+0x122/0x250 drivers/base/dd.c:912
 bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491
 device_add+0x5ac/0xc30 drivers/base/core.c:2936
 usb_new_device.cold+0x166/0x578 drivers/usb/core/hub.c:2554
 hub_port_connect drivers/usb/core/hub.c:5222 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5362 [inline]
 port_event drivers/usb/core/hub.c:5508 [inline]
 hub_event+0x144a/0x20d0 drivers/usb/core/hub.c:5590
 process_one_work+0x27d/0x590 kernel/workqueue.c:2272
 worker_thread+0x59/0x5d0 kernel/workqueue.c:2418
 kthread+0x178/0x1b0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
Modules linked in:
CR2: 
---[ end trace 90e0be95dcb7e0d1 ]---
RIP: 0010:__videobuf_free+0x62/0x180 drivers/media/v4l2-core/videobuf-core.c:243
Code: 9d 70 01 00 00 31 ff 83 e3 03 89 de e8 b7 da 4a fe 84 db 0f 85 00 01 00 
00 e8 2a e1 4a fe 48 8b 85 68 01 00 00 bf 03 10 26 12 <44> 8b 20 44 89 e6 e8 d3 
da 4a fe 41 81 fc 03 10 26 12 0f 85 c4 2c
RSP: 0018:c900024ef7b8 EFLAGS: 00010293
RAX:  RBX:  RCX: 82e82989
RDX: 88811813d040 RSI: 82e82996 RDI: 12261003
RBP: 888125921780 R08: 888125ffe008 R09: 08fd
R10:  R11: 3a7878343633727a R12: 0001
R13: 888125921000 R14: c900032b1000 R15: ffa6
FS:  () GS:88813bd0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 000109bb5000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


Tested on:

commit: a1714d22 media: zr364xx: Fix memory leak in ->probe()
git tree:   https://gitlab.collabora.com/linux/0day.git
console output: https://syzkaller.appspot.com/x/log.txt?x=11415e0b50
kernel config:  https://syzkaller.appspot.com/x/.config?x=ec2338be23ae163e
dashboard link: https://syzkaller.appspot.com/bug?extid=b4d54814b339b5c6bbd4
compiler:   gcc (GCC) 10.1.0-syz 20200507

Re: mmotm 2020-12-31-11-52 uploaded (mm/cma.c)

[Randy Dunlap]

On 12/31/20 11:53 AM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2020-12-31-11-52 has been uploaded to
> 
>https://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> https://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.
> 
> You will need quilt to apply these patches to the latest Linus release (5.x
> or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> https://ozlabs.org/~akpm/mmotm/series
> 
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.

../mm/cma.c: In function ‘cma_declare_contiguous_nid’:
../mm/cma.c:347:5: warning: "CONFIG_PHYS_ADDR_T_64BIT" is not defined, 
evaluates to 0 [-Wundef]
 #if CONFIG_PHYS_ADDR_T_64BIT
 ^~~~


s/#if/#ifdef/


-- 
~Randy

Re: memory leak in zr364xx_probe

[Ezequiel Garcia]

Let's see if this works:

#syz test: https://gitlab.collabora.com/linux/0day.git
a1714d224e516b579d09cc1b4c3d85042e42f14c

On Wed, 23 Dec 2020 at 12:27, syzbot
 wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:3644e2d2 mm/filemap: fix infinite loop in generic_file_buf..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16f80eff50
> kernel config:  https://syzkaller.appspot.com/x/.config?x=37c889fb8b2761af
> dashboard link: https://syzkaller.appspot.com/bug?extid=b4d54814b339b5c6bbd4
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1089df0750
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1671c77f50
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b4d54814b339b5c6b...@syzkaller.appspotmail.com
>
> BUG: memory leak
> unreferenced object 0xc9e71000 (size 200704):
>   comm "kworker/0:2", pid 3653, jiffies 4294942426 (age 13.820s)
>   hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>   backtrace:
> [<110a155e>] __vmalloc_node_range+0x3a5/0x410 mm/vmalloc.c:2585
> [<8a1ee970>] __vmalloc_node mm/vmalloc.c:2617 [inline]
> [<8a1ee970>] vmalloc+0x49/0x50 mm/vmalloc.c:2650
> [] zr364xx_board_init 
> drivers/media/usb/zr364xx/zr364xx.c:1348 [inline]
> [] zr364xx_probe+0x60b/0x833 
> drivers/media/usb/zr364xx/zr364xx.c:1509
> [<14a572f5>] usb_probe_interface+0x177/0x370 
> drivers/usb/core/driver.c:396
> [] really_probe+0x159/0x480 drivers/base/dd.c:561
> [] driver_probe_device+0x84/0x100 drivers/base/dd.c:745
> [<73c89cb9>] __device_attach_driver+0xee/0x110 
> drivers/base/dd.c:851
> [<9f56a99c>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431
> [<848d591a>] __device_attach+0x122/0x250 drivers/base/dd.c:919
> [<168be5bb>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491
> [<464f40a6>] device_add+0x5be/0xc30 drivers/base/core.c:3091
> [<8c75a2b5>] usb_set_configuration+0x9d9/0xb90 
> drivers/usb/core/message.c:2164
> [<071d14a5>] usb_generic_driver_probe+0x8c/0xc0 
> drivers/usb/core/generic.c:238
> [] usb_probe_device+0x5c/0x140 
> drivers/usb/core/driver.c:293
> [] really_probe+0x159/0x480 drivers/base/dd.c:561
> [] driver_probe_device+0x84/0x100 drivers/base/dd.c:745
>
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches

Re: power-off delay/hang due to commit 6d25be57 (mainline)

[Rafael J. Wysocki]

On Wednesday, December 2, 2020 8:13:38 PM CET Rafael J. Wysocki wrote:
> On Wed, Dec 2, 2020 at 7:31 PM Rafael J. Wysocki  wrote:
> >
> > On Wed, Dec 2, 2020 at 7:03 PM Sebastian Andrzej Siewior
> >  wrote:
> > >
> > > On 2020-10-26 18:20:59 [+0100], To Rafael J. Wysocki wrote:
> > > > > > > > Done as Bug 208877.
> > > > > > Rafael, do you have any suggestions?
> > > > >
> > > > > I've lost track of this sorry.
> > > > >
> > > > > I have ideas, let me get back to this next week.
> > > >
> > > > :)
> > >
> > > Rafael, any update? If you outline an idea or so then I may be able to
> > > form a patch out of it. Otherwise I have no idea how to fix this - other
> > > than telling the driver to not poll in smaller intervals than
> > > 30secs.
> >
> > The idea, roughly speaking, is to limit the number of outstanding work
> > items in the queue (basically, if there's a notification occurring
> > before the previous one can be handled, there is no need to queue up
> > another work item for it).
> 
> That's easier said than done, though, because of the way the work item
> queue-up is hooked up into the ACPICA code.

So scratch this and it wouldn't work in general anyway AFAICS.

ATM, I'm tempted to do something like the patch below (with the rationale
that it shouldn't be necessary to read the temperature right after updating
the trip points if polling is in use, because the next update through polling
will cause it to be read anyway and it will trigger trip point actions as
needed).

Stephen, can you give it a go, please?

---
 drivers/acpi/thermal.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

Index: linux-pm/drivers/acpi/thermal.c
===
--- linux-pm.orig/drivers/acpi/thermal.c
+++ linux-pm/drivers/acpi/thermal.c
@@ -911,24 +911,25 @@ static void acpi_thermal_notify(struct a
switch (event) {
case ACPI_THERMAL_NOTIFY_TEMPERATURE:
acpi_thermal_check(tz);
-   break;
+   return;
case ACPI_THERMAL_NOTIFY_THRESHOLDS:
acpi_thermal_trips_update(tz, ACPI_TRIPS_REFRESH_THRESHOLDS);
-   acpi_thermal_check(tz);
-   acpi_bus_generate_netlink_event(device->pnp.device_class,
- dev_name(&device->dev), 
event, 0);
break;
case ACPI_THERMAL_NOTIFY_DEVICES:
acpi_thermal_trips_update(tz, ACPI_TRIPS_REFRESH_DEVICES);
-   acpi_thermal_check(tz);
-   acpi_bus_generate_netlink_event(device->pnp.device_class,
- dev_name(&device->dev), 
event, 0);
break;
default:
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
  "Unsupported event [0x%x]\n", event));
-   break;
+   return;
}
+
+   /* Trigger an update of the thermal zone unless polling is in use. */
+   if (!tz->polling_frequency)
+   acpi_thermal_check(tz);
+
+   acpi_bus_generate_netlink_event(device->pnp.device_class,
+   dev_name(&device->dev), event, 0);
 }
 
 /*

Re: [PATCH v2 1/2] dt-bindings: pwm: allwinner: Add V3s compatible description

[Rob Herring]

On Fri, 18 Dec 2020 21:54:35 +0100, Paul Kocialkowski wrote:
> Introduce bindings description for the V3s PWM, which is
> register-compatible with the A20 PWM.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  .../devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml   | 3 +++
>  1 file changed, 3 insertions(+)
> 

Acked-by: Rob Herring 

[PATCH] ARM: dts: da850: add MMD SDIO interrupts

[David Lechner]

This adds the MMC SDIO interrupts to the MMC nodes in the device tree
for TI DA850/AM18XX/OMAP-L138.

The missing interrupts were causing the following error message to be
printed:

davinci_mmc 1c4.mmc: IRQ index 1 not found

Signed-off-by: David Lechner 
---
 arch/arm/boot/dts/da850.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 7cf31b6e48b7..d2c609e4da5b 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -537,7 +537,7 @@ mmc0: mmc@4 {
reg = <0x4 0x1000>;
cap-sd-highspeed;
cap-mmc-highspeed;
-   interrupts = <16>;
+   interrupts = <16>, <17>;
dmas = <&edma0 16 0>, <&edma0 17 0>;
dma-names = "rx", "tx";
clocks = <&psc0 5>;
@@ -567,7 +567,7 @@ mmc1: mmc@21b000 {
reg = <0x21b000 0x1000>;
cap-sd-highspeed;
cap-mmc-highspeed;
-   interrupts = <72>;
+   interrupts = <72>, <73>;
dmas = <&edma1 28 0>, <&edma1 29 0>;
dma-names = "rx", "tx";
clocks = <&psc1 18>;
-- 
2.25.1

Re: [PATCH 5/8] dt-bindings: serial: stm32: update rts-gpios and cts-gpios

[Rob Herring]

On Fri, 18 Dec 2020 20:00:16 +0100, Erwan Le Ray wrote:
> Update rts-gpios and cts-gpios:
> - remove max-items as already defined in serial.yaml
> - add a note describing rts-gpios and cts-gpios usage with stm32
> 
> Document the use of cts-gpios and rts-gpios for flow control in STM32 UART
> controller. These properties can be used instead of 'uart-has-rtscts' or
> 'st,hw-flow-ctrl' (deprecated) for making use of any gpio pins for flow
> control instead of dedicated pins.
> It should be noted that both cts-gpios/rts-gpios and 'uart-has-rtscts' or
> 'st,hw-flow-ctrl' (deprecated) properties cannot co-exist in a design.
> 
> Signed-off-by: Erwan Le Ray 
> 

Acked-by: Rob Herring 

Re: [PATCH 1/5] dt-bindings: watchdog: renesas,wdt: add r8a779a0 (V3U) support

[Rob Herring]

On Fri, 18 Dec 2020 18:37:26 +0100, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang 
> ---
> 
> Please apply it to the watchdog-tree.
> 
>  Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 

Re: [PATCH] Revert "clk: imx: fix composite peripheral flags"

[Fabio Estevam]

Hi Martin,

On Thu, Dec 31, 2020 at 11:22 AM Martin Kepplinger
 wrote:
>
> This reverts commit 936c383673b9e3007432f17140ac62de53d87db9.
>
> It breaks clock reparenting via devfreq on the imx8mq used in the
> Librem 5 phone. When switching dram frequency (which worked before)
> the system now hangs after this where the dram_apb clock cannot be
> set:
>
> [  129.391755] imx8m-ddrc-devfreq 3d40.memory-controller: failed to
> set dram_apb parent: -16
> [  129.391959] imx8m-ddrc-devfreq 3d40.memory-controller: ddrc
> failed freq switch to 2500 from 8: error -16. now at 2500
> [  129.406133] imx8m-ddrc-devfreq 3d40.memory-controller: failed to
> update frequency from PM QoS (-16)

I am wondering whether IMX8MQ_CLK_DRAM_ALT should also be marked as
CLK_IS_CRITICAL.

Could you please try the following change without the revert?

--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -458,7 +458,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
 * Mark with GET_RATE_NOCACHE to always read div value from hardware
 */
hws[IMX8MQ_CLK_DRAM_CORE] =
imx_clk_hw_mux2_flags("dram_core_clk", base + 0x9800, 24, 1,
imx8mq_dram_core_sels, ARRAY_SIZE(imx8mq_dram_core_sels),
CLK_IS_CRITICAL);
-   hws[IMX8MQ_CLK_DRAM_ALT] =
__imx8m_clk_hw_composite("dram_alt", imx8mq_dram_alt_sels, base +
0xa000, CLK_GET_RATE_NOCACHE);
+   hws[IMX8MQ_CLK_DRAM_ALT] =
__imx8m_clk_hw_composite("dram_alt", imx8mq_dram_alt_sels, base +
0xa000, CLK_IS_CRITICAL | CLK_GET_RATE_NOCACHE);
hws[IMX8MQ_CLK_DRAM_APB] =
__imx8m_clk_hw_composite("dram_apb", imx8mq_dram_apb_sels, base +
0xa080, CLK_IS_CRITICAL | CLK_GET_RATE_NOCACHE);

Thanks

Re: [PATCH] ASoC: fsl: fix -Wmaybe-uninitialized warning

[Nicolin Chen]

On Wed, Dec 30, 2020 at 04:44:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> Clang points out a code path that returns an undefined value
> in an error case:
> 
> sound/soc/fsl/imx-hdmi.c:165:6: error: variable 'ret' is used uninitialized 
> whenever 'if' condition is true [-Werror,-Wsom
> etimes-uninitialized]
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> ^~~~
> sound/soc/fsl/imx-hdmi.c:212:9: note: uninitialized use occurs here
> return ret;
> 
> The driver returns -EINVAL for other broken DT properties, so do
> it the same way here.
> 
> Fixes: 6a5f850aa83a ("ASoC: fsl: Add imx-hdmi machine driver")
> Signed-off-by: Arnd Bergmann 
> ---
>  sound/soc/fsl/imx-hdmi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
> index 2c2a76a71940..ede4a9ad1054 100644
> --- a/sound/soc/fsl/imx-hdmi.c
> +++ b/sound/soc/fsl/imx-hdmi.c
> @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
>  
>   if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
>   dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
> + ret = -EINVAL;
>   goto fail;

I think Mark has already applied a fix :)
https://lkml.org/lkml/2020/12/16/275

Re: [PATCH 4.19 287/346] crypto: ecdh - avoid unaligned accesses in ecdh_set_secret()

[Pavel Machek]

Hi!

> ecdh_set_secret() casts a void* pointer to a const u64* in order to
> feed it into ecc_is_key_valid(). This is not generally permitted by
> the C standard, and leads to actual misalignment faults on ARMv6
> cores. In some cases, these are fixed up in software, but this still
> leads to performance hits that are entirely avoidable.
> 
> So let's copy the key into the ctx buffer first, which we will do
> anyway in the common case, and which guarantees correct alignment.

Fair enough... but: params.key_size is validated in
ecc_is_key_valid(), and that now happens _after_ memcpy.

How is it guaranteed that we don't overflow the buffer during memcpy?

> +++ b/crypto/ecdh.c
> @@ -57,12 +57,13 @@ static int ecdh_set_secret(struct crypto
>   return ecc_gen_privkey(ctx->curve_id, ctx->ndigits,
>  ctx->private_key);
>  
> - if (ecc_is_key_valid(ctx->curve_id, ctx->ndigits,
> -  (const u64 *)params.key, params.key_size) < 0)
> - return -EINVAL;
> -
>   memcpy(ctx->private_key, params.key, params.key_size);
>  
> + if (ecc_is_key_valid(ctx->curve_id, ctx->ndigits,
> +  ctx->private_key, params.key_size) < 0) {
> + memzero_explicit(ctx->private_key, params.key_size);
> + return -EINVAL;
> + }
>   return 0;

Best regards,
Pavel
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: Digital signature

mmotm 2020-12-31-11-52 uploaded

[akpm]

The mm-of-the-moment snapshot 2020-12-31-11-52 has been uploaded to

   https://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

https://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
https://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

https://github.com/hnaz/linux-mm

The directory https://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is also available at

https://github.com/hnaz/linux-mm



This mmotm tree contains the following patches against 5.11-rc1:
(patches marked "*" will be included in linux-next)

  origin.patch
* mm-slub-consider-rest-of-partial-list-if-acquire_slab-fails.patch
* mm-page_alloc-add-a-missing-mm_page_alloc_zone_locked-tracepoint.patch
* mm-page_alloc-add-a-missing-mm_page_alloc_zone_locked-tracepoint-fix.patch
* proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch
* proc-kpageflags-do-not-use-uninitialized-struct-pages.patch
* ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch
* ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch
* ramfs-support-o_tmpfile.patch
* fs-delete-repeated-words-in-comments.patch
* kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch
  mm.patch
* mm-tracing-record-slab-name-for-kmem_cache_free.patch
* mm-msync-exit-early-when-the-flags-is-an-ms_async-and-start-vm_start.patch
* mm-swap-dont-setpageworkingset-unconditionally-during-swapin.patch
* mm-memcg-slab-pre-allocate-obj_cgroups-for-slab-caches-with-slab_account.patch
* 
mm-memcg-slab-pre-allocate-obj_cgroups-for-slab-caches-with-slab_account-fix.patch
* mm-memcontrol-optimize-per-lruvec-stats-counter-memory-usage.patch
* 
mm-memcontrol-optimize-per-lruvec-stats-counter-memory-usage-checkpatch-fixes.patch
* mm-memcontrol-fix-nr_anon_thps-accounting-in-charge-moving.patch
* mm-memcontrol-convert-nr_anon_thps-account-to-pages.patch
* mm-memcontrol-convert-nr_file_thps-account-to-pages.patch
* mm-memcontrol-convert-nr_shmem_thps-account-to-pages.patch
* mm-memcontrol-convert-nr_shmem_pmdmapped-account-to-pages.patch
* mm-memcontrol-convert-nr_file_pmdmapped-account-to-pages.patch
* mm-memcontrol-make-the-slab-calculation-consistent.patch
* mm-memcg-revise-the-using-condition-of-lock_page_lruvec-function-series.patch
* mm-memcg-remove-rcu-locking-for-lock_page_lruvec-function-series.patch
* mm-mmap-remove-unnecessary-local-variable.patch
* mm-mmap-replace-if-cond-bug-with-bug_on.patch
* mm-mmap-fix-the-adjusted-length-error.patch
* mm-page_reporting-use-list_entry_is_head-in-page_reporting_cycle.patch
* mm-hugetlbc-fix-unnecessary-address-expansion-of-pmd-sharing.patch
* mm-huge_memoryc-update-tlb-entry-if-pmd-is-changed.patch
* mips-do-not-call-flush_tlb_all-when-setting-pmd-entry.patch
* mm-vmscan-__isolate_lru_page_prepare-clean-up.patch
* mm-compaction-remove-rcu_read_lock-during-page-compaction.patch
* mm-memblock-enforce-overlap-of-memorymemblock-and-memoryreserved.patch
* mm-fix-initialization-of-struct-page-for-holes-in-memory-layout.patch
* 
mm-fix-initialization-of-struct-page-for-holes-in-memory-layout-checkpatch-fixes.patch
* mm-hugetlb-change-hugetlb_reserve_pages-to-type-bool.patch
* hugetlbfs-remove-special-hugetlbfs_set_page_dirty.patch
* mm-make-pagecache-tagged-lookups-return-only-head-pages.patch
* mm-shmem-use-pagevec_lookup-in-shmem_unlock_mapping.patch
* mm-swap-optimise-get_shadow_from_swap_cache.patch
* mm-add-fgp_entry.patch
* mm-filemap-rename-find_get_entry-to-mapping_get_entry.patch
* mm-filemap-add-helper-for-finding-pages.patch
* mm-filemap-add-helper-for-finding-pages-fix.patch
* mm-filemap-add-mapping_seek_hole_data.patch
* mm-filemap-add-mapping_seek_hole_data-fix.patch
* iomap-use-mapping_seek_hole_data.patch
* mm-add-and-use-find_lock_entries.patch
* mm-add-and-use-find_lock_entries-fix.patch
* mm-add-an-end-parameter-to-find_get_entries.patch
* mm-add-an-end-parameter-to-pagevec_lookup_entries.patch
* mm-remove

Re: [PATCH] cifs: style: replace one-element array with flexible-array

[Steve French]

merged into cifs-2.6.git for-next

On Wed, Dec 30, 2020 at 12:37 AM YANG LI  wrote:
>
> There is a regular need in the kernel to provide a way to declare
> having a dynamically sized set of trailing elements in a structure.
> Kernel code should always use "flexible array members"[1] for these
> cases. The older style of one-element or zero-length arrays should
> no longer be used[2].
>
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] https://www.kernel.org/doc/html/v5.9/process/
> deprecated.html#zero-length-and-one-element-arrays
>
> Signed-off-by: YANG LI 
> Reported-by: Abaci 
> ---
>  fs/cifs/smb2pdu.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/smb2pdu.h b/fs/cifs/smb2pdu.h
> index 204a622..d85edf5 100644
> --- a/fs/cifs/smb2pdu.h
> +++ b/fs/cifs/smb2pdu.h
> @@ -424,7 +424,7 @@ struct smb2_rdma_transform_capabilities_context {
> __le16  TransformCount;
> __u16   Reserved1;
> __u32   Reserved2;
> -   __le16  RDMATransformIds[1];
> +   __le16  RDMATransformIds[];
>  } __packed;
>
>  /* Signing algorithms */
> --
> 1.8.3.1
>


-- 
Thanks,

Steve

Re: [PATCH v3 0/2] Kbuild: DWARF v5 support

[Sedat Dilek]

On Mon, Dec 28, 2020 at 4:15 PM Sedat Dilek  wrote:
>
> On Sun, Dec 27, 2020 at 7:47 PM Sedat Dilek  wrote:
> >
> > On Fri, Dec 4, 2020 at 2:13 AM 'Nick Desaulniers' via Clang Built
> > Linux  wrote:
> > >
> > > sigh...I ran a broken script to send the series which doesn't cc folks 
> > > properly.
> > > + lkml, linux-kbuild
> > > (Might just resend, properly)
> > >
> > > On Thu, Dec 3, 2020 at 5:11 PM Nick Desaulniers  
> > > wrote:
> > > >
> > > > DWARF v5 is the latest standard of the DWARF debug info format.
> > > >
> > > > DWARF5 wins significantly in terms of size when mixed with compression
> > > > (CONFIG_DEBUG_INFO_COMPRESSED).
> > > >
> > > > Link: http://www.dwarfstd.org/doc/DWARF5.pdf
> > > >
> > > > Patch 1 is a cleanup that lays the ground work and isn't DWARF
> > > > v5 specific.
> > > > Patch 2 implements Kconfig and Kbuild support for DWARFv5.
> > > >
> > > > Changes from v2:
> > > > * Drop two of the earlier patches that have been accepted already.
> > > > * Add measurements with GCC 10.2 to commit message.
> > > > * Update help text as per Arvind with help from Caroline.
> > > > * Improve case/wording between DWARF Versions as per Masahiro.
> > > >
> > > > Changes from the RFC:
> > > > * split patch in 3 patch series, include Fangrui's patch, too.
> > > > * prefer `DWARF vX` format, as per Fangrui.
> > > > * use spaces between assignment in Makefile as per Masahiro.
> > > > * simplify setting dwarf-version-y as per Masahiro.
> > > > * indent `prompt` in Kconfig change as per Masahiro.
> > > > * remove explicit default in Kconfig as per Masahiro.
> > > > * add comments to test_dwarf5_support.sh.
> > > > * change echo in test_dwarf5_support.sh as per Masahiro.
> > > > * remove -u from test_dwarf5_support.sh as per Masahiro.
> > > > * add a -gdwarf-5 cc-option check to Kconfig as per Jakub.
> > > >
> >

[ ... ]

Some more numbers with Linux v5.10.4.

GCC v10.2.1
GNU/ld BFDd v2.35.1
LLD v11.0.1-rc2
LLVM toolchain v11.0.1-rc2

So using GCC with LLD together with DWARF v5 reduces the binary sizes.

Looks like Gmail makes the tabella look ugly...

  | gcc10-bfd | gcc10-lld | gcc10-llvm | clang-ias
--
vmlinux.o | 580212| 504508| 504508 | 353864
--
vmlinux   | 503172| 509944| 509944 | 358500
--
dbg deb   | 701576| 606348| 607656 | 506816

...so I add the lines below.

580212  5.10.4-1-amd64-gcc10-bfd/vmlinux.o
504508  5.10.4-2-amd64-gcc10-lld/vmlinux.o
504508  5.10.4-3-amd64-gcc10-llvm/vmlinux.o
353864  5.10.4-4-amd64-clang-ias/vmlinux.o

503172  5.10.4-1-amd64-gcc10-bfd/vmlinux
509944  5.10.4-2-amd64-gcc10-lld/vmlinux
509944  5.10.4-3-amd64-gcc10-llvm/vmlinux
358500  5.10.4-4-amd64-clang-ias/vmlinux

701576  
5.10.4-1-amd64-gcc10-bfd/linux-image-5.10.4-1-amd64-gcc10-bfd-dbg_5.10.4-1~bullseye+dileks1_amd64.deb
606348  
5.10.4-2-amd64-gcc10-lld/linux-image-5.10.4-2-amd64-gcc10-lld-dbg_5.10.4-2~bullseye+dileks1_amd64.deb
607656  
5.10.4-3-amd64-gcc10-llvm/linux-image-5.10.4-3-amd64-gcc10-llvm-dbg_5.10.4-3~bullseye+dileks1_amd64.deb
506816  
5.10.4-4-amd64-clang-ias/linux-image-5.10.4-4-amd64-clang-ias-dbg_5.10.4-4~bullseye+dileks1_amd64.deb

- Sedat -

> >
> > > > Nick Desaulniers (2):
> > > >   Kbuild: make DWARF version a choice
> > > >   Kbuild: implement support for DWARF v5
> > > >
> > > >  Makefile  | 15 +++--
> > > >  include/asm-generic/vmlinux.lds.h |  6 +-
> > > >  lib/Kconfig.debug | 35 ++-
> > > >  scripts/test_dwarf5_support.sh|  9 
> > > >  4 files changed, 53 insertions(+), 12 deletions(-)
> > > >  create mode 100755 scripts/test_dwarf5_support.sh
> > > >
> > > > --
> > > > 2.29.2.576.ga3fc446d84-goog
> > > >
> > >
> > >
> > > --
> > > Thanks,
> > > ~Nick Desaulniers
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Clang Built Linux" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to clang-built-linux+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit 
> > > https://groups.google.com/d/msgid/clang-built-linux/CAKwvOdkZEiHK01OD420USb0j%3DF0LcrnRbauv9Yw26tu-GRbYkg%40mail.gmail.com.

Re: [PATCH 3/3] dt-bindings: mxsfb: add compatible for i.MX6UL/i.MX6ULL

[Rob Herring]

On Fri, Dec 18, 2020 at 03:10:35PM +0100, Sébastien Szymanski wrote:
> i.MX6UL/i.MX6ULL have eLCDIF controller, too.
> 
> Signed-off-by: Sébastien Szymanski 
> ---
>  Documentation/devicetree/bindings/display/mxsfb.txt | 1 +
>  1 file changed, 1 insertion(+)

This will need to be rebased on this:

https://lore.kernel.org/dri-devel/20201007012438.27970-2-laurent.pinch...@ideasonboard.com/

Re: [PATCH 1/2] Documentation: devicetree: Add new compatible string for eeprom microchip 93LC46B

[Rob Herring]

On Fri, Dec 18, 2020 at 07:38:10PM +0530, Aswath Govindraju wrote:
> Add a new compatible string for eeprom microchip 93LC46B in eeprom-93xx46
> dt-binding file as it belongs to the 93xx46 family of devices.
> 
> Signed-off-by: Aswath Govindraju 
> ---
>  Documentation/devicetree/bindings/misc/eeprom-93xx46.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt 
> b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
> index a8ebb4621f79..9f272361f117 100644
> --- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
> +++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
> @@ -4,6 +4,7 @@ Required properties:
>  - compatible : shall be one of:
>  "atmel,at93c46d"
>  "eeprom-93xx46"
> +"microchip,93LC46B"

Generally, we use lowercase and that's the existing pattern here.

>  - data-size : number of data bits per word (either 8 or 16)
>  
>  Optional properties:
> -- 
> 2.17.1
> 

Re: [PATCH 1/8] dt-binding: watchdog: add more Rockchip compatibles to snps, dw-wdt.yaml

[Rob Herring]

On Fri, 18 Dec 2020 13:05:27 +0100, Johan Jonker wrote:
> The watchdog compatible strings are suppose to be SoC orientated.
> In the more recently added Rockchip SoC dtsi files only
> the fallback string "snps,dw-wdt" is used, so add the following
> compatible strings:
> 
> "rockchip,px30-wdt", "snps,dw-wdt"
> "rockchip,rk3228-wdt", "snps,dw-wdt"
> "rockchip,rk3308-wdt", "snps,dw-wdt"
> "rockchip,rk3328-wdt", "snps,dw-wdt"
> "rockchip,rk3399-wdt", "snps,dw-wdt"
> "rockchip,rv1108-wdt", "snps,dw-wdt"
> 
> make ARCH=arm dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
> 
> make ARCH=arm64 dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
> 
> Signed-off-by: Johan Jonker 
> ---
>  Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml | 6 ++
>  1 file changed, 6 insertions(+)
> 

Acked-by: Rob Herring 

Re: [PATCH 1/5] dt-bindings: remoteproc: Add PRU consumer bindings

[Rob Herring]

On Tue, Dec 22, 2020 at 8:57 AM Grzegorz Jaszczyk
 wrote:
>
> Hi Rob,
>
> On Fri, 18 Dec 2020 at 23:51, Rob Herring  wrote:
> >
> > On Wed, Dec 16, 2020 at 9:55 AM Grzegorz Jaszczyk
> >  wrote:
> > >
> > > Hi Rob,
> > >
> > > On Mon, 14 Dec 2020 at 23:58, Rob Herring  wrote:
> > > >
> > > > On Fri, Dec 11, 2020 at 03:29:29PM +0100, Grzegorz Jaszczyk wrote:
> > > > > From: Suman Anna 
> > > > >
> > > > > Add a YAML binding document for PRU consumers. The binding includes
> > > > > all the common properties that can be used by different PRU consumer
> > > > > or application nodes and supported by the PRU remoteproc driver.
> > > > > These are used to configure the PRU hardware for specific user
> > > > > applications.
> > > > >
> > > > > The application nodes themselves should define their own bindings.
> > > > >
> > > > > Co-developed-by: Tero Kristo 
> > > > > Signed-off-by: Tero Kristo 
> > > > > Signed-off-by: Suman Anna 
> > > > > Co-developed-by: Grzegorz Jaszczyk 
> > > > > Signed-off-by: Grzegorz Jaszczyk 
> > > > > ---
> > > > >  .../bindings/remoteproc/ti,pru-consumer.yaml  | 64 
> > > > > +++
> > > > >  1 file changed, 64 insertions(+)
> > > > >  create mode 100644 
> > > > > Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > > >
> > > > > diff --git 
> > > > > a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml 
> > > > > b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > > > new file mode 100644
> > > > > index ..2c5c5e2b6159
> > > > > --- /dev/null
> > > > > +++ 
> > > > > b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > > > > @@ -0,0 +1,64 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Common TI PRU Consumer Binding
> > > > > +
> > > > > +maintainers:
> > > > > +  - Suman Anna 
> > > > > +
> > > > > +description: |
> > > > > +  A PRU application/consumer/user node typically uses one or more 
> > > > > PRU device
> > > > > +  nodes to implement a PRU application/functionality. Each 
> > > > > application/client
> > > > > +  node would need a reference to at least a PRU node, and optionally 
> > > > > define
> > > > > +  some properties needed for hardware/firmware configuration. The 
> > > > > below
> > > > > +  properties are a list of common properties supported by the PRU 
> > > > > remoteproc
> > > > > +  infrastructure.
> > > > > +
> > > > > +  The application nodes shall define their own bindings like regular 
> > > > > platform
> > > > > +  devices, so below are in addition to each node's bindings.
> > > > > +
> > > > > +properties:
> > > > > +  prus:
> > > >
> > > > ti,prus
> > >
> > > Thank you - I will change and post v2 but with this I will run into
> > > issues when this binding will be referenced by some consumer YAML
> > > binding. Running dtbs_check in such case throws:
> > > ... k3-am654-base-board.dt.yaml: serial@28000: 'ti,prus' does not
> > > match any of the regexes: 'pinctrl-[0-9]+'
> > > In the same time if I will remove this property from that node I am 
> > > getting:
> > > ... k3-am654-base-board.dt.yaml: serial@28000: 'ti,prus' is a required 
> > > property
> > > as expected.
> >
> > Sounds like you didn't update 'ti,prus' in whatever schema you include
> > this one from.
> >
> > >
> > > Getting rid of the comma from this property name workarounds mentioned
> > > problem (which is not proper but allows me to correctly test this
> > > binding): e.g. s/ti,prus/ti-pruss/ or using the previous name without
> > > a comma.
> > > It seems to be an issue with dtbs_check itself which we will encounter
> > > in the future.
> >
> > If not, can you point me to a branch having this problem.
>
> Sure, here is temporary branch with 4 last commits demonstrating
> mentioned issues (when property name contains comma):
> https://git.linaro.org/people/grzegorz.jaszczyk/linux.git/log/?h=ti-pruss-binding-issue
>
> The last commit gets rid of the comma from properties names which
> successfully w/a the problem.
>
> Please note that those are only TEMP commits which demonstrates the
> mentioned issue. I've put error logs with some notes in commit log to
> ease understanding what issues are seen when.

The problem is any property with a vendor prefix has to define a type.
There's not a way to define a 'common vendor property' and distinguish
both cases in the meta-schemas. I'd like to come up with a more robust
mechanism where we just detect if a property has a defined type or
not. It should be possible to extract that. (Related, I also want to
check for conflicting types.)

How many cases of 'ti,prus' do you expect to have and what's the range
of number of phandles? Either you should just not have the common
schema and just define the properties in eac

Re: [PATCH v2] dt-bindings: display: bridge: tc358768: Change maintainer information

[Rob Herring]

On Fri, 18 Dec 2020 10:35:22 +0200, Peter Ujfalusi wrote:
> My employment with TI is coming to an end and I will not have access to
> the board where this bridge is connected to and I will also loose access to
> the manual of the chip.
> 
> Add the missing copyright information, author and change the maintainer to
> Sam Ravnborg (thank you for volenteering!)
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml  | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring 

[PATCH] sound: Convert strlcpy to strscpy when return value is unused

[Joe Perches]

strlcpy is deprecated.  see: Documentation/process/deprecated.rst

Change the calls that do not use the strlcpy return value to the
preferred strscpy.

Done with cocci script:

@@
expression e1, e2, e3;
@@

-   strlcpy(
+   strscpy(
e1, e2, e3);

This cocci script leaves the instances where the return value is
used unchanged.

After this patch, sound/ has 3 uses of strlcpy() that need to be
manually inspected for conversion and changed one day.

$ git grep -w strlcpy sound/
sound/usb/card.c:   len = strlcpy(card->longname, s, 
sizeof(card->longname));
sound/usb/mixer.c:  return strlcpy(buf, p->name, buflen);
sound/usb/mixer.c:  return strlcpy(buf, p->names[index], 
buflen);

Miscellenea:

o Remove trailing whitespace in conversion of sound/core/hwdep.c

Link: 
https://lore.kernel.org/lkml/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/

Signed-off-by: Joe Perches 
---
 sound/aoa/codecs/onyx.c|  2 +-
 sound/aoa/codecs/tas.c |  2 +-
 sound/aoa/codecs/toonie.c  |  2 +-
 sound/aoa/core/alsa.c  |  8 
 sound/aoa/fabrics/layout.c |  6 +++---
 sound/aoa/soundbus/sysfs.c |  2 +-
 sound/arm/aaci.c   |  6 +++---
 sound/arm/pxa2xx-ac97.c|  2 +-
 sound/core/compress_offload.c  |  2 +-
 sound/core/control.c   | 16 
 sound/core/ctljack.c   |  2 +-
 sound/core/hwdep.c |  6 +++---
 sound/core/init.c  |  4 ++--
 sound/core/oss/mixer_oss.c | 12 ++--
 sound/core/pcm.c   |  2 +-
 sound/core/pcm_native.c|  6 +++---
 sound/core/rawmidi.c   |  2 +-
 sound/core/seq/oss/seq_oss_midi.c  |  4 ++--
 sound/core/seq/oss/seq_oss_synth.c |  6 +++---
 sound/core/seq/seq_clientmgr.c |  2 +-
 sound/core/seq/seq_ports.c |  6 +++---
 sound/core/timer.c | 10 +-
 sound/core/timer_compat.c  |  4 ++--
 sound/drivers/opl3/opl3_oss.c  |  2 +-
 sound/drivers/opl3/opl3_synth.c|  2 +-
 sound/firewire/bebob/bebob_hwdep.c |  2 +-
 sound/firewire/dice/dice-hwdep.c   |  2 +-
 sound/firewire/digi00x/digi00x-hwdep.c |  2 +-
 sound/firewire/fireface/ff-hwdep.c |  2 +-
 sound/firewire/fireworks/fireworks_hwdep.c |  2 +-
 sound/firewire/motu/motu-hwdep.c   |  2 +-
 sound/firewire/oxfw/oxfw-hwdep.c   |  2 +-
 sound/firewire/tascam/tascam-hwdep.c   |  2 +-
 sound/i2c/i2c.c|  4 ++--
 sound/isa/ad1848/ad1848.c  |  4 ++--
 sound/isa/cs423x/cs4231.c  |  4 ++--
 sound/isa/cs423x/cs4236.c  |  4 ++--
 sound/isa/es1688/es1688.c  |  4 ++--
 sound/isa/sb/sb16_csp.c|  2 +-
 sound/isa/sb/sb_mixer.c|  2 +-
 sound/oss/dmasound/dmasound_core.c |  4 ++--
 sound/pci/cs5535audio/cs5535audio_olpc.c   |  4 ++--
 sound/pci/ctxfi/ctpcm.c|  2 +-
 sound/pci/emu10k1/emu10k1.c|  4 ++--
 sound/pci/emu10k1/emu10k1_main.c   |  2 +-
 sound/pci/emu10k1/emufx.c  |  6 +++---
 sound/pci/es1968.c |  2 +-
 sound/pci/fm801.c  |  2 +-
 sound/pci/hda/hda_auto_parser.c|  2 +-
 sound/pci/hda/hda_codec.c  |  2 +-
 sound/pci/hda/hda_controller.c |  2 +-
 sound/pci/hda/hda_eld.c|  2 +-
 sound/pci/hda/hda_generic.c|  2 +-
 sound/pci/hda/hda_intel.c  |  2 +-
 sound/pci/hda/hda_jack.c   |  2 +-
 sound/pci/ice1712/juli.c   |  2 +-
 sound/pci/ice1712/psc724.c |  4 ++--
 sound/pci/ice1712/quartet.c|  2 +-
 sound/pci/ice1712/wm8776.c |  2 +-
 sound/pci/lola/lola.c  |  2 +-
 sound/pci/lola/lola_pcm.c  |  2 +-
 sound/pci/rme9652/hdspm.c  |  2 +-
 sound/ppc/keywest.c|  2 +-
 sound/soc/qcom/qdsp6/q6afe.c   |  2 +-
 sound/soc/sh/rcar/core.c   |  2 +-
 sound/usb/bcd2000/bcd2000.c|  2 +-
 sound/usb/caiaq/audio.c|  2 +-
 sound/usb/caiaq/device.c   |  6 +++---
 sound/usb/caiaq/midi.c |  2 +-
 sound/usb/card.c   |  4 ++--
 sound/usb/hiface/chip.c|  6 +++---
 sound/usb/hiface/pcm.c |  2 +-
 sound/usb/mixer.c  | 12 ++--
 sound/usb/mixer_quirks.c   |  2 +-
 sound/usb/mixer_scarlett.c |  2 +-
 sound/usb/mixer_scarlett_gen2.c

Re: [PATCH v5 2/9] dt-bindings: spi: Add Tegra Quad SPI device tree binding

[Rob Herring]

On Mon, 21 Dec 2020 13:17:32 -0800, Sowjanya Komatineni wrote:
> This patch adds YAML based device tree binding document for Tegra
> Quad SPI driver.
> 
> Signed-off-by: Sowjanya Komatineni 
> ---
>  .../bindings/spi/nvidia,tegra210-quad.yaml | 117 
> +
>  1 file changed, 117 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
> 


Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

If a tag was not added on purpose, please state why and what changed.

Re: [PATCH v2] PCI: dwc: Fix MSI not work after resume

[Rob Herring]

On Mon, Dec 28, 2020 at 8:36 PM Jisheng Zhang
 wrote:
>
> After we move dw_pcie_msi_init() into core -- dw_pcie_host_init(), the
> MSI stops working after resume. Because dw_pcie_host_init() is only
> called once during probe. To fix this issue, we move dw_pcie_msi_init()
> to dw_pcie_setup_rc().
>
> Fixes: 59fbab1ae40e ("PCI: dwc: Move dw_pcie_msi_init() into core")
> Signed-off-by: Jisheng Zhang 
> ---
>
> Since v1:
>  - rebased on 5.11-rc1
>  - add Fixes tag
>
>  drivers/pci/controller/dwc/pcie-designware-host.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Bjorn, please pick up for 5.11.

Rob

Re: C/C++ Code Reviewer Available

[Theodore Ts'o]

On Wed, Dec 30, 2020 at 11:45:58PM -0800, Robin Rowe wrote:
> "Linux kernel's Kroah-Hartman: We're not struggling to get new coders, it's
> code review that's the bottleneck", says article at The Register.
> 
> Ok, I've used C++ for 20 years, taught C/C++ at two universities, and
> developed real-time safety-critical systems. Need me? Contact me off-list.

Hi Robin,

It's great that you expressed an interest in contributing to the Linux
kernel!

How much experience do you have with Linux kernel coding?  Most code
reviewers specialize in a particular kernel subsystem, and often get
their start submitting patches as part of coming up to speed with that
particular subsystem so that a subsystem maintainer knows how much
they can trust a particular code review.

The real challenge is that we have plenty of people who are
enthusiastic about submitting whitespace patches and drive-by
checkpatch fixes, and/or submitting new drives or other features for
their particular employer, but we need to get them to graduate from
being entry-level coders, to being people who become senior developers
who can perform trusted code reviews --- and for their employers to
allow them to spend company time contributing back to the community.

Or for people who are willing to spend their own time on nights and
weekend doing this sort of code review work and/or bug fixes and/or
reviewing issues reported by fuzz testers or static code analyizers,
instead of just focusing on features that aren't part of drivers or
features that their companies need for their own short-term business
interest.  This does happen of course, for people who have become
super-passionate about contributing to the subsystem and the kernel
community at large, but there are many people who just submit device
drivers and/or specific kernel features because it's part of their 9-5
job.

This is most of what maintainers and other senior developers do; it's
the less glamorous "scut work" that fewer people are interested in ---
including implementing regression test frameworks, improving subsystem
documentation, investigating fuzz reports and hard-to-reproduce flaky
tests, helping to mentor and train newer engineers, and yes, code
review.  It's what's called servant-leadership.  :-)

Cheers,

- Ted

Re: [PATCH 4.19 267/346] ALSA: hda/ca0132 - Change Input Source enum strings.

[Pavel Machek]

Hi!

> From: Connor McAdams 
> 
> commit 7079f785b50055a32b72eddcb7d9ba5688db24d0 upstream.
> 
> Change the Input Source enumerated control's strings to make it play
> nice with pulseaudio.

> +++ b/sound/pci/hda/patch_ca0132.c
> @@ -106,7 +106,7 @@ enum {
>  };
>  
>  /* Strings for Input Source Enum Control */
> -static const char *const in_src_str[3] = {"Rear Mic", "Line", "Front Mic" };
> +static const char *const in_src_str[3] = { "Microphone", "Line In", "Front 
> Microphone" };
>  #define IN_SRC_NUM_OF_INPUTS 3

If pulseaudio expects the strings to be from small set, should we have
defines for them?

If pulseaudio can't understand short versions, do these need fixing,
too?

hda_auto_parser.c:  "Internal Mic", "Dock Mic", "Mic", "Rear Mic", 
"Front Mic"
hda_auto_parser.c:  return "Headset Mic";
hda_auto_parser.c:  return "Headphone Mic";
hda_auto_parser.c:  return "Mic";
hda_auto_parser.c:  return "Headphone Mic";
hda_jack.c: cfg, "Headphone 
Mic");
hda_jack.c: cfg, "Headphone 
Mic");
hda_proc.c: "Line In", "Aux", "Mic", "Telephony",

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [PATCH 2/5] dt-bindings: Amlogic: add the documentation for the SECBUS2 registers

[Rob Herring]

On Wed, Dec 30, 2020 at 02:27:21AM +0100, Martin Blumenstingl wrote:
> The Meson8/Meson8b/Meson8m2 SoCs have a register bank called SECBUS2 which
> contains registers for various IP blocks such as pin-controller bits for
> the BSD_EN and TEST_N GPIOs as well as some AO ARC core control bits.
> The registers can be accessed directly when not running in "secure mode".
> When "secure mode" is enabled then these registers have to be accessed
> through secure monitor calls.
> 
> So far these SoCs are always known to boot in "non-secure mode".
> Add a binding documentation using syscon (as these registers are shared
> across different IPs) for the SECBUS2 registers.
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  .../arm/amlogic/amlogic,meson-mx-secbus2.yaml | 53 +++
>  1 file changed, 53 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml 
> b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
> new file mode 100644
> index ..cfa8e9de6c28
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-mx-secbus2.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: Amlogic Meson8/Meson8b/Meson8m2 SECBUS2 register interface
> +
> +maintainers:
> +  - Martin Blumenstingl 
> +
> +description: |
> +  The Meson8/Meson8b/Meson8m2 SoCs have a register bank called SECBUS2 which
> +  contains registers for various IP blocks such as pin-controller bits for
> +  the BSD_EN and TEST_N GPIOs as well as some AO ARC core control bits.
> +  The registers can be accessed directly when not running in "secure mode".
> +  When "secure mode" is enabled then these registers have to be accessed
> +  through secure monitor calls.
> +
> +# We need a select here so we don't match all nodes with 'syscon'

No, you don't. The default 'select' will ignore 'syscon' and 
'simple-mfd'.

> +select:
> +  properties:
> +compatible:
> +  contains:
> +enum:
> +  - amlogic,meson8-secbus2
> +  - amlogic,meson8b-secbus2
> +  required:
> +- compatible
> +
> +properties:
> +  compatible:
> +items:
> +  - enum:
> +- amlogic,meson8-secbus2
> +- amlogic,meson8b-secbus2
> +  - const: syscon
> +
> +  reg:
> +maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +secbus2: system-controller@4000 {
> +  compatible = "amlogic,meson8-secbus2", "syscon";
> +  reg = <0x4000 0x2000>;
> +};
> -- 
> 2.30.0
> 

Re: [PATCH v10 1/7] [v10,1/7]: dt-bindings: soc: mediatek: add mtk svs dt-bindings

[Rob Herring]

On Sun, Dec 27, 2020 at 06:54:43PM +0800, Roger Lu wrote:
> Document the binding for enabling mtk svs on MediaTek SoC.
> 
> Signed-off-by: Roger Lu 
> ---
>  .../bindings/soc/mediatek/mtk-svs.yaml| 75 +++
>  1 file changed, 75 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml 
> b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> new file mode 100644
> index ..9c7da0acd82f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
> @@ -0,0 +1,75 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/mediatek/mtk-svs.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Introduce MTK SVS engine
> +
> +maintainers:
> +  - Matthias Brugger 
> +  - Kevin Hilman 
> +  - Nishanth Menon 
> +
> +description: |+
> +  The Smart Voltage Scaling(SVS) engine is a piece of hardware
> +  which has several controllers(banks) for calculating suitable
> +  voltage to different power domains(CPU/GPU/CCI) according to
> +  chip process corner, temperatures and other factors. Then DVFS
> +  driver could apply SVS bank voltage to PMIC/Buck.
> +
> +properties:
> +  compatible:
> +enum:
> +  - mediatek,mt8183-svs
> +
> +  reg:
> +description: Address range of the MTK SVS controller.

Drop. That doesn't really add anything.

> +maxItems: 1
> +
> +  interrupts:
> +description: IRQ for the MTK SVS controller.

Drop.

> +maxItems: 1
> +
> +  clocks:
> +description: Main clock for MTK SVS controller to work.

Drop, but you need:

maxItems: 1

> +
> +  clock-names:
> +const: main
> +
> +  nvmem-cells:
> +maxItems: 2
> +description:
> +  Phandle to the calibration data provided by a nvmem device.

Drop.

> +
> +  nvmem-cell-names:
> +items:
> +  - const: svs-calibration-data
> +  - const: t-calibration-data
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +  - nvmem-cells
> +  - nvmem-cell-names
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +#include 
> +
> +svs: svs@1100b000 {
> +compatible = "mediatek,mt8183-svs";
> +reg = <0 0x1100b000 0 0x1000>;
> +interrupts = ;
> +clocks = <&infracfg CLK_INFRA_THERM>;
> +clock-names = "main";
> +nvmem-cells = <&svs_calibration>, <&thermal_calibration>;
> +nvmem-cell-names = "svs-calibration-data", "t-calibration-data";
> +};
> -- 
> 2.18.0
> 

Re: [PATCH 1/2] ASoC: SOF: Intel: hda: Modify existing helper to disable WAKEEN

[Kai-Heng Feng]

On Thu, Dec 31, 2020 at 6:52 PM Takashi Iwai  wrote:
>
> On Tue, 29 Dec 2020 14:38:14 +0100,
> Kai-Heng Feng wrote:
> >
> > Modify hda_codec_jack_wake_enable() to also support disable WAKEEN.
> > This is a preparation for next patch.
> >
> > No functional change intended.
>
> Maybe it's better to mention that this patch moves the WAKEEN
> disablement call out of hda_codec_jack_check() into
> hda_codec_jack_wake_enable(), too.

Ok, will update the commit log in v2.

Kai-Heng

>
>
> thanks,
>
> Takashi
>
> >
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >  sound/soc/sof/intel/hda-codec.c | 16 +++-
> >  sound/soc/sof/intel/hda-dsp.c   |  6 --
> >  sound/soc/sof/intel/hda.h   |  2 +-
> >  3 files changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/sound/soc/sof/intel/hda-codec.c 
> > b/sound/soc/sof/intel/hda-codec.c
> > index 6875fa570c2c..bc9ac4abdab5 100644
> > --- a/sound/soc/sof/intel/hda-codec.c
> > +++ b/sound/soc/sof/intel/hda-codec.c
> > @@ -63,16 +63,18 @@ static int hda_codec_load_module(struct hda_codec 
> > *codec)
> >  }
> >
> >  /* enable controller wake up event for all codecs with jack connectors */
> > -void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev)
> > +void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev, bool enable)
> >  {
> >   struct hda_bus *hbus = sof_to_hbus(sdev);
> >   struct hdac_bus *bus = sof_to_bus(sdev);
> >   struct hda_codec *codec;
> >   unsigned int mask = 0;
> >
> > - list_for_each_codec(codec, hbus)
> > - if (codec->jacktbl.used)
> > - mask |= BIT(codec->core.addr);
> > + if (enable) {
> > + list_for_each_codec(codec, hbus)
> > + if (codec->jacktbl.used)
> > + mask |= BIT(codec->core.addr);
> > + }
> >
> >   snd_hdac_chip_updatew(bus, WAKEEN, STATESTS_INT_MASK, mask);
> >  }
> > @@ -81,12 +83,8 @@ void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev)
> >  void hda_codec_jack_check(struct snd_sof_dev *sdev)
> >  {
> >   struct hda_bus *hbus = sof_to_hbus(sdev);
> > - struct hdac_bus *bus = sof_to_bus(sdev);
> >   struct hda_codec *codec;
> >
> > - /* disable controller Wake Up event*/
> > - snd_hdac_chip_updatew(bus, WAKEEN, STATESTS_INT_MASK, 0);
> > -
> >   list_for_each_codec(codec, hbus)
> >   /*
> >* Wake up all jack-detecting codecs regardless whether an 
> > event
> > @@ -97,7 +95,7 @@ void hda_codec_jack_check(struct snd_sof_dev *sdev)
> > codec->jackpoll_interval);
> >  }
> >  #else
> > -void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev) {}
> > +void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev, bool enable) {}
> >  void hda_codec_jack_check(struct snd_sof_dev *sdev) {}
> >  #endif /* CONFIG_SND_SOC_SOF_HDA_AUDIO_CODEC */
> >  EXPORT_SYMBOL_NS(hda_codec_jack_wake_enable, SND_SOC_SOF_HDA_AUDIO_CODEC);
> > diff --git a/sound/soc/sof/intel/hda-dsp.c b/sound/soc/sof/intel/hda-dsp.c
> > index 2b001151fe37..7d00107cf3b2 100644
> > --- a/sound/soc/sof/intel/hda-dsp.c
> > +++ b/sound/soc/sof/intel/hda-dsp.c
> > @@ -617,7 +617,7 @@ static int hda_suspend(struct snd_sof_dev *sdev, bool 
> > runtime_suspend)
> >
> >  #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA)
> >   if (runtime_suspend)
> > - hda_codec_jack_wake_enable(sdev);
> > + hda_codec_jack_wake_enable(sdev, true);
> >
> >   /* power down all hda link */
> >   snd_hdac_ext_bus_link_power_down_all(bus);
> > @@ -683,8 +683,10 @@ static int hda_resume(struct snd_sof_dev *sdev, bool 
> > runtime_resume)
> >
> >  #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA)
> >   /* check jack status */
> > - if (runtime_resume)
> > + if (runtime_resume) {
> > + hda_codec_jack_wake_enable(sdev, false);
> >   hda_codec_jack_check(sdev);
> > + }
> >
> >   /* turn off the links that were off before suspend */
> >   list_for_each_entry(hlink, &bus->hlink_list, list) {
> > diff --git a/sound/soc/sof/intel/hda.h b/sound/soc/sof/intel/hda.h
> > index 9ec8ae0fd649..a3b6f3e9121c 100644
> > --- a/sound/soc/sof/intel/hda.h
> > +++ b/sound/soc/sof/intel/hda.h
> > @@ -650,7 +650,7 @@ void sof_hda_bus_init(struct hdac_bus *bus, struct 
> > device *dev);
> >   */
> >  void hda_codec_probe_bus(struct snd_sof_dev *sdev,
> >bool hda_codec_use_common_hdmi);
> > -void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev);
> > +void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev, bool enable);
> >  void hda_codec_jack_check(struct snd_sof_dev *sdev);
> >
> >  #endif /* CONFIG_SND_SOC_SOF_HDA */
> > --
> > 2.29.2
> >

Re: [PATCH 2/2] ASoC: SOF: Intel: hda: Avoid checking jack on system suspend

[Kai-Heng Feng]

On Thu, Dec 31, 2020 at 6:55 PM Takashi Iwai  wrote:
>
> On Tue, 29 Dec 2020 14:38:15 +0100,
> Kai-Heng Feng wrote:
> >
> > System takes a very long time to suspend after commit 215a22ed31a1
> > ("ALSA: hda: Refactor codec PM to use direct-complete optimization"):
> > [   90.065964] PM: suspend entry (s2idle)
> > [   90.067337] Filesystems sync: 0.001 seconds
> > [   90.185758] Freezing user space processes ... (elapsed 0.002 seconds) 
> > done.
> > [   90.188713] OOM killer disabled.
> > [   90.188714] Freezing remaining freezable tasks ... (elapsed 0.001 
> > seconds) done.
> > [   90.190024] printk: Suspending console(s) (use no_console_suspend to 
> > debug)
> > [   90.904912] intel_pch_thermal :00:12.0: CPU-PCH is cool [49C], 
> > continue to suspend
> > [  321.262505] snd_hda_codec_realtek ehdaudio0D0: Unable to sync register 
> > 0x2b8000. -5
> > [  328.426919] snd_hda_codec_realtek ehdaudio0D0: Unable to sync register 
> > 0x2b8000. -5
> > [  329.490933] ACPI: EC: interrupt blocked
> >
> > That commit keeps codec suspended during the system suspend. However,
> > SOF driver's runtime resume, which is for system suspend, calls
> > hda_codec_jack_check() and schedules jackpoll_work. The jackpoll
> > work uses snd_hda_power_up_pm() which tries to resume the codec in
> > system suspend path, hence blocking the suspend process.
> >
> > So only check jack status if it's not in system PM process.
>
> After your previous patch set, the legacy HDA does queue the
> jackpoll_work only if jackpoll_interval is set.  I suppose rather the
> same rule would be applied?

It's queued in hda_codec_pm_complete(), which happens at the end of PM process.
This one is queued in the middle of PM suspend, so it's not the same here.

Kai-Heng

>
>
> thanks,
>
> Takashi
>
> >
> > Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete 
> > optimization")
> > Signed-off-by: Kai-Heng Feng 
> > ---
> >  sound/soc/sof/intel/hda-dsp.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/sof/intel/hda-dsp.c b/sound/soc/sof/intel/hda-dsp.c
> > index 7d00107cf3b2..1c5e05b88a90 100644
> > --- a/sound/soc/sof/intel/hda-dsp.c
> > +++ b/sound/soc/sof/intel/hda-dsp.c
> > @@ -685,7 +685,8 @@ static int hda_resume(struct snd_sof_dev *sdev, bool 
> > runtime_resume)
> >   /* check jack status */
> >   if (runtime_resume) {
> >   hda_codec_jack_wake_enable(sdev, false);
> > - hda_codec_jack_check(sdev);
> > + if (sdev->system_suspend_target == SOF_SUSPEND_NONE)
> > + hda_codec_jack_check(sdev);
> >   }
> >
> >   /* turn off the links that were off before suspend */
> > --
> > 2.29.2
> >

Re: [PATCH] i3c/master/mipi-i3c-hci: Fix position of __maybe_unused in i3c_hci_of_match

[Alexandre Belloni]

On Mon, 21 Dec 2020 19:59:31 -0700, Nathan Chancellor wrote:
> Clang warns:
> 
>  ../drivers/i3c/master/mipi-i3c-hci/core.c:780:21: warning: attribute
>  declaration must precede definition [-Wignored-attributes]
>  static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
>  ^
>  ../include/linux/compiler_attributes.h:267:56: note: expanded from macro
>  '__maybe_unused'
>  #define __maybe_unused  __attribute__((__unused__))
> ^
>  ../include/linux/mod_devicetable.h:262:8: note: previous definition is
>  here
>  struct of_device_id {
> ^
> 1 warning generated.
> 
> [...]

Applied, thanks!

[1/1] i3c/master/mipi-i3c-hci: Fix position of __maybe_unused in 
i3c_hci_of_match
  commit: 291b5c9870fc546376d69cf792b7885cd0c9c1b3

Best regards,
-- 
Alexandre Belloni 

[PATCH net] net: lapb: Decrease the refcount of "struct lapb_cb" in lapb_device_event

[Xie He]

In lapb_device_event, lapb_devtostruct is called to get a reference to
an object of "struct lapb_cb". lapb_devtostruct increases the refcount
of the object and returns a pointer to it. However, we didn't decrease
the refcount after we finished using the pointer. This patch fixes this
problem.

Fixes: a4989fa91110 ("net/lapb: support netdev events")
Cc: Martin Schiller 
Signed-off-by: Xie He 
---
 net/lapb/lapb_iface.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/lapb/lapb_iface.c b/net/lapb/lapb_iface.c
index 213ea7abc9ab..40961889e9c0 100644
--- a/net/lapb/lapb_iface.c
+++ b/net/lapb/lapb_iface.c
@@ -489,6 +489,7 @@ static int lapb_device_event(struct notifier_block *this, 
unsigned long event,
break;
}
 
+   lapb_put(lapb);
return NOTIFY_DONE;
 }
 
-- 
2.27.0

Re: [PATCH 1/4] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips

[Andrew Lunn]

> > Looking at sfp_module_info(), adding a check for i2c_block_size < 2
> > when determining what length to return. ethtool should do the right
> > thing, know that the second page has not been returned to user space.
> 
> But if we limit length of eeprom then userspace would not be able to
> access those TX_DISABLE, LOS and other bits from byte 110 at address A2.

Have you tested these bits to see if they actually work? If they don't
work...

 Andrew

Re: [PATCH v3 00/13] Add CMU/RMU/DMA/MMC/I2C support for Actions Semi

[Manivannan Sadhasivam]

On 31 December 2020 2:42:02 PM IST, Cristian Ciocaltea 
 wrote:
>On Thu, Dec 31, 2020 at 01:24:35PM +0530, Manivannan Sadhasivam wrote:
>> On Tue, Dec 29, 2020 at 11:17:15PM +0200, Cristian Ciocaltea wrote:
>> > Hi,
>> > 
>> > This patchset brings a series of improvements for the Actions Semi
>S500
>> > SoCs family, by adding support for Clock & Reset Management Units,
>DMA,
>> > MMC, I2C & SIRQ controllers.
>> > 
>> > Please note the patches consist mostly of DTS and
>bindings/compatibles
>> > changes, since all the work they depend on has been already merged,
>> > i.e. clock fixes/additions, pinctrl driver, sirq driver.
>> > 
>> > For the moment, I have only enabled the features I could test on
>> > RoseapplePi SBC.
>> > 
>> 
>> Applied all patches except the 2 dmaengine patches for v5.12.
>Andreas, please
>> let me know if you want to do the PR this time. Else I'll proceed.
>
>Thank you, Mani!
>The dmaengine patches should be picked up by Vinod, right?
>

Yes! Vinod is just back from vacation, so he will :) 

Thanks, 
Mani

>> Thanks,
>> Mani
>> 
>> > Thanks,
>> > Cristi
>> > 
>> > Changes in v3:
>> > - Squashed 'arm: dts: owl-s500-roseapplepi: Use UART clock from
>CMU' with
>> >   'arm: dts: owl-s500: Set CMU clocks for UARTs', according to
>Mani's review
>> > - Rebased series on v5.11-rc1 and dropped the already merged
>patches:
>> >  * dt-bindings: mmc: owl: Add compatible string for Actions Semi
>S500 SoC
>> >  * dt-bindings: i2c: owl: Convert Actions Semi Owl binding to a
>schema
>> >  * MAINTAINERS: Update entry for Actions Semi Owl I2C binding
>> >  * i2c: owl: Add compatible for the Actions Semi S500 I2C
>controller
>> > 
>> > Changes in v2:
>> > - Added new bindings/compatibles for S500 DMA, MMC & I2C
>controllers
>> > - Added support for the SIRQ controller
>> > - Added new entries in MAINTAINERS
>> > - Updated naming of some patches in v1
>> > 
>> > Cristian Ciocaltea (13):
>> >   arm: dts: owl-s500: Add Clock Management Unit
>> >   arm: dts: owl-s500: Set CMU clocks for UARTs
>> >   arm: dts: owl-s500: Add Reset controller
>> >   dt-bindings: dma: owl: Add compatible string for Actions Semi
>S500 SoC
>> >   dmaengine: owl: Add compatible for the Actions Semi S500 DMA
>> > controller
>> >   arm: dts: owl-s500: Add DMA controller
>> >   arm: dts: owl-s500: Add pinctrl & GPIO support
>> >   arm: dts: owl-s500: Add MMC support
>> >   arm: dts: owl-s500: Add I2C support
>> >   arm: dts: owl-s500: Add SIRQ controller
>> >   arm: dts: owl-s500-roseapplepi: Add uSD support
>> >   arm: dts: owl-s500-roseapplepi: Add I2C pinctrl configuration
>> >   MAINTAINERS: Add linux-actions ML for Actions Semi Arch
>> > 
>> >  .../devicetree/bindings/dma/owl-dma.yaml  |   7 +-
>> >  MAINTAINERS   |   1 +
>> >  arch/arm/boot/dts/owl-s500-cubieboard6.dts|   7 -
>> >  .../arm/boot/dts/owl-s500-guitar-bb-rev-b.dts |   7 -
>> >  .../arm/boot/dts/owl-s500-labrador-base-m.dts |   7 -
>> >  arch/arm/boot/dts/owl-s500-roseapplepi.dts|  97 +++-
>> >  arch/arm/boot/dts/owl-s500-sparky.dts |   7 -
>> >  arch/arm/boot/dts/owl-s500.dtsi   | 140
>++
>> >  drivers/dma/owl-dma.c |   3 +-
>> >  9 files changed, 239 insertions(+), 37 deletions(-)
>> > 
>> > -- 
>> > 2.30.0
>> > 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

possible deadlock in io_timeout_fn (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:f6e1ea19 Merge tag 'ceph-for-5.11-rc2' of git://github.com..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=108227df50
kernel config:  https://syzkaller.appspot.com/x/.config?x=725326c654c08da7
dashboard link: https://syzkaller.appspot.com/bug?extid=91ca3f25bd7f795f019c
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+91ca3f25bd7f795f0...@syzkaller.appspotmail.com


WARNING: possible irq lock inversion dependency detected
5.11.0-rc1-syzkaller #0 Not tainted

syz-executor.4/15599 just changed the state of lock:
888011ba2498 (&ctx->completion_lock){-...}-{2:2}, at: 
io_timeout_fn+0x6f/0x3d0 fs/io_uring.c:5619
but this lock took another, HARDIRQ-READ-unsafe lock in the past:
 (&new->fa_lock){.+.+}-{2:2}


and interrupts could create inverse lock ordering between them.


other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

   CPU0CPU1
   
  lock(&new->fa_lock);
   local_irq_disable();
   lock(&ctx->completion_lock);
   lock(&new->fa_lock);
  
lock(&ctx->completion_lock);

 *** DEADLOCK ***

2 locks held by syz-executor.4/15599:
 #0: 8c948be8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock 
net/core/rtnetlink.c:72 [inline]
 #0: 8c948be8 (rtnl_mutex){+.+.}-{3:3}, at: 
rtnetlink_rcv_msg+0x3f9/0xad0 net/core/rtnetlink.c:5561
 #1: 8cabf298
 (addrconf_hash_lock){+...}-{2:2}, at: spin_lock_bh 
include/linux/spinlock.h:359 [inline]
 (addrconf_hash_lock){+...}-{2:2}, at: addrconf_ifdown.isra.0+0x2b6/0x1590 
net/ipv6/addrconf.c:3741

the shortest dependencies between 2nd lock and 1st lock:
 -> (
&new->fa_lock){.+.+}-{2:2} {
HARDIRQ-ON-R at:
  lock_acquire kernel/locking/lockdep.c:5437 [inline]
  lock_acquire+0x29d/0x740 kernel/locking/lockdep.c:5402
  __raw_read_lock include/linux/rwlock_api_smp.h:149 
[inline]
  _raw_read_lock+0x5b/0x70 kernel/locking/spinlock.c:223
  kill_fasync_rcu fs/fcntl.c:1004 [inline]
  kill_fasync fs/fcntl.c:1025 [inline]
  kill_fasync+0x14b/0x460 fs/fcntl.c:1018
  sock_wake_async+0xd2/0x160 net/socket.c:1310
  sk_wake_async include/net/sock.h:2279 [inline]
  sk_wake_async include/net/sock.h:2275 [inline]
  af_alg_data_wakeup.part.0+0x2cb/0x4c0 crypto/af_alg.c:810
  af_alg_data_wakeup include/crypto/if_alg.h:187 [inline]
  af_alg_sendmsg+0xf24/0x1400 crypto/af_alg.c:971
  sock_sendmsg_nosec net/socket.c:652 [inline]
  sock_sendmsg+0xcf/0x120 net/socket.c:672
  sys_sendmsg+0x6e8/0x810 net/socket.c:2345
  ___sys_sendmsg+0xf3/0x170 net/socket.c:2399
  __sys_sendmsg+0xe5/0x1b0 net/socket.c:2432
  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
SOFTIRQ-ON-R at:
  lock_acquire kernel/locking/lockdep.c:5437 [inline]
  lock_acquire+0x29d/0x740 kernel/locking/lockdep.c:5402
  __raw_read_lock include/linux/rwlock_api_smp.h:149 
[inline]
  _raw_read_lock+0x5b/0x70 kernel/locking/spinlock.c:223
  kill_fasync_rcu fs/fcntl.c:1004 [inline]
  kill_fasync fs/fcntl.c:1025 [inline]
  kill_fasync+0x14b/0x460 fs/fcntl.c:1018
  sock_wake_async+0xd2/0x160 net/socket.c:1310
  sk_wake_async include/net/sock.h:2279 [inline]
  sk_wake_async include/net/sock.h:2275 [inline]
  af_alg_data_wakeup.part.0+0x2cb/0x4c0 crypto/af_alg.c:810
  af_alg_data_wakeup include/crypto/if_alg.h:187 [inline]
  af_alg_sendmsg+0xf24/0x1400 crypto/af_alg.c:971
  sock_sendmsg_nosec net/socket.c:652 [inline]
  sock_sendmsg+0xcf/0x120 net/socket.c:672
  sys_sendmsg+0x6e8/0x810 net/socket.c:2345
  ___sys_sendmsg+0xf3/0x170 net/socket.c:2399
  __sys_sendmsg+0xe5/0x1b0 net/socket.c:2432
  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
INITIAL USE at:
 lock_acquire kernel/lo

Re: [PATCH 1/4] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips

[Pali Rohár]

On Thursday 31 December 2020 16:30:33 Andrew Lunn wrote:
> On Thu, Dec 31, 2020 at 01:14:10PM +0100, Pali Rohár wrote:
> > On Wednesday 30 December 2020 19:09:58 Russell King - ARM Linux admin wrote:
> > > On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> > > > On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrote:
> > > > > Hi Pali
> > > > > 
> > > > > I have to agree with Russell here. I would rather have no diagnostics
> > > > > than untrustable diagnostics.
> > > > 
> > > > Ok!
> > > > 
> > > > So should we completely skip hwmon_device_register_with_info() call
> > > > if (i2c_block_size < 2) ?
> > > 
> > > I don't think that alone is sufficient - there's also the matter of
> > > ethtool -m which will dump that information as well, and we don't want
> > > to offer it to userspace in an unreliable form.
> > 
> > Any idea/preference how to disable access to these registers?
> 
> Page A0, byte 92:
> 
> "Diagnostic Monitoring Type" is a 1 byte field with 8 single bit
> indicators describing how diagnostic monitoring is implemented in the
> particular transceiver.
> 
> Note that if bit 6, address 92 is set indicating that digital
> diagnostic monitoring has been implemented, received power
> monitoring, transmitted power monitoring, bias current monitoring,
> supply voltage monitoring and temperature monitoring must all be
> implemented. Additionally, alarm and warning thresholds must be
> written as specified in this document at locations 00 to 55 on
> two-wire serial address 1010001X (A2h) (see Table 8-5).
> 
> Unfortunately, we cannot simply set sfp->id.ext.diagmon to false,
> because it can also be used to indicate power, software reading of
> TX_DISABLE, LOS, etc. These are all single bytes, so could be returned
> correctly, assuming they have been implemented according to the spec.
> 
> Looking at sfp_module_info(), adding a check for i2c_block_size < 2
> when determining what length to return. ethtool should do the right
> thing, know that the second page has not been returned to user space.

But if we limit length of eeprom then userspace would not be able to
access those TX_DISABLE, LOS and other bits from byte 110 at address A2.

Problematic two-byte values are in byte range 96-109 at address A2.
Therefore before byte 110.

[PATCH] dt-bindings: mips: lantiq: Document Lantiq Xway PMU bindings

[Aleksander Jan Bajkowski]

Document the Lantiq Xway SoC series Power Management Unit (PMU) bindings.

Signed-off-by: Aleksander Jan Bajkowski 
---
 .../bindings/mips/lantiq/lantiq,pmu.yaml  | 32 +++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mips/lantiq/lantiq,pmu.yaml

diff --git a/Documentation/devicetree/bindings/mips/lantiq/lantiq,pmu.yaml 
b/Documentation/devicetree/bindings/mips/lantiq/lantiq,pmu.yaml
new file mode 100644
index ..4982b458ac12
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/lantiq/lantiq,pmu.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/lantiq/lantiq,pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lantiq Xway SoC series Power Management Unit (PMU)
+
+maintainers:
+  - John Crispin 
+
+properties:
+  compatible:
+items:
+  - enum:
+  - lantiq,pmu-xway
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+pmu@102000 {
+compatible = "lantiq,pmu-xway";
+reg = <0x102000 0x1000>;
+};
-- 
2.20.1

Re: [RFC PATCH 1/2] EDAC/ghes: Add EDAC device for the CPU caches

[Borislav Petkov]

On Tue, Dec 08, 2020 at 05:29:58PM +, Shiju Jose wrote:
> The corrected error count on the CPU caches required
> reporting to the user-space for the predictive failure
> analysis. For this purpose, add an EDAC device and device
> blocks for the CPU caches found.
> The cache's corrected error count would be stored in the
> /sys/devices/system/edac/cpu/cpu*/cache*/ce_count.

This still doesn't begin to explain why the kernel needs this. I had
already asked whether errors in CPU caches are something which happen
often enough so that software should count them but nothing came. So pls
justify first why this wants to be added to the kernel.

> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 7a47680d6f07..c73eeab27ac9 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -74,6 +74,16 @@ config EDAC_GHES
>  
> In doubt, say 'Y'.
>  
> +config EDAC_GHES_CPU_ERROR
> + bool "EDAC device for reporting firmware-first BIOS detected CPU error 
> count"

Why a separate Kconfig item?

> + depends on EDAC_GHES
> + help
> +   EDAC device for the firmware-first BIOS detected CPU error count 
> reported

Well this is not what it is doing - you're talking about cache errors.
"CPU errors" can be a lot more than just cache errors.

> +static void ghes_edac_create_cpu_device(struct device *dev)
> +{
> + int cpu;
> + struct cpu_cacheinfo *this_cpu_ci;
> +
> + /*
> +  * Find the maximum number of caches present in the CPU heirarchy
> +  * among the online CPUs.
> +  */
> + for_each_online_cpu(cpu) {
> + this_cpu_ci = get_cpu_cacheinfo(cpu);
> + if (!this_cpu_ci)
> + continue;
> + if (max_number_of_caches < this_cpu_ci->num_leaves)
> + max_number_of_caches = this_cpu_ci->num_leaves;

So this is counting the number of cache levels on the system? So you
want to count the errors per cache levels?

> + }
> + if (!max_number_of_caches)
> + return;
> +
> + /*
> +  * EDAC device interface only supports creating the CPU cache hierarchy 
> for alls
> +  * the CPUs together. Thus need to allocate cpu_edac_block_list for the
> +  * max_number_of_caches among all the CPUs irrespective of the number 
> of caches
> +  * per CPU might vary.
> +  */

So this is lumping all the caches together into a single list? What for?
To untangle to the proper ones when the error gets reported?

Have you heard of percpu variables?

> @@ -624,6 +787,10 @@ int ghes_edac_register(struct ghes *ghes, struct device 
> *dev)
>   ghes_pvt = pvt;
>   spin_unlock_irqrestore(&ghes_lock, flags);
>  
> +#if defined(CONFIG_EDAC_GHES_CPU_ERROR)
> + ghes_edac_create_cpu_device(dev);
> +#endif
> +

Init stuff belongs into ghes_scan_system().

...

Ok, I've seen enough. "required reporting to the user-space for the
predictive failure analysis." is not even trying to explain *why* you're
doing this, what *actual* problem it is addressing and why should the
kernel get it.

And without a proper problem definition of what you're trying to solve,
this is not going anywhere.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

SDHCI：drivers problem running on pynq

[徐天宇]

When I run the RV_BOOT.bin, which is generated by riscv-pk with
linux-5.9.4 as payload, on xilinx pynq-z2, the BBL  met the problem below:

mmc0: Timeout waiting for hardware cmd interrupt.
mmc0: sdhci:  SDHCI REGISTER DUMP ===
mmc0: sdhci: Sys addr:  0x | Version:  0x8901
mmc0: sdhci: Blk size:  0x | Blk cnt:  0x
mmc0: sdhci: Argument:  0x0c00 | Trn mode: 0x
mmc0: sdhci: Present:   0x01ff0001 | Host ctl: 0x0001
mmc0: sdhci: Power: 0x000f | Blk gap:  0x
mmc0: sdhci: Wake-up:   0x | Clock:0x4007
mmc0: sdhci: Timeout:   0x | Int stat: 0x00018000
mmc0: sdhci: Int enab:  0x00ff0083 | Sig enab: 0x00ff0083
mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001
mmc0: sdhci: Caps:  0x69ec0080 | Caps_1:   0x
mmc0: sdhci: Cmd:   0x341a | Max curr: 0x0001
mmc0: sdhci: Resp[0]:   0x | Resp[1]:  0x
mmc0: sdhci: Resp[2]:   0x | Resp[3]:  0x
mmc0: sdhci: Host ctl2: 0x
mmc0: sdhci: ADMA Err:  0x | ADMA Ptr: 0x
mmc0: sdhci:

Does anyone have any idea about this problem? Thanks a lot.

RE: [PATCH bpf-next] xsk: build skb by page

[John Fastabend]

Xuan Zhuo wrote:
> This patch is used to construct skb based on page to save memory copy
> overhead.
> 
> Taking into account the problem of addr unaligned, and the
> possibility of frame size greater than page in the future.
> 
> Signed-off-by: Xuan Zhuo 
> ---
>  net/xdp/xsk.c | 68 
> ---
>  1 file changed, 51 insertions(+), 17 deletions(-)
> 
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index ac4a317..7cab40f 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -430,6 +430,55 @@ static void xsk_destruct_skb(struct sk_buff *skb)
>   sock_wfree(skb);
>  }
>  
> +static struct sk_buff *xsk_build_skb_bypage(struct xdp_sock *xs, struct 
> xdp_desc *desc)
> +{
> + char *buffer;
> + u64 addr;
> + u32 len, offset, copy, copied;
> + int err, i;
> + struct page *page;
> + struct sk_buff *skb;
> +
> + skb = sock_alloc_send_skb(&xs->sk, 0, 1, &err);

Because this is just grabbing an skb did you consider build_skb?

> + if (unlikely(!skb))
> + return NULL;

I think it would be best to push err back to caller here with ERR_PTR().

> +
> + addr = desc->addr;
> + len = desc->len;
> +
> + buffer = xsk_buff_raw_get_data(xs->pool, addr);
> + offset = offset_in_page(buffer);
> + addr = buffer - (char *)xs->pool->addrs;
> +
> + for (copied = 0, i = 0; copied < len; ++i) {
> + page = xs->pool->umem->pgs[addr >> PAGE_SHIFT];
> +
> + get_page(page);

Is it obvious why this get_page() is needed? Maybe a small comment would
be nice. Something like, "we need to inc refcnt on page to ensure skb
does not release page from pool".

> +
> + copy = min((u32)(PAGE_SIZE - offset), len - copied);
> +

nit: take it or leave it, seems like a lot of new lines imo. I would
just put all these together. Not really important though.

> + skb_fill_page_desc(skb, i, page, offset, copy);
> +
> + copied += copy;
> + addr += copy;
> + offset = 0;
> + }
> +
> + skb->len += len;
> + skb->data_len += len;
> + skb->truesize += len;
> +
> + refcount_add(len, &xs->sk.sk_wmem_alloc);
> +
> + skb->dev = xs->dev;
> + skb->priority = xs->sk.sk_priority;
> + skb->mark = xs->sk.sk_mark;
> + skb_shinfo(skb)->destructor_arg = (void *)(long)addr;
> + skb->destructor = xsk_destruct_skb;
> +
> + return skb;
> +}
> +
>  static int xsk_generic_xmit(struct sock *sk)
>  {
>   struct xdp_sock *xs = xdp_sk(sk);
> @@ -445,40 +494,25 @@ static int xsk_generic_xmit(struct sock *sk)
>   goto out;
>  
>   while (xskq_cons_peek_desc(xs->tx, &desc, xs->pool)) {
> - char *buffer;
> - u64 addr;
> - u32 len;
> -
>   if (max_batch-- == 0) {
>   err = -EAGAIN;
>   goto out;
>   }
>  
> - len = desc.len;
> - skb = sock_alloc_send_skb(sk, len, 1, &err);
> + skb = xsk_build_skb_bypage(xs, &desc);
>   if (unlikely(!skb))

Is err set here? Either way if skb is an ERR_PTR we can use that
here for better error handling.

>   goto out;
>  
> - skb_put(skb, len);
> - addr = desc.addr;
> - buffer = xsk_buff_raw_get_data(xs->pool, addr);
> - err = skb_store_bits(skb, 0, buffer, len);
>   /* This is the backpressure mechanism for the Tx path.
>* Reserve space in the completion queue and only proceed
>* if there is space in it. This avoids having to implement
>* any buffering in the Tx path.
>*/
> - if (unlikely(err) || xskq_prod_reserve(xs->pool->cq)) {
> + if (xskq_prod_reserve(xs->pool->cq)) {
>   kfree_skb(skb);

Same here, do we need to set err now that its not explicit above in
err = skb_store_bits...

>   goto out;
>   }
>  
> - skb->dev = xs->dev;
> - skb->priority = sk->sk_priority;
> - skb->mark = sk->sk_mark;
> - skb_shinfo(skb)->destructor_arg = (void *)(long)desc.addr;
> - skb->destructor = xsk_destruct_skb;
> -
>   err = __dev_direct_xmit(skb, xs->queue_id);
>   if  (err == NETDEV_TX_BUSY) {
>   /* Tell user-space to retry the send */
> -- 
> 1.8.3.1
> 

[rcu:rcu/next] BUILD SUCCESS WITH WARNING 295c99e6b1466988ac66cd710411f11c610b0294

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  rcu/next
branch HEAD: 295c99e6b1466988ac66cd710411f11c610b0294  rcutorture: Add 
rcutree.use_softirq=0 to RUDE01 and TASKS01

Warning ids grouped by kconfigs:

gcc_recent_errors
`-- x86_64-randconfig-c002-20201229
`-- 
kernel-rcu-rcuscale.c:WARNING-kmalloc-is-used-to-allocate-this-memory-at-line

elapsed time: 723m

configs tested: 117
configs skipped: 2

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
nios2alldefconfig
powerpc  pcm030_defconfig
x86_64  defconfig
sh  sh7785lcr_32bit_defconfig
mipsbcm63xx_defconfig
powerpc  mpc885_ads_defconfig
arm   corgi_defconfig
powerpc  allyesconfig
m68k   m5208evb_defconfig
mips tb0226_defconfig
xtensa  nommu_kc705_defconfig
powerpc  tqm8xx_defconfig
arm   u8500_defconfig
powerpc skiroot_defconfig
armoxnas_v6_defconfig
armmvebu_v5_defconfig
sh   sh7724_generic_defconfig
mips  pic32mzda_defconfig
arm   aspeed_g5_defconfig
arm   spitz_defconfig
powerpc tqm8540_defconfig
powerpc  chrp32_defconfig
powerpc wii_defconfig
mips   bmips_be_defconfig
microblaze  defconfig
sh   se7722_defconfig
shmigor_defconfig
arm  integrator_defconfig
mips   ip22_defconfig
powerpc   allnoconfig
powerpcsam440ep_defconfig
arc haps_hs_smp_defconfig
ia64 alldefconfig
sh sh7710voipgw_defconfig
powerpc tqm8541_defconfig
arm  tct_hammer_defconfig
powerpc  walnut_defconfig
arm   sunxi_defconfig
ia64 allmodconfig
ia64 allyesconfig
ia64defconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
xtensa   allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
sparc   defconfig
mips allyesconfig
mips allmodconfig
powerpc  allmodconfig
i386 randconfig-a003-20201231
i386 randconfig-a004-20201231
i386 randconfig-a002-20201231
i386 randconfig-a001-20201231
i386 randconfig-a005-20201231
i386 randconfig-a006-20201231
x86_64   randconfig-a015-20201231
x86_64   randconfig-a014-20201231
x86_64   randconfig-a011-20201231
x86_64   randconfig-a016-20201231
x86_64   randconfig-a013-20201231
x86_64   randconfig-a012-20201231
i386 randconfig-a016-20201231
i386 randconfig-a014-20201231
i386 randconfig-a012-20201231
i386 randconfig-a015-20201231
i386 randconfig-a011-20201231
i386 randconfig-a013-20201231
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscv

Re: [PATCH 1/3] MIPS: Add vulnerabilities infrastructure

[Jiaxun Yang]

在 2020/12/31 23:38, WANG Xuerui 写道:

Hi Jiaxun,

Overall a nice step towards a more conformant arch/mips! Some nits 
below though.



On 12/30/20 11:23 AM, Jiaxun Yang wrote:

Add infrastructure to display CPU vulnerabilities.
As most MIPS CPU vendors are dead today and we can't confirm
vulnerabilities states with them, we'll display vulnerabilities
as "Unknown" by default and override them in cpu-probe.c

Add trailing period.


Signed-off-by: Jiaxun Yang 
---
  arch/mips/Kconfig    |  1 +
  arch/mips/include/asm/cpu-info.h |  5 
  arch/mips/include/asm/cpu.h  |  7 +
  arch/mips/kernel/Makefile    |  2 +-
  arch/mips/kernel/vulnbl.c    | 46 
  5 files changed, 60 insertions(+), 1 deletion(-)
  create mode 100644 arch/mips/kernel/vulnbl.c

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ef5b2a177b1b..524053b8f769 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -24,6 +24,7 @@ config MIPS
  select GENERIC_CLOCKEVENTS
  select GENERIC_CMOS_UPDATE
  select GENERIC_CPU_AUTOPROBE
+    select GENERIC_CPU_VULNERABILITIES
  select GENERIC_GETTIMEOFDAY
  select GENERIC_IOMAP
  select GENERIC_IRQ_PROBE
diff --git a/arch/mips/include/asm/cpu-info.h 
b/arch/mips/include/asm/cpu-info.h

index a600670d00e9..1a964dbfc0a8 100644
--- a/arch/mips/include/asm/cpu-info.h
+++ b/arch/mips/include/asm/cpu-info.h
@@ -106,6 +106,11 @@ struct cpuinfo_mips {
  unsigned int    guestid_mask;
  unsigned int    guestid_cache;
  +    /* Vulnerabilities */
+    unsigned int    vulnerabilities; /* Vulnerabilities states 
that we known */

+    unsigned int    vulnerable; /* Vulnerabilities affated */
+    unsigned int    mitigations; /* Mitigations */


Could you make the field names a little clearer? Like "known_mask", 
"affected_mask" and "mitigated_mask"?


Also I wonder if removing the first mask is okay, since if a bit is 
neither "affected" nor "mitigated" then it must belong to the 
"unknown" case.


Actually we have no way to mitigate them in kernel for now :-(





+
  #ifdef CONFIG_CPU_LOONGSON3_CPUCFG_EMULATION
  /* CPUCFG data for this CPU, synthesized at probe time.
   *
diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index f5b04e8f6061..3414c9f5464e 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -447,4 +447,11 @@ enum cpu_type_enum {
  #define MIPS_ASE_LOONGSON_EXT    0x2000 /* Loongson EXTensions */
  #define MIPS_ASE_LOONGSON_EXT2    0x4000 /* Loongson EXTensions 
R2 */

  +/*
+ * CPU security vulnerabilities
+ */
+#define MIPS_VULNBL_MELTDOWN    BIT(0)
+#define MIPS_VULNBL_SPECTRE_V1    BIT(1)
+#define MIPS_VULNBL_SPECTRE_V2    BIT(2)
Looking at the arch/x86 vulnerabilities code, I tend to think that 
"VULNBL" is not (rather ugly) shorthand for "vulnerability", but 
"vulnerability blacklist" (!), because they have "VULNWL" for 
apparently "whitelist". So I suggest writing out "VULNERABILITY" fully 
for clarity.

+
  #endif /* _ASM_CPU_H */
diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index 13a26d254829..39abc8ead5e0 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -8,7 +8,7 @@ extra-y    := head.o vmlinux.lds
  obj-y    += cmpxchg.o cpu-probe.o branch.o elf.o entry.o 
genex.o idle.o irq.o \

 process.o prom.o ptrace.o reset.o setup.o signal.o \
 syscall.o time.o topology.o traps.o unaligned.o watch.o \
-   vdso.o cacheinfo.o
+   vdso.o cacheinfo.o vulnbl.o
    ifdef CONFIG_FUNCTION_TRACER
  CFLAGS_REMOVE_ftrace.o = -pg
diff --git a/arch/mips/kernel/vulnbl.c b/arch/mips/kernel/vulnbl.c
new file mode 100644
index ..fc73da6214fe
--- /dev/null
+++ b/arch/mips/kernel/vulnbl.c

Same with this filename.

@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2020, Jiaxun Yang 
+ *  MIPS CPU vulnerabilities
+ */
+
+#include 
+
+#include 
+#include 
+
+ssize_t cpu_show_meltdown(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+    if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_MELTDOWN))
+    return sprintf(buf, "Unknown\n");
+
+    if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_MELTDOWN))
+    return sprintf(buf, "Not affected\n");
+
+    return sprintf(buf, "Affected\n");

Be consistent with other arches and use "Vulnerable"?

+}
+
+ssize_t cpu_show_spectre_v1(struct device *dev,
+    struct device_attribute *attr, char *buf)
+{
+    if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_SPECTRE_V1))
+    return sprintf(buf, "Unknown\n");
+
+    if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_SPECTRE_V1))
+    return sprintf(buf, "Not affected\n");
+
+    return sprintf(buf, "Affected\n");

Same as above.

+}
+
+ssize_t cpu_show_spectre_v2(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+    if (!(boot_cpu_data.v

Re: [PATCH -tip v2] x86/kprobes: Do not decode opcode in resume_execution()

[Borislav Petkov]

On Fri, Dec 18, 2020 at 11:12:05PM +0900, Masami Hiramatsu wrote:
> @@ -467,8 +489,8 @@ static int arch_copy_kprobe(struct kprobe *p)
>*/
>   len = prepare_boost(buf, p, &insn);
>  
> - /* Check whether the instruction modifies Interrupt Flag or not */
> - p->ainsn.if_modifier = is_IF_modifier(buf);
> + /* Analyze the opcode and set resume flags */
> + set_resume_flags(p, &insn);

So this function wants to be called something like analyze_insn() or so
then? set_resume_flags() is kinda misleading as a name.

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 3/3] MIPS: cpu-probe: Vulnerabilities for Loongson cores

[Jiaxun Yang]

在 2020/12/31 23:43, WANG Xuerui 写道:

Hi Jiaxun,

On 12/30/20 11:23 AM, Jiaxun Yang wrote:

Loongson64C is known to be vulnerable to meltdown according to
PoC from Rui Wang .

Loongson64G defended these side-channel attack by silicon.

"Loongson64G mitigated it in hardware"?


Signed-off-by: Jiaxun Yang 
---
  arch/mips/kernel/cpu-probe.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 2460783dbdb1..24b21f51353c 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -2092,6 +2092,8 @@ static inline void cpu_probe_loongson(struct 
cpuinfo_mips *c, unsigned int cpu)

  c->ases |= (MIPS_ASE_LOONGSON_MMI | MIPS_ASE_LOONGSON_CAM |
  MIPS_ASE_LOONGSON_EXT | MIPS_ASE_LOONGSON_EXT2);
  c->ases &= ~MIPS_ASE_VZ; /* VZ of Loongson-3A2000/3000 is 
incomplete */

+    c->vulnerabilities |= MIPS_VULNBL_MELTDOWN;
+    c->vulnerable |= MIPS_VULNBL_MELTDOWN;
  break;
  case PRID_IMP_LOONGSON_64G:
  c->cputype = CPU_LOONGSON64;
@@ -2100,6 +2102,8 @@ static inline void cpu_probe_loongson(struct 
cpuinfo_mips *c, unsigned int cpu)

  set_isa(c, MIPS_CPU_ISA_M64R2);
  decode_cpucfg(c);
  c->writecombine = _CACHE_UNCACHED_ACCELERATED;
+    c->vulnerabilities |= MIPS_VULNBL_MELTDOWN |
+  MIPS_VULNBL_SPECTRE_V1 | MIPS_VULNBL_SPECTRE_V2;


Of course you forgot to set the "mitigated" mask... Oh wait.


Hi Xuerui,

Actually it belongs to not affected category as there is no action
to take in kernel.



It seems the "mitigated" mask in the 1st patch is never used, so 
either code there or here must be amended.


Yes, it's just a place holder for future kernel mitigations~
Or I should leave it until we find out these mitigations?

Thanks.

- Jiaxun




  break;
  default:
  panic("Unknown Loongson Processor ID!");

[PATCH] can: rcar: Update help description for CAN_RCAR_CANFD config

[Lad Prabhakar]

The rcar_canfd driver supports R-Car Gen3 and RZ/G2 SoC's, update the
description to reflect this.

Signed-off-by: Lad Prabhakar 
---
 drivers/net/can/rcar/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/can/rcar/Kconfig b/drivers/net/can/rcar/Kconfig
index 6bb0e7c052ad..a669b9ac8057 100644
--- a/drivers/net/can/rcar/Kconfig
+++ b/drivers/net/can/rcar/Kconfig
@@ -10,13 +10,13 @@ config CAN_RCAR
  be called rcar_can.
 
 config CAN_RCAR_CANFD
-   tristate "Renesas R-Car CAN FD controller"
+   tristate "Renesas R-Car Gen3 and RZ/G2 CAN FD controller"
depends on ARCH_RENESAS || ARM
help
  Say Y here if you want to use CAN FD controller found on
- Renesas R-Car SoCs. The driver puts the controller in CAN FD only
- mode, which can interoperate with CAN2.0 nodes but does not support
- dedicated CAN 2.0 mode.
+ Renesas R-Car Gen3 and RZ/G2 SoCs. The driver puts the
+ controller in CAN FD only mode, which can interoperate with
+ CAN2.0 nodes but does not support dedicated CAN 2.0 mode.
 
  To compile this driver as a module, choose M here: the module will
  be called rcar_canfd.
-- 
2.17.1

[PATCH] can: rcar: Update help description for CAN_RCAR config

[Lad Prabhakar]

The rcar_can driver supports R-Car Gen{1,2,3} and RZ/G{1,2} SoC's, update
the description to reflect this.

Signed-off-by: Lad Prabhakar 
---
 drivers/net/can/rcar/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/can/rcar/Kconfig b/drivers/net/can/rcar/Kconfig
index 8d36101b78e3..6bb0e7c052ad 100644
--- a/drivers/net/can/rcar/Kconfig
+++ b/drivers/net/can/rcar/Kconfig
@@ -1,10 +1,10 @@
 # SPDX-License-Identifier: GPL-2.0
 config CAN_RCAR
-   tristate "Renesas R-Car CAN controller"
+   tristate "Renesas R-Car Gen{1,2,3} and RZ/G{1,2} CAN controller"
depends on ARCH_RENESAS || ARM
help
  Say Y here if you want to use CAN controller found on Renesas R-Car
- SoCs.
+ Gen{1,2,3} and RZ/G{1,2} SoCs.
 
  To compile this driver as a module, choose M here: the module will
  be called rcar_can.
-- 
2.17.1

Re: [PATCH 1/2] dt-bindings: Convert Arm Mali Valhall GPU to DT schema

[Rob Herring]

On Thu, Dec 24, 2020 at 08:31:18PM +0800, Nick Fan wrote:
> Convert the Arm Valhall GPU binding to DT schema format.

Convert? There's no existing binding.

> 
> Define a compatible string for the Mali Valhall GPU
> for Mediatek's SoC platform.
> 
> Signed-off-by: Nick Fan 
> ---
>  .../bindings/gpu/arm,mali-valhall.yaml| 252 ++
>  1 file changed, 252 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
> 
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml 
> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
> new file mode 100644
> index ..3dba202bec95
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
> @@ -0,0 +1,252 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpu/arm,mali-vallhall.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM Mali Valhall GPU
> +
> +maintainers:
> +  - Rob Herring 
> +
> +properties:
> +  $nodename:
> +pattern: '^gpu@[a-f0-9]+$'
> +
> +  compatible:
> +items:
> +  - enum:
> +  - mediatek,mt8192-mali
> +  - const: arm,mali-valhall # Mali Valhall GPU model/revision is fully 
> discoverable
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +items:
> +  - description: GPU interrupt
> +  - description: MMU interrupt
> +  - description: Job interrupt
> +
> +  interrupt-names:
> +items:
> +  - const: gpu
> +  - const: mmu
> +  - const: job
> +
> +  clocks:
> +minItems: 1
> +
> +  power-domains:
> +minItems: 1
> +maxItems: 5
> +
> +  mali-supply: true
> +  sram-supply: true
> +
> +  operating-points-v2: true
> +
> +  "#cooling-cells":
> +const: 2
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - interrupt-names
> +  - clocks
> +
> +additionalProperties: false
> +
> +allOf:
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: mediatek,mt8192-mali
> +then:
> +  properties:
> +sram-supply: true

No need for this line.

> +power-domains:
> +  description:
> +List of phandle and PM domain specifier as documented in
> +Documentation/devicetree/bindings/power/power_domain.txt

No need re-describe a common property.

> +  minItems: 5
> +  maxItems: 5

blank line between DT properties.

> +power-domain-names:
> +  items:
> +- const: core0
> +- const: core1
> +- const: core2
> +- const: core3
> +- const: core4
> +
> +  required:
> +- sram-supply
> +- power-domains
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +gpu@1300 {
> +   compatible = "mediatek,mt8192-mali", "arm,mali-valhall";
> +   reg = <0x1300 0x4000>;
> +   interrupts =
> +   ,
> +   ,
> +   ;
> +   interrupt-names =
> +   "gpu",
> +   "mmu",
> +   "job";
> +
> +   clocks = <&mfgcfg 0>;
> +
> +   power-domains =
> +   <&scpsys 4>,
> +   <&scpsys 5>,
> +   <&scpsys 6>,
> +   <&scpsys 7>,
> +   <&scpsys 8>;
> +
> +   operating-points-v2 = <&gpu_opp_table>;
> +   mali-supply = <&mt6315_7_vbuck1>;
> +   sram-supply = <&mt6359_vsram_others_ldo_reg>;
> +};
> +
> +gpu_opp_table: opp_table0 {

Make this a child of the gpu node. Node name should be just 'opp-table'.

> +  compatible = "operating-points-v2";
> +  opp-shared;
> +
> +  opp-35800 {
> +  opp-hz = /bits/ 64 <35800>;
> +  opp-hz-real = /bits/ 64 <35800>,

I don't recall this being an OPP property.

> +/bits/ 64 <35800>;
> +  opp-microvolt = <606250>,
> +  <75>;
> +  };
> +
> +  opp-39900 {
> +  opp-hz = /bits/ 64 <39900>;
> +  opp-hz-real = /bits/ 64 <39900>,
> +/bits/ 64 <39900>;
> +  opp-microvolt = <618750>,
> +  <75>;
> +  };
> +
> +  opp-44000 {
> +  opp-hz = /bits/ 64 <44000>;
> +  opp-hz-real = /bits/ 64 <44000>,
> +/bits/ 64 <44000>;
> +  opp-microvolt = <631250>,
> +  <75>;
> +  };
> +
> +  opp-48200 {
> +  opp-hz = /bits/ 64 <48200>;
> +  opp-hz-real = /bits/ 64 <48200>,
> +/bits/ 64 <48200>;
> +  opp-microvolt = <643750>,
> +  

Re: [PATCH 3/3] MIPS: cpu-probe: Vulnerabilities for Loongson cores

[WANG Xuerui]

Hi Jiaxun,

On 12/30/20 11:23 AM, Jiaxun Yang wrote:

Loongson64C is known to be vulnerable to meltdown according to
PoC from Rui Wang .

Loongson64G defended these side-channel attack by silicon.

"Loongson64G mitigated it in hardware"?


Signed-off-by: Jiaxun Yang 
---
  arch/mips/kernel/cpu-probe.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 2460783dbdb1..24b21f51353c 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -2092,6 +2092,8 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips 
*c, unsigned int cpu)
c->ases |= (MIPS_ASE_LOONGSON_MMI | MIPS_ASE_LOONGSON_CAM |
MIPS_ASE_LOONGSON_EXT | MIPS_ASE_LOONGSON_EXT2);
c->ases &= ~MIPS_ASE_VZ; /* VZ of Loongson-3A2000/3000 is 
incomplete */
+   c->vulnerabilities |= MIPS_VULNBL_MELTDOWN;
+   c->vulnerable |= MIPS_VULNBL_MELTDOWN;
break;
case PRID_IMP_LOONGSON_64G:
c->cputype = CPU_LOONGSON64;
@@ -2100,6 +2102,8 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips 
*c, unsigned int cpu)
set_isa(c, MIPS_CPU_ISA_M64R2);
decode_cpucfg(c);
c->writecombine = _CACHE_UNCACHED_ACCELERATED;
+   c->vulnerabilities |= MIPS_VULNBL_MELTDOWN |
+ MIPS_VULNBL_SPECTRE_V1 | MIPS_VULNBL_SPECTRE_V2;


Of course you forgot to set the "mitigated" mask... Oh wait.

It seems the "mitigated" mask in the 1st patch is never used, so either 
code there or here must be amended.



break;
default:
panic("Unknown Loongson Processor ID!");

Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Rob Herring]

On Thu, Dec 24, 2020 at 04:42:08PM +0530, Roja Rani Yarubandi wrote:
> While most devices within power-domains which support performance states,
> scale the performance state dynamically, some devices might want to
> set a static/default performance state while the device is active.
> These devices typically would also run off a fixed clock and not support
> dynamically scaling the device's performance, also known as DVFS
> techniques.
> 
> Add a property 'assigned-performance-states' which client devices can
> use to set this default performance state on their power-domains.
> 
> Signed-off-by: Roja Rani Yarubandi 
> ---
>  .../bindings/power/power-domain.yaml  | 49 +++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml 
> b/Documentation/devicetree/bindings/power/power-domain.yaml
> index aed51e9dcb11..a42977a82d06 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -66,6 +66,18 @@ properties:
>by the given provider should be subdomains of the domain specified
>by this binding.
>  
> +  assigned-performance-states:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description:
> +   Some devices might need to configure their power domains in a default
> +   performance state while the device is active. These devices typcially
> +   would also run off a fixed clock and not support dynamically scaling
> +   the device's performance, also known as DVFS techniques. Each cell in
> +   performance state value corresponds to one power domain specified as
> +   part of the power-domains property. Performance state value can be an
> +   opp-level inside an OPP table of the power-domain and need not match
> +   with any OPP table performance state.

Couldn't this just be an additional cell in 'power-domains'?

> +
>  required:
>- "#power-domain-cells"
>  
> @@ -131,3 +143,40 @@ examples:
>  min-residency-us = <7000>;
>  };
>  };
> +
> +  - |
> +parent4: power-controller@1234 {
> +compatible = "foo,power-controller";
> +reg = <0x1234 0x1000>;
> +#power-domain-cells = <0>;
> +};
> +
> +parent5: power-controller@4321 {
> +compatible = "foo,power-controller";
> +reg = <0x4321 0x1000>;
> +#power-domain-cells = <0>;
> +operating-points-v2 = <&power_opp_table>;
> +
> +power_opp_table: opp-table {
> +compatible = "operating-points-v2";
> +
> +power_opp_low: opp1 {
> +opp-level = <16>;
> +};
> +
> +rpmpd_opp_ret: opp2 {
> +opp-level = <64>;
> +};
> +
> +rpmpd_opp_svs: opp3 {
> +opp-level = <256>;
> +};
> +};
> +};
> +
> +child4: consumer@12341000 {
> +compatible = "foo,consumer";
> +reg = <0x12341000 0x1000>;
> +power-domains = <&parent4>, <&parent5>;
> +assigned-performance-states = <0>, <256>;
> +};
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member 
> of Code Aurora Forum, hosted by The Linux Foundation
> 

Re: [PATCH 1/3] MIPS: Add vulnerabilities infrastructure

[WANG Xuerui]

Hi Jiaxun,

Overall a nice step towards a more conformant arch/mips! Some nits below 
though.



On 12/30/20 11:23 AM, Jiaxun Yang wrote:

Add infrastructure to display CPU vulnerabilities.
As most MIPS CPU vendors are dead today and we can't confirm
vulnerabilities states with them, we'll display vulnerabilities
as "Unknown" by default and override them in cpu-probe.c

Add trailing period.


Signed-off-by: Jiaxun Yang 
---
  arch/mips/Kconfig|  1 +
  arch/mips/include/asm/cpu-info.h |  5 
  arch/mips/include/asm/cpu.h  |  7 +
  arch/mips/kernel/Makefile|  2 +-
  arch/mips/kernel/vulnbl.c| 46 
  5 files changed, 60 insertions(+), 1 deletion(-)
  create mode 100644 arch/mips/kernel/vulnbl.c

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ef5b2a177b1b..524053b8f769 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -24,6 +24,7 @@ config MIPS
select GENERIC_CLOCKEVENTS
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
+   select GENERIC_CPU_VULNERABILITIES
select GENERIC_GETTIMEOFDAY
select GENERIC_IOMAP
select GENERIC_IRQ_PROBE
diff --git a/arch/mips/include/asm/cpu-info.h b/arch/mips/include/asm/cpu-info.h
index a600670d00e9..1a964dbfc0a8 100644
--- a/arch/mips/include/asm/cpu-info.h
+++ b/arch/mips/include/asm/cpu-info.h
@@ -106,6 +106,11 @@ struct cpuinfo_mips {
unsigned intguestid_mask;
unsigned intguestid_cache;
  
+	/* Vulnerabilities */

+   unsigned intvulnerabilities; /* Vulnerabilities states that 
we known */
+   unsigned intvulnerable; /* Vulnerabilities affated */
+   unsigned intmitigations; /* Mitigations */


Could you make the field names a little clearer? Like "known_mask", 
"affected_mask" and "mitigated_mask"?


Also I wonder if removing the first mask is okay, since if a bit is 
neither "affected" nor "mitigated" then it must belong to the "unknown" 
case.



+
  #ifdef CONFIG_CPU_LOONGSON3_CPUCFG_EMULATION
/* CPUCFG data for this CPU, synthesized at probe time.
 *
diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index f5b04e8f6061..3414c9f5464e 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -447,4 +447,11 @@ enum cpu_type_enum {
  #define MIPS_ASE_LOONGSON_EXT 0x2000 /* Loongson EXTensions */
  #define MIPS_ASE_LOONGSON_EXT20x4000 /* Loongson EXTensions R2 */
  
+/*

+ * CPU security vulnerabilities
+ */
+#define MIPS_VULNBL_MELTDOWN   BIT(0)
+#define MIPS_VULNBL_SPECTRE_V1 BIT(1)
+#define MIPS_VULNBL_SPECTRE_V2 BIT(2)
Looking at the arch/x86 vulnerabilities code, I tend to think that 
"VULNBL" is not (rather ugly) shorthand for "vulnerability", but 
"vulnerability blacklist" (!), because they have "VULNWL" for apparently 
"whitelist". So I suggest writing out "VULNERABILITY" fully for clarity.

+
  #endif /* _ASM_CPU_H */
diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index 13a26d254829..39abc8ead5e0 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -8,7 +8,7 @@ extra-y := head.o vmlinux.lds
  obj-y += cmpxchg.o cpu-probe.o branch.o elf.o entry.o genex.o idle.o 
irq.o \
   process.o prom.o ptrace.o reset.o setup.o signal.o \
   syscall.o time.o topology.o traps.o unaligned.o watch.o \
-  vdso.o cacheinfo.o
+  vdso.o cacheinfo.o vulnbl.o
  
  ifdef CONFIG_FUNCTION_TRACER

  CFLAGS_REMOVE_ftrace.o = -pg
diff --git a/arch/mips/kernel/vulnbl.c b/arch/mips/kernel/vulnbl.c
new file mode 100644
index ..fc73da6214fe
--- /dev/null
+++ b/arch/mips/kernel/vulnbl.c

Same with this filename.

@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2020, Jiaxun Yang 
+ *  MIPS CPU vulnerabilities
+ */
+
+#include 
+
+#include 
+#include 
+
+ssize_t cpu_show_meltdown(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_MELTDOWN))
+   return sprintf(buf, "Unknown\n");
+
+   if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_MELTDOWN))
+   return sprintf(buf, "Not affected\n");
+
+   return sprintf(buf, "Affected\n");

Be consistent with other arches and use "Vulnerable"?

+}
+
+ssize_t cpu_show_spectre_v1(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_SPECTRE_V1))
+   return sprintf(buf, "Unknown\n");
+
+   if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_SPECTRE_V1))
+   return sprintf(buf, "Not affected\n");
+
+   return sprintf(buf, "Affected\n");

Same as above.

+}
+
+ssize_t cpu_show_spectre_v2(struct device *dev,
+  struct device_attribute *

Re: [PATCH v3 1/3] dt-bindings: regulator: document binding for MT6315 regulator

[Rob Herring]

On Wed, Dec 23, 2020 at 08:13:42PM +0800, Hsin-Hsiung Wang wrote:
> Add device tree binding information for MT6315 regulator driver.
> Example bindings for MT6315 are added.
> 
> Signed-off-by: Hsin-Hsiung Wang 
> ---
>  .../bindings/regulator/mt6315-regulator.yaml  | 71 +++
>  1 file changed, 71 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml 
> b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
> new file mode 100644
> index ..15ce83a36174
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
> @@ -0,0 +1,71 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mtk,mt6315-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek MT6315 Regulator
> +
> +maintainers:
> +  - Hsin-Hsiung Wang 
> +
> +description: |
> +  The MT6315 is a power management IC (PMIC) configurable with SPMI.
> +  that contains 4 BUCKs output which can combine with each other
> +  by different efuse settings.
> +
> +properties:
> +  compatible:
> +const: mediatek,mt6315-regulator
> +
> +  reg:
> +maxItems: 1
> +
> +  regulators:
> +type: object
> +description: List of regulators and its properties
> +
> +patternProperties:
> +  "^vbuck[1-4]$":
> +type: object
> +$ref: "regulator.yaml#"
> +
> +properties:
> +  regulator-name:
> +pattern: "^vbuck[1-4]$"
> +description:
> +  should be "vbuck1", ..., "vbuck4"

The description just repeats what the schema defines. Drop it.

> +
> +additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - regulators
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +pmic@6 {
> +  compatible = "mediatek,mt6315-regulator";
> +  reg = <0x6 0 0xb 1>;
> +
> +  regulators {
> +vbuck1 {
> +  regulator-compatible = "vbuck1";
> +  regulator-min-microvolt = <30>;
> +  regulator-max-microvolt = <1193750>;
> +  regulator-enable-ramp-delay = <256>;
> +  regulator-allowed-modes = <0 1 2 4>;
> +};
> +
> +vbuck3 {
> +  regulator-compatible = "vbuck3";
> +  regulator-min-microvolt = <30>;
> +  regulator-max-microvolt = <1193750>;
> +  regulator-enable-ramp-delay = <256>;
> +  regulator-allowed-modes = <0 1 2 4>;
> +};
> +  };
> +};
> -- 
> 2.18.0
> 

Re: [PATCH v5 2/4] dt-bindings: spmi: document binding for the Mediatek SPMI controller

[Rob Herring]

On Wed, 23 Dec 2020 10:44:27 +0800, Hsin-Hsiung Wang wrote:
> This adds documentation for the SPMI controller found on Mediatek SoCs.
> 
> Signed-off-by: Hsin-Hsiung Wang 
> ---
>  .../bindings/spmi/mtk,spmi-mtk-pmif.yaml  | 74 +++
>  1 file changed, 74 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml
> 

Reviewed-by: Rob Herring 

Re: [PATCH 1/4] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips

[Pali Rohár]

On Thursday 31 December 2020 16:09:25 Andrew Lunn wrote:
> On Thu, Dec 31, 2020 at 01:14:10PM +0100, Pali Rohár wrote:
> > On Wednesday 30 December 2020 19:09:58 Russell King - ARM Linux admin wrote:
> > > On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> > > > On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrote:
> > > > > Hi Pali
> > > > > 
> > > > > I have to agree with Russell here. I would rather have no diagnostics
> > > > > than untrustable diagnostics.
> > > > 
> > > > Ok!
> > > > 
> > > > So should we completely skip hwmon_device_register_with_info() call
> > > > if (i2c_block_size < 2) ?
> > > 
> > > I don't think that alone is sufficient - there's also the matter of
> > > ethtool -m which will dump that information as well, and we don't want
> > > to offer it to userspace in an unreliable form.
> > 
> > Any idea/preference how to disable access to these registers?
> > 
> > > For reference, here is what SFF-8472 which defines the diagnostics, says
> > > about this:
> > > 
> > >   To guarantee coherency of the diagnostic monitoring data, the host is
> > >   required to retrieve any multi-byte fields from the diagnostic
> > >   monitoring data structure (IE: Rx Power MSB - byte 104 in A2h, Rx Power
> > >   LSB - byte 105 in A2h) by the use of a single two-byte read sequence
> > >   across the two-wire interface interface.
> > > 
> > >   The transceiver is required to ensure that any multi-byte fields which
> > >   are updated with diagnostic monitoring data (e.g. Rx Power MSB - byte
> > >   104 in A2h, Rx Power LSB - byte 105 in A2h) must have this update done
> > >   in a fashion which guarantees coherency and consistency of the data. In
> > >   other words, the update of a multi-byte field by the transceiver must
> > >   not occur such that a partially updated multi-byte field can be
> > >   transferred to the host. Also, the transceiver shall not update a
> > >   multi-byte field within the structure during the transfer of that
> > >   multi-byte field to the host, such that partially updated data would be
> > >   transferred to the host.
> > > 
> > > The first paragraph is extremely definitive in how these fields shall
> > > be read atomically - by a _single_ two-byte read sequence. From what
> > > you are telling us, these modules do not support that. Therefore, by
> > > definition, they do *not* support proper and reliable reporting of
> > > diagnostic data, and are non-conformant with the SFP MSAs.
> > > 
> > > So, they are basically broken, and the diagnostics can't be used to
> > > retrieve data that can be said to be useful.
> > 
> > I agree they are broken. We really should disable access to those 16bit
> > registers.
> > 
> > Anyway here is "datasheet" to some CarlitoxxPro SFP:
> > https://www.docdroid.net/hRsJ560/cpgos03-0490v2-datasheet-10-pdf
> > 
> > And on page 10 is written:
> > 
> > The I2C system can support the mode of random address / single
> > byteread which conform to SFF-8431.
> > 
> > Which seems to be wrong.
> 
> Searching around, i found:
> 
> http://read.pudn.com/downloads776/doc/3073304/RTL9601B-CG_Datasheet.pdf
> 
> It has two i2c busses, a master and a slave. The master bus can do
> multi-byte transfers. The slave bus description says nothing in words
> about multi-byte transfers, but the diagram shows only single byte
> transfers.

Yes. Only i2c slave is used for communication with external entity and
diagrams clearly shows that only single byte i2c transfers are
supported.

> So any SFP based around this device is broken.

Exactly. That is why I send this patch in a way that try to detect these
RTL chips and not particular vendors who create product on top of this
chip.

All SFP modules with this RTL9601B chip are broken and cannot be fixed.

Re-branders and OEM vendors like CarlitoxxPro or UBNT should stop saying
that they are compliant to SFP/SFF standards, because based on above
descriptions it is not truth.

> The silly thing is, it is reading/writing from a shadow SRAM. The CPU
> is not directly involved in an I2C transaction. So it could easily
> read multiple bytes from the SRAM and return them. But it would still
> need a synchronisation method to handle writes from the CPU to the
> SRAM, in order to make these word values safe.

But there is a still issue how to read these values from SRAM outside of
SFP module via i2c. And with current one-byte transfers of that i2c
slave on RTL9601B it is impossible via current SFP diagnostic API
specification.

[PATCH] gpio: Kconfig: Update help description for GPIO_RCAR

[Lad Prabhakar]

The gpio-rcar driver supports R-Car Gen{1,2,3} and RZ/G{1,2} SoC's, update
the description to reflect this.

Signed-off-by: Lad Prabhakar 
---
 drivers/gpio/Kconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c70f46e80a3b..47e545d71df1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -486,11 +486,12 @@ config GPIO_PXA
  Say yes here to support the PXA GPIO device
 
 config GPIO_RCAR
-   tristate "Renesas R-Car GPIO"
+   tristate "Renesas R-Car Gen{1,2,3} and RZ/G{1,2} GPIO support"
depends on ARCH_RENESAS || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
- Say yes here to support GPIO on Renesas R-Car SoCs.
+ Say yes here to support GPIO on Renesas R-Car Gen{1,2,3} and
+ RZ/G{1,2} SoCs.
 
 config GPIO_RDA
bool "RDA Micro GPIO controller support"
-- 
2.17.1

Re: [PATCH v5 1/4] dt-bindings: spmi: modify the constraint 'maxItems' to 'minItems'

[Rob Herring]

On Wed, Dec 23, 2020 at 10:44:26AM +0800, Hsin-Hsiung Wang wrote:
> The constraint of 'maxItem: 1' might be larger than 1, so we modify it
> to 'minItem: 0'.
> 
> Signed-off-by: Hsin-Hsiung Wang 
> ---
>  Documentation/devicetree/bindings/spmi/spmi.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/spmi/spmi.yaml 
> b/Documentation/devicetree/bindings/spmi/spmi.yaml
> index 173940930719..f1a26391ffde 100644
> --- a/Documentation/devicetree/bindings/spmi/spmi.yaml
> +++ b/Documentation/devicetree/bindings/spmi/spmi.yaml
> @@ -25,7 +25,7 @@ properties:
>  pattern: "^spmi@.*"
>  
>reg:
> -maxItems: 1
> +minItems: 0

0 is never right. That's 'reg' not present.

>  
>"#address-cells":
>  const: 2
> -- 
> 2.18.0
> 

[PATCH] trace: Update trace_ignore_this_task() kernel-doc comment

[Qiujun Huang]

Update kernel-doc parameter after
commit b3b1e6ededa4 ("ftrace: Create set_ftrace_notrace_pid to not trace
tasks")
added @filtered_no_pids.

Signed-off-by: Qiujun Huang 
---
 kernel/trace/trace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index b8a2d786b503..9e4f4043a3df 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -530,6 +530,7 @@ trace_find_filtered_pid(struct trace_pid_list 
*filtered_pids, pid_t search_pid)
 /**
  * trace_ignore_this_task - should a task be ignored for tracing
  * @filtered_pids: The list of pids to check
+ * @filtered_no_pids: The list of pids not to be traced
  * @task: The task that should be ignored if not filtered
  *
  * Checks if @task should be traced or not from @filtered_pids.
@@ -780,7 +781,7 @@ u64 ftrace_now(int cpu)
 }
 
 /**
- * tracing_is_enabled - Show if global_trace has been disabled
+ * tracing_is_enabled - Show if global_trace has been enabled
  *
  * Shows if the global trace has been enabled or not. It uses the
  * mirror flag "buffer_disabled" to be used in fast paths such as for
-- 
2.26.2

Re: [PATCH 3/5] dt-bindings: remoteproc: Add the documentation for Meson AO ARC rproc

[Rob Herring]

On Wed, 30 Dec 2020 02:27:22 +0100, Martin Blumenstingl wrote:
> Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC EM4
> controller for always-on operations, typically used for managing system
> suspend.
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  .../remoteproc/amlogic,meson-mx-ao-arc.yaml   | 87 +++
>  1 file changed, 87 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml:23:9:
 [warning] wrong indentation: expected 10 but found 8 (indentation)
./Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml:45:6:
 [warning] wrong indentation: expected 4 but found 5 (indentation)

dtschema/dtc warnings/errors:

See https://patchwork.ozlabs.org/patch/1421301

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

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

[Rob Herring]

On Thu, 31 Dec 2020 20:39:45 +0800, Campion Kang wrote:
> Add DT binding schema for Advantech embedded controller AHC1EC0.
> 
> Signed-off-by: Campion Kang 
> ---
>  .../devicetree/bindings/mfd/ahc1ec0.yaml  | 69 +++
>  1 file changed, 69 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/mfd/ahc1ec0.example.dts:19:18: fatal error: 
dt-bindings/mfd/ahc1ec0.h: No such file or directory
   19 | #include 
  |  ^~~
compilation terminated.
make[1]: *** [scripts/Makefile.lib:344: 
Documentation/devicetree/bindings/mfd/ahc1ec0.example.dt.yaml] Error 1
make: *** [Makefile:1370: dt_binding_check] Error 2

See https://patchwork.ozlabs.org/patch/1421561

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH v2 1/2] dt-bindings: timer: Add bindings for Intel Keem Bay SoC timer

[Rob Herring]

On Wed, 30 Dec 2020 14:25:26 +0800, vijayakannan.ayyathu...@intel.com wrote:
> From: Vijayakannan Ayyathurai 
> 
> Add Device Tree bindings for the Timer IP, which used as clocksource and
> clockevent device in the Intel Keem Bay SoC.
> 
> Acked-by: Mark Gross 
> Acked-by: Andy Shevchenko 
> Signed-off-by: Vijayakannan Ayyathurai 
> ---
>  .../bindings/timer/intel,keembay-timer.yaml   | 52 +++
>  1 file changed, 52 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Error: 
Documentation/devicetree/bindings/timer/intel,keembay-timer.example.dts:32.3-33.1
 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:344: 
Documentation/devicetree/bindings/timer/intel,keembay-timer.example.dt.yaml] 
Error 1
make: *** [Makefile:1370: dt_binding_check] Error 2

See https://patchwork.ozlabs.org/patch/1421313

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH 2/5] dt-bindings: Amlogic: add the documentation for the SECBUS2 registers

[Rob Herring]

On Wed, 30 Dec 2020 02:27:21 +0100, Martin Blumenstingl wrote:
> The Meson8/Meson8b/Meson8m2 SoCs have a register bank called SECBUS2 which
> contains registers for various IP blocks such as pin-controller bits for
> the BSD_EN and TEST_N GPIOs as well as some AO ARC core control bits.
> The registers can be accessed directly when not running in "secure mode".
> When "secure mode" is enabled then these registers have to be accessed
> through secure monitor calls.
> 
> So far these SoCs are always known to boot in "non-secure mode".
> Add a binding documentation using syscon (as these registers are shared
> across different IPs) for the SECBUS2 registers.
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  .../arm/amlogic/amlogic,meson-mx-secbus2.yaml | 53 +++
>  1 file changed, 53 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml:35:9:
 [warning] wrong indentation: expected 10 but found 8 (indentation)

dtschema/dtc warnings/errors:

See https://patchwork.ozlabs.org/patch/1421302

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.