Re: [PATCH v3 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

[Wesley Cheng]

On 6/18/2020 3:23 PM, Rob Herring wrote:
> On Thu, Jun 18, 2020 at 2:09 PM Wesley Cheng  wrote:
>>
>>
>> On 6/18/2020 11:33 AM, Rob Herring wrote:
>>> On Wed, Jun 17, 2020 at 12:02 PM Wesley Cheng  wrote:
>>>
>>> You are duplicating everything in usb-connector.yaml. You should have
>>> a $ref to it.
>>>
>>
>> Hi Rob,
>>
>> Sure, I will add a reference to that doc.
>>
>>>
>>> This is wrong. The connector binding says port 0 is the connection the
>>> USB HS controller.
>>>
>>> What's a type C mux node? Is there a binding for that? There's an
>>> ongoing discussion with the CrOS folks on how to describe Alt mode
>>> mux/switches.
>>
>> I reviewed the connector binding previously, and couldn't seem to come
>> up with a model which fit a design where the type C controller (ie the
>> entity which does the CC orientation and role detection) does not have
>> the SS lane mux included.  The SS lane mux is the HW which handles the
>> selection of the SS lanes to utilize based on cable orientation.
> 
> The intent was the controller would be the parent node of the connector.
> 

Hi Rob,

Correct, I agree with that point, and in the changes uploaded, the QCOM
PMIC type C controller will be the parent node for the connector.

> How the SS lane mux is represented is what needs to be figured out. I
> don't know what that looks like, but it needs to be something that
> works for multiple designs. Ideally, that's an extension of the
> existing 'usb-c-connector' binding, but if there's good reasons to
> redesign it that can happen.
> 
> Rob
> 

We probably wouldn't need to redesign it, but maybe if we can remove the
connector port assignments requirement, it would allow for some
flexibility.  From my knowledge, I don't think any driver is actually
utilizing or checking the port number assignments, so there isn't a
limitation on what could be defined in there.

Here's a simplified diagram of the FUSB302 reference design from the
data sheet.  The I2C bus is just for CSR access to the FUSB302.

   ___   ___
__|FUSB302| |SOC|
   |  |Type C | |   |
   |  |Cntrl  |__I2C___ |   |
   |  |___| |   |
 ___   ||   |
|   |__ CC1/2 _||   |
|   |__ HS DP/DM __ |   |
|   |   |   |
    |   |
|   |__ SS RX/TX1 |FUSB304 |__SS RX/TX_ |   |
|   |__ SS RX/TX2 |USB Mux ||___|
|   | ||
|   |
|___|


Otherwise, we can just simply add another port definition for external
SS lane muxes if possible.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 17/21] x86/fpu: Use proper mask to replace full instruction mask

[Liang, Kan]

On 6/22/2020 11:02 AM, Dave Hansen wrote:

On 6/22/20 7:52 AM, Liang, Kan wrote:

--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -58,6 +58,7 @@ static short xsave_cpuid_features[] __initdata = {
    * XSAVE buffer, both supervisor and user xstates.
    */
   u64 xfeatures_mask_all __read_mostly;
+EXPORT_SYMBOL_GPL(xfeatures_mask_all);


*groan*...

AFAICT KVM doesn't actually use any of those functions,


It seems KVM may eventually invoke copy_xregs_to_kernel() as below.

kvm_save_current_fpu()
     copy_fpregs_to_fpstate()
     copy_xregs_to_kernel()

I think we have to export the xfeatures_mask_all.


I'm wondering if we should just take these copy_*regs_to_*() functions
and uninline them.  Yeah, they are basically wrapping one instruction,
but it might literally be the most heavyweight instruction in the whole ISA.



Thanks for the suggestions, but I'm not sure if I follow these methods.

I don't think simply removing the "inline" key word for the 
copy_xregs_to_kernel() functions would help here.

Do you mean exporting the copy_*regs_to_*()?



Or, maybe just make an out-of-line version for KVM to call?



I think the out-of-line version for KVM still needs the 
xfeatures_mask_all. Because the size of vcpu's XSAVE buffer 
(>arch.guest_fpu) is the same as other kernel XSAVE buffers, such 
as task->fpu. The xfeatures_mask_all is required for KVM to filter out 
the dynamic supervisor feature as well. I think even if we make an 
out-of-line version for KVM, we still have to export the 
xfeatures_mask_all for KVM.



Thanks,
Kan

Re: [PATCH v2 3/8] soc: qcom: socinfo: Add socinfo entry for SDM630

[Bjorn Andersson]

On Mon 22 Jun 01:37 PDT 2020, Konrad Dybcio wrote:

> Hi Bjorn,
> 
> you said "Applied" - so should I omit this patch when sending a v3 of
> the series or keep it in there?
> 

Seems I missed pushing out the drivers-for-5.9 branch, but the change is
staged for 5.9 here:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h=for-next

So you can omit it from now on.

Regards,
Bjorn

Re: [PATCH v2] perf flamegraph: explicitly set utf-8 encoding

[Andreas Gerstmayr]

On 22.06.20 18:31, Arnaldo Carvalho de Melo wrote:

Em Fri, Jun 19, 2020 at 05:32:31PM +0200, Andreas Gerstmayr escreveu:

on some platforms the default encoding is not utf-8,
which causes an UnicodeDecodeError when reading the flamegraph template
and writing the flamegraph


Thanks, applied.


Thank you!

Cheers,
Andreas




- Arnaldo
  

Signed-off-by: Andreas Gerstmayr 
---

changelog v2: also write to stdout with utf-8 encoding

  tools/perf/scripts/python/flamegraph.py | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/perf/scripts/python/flamegraph.py 
b/tools/perf/scripts/python/flamegraph.py
index 61f3be9add6b..65780013f745 100755
--- a/tools/perf/scripts/python/flamegraph.py
+++ b/tools/perf/scripts/python/flamegraph.py
@@ -17,6 +17,7 @@
  from __future__ import print_function
  import sys
  import os
+import io
  import argparse
  import json
  
@@ -81,7 +82,7 @@ class FlameGraphCLI:
  
  if self.args.format == "html":

  try:
-with open(self.args.template) as f:
+with io.open(self.args.template, encoding="utf-8") as f:
  output_str = f.read().replace("/** @flamegraph_json **/",
json_str)
  except IOError as e:
@@ -93,11 +94,12 @@ class FlameGraphCLI:
  output_fn = self.args.output or "stacks.json"
  
  if output_fn == "-":

-sys.stdout.write(output_str)
+with io.open(sys.stdout.fileno(), "w", encoding="utf-8", 
closefd=False) as out:
+out.write(output_str)
  else:
  print("dumping data to {}".format(output_fn))
  try:
-with open(output_fn, "w") as out:
+with io.open(output_fn, "w", encoding="utf-8") as out:
  out.write(output_str)
  except IOError as e:
  print("Error writing output file: {}".format(e), 
file=sys.stderr)
--
2.25.4

Re: [PATCH v2 1/1] clk: qcom: gcc-msm8994: Add missing clocks, resets and GDSCs

[Bjorn Andersson]

On Mon 22 Jun 02:18 PDT 2020, Konrad Dybcio wrote:

> changes since v1:
> - refrain from reordering defines in the header

The changelog goes after '---' below.

> 
> This change adds GDSCs, resets and most of the missing
> clocks to the msm8994 GCC driver. The remaining ones
> are of local_vote_clk and gate_clk type, which are not
> yet supported upstream. Also reorder them to match the
> original downstream driver.
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  drivers/clk/qcom/gcc-msm8994.c   | 388 ++-
>  include/dt-bindings/clock/qcom,gcc-msm8994.h |  36 ++
>  2 files changed, 423 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
> index b7fc8c7ba195..144d2ba7a9be 100644
> --- a/drivers/clk/qcom/gcc-msm8994.c
> +++ b/drivers/clk/qcom/gcc-msm8994.c
> @@ -20,6 +20,7 @@
>  #include "clk-rcg.h"
>  #include "clk-branch.h"
>  #include "reset.h"
> +#include "gdsc.h"
>  
>  enum {
>   P_XO,
> @@ -1772,6 +1773,32 @@ static struct clk_branch gcc_gp3_clk = {
>   },
>  };
>  
> +static struct clk_branch gcc_lpass_q6_axi_clk = {
> + .halt_reg = 0x0280,
> + .clkr = {
> + .enable_reg = 0x0280,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data)
> + {
> + .name = "gcc_lpass_q6_axi_clk",
> + .ops = _branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch gcc_mss_q6_bimc_axi_clk = {
> + .halt_reg = 0x0284,
> + .clkr = {
> + .enable_reg = 0x0284,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data)
> + {
> + .name = "gcc_mss_q6_bimc_axi_clk",
> + .ops = _branch2_ops,
> + },
> + },
> +};
> +
>  static struct clk_branch gcc_pcie_0_aux_clk = {
>   .halt_reg = 0x1ad4,
>   .clkr = {
> @@ -1790,6 +1817,32 @@ static struct clk_branch gcc_pcie_0_aux_clk = {
>   },
>  };
>  
> +static struct clk_branch gcc_pcie_0_cfg_ahb_clk = {
> + .halt_reg = 0x1ad0,
> + .clkr = {
> + .enable_reg = 0x1ad0,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data)
> + {
> + .name = "gcc_pcie_0_cfg_ahb_clk",
> + .ops = _branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch gcc_pcie_0_mstr_axi_clk = {
> + .halt_reg = 0x1acc,
> + .clkr = {
> + .enable_reg = 0x1acc,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data)
> + {
> + .name = "gcc_pcie_0_mstr_axi_clk",
> + .ops = _branch2_ops,
> + },
> + },
> +};
> +
>  static struct clk_branch gcc_pcie_0_pipe_clk = {
>   .halt_reg = 0x1ad8,
>   .halt_check = BRANCH_HALT_DELAY,
> @@ -1809,6 +1862,20 @@ static struct clk_branch gcc_pcie_0_pipe_clk = {
>   },
>  };
>  
> +static struct clk_branch gcc_pcie_0_slv_axi_clk = {
> + .halt_reg = 0x1ac8,
> + .halt_check = BRANCH_HALT_DELAY,
> + .clkr = {
> + .enable_reg = 0x1ac8,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data)
> + {
> + .name = "gcc_pcie_0_slv_axi_clk",
> + .ops = _branch2_ops,
> + },
> + },
> +};
> +
>  static struct clk_branch gcc_pcie_1_aux_clk = {
>   .halt_reg = 0x1b54,
>   .clkr = {
> @@ -1827,6 +1894,32 @@ static struct clk_branch gcc_pcie_1_aux_clk = {
>   },
>  };
>  
> +static struct clk_branch gcc_pcie_1_cfg_ahb_clk = {
> + .halt_reg = 0x1b54,
> + .clkr = {
> + .enable_reg = 0x1b54,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data)
> + {
> + .name = "gcc_pcie_1_cfg_ahb_clk",
> + .ops = _branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch gcc_pcie_1_mstr_axi_clk = {
> + .halt_reg = 0x1b50,
> + .clkr = {
> + .enable_reg = 0x1b50,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data)
> + {
> + .name = "gcc_pcie_1_mstr_axi_clk",
> + .ops = _branch2_ops,
> + },
> + },
> +};
> +
>  static struct clk_branch gcc_pcie_1_pipe_clk = {
>   .halt_reg = 0x1b58,
>   .halt_check = BRANCH_HALT_DELAY,
> @@ -1846,6 +1939,19 @@ static struct clk_branch gcc_pcie_1_pipe_clk = {
>   },
>  };
>  
> +static struct clk_branch gcc_pcie_1_slv_axi_clk = {
> + .halt_reg = 0x1b48,
> + .clkr = {
> + .enable_reg = 0x1b48,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data)
> + {
> + .name = "gcc_pcie_1_slv_axi_clk",
> + .ops 

Re: [PATCH v6 13/19] mm: memcg/slab: simplify memcg cache creation

[Roman Gushchin]

On Mon, Jun 22, 2020 at 10:29:29AM -0700, Shakeel Butt wrote:
> On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin  wrote:
> >
> > Because the number of non-root kmem_caches doesn't depend on the
> > number of memory cgroups anymore and is generally not very big,
> > there is no more need for a dedicated workqueue.
> >
> > Also, as there is no more need to pass any arguments to the
> > memcg_create_kmem_cache() except the root kmem_cache, it's
> > possible to just embed the work structure into the kmem_cache
> > and avoid the dynamic allocation of the work structure.
> >
> > This will also simplify the synchronization: for each root kmem_cache
> > there is only one work. So there will be no more concurrent attempts
> > to create a non-root kmem_cache for a root kmem_cache: the second and
> > all following attempts to queue the work will fail.
> >
> >
> > On the kmem_cache destruction path there is no more need to call the
> > expensive flush_workqueue() and wait for all pending works to be
> > finished. Instead, cancel_work_sync() can be used to cancel/wait for
> > only one work.
> >
> > Signed-off-by: Roman Gushchin 
> > Reviewed-by: Vlastimil Babka 
> 
> Why not pre-allocate the non-root kmem_cache at the kmem_cache
> creation time? No need for work_struct, queue_work() or
> cancel_work_sync() at all.

Simple because some kmem_caches are created very early, so we don't
even know at that time if we will need memcg slab caches. But this
code is likely going away if we're going with a single set for all
allocations.

Thanks!

[PATCH 5/5] Huawei BMA: Adding Huawei BMA driver: host_kbox_drv

[yunaixin03610]

From: yunaixin 

The BMA software is a system management software offered by Huawei. It supports 
the status monitoring, performance monitoring, and event monitoring of various 
components, including server CPUs, memory, hard disks, NICs, IB cards, PCIe 
cards, RAID controller cards, and optical modules.

The host_kbox_drv driver serves the function of a black box. When a panic or 
mce event happen to the system, it will record the event time, system's status 
and system logs and send them to BMC before the OS shutdown. This driver 
depends on the host_edms_drv driver.

Signed-off-by: yunaixin 
---
 drivers/net/ethernet/huawei/bma/Kconfig   |   3 +-
 drivers/net/ethernet/huawei/bma/Makefile  |   1 +
 .../net/ethernet/huawei/bma/kbox_drv/Kconfig  |  11 +
 .../net/ethernet/huawei/bma/kbox_drv/Makefile |   2 +
 .../ethernet/huawei/bma/kbox_drv/kbox_dump.c  | 121 +++
 .../ethernet/huawei/bma/kbox_drv/kbox_dump.h  |  33 +
 .../ethernet/huawei/bma/kbox_drv/kbox_hook.c  | 101 ++
 .../ethernet/huawei/bma/kbox_drv/kbox_hook.h  |  33 +
 .../huawei/bma/kbox_drv/kbox_include.h|  40 +
 .../ethernet/huawei/bma/kbox_drv/kbox_main.c  | 168 +++
 .../ethernet/huawei/bma/kbox_drv/kbox_main.h  |  23 +
 .../ethernet/huawei/bma/kbox_drv/kbox_mce.c   | 264 +
 .../ethernet/huawei/bma/kbox_drv/kbox_mce.h   |  23 +
 .../ethernet/huawei/bma/kbox_drv/kbox_panic.c | 187 
 .../ethernet/huawei/bma/kbox_drv/kbox_panic.h |  25 +
 .../huawei/bma/kbox_drv/kbox_printk.c | 363 +++
 .../huawei/bma/kbox_drv/kbox_printk.h |  33 +
 .../huawei/bma/kbox_drv/kbox_ram_drive.c  | 188 
 .../huawei/bma/kbox_drv/kbox_ram_drive.h  |  31 +
 .../huawei/bma/kbox_drv/kbox_ram_image.c  | 135 +++
 .../huawei/bma/kbox_drv/kbox_ram_image.h  |  84 ++
 .../huawei/bma/kbox_drv/kbox_ram_op.c | 986 ++
 .../huawei/bma/kbox_drv/kbox_ram_op.h |  77 ++
 23 files changed, 2931 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/Kconfig
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/Makefile
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_dump.c
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_dump.h
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_hook.c
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_hook.h
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_include.h
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_main.c
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_main.h
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_mce.c
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_mce.h
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_panic.c
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_panic.h
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_printk.c
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_printk.h
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_drive.c
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_drive.h
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_image.c
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_image.h
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.c
 create mode 100644 drivers/net/ethernet/huawei/bma/kbox_drv/kbox_ram_op.h

diff --git a/drivers/net/ethernet/huawei/bma/Kconfig 
b/drivers/net/ethernet/huawei/bma/Kconfig
index d8710b8e1c18..77041669d4b4 100644
--- a/drivers/net/ethernet/huawei/bma/Kconfig
+++ b/drivers/net/ethernet/huawei/bma/Kconfig
@@ -1,4 +1,5 @@
 source "drivers/net/ethernet/huawei/bma/edma_drv/Kconfig"
 source "drivers/net/ethernet/huawei/bma/cdev_drv/Kconfig"
 source "drivers/net/ethernet/huawei/bma/veth_drv/Kconfig"
-source "drivers/net/ethernet/huawei/bma/cdev_veth_drv/Kconfig"
+source "drivers/net/ethernet/huawei/bma/kbox_drv/Kconfig"
+source "drivers/net/ethernet/huawei/bma/cdev_veth_drv/Kconfig"
\ No newline at end of file
diff --git a/drivers/net/ethernet/huawei/bma/Makefile 
b/drivers/net/ethernet/huawei/bma/Makefile
index c626618f47fb..5caa8290a1f7 100644
--- a/drivers/net/ethernet/huawei/bma/Makefile
+++ b/drivers/net/ethernet/huawei/bma/Makefile
@@ -5,4 +5,5 @@
 obj-$(CONFIG_BMA) += edma_drv/
 obj-$(CONFIG_BMA) += cdev_drv/
 obj-$(CONFIG_BMA) += veth_drv/
+obj-$(CONFIG_BMA) += kbox_drv/
 obj-$(CONFIG_BMA) += cdev_veth_drv/
\ No newline at end of file
diff --git a/drivers/net/ethernet/huawei/bma/kbox_drv/Kconfig 
b/drivers/net/ethernet/huawei/bma/kbox_drv/Kconfig
new file mode 100644
index ..97829c5487c2
--- /dev/null
+++ b/drivers/net/ethernet/huawei/bma/kbox_drv/Kconfig
@@ -0,0 +1,11 @@
+#
+# Huawei BMA software driver configuration
+#
+
+config BMA
+   tristate "Huawei BMA Software Communication Driver"
+
+   

Re: [PATCH] security: fix the key_permission LSM hook function type

[James Morris]

On Mon, 15 Jun 2020, Sami Tolvanen wrote:

> Commit 8c0637e950d6 ("keys: Make the KEY_NEED_* perms an enum rather than
> a mask") changed the type of the key_permission callback functions, but
> didn't change the type of the hook, which trips indirect call checking with
> Control-Flow Integrity (CFI). This change fixes the issue by changing the
> hook type to match the functions.
> 
> Fixes: 8c0637e950d6 ("keys: Make the KEY_NEED_* perms an enum rather than a 
> mask")
> Signed-off-by: Sami Tolvanen 

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
fixes-v5.8


NOTE: please cc: the LSM list with patches such as these.



-- 
James Morris

Re: [PATCH] Revert "kernel/printk: add kmsg SEEK_CUR handling"

[Bruno Meneguele]

On Mon, Jun 22, 2020 at 10:32:51AM -0700, Linus Torvalds wrote:
> On Mon, Jun 22, 2020 at 10:10 AM Bruno Meneguele  wrote:
> >
> > Although both options are pretty fine by me too, I "fear" (not really)
> > we can end up stacking special behavior interfaces, forcing userspace to
> > keep a "table of special case files". Personally, I prefer to return
> > something _valid_ to userspace rather than _fail_ with special meaning.
> 
> Well, what's even worse if user space has to handle two different
> things just because behavior changed in different kernels..
> 
> So at some point "odd behavior" is much better than "odd behavior in
> two different ways"..

Really well pointed!

Ok, +1 for doc-only patch it is :).

-- 
bmeneg 
PGP Key: http://bmeneg.com/pubkey.txt


signature.asc
Description: PGP signature

Re: [PATCH v33 01/21] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits

[Borislav Petkov]

On Thu, Jun 18, 2020 at 01:08:23AM +0300, Jarkko Sakkinen wrote:
> From: Sean Christopherson 
> 
> Add X86_FEATURE_SGX from CPUID.(EAX=7, ECX=1), which informs whether the
> CPU has SGX.
> 
> Add X86_FEATURE_SGX1 and X86_FEATURE_SGX2 from CPUID.(EAX=12H, ECX=0),
> which describe the level of SGX support available [1].
> 
> Add IA32_FEATURE_CONTROL_SGX_ENABLE. BIOS can use this bit to opt-in SGX

I'm guessing that wants to be

IA32_FEATURE_CONTROL.SGX_ENABLE

judging by the diff and the SDM chapter.

> before locking the feature control MSR [2].
> 
> [1] Intel SDM: 36.7.2 Intel® SGX Resource Enumeration Leaves
> [2] Intel SDM: 36.7.1 Intel® SGX Opt-In Configuration
> 
> Cc: Borislav Petkov 
> Acked-by: Jethro Beekman 
> Signed-off-by: Sean Christopherson 
> Co-developed-by: Jarkko Sakkinen 
> Signed-off-by: Jarkko Sakkinen 
> ---
>  arch/x86/include/asm/cpufeature.h|  5 +++--
>  arch/x86/include/asm/cpufeatures.h   |  7 ++-
>  arch/x86/include/asm/disabled-features.h | 18 +++---
>  arch/x86/include/asm/msr-index.h |  1 +
>  arch/x86/include/asm/required-features.h |  2 +-
>  arch/x86/kernel/cpu/common.c |  4 
>  tools/arch/x86/include/asm/cpufeatures.h |  7 ++-

Also, please drop this change to tools/, see

https://lkml.kernel.org/r/20200622141737.ga30...@kernel.org

from today.

With those addressed:

Reviewed-by: Borislav Petkov 

Thx.

-- 
Regards/Gruss,
Boris.

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

Re: UART/TTY console deadlock

[Andy Shevchenko]

+Cc: Tony and console people

On Mon, Jun 22, 2020 at 8:32 PM Raul Rangel  wrote:
>
> We are trying an S3 suspend stress test and occasionally while
> entering S3 we get a console deadlock. Is this a known issue? I'm not
> really sure why a probe would be happening while suspending.
>
> The kernel command line is `console=ttyS0` and kernel 5.4.39.
>
> Here is the log:
>
> [  278.885831] leds mmc0::: calling led_resume+0x0/0x1c @ 3909,
> parent: :02:00.0
> [  278.885835] leds mmc0::: led_resume+0x0/0x1c returned 0 after 0 usecs
> [  278.890230]  secondary_startup_64+0xa4/0xb0
> [  278.890236] handlers:
> [  279.752138] [] i8042_interrupt
> [  279.756915] Disabling IRQ #1
> [  279.759801]
> [  279.759802] ==
> [  279.759803] WARNING: possible circular locking dependency detected
> [  279.759803] 5.4.39 #55 Not tainted
> [  279.759804] --
> [  279.759804] swapper/0/0 is trying to acquire lock:
> [  279.759805] ab65b6c0 (console_owner){-...}, at:
> console_lock_spinning_enable+0x31/0x57
> [  279.759806]
> [  279.759807] but task is already holding lock:
> [  279.759807] 88810a8e34c0 (_desc_lock_class){-.-.}, at:
> __report_bad_irq+0x5b/0xba
> [  279.759809]
> [  279.759809] which lock already depends on the new lock.
> [  279.759810]
> [  279.759810]
> [  279.759811] the existing dependency chain (in reverse order) is:
> [  279.759811]
> [  279.759811] -> #2 (_desc_lock_class){-.-.}:
> [  279.759813]_raw_spin_lock_irqsave+0x61/0x8d
> [  279.759813]__irq_get_desc_lock+0x65/0x89
> [  279.759814]__disable_irq_nosync+0x3b/0x93
> [  279.759814]serial8250_do_startup+0x451/0x75c
> [  279.759815]uart_startup+0x1b4/0x2ff
> [  279.759815]uart_port_activate+0x73/0xa0
> [  279.759815]tty_port_open+0xae/0x10a
> [  279.759816]uart_open+0x1b/0x26
> [  279.759816]tty_open+0x24d/0x3a0
> [  279.759817]chrdev_open+0xd5/0x1cc
> [  279.759817]do_dentry_open+0x299/0x3c8
> [  279.759817]path_openat+0x434/0x1100
> [  279.759818]do_filp_open+0x9b/0x10a
> [  279.759818]do_sys_open+0x15f/0x3d7
> [  279.759819]kernel_init_freeable+0x157/0x1dd
> [  279.759819]kernel_init+0xe/0x105
> [  279.759819]ret_from_fork+0x27/0x50
> [  279.759820]
> [  279.759820] -> #1 (_lock_key){-.-.}:
> [  279.759822]_raw_spin_lock_irqsave+0x61/0x8d
> [  279.759822]serial8250_console_write+0xa7/0x2a0
> [  279.759823]console_unlock+0x3b7/0x528
> [  279.759823]vprintk_emit+0x111/0x17f
> [  279.759823]printk+0x59/0x73
> [  279.759824]register_console+0x336/0x3a4
> [  279.759824]uart_add_one_port+0x51b/0x5be
> [  279.759825]serial8250_register_8250_port+0x454/0x55e
> [  279.759825]dw8250_probe+0x4dc/0x5b9
> [  279.759825]platform_drv_probe+0x67/0x8b
> [  279.759826]really_probe+0x14a/0x422
> [  279.759826]driver_probe_device+0x66/0x130
> [  279.759827]device_driver_attach+0x42/0x5b
> [  279.759827]__driver_attach+0xca/0x139
> [  279.759827]bus_for_each_dev+0x97/0xc9
> [  279.759828]bus_add_driver+0x12b/0x228
> [  279.759828]driver_register+0x64/0xed
> [  279.759829]do_one_initcall+0x20c/0x4a6
> [  279.759829]do_initcall_level+0xb5/0xc5
> [  279.759829]do_basic_setup+0x4c/0x58
> [  279.759830]kernel_init_freeable+0x13f/0x1dd
> [  279.759830]kernel_init+0xe/0x105
> [  279.759831]ret_from_fork+0x27/0x50
> [  279.759831]
> [  279.759831] -> #0 (console_owner){-...}:
> [  279.759833]__lock_acquire+0x118d/0x2714
> [  279.759833]lock_acquire+0x203/0x258
> [  279.759834]console_lock_spinning_enable+0x51/0x57
> [  279.759834]console_unlock+0x25d/0x528
> [  279.759834]vprintk_emit+0x111/0x17f
> [  279.759835]printk+0x59/0x73
> [  279.759835]__report_bad_irq+0xa3/0xba
> [  279.759836]note_interrupt+0x19a/0x1d6
> [  279.759836]handle_irq_event_percpu+0x57/0x79
> [  279.759836]handle_irq_event+0x36/0x55
> [  279.759837]handle_fasteoi_irq+0xc2/0x18a
> [  279.759837]do_IRQ+0xb3/0x157
> [  279.759838]ret_from_intr+0x0/0x1d
> [  279.759838]cpuidle_enter_state+0x12f/0x1fd
> [  279.759838]cpuidle_enter+0x2e/0x3d
> [  279.759839]do_idle+0x1ce/0x2ce
> [  279.759839]cpu_startup_entry+0x1d/0x1f
> [  279.759840]start_kernel+0x406/0x46a
> [  279.759840]secondary_startup_64+0xa4/0xb0
> [  279.759840]
> [  279.759841] other info that might help us debug this:
> [  279.759841]
> [  279.759841] Chain exists of:
> [  279.759842]   console_owner --> _lock_key --> _desc_lock_class
> [  279.759844]
> [  279.759844]  Possible unsafe locking scenario:
> [  279.759845]
> [  279.759845]CPU0  

Re: [PATCH v6 15/19] mm: memcg/slab: deprecate slab_root_caches

[Shakeel Butt]

On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin  wrote:
>
> Currently there are two lists of kmem_caches:
> 1) slab_caches, which contains all kmem_caches,
> 2) slab_root_caches, which contains only root kmem_caches.
>
> And there is some preprocessor magic to have a single list
> if CONFIG_MEMCG_KMEM isn't enabled.
>
> It was required earlier because the number of non-root kmem_caches
> was proportional to the number of memory cgroups and could reach
> really big values. Now, when it cannot exceed the number of root
> kmem_caches, there is really no reason to maintain two lists.
>
> We never iterate over the slab_root_caches list on any hot paths,
> so it's perfectly fine to iterate over slab_caches and filter out
> non-root kmem_caches.
>
> It allows to remove a lot of config-dependent code and two pointers
> from the kmem_cache structure.
>
> Signed-off-by: Roman Gushchin 
> Reviewed-by: Vlastimil Babka 

Reviewed-by: Shakeel Butt 

Re: [PATCH v3 2/6] remoteproc: k3: Add TI-SCI processor control helper functions

[Mathieu Poirier]

Hi Suman,

Apologies for the late reply, this one slipped through the cracks...


On Fri, Jun 12, 2020 at 05:49:10PM -0500, Suman Anna wrote:
> Texas Instruments' K3 generation SoCs have specific modules/register
> spaces used for configuring the various aspects of a remote processor.
> These include power, reset, boot vector and other configuration features
> specific to each compute processor present on the SoC. These registers
> are managed by the System Controller such as DMSC on K3 AM65x SoCs.
> 
> The Texas Instrument's System Control Interface (TI-SCI) Message Protocol
> is used to communicate to the System Controller from various compute
> processors to invoke specific services provided by the firmware running
> on the System Controller.
> 
> Add a common processor control interface header file that can be used by
> multiple remoteproc drivers. The helper functions within this header file
> abstract the various TI SCI protocol ops for the remoteproc drivers, and
> allow them to request the System Controller to be able to program and
> manage various remote processors on the SoC. The remoteproc drivers are
> expected to manage the life-cycle of their ti_sci_proc_dev local
> structures.
> 
> Signed-off-by: Suman Anna 
> ---
> v3: New to this series, but the patch is identical to the one from the
> K3 R5F series posted previously, with patch title adjusted
> https://patchwork.kernel.org/patch/11456379/
> 
>  drivers/remoteproc/ti_sci_proc.h | 102 +++
>  1 file changed, 102 insertions(+)
>  create mode 100644 drivers/remoteproc/ti_sci_proc.h
> 
> diff --git a/drivers/remoteproc/ti_sci_proc.h 
> b/drivers/remoteproc/ti_sci_proc.h
> new file mode 100644
> index ..e42d8015b8e7
> --- /dev/null
> +++ b/drivers/remoteproc/ti_sci_proc.h
> @@ -0,0 +1,102 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Texas Instruments TI-SCI Processor Controller Helper Functions
> + *
> + * Copyright (C) 2018-2020 Texas Instruments Incorporated - 
> http://www.ti.com/
> + *   Suman Anna
> + */
> +
> +#ifndef REMOTEPROC_TI_SCI_PROC_H
> +#define REMOTEPROC_TI_SCI_PROC_H
> +
> +/**
> + * struct ti_sci_proc - structure representing a processor control client
> + * @sci: cached TI-SCI protocol handle
> + * @ops: cached TI-SCI proc ops
> + * @dev: cached client device pointer
> + * @proc_id: processor id for the consumer remoteproc device
> + * @host_id: host id to pass the control over for this consumer remoteproc
> + *device
> + */
> +struct ti_sci_proc {
> + const struct ti_sci_handle *sci;
> + const struct ti_sci_proc_ops *ops;
> + struct device *dev;

Please include the proper header files for the above structures.  I would also
have expected the name of the structure to be ti_sci_rproc but that choice is
entirely your.

With the proper header files included:

Reviewed-by: Mathieu Poirier 

> + u8 proc_id;
> + u8 host_id;
> +};
> +
> +static inline int ti_sci_proc_request(struct ti_sci_proc *tsp)
> +{
> + int ret;
> +
> + ret = tsp->ops->request(tsp->sci, tsp->proc_id);
> + if (ret)
> + dev_err(tsp->dev, "ti-sci processor request failed: %d\n",
> + ret);
> + return ret;
> +}
> +
> +static inline int ti_sci_proc_release(struct ti_sci_proc *tsp)
> +{
> + int ret;
> +
> + ret = tsp->ops->release(tsp->sci, tsp->proc_id);
> + if (ret)
> + dev_err(tsp->dev, "ti-sci processor release failed: %d\n",
> + ret);
> + return ret;
> +}
> +
> +static inline int ti_sci_proc_handover(struct ti_sci_proc *tsp)
> +{
> + int ret;
> +
> + ret = tsp->ops->handover(tsp->sci, tsp->proc_id, tsp->host_id);
> + if (ret)
> + dev_err(tsp->dev, "ti-sci processor handover of %d to %d 
> failed: %d\n",
> + tsp->proc_id, tsp->host_id, ret);
> + return ret;
> +}
> +
> +static inline int ti_sci_proc_set_config(struct ti_sci_proc *tsp,
> +  u64 boot_vector,
> +  u32 cfg_set, u32 cfg_clr)
> +{
> + int ret;
> +
> + ret = tsp->ops->set_config(tsp->sci, tsp->proc_id, boot_vector,
> +cfg_set, cfg_clr);
> + if (ret)
> + dev_err(tsp->dev, "ti-sci processor set_config failed: %d\n",
> + ret);
> + return ret;
> +}
> +
> +static inline int ti_sci_proc_set_control(struct ti_sci_proc *tsp,
> +   u32 ctrl_set, u32 ctrl_clr)
> +{
> + int ret;
> +
> + ret = tsp->ops->set_control(tsp->sci, tsp->proc_id, ctrl_set, ctrl_clr);
> + if (ret)
> + dev_err(tsp->dev, "ti-sci processor set_control failed: %d\n",
> + ret);
> + return ret;
> +}
> +
> +static inline int ti_sci_proc_get_status(struct ti_sci_proc *tsp,
> +  u64 *boot_vector, u32 *cfg_flags,
> + 

Re: drivers/gpu/drm/panel/panel-samsung-ld9040.c:240:12: warning: stack frame size of 8312 bytes in function 'ld9040_prepare'

[Sam Ravnborg]

Hi Vladimir

> I really don't get what's the problem here. The listing of
> ld9040_prepare at the given commit and with the given .config is:

The culprint is likely ld9040_brightness_set() that is inlined.

I think we have troubles with

static u8 const ld9040_gammas[25][22]

I did not look closely but if you can reproduce this is where I think you
should look.

Sam

Re: [PATCH] qla2xxx: Set NVME status code for failed NVME FCP request

[Himanshu Madhani]

On 6/4/20 5:07 AM, Daniel Wagner wrote:

The qla2xxx driver knows when request was processed successfully or
not. But it always sets the NVME status code to 0/NVME_SC_SUCCESS. The
upper layer needs to figure out from the rcv_rsplen and
transferred_length variables if the request was successfully. This is
not always possible, e.g. when the request data length is 0, the
transferred_length is also set 0 which is interpreted as success in
nvme_fc_fcpio_done(). Let's inform the upper
layer (nvme_fc_fcpio_done()) when something went wrong.

nvme_fc_fcpio_done() maps all non NVME_SC_SUCCESS status codes to
NVME_SC_HOST_PATH_ERROR. There isn't any benefit to map the QLA status
code to the NVME status code. Therefore, let's use NVME_SC_INTERNAL to
indicate an error which aligns it with the lpfc driver.

Signed-off-by: Daniel Wagner 
---
  drivers/scsi/qla2xxx/qla_nvme.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/qla2xxx/qla_nvme.c b/drivers/scsi/qla2xxx/qla_nvme.c
index d66d47a0f958..fa695a4007f8 100644
--- a/drivers/scsi/qla2xxx/qla_nvme.c
+++ b/drivers/scsi/qla2xxx/qla_nvme.c
@@ -139,11 +139,12 @@ static void qla_nvme_release_fcp_cmd_kref(struct kref 
*kref)
sp->priv = NULL;
if (priv->comp_status == QLA_SUCCESS) {
fd->rcv_rsplen = le16_to_cpu(nvme->u.nvme.rsp_pyld_len);
+   fd->status = NVME_SC_SUCCESS;
} else {
fd->rcv_rsplen = 0;
fd->transferred_length = 0;
+   fd->status = NVME_SC_INTERNAL;
}
-   fd->status = 0;
spin_unlock_irqrestore(>cmd_lock, flags);
  
  	fd->done(fd);




Makes sense.

Reviewed-by: Himanshu Madhani 

--
Himanshu Madhani Oracle Linux Engineering

[PATCH 1/4] iommu/arm-smmu-v3: Fix trivial typo

[John Garry]

Set "cmq" -> "cmdq".

Signed-off-by: John Garry 
---
 drivers/iommu/arm-smmu-v3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index f578677a5c41..a8e814c652fe 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1479,7 +1479,7 @@ static int arm_smmu_cmdq_issue_cmdlist(struct 
arm_smmu_device *smmu,
}
 
/*
-* Try to unlock the cmq lock. This will fail if we're the last
+* Try to unlock the cmdq lock. This will fail if we're the last
 * reader, in which case we can safely update cmdq->q.llq.cons
 */
if (!arm_smmu_cmdq_shared_tryunlock(cmdq)) {
-- 
2.26.2

[PATCH v3 2/3] ARM: dts: change AM33XX_PADCONF macro separate conf and mux

[Drew Fustini]

AM33XX_PADCONF macro is modified to keep pin conf and pin mux separate.

This requires #pinctrl-cells = 2 in am33xx-l4.dtsi

pinctrl-single.c but also be changed to support "pinctrl-single,pins"
with 3 arguments (offset, conf, mux)

Signed-off-by: Drew Fustini 
---
 include/dt-bindings/pinctrl/omap.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/dt-bindings/pinctrl/omap.h 
b/include/dt-bindings/pinctrl/omap.h
index 625718042413..2d2a8c737822 100644
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -65,7 +65,7 @@
 #define DM814X_IOPAD(pa, val)  OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
 #define DM816X_IOPAD(pa, val)  OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
 #define AM33XX_IOPAD(pa, val)  OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
-#define AM33XX_PADCONF(pa, dir, mux)   OMAP_IOPAD_OFFSET((pa), 0x0800) ((dir) 
| (mux))
+#define AM33XX_PADCONF(pa, conf, mux)  OMAP_IOPAD_OFFSET((pa), 0x0800) (conf) 
(mux)
 
 /*
  * Macros to allow using the offset from the padconf physical address
-- 
2.25.1

[PATCH 0/4] iommu/arm-smmu-v3: Improve cmdq lock efficiency

[John Garry]

As mentioned in [0], the CPU may consume many cycles processing
arm_smmu_cmdq_issue_cmdlist(). One issue we find is the cmpxchg() loop to
get space on the queue takes approx 25% of the cycles for this function.

This series removes that cmpxchg().

For my NVMe test with 3x NVMe SSDs, I'm getting a ~24% throughput
increase:
Before: 1310 IOPs
After: 1630 IOPs

I also have a test harness to check the rate of DMA map+unmaps we can
achieve:

CPU count   32  64  128
Before: 63187   19418   10169
After:  93287   44789   15862

(unit is map+unmaps per CPU per second)

[0] 
https://lore.kernel.org/linux-iommu/b926444035e5e2439431908e3842afd24b8...@dggemi525-mbs.china.huawei.com/T/#ma02e301c38c3e94b7725e685757c27e39c7cbde3

John Garry (4):
  iommu/arm-smmu-v3: Fix trivial typo
  iommu/arm-smmu-v3: Calculate bits for prod and owner
  iommu/arm-smmu-v3: Always issue a CMD_SYNC per batch
  iommu/arm-smmu-v3: Remove cmpxchg() in arm_smmu_cmdq_issue_cmdlist()

 drivers/iommu/arm-smmu-v3.c | 233 +++-
 1 file changed, 151 insertions(+), 82 deletions(-)

-- 
2.26.2

[PATCH 3/4] iommu/arm-smmu-v3: Always issue a CMD_SYNC per batch

[John Garry]

To ensure that a CPU does not send more than a permitted amount of commands
to the cmdq, ensure that each batch includes a CMD_SYNC. When issuing a
CMD_SYNC, we always wait for the consumption of its batch of commands - as
such, we guarantee that any CPU will not issue more than its permitted
amount.

Signed-off-by: John Garry 
---
 drivers/iommu/arm-smmu-v3.c | 86 +
 1 file changed, 39 insertions(+), 47 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 4e9677b066f1..45a39ccaf455 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1373,11 +1373,15 @@ static void arm_smmu_cmdq_write_entries(struct 
arm_smmu_cmdq *cmdq, u64 *cmds,
  * - Command insertion is totally ordered, so if two CPUs each race to
  *   insert their own list of commands then all of the commands from one
  *   CPU will appear before any of the commands from the other CPU.
+ *
+ * - A CMD_SYNC is always inserted, ensuring that any CPU does not issue
+ *   more than the permitted amount commands at once.
  */
 static int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
-  u64 *cmds, int n, bool sync)
+  u64 *cmds, int n)
 {
u64 cmd_sync[CMDQ_ENT_DWORDS];
+   const int sync = 1;
u32 prod;
unsigned long flags;
bool owner;
@@ -1419,19 +1423,17 @@ static int arm_smmu_cmdq_issue_cmdlist(struct 
arm_smmu_device *smmu,
 * Dependency ordering from the cmpxchg() loop above.
 */
arm_smmu_cmdq_write_entries(cmdq, cmds, llq.prod, n);
-   if (sync) {
-   prod = queue_inc_prod_n(, n);
-   arm_smmu_cmdq_build_sync_cmd(cmd_sync, smmu, prod);
-   queue_write(Q_ENT(>q, prod), cmd_sync, CMDQ_ENT_DWORDS);
 
-   /*
-* In order to determine completion of our CMD_SYNC, we must
-* ensure that the queue can't wrap twice without us noticing.
-* We achieve that by taking the cmdq lock as shared before
-* marking our slot as valid.
-*/
-   arm_smmu_cmdq_shared_lock(cmdq);
-   }
+   prod = queue_inc_prod_n(, n);
+   arm_smmu_cmdq_build_sync_cmd(cmd_sync, smmu, prod);
+   queue_write(Q_ENT(>q, prod), cmd_sync, CMDQ_ENT_DWORDS);
+
+   /*
+* In order to determine completion of our CMD_SYNC, we must ensure
+* that the queue can't wrap twice without us noticing. We achieve that
+* by taking the cmdq lock as shared before marking our slot as valid.
+*/
+   arm_smmu_cmdq_shared_lock(cmdq);
 
/* 3. Mark our slots as valid, ensuring commands are visible first */
dma_wmb();
@@ -1468,26 +1470,21 @@ static int arm_smmu_cmdq_issue_cmdlist(struct 
arm_smmu_device *smmu,
atomic_set_release(>owner_prod, prod);
}
 
-   /* 5. If we are inserting a CMD_SYNC, we must wait for it to complete */
-   if (sync) {
-   llq.prod = queue_inc_prod_n(, n);
-   ret = arm_smmu_cmdq_poll_until_sync(smmu, );
-   if (ret) {
-   dev_err_ratelimited(smmu->dev,
-   "CMD_SYNC timeout at 0x%08x [hwprod 
0x%08x, hwcons 0x%08x]\n",
-   llq.prod,
-   readl_relaxed(cmdq->q.prod_reg),
-   readl_relaxed(cmdq->q.cons_reg));
-   }
+   /* 5. Since we always insert a CMD_SYNC, we must wait for it to 
complete */
+   llq.prod = queue_inc_prod_n(, n);
+   ret = arm_smmu_cmdq_poll_until_sync(smmu, );
+   if (ret)
+   dev_err_ratelimited(smmu->dev, "CMD_SYNC timeout at 0x%08x 
[hwprod 0x%08x, hwcons 0x%08x]\n",
+   llq.prod, readl_relaxed(cmdq->q.prod_reg),
+   readl_relaxed(cmdq->q.cons_reg));
 
-   /*
-* Try to unlock the cmdq lock. This will fail if we're the last
-* reader, in which case we can safely update cmdq->q.llq.cons
-*/
-   if (!arm_smmu_cmdq_shared_tryunlock(cmdq)) {
-   WRITE_ONCE(cmdq->q.llq.cons, llq.cons);
-   arm_smmu_cmdq_shared_unlock(cmdq);
-   }
+   /*
+* Try to unlock the cmdq lock. This will fail if we're the last reader,
+* in which case we can safely update cmdq->q.llq.cons
+*/
+   if (!arm_smmu_cmdq_shared_tryunlock(cmdq)) {
+   WRITE_ONCE(cmdq->q.llq.cons, llq.cons);
+   arm_smmu_cmdq_shared_unlock(cmdq);
}
 
local_irq_restore(flags);
@@ -1505,12 +1502,7 @@ static int arm_smmu_cmdq_issue_cmd(struct 
arm_smmu_device *smmu,
return -EINVAL;
}
 
-   return 

[PATCH v3 3/3] ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2

[Drew Fustini]

This requires AM33XX_PADCONF macro in omap.h to be modified to keep pin
conf and pin mux values separate.

pinctrl-single.c must also be changed to support "pinctrl-single,pins"
with 3 arguments (offset, conf, mux).

Signed-off-by: Drew Fustini 
---
 arch/arm/boot/dts/am33xx-l4.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
index 7ff11d6bf0f2..dafd6e8b42a1 100644
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/am33xx-l4.dtsi
@@ -278,7 +278,7 @@ scm: scm@0 {
am33xx_pinmux: pinmux@800 {
compatible = "pinctrl-single";
reg = <0x800 0x238>;
-   #pinctrl-cells = <1>;
+   #pinctrl-cells = <2>;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x7f>;
};
-- 
2.25.1

[PATCH 4/4] iommu/arm-smmu-v3: Remove cmpxchg() in arm_smmu_cmdq_issue_cmdlist()

[John Garry]

It has been shown that the cmpxchg() for finding space in the cmdq can
be a bottleneck:
- for more CPUs contending the cmdq, the cmpxchg() will fail more often
- since the software-maintained cons pointer is updated on the same 64b
  memory region, the chance of cmpxchg() failure increases again

The cmpxchg() is removed as part of 2 related changes:

- Update prod and cmdq owner in a single atomic add operation. For this, we
  count the prod and owner in separate regions in prod memory.

  As with simple binary counting, once the prod+wrap fields overflow, they
  will zero. They should never overflow into "owner" region, and we zero
  the non-owner, prod region for each owner. This maintains the prod
  pointer.

  As for the "owner", we now count this value, instead of setting a flag.
  Similar to before, once the owner has finished gathering, it will clear
  a mask. As such, a CPU declares itself as the "owner" when it reads zero
  for this region. This zeroing will also clear possible overflow in
  wrap+prod region, above.

  The owner is now responsible for all cmdq locking to avoid possible
  deadlock. The owner will lock the cmdq for all non-owers it has gathered
  when they have space in the queue and have written their entries.

- Check for space in the cmdq after the prod pointer has been assigned.

  We don't bother checking for space in the cmdq before assigning the prod
  pointer, as this would be racy.

  So since the prod pointer is updated unconditionally, it would be common
  for no space to be available in the cmdq when prod is assigned - that
  is, according the software-maintained prod and cons pointer. So now
  it must be ensured that the entries are not yet written and not until
  there is space.

  How the prod pointer is maintained also leads to a strange condition
  where the prod pointer can wrap past the cons pointer. We can detect this
  condition, and report no space here. However, a prod pointer progressed
  twice past the cons pointer cannot be detected. But it can be ensured that
  this that this scenario does not occur, as we limit the amount of
  commands any CPU can issue at any given time, such that we cannot
  progress prod pointer further.

Signed-off-by: John Garry 
---
 drivers/iommu/arm-smmu-v3.c | 101 ++--
 1 file changed, 61 insertions(+), 40 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 45a39ccaf455..54d056f10bea 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -772,10 +772,19 @@ static bool queue_has_space(struct arm_smmu_ll_queue *q, 
u32 n)
prod = Q_IDX(q, q->prod);
cons = Q_IDX(q, q->cons);
 
-   if (Q_WRP(q, q->prod) == Q_WRP(q, q->cons))
+   if (Q_WRP(q, q->prod) == Q_WRP(q, q->cons)) {
+   /* check if we have wrapped, meaning definitely no space */
+   if (cons > prod)
+   return false;
+
space = (1 << q->max_n_shift) - (prod - cons);
-   else
+   } else {
+   /* similar check to above */
+   if (prod > cons)
+   return false;
+
space = cons - prod;
+   }
 
return space >= n;
 }
@@ -1073,7 +1082,7 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_device 
*smmu)
  *   fails if the caller appears to be the last lock holder (yes, this is
  *   racy). All successful UNLOCK routines have RELEASE semantics.
  */
-static void arm_smmu_cmdq_shared_lock(struct arm_smmu_cmdq *cmdq)
+static void arm_smmu_cmdq_shared_lock(struct arm_smmu_cmdq *cmdq, int count)
 {
int val;
 
@@ -1083,12 +1092,12 @@ static void arm_smmu_cmdq_shared_lock(struct 
arm_smmu_cmdq *cmdq)
 * to INT_MIN so these increments won't hurt as the value will remain
 * negative.
 */
-   if (atomic_fetch_inc_relaxed(>lock) >= 0)
+   if (atomic_fetch_add_relaxed(count, >lock) >= 0)
return;
 
do {
val = atomic_cond_read_relaxed(>lock, VAL >= 0);
-   } while (atomic_cmpxchg_relaxed(>lock, val, val + 1) != val);
+   } while (atomic_cmpxchg_relaxed(>lock, val, val + count) != val);
 }
 
 static void arm_smmu_cmdq_shared_unlock(struct arm_smmu_cmdq *cmdq)
@@ -1374,8 +1383,10 @@ static void arm_smmu_cmdq_write_entries(struct 
arm_smmu_cmdq *cmdq, u64 *cmds,
  *   insert their own list of commands then all of the commands from one
  *   CPU will appear before any of the commands from the other CPU.
  *
- * - A CMD_SYNC is always inserted, ensuring that any CPU does not issue
- *   more than the permitted amount commands at once.
+ * - A CMD_SYNC is always inserted, which ensures we limit the prod pointer
+ *   for when the cmdq is full, such that we don't wrap more than twice.
+ *   It also makes it easy for the owner to know by how many to increment the
+ *   cmdq lock.
  */
 static int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,

Re: [PATCH v6 16/19] mm: memcg/slab: remove redundant check in memcg_accumulate_slabinfo()

[Shakeel Butt]

On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin  wrote:
>
> memcg_accumulate_slabinfo() is never called with a non-root
> kmem_cache as a first argument, so the is_root_cache(s) check
> is redundant and can be removed without any functional change.
>
> Signed-off-by: Roman Gushchin 
> Reviewed-by: Vlastimil Babka 

Reviewed-by: Shakeel Butt 

[PATCH 2/4] iommu/arm-smmu-v3: Calculate bits for prod and owner

[John Garry]

Since the arm_smmu_ll_queue.prod will be for counting the "owner" value
and also HW prod pointer, calculate how many bits are available for and
used by each.

This is based on the number of possible CPUs in the system. And we require
that each CPU can issue a minimum of 2 commands per batch - 1 x CMD_SYNC
and at least 1 x other.

Ignoring limits of HW max_n_shift and HW cmdq memory allocation, approx 32K
is the max supported CPUs. For this, max_n_shift would be 15.

Signed-off-by: John Garry 
---
 drivers/iommu/arm-smmu-v3.c | 64 ++---
 1 file changed, 60 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index a8e814c652fe..4e9677b066f1 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -532,6 +532,8 @@ struct arm_smmu_ll_queue {
u8  __pad[SMP_CACHE_BYTES];
} cacheline_aligned_in_smp;
u32 max_n_shift;
+   u32 max_cmd_per_batch;
+   u32 owner_count_shift;
 };
 
 struct arm_smmu_queue {
@@ -1515,7 +1517,10 @@ static void arm_smmu_cmdq_batch_add(struct 
arm_smmu_device *smmu,
struct arm_smmu_cmdq_batch *cmds,
struct arm_smmu_cmdq_ent *cmd)
 {
-   if (cmds->num == CMDQ_BATCH_ENTRIES) {
+   struct arm_smmu_cmdq *q = >cmdq;
+   struct arm_smmu_ll_queue *llq = >q.llq;
+
+   if (cmds->num == llq->max_cmd_per_batch) {
arm_smmu_cmdq_issue_cmdlist(smmu, cmds->cmds, cmds->num, false);
cmds->num = 0;
}
@@ -3177,6 +3182,58 @@ static int arm_smmu_init_one_queue(struct 
arm_smmu_device *smmu,
return 0;
 }
 
+static int arm_smmu_init_cmd_queue(struct arm_smmu_device *smmu,
+  struct arm_smmu_queue *q,
+  unsigned long prod_off,
+  unsigned long cons_off,
+  size_t dwords)
+{
+   u32 cpus = num_possible_cpus(), bits_for_cmdq_owner,
+   bits_available_for_prod, entries_for_prod;
+   int ret;
+
+   /*
+* We can get the number of bits required for owner counting by
+* log2(nr possible cpus) + 1
+*/
+   bits_for_cmdq_owner = ilog2(cpus) + 1;
+
+   /*
+* Add an extra bit to ensure prod(+wrap) do not overflow into
+* owner count.
+*/
+   bits_available_for_prod = 32 - 1 - bits_for_cmdq_owner;
+
+   if (bits_available_for_prod < 1) /* How many CPUs??? */
+   return -ENOMEM;
+
+   q->llq.max_n_shift = min(q->llq.max_n_shift, bits_available_for_prod);
+
+   ret = arm_smmu_init_one_queue(smmu, q, prod_off, cons_off, dwords,
+ "cmdq");
+   if (ret)
+   return ret;
+
+   entries_for_prod = 1 << q->llq.max_n_shift;
+
+   /*
+* We need at least 2 commands in a batch (1 x CMD_SYNC and 1 x
+* whatever else).
+*/
+   if (entries_for_prod < 2 * cpus)
+   return -ENOMEM;
+
+   /*
+* When finding max_cmd_per_batch, deduct 1 entry per batch to take
+* account of CMD_SYNC
+*/
+   q->llq.max_cmd_per_batch = min((entries_for_prod / cpus) - 1,
+  (u32)CMDQ_BATCH_ENTRIES);
+   q->llq.owner_count_shift = q->llq.max_n_shift + 2;
+
+   return 0;
+}
+
 static void arm_smmu_cmdq_free_bitmap(void *data)
 {
unsigned long *bitmap = data;
@@ -3210,9 +3267,8 @@ static int arm_smmu_init_queues(struct arm_smmu_device 
*smmu)
int ret;
 
/* cmdq */
-   ret = arm_smmu_init_one_queue(smmu, >cmdq.q, ARM_SMMU_CMDQ_PROD,
- ARM_SMMU_CMDQ_CONS, CMDQ_ENT_DWORDS,
- "cmdq");
+   ret = arm_smmu_init_cmd_queue(smmu, >cmdq.q, ARM_SMMU_CMDQ_PROD,
+ ARM_SMMU_CMDQ_CONS, CMDQ_ENT_DWORDS);
if (ret)
return ret;
 
-- 
2.26.2

Re: [PATCH] Revert "kernel/printk: add kmsg SEEK_CUR handling"

[Linus Torvalds]

On Mon, Jun 22, 2020 at 10:10 AM Bruno Meneguele  wrote:
>
> Although both options are pretty fine by me too, I "fear" (not really)
> we can end up stacking special behavior interfaces, forcing userspace to
> keep a "table of special case files". Personally, I prefer to return
> something _valid_ to userspace rather than _fail_ with special meaning.

Well, what's even worse if user space has to handle two different
things just because behavior changed in different kernels..

So at some point "odd behavior" is much better than "odd behavior in
two different ways"..

Linus

[PATCH v3 1/3] pinctrl: single: parse #pinctrl-cells = 2

[Drew Fustini]

If "pinctrl-single,pins" has 3 arguments (offset, conf, mux) then
pcs_parse_one_pinctrl_entry() does an OR operation on to get the
value to store in the register.

Signed-off-by: Drew Fustini 
---
 drivers/pinctrl/pinctrl-single.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index a9d511982780..17b32cafe5f0 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1017,10 +1017,17 @@ static int pcs_parse_one_pinctrl_entry(struct 
pcs_device *pcs,
break;
}
 
-   /* Index plus one value cell */
offset = pinctrl_spec.args[0];
vals[found].reg = pcs->base + offset;
-   vals[found].val = pinctrl_spec.args[1];
+
+   switch (pinctrl_spec.args_count) {
+   case 2:
+   vals[found].val = pinctrl_spec.args[1];
+   break;
+   case 3:
+   vals[found].val = (pinctrl_spec.args[1] | 
pinctrl_spec.args[2]);
+   break;
+   }
 
dev_dbg(pcs->dev, "%pOFn index: 0x%x value: 0x%x\n",
pinctrl_spec.np, offset, pinctrl_spec.args[1]);
-- 
2.25.1

[PATCH v3 0/3] pinctrl: single: support #pinctrl-cells = 2

[Drew Fustini]

Currently, pinctrl-single only allows #pinctrl-cells = 1.

This series will allow pinctrl-single to also support #pinctrl-cells = 2

If "pinctrl-single,pins" has 3 arguments (offset, conf, mux) then
pcs_parse_one_pinctrl_entry() does an OR operation on to get the
value to store in the register.

To take advantage of #pinctrl-cells = 2, the AM33XX_PADCONF macro in
omap.h is modified to keep pin conf and pin mux values separate.

change log:
- v3: change order of patches to make sure the pinctrl-single.c patch
  does not break anything without the dts patches

- v2: remove outer parentheses from AM33XX_PADCONF macro as it causes a
  compile error in dtc.  I had added it per suggestion from checkpatch
  about having parentheses around complex values.

Drew Fustini (3):
  pinctrl: single: parse #pinctrl-cells = 2
  ARM: dts: change AM33XX_PADCONF macro separate conf and mux
  ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2

 arch/arm/boot/dts/am33xx-l4.dtsi   |  2 +-
 drivers/pinctrl/pinctrl-single.c   | 11 +--
 include/dt-bindings/pinctrl/omap.h |  2 +-
 3 files changed, 11 insertions(+), 4 deletions(-)

-- 
2.25.1

Re: [PATCH v2] dma-pool: Fix too large DMA pools on medium systems

[Christoph Hellwig]

On Mon, Jun 22, 2020 at 05:07:55PM +0100, Robin Murphy wrote:
> Another angle, though, is to question why this driver is making such a 
> large allocation with GFP_ATOMIC in the first place. At a glance it looks 
> like there's no reason at all other than that it's still using the legacy 
> pci_alloc_consistent() API, since every path to that appears to have 
> CAN_SLEEP passed as its flag - modernising that would arguably be an even 
> better long-term win.

Maybe we can just try that for now?  If other problems show up we
can still increase the initial pool size later in this cycle.

I'll try to cook up a patch.

UART/TTY console deadlock

[Raul Rangel]

We are trying an S3 suspend stress test and occasionally while
entering S3 we get a console deadlock. Is this a known issue? I'm not
really sure why a probe would be happening while suspending.

The kernel command line is `console=ttyS0` and kernel 5.4.39.

Here is the log:

[  278.885831] leds mmc0::: calling led_resume+0x0/0x1c @ 3909,
parent: :02:00.0
[  278.885835] leds mmc0::: led_resume+0x0/0x1c returned 0 after 0 usecs
[  278.890230]  secondary_startup_64+0xa4/0xb0
[  278.890236] handlers:
[  279.752138] [] i8042_interrupt
[  279.756915] Disabling IRQ #1
[  279.759801]
[  279.759802] ==
[  279.759803] WARNING: possible circular locking dependency detected
[  279.759803] 5.4.39 #55 Not tainted
[  279.759804] --
[  279.759804] swapper/0/0 is trying to acquire lock:
[  279.759805] ab65b6c0 (console_owner){-...}, at:
console_lock_spinning_enable+0x31/0x57
[  279.759806]
[  279.759807] but task is already holding lock:
[  279.759807] 88810a8e34c0 (_desc_lock_class){-.-.}, at:
__report_bad_irq+0x5b/0xba
[  279.759809]
[  279.759809] which lock already depends on the new lock.
[  279.759810]
[  279.759810]
[  279.759811] the existing dependency chain (in reverse order) is:
[  279.759811]
[  279.759811] -> #2 (_desc_lock_class){-.-.}:
[  279.759813]_raw_spin_lock_irqsave+0x61/0x8d
[  279.759813]__irq_get_desc_lock+0x65/0x89
[  279.759814]__disable_irq_nosync+0x3b/0x93
[  279.759814]serial8250_do_startup+0x451/0x75c
[  279.759815]uart_startup+0x1b4/0x2ff
[  279.759815]uart_port_activate+0x73/0xa0
[  279.759815]tty_port_open+0xae/0x10a
[  279.759816]uart_open+0x1b/0x26
[  279.759816]tty_open+0x24d/0x3a0
[  279.759817]chrdev_open+0xd5/0x1cc
[  279.759817]do_dentry_open+0x299/0x3c8
[  279.759817]path_openat+0x434/0x1100
[  279.759818]do_filp_open+0x9b/0x10a
[  279.759818]do_sys_open+0x15f/0x3d7
[  279.759819]kernel_init_freeable+0x157/0x1dd
[  279.759819]kernel_init+0xe/0x105
[  279.759819]ret_from_fork+0x27/0x50
[  279.759820]
[  279.759820] -> #1 (_lock_key){-.-.}:
[  279.759822]_raw_spin_lock_irqsave+0x61/0x8d
[  279.759822]serial8250_console_write+0xa7/0x2a0
[  279.759823]console_unlock+0x3b7/0x528
[  279.759823]vprintk_emit+0x111/0x17f
[  279.759823]printk+0x59/0x73
[  279.759824]register_console+0x336/0x3a4
[  279.759824]uart_add_one_port+0x51b/0x5be
[  279.759825]serial8250_register_8250_port+0x454/0x55e
[  279.759825]dw8250_probe+0x4dc/0x5b9
[  279.759825]platform_drv_probe+0x67/0x8b
[  279.759826]really_probe+0x14a/0x422
[  279.759826]driver_probe_device+0x66/0x130
[  279.759827]device_driver_attach+0x42/0x5b
[  279.759827]__driver_attach+0xca/0x139
[  279.759827]bus_for_each_dev+0x97/0xc9
[  279.759828]bus_add_driver+0x12b/0x228
[  279.759828]driver_register+0x64/0xed
[  279.759829]do_one_initcall+0x20c/0x4a6
[  279.759829]do_initcall_level+0xb5/0xc5
[  279.759829]do_basic_setup+0x4c/0x58
[  279.759830]kernel_init_freeable+0x13f/0x1dd
[  279.759830]kernel_init+0xe/0x105
[  279.759831]ret_from_fork+0x27/0x50
[  279.759831]
[  279.759831] -> #0 (console_owner){-...}:
[  279.759833]__lock_acquire+0x118d/0x2714
[  279.759833]lock_acquire+0x203/0x258
[  279.759834]console_lock_spinning_enable+0x51/0x57
[  279.759834]console_unlock+0x25d/0x528
[  279.759834]vprintk_emit+0x111/0x17f
[  279.759835]printk+0x59/0x73
[  279.759835]__report_bad_irq+0xa3/0xba
[  279.759836]note_interrupt+0x19a/0x1d6
[  279.759836]handle_irq_event_percpu+0x57/0x79
[  279.759836]handle_irq_event+0x36/0x55
[  279.759837]handle_fasteoi_irq+0xc2/0x18a
[  279.759837]do_IRQ+0xb3/0x157
[  279.759838]ret_from_intr+0x0/0x1d
[  279.759838]cpuidle_enter_state+0x12f/0x1fd
[  279.759838]cpuidle_enter+0x2e/0x3d
[  279.759839]do_idle+0x1ce/0x2ce
[  279.759839]cpu_startup_entry+0x1d/0x1f
[  279.759840]start_kernel+0x406/0x46a
[  279.759840]secondary_startup_64+0xa4/0xb0
[  279.759840]
[  279.759841] other info that might help us debug this:
[  279.759841]
[  279.759841] Chain exists of:
[  279.759842]   console_owner --> _lock_key --> _desc_lock_class
[  279.759844]
[  279.759844]  Possible unsafe locking scenario:
[  279.759845]
[  279.759845]CPU0CPU1
[  279.759845]
[  279.759846]   lock(_desc_lock_class);
[  279.759847]lock(_lock_key);
[  279.759848]lock(_desc_lock_class);
[  279.759849]   lock(console_owner);
[  

Re: [PATCH] Replace HTTP links with HTTPS ones: Documentation/process

[Joe Perches]

On Mon, 2020-06-22 at 19:03 +0200, Miguel Ojeda wrote:
> On Mon, Jun 22, 2020 at 3:06 PM Jonathan Corbet  wrote:
> > As has been noted elsewhere, checkpatch.pl seems like the appropriate
> > place to make this check.  As for "the entire tree"...if this job gets
> > completed, "git grep" should be a fine way to do that.
> 
> `checkpatch` is not really enforced in many subsystems, no? Further,
> some existing and future HTTP links may support HTTPS later on.
> 
> As for `git grep`, agreed if we reach near 100%. Otherwise, no. In the
> general case, including the code for a task that has some likelihood
> of needing repetition is a safe bet, which is why I suggested it. The
> same script could be also used to check for broken links and related
> maintenance.

scripts/get_maintainer.pl --self-test=links has a reachability test
using wget.

Perhaps a script like that could be used for http:// vs https://

## Link reachability
} elsif (($type eq "W" || $type eq "Q" || $type eq "B") &&
 $value =~ /^https?:/ &&
 ($self_test eq "" || $self_test =~ /\blinks\b/)) {
next if (grep(m@^\Q$value\E$@, @good_links));
my $isbad = 0;
if (grep(m@^\Q$value\E$@, @bad_links)) {
$isbad = 1;
} else {
my $output = `wget --spider -q --no-check-certificate --timeout 
10 --tries 1 $value`;
if ($? == 0) {
push(@good_links, $value);
} else {
push(@bad_links, $value);
$isbad = 1;
}
}
if ($isbad) {
print("$x->{file}:$x->{linenr}: warning: possible bad 
link\t$x->{line}\n");
}

Re: [PATCH v6 13/19] mm: memcg/slab: simplify memcg cache creation

[Shakeel Butt]

On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin  wrote:
>
> Because the number of non-root kmem_caches doesn't depend on the
> number of memory cgroups anymore and is generally not very big,
> there is no more need for a dedicated workqueue.
>
> Also, as there is no more need to pass any arguments to the
> memcg_create_kmem_cache() except the root kmem_cache, it's
> possible to just embed the work structure into the kmem_cache
> and avoid the dynamic allocation of the work structure.
>
> This will also simplify the synchronization: for each root kmem_cache
> there is only one work. So there will be no more concurrent attempts
> to create a non-root kmem_cache for a root kmem_cache: the second and
> all following attempts to queue the work will fail.
>
>
> On the kmem_cache destruction path there is no more need to call the
> expensive flush_workqueue() and wait for all pending works to be
> finished. Instead, cancel_work_sync() can be used to cancel/wait for
> only one work.
>
> Signed-off-by: Roman Gushchin 
> Reviewed-by: Vlastimil Babka 

Why not pre-allocate the non-root kmem_cache at the kmem_cache
creation time? No need for work_struct, queue_work() or
cancel_work_sync() at all.

Re: [PATCH] xfs: Couple of typo fixes in comments

[Darrick J. Wong]

On Sun, Jun 07, 2020 at 03:44:59AM -0400, Keyur Patel wrote:
> ./xfs/libxfs/xfs_inode_buf.c:56: unnecssary ==> unnecessary
> ./xfs/libxfs/xfs_inode_buf.c:59: behavour ==> behaviour
> ./xfs/libxfs/xfs_inode_buf.c:206: unitialized ==> uninitialized
> 
> Signed-off-by: Keyur Patel 

Looks simple enough, though I bet this will have to be rebased against
5.8...

Reviewed-by: Darrick J. Wong 

--D

> ---
>  fs/xfs/libxfs/xfs_inode_buf.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/xfs/libxfs/xfs_inode_buf.c b/fs/xfs/libxfs/xfs_inode_buf.c
> index 6f84ea85fdd8..5c93e8e6de74 100644
> --- a/fs/xfs/libxfs/xfs_inode_buf.c
> +++ b/fs/xfs/libxfs/xfs_inode_buf.c
> @@ -53,10 +53,10 @@ xfs_inobp_check(
>   * If the readahead buffer is invalid, we need to mark it with an error and
>   * clear the DONE status of the buffer so that a followup read will re-read 
> it
>   * from disk. We don't report the error otherwise to avoid warnings during 
> log
> - * recovery and we don't get unnecssary panics on debug kernels. We use EIO 
> here
> + * recovery and we don't get unnecessary panics on debug kernels. We use EIO 
> here
>   * because all we want to do is say readahead failed; there is no-one to 
> report
>   * the error to, so this will distinguish it from a non-ra verifier failure.
> - * Changes to this readahead error behavour also need to be reflected in
> + * Changes to this readahead error behaviour also need to be reflected in
>   * xfs_dquot_buf_readahead_verify().
>   */
>  static void
> @@ -203,7 +203,7 @@ xfs_inode_from_disk(
>   /*
>* First get the permanent information that is needed to allocate an
>* inode. If the inode is unused, mode is zero and we shouldn't mess
> -  * with the unitialized part of it.
> +  * with the uninitialized part of it.
>*/
>   to->di_flushiter = be16_to_cpu(from->di_flushiter);
>   inode->i_generation = be32_to_cpu(from->di_gen);
> -- 
> 2.26.2
> 

Re: [PATCH v2 13/16] mm/debug_vm_pgtable: Remove uninitialized_var() usage

[Nick Desaulniers]

On Fri, Jun 19, 2020 at 8:30 PM Kees Cook  wrote:
>
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings (e.g.
> "unused variable"). If the compiler thinks it is uninitialized, either
> simply initialize the variable or make compiler changes. As a precursor
> to removing[2] this[3] macro[4], just initialize this variable to NULL.
>
> [1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
> [2] 
> https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
> [3] 
> https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
> [4] 
> https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/
>
> Fixes: 399145f9eb6c ("mm/debug: add tests validating architecture page table 
> helpers")
> Signed-off-by: Kees Cook 
> ---
>  mm/debug_vm_pgtable.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
> index e45623016aea..83c9e88a052a 100644
> --- a/mm/debug_vm_pgtable.c
> +++ b/mm/debug_vm_pgtable.c
> @@ -307,7 +307,7 @@ static int __init debug_vm_pgtable(void)
> phys_addr_t paddr;
> unsigned long vaddr, pte_aligned, pmd_aligned;
> unsigned long pud_aligned, p4d_aligned, pgd_aligned;
> -   spinlock_t *uninitialized_var(ptl);
> +   spinlock_t *ptl = NULL;

It looks like the address of ptl is passed to pte_alloc_map_lock.  It
looks like pte_offset_map_lock unconditionally assigns through that
pointer before reading.  So this could be left uninitialized, but
initializing it doesn't hurt.
Reviewed-by: Nick Desaulniers 

>
> pr_info("Validating architecture page table helpers\n");
> prot = vm_get_page_prot(VMFLAGS);
> --

-- 
Thanks,
~Nick Desaulniers

[PATCH v2] ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime

[Bruno Meneguele]

IMA_APPRAISE_BOOTPARAM has been marked as dependent on !IMA_ARCH_POLICY in
compile time, enforcing the appraisal whenever the kernel had the arch
policy option enabled.

However it breaks systems where the option is actually set but the system
wasn't booted in a "secure boot" platform. In this scenario, anytime the
an appraisal policy (i.e. ima_policy=appraisal_tcb) is used it will be
forced, giving no chance to the user set the 'fix' state (ima_appraise=fix)
to actually measure system's files.

This patch remove this compile time dependency and move it to a runtime
decision, based on the arch policy loading failure/success.

Cc: sta...@vger.kernel.org
Fixes: d958083a8f64 ("x86/ima: define arch_get_ima_policy() for x86")
Signed-off-by: Bruno Meneguele 
---
changes from v1:
- removed "ima:" prefix from pr_info() message

 security/integrity/ima/Kconfig  | 2 +-
 security/integrity/ima/ima_policy.c | 8 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index edde88dbe576..62dc11a5af01 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -232,7 +232,7 @@ config IMA_APPRAISE_REQUIRE_POLICY_SIGS
 
 config IMA_APPRAISE_BOOTPARAM
bool "ima_appraise boot parameter"
-   depends on IMA_APPRAISE && !IMA_ARCH_POLICY
+   depends on IMA_APPRAISE
default y
help
  This option enables the different "ima_appraise=" modes
diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index e493063a3c34..c876617d4210 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -733,11 +733,15 @@ void __init ima_init_policy(void)
 * (Highest priority)
 */
arch_entries = ima_init_arch_policy();
-   if (!arch_entries)
+   if (!arch_entries) {
pr_info("No architecture policies found\n");
-   else
+   } else {
+   /* Force appraisal, preventing runtime xattr changes */
+   pr_info("setting IMA appraisal to enforced\n");
+   ima_appraise = IMA_APPRAISE_ENFORCE;
add_rules(arch_policy_entry, arch_entries,
  IMA_DEFAULT_POLICY | IMA_CUSTOM_POLICY);
+   }
 
/*
 * Insert the builtin "secure_boot" policy rules requiring file
-- 
2.26.2

Re: [PATCH 09/16] mm/hmm: add output flag for compound page mapping

[Jason Gunthorpe]

On Fri, Jun 19, 2020 at 02:56:42PM -0700, Ralph Campbell wrote:
> hmm_range_fault() returns an array of page frame numbers and flags for
> how the pages are mapped in the requested process' page tables. The PFN
> can be used to get the struct page with hmm_pfn_to_page() and the page size
> order can be determined with compound_order(page) but if the page is larger
> than order 0 (PAGE_SIZE), there is no indication that the page is mapped
> using a larger page size. To be fully general, hmm_range_fault() would need
> to return the mapping size to handle cases like a 1GB compound page being
> mapped with 2MB PMD entries. However, the most common case is the mapping
> size is the same as the underlying compound page size.
> Add a new output flag to indicate this so that callers know it is safe to
> use a large device page table mapping if one is available.

But what size should the caller use?

You already explained that the caller cannot use compound_ordet() to
get the size, so what should it be?

Probably this needs to be two flags, PUD and PMD, and the caller should
use the PUD and PMD sizes to figure out how big it is?

Jason

Re: [PATCH v2 10/16] KVM: PPC: Book3S PR: Remove uninitialized_var() usage

[Nick Desaulniers]

On Fri, Jun 19, 2020 at 8:30 PM Kees Cook  wrote:
>
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings (e.g.
> "unused variable"). If the compiler thinks it is uninitialized, either
> simply initialize the variable or make compiler changes. As a precursor
> to removing[2] this[3] macro[4], just remove this variable since it was
> actually unused:
>
> arch/powerpc/kvm/book3s_pr.c:1832:16: warning: unused variable 'vrsave' 
> [-Wunused-variable]
> unsigned long vrsave;
>   ^
>
> [1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
> [2] 
> https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
> [3] 
> https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
> [4] 
> https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/
>
> Suggested-by: Nathan Chancellor 
> Fixes: f05ed4d56e9c ("KVM: PPC: Split out code from book3s.c into 
> book3s_pr.c")
> Signed-off-by: Kees Cook 

Reviewed-by: Nick Desaulniers 

> ---
>  arch/powerpc/kvm/book3s_pr.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index ef54f917bdaf..ed12dfbf9bb5 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -1828,9 +1828,6 @@ static int kvmppc_vcpu_run_pr(struct kvm_vcpu *vcpu)
>  {
> struct kvm_run *run = vcpu->run;
> int ret;
> -#ifdef CONFIG_ALTIVEC
> -   unsigned long uninitialized_var(vrsave);
> -#endif
>
> /* Check if we can run the vcpu at all */
> if (!vcpu->arch.sane) {
> --

-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 08/16] nouveau/hmm: fault one page at a time

[Jason Gunthorpe]

On Fri, Jun 19, 2020 at 02:56:41PM -0700, Ralph Campbell wrote:
> The SVM page fault handler groups faults into a range of contiguous
> virtual addresses and requests hmm_range_fault() to populate and
> return the page frame number of system memory mapped by the CPU.
> In preparation for supporting large pages to be mapped by the GPU,
> process faults one page at a time. In addition, use the hmm_range
> default_flags to fix a corner case where the input hmm_pfns array
> is not reinitialized after hmm_range_fault() returns -EBUSY and must
> be called again.

Are you sure? hmm_range_fault is pretty expensive per call..

Jason

Re: [PATCH] docs: f2fs: fix a broken table

[Jonathan Corbet]

On Mon, 22 Jun 2020 10:11:06 -0700
Eric Biggers  wrote:

> Someone already sent out a fix for this:
> https://lkml.kernel.org/linux-doc/52f851cb5c9fd2ecae97deec7e168e66b8c295c3.1591137229.git.mchehab+hua...@kernel.org/
> 
> Is it intentional that you're sending out a different fix rather than applying
> that one?

It wasn't, actually, I'm just finding myself more than usually challenged
these days.

That said, removing the table entirely seems ... excessive.  It's not
terrible the way it is, or we could make it:

test_dummy_encryption[=%s]

if we really want to.

jon

Important Notification.

[Cephas Agbeh]

I am bringing this notice to your attention in respect of the death of
a deceased client of mine that has the same surname with you and his
fund valued at $19.9M to be paid to you.contact me at
cephasagb...@gmail.com for more details.

Yours Sincerely,
Cephas Agbeh,
Attorney At Law.

Re: [PATCH][v2] PM / s2idle: Clear _TIF_POLLING_NRFLAG before suspend to idle

[Chen Yu]

Hi Rafael,
On Mon, Jun 22, 2020 at 06:19:35PM +0200, Rafael J. Wysocki wrote:
[cut]
> > +{
> > +   if (!current_clr_polling_and_test())
> > +   s2idle_enter(drv, dev, index);
> > +
> > +   return index;
> 
> Is the value returned here used at all?
>
It is not used for now IMO.
> >  */
> > index = find_deepest_state(drv, dev, U64_MAX, 0, true);
> > if (index > 0)
> > -   enter_s2idle_proper(drv, dev, index);
> > +   call_s2idle(drv, dev, index);
> 
> I'm wondering why this can't be
> 
> if (index > 0 && !current_clr_polling_and_test())
> enter_s2idle_proper(drv, dev, index);
> 
Yes, it should be simpler, but I guess Peter was trying to
make call_s2idle() consistent with call_cpuidle(),
and also s2idle_enter() is analogous to cpuidle_enter().

Thanks,
Chenyu

Re: [PATCH] proc: Avoid a thundering herd of threads freeing proc dentries

[Junxiao Bi]

On 6/22/20 8:20 AM, ebied...@xmission.com wrote:


If I understand correctly, the Java VM is not exiting.  Just some of
it's threads.

That is a very different problem to deal with.  That are many
optimizations that are possible when_all_  of the threads are exiting
that are not possible when_many_  threads are exiting.

Do you know if it is simply the cpu time or if it is the lock contention
that is the problem?  If it is simply the cpu time we should consider if
some of the locks that can be highly contended should become mutexes.
Or perhaps something like Matthew's cpu pinning idea.


The problem is high %sys time.

Thanks,

Junxiao.

Re: [PATCH v6 10/19] mm: memcg/slab: deprecate memory.kmem.slabinfo

[Shakeel Butt]

On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin  wrote:
>
> Deprecate memory.kmem.slabinfo.
>
> An empty file will be presented if corresponding config options are
> enabled.
>
> The interface is implementation dependent, isn't present in cgroup v2,
> and is generally useful only for core mm debugging purposes. In other
> words, it doesn't provide any value for the absolute majority of users.
>
> A drgn-based replacement can be found in tools/cgroup/slabinfo.py .
> It does support cgroup v1 and v2, mimics memory.kmem.slabinfo output
> and also allows to get any additional information without a need
> to recompile the kernel.
>
> If a drgn-based solution is too slow for a task, a bpf-based tracing
> tool can be used, which can easily keep track of all slab allocations
> belonging to a memory cgroup.
>
> Signed-off-by: Roman Gushchin 
> Acked-by: Johannes Weiner 
> Reviewed-by: Vlastimil Babka 

Hi Roman,

I am not against removing the memory.kmem.slabinfo interface but I
would like to have an alternative solution more accessible than
tools/cgroup/slabinfo.py.

In our case, we don't have ssh access and if we need something for
debugging, it is much more preferable to provide a file to read to
SREs. After the review, that file will be added to a whitelist and
then we can directly read that file through automated tools without
approval for each request.

I am just wondering if a file interface can be provided for whatever
tools/cgroup/slabinfo.py is providing.

Shakeel

Re: [PATCH 2/2] selftests/fpu: Add an FPU selftest

[Borislav Petkov]

On Fri, Jun 19, 2020 at 11:00:28AM -0700, Andy Lutomirski wrote:
> This should be cc-option, not cc-ifversion, I think.

Why?

> But maybe we should consider dropping the problematic GCC version
> instead? The old GCC versions with stack alignment problems are
> seriously problematic for x86 kernels, and I don't really trust
> kernels built with them.

Can't - we just upped min gcc version to 4.8:

5429ef62bcf3 ("compiler/gcc: Raise minimum GCC version for kernel builds to 
4.8")

I mean we could but everytime we do that, it is all a big bikeshedding
discussion. Even though almost everyone is using gcc9 or so to build...

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] docs: f2fs: fix a broken table

[Eric Biggers]

On Mon, Jun 22, 2020 at 07:39:07AM -0600, Jonathan Corbet wrote:
> Commit ed318a6cc0b6 ("fscrypt: support test_dummy_encryption=v2") added an
> entry to the massive option table in Documentation/filesystems/f2fs.txt.
> The option was too wide for the formatting of the table, though, leading to
> a verbose and ugly docs-build warning starting with:
> 
> Documentation/filesystems/f2fs.rst:229: WARNING: Malformed table.
> Text in column margin in table line 126.
> 
> Fixing this requires formatting the whole table; let's hear it for Emacs
> query-replace-regexp.  No changes were made to the actual text.
> 
> Fixes: ed318a6cc0b6 ("fscrypt: support test_dummy_encryption=v2")
> Signed-off-by: Jonathan Corbet 
> ---
>  Documentation/filesystems/f2fs.rst | 312 ++---
>  1 file changed, 156 insertions(+), 156 deletions(-)
> 

Someone already sent out a fix for this:
https://lkml.kernel.org/linux-doc/52f851cb5c9fd2ecae97deec7e168e66b8c295c3.1591137229.git.mchehab+hua...@kernel.org/

Is it intentional that you're sending out a different fix rather than applying
that one?

- Eric

Re: [PATCH v2] USB: Serial: cypress_M8: Enable Simply Automated UPB PIM

[James Hilliard]

On Mon, Jun 22, 2020 at 2:53 AM Johan Hovold  wrote:
>
> On Tue, Jun 16, 2020 at 04:04:03PM -0600, James Hilliard wrote:
> > This is a UPB(Universal Powerline Bus) PIM(Powerline Interface Module)
> > which allows for controlling multiple UPB compatible devices from
> > Linux using the standard serial interface.
> >
> > Based on vendor application source code there are two different models
> > of USB based PIM devices in addition to a number of RS232 based PIM's.
> >
> > The vendor UPB application source contains the following USB ID's:
> > #define USB_PCS_VENDOR_ID 0x04b4
> > #define USB_PCS_PIM_PRODUCT_ID 0x5500
> >
> > #define USB_SAI_VENDOR_ID 0x17dd
> > #define USB_SAI_PIM_PRODUCT_ID 0x5500
> >
> > The first set of ID's correspond to the PIM variant sold by Powerline
> > Control Systems while the second corresponds to the Simply Automated
> > Incorporated PIM. As the product ID for both of these match the default
> > cypress HID->COM RS232 product ID it assumed that they both use an
> > internal variant of this HID->COM RS232 converter hardware. However
> > as the vendor ID for the Simply Automated variant is different we need
> > to also add it to the cypress_M8 driver so that it is properly
> > detected.
> >
> > Signed-off-by: James Hilliard 
> > ---
> > Changes v1 -> v2:
> >   - Add more detailed commit message.
>
> Now applied, thanks.
Oh, FYI I think part of the comment got dropped when you amended the patch
I don't see the defines in the comment here:
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/commit/?h=usb-linus=7527d963dff544b0ddfba4319824c50f2a892aeb

I think I had to temporarily change my git config with this to make it not drop
the defines:
git config core.commentchar "*"
>
> Would you mind posting the output of "lsusb -v" for this device for
> completeness?
>
> Johan

Re: [PATCH] Revert "kernel/printk: add kmsg SEEK_CUR handling"

[Bruno Meneguele]

On Mon, Jun 22, 2020 at 09:42:25AM -0700, Linus Torvalds wrote:
> > Would it make sense to return the next buffer index instead? Basically
> > the same as SEEK_END does? The first "if (offset)" in the function would
> > prevent any real relative move while SEEK_CUR would return a valid
> > address following this buffer behavior of specific points it could seek
> > to.
> 
> Maybe. At the same time, the way we don't actually return a real
> position means that that's very dangerous too. We'll always return
> "we're at position zero".
> 
> And we never accept byte-by-byte reads and require a "get the whole
> record" model.
> 
> So I think we might as well accept "kmsg is special".
> 
> I don't have hugely strong opinions on it - I certainly agree that
> "SEEK_CUR with offset zero could be a no-op", but I also don't think
> there's a huge reason to try to change it, considering just _how_
> special kmsg is.

Although both options are pretty fine by me too, I "fear" (not really)
we can end up stacking special behavior interfaces, forcing userspace to
keep a "table of special case files". Personally, I prefer to return
something _valid_ to userspace rather than _fail_ with special meaning.

But in any case I think it's worth adding a note in the docs just to
make sure we have somewhere to point in case they start looking.

Thanks Linus! Will wait some more in case we have other thoughts around
it before posting anything (doc patch or the other approach).

-- 
bmeneg 
PGP Key: http://bmeneg.com/pubkey.txt


signature.asc
Description: PGP signature

Re: [PATCH 1/2] x86/fpu: Reset MXCSR to default in kernel_fpu_begin()

[Borislav Petkov]

On Fri, Jun 19, 2020 at 11:01:44AM -0700, Andy Lutomirski wrote:
> On Fri, Jun 19, 2020 at 10:41 AM Borislav Petkov  wrote:
> >
> > From: Petteri Aimonen 
> >
> > Previously, kernel floating point code would run with the MXCSR control
> > register value last set by userland code by the thread that was active
> > on the CPU core just before kernel call. This could affect calculation
> > results if rounding mode was changed, or a crash if a FPU/SIMD exception
> > was unmasked.
> >
> > Restore MXCSR to the kernel's default value.
> >
> >  [ bp: Carve out from a bigger patch by Petteri, add feature check, add
> >FNINIT call too (amluto). ]
> 
> Acked-by: Andy Lutomirski 
> 
> but:
> 
> shouldn't kernel_fpu_begin() end with a barrier()?

the "fninit" thing is already asm volatile or do you want the explicit
memory clobber of barrier?

If so, why?

The LDMXCSR and FNINIT have effect only on hardware state...

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 0/2] Allow breaking up Thunderbolt/USB4 updates

[Mika Westerberg]

On Mon, Jun 22, 2020 at 04:41:35PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Mika Westerberg 
> > Sent: Monday, June 22, 2020 11:38 AM
> > To: Limonciello, Mario
> > Cc: Andreas Noever; Michael Jamet; Yehezkel Bernat; 
> > linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 0/2] Allow breaking up Thunderbolt/USB4 updates
> > 
> > 
> > [EXTERNAL EMAIL]
> > 
> > Hi Mario,
> > 
> > On Mon, Jun 22, 2020 at 09:30:33AM -0500, Mario Limonciello wrote:
> > > Currently updates to Thunderbolt and USB4 controllers are fully atomic
> > > actions. When writing into the non-active NVM nothing gets flushed to
> > > the hardware until authenticate is sent.
> > >
> > > There has been some desire to improve the perceived performance of these
> > > updates, particularly for userland that may perform the update upon
> > > a performance sensitive time like logging out.
> > >
> > > So allow userland to flush the image to hardware at runtime, and then
> > > allow authenticating the image at another time.
> > >
> > > For the Dell WD19TB some specific hardware capability exists that allows
> > > extending this to automatically complete the update when unplugged.
> > > Export that functionality to userspace as well.
> > >
> > > This patch series is done relative thunderbolt.git/next.
> > 
> > Thanks for the patch series. I wonder if you could base this on top of
> > my "retimer NVM upgrade" series here (you are also Cc'd):
> > 
> >   https://lore.kernel.org/linux-usb/20200616135617.85752-1-
> > mika.westerb...@linux.intel.com/
> > 
> > That series moves some of the common NVM functionality into a separate
> > file (nvm.c).
> 
> Sure thing.  Do you by chance already have that on a public branch somewhere
> that I can easily rebase it?

I just pushed "bleeding-edge" branch that you should be able to base
your stuff on top:

   
https://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git/log/?h=bleeding-edge

It includes a couple of other patches as well (subject to change since
they are also under review).

Re: [PATCH v1 03/11] soc: mediatek: cmdq: add write_s function

[Matthias Brugger]

On 22/06/2020 18:12, Dennis-YC Hsieh wrote:
> Hi Matthias,
> 
> On Mon, 2020-06-22 at 17:54 +0200, Matthias Brugger wrote:
>>
>> On 22/06/2020 17:36, Dennis-YC Hsieh wrote:
>>> Hi Matthias,
>>>
>>> thanks for your comment.
>>>
>>> On Mon, 2020-06-22 at 13:07 +0200, Matthias Brugger wrote:

 On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> add write_s function in cmdq helper functions which
> writes value contains in internal register to address
> with large dma access support.
>
> Signed-off-by: Dennis YC Hsieh 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |   19 +++
>  include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
>  include/linux/soc/mediatek/mtk-cmdq.h|   19 +++
>  3 files changed, 39 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index bf32e3b2ca6c..817a5a97dbe5 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -18,6 +18,10 @@ struct cmdq_instruction {
>   union {
>   u32 value;
>   u32 mask;
> + struct {
> + u16 arg_c;
> + u16 src_reg;
> + };
>   };
>   union {
>   u16 offset;
> @@ -222,6 +226,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 
> subsys,
>  }
>  EXPORT_SYMBOL(cmdq_pkt_write_mask);
>  
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> +  u16 addr_low, u16 src_reg_idx)
> +{

 Do I understand correctly that we use CMDQ_ADDR_HIGH(addr) and
 CMDQ_ADDR_LOW(addr) to calculate in the client high_addr_reg_idx and 
 addr_low
 respectively?

 In that case I think a better interface would be to pass the address and 
 do the
 high/low calculation in the cmdq_pkt_write_s
>>>
>>> Not exactly. The high_addr_reg_idx parameter is index of internal
>>> register (which store address bit[47:16]), not result of
>>> CMDQ_ADDR_HIGH(addr). 
>>>
>>> The CMDQ_ADDR_HIGH macro use in patch 02/11 cmdq_pkt_assign() api. This
>>> api helps assign address bit[47:16] into one of internal register by
>>> index. And same index could be use in cmdq_pkt_write_s(). The gce
>>> combine bit[47:16] in internal register and bit[15:0] in addr_low
>>> parameter to final address. So it is better to keep interface in this
>>> way.
>>>
>>
>> Got it, but then why don't we call cmdq_pkt_assign() in cmdq_pkt_write_s()? 
>> This
>> way we would get a clean API for what we want to do.
>> Do we expect other users of cmdq_pkt_assign()? Otherwise we could keep it
>> private the this file and don't export it.
> 
> Considering this case: write 2 register 0xaabb00c0 0xaabb00d0.
> 
> If we call assign inside write_s api it will be:
> assign aabb to internal reg 0
> write reg 0 + 0x00c0
> assign aabb to internal reg 0
> write reg 0 + 0x00d0
> 
> 
> But if we let client decide timing to call assign, it will be like:
> assign aabb to internal reg 0
> write reg 0 + 0x00c0
> write reg 0 + 0x00d0
> 

Ok, thanks for clarification. Is this something you exepect to see in the gce
consumer driver?

> 
> The first way uses 4 command and second one uses only 3 command.
> Thus it is better to let client call assign explicitly.
> 
>>
>> By the way, why do you postfix the _s, I understand that it reflects the 
>> large
>> DMA access but I wonder why you choose '_s'.
>>
> 
> The name of this command is "write_s" which is hardware spec.
> I'm just following it since it is a common language between gce sw/hw
> designers.
> 

Ok, I will probably have to look that up every time have a look at the driver,
but that's OK.

Regards,
Matthias

> 
> Regards,
> Dennis
> 
>> Regards,
>> Matthias
>>
>>>
>>> Regards,
>>> Dennis
>>>

 Regards,
 Matthias

> + struct cmdq_instruction inst = {};
> +
> + inst.op = CMDQ_CODE_WRITE_S;
> + inst.src_t = CMDQ_REG_TYPE;
> + inst.sop = high_addr_reg_idx;
> + inst.offset = addr_low;
> + inst.src_reg = src_reg_idx;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_write_s);
> +
>  int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
>  {
>   struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 121c3bb6d3de..ee67dd3b86f5 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,7 @@ enum cmdq_code {
>   CMDQ_CODE_JUMP = 0x10,
>   CMDQ_CODE_WFE = 0x20,
>   CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_WRITE_S = 0x90,
>   CMDQ_CODE_LOGIC = 0xa0,
>  };
>  
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 

Re: [PATCH 13/19] mm: memcontrol: drop unused try/commit/cancel charge API

[Ben Widawsky]

On 20-05-08 14:31:00, Johannes Weiner wrote:
> There are no more users. RIP in peace.
> 

Would it make sense to update Documentation/admin-guide/cgroup-v1/memcg_test.rst
too? I don't have the history on this file, or why it exists (it does say
implementation details can be changed).

> Signed-off-by: Johannes Weiner 
> Reviewed-by: Joonsoo Kim 
[snip]

Re: [PATCH 2/2] selftests/fpu: Add an FPU selftest

[Borislav Petkov]

On Sun, Jun 21, 2020 at 03:55:00AM +0800, kernel test robot wrote:
> Hi Borislav,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on kselftest/next]
> [also build test ERROR on tip/auto-latest linus/master v5.8-rc1 next-20200618]
> [cannot apply to tip/x86/core]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use  as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:
> https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-FPU-FPU-sanitization-for-in-kernel-use/20200620-014453
> base:   
> https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git next
> config: x86_64-allmodconfig (attached as .config)
> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
> 487ca07fcc75d52755c9fe2ee05bcb3b6c44)
> 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
> # 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 errors (new ones prefixed by >>, old ones prefixed by <<):
> 
> >> ERROR: modpost: "__gtdf2" [lib/test_fpu.ko] undefined!
> >> ERROR: modpost: "__divdf3" [lib/test_fpu.ko] undefined!
> >> ERROR: modpost: "__muldf3" [lib/test_fpu.ko] undefined!
> >> ERROR: modpost: "__adddf3" [lib/test_fpu.ko] undefined!

Hmm, the point here is to actually have SSE* code in a kernel module for
testing. And gcc does the right thing, see below.

LLVM folks, how can I make llvm not call those library functions and
actually spit out SSE* code?

Full build command is:

  /mnt/smr/share/src/llvm/tc-build/install/bin/clang-11 
-Wp,-MMD,lib/.test_fpu.o.d  -nostdinc -isystem 
/mnt/smr/share/src/llvm/tc-build/install/lib/clang/11.0.0/include 
-I./arch/x86/include -I./arch/x86/include/generated  -I./include 
-I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi 
-I./include/generated/uapi -include ./include/linux/kconfig.h -include 
./include/linux/compiler_types.h -D__KERNEL__ -Qunused-arguments -Wall -Wundef 
-Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common 
-fshort-wchar -fno-PIE -Werror=implicit-function-declaration 
-Werror=implicit-int -Wno-format-security -std=gnu89 -no-integrated-as 
-Werror=unknown-warning-option -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx 
-m64 -mno-80387 -mstack-alignment=8 -march=k8 -mno-red-zone -mcmodel=kernel 
-Wno-sign-compare -fno-asynchronous-unwind-tables -mretpoline-external-thunk 
-fno-delete-null-pointer-checks -Wno-frame-address 
-Wno-address-of-packed-member -O2 -Wframe-larger-than=2048 -fstack-protector 
-Wno-format-invalid-specifier -Wno-gnu -mno-global-merge 
-Wno-unused-const-variable -g -DCC_USING_FENTRY -Wdeclaration-after-statement 
-Wvla -Wno-pointer-sign -Wno-array-bounds -fno-strict-overflow 
-fno-merge-all-constants -fno-stack-check -Werror=date-time 
-Werror=incompatible-pointer-types -fmacro-prefix-map=./= -fcf-protection=none 
-Wno-initializer-overrides -Wno-format -Wno-sign-compare 
-Wno-format-zero-length -Wno-pointer-to-enum-cast 
-Wno-tautological-constant-out-of-range-compare -mhard-float -msse  -DMODULE  
-DKBUILD_BASENAME='"test_fpu"' -DKBUILD_MODNAME='"test_fpu"' -c -o 
lib/test_fpu.o lib/test_fpu.c

Thx.

--- /tmp/test_fpu.s.gcc 2020-06-22 18:51:25.828615337 +0200
+++ /tmp/test_fpu.s.llvm-11 2020-06-22 18:50:35.080614534 +0200
@@ -1,74 +1,49 @@
-test_fpu_get:
-   pushq   %r12#
-   pushq   %rbx#
-   movq%rsi, %rbx  # tmp119, val
-   subq$56, %rsp   #,
-# lib/test_fpu.c:58:   kernel_fpu_begin();
-   callkernel_fpu_begin#
-# lib/test_fpu.c:32:   a = 4.0;
-   movlpd  .LC1(%rip), %xmm0   #, tmp106
-   movsd   %xmm0, (%rsp)   # tmp106, a
-# lib/test_fpu.c:33:   b = 1e-15;
-   movlpd  .LC2(%rip), %xmm0   #, tmp107
-   movsd   %xmm0, 8(%rsp)  # tmp107, b
-# lib/test_fpu.c:34:   c = 1e-310;
-   movlpd  .LC3(%rip), %xmm0   #, tmp108
-   movsd   %xmm0, 16(%rsp) # tmp108, c
-# lib/test_fpu.c:37:   d = a + b;
-   movlpd  (%rsp), %xmm0   # a, a.2_8
-   movlpd  8(%rsp), %xmm1  # b, b.3_9
-   addsd   %xmm1, %xmm0# b.3_9, _10
-# lib/test_fpu.c:37:   d = a + b;
-   movsd   %xmm0, 24(%rsp) # _10, d
-# lib/test_fpu.c:40:   e = a + b / 2;
-   movlpd  8(%rsp), %xmm0  # b, b.4_11
-# lib/test_fpu.c:40:   e = a + b / 2;
-   movlpd  (%rsp), %xmm1   # a, a.5_13
-# lib/test_fpu.c:40:   e = a + b / 2;
-   mulsd   .LC4(%rip), %xmm0   #, tmp109
-# lib/test_fpu.c:40:   e = a + b / 2;
-   addsd   %xmm1, %xmm0# 

Re: [PATCH] KVM: x86/mmu: Avoid mixing gpa_t with gfn_t in walk_addr_generic()

[Paolo Bonzini]

On 22/06/20 17:14, Vitaly Kuznetsov wrote:
> translate_gpa() returns a GPA, assigning it to 'real_gfn' seems obviously
> wrong. There is no real issue because both 'gpa_t' and 'gfn_t' are u64 and
> we don't use the value in 'real_gfn' as a GFN, we do
> 
>  real_gfn = gpa_to_gfn(real_gfn);
> 
> instead. 'If you see a "buffalo" sign on an elephant's cage, do not trust
> your eyes', but let's fix it for good.
> 
> No functional change intended.
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
>  arch/x86/kvm/mmu/paging_tmpl.h | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
> index a6d484ea110b..58234bfaca07 100644
> --- a/arch/x86/kvm/mmu/paging_tmpl.h
> +++ b/arch/x86/kvm/mmu/paging_tmpl.h
> @@ -360,7 +360,6 @@ static int FNAME(walk_addr_generic)(struct guest_walker 
> *walker,
>   ++walker->level;
>  
>   do {
> - gfn_t real_gfn;
>   unsigned long host_addr;
>  
>   pt_access = pte_access;
> @@ -375,7 +374,7 @@ static int FNAME(walk_addr_generic)(struct guest_walker 
> *walker,
>   walker->table_gfn[walker->level - 1] = table_gfn;
>   walker->pte_gpa[walker->level - 1] = pte_gpa;
>  
> - real_gfn = mmu->translate_gpa(vcpu, gfn_to_gpa(table_gfn),
> + real_gpa = mmu->translate_gpa(vcpu, gfn_to_gpa(table_gfn),
> nested_access,
> >fault);
>  
> @@ -389,12 +388,10 @@ static int FNAME(walk_addr_generic)(struct guest_walker 
> *walker,
>* information to fix the exit_qualification or exit_info_1
>* fields.
>*/
> - if (unlikely(real_gfn == UNMAPPED_GVA))
> + if (unlikely(real_gpa == UNMAPPED_GVA))
>   return 0;
>  
> - real_gfn = gpa_to_gfn(real_gfn);
> -
> - host_addr = kvm_vcpu_gfn_to_hva_prot(vcpu, real_gfn,
> + host_addr = kvm_vcpu_gfn_to_hva_prot(vcpu, gpa_to_gfn(real_gpa),
>   >pte_writable[walker->level 
> - 1]);
>   if (unlikely(kvm_is_error_hva(host_addr)))
>   goto error;
> 

Queued, thanks.

Paolo

Re: [PATCH v2 04/16] b43: Remove uninitialized_var() usage

[Nick Desaulniers]

On Fri, Jun 19, 2020 at 8:30 PM Kees Cook  wrote:
>
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings (e.g.
> "unused variable"). If the compiler thinks it is uninitialized, either
> simply initialize the variable or make compiler changes. As a precursor
> to removing[2] this[3] macro[4], just initialize this variable to NULL.
> No later NULL deref is possible due to the early returns outside of the
> (phy->rev >= 7 && phy->rev < 19) case, which explicitly tests for NULL.
>
> [1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
> [2] 
> https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
> [3] 
> https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
> [4] 
> https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/
>
> Fixes: 58619b14d106 ("b43: move under broadcom vendor directory")
> Signed-off-by: Kees Cook 

I see three total uses of uninitialized_var() in this file, do we want
to eliminate all of them?

> ---
>  drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c 
> b/drivers/net/wireless/broadcom/b43/phy_n.c
> index c33b4235839d..46db91846007 100644
> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
> @@ -4222,7 +4222,7 @@ static void b43_nphy_tx_gain_table_upload(struct 
> b43_wldev *dev)
> u32 rfpwr_offset;
> u8 pga_gain, pad_gain;
> int i;
> -   const s16 *uninitialized_var(rf_pwr_offset_table);
> +   const s16 *rf_pwr_offset_table = NULL;
>
> table = b43_nphy_get_tx_gain_table(dev);
> if (!table)
> --

-- 
Thanks,
~Nick Desaulniers

Re: [PATCH v2] USB: Serial: cypress_M8: Enable Simply Automated UPB PIM

[James Hilliard]

On Mon, Jun 22, 2020 at 2:53 AM Johan Hovold  wrote:
>
> On Tue, Jun 16, 2020 at 04:04:03PM -0600, James Hilliard wrote:
> > This is a UPB(Universal Powerline Bus) PIM(Powerline Interface Module)
> > which allows for controlling multiple UPB compatible devices from
> > Linux using the standard serial interface.
> >
> > Based on vendor application source code there are two different models
> > of USB based PIM devices in addition to a number of RS232 based PIM's.
> >
> > The vendor UPB application source contains the following USB ID's:
> > #define USB_PCS_VENDOR_ID 0x04b4
> > #define USB_PCS_PIM_PRODUCT_ID 0x5500
> >
> > #define USB_SAI_VENDOR_ID 0x17dd
> > #define USB_SAI_PIM_PRODUCT_ID 0x5500
> >
> > The first set of ID's correspond to the PIM variant sold by Powerline
> > Control Systems while the second corresponds to the Simply Automated
> > Incorporated PIM. As the product ID for both of these match the default
> > cypress HID->COM RS232 product ID it assumed that they both use an
> > internal variant of this HID->COM RS232 converter hardware. However
> > as the vendor ID for the Simply Automated variant is different we need
> > to also add it to the cypress_M8 driver so that it is properly
> > detected.
> >
> > Signed-off-by: James Hilliard 
> > ---
> > Changes v1 -> v2:
> >   - Add more detailed commit message.
>
> Now applied, thanks.
>
> Would you mind posting the output of "lsusb -v" for this device for
> completeness?
Bus 001 Device 004: ID 17dd:5500
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.00
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x17dd
  idProduct  0x5500
  bcdDevice0.00
  iManufacturer   1 Simply Automated Inc.
  iProduct2 USB to Serial
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0029
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  4 Sample HID
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 3
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.00
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength  37
 Report Descriptors:
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x
  (Bus Powered)
>
> Johan

Re: [PATCH] Replace HTTP links with HTTPS ones: Documentation/process

[Miguel Ojeda]

On Mon, Jun 22, 2020 at 3:06 PM Jonathan Corbet  wrote:
>
> As has been noted elsewhere, checkpatch.pl seems like the appropriate
> place to make this check.  As for "the entire tree"...if this job gets
> completed, "git grep" should be a fine way to do that.

`checkpatch` is not really enforced in many subsystems, no? Further,
some existing and future HTTP links may support HTTPS later on.

As for `git grep`, agreed if we reach near 100%. Otherwise, no. In the
general case, including the code for a task that has some likelihood
of needing repetition is a safe bet, which is why I suggested it. The
same script could be also used to check for broken links and related
maintenance.

Cheers,
Miguel

Re: [PATCH v2 00/11] KVM: Support guest MAXPHYADDR < host MAXPHYADDR

[Paolo Bonzini]

On 22/06/20 18:33, Tom Lendacky wrote:
> I'm not a big fan of trapping #PF for this. Can't this have a performance
> impact on the guest? If I'm not mistaken, Qemu will default to TCG
> physical address size (40-bits), unless told otherwise, causing #PF to now
> be trapped. Maybe libvirt defaults to matching host/guest CPU MAXPHYADDR?

Yes, this is true.  We should change it similar to how we handle TSC
frequency (and having support for guest MAXPHYADDR < host MAXPHYADDR is
a prerequisite).

> In bare-metal, there's no guarantee a CPU will report all the faults in a
> single PF error code. And because of race conditions, software can never
> rely on that behavior. Whenever the OS thinks it has cured an error, it
> must always be able to handle another #PF for the same access when it
> retries because another processor could have modified the PTE in the
> meantime.

I agree, but I don't understand the relation to this patch.  Can you
explain?

> What's the purpose of reporting RSVD in the error code in the
> guest in regards to live migration?
>
>> - if the page is accessible to the guest according to the permissions in
>> the page table, it will cause a #NPF.  Again, we need to trap it, check
>> the guest physical address and inject a P|RSVD #PF if the guest physical
>> address has any guest-reserved bits.
>>
>> The AMD specific issue happens in the second case.  By the time the NPF
>> vmexit occurs, the accessed and/or dirty bits have been set and this
>> should not have happened before the RSVD page fault that we want to
>> inject.  On Intel processors, instead, EPT violations trigger before
>> accessed and dirty bits are set.  I cannot find an explicit mention of
>> the intended behavior in either the
>> Intel SDM or the AMD APM.
> 
> Section 15.25.6 of the AMD APM volume 2 talks about page faults (nested vs
> guest) and fault ordering. It does talk about setting guest A/D bits
> during the walk, before an #NPF is taken. I don't see any way around that
> given a virtual MAXPHYADDR in the guest being less than the host MAXPHYADDR.

Right you are...  Then this behavior cannot be implemented on AMD.

Paolo

[tip: x86/fsgsbase] selftests/x86: Add a syscall_arg_fault_64 test for negative GSBASE

[tip-bot2 for Andy Lutomirski]

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

Commit-ID: a5d25e01c8146ad8846da4760422e12242fceafe
Gitweb:
https://git.kernel.org/tip/a5d25e01c8146ad8846da4760422e12242fceafe
Author:Andy Lutomirski 
AuthorDate:Wed, 27 May 2020 16:02:36 -07:00
Committer: Borislav Petkov 
CommitterDate: Mon, 22 Jun 2020 18:56:36 +02:00

selftests/x86: Add a syscall_arg_fault_64 test for negative GSBASE

If the kernel erroneously allows WRGSBASE and user code writes a
negative value, paranoid_entry will get confused. Check for this by
writing a negative value to GSBASE and doing SYSENTER with TF set. A
successful run looks like:

[RUN]   SYSENTER with TF, invalid state, and GSBASE < 0
[SKIP]  Illegal instruction

A failed run causes a kernel hang, and I believe it's because we
double-fault and then get a never ending series of page faults and,
when we exhaust the double fault stack we double fault again,
starting the process over.

Signed-off-by: Andy Lutomirski 
Signed-off-by: Borislav Petkov 
Link: 
https://lkml.kernel.org/r/f4f71efc91b9eae5e3dae21c9aee1c70cf5f370e.1590620529.git.l...@kernel.org
---
 tools/testing/selftests/x86/syscall_arg_fault.c | 26 -
 1 file changed, 26 insertions(+)

diff --git a/tools/testing/selftests/x86/syscall_arg_fault.c 
b/tools/testing/selftests/x86/syscall_arg_fault.c
index bc0ecc2..62fba40 100644
--- a/tools/testing/selftests/x86/syscall_arg_fault.c
+++ b/tools/testing/selftests/x86/syscall_arg_fault.c
@@ -72,6 +72,7 @@ static void sigsegv_or_sigbus(int sig, siginfo_t *info, void 
*ctx_void)
if (ax != -EFAULT && ax != -ENOSYS) {
printf("[FAIL]\tAX had the wrong value: 0x%lx\n",
   (unsigned long)ax);
+   printf("\tIP = 0x%lx\n", (unsigned 
long)ctx->uc_mcontext.gregs[REG_IP]);
n_errs++;
} else {
printf("[OK]\tSeems okay\n");
@@ -226,5 +227,30 @@ int main()
}
set_eflags(get_eflags() & ~X86_EFLAGS_TF);
 
+#ifdef __x86_64__
+   printf("[RUN]\tSYSENTER with TF, invalid state, and GSBASE < 0\n");
+
+   if (sigsetjmp(jmpbuf, 1) == 0) {
+   sigtrap_consecutive_syscalls = 0;
+
+   asm volatile ("wrgsbase %%rax\n\t"
+ :: "a" (0xUL));
+
+   set_eflags(get_eflags() | X86_EFLAGS_TF);
+   asm volatile (
+   "movl $-1, %%eax\n\t"
+   "movl $-1, %%ebx\n\t"
+   "movl $-1, %%ecx\n\t"
+   "movl $-1, %%edx\n\t"
+   "movl $-1, %%esi\n\t"
+   "movl $-1, %%edi\n\t"
+   "movl $-1, %%ebp\n\t"
+   "movl $-1, %%esp\n\t"
+   "sysenter"
+   : : : "memory", "flags");
+   }
+   set_eflags(get_eflags() & ~X86_EFLAGS_TF);
+#endif
+
return 0;
 }

Re: [PATCH v2 01/16] docs: deprecated.rst: Add uninitialized_var()

[Nick Desaulniers]

On Fri, Jun 19, 2020 at 8:30 PM Kees Cook  wrote:
>
> Nothing should be using this macro, and the entire idea of tricking the
> compiler into silencing such warnings is a mistake.
>
> Signed-off-by: Kees Cook 

Reviewed-by: Nick Desaulniers 

> ---
>  Documentation/process/deprecated.rst | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/process/deprecated.rst 
> b/Documentation/process/deprecated.rst
> index 652e2aa02a66..943a926ecbbb 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -51,6 +51,24 @@ to make sure their systems do not continue running in the 
> face of
>  "unreachable" conditions. (For example, see commits like `this one
>  `_.)
>
> +uninitialized_var()
> +---
> +For any compiler warnings about uninitialized variables, just add
> +an initializer. Using the uninitialized_var() macro (or similar
> +warning-silencing tricks) is dangerous as it papers over `real bugs
> +`_
> +(or can in the future), and suppresses unrelated compiler warnings
> +(e.g. "unused variable"). If the compiler thinks it is uninitialized,
> +either simply initialize the variable or make compiler changes. Keep in
> +mind that in most cases, if an initialization is obviously redundant,
> +the compiler's dead-store elimination pass will make sure there are no
> +needless variable writes.
> +
> +As Linus has said, this macro
> +`must 
> `_
> +`be 
> `_
> +`removed 
> `_.
> +
>  open-coded arithmetic in allocator arguments
>  
>  Dynamic size calculations (especially multiplication) should not be
> --
> 2.25.1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clang-built-linux/20200620033007.1444705-2-keescook%40chromium.org.



-- 
Thanks,
~Nick Desaulniers

Re: [GIT PULL] regmap fixes for v5.8-rc2

[Mark Brown]

On Mon, Jun 22, 2020 at 09:46:24AM -0700, Linus Torvalds wrote:

> That said, automating the mailing is *not* incompatible with having a
> real name in the "From" line. Can you please make your scripting at
> least say "Mark Brown " rather than just
> "broo...@kernel.org".

Sure, will do - my MTA fills it in on one machine and not the other it
seems and I tested on the wrong one.


signature.asc
Description: PGP signature

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

[Shakeel Butt]

Hi SeongJae,

On Mon, Jun 22, 2020 at 1:42 AM SeongJae Park  wrote:
>
> Last week, this patchset received 5 'Reviewed-by' tags, but no further 
> comments
> for changes.  I updated the documentation, but the change is only small.  For
> the reason, I'm only asking more reviews rather than posting the whole series
> again.  Any comment is welcome.
>
>
> Thanks,
> SeongJae Park


This is on my review TODO list and I will get to it in a couple of
days. No need to post new versions.

thanks,
Shakeel

Re: [PATCH 00/16] mm/hmm/nouveau: THP mapping and migration

[Ralph Campbell]

On 6/22/20 5:39 AM, Jason Gunthorpe wrote:

On Fri, Jun 19, 2020 at 02:56:33PM -0700, Ralph Campbell wrote:

These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go
into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM
self tests. Patch 7-8 prepare nouveau for the meat of this series which
adds support and testing for compound page mapping of system memory
(patches 9-11) and compound page migration to device private memory
(patches 12-16). Since these changes are split across mm core, nouveau,
and testing, I'm guessing Jason Gunthorpe's HMM tree would be appropriate.


You need to break this up into parts that go where they need to
go. Nouveau rc changes should go to DRM or some series needs to
explain the linkage


Ralph Campbell (16):
   mm: fix migrate_vma_setup() src_owner and normal pages
   nouveau: fix migrate page regression
   nouveau: fix mixed normal and device private page migration
   mm/hmm: fix test timeout on slower machines
   mm/hmm/test: remove redundant page table invalidate
   mm/hmm: test mixed normal and device private migrations
   nouveau: make nvkm_vmm_ctor() and nvkm_mmu_ptp_get() static
   nouveau/hmm: fault one page at a time
   mm/hmm: add output flag for compound page mapping
   nouveau/hmm: support mapping large sysmem pages
   hmm: add tests for HMM_PFN_COMPOUND flag
   mm/hmm: optimize migrate_vma_setup() for holes


Order things so it is hmm, test, noeveau


   mm: support THP migration to device private memory
   mm/thp: add THP allocation helper
   mm/hmm/test: add self tests for THP migration
   nouveau: support THP migration to private memory


This is another series, you should split it even if it has to go
through the hmm tree

Jason


Thanks. I thought there was probably a better way to submit this but
I posted everything so people could see how it all fit together.

Re: Strange problem with SCTP+IPv6

[Corey Minyard]

On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard  wrote:
> >
> > I've stumbled upon a strange problem with SCTP and IPv6.  If I create an
> > sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
> > then I make a connection to it using ::1, the connection will drop after
> > 2.5 seconds with an ECONNRESET error.
> >
> > It only happens on SCTP, it doesn't have the issue if you connect to a
> > full IPv6 address instead of ::1, and it doesn't happen if you don't
> > set IPV6_V6ONLY.  I have verified current end of tree kernel.org.
> > I tried on an ARM system and x86_64.
> >
> > I haven't dug into the kernel to see if I could find anything yet, but I
> > thought I would go ahead and report it.  I am attaching a reproducer.
> > Basically, compile the following code:
> The code only set IPV6_V6ONLY on server side, so the client side will
> still bind all the local ipv4 addresses (as you didn't call bind() to
> bind any specific addresses ). Then after the connection is created,
> the client will send HB on the v4 paths to the server. The server
> will abort the connection, as it can't support v4.
> 
> So you can work around it by either:
> 
>   - set IPV6_V6ONLY on client side.
> 
> or
> 
>   - bind to the specific v6 addresses on the client side.
> 
> I don't see RFC said something about this.
> So it may not be a good idea to change the current behaviour
> to not establish the connection in this case, which may cause regression.

Ok, I understand this.  It's a little strange, but I see why it works
this way.

Thanks,

-corey

> 
> >
> >   gcc -g -o sctptest -Wall sctptest.c
> >
> > and run it in one window as a server:
> >
> >   ./sctptest a
> >
> > (Pass in any option to be the server) and run the following in another
> > window as the client:
> >
> >   ./sctptest
> >
> > It disconnects after about 2.5 seconds.  If it works, it should just sit
> > there forever.
> >
> > -corey
> >
> >
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> >
> > static int
> > getaddr(const char *addr, const char *port, bool listen,
> > struct addrinfo **rai)
> > {
> > struct addrinfo *ai, hints;
> >
> > memset(, 0, sizeof(hints));
> > hints.ai_flags = AI_ADDRCONFIG;
> > if (listen)
> > hints.ai_flags |= AI_PASSIVE;
> > hints.ai_family = AF_UNSPEC;
> > hints.ai_socktype = SOCK_STREAM;
> > hints.ai_protocol = IPPROTO_SCTP;
> > if (getaddrinfo(addr, port, , )) {
> > perror("getaddrinfo");
> > return -1;
> > }
> >
> > *rai = ai;
> > return 0;
> > }
> >
> > static int
> > waitread(int s)
> > {
> > char data[1];
> > ssize_t rv;
> >
> > rv = read(s, data, sizeof(data));
> > if (rv == -1) {
> > perror("read");
> > return -1;
> > }
> > printf("Read %d bytes\n", (int) rv);
> > return 0;
> > }
> >
> > static int
> > do_server(void)
> > {
> > int err, ls, s, optval;
> > struct addrinfo *ai;
> >
> > printf("Server\n");
> >
> > err = getaddr("::", "3023", true, );
> > if (err)
> > return err;
> >
> > ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
> > if (ls == -1) {
> > perror("socket");
> > return -1;
> > }
> >
> > optval = 1;
> > if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR,
> >(void *), sizeof(optval)) == -1) {
> > perror("setsockopt reuseaddr");
> > return -1;
> > }
> >
> > /* Comment this out and it will work. */
> > if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, ,
> >sizeof(optval)) == -1) {
> > perror("setsockopt ipv6 only");
> > return -1;
> > }
> >
> > err = bind(ls, ai->ai_addr, ai->ai_addrlen);
> > if (err == -1) {
> > perror("bind");
> > return -1;
> > }
> >
> > err = listen(ls, 5);
> > if (err == -1) {
> > perror("listen");
> > return -1;
> > }
> >
> > s = accept(ls, NULL, NULL);
> > if (s == -1) {
> > perror("accept");
> > return -1;
> > }
> >
> > close(ls);
> >
> > err = waitread(s);
> > close(s);
> > return err;
> > }
> >
> > static int
> > do_client(void)
> > {
> > int err, s;
> > struct addrinfo *ai;
> >
> > printf("Client\n");
> >
> > err = getaddr("::1", "3023", false, );
> > if (err)
> > return err;
> >
> > s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
> > if (s == -1) {
> > perror("socket");
> > return -1;
> > }
> >
> > err = connect(s, ai->ai_addr, ai->ai_addrlen);
> > if (err == -1) {
> > perror("connect");
> > return -1;
> > }
> >
> > err = waitread(s);
> > close(s);
> > return err;
> > }
> >
> > int
> > main(int argc, char *argv[])
> > {
> > 

Re: [PATCH] dt-bindings: backlight: Convert common backlight bindings to DT schema

[Daniel Thompson]

On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote:
> > diff --git 
> > a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml 
> > b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> > new file mode 100644
> > index ..7e1f109a38a4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> > @@ -0,0 +1,98 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/leds/backlight/pwm-backlight.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: pwm-backlight bindings
> > +
> > +maintainers:
> > +  - Lee Jones 
> > +  - Daniel Thompson 
> > +  - Jingoo Han 
> > +
> > +properties:
> > +  compatible:
> > +const: pwm-backlight
> > +
> > +  pwms:
> > +maxItems: 1
> > +
> > +  pwm-names: true
> > +
> > +  power-supply:
> > +description: regulator for supply voltage
> > +
> > +  enable-gpios:
> > +description: Contains a single GPIO specifier for the GPIO which 
> > enables
> > +  and disables the backlight
> > +maxItems: 1
> > +
> > +  post-pwm-on-delay-ms:
> > +description: Delay in ms between setting an initial (non-zero) PWM and
> > +  enabling the backlight using GPIO.
> > +
> > +  pwm-off-delay-ms:
> > +description: Delay in ms between disabling the backlight using GPIO
> > +  and setting PWM value to 0.
> > +
> > +  brightness-levels:
> > +description: Array of distinct brightness levels. Typically these are
> > +  in the range from 0 to 255, but any range starting at 0 will do. The
> > +  actual brightness level (PWM duty cycle) will be interpolated from
> > +  these values. 0 means a 0% duty cycle (darkest/off), while the last
> > +  value in the array represents a 100% duty cycle (brightest).
> > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +  default-brightness-level:
> > +description: The default brightness level (index into the array defined
> > +  by the "brightness-levels" property).
> > +$ref: /schemas/types.yaml#/definitions/uint32
> Same comment as before...

Sorry the "ditto" meant I didn't thing about PWM as much as I should
have.

The situation for PWM is a little different to LED. That's mostly
because we decided not to clutter the LED code with
"num-interpolated-steps".

The PWM code implements the default-brightness-level as an index into
the brightness array *after* it has been expanded using interpolation.
In other words today Linux treats the default-brightness-level more
like[1].

description: The default brightness level. When
  num-interpolated-steps is not set this is simply an index into
  the array defined by the "brightness-levels" property. If
  num-interpolated-steps is set the brightness array will be
  expanded by interpolation before we index to get a default
  level.

This is the best I have come up with so far... but I concede it still
lacks elegance.


Daniel.


[1] I don't know my way round the BSD code bases to be sure what they
do... I did a couple of web searches but didn't pull up anything
definitive.


> 
> > +
> > +  num-interpolated-steps:
> > +description: Number of interpolated steps between each value of 
> > brightness-levels
> > +  table. This way a high resolution pwm duty cycle can be used without
> > +  having to list out every possible value in the brightness-level 
> > array.
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +dependencies:
> > +  default-brightness-level: [brightness-levels]
> > +  num-interpolated-steps: [brightness-levels]
> > +
> > +required:
> > +  - compatible
> > +  - pwms
> > +  - power-supply
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +backlight {
> > +compatible = "pwm-backlight";
> > +pwms = < 0 500>;
> > +
> > +brightness-levels = <0 4 8 16 32 64 128 255>;
> > +default-brightness-level = <6>;
> > +
> > +power-supply = <_bl_reg>;
> > +enable-gpios = < 58 0>;
> > +post-pwm-on-delay-ms = <10>;
> > +pwm-off-delay-ms = <10>;
> > +};
> > +
> > +  - |
> > +// Example using num-interpolation-steps:
> > +backlight {
> > +compatible = "pwm-backlight";
> > +pwms = < 0 500>;
> > +
> > +brightness-levels = <0 2048 4096 8192 16384 65535>;
> > +num-interpolated-steps = <2048>;
> > +default-brightness-level = <4096>;
> > +
> > +power-supply = <_bl_reg>;
> > +enable-gpios = < 58 0>;
> > +};
> > +
> > +...
> > -- 
> > 2.25.1
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/21] KVM: Move x86's version of struct kvm_mmu_memory_cache to common code

[Sean Christopherson]

On Wed, Jun 10, 2020 at 02:58:21PM -0700, Ben Gardon wrote:
> On Wed, Jun 10, 2020 at 12:01 PM Ben Gardon  wrote:
> > > diff --git a/arch/x86/include/asm/kvm_host.h 
> > > b/arch/x86/include/asm/kvm_host.h
> > > index fb99e6776e27..8e8fea13b6c7 100644
> > > --- a/arch/x86/include/asm/kvm_host.h
> > > +++ b/arch/x86/include/asm/kvm_host.h
> > > @@ -193,8 +193,6 @@ struct x86_exception;
> > >  enum x86_intercept;
> > >  enum x86_intercept_stage;
> > >
> > > -#define KVM_NR_MEM_OBJS 40
> > > -
> Oops I didn't catch this on my first read through, but in patch 16 in
> this series I see some references to KVM_NR_MEM_OBJS being removed. As
> a result I would not expect this patch to build. Other references to
> this value should probably replaced with
> KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE as well.

This patch intentionally uses a different name for the #define (see below)
so that the existing arm64 and MIPS declarations don't get picked up by
common KVM code.  This is required so that arm64 and MIPS continue to use
their versions of the cache implementation until they are converted to the
common implementation later in the series, e.g. in patch 16 when the
references to KVM_NR_MEM_OBJS are removed.

I confirmed the above (after sending v1) by compiling all non-x86 changes
on arm64, MIPS, s390 and PPC to verify that this doesn't break bisection.

> > >  #define KVM_NR_DB_REGS 4
> > >
> > >  #define DR6_BD (1 << 13)
> > > @@ -245,17 +243,6 @@ enum x86_intercept_stage;
> > >
> > >  struct kvm_kernel_irq_routing_entry;

...

> > > +#ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE
> > > +/*
> > > + * Memory caches are used to preallocate memory ahead of various MMU 
> > > flows,
> > > + * e.g. page fault handlers.  Gracefully handling allocation failures 
> > > deep in
> > > + * MMU flows is problematic, as is triggering reclaim, I/O, etc... while
> > > + * holding MMU locks.  Note, these caches act more like prefetch buffers 
> > > than
> > > + * classical caches, i.e. objects are not returned to the cache on being 
> > > freed.
> > > + */
> > > +struct kvm_mmu_memory_cache {
> > > +   int nobjs;
> > > +   gfp_t gfp_zero;
> > > +   struct kmem_cache *kmem_cache;
> > > +   void *objects[KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE];
> > > +};
> > > +#endif
> > > +
> > > +
> > >  #endif /* __KVM_TYPES_H__ */
> > > --
> > > 2.26.0
> > >

INFO: trying to register non-static key in skb_queue_tail

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:f8f02d5c USB: OTG: rename product list of devices
git tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=17205bae10
kernel config:  https://syzkaller.appspot.com/x/.config?x=f1981539b6376b73
dashboard link: https://syzkaller.appspot.com/bug?extid=743547b2a7fd655ffb6d
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11eab94910
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10dc82ed10

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+743547b2a7fd655ff...@syzkaller.appspotmail.com

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 323 Comm: systemd-udevd Not tainted 5.8.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xf6/0x16e lib/dump_stack.c:118
 assign_lock_key kernel/locking/lockdep.c:894 [inline]
 register_lock_class+0x1228/0x16d0 kernel/locking/lockdep.c:1206
 __lock_acquire+0x101/0x6270 kernel/locking/lockdep.c:4259
 lock_acquire+0x18b/0x7c0 kernel/locking/lockdep.c:4959
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0x32/0x50 kernel/locking/spinlock.c:159
 skb_queue_tail+0x27/0x180 net/core/skbuff.c:3143
 ath9k_htc_txep+0x287/0x400 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c:707
 ath9k_htc_txcompletion_cb+0x1a1/0x2b0 
drivers/net/wireless/ath/ath9k/htc_hst.c:346
 hif_usb_regout_cb+0x115/0x1c0 drivers/net/wireless/ath/ath9k/hif_usb.c:90
 __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
 dummy_timer+0x125e/0x32b4 drivers/usb/gadget/udc/dummy_hcd.c:1967
 call_timer_fn+0x1ac/0x6e0 kernel/time/timer.c:1404
 expire_timers kernel/time/timer.c:1449 [inline]
 __run_timers kernel/time/timer.c:1773 [inline]
 __run_timers kernel/time/timer.c:1740 [inline]
 run_timer_softirq+0x5e5/0x14c0 kernel/time/timer.c:1786
 __do_softirq+0x21e/0x996 kernel/softirq.c:292
 asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:711
 
 __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
 run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
 do_softirq_own_stack+0x109/0x140 arch/x86/kernel/irq_64.c:77
 invoke_softirq kernel/softirq.c:387 [inline]
 __irq_exit_rcu kernel/softirq.c:417 [inline]
 irq_exit_rcu+0x16f/0x1a0 kernel/softirq.c:429
 sysvec_apic_timer_interrupt+0xd3/0x1b0 arch/x86/kernel/apic/apic.c:1091
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:596
RIP: 0010:lock_release+0x3c9/0x710 kernel/locking/lockdep.c:4967
Code: 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 bb 02 00 
00 83 ad 84 08 00 00 01 0f 85 4a 01 00 00 ff 34 24 9d <48> b8 00 00 00 00 00 fc 
ff df 48 01 c3 48 c7 03 00 00 00 00 c7 43
RSP: 0018:8881cd71f8f0 EFLAGS: 0246
RAX: 0007 RBX: 111039ae3f21 RCX: 111039a85d8f
RDX:  RSI: 111039a85d96 RDI: 8881cd42ec84
RBP: 8881cd42e400 R08: 8881cd42e400 R09: fbfff1014d0a
R10: 880a684f R11: fbfff1014d09 R12: f002853324f3be8d
R13: 816b05ef R14: 8881cd42ec80 R15: 0002
 zap_pte_range mm/memory.c:1089 [inline]
 zap_pmd_range mm/memory.c:1193 [inline]
 zap_pud_range mm/memory.c:1222 [inline]
 zap_p4d_range mm/memory.c:1243 [inline]
 unmap_page_range+0xe2f/0x1fc0 mm/memory.c:1264
 unmap_single_vma+0x196/0x300 mm/memory.c:1309
 unmap_vmas+0x174/0x2f0 mm/memory.c:1341
 exit_mmap+0x278/0x4d0 mm/mmap.c:3150
 __mmput kernel/fork.c:1093 [inline]
 mmput+0xce/0x3d0 kernel/fork.c:1114
 exit_mm kernel/exit.c:482 [inline]
 do_exit+0xaaf/0x2cb0 kernel/exit.c:792
 do_group_exit+0x125/0x340 kernel/exit.c:903
 __do_sys_exit_group kernel/exit.c:914 [inline]
 __se_sys_exit_group kernel/exit.c:912 [inline]
 __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:912
 do_syscall_64+0x50/0x90 arch/x86/entry/common.c:359
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f7ad8c2a618
Code: Bad RIP value.
RSP: 002b:7ffd37c486a8 EFLAGS: 0206 ORIG_RAX: 00e7
RAX: ffda RBX: 7ffd37c48770 RCX: 7f7ad8c2a618
RDX:  RSI: 003c RDI: 
RBP: 7ffd37c48820 R08: 00e7 R09: fe50
R10:  R11: 0206 R12: 
R13:  R14: 0003 R15: 000e
general protection fault, probably for non-canonical address 
0xdc00:  [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x-0x0007]
CPU: 0 PID: 323 Comm: systemd-udevd Not tainted 5.8.0-rc1-syzkaller #0
Hardware name: Google 

Re: [PATCH v6 12/19] mm: memcg/slab: use a single set of kmem_caches for all accounted allocations

[Shakeel Butt]

On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin  wrote:
>
> This is fairly big but mostly red patch, which makes all accounted
> slab allocations use a single set of kmem_caches instead of
> creating a separate set for each memory cgroup.
>
> Because the number of non-root kmem_caches is now capped by the number
> of root kmem_caches, there is no need to shrink or destroy them
> prematurely. They can be perfectly destroyed together with their
> root counterparts. This allows to dramatically simplify the
> management of non-root kmem_caches and delete a ton of code.
>
> This patch performs the following changes:
> 1) introduces memcg_params.memcg_cache pointer to represent the
>kmem_cache which will be used for all non-root allocations
> 2) reuses the existing memcg kmem_cache creation mechanism
>to create memcg kmem_cache on the first allocation attempt
> 3) memcg kmem_caches are named -memcg,
>e.g. dentry-memcg
> 4) simplifies memcg_kmem_get_cache() to just return memcg kmem_cache
>or schedule it's creation and return the root cache
> 5) removes almost all non-root kmem_cache management code
>(separate refcounter, reparenting, shrinking, etc)
> 6) makes slab debugfs to display root_mem_cgroup css id and never
>show :dead and :deact flags in the memcg_slabinfo attribute.
>
> Following patches in the series will simplify the kmem_cache creation.
>
> Signed-off-by: Roman Gushchin 
> Reviewed-by: Vlastimil Babka 

This is a very satisfying patch.

Reviewed-by: Shakeel Butt 

Re: [GIT PULL] regulator fixes for v5.8-rc2

[pr-tracker-bot]

The pull request you sent on Mon, 22 Jun 2020 12:40:20 +0100:

> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
> tags/regulator-fix-v5.8-rc2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/751645789f7cffddb0715d51fd9e72986ad9ecaf

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

[PATCH] drm/msm: Fix up the rest of the messed up address sizes

[Jordan Crouse]

msm_gem_address_space_create() changed to take a start/length instead
of a start/end for the iova space but all of the callers were just
cut and pasted from the old usage. Most of the mistakes have been fixed
up so just catch up the rest.

Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a2xx_gpu.c| 2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c| 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 2 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 60f6472a3e58..6021f8d9efd1 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -408,7 +408,7 @@ a2xx_create_address_space(struct msm_gpu *gpu, struct 
platform_device *pdev)
struct msm_gem_address_space *aspace;
 
aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
-   SZ_16M + 0xfff * SZ_64K);
+   0xfff * SZ_64K);
 
if (IS_ERR(aspace) && !IS_ERR(mmu))
mmu->funcs->destroy(mmu);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 096be97ce9f9..21e77d67151f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1121,7 +1121,7 @@ static int a6xx_gmu_memory_probe(struct a6xx_gmu *gmu)
return -ENODEV;
 
mmu = msm_iommu_new(gmu->dev, domain);
-   gmu->aspace = msm_gem_address_space_create(mmu, "gmu", 0x0, 0x7fff);
+   gmu->aspace = msm_gem_address_space_create(mmu, "gmu", 0x0, 0x8000);
if (IS_ERR(gmu->aspace)) {
iommu_domain_free(domain);
return PTR_ERR(gmu->aspace);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index b8615d4fe8a3..680527e28d09 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -780,7 +780,7 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
 
mmu = msm_iommu_new(dpu_kms->dev->dev, domain);
aspace = msm_gem_address_space_create(mmu, "dpu1",
-   0x1000, 0xfff);
+   0x1000, 0x1 - 0x1000);
 
if (IS_ERR(aspace)) {
mmu->funcs->destroy(mmu);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 08897184b1d9..fc6a3f8134c7 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -514,7 +514,7 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
config->iommu);
 
aspace  = msm_gem_address_space_create(mmu,
-   "mdp4", 0x1000, 0x);
+   "mdp4", 0x1000, 0x1 - 0x1000);
 
if (IS_ERR(aspace)) {
if (!IS_ERR(mmu))
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 54631fbd9389..8586d2cf1d94 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -641,7 +641,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
mmu = msm_iommu_new(iommu_dev, config->platform.iommu);
 
aspace = msm_gem_address_space_create(mmu, "mdp5",
-   0x1000, 0x);
+   0x1000, 0x1 - 0x1000);
 
if (IS_ERR(aspace)) {
if (!IS_ERR(mmu))
-- 
2.17.1

Re: [GIT PULL] regmap fixes for v5.8-rc2

[pr-tracker-bot]

The pull request you sent on Mon, 22 Jun 2020 12:39:14 +0100:

> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 
> tags/regmap-fix-v5.8-rc2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2a00087068542b4324b54a14278acabc50f2a61b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH v2] gpio: rcar: handle pm_runtime_get_sync failure case

[Bartosz Golaszewski]

śr., 17 cze 2020 o 09:43 Geert Uytterhoeven  napisał(a):
>
> On Wed, Jun 17, 2020 at 9:40 AM Navid Emamdoost
>  wrote:
> > Calling pm_runtime_get_sync increments the counter even in case of
> > failure, causing incorrect ref count. Call pm_runtime_put if
> > pm_runtime_get_sync fails.
> >
> > Signed-off-by: Navid Emamdoost 
>
> Reviewed-by: Geert Uytterhoeven 
>

Is this stable material?

Bart

Re: [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes

[Lee Jones]

On Mon, 22 Jun 2020, Frank Rowand wrote:

> On 2020-06-22 03:09, Lee Jones wrote:
> > On Thu, 11 Jun 2020, Lee Jones wrote:
> > 
> >> Currently, when a child platform device (sometimes referred to as a
> >> sub-device) is registered via the Multi-Functional Device (MFD) API,
> >> the framework attempts to match the newly registered platform device
> >> with its associated Device Tree (OF) node.  Until now, the device has
> >> been allocated the first node found with an identical OF compatible
> >> string.  Unfortunately, if there are, say for example '3' devices
> >> which are to be handled by the same driver and therefore have the same
> >> compatible string, each of them will be allocated a pointer to the
> >> *first* node.
> > 
> > Any more reviews/comments before I apply this?
> > 
> 
> Yes, outstanding issues, so please do not apply.
> 
> Shortly after you sent this email, you sent a reply to one of my
> earlier emails in this thread.  I have replied to that email,
> so we still have an ongoing conversation where we are trying
> to resolve my understanding of the problem and whether the
> solution is appropriate.

Happy to discuss whatever issues you're having.

Looks like the ball is in your court. :)

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v1 1/1] pci: controller: cadence: fix wrong path in comment

[Bjorn Helgaas]

Please use "git log --oneline" to help construct the subject line.
Maybe:

  PCI: cadence-ep: Remove obsolete path from comment

On Mon, Jun 22, 2020 at 11:15:20AM +0200, Flavio Suligoi wrote:
> This comment still refers to the old driver pathname,
> when all PCI drivers were located directly under the
> drivers/pci directory.
> 
> Anyway the function name itself is enough, so we can
> remove the overabundant path reference.
> 
> Signed-off-by: Flavio Suligoi 
> Acked-by: Bjorn Helgaas 

I did not ack this.  Please don't add acks unless someone does so
explicitly.

> ---
> 
> v1: - after the suggestion of Bjorn, remove the whole comment line related to
>   the wrong path
> - add: Acked-by: Bjorn Helgaas 
> 
>  drivers/pci/controller/cadence/pcie-cadence-ep.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c 
> b/drivers/pci/controller/cadence/pcie-cadence-ep.c
> index 1c15c8352125..690eefd328ea 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
> @@ -276,7 +276,6 @@ static int cdns_pcie_ep_send_legacy_irq(struct 
> cdns_pcie_ep *ep, u8 fn, u8 intx)
>   cdns_pcie_ep_assert_intx(ep, fn, intx, true);
>   /*
>* The mdelay() value was taken from dra7xx_pcie_raise_legacy_irq()
> -  * from drivers/pci/dwc/pci-dra7xx.c
>*/
>   mdelay(1);
>   cdns_pcie_ep_assert_intx(ep, fn, intx, false);
> -- 
> 2.17.1
> 

Re: [PATCH 2/2] thunderbolt: Add support for authenticate on disconnect

[Mika Westerberg]

On Mon, Jun 22, 2020 at 09:30:35AM -0500, Mario Limonciello wrote:
> Some external devices can support completing thunderbolt authentication
> when they are unplugged. For this to work though, the link controller must
> remain operational.
> 
> The only device known to support this right now is the Dell WD19TB, so add
> a quirk for this.
> 
> Signed-off-by: Mario Limonciello 
> ---
>  .../ABI/testing/sysfs-bus-thunderbolt | 13 ++
>  drivers/thunderbolt/Makefile  |  1 +
>  drivers/thunderbolt/eeprom.c  |  2 +
>  drivers/thunderbolt/lc.c  | 14 +++
>  drivers/thunderbolt/quirks.c  | 38 +
>  drivers/thunderbolt/switch.c  | 42 +--
>  drivers/thunderbolt/tb-quirks.h   | 16 +++
>  drivers/thunderbolt/tb.h  |  3 ++
>  drivers/thunderbolt/tb_regs.h |  1 +
>  9 files changed, 126 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/thunderbolt/quirks.c
>  create mode 100644 drivers/thunderbolt/tb-quirks.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt 
> b/Documentation/ABI/testing/sysfs-bus-thunderbolt
> index 26b15cbc9881..30798f9a8f59 100644
> --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt
> +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt
> @@ -243,3 +243,16 @@ KernelVersion:   4.15
>  Contact: thunderbolt-softw...@lists.01.org
>  Description: This contains XDomain service specific settings as
>   bitmask. Format: %x
> +
> +What:
> /sys/bus/thunderbolt/devices/.../nvm_authenticate_on_disconnect
> +Date:August 2020
> +KernelVersion:   5.9
> +Contact: thunderbolt-softw...@lists.01.org

I think you can use your email address here instead.

> +Description: For supported devices, automatically authenticate the new 
> Thunderbolt
> + image when the device is disconnected from the host system.
> +
> + This file will accept writing values "1" or "2"
> + - Writing "1" will flush the image to the storage
> + area and prepare the device for authentication on disconnect.
> + - Writing "2" will only flush the image to the storage
> + area.

Also here it does the basic image validation so probably good to
mention.

> diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
> index eae28dd45250..013c5564565a 100644
> --- a/drivers/thunderbolt/Makefile
> +++ b/drivers/thunderbolt/Makefile
> @@ -2,3 +2,4 @@
>  obj-${CONFIG_USB4} := thunderbolt.o
>  thunderbolt-objs := nhi.o nhi_ops.o ctl.o tb.o switch.o cap.o path.o 
> tunnel.o eeprom.o
>  thunderbolt-objs += domain.o dma_port.o icm.o property.o xdomain.o lc.o 
> tmu.o usb4.o
> +thunderbolt-objs += quirks.o
> diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
> index b451a5aa90b5..32838c016c4f 100644
> --- a/drivers/thunderbolt/eeprom.c
> +++ b/drivers/thunderbolt/eeprom.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include "tb.h"
> +#include "tb-quirks.h"
>  
>  /**
>   * tb_eeprom_ctl_write() - write control word
> @@ -599,6 +600,7 @@ int tb_drom_read(struct tb_switch *sw)
>   sw->uid = header->uid;
>   sw->vendor = header->vendor_id;
>   sw->device = header->model_id;
> + check_tbt_quirks(sw);
>  
>   crc = tb_crc32(sw->drom + TB_DROM_DATA_START, header->data_len);
>   if (crc != header->data_crc32) {
> diff --git a/drivers/thunderbolt/lc.c b/drivers/thunderbolt/lc.c
> index bd44d50246d2..45d2a1de2069 100644
> --- a/drivers/thunderbolt/lc.c
> +++ b/drivers/thunderbolt/lc.c
> @@ -366,3 +366,17 @@ int tb_lc_dp_sink_dealloc(struct tb_switch *sw, struct 
> tb_port *in)
>   tb_port_dbg(in, "sink %d de-allocated\n", sink);
>   return 0;
>  }
> +
> +/**
> + * lc_force_power() - Force powers a ridge

Maybe "Forces LC to be powered on" or similar?

> + * @sw: thunderbolt switch
> + *
> + * This is useful to let authentication cycle pass even without
> + * a Thunderbolt link present

Add "." at the end of the sentence.

> + */
> +int lc_force_power(struct tb_switch *sw)

Also tb_lc_force_power() or so to follow the conventions used in the
driver.

> +{
> + u32 in = 0x;

I prefer 0x instead.

> +
> + return tb_sw_write(sw, , TB_CFG_SWITCH, TB_LC_POWER, 1);
> +}
> diff --git a/drivers/thunderbolt/quirks.c b/drivers/thunderbolt/quirks.c
> new file mode 100644
> index ..b9c5cfb97645
> --- /dev/null
> +++ b/drivers/thunderbolt/quirks.c
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Thunderbolt driver - quirks
> + *
> + * Copyright (c) 2020 Mario Limonciello 
> + */
> +
> +#include "tb.h"
> +#include "tb-quirks.h"
> +
> +static void quirk_force_power_link(struct tb_switch *sw)
> +{
> + sw->quirks |= QUIRK_FORCE_POWER_LINK_CONTROLLER;
> +}
> +
> +struct tbt_quirk {

tb_quirk please.

> + u16 vendor;
> + 

Re: [PATCH 5.7] x86/crypto: aesni: Fix build with LLVM_IAS=1

[Sedat Dilek]

On Mon, Jun 22, 2020 at 5:50 PM Sedat Dilek  wrote:

> Craig Topper suggested me in ClangBuiltLinux issue #1050:
>
> > I think the "too many positional arguments" is because the parser isn't able
> > to handle the trailing commas.
> >
> > The "unknown use of instruction mnemonic" is because the macro was named
> > GHASH_4_ENCRYPT_4_PARALLEL_DEC but its being instantiated with
> > GHASH_4_ENCRYPT_4_PARALLEL_dec I guess gas ignores case on the
> > macro instantiation, but llvm doesn't.
>

> Cc: Craig Topper 
> Cc: Craig Topper 

That should be a s/Cc/Suggested-by/.

- Sedat -

Re: [PATCH 1/2] net: phy: export phy_disable_interrupts()

[kernel test robot]

Hi Jisheng,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Jisheng-Zhang/net-phy-call-phy_disable_interrupts-in-phy_init_hw/20200622-183400
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
625d3449788f85569096780592549d0340e9c0c7
config: x86_64-lkp (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   /tmp/ccwmxln4.s: Assembler messages:
>> /tmp/ccwmxln4.s:247: Error: symbol `__kstrtab_phy_request_interrupt' is 
>> already defined
>> /tmp/ccwmxln4.s:249: Error: symbol `__kstrtabns_phy_request_interrupt' is 
>> already defined
   /tmp/ccwmxln4.s:255: Error: symbol `__ksymtab_phy_request_interrupt' is 
already defined

---
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] max732x_probe: remove redundant check

[Bartosz Golaszewski]

czw., 18 cze 2020 o 01:58 Gaurav Singh  napisał(a):
>
> The check : if (pdata) is redundant since its already
> dereferenced before: pdata->have_64bit_regs;
> pdata is not initialized after that hence remove
> this null check.
>
> Signed-off-by: Gaurav Singh 
> ---
>  drivers/gpio/gpio-max732x.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-max732x.c b/drivers/gpio/gpio-max732x.c
> index 5fb0bcf31142..63472f308857 100644
> --- a/drivers/gpio/gpio-max732x.c
> +++ b/drivers/gpio/gpio-max732x.c
> @@ -703,7 +703,7 @@ static int max732x_probe(struct i2c_client *client,
> if (ret)
> return ret;
>
> -   if (pdata && pdata->setup) {
> +   if (pdata->setup) {
> ret = pdata->setup(client, chip->gpio_chip.base,
> chip->gpio_chip.ngpio, pdata->context);
> if (ret < 0)
> --
> 2.17.1
>

The subject should be 'gpio: max732x: ...". I fixed it up and applied
the path to for-next.

Bartosz

Re: drivers/gpu/drm/panel/panel-samsung-ld9040.c:240:12: warning: stack frame size of 8312 bytes in function 'ld9040_prepare'

[Nick Desaulniers]

On Sat, Jun 20, 2020 at 3:09 PM Vladimir Oltean  wrote:
>
> On Sat, 20 Jun 2020 at 21:22, kernel test robot  wrote:
> >
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> > master
> > head:   4333a9b0b67bb4e8bcd91bdd80da80b0ec151162
> > commit: 79591b7db21d255db158afaa48c557dcab631a1c spi: Add a PTP system 
> > timestamp to the transfer structure
> > date:   9 months ago
> > config: x86_64-randconfig-a014-20200620 (attached as .config)
> > compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
> > f5bbe390d23d7da0ffb110cdb24b583c2dc87eba)
> > 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
> > git checkout 79591b7db21d255db158afaa48c557dcab631a1c
> > # 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 >>, old ones prefixed by <<):
> >
> > >> drivers/gpu/drm/panel/panel-samsung-ld9040.c:240:12: warning: stack 
> > >> frame size of 8312 bytes in function 'ld9040_prepare' 
> > >> [-Wframe-larger-than=]
> > static int ld9040_prepare(struct drm_panel *panel)
> > ^
> > 1 warning generated.
> >
> > vim +/ld9040_prepare +240 drivers/gpu/drm/panel/panel-samsung-ld9040.c
> >
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  239
> > 099b3e8699322e drivers/gpu/drm/panel/panel-ld9040.c Ajay Kumar
> > 2014-07-31 @240  static int ld9040_prepare(struct drm_panel *panel)
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  241  {
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  242   struct ld9040 *ctx = panel_to_ld9040(panel);
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  243   int ret;
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  244
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  245   ret = ld9040_power_on(ctx);
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  246   if (ret < 0)
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  247   return ret;
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  248
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  249   ld9040_init(ctx);
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  250
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  251   ret = ld9040_clear_error(ctx);
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  252
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  253   if (ret < 0)
> > 8141028278c2ea drivers/gpu/drm/panel/panel-ld9040.c Ajay Kumar
> > 2014-07-31  254   ld9040_unprepare(panel);
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  255
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  256   return ret;
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  257  }
> > ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 
> > 2014-03-26  258
> >
> > :: The code at line 240 was first introduced by commit
> > :: 099b3e8699322efb7229913d2c1651588205f182 drm/panel: ld9040: Add 
> > dummy prepare and unprepare routines
> >
> > :: TO: Ajay Kumar 
> > :: CC: Thierry Reding 
> >
> > ---
> > 0-DAY CI Kernel Test Service, Intel Corporation
> > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
>
> I really don't get what's the problem here. The listing of
> ld9040_prepare at the given commit and with the given .config is:

I wrote a tool to help debug these.
https://github.com/ClangBuiltLinux/frame-larger-than
If you fetch the randconfig and rebuild with debug info, that tool
will help show you which variables are used in which stack frames and
what their sizes are.  Also note that strange things get dug up from
randconfigs.


>
> 0630 :
> {
>  630:f3 0f 1e fa  endbr64
>  634:e8 00 00 00 00   callq  639 
> 635: R_X86_64_PLT32__fentry__-0x4
>  639:41 56push   %r14
> ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
>  63b:48 8d 77 30  lea0x30(%rdi),%rsi
> {
>  63f:41 55 

Re: [PATCH 1/5] Huawei BMA: Adding Huawei BMA driver: host_edma_drv

[Randy Dunlap]

On 6/22/20 9:03 AM, yunaixin03...@163.com wrote:
> diff --git a/drivers/net/ethernet/huawei/bma/edma_drv/Kconfig 
> b/drivers/net/ethernet/huawei/bma/edma_drv/Kconfig
> new file mode 100644
> index ..97829c5487c2
> --- /dev/null
> +++ b/drivers/net/ethernet/huawei/bma/edma_drv/Kconfig
> @@ -0,0 +1,11 @@
> +#
> +# Huawei BMA software driver configuration
> +#
> +
> +config BMA
> + tristate "Huawei BMA Software Communication Driver"
> +
> + ---help---

Juse use
help

Use of ---help--- is being phased out (removed).

> +   This driver supports Huawei BMA Software. It is used 
> +   to communication between Huawei BMA and BMC software.
> +

thanks.
-- 
~Randy

[PATCH 3/6] soc: ti: omap-prm: Configure sgx power domain for am3 and am4

[Tony Lindgren]

Let's configure only sgx power domain for am3 and am4 to start with.

Signed-off-by: Tony Lindgren 
---
 drivers/soc/ti/omap_prm.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -95,6 +95,18 @@ struct omap_reset_data {
 
 #define PRM_ST_INTRANSITIONBIT(20)
 
+static const struct __maybe_unused omap_prm_domain_map omap_prm_noinact = {
+   .usable_modes = BIT(OMAP_PRMD_ON_ACTIVE) | BIT(OMAP_PRMD_RETENTION) |
+   BIT(OMAP_PRMD_OFF),
+   .statechange = 1,
+   .logicretstate = 1,
+};
+
+static const struct __maybe_unused omap_prm_domain_map omap_prm_onoff_noauto = 
{
+   .usable_modes = BIT(OMAP_PRMD_ON_ACTIVE) | BIT(OMAP_PRMD_OFF),
+   .statechange = 1,
+};
+
 static const struct omap_rst_map rst_map_0[] = {
{ .rst = 0, .st = 0 },
{ .rst = -1 },
@@ -156,7 +168,11 @@ static const struct omap_prm_data am3_prm_data[] = {
{ .name = "per", .base = 0x44e00c00, .rstctrl = 0x0, .rstmap = 
am3_per_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL, .clkdm_name = "pruss_ocp" },
{ .name = "wkup", .base = 0x44e00d00, .rstctrl = 0x0, .rstst = 0xc, 
.rstmap = am3_wkup_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL | 
OMAP_PRM_HAS_NO_CLKDM },
{ .name = "device", .base = 0x44e00f00, .rstctrl = 0x0, .rstst = 0x8, 
.rstmap = rst_map_01, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
-   { .name = "gfx", .base = 0x44e01100, .rstctrl = 0x4, .rstst = 0x14, 
.rstmap = rst_map_0, .clkdm_name = "gfx_l3" },
+   {
+   .name = "gfx", .base = 0x44e01100,
+   .pwrstctrl = 0, .pwrstst = 0x10, .dmap = _prm_noinact,
+   .rstctrl = 0x4, .rstst = 0x14, .rstmap = rst_map_0, .clkdm_name 
= "gfx_l3",
+   },
{ },
 };
 
@@ -172,7 +188,11 @@ static const struct omap_rst_map am4_device_rst_map[] = {
 };
 
 static const struct omap_prm_data am4_prm_data[] = {
-   { .name = "gfx", .base = 0x44df0400, .rstctrl = 0x10, .rstst = 0x14, 
.rstmap = rst_map_0, .clkdm_name = "gfx_l3" },
+   {
+   .name = "gfx", .base = 0x44df0400,
+   .pwrstctrl = 0, .pwrstst = 0x4, .dmap = _prm_onoff_noauto,
+   .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_0, 
.clkdm_name = "gfx_l3",
+   },
{ .name = "per", .base = 0x44df0800, .rstctrl = 0x10, .rstst = 0x14, 
.rstmap = am4_per_rst_map, .clkdm_name = "pruss_ocp" },
{ .name = "wkup", .base = 0x44df2000, .rstctrl = 0x10, .rstst = 0x14, 
.rstmap = am3_wkup_rst_map, .flags = OMAP_PRM_HAS_NO_CLKDM },
{ .name = "device", .base = 0x44df4000, .rstctrl = 0x0, .rstst = 0x4, 
.rstmap = am4_device_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL | 
OMAP_PRM_HAS_NO_CLKDM },
-- 
2.27.0

Re: [PATCH] kvm: lapic: fix broken vcpu hotplug

[Paolo Bonzini]

On 22/06/20 18:08, Igor Mammedov wrote:
> Guest fails to online hotplugged CPU with error
>   smpboot: do_boot_cpu failed(-1) to wakeup CPU#4
> 
> It's caused by the fact that kvm_apic_set_state(), which used to call
> recalculate_apic_map() unconditionally and pulled hotplugged CPU into
> apic map, is updating map conditionally [1] on state change which doesn't
> happen in this case and apic map update is skipped.
> 
> Note:
> new CPU during kvm_arch_vcpu_create() is not visible to
> kvm_recalculate_apic_map(), so all related update calls endup
> as NOP and only follow up kvm_apic_set_state() used to trigger map
> update that counted in hotplugged CPU.
> Fix issue by forcing unconditional update from kvm_apic_set_state(),
> like it used to be.
> 
> 1)
> Fixes: (4abaffce4d25a KVM: LAPIC: Recalculate apic map in batch)
> Signed-off-by: Igor Mammedov 
> ---
> PS:
> it's alternative to full revert of [1], I've posted earlier
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2205600.html
> so fii free to pick up whatever is better by now
> ---
>  arch/x86/kvm/lapic.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 34a7e0533dad..5696831d4005 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -2556,6 +2556,7 @@ int kvm_apic_set_state(struct kvm_vcpu *vcpu, struct 
> kvm_lapic_state *s)
>   struct kvm_lapic *apic = vcpu->arch.apic;
>   int r;
>  
> + apic->vcpu->kvm->arch.apic_map_dirty = true;
>   kvm_lapic_set_base(vcpu, vcpu->arch.apic_base);
>   /* set SPIV separately to get count of SW disabled APICs right */
>   apic_set_spiv(apic, *((u32 *)(s->regs + APIC_SPIV)));
> 

Queued, but it's better to set apic_map_dirty just before the call to
kvm_recalculate_apic_map, or you can have a variant of the race that you
pointed out.

Paolo

Re: [PATCH 0/3] pinctrl: single: support #pinctrl-cells = 2

[Tony Lindgren]

* Drew Fustini  [200622 16:47]:
> On Mon, Jun 22, 2020 at 09:11:32AM -0700, Tony Lindgren wrote:
> > * Drew Fustini  [200618 05:52]:
> > > Currently, pinctrl-single only allows #pinctrl-cells = 1.
> > > 
> > > This series will allow pinctrl-single to also support #pinctrl-cells = 2
> > > 
> > > If "pinctrl-single,pins" has 3 arguments (offset, conf, mux) then
> > > pcs_parse_one_pinctrl_entry() does an OR operation on to get the
> > > value to store in the register.
> > > 
> > > To take advantage of #pinctrl-cells = 2, the AM33XX_PADCONF macro in
> > > omap.h is modified to keep pin conf and pin mux values separate.
> > 
> > Hmm to me it looks like the order of the patches is the
> > wrong way around here. Don't we need to first change
> > pinctrl-single.c, and then only after that update the
> > dts? And make sure the pinctrl-single.c change does not
> > break anything without changing the dts :)
> > 
> > Regards,
> > 
> > Tony
> 
> Thanks for pointing this out.
> 
> I'll submit new version where:
> [PATCH 1/3] pinctrl: single: parse #pinctrl-cells = 2
> [PATCH 2/3] ARM: dts: change AM33XX_PADCONF macro separate conf and mux
> [PATCH 3/3] ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2

OK thanks. Otherwise sounds like git bisect will break for booting.

Regards,

Tony

[PATCH 4/6] soc: ti: omap-prm: Configure omap4 and 5 l4_abe power domain

[Tony Lindgren]

Let's add omap4 and 5 l4_abe interconnect instance for the power
domain.

Signed-off-by: Tony Lindgren 
---
 drivers/soc/ti/omap_prm.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -95,6 +95,13 @@ struct omap_reset_data {
 
 #define PRM_ST_INTRANSITIONBIT(20)
 
+static const struct __maybe_unused omap_prm_domain_map omap_prm_all = {
+   .usable_modes = BIT(OMAP_PRMD_ON_ACTIVE) | BIT(OMAP_PRMD_ON_INACTIVE) |
+   BIT(OMAP_PRMD_RETENTION) | BIT(OMAP_PRMD_OFF),
+   .statechange = 1,
+   .logicretstate = 1,
+};
+
 static const struct __maybe_unused omap_prm_domain_map omap_prm_noinact = {
.usable_modes = BIT(OMAP_PRMD_ON_ACTIVE) | BIT(OMAP_PRMD_RETENTION) |
BIT(OMAP_PRMD_OFF),
@@ -102,6 +109,13 @@ static const struct __maybe_unused omap_prm_domain_map 
omap_prm_noinact = {
.logicretstate = 1,
 };
 
+static const struct __maybe_unused omap_prm_domain_map omap_prm_nooff = {
+   .usable_modes = BIT(OMAP_PRMD_ON_ACTIVE) | BIT(OMAP_PRMD_ON_INACTIVE) |
+   BIT(OMAP_PRMD_RETENTION),
+   .statechange = 1,
+   .logicretstate = 1,
+};
+
 static const struct __maybe_unused omap_prm_domain_map omap_prm_onoff_noauto = 
{
.usable_modes = BIT(OMAP_PRMD_ON_ACTIVE) | BIT(OMAP_PRMD_OFF),
.statechange = 1,
@@ -127,6 +141,10 @@ static const struct omap_rst_map rst_map_012[] = {
 
 static const struct omap_prm_data omap4_prm_data[] = {
{ .name = "tesla", .base = 0x4a306400, .rstctrl = 0x10, .rstst = 0x14, 
.rstmap = rst_map_01 },
+   {
+   .name = "abe", .base = 0x4a306500,
+   .pwrstctrl = 0, .pwrstst = 0x4, .dmap = _prm_all,
+   },
{ .name = "core", .base = 0x4a306700, .rstctrl = 0x210, .rstst = 0x214, 
.clkdm_name = "ducati", .rstmap = rst_map_012 },
{ .name = "ivahd", .base = 0x4a306f00, .rstctrl = 0x10, .rstst = 0x14, 
.rstmap = rst_map_012 },
{ .name = "device", .base = 0x4a307b00, .rstctrl = 0x0, .rstst = 0x4, 
.rstmap = rst_map_01, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
@@ -135,6 +153,10 @@ static const struct omap_prm_data omap4_prm_data[] = {
 
 static const struct omap_prm_data omap5_prm_data[] = {
{ .name = "dsp", .base = 0x4ae06400, .rstctrl = 0x10, .rstst = 0x14, 
.rstmap = rst_map_01 },
+   {
+   .name = "abe", .base = 0x4ae06500,
+   .pwrstctrl = 0, .pwrstst = 0x4, .dmap = _prm_nooff,
+   },
{ .name = "core", .base = 0x4ae06700, .rstctrl = 0x210, .rstst = 0x214, 
.clkdm_name = "ipu", .rstmap = rst_map_012 },
{ .name = "iva", .base = 0x4ae07200, .rstctrl = 0x10, .rstst = 0x14, 
.rstmap = rst_map_012 },
{ .name = "device", .base = 0x4ae07c00, .rstctrl = 0x0, .rstst = 0x4, 
.rstmap = rst_map_01, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
-- 
2.27.0

[PATCH 2/6] soc: ti: omap-prm: Add basic power domain support

[Tony Lindgren]

The PRM controller has currently only support for resets while the power
domains are still handled in the platform code.

Let's add basic power domain support to enable and disable a PRM
controlled power domain if configured in the devicetree. This can be
used for various hardware accelerators, and interconnect instances.

Further support can be added later on as needed for runtime configuration
based on domain-idle-states.

Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/Kconfig |   1 +
 drivers/soc/ti/omap_prm.c   | 228 +++-
 2 files changed, 228 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -7,6 +7,7 @@ config ARCH_OMAP2
depends on ARCH_MULTI_V6
select ARCH_OMAP2PLUS
select CPU_V6
+   select PM_GENERIC_DOMAINS if PM
select SOC_HAS_OMAP2_SDRC
 
 config ARCH_OMAP3
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -10,14 +10,39 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include 
 
+enum omap_prm_domain_mode {
+   OMAP_PRMD_OFF,
+   OMAP_PRMD_RETENTION,
+   OMAP_PRMD_ON_INACTIVE,
+   OMAP_PRMD_ON_ACTIVE,
+};
+
+struct omap_prm_domain_map {
+   unsigned int usable_modes;  /* Mask of hardware supported modes */
+   unsigned long statechange:1;/* Optional low-power state change */
+   unsigned long logicretstate:1;  /* Optional logic off mode */
+};
+
+struct omap_prm_domain {
+   struct device *dev;
+   struct omap_prm *prm;
+   struct generic_pm_domain pd;
+   u16 pwrstctrl;
+   u16 pwrstst;
+   const struct omap_prm_domain_map *cap;
+   u32 pwrstctrl_saved;
+};
+
 struct omap_rst_map {
s8 rst;
s8 st;
@@ -27,6 +52,9 @@ struct omap_prm_data {
u32 base;
const char *name;
const char *clkdm_name;
+   u16 pwrstctrl;
+   u16 pwrstst;
+   const struct omap_prm_domain_map *dmap;
u16 rstctrl;
u16 rstst;
const struct omap_rst_map *rstmap;
@@ -36,6 +64,7 @@ struct omap_prm_data {
 struct omap_prm {
const struct omap_prm_data *data;
void __iomem *base;
+   struct omap_prm_domain *prmd;
 };
 
 struct omap_reset_data {
@@ -47,6 +76,7 @@ struct omap_reset_data {
struct device *dev;
 };
 
+#define genpd_to_prm_domain(gpd) container_of(gpd, struct omap_prm_domain, pd)
 #define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
 
 #define OMAP_MAX_RESETS8
@@ -58,6 +88,13 @@ struct omap_reset_data {
 
 #define OMAP_PRM_HAS_RESETS(OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_RSTST)
 
+#define PRM_STATE_MAX_WAIT 1
+#define PRM_LOGICRETSTATE  BIT(2)
+#define PRM_LOWPOWERSTATECHANGEBIT(4)
+#define PRM_POWERSTATE_MASKOMAP_PRMD_ON_ACTIVE
+
+#define PRM_ST_INTRANSITIONBIT(20)
+
 static const struct omap_rst_map rst_map_0[] = {
{ .rst = 0, .st = 0 },
{ .rst = -1 },
@@ -151,6 +188,180 @@ static const struct of_device_id omap_prm_id_table[] = {
{ },
 };
 
+#ifdef DEBUG
+static void omap_prm_domain_show_state(struct omap_prm_domain *prmd,
+  const char *desc)
+{
+   dev_dbg(prmd->dev, "%s %s: %08x/%08x\n",
+   prmd->pd.name, desc,
+   readl_relaxed(prmd->prm->base + prmd->pwrstctrl),
+   readl_relaxed(prmd->prm->base + prmd->pwrstst));
+}
+#else
+static inline void omap_prm_domain_show_state(struct omap_prm_domain *prmd,
+ const char *desc)
+{
+}
+#endif
+
+static int omap_prm_domain_power_on(struct generic_pm_domain *domain)
+{
+   struct omap_prm_domain *prmd;
+   int ret;
+   u32 v;
+
+   prmd = genpd_to_prm_domain(domain);
+   if (!prmd->cap)
+   return 0;
+
+   omap_prm_domain_show_state(prmd, "on: previous state");
+
+   if (prmd->pwrstctrl_saved)
+   v = prmd->pwrstctrl_saved;
+   else
+   v = readl_relaxed(prmd->prm->base + prmd->pwrstctrl);
+
+   writel_relaxed(v | OMAP_PRMD_ON_ACTIVE,
+  prmd->prm->base + prmd->pwrstctrl);
+
+   /* wait for the transition bit to get cleared */
+   ret = readl_relaxed_poll_timeout(prmd->prm->base + prmd->pwrstst,
+v, !(v & PRM_ST_INTRANSITION), 1,
+PRM_STATE_MAX_WAIT);
+   if (ret)
+   dev_err(prmd->dev, "%s: %s timed out\n",
+   prmd->pd.name, __func__);
+
+   omap_prm_domain_show_state(prmd, "on: new state");
+
+   return ret;
+}
+
+/* No need to check for holes in the mask for the lowest mode */
+static int omap_prm_domain_find_lowest(struct 

[PATCH 1/6] dt-bindings: omap: Update PRM binding for genpd

[Tony Lindgren]

The PRM (Power and Reset Module) has a register to enable and disable
the related power domain, so let's update the binding for that.

Cc: devicet...@vger.kernel.org
Cc: Rob Herring 
Signed-off-by: Tony Lindgren 
---
 Documentation/devicetree/bindings/arm/omap/prm-inst.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt 
b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
--- a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
+++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
@@ -18,6 +18,7 @@ Required properties:
(base address and length)
 
 Optional properties:
+- #power-domain-cells: Should be 0 if the instance is a power domain provider.
 - #reset-cells:Should be 1 if the PRM instance in question supports 
resets.
 
 Example:
@@ -25,5 +26,6 @@ Example:
 prm_dsp2: prm@1b00 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0x1b00 0x40>;
+   #power-domain-cells = <0>;
#reset-cells = <1>;
 };
-- 
2.27.0

Re: [GIT PULL] regmap fixes for v5.8-rc2

[Linus Torvalds]

On Mon, Jun 22, 2020 at 5:09 AM Mark Brown  wrote:
>
> This (and my other pull requests today) are unsigned because I've
> automated the final checks and sending of the mails and that's not
> really compatible with signing the mails.

I don't personally check email signatures anyway. I do check the git
signed tags. So that's fine.

That said, automating the mailing is *not* incompatible with having a
real name in the "From" line. Can you please make your scripting at
least say "Mark Brown " rather than just
"broo...@kernel.org".

Not having a real name just looks like bad email etiquette.

 Linus

[PATCH 5/6] ARM: dts: Configure am3 and am4 sgx for genpd and drop platform data

[Tony Lindgren]

We can power off the SGX power domain when not in use when we configure
it for genpd. And with that change, we can now also drop the old unused
legacy platform data.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/am33xx.dtsi |  2 +
 arch/arm/boot/dts/am4372.dtsi |  2 +
 .../omap_hwmod_33xx_43xx_interconnect_data.c  | 16 
 .../omap_hwmod_33xx_43xx_ipblock_data.c   | 40 ---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c|  2 -
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c|  2 -
 6 files changed, 4 insertions(+), 60 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -577,6 +577,7 @@ target-module@5600 {
;
clocks = <_l3_clkctrl AM3_GFX_L3_GFX_CLKCTRL 0>;
clock-names = "fck";
+   power-domains = <_gfx>;
resets = <_gfx 0>;
reset-names = "rstctrl";
#address-cells = <1>;
@@ -616,6 +617,7 @@ prm_device: prm@f00 {
prm_gfx: prm@1100 {
compatible = "ti,am3-prm-inst", "ti,omap-prm-inst";
reg = <0x1100 0x100>;
+   #power-domain-cells = <0>;
#reset-cells = <1>;
};
 };
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -516,6 +516,7 @@ target-module@5600 {
;
clocks = <_l3_clkctrl AM4_GFX_L3_GFX_CLKCTRL 0>;
clock-names = "fck";
+   power-domains = <_gfx>;
resets = <_gfx 0>;
reset-names = "rstctrl";
#address-cells = <1>;
@@ -532,6 +533,7 @@  {
prm_gfx: prm@400 {
compatible = "ti,am4-prm-inst", "ti,omap-prm-inst";
reg = <0x400 0x100>;
+   #power-domain-cells = <0>;
#reset-cells = <1>;
};
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
@@ -74,22 +74,6 @@ struct omap_hwmod_ocp_if am33xx_l3_s__l3_main = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-/* gfx -> l3 main */
-struct omap_hwmod_ocp_if am33xx_gfx__l3_main = {
-   .master = _gfx_hwmod,
-   .slave  = _l3_main_hwmod,
-   .clk= "dpll_core_m4_ck",
-   .user   = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* l3 main -> gfx */
-struct omap_hwmod_ocp_if am33xx_l3_main__gfx = {
-   .master = _l3_main_hwmod,
-   .slave  = _gfx_hwmod,
-   .clk= "dpll_core_m4_ck",
-   .user   = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
 /* l4 wkup -> rtc */
 struct omap_hwmod_ocp_if am33xx_l4_wkup__rtc = {
.master = _l4_wkup_hwmod,
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -133,30 +133,6 @@ struct omap_hwmod_class am33xx_wkup_m3_hwmod_class = {
.name   = "wkup_m3",
 };
 
-/* gfx */
-/* Pseudo hwmod for reset control purpose only */
-static struct omap_hwmod_class am33xx_gfx_hwmod_class = {
-   .name   = "gfx",
-};
-
-static struct omap_hwmod_rst_info am33xx_gfx_resets[] = {
-   { .name = "gfx", .rst_shift = 0, .st_shift = 0},
-};
-
-struct omap_hwmod am33xx_gfx_hwmod = {
-   .name   = "gfx",
-   .class  = _gfx_hwmod_class,
-   .clkdm_name = "gfx_l3_clkdm",
-   .main_clk   = "gfx_fck_div_ck",
-   .prcm   = {
-   .omap4  = {
-   .modulemode = MODULEMODE_SWCTRL,
-   },
-   },
-   .rst_lines  = am33xx_gfx_resets,
-   .rst_lines_cnt  = ARRAY_SIZE(am33xx_gfx_resets),
-};
-
 /*
  * 'prcm' class
  * power and reset manager (whole prcm infrastructure)
@@ -319,22 +295,14 @@ static void omap_hwmod_am33xx_clkctrl(void)
CLKCTRL(am33xx_l4_ls_hwmod, AM33XX_CM_PER_L4LS_CLKCTRL_OFFSET);
CLKCTRL(am33xx_l4_wkup_hwmod, AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET);
CLKCTRL(am33xx_l3_main_hwmod, AM33XX_CM_PER_L3_CLKCTRL_OFFSET);
-   CLKCTRL(am33xx_gfx_hwmod, AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET);
CLKCTRL(am33xx_mpu_hwmod , AM33XX_CM_MPU_MPU_CLKCTRL_OFFSET);
CLKCTRL(am33xx_l3_instr_hwmod , AM33XX_CM_PER_L3_INSTR_CLKCTRL_OFFSET);
CLKCTRL(am33xx_ocmcram_hwmod , AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET);
 }
 

[PATCHv3 0/6] Add initial genpd support for omap PRM driver

[Tony Lindgren]

Hi all,

Here is v3 set of patches to add genpd support to the PRM (Power and
Reset Module) driver.

Initially we just add one hardware accelerator power domain for sgx,
and one interconnect instance for l4_abe. The rest of the SoC specific
domain data is probably best added one SoC at a time based on
generated data.

Regards,

Tony

Changes since v2:

- Update binding to clarify a single power domain provider

- Fix maybe unused compile warnings

Changes since v1:

- Dropped clocks from the binding and prm driver as there's no need
  for them as pointed out by Tero

- Add checking for domain transition bit in pwrstst register as
  pointed out by Tero

- Add omap_prm_domain_show_state() for CONFIG_DEBUG

Tony Lindgren (6):
  dt-bindings: omap: Update PRM binding for genpd
  soc: ti: omap-prm: Add basic power domain support
  soc: ti: omap-prm: Configure sgx power domain for am3 and am4
  soc: ti: omap-prm: Configure omap4 and 5 l4_abe power domain
  ARM: dts: Configure am3 and am4 sgx for genpd and drop platform data
  ARM: dts: Configure omap4 and 5 l4_abe for genpd and drop platform
data

 .../devicetree/bindings/arm/omap/prm-inst.txt |   2 +
 arch/arm/boot/dts/am33xx.dtsi |   2 +
 arch/arm/boot/dts/am4372.dtsi |   2 +
 arch/arm/boot/dts/omap4-l4-abe.dtsi   |   6 +-
 arch/arm/boot/dts/omap4.dtsi  |   6 +
 arch/arm/boot/dts/omap5-l4-abe.dtsi   |   6 +-
 arch/arm/boot/dts/omap5.dtsi  |   6 +
 arch/arm/mach-omap2/Kconfig   |   1 +
 .../omap_hwmod_33xx_43xx_interconnect_data.c  |  16 -
 .../omap_hwmod_33xx_43xx_ipblock_data.c   |  40 ---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c|   2 -
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c|   2 -
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c|  33 ---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c|  31 --
 drivers/soc/ti/omap_prm.c | 274 +-
 15 files changed, 298 insertions(+), 131 deletions(-)

-- 
2.27.0

[PATCH 6/6] ARM: dts: Configure omap4 and 5 l4_abe for genpd and drop platform data

[Tony Lindgren]

We can power off l4_abe domain when not in use when we configure it for
genpd. And with that change, we can now also drop the old unused legacy
platform data.

Note that we also need to now use "simple-pm-bus" instead of "simple-bus"
for PM runtime to get enabled for the bus.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/omap4-l4-abe.dtsi|  6 ++--
 arch/arm/boot/dts/omap4.dtsi   |  6 
 arch/arm/boot/dts/omap5-l4-abe.dtsi|  6 ++--
 arch/arm/boot/dts/omap5.dtsi   |  6 
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 33 --
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 31 
 6 files changed, 20 insertions(+), 68 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-l4-abe.dtsi 
b/arch/arm/boot/dts/omap4-l4-abe.dtsi
--- a/arch/arm/boot/dts/omap4-l4-abe.dtsi
+++ b/arch/arm/boot/dts/omap4-l4-abe.dtsi
@@ -1,14 +1,16 @@
 _abe {  /* 0x4010 */
-   compatible = "ti,omap4-l4-abe", "simple-bus";
+   compatible = "ti,omap4-l4-abe", "simple-pm-bus";
reg = <0x4010 0x400>,
  <0x40100400 0x400>;
reg-names = "la", "ap";
+   power-domains = <_abe>;
+   /* OMAP4_L4_ABE_CLKCTRL is read-only */
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x 0x4010 0x10>,  /* segment 0 */
 <0x4900 0x4900 0x10>;
segment@0 { /* 0x4010 */
-   compatible = "simple-bus";
+   compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges =
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -637,6 +637,12 @@ prm_tesla: prm@400 {
#reset-cells = <1>;
};
 
+   prm_abe: prm@500 {
+   compatible = "ti,omap4-prm-inst", "ti,omap-prm-inst";
+   reg = <0x500 0x100>;
+   #power-domain-cells = <0>;
+   };
+
prm_core: prm@700 {
compatible = "ti,omap4-prm-inst", "ti,omap-prm-inst";
reg = <0x700 0x100>;
diff --git a/arch/arm/boot/dts/omap5-l4-abe.dtsi 
b/arch/arm/boot/dts/omap5-l4-abe.dtsi
--- a/arch/arm/boot/dts/omap5-l4-abe.dtsi
+++ b/arch/arm/boot/dts/omap5-l4-abe.dtsi
@@ -1,14 +1,16 @@
 _abe {  /* 0x4010 */
-   compatible = "ti,omap5-l4-abe", "simple-bus";
+   compatible = "ti,omap5-l4-abe", "simple-pm-bus";
reg = <0x4010 0x400>,
  <0x40100400 0x400>;
reg-names = "la", "ap";
+   power-domains = <_abe>;
+   /* OMAP5_L4_ABE_CLKCTRL is read-only */
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x 0x4010 0x10>,  /* segment 0 */
 <0x4900 0x4900 0x10>;
segment@0 { /* 0x4010 */
-   compatible = "simple-bus";
+   compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges =
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -649,6 +649,12 @@ prm_dsp: prm@400 {
#reset-cells = <1>;
};
 
+   prm_abe: prm@500 {
+   compatible = "ti,omap5-prm-inst", "ti,omap-prm-inst";
+   reg = <0x500 0x100>;
+   #power-domain-cells = <0>;
+   };
+
prm_core: prm@700 {
compatible = "ti,omap5-prm-inst", "ti,omap-prm-inst";
reg = <0x700 0x100>;
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -124,21 +124,6 @@ static struct omap_hwmod_class omap44xx_l4_hwmod_class = {
.name   = "l4",
 };
 
-/* l4_abe */
-static struct omap_hwmod omap44xx_l4_abe_hwmod = {
-   .name   = "l4_abe",
-   .class  = _l4_hwmod_class,
-   .clkdm_name = "abe_clkdm",
-   .prcm = {
-   .omap4 = {
-   .clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
-   .context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
-   .lostcontext_mask = OMAP4430_LOSTMEM_AESSMEM_MASK,
-   .flags= HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
-   },
-   },
-};
-
 /* l4_cfg */
 static struct omap_hwmod omap44xx_l4_cfg_hwmod = {
.name   = "l4_cfg",
@@ -935,22 +920,6 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_3 
= {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-/* l3_main_1 -> l4_abe */
-static struct 

Re: [PATCH 0/3] pinctrl: single: support #pinctrl-cells = 2

[Drew Fustini]

On Mon, Jun 22, 2020 at 09:11:32AM -0700, Tony Lindgren wrote:
> * Drew Fustini  [200618 05:52]:
> > Currently, pinctrl-single only allows #pinctrl-cells = 1.
> > 
> > This series will allow pinctrl-single to also support #pinctrl-cells = 2
> > 
> > If "pinctrl-single,pins" has 3 arguments (offset, conf, mux) then
> > pcs_parse_one_pinctrl_entry() does an OR operation on to get the
> > value to store in the register.
> > 
> > To take advantage of #pinctrl-cells = 2, the AM33XX_PADCONF macro in
> > omap.h is modified to keep pin conf and pin mux values separate.
> 
> Hmm to me it looks like the order of the patches is the
> wrong way around here. Don't we need to first change
> pinctrl-single.c, and then only after that update the
> dts? And make sure the pinctrl-single.c change does not
> break anything without changing the dts :)
> 
> Regards,
> 
> Tony

Thanks for pointing this out.

I'll submit new version where:
[PATCH 1/3] pinctrl: single: parse #pinctrl-cells = 2
[PATCH 2/3] ARM: dts: change AM33XX_PADCONF macro separate conf and mux
[PATCH 3/3] ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2

-drew

[PATCH V7 1/4] x86/resctrl: Enable user to view and select thread throttling mode

[Reinette Chatre]

Intel Memory Bandwidth Allocation (MBA) control is provided per
processor core. At the same time different CLOS, configured with
different bandwidth percentages, can be assigned to the hardware
threads sharing a core. In the original implementation of MBA the
maximum throttling of the per-thread CLOS is allocated to the core.
Specifically, the lower bandwidth percentage is allocated to the core.

Newer systems can be configured to allocate either maximum or
minimum throttling of the per-thread CLOS values to the core.

Introduce a new resctrl file, "thread_throttle_mode", on Intel systems
that exposes to the user how per-thread values are allocated to
a core. On systems that support the original MBA implementation the
file will always display "max". On systems that can be configured
the possible values are "min" or "max" that the user can modify by
writing these same words to the file.

AMD confirmed in
https://lore.kernel.org/lkml/18d277fd-6523-319c-d560-66b63ff60...@amd.com
that AMD bandwidth allocation is already at thread level. But AMD does not
use memory delay throttle model to control the allocation like Intel does.
So, to avoid any confusion the thread throttling mode would be UNDEFINED
on AMD systems and the "thread_throttle_mode" file will not be visible.

Cc: Babu Moger 
Signed-off-by: Reinette Chatre 
---
No changes since V6

 Documentation/x86/resctrl_ui.rst   |  19 ++-
 arch/x86/kernel/cpu/resctrl/core.c |  49 +++
 arch/x86/kernel/cpu/resctrl/internal.h |  47 +-
 arch/x86/kernel/cpu/resctrl/rdtgroup.c | 196 -
 4 files changed, 302 insertions(+), 9 deletions(-)

diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
index 5368cedfb530..861ee2816470 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl_ui.rst
@@ -138,6 +138,19 @@ with respect to allocation:
non-linear. This field is purely informational
only.
 
+"thread_throttle_mode":
+   Indicator (on some CPU models control) on Intel systems
+   of how tasks running on threads of a physical core are
+   throttled in cases where they request different memory
+   bandwidth percentages:
+
+   "min":
+   the largest percentage is applied
+   to all threads
+   "max":
+   the smallest percentage is applied
+   to all threads
+
 If RDT monitoring is available there will be an "L3_MON" directory
 with the following files:
 
@@ -364,8 +377,10 @@ to the next control step available on the hardware.
 
 The bandwidth throttling is a core specific mechanism on some of Intel
 SKUs. Using a high bandwidth and a low bandwidth setting on two threads
-sharing a core will result in both threads being throttled to use the
-low bandwidth. The fact that Memory bandwidth allocation(MBA) is a core
+sharing a core may result in both threads being throttled to use the
+low bandwidth (see "thread_throttle_mode").
+
+The fact that Memory bandwidth allocation(MBA) may be a core
 specific mechanism where as memory bandwidth monitoring(MBM) is done at
 the package level may lead to confusion when users try to apply control
 via the MBA and then monitor the bandwidth to see if the controls are
diff --git a/arch/x86/kernel/cpu/resctrl/core.c 
b/arch/x86/kernel/cpu/resctrl/core.c
index 12f967c6b603..687221cae5c3 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -250,6 +250,40 @@ static inline bool rdt_get_mb_table(struct rdt_resource *r)
return false;
 }
 
+/*
+ * Restore the MBA configuration from the cached configuration. Used for
+ * the case when an entire package was offline at the time the user made
+ * the configuration change.
+ */
+static void mba_cfg_reconfigure_throttle_mode(struct rdt_resource *r)
+{
+   if (r->alloc_capable && r == _resources_all[RDT_RESOURCE_MBA] &&
+   r->membw.arch_throttle_mode == THREAD_THROTTLE_MIN_MAX)
+   wrmsrl(MSR_MBA_CFG, mba_cfg_msr);
+}
+
+/*
+ * Model-specific test to determine if platform where memory bandwidth
+ * control is applied to a core can be configured to apply either the
+ * maximum or minimum of the per-thread delay values.
+ * By default, platforms where memory bandwidth control is applied to a
+ * core will select the maximum delay value of the per-thread CLOS.
+ *
+ * NOTE: delay value programmed to hardware is inverse of bandwidth
+ * percentage configured via user interface.
+ */
+static bool mba_cfg_supports_min_max_intel(void)
+{
+   switch (boot_cpu_data.x86_model) {
+   case INTEL_FAM6_ATOM_TREMONT_D:
+   case INTEL_FAM6_ICELAKE_X:
+   case INTEL_FAM6_ICELAKE_D:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static bool __get_mem_config_intel(struct rdt_resource *r)
 {
union cpuid_0x10_3_eax eax;
@@ 

[PATCH V7 3/4] x86/resctrl: Enable per-thread MBA

[Reinette Chatre]

From: Fenghua Yu 

Current Memory Bandwidth Allocation (MBA) hardware has a limitation:
all threads on the same core must have the same delay value. If there
are different delay values across threads on one core, the original
MBA implementation allocates the max delay value to the core and an
updated implementation allocates either min or max delay value specified
by a configuration MSR across threads on the core.

Newer systems support per-thread MBA such that each thread is allocated
with its own delay value.

If per-thread MBA is supported, report "per-thread" in resctrl file
"info/MB/thread_throttle_mode" to let user applications know memory
bandwidth is allocated per thread and help them fine tune MBA on thread
level.

Signed-off-by: Fenghua Yu 
[reinette: transition patch to use membw_throttle_mode enum]
Signed-off-by: Reinette Chatre 
Reviewed-by: Babu Moger 
---
No changes since V6

 Documentation/x86/resctrl_ui.rst   |  3 +++
 arch/x86/kernel/cpu/resctrl/core.c |  5 -
 arch/x86/kernel/cpu/resctrl/internal.h |  2 ++
 arch/x86/kernel/cpu/resctrl/rdtgroup.c | 11 +++
 4 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
index 861ee2816470..1b066d1aafad 100644
--- a/Documentation/x86/resctrl_ui.rst
+++ b/Documentation/x86/resctrl_ui.rst
@@ -150,6 +150,9 @@ with respect to allocation:
"max":
the smallest percentage is applied
to all threads
+   "per-thread":
+   bandwidth percentages are directly applied to
+   the threads running on the core
 
 If RDT monitoring is available there will be an "L3_MON" directory
 with the following files:
diff --git a/arch/x86/kernel/cpu/resctrl/core.c 
b/arch/x86/kernel/cpu/resctrl/core.c
index 687221cae5c3..716ad71edf80 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -304,7 +304,10 @@ static bool __get_mem_config_intel(struct rdt_resource *r)
}
r->data_width = 3;
 
-   if (mba_cfg_supports_min_max_intel()) {
+   if (boot_cpu_has(X86_FEATURE_PER_THREAD_MBA)) {
+   r->membw.arch_throttle_mode = THREAD_THROTTLE_PER_THREAD;
+   thread_throttle_mode_init_ro();
+   } else if (mba_cfg_supports_min_max_intel()) {
r->membw.arch_throttle_mode = THREAD_THROTTLE_MIN_MAX;
thread_throttle_mode_init_rw();
} else {
diff --git a/arch/x86/kernel/cpu/resctrl/internal.h 
b/arch/x86/kernel/cpu/resctrl/internal.h
index 6b9b21d67c9b..e198ea2a8468 100644
--- a/arch/x86/kernel/cpu/resctrl/internal.h
+++ b/arch/x86/kernel/cpu/resctrl/internal.h
@@ -391,11 +391,13 @@ struct rdt_cache {
  * @THREAD_THROTTLE_MAX_ONLY:  Memory bandwidth is throttled at the core
  * always using smallest bandwidth percentage
  * assigned to threads, aka "max throttling"
+ * @THREAD_THROTTLE_PER_THREAD:Memory bandwidth is throttled at the 
thread
  */
 enum membw_throttle_mode {
THREAD_THROTTLE_UNDEFINED = 0,
THREAD_THROTTLE_MIN_MAX,
THREAD_THROTTLE_MAX_ONLY,
+   THREAD_THROTTLE_PER_THREAD,
 };
 
 /**
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c 
b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 3f9d03f72005..25c7379ddb0b 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -1038,6 +1038,11 @@ static int max_threshold_occ_show(struct 
kernfs_open_file *of,
  * with the maximum delay value that from the software interface will be
  * the minimum of the bandwidth percentages assigned to the hardware threads
  * sharing the core.
+ *
+ * Some systems (identified by X86_FEATURE_PER_THREAD_MBA enumerated via CPUID)
+ * support per-thread MBA. On these systems hardware doesn't apply the minimum
+ * or maximum delay value to all threads in a core. Instead, a thread is
+ * allocated with the delay value that is assigned to the thread.
  */
 static int rdt_thread_throttle_mode_show(struct kernfs_open_file *of,
 struct seq_file *seq, void *v)
@@ -1047,12 +1052,18 @@ static int rdt_thread_throttle_mode_show(struct 
kernfs_open_file *of,
 
mutex_lock(_mutex);
 
+   if (r->membw.arch_throttle_mode == THREAD_THROTTLE_PER_THREAD) {
+   seq_puts(seq, "per-thread\n");
+   goto out;
+   }
+
if (r->membw.arch_throttle_mode == THREAD_THROTTLE_MIN_MAX)
throttle_mode = mba_cfg_msr & MBA_THROTTLE_MODE_MASK;
 
seq_puts(seq,
 throttle_mode == MBA_THROTTLE_MODE_MIN ? "min\n" : "max\n");
 
+out:
mutex_unlock(_mutex);
return 0;
 }
-- 
2.26.2

[PATCH V7 4/4] x86/resctrl: Use appropriate API for strings terminated by newline

[Reinette Chatre]

The user input to files in the resctrl filesystem are expected to be
terminated with a newline. Testing the user input includes a test for
the presence of a newline and then replacing the newline with NUL
byte followed by comparison using strcmp().

sysfs_streq() exists to test if strings are equal, treating both NUL and
newline-then-NUL as equivalent string terminations. Even more,
sysfs_match_string() exists to match a given string in an array using
sysfs_streq().

Replace existing strcmp() comparisons of strings that are terminated
with a newline with more appropriate sysfs_streq() via the
sysfs_match_string() API that can perform the match across the different
mode strings that are already maintained in an array.

Suggested-by: Andy Shevchenko 
Signed-off-by: Reinette Chatre 
Reviewed-by: Andy Shevchenko 
---
Changes since V6:
- Add Andy's Reviewed-by tag

 arch/x86/kernel/cpu/resctrl/rdtgroup.c | 28 ++
 1 file changed, 11 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c 
b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 25c7379ddb0b..dfd3c6f58901 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -1414,13 +1414,11 @@ static ssize_t rdtgroup_mode_write(struct 
kernfs_open_file *of,
   char *buf, size_t nbytes, loff_t off)
 {
struct rdtgroup *rdtgrp;
-   enum rdtgrp_mode mode;
int ret = 0;
+   int user_m;
 
-   /* Valid input requires a trailing newline */
-   if (nbytes == 0 || buf[nbytes - 1] != '\n')
+   if (nbytes == 0)
return -EINVAL;
-   buf[nbytes - 1] = '\0';
 
rdtgrp = rdtgroup_kn_lock_live(of->kn);
if (!rdtgrp) {
@@ -1430,29 +1428,25 @@ static ssize_t rdtgroup_mode_write(struct 
kernfs_open_file *of,
 
rdt_last_cmd_clear();
 
-   mode = rdtgrp->mode;
+   user_m = sysfs_match_string(rdt_mode_str, buf);
 
-   if ((!strcmp(buf, "shareable") && mode == RDT_MODE_SHAREABLE) ||
-   (!strcmp(buf, "exclusive") && mode == RDT_MODE_EXCLUSIVE) ||
-   (!strcmp(buf, "pseudo-locksetup") &&
-mode == RDT_MODE_PSEUDO_LOCKSETUP) ||
-   (!strcmp(buf, "pseudo-locked") && mode == RDT_MODE_PSEUDO_LOCKED))
+   /* Do nothing and return success if user asks for current mode */
+   if (user_m == rdtgrp->mode)
goto out;
 
-   if (mode == RDT_MODE_PSEUDO_LOCKED) {
+   if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED) {
rdt_last_cmd_puts("Cannot change pseudo-locked group\n");
ret = -EINVAL;
goto out;
}
 
-   if (!strcmp(buf, "shareable")) {
+   if (user_m == RDT_MODE_SHAREABLE) {
if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
ret = rdtgroup_locksetup_exit(rdtgrp);
if (ret)
goto out;
}
-   rdtgrp->mode = RDT_MODE_SHAREABLE;
-   } else if (!strcmp(buf, "exclusive")) {
+   } else if (user_m == RDT_MODE_EXCLUSIVE) {
if (!rdtgroup_mode_test_exclusive(rdtgrp)) {
ret = -EINVAL;
goto out;
@@ -1462,16 +1456,16 @@ static ssize_t rdtgroup_mode_write(struct 
kernfs_open_file *of,
if (ret)
goto out;
}
-   rdtgrp->mode = RDT_MODE_EXCLUSIVE;
-   } else if (!strcmp(buf, "pseudo-locksetup")) {
+   } else if (user_m == RDT_MODE_PSEUDO_LOCKSETUP) {
ret = rdtgroup_locksetup_enter(rdtgrp);
if (ret)
goto out;
-   rdtgrp->mode = RDT_MODE_PSEUDO_LOCKSETUP;
} else {
rdt_last_cmd_puts("Unknown or unsupported mode\n");
ret = -EINVAL;
+   goto out;
}
+   rdtgrp->mode = user_m;
 
 out:
rdtgroup_kn_unlock(of->kn);
-- 
2.26.2

[PATCH V7 0/4] x86/resctrl: Enable user to view and select thread throttling mode

[Reinette Chatre]

V6 upstream submission available from:
https://lore.kernel.org/lkml/cover.1589922949.git.reinette.cha...@intel.com

Patches apply against v5.8-rc2
base-commit: 48778464bb7d346b47157d21ffde2af6b2d39110

Changes since V6:
- Rebase against v5.8-rc2
- Add Andy's Reviewed-by tag to patch 4

V5 upstream submission available from:
https://lore.kernel.org/lkml/cover.1589844108.git.reinette.cha...@intel.com

Patches apply against x86/cache branch commit 0c4d5ba1b998e of tip repo at
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

Changes since V5:
- Remove the early check of the sysfs_match_string() return code. (Andy)

V4 upstream submission available from:
https://lore.kernel.org/lkml/cover.1589652468.git.reinette.cha...@intel.com

Patches apply against x86/cache branch commit 0c4d5ba1b998e of tip repo at
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

Changes since V4:
- Pick up Babu's "Reviewed-by" tags.
- Three checks are performed before the MBA_CFG register is updated from
  its cache. Move all checks to the same if statement. (Babu)
- Remove unnecessary return statement when there is only a switch statement
  in the function that is already handling all cases. (Babu)
- Remove "mode" local variable from rdtgroup_mode_write(). This variable
  was previously used to create shorter lines with the original strcmp()
  code that was removed in patch 4/4.
- Andy pointed out that the repeated assignment to rdtgrp->mode could be
  replaced by a single assignment after all the checks. This was initially
  rejected because it would let the "RDT_MODE_PSEUDO_LOCKED" assignment
  slip through. Even so, Andy's feedback revealed that the new changes
  unintentionally let a user's attempt at setting the mode to pseudo-locked
  be silently ignored where it previously reported an error. Restore original
  user space behavior by returning success when user attempts to change any
  mode when it is already the current mode (including pseudo-locked) and
  returning failure when user attempts to set the mode to pseudo-locked.
  After this change it is possible to follow Andy's original suggestion
  of using a single assignment. (Andy)

V3 upstream submission available from:
https://lore.kernel.org/lkml/cover.1588808537.git.reinette.cha...@intel.com

Patches apply against x86/cache branch of tip repo at
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

Changes since V3:
- Maintain the thread throttling mode as a property ("arch_throttle_mode")
  of the memory bandwidth allocation resource
  instead of calling a function that queries the system's model each time
  this information is needed. Use this new property generically throughout
  with the goal of being independent of architecture. (Babu)
- Remove "intel" from thread_throttle_mode_init_intel_rw() and
  thread_throttle_mode_init_intel_ro() in anticipation of usage by other
  architectures.
- Use function parameter to update_mba_cfg() directly instead of having
  local variable point to it. (Fenghua)
- Remove unnecessary additional check whether platform supports feature
  from the "thread_throttle_mode" callback. The file will only be
  accessible on platforms that support the feature.
- Rework commit message of first patch to be more complete regarding
  support of all architectures after incorporating AMD feedback.
- View the thread throttle mode with rdtgroup mutex held since it is using
  cached information that may be changed concurrently.
- Remove unnecessary empty line. (Babu)

V2 upstream submission available from:
https://lore.kernel.org/lkml/cover.1586801373.git.reinette.cha...@intel.com

Changes since V2:
- Rebase on top of recently merged series "x86/resctrl: Support wider
  MBM counters". Small change needed to take into account
  asm/resctrl_sched.h -> asm/resctrl.h name change.
- Fix rST formatting of documentation (resctrl_ui.rst) describing
  new "thread_throttle_mode" resctrl file.
- Use boot_cpu_has() instead of static_cpu_has() when determining what
  to display to user (slow path).

V1 upstream submission available from:
https://lore.kernel.org/lkml/cover.1585765499.git.reinette.cha...@intel.com

A notable change since V1 is the inclusion of two additional patches from
Fenghua Yu that introduce the new per-thread MBA feature. These changes are
added to this series because they are small and closely related to the
original submission. The per-thread MBA feature is a hardware advancement
that requires no software interface changes. The patches added just enumerate
the feature and expose it to userspace by showing "per-thread" in the new
resctrl file "thread_throttle_mode" to help user applications fine tune
performance.

There are currently a few resctrl changes outstanding for upstream inclusion.
To support their consideration all outstanding resctrl patches can be
viewed at https://github.com/rchatre/linux.git (branch resctrl/next)

Changes since V1 (also documented within patches to which they apply):
- Rebased on top of 

[PATCH V7 2/4] x86/resctrl: Enumerate per-thread MBA

[Reinette Chatre]

From: Fenghua Yu 

Some systems support per-thread Memory Bandwidth Allocation (MBA) which
applies a throttling delay value to each hardware thread instead of to
a core. Per-thread MBA is enumerated by CPUID.

No feature flag is shown in /proc/cpuinfo. User applications need to
check a resctrl throttling mode info file to know if the feature is
supported.

Signed-off-by: Fenghua Yu 
Signed-off-by: Reinette Chatre 
Reviewed-by: Babu Moger 
---
No changes since V6

 arch/x86/include/asm/cpufeatures.h | 1 +
 arch/x86/kernel/cpu/cpuid-deps.c   | 1 +
 arch/x86/kernel/cpu/scattered.c| 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index 02dabc9e77b0..ee5729da8379 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -286,6 +286,7 @@
 #define X86_FEATURE_FENCE_SWAPGS_USER  (11*32+ 4) /* "" LFENCE in user entry 
SWAPGS path */
 #define X86_FEATURE_FENCE_SWAPGS_KERNEL(11*32+ 5) /* "" LFENCE in 
kernel entry SWAPGS path */
 #define X86_FEATURE_SPLIT_LOCK_DETECT  (11*32+ 6) /* #AC for split lock */
+#define X86_FEATURE_PER_THREAD_MBA (11*32+ 7) /* "" Per-thread Memory 
Bandwidth Allocation */
 
 /* Intel-defined CPU features, CPUID level 0x0007:1 (EAX), word 12 */
 #define X86_FEATURE_AVX512_BF16(12*32+ 5) /* AVX512 BFLOAT16 
instructions */
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 3cbe24ca80ab..3e30b26c50ef 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -69,6 +69,7 @@ static const struct cpuid_dep cpuid_deps[] = {
{ X86_FEATURE_CQM_MBM_TOTAL,X86_FEATURE_CQM_LLC   },
{ X86_FEATURE_CQM_MBM_LOCAL,X86_FEATURE_CQM_LLC   },
{ X86_FEATURE_AVX512_BF16,  X86_FEATURE_AVX512VL  },
+   { X86_FEATURE_PER_THREAD_MBA,   X86_FEATURE_MBA   },
{}
 };
 
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index 62b137c3c97a..bccfc9ff3cc1 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -35,6 +35,7 @@ static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },
{ X86_FEATURE_CDP_L2,   CPUID_ECX,  2, 0x0010, 2 },
{ X86_FEATURE_MBA,  CPUID_EBX,  3, 0x0010, 0 },
+   { X86_FEATURE_PER_THREAD_MBA,   CPUID_ECX,  0, 0x0010, 3 },
{ X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
{ X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
{ X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
-- 
2.26.2

Re: [PATCH 4/5] Huawei BMA: Adding Huawei BMA driver: cdev_veth_drv

[Randy Dunlap]

On 6/22/20 9:03 AM, yunaixin03...@163.com wrote:
> diff --git a/drivers/net/ethernet/huawei/bma/Makefile 
> b/drivers/net/ethernet/huawei/bma/Makefile
> index e6e46d820082..c626618f47fb 100644
> --- a/drivers/net/ethernet/huawei/bma/Makefile
> +++ b/drivers/net/ethernet/huawei/bma/Makefile
> @@ -5,3 +5,4 @@
>  obj-$(CONFIG_BMA) += edma_drv/
>  obj-$(CONFIG_BMA) += cdev_drv/
>  obj-$(CONFIG_BMA) += veth_drv/
> +obj-$(CONFIG_BMA) += cdev_veth_drv/
> \ No newline at end of file

Please fix the "No newline" warning.

> diff --git a/drivers/net/ethernet/huawei/bma/cdev_veth_drv/Kconfig 
> b/drivers/net/ethernet/huawei/bma/cdev_veth_drv/Kconfig
> new file mode 100644
> index ..97829c5487c2
> --- /dev/null
> +++ b/drivers/net/ethernet/huawei/bma/cdev_veth_drv/Kconfig
> @@ -0,0 +1,11 @@
> +#
> +# Huawei BMA software driver configuration
> +#
> +
> +config BMA
> + tristate "Huawei BMA Software Communication Driver"
> +
> + ---help---

Juse use
help

> +   This driver supports Huawei BMA Software. It is used 
> +   to communication between Huawei BMA and BMC software.
> +


-- 
~Randy
Reported-by: Randy Dunlap 

Re: [PATCH 1/2] thunderbolt: Add support for separating the flush to SPI and authenticate

[Mika Westerberg]

On Mon, Jun 22, 2020 at 09:30:34AM -0500, Mario Limonciello wrote:
> This allows userspace to have a shorter period of time that the device
> is unusable and to call it at a more convenient time.
> 
> For example flushing the image may happen while the user is using the
> machine and authenticating/rebooting may happen while logging out.
> 
> Signed-off-by: Mario Limonciello 
> ---
>  .../ABI/testing/sysfs-bus-thunderbolt | 11 -
>  drivers/thunderbolt/switch.c  | 43 ---
>  drivers/thunderbolt/tb.h  |  1 +
>  3 files changed, 38 insertions(+), 17 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt 
> b/Documentation/ABI/testing/sysfs-bus-thunderbolt
> index 82e80de78dd0..26b15cbc9881 100644
> --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt
> +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt
> @@ -178,11 +178,18 @@ KernelVersion:  4.13
>  Contact: thunderbolt-softw...@lists.01.org
>  Description: When new NVM image is written to the non-active NVM
>   area (through non_activeX NVMem device), the
> - authentication procedure is started by writing 1 to
> - this file. If everything goes well, the device is
> + authentication procedure is started by writing to
> + this file.
> + If everything goes well, the device is
>   restarted with the new NVM firmware. If the image
>   verification fails an error code is returned instead.
>  
> + This file will accept writing values "1" or "2"
> + - Writing "1" will flush the image to the storage
> + area and authenticate the image in one action.
> + - Writing "2" will only flush the image to the storage
> + area.

Does this ("2") also do the basic validation? I think it does so
probably good to mention that here.

> +
>   When read holds status of the last authentication
>   operation if an error occurred during the process. This
>   is directly the status value from the DMA configuration
> diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
> index d7d60cd9226f..4c476a58db38 100644
> --- a/drivers/thunderbolt/switch.c
> +++ b/drivers/thunderbolt/switch.c
> @@ -27,6 +27,11 @@
>  #define NVM_MIN_SIZE SZ_32K
>  #define NVM_MAX_SIZE SZ_512K
>  
> +enum nvm_write_ops {
> + WRITE_AND_AUTHENTICATE = 1,
> + WRITE_ONLY = 2,
> +};
> +
>  static DEFINE_IDA(nvm_ida);
>  
>  struct nvm_auth_status {
> @@ -164,8 +169,12 @@ static int nvm_validate_and_write(struct tb_switch *sw)
>   }
>  
>   if (tb_switch_is_usb4(sw))
> - return usb4_switch_nvm_write(sw, 0, buf, image_size);
> - return dma_port_flash_write(sw->dma_port, 0, buf, image_size);
> + ret = usb4_switch_nvm_write(sw, 0, buf, image_size);
> + else
> + ret = dma_port_flash_write(sw->dma_port, 0, buf, image_size);
> + if (!ret)
> + sw->nvm->flushed = true;
> + return ret;
>  }
>  
>  static int nvm_authenticate_host_dma_port(struct tb_switch *sw)
> @@ -371,6 +380,7 @@ static int tb_switch_nvm_write(void *priv, unsigned int 
> offset, void *val,
>   }
>   }
>  
> + sw->nvm->flushed = false;
>   sw->nvm->buf_data_size = offset + bytes;
>   memcpy(sw->nvm->buf + offset, val, bytes);
>  
> @@ -1536,7 +1546,7 @@ static ssize_t nvm_authenticate_store(struct device 
> *dev,
>   struct device_attribute *attr, const char *buf, size_t count)
>  {
>   struct tb_switch *sw = tb_to_switch(dev);
> - bool val;
> + int val;
>   int ret;
>  
>   pm_runtime_get_sync(>dev);
> @@ -1552,25 +1562,28 @@ static ssize_t nvm_authenticate_store(struct device 
> *dev,
>   goto exit_unlock;
>   }
>  
> - ret = kstrtobool(buf, );
> + ret = kstrtoint(buf, 10, );
>   if (ret)
>   goto exit_unlock;
>  
>   /* Always clear the authentication status */
>   nvm_clear_auth_status(sw);
>  
> - if (val) {
> - if (!sw->nvm->buf) {
> - ret = -EINVAL;
> - goto exit_unlock;
> - }
> -
> - ret = nvm_validate_and_write(sw);
> - if (ret)
> - goto exit_unlock;
> + if (val > 0) {
> + if (!sw->nvm->flushed) {
> + if (!sw->nvm->buf) {
> + ret = -EINVAL;
> + goto exit_unlock;
> + }
>  
> - sw->nvm->authenticating = true;
> - ret = nvm_authenticate(sw);
> + ret = nvm_validate_and_write(sw);
> + if (ret || val == WRITE_ONLY)
> + goto exit_unlock;
> + }
> + if (val == WRITE_AND_AUTHENTICATE) {
> + sw->nvm->authenticating = 

Re: [PATCH] Revert "kernel/printk: add kmsg SEEK_CUR handling"

[Linus Torvalds]

On Mon, Jun 22, 2020 at 6:38 AM Bruno Meneguele  wrote:
>
> However, the issue with glibc is their fd checking on dprintf using:
>
> lseek(offset == 0, whence == SEEK_CUR)
>
> Which, technically, isn't a relative seek operation in my opinion, thus
> I'm also not sure that returning EINVAL is correct.

Well, I'm not sure there is a "correct". Normal file descriptors are
seekable or not, this is kind of a special one. It's not like you can
read it byte for byte anyway.

There is a "historical behavior".

> Would it make sense to return the next buffer index instead? Basically
> the same as SEEK_END does? The first "if (offset)" in the function would
> prevent any real relative move while SEEK_CUR would return a valid
> address following this buffer behavior of specific points it could seek
> to.

Maybe. At the same time, the way we don't actually return a real
position means that that's very dangerous too. We'll always return
"we're at position zero".

And we never accept byte-by-byte reads and require a "get the whole
record" model.

So I think we might as well accept "kmsg is special".

I don't have hugely strong opinions on it - I certainly agree that
"SEEK_CUR with offset zero could be a no-op", but I also don't think
there's a huge reason to try to change it, considering just _how_
special kmsg is.

   Linus

RE: [PATCH 0/2] Allow breaking up Thunderbolt/USB4 updates

[Mario.Limonciello]

> -Original Message-
> From: Mika Westerberg 
> Sent: Monday, June 22, 2020 11:38 AM
> To: Limonciello, Mario
> Cc: Andreas Noever; Michael Jamet; Yehezkel Bernat; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 0/2] Allow breaking up Thunderbolt/USB4 updates
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi Mario,
> 
> On Mon, Jun 22, 2020 at 09:30:33AM -0500, Mario Limonciello wrote:
> > Currently updates to Thunderbolt and USB4 controllers are fully atomic
> > actions. When writing into the non-active NVM nothing gets flushed to
> > the hardware until authenticate is sent.
> >
> > There has been some desire to improve the perceived performance of these
> > updates, particularly for userland that may perform the update upon
> > a performance sensitive time like logging out.
> >
> > So allow userland to flush the image to hardware at runtime, and then
> > allow authenticating the image at another time.
> >
> > For the Dell WD19TB some specific hardware capability exists that allows
> > extending this to automatically complete the update when unplugged.
> > Export that functionality to userspace as well.
> >
> > This patch series is done relative thunderbolt.git/next.
> 
> Thanks for the patch series. I wonder if you could base this on top of
> my "retimer NVM upgrade" series here (you are also Cc'd):
> 
>   https://lore.kernel.org/linux-usb/20200616135617.85752-1-
> mika.westerb...@linux.intel.com/
> 
> That series moves some of the common NVM functionality into a separate
> file (nvm.c).

Sure thing.  Do you by chance already have that on a public branch somewhere
that I can easily rebase it?

> 
> > Mario Limonciello (2):
> >   thunderbolt: Add support for separating the flush to SPI and
> > authenticate
> >   thunderbolt: Add support for authenticate on disconnect
> >
> >  .../ABI/testing/sysfs-bus-thunderbolt | 24 +-
> >  drivers/thunderbolt/Makefile  |  1 +
> >  drivers/thunderbolt/eeprom.c  |  2 +
> >  drivers/thunderbolt/lc.c  | 14 
> >  drivers/thunderbolt/quirks.c  | 38 +
> >  drivers/thunderbolt/switch.c  | 81 +++
> >  drivers/thunderbolt/tb-quirks.h   | 16 
> >  drivers/thunderbolt/tb.h  |  4 +
> >  drivers/thunderbolt/tb_regs.h |  1 +
> >  9 files changed, 162 insertions(+), 19 deletions(-)
> >  create mode 100644 drivers/thunderbolt/quirks.c
> >  create mode 100644 drivers/thunderbolt/tb-quirks.h
> >
> > --
> > 2.25.1

Re: [PATCH 3/5] Huawei BMA: Adding Huawei BMA driver: host_veth_drv

[Randy Dunlap]

On 6/22/20 9:03 AM, yunaixin03...@163.com wrote:
> diff --git a/drivers/net/ethernet/huawei/bma/Makefile 
> b/drivers/net/ethernet/huawei/bma/Makefile
> index c9bbcbf2a388..e6e46d820082 100644
> --- a/drivers/net/ethernet/huawei/bma/Makefile
> +++ b/drivers/net/ethernet/huawei/bma/Makefile
> @@ -3,4 +3,5 @@
>  # 
>  
>  obj-$(CONFIG_BMA) += edma_drv/
> -obj-$(CONFIG_BMA) += cdev_drv/
> \ No newline at end of file

Please fix the "No newline" warning.

> +obj-$(CONFIG_BMA) += cdev_drv/
> +obj-$(CONFIG_BMA) += veth_drv/
> diff --git a/drivers/net/ethernet/huawei/bma/veth_drv/Kconfig 
> b/drivers/net/ethernet/huawei/bma/veth_drv/Kconfig
> new file mode 100644
> index ..97829c5487c2
> --- /dev/null
> +++ b/drivers/net/ethernet/huawei/bma/veth_drv/Kconfig
> @@ -0,0 +1,11 @@
> +#
> +# Huawei BMA software driver configuration
> +#
> +
> +config BMA
> + tristate "Huawei BMA Software Communication Driver"
> +
> + ---help---

Juse use
help

> +   This driver supports Huawei BMA Software. It is used 
> +   to communication between Huawei BMA and BMC software.
> +


-- 
~Randy
Reported-by: Randy Dunlap 

Re: [PATCH 2/5] Huawei BMA: Adding Huawei BMA driver: host_cdev_drv

[Randy Dunlap]

On 6/22/20 9:03 AM, yunaixin03...@163.com wrote:
> diff --git a/drivers/net/ethernet/huawei/bma/Makefile 
> b/drivers/net/ethernet/huawei/bma/Makefile
> index 8582fb3998fb..c9bbcbf2a388 100644
> --- a/drivers/net/ethernet/huawei/bma/Makefile
> +++ b/drivers/net/ethernet/huawei/bma/Makefile
> @@ -3,3 +3,4 @@
>  # 
>  
>  obj-$(CONFIG_BMA) += edma_drv/
> +obj-$(CONFIG_BMA) += cdev_drv/
> \ No newline at end of file

Please fix the "No newline" warning.

> diff --git a/drivers/net/ethernet/huawei/bma/cdev_drv/Kconfig 
> b/drivers/net/ethernet/huawei/bma/cdev_drv/Kconfig
> new file mode 100644
> index ..97829c5487c2
> --- /dev/null
> +++ b/drivers/net/ethernet/huawei/bma/cdev_drv/Kconfig
> @@ -0,0 +1,11 @@
> +#
> +# Huawei BMA software driver configuration
> +#
> +
> +config BMA
> + tristate "Huawei BMA Software Communication Driver"
> +
> + ---help---

Just use
help

> +   This driver supports Huawei BMA Software. It is used 
> +   to communication between Huawei BMA and BMC software.
> +


-- 
~Randy

Re: [PATCH 0/2] Allow breaking up Thunderbolt/USB4 updates

[Mika Westerberg]

Hi Mario,

On Mon, Jun 22, 2020 at 09:30:33AM -0500, Mario Limonciello wrote:
> Currently updates to Thunderbolt and USB4 controllers are fully atomic
> actions. When writing into the non-active NVM nothing gets flushed to
> the hardware until authenticate is sent.
> 
> There has been some desire to improve the perceived performance of these
> updates, particularly for userland that may perform the update upon
> a performance sensitive time like logging out.
> 
> So allow userland to flush the image to hardware at runtime, and then
> allow authenticating the image at another time.
> 
> For the Dell WD19TB some specific hardware capability exists that allows
> extending this to automatically complete the update when unplugged.
> Export that functionality to userspace as well.
> 
> This patch series is done relative thunderbolt.git/next.

Thanks for the patch series. I wonder if you could base this on top of
my "retimer NVM upgrade" series here (you are also Cc'd):

  
https://lore.kernel.org/linux-usb/20200616135617.85752-1-mika.westerb...@linux.intel.com/

That series moves some of the common NVM functionality into a separate
file (nvm.c).

> Mario Limonciello (2):
>   thunderbolt: Add support for separating the flush to SPI and
> authenticate
>   thunderbolt: Add support for authenticate on disconnect
> 
>  .../ABI/testing/sysfs-bus-thunderbolt | 24 +-
>  drivers/thunderbolt/Makefile  |  1 +
>  drivers/thunderbolt/eeprom.c  |  2 +
>  drivers/thunderbolt/lc.c  | 14 
>  drivers/thunderbolt/quirks.c  | 38 +
>  drivers/thunderbolt/switch.c  | 81 +++
>  drivers/thunderbolt/tb-quirks.h   | 16 
>  drivers/thunderbolt/tb.h  |  4 +
>  drivers/thunderbolt/tb_regs.h |  1 +
>  9 files changed, 162 insertions(+), 19 deletions(-)
>  create mode 100644 drivers/thunderbolt/quirks.c
>  create mode 100644 drivers/thunderbolt/tb-quirks.h
> 
> -- 
> 2.25.1