Re: [PATCH] ALSA: usb-audio: Disable USB autosuspend properly in setup_disable_autosuspend()

[Joakim Tjernlund]

On Thu, 2021-03-04 at 12:34 +0800, Kai-Heng Feng wrote:
> Rear audio on Lenovo ThinkStation P620 stops working after commit
> 1965c4364bdd ("ALSA: usb-audio: Disable autosuspend for Lenovo
> ThinkStation P620"):
> [6.013526] usbcore: registered new interface driver snd-usb-audio
> [6.023064] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> wIndex = 0x0, type = 1
> [6.023083] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> wIndex = 0x0, type = 4
> [6.023090] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> wIndex = 0x0, type = 1
> [6.023098] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> wIndex = 0x0, type = 4
> [6.023103] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> wIndex = 0x0, type = 1
> [6.023110] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> wIndex = 0x0, type = 4
> [6.045846] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> wIndex = 0x0, type = 1
> [6.045866] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> wIndex = 0x0, type = 4
> [6.045877] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> wIndex = 0x0, type = 1
> [6.045886] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> wIndex = 0x0, type = 4
> [6.045894] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> wIndex = 0x0, type = 1
> [6.045908] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> wIndex = 0x0, type = 4
> 
> I overlooked the issue because when I was working on the said commit,
> only the front audio is tested. Apology for that.
> 
> Changing supports_autosuspend in driver is too late for disabling
> autosuspend, because it was already used by USB probe routine, so it can
> break the balance on the following code that depends on
> supports_autosuspend.
> 
> Fix it by using usb_disable_autosuspend() helper, and balance the
> suspend count in disconnect callback.
> 
> Fixes: 1965c4364bdd ("ALSA: usb-audio: Disable autosuspend for Lenovo 
> ThinkStation P620")
> Signed-off-by: Kai-Heng Feng 

I got an report from a co-worker who has no USB sound from a Lenovo ThinkPad in 
a Ultra Dock.
USB HS is connected to Dock USB jack.
Could this be the same problem?

 Jocke

Re: [PATCH 4/4] platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCs

[Andy Shevchenko]

On Thu, Mar 4, 2021 at 9:27 AM Henning Schild
 wrote:

> Siemens industrial PCs unfortunately can not always be properly
> identified the way we used to. An earlier commit introduced code that
> allows proper identification without looking at DMI strings that could
> differ based on product branding.
> Switch over to that proper way and revert commits that used to collect
> the machines based on unstable strings.

> +#include 

> +static int pmc_clk_is_critical(const struct dmi_system_id *d)
> +{
> +   int ret = true;
> +   u32 station_id;
> +
> +   if (!strcmp(d->ident, "SIEMENS AG")) {
> +   if (dmi_walk(simatic_ipc_find_dmi_entry_helper, &station_id))
> +   ret = false;
> +   else
> +   ret = (station_id == SIMATIC_IPC_IPC227E ||
> +  station_id == SIMATIC_IPC_IPC277E);
> +   }
> +
> +   return ret;

Much easier to rewrite it as

if (strcmp(...)) // BTW, do we have a dmi_* helper for that?
  return true;

if (dmi_walk)
  return false;

return station_id == || ...;

> +}

Maybe instead you can rewrite it as a callback in DMI table which
changes a (global, yeah) variable that you simply reassign...



> if (d) {
> -   clk_data->critical = true;
> -   pr_info("%s critclks quirk enabled\n", d->ident);
> +   clk_data->critical = pmc_clk_is_critical(d);
> +   if (clk_data->critical)
> +   pr_info("%s critclks quirk enabled\n", d->ident);
> }

...somewhere here?

Like
  clk_data->critical = global_var;
  if (...)
pr_info();

It seems it will reduce burden on a callback by dropping strcmp() call.

-- 
With Best Regards,
Andy Shevchenko

[PATCH] USB: serial: cp210x: Make the CP210x driver work with GPIOs of CP2108

[Pho Tran]

Similar to other CP210x devices, GPIO interfaces (gpiochip) should be
supported for CP2108.

CP2108 has 4 serial interfaces but only 1 set of GPIO pins are shared
to all of those interfaces. So, just need to initialize GPIOs of CP2108
with only one interface (I use interface 0). It means just only 1 gpiochip
device file will be created for CP2108.

CP2108 has 16 GPIOs, So data types of several variables need to be is u16
instead of u8(in struct cp210x_serial_private). This doesn't affect other
CP210x devices.

Because CP2108 has 16 GPIO pins, the parameter passed by cp210x functions
will be different from other CP210x devices. So need to check part number
of the device to use correct data format  before sending commands to
devices.

Like CP2104, CP2108 have GPIO pins with configurable options. Therefore,
should be mask all pins which are not in GPIO mode in cp2108_gpio_init()
function.

Signed-off-by: Pho Tran 
---
 drivers/usb/serial/cp210x.c | 199 +++-
 1 file changed, 172 insertions(+), 27 deletions(-)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 7bec1e730b20..0e92e41bacc5 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -245,9 +245,9 @@ struct cp210x_serial_private {
 #ifdef CONFIG_GPIOLIB
struct gpio_chipgc;
boolgpio_registered;
-   u8  gpio_pushpull;
-   u8  gpio_altfunc;
-   u8  gpio_input;
+   u16 gpio_pushpull;
+   u16 gpio_altfunc;
+   u16 gpio_input;
 #endif
u8  partnum;
speed_t min_speed;
@@ -500,6 +500,25 @@ struct cp210x_single_port_config {
u8  device_cfg;
 } __packed;
 
+/*
+ * CP210X_VENDOR_SPECIFIC, CP210X_GET_PORTCONFIG call reads these 0x49 bytes
+ * on a CP2108 chip. Structure needs padding due to unused/unspecified bytes.
+ */
+struct cp210x_quad_port_state {
+   __le16 Mode_PB[5];
+   __le16 LowPower_PB[5];
+   __le16 Latch_PB[5];
+} __packed;
+
+struct cp210x_quad_port_config {
+   struct cp210x_quad_port_state reset_state;
+   struct cp210x_quad_port_state suspend_state;
+   u8 IPDelay_IFC[4];
+   u8 EnhancedFxn_IFC[4];
+   u8 EnhancedFxn_Device;
+   u8 ExtClkFreq[4];
+} __packed;
+
 /* GPIO modes */
 #define CP210X_SCI_GPIO_MODE_OFFSET9
 #define CP210X_SCI_GPIO_MODE_MASK  GENMASK(11, 9)
@@ -510,6 +529,27 @@ struct cp210x_single_port_config {
 #define CP210X_GPIO_MODE_OFFSET8
 #define CP210X_GPIO_MODE_MASK  GENMASK(11, 8)
 
+#define CP2108_GPIO_MODE_OFFSET0
+#define CP2108_GPIO_MODE_MASK  GENMASK(15, 0)
+
+/* CP2108 port configuration values */
+#define CP2108_GPIO0_ALTERNATE_FUNCBIT(0)
+#define CP2108_GPIO1_ALTERNATE_FUNCBIT(1)
+#define CP2108_GPIO2_ALTERNATE_FUNCBIT(2)
+#define CP2108_GPIO3_ALTERNATE_FUNCBIT(3)
+#define CP2108_GPIO4_ALTERNATE_FUNCBIT(4)
+#define CP2108_GPIO5_ALTERNATE_FUNCBIT(5)
+#define CP2108_GPIO6_ALTERNATE_FUNCBIT(6)
+#define CP2108_GPIO7_ALTERNATE_FUNCBIT(7)
+#define CP2108_GPIO8_ALTERNATE_FUNCBIT(8)
+#define CP2108_GPIO9_ALTERNATE_FUNCBIT(9)
+#define CP2108_GPIO10_ALTERNATE_FUNC   BIT(10)
+#define CP2108_GPIO11_ALTERNATE_FUNC   BIT(11)
+#define CP2108_GPIO12_ALTERNATE_FUNC   BIT(12)
+#define CP2108_GPIO13_ALTERNATE_FUNC   BIT(13)
+#define CP2108_GPIO14_ALTERNATE_FUNC   BIT(14)
+#define CP2108_GPIO15_ALTERNATE_FUNC   BIT(15)
+
 /* CP2105 port configuration values */
 #define CP2105_GPIO0_TXLED_MODEBIT(0)
 #define CP2105_GPIO1_RXLED_MODEBIT(1)
@@ -532,6 +572,12 @@ struct cp210x_gpio_write {
u8  state;
 };
 
+/* CP210X_VENDOR_SPECIFIC, CP210X_WRITE_LATCH call writes these 0x4 bytes on 
CP2108. */
+struct cp2108_gpio_write {
+   u16 mask;
+   u16 state;
+} __packed;
+
 /*
  * Helper to get interface number when we only have struct usb_serial.
  */
@@ -1298,50 +1344,73 @@ static int cp210x_gpio_get(struct gpio_chip *gc, 
unsigned int gpio)
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
u8 req_type = REQTYPE_DEVICE_TO_HOST;
int result;
-   u8 buf;
-
-   if (priv->partnum == CP210X_PARTNUM_CP2105)
-   req_type = REQTYPE_INTERFACE_TO_HOST;
 
-   result = usb_autopm_get_interface(serial->interface);
-   if (result)
-   return result;
+   if (priv->partnum == CP210X_PARTNUM_CP2108) {
+   u16 buf;
 
-   result = cp210x_read_vendor_block(serial, req_type,
- CP210X_READ_LATCH, &buf, sizeof(buf));
-   usb_autopm_put_interface(serial->interface);
-   if (result < 0)
-   return result;
-
-   return !!(b

Re: [PATCH v3 1/3] KVM: nVMX: Sync L2 guest CET states between L1/L2

[Vitaly Kuznetsov]

Yang Weijiang  writes:

> These fields are rarely updated by L1 QEMU/KVM, sync them when L1 is trying to
> read/write them and after they're changed. If CET guest entry-load bit is not
> set by L1 guest, migrate them to L2 manaully.
>
> Suggested-by: Sean Christopherson 
> Signed-off-by: Yang Weijiang 
> ---
>  arch/x86/kvm/cpuid.c  |  1 -
>  arch/x86/kvm/vmx/nested.c | 30 ++
>  arch/x86/kvm/vmx/vmx.h|  3 +++
>  3 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index d191de769093..8692f53b8cd0 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -143,7 +143,6 @@ void kvm_update_cpuid_runtime(struct kvm_vcpu *vcpu)
>   }
>   vcpu->arch.guest_supported_xss =
>   (((u64)best->edx << 32) | best->ecx) & supported_xss;
> -

Nitpick: stray change?

>   } else {
>   vcpu->arch.guest_supported_xss = 0;
>   }
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 9728efd529a1..24cace55e1f9 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -2516,6 +2516,13 @@ static void prepare_vmcs02_rare(struct vcpu_vmx *vmx, 
> struct vmcs12 *vmcs12)
>   vmcs_write32(VM_ENTRY_MSR_LOAD_COUNT, vmx->msr_autoload.guest.nr);
>  
>   set_cr4_guest_host_mask(vmx);
> +
> + if (kvm_cet_supported() && vmx->nested.nested_run_pending &&
> + (vmcs12->vm_entry_controls & VM_ENTRY_LOAD_CET_STATE)) {
> + vmcs_writel(GUEST_SSP, vmcs12->guest_ssp);
> + vmcs_writel(GUEST_S_CET, vmcs12->guest_s_cet);
> + vmcs_writel(GUEST_INTR_SSP_TABLE, vmcs12->guest_ssp_tbl);
> + }
>  }
>  
>  /*
> @@ -2556,6 +2563,15 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, 
> struct vmcs12 *vmcs12,
>   if (kvm_mpx_supported() && (!vmx->nested.nested_run_pending ||
>   !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS)))
>   vmcs_write64(GUEST_BNDCFGS, vmx->nested.vmcs01_guest_bndcfgs);
> +
> + if (kvm_cet_supported() && (!vmx->nested.nested_run_pending ||
> + !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_CET_STATE))) {
> + vmcs_writel(GUEST_SSP, vmx->nested.vmcs01_guest_ssp);
> + vmcs_writel(GUEST_S_CET, vmx->nested.vmcs01_guest_s_cet);
> + vmcs_writel(GUEST_INTR_SSP_TABLE,
> + vmx->nested.vmcs01_guest_ssp_tbl);
> + }
> +
>   vmx_set_rflags(vcpu, vmcs12->guest_rflags);
>  
>   /* EXCEPTION_BITMAP and CR0_GUEST_HOST_MASK should basically be the
> @@ -3375,6 +3391,12 @@ enum nvmx_vmentry_status 
> nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
>   if (kvm_mpx_supported() &&
>   !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS))
>   vmx->nested.vmcs01_guest_bndcfgs = vmcs_read64(GUEST_BNDCFGS);
> + if (kvm_cet_supported() &&
> + !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_CET_STATE)) {
> + vmx->nested.vmcs01_guest_ssp = vmcs_readl(GUEST_SSP);
> + vmx->nested.vmcs01_guest_s_cet = vmcs_readl(GUEST_S_CET);
> + vmx->nested.vmcs01_guest_ssp_tbl = 
> vmcs_readl(GUEST_INTR_SSP_TABLE);
> + }
>  
>   /*
>* Overwrite vmcs01.GUEST_CR3 with L1's CR3 if EPT is disabled *and*
> @@ -4001,6 +4023,9 @@ static bool is_vmcs12_ext_field(unsigned long field)
>   case GUEST_IDTR_BASE:
>   case GUEST_PENDING_DBG_EXCEPTIONS:
>   case GUEST_BNDCFGS:
> + case GUEST_SSP:
> + case GUEST_INTR_SSP_TABLE:
> + case GUEST_S_CET:
>   return true;
>   default:
>   break;
> @@ -4052,6 +4077,11 @@ static void sync_vmcs02_to_vmcs12_rare(struct kvm_vcpu 
> *vcpu,
>   vmcs_readl(GUEST_PENDING_DBG_EXCEPTIONS);
>   if (kvm_mpx_supported())
>   vmcs12->guest_bndcfgs = vmcs_read64(GUEST_BNDCFGS);
> + if (kvm_cet_supported()) {
> + vmcs12->guest_ssp = vmcs_readl(GUEST_SSP);
> + vmcs12->guest_s_cet = vmcs_readl(GUEST_S_CET);
> + vmcs12->guest_ssp_tbl = vmcs_readl(GUEST_INTR_SSP_TABLE);
> + }
>  
>   vmx->nested.need_sync_vmcs02_to_vmcs12_rare = false;
>  }
> diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> index 9d3a557949ac..36dc4fdb0909 100644
> --- a/arch/x86/kvm/vmx/vmx.h
> +++ b/arch/x86/kvm/vmx/vmx.h
> @@ -155,6 +155,9 @@ struct nested_vmx {
>   /* to migrate it to L2 if VM_ENTRY_LOAD_DEBUG_CONTROLS is off */
>   u64 vmcs01_debugctl;
>   u64 vmcs01_guest_bndcfgs;
> + u64 vmcs01_guest_ssp;
> + u64 vmcs01_guest_s_cet;
> + u64 vmcs01_guest_ssp_tbl;
>  
>   /* to migrate it to L1 if L2 writes to L1's CR8 directly */
>   int l1_tpr_threshold;

-- 
Vitaly

[PATCH] PATCH Documentation translations:translate sound/hd-audio/controls to chinese

[hjh]

Signed-off-by: hjh 
---
 Documentation/translations/zh_CN/index.rst|   1 +
 .../zh_CN/sound/hd-audio/controls.rst | 102 ++
 .../zh_CN/sound/hd-audio/index.rst|  14 +++
 .../translations/zh_CN/sound/index.rst|  22 
 4 files changed, 139 insertions(+)
 create mode 100644 Documentation/translations/zh_CN/sound/hd-audio/controls.rst
 create mode 100644 Documentation/translations/zh_CN/sound/hd-audio/index.rst
 create mode 100644 Documentation/translations/zh_CN/sound/index.rst

diff --git a/Documentation/translations/zh_CN/index.rst 
b/Documentation/translations/zh_CN/index.rst
index be6f11176200..2767dacfe86d 100644
--- a/Documentation/translations/zh_CN/index.rst
+++ b/Documentation/translations/zh_CN/index.rst
@@ -20,6 +20,7 @@
process/index
filesystems/index
arm64/index
+   sound/index
 
 目录和表格
 --
diff --git a/Documentation/translations/zh_CN/sound/hd-audio/controls.rst 
b/Documentation/translations/zh_CN/sound/hd-audio/controls.rst
new file mode 100644
index ..54c028ab9a40
--- /dev/null
+++ b/Documentation/translations/zh_CN/sound/hd-audio/controls.rst
@@ -0,0 +1,102 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Chinese translator: Huang Jianghui 
+-
+.. include:: ../../disclaimer-zh_CN.rst
+以下为正文
+-
+==
+高清音频编解码器特定混音器控件
+==
+
+
+此文件解释特定于编解码器的混音器控件.
+
+瑞昱编解码器
+
+
+声道模式
+  这是一个用于更改环绕声道设置的枚举控件,仅在环绕声道打开时显示出现。
+  它给出要使用的通道数:"2ch","4ch","6ch"，和"8ch"。根据配置，这还控
+  制多I/O插孔的插孔重分配。
+
+自动静音模式
+  这是一个枚举控件，用于更改耳机和线路输出插孔的自动静音行为。如果内
+  置扬声器、耳机和/或线路输出插孔在机器上可用，则显示该控件。当只有
+  耳机或者线路输出的时候，它给出”禁用“和”启用“状态。当启用后，插孔插
+  入后扬声器会自动静音。
+
+  当耳机和线路输出插孔都存在时，它给出”禁用“、”仅扬声器“和”线路输出+扬
+  声器“。当”仅扬声器“被选择，插入耳机或者线路输出插孔可使扬声器静音，
+  但不会使线路输出静音。当线路输出+扬声器被选择，插入耳机插孔会同时使扬
+  声器和线路输出静音。
+
+
+矽玛特编解码器
+--
+
+模拟环回
+   此控件启用/禁用模拟环回电路。只有在编解码器提示中将”lookback“设置为真
+   时才会出现(见HD-Audio.txt)。请注意，在某些编解码器上，模拟环回和正常
+   PCM播放是独占的,即当此选项打开时，您将听不到任何PCM流。
+
+交换中置/低频
+   交换中置和低频通道顺序，通常情况下，左侧对应中置，右侧对应低频,启动此
+   项后，左边低频，右边中置。
+
+耳机作为线路输出
+   当此控制开启时，将耳机视为线路输出插孔。也就是说，耳机不会自动静音其他
+   线路输出，没有耳机放大器被设置到引脚上。
+
+麦克风插口模式、线路插孔模式等
+   这些枚举控制输入插孔引脚的方向和偏置。根据插孔类型，它可以设置为”麦克风
+   输入“和”线路输入“以确定输入偏置,或者当引脚是环绕声道的多I/O插孔时，它
+   可以设置为”线路输出“。
+
+
+威盛编解码器
+
+
+智能5.1
+   一个枚举控件，用于为环绕输出重新分配多个I/O插孔的任务。当它打开时，相应
+   的输入插孔（通常是线路输入和麦克风输入）被切换为环绕和中央低频输出插孔。
+
+独立耳机
+   启用此枚举控制时，耳机输出从单个流（第三个PCM，如hw:0,2）而不是主流路由。
+   如果耳机DAC与侧边或中央低频通道DAC共享，则DAC将自动切换到耳机。
+
+环回混合
+   一个用于确定是否启动了模拟环回路由的枚举控件。当它启用后，模拟环回路由到
+   前置通道。同样，耳机与扬声器输出也采用相同的路径。作为一个副作用，当设置
+   此模式后，单个音量控制将不再适用于耳机和扬声器，因为只有一个DAC连接到混
+   音器小部件。
+
+动态电源控制
+   此控件决定是否启动每个插孔的动态电源控制检测。启用时，根据插孔的插入情况
+   动态更改组件的电源状态（D0/D3）以节省电量消耗。但是，如果您的系统没有提
+   供正确的插孔检测，这将无法工作;在这种情况下，请关闭此控件。
+
+插孔检测
+   此控件仅为VT1708编解码器提供，它不会为每个插孔插拔提供适当的未请求事件。
+   当此控件打开，驱动将轮询插孔检测，以便耳机自动静音可以工作，而关闭此控
+   件将降低功耗。
+
+
+科胜讯编解码器
+--
+
+自动静音模式
+   见瑞昱解码器
+
+
+
+模拟编解码器
+
+
+通道模式
+   这是一个用于更改环绕声道设置的枚举控件,仅在环绕声道可用时显示。它提供了能
+   被使用的通道数:”2ch“、”4ch“和”6ch“。根据配置，这还控制多I/O插孔的插孔重
+   分配。
+
+独立耳机
+   启动此枚举控制后，耳机输出从单个流（第三个PCM，如hw:0,2）而不是主流路由。
diff --git a/Documentation/translations/zh_CN/sound/hd-audio/index.rst 
b/Documentation/translations/zh_CN/sound/hd-audio/index.rst
new file mode 100644
index ..d9885d53b069
--- /dev/null
+++ b/Documentation/translations/zh_CN/sound/hd-audio/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: :doc:`../../../../sound/hd-audio/index`
+:Translator: Huang Jianghui 
+
+
+高清音频
+
+
+.. toctree::
+   :maxdepth: 2
+
+   controls
diff --git a/Documentation/translations/zh_CN/sound/index.rst 
b/Documentation/translations/zh_CN/sound/index.rst
new file mode 100644
index ..28d5dca34a63
--- /dev/null
+++ b/Documentation/translations/zh_CN/sound/index.rst
@@ -0,0 +1,22 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :doc:`../../../sound/index`
+:Translator: Huang Jianghui 
+
+
+
+Linux 声音子系统文档
+
+
+.. toctree::
+   :maxdepth: 2
+
+   hd-audio/index
+
+.. only::  subproject and html
+
+   Indices
+   ===
+
+   * :ref:`genindex`
-- 
2.20.1

Re: [PATCH 08/30] scsi: pm8001: pm8001_init: Provide function name and fix a misspelling

[Jinpu Wang]

On Wed, Mar 3, 2021 at 3:46 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/scsi/pm8001/pm8001_init.c:192: warning: expecting prototype for 
> tasklet for 64 msi(). Prototype was for pm8001_tasklet() instead
>  drivers/scsi/pm8001/pm8001_init.c:872: warning: expecting prototype for 
> pm8001_set_phy_settings_ven_117c_12Gb(). Prototype was for 
> pm8001_set_phy_settings_ven_117c_12G() instead
>
> Cc: Jack Wang 
> Cc: "James E.J. Bottomley" 
> Cc: "Martin K. Petersen" 
> Cc: Kumar Santhanam 
> Cc: Sangeetha Gnanasekaran 
> Cc: Nikith Ganigarakoppal 
> Cc: linux-s...@vger.kernel.org
> Signed-off-by: Lee Jones 
Acked-by: Jack Wang 
Thanks
> ---
>  drivers/scsi/pm8001/pm8001_init.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c 
> b/drivers/scsi/pm8001/pm8001_init.c
> index bd626ef876dac..bbb6b23aa6b1c 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -184,7 +184,7 @@ static void pm8001_free(struct pm8001_hba_info *pm8001_ha)
>  #ifdef PM8001_USE_TASKLET
>
>  /**
> - * tasklet for 64 msi-x interrupt handler
> + * pm8001_tasklet() - tasklet for 64 msi-x interrupt handler
>   * @opaque: the passed general host adapter struct
>   * Note: pm8001_tasklet is common for pm8001 & pm80xx
>   */
> @@ -864,7 +864,7 @@ void pm8001_get_phy_mask(struct pm8001_hba_info 
> *pm8001_ha, int *phymask)
>  }
>
>  /**
> - * pm8001_set_phy_settings_ven_117c_12Gb : Configure ATTO 12Gb PHY settings
> + * pm8001_set_phy_settings_ven_117c_12G() : Configure ATTO 12Gb PHY settings
>   * @pm8001_ha : our adapter
>   */
>  static
> --
> 2.27.0
>

Re: [PATCH 13/30] scsi: pm8001: pm8001_ctl: Fix incorrectly named functions in headers

[Jinpu Wang]

On Wed, Mar 3, 2021 at 3:47 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/scsi/pm8001/pm8001_ctl.c:313: warning: expecting prototype for 
> pm8001_ctl_sas_address_show(). Prototype was for 
> pm8001_ctl_host_sas_address_show() instead
>  drivers/scsi/pm8001/pm8001_ctl.c:530: warning: expecting prototype for 
> pm8001_ctl_aap_log_show(). Prototype was for pm8001_ctl_iop_log_show() instead
>
> Cc: Jack Wang 
> Cc: "James E.J. Bottomley" 
> Cc: "Martin K. Petersen" 
> Cc: linux-s...@vger.kernel.org
> Signed-off-by: Lee Jones 
Acked-by: Jack Wang 
Thanks
> ---
>  drivers/scsi/pm8001/pm8001_ctl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_ctl.c 
> b/drivers/scsi/pm8001/pm8001_ctl.c
> index 12035baf0997b..1921e69bc2328 100644
> --- a/drivers/scsi/pm8001/pm8001_ctl.c
> +++ b/drivers/scsi/pm8001/pm8001_ctl.c
> @@ -299,7 +299,7 @@ static DEVICE_ATTR(sas_spec_support, S_IRUGO,
>pm8001_ctl_sas_spec_support_show, NULL);
>
>  /**
> - * pm8001_ctl_sas_address_show - sas address
> + * pm8001_ctl_host_sas_address_show - sas address
>   * @cdev: pointer to embedded class device
>   * @attr: device attribute (unused)
>   * @buf: the buffer returned
> @@ -518,7 +518,7 @@ static ssize_t event_log_size_show(struct device *cdev,
>  }
>  static DEVICE_ATTR_RO(event_log_size);
>  /**
> - * pm8001_ctl_aap_log_show - IOP event log
> + * pm8001_ctl_iop_log_show - IOP event log
>   * @cdev: pointer to embedded class device
>   * @attr: device attribute (unused)
>   * @buf: the buffer returned
> --
> 2.27.0
>

Re: [PATCH 4.19 055/247] soc: aspeed: snoop: Add clock control logic

[Joel Stanley]

On Thu, 4 Mar 2021 at 08:12, Greg Kroah-Hartman
 wrote:
>
> On Tue, Mar 02, 2021 at 12:09:21AM +, Yoo, Jae Hyun wrote:

> > > From: Joel Stanley 

> > > Jae, John; with this backported do we need to also provide a corresponding
> > > device tree change for the stable tree, otherwise this driver will no 
> > > longer
> > > probe?
> >
> > Right. The second patch
> > https://lore.kernel.org/linux-arm-kernel/20201208091748.1920-2-wangzhiqiang...@bytedance.com/
> > John submitted should be applied to stable tree too to make this module be 
> > probed
> > correctly.
>
> Now queued up, thanks.

Thanks Jae and Greg.

Re: [PATCH v3 3/3] KVM: nVMX: Add CET entry/exit load bits to evmcs unsupported list

[Vitaly Kuznetsov]

Yang Weijiang  writes:

> Nested guest doesn't support CET when KVM is running as an intermediate
> layer between two Hyper-Vs for now, so mask out related CET entry/exit
> load bits. Relevant enabling patches will be posted as a separate patch
> series.
>
> Suggested-by: Paolo Bonzini 
> Suggested-by: Vitaly Kuznetsov 
> Signed-off-by: Yang Weijiang 
> ---
>  arch/x86/kvm/vmx/evmcs.c | 4 ++--
>  arch/x86/kvm/vmx/evmcs.h | 6 --
>  2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/evmcs.c b/arch/x86/kvm/vmx/evmcs.c
> index 41f24661af04..9f81db51fd8b 100644
> --- a/arch/x86/kvm/vmx/evmcs.c
> +++ b/arch/x86/kvm/vmx/evmcs.c
> @@ -351,11 +351,11 @@ void nested_evmcs_filter_control_msr(u32 msr_index, u64 
> *pdata)
>   switch (msr_index) {
>   case MSR_IA32_VMX_EXIT_CTLS:
>   case MSR_IA32_VMX_TRUE_EXIT_CTLS:
> - ctl_high &= ~VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL;
> + ctl_high &= ~EVMCS1_UNSUPPORTED_VMEXIT_CTRL;
>   break;
>   case MSR_IA32_VMX_ENTRY_CTLS:
>   case MSR_IA32_VMX_TRUE_ENTRY_CTLS:
> - ctl_high &= ~VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL;
> + ctl_high &= ~EVMCS1_UNSUPPORTED_VMENTRY_CTRL;
>   break;
>   case MSR_IA32_VMX_PROCBASED_CTLS2:
>   ctl_high &= ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
> diff --git a/arch/x86/kvm/vmx/evmcs.h b/arch/x86/kvm/vmx/evmcs.h
> index bd41d9462355..25588694eb04 100644
> --- a/arch/x86/kvm/vmx/evmcs.h
> +++ b/arch/x86/kvm/vmx/evmcs.h
> @@ -59,8 +59,10 @@ DECLARE_STATIC_KEY_FALSE(enable_evmcs);
>SECONDARY_EXEC_SHADOW_VMCS |   \
>SECONDARY_EXEC_TSC_SCALING |   \
>SECONDARY_EXEC_PAUSE_LOOP_EXITING)
> -#define EVMCS1_UNSUPPORTED_VMEXIT_CTRL (VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL)
> -#define EVMCS1_UNSUPPORTED_VMENTRY_CTRL (VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL)
> +#define EVMCS1_UNSUPPORTED_VMEXIT_CTRL (VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL | 
> \
> + VM_EXIT_LOAD_CET_STATE)
> +#define EVMCS1_UNSUPPORTED_VMENTRY_CTRL (VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL 
> | \
> +  VM_ENTRY_LOAD_CET_STATE)
>  #define EVMCS1_UNSUPPORTED_VMFUNC (VMX_VMFUNC_EPTP_SWITCHING)
>  
>  #if IS_ENABLED(CONFIG_HYPERV)

Thanks, this should be enough for both KVM on Hyper-V and Hyper-V on KVM
using eVMCS.

Reviewed-by: Vitaly Kuznetsov 

-- 
Vitaly

Re: [PATCH 11/30] scsi: pm8001: pm8001_sas: Provide function name 'pm8001_I_T_nexus_reset()' in header

[Jinpu Wang]

On Wed, Mar 3, 2021 at 3:47 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/scsi/pm8001/pm8001_sas.c:989: warning: expecting prototype for and 
> hard reset for(). Prototype was for pm8001_I_T_nexus_reset() instead
>
> Cc: Jack Wang 
> Cc: "James E.J. Bottomley" 
> Cc: "Martin K. Petersen" 
> Cc: linux-s...@vger.kernel.org
> Signed-off-by: Lee Jones 
Acked-by: Jack Wang 
Thanks
> ---
>  drivers/scsi/pm8001/pm8001_sas.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/pm8001/pm8001_sas.c 
> b/drivers/scsi/pm8001/pm8001_sas.c
> index a98d4496ff8b6..742c83bc45554 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -981,6 +981,7 @@ void pm8001_open_reject_retry(
>  }
>
>  /**
> + * pm8001_I_T_nexus_reset()
>* Standard mandates link reset for ATA  (type 0) and hard reset for
>* SSP (type 1) , only for RECOVERY
>* @dev: the device structure for the device to reset.
> --
> 2.27.0
>

Re: [PATCH 22/30] scsi: pm8001: pm80xx_hwi: Fix a bunch of doc-rotted function headers

[Jinpu Wang]

On Wed, Mar 3, 2021 at 3:47 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/scsi/pm8001/pm80xx_hwi.c:1427: warning: expecting prototype for 
> pm8001_chip_init(). Prototype was for pm80xx_chip_init() instead
>  drivers/scsi/pm8001/pm80xx_hwi.c:1584: warning: expecting prototype for 
> pm8001_chip_soft_rst(). Prototype was for pm80xx_chip_soft_rst() instead
>  drivers/scsi/pm8001/pm80xx_hwi.c:1711: warning: expecting prototype for 
> pm8001_chip_interrupt_enable(). Prototype was for 
> pm80xx_chip_intx_interrupt_enable() instead
>  drivers/scsi/pm8001/pm80xx_hwi.c:1722: warning: expecting prototype for 
> pm8001_chip_intx_interrupt_disable(). Prototype was for 
> pm80xx_chip_intx_interrupt_disable() instead
>  drivers/scsi/pm8001/pm80xx_hwi.c:1733: warning: expecting prototype for 
> pm8001_chip_interrupt_enable(). Prototype was for 
> pm80xx_chip_interrupt_enable() instead
>  drivers/scsi/pm8001/pm80xx_hwi.c:1752: warning: expecting prototype for 
> pm8001_chip_interrupt_disable(). Prototype was for 
> pm80xx_chip_interrupt_disable() instead
>  drivers/scsi/pm8001/pm80xx_hwi.c:4192: warning: expecting prototype for 
> pm8001_chip_smp_req(). Prototype was for pm80xx_chip_smp_req() instead
>  drivers/scsi/pm8001/pm80xx_hwi.c:4775: warning: expecting prototype for 
> pm8001_chip_phy_stop_req(). Prototype was for pm80xx_chip_phy_stop_req() 
> instead
>  drivers/scsi/pm8001/pm80xx_hwi.c:4907: warning: expecting prototype for 
> pm8001_chip_isr(). Prototype was for pm80xx_chip_isr() instead
>
> Cc: Jack Wang 
> Cc: "James E.J. Bottomley" 
> Cc: "Martin K. Petersen" 
> Cc: linux-s...@vger.kernel.org
> Signed-off-by: Lee Jones 
Acked-by: Jack Wang 
Thanks
> ---
>  drivers/scsi/pm8001/pm80xx_hwi.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c 
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 84315560e8e1a..74ed072209f47 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -1420,7 +1420,7 @@ static int pm80xx_encrypt_update(struct pm8001_hba_info 
> *pm8001_ha)
>  }
>
>  /**
> - * pm8001_chip_init - the main init function that initialize whole PM8001 
> chip.
> + * pm80xx_chip_init - the main init function that initialize whole PM8001 
> chip.
>   * @pm8001_ha: our hba card information
>   */
>  static int pm80xx_chip_init(struct pm8001_hba_info *pm8001_ha)
> @@ -1574,7 +1574,7 @@ pm80xx_fatal_errors(struct pm8001_hba_info *pm8001_ha)
>  }
>
>  /**
> - * pm8001_chip_soft_rst - soft reset the PM8001 chip, so that the clear all
> + * pm80xx_chip_soft_rst - soft reset the PM8001 chip, so that the clear all
>   * the FW register status to the originated status.
>   * @pm8001_ha: our hba card information
>   */
> @@ -1703,7 +1703,7 @@ static void pm80xx_hw_chip_rst(struct pm8001_hba_info 
> *pm8001_ha)
>  }
>
>  /**
> - * pm8001_chip_interrupt_enable - enable PM8001 chip interrupt
> + * pm80xx_chip_intx_interrupt_enable - enable PM8001 chip interrupt
>   * @pm8001_ha: our hba card information
>   */
>  static void
> @@ -1714,7 +1714,7 @@ pm80xx_chip_intx_interrupt_enable(struct 
> pm8001_hba_info *pm8001_ha)
>  }
>
>  /**
> - * pm8001_chip_intx_interrupt_disable- disable PM8001 chip interrupt
> + * pm80xx_chip_intx_interrupt_disable - disable PM8001 chip interrupt
>   * @pm8001_ha: our hba card information
>   */
>  static void
> @@ -1724,7 +1724,7 @@ pm80xx_chip_intx_interrupt_disable(struct 
> pm8001_hba_info *pm8001_ha)
>  }
>
>  /**
> - * pm8001_chip_interrupt_enable - enable PM8001 chip interrupt
> + * pm80xx_chip_interrupt_enable - enable PM8001 chip interrupt
>   * @pm8001_ha: our hba card information
>   * @vec: interrupt number to enable
>   */
> @@ -1743,7 +1743,7 @@ pm80xx_chip_interrupt_enable(struct pm8001_hba_info 
> *pm8001_ha, u8 vec)
>  }
>
>  /**
> - * pm8001_chip_interrupt_disable- disable PM8001 chip interrupt
> + * pm80xx_chip_interrupt_disable - disable PM8001 chip interrupt
>   * @pm8001_ha: our hba card information
>   * @vec: interrupt number to disable
>   */
> @@ -4183,7 +4183,7 @@ static void build_smp_cmd(u32 deviceID, __le32 hTag,
>  }
>
>  /**
> - * pm8001_chip_smp_req - send a SMP task to FW
> + * pm80xx_chip_smp_req - send a SMP task to FW
>   * @pm8001_ha: our hba card information.
>   * @ccb: the ccb information this request used.
>   */
> @@ -4766,7 +4766,7 @@ pm80xx_chip_phy_start_req(struct pm8001_hba_info 
> *pm8001_ha, u8 phy_id)
>  }
>
>  /**
> - * pm8001_chip_phy_stop_req - start phy via PHY_STOP COMMAND
> + * pm80xx_chip_phy_stop_req - start phy via PHY_STOP COMMAND
>   * @pm8001_ha: our hba card information.
>   * @phy_id: the phy id which we wanted to start up.
>   */
> @@ -4898,7 +4898,7 @@ static u32 pm80xx_chip_is_our_interrupt(struct 
> pm8001_hba_info *pm8001_ha)
>  }
>
>  /**
> - * pm8001_chip_isr - PM8001 isr handler.
> + * pm80xx_chip_isr - PM8001 isr handler.
>   * @pm8001_ha: our hba card information.
>   * @vec: i

Re: [PATCH 18/30] scsi: pm8001: pm8001_hwi: Fix some misnamed function descriptions

[Jinpu Wang]

On Wed, Mar 3, 2021 at 3:47 PM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/scsi/pm8001/pm8001_hwi.c:1183: warning: expecting prototype for 
> pm8001_chip_interrupt_enable(). Prototype was for 
> pm8001_chip_intx_interrupt_enable() instead
>  drivers/scsi/pm8001/pm8001_hwi.c:1257: warning: expecting prototype for 
> pm8001_chip_intx_interrupt_disable(). Prototype was for 
> pm8001_chip_interrupt_disable() instead
>  drivers/scsi/pm8001/pm8001_hwi.c:3235: warning: expecting prototype for 
> asd_get_attached_sas_addr(). Prototype was for pm8001_get_attached_sas_addr() 
> instead
>  drivers/scsi/pm8001/pm8001_hwi.c:3555: warning: expecting prototype for 
> fw_flash_update_resp(). Prototype was for pm8001_mpi_fw_flash_update_resp() 
> instead
>
> Cc: Jack Wang 
> Cc: "James E.J. Bottomley" 
> Cc: "Martin K. Petersen" 
> Cc: linux-s...@vger.kernel.org
> Signed-off-by: Lee Jones 
Acked-by: Jack Wang 
Thanks
> ---
>  drivers/scsi/pm8001/pm8001_hwi.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c 
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index 49bf2f70a470e..6b600e33e9e8d 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -1175,7 +1175,7 @@ void pm8001_chip_iounmap(struct pm8001_hba_info 
> *pm8001_ha)
>
>  #ifndef PM8001_USE_MSIX
>  /**
> - * pm8001_chip_interrupt_enable - enable PM8001 chip interrupt
> + * pm8001_chip_intx_interrupt_enable - enable PM8001 chip interrupt
>   * @pm8001_ha: our hba card information
>   */
>  static void
> @@ -1248,7 +1248,7 @@ pm8001_chip_interrupt_enable(struct pm8001_hba_info 
> *pm8001_ha, u8 vec)
>  }
>
>  /**
> - * pm8001_chip_intx_interrupt_disable- disable PM8001 chip interrupt
> + * pm8001_chip_interrupt_disable - disable PM8001 chip interrupt
>   * @pm8001_ha: our hba card information
>   * @vec: unused
>   */
> @@ -3219,7 +3219,7 @@ void pm8001_get_lrate_mode(struct pm8001_phy *phy, u8 
> link_rate)
>  }
>
>  /**
> - * asd_get_attached_sas_addr -- extract/generate attached SAS address
> + * pm8001_get_attached_sas_addr - extract/generate attached SAS address
>   * @phy: pointer to asd_phy
>   * @sas_addr: pointer to buffer where the SAS address is to be written
>   *
> @@ -3546,7 +3546,7 @@ int pm8001_mpi_dereg_resp(struct pm8001_hba_info 
> *pm8001_ha, void *piomb)
>  }
>
>  /**
> - * fw_flash_update_resp - Response from FW for flash update command.
> + * pm8001_mpi_fw_flash_update_resp - Response from FW for flash update 
> command.
>   * @pm8001_ha: our hba card information
>   * @piomb: IO message buffer
>   */
> --
> 2.27.0
>

Re: linux-next: build failure after merge of the pinctrl tree

[Stephen Rothwell]

Hi Linus,

On Thu, 4 Mar 2021 09:16:17 +0100 Linus Walleij  
wrote:
>
> On Thu, Mar 4, 2021 at 2:12 AM Stephen Rothwell  wrote:
> 
> > After merging the pinctrl tree, today's linux-next build (x86_64
> > allmodconfig ) failed like this:
> >
> >
> > Presumably caused by commit
> >
> >   c9e84d46cc03 ("pinctrl: rockchip: make driver be tristate module")
> >
> > I have used the pinctrl tree from next-20210303 for today.  
> 
> Thanks Stephen, I'm taking the patch out again.

Sorry I managed to not put the error message in the mail :-(

-- 
Cheers,
Stephen Rothwell


pgp_d2jNe5plS.pgp
Description: OpenPGP digital signature

Re: [PATCH] KVM: arm64: Fix unaligned addr case in mmu walking

[Marc Zyngier]

On Wed, 3 Mar 2021 10:42:25 +0800, Jia He wrote:
> If the start addr is not aligned with the granule size of that level.
> loop step size should be adjusted to boundary instead of simple
> kvm_granual_size(level) increment. Otherwise, some mmu entries might miss
> the chance to be walked through.
> E.g. Assume the unmap range [data->addr, data->end] is
> [0xff00ab2000,0xff00cb2000] in level 2 walking and NOT block mapping.
> And the 1st part of that pmd entry is [0xff00ab2000,0xff00c0]. The
> pmd value is 0x83fbd2c1002 (not valid entry). In this case, data->addr
> should be adjusted to 0xff00c0 instead of 0xff00cb2000.
> 
> [...]

Applied to fixes, thanks!

[1/1] KVM: arm64: Fix unaligned addr case in mmu walking
  commit: e85583b3f1fe62c9b371a3100c1c91af94005ca9

Cheers,

M.
-- 
Without deviation from the norm, progress is not possible.

[PATCH v4] mm/userfaultfd: fix memory corruption due to writeprotect

[Nadav Amit]

From: Nadav Amit 

Userfaultfd self-test fails occasionally, indicating a memory
corruption.

Analyzing this problem indicates that there is a real bug since
mmap_lock is only taken for read in mwriteprotect_range() and defers
flushes, and since there is insufficient consideration of concurrent
deferred TLB flushes in wp_page_copy(). Although the PTE is flushed from
the TLBs in wp_page_copy(), this flush takes place after the copy has
already been performed, and therefore changes of the page are possible
between the time of the copy and the time in which the PTE is flushed.

To make matters worse, memory-unprotection using userfaultfd also poses
a problem. Although memory unprotection is logically a promotion of PTE
permissions, and therefore should not require a TLB flush, the current
userrfaultfd code might actually cause a demotion of the architectural
PTE permission: when userfaultfd_writeprotect() unprotects memory
region, it unintentionally *clears* the RW-bit if it was already set.
Note that this unprotecting a PTE that is not write-protected is a valid
use-case: the userfaultfd monitor might ask to unprotect a region that
holds both write-protected and write-unprotected PTEs.

The scenario that happens in selftests/vm/userfaultfd is as follows:

cpu0cpu1cpu2

[ Writable PTE
  cached in TLB ]
userfaultfd_writeprotect()
[ write-*unprotect* ]
mwriteprotect_range()
mmap_read_lock()
change_protection()

change_protection_range()
...
change_pte_range()
[ *clear* “write”-bit ]
[ defer TLB flushes ]
[ page-fault ]
...
wp_page_copy()
 cow_user_page()
  [ copy page ]
[ write to old
  page ]
...
 set_pte_at_notify()

A similar scenario can happen:

cpu0cpu1cpu2cpu3

[ Writable PTE
  cached in TLB ]
userfaultfd_writeprotect()
[ write-protect ]
[ deferred TLB flush ]
userfaultfd_writeprotect()
[ write-unprotect ]
[ deferred TLB flush]
[ page-fault ]
wp_page_copy()
 cow_user_page()
 [ copy page ]
 ...[ write to page ]
set_pte_at_notify()

This race exists since commit 292924b26024 ("userfaultfd: wp: apply
_PAGE_UFFD_WP bit"). Yet, as Yu Zhao pointed, these races became
apparent since commit 09854ba94c6a ("mm: do_wp_page() simplification")
which made wp_page_copy() more likely to take place, specifically if
page_count(page) > 1.

To resolve the aforementioned races, check whether there are pending
flushes on uffd-write-protected VMAs, and if there are, perform a flush
before doing the COW.

Further optimizations will follow to avoid during uffd-write-unprotect
unnecassary PTE write-protection and TLB flushes.

Cc: Andrea Arcangeli 
Cc: Andy Lutomirski 
Cc: Pavel Emelyanov 
Cc: Mike Kravetz 
Cc: Mike Rapoport 
Cc: Minchan Kim 
Cc: Will Deacon 
Cc: Peter Zijlstra 
Cc: sta...@vger.kernel.org # 5.9+
Suggested-by: Yu Zhao 
Reviewed-by: Peter Xu 
Tested-by: Peter Xu 
Fixes: 09854ba94c6a ("mm: do_wp_page() simplification")
Signed-off-by: Nadav Amit 

---
v3->v4:
* Fix the "Fixes" tag for real [Peter Xu]
* Reviewed-by, suggested-by tags [Peter Xu]
* Adding unlikely() [Peter Xu]

v2->v3:
* Do not acquire mmap_lock for write, flush conditionally instead [Yu]
* Change the fixes tag to the patch that made the race apparent [Yu]
* Removing patch to avoid write-protect on uffd unprotect. More
  comprehensive solution to follow (and avoid the TLB flush as well).
---
 mm/memory.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/mm/memory.c b/mm/memory.c
index 9e8576a83147..79253cb3bcd5 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3092,6 +3092,14 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf)
return handle_userfault(vmf, VM_UFFD_WP);
}
 
+   /*
+* Userfaultfd write-protect can defer flushes. Ensure the TLB
+* is flushed in this case before copying.
+*/
+   if (unlikely(userfaultfd_wp(vmf->vma) &&
+mm_tlb_flush_pending(vmf->vma->vm_mm)))
+   flush_tlb_page(vmf->vma, vmf->address);
+
vmf->page = vm_normal_page(vma, vmf->address, vmf->orig_pte);

Re: possible deadlock in sk_clone_lock

[Michal Hocko]

On Wed 03-03-21 09:59:45, Paul E. McKenney wrote:
> On Wed, Mar 03, 2021 at 09:03:27AM +0100, Michal Hocko wrote:
[...]
> > Paul what is the current plan with in_atomic to be usable for !PREEMPT
> > configurations?
> 
> Ah, thank you for the reminder!  I have rebased that series on top of
> v5.12-rc1 on -rcu branch tglx-pc.2021.03.03a.
> 
> The current state is that Linus is not convinced that this change is
> worthwhile given that only RCU and printk() want it.  (BPF would use
> it if it were available, but is willing to live without it, at least in
> the short term.)
> 
> But maybe Linus will be convinced given your additional use case.
> Here is hoping!

Yes, hugetlb freeing path would benefit from this. You can reference
this lockdep report 
(http://lkml.kernel.org/r/f1c03b05bc43a...@google.com)
with an additional argument that making hugetlb_lock irq safe is a
larger undertaking and we will need something reasonably backportable
for older kernels as well.
-- 
Michal Hocko
SUSE Labs

[PATCH v3 0/5] Allocate memmap from hotadded memory (per device)

[Oscar Salvador]

Hi,

here is v3.

Changes from v2 -> v3:
 - Addressed feedback from David
 - Squash former patch#4 and and patch#5 into patch#1
 - Fix config dependency CONFIR_SPARSE_VMEMMAP vs CONFIG_SPARSE_VMEMMAP_ENABLE
 - Simplify module parameter functions

Changes from v1 -> v2
 - Addressed feedback from David
 - Fence off the feature in case struct page size is not
   multiple of PMD size or pageblock alignment cannot be guaranted
 - Tested on x86_64 small and large memory_blocks
 - Tested on arm64 4KB and 64KB page sizes (for some reason I cannot boot
   my VM with 16KB page size).

 Arm64 with 4KB page size behaves like x86_64 after [1], which made section
 size smaller.
 With 64KB, the feature gets fenced off due to pageblock alignment.

Changes from RFCv3 -> v1:
 - Addressed feedback from David
 - Re-order patches

Changes from v2 -> v3 (RFC):
 - Re-order patches (Michal)
 - Fold "mm,memory_hotplug: Introduce MHP_MEMMAP_ON_MEMORY" in patch#1
 - Add kernel boot option to enable this feature (Michal)

Changes from v1 -> v2 (RFC):
 - Addressed feedback provided by David
 - Add a arch_support_memmap_on_memory to be called
   from mhp_supports_memmap_on_memory, as atm,
   only ARM, powerpc and x86_64 have altmat support.

[1] https://lore.kernel.org/lkml/cover.1611206601.git.sudar...@codeaurora.org/

Original cover letter:



The primary goal of this patchset is to reduce memory overhead of the
hot-added memory (at least for SPARSEMEM_VMEMMAP memory model).
The current way we use to populate memmap (struct page array) has two main 
drawbacks:

a) it consumes an additional memory until the hotadded memory itself is
   onlined and
b) memmap might end up on a different numa node which is especially true
   for movable_node configuration.
c) due to fragmentation we might end up populating memmap with base
   pages

One way to mitigate all these issues is to simply allocate memmap array
(which is the largest memory footprint of the physical memory hotplug)
from the hot-added memory itself. SPARSEMEM_VMEMMAP memory model allows
us to map any pfn range so the memory doesn't need to be online to be
usable for the array. See patch 3 for more details.
This feature is only usable when CONFIG_SPARSEMEM_VMEMMAP is set.

[Overall design]:

Implementation wise we reuse vmem_altmap infrastructure to override
the default allocator used by vmemap_populate.
memory_block structure gained a new field called nr_vmemmap_pages.
This plays well for two reasons:

 1) {offline/online}_pages know the difference between start_pfn and
buddy_start_pfn, which is start_pfn + nr_vmemmap_pages.
In this way all isolation/migration operations are
done to within the right range of memory without vmemmap pages.
This allows us for a much cleaner handling.

 2) In try_remove_memory, we construct a new vmemap_altmap struct with the
right information based on memory_block->nr_vmemap_pages, so we end up
calling vmem_altmap_free instead of free_pagetable when removing the memory.

Oscar Salvador (5):
  mm,memory_hotplug: Allocate memmap from the added memory range
  acpi,memhotplug: Enable MHP_MEMMAP_ON_MEMORY when supported
  mm,memory_hotplug: Add kernel boot option to enable memmap_on_memory
  x86/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE
  arm64/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE

 Documentation/admin-guide/kernel-parameters.txt |  14 +++
 arch/arm64/Kconfig  |   4 +
 arch/x86/Kconfig|   4 +
 drivers/acpi/acpi_memhotplug.c  |   5 +-
 drivers/base/memory.c   |  20 +--
 include/linux/memory.h  |   8 +-
 include/linux/memory_hotplug.h  |  21 +++-
 include/linux/memremap.h|   2 +-
 include/linux/mmzone.h  |   5 +
 mm/Kconfig  |   4 +
 mm/Makefile |   5 +-
 mm/memory_hotplug.c | 155 
 mm/page_alloc.c |   4 +-
 13 files changed, 213 insertions(+), 38 deletions(-)

-- 
2.16.3

[PATCH v3 3/5] mm,memory_hotplug: Add kernel boot option to enable memmap_on_memory

[Oscar Salvador]

Self stored memmap leads to a sparse memory situation which is unsuitable
for workloads that requires large contiguous memory chunks, so make this
an opt-in which needs to be explicitly enabled.

To control this, let memory_hotplug have its own memory space, as suggested
by David, so we can add memory_hotplug.memmap_on_memory parameter.

Signed-off-by: Oscar Salvador 
---
 Documentation/admin-guide/kernel-parameters.txt | 14 ++
 mm/Makefile |  5 -
 mm/memory_hotplug.c |  8 +++-
 3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..e626dab39c60 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2794,6 +2794,20 @@
seconds.  Use this parameter to check at some
other rate.  0 disables periodic checking.
 
+   memory_hotplug.memmap_on_memory
+   [KNL,X86,ARM] Boolean flag to enable this feature.
+   Format: {on | off (default)}
+   When enabled, memory to build the pages tables for the
+   memmap array describing the hot-added range will be 
taken
+   from the range itself, so the memmap page tables will be
+   self-hosted.
+   Since only single memory device ranges are supported at
+   the moment, this option is disabled by default because
+   it might have an impact on workloads that needs large
+   contiguous memory chunks.
+   The state of the flag can be read in
+   /sys/module/memory_hotplug/parameters/memmap_on_memory.
+
memtest=[KNL,X86,ARM,PPC] Enable memtest
Format: 
default : 0 
diff --git a/mm/Makefile b/mm/Makefile
index 72227b24a616..82ae9482f5e3 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -58,9 +58,13 @@ obj-y:= filemap.o mempool.o 
oom_kill.o fadvise.o \
 page-alloc-y := page_alloc.o
 page-alloc-$(CONFIG_SHUFFLE_PAGE_ALLOCATOR) += shuffle.o
 
+# Give 'memory_hotplug' its own module-parameter namespace
+memory-hotplug-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
+
 obj-y += page-alloc.o
 obj-y += init-mm.o
 obj-y += memblock.o
+obj-y += $(memory-hotplug-y)
 
 ifdef CONFIG_MMU
obj-$(CONFIG_ADVISE_SYSCALLS)   += madvise.o
@@ -83,7 +87,6 @@ obj-$(CONFIG_SLUB) += slub.o
 obj-$(CONFIG_KASAN)+= kasan/
 obj-$(CONFIG_KFENCE) += kfence/
 obj-$(CONFIG_FAILSLAB) += failslab.o
-obj-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
 obj-$(CONFIG_MEMTEST)  += memtest.o
 obj-$(CONFIG_MIGRATION) += migrate.o
 obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o khugepaged.o
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 63e5a0e9a6f3..94b0ec3d2ff2 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -42,7 +42,13 @@
 #include "internal.h"
 #include "shuffle.h"
 
-static bool memmap_on_memory;
+
+/*
+ * memory_hotplug.memmap_on_memory parameter
+ */
+static bool memmap_on_memory __ro_after_init;
+module_param(memmap_on_memory, bool, 0444);
+MODULE_PARM_DESC(memmap_on_memory, "Enable memmap on memory for memory 
hotplug");
 
 /*
  * online_page_callback contains pointer to current page onlining function.
-- 
2.16.3

[PATCH v3 5/5] arm64/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE

[Oscar Salvador]

Enable arm64 platform to use the MHP_MEMMAP_ON_MEMORY feature.

Signed-off-by: Oscar Salvador 
---
 arch/arm64/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f212b47a48a..3c5380c626df 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -309,6 +309,10 @@ config ARCH_ENABLE_MEMORY_HOTPLUG
 config ARCH_ENABLE_MEMORY_HOTREMOVE
def_bool y
 
+config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE
+   def_bool y
+   depends on MEMORY_HOTPLUG
+
 config SMP
def_bool y
 
-- 
2.16.3

Re: [PATCH v9 0/4] Introduce TEE based Trusted Keys support

[Sumit Garg]

Hi Jarkko,

On Mon, 1 Mar 2021 at 18:41, Sumit Garg  wrote:
>
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key. Also, this is
> an alternative in case platform doesn't possess a TPM device.
>
> This patch-set has been tested with OP-TEE based early TA which is already
> merged in upstream [1].
>
> [1] 
> https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b
>
> Changes in v9:
> 1. Rebased to latest tpmdd/master.
> 2. Defined pr_fmt() and removed redundant tags.
> 3. Patch #2: incorporated misc. comments.
> 4. Patch #3: incorporated doc changes from Elaine and misc. comments
>from Randy.
> 5. Patch #4: reverted to separate maintainer entry as per request from
>Jarkko.
> 6. Added Jarkko's Tested-by: tag on patch #2.

It looks like we don't have any further comments on this patch-set. So
would you be able to pick up this patch-set?

-Sumit

>
> Changes in v8:
> 1. Added static calls support instead of indirect calls.
> 2. Documented trusted keys source module parameter.
> 3. Refined patch #1 commit message discription.
> 4. Addressed misc. comments on patch #2.
> 5. Added myself as Trusted Keys co-maintainer instead.
> 6. Rebased to latest tpmdd master.
>
> Changes in v7:
> 1. Added a trusted.source module parameter in order to enforce user's
>choice in case a particular platform posses both TPM and TEE.
> 2. Refine commit description for patch #1.
>
> Changes in v6:
> 1. Revert back to dynamic detection of trust source.
> 2. Drop author mention from trusted_core.c and trusted_tpm1.c files.
> 3. Rebased to latest tpmdd/master.
>
> Changes in v5:
> 1. Drop dynamic detection of trust source and use compile time flags
>instead.
> 2. Rename trusted_common.c -> trusted_core.c.
> 3. Rename callback: cleanup() -> exit().
> 4. Drop "tk" acronym.
> 5. Other misc. comments.
> 6. Added review tags for patch #3 and #4.
>
> Changes in v4:
> 1. Pushed independent TEE features separately:
>   - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062
> 2. Updated trusted-encrypted doc with TEE as a new trust source.
> 3. Rebased onto latest tpmdd/master.
>
> Changes in v3:
> 1. Update patch #2 to support registration of multiple kernel pages.
> 2. Incoporate dependency patch #4 in this patch-set:
>https://patchwork.kernel.org/patch/11091435/
>
> Changes in v2:
> 1. Add reviewed-by tags for patch #1 and #2.
> 2. Incorporate comments from Jens for patch #3.
> 3. Switch to use generic trusted keys framework.
>
> Sumit Garg (4):
>   KEYS: trusted: Add generic trusted keys framework
>   KEYS: trusted: Introduce TEE based Trusted Keys
>   doc: trusted-encrypted: updates with TEE as a new trust source
>   MAINTAINERS: Add entry for TEE based Trusted Keys
>
>  .../admin-guide/kernel-parameters.txt |  12 +
>  .../security/keys/trusted-encrypted.rst   | 171 ++--
>  MAINTAINERS   |   8 +
>  include/keys/trusted-type.h   |  53 +++
>  include/keys/trusted_tee.h|  16 +
>  include/keys/trusted_tpm.h|  29 +-
>  security/keys/trusted-keys/Makefile   |   2 +
>  security/keys/trusted-keys/trusted_core.c | 358 +
>  security/keys/trusted-keys/trusted_tee.c  | 317 +++
>  security/keys/trusted-keys/trusted_tpm1.c | 366 --
>  10 files changed, 981 insertions(+), 351 deletions(-)
>  create mode 100644 include/keys/trusted_tee.h
>  create mode 100644 security/keys/trusted-keys/trusted_core.c
>  create mode 100644 security/keys/trusted-keys/trusted_tee.c
>
> --
> 2.25.1
>

Re: [PATCH v26 4/4] scsi: ufs: Add HPB 2.0 support

[Bean Huo]

On Wed, 2021-03-03 at 15:29 +0900, Daejun Park wrote:
> +
> +static inline int ufshpb_get_read_id(struct ufshpb_lu *hpb)
> +{
> +   if (++hpb->cur_read_id >= MAX_HPB_READ_ID)
> +   hpb->cur_read_id = 0;
> +   return hpb->cur_read_id;
> +}
> +
> +static int ufshpb_execute_pre_req(struct ufshpb_lu *hpb, struct
> scsi_cmnd *cmd,
> + struct ufshpb_req *pre_req, int
> read_id)
> +{
> +   struct scsi_device *sdev = cmd->device;
> +   struct request_queue *q = sdev->request_queue;
> +   struct request *req;
> +   struct scsi_request *rq;
> +   struct bio *bio = pre_req->bio;
> +
> +   pre_req->hpb = hpb;
> +   pre_req->wb.lpn = sectors_to_logical(cmd->device,
> +blk_rq_pos(cmd-
> >request));
> +   pre_req->wb.len = sectors_to_logical(cmd->device,
> +blk_rq_sectors(cmd-
> >request));
> +   if (ufshpb_pre_req_add_bio_page(hpb, q, pre_req))
> +   return -ENOMEM;
> +
> +   req = pre_req->req;
> +
> +   /* 1. request setup */
> +   blk_rq_append_bio(req, &bio);
> +   req->rq_disk = NULL;
> +   req->end_io_data = (void *)pre_req;
> +   req->end_io = ufshpb_pre_req_compl_fn;
> +
> +   /* 2. scsi_request setup */
> +   rq = scsi_req(req);
> +   rq->retries = 1;
> +
> +   ufshpb_set_write_buf_cmd(rq->cmd, pre_req->wb.lpn, pre_req-
> >wb.len,
> +read_id);
> +   rq->cmd_len = scsi_command_size(rq->cmd);
> +
> +   if (blk_insert_cloned_request(q, req) != BLK_STS_OK)
> +   return -EAGAIN;
> +
> +   hpb->stats.pre_req_cnt++;
> +
> +   return 0;
> +}
> +
> +static int ufshpb_issue_pre_req(struct ufshpb_lu *hpb, struct
> scsi_cmnd *cmd,
> +   int *read_id)
> +{
> +   struct ufshpb_req *pre_req;
> +   struct request *req = NULL;
> +   struct bio *bio = NULL;
> +   unsigned long flags;
> +   int _read_id;
> +   int ret = 0;
> +
> +   req = blk_get_request(cmd->device->request_queue,
> + REQ_OP_SCSI_OUT | REQ_SYNC,
> BLK_MQ_REQ_NOWAIT);
> +   if (IS_ERR(req))
> +   return -EAGAIN;
> +
> +   bio = bio_alloc(GFP_ATOMIC, 1);
> +   if (!bio) {
> +   blk_put_request(req);
> +   return -EAGAIN;
> +   }
> +
> +   spin_lock_irqsave(&hpb->rgn_state_lock, flags);
> +   pre_req = ufshpb_get_pre_req(hpb);
> +   if (!pre_req) {
> +   ret = -EAGAIN;
> +   goto unlock_out;
> +   }
> +   _read_id = ufshpb_get_read_id(hpb);
> +   spin_unlock_irqrestore(&hpb->rgn_state_lock, flags);
> +
> +   pre_req->req = req;
> +   pre_req->bio = bio;
> +
> +   ret = ufshpb_execute_pre_req(hpb, cmd, pre_req, _read_id);
> +   if (ret)
> +   goto free_pre_req;
> +
> +   *read_id = _read_id;
> +
> +   return ret;
> +free_pre_req:
> +   spin_lock_irqsave(&hpb->rgn_state_lock, flags);
> +   ufshpb_put_pre_req(hpb, pre_req);
> +unlock_out:
> +   spin_unlock_irqrestore(&hpb->rgn_state_lock, flags);
> +   bio_put(bio);
> +   blk_put_request(req);
> +   return ret;
> +}
> +
>  /*
>   * This function will set up HPB read command using host-side L2P
> map data.
> - * In HPB v1.0, maximum size of HPB read command is 4KB.
>   */
> -void ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
> +int ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
>  {
> struct ufshpb_lu *hpb;
> struct ufshpb_region *rgn;
> @@ -291,26 +560,27 @@ void ufshpb_prep(struct ufs_hba *hba, struct
> ufshcd_lrb *lrbp)
> u64 ppn;
> unsigned long flags;
> int transfer_len, rgn_idx, srgn_idx, srgn_offset;
> +   int read_id = 0;
> int err = 0;
>  
> hpb = ufshpb_get_hpb_data(cmd->device);
> if (!hpb)
> -   return;
> +   return -ENODEV;
>  
> if (ufshpb_get_state(hpb) != HPB_PRESENT) {
> dev_notice(&hpb->sdev_ufs_lu->sdev_dev,
>"%s: ufshpb state is not PRESENT",
> __func__);
> -   return;
> +   return -ENODEV;
> }
>  
> if (!ufshpb_is_write_or_discard_cmd(cmd) &&
> !ufshpb_is_read_cmd(cmd))
> -   return;
> +   return 0;
>  
> transfer_len = sectors_to_logical(cmd->device,
>   blk_rq_sectors(cmd-
> >request));
> if (unlikely(!transfer_len))
> -   return;
> +   return 0;
>  
> lpn = sectors_to_logical(cmd->device, blk_rq_pos(cmd-
> >request));
> ufshpb_get_pos_from_lpn(hpb, lpn, &rgn_idx, &srgn_idx,
> &srgn_offset);
> @@ -323,18 +593,19 @@ void ufshpb_prep(struct ufs_hba *hba, struct
> ufshcd_lrb *lrbp)
> ufshpb_set_ppn_dirty(hpb, rgn_idx, srgn_idx,
>

[PATCH v3 1/5] mm,memory_hotplug: Allocate memmap from the added memory range

[Oscar Salvador]

Physical memory hotadd has to allocate a memmap (struct page array) for
the newly added memory section. Currently, alloc_pages_node() is used
for those allocations.

This has some disadvantages:
 a) an existing memory is consumed for that purpose
(eg: ~2MB per 128MB memory section on x86_64)
 b) if the whole node is movable then we have off-node struct pages
which has performance drawbacks.
 c) It might be there are no PMD_ALIGNED chunks so memmap array gets
populated with base pages.

This can be improved when CONFIG_SPARSEMEM_VMEMMAP is enabled.

Vmemap page tables can map arbitrary memory.
That means that we can simply use the beginning of each memory section and
map struct pages there.
struct pages which back the allocated space then just need to be treated
carefully.

Implementation wise we will reuse vmem_altmap infrastructure to override
the default allocator used by __populate_section_memmap.
Part of the implementation also relies on memory_block structure gaining
a new field which specifies the number of vmemmap_pages at the beginning.
This comes in handy as in {online,offline}_pages, all the isolation and
migration is being done on (buddy_start_pfn, end_pfn] range,
being buddy_start_pfn = start_pfn + nr_vmemmap_pages.

In this way, we have:

[start_pfn, buddy_start_pfn - 1] = Initialized and PageReserved
[buddy_start_pfn, end_pfn - 1]   = Initialized and sent to buddy

Hot-remove:

 We need to be careful when removing memory, as adding and
 removing memory needs to be done with the same granularity.
 To check that this assumption is not violated, we check the
 memory range we want to remove and if a) any memory block has
 vmemmap pages and b) the range spans more than a single memory
 block, we scream out loud and refuse to proceed.

 If all is good and the range was using memmap on memory (aka vmemmap pages),
 we construct an altmap structure so free_hugepage_table does the right
 thing and calls vmem_altmap_free instead of free_pagetable.

Signed-off-by: Oscar Salvador 
---
 drivers/base/memory.c  |  20 +++---
 include/linux/memory.h |   8 ++-
 include/linux/memory_hotplug.h |  21 --
 include/linux/memremap.h   |   2 +-
 include/linux/mmzone.h |   5 ++
 mm/Kconfig |   4 ++
 mm/memory_hotplug.c| 149 +++--
 mm/page_alloc.c|   4 +-
 8 files changed, 177 insertions(+), 36 deletions(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index f35298425575..5ea2b3fbce02 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -175,7 +175,7 @@ int memory_notify(unsigned long val, void *v)
  */
 static int
 memory_block_action(unsigned long start_section_nr, unsigned long action,
-   int online_type, int nid)
+   int online_type, int nid, unsigned long nr_vmemmap_pages)
 {
unsigned long start_pfn;
unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
@@ -185,10 +185,11 @@ memory_block_action(unsigned long start_section_nr, 
unsigned long action,
 
switch (action) {
case MEM_ONLINE:
-   ret = online_pages(start_pfn, nr_pages, online_type, nid);
+   ret = online_pages(start_pfn, nr_pages, nr_vmemmap_pages,
+  online_type, nid);
break;
case MEM_OFFLINE:
-   ret = offline_pages(start_pfn, nr_pages);
+   ret = offline_pages(start_pfn, nr_pages, nr_vmemmap_pages);
break;
default:
WARN(1, KERN_WARNING "%s(%ld, %ld) unknown action: "
@@ -211,7 +212,7 @@ static int memory_block_change_state(struct memory_block 
*mem,
mem->state = MEM_GOING_OFFLINE;
 
ret = memory_block_action(mem->start_section_nr, to_state,
- mem->online_type, mem->nid);
+ mem->online_type, mem->nid, 
mem->nr_vmemmap_pages);
 
mem->state = ret ? from_state_req : to_state;
 
@@ -567,7 +568,8 @@ int register_memory(struct memory_block *memory)
return ret;
 }
 
-static int init_memory_block(unsigned long block_id, unsigned long state)
+static int init_memory_block(unsigned long block_id, unsigned long state,
+unsigned long nr_vmemmap_pages)
 {
struct memory_block *mem;
int ret = 0;
@@ -584,6 +586,7 @@ static int init_memory_block(unsigned long block_id, 
unsigned long state)
mem->start_section_nr = block_id * sections_per_block;
mem->state = state;
mem->nid = NUMA_NO_NODE;
+   mem->nr_vmemmap_pages = nr_vmemmap_pages;
 
ret = register_memory(mem);
 
@@ -603,7 +606,7 @@ static int add_memory_block(unsigned long base_section_nr)
if (section_count == 0)
return 0;
return init_memory_block(memory_block_id(base_section_nr),
-MEM_ONLINE);
+ 

[PATCH v3 4/5] x86/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE

[Oscar Salvador]

Enable x86_64 platform to use the MHP_MEMMAP_ON_MEMORY feature.

Signed-off-by: Oscar Salvador 
---
 arch/x86/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879d398e..6d716d8bce1e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2433,6 +2433,10 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
def_bool y
depends on MEMORY_HOTPLUG
 
+config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE
+   def_bool y
+   depends on X86_64 && MEMORY_HOTPLUG
+
 config USE_PERCPU_NUMA_NODE_ID
def_bool y
depends on NUMA
-- 
2.16.3

[PATCH v3 2/5] acpi,memhotplug: Enable MHP_MEMMAP_ON_MEMORY when supported

[Oscar Salvador]

Let the caller check whether it can pass MHP_MEMMAP_ON_MEMORY by
checking mhp_supports_memmap_on_memory().
MHP_MEMMAP_ON_MEMORY can only be set in case
ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE is enabled, the architecture supports
altmap, and the range to be added spans a single memory block.

Signed-off-by: Oscar Salvador 
Reviewed-by: David Hildenbrand 
---
 drivers/acpi/acpi_memhotplug.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index b02fd51e5589..8cc195c4c861 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -171,6 +171,7 @@ static int acpi_memory_enable_device(struct 
acpi_memory_device *mem_device)
acpi_handle handle = mem_device->device->handle;
int result, num_enabled = 0;
struct acpi_memory_info *info;
+   mhp_t mhp_flags = MHP_NONE;
int node;
 
node = acpi_get_node(handle);
@@ -194,8 +195,10 @@ static int acpi_memory_enable_device(struct 
acpi_memory_device *mem_device)
if (node < 0)
node = memory_add_physaddr_to_nid(info->start_addr);
 
+   if (mhp_supports_memmap_on_memory(info->length))
+   mhp_flags |= MHP_MEMMAP_ON_MEMORY;
result = __add_memory(node, info->start_addr, info->length,
- MHP_NONE);
+ mhp_flags);
 
/*
 * If the memory block has been used by the kernel, add_memory()
-- 
2.16.3

Re: [PATCH] ALSA: usb-audio: Disable USB autosuspend properly in setup_disable_autosuspend()

[Kai-Heng Feng]

Hi Joakim,

On Thu, Mar 4, 2021 at 5:50 PM Joakim Tjernlund
 wrote:
>
> On Thu, 2021-03-04 at 12:34 +0800, Kai-Heng Feng wrote:
> > Rear audio on Lenovo ThinkStation P620 stops working after commit
> > 1965c4364bdd ("ALSA: usb-audio: Disable autosuspend for Lenovo
> > ThinkStation P620"):
> > [6.013526] usbcore: registered new interface driver snd-usb-audio
> > [6.023064] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> > wIndex = 0x0, type = 1
> > [6.023083] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> > wIndex = 0x0, type = 4
> > [6.023090] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> > wIndex = 0x0, type = 1
> > [6.023098] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> > wIndex = 0x0, type = 4
> > [6.023103] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> > wIndex = 0x0, type = 1
> > [6.023110] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> > wIndex = 0x0, type = 4
> > [6.045846] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> > wIndex = 0x0, type = 1
> > [6.045866] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> > wIndex = 0x0, type = 4
> > [6.045877] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> > wIndex = 0x0, type = 1
> > [6.045886] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> > wIndex = 0x0, type = 4
> > [6.045894] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, 
> > wIndex = 0x0, type = 1
> > [6.045908] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, 
> > wIndex = 0x0, type = 4
> >
> > I overlooked the issue because when I was working on the said commit,
> > only the front audio is tested. Apology for that.
> >
> > Changing supports_autosuspend in driver is too late for disabling
> > autosuspend, because it was already used by USB probe routine, so it can
> > break the balance on the following code that depends on
> > supports_autosuspend.
> >
> > Fix it by using usb_disable_autosuspend() helper, and balance the
> > suspend count in disconnect callback.
> >
> > Fixes: 1965c4364bdd ("ALSA: usb-audio: Disable autosuspend for Lenovo 
> > ThinkStation P620")
> > Signed-off-by: Kai-Heng Feng 
>
> I got an report from a co-worker who has no USB sound from a Lenovo ThinkPad 
> in a Ultra Dock.
> USB HS is connected to Dock USB jack.
> Could this be the same problem?

It's a different issue. Please file a separate bug report.

Kai-Heng

>
>  Jocke

Re: [PATCH 5.10 337/663] iommu: Move iotlb_sync_map out from __iommu_map

[Robin Murphy]

On 2021-03-04 08:43, Pavel Machek wrote:

Hi!


[ Upstream commit d8c1df02ac7f2c802a9b2afc0f5c888c4217f1d5 ]

In the end of __iommu_map, It alway call iotlb_sync_map.

This patch moves iotlb_sync_map out from __iommu_map since it is
unnecessary to call this for each sg segment especially iotlb_sync_map
is flush tlb all currently. Add a little helper _iommu_map for this.



Signed-off-by: Sasha Levin 


AFAICT this is slight performance optimalization, not a bugfix. It
actually introduces a bug, fixed by the next patch. I'd preffer not to
have it in stable.


Right, the whole original series was a set of performance/efficiency 
improvements, so I'm not sure there's much justification for backporting 
individual patches out of context. Plus as you say this one has the 
unfortunate gfp bug.


Thanks for spotting this!

Robin.



Best regards,
Pavel


@@ -2421,18 +2418,31 @@ static int __iommu_map(struct iommu_domain *domain, 
unsigned long iova,
  
+static int _iommu_map(struct iommu_domain *domain, unsigned long iova,

+ phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
+{
+   const struct iommu_ops *ops = domain->ops;
+   int ret;
+
+   ret = __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
+   if (ret == 0 && ops->iotlb_sync_map)
+   ops->iotlb_sync_map(domain);
+
+   return ret;
+}

[PATCH v2] mm/compaction: remove unused variable sysctl_compact_memory

[Pintu Kumar]

The sysctl_compact_memory is mostly unused in mm/compaction.c
It just acts as a place holder for sysctl to store .data.

But the .data itself is not needed here.
So we can get ride of this variable completely and make .data as NULL.
This will also eliminate the extern declaration from header file.
No functionality is broken or changed this way.

Signed-off-by: Pintu Kumar 
Signed-off-by: Pintu Agarwal 
---
v2: completely get rid of this variable and set .data to NULL
Suggested-by: Vlastimil Babka 

 include/linux/compaction.h | 1 -
 kernel/sysctl.c| 2 +-
 mm/compaction.c| 3 ---
 3 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index ed4070e..4221888 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -81,7 +81,6 @@ static inline unsigned long compact_gap(unsigned int order)
 }
 
 #ifdef CONFIG_COMPACTION
-extern int sysctl_compact_memory;
 extern unsigned int sysctl_compaction_proactiveness;
 extern int sysctl_compaction_handler(struct ctl_table *table, int write,
void *buffer, size_t *length, loff_t *ppos);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index c9fbdd8..07ef240 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2856,7 +2856,7 @@ static struct ctl_table vm_table[] = {
 #ifdef CONFIG_COMPACTION
{
.procname   = "compact_memory",
-   .data   = &sysctl_compact_memory,
+   .data   = NULL,
.maxlen = sizeof(int),
.mode   = 0200,
.proc_handler   = sysctl_compaction_handler,
diff --git a/mm/compaction.c b/mm/compaction.c
index 190ccda..ede2886 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -2650,9 +2650,6 @@ static void compact_nodes(void)
compact_node(nid);
 }
 
-/* The written value is actually unused, all memory is compacted */
-int sysctl_compact_memory;
-
 /*
  * Tunable for proactive compaction. It determines how
  * aggressively the kernel should compact memory in the
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v24 00/14] Subject: Introduce Data Access MONitor (DAMON)

[SeongJae Park]

On Thu, 4 Feb 2021 16:31:36 +0100 SeongJae Park  wrote:

> From: SeongJae Park 
[...]
> 
> Introduction
> 
> 
> DAMON is a data access monitoring framework for the Linux kernel.  The core
> mechanisms of DAMON called 'region based sampling' and 'adaptive regions
> adjustment' (refer to 'mechanisms.rst' in the 11th patch of this patchset for
> the detail) make it
> 
>  - accurate (The monitored information is useful for DRAM level memory
>management. It might not appropriate for Cache-level accuracy, though.),
>  - light-weight (The monitoring overhead is low enough to be applied online
>while making no impact on the performance of the target workloads.), and
>  - scalable (the upper-bound of the instrumentation overhead is controllable
>regardless of the size of target workloads.).
> 
> Using this framework, therefore, several memory management mechanisms such as
> reclamation and THP can be optimized to aware real data access patterns.
> Experimental access pattern aware memory management optimization works that
> incurring high instrumentation overhead will be able to have another try.
> 
> Though DAMON is for kernel subsystems, it can be easily exposed to the user
> space by writing a DAMON-wrapper kernel subsystem.  Then, user space users who
> have some special workloads will be able to write personalized tools or
> applications for deeper understanding and specialized optimizations of their
> systems.
>
[...]
> 
> Baseline and Complete Git Trees
> ===
> 
> The patches are based on the v5.10.  You can also clone the complete git
> tree:
> 
> $ git clone git://github.com/sjp38/linux -b damon/patches/v24
> 
> The web is also available:
> https://github.com/sjp38/linux/releases/tag/damon/patches/v24
> 
> There are a couple of trees for entire DAMON patchset series.  It includes
> future features.  The first one[1] contains the changes for latest release,
> while the other one[2] contains the changes for next release.
> 
> [1] https://github.com/sjp38/linux/tree/damon/master
> [2] https://github.com/sjp38/linux/tree/damon/next

For people who prefer LTS kernels, I decided to maintain two more trees that
repectively based on latest two LTS kernels and contains backports of the
latest 'damon/master' tree, as below.  Please use those if you want to test
DAMON but using LTS.

- For v5.4.y: https://github.com/sjp38/linux/tree/damon/for-v5.4.y
- For v5.10.y: https://github.com/sjp38/linux/tree/damon/for-v5.10.y


Thanks,
SeongJae Park

Re: [PATCH v4 01/10] coresight: syscfg: Initial coresight system configuration

[Suzuki K Poulose]

On 1/28/21 5:09 PM, Mike Leach wrote:

Creates an system management API to allow complex configurations and
features to be programmed into a CoreSight infrastructure.

A feature is defined as a programming set for a device or class of
devices.

A configuration is a set of features across the system that are enabled
for a trace session.

The API will manage system wide configuration, and allow complex
programmed features to be added to individual device instances, and
provide for system wide configuration selection on trace capture
operations.

This patch creates the initial data object and the initial API for
loading configurations and features.

Signed-off-by: Mike Leach 
---
  drivers/hwtracing/coresight/Makefile  |   2 +-
  .../hwtracing/coresight/coresight-config.h| 167 +++
  drivers/hwtracing/coresight/coresight-core.c  |  12 +-
  .../hwtracing/coresight/coresight-etm-perf.c  |   2 +-
  .../hwtracing/coresight/coresight-etm-perf.h  |   2 +-
  .../hwtracing/coresight/coresight-syscfg.c| 197 ++
  .../hwtracing/coresight/coresight-syscfg.h|  54 +
  7 files changed, 432 insertions(+), 4 deletions(-)
  create mode 100644 drivers/hwtracing/coresight/coresight-config.h
  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.c
  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.h

diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index f20e357758d1..4ce854c434b1 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -4,7 +4,7 @@
  #
  obj-$(CONFIG_CORESIGHT) += coresight.o
  coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
-   coresight-sysfs.o
+   coresight-sysfs.o coresight-syscfg.o
  obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
  coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
  coresight-tmc-etr.o
diff --git a/drivers/hwtracing/coresight/coresight-config.h 
b/drivers/hwtracing/coresight/coresight-config.h
new file mode 100644
index ..3fedf8ab3cee
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -0,0 +1,167 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Linaro Limited, All rights reserved.
+ * Author: Mike Leach 
+ */
+
+#ifndef _CORESIGHT_CORESIGHT_CONFIG_H
+#define _CORESIGHT_CORESIGHT_CONFIG_H
+
+#include 
+#include 
+
+/* CoreSight Configuration Management - component and system wide 
configuration */
+
+/*
+ * Register type flags for register value descriptor:
+ * describe how the value is interpreted, and handled.
+ */
+#define CS_CFG_REG_TYPE_STD0x80/* reg is standard reg */
+#define CS_CFG_REG_TYPE_RESOURCE   0x40/* reg is a resource */
+#define CS_CFG_REG_TYPE_VAL_PARAM  0x08/* reg value uses param */
+#define CS_CFG_REG_TYPE_VAL_MASK   0x04/* reg value bit masked */
+#define CS_CFG_REG_TYPE_VAL_64BIT  0x02/* reg value 64 bit */
+#define CS_CFG_REG_TYPE_VAL_SAVE   0x01/* reg value save on disable */
+
+/*
+ * flags defining what device class a feature will match to when processing a
+ * system configuration - used by config data and devices.
+ */
+#defineCS_CFG_MATCH_CLASS_SRC_ALL  0x0001  /* match any source */
+#define CS_CFG_MATCH_CLASS_SRC_ETM40x0002  /* match any ETMv4 device */
+
+/* flags defining device instance matching - used in config match desc data. */
+#define CS_CFG_MATCH_INST_ANY  0x8000 /* any instance of a class */
+
+/*
+ * Limit number of presets in a configuration
+ * This is related to the number of bits (4) we use to select the preset on
+ * the perf command line. Preset 0 is always none selected.
+ * See PMU_FORMAT_ATTR(preset, "config:0-3") in coresight-etm-perf.c
+ */
+#define CS_CFG_CONFIG_PRESET_MAX 15
+
+/**
+ * Parameter descriptor for a device feature.
+ *
+ * @name:  Name of parameter.
+ * @value: Initial or default value.
+ */
+struct cscfg_parameter_desc {
+   const char *name;
+   u64 value;
+};
+
+/**
+ * Representation of register value.
+ *
+ * Supports full 64 bit register value, or 32 bit value with optional mask
+ * value.
+ *
+ * @type:  define register usage and interpretation.
+ * @offset:the address offset for register in the hardware device (per 
device specification).
+ * @hw_info:   optional hardware device type specific information. (ETM / CTI 
specific etc)
+ * @val64: 64 bit value.
+ * @val32: 32 bit value.
+ * @mask32:32 bit mask when using 32 bit value to access device register.
+ */
+struct cscfg_regval_desc {
+   struct {
+   u32 type:8;
+   u32 offset:12;
+   u32 hw_info:12;
+   };
+   union {
+   u64 val64;
+   struct {
+   u32 val32;
+   u32 mask32;
+   };
+   };
+};
+
+/**
+ * Device feature de

RE: [PATCH v10 0/7] I3C mastership handover support

[Parshuram Raju Thombare]

Ping !

>-Original Message-
>From: Parshuram Thombare 
>Sent: Monday, November 30, 2020 11:46 AM
>To: alexandre.bell...@bootlin.com; slongerb...@gmail.com;
>vitor.soa...@synopsys.com
>Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org; Milind Parab
>; prane...@ti.com; Parshuram Raju Thombare
>
>Subject: [PATCH v10 0/7] I3C mastership handover support
>
>Main changes between v9 and v10 are:
>- Fix build failure reported by kernel test robot
>
>Main changes between v8 and v9 are:
>- Fix NULL dereference issue in current_master_show when
>  cat'ing sysfs key current_master for secondary master
>  before primary master gets initialized.
>
>Main changes between v7 and v8 are:
>- Document format changed from table to DOT diagram
>- Appropriate names for few functions
>- Moved mastership request process entirely to the driver
>- Reuse of i3c_master_add_i3c_dev_locked in core defslvs
>  processing
>
>Main changes between v6 and v7 are:
>- Added separate functions for main and secondary
>  master initialization
>- Secondary master initialization don't wait for
>  DEFSLSVS.
>- Change to use I2C device information from DTS,
>  and corresponding changes in controller driver
>  and I3C core DEFSLVS processing to ignore I2C
>  devices received in DEFSLVS
>- Reverted bus_init split
>- Fixed formatting issues in document
>
>Main changes between v5 and v6 are:
>- Moved populate_bus() hook to master subsystem code.
>- For secondary master initialization i3c_master_register
>  spawan separate threads, as secondary master may have to
>  wait for DEFSLVS and bus mastership.
>- Populate bus info is based on DEFSLVS data and take care
>  of hot plugged / unplugged I3C devices.
>- Split bus_init into bus_init and master_set_info callbacks
>- Moved mastership aquire and handover to separate state
>  machines.
>- Added DEFSLVS processing code.
>- Moved back all locks in side the subsystem code.
>- Secondary mastership support to Cadence I3C master
>  controller driver
>- Sysfs key 'i3c_acquire_bus' to acauire bus.
>- NULL check for pool pointer in i3c_generic_ibi_free_pool.
>
>Main changes between v4 and v5 are:
>- Add populate_bus() hook
>- Split i3c_master_register into init and register pair
>- Split device information retrieval, let add partialy discovered devices
>- Make i3c_master_set_info private
>- Add separate function to register secondary master
>- Reworked secondary master register in CDNS driver
>- Export i3c_bus_set_mode
>
>Main changes between v3 and v4 are:
>- Reworked acquire bus ownership
>- Refactored the code
>
>Main changes between v2 and v3 are:
>- Added DEFSLVS devices are registered from master driver
>- Reworked I2C registering on secondary master side
>- Reworked Mastership event is enabled/disabled globally (for all devices)
>
>Main changes between initial version and v2 are:
>- Reworked devices registration on secondary master side
>- Reworked mastership event disabling/enabling
>- Reworked bus locking during mastership takeover process
>- Added DEFSLVS devices registration during initialization
>- Fixed style issues
>
>Parshuram Thombare (7):
>  i3c: master: master initialization flow document
>  i3c: master: use i3c_master_register only for main master
>  i3c: master: add i3c_secondary_master_register
>  i3c: master: add mastership handover support
>  i3c: master: add defslvs processing
>  i3c: master: sysfs key for acquire bus
>  i3c: master: mastership handover, defslvs processing in cdns
>controller driver
>
> Documentation/driver-api/i3c/index.rst |1 +
> .../driver-api/i3c/master-initialization-flow.rst  |  187 
> drivers/i3c/master.c   |  497 ++--
> drivers/i3c/master/dw-i3c-master.c |4 +-
> drivers/i3c/master/i3c-master-cdns.c   |  329 -
> drivers/i3c/master/mipi-i3c-hci/core.c |4 +-
> include/linux/i3c/master.h |   23 +-
> 7 files changed, 970 insertions(+), 75 deletions(-)
> create mode 100644 Documentation/driver-api/i3c/master-initialization-flow.rst

Re: [PATCH 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices

[Andy Shevchenko]

On Thu, Mar 4, 2021 at 8:36 AM Henning Schild
 wrote:
>
> From: Henning Schild 
>
> This mainly implements detection of these devices and will allow
> secondary drivers to work on such machines.
>
> The identification is DMI-based with a vendor specific way to tell them
> apart in a reliable way.
>
> Drivers for LEDs and Watchdogs will follow to make use of that platform
> detection.

> Signed-off-by: Gerd Haeussler 
> Signed-off-by: Henning Schild 

The order is wrong taking into account the From line in the body. So,
it's not clear who is the author, who is a co-developer, and who is
the committer (one person may utilize few roles).
Check for the rest of the series as well (basically this is the rule
of thumb to recheck entire code for the comment you have got at any
single place of it).

...

> +config SIEMENS_SIMATIC_IPC
> +   tristate "Siemens Simatic IPC Class driver"
> +   depends on PCI
> +   help
> + This Simatic IPC class driver is the central of several drivers. It
> + is mainly used for system identification, after which drivers in 
> other
> + classes will take care of driving specifics of those machines.
> + i.e. leds and watchdogs

LEDs
watchdog. (missed period and singular form)

Module name?

>  endif # X86_PLATFORM_DEVICES

Not sure about the ordering of the section in Kconfig, but it is up to
maintainers.

...

> +# Siemens Simatic Industrial PCs
> +obj-$(CONFIG_SIEMENS_SIMATIC_IPC)  += simatic-ipc.o

Ditto.

...

> + * Siemens SIMATIC IPC driver for LEDs

It seems to be used in patch 4 which is not LED related. Also, why is
it here if it's for LEDs?

...

> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.

Replace with SPDX

...

> +#include 
> +#include 
> +#include 

Ordered?

> +#include 

...

> +static int register_platform_devices(u32 station_id)
> +{
> +   int i;
> +   u8 ledmode = SIMATIC_IPC_DEVICE_NONE;
> +   u8 wdtmode = SIMATIC_IPC_DEVICE_NONE;

Reversed xmas tree order?

> +   platform_data.devmode = SIMATIC_IPC_DEVICE_NONE;
> +
> +   for (i = 0; i < ARRAY_SIZE(device_modes); i++) {
> +   if (device_modes[i].station_id == station_id) {
> +   ledmode = device_modes[i].led_mode;
> +   wdtmode = device_modes[i].wdt_mode;
> +   break;
> +   }
> +   }
> +
> +   if (ledmode != SIMATIC_IPC_DEVICE_NONE) {
> +   platform_data.devmode = ledmode;

> +   ipc_led_platform_device = platform_device_register_data
> +   (NULL, KBUILD_MODNAME "_leds", PLATFORM_DEVID_NONE,
> +&platform_data, sizeof(struct simatic_ipc_platform));

Strange indentation (second line).

> +   if (IS_ERR(ipc_led_platform_device))
> +   return PTR_ERR(ipc_led_platform_device);

> +   pr_debug(KBUILD_MODNAME ": device=%s created\n",
> +ipc_led_platform_device->name);

Utilize pr_fmt() instead of adding prefixes like this.

> +   }

> +   if (wdtmode != SIMATIC_IPC_DEVICE_NONE) {
> +   platform_data.devmode = wdtmode;
> +   ipc_wdt_platform_device = platform_device_register_data
> +   (NULL, KBUILD_MODNAME "_wdt", PLATFORM_DEVID_NONE,
> +&platform_data, sizeof(struct simatic_ipc_platform));
> +   if (IS_ERR(ipc_wdt_platform_device))
> +   return PTR_ERR(ipc_wdt_platform_device);
> +
> +   pr_debug(KBUILD_MODNAME ": device=%s created\n",
> +ipc_wdt_platform_device->name);
> +   }

Same comments as above.

> +   if (ledmode == SIMATIC_IPC_DEVICE_NONE &&
> +   wdtmode == SIMATIC_IPC_DEVICE_NONE) {
> +   pr_warn(KBUILD_MODNAME
> +   ": unsupported IPC detected, station id=%08x\n",
> +   station_id);

Ugly indentation. With pr_fmt() in use will be much better.

> +   return -EINVAL;

> +   } else {

Redundant.

> +   return 0;
> +   }
> +}

...

> +/*
> + * Get membase address from PCI, used in leds and wdt modul. Here we read
> + * the bar0. The final address calculation is done in the appropriate modules

bar -> BAR
Missed period.

> + */

> +

Unneeded blank line.

> +u32 simatic_ipc_get_membase0(unsigned int p2sb)
> +{
> +   u32 bar0 = 0;

> +#ifdef CONFIG_PCI

It's ugly besides the fact that you have a dependency.

> +   struct pci_bus *bus;

Missed blank line.

> +   /*
> +* The GPIO memory is bar0 of the hidden P2SB device. Unhide the 
> device
> +* to have a quick look at it, before we hide it again.
> +* Also grab the pci rescan lock so that device does not get 
> discovered
> +* and remapped while 

Re: [RFC PATCH] autofs: find_autofs_mount overmounted parent support

[Alexander Mikhalitsyn]

On Thu, 04 Mar 2021 14:54:11 +0800
Ian Kent  wrote:

> On Wed, 2021-03-03 at 18:28 +0300, Alexander Mikhalitsyn wrote:
> > It was discovered that find_autofs_mount() function
> > in autofs not support cases when autofs mount
> > parent is overmounted. In this case this function will
> > always return -ENOENT.
> 
> Ok, I get this shouldn't happen.
> 
> > 
> > Real-life reproducer is fairly simple.
> > Consider the following mounts on root mntns:
> > --
> > 35 24 0:36 / /proc/sys/fs/binfmt_misc ... shared:16 - autofs systemd-
> > 1 ...
> > 654 35 0:57 / /proc/sys/fs/binfmt_misc ... shared:322 - binfmt_misc
> > ...
> > --
> > and some process which calls ioctl(AUTOFS_DEV_IOCTL_OPENMOUNT)
> > $ unshare -m -p --fork --mount-proc ./process-bin
> > 
> > Due to "mount-proc" /proc will be overmounted and
> > ioctl() will fail with -ENOENT
> 
> I think I need a better explanation ...

Thank you for the quick reply, Ian.
I'm sorry If my patch description was not sufficiently clear and detailed.

That problem connected with CRIU (Checkpoint-Restore in Userspace) project.
In CRIU we have support of autofs mounts C/R. To acheive that we need to use
ioctl's from /dev/autofs to get data about mounts, restore mount as catatonic
(if needed), change pipe fd and so on. But the problem is that during CRIU
dump we may meet situation when VFS subtree where autofs mount present was
overmounted as whole.

Simpliest example is /proc/sys/fs/binfmt_misc. This mount present on most
GNU/Linux distributions by default. For instance on my Fedora 33:

trigger automount of binfmt_misc
$ ls /proc/sys/fs/binfmt_misc

$ cat /proc/1/mountinfo | grep binfmt
35 24 0:36 / /proc/sys/fs/binfmt_misc rw,relatime shared:16 - autofs systemd-1 
rw,...,direct,pipe_ino=223
632 35 0:56 / /proc/sys/fs/binfmt_misc rw,...,relatime shared:315 - binfmt_misc 
binfmt_misc rw

$ sudo unshare -m -p --fork --mount-proc sh
# cat /proc/self/mountinfo | grep "/proc"
828 809 0:23 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
829 828 0:36 / /proc/sys/fs/binfmt_misc rw,relatime - autofs systemd-1 
rw,...,direct,pipe_ino=223
943 829 0:56 / /proc/sys/fs/binfmt_misc rw,...,relatime - binfmt_misc 
binfmt_misc rw
949 828 0:57 / /proc rw...,relatime - proc proc rw

As we can see now autofs mount /proc/sys/fs/binfmt_misc is inaccessible.
If we do something like:

struct autofs_dev_ioctl *param;
param = malloc(...);
devfd = open("/dev/autofs", O_RDONLY);
init_autofs_dev_ioctl(param);
param->size = size;
strcpy(param->path, "/proc/sys/fs/binfmt_misc");
param->openmount.devid = 36;
err = ioctl(devfd, AUTOFS_DEV_IOCTL_OPENMOUNT, param)

now we get err = -ENOENT.

> 
> What's being said here?
> 
> For a start your talking about direct mounts, I'm pretty sure this
> use case can't occur with indirect mounts in the sense that the
> indirect mount base should/must never be over mounted and IIRC that
> base can't be /proc (but maybe that's just mounts inside proc ...),
> can't remember now but from a common sense POV an indirect mount
> won't/can't be on /proc.
> 
> And why is this ioctl be called?

We call this ioctl during criu dump stage to open fd from autofs
mount dentry. This fd is used later to call ioctl(AUTOFS_IOC_CATATONIC)
(we do that on criu dump if we see that control process of autofs mount
is dead or pipe is dead).

> 
> If the mount is over mounted should that prevent expiration of the
> over mounted /proc anyway, so maybe the return is correct ... or
> not ...

I agree that case with overmounted subtree with autofs mount is weird case.
But it may be easily created by user and we in CRIU try to handle that.

> 
> I get that the mount namespaces should be independent and intuitively
> this is a bug but what is the actual use and expected result.
> 
> But anyway, aren't you saying that the VFS path walk isn't handling
> mount namespaces properly or are you saying that a process outside
> this new mount namespace becomes broken because of it?

No-no, it's only about opening autofs mount by device id + path.

> 
> Either way the solution looks more complicated than I'd expect so
> some explanation along these lines would be good.
> 
> Ian

Regards,
Alex

> > 
> > Cc: Matthew Wilcox 
> > Cc: Al Viro 
> > Cc: Pavel Tikhomirov 
> > Cc: Kirill Tkhai 
> > Cc: aut...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Alexander Mikhalitsyn <
> > alexander.mikhalit...@virtuozzo.com>
> > ---
> >  fs/autofs/dev-ioctl.c | 127 +---
> > --
> >  fs/namespace.c|  44 +++
> >  include/linux/mount.h |   5 ++
> >  3 files changed, 162 insertions(+), 14 deletions(-)
> > 
> > diff --git a/fs/autofs/dev-ioctl.c b/fs/autofs/dev-ioctl.c
> > index 5bf781ea6d67..55edd3eba8ce 100644
> > --- a/fs/autofs/dev-ioctl.c
> > +++ b/fs/autofs/dev-ioctl.c
> > @@ -10,6 +10,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "autofs_i.h"
> >  
> > @@ -179,32 +180,130 @@ static int autofs_dev_ioctl

drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c:15:9: warning: 'RST' macro redefined

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f69d02e37a85645aa90d18cacfff36dba370f797
commit: 030a7b5c168d996e590cdd09fffd8ebaa8a5d571 media: platform: Rename jpeg 
dec file name
date:   6 months ago
config: mips-randconfig-r006-20210304 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
eec7f8f7b1226be422a76542cb403d02538f453a)
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 mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=030a7b5c168d996e590cdd09fffd8ebaa8a5d571
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 030a7b5c168d996e590cdd09fffd8ebaa8a5d571
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips 

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

All warnings (new ones prefixed by >>):

>> drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c:15:9: warning: 'RST' 
>> macro redefined [-Wmacro-redefined]
   #define RST 0xd0
   ^
   arch/mips/include/asm/mach-rc32434/rb.h:15:9: note: previous definition is 
here
   #define RST (1 << 15)
   ^
   1 warning generated.


vim +/RST +15 drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c

b2f0d2724ba477 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c Rick Chang 
2016-12-14  12  
b2f0d2724ba477 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c Rick Chang 
2016-12-14  13  #define TEM  0x01
b2f0d2724ba477 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c Rick Chang 
2016-12-14  14  #define SOF0 0xc0
b2f0d2724ba477 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c Rick Chang 
2016-12-14 @15  #define RST  0xd0
b2f0d2724ba477 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c Rick Chang 
2016-12-14  16  #define SOI  0xd8
b2f0d2724ba477 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c Rick Chang 
2016-12-14  17  #define EOI  0xd9
b2f0d2724ba477 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c Rick Chang 
2016-12-14  18  

:: The code at line 15 was first introduced by commit
:: b2f0d2724ba477d326e9d654d4db1c93e98f8b93 [media] vcodec: mediatek: Add 
Mediatek JPEG Decoder Driver

:: TO: Rick Chang 
:: CC: Mauro Carvalho Chehab 

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


.config.gz
Description: application/gzip

Re: [PATCH] netdevsim: init u64 stats for 32bit hardware

[Dmitry Vyukov]

On Wed, Mar 3, 2021 at 12:10 AM Jakub Kicinski  wrote:
>
> On Tue, 2 Mar 2021 12:55:47 +0100 Dmitry Vyukov wrote:
> > On Tue, Mar 2, 2021 at 10:06 AM Hillf Danton  wrote:
> > > On Mar 2, 2021 at 16:40 Dmitry Vyukov wrote:
> > > >I hoped this would get at least into 5.12. syzbot can't start testing
> > > >arm32 because of this.
>
> FWIW the submission never got into patchwork or lore so we had
> no public source to apply from.
>
> > > Or what is more feasible is you send a fix to Jakub today.
> >
> > So far I can't figure out how to make git work with my Gmail account
> > with 1.5-factor auth enabled, neither password nor asp work...
>
> LMK if you get overly frustrated, I can get the patch from my inbox and
> resend it for you :)

This would be great, thanks Jakub.

Re: [PATCH v3] powerpc/uprobes: Validation for prefixed instruction

[Ravi Bangoria]

On 3/4/21 1:02 PM, Christophe Leroy wrote:



Le 04/03/2021 à 06:05, Ravi Bangoria a écrit :

As per ISA 3.1, prefixed instruction should not cross 64-byte
boundary. So don't allow Uprobe on such prefixed instruction.

There are two ways probed instruction is changed in mapped pages.
First, when Uprobe is activated, it searches for all the relevant
pages and replace instruction in them. In this case, if that probe
is on the 64-byte unaligned prefixed instruction, error out
directly. Second, when Uprobe is already active and user maps a
relevant page via mmap(), instruction is replaced via mmap() code
path. But because Uprobe is invalid, entire mmap() operation can
not be stopped. In this case just print an error and continue.

Signed-off-by: Ravi Bangoria 
---
v2: 
https://lore.kernel.org/r/20210204104703.273429-1-ravi.bango...@linux.ibm.com
v2->v3:
   - Drop restriction for Uprobe on suffix of prefixed instruction.
 It needs lot of code change including generic code but what
 we get in return is not worth it.

  arch/powerpc/kernel/uprobes.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index e8a63713e655..c400971ebe70 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -41,6 +41,14 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
  if (addr & 0x03)
  return -EINVAL;
+    if (!IS_ENABLED(CONFIG_PPC64) || !cpu_has_feature(CPU_FTR_ARCH_31))


cpu_has_feature(CPU_FTR_ARCH_31) should return 'false' when CONFIG_PPC64 is not 
enabled, no need to double check.


Ok.

I'm going to drop CONFIG_PPC64 check because it's not really
required as I replied to Naveen. So, I'll keep CPU_FTR_ARCH_31
check as is.




+    return 0;
+
+    if (ppc_inst_prefixed(auprobe->insn) && (addr & 0x3F) == 0x3C) {


Maybe 3C instead of 4F ? : (addr & 0x3C) == 0x3C


Didn't follow. It's not (addr & 0x3C), it's (addr & 0x3F).



What about

(addr & (SZ_64 - 4)) == SZ_64 - 4 to make it more explicit ?


Yes this is bit better. Though, it should be:

(addr & (SZ_64 - 1)) == SZ_64 - 4

Ravi

net: mscc: ocelot: issue with uninitialized pointer read in ocelot_flower_parse_key

[Colin Ian King]

Hi,

Static analysis with Coverity had detected an uninitialized pointer read
in function ocelot_flower_parse_key in
drivers/net/ethernet/mscc/ocelot_flower.c introduced by commit:

commit 75944fda1dfe836fdd406bef6cb3cc8a80f7af83
Author: Xiaoliang Yang 
Date:   Fri Oct 2 15:02:23 2020 +0300

net: mscc: ocelot: offload ingress skbedit and vlan actions to VCAP IS1

The analysis is as follows:

531

   10. Condition flow_rule_match_key(rule,
FLOW_DISSECTOR_KEY_IPV4_ADDRS), taking true branch.
   11. Condition proto == 2048, taking true branch.

532if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_IPV4_ADDRS) &&
533proto == ETH_P_IP) {

   12. var_decl: Declaring variable match without initializer.

534struct flow_match_ipv4_addrs match;
535u8 *tmp;
536

   13. Condition filter->block_id == VCAP_ES0, taking false branch.

537if (filter->block_id == VCAP_ES0) {
538NL_SET_ERR_MSG_MOD(extack,
539   "VCAP ES0 cannot match on
IP address");
540return -EOPNOTSUPP;
541}
542

   14. Condition filter->block_id == VCAP_IS1, taking true branch.
   Uninitialized pointer read (UNINIT)
   15. uninit_use: Using uninitialized value match.mask.

543if (filter->block_id == VCAP_IS1 && *(u32
*)&match.mask->dst) {
544NL_SET_ERR_MSG_MOD(extack,
545   "Key type S1_NORMAL cannot
match on destination IP");
546return -EOPNOTSUPP;
547}

match is declared in line 534 and is not initialized and the
uninitialized match.mask is being dereferenced on line 543. Not sure
what intent was on this and how to fix, hence I'm reporting this issue.

Colin

Re: [RFC PATCH 2/5] char: rpmb: provide a user space interface

[Alex Bennée]

"Winkler, Tomas"  writes:

>> The user space API is achieved via a number of synchronous IOCTLs.
>> 
>>   * RPMB_IOC_VER_CMD - simple versioning API
>>   * RPMB_IOC_CAP_CMD - query of underlying capabilities
>>   * RPMB_IOC_PKEY_CMD - one time programming of access key
>>   * RPMB_IOC_COUNTER_CMD - query the write counter
>>   * RPMB_IOC_WBLOCKS_CMD - write blocks to device
>>   * RPMB_IOC_RBLOCKS_CMD - read blocks from device
>> 
>> The keys used for programming and writing blocks to the device are
>> key_serial_t handles as provided by the keyctl() interface.
>> 
>> [AJB: here there are two key differences between this and the original
>> proposal. The first is the dropping of the sequence of preformated frames in
>> favour of explicit actions. The second is the introduction of key_serial_t 
>> and
>> the keyring API for referencing the key to use]
>
> Putting it gently I'm not sure this is good idea, from the security point of 
> view.
> The key has to be possession of the one that signs the frames as they are, it 
> doesn't mean it is linux kernel keyring, it can be other party on different 
> system.
> With this approach you will make the other usecases not applicable. It
> is less then trivial to move key securely from one system to another.

OK I can understand the desire for such a use-case but it does constrain
the interface on the kernel with access to the hardware to purely
providing a pipe to the raw hardware while also having to expose the
details of the HW to userspace. Also doesn't this break down after a
PROGRAM_KEY event as the key will have had to traverse into the
"untrusted" kernel?

I wonder if virtio-rpmb may be of help here? You could wrap up up the
front-end in the security domain that has the keys although I don't know
how easy it would be for a backend to work with real hardware?

> We all wished it can be abstracted more but the frames has to come already 
> signed, and the key material is inside the frame. 
> Thanks
> Tomas
>
>
>> 
>> Signed-off-by: Alex Bennée 
>> Cc: Ulf Hansson 
>> Cc: Linus  Walleij 
>> Cc: Arnd Bergmann 
>> Cc: Ilias Apalodimas 
>> Cc: Tomas Winkler 
>> Cc: Alexander Usyskin 
>> Cc: Avri Altman 
>> ---
>>  .../userspace-api/ioctl/ioctl-number.rst  |   1 +
>>  MAINTAINERS   |   1 +
>>  drivers/char/rpmb/Kconfig |   7 +
>>  drivers/char/rpmb/Makefile|   1 +
>>  drivers/char/rpmb/cdev.c  | 246 ++
>>  drivers/char/rpmb/core.c  |  10 +-
>>  drivers/char/rpmb/rpmb-cdev.h |  17 ++
>>  include/linux/rpmb.h  |  10 +
>>  include/uapi/linux/rpmb.h |  68 +
>>  9 files changed, 357 insertions(+), 4 deletions(-)  create mode 100644
>> drivers/char/rpmb/cdev.c  create mode 100644 drivers/char/rpmb/rpmb-
>> cdev.h  create mode 100644 include/uapi/linux/rpmb.h
>> 
>> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst
>> b/Documentation/userspace-api/ioctl/ioctl-number.rst
>> index a4c75a28c839..0ff2d4d81bb0 100644
>> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
>> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
>> @@ -344,6 +344,7 @@ Code  Seq#Include File
>> Comments
>>  0xB5  00-0F  uapi/linux/rpmsg.h  
>> > remotep...@vger.kernel.org>
>>  0xB6  alllinux/fpga-dfl.h
>>  0xB7  alluapi/linux/remoteproc_cdev.h
>> > remotep...@vger.kernel.org>
>> +0xB8  80-8F  uapi/linux/rpmb.h   
>> > m...@vger.kernel.org>
>>  0xC0  00-0F  linux/usb/iowarrior.h
>>  0xCA  00-0F  uapi/misc/cxl.h
>>  0xCA  10-2F  uapi/misc/ocxl.h
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 076f3983526c..c60b41b6e6bd 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -15374,6 +15374,7 @@ M:   ?
>>  L:  linux-kernel@vger.kernel.org
>>  S:  Supported
>>  F:  drivers/char/rpmb/*
>> +F:  include/uapi/linux/rpmb.h
>>  F:  include/linux/rpmb.h
>> 
>>  RTL2830 MEDIA DRIVER
>> diff --git a/drivers/char/rpmb/Kconfig b/drivers/char/rpmb/Kconfig index
>> 431c2823cf70..9068664a399a 100644
>> --- a/drivers/char/rpmb/Kconfig
>> +++ b/drivers/char/rpmb/Kconfig
>> @@ -9,3 +9,10 @@ config RPMB
>>access RPMB partition.
>> 
>>If unsure, select N.
>> +
>> +config RPMB_INTF_DEV
>> +bool "RPMB character device interface /dev/rpmbN"
>> +depends on RPMB && KEYS
>> +help
>> +  Say yes here if you want to access RPMB from user space
>> +  via character device interface /dev/rpmb%d
>> diff --git a/drivers/char/rpmb/Makefile b/drivers/char/rpmb/Makefile index
>> 24d4752a9a53..f54b3f30514b 100644
>> --- a/drivers/char/rpmb/Makefile
>> +++ b/drivers/char/rpmb/Makefile
>> @@ -3,5 +3,6 @@
>> 
>>  obj-$(CONFIG_RPMB) += rpmb.o
>>  rpmb-objs += core.o
>> +rpmb-$(CONFIG_RPMB_INTF_DEV) += cdev.o
>> 
>>  ccflags-y += -D__

Re: [PATCH 0/4] add device drivers for Siemens Industrial PCs

[Andy Shevchenko]

On Thu, Mar 4, 2021 at 12:19 PM Andy Shevchenko
 wrote:
> On Thu, Mar 4, 2021 at 9:29 AM Henning Schild
>  wrote:

> I have given a few comments here and there, so please check the entire
> series and address them in _all_ similar locations. As I have noticed,
> I have different approach about P2SB code, I have to give the series a
> dust and see if you can utilize it.
>
> I would like to be Cc'ed on the next version.

One more thing, is it Apollo Lake based?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 0/4] add device drivers for Siemens Industrial PCs

[Andy Shevchenko]

On Thu, Mar 4, 2021 at 9:29 AM Henning Schild
 wrote:

> This series adds support for watchdogs and leds of several x86 devices
> from Siemens.
>
> It is structured with a platform driver that mainly does identification
> of the machines. It might trigger loading of the actual device drivers
> by attaching devices to the platform bus.
>
> The identification is vendor specific, parsing a special binary DMI
> entry. The implementation of that platform identification is applied on
> pmc_atom clock quirks in the final patch.
>
> It is all structured in a way that we can easily add more devices and
> more platform drivers later. Internally we have some more code for
> hardware monitoring, more leds, watchdogs etc. This will follow some
> day.
>
> But the idea here is to share early, and hopefully not fail early.

I have given a few comments here and there, so please check the entire
series and address them in _all_ similar locations. As I have noticed,
I have different approach about P2SB code, I have to give the series a
dust and see if you can utilize it.

I would like to be Cc'ed on the next version.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/2] mm: Make alloc_contig_range handle free hugetlb pages

[Oscar Salvador]

On Mon, Mar 01, 2021 at 03:09:06PM +0100, David Hildenbrand wrote:
> On 22.02.21 14:51, Oscar Salvador wrote:
> > @@ -905,6 +905,18 @@ isolate_migratepages_block(struct compact_control *cc, 
> > unsigned long low_pfn,
> > valid_page = page;
> > }
> > +   if (PageHuge(page) && cc->alloc_contig) {
> > +   if (!isolate_or_dissolve_huge_page(page))
> > +   goto isolate_fail;

Bleh, sorry for the lateness David, I was farly busy.

> So, the callchain is:
> 
> alloc_contig_range()->__alloc_contig_migrate_range()->isolate_migratepages_range()->isolate_migratepages_block()
> 
> The case I am thinking about is if we run out of memory and would return
> -ENOMEM from alloc_and_dissolve_huge_page(). We silently drop the real error
> (e.g., -ENOMEM vs. -EBUSY vs. e.g., -EAGAIN) we had in
> isolate_or_dissolve_huge_page().

Yes, that is true.

> I think we should not swallo such return values in
> isolate_or_dissolve_huge_page() and instead properly report esp. -ENOMEM
> properly up this callchain now. Otherwise we'll end up retrying / reporting
> -EBUSY, which is misleading.

I am not sure I follow you here.
So, atm, alloc_and_dissolve_huge_page can either generate -ENOMEM or
-EBUSY wrt. error codes.
-ENOMEM when we cannot allocate a page, and -EBUSY when we raced with
someone.
You mean to only report ENOMEM down the chain?

> From isolate_migratepages_range()/isolate_migratepages_block() we'll keep
> reporting "pfn > 0".
> 
> a) In isolate_migratepages_range() we'll keep iterating over pageblocks
> although we should just fail with -ENOMEM right away.
> 
> b) In __alloc_contig_migrate_range() we'll keep retrying up to 5 times
> although we should just fail with -ENOMEM. We end up returning "-EBUSY"
> after retrying.
> 
> c) In alloc_contig_range() we'll continue trying to isolate although we
> should just return -ENOMEM.

Yes, "fatal" errors get masked, and hence we treat everything as "things
are busy, let us try again", and this is rather unforunate.

> I think we have should start returning proper errors from
> isolate_migratepages_range()/isolate_migratepages_block() on critical issues
> (-EINTR, -ENOMEM) instead of going via "!pfn vs. pfn" and retrying on "pfn".
> 
> So we should then fail with -ENOMEM during isolate_migratepages_range()
> cleanly, just as we would do when we get -ENOMEM during migrate_pages().

I guess we could rework the interface and make isolate_migratepages_range and
isolate_migratepages_block to report the right thing.
I yet have to check that this does not mess up a lot with the compaction
interface.

But overall I agree with your point here, and I am willing to to tackle
this.

The question is whether we want to do this as part of this series, or
after this series gets picked up.
IMHO, we could do it after, as a follow-up, unless you feel strong about
it.

What do you think?


-- 
Oscar Salvador
SUSE L3

Re:reply

[Ms. Reem]

Hello,

My name is Ms. Reem Ebrahim Al-Hashimi, I am the "Minister of state
and Petroleum" also "Minister of State for International Cooperation"
in UAE. I write to you on behalf of my other "three (3) colleagues"
who has approved me to solicit for your "partnership in claiming of
{us$47=Million}" from a Financial Home in Cambodia on their behalf and
for our "Mutual Benefits".

The Fund {us$47=Million} is our share from the (over-invoiced) Oil/Gas
deal with Cambodian/Vietnam Government within 2013/2014, however, we
don't want our government to know about the fund. If this proposal
interests you, let me know, by sending me an email and I will send to
you detailed information on how this business would be successfully
transacted. Be informed that nobody knows about the secret of this
fund except us, and we know how to carry out the entire transaction.
So I am compelled to ask, that you will stand on our behalf and
receive this fund into any account that is solely controlled by you.

We will compensate you with 15% of the total amount involved as
gratification for being our partner in this transaction. Reply to:
ms.r...@yandex.com

Regards,
Ms. Reem.

[PATCH v2 01/12] configfs: increase the item name length

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

20 characters limit for item name is relatively small. Let's increase it
to 32 to fit '04-committable-children' - a name we'll use in the sample
code for committable items.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Linus Walleij 
---
 include/linux/configfs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 2e8c69b43c64..4f76dcc08134 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -27,7 +27,7 @@
 #include/* struct kref */
 #include   /* struct mutex */
 
-#define CONFIGFS_ITEM_NAME_LEN 20
+#define CONFIGFS_ITEM_NAME_LEN 32
 
 struct module;
 
-- 
2.29.1

[PATCH v2 00/12] gpio: implement the configfs testing module

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

This series adds a new GPIO testing module based on configfs committable items
and sysfs. The goal is to provide a testing driver that will be configurable
at runtime (won't need module reload) and easily extensible. The control over
the attributes is also much more fine-grained than in gpio-mockup.

This series also contains a respin of the patches I sent separately to the
configfs maintainers - these patches implement the concept of committable
items that was well defined for a long time but never actually completed.

Apart from the new driver itself, its selftests and the configfs patches, this
series contains some changes to the bitmap API - most importantly: it adds
devres managed variants of bitmap_alloc() and bitmap_zalloc().

v1 -> v2:
- add selftests for gpio-sim
- add helper programs for selftests
- update the configfs rename callback to work with the new API introduced in
  v5.11
- fix a missing quote in the documentation
- use !! whenever using bits operation that are required to return 0 or 1
- use provided bitmap API instead of reimplementing copy or fill operations
- fix a deadlock in gpio_sim_direction_output()
- add new read-only configfs attributes for mapping of configfs items to GPIO
  device names
- and address other minor issues pointed out in reviews of v1

Bartosz Golaszewski (12):
  configfs: increase the item name length
  configfs: use (1UL << bit) for internal flags
  configfs: implement committable items
  samples: configfs: add a committable group
  lib: bitmap: remove the 'extern' keyword from function declarations
  lib: bitmap: order includes alphabetically
  lib: bitmap: provide devm_bitmap_alloc() and devm_bitmap_zalloc()
  drivers: export device_is_bound()
  gpio: sim: new testing module
  selftests: gpio: provide a helper for reading chip info
  selftests: gpio: add a helper for reading GPIO line names
  selftests: gpio: add test cases for gpio-sim

 Documentation/admin-guide/gpio/gpio-sim.rst   |  72 ++
 Documentation/filesystems/configfs.rst|   6 +-
 drivers/base/dd.c |   1 +
 drivers/gpio/Kconfig  |   8 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-sim.c   | 878 ++
 fs/configfs/configfs_internal.h   |  22 +-
 fs/configfs/dir.c | 245 -
 include/linux/bitmap.h| 129 +--
 include/linux/configfs.h  |   3 +-
 lib/bitmap.c  |  42 +-
 samples/configfs/configfs_sample.c| 153 +++
 tools/testing/selftests/gpio/.gitignore   |   2 +
 tools/testing/selftests/gpio/Makefile |   4 +-
 tools/testing/selftests/gpio/config   |   1 +
 tools/testing/selftests/gpio/gpio-chip-info.c |  57 ++
 tools/testing/selftests/gpio/gpio-line-name.c |  55 ++
 tools/testing/selftests/gpio/gpio-sim.sh  | 229 +
 18 files changed, 1822 insertions(+), 86 deletions(-)
 create mode 100644 Documentation/admin-guide/gpio/gpio-sim.rst
 create mode 100644 drivers/gpio/gpio-sim.c
 create mode 100644 tools/testing/selftests/gpio/gpio-chip-info.c
 create mode 100644 tools/testing/selftests/gpio/gpio-line-name.c
 create mode 100755 tools/testing/selftests/gpio/gpio-sim.sh

-- 
2.29.1

[PATCH v2 02/12] configfs: use (1UL << bit) for internal flags

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

For better readability and maintenance: use the (1UL << bit) for flag
definitions.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Linus Walleij 
---
 fs/configfs/configfs_internal.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h
index 9a3aed249692..b495c9f043d4 100644
--- a/fs/configfs/configfs_internal.h
+++ b/fs/configfs/configfs_internal.h
@@ -46,16 +46,16 @@ struct configfs_dirent {
struct configfs_fragment *s_frag;
 };
 
-#define CONFIGFS_ROOT  0x0001
-#define CONFIGFS_DIR   0x0002
-#define CONFIGFS_ITEM_ATTR 0x0004
-#define CONFIGFS_ITEM_BIN_ATTR 0x0008
-#define CONFIGFS_ITEM_LINK 0x0020
-#define CONFIGFS_USET_DIR  0x0040
-#define CONFIGFS_USET_DEFAULT  0x0080
-#define CONFIGFS_USET_DROPPING 0x0100
-#define CONFIGFS_USET_IN_MKDIR 0x0200
-#define CONFIGFS_USET_CREATING 0x0400
+#define CONFIGFS_ROOT  (1UL << 0)
+#define CONFIGFS_DIR   (1UL << 1)
+#define CONFIGFS_ITEM_ATTR (1UL << 2)
+#define CONFIGFS_ITEM_BIN_ATTR (1UL << 3)
+#define CONFIGFS_ITEM_LINK (1UL << 5)
+#define CONFIGFS_USET_DIR  (1UL << 6)
+#define CONFIGFS_USET_DEFAULT  (1UL << 7)
+#define CONFIGFS_USET_DROPPING (1UL << 8)
+#define CONFIGFS_USET_IN_MKDIR (1UL << 9)
+#define CONFIGFS_USET_CREATING (1UL << 10)
 #define CONFIGFS_NOT_PINNED(CONFIGFS_ITEM_ATTR | CONFIGFS_ITEM_BIN_ATTR)
 
 extern struct mutex configfs_symlink_mutex;
-- 
2.29.1

Re: [PATCH] media: qcom: camss: Fix overflows in clock rate calculations

[Hans Verkuil]

On 10/02/2021 13:29, Vladimir Lypak wrote:
> Because of u32 type being used to store pixel clock rate, expression used
> to calculate pipeline clocks (pixel_clock * bpp) produces wrong value due
> to integer overflow. This patch changes data type used to store, pass and
> retrieve pixel_clock from u32 to u64 to make this mistake less likely to
> be repeated in the future.

This patch conflicts with Andrey's patch:

https://patchwork.linuxtv.org/project/linux-media/patch/20210217221134.2606-4-andrey.konova...@linaro.org/

I've picked up Andrey's patch in a pull request (not yet merged in our media 
master tree),
but you should rebase your patch on top of his if it is still needed.

Regards,

Hans

> 
> Signed-off-by: Vladimir Lypak 
> ---
>  drivers/media/platform/qcom/camss/camss-csid.c   | 2 +-
>  drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c | 4 ++--
>  drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c | 4 ++--
>  drivers/media/platform/qcom/camss/camss-csiphy.c | 4 ++--
>  drivers/media/platform/qcom/camss/camss-csiphy.h | 2 +-
>  drivers/media/platform/qcom/camss/camss-vfe.c| 4 ++--
>  drivers/media/platform/qcom/camss/camss.c| 2 +-
>  drivers/media/platform/qcom/camss/camss.h| 2 +-
>  8 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/camss/camss-csid.c 
> b/drivers/media/platform/qcom/camss/camss-csid.c
> index be3fe76f3dc30..6307b889baa69 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid.c
> @@ -462,7 +462,7 @@ static irqreturn_t csid_isr(int irq, void *dev)
>  static int csid_set_clock_rates(struct csid_device *csid)
>  {
>   struct device *dev = csid->camss->dev;
> - u32 pixel_clock;
> + u64 pixel_clock;
>   int i, j;
>   int ret;
>  
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c 
> b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
> index 12bce391d71fd..ec66d1557b8b1 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
> @@ -57,7 +57,7 @@ static void csiphy_reset(struct csiphy_device *csiphy)
>   * Return settle count value or 0 if the CSI2 pixel clock
>   * frequency is not available
>   */
> -static u8 csiphy_settle_cnt_calc(u32 pixel_clock, u8 bpp, u8 num_lanes,
> +static u8 csiphy_settle_cnt_calc(u64 pixel_clock, u8 bpp, u8 num_lanes,
>u32 timer_clk_rate)
>  {
>   u32 mipi_clock; /* Hz */
> @@ -83,7 +83,7 @@ static u8 csiphy_settle_cnt_calc(u32 pixel_clock, u8 bpp, 
> u8 num_lanes,
>  
>  static void csiphy_lanes_enable(struct csiphy_device *csiphy,
>   struct csiphy_config *cfg,
> - u32 pixel_clock, u8 bpp, u8 lane_mask)
> + u64 pixel_clock, u8 bpp, u8 lane_mask)
>  {
>   struct csiphy_lanes_cfg *c = &cfg->csi2->lane_cfg;
>   u8 settle_cnt;
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c 
> b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> index 97cb9de850315..cd6eb88a7c153 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> @@ -113,7 +113,7 @@ static irqreturn_t csiphy_isr(int irq, void *dev)
>   * Return settle count value or 0 if the CSI2 pixel clock
>   * frequency is not available
>   */
> -static u8 csiphy_settle_cnt_calc(u32 pixel_clock, u8 bpp, u8 num_lanes,
> +static u8 csiphy_settle_cnt_calc(u64 pixel_clock, u8 bpp, u8 num_lanes,
>u32 timer_clk_rate)
>  {
>   u32 mipi_clock; /* Hz */
> @@ -137,7 +137,7 @@ static u8 csiphy_settle_cnt_calc(u32 pixel_clock, u8 bpp, 
> u8 num_lanes,
>  
>  static void csiphy_lanes_enable(struct csiphy_device *csiphy,
>   struct csiphy_config *cfg,
> - u32 pixel_clock, u8 bpp, u8 lane_mask)
> + u64 pixel_clock, u8 bpp, u8 lane_mask)
>  {
>   struct csiphy_lanes_cfg *c = &cfg->csi2->lane_cfg;
>   u8 settle_cnt;
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c 
> b/drivers/media/platform/qcom/camss/camss-csiphy.c
> index 509c9a59c09cd..61628f55c4f63 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
> @@ -102,7 +102,7 @@ static u8 csiphy_get_bpp(const struct csiphy_format 
> *formats,
>  static int csiphy_set_clock_rates(struct csiphy_device *csiphy)
>  {
>   struct device *dev = csiphy->camss->dev;
> - u32 pixel_clock;
> + u64 pixel_clock;
>   int i, j;
>   int ret;
>  
> @@ -238,7 +238,7 @@ static u8 csiphy_get_lane_mask(struct csiphy_lanes_cfg 
> *lane_cfg)
>  static int csiphy_stream_on(struct csiphy_device *csiphy)
>  {
>   struct csip

[PATCH v2 04/12] samples: configfs: add a committable group

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Add an example of using committable items to configfs samples. Each
config item has two attributes: read-write 'storeme' which works
similarly to other examples in this file and a read-only 'committed'
attribute which changes its value between false and true depending on
whether it's committed or not at the moment.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Linus Walleij 
---
 samples/configfs/configfs_sample.c | 153 +
 1 file changed, 153 insertions(+)

diff --git a/samples/configfs/configfs_sample.c 
b/samples/configfs/configfs_sample.c
index f9008be7a8a1..9bef74e4369d 100644
--- a/samples/configfs/configfs_sample.c
+++ b/samples/configfs/configfs_sample.c
@@ -315,6 +315,158 @@ static struct configfs_subsystem group_children_subsys = {
 
 /* - */
 
+/*
+ * 04-committable-children
+ *
+ * This is an example of a committable group.  It's similar to the simple
+ * children example but each config_item has an additional 'committed'
+ * attribute which is read-only and is only modified when the config_item
+ * is moved from the 'pending' to the 'live' directory.
+ */
+
+struct committable_child {
+   struct config_item item;
+   int storeme;
+   bool committed;
+};
+
+static inline struct committable_child *
+to_committable_child(struct config_item *item)
+{
+   return container_of(item, struct committable_child, item);
+}
+
+static ssize_t
+committable_child_storeme_show(struct config_item *item, char *page)
+{
+   return sprintf(page, "%d\n", to_committable_child(item)->storeme);
+}
+
+static ssize_t committable_child_storeme_store(struct config_item *item,
+  const char *page, size_t count)
+{
+   struct committable_child *child = to_committable_child(item);
+   int ret;
+
+   if (child->committed)
+   return -EPERM;
+
+   ret = kstrtoint(page, 10, &child->storeme);
+   if (ret)
+   return ret;
+
+   return count;
+}
+
+CONFIGFS_ATTR(committable_child_, storeme);
+
+static ssize_t
+committable_child_committed_show(struct config_item *item, char *page)
+{
+   return sprintf(page, "%s\n",
+   to_committable_child(item)->committed ? "true" : "false");
+}
+
+CONFIGFS_ATTR_RO(committable_child_, committed);
+
+static struct configfs_attribute *committable_child_attrs[] = {
+   &committable_child_attr_storeme,
+   &committable_child_attr_committed,
+   NULL,
+};
+
+static void committable_child_release(struct config_item *item)
+{
+   kfree(to_committable_child(item));
+}
+
+static struct configfs_item_operations committable_child_item_ops = {
+   .release= committable_child_release,
+};
+
+static const struct config_item_type committable_child_type = {
+   .ct_item_ops= &committable_child_item_ops,
+   .ct_attrs   = committable_child_attrs,
+   .ct_owner   = THIS_MODULE,
+};
+
+struct committable_children {
+   struct config_group group;
+};
+
+static struct config_item *
+committable_children_make_item(struct config_group *group, const char *name)
+{
+   struct committable_child *child;
+
+   child = kzalloc(sizeof(*child), GFP_KERNEL);
+   if (!child)
+   return ERR_PTR(-ENOMEM);
+
+   config_item_init_type_name(&child->item, name, &committable_child_type);
+
+   return &child->item;
+}
+
+static ssize_t
+committable_children_description_show(struct config_item *item, char *page)
+{
+   return sprintf(page,
+"[04-committable-children]\n"
+"\n"
+"This subsystem allows creation of committable config_items.  The subsystem\n"
+"has two subdirectories: pending and live.  New config_items can only be\n"
+"created in pending/ and they have one writable and readable attribute as\n"
+"well as a single read-only attribute.  The latter is only changed once the\n"
+"item is 'committed'.  This is done by moving the config_item (using\n"
+"rename()) to the live/ directory.  In this example, the storeme attribute\n"
+"becomes 'read-only' once committed.\n");
+}
+
+CONFIGFS_ATTR_RO(committable_children_, description);
+
+static struct configfs_attribute *committable_children_attrs[] = {
+   &committable_children_attr_description,
+   NULL,
+};
+
+static int committable_children_commit_item(struct config_item *item)
+{
+   to_committable_child(item)->committed = true;
+
+   return 0;
+}
+
+static int committable_children_uncommit_item(struct config_item *item)
+{
+   to_committable_child(item)->committed = false;
+
+   return 0;
+}
+
+static struct configfs_group_operations committable_children_group_ops = {
+   .make_item  = committable_children_make_item,
+   .commit_item= committable_children_commit_item,
+   .uncommit_item  = committable_children_uncommit_item,
+};
+
+static const struct config_item_type committable_children_type = {
+  

[PATCH v2 09/12] gpio: sim: new testing module

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Implement a new, modern GPIO testing module controlled by configfs
attributes instead of module parameters. The goal of this driver is
to provide a replacement for gpio-mockup that will be easily extensible
with new features and doesn't require reloading the module to change
the setup.

Signed-off-by: Bartosz Golaszewski 
---
 Documentation/admin-guide/gpio/gpio-sim.rst |  72 ++
 drivers/gpio/Kconfig|   8 +
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-sim.c | 878 
 4 files changed, 959 insertions(+)
 create mode 100644 Documentation/admin-guide/gpio/gpio-sim.rst
 create mode 100644 drivers/gpio/gpio-sim.c

diff --git a/Documentation/admin-guide/gpio/gpio-sim.rst 
b/Documentation/admin-guide/gpio/gpio-sim.rst
new file mode 100644
index ..08eac487e35e
--- /dev/null
+++ b/Documentation/admin-guide/gpio/gpio-sim.rst
@@ -0,0 +1,72 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Configfs GPIO Simulator
+===
+
+The configfs GPIO Simulator (gpio-sim) provides a way to create simulated GPIO
+chips for testing purposes. The lines exposed by these chips can be accessed
+using the standard GPIO character device interface as well as manipulated
+using sysfs attributes.
+
+Creating simulated chips
+
+
+The gpio-sim module registers a configfs subsystem called 'gpio-sim'. It's a
+subsystem with committable items which means two subdirectories are created in
+the filesystem: pending and live. For more information on configfs and
+committable items, please refer to Documentation/filesystems/configfs.rst.
+
+In order to instantiate a new simulated chip, the user needs to mkdir() a new
+directory in pending/. Inside each new directory, there's a set of attributes
+that can be used to configure the new chip. Once the configuration is complete,
+the user needs to use rename() to move the chip to the live/ directory. This
+creates and registers the new device.
+
+In order to destroy a simulated chip, it has to be moved back to pending first
+and then removed using rmdir().
+
+Currently supported configuration attributes are:
+
+  num_lines - an unsigned integer value defining the number of GPIO lines to
+  export
+
+  label - a string defining the label for the GPIO chip
+
+  line_names - a list of GPIO line names in the form of quoted strings
+   separated by commas, e.g.: '"foo", "bar", "", "foobar"'. The
+   number of strings doesn't have to be equal to the value set in
+   the num_lines attribute. If it's lower than the number of lines,
+   the remaining lines are unnamed. If it's larger, the superfluous
+   lines are ignored. A name of the form: '""' means the line
+   should be unnamed.
+
+Additionally two read-only attributes named 'chip_name' and 'dev_name' are
+exposed in order to provide users with a mapping from configfs directories to
+the actual devices created in the kernel. The former returns the name of the
+GPIO device as assigned by gpiolib (i.e. "gpiochip0", "gpiochip1", etc.). The
+latter returns the parent device name as defined by the gpio-sim driver (i.e.
+"gpio-sim.0", "gpio-sim.1", etc.). This allows user-space to map the configfs
+items both to the correct character device file as well as the associated entry
+in sysfs.
+
+Simulated GPIO chips can also be defined in device-tree. The compatible string
+must be: "gpio-simulator". Supported properties are:
+
+  "gpio-sim,label" - chip label
+
+  "gpio-sim,nr-gpios" - number of lines
+
+Other standard GPIO properties (like "gpio-line-names" and gpio-hog) are also
+supported.
+
+Manipulating simulated lines
+
+
+Each simulated GPIO chip creates a sysfs attribute group under its device
+directory called 'line-ctrl'. Inside each group, there's a separate attribute
+for each GPIO line. The name of the attribute is of the form 'gpioX' where X
+is the line's offset in the chip.
+
+Reading from a line attribute returns the current value. Writing to it (0 or 1)
+changes the configuration of the simulated pull-up/pull-down resistor
+(1 - pull-up, 0 - pull-down).
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index e3607ec4c2e8..b6b6150d0d04 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1633,6 +1633,14 @@ config GPIO_MOCKUP
  tools/testing/selftests/gpio/gpio-mockup.sh. Reference the usage in
  it.
 
+config GPIO_SIM
+   tristate "GPIO Simulator Module"
+   select IRQ_SIM
+   select CONFIGFS_FS
+   help
+ This enables the GPIO simulator - a configfs-based GPIO testing
+ driver.
+
 endmenu
 
 endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index c58a90a3c3b1..d717aa85f8e1 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -130,6 +130,7 @@ obj-$(CONFIG_GPIO_SAMA5D2_PIOBU)

[PATCH v2 05/12] lib: bitmap: remove the 'extern' keyword from function declarations

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

The 'extern' keyword doesn't have any benefits in header files. Remove it.

Signed-off-by: Bartosz Golaszewski 
---
 include/linux/bitmap.h | 115 -
 1 file changed, 57 insertions(+), 58 deletions(-)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 70a932470b2d..6939a8983026 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -118,54 +118,53 @@
  * Allocation and deallocation of bitmap.
  * Provided in lib/bitmap.c to avoid circular dependency.
  */
-extern unsigned long *bitmap_alloc(unsigned int nbits, gfp_t flags);
-extern unsigned long *bitmap_zalloc(unsigned int nbits, gfp_t flags);
-extern void bitmap_free(const unsigned long *bitmap);
+unsigned long *bitmap_alloc(unsigned int nbits, gfp_t flags);
+unsigned long *bitmap_zalloc(unsigned int nbits, gfp_t flags);
+void bitmap_free(const unsigned long *bitmap);
 
 /*
  * lib/bitmap.c provides these functions:
  */
 
-extern int __bitmap_equal(const unsigned long *bitmap1,
- const unsigned long *bitmap2, unsigned int nbits);
-extern bool __pure __bitmap_or_equal(const unsigned long *src1,
-const unsigned long *src2,
-const unsigned long *src3,
-unsigned int nbits);
-extern void __bitmap_complement(unsigned long *dst, const unsigned long *src,
-   unsigned int nbits);
-extern void __bitmap_shift_right(unsigned long *dst, const unsigned long *src,
-   unsigned int shift, unsigned int nbits);
-extern void __bitmap_shift_left(unsigned long *dst, const unsigned long *src,
-   unsigned int shift, unsigned int nbits);
-extern void bitmap_cut(unsigned long *dst, const unsigned long *src,
-  unsigned int first, unsigned int cut,
-  unsigned int nbits);
-extern int __bitmap_and(unsigned long *dst, const unsigned long *bitmap1,
+int __bitmap_equal(const unsigned long *bitmap1,
+  const unsigned long *bitmap2, unsigned int nbits);
+bool __pure __bitmap_or_equal(const unsigned long *src1,
+ const unsigned long *src2,
+ const unsigned long *src3,
+ unsigned int nbits);
+void __bitmap_complement(unsigned long *dst, const unsigned long *src,
+unsigned int nbits);
+void __bitmap_shift_right(unsigned long *dst, const unsigned long *src,
+ unsigned int shift, unsigned int nbits);
+void __bitmap_shift_left(unsigned long *dst, const unsigned long *src,
+unsigned int shift, unsigned int nbits);
+void bitmap_cut(unsigned long *dst, const unsigned long *src,
+   unsigned int first, unsigned int cut, unsigned int nbits);
+int __bitmap_and(unsigned long *dst, const unsigned long *bitmap1,
+const unsigned long *bitmap2, unsigned int nbits);
+void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1,
+const unsigned long *bitmap2, unsigned int nbits);
+void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1,
+ const unsigned long *bitmap2, unsigned int nbits);
+int __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1,
+   const unsigned long *bitmap2, unsigned int nbits);
+void __bitmap_replace(unsigned long *dst,
+ const unsigned long *old, const unsigned long *new,
+ const unsigned long *mask, unsigned int nbits);
+int __bitmap_intersects(const unsigned long *bitmap1,
const unsigned long *bitmap2, unsigned int nbits);
-extern void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1,
-   const unsigned long *bitmap2, unsigned int nbits);
-extern void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1,
-   const unsigned long *bitmap2, unsigned int nbits);
-extern int __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1,
-   const unsigned long *bitmap2, unsigned int nbits);
-extern void __bitmap_replace(unsigned long *dst,
-   const unsigned long *old, const unsigned long *new,
-   const unsigned long *mask, unsigned int nbits);
-extern int __bitmap_intersects(const unsigned long *bitmap1,
-   const unsigned long *bitmap2, unsigned int nbits);
-extern int __bitmap_subset(const unsigned long *bitmap1,
-   const unsigned long *bitmap2, unsigned int nbits);
-extern int __bitmap_weight(const unsigned long *bitmap, unsigned int nbits);
-extern void __bitmap_set(unsigned long *map, unsigned int start, int len);
-extern void __bitmap_clear(unsigned long *map, unsigned int start, int len);
-
-extern unsigned long bitmap_find_next_zero_area_o

[PATCH v2 10/12] selftests: gpio: provide a helper for reading chip info

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Add a simple program that allows to retrieve chip properties from the
GPIO character device. This will be used in gpio-sim selftests.

Signed-off-by: Bartosz Golaszewski 
---
 tools/testing/selftests/gpio/.gitignore   |  1 +
 tools/testing/selftests/gpio/Makefile |  2 +-
 tools/testing/selftests/gpio/gpio-chip-info.c | 57 +++
 3 files changed, 59 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/gpio/gpio-chip-info.c

diff --git a/tools/testing/selftests/gpio/.gitignore 
b/tools/testing/selftests/gpio/.gitignore
index a4969f7ee020..4ea4f58dab1a 100644
--- a/tools/testing/selftests/gpio/.gitignore
+++ b/tools/testing/selftests/gpio/.gitignore
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0-only
 gpio-mockup-cdev
+gpio-chip-info
diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 39f2bbe8dd3d..84b48547f94c 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -2,6 +2,6 @@
 
 TEST_PROGS := gpio-mockup.sh
 TEST_FILES := gpio-mockup-sysfs.sh
-TEST_GEN_PROGS_EXTENDED := gpio-mockup-cdev
+TEST_GEN_PROGS_EXTENDED := gpio-mockup-cdev gpio-chip-info
 
 include ../lib.mk
diff --git a/tools/testing/selftests/gpio/gpio-chip-info.c 
b/tools/testing/selftests/gpio/gpio-chip-info.c
new file mode 100644
index ..4d26fa7c254a
--- /dev/null
+++ b/tools/testing/selftests/gpio/gpio-chip-info.c
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * GPIO character device helper for reading chip information.
+ *
+ * Copyright (C) 2021 Bartosz Golaszewski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void print_usage(void)
+{
+   printf("usage:\n");
+   printf("  gpio-chip-info  [name|label|num-lines]\n");
+}
+
+int main(int argc, char **argv)
+{
+   struct gpiochip_info info;
+   int fd, ret;
+
+   if (argc !=3) {
+   print_usage();
+   return EXIT_FAILURE;
+   }
+
+   fd = open(argv[1], O_RDWR);
+   if (fd < 0) {
+   perror("unable to open the GPIO chip");
+   return EXIT_FAILURE;
+   }
+
+   memset(&info, 0, sizeof(info));
+   ret = ioctl(fd, GPIO_GET_CHIPINFO_IOCTL, &info);
+   if (ret) {
+   perror("chip info ioctl failed");
+   return EXIT_FAILURE;
+   }
+
+   if (strcmp(argv[2], "name") == 0) {
+   printf("%s\n", info.name);
+   } else if (strcmp(argv[2], "label") == 0) {
+   printf("%s\n", info.label);
+   } else if (strcmp(argv[2], "num-lines") == 0) {
+   printf("%u\n", info.lines);
+   } else {
+   fprintf(stderr, "unknown command: %s\n", argv[2]);
+   return EXIT_FAILURE;
+   }
+
+   return EXIT_SUCCESS;
+}
-- 
2.29.1

[PATCH v2 11/12] selftests: gpio: add a helper for reading GPIO line names

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Add a simple program that allows to read GPIO line names from the
character device. This will be used in gpio-sim selftests.

Signed-off-by: Bartosz Golaszewski 
---
 tools/testing/selftests/gpio/.gitignore   |  1 +
 tools/testing/selftests/gpio/Makefile |  2 +-
 tools/testing/selftests/gpio/gpio-line-name.c | 55 +++
 3 files changed, 57 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/gpio/gpio-line-name.c

diff --git a/tools/testing/selftests/gpio/.gitignore 
b/tools/testing/selftests/gpio/.gitignore
index 4ea4f58dab1a..ededb077a3a6 100644
--- a/tools/testing/selftests/gpio/.gitignore
+++ b/tools/testing/selftests/gpio/.gitignore
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 gpio-mockup-cdev
 gpio-chip-info
+gpio-line-name
diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 84b48547f94c..d7d8f1985d99 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -2,6 +2,6 @@
 
 TEST_PROGS := gpio-mockup.sh
 TEST_FILES := gpio-mockup-sysfs.sh
-TEST_GEN_PROGS_EXTENDED := gpio-mockup-cdev gpio-chip-info
+TEST_GEN_PROGS_EXTENDED := gpio-mockup-cdev gpio-chip-info gpio-line-name
 
 include ../lib.mk
diff --git a/tools/testing/selftests/gpio/gpio-line-name.c 
b/tools/testing/selftests/gpio/gpio-line-name.c
new file mode 100644
index ..a52e75bc37ba
--- /dev/null
+++ b/tools/testing/selftests/gpio/gpio-line-name.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * GPIO character device helper for reading line names.
+ *
+ * Copyright (C) 2021 Bartosz Golaszewski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void print_usage(void)
+{
+   printf("usage:\n");
+   printf("  gpio-line-name  \n");
+}
+
+int main(int argc, char **argv)
+{
+   struct gpio_v2_line_info info;
+   int fd, ret;
+   char *endp;
+
+   if (argc != 3) {
+   print_usage();
+   return EXIT_FAILURE;
+   }
+
+   fd = open(argv[1], O_RDWR);
+   if (fd < 0) {
+   perror("unable to open the GPIO chip");
+   return EXIT_FAILURE;
+   }
+
+   memset(&info, 0, sizeof(info));
+   info.offset = strtoul(argv[2], &endp, 10);
+   if (*endp != '\0') {
+   print_usage();
+   return EXIT_FAILURE;
+   }
+
+   ret = ioctl(fd, GPIO_V2_GET_LINEINFO_IOCTL, &info);
+   if (ret) {
+   perror("line info ioctl failed");
+   return EXIT_FAILURE;
+   }
+
+   printf("%s\n", info.name);
+
+   return EXIT_SUCCESS;
+}
-- 
2.29.1

[PATCH v2 07/12] lib: bitmap: provide devm_bitmap_alloc() and devm_bitmap_zalloc()

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Provide managed variants of bitmap_alloc() and bitmap_zalloc().

Signed-off-by: Bartosz Golaszewski 
---
 include/linux/bitmap.h | 10 ++
 lib/bitmap.c   | 33 +
 2 files changed, 43 insertions(+)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 3282db97e06c..e41c622db1b8 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -9,6 +9,8 @@
 #include 
 #include 
 
+struct device;
+
 /*
  * bitmaps provide bit arrays that consume one or more unsigned
  * longs.  The bitmap interface and available operations are listed
@@ -122,6 +124,14 @@ unsigned long *bitmap_alloc(unsigned int nbits, gfp_t 
flags);
 unsigned long *bitmap_zalloc(unsigned int nbits, gfp_t flags);
 void bitmap_free(const unsigned long *bitmap);
 
+/*
+ * Managed variants of the above.
+ */
+unsigned long *devm_bitmap_alloc(struct device *dev,
+unsigned int nbits, gfp_t flags);
+unsigned long *devm_bitmap_zalloc(struct device *dev,
+ unsigned int nbits, gfp_t flags);
+
 /*
  * lib/bitmap.c provides these functions:
  */
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 78f70d9007ad..b4fd7fd084c6 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1263,6 +1264,38 @@ void bitmap_free(const unsigned long *bitmap)
 }
 EXPORT_SYMBOL(bitmap_free);
 
+static void devm_bitmap_free(void *data)
+{
+   unsigned long *bitmap = data;
+
+   bitmap_free(bitmap);
+}
+
+unsigned long *devm_bitmap_alloc(struct device *dev,
+unsigned int nbits, gfp_t flags)
+{
+   unsigned long *bitmap;
+   int ret;
+
+   bitmap = bitmap_alloc(nbits, flags);
+   if (!bitmap)
+   return NULL;
+
+   ret = devm_add_action_or_reset(dev, devm_bitmap_free, bitmap);
+   if (ret)
+   return NULL;
+
+   return bitmap;
+}
+EXPORT_SYMBOL(devm_bitmap_alloc);
+
+unsigned long *devm_bitmap_zalloc(struct device *dev,
+ unsigned int nbits, gfp_t flags)
+{
+   return devm_bitmap_alloc(dev, nbits, flags | __GFP_ZERO);
+}
+EXPORT_SYMBOL(devm_bitmap_zalloc);
+
 #if BITS_PER_LONG == 64
 /**
  * bitmap_from_arr32 - copy the contents of u32 array of bits to bitmap
-- 
2.29.1

[PATCH v2 03/12] configfs: implement committable items

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

This implements configfs committable items. We mostly follow the
documentation except that we extend config_group_ops with uncommit_item()
callback for reverting the changes made by commit_item().

Each committable group has two sub-directories: pending and live. New
items can only be created in pending/. Attributes can only be modified
while the item is in pending/. Once it's ready to be committed, it must
be moved over to live/ using the rename() system call. This is when the
commit_item() function will be called.

Implementation-wise: we reuse the default group mechanism to elegantly
plug the new pseude-groups into configfs. The pending group inherits the
parent group's operations so that config_items can be seamlesly created
in it using the callbacks supplied by the user as part of the committable
group itself.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Linus Walleij 
---
 Documentation/filesystems/configfs.rst |   6 +-
 fs/configfs/configfs_internal.h|   2 +
 fs/configfs/dir.c  | 245 -
 include/linux/configfs.h   |   1 +
 4 files changed, 245 insertions(+), 9 deletions(-)

diff --git a/Documentation/filesystems/configfs.rst 
b/Documentation/filesystems/configfs.rst
index 1d3d6f4a82a9..7e0e7c356450 100644
--- a/Documentation/filesystems/configfs.rst
+++ b/Documentation/filesystems/configfs.rst
@@ -290,6 +290,7 @@ config_item_type::
struct config_group *(*make_group)(struct config_group *group,
   const char *name);
int (*commit_item)(struct config_item *item);
+   int (*uncommit_item)(struct config_item *item);
void (*disconnect_notify)(struct config_group *group,
  struct config_item *item);
void (*drop_item)(struct config_group *group,
@@ -490,9 +491,6 @@ pass up an error.
 Committable Items
 =
 
-Note:
- Committable items are currently unimplemented.
-
 Some config_items cannot have a valid initial state.  That is, no
 default values can be specified for the item's attributes such that the
 item can do its work.  Userspace must configure one or more attributes,
@@ -532,4 +530,4 @@ method returns zero and the item is moved to the "live" 
directory.
 As rmdir(2) does not work in the "live" directory, an item must be
 shutdown, or "uncommitted".  Again, this is done via rename(2), this
 time from the "live" directory back to the "pending" one.  The subsystem
-is notified by the ct_group_ops->uncommit_object() method.
+is notified by the ct_group_ops->uncommit_item() method.
diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h
index b495c9f043d4..41ac21c82bf5 100644
--- a/fs/configfs/configfs_internal.h
+++ b/fs/configfs/configfs_internal.h
@@ -56,6 +56,8 @@ struct configfs_dirent {
 #define CONFIGFS_USET_DROPPING (1UL << 8)
 #define CONFIGFS_USET_IN_MKDIR (1UL << 9)
 #define CONFIGFS_USET_CREATING (1UL << 10)
+#define CONFIGFS_GROUP_PENDING (1UL << 11)
+#define CONFIGFS_GROUP_LIVE(1UL << 12)
 #define CONFIGFS_NOT_PINNED(CONFIGFS_ITEM_ATTR | CONFIGFS_ITEM_BIN_ATTR)
 
 extern struct mutex configfs_symlink_mutex;
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index b6098e02e20b..f3c95c1d5278 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -656,6 +656,13 @@ static void detach_groups(struct config_group *group)
 
inode_unlock(d_inode(child));
 
+   /*
+* Free memory allocated for the pending and live directories
+* of committable groups.
+*/
+   if (sd->s_type & (CONFIGFS_GROUP_PENDING | CONFIGFS_GROUP_LIVE))
+   kfree(sd->s_element);
+
d_delete(child);
dput(child);
}
@@ -860,6 +867,134 @@ static void configfs_detach_item(struct config_item *item)
configfs_remove_dir(item);
 }
 
+static bool is_committable_group(struct config_item *item)
+{
+   const struct config_item_type *type = item->ci_type;
+
+   if (type && type->ct_group_ops &&
+   type->ct_group_ops->commit_item &&
+   type->ct_group_ops->uncommit_item)
+   return true;
+
+   return false;
+}
+
+struct pending_group_data {
+   struct config_group group;
+   struct config_item_type type;
+   struct configfs_group_operations group_ops;
+};
+
+struct live_group_data {
+   struct config_group group;
+   struct config_item_type type;
+};
+
+static int create_pending_group(struct config_item *parent_item,
+   struct configfs_fragment *frag)
+{
+   const struct config_item_type *parent_type = parent_item->ci_type;
+   struct pending_group_data *pending;
+   struct configfs_dirent *sd;
+   int ret;
+
+   pending = kzalloc(sizeof(*pendin

[PATCH v2 12/12] selftests: gpio: add test cases for gpio-sim

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Add a set of tests for the new gpio-sim module. This is a pure shell
test-suite and uses the helper programs available in the gpio selftests
directory. These test-cases only test the functionalities exposed by the
gpio-sim driver, not those handled by core gpiolib code.

Signed-off-by: Bartosz Golaszewski 
---
 tools/testing/selftests/gpio/Makefile|   2 +-
 tools/testing/selftests/gpio/config  |   1 +
 tools/testing/selftests/gpio/gpio-sim.sh | 229 +++
 3 files changed, 231 insertions(+), 1 deletion(-)
 create mode 100755 tools/testing/selftests/gpio/gpio-sim.sh

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index d7d8f1985d99..4c6df61c76a8 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 
-TEST_PROGS := gpio-mockup.sh
+TEST_PROGS := gpio-mockup.sh gpio-sim.sh
 TEST_FILES := gpio-mockup-sysfs.sh
 TEST_GEN_PROGS_EXTENDED := gpio-mockup-cdev gpio-chip-info gpio-line-name
 
diff --git a/tools/testing/selftests/gpio/config 
b/tools/testing/selftests/gpio/config
index ce100342c20b..409a8532facc 100644
--- a/tools/testing/selftests/gpio/config
+++ b/tools/testing/selftests/gpio/config
@@ -1,3 +1,4 @@
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_CDEV=y
 CONFIG_GPIO_MOCKUP=m
+CONFIG_GPIO_SIM=m
diff --git a/tools/testing/selftests/gpio/gpio-sim.sh 
b/tools/testing/selftests/gpio/gpio-sim.sh
new file mode 100755
index ..9fd13ab8bec6
--- /dev/null
+++ b/tools/testing/selftests/gpio/gpio-sim.sh
@@ -0,0 +1,229 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2021 Bartosz Golaszewski 
+
+BASE_DIR=`dirname $0`
+CONFIGFS_DIR="/sys/kernel/config/gpio-sim"
+PENDING_DIR=$CONFIGFS_DIR/pending
+LIVE_DIR=$CONFIGFS_DIR/live
+MODULE="gpio-sim"
+
+fail() {
+   echo "$*" >&2
+   echo "GPIO $MODULE test FAIL"
+   exit 1
+}
+
+skip() {
+   echo "$*" >&2
+   echo "GPIO $MODULE test SKIP"
+   exit 4
+}
+
+configfs_cleanup() {
+   for DIR in `ls $LIVE_DIR`; do
+   mv $LIVE_DIR/$DIR $PENDING_DIR
+   done
+
+   for DIR in `ls $PENDING_DIR`; do
+   rmdir $PENDING_DIR/$DIR
+   done
+}
+
+create_pending_chip() {
+   local NAME="$1"
+   local LABEL="$2"
+   local NUM_LINES="$3"
+   local LINE_NAMES="$4"
+   local CHIP_DIR="$PENDING_DIR/$NAME"
+
+   mkdir $CHIP_DIR
+   test -n "$LABEL" && echo $LABEL > $CHIP_DIR/label
+   test -n "$NUM_LINES" && echo $NUM_LINES > $CHIP_DIR/num_lines
+   if [ -n "$LINE_NAMES" ]; then
+   echo $LINE_NAMES 2> /dev/null > $CHIP_DIR/line_names
+   # This one can fail
+   if [ "$?" -ne "0" ]; then
+   return 1
+   fi
+   fi
+}
+
+create_live_chip() {
+   local CHIP_DIR="$PENDING_DIR/$1"
+
+   create_pending_chip "$@" || fail "unable to create the chip configfs 
item"
+   mv $CHIP_DIR $LIVE_DIR || fail "unable to commit the chip configfs item"
+}
+
+remove_pending_chip() {
+   local NAME="$1"
+
+   rmdir $PENDING_DIR/$NAME || fail "unable to remove the chip configfs 
item"
+}
+
+remove_live_chip() {
+   local NAME="$1"
+
+   mv $LIVE_DIR/$NAME $PENDING_DIR || fail "unable to uncommit the chip 
configfs item"
+   remove_pending_chip "$@"
+}
+
+configfs_chip_name() {
+   local CHIP="$1"
+
+   cat $LIVE_DIR/$CHIP/chip_name 2> /dev/null || return 1
+}
+
+configfs_dev_name() {
+   local CHIP="$1"
+
+   cat $LIVE_DIR/$CHIP/dev_name 2> /dev/null || return 1
+}
+
+get_chip_num_lines() {
+   local CHIP="$1"
+
+   $BASE_DIR/gpio-chip-info /dev/`configfs_chip_name $CHIP` num-lines
+}
+
+get_chip_label() {
+   local CHIP="$1"
+
+   $BASE_DIR/gpio-chip-info /dev/`configfs_chip_name $CHIP` label
+}
+
+get_line_name() {
+   local CHIP="$1"
+   local OFFSET="$2"
+
+   $BASE_DIR/gpio-line-name /dev/`configfs_chip_name $CHIP` $OFFSET
+}
+
+sysfs_set_pull() {
+   local CHIP="$1"
+   local OFFSET="$2"
+   local PULL="$3"
+   local SYSFSPATH="/sys/devices/platform/`configfs_dev_name 
$CHIP`/line-ctrl/gpio$OFFSET"
+
+   echo $PULL > $SYSFSPATH
+}
+
+# Load the gpio-sim module. This will pull in configfs if needed too.
+modprobe gpio-sim || skip "unable to load the gpio-sim module"
+# Make sure configfs is mounted at /sys/kernel/config. Wait a bit if needed.
+for IDX in `seq 5`; do
+   if [ "$IDX" -eq "5" ]; then
+   skip "configfs not mounted at /sys/kernel/config"
+   fi
+
+   mountpoint -q /sys/kernel/config && break
+   sleep 0.1
+done
+# If the module was already loaded: remove all previous chips
+configfs_cleanup
+
+trap "exit 1" SIGTERM SIGINT
+trap configfs_cleanup EXIT
+
+echo "1. chip_name and dev_name attributes"
+
+echo "1.1. Chip name is communicated to user"
+create_live_chip chip
+test -n `cat $LIVE_DIR/chip/chip_name` ||

[PATCH v2 06/12] lib: bitmap: order includes alphabetically

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

For better readability and maintenance: order the includes in bitmap
source files alphabetically.

Signed-off-by: Bartosz Golaszewski 
---
 include/linux/bitmap.h | 4 ++--
 lib/bitmap.c   | 9 +
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 6939a8983026..3282db97e06c 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -4,10 +4,10 @@
 
 #ifndef __ASSEMBLY__
 
-#include 
 #include 
-#include 
 #include 
+#include 
+#include 
 
 /*
  * bitmaps provide bit arrays that consume one or more unsigned
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 75006c4036e9..78f70d9007ad 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -3,17 +3,18 @@
  * lib/bitmap.c
  * Helper functions for bitmap.h.
  */
-#include 
-#include 
-#include 
-#include 
+
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
-- 
2.29.1

[PATCH v2 08/12] drivers: export device_is_bound()

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Export the symbol for device_is_bound() so that we can use it in gpio-sim
to check if the simulated GPIO chip is bound before fetching its driver
data from configfs callbacks in order to retrieve the name of the GPIO
chip device.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/base/dd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9179825ff646..c62c02e3490a 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -353,6 +353,7 @@ bool device_is_bound(struct device *dev)
 {
return dev->p && klist_node_attached(&dev->p->knode_driver);
 }
+EXPORT_SYMBOL_GPL(device_is_bound);
 
 static void driver_bound(struct device *dev)
 {
-- 
2.29.1

Re: [PATCH v3 1/2] mm: Make alloc_contig_range handle free hugetlb pages

[David Hildenbrand]

I think we should not swallo such return values in
isolate_or_dissolve_huge_page() and instead properly report esp. -ENOMEM
properly up this callchain now. Otherwise we'll end up retrying / reporting
-EBUSY, which is misleading.


I am not sure I follow you here.
So, atm, alloc_and_dissolve_huge_page can either generate -ENOMEM or
-EBUSY wrt. error codes.
-ENOMEM when we cannot allocate a page, and -EBUSY when we raced with
someone.
You mean to only report ENOMEM down the chain?


Yes, fatal errors.




 From isolate_migratepages_range()/isolate_migratepages_block() we'll keep
reporting "pfn > 0".

a) In isolate_migratepages_range() we'll keep iterating over pageblocks
although we should just fail with -ENOMEM right away.

b) In __alloc_contig_migrate_range() we'll keep retrying up to 5 times
although we should just fail with -ENOMEM. We end up returning "-EBUSY"
after retrying.

c) In alloc_contig_range() we'll continue trying to isolate although we
should just return -ENOMEM.


Yes, "fatal" errors get masked, and hence we treat everything as "things
are busy, let us try again", and this is rather unforunate.


I think we have should start returning proper errors from
isolate_migratepages_range()/isolate_migratepages_block() on critical issues
(-EINTR, -ENOMEM) instead of going via "!pfn vs. pfn" and retrying on "pfn".

So we should then fail with -ENOMEM during isolate_migratepages_range()
cleanly, just as we would do when we get -ENOMEM during migrate_pages().


I guess we could rework the interface and make isolate_migratepages_range and
isolate_migratepages_block to report the right thing.
I yet have to check that this does not mess up a lot with the compaction
interface.

But overall I agree with your point here, and I am willing to to tackle
this.

The question is whether we want to do this as part of this series, or
after this series gets picked up.
IMHO, we could do it after, as a follow-up, unless you feel strong about
it.

What do you think?


I think this is now the second fatal error we can have (-EINTR, 
-ENOMEM), thus the current interface (return "NULL" on fatal errros) no 
longer works properly.


No strong opinion about fixing this up on top - could be it's cleaner to 
just do it right away.


--
Thanks,

David / dhildenb

Re: [PATCH v4 01/15] gpio: guard gpiochip_irqchip_add_domain() with GPIOLIB_IRQCHIP

[Andy Shevchenko]

On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
 wrote:
>
> The current code doesn't check if GPIOLIB_IRQCHIP is enabled, which results in
> a compilation error when trying to build gpio-regmap if CONFIG_GPIOLIB_IRQCHIP
> isn't enabled.

Suggested-by: ?

> Fixes: 6a45b0e2589f ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
> Signed-off-by: Álvaro Fernández Rojas 
> ---
>  v4: add patch (fix include instead of gpio-regmap.c)
>
>  include/linux/gpio/driver.h | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
> index 286de0520574..ecf0032a0995 100644
> --- a/include/linux/gpio/driver.h
> +++ b/include/linux/gpio/driver.h
> @@ -624,8 +624,17 @@ void gpiochip_irq_domain_deactivate(struct irq_domain 
> *domain,
>  bool gpiochip_irqchip_irq_valid(const struct gpio_chip *gc,
> unsigned int offset);
>
> +#ifdef CONFIG_GPIOLIB_IRQCHIP
>  int gpiochip_irqchip_add_domain(struct gpio_chip *gc,
> struct irq_domain *domain);
> +#else
> +static inline int gpiochip_irqchip_add_domain(struct gpio_chip *gc,
> + struct irq_domain *domain)
> +{
> +   WARN_ON(1);
> +   return -EINVAL;
> +}
> +#endif
>
>  int gpiochip_generic_request(struct gpio_chip *gc, unsigned int offset);
>  void gpiochip_generic_free(struct gpio_chip *gc, unsigned int offset);
> --
> 2.20.1
>


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 02/10] coresight: syscfg: Add registration and feature loading for cs devices

[Suzuki K Poulose]

Hi Mike

There are some minor comments on the naming scheme of the structures,
which I think might improve the code readability.

e.g, in general anything that is associated with a csdev could be named
as such csdev_*, rather than cscfg_*_csdev. The latter kind of implies
"cscfg" is the "primary" object, while it is the csdev where we track
this.

Feel free to ignore.

On 1/28/21 5:09 PM, Mike Leach wrote:

API for individual devices to register with the syscfg management
system is added.

Devices register with matching information, and any features or
configurations that match will be loaded into the device.

The feature and configuration loading is extended so that on load these
are loaded into any currently registered devices. This allows
configuration loading after devices have been registered.

Signed-off-by: Mike Leach 
---
  .../hwtracing/coresight/coresight-config.h|  98 +
  .../hwtracing/coresight/coresight-syscfg.c| 348 ++
  .../hwtracing/coresight/coresight-syscfg.h|  20 +
  include/linux/coresight.h |   5 +
  4 files changed, 471 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-config.h 
b/drivers/hwtracing/coresight/coresight-config.h
index 3fedf8ab3cee..75ecdecf7013 100644
--- a/drivers/hwtracing/coresight/coresight-config.h
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -164,4 +164,102 @@ struct cscfg_config_desc {
const u64 *presets; /* nr_presets * nr_total_params */
  };
  
+/**

+ * config register instance - part of a loaded feature.
+ *maps register values to csdev driver structures
+ *
+ * @value: value to use when setting feature on device / store for
+ * readback of volatile values.
+ * @drv_store: pointer to internal driver element used to set the value
+ * in hardware.
+ */
+struct cscfg_reg_csdev {


minor nit: csdev_csfg_reg ?


+   struct cscfg_regval_desc value;
+   void *drv_store;
+};


I am not sure if it helps to move this drv_store field into csfg_regval_desc
as "void *private". I haven't looked at the following patches. That way we
have less number of structures to deal with.


+
+/**
+ * config parameter instance - part of a loaded feature.
+ *
+ * @feat:  parent feature
+ * @reg:   register value updated by this parameter.
+ * @current_value: current value of parameter - may be set by user via
+ * sysfs, or modified during device operation.
+ * @val64: true if 64 bit value
+ */
+struct cscfg_parameter_csdev {


nit: cscdev_cfg_parameter ?


+   struct cscfg_feature_csdev *feat;


nit: s/feat/cscfg_feat ?


+   struct cscfg_reg_csdev *reg;


nit: s/reg/cscfg_reg/ ?


+   u64 current_value;
+   bool val64;
+};
+
+/**
+ * Feature instance loaded into a CoreSight device.
+ *
+ * When a feature is loaded into a specific device, then this structure holds
+ * the connections between the register / parameter values used and the
+ * internal data structures that are written when the feature is enabled.
+ *
+ * Since applying a feature modifies internal data structures in the device,
+ * then we have a reference to the device spinlock to protect access to these
+ * structures (@csdev_spinlock).
+ *
+ * @desc:  pointer to the static descriptor for this feature.
+ * @csdev: parent CoreSight device instance.
+ * @node:  list entry into feature list for this device.
+ * @csdev_spinlock:device spinlock from csdev instance..
+ * @nr_params: number of parameters.
+ * @params:current parameter values on this device
+ * @nr_regs:   number of registers to be programmed.
+ * @regs:  Programming details for the registers
+ */
+struct cscfg_feature_csdev {
+   const struct cscfg_feature_desc *desc;


nit: s/desc/cscfg_feat_desc ?


+   struct coresight_device *csdev;
+   struct list_head node;
+   spinlock_t *csdev_spinlock;


Why do we need this explicitly here when we have access to csdev ?


+   int nr_params;
+   struct cscfg_parameter_csdev *params;


nit: s/params/cscfg_params/ ?


+   int nr_regs;
+   struct cscfg_reg_csdev *regs;


nit: cscfg_regs ?


+};
+
+/**
+ * Configuration instance when loaded into a CoreSight device.
+ *
+ * The instance contains references to loaded features on this device that are
+ * used by the configuration.
+ *
+ * @desc:  reference to the descriptor for this configuration
+ * @csdev: parent coresight device for this configuration instance.
+ * @node:  list entry within the coresight device
+ * @nr_feat:   Number of features on this device that are used in the
+ *  configuration.
+ * @feats: reference to the device features to enable.
+ * @enabled:   true if configuration is enabled on this device.
+ */
+struct cscfg_config_csdev {


nit: csdev_cscfg_config ?


+   const struct cscfg_confi

RE: [RFC PATCH 2/5] char: rpmb: provide a user space interface

[Winkler, Tomas]

> "Winkler, Tomas"  writes:
> 
> >> The user space API is achieved via a number of synchronous IOCTLs.
> >>
> >>   * RPMB_IOC_VER_CMD - simple versioning API
> >>   * RPMB_IOC_CAP_CMD - query of underlying capabilities
> >>   * RPMB_IOC_PKEY_CMD - one time programming of access key
> >>   * RPMB_IOC_COUNTER_CMD - query the write counter
> >>   * RPMB_IOC_WBLOCKS_CMD - write blocks to device
> >>   * RPMB_IOC_RBLOCKS_CMD - read blocks from device
> >>
> >> The keys used for programming and writing blocks to the device are
> >> key_serial_t handles as provided by the keyctl() interface.
> >>
> >> [AJB: here there are two key differences between this and the
> >> original proposal. The first is the dropping of the sequence of
> >> preformated frames in favour of explicit actions. The second is the
> >> introduction of key_serial_t and the keyring API for referencing the
> >> key to use]
> >
> > Putting it gently I'm not sure this is good idea, from the security point of
> view.
> > The key has to be possession of the one that signs the frames as they are,
> it doesn't mean it is linux kernel keyring, it can be other party on different
> system.
> > With this approach you will make the other usecases not applicable. It
> > is less then trivial to move key securely from one system to another.
> 
> OK I can understand the desire for such a use-case but it does constrain the
> interface on the kernel with access to the hardware to purely providing a
> pipe to the raw hardware while also having to expose the details of the HW
> to userspace. 
This is the use case in Android. The key is in the "trusty" which different os 
running in a  virtual environment. The file storage abstraction is 
implemented there.
I'm not sure the point of constraining the kernel, can you please elaborate on 
that.

Also doesn't this break down after a PROGRAM_KEY event as
> the key will have had to traverse into the "untrusted" kernel?

This is one in a life event of the card happening on the manufacturing floor, 
maybe even not performed on Linux.

> I wonder if virtio-rpmb may be of help here? You could wrap up up the front-
> end in the security domain that has the keys although I don't know how easy
> it would be for a backend to work with real hardware?

I'm open to see any proposal, not sure I can wrap may head about it right now. 

Anyway I was about to send the new round of my code,  but let's come to common 
ground first. 

Thanks
Tomas

> 
> > We all wished it can be abstracted more but the frames has to come
> already signed, and the key material is inside the frame.
> > Thanks
> > Tomas
> >
> >
> >>
> >> Signed-off-by: Alex Bennée 
> >> Cc: Ulf Hansson 
> >> Cc: Linus  Walleij 
> >> Cc: Arnd Bergmann 
> >> Cc: Ilias Apalodimas 
> >> Cc: Tomas Winkler 
> >> Cc: Alexander Usyskin 
> >> Cc: Avri Altman 
> >> ---
> >>  .../userspace-api/ioctl/ioctl-number.rst  |   1 +
> >>  MAINTAINERS   |   1 +
> >>  drivers/char/rpmb/Kconfig |   7 +
> >>  drivers/char/rpmb/Makefile|   1 +
> >>  drivers/char/rpmb/cdev.c  | 246 ++
> >>  drivers/char/rpmb/core.c  |  10 +-
> >>  drivers/char/rpmb/rpmb-cdev.h |  17 ++
> >>  include/linux/rpmb.h  |  10 +
> >>  include/uapi/linux/rpmb.h |  68 +
> >>  9 files changed, 357 insertions(+), 4 deletions(-)  create mode
> >> 100644 drivers/char/rpmb/cdev.c  create mode 100644
> >> drivers/char/rpmb/rpmb- cdev.h  create mode 100644
> >> include/uapi/linux/rpmb.h
> >>
> >> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst
> >> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> >> index a4c75a28c839..0ff2d4d81bb0 100644
> >> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> >> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> >> @@ -344,6 +344,7 @@ Code  Seq#Include File
> >> Comments
> >>  0xB5  00-0F  uapi/linux/rpmsg.h  
> >>  >> remotep...@vger.kernel.org>
> >>  0xB6  alllinux/fpga-dfl.h
> >>  0xB7  alluapi/linux/remoteproc_cdev.h
> >>  >> remotep...@vger.kernel.org>
> >> +0xB8  80-8F  uapi/linux/rpmb.h   
> >>  >> m...@vger.kernel.org>
> >>  0xC0  00-0F  linux/usb/iowarrior.h
> >>  0xCA  00-0F  uapi/misc/cxl.h
> >>  0xCA  10-2F  uapi/misc/ocxl.h
> >> diff --git a/MAINTAINERS b/MAINTAINERS index
> >> 076f3983526c..c60b41b6e6bd 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -15374,6 +15374,7 @@ M: ?
> >>  L:linux-kernel@vger.kernel.org
> >>  S:Supported
> >>  F:drivers/char/rpmb/*
> >> +F:include/uapi/linux/rpmb.h
> >>  F:include/linux/rpmb.h
> >>
> >>  RTL2830 MEDIA DRIVER
> >> diff --git a/drivers/char/rpmb/Kconfig b/drivers/char/rpmb/Kconfig
> >> index 431c2823cf

Re: [PATCH v4 02/15] gpio: regmap: set gpio_chip of_node

[Andy Shevchenko]

On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
 wrote:
>
> This is needed for properly registering gpio regmap as a child of a regmap

gpio -> GPIO

> pin controller.

...

> + * @of_node:   (Optional) The device node

> +   struct device_node *of_node;

Can we use fwnode from day 1, please?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 01/15] gpio: guard gpiochip_irqchip_add_domain() with GPIOLIB_IRQCHIP

[Álvaro Fernández Rojas]

Add missing tag:

Suggested-by: Michael Walle 

> El 4 mar 2021, a las 9:56, Álvaro Fernández Rojas  
> escribió:
> 
> The current code doesn't check if GPIOLIB_IRQCHIP is enabled, which results in
> a compilation error when trying to build gpio-regmap if CONFIG_GPIOLIB_IRQCHIP
> isn't enabled.
> 
> Fixes: 6a45b0e2589f ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
> Signed-off-by: Álvaro Fernández Rojas 
> ---
> v4: add patch (fix include instead of gpio-regmap.c)
> 
> include/linux/gpio/driver.h | 9 +
> 1 file changed, 9 insertions(+)
> 
> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
> index 286de0520574..ecf0032a0995 100644
> --- a/include/linux/gpio/driver.h
> +++ b/include/linux/gpio/driver.h
> @@ -624,8 +624,17 @@ void gpiochip_irq_domain_deactivate(struct irq_domain 
> *domain,
> bool gpiochip_irqchip_irq_valid(const struct gpio_chip *gc,
>   unsigned int offset);
> 
> +#ifdef CONFIG_GPIOLIB_IRQCHIP
> int gpiochip_irqchip_add_domain(struct gpio_chip *gc,
>   struct irq_domain *domain);
> +#else
> +static inline int gpiochip_irqchip_add_domain(struct gpio_chip *gc,
> +   struct irq_domain *domain)
> +{
> + WARN_ON(1);
> + return -EINVAL;
> +}
> +#endif
> 
> int gpiochip_generic_request(struct gpio_chip *gc, unsigned int offset);
> void gpiochip_generic_free(struct gpio_chip *gc, unsigned int offset);
> -- 
> 2.20.1
> 

Re: [PATCH mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM

[kernel test robot]

Hi "Rafał,

I love your patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/firmware-bcm47xx_nvram-refactor-finding-reading-NVRAM/20210304-153024
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
f69d02e37a85645aa90d18cacfff36dba370f797
config: x86_64-randconfig-a011-20210304 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
eec7f8f7b1226be422a76542cb403d02538f453a)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/10b445f4686138c7c84adb02aa521bbc6bef8ab7
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Rafa-Mi-ecki/firmware-bcm47xx_nvram-refactor-finding-reading-NVRAM/20210304-153024
git checkout 10b445f4686138c7c84adb02aa521bbc6bef8ab7
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

   drivers/firmware/broadcom/bcm47xx_nvram.c:41: warning: Function parameter or 
member 'nvram' not described in 'bcm47xx_nvram_is_valid'
>> drivers/firmware/broadcom/bcm47xx_nvram.c:41: warning: expecting prototype 
>> for bcm47xx_nvram_validate(). Prototype was for bcm47xx_nvram_is_valid() 
>> instead
   drivers/firmware/broadcom/bcm47xx_nvram.c:49: warning: Function parameter or 
member 'nvram_start' not described in 'bcm47xx_nvram_copy'
   drivers/firmware/broadcom/bcm47xx_nvram.c:49: warning: Function parameter or 
member 'res_size' not described in 'bcm47xx_nvram_copy'
   drivers/firmware/broadcom/bcm47xx_nvram.c:73: warning: Function parameter or 
member 'flash_start' not described in 'bcm47xx_nvram_find_and_copy'
   drivers/firmware/broadcom/bcm47xx_nvram.c:73: warning: Function parameter or 
member 'res_size' not described in 'bcm47xx_nvram_find_and_copy'


vim +41 drivers/firmware/broadcom/bcm47xx_nvram.c

121915c4ee0812 arch/mips/bcm47xx/nvram.c Waldemar Brodkorb 
2010-06-08  36  
10b445f4686138 drivers/firmware/broadcom/bcm47xx_nvram.c Rafał Miłecki 
2021-03-04  37  /**
10b445f4686138 drivers/firmware/broadcom/bcm47xx_nvram.c Rafał Miłecki 
2021-03-04  38   * bcm47xx_nvram_validate - check for a valid NVRAM at 
specified memory
10b445f4686138 drivers/firmware/broadcom/bcm47xx_nvram.c Rafał Miłecki 
2021-03-04  39   */
10b445f4686138 drivers/firmware/broadcom/bcm47xx_nvram.c Rafał Miłecki 
2021-03-04  40  static bool bcm47xx_nvram_is_valid(void __iomem *nvram)
f36738ddfeea02 arch/mips/bcm47xx/nvram.c Hauke Mehrtens
2012-12-26 @41  {
10b445f4686138 drivers/firmware/broadcom/bcm47xx_nvram.c Rafał Miłecki 
2021-03-04  42   return ((struct nvram_header *)nvram)->magic == 
NVRAM_MAGIC;
10b445f4686138 drivers/firmware/broadcom/bcm47xx_nvram.c Rafał Miłecki 
2021-03-04  43  }
f36738ddfeea02 arch/mips/bcm47xx/nvram.c Hauke Mehrtens
2012-12-26  44  

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


.config.gz
Description: application/gzip

Re: [PATCH 5.10 000/661] 5.10.20-rc2 review

[Greg Kroah-Hartman]

On Mon, Mar 01, 2021 at 02:43:59PM -0700, Shuah Khan wrote:
> On 3/1/21 12:37 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.20 release.
> > There are 661 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed, 03 Mar 2021 19:34:53 +.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.20-rc2.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.10.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.
> 
> Tested-by: Shuah Khan 

Thanks for all the testing and letting me know.

greg k-h

Re: [PATCH v3 1/2] mm: Make alloc_contig_range handle free hugetlb pages

[Oscar Salvador]

On Thu, Mar 04, 2021 at 11:32:29AM +0100, David Hildenbrand wrote:
> I think this is now the second fatal error we can have (-EINTR, -ENOMEM),
> thus the current interface (return "NULL" on fatal errros) no longer works
> properly.
> 
> No strong opinion about fixing this up on top - could be it's cleaner to
> just do it right away.

Ok, I see.

Then I will start working on that in v4.

Any more feedback to either patch#1 or patch#2?

Thanks!


-- 
Oscar Salvador
SUSE L3

Re: [PATCH 5.10 000/661] 5.10.20-rc2 review

[Greg Kroah-Hartman]

On Mon, Mar 01, 2021 at 10:19:25PM +0100, Pavel Machek wrote:
> Hi!
> 
> > This is the start of the stable review cycle for the 5.10.20 release.
> > There are 661 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> 
> CIP testing did not find any problems here (failures are due to
> unavailable boards).
> 
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
> 
> Tested-by: Pavel Machek (CIP) 

Thanks for testing some of these and letting me know.

greg k-h

Re: [PATCH 5.10 000/657] 5.10.20-rc4 review

[Greg Kroah-Hartman]

On Wed, Mar 03, 2021 at 12:08:20PM -0800, Guenter Roeck wrote:
> On Tue, Mar 02, 2021 at 08:28:49PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.20 release.
> > There are 657 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 156 pass: 156 fail: 0
> Qemu test results:
>   total: 430 pass: 430 fail: 0
> 
> Tested-by: Guenter Roeck 

thanks for testing them all and letting me know.

greg k-h

Re: [PATCH 5.10 000/657] 5.10.20-rc4 review

[Greg Kroah-Hartman]

On Wed, Mar 03, 2021 at 10:18:30AM +, Guillaume Tucker wrote:
> On 02/03/2021 19:28, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.20 release.
> > There are 657 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu, 04 Mar 2021 19:25:07 +.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.20-rc4.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.10.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> 
> No build errors seen on kernelci.org:
> 
>   
> https://kernelci.org/build/stable-rc/branch/linux-5.10.y/kernel/v5.10.19-658-g083cbba104d9/
> 
> 
> No test regressions either:
> 
>   
> https://kernelci.org/test/job/stable-rc/branch/linux-5.10.y/kernel/v5.10.19-658-g083cbba104d9/
> 
> 
> Tested-by: "kernelci.org bot" 
> 

Great, thanks for testing and letting me know.

greg k-h

Re: [PATCH v4 03/15] pinctrl: bcm: add bcm63xx base code

[Andy Shevchenko]

On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
 wrote:
>
> Add a helper for registering BCM63XX pin controllers.
>
> Signed-off-by: Álvaro Fernández Rojas 
> Signed-off-by: Jonas Gorski 

This SoB is in a strange place.

The order is wrong taking into account the From header (committer). So,
it's not clear who is the author, who is a co-developer, and who is
the committer (one person may utilize few roles).
Check for the rest of the series as well (basically this is the rule
of thumb to recheck entire code for the comment you have got at any
single place of it).

...

> +static const struct of_device_id bcm63xx_gpio_of_match[] = {
> +   { .compatible = "brcm,bcm6318-gpio", },
> +   { .compatible = "brcm,bcm6328-gpio", },
> +   { .compatible = "brcm,bcm6358-gpio", },
> +   { .compatible = "brcm,bcm6362-gpio", },
> +   { .compatible = "brcm,bcm6368-gpio", },
> +   { .compatible = "brcm,bcm63268-gpio", },

> +   { /* sentinel */ },

Comma is not needed in terminator line

> +};

...

> +   dev_info(dev, "registered\n");

Unneeded noise.

...

> +#include 
> +#include 

The rule of thumb is to include only the headers that the below code
is direct user of.

The above are not used anyhow, while missed types.h and several
forward declarations.

> +#include "../core.h"

Seems the same.

> +#define BCM63XX_BANK_GPIOS 32
> +
> +struct bcm63xx_pinctrl_soc {
> +   struct pinctrl_ops *pctl_ops;
> +   struct pinmux_ops *pmx_ops;
> +
> +   const struct pinctrl_pin_desc *pins;
> +   unsigned npins;
> +
> +   unsigned int ngpios;
> +};
> +
> +struct bcm63xx_pinctrl {
> +   struct device *dev;
> +   struct regmap *regs;
> +
> +   struct pinctrl_desc pctl_desc;
> +   struct pinctrl_dev *pctl_dev;
> +
> +   void *driver_data;
> +};


--
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 01/10] coresight: syscfg: Initial coresight system configuration

[Mike Leach]

Hi Suzuki,

On Thu, 4 Mar 2021 at 10:08, Suzuki K Poulose  wrote:
>
> On 1/28/21 5:09 PM, Mike Leach wrote:
> > Creates an system management API to allow complex configurations and
> > features to be programmed into a CoreSight infrastructure.
> >
> > A feature is defined as a programming set for a device or class of
> > devices.
> >
> > A configuration is a set of features across the system that are enabled
> > for a trace session.
> >
> > The API will manage system wide configuration, and allow complex
> > programmed features to be added to individual device instances, and
> > provide for system wide configuration selection on trace capture
> > operations.
> >
> > This patch creates the initial data object and the initial API for
> > loading configurations and features.
> >
> > Signed-off-by: Mike Leach 
> > ---
> >   drivers/hwtracing/coresight/Makefile  |   2 +-
> >   .../hwtracing/coresight/coresight-config.h| 167 +++
> >   drivers/hwtracing/coresight/coresight-core.c  |  12 +-
> >   .../hwtracing/coresight/coresight-etm-perf.c  |   2 +-
> >   .../hwtracing/coresight/coresight-etm-perf.h  |   2 +-
> >   .../hwtracing/coresight/coresight-syscfg.c| 197 ++
> >   .../hwtracing/coresight/coresight-syscfg.h|  54 +
> >   7 files changed, 432 insertions(+), 4 deletions(-)
> >   create mode 100644 drivers/hwtracing/coresight/coresight-config.h
> >   create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.c
> >   create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.h
> >
> > diff --git a/drivers/hwtracing/coresight/Makefile 
> > b/drivers/hwtracing/coresight/Makefile
> > index f20e357758d1..4ce854c434b1 100644
> > --- a/drivers/hwtracing/coresight/Makefile
> > +++ b/drivers/hwtracing/coresight/Makefile
> > @@ -4,7 +4,7 @@
> >   #
> >   obj-$(CONFIG_CORESIGHT) += coresight.o
> >   coresight-y := coresight-core.o  coresight-etm-perf.o 
> > coresight-platform.o \
> > - coresight-sysfs.o
> > + coresight-sysfs.o coresight-syscfg.o
> >   obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
> >   coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
> > coresight-tmc-etr.o
> > diff --git a/drivers/hwtracing/coresight/coresight-config.h 
> > b/drivers/hwtracing/coresight/coresight-config.h
> > new file mode 100644
> > index ..3fedf8ab3cee
> > --- /dev/null
> > +++ b/drivers/hwtracing/coresight/coresight-config.h
> > @@ -0,0 +1,167 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (c) 2020 Linaro Limited, All rights reserved.
> > + * Author: Mike Leach 
> > + */
> > +
> > +#ifndef _CORESIGHT_CORESIGHT_CONFIG_H
> > +#define _CORESIGHT_CORESIGHT_CONFIG_H
> > +
> > +#include 
> > +#include 
> > +
> > +/* CoreSight Configuration Management - component and system wide 
> > configuration */
> > +
> > +/*
> > + * Register type flags for register value descriptor:
> > + * describe how the value is interpreted, and handled.
> > + */
> > +#define CS_CFG_REG_TYPE_STD  0x80/* reg is standard reg */
> > +#define CS_CFG_REG_TYPE_RESOURCE 0x40/* reg is a resource */
> > +#define CS_CFG_REG_TYPE_VAL_PARAM0x08/* reg value uses param */
> > +#define CS_CFG_REG_TYPE_VAL_MASK 0x04/* reg value bit masked */
> > +#define CS_CFG_REG_TYPE_VAL_64BIT0x02/* reg value 64 bit */
> > +#define CS_CFG_REG_TYPE_VAL_SAVE 0x01/* reg value save on disable 
> > */
> > +
> > +/*
> > + * flags defining what device class a feature will match to when 
> > processing a
> > + * system configuration - used by config data and devices.
> > + */
> > +#define  CS_CFG_MATCH_CLASS_SRC_ALL  0x0001  /* match any source */
> > +#define CS_CFG_MATCH_CLASS_SRC_ETM4  0x0002  /* match any ETMv4 device */
> > +
> > +/* flags defining device instance matching - used in config match desc 
> > data. */
> > +#define CS_CFG_MATCH_INST_ANY0x8000 /* any instance of 
> > a class */
> > +
> > +/*
> > + * Limit number of presets in a configuration
> > + * This is related to the number of bits (4) we use to select the preset on
> > + * the perf command line. Preset 0 is always none selected.
> > + * See PMU_FORMAT_ATTR(preset, "config:0-3") in coresight-etm-perf.c
> > + */
> > +#define CS_CFG_CONFIG_PRESET_MAX 15
> > +
> > +/**
> > + * Parameter descriptor for a device feature.
> > + *
> > + * @name:  Name of parameter.
> > + * @value: Initial or default value.
> > + */
> > +struct cscfg_parameter_desc {
> > + const char *name;
> > + u64 value;
> > +};
> > +
> > +/**
> > + * Representation of register value.
> > + *
> > + * Supports full 64 bit register value, or 32 bit value with optional mask
> > + * value.
> > + *
> > + * @type:define register usage and interpretation.
> > + * @offset:  the address offset for register in the hardware device (per 
> > device specification).
> > + * @hw_info: optional hardware device type specific in

Re: [PATCH v4 01/10] coresight: syscfg: Initial coresight system configuration

[Suzuki K Poulose]

On 1/28/21 5:09 PM, Mike Leach wrote:

Creates an system management API to allow complex configurations and
features to be programmed into a CoreSight infrastructure.

A feature is defined as a programming set for a device or class of
devices.

A configuration is a set of features across the system that are enabled
for a trace session.

The API will manage system wide configuration, and allow complex
programmed features to be added to individual device instances, and
provide for system wide configuration selection on trace capture
operations.

This patch creates the initial data object and the initial API for
loading configurations and features.

Signed-off-by: Mike Leach 




+/**
+ * Representation of register value.
+ *
+ * Supports full 64 bit register value, or 32 bit value with optional mask
+ * value.
+ *
+ * @type:  define register usage and interpretation.
+ * @offset:the address offset for register in the hardware device (per 
device specification).
+ * @hw_info:   optional hardware device type specific information. (ETM / CTI 
specific etc)
+ * @val64: 64 bit value.
+ * @val32: 32 bit value.
+ * @mask32:32 bit mask when using 32 bit value to access device register.
+ */
+struct cscfg_regval_desc {
+   struct {
+   u32 type:8;
+   u32 offset:12;
+   u32 hw_info:12;
+   };
+   union {
+   u64 val64;
+   struct {
+   u32 val32;


Since this is also overloaded with param_idx for VAL_PARAM type, please
make this explicit by doing something like this, to avoid having
to explain things in the code, undocumented here.

union {
u32 val32;
u32 param_idx;
};


Cheers
Suzuki

[PATCH v2] hwmon: (nct6883) Support NCT6686D

[Jiqi Li]

Add support for NCT6686D chip used in the Lenovo P620.

Signed-off-by: Jiqi Li 
Reviewed-by: Mark Pearson 
---
Changes in v2: Corrected typo from NCT6886D to NCT6686D
---
 drivers/hwmon/nct6683.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/nct6683.c b/drivers/hwmon/nct6683.c
index a23047a3bfe2..256e8d62f858 100644
--- a/drivers/hwmon/nct6683.c
+++ b/drivers/hwmon/nct6683.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
  * nct6683 - Driver for the hardware monitoring functionality of
- *  Nuvoton NCT6683D/NCT6687D eSIO
+ *  Nuvoton NCT6683D/NCT6686D/NCT6687D eSIO
  *
  * Copyright (C) 2013  Guenter Roeck 
  *
@@ -12,6 +12,7 @@
  *
  * Chip#vin#fan#pwm#temp  chip ID
  * nct6683d 21(1)   16  8   32(1) 0xc730
+ * nct6686d 21(1)   16  8   32(1) 0xd440
  * nct6687d 21(1)   16  8   32(1) 0xd590
  *
  * Notes:
@@ -33,7 +34,7 @@
 #include 
 #include 
 
-enum kinds { nct6683, nct6687 };
+enum kinds { nct6683, nct6686, nct6687 };
 
 static bool force;
 module_param(force, bool, 0);
@@ -41,11 +42,13 @@ MODULE_PARM_DESC(force, "Set to one to enable support for 
unknown vendors");
 
 static const char * const nct6683_device_names[] = {
"nct6683",
+   "nct6686",
"nct6687",
 };
 
 static const char * const nct6683_chip_names[] = {
"NCT6683D",
+   "NCT6686D",
"NCT6687D",
 };
 
@@ -66,6 +69,7 @@ static const char * const nct6683_chip_names[] = {
 
 #define SIO_NCT6681_ID 0xb270  /* for later */
 #define SIO_NCT6683_ID 0xc730
+#define SIO_NCT6686_ID 0xd440
 #define SIO_NCT6687_ID 0xd590
 #define SIO_ID_MASK0xFFF0
 
@@ -1362,6 +1366,9 @@ static int __init nct6683_find(int sioaddr, struct 
nct6683_sio_data *sio_data)
case SIO_NCT6683_ID:
sio_data->kind = nct6683;
break;
+   case SIO_NCT6686_ID:
+   sio_data->kind = nct6686;
+   break;
case SIO_NCT6687_ID:
sio_data->kind = nct6687;
break;
-- 
2.18.2

Re: [PATCH] x86/vdso: Use proper modifier for len's printf in extract

[Borislav Petkov]

On Thu, Mar 04, 2021 at 06:18:25AM +0100, Jiri Slaby wrote:
> It's built with gcc 10 from tumbleweed and it's a standard config from
> kerncvs:
> https://github.com/openSUSE/kernel-source/blob/stable/config/i386/pae

Nope, can't trigger with that one either. :-\

Anyway, it is obvious enough so applied.

Thx.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH v4 05/15] pinctrl: add a pincontrol driver for BCM6328

[Andy Shevchenko]

On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas
 wrote:
>
> Add a pincontrol driver for BCM6328. BCM628 supports muxing 32 pins as
> GPIOs, as LEDs for the integrated LED controller, or various other
> functions. Its pincontrol mux registers also control other aspects, like
> switching the second USB port between host and device mode.

...

> +static inline unsigned int bcm6328_mux_off(unsigned int pin)
> +{
> +   static const unsigned int bcm6328_mux[] = {
> +   BCM6328_MUX_LO_REG,
> +   BCM6328_MUX_HI_REG,

> +   BCM6328_MUX_OTHER_REG

When it's not terminator add a comma, otherwise remove a comma.

Also, why is it inside a function? It's anyway global and constant.

> +   };

...

> +   regmap_update_bits(pc->regs, bcm6328_mux_off(pin),
> +  3UL << ((pin % 16) * 2),

3UL => #define BLABLA  GENMASK(1, 0)

> +  mux << ((pin % 16) * 2));

...

> +static const struct of_device_id bcm6328_pinctrl_match[] = {
> +   { .compatible = "brcm,bcm6328-pinctrl", },
> +   { },

No comma.

> +};

Above comments to all your patches.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy

[Hans de Goede]

Hi,

On 2/16/21 8:24 AM, Perry Yuan wrote:
> Hi Hans:
> 
> On 2021/1/13 2:37, Hans de Goede wrote:
>> Hi,
>>
>> I know there already is a v3 out and I will try to get around to reviewing
>> that soon, still 1 remark about the discussion surrounding v2:
>>
>> On 1/11/21 2:42 PM, Perry Yuan wrote:
>>
>> 
>>
> *The flow is like this:
> 1) User presses key. HW does stuff with this key (timeout is started)
> 2) Event is emitted from FW
> 3) Event received by dell-privacy
> 4) KEY_MICMUTE emitted from dell-privacy
> 5) Userland picks up key and modifies kcontrol for SW mute
> 6) Codec kernel driver catches and calls ledtrig_audio_set, like this:
> ledtrig_audio_set(LED_AUDIO_MICMUTE,
>     rt715->micmute_led ? LED_ON :LED_OFF);
> 7) If "LED" is set to on dell-privacy notifies ec,
>    and timeout is cancelled,HW mic mute activated.
>
 Please proofread the commit message again, and pay attention to 
 capitalization
 and spacing.
>>> I want to reformat it and move the commit info to cover letter.
>>
>> Please also put a copy of this as a comment in either the wmi or the
>> acpi driver (with a comment pointing to the comment in the other) this is
>> important info to have for someone reading the code and trying to understand
>> how this all fits together.
>>
>> Regards,
>>
>> Hans
>>
> Hans.
> I have added the comments to the dell-privacy  driver file in V4
> 
> ---
> drivers/platform/x86/dell-privacy-wmi.c
> 
> EXPORT_SYMBOL_GPL(dell_privacy_valid);
> /*
>  * The flow of privacy event:
>  * 1) User presses key. HW does stuff with this key (timeout is started)
>  * 2) WMI event is emitted from BIOS
>  * 3) WMI event is received by dell-privacy
>  * 4) KEY_MICMUTE emitted from dell-privacy
>  * 5) Userland picks up key and modifies kcontrol for SW mute
>  * 6) Codec kernel driver catches and calls ledtrig_audio_set defined by
>  *    dell-privacy-acpi driver.
>  *    codec driver will call like this to switch micmute led state.
>  *  ledtrig_audio_set(LED_AUDIO_MICMUTE, micmute_led ? LED_ON :LED_OFF);
>  * 7) If "LED" is set to on dell-privacy notifies EC,and timeout is cancelled,
>  *  HW mic mute activated.
>  */
> void dell_privacy_process_event(int type, int code, int status)
> {
>     struct privacy_wmi_data *priv;
>     const struct key_entry *key;
> 
>     mutex_lock(&list_mutex);
> 
> 
> ---
> drivers/platform/x86/dell-privacy-acpi.c
> 
> /*
>  * Pressing the mute key activates a time delayed circuit to physically cut
>  * off the mute. The LED is in the same circuit, so it reflects the true
>  * state of the HW mute.  The reason for the EC "ack" is so that software
>  * can first invoke a SW mute before the HW circuit is cut off.  Without SW
>  * cutting this off first does not affect the time delayed muting or status
>  * of the LED but there is a possibility of a "popping" noise.
>  *
>  * If the EC receives the SW ack, the circuit will be activated before the
>  * delay completed.
>  *
>  * Exposing as an LED device allows the codec drivers notification path to
>  * EC ACK to work
>  */
> static int dell_privacy_leds_setup(struct device *dev)
> {
>     struct privacy_acpi_priv *priv = dev_get_drvdata(dev);
>     int ret = 0;
> 
> .
> 

This looks good, thank you.

Regards,

Hans

Re: [PATCH v3] powerpc/uprobes: Validation for prefixed instruction

[Christophe Leroy]

Le 04/03/2021 à 11:13, Ravi Bangoria a écrit :



On 3/4/21 1:02 PM, Christophe Leroy wrote:



Le 04/03/2021 à 06:05, Ravi Bangoria a écrit :

As per ISA 3.1, prefixed instruction should not cross 64-byte
boundary. So don't allow Uprobe on such prefixed instruction.

There are two ways probed instruction is changed in mapped pages.
First, when Uprobe is activated, it searches for all the relevant
pages and replace instruction in them. In this case, if that probe
is on the 64-byte unaligned prefixed instruction, error out
directly. Second, when Uprobe is already active and user maps a
relevant page via mmap(), instruction is replaced via mmap() code
path. But because Uprobe is invalid, entire mmap() operation can
not be stopped. In this case just print an error and continue.

Signed-off-by: Ravi Bangoria 
---
v2: 
https://lore.kernel.org/r/20210204104703.273429-1-ravi.bango...@linux.ibm.com
v2->v3:
   - Drop restriction for Uprobe on suffix of prefixed instruction.
 It needs lot of code change including generic code but what
 we get in return is not worth it.

  arch/powerpc/kernel/uprobes.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index e8a63713e655..c400971ebe70 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -41,6 +41,14 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
  if (addr & 0x03)
  return -EINVAL;
+    if (!IS_ENABLED(CONFIG_PPC64) || !cpu_has_feature(CPU_FTR_ARCH_31))


cpu_has_feature(CPU_FTR_ARCH_31) should return 'false' when CONFIG_PPC64 is not enabled, no need 
to double check.


Ok.

I'm going to drop CONFIG_PPC64 check because it's not really
required as I replied to Naveen. So, I'll keep CPU_FTR_ARCH_31
check as is.




+    return 0;
+
+    if (ppc_inst_prefixed(auprobe->insn) && (addr & 0x3F) == 0x3C) {


Maybe 3C instead of 4F ? : (addr & 0x3C) == 0x3C


Didn't follow. It's not (addr & 0x3C), it's (addr & 0x3F).


Sorry I meant 3c instead of 3f (And usually we don't use capital letters for 
that).
The last two bits are supposed to always be 0, so it doesn't really matter, I just thought it would 
look better having the same value both sides of the test, ie (addr & 0x3c) == 0x3c.






What about

(addr & (SZ_64 - 4)) == SZ_64 - 4 to make it more explicit ?


Yes this is bit better. Though, it should be:

     (addr & (SZ_64 - 1)) == SZ_64 - 4


-1 or -4 should give the same results as instructions are always 32 bits 
aligned though.

Christophe

Re: [PATCH v9 17/18] virt: acrn: Introduce an interface for Service VM to control vCPU

[Borislav Petkov]

On Thu, Mar 04, 2021 at 09:36:57AM +0800, Shuo A Liu wrote:
> This patchset could fix it.
> https://lore.kernel.org/lkml/20210221134339.57851-1-shuo.a@intel.com/.

Yap, it does, thx.

Tested-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] x86/vdso: Use proper modifier for len's printf in extract

[Jiri Slaby]

On 04. 03. 21, 11:48, Borislav Petkov wrote:

On Thu, Mar 04, 2021 at 06:18:25AM +0100, Jiri Slaby wrote:

It's built with gcc 10 from tumbleweed and it's a standard config from
kerncvs:
https://github.com/openSUSE/kernel-source/blob/stable/config/i386/pae


Nope, can't trigger with that one either. :-\


Beware:
HOSTCC  arch/x86/entry/vdso/vdso2c
^^
You would need to _be_ on i586. Or try with -m32:


gcc -m32 -Wp,-MMD,arch/x86/entry/vdso/.vdso2c.d -Wall -Wmissing-prototypes 
-Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89 
-I/dev/shm/jslaby/linux/tools/include -I/dev/shm/jslaby/linux/include/uapi 
-I/dev/shm/jslaby/linux/arch/i386/include/uapi  -I ./arch/x86/entry/vdso   -o 
/dev/null /dev/shm/jslaby/linux/arch/x86/entry/vdso/vdso2c.c
In file included from /dev/shm/jslaby/linux/arch/x86/entry/vdso/vdso2c.c:162:0:
/dev/shm/jslaby/linux/arch/x86/entry/vdso/vdso2c.h: In function ‘extract64’:
/dev/shm/jslaby/linux/arch/x86/entry/vdso/vdso2c.h:38:52: warning: format ‘%lu’ 
expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t 
{aka unsigned int}’ [-Wformat=]
  fprintf(outfile, "static const unsigned char %s[%lu] = {", name, len);
  ~~^
  %u
In file included from /dev/shm/jslaby/linux/arch/x86/entry/vdso/vdso2c.c:166:0:
/dev/shm/jslaby/linux/arch/x86/entry/vdso/vdso2c.h: In function ‘extract32’:
/dev/shm/jslaby/linux/arch/x86/entry/vdso/vdso2c.h:38:52: warning: format ‘%lu’ 
expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t 
{aka unsigned int}’ [-Wformat=]
  fprintf(outfile, "static const unsigned char %s[%lu] = {", name, len);
  ~~^
  %u


regards,
--
js
suse labs

[tip: x86/vdso] x86/vdso: Use proper modifier for len's format specifier in extract()

[tip-bot2 for Jiri Slaby]

The following commit has been merged into the x86/vdso branch of tip:

Commit-ID: 6bdbe1760651484b0fe6f6d0cc3a2fe8741e6f87
Gitweb:
https://git.kernel.org/tip/6bdbe1760651484b0fe6f6d0cc3a2fe8741e6f87
Author:Jiri Slaby 
AuthorDate:Wed, 03 Mar 2021 07:43:57 +01:00
Committer: Borislav Petkov 
CommitterDate: Thu, 04 Mar 2021 11:47:01 +01:00

x86/vdso: Use proper modifier for len's format specifier in extract()

Commit

  8382c668ce4f ("x86/vdso: Add support for exception fixup in vDSO functions")

prints length "len" which is size_t. Compilers now complain on 32-bit:

  In file included from arch/x86/entry/vdso/vdso2c.c:162:
  arch/x86/entry/vdso/vdso2c.h: In function 'extract64':
  arch/x86/entry/vdso/vdso2c.h:38:52: warning: format '%lu' expects argument of 
\
type 'long unsigned int', but argument 4 has type 'size_t' {aka 
'unsigned int'}

So use proper modifier (%zu) for size_t.

 [ bp: Massage commit message. ]

Fixes: 8382c668ce4f ("x86/vdso: Add support for exception fixup in vDSO 
functions")
Signed-off-by: Jiri Slaby 
Signed-off-by: Borislav Petkov 
Acked-by: Jarkko Sakkinen 
Link: https://lkml.kernel.org/r/20210303064357.17056-1-jsl...@suse.cz
---
 arch/x86/entry/vdso/vdso2c.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/vdso2c.h b/arch/x86/entry/vdso/vdso2c.h
index 1c7cfac..5264daa 100644
--- a/arch/x86/entry/vdso/vdso2c.h
+++ b/arch/x86/entry/vdso/vdso2c.h
@@ -35,7 +35,7 @@ static void BITSFUNC(extract)(const unsigned char *data, 
size_t data_len,
if (offset + len > data_len)
fail("section to extract overruns input data");
 
-   fprintf(outfile, "static const unsigned char %s[%lu] = {", name, len);
+   fprintf(outfile, "static const unsigned char %s[%zu] = {", name, len);
BITSFUNC(copy)(outfile, data + offset, len);
fprintf(outfile, "\n};\n\n");
 }

[tip: irq/core] genirq: Add IRQF_NO_AUTOEN for request_irq/nmi()

[tip-bot2 for Barry Song]

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

Commit-ID: e749df1bbd23f4472082210650514548d8a39e9b
Gitweb:
https://git.kernel.org/tip/e749df1bbd23f4472082210650514548d8a39e9b
Author:Barry Song 
AuthorDate:Wed, 03 Mar 2021 11:49:15 +13:00
Committer: Thomas Gleixner 
CommitterDate: Thu, 04 Mar 2021 11:47:52 +01:00

genirq: Add IRQF_NO_AUTOEN for request_irq/nmi()

Many drivers don't want interrupts enabled automatically via request_irq().
So they are handling this issue by either way of the below two:

(1)
  irq_set_status_flags(irq, IRQ_NOAUTOEN);
  request_irq(dev, irq...);

(2)
  request_irq(dev, irq...);
  disable_irq(irq);

The code in the second way is silly and unsafe. In the small time gap
between request_irq() and disable_irq(), interrupts can still come.

The code in the first way is safe though it's subobtimal.

Add a new IRQF_NO_AUTOEN flag which can be handed in by drivers to
request_irq() and request_nmi(). It prevents the automatic enabling of the
requested interrupt/nmi in the same safe way as #1 above. With that the
various usage sites of #1 and #2 above can be simplified and corrected.

Signed-off-by: Barry Song 
Signed-off-by: Thomas Gleixner 
Cc: dmitry.torok...@gmail.com
Link: 
https://lore.kernel.org/r/20210302224916.13980-2-song.bao@hisilicon.com

---
 include/linux/interrupt.h |  4 
 kernel/irq/manage.c   | 11 +--
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 967e257..76f1161 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -61,6 +61,9 @@
  *interrupt handler after suspending interrupts. For system
  *wakeup devices users need to implement wakeup detection in
  *their interrupt handlers.
+ * IRQF_NO_AUTOEN - Don't enable IRQ or NMI automatically when users request 
it.
+ *Users will enable it explicitly by enable_irq() or 
enable_nmi()
+ *later.
  */
 #define IRQF_SHARED0x0080
 #define IRQF_PROBE_SHARED  0x0100
@@ -74,6 +77,7 @@
 #define IRQF_NO_THREAD 0x0001
 #define IRQF_EARLY_RESUME  0x0002
 #define IRQF_COND_SUSPEND  0x0004
+#define IRQF_NO_AUTOEN 0x0008
 
 #define IRQF_TIMER (__IRQF_TIMER | IRQF_NO_SUSPEND | 
IRQF_NO_THREAD)
 
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index dec3f73..97c231a 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1693,7 +1693,8 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, 
struct irqaction *new)
irqd_set(&desc->irq_data, IRQD_NO_BALANCING);
}
 
-   if (irq_settings_can_autoenable(desc)) {
+   if (!(new->flags & IRQF_NO_AUTOEN) &&
+   irq_settings_can_autoenable(desc)) {
irq_startup(desc, IRQ_RESEND, IRQ_START_COND);
} else {
/*
@@ -2086,10 +2087,15 @@ int request_threaded_irq(unsigned int irq, 
irq_handler_t handler,
 * which interrupt is which (messes up the interrupt freeing
 * logic etc).
 *
+* Also shared interrupts do not go well with disabling auto enable.
+* The sharing interrupt might request it while it's still disabled
+* and then wait for interrupts forever.
+*
 * Also IRQF_COND_SUSPEND only makes sense for shared interrupts and
 * it cannot be set along with IRQF_NO_SUSPEND.
 */
if (((irqflags & IRQF_SHARED) && !dev_id) ||
+   ((irqflags & IRQF_SHARED) && (irqflags & IRQF_NO_AUTOEN)) ||
(!(irqflags & IRQF_SHARED) && (irqflags & IRQF_COND_SUSPEND)) ||
((irqflags & IRQF_NO_SUSPEND) && (irqflags & IRQF_COND_SUSPEND)))
return -EINVAL;
@@ -2245,7 +2251,8 @@ int request_nmi(unsigned int irq, irq_handler_t handler,
 
desc = irq_to_desc(irq);
 
-   if (!desc || irq_settings_can_autoenable(desc) ||
+   if (!desc || (irq_settings_can_autoenable(desc) &&
+   !(irqflags & IRQF_NO_AUTOEN)) ||
!irq_settings_can_request(desc) ||
WARN_ON(irq_settings_is_per_cpu_devid(desc)) ||
!irq_supports_nmi(desc))

[PATCH v1 1/1] pinctrl: intel: No need to disable IRQs in the handler

[Andy Shevchenko]

In IRQ handler interrupts are already disabled, hence no need
to repeat it. Even in the threaded case, which is disabled here,
it is not a problem because IRQ framework serializes descriptor
handling. Remove disabling IRQ part in the handler.

Signed-off-by: Andy Shevchenko 
---
 drivers/pinctrl/intel/pinctrl-intel.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/intel/pinctrl-intel.c 
b/drivers/pinctrl/intel/pinctrl-intel.c
index 93237d6e4316..268aaad3bb08 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -1173,16 +1173,15 @@ static int intel_gpio_community_irq_handler(struct 
intel_pinctrl *pctrl,
for (gpp = 0; gpp < community->ngpps; gpp++) {
const struct intel_padgroup *padgrp = &community->gpps[gpp];
unsigned long pending, enabled, gpp_offset;
-   unsigned long flags;
 
-   raw_spin_lock_irqsave(&pctrl->lock, flags);
+   raw_spin_lock(&pctrl->lock);
 
pending = readl(community->regs + community->is_offset +
padgrp->reg_num * 4);
enabled = readl(community->regs + community->ie_offset +
padgrp->reg_num * 4);
 
-   raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+   raw_spin_unlock(&pctrl->lock);
 
/* Only interrupts that are enabled */
pending &= enabled;
-- 
2.30.1

Re: [PATCH v2] mm/compaction: remove unused variable sysctl_compact_memory

[Vlastimil Babka]

On 3/4/21 11:03 AM, Pintu Kumar wrote:
> The sysctl_compact_memory is mostly unused in mm/compaction.c
> It just acts as a place holder for sysctl to store .data.
> 
> But the .data itself is not needed here.
> So we can get ride of this variable completely and make .data as NULL.
> This will also eliminate the extern declaration from header file.
> No functionality is broken or changed this way.
> 
> Signed-off-by: Pintu Kumar 
> Signed-off-by: Pintu Agarwal 

Reviewed-by: Vlastimil Babka 

> ---
> v2: completely get rid of this variable and set .data to NULL
> Suggested-by: Vlastimil Babka 
> 
>  include/linux/compaction.h | 1 -
>  kernel/sysctl.c| 2 +-
>  mm/compaction.c| 3 ---
>  3 files changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/include/linux/compaction.h b/include/linux/compaction.h
> index ed4070e..4221888 100644
> --- a/include/linux/compaction.h
> +++ b/include/linux/compaction.h
> @@ -81,7 +81,6 @@ static inline unsigned long compact_gap(unsigned int order)
>  }
>  
>  #ifdef CONFIG_COMPACTION
> -extern int sysctl_compact_memory;
>  extern unsigned int sysctl_compaction_proactiveness;
>  extern int sysctl_compaction_handler(struct ctl_table *table, int write,
>   void *buffer, size_t *length, loff_t *ppos);
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index c9fbdd8..07ef240 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -2856,7 +2856,7 @@ static struct ctl_table vm_table[] = {
>  #ifdef CONFIG_COMPACTION
>   {
>   .procname   = "compact_memory",
> - .data   = &sysctl_compact_memory,
> + .data   = NULL,
>   .maxlen = sizeof(int),
>   .mode   = 0200,
>   .proc_handler   = sysctl_compaction_handler,
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 190ccda..ede2886 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -2650,9 +2650,6 @@ static void compact_nodes(void)
>   compact_node(nid);
>  }
>  
> -/* The written value is actually unused, all memory is compacted */
> -int sysctl_compact_memory;
> -
>  /*
>   * Tunable for proactive compaction. It determines how
>   * aggressively the kernel should compact memory in the
> 

Re: [tip: irq/core] genirq: Add IRQF_NO_AUTOEN for request_irq/nmi()

[Thomas Gleixner]

Dmitry,

On Thu, Mar 04 2021 at 10:53, tip-bot wrote:

> The following commit has been merged into the irq/core branch of tip:
>
> Commit-ID: e749df1bbd23f4472082210650514548d8a39e9b
> Gitweb:
> https://git.kernel.org/tip/e749df1bbd23f4472082210650514548d8a39e9b
> Author:Barry Song 
> AuthorDate:Wed, 03 Mar 2021 11:49:15 +13:00
> Committer: Thomas Gleixner 
> CommitterDate: Thu, 04 Mar 2021 11:47:52 +01:00
>
> genirq: Add IRQF_NO_AUTOEN for request_irq/nmi()

this commit is immutable and I tagged it so you can pull it into your
tree to add the input changes on top:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
irq-no-autoen-2021-03-04

Thanks,

tglx

arch/mips/kernel/vpe-mt.c:178:7: warning: no previous prototype for 'vpe_alloc'

[kernel test robot]

Hi Bert,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f69d02e37a85645aa90d18cacfff36dba370f797
commit: 4042147a0cc6af5a400b5e12a7855e893dec01b4 MIPS: Add Realtek 
RTL838x/RTL839x support as generic MIPS system
date:   4 weeks ago
config: mips-randconfig-r024-20210304 (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4042147a0cc6af5a400b5e12a7855e893dec01b4
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 4042147a0cc6af5a400b5e12a7855e893dec01b4
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

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

All warnings (new ones prefixed by >>):

>> arch/mips/kernel/vpe-mt.c:178:7: warning: no previous prototype for 
>> 'vpe_alloc' [-Wmissing-prototypes]
 178 | void *vpe_alloc(void)
 |   ^
>> arch/mips/kernel/vpe-mt.c:196:5: warning: no previous prototype for 
>> 'vpe_start' [-Wmissing-prototypes]
 196 | int vpe_start(void *vpe, unsigned long start)
 | ^
>> arch/mips/kernel/vpe-mt.c:206:5: warning: no previous prototype for 
>> 'vpe_stop' [-Wmissing-prototypes]
 206 | int vpe_stop(void *vpe)
 | ^~~~
>> arch/mips/kernel/vpe-mt.c:227:5: warning: no previous prototype for 
>> 'vpe_free' [-Wmissing-prototypes]
 227 | int vpe_free(void *vpe)
 | ^~~~


vim +/vpe_alloc +178 arch/mips/kernel/vpe-mt.c

1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  175  
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  176  /* module wrapper entry points */
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  177  /* give me a vpe */
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30 @178  void *vpe_alloc(void)
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  179  {
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  180int i;
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  181struct vpe *v;
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  182  
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  183/* find a vpe */
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  184for (i = 1; i < MAX_VPES; i++) {
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  185v = get_vpe(i);
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  186if (v != NULL) {
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  187v->state = 
VPE_STATE_INUSE;
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  188return v;
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  189}
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  190}
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  191return NULL;
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  192  }
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  193  EXPORT_SYMBOL(vpe_alloc);
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  194  
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  195  /* start running from here */
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30 @196  int vpe_start(void *vpe, unsigned 
long start)
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  197  {
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  198struct vpe *v = vpe;
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  199  
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  200v->__start = start;
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  201return vpe_run(v);
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  202  }
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  203  EXPORT_SYMBOL(vpe_start);
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  204  
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  205  /* halt it for now */
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30 @206  int vpe_stop(void *vpe)
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  207  {
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  208struct vpe *v = vpe;
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  209struct tc *t;
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  210unsigned int evpe_flags;
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  211  
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  212evpe_flags = dvpe();
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  213  
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  214t = list_entry(v->tc.next, 
struct tc, tc);
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  215if (t != NULL) {
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  216settc(t->index);
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  217
write_vpe_c0_vpeconf0(read_vpe_c0_vpeconf0() & ~VPECONF0_VPA);
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  218}
1a2a6d7e8816ed Dengcheng Zhu 2013-10-30  219  
1a2a6d7e8816ed Dengcheng Zhu 2013-10

Re: [PATCH v1 2/2] gpio: aggregator: Replace custom get_arg() with a generic next_arg()

[Andy Shevchenko]

On Thu, Mar 04, 2021 at 10:01:46AM +0100, Geert Uytterhoeven wrote:
> Hi Andy,
> 
> On Mon, Mar 1, 2021 at 5:59 PM Andy Shevchenko
>  wrote:
> > cmdline library provides next_arg() helper to traverse over parameters
> > and their values given in command line. Replace custom approach in the 
> > driver
> > by it.
> >
> > Signed-off-by: Andy Shevchenko 
> 
> Thanks for your patch!
> 
> > --- a/drivers/gpio/gpio-aggregator.c
> > +++ b/drivers/gpio/gpio-aggregator.c
> > @@ -93,13 +68,9 @@ static int aggr_parse(struct gpio_aggregator *aggr)
> > if (!bitmap)
> > return -ENOMEM;
> >
> > -   for (name = get_arg(&args), offsets = get_arg(&args); name;
> > -offsets = get_arg(&args)) {
> > -   if (IS_ERR(name)) {
> > -   pr_err("Cannot get GPIO specifier: %pe\n", name);
> > -   error = PTR_ERR(name);
> > -   goto free_bitmap;
> > -   }
> > +   args = next_arg(args, &name, &p);
> > +   while (*args) {
> > +   args = next_arg(args, &offsets, &p);
> 
> As name and offsets should not contain equal signs (can they?),
> I guess using next_arg() is fine.

Even though we can use double quotes (AFAICU the next_arg() code).

> Reviewed-by: Geert Uytterhoeven 

Thanks!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5] kdb: Simplify kdb commands registration

[Sumit Garg]

Hi Doug,

On Tue, 2 Mar 2021 at 00:10, Doug Anderson  wrote:
>
> Hi,
>
> On Tue, Feb 23, 2021 at 11:08 PM Sumit Garg  wrote:
> >
> > Simplify kdb commands registration via using linked list instead of
> > static array for commands storage.
> >
> > Signed-off-by: Sumit Garg 
> > ---
> >
> > Changes in v5:
> > - Introduce new method: kdb_register_table() to register static kdb
> >   main and breakpoint command tables instead of using statically
> >   allocated commands.
> >
> > Changes in v4:
> > - Fix kdb commands memory allocation issue prior to slab being available
> >   with an array of statically allocated commands. Now it works fine with
> >   kgdbwait.
> > - Fix a misc checkpatch warning.
> > - I have dropped Doug's review tag as I think this version includes a
> >   major fix that should be reviewed again.
> >
> > Changes in v3:
> > - Remove redundant "if" check.
> > - Pick up review tag from Doug.
> >
> > Changes in v2:
> > - Remove redundant NULL check for "cmd_name".
> > - Incorporate misc. comment.
> >
> >  kernel/debug/kdb/kdb_bp.c  |  81 --
> >  kernel/debug/kdb/kdb_main.c| 472 -
> >  kernel/debug/kdb/kdb_private.h |   3 +
> >  3 files changed, 343 insertions(+), 213 deletions(-)
>
> This looks good to me, thanks!
>
> Random notes:
>
> * We no longer check for "duplicate" commands for any of these
> statically allocated ones, but I guess that's fine.

Yeah, I think that check is redundant for static ones.

>
> * Presumably nothing outside of kdb/kgdb itself needs the ability to
> allocate commands statically.  The only user I see now is ftrace and
> it looks like it runs late enough that it should be fine.

Agree.

>
> Reviewed-by: Douglas Anderson 
>

Thanks,
-Sumit

>
> -Doug

[PATCH 3/7] hwmon: (max31790) Allow setting pulses

[Václav Kubernát]

In the old code, the value calculated RPM_FROM_REG is misleading. The
left-hand side of the division is correct (as per the datasheet, page
11). The misleading part is the right-hand side: the datasheet says it
is should be "number of pulses * TACH count". The TACH count is the
value of the register which is a 11-bit left-justified value. This means
that the register value should be shifted by 5 if we want the actual
value. However, in the old code, the value is shifted by 4 with no way
to set the pulses per revolution. This essentially means, that the
default pulses per revolution is 2, because shifting the right-hand side
one less bit means that the final value is doubled by 2. In the end,
what happens is, that the old code works as if fan*_pulses had the
default value of 2 all the time. This is somewhat correct, but in my
opinion the intention isn't entirely clear, at first glance, shifting by
4 instead of 5 seems like a bug (after one checks the datasheet).

Pulses per revolution should be a configurable because otherwise there's
no way to correctly calculate the RPM of the fan. This patch adds the
option to set pulses per revolution.

The hwmon documentation for fan*_pulses says that it shouldn't be
present unless the chip has a register to save this value. This seems
non-sensical, because setting the pulses is essential to properly
calculate RPM. The value is saved inside the driver's data structure.

Signed-off-by: Václav Kubernát 
---
 Documentation/hwmon/max31790.rst |  1 +
 drivers/hwmon/max31790.c | 57 +---
 2 files changed, 39 insertions(+), 19 deletions(-)

diff --git a/Documentation/hwmon/max31790.rst b/Documentation/hwmon/max31790.rst
index 8979c8a02cd1..8d86698b25de 100644
--- a/Documentation/hwmon/max31790.rst
+++ b/Documentation/hwmon/max31790.rst
@@ -36,6 +36,7 @@ Sysfs entries
 
 == === 
=
 fan[1-12]_enable   RW  enable fan speed monitoring
+fan[1-12]_pulses   RW  pulses per fan revolution (default: 2)
 fan[1-12]_inputRO  fan tachometer speed in RPM
 fan[1-12]_faultRO  fan experienced fault
 fan[1-6]_targetRW  desired fan speed in RPM
diff --git a/drivers/hwmon/max31790.c b/drivers/hwmon/max31790.c
index eca5ec615734..74a81e5e3383 100644
--- a/drivers/hwmon/max31790.c
+++ b/drivers/hwmon/max31790.c
@@ -41,10 +41,12 @@
 #define FAN_RPM_MAX7864320
 #define MAX_PWM0XFF80
 
-#define RPM_FROM_REG(reg, sr)  (((reg) >> 4) ? \
-((60 * (sr) * 8192) / ((reg) >> 4)) : \
-FAN_RPM_MAX)
-#define RPM_TO_REG(rpm, sr)((60 * (sr) * 8192) / ((rpm) * 2))
+#define RPM_FROM_REG(reg, sr, pulses) \
+   (((reg) >> 5) ? \
+((60 * (sr) * 8192) / ((reg) >> 5) / (pulses)) : \
+FAN_RPM_MAX)
+#define RPM_TO_REG(rpm, sr, pulses) \
+   ((60 * (sr) * 8192) / ((rpm) * (pulses)))
 
 #define NR_CHANNEL 6
 
@@ -81,6 +83,7 @@ struct max31790_data {
bool valid; /* zero until following fields are valid */
unsigned long last_updated; /* in jiffies */
bool full_speed[NR_CHANNEL];
+   u8 pulses[NR_CHANNEL];
 
/* register values */
u8 fan_config[NR_CHANNEL];
@@ -217,12 +220,16 @@ static int max31790_read_fan(struct device *dev, u32 
attr, int channel,
switch (attr) {
case hwmon_fan_input:
sr = get_tach_period(data->fan_dynamics[channel]);
-   rpm = RPM_FROM_REG(data->tach[channel], sr);
+   rpm = RPM_FROM_REG(data->tach[channel],
+  sr,
+  data->pulses[channel]);
*val = rpm;
return 0;
case hwmon_fan_target:
sr = get_tach_period(data->fan_dynamics[channel]);
-   rpm = RPM_FROM_REG(data->target_count[channel], sr);
+   rpm = RPM_FROM_REG(data->target_count[channel],
+  sr,
+  data->pulses[channel]);
*val = rpm;
return 0;
case hwmon_fan_fault:
@@ -231,6 +238,9 @@ static int max31790_read_fan(struct device *dev, u32 attr, 
int channel,
case hwmon_fan_enable:
*val = !!(data->fan_config[channel] & 
MAX31790_FAN_CFG_TACH_INPUT_EN);
return 0;
+   case hwmon_fan_pulses:
+   *val = data->pulses[channel];
+   return 0;
default:
return -EOPNOTSUPP;
}
@@ -264,7 +274,7 @@ static int max31790_write_fan(struct device *dev, u32 attr, 
int channel,
break;
 
sr = get_tach_period(data->fan_dynamics[channel]);
-   target_count = RPM_TO_REG(val, sr);
+   target_count = RPM_TO_REG(val, sr, data->pulses[channel]);
target_c

[PATCH 6/7] hwmon: (max31790) Allow setting fan*_div

[Václav Kubernát]

Right now, the divisor (which determines the speed range) is only set
when in RPM mode. However, the speed range also affects the input RPM,
which means, to get more accurate readings, this speed range needs to be
set.

Signed-off-by: Václav Kubernát 
---
 Documentation/hwmon/max31790.rst |  1 +
 drivers/hwmon/max31790.c | 46 +++-
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/Documentation/hwmon/max31790.rst b/Documentation/hwmon/max31790.rst
index 8d86698b25de..627816fa45fb 100644
--- a/Documentation/hwmon/max31790.rst
+++ b/Documentation/hwmon/max31790.rst
@@ -39,6 +39,7 @@ fan[1-12]_enable   RW  enable fan speed monitoring
 fan[1-12]_pulses   RW  pulses per fan revolution (default: 2)
 fan[1-12]_inputRO  fan tachometer speed in RPM
 fan[1-12]_faultRO  fan experienced fault
+fan[1-12]_div  RW  set the measurable speed range, not available in RPM 
mode
 fan[1-6]_targetRW  desired fan speed in RPM
 pwm[1-6]_enableRW  regulator mode, 0=full speed, 1=manual (pwm) mode, 
2=rpm mode
setting rpm mode sets fan*_enable to 1
diff --git a/drivers/hwmon/max31790.c b/drivers/hwmon/max31790.c
index d4f259dd4e19..12eab8817c8a 100644
--- a/drivers/hwmon/max31790.c
+++ b/drivers/hwmon/max31790.c
@@ -57,7 +57,8 @@
 #define U16_LSB(num)   ((num) & 0x00FF)
 
 #define FAN_INFO_1_TO_6 \
-   (HWMON_F_PULSES | \
+   (HWMON_F_DIV | \
+   HWMON_F_PULSES | \
HWMON_F_ENABLE | \
HWMON_F_INPUT | \
HWMON_F_TARGET | \
@@ -221,6 +222,26 @@ static u8 bits_for_tach_period(int rpm)
return bits;
 }
 
+static int bits_for_speed_range(int speed_range)
+{
+   switch (speed_range) {
+   case 1:
+   return 0x0;
+   case 2:
+   return 0x1;
+   case 4:
+   return 0x2;
+   case 8:
+   return 0x3;
+   case 16:
+   return 0x4;
+   case 32:
+   return 0x5;
+   default:
+   return -1;
+   }
+}
+
 static int max31790_read_fan(struct device *dev, u32 attr, int channel,
 long *val)
 {
@@ -264,6 +285,9 @@ static int max31790_read_fan(struct device *dev, u32 attr, 
int channel,
case hwmon_fan_pulses:
*val = data->pulses[channel];
return 0;
+   case hwmon_fan_div:
+   *val = get_tach_period(data->fan_config[channel]);
+   return 0;
default:
return -EOPNOTSUPP;
}
@@ -321,6 +345,25 @@ static int max31790_write_fan(struct device *dev, u32 
attr, int channel,
case hwmon_fan_pulses:
data->pulses[channel] = val;
break;
+   case hwmon_fan_div:
+   if (data->fan_config[channel] & MAX31790_FAN_CFG_RPM_MODE) {
+   err = -EINVAL;
+   break;
+   }
+   sr = bits_for_speed_range(val);
+   if (sr < 0) {
+   err = -EINVAL;
+   break;
+   }
+
+   data->fan_dynamics[channel] =
+   ((data->fan_dynamics[channel] &
+ ~MAX31790_FAN_DYN_SR_MASK) |
+(sr << MAX31790_FAN_DYN_SR_SHIFT));
+   err = regmap_write(regmap,
+  MAX31790_REG_FAN_DYNAMICS(channel),
+  data->fan_dynamics[channel]);
+   break;
default:
err = -EOPNOTSUPP;
break;
@@ -353,6 +396,7 @@ static umode_t max31790_fan_is_visible(const void *_data, 
u32 attr, int channel)
(fan_config & MAX31790_FAN_CFG_TACH_INPUT))
return 0644;
return 0;
+   case hwmon_fan_div:
case hwmon_fan_pulses:
if (channel < NR_CHANNEL)
return 0644;
-- 
2.30.1

[GIT PULL] xen: branch for v5.12-rc2

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-5.12b-rc2-tag

xen: branch for v5.12-rc2

It contains fixes for 2 security issues (XSA-367 and XSA-369).


Thanks.

Juergen

 arch/arm/xen/p2m.c| 35 ++---
 arch/x86/include/asm/xen/page.h   | 12 +
 arch/x86/xen/p2m.c| 54 ++-
 arch/x86/xen/setup.c  | 25 +++---
 drivers/net/xen-netback/netback.c | 12 -
 5 files changed, 104 insertions(+), 34 deletions(-)

Jan Beulich (2):
  Xen/gnttab: handle p2m update errors on a per-slot basis
  xen-netback: respect gnttab_map_refs()'s return value

Juergen Gross (1):
  xen: fix p2m size in dom0 for disabled memory hotplug case

[PATCH 7/7] hwmon: (max31790) Update documentation

[Václav Kubernát]

The conditions for fan fault and its connection to the PWM mode are now
documented.

The pwm_rate_of_change and fan_window are now mentioned. According to
our testing with Sunon PF36281BX-000U-S99, these values are crucial in
how RPM mode works and how long it takes for the RPM to stabilize. For
example, setting 5000 RPM (the fan goes up to 23000), the
pwm_rate_of_change needed to be changed to the lowest possible value,
otherwise the chip would just go from pwm 0 to pwm 60 back and forth and
never achieving 5000 RPM (and also signaling fan fault). Based on this
testing, we found out that it the pwm_rate_of_change and fan_window
values need to be changed manually by the user, based on the user's
exact fan configuration.

Signed-off-by: Václav Kubernát 
---
 Documentation/hwmon/max31790.rst | 48 +++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/Documentation/hwmon/max31790.rst b/Documentation/hwmon/max31790.rst
index 627816fa45fb..d5ab7caa491a 100644
--- a/Documentation/hwmon/max31790.rst
+++ b/Documentation/hwmon/max31790.rst
@@ -30,6 +30,51 @@ monitoring and control of fan RPM as well as detection of 
fan failure.
 Six pins are dedicated tachometer inputs. Any of the six PWM outputs can
 also be configured to serve as tachometer inputs.
 
+About pwm[1-6]_enable
+-
+full-speed
+- The chip doesn't have a specific way to set "full speed", so setting 
pwm[1-6]_enable to 0 is just "set PWM mode with 255 duty cycle".
+
+PWM mode
+- Fan speed is controlled by writing a value to pwm[1-6].
+
+RPM mode
+- Fan speed is controlled by writing a value to fan[1-6]_target.
+
+About fan[1-6]_fault
+
+In PWM (or full-speed) mode, if the input RPM goes below what is set
+in fan[1-6]_target, fan[1-6]_fault gets set to 1. In other words,
+fan[1-6]_target works as the minimum input RPM before a fan fault goes off.
+
+In RPM mode, fan fault is set when the fan spins "too slowly" (exact
+conditions are in the datasheet). RPM mode depends on four variables:
+
+- target_speed:This is set by fan[1-6]_target.
+- speed_range: This is set automatically when setting target_speed or 
manually by fan[1-12]_div.
+- pwm_rate_of_change:  NOT set by the driver.
+- fan_window:  NOT set by the driver.
+
+The last two values are not set by the driver, because there's no generic way 
to
+compute them. You should set them manually through i2c (in the bootloader for
+example). Check the datasheet for details. The driver uses `regmap`, so it
+should be easy to read the values of the registers from userspace.
+
+The fan fault value latches. To reset it, set a value to pwm[1-6]
+or fan[1-6]_target.
+
+About fan[1-12]_pulses
+--
+You should set this depending on the fan you use. It affects what values
+are in fan[1-12]_input and also what gets written to fan[1-6]_target.
+
+About fan[1-12]_div
+---
+This value affects the measurable range of the chip. The driver sets this value
+automatically in RPM based on fan[1-6]_target. In PWM mode, you should set this
+value manually based on the details from the datasheet. Setting the speed range
+is disabled while in RPM mode to prevent overwriting the automatically
+calculated value.
 
 Sysfs entries
 -
@@ -40,7 +85,8 @@ fan[1-12]_pulses   RW  pulses per fan revolution (default: 2)
 fan[1-12]_inputRO  fan tachometer speed in RPM
 fan[1-12]_faultRO  fan experienced fault
 fan[1-12]_div  RW  set the measurable speed range, not available in RPM 
mode
-fan[1-6]_targetRW  desired fan speed in RPM
+fan[1-6]_targetRW  RPM mode = desired fan speed,
+   PWM mode = minimum fan speed until fault
 pwm[1-6]_enableRW  regulator mode, 0=full speed, 1=manual (pwm) mode, 
2=rpm mode
setting rpm mode sets fan*_enable to 1
 pwm[1-6]   RW  fan target duty cycle (0-255)
-- 
2.30.1

[PATCH 2/7] hwmon: (max31790) Fix and split pwm*_enable

[Václav Kubernát]

In the old code, pwm*_enable does two things. Firstly, it sets whether
the chip should run in PWM or RPM mode. Secondly, it tells the chip
whether it should monitor fan RPM. However, these two settings aren't
tied together, so they shouldn't be set with a single value. In the new
code, fan*_enable now controls fan RPM monitoring (pwm*_enable no longer
controls that).

According to the sysfs hwmon documentation, pwm*_enable has three
possible values, 0 for "no control / full-speed", 1 for manual mode, and
2+ for automatic. The old code works fine for 1 and 2, but 0 only
differs from 1 in that it just turns off fan speed monitoring. The chip
actually does have a way to turn off fan controls (and only monitor),
but what that does is that it sets PWM to 0% duty cycle (which is the
opposite to full-speed) AND it also turns off fan speed monitoring.
Because of this, I implemented the 0 value by setting PWM mode to 100%.
This method does come with a problem: it is impossible to differentiate
between full-speed and PWM mode just from the values on the chip. The
new code solves this by saving a value indicating whether we're in
full-speed mode. This value is initialized to 0, so full-speed mode
won't persist across reboots.

These two changes are closely connected together, mainly because the
detection of the pwm*_enable value depended on whether fan speed
monitoring is enabled (which is now controlled as written in the first
paragraph).

Signed-off-by: Václav Kubernát 
---
 Documentation/hwmon/max31790.rst |   8 ++-
 drivers/hwmon/max31790.c | 107 ++-
 2 files changed, 80 insertions(+), 35 deletions(-)

diff --git a/Documentation/hwmon/max31790.rst b/Documentation/hwmon/max31790.rst
index f301385d8cef..8979c8a02cd1 100644
--- a/Documentation/hwmon/max31790.rst
+++ b/Documentation/hwmon/max31790.rst
@@ -34,10 +34,12 @@ also be configured to serve as tachometer inputs.
 Sysfs entries
 -
 
-== === ===
+== === 
=
+fan[1-12]_enable   RW  enable fan speed monitoring
 fan[1-12]_inputRO  fan tachometer speed in RPM
 fan[1-12]_faultRO  fan experienced fault
 fan[1-6]_targetRW  desired fan speed in RPM
-pwm[1-6]_enableRW  regulator mode, 0=disabled, 1=manual mode, 2=rpm mode
+pwm[1-6]_enableRW  regulator mode, 0=full speed, 1=manual (pwm) mode, 
2=rpm mode
+   setting rpm mode sets fan*_enable to 1
 pwm[1-6]   RW  fan target duty cycle (0-255)
-== === ===
+== === 
=
diff --git a/drivers/hwmon/max31790.c b/drivers/hwmon/max31790.c
index ca413985b5f9..eca5ec615734 100644
--- a/drivers/hwmon/max31790.c
+++ b/drivers/hwmon/max31790.c
@@ -39,6 +39,7 @@
 
 #define FAN_RPM_MIN120
 #define FAN_RPM_MAX7864320
+#define MAX_PWM0XFF80
 
 #define RPM_FROM_REG(reg, sr)  (((reg) >> 4) ? \
 ((60 * (sr) * 8192) / ((reg) >> 4)) : \
@@ -79,6 +80,7 @@ struct max31790_data {
struct mutex update_lock;
bool valid; /* zero until following fields are valid */
unsigned long last_updated; /* in jiffies */
+   bool full_speed[NR_CHANNEL];
 
/* register values */
u8 fan_config[NR_CHANNEL];
@@ -226,6 +228,9 @@ static int max31790_read_fan(struct device *dev, u32 attr, 
int channel,
case hwmon_fan_fault:
*val = !!(data->fault_status & (1 << channel));
return 0;
+   case hwmon_fan_enable:
+   *val = !!(data->fan_config[channel] & 
MAX31790_FAN_CFG_TACH_INPUT_EN);
+   return 0;
default:
return -EOPNOTSUPP;
}
@@ -271,6 +276,15 @@ static int max31790_write_fan(struct device *dev, u32 
attr, int channel,
bulk_val,
2);
break;
+   case hwmon_fan_enable:
+   if (val == 0)
+   data->fan_config[channel] &= 
~MAX31790_FAN_CFG_TACH_INPUT_EN;
+   else
+   data->fan_config[channel] |= 
MAX31790_FAN_CFG_TACH_INPUT_EN;
+   err = regmap_write(regmap,
+  MAX31790_REG_FAN_CONFIG(channel),
+  data->fan_config[channel]);
+   break;
default:
err = -EOPNOTSUPP;
break;
@@ -298,6 +312,11 @@ static umode_t max31790_fan_is_visible(const void *_data, 
u32 attr, int channel)
!(fan_config & MAX31790_FAN_CFG_TACH_INPUT))
return 0644;
return 0;
+   case hwmon_fan_enable:
+   if (channel < 

Linux 5.4.102

[Greg Kroah-Hartman]

I'm announcing the release of the 5.4.102 kernel.

All users of the 5.4 kernel series must upgrade.

The updated 5.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-5.4.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/filesystems/seq_file.txt   |6 
 Makefile |2 
 arch/arm/boot/compressed/head.S  |4 
 arch/arm/boot/dts/armada-388-helios4.dts |   28 
 arch/arm/boot/dts/aspeed-g4.dtsi |1 
 arch/arm/boot/dts/aspeed-g5.dtsi |1 
 arch/arm/boot/dts/exynos3250-artik5.dtsi |2 
 arch/arm/boot/dts/exynos3250-monk.dts|2 
 arch/arm/boot/dts/exynos3250-rinato.dts  |2 
 arch/arm/boot/dts/exynos5250-spring.dts  |2 
 arch/arm/boot/dts/exynos5420-arndale-octa.dts|2 
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi|2 
 arch/arm/boot/dts/omap443x.dtsi  |2 
 arch/arm/mach-ixp4xx/Kconfig |1 
 arch/arm64/Kconfig   |2 
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts|5 
 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi |1 
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi|6 
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi |7 
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi|2 
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts  |2 
 arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts   |2 
 arch/arm64/boot/dts/mediatek/mt7622.dtsi |2 
 arch/arm64/boot/dts/qcom/msm8916.dtsi|4 
 arch/arm64/crypto/aes-glue.c |4 
 arch/arm64/crypto/sha1-ce-glue.c |1 
 arch/arm64/crypto/sha2-ce-glue.c |2 
 arch/arm64/crypto/sha3-ce-glue.c |4 
 arch/arm64/crypto/sha512-ce-glue.c   |2 
 arch/arm64/kernel/cpufeature.c   |2 
 arch/arm64/kernel/head.S |1 
 arch/arm64/kernel/machine_kexec_file.c   |4 
 arch/arm64/kernel/probes/uprobes.c   |2 
 arch/mips/include/asm/asm.h  |   18 
 arch/mips/kernel/vmlinux.lds.S   |2 
 arch/mips/lantiq/irq.c   |2 
 arch/mips/mm/c-r4k.c |2 
 arch/powerpc/Kconfig |2 
 arch/powerpc/kernel/entry_32.S   |3 
 arch/powerpc/kernel/head_8xx.S   |2 
 arch/powerpc/kernel/prom_init.c  |   12 
 arch/powerpc/kvm/powerpc.c   |8 
 arch/powerpc/platforms/pseries/dlpar.c   |7 
 arch/s390/kernel/vtime.c |3 
 arch/sparc/Kconfig   |2 
 arch/sparc/lib/memset.S  |1 
 arch/um/kernel/tlb.c |   12 
 arch/x86/crypto/aesni-intel_glue.c   |   28 
 arch/x86/include/asm/virtext.h   |   17 
 arch/x86/kernel/reboot.c |   29 
 arch/x86/kvm/svm.c   |2 
 arch/x86/kvm/vmx/vmx.c   |2 
 arch/x86/kvm/x86.c   |   38 
 arch/x86/kvm/x86.h   |2 
 arch/x86/mm/pat.c|3 
 block/bfq-iosched.c  |1 
 block/blk-settings.c |   12 
 block/bsg.c  |4 
 certs/blacklist.c|2 
 crypto/ecdh_helper.c |3 
 drivers/acpi/acpi_configfs.c |7 
 drivers/acpi/property.c  |   44 
 drivers/amba/bus.c   |   20 
 drivers/ata/ahci_brcm.c  |   14 
 drivers/auxdisplay/ht16k33.c |3 
 drivers/base/regmap/regmap-sdw.

[PATCH 2/2] MIPS: Loongson64: Move loongson_system_configuration to loongson.h

[Qing Zhang]

The purpose of separating loongson_system_configuration from boot_param.h
is to keep the other structure consistent with the firmware.

Signed-off-by: Jiaxun Yang 
Signed-off-by: Qing Zhang 
---
 .../include/asm/mach-loongson64/boot_param.h   | 18 --
 .../include/asm/mach-loongson64/loongson.h | 18 ++
 drivers/irqchip/irq-loongson-liointc.c |  2 +-
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h 
b/arch/mips/include/asm/mach-loongson64/boot_param.h
index 1c1cdf57137e..035b1a69e2d0 100644
--- a/arch/mips/include/asm/mach-loongson64/boot_param.h
+++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
@@ -198,24 +198,6 @@ enum loongson_bridge_type {
VIRTUAL = 3
 };
 
-struct loongson_system_configuration {
-   u32 nr_cpus;
-   u32 nr_nodes;
-   int cores_per_node;
-   int cores_per_package;
-   u16 boot_cpu_id;
-   u16 reserved_cpus_mask;
-   enum loongson_cpu_type cputype;
-   enum loongson_bridge_type bridgetype;
-   u64 restart_addr;
-   u64 poweroff_addr;
-   u64 suspend_addr;
-   u64 vgabios_addr;
-   u32 dma_mask_bits;
-   u64 workarounds;
-   void (*early_config)(void);
-};
-
 extern struct efi_memory_map_loongson *loongson_memmap;
 extern struct loongson_system_configuration loongson_sysconf;
 
diff --git a/arch/mips/include/asm/mach-loongson64/loongson.h 
b/arch/mips/include/asm/mach-loongson64/loongson.h
index ac1c20e172a2..6189deb188cf 100644
--- a/arch/mips/include/asm/mach-loongson64/loongson.h
+++ b/arch/mips/include/asm/mach-loongson64/loongson.h
@@ -12,6 +12,24 @@
 #include 
 #include 
 
+/* machine-specific boot configuration */
+struct loongson_system_configuration {
+   u32 nr_cpus;
+   u32 nr_nodes;
+   int cores_per_node;
+   int cores_per_package;
+   u16 boot_cpu_id;
+   u16 reserved_cpus_mask;
+   enum loongson_cpu_type cputype;
+   enum loongson_bridge_type bridgetype;
+   u64 restart_addr;
+   u64 poweroff_addr;
+   u64 suspend_addr;
+   u64 vgabios_addr;
+   u32 dma_mask_bits;
+   u64 workarounds;
+   void (*early_config)(void);
+};
 
 /* machine-specific reboot/halt operation */
 extern void mach_prepare_reboot(void);
diff --git a/drivers/irqchip/irq-loongson-liointc.c 
b/drivers/irqchip/irq-loongson-liointc.c
index 09b91b81851c..249566a23cc4 100644
--- a/drivers/irqchip/irq-loongson-liointc.c
+++ b/drivers/irqchip/irq-loongson-liointc.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #define LIOINTC_CHIP_IRQ   32
 #define LIOINTC_NUM_PARENT 4
-- 
2.20.1

[PATCH 0/2] some cleanup code

[Qing Zhang]

These patches clean up some code about Loongson64.

Qing Zhang (2):
  MIPS: Loongson64: Remove unused sysconf members
  MIPS: Loongson64: Move loongson_system_configuration to loongson.h

 .../include/asm/mach-loongson64/boot_param.h  | 27 
 .../include/asm/mach-loongson64/loongson.h| 18 
 arch/mips/loongson64/Makefile |  2 +-
 arch/mips/loongson64/env.c| 20 -
 arch/mips/loongson64/platform.c   | 42 ---
 drivers/irqchip/irq-loongson-liointc.c|  2 +-
 6 files changed, 20 insertions(+), 91 deletions(-)
 delete mode 100644 arch/mips/loongson64/platform.c

-- 
2.20.1

[PATCH 4/7] hwmon: (max31790) Show 0 RPM/fault when input disabled

[Václav Kubernát]

When fan speed input is disabled, it makes no sense to show values in
fan*_input and fan*_fault.

Signed-off-by: Václav Kubernát 
---
 drivers/hwmon/max31790.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/hwmon/max31790.c b/drivers/hwmon/max31790.c
index 74a81e5e3383..fde08c95d942 100644
--- a/drivers/hwmon/max31790.c
+++ b/drivers/hwmon/max31790.c
@@ -219,6 +219,11 @@ static int max31790_read_fan(struct device *dev, u32 attr, 
int channel,
 
switch (attr) {
case hwmon_fan_input:
+   if (!(data->fan_config[channel] &
+ MAX31790_FAN_CFG_TACH_INPUT_EN)) {
+   *val = 0;
+   return 0;
+   }
sr = get_tach_period(data->fan_dynamics[channel]);
rpm = RPM_FROM_REG(data->tach[channel],
   sr,
@@ -233,6 +238,11 @@ static int max31790_read_fan(struct device *dev, u32 attr, 
int channel,
*val = rpm;
return 0;
case hwmon_fan_fault:
+   if (!(data->fan_config[channel] &
+ MAX31790_FAN_CFG_TACH_INPUT_EN)) {
+   *val = 0;
+   return 0;
+   }
*val = !!(data->fault_status & (1 << channel));
return 0;
case hwmon_fan_enable:
-- 
2.30.1

[PATCH 1/2] MIPS: Loongson64: Remove unused sysconf members

[Qing Zhang]

We don't need them anymore, They are uniform on all Loongson64 systems
and have been fixed in DeviceTree.loongson3_platform_init is replaced
with DTS + driver.

Signed-off-by: Jiaxun Yang 
Signed-off-by: Qing Zhang 
---
 .../include/asm/mach-loongson64/boot_param.h  |  9 
 arch/mips/loongson64/Makefile |  2 +-
 arch/mips/loongson64/env.c| 20 -
 arch/mips/loongson64/platform.c   | 42 ---
 4 files changed, 1 insertion(+), 72 deletions(-)
 delete mode 100644 arch/mips/loongson64/platform.c

diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h 
b/arch/mips/include/asm/mach-loongson64/boot_param.h
index 4592841b6b0c..1c1cdf57137e 100644
--- a/arch/mips/include/asm/mach-loongson64/boot_param.h
+++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
@@ -207,20 +207,11 @@ struct loongson_system_configuration {
u16 reserved_cpus_mask;
enum loongson_cpu_type cputype;
enum loongson_bridge_type bridgetype;
-   u64 ht_control_base;
-   u64 pci_mem_start_addr;
-   u64 pci_mem_end_addr;
-   u64 pci_io_base;
u64 restart_addr;
u64 poweroff_addr;
u64 suspend_addr;
u64 vgabios_addr;
u32 dma_mask_bits;
-   char ecname[32];
-   u32 nr_uarts;
-   struct uart_device uarts[MAX_UARTS];
-   u32 nr_sensors;
-   struct sensor_device sensors[MAX_SENSORS];
u64 workarounds;
void (*early_config)(void);
 };
diff --git a/arch/mips/loongson64/Makefile b/arch/mips/loongson64/Makefile
index cc76944b1a9d..e806280bbb85 100644
--- a/arch/mips/loongson64/Makefile
+++ b/arch/mips/loongson64/Makefile
@@ -2,7 +2,7 @@
 #
 # Makefile for Loongson-3 family machines
 #
-obj-$(CONFIG_MACH_LOONGSON64) += cop2-ex.o platform.o dma.o \
+obj-$(CONFIG_MACH_LOONGSON64) += cop2-ex.o dma.o \
setup.o init.o env.o time.o reset.o \
 
 obj-$(CONFIG_SMP)  += smp.o
diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
index 51a5d050a94c..1821d461b606 100644
--- a/arch/mips/loongson64/env.c
+++ b/arch/mips/loongson64/env.c
@@ -95,7 +95,6 @@ void __init prom_init_env(void)
loongson_freqctrl[1] = 0x900010001fe001d0;
loongson_freqctrl[2] = 0x900020001fe001d0;
loongson_freqctrl[3] = 0x900030001fe001d0;
-   loongson_sysconf.ht_control_base = 0x9EFDFB00;
loongson_sysconf.workarounds = WORKAROUND_CPUFREQ;
break;
case Legacy_3B:
@@ -118,7 +117,6 @@ void __init prom_init_env(void)
loongson_freqctrl[1] = 0x900020001fe001d0;
loongson_freqctrl[2] = 0x900040001fe001d0;
loongson_freqctrl[3] = 0x900060001fe001d0;
-   loongson_sysconf.ht_control_base = 0x90001EFDFB00;
loongson_sysconf.workarounds = WORKAROUND_CPUHOTPLUG;
break;
default:
@@ -136,9 +134,6 @@ void __init prom_init_env(void)
loongson_sysconf.cores_per_node - 1) /
loongson_sysconf.cores_per_node;
 
-   loongson_sysconf.pci_mem_start_addr = eirq_source->pci_mem_start_addr;
-   loongson_sysconf.pci_mem_end_addr = eirq_source->pci_mem_end_addr;
-   loongson_sysconf.pci_io_base = eirq_source->pci_io_start_addr;
loongson_sysconf.dma_mask_bits = eirq_source->dma_mask_bits;
if (loongson_sysconf.dma_mask_bits < 32 ||
loongson_sysconf.dma_mask_bits > 64)
@@ -153,23 +148,8 @@ void __init prom_init_env(void)
loongson_sysconf.poweroff_addr, loongson_sysconf.restart_addr,
loongson_sysconf.vgabios_addr);
 
-   memset(loongson_sysconf.ecname, 0, 32);
-   if (esys->has_ec)
-   memcpy(loongson_sysconf.ecname, esys->ec_name, 32);
loongson_sysconf.workarounds |= esys->workarounds;
 
-   loongson_sysconf.nr_uarts = esys->nr_uarts;
-   if (esys->nr_uarts < 1 || esys->nr_uarts > MAX_UARTS)
-   loongson_sysconf.nr_uarts = 1;
-   memcpy(loongson_sysconf.uarts, esys->uarts,
-   sizeof(struct uart_device) * loongson_sysconf.nr_uarts);
-
-   loongson_sysconf.nr_sensors = esys->nr_sensors;
-   if (loongson_sysconf.nr_sensors > MAX_SENSORS)
-   loongson_sysconf.nr_sensors = 0;
-   if (loongson_sysconf.nr_sensors)
-   memcpy(loongson_sysconf.sensors, esys->sensors,
-   sizeof(struct sensor_device) * 
loongson_sysconf.nr_sensors);
pr_info("CpuClock = %u\n", cpu_clock_freq);
 
/* Read the ID of PCI host bridge to detect bridge type */
diff --git a/arch/mips/loongson64/platform.c b/arch/mips/loongson64/platform.c
deleted file mode 100644
index 9674ae1361a8..
--- a/arch/mips/loongson64/platform.c
+++ /dev/null
@@ -1,42 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Copyright (C) 2009 Lemote Inc.
- * Author: Wu Zhangjin, wuzhang...@gm

[PATCH 1/7] hwmon: (max31790) Rework to use regmap

[Václav Kubernát]

Converting the driver to use regmap makes it more generic. It also makes
it a lot easier to debug through debugfs.

Signed-off-by: Václav Kubernát 
---
 drivers/hwmon/Kconfig|   1 +
 drivers/hwmon/max31790.c | 148 +++
 2 files changed, 105 insertions(+), 44 deletions(-)

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 54f04e61fb83..c2ec57672c4e 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1092,6 +1092,7 @@ config SENSORS_MAX6697
 config SENSORS_MAX31790
tristate "Maxim MAX31790 sensor chip"
depends on I2C
+   select REGMAP_I2C
help
  If you say yes here you get support for 6-Channel PWM-Output
  Fan RPM Controller.
diff --git a/drivers/hwmon/max31790.c b/drivers/hwmon/max31790.c
index 86e6c71db685..ca413985b5f9 100644
--- a/drivers/hwmon/max31790.c
+++ b/drivers/hwmon/max31790.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* MAX31790 registers */
@@ -46,11 +47,35 @@
 
 #define NR_CHANNEL 6
 
+#define MAX31790_REG_USER_BYTE_67  0x67
+
+#define BULK_TO_U16(msb, lsb)  (((msb) << 8) + (lsb))
+#define U16_MSB(num)   (((num) & 0xFF00) >> 8)
+#define U16_LSB(num)   ((num) & 0x00FF)
+
+static const struct regmap_range max31790_ro_range = {
+   .range_min = MAX31790_REG_TACH_COUNT(0),
+   .range_max = MAX31790_REG_PWMOUT(0) - 1,
+};
+
+static const struct regmap_access_table max31790_wr_table = {
+   .no_ranges = &max31790_ro_range,
+   .n_no_ranges = 1,
+};
+
+static const struct regmap_config max31790_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .reg_stride = 1,
+   .max_register = MAX31790_REG_USER_BYTE_67,
+   .wr_table = &max31790_wr_table,
+};
+
 /*
  * Client data (each client gets its own)
  */
 struct max31790_data {
-   struct i2c_client *client;
+   struct regmap *regmap;
struct mutex update_lock;
bool valid; /* zero until following fields are valid */
unsigned long last_updated; /* in jiffies */
@@ -67,53 +92,72 @@ struct max31790_data {
 static struct max31790_data *max31790_update_device(struct device *dev)
 {
struct max31790_data *data = dev_get_drvdata(dev);
-   struct i2c_client *client = data->client;
+   struct regmap *regmap = data->regmap;
struct max31790_data *ret = data;
int i;
int rv;
+   int val;
+   u8 val_bulk[2];
 
mutex_lock(&data->update_lock);
 
if (time_after(jiffies, data->last_updated + HZ) || !data->valid) {
-   rv = i2c_smbus_read_byte_data(client,
-   MAX31790_REG_FAN_FAULT_STATUS1);
+   rv = regmap_read(regmap,
+MAX31790_REG_FAN_FAULT_STATUS1,
+&val);
if (rv < 0)
goto abort;
-   data->fault_status = rv & 0x3F;
+   data->fault_status = val & 0x3F;
 
-   rv = i2c_smbus_read_byte_data(client,
-   MAX31790_REG_FAN_FAULT_STATUS2);
+   rv = regmap_read(regmap,
+MAX31790_REG_FAN_FAULT_STATUS2,
+&val);
if (rv < 0)
goto abort;
-   data->fault_status |= (rv & 0x3F) << 6;
+   data->fault_status |= (val & 0x3F) << 6;
 
for (i = 0; i < NR_CHANNEL; i++) {
-   rv = i2c_smbus_read_word_swapped(client,
-   MAX31790_REG_TACH_COUNT(i));
+   rv = regmap_bulk_read(regmap,
+ MAX31790_REG_TACH_COUNT(i),
+ val_bulk,
+ 2);
if (rv < 0)
goto abort;
-   data->tach[i] = rv;
+   data->tach[i] = BULK_TO_U16(val_bulk[0],
+   val_bulk[1]);
 
if (data->fan_config[i]
& MAX31790_FAN_CFG_TACH_INPUT) {
-   rv = i2c_smbus_read_word_swapped(client,
-   MAX31790_REG_TACH_COUNT(NR_CHANNEL
-   + i));
+   rv = regmap_bulk_read(regmap,
+ 
MAX31790_REG_TACH_COUNT(NR_CHANNEL
+ + 
i),
+ val_bulk,
+ 2);
if (rv < 0)
goto abort;
-   data->tach[N

[PATCH 5/7] hwmon: (max31790) Refactor HWMON_CHANNEL_INFO

[Václav Kubernát]

The line was starting to get a little long.

Signed-off-by: Václav Kubernát 
---
 drivers/hwmon/max31790.c | 37 +
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/drivers/hwmon/max31790.c b/drivers/hwmon/max31790.c
index fde08c95d942..d4f259dd4e19 100644
--- a/drivers/hwmon/max31790.c
+++ b/drivers/hwmon/max31790.c
@@ -56,6 +56,19 @@
 #define U16_MSB(num)   (((num) & 0xFF00) >> 8)
 #define U16_LSB(num)   ((num) & 0x00FF)
 
+#define FAN_INFO_1_TO_6 \
+   (HWMON_F_PULSES | \
+   HWMON_F_ENABLE | \
+   HWMON_F_INPUT | \
+   HWMON_F_TARGET | \
+   HWMON_F_FAULT)
+
+#define FAN_INFO_7_TO_12 \
+   (HWMON_F_PULSES | \
+   HWMON_F_ENABLE | \
+   HWMON_F_INPUT | \
+   HWMON_F_FAULT)
+
 static const struct regmap_range max31790_ro_range = {
.range_min = MAX31790_REG_TACH_COUNT(0),
.range_max = MAX31790_REG_PWMOUT(0) - 1,
@@ -513,18 +526,18 @@ static umode_t max31790_is_visible(const void *data,
 
 static const struct hwmon_channel_info *max31790_info[] = {
HWMON_CHANNEL_INFO(fan,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | 
HWMON_F_TARGET | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | 
HWMON_F_TARGET | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | 
HWMON_F_TARGET | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | 
HWMON_F_TARGET | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | 
HWMON_F_TARGET | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | 
HWMON_F_TARGET | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | HWMON_F_FAULT,
-   HWMON_F_PULSES | HWMON_F_ENABLE | HWMON_F_INPUT | 
HWMON_F_FAULT),
+   FAN_INFO_1_TO_6,
+   FAN_INFO_1_TO_6,
+   FAN_INFO_1_TO_6,
+   FAN_INFO_1_TO_6,
+   FAN_INFO_1_TO_6,
+   FAN_INFO_1_TO_6,
+   FAN_INFO_7_TO_12,
+   FAN_INFO_7_TO_12,
+   FAN_INFO_7_TO_12,
+   FAN_INFO_7_TO_12,
+   FAN_INFO_7_TO_12,
+   FAN_INFO_7_TO_12),
HWMON_CHANNEL_INFO(pwm,
HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
-- 
2.30.1

Re: [PATCH v3 0/6] platform/surface: Add Surface Aggregator device registry

[Hans de Goede]

Hi,

On 2/12/21 12:54 PM, Maximilian Luz wrote:
> The Surface System Aggregator Module (SSAM) subsystem provides various
> functionalities, which are separated by spreading them across multiple
> devices and corresponding drivers. Parts of that functionality / some of
> those devices, however, can (as far as we currently know) not be
> auto-detected by conventional means. While older (specifically 5th- and
> 6th-)generation models do advertise most of their functionality via
> standard platform devices in ACPI, newer generations do not.
> 
> As we are currently also not aware of any feasible way to query said
> functionalities dynamically, this poses a problem. There is, however, a
> device in ACPI that seems to be used by Windows for identifying
> different Surface models: The Windows Surface Integration Device (WSID).
> This device seems to have a HID corresponding to the overall set of
> functionalities SSAM provides for the associated model.
> 
> This series introduces a device registry based on software nodes and
> device hubs to solve this problem. The registry is intended to contain
> all required non-detectable information.
> 
> The platform hub driver is loaded against the WSID device and
> instantiates and manages SSAM devices based on the information provided
> by the registry for the given WSID HID of the Surface model. All new
> devices created by this hub added as child devices to this hub.
> 
> In addition, a base hub is introduced to manage devices associated with
> the detachable base part of the Surface Book 3, as this requires special
> handling (i.e. devices need to be removed when the base is removed).
> Again, all devices created by the base hub (i.e. associated with the
> base) are added as child devices to this hub.
> 
> In total, this will yield the following device structure
> 
>   WSID
>|- SSAM device 1 (physical device)
>|- SSAM device 2 (physical device)
>|- SSAM device 3 (physical device)
>|- ...
>\- SSAM base hub (virtual device)
>   |- SSAM base device 1 (physical device)
>   |- SSAM base device 2 (physical device)
>   |- ...
> 
> While software nodes seem to be well suited for this approach due to
> extensibility, they still need to be hard-coded, so I'm open for ideas
> on how this could be improved.

Thank you for your patch-series, I've applied the series to my
review-hans branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans

Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.

Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.

Regards,

Hans



> 
> Changes in v2:
>  - Fix Kconfig dependency
> 
> Changes in v3:
>  - Fix use of lockdep_assert_held()
> 
> Maximilian Luz (6):
>   platform/surface: Set up Surface Aggregator device registry
>   platform/surface: aggregator_registry: Add base device hub
>   platform/surface: aggregator_registry: Add battery subsystem devices
>   platform/surface: aggregator_registry: Add platform profile device
>   platform/surface: aggregator_registry: Add DTX device
>   platform/surface: aggregator_registry: Add HID subsystem devices
> 
>  MAINTAINERS   |   1 +
>  drivers/platform/surface/Kconfig  |  27 +
>  drivers/platform/surface/Makefile |   1 +
>  .../surface/surface_aggregator_registry.c | 641 ++
>  4 files changed, 670 insertions(+)
>  create mode 100644 drivers/platform/surface/surface_aggregator_registry.c
> 

Linux 5.10.20

[Greg Kroah-Hartman]

I'm announcing the release of the 5.10.20 kernel.

All users of the 5.10 kernel series must upgrade.

The updated 5.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-5.10.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/admin-guide/perf/arm-cmn.rst 
|2 
 Documentation/admin-guide/sysctl/vm.rst
|   10 
 Documentation/filesystems/seq_file.rst 
|6 
 Documentation/scsi/libsas.rst  
|1 
 Documentation/security/keys/core.rst   
|4 
 Makefile   
|2 
 arch/arm/boot/compressed/head.S
|4 
 arch/arm/boot/dts/armada-388-helios4.dts   
|   28 
 arch/arm/boot/dts/aspeed-g4.dtsi   
|1 
 arch/arm/boot/dts/aspeed-g5.dtsi   
|1 
 arch/arm/boot/dts/aspeed-g6.dtsi   
|1 
 arch/arm/boot/dts/exynos3250-artik5.dtsi   
|2 
 arch/arm/boot/dts/exynos3250-monk.dts  
|2 
 arch/arm/boot/dts/exynos3250-rinato.dts
|2 
 arch/arm/boot/dts/exynos5250-spring.dts
|2 
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  
|2 
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi  
|2 
 arch/arm/boot/dts/omap443x.dtsi
|2 
 arch/arm/kernel/sys_oabi-compat.c  
|   15 
 arch/arm/mach-at91/pm_suspend.S
|2 
 arch/arm/mach-ixp4xx/Kconfig   
|1 
 arch/arm/mach-s3c/irq-s3c24xx-fiq.S
|9 
 arch/arm64/Kconfig 
|2 
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts  
|5 
 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi   
|1 
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  
|6 
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi   
|7 
 arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts 
|7 
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi  
|2 
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts
|2 
 arch/arm64/boot/dts/intel/socfpga_agilex.dtsi  
|4 
 arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts 
|2 
 arch/arm64/boot/dts/mediatek/mt7622.dtsi   
|2 
 arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi 
|6 
 arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts   
|2 
 arch/arm64/boot/dts/qcom/msm8916.dtsi  
|4 
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts   
|9 
 arch/arm64/boot/dts/qcom/sdm845-db845c.dts 
|4 
 arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi  
|2 
 arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
|4 
 arch/arm64/boot/dts/rockchip/rk3328.dtsi   
|1 
 arch/arm64/crypto/aes-glue.c   
|4 
 

Re: [PATCH v1 1/2] lib/cmdline: Export next_arg() for being used in modules

[Andy Shevchenko]

On Thu, Mar 04, 2021 at 09:53:28AM +0100, Geert Uytterhoeven wrote:
> On Mon, Mar 1, 2021 at 6:00 PM Andy Shevchenko
>  wrote:
> > At least one module will benefit from using next_arg() helper.
> > Let's export it for that module and others if they consider it
> > helpful.
> >
> > Signed-off-by: Andy Shevchenko 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks Geert and Linus!

Bart, do you want me to add it to my usual PR or you want to take it yourself
(I have no dependencies in my tree on this anyway)?

-- 
With Best Regards,
Andy Shevchenko