date:20210114

Hi Ian,

On Fri, Jan 15, 2021 at 6:23 AM Ian Rogers  wrote:
>
> The variable bf is read (for a write call) without being initialized
> triggering a memory sanitizer warning. Use bf in the read and switch the
> write to reading from a string.
>
> Signed-off-by: Ian Rogers 

Acked-by: Namhyung Kim 

Thanks,
Namhyung

> ---
>  tools/lib/perf/tests/test-evlist.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/lib/perf/tests/test-evlist.c 
> b/tools/lib/perf/tests/test-evlist.c
> index 6d8ebe0c2504..1b225fe34a72 100644
> --- a/tools/lib/perf/tests/test-evlist.c
> +++ b/tools/lib/perf/tests/test-evlist.c
> @@ -208,7 +208,6 @@ static int test_mmap_thread(void)
> char path[PATH_MAX];
> int id, err, pid, go_pipe[2];
> union perf_event *event;
> -   char bf;
> int count = 0;
>
> snprintf(path, PATH_MAX, 
> "%s/kernel/debug/tracing/events/syscalls/sys_enter_prctl/id",
> @@ -229,6 +228,7 @@ static int test_mmap_thread(void)
> pid = fork();
> if (!pid) {
> int i;
> +   char bf;
>
> read(go_pipe[0], &bf, 1);
>
> @@ -266,7 +266,7 @@ static int test_mmap_thread(void)
> perf_evlist__enable(evlist);
>
> /* kick the child and wait for it to finish */
> -   write(go_pipe[1], &bf, 1);
> +   write(go_pipe[1], "A", 1);
> waitpid(pid, NULL, 0);
>
> /*
> --
> 2.30.0.296.g2bfb1c46d8-goog
>

[PATCH] drm/rockchip: cdn-dp-core: Fix cdn_dp_resume unused warning

2021-01-14 Thread Palmer Dabbelt

From: Palmer Dabbelt 

cdn_dp_resume is only used under PM_SLEEP, and now that it's static an
unused function warning is triggered undner !PM_SLEEP.  This
conditionally enables the function to avoid the warning.

Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make 
cdn_dp_core_suspend/resume static")
Signed-off-by: Palmer Dabbelt 
---
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a4a45daf93f2..063a60d213ba 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1121,6 +1121,7 @@ static int cdn_dp_suspend(struct device *dev)
return ret;
 }
 
+#ifdef CONFIG_PM_SLEEP
 static int cdn_dp_resume(struct device *dev)
 {
struct cdn_dp_device *dp = dev_get_drvdata(dev);
@@ -1133,6 +1134,7 @@ static int cdn_dp_resume(struct device *dev)
 
return 0;
 }
+#endif
 
 static int cdn_dp_probe(struct platform_device *pdev)
 {
-- 
2.20.1

Re: [PATCH v4 1/1] mfd: intel-m10-bmc: expose mac address and count

2021-01-14 Thread Lee Jones

On Thu, 14 Jan 2021, Russ Weight wrote:

> Create two sysfs entries for exposing the MAC address
> and count from the MAX10 BMC register space. The MAC
> address is the first in a sequential block of MAC addresses
> reserved for the FPGA card. The MAC count is the number
> of MAC addresses in the reserved block.
> 
> Signed-off-by: Russ Weight 
> Signed-off-by: Xu Yilun 
> ---
> v4:
>   - Changed local variables macaddr1 and macaddr2 to macaddr_low
> and macaddr_high
>   - Change macros M10BMC_MACADDR1 and M10BMC_MACADDR2 to
> M10BMC_MAC_LOW and M10BMC_MAC_HIGH
> v3:
>   - Updated Date and KernelVersion in ABI documentation
> v2:
>   - Updated the documentation for the mac_address and mac_count
> sysfs nodes to clarify their usage.
>   - Changed sysfs _show() functions to use sysfs_emit() instead
> of sprintf.
> ---
>  .../ABI/testing/sysfs-driver-intel-m10-bmc| 21 +
>  drivers/mfd/intel-m10-bmc.c   | 43 +++
>  include/linux/mfd/intel-m10-bmc.h |  9 
>  3 files changed, 73 insertions(+)

Changed the subject line to start with an uppercase char and used more
width in the commit message and applied, thanks.

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

Re: [PATCH] perf tools: Resolve symbols against debug file first

Hello,

On Thu, Jan 14, 2021 at 8:17 PM Michael Ellerman  wrote:
>
> Namhyung Kim  writes:
> > On Wed, Jan 13, 2021 at 8:43 PM Jiri Slaby  wrote:
> >>
> >> On 13. 01. 21, 11:46, Jiri Olsa wrote:
> >> > On Wed, Jan 13, 2021 at 09:01:28AM +0100, Jiri Slaby wrote:
> >> >> With LTO, there are symbols like these:
> >> >> /usr/lib/debug/usr/lib64/libantlr4-runtime.so.4.8-4.8-1.4.x86_64.debug
> >> >>   10305: 00955fa4 0 NOTYPE  LOCAL  DEFAULT   29 
> >> >> Predicate.cpp.2bc410e7
> >> >>
> >> >> This comes from a runtime/debug split done by the standard way:
> >> >> objcopy --only-keep-debug $runtime $debug
> >> >> objcopy --add-gnu-debuglink=$debugfn -R .comment -R .GCC.command.line 
> >> >> --strip-all $runtime
> >> >>
> ...
> >> >> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> >> >> index f3577f7d72fe..a31b716fa61c 100644
> >> >> --- a/tools/perf/util/symbol-elf.c
> >> >> +++ b/tools/perf/util/symbol-elf.c
> >> >> @@ -1226,12 +1226,20 @@ int dso__load_sym(struct dso *dso, struct map 
> >> >> *map, struct symsrc *syms_ss,
> >> >>  if (sym.st_shndx == SHN_ABS)
> >> >>  continue;
> >> >>
> >> >> -sec = elf_getscn(runtime_ss->elf, sym.st_shndx);
> >> >> +sec = elf_getscn(syms_ss->elf, sym.st_shndx);
> >> >>  if (!sec)
> >> >>  goto out_elf_end;
> >> >
> >> > we iterate symbols from syms_ss, so the fix seems to be correct
> >> > to call elf_getscn on syms_ss, not on runtime_ss as we do now
> >> >
> >> > I'd think this worked only when runtime_ss == syms_ss
> >>
> >> No, because the headers are copied 1:1 from runtime_ss to syms_ss. And
> >> runtime_ss is then stripped, so only .debug* sections are removed there.
> >> (And syms_ss's are set as NOBITS.)
> >>
> >> We iterated .debug* sections in syms_ss and used runtime_ss section
> >> _headers_ only to adjust symbols (sometimes). That worked.
> >
> > It seems PPC has an opd section only in the runtime_ss and that's why
> > we use it for section headers.
>
> At least on my system (Ubuntu 20.04.1) I see .opd in the debug file with
> NOBITS set:
>
> $ readelf -e vmlinux.debug | grep opd
>   [37] .opd  NOBITS   c1c1f548  01202e14
>
>
> But possibly that's not the case with older toolchains?

I was referring to this commit:

commit 261360b6e90a782f0a63d8f61a67683c376c88cf
Author: Cody P Schafer 
Date:   Fri Aug 10 15:23:01 2012 -0700

perf symbols: Convert dso__load_syms to take 2 symsrc's

To properly handle platforms with an opd section, both a runtime image
(which contains the opd section but possibly lacks symbols) and a symbol
image (which probably lacks an opd section but has symbols).

The next patch ("perf symbol: use both runtime and debug images")
adjusts the callsite in dso__load() to take advantage of being able to
pass both runtime & debug images.

Assumptions made here:

 - The opd section, if it exists in the runtime image, has headers in
   both the runtime image and the debug/syms image.

 - The index of the opd section (again, only if it exists in the runtime
   image) is the same in both the runtime and debug/symbols image.

Both of these are true on RHEL, but it is unclear how accurate they are
in general (on platforms with function descriptors in opd sections).

Signed-off-by: Cody P Schafer 


Thanks,
Namhyung

[PATCH] powerpc: dts: p2020rdb: add missing peripherials

2021-01-14 Thread Pawel Dembicki

This patch adds dts entry for some peripherials:
- i2c: temperature sensor ADT7461
- i2c: eeprom m24256
- i2c: eeprom at24c01
- i2c: pmic zl2006
- i2c: gpio expander
- phy: reset pins for phy
- dsa: switch vsc7385

It was required to adjust rgmii settings for enet0 because switch with
dsa driver act different without 8081 sterring.

Signed-off-by: Pawel Dembicki 
---
 arch/powerpc/boot/dts/fsl/p2020rdb.dts | 73 --
 1 file changed, 70 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/p2020rdb.dts 
b/arch/powerpc/boot/dts/fsl/p2020rdb.dts
index 3acd3890b397..1f2ddeca0375 100644
--- a/arch/powerpc/boot/dts/fsl/p2020rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/p2020rdb.dts
@@ -7,6 +7,9 @@
 
 /include/ "p2020si-pre.dtsi"
 
+#include 
+#include 
+
 / {
model = "fsl,P2020RDB";
compatible = "fsl,P2020RDB";
@@ -131,22 +134,84 @@ partition@110 {
L2switch@2,0 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "vitesse-7385";
+   compatible = "vitesse,vsc7385";
reg = <0x2 0x0 0x2>;
-   };
+   reset-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
 
+   port@1 {
+   reg = <1>;
+   label = "e1-sw-p1";
+   };
+   port@2 {
+   reg = <2>;
+   label = "e1-sw-p2";
+   };
+   port@3 {
+   reg = <3>;
+   label = "e1-sw-p3";
+   };
+   port@4 {
+   reg = <4>;
+   label = "e1-sw-p4";
+   };
+   port@6 {
+   reg = <6>;
+   label = "cpu";
+   ethernet = <&enet0>;
+   phy-mode = "rgmii";
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   pause;
+   };
+   };
+   };
+   };
};
 
soc: soc@ffe0 {
ranges = <0x0 0x0 0xffe0 0x10>;
 
+   gpio0: gpio-controller@fc00 {
+   };
+
i2c@3000 {
+   temperature-sensor@4c {
+   compatible = "adi,adt7461";
+   reg = <0x4c>;
+   };
+
+   eeprom@50 {
+   compatible = "atmel,24c256";
+   reg = <0x50>;
+   };
rtc@68 {
compatible = "dallas,ds1339";
reg = <0x68>;
};
};
 
+   i2c@3100 {
+   pmic@11 {
+   compatible = "zl2006";
+   reg = <0x11>;
+   };
+
+   gpio@18 {
+   compatible = "nxp,pca9557";
+   reg = <0x18>;
+   };
+
+   eeprom@52 {
+   compatible = "atmel,24c01";
+   reg = <0x52>;
+   };
+   };
+
spi@7000 {
flash@0 {
#address-cells = <1>;
@@ -200,10 +265,12 @@ mdio@24520 {
phy0: ethernet-phy@0 {
interrupts = <3 1 0 0>;
reg = <0x0>;
+   reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
};
phy1: ethernet-phy@1 {
interrupts = <3 1 0 0>;
reg = <0x1>;
+   reset-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
};
tbi-phy@2 {
device_type = "tbi-phy";
@@ -233,7 +300,7 @@ ptp_clock@24e00 {
 
enet0: ethernet@24000 {
fixed-link = <1 1 1000 0 0>;
-   phy-connection-type = "rgmii-i

Re: [PATCH v2 5/6] perf stat: Enable iiostat mode for x86 platforms

On Fri, Jan 15, 2021 at 1:41 AM Alexander Antonov
 wrote:
> On 1/14/2021 6:39 AM, Namhyung Kim wrote:
> > On Wed, Jan 13, 2021 at 9:08 PM Alexander Antonov
> >  wrote:
> >>
> >> On 1/6/2021 12:02 PM, Namhyung Kim wrote:
> >>> On Wed, Dec 23, 2020 at 10:03 PM Alexander Antonov
>  diff --git a/tools/perf/perf-iiostat.sh b/tools/perf/perf-iiostat.sh
>  new file mode 100644
>  index ..2c5168d2550b
>  --- /dev/null
>  +++ b/tools/perf/perf-iiostat.sh
>  @@ -0,0 +1,12 @@
>  +#!/bin/bash
>  +# SPDX-License-Identifier: GPL-2.0
>  +# perf iiostat
>  +# Alexander Antonov 
>  +
>  +if [[ "$1" == "show" ]] || [[ "$1" =~ 
>  ([a-f0-9A-F]{1,}):([a-f0-9A-F]{1,2})(,)? ]]; then
>  +DELIMITER="="
>  +else
>  +DELIMITER=" "
>  +fi
>  +
>  +perf stat --iiostat$DELIMITER$*
> >>> Why is this needed?
> >>>
> >>> Thanks,
> >>> Namhyung
> >> Arnaldo raised question relates to format of 'perf stat --iiostat'
> >> subcommand
> >> and explained how it can be changed to 'perf iiostat' through the aliases
> >> mechanism in perf.
> > Yeah, I know that.  What I'm asking is the DELIMITER part.
> >
> > Thanks,
> > Namhyung
> I'm using DELIMITER to resolve two different cases for format of iiostat
> command:
> The first one is the command with an option for iiostat mode, for example:
> 'perf iiostat show' which should be converted to 'perf stat
> --iiostat=show' or
> 'perf iiostat :ae,:5d' to 'perf stat --iiostat=:ae,:5d'.
> The second is the command without any option for iiostat: 'perf iiostat
> -I 1000'
> should be converted to 'perf stat --iiostat -I 1000'.

Can't we simply use a whitespace ?

Thanks,
Namhyung

Re: [PATCH v7 04/11] mfd: mt6360: Combine mt6360 pmic/ldo resources into mt6360 regulator resources

2021-01-14 Thread Lee Jones

On Fri, 15 Jan 2021, Gene Chen wrote:

> Matthias Brugger  於 2021年1月12日 週二 下午8:32寫道：
> >
> >
> >
> > On 12/11/2020 11:39, Gene Chen wrote:
> > > From: Gene Chen 
> > >
> > > Combine mt6360 pmic/ldo resources into mt6360 regulator resources
> > > to simplify the similar resources object.
> > >
> > > Signed-off-by: Gene Chen 
> > > Acked-for-MFD-by: Lee Jones 
> > > ---
> > >  drivers/mfd/mt6360-core.c | 11 +++
> > >  1 file changed, 3 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
> > > index 692e47b..5119e51 100644
> > > --- a/drivers/mfd/mt6360-core.c
> > > +++ b/drivers/mfd/mt6360-core.c
> > > @@ -265,7 +265,7 @@ static const struct resource mt6360_led_resources[] = 
> > > {
> > >   DEFINE_RES_IRQ_NAMED(MT6360_FLED1_STRB_TO_EVT, "fled1_strb_to_evt"),
> > >  };
> > >
> > > -static const struct resource mt6360_pmic_resources[] = {
> > > +static const struct resource mt6360_regulator_resources[] = {
> > >   DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_PGB_EVT, "buck1_pgb_evt"),
> > >   DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OC_EVT, "buck1_oc_evt"),
> > >   DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OV_EVT, "buck1_ov_evt"),
> > > @@ -278,9 +278,6 @@ static const struct resource mt6360_pmic_resources[] 
> > > = {
> > >   DEFINE_RES_IRQ_NAMED(MT6360_LDO7_OC_EVT, "ldo7_oc_evt"),
> > >   DEFINE_RES_IRQ_NAMED(MT6360_LDO6_PGB_EVT, "ldo6_pgb_evt"),
> > >   DEFINE_RES_IRQ_NAMED(MT6360_LDO7_PGB_EVT, "ldo7_pgb_evt"),
> > > -};
> > > -
> > > -static const struct resource mt6360_ldo_resources[] = {
> > >   DEFINE_RES_IRQ_NAMED(MT6360_LDO1_OC_EVT, "ldo1_oc_evt"),
> > >   DEFINE_RES_IRQ_NAMED(MT6360_LDO2_OC_EVT, "ldo2_oc_evt"),
> > >   DEFINE_RES_IRQ_NAMED(MT6360_LDO3_OC_EVT, "ldo3_oc_evt"),
> > > @@ -298,10 +295,8 @@ static const struct mfd_cell mt6360_devs[] = {
> > >   NULL, 0, 0, "mediatek,mt6360-chg"),
> > >   OF_MFD_CELL("mt6360-led", mt6360_led_resources,
> > >   NULL, 0, 0, "mediatek,mt6360-led"),
> > > - OF_MFD_CELL("mt6360-pmic", mt6360_pmic_resources,
> > > - NULL, 0, 0, "mediatek,mt6360-pmic"),
> > > - OF_MFD_CELL("mt6360-ldo", mt6360_ldo_resources,
> > > - NULL, 0, 0, "mediatek,mt6360-ldo"),
> > > + OF_MFD_CELL("mt6360-regulator", mt6360_regulator_resources,
> > > + NULL, 0, 0, "mediatek,mt6360-regulator"),
> >
> > As discussed with the MFD maintainer [1], the regulator (and probably all 
> > cells)
> > shouldn't have a DT binding.
> >
> > So please send a new version which fixes that.
> >
> > Regards,
> > Matthias
> >
> > [1] 
> > https://lore.kernel.org/linux-mediatek/2021064118.ge4...@sirena.org.uk/

I don't think Mark is correct here.

We usually do implement compatible strings for sub-devices and they do
tend to have their own device nodes.

It's a very long time ago since I coded this up myself, but from
memory, you can't have 2 devices share a compatible string.

> Should I use parent's device to find sub-devices of_node if without
> compatible name?
> I trace the function mfd_add_device,
> 
> if (IS_ENABLED(CONFIG_OF) && parent->of_node && cell->of_compatible) {
> .
> ret = mfd_match_of_node_to_dev(pdev, np, cell);
> .
> }
> 
> which is binding mfd sub-device with compatible. Does it be removed in
> the feature?
> 
> > >   OF_MFD_CELL("mt6360-tcpc", NULL,
> > >   NULL, 0, 0, "mediatek,mt6360-tcpc"),
> > >  };
> > >

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

Re: [PATCH v4 0/6] perf c2c: Code refactoring

Hello,

On Fri, Jan 15, 2021 at 12:46 AM Leo Yan  wrote:
>
> This patch series is for several minor code refactoring, which is
> extracted from the patch series "perf c2c: Sort cacheline with all
> loads" [1].
>
> There has a known issue for Arm SPE store operations and Arm SPE is
> the only consumer for soring with all loads, this is the reason in this
> series drops the changes for dimensions and sorting, and only extracts
> the patches related with code refactoring.  So this series doesn't
> introduce any functionality change.
>
> The patches have been tested on x86_64 and compared the result before
> and after applying the patches, and confirmed no difference for the
> output result.
>
> Changes from v3:
> * Refined patch 03/06 to remove unnecessary parentheses and test and
>   return early in the function filter_display() (Joe Perches);
> * Added new patch 04/06 to make argument type as u32 for percent().
>
> Changes from v2:
> * Changed to use static functions to replace macros (Namhyung);
> * Added Jiri's Ack tags in the unchanged patches;
> * Minor improvement in the commit logs.
>
> [1] https://lore.kernel.org/patchwork/cover/1353064/
>
>
> Leo Yan (6):
>   perf c2c: Rename for shared cache line stats
>   perf c2c: Refactor hist entry validation
>   perf c2c: Refactor display filter
>   perf c2c: Fix argument type for percent()
>   perf c2c: Refactor node display
>   perf c2c: Add local variables for output metrics

Acked-by: Namhyung Kim 

Thanks,
Namhyung

Test report for kernel direct mapping performance

2021-01-14 Thread Xing Zhengjun

Hi,

There is currently a bit of a debate about the kernel direct map. Does
using 2M/1G pages aggressively for the kernel direct map help
performance? Or, is it an old optimization which is not as helpful on
modern CPUs as it was in the old days? What is the penalty of a kernel
feature that heavily demotes this mapping from larger to smaller pages?
We did a set of runs with 1G and 2M pages enabled /disabled and saw the
changes.

[Conclusions]

Assuming that this was a good representative set of workloads and that
the data are good, for server usage, we conclude that the existing
aggressive use of 1G mappings is a good choice since it represents the
best in a plurality of the workloads. However, in a *majority* of cases,
another mapping size (2M or 4k) potentially offers a performance
improvement. This leads us to conclude that although 1G mappings are a
good default choice, there is no compelling evidence that it must be the
only choice, or that folks deriving benefits (like hardening) from
smaller mapping sizes should avoid the smaller mapping sizes.

[Summary of results]

1. The test was done on server platforms with 11 benchmarks. For the 4
different server platforms tested, each with three different maximums
kernel mapping sizes: 4k, 2M, and 1G. Each system has enough memory to
effectively deploy 1G mappings. For the 11 different benchmarks were
used, not every benchmark was run on every system, there was a total of
259 tests.

2. For each benchmark/system combination, the 1G mapping had the highest
performance for 45% of the tests, 2M for ~30%, and 4k for~20%.

3. From the average delta, among 1G/2M/4K, 4K gets the lowest
performance in all the 4 test machines, while 1G gets the best
performance on 2 test machines and 2M gets the best performance on the
other 2 machines.

4. By testing with machine memory from 256G to 512G, we observed that
the larger memory will lead to the performance better for 1G page size.
With Large memory,
Will-it-scale/vm-scalability/unixbench/reaim/hackbench shows 1G has the
best performance, while kbuild/memtier/netperf shows 4K has the best
performance.

For more details please see the following web link:

https://01.org/sites/default/files/documentation/test_report_for_kernel_direct_mapping_performance_0.pdf

--
Zhengjun Xing

[PATCH v2] Adds a new ioctl32 syscall for backwards compatibility layers

2021-01-14 Thread sonicadvance1

From: Ryan Houdek 

Problem presented:
A backwards compatibility layer that allows running x86-64 and x86
processes inside of an AArch64 process.
  - CPU is emulated
  - Syscall interface is mostly passthrough
  - Some syscalls require patching or emulation depending on behaviour
  - Not viable from the emulator design to use an AArch32 host process

x86-64 and x86 userspace emulator source:
https://github.com/FEX-Emu/FEX
Usage of ioctl32 is currently in a downstream fork. This will be the
first user of the syscall.

Cross documentation:
https://github.com/FEX-Emu/FEX/wiki/32Bit-x86-Woes#ioctl---54

ioctls are opaque from the emulator perspective and the data wants to be
passed through a syscall as unimpeded as possible.
Sadly due to ioctl struct differences between x86 and x86-64, we need a
syscall that exposes the compatibility ioctl handler to userspace in a
64bit process.

This is necessary behaves of the behaviour differences that occur
between an x86 process doing an ioctl and an x86-64 process doing an
ioctl.

Both of which are captured and passed through the AArch64 ioctl space.
This is implementing a new ioctl32 syscall that allows us to pass 32bit
x86 ioctls through to the kernel with zero or minimal manipulation.

The only supported hosts where we care about this currently is AArch64
and x86-64 (For testing purposes).
PPC64LE, MIPS64LE, and RISC-V64 might be interesting to support in the
future; But I don't have any platforms that get anywhere near Cortex-A77
performance in those architectures. Nor do I have the time to bring up
the emulator on them.
x86-64 can get to the compatibility ioctl through the int $0x80 handler.

This does not solve the following problems:
1) compat_alloc_user_space inside ioctl
2) ioctls that check task mode instead of entry point for behaviour
3) ioctls allocating memory
4) struct packing problems between architectures

Workarounds for the problems presented:
1a) Do a stack pivot to the lower 32bits from userspace
  - Forces host 64bit process to have its thread stacks to live in 32bit
  space. Not ideal.
  - Only do a stack pivot on ioctl to save previous 32bit VA space
1b) Teach kernel that compat_alloc_userspace can return a 64bit pointer
  - x86-64 truncates stack from this function
  - AArch64 returns the full stack pointer
  - Only ~29 users. Validating all of them support a 64bit stack is
  trivial?

2a) Any application using these can be checked for compatibility in
userspace and put on a block list.
2b) Fix any ioctls doing broken behaviour based on task mode rather than
ioctl entry point

3a) Userspace consumes all VA space above 32bit. Forcing allocations to
occur in lower 32bits
  - This is the current implementation
3b) Ensure any allocation in the ioctl handles ioctl entrypoint rather
than just allow generic memory allocations in full VA space
  - This is hard to guarantee

4a) Blocklist any application using ioctls that have different struct
packing across the boundary
  - Can happen when struct packing of 32bit x86 application goes down
  the aarch64 compat_ioctl path
  - Userspace is a AArch64 process passing 32bit x86 ioctl structures
  through the compat_ioctl path which is typically for AArch32 processes
  - None currently identified
4b) Work with upstream kernel and userspace projects to evaluate and fix
  - Identify the problem ioctls
  - Implement a new ioctl with more sane struct packing that matches
  cross-arch
  - Implement new ioctl while maintaining backwards compatibility with
  previous ioctl handler
  - Change upstream project to use the new compatibility ioctl
  - ioctl deprecation will be case by case per device and project
4b) Userspace implements a full ioctl emulation layer
  - Parses the full ioctl tree
  - Either passes through ioctls that it doesn't understand or
  transforms ioctls that it knows are trouble
  - Has the downside that it can still run in to edge cases that will
  fail
  - Performance of additional tracking is a concern
  - Prone to failure keeping the kernel ioctl and userspace ioctl
  handling in sync
  - Really want to have it in the kernel space as much as possible

Changes in v2:
- Added the syscall to all architecture tables
- Disabled on 32bit and BE platforms. They can call ioctl directly.
- Disabled on x86-64 as well since you can call this from ia32 or x32
dispatch tables

Signed-off-by: Ryan Houdek 
---
 arch/alpha/kernel/syscalls/syscall.tbl  |  1 +
 arch/arm/tools/syscall.tbl  |  1 +
 arch/arm64/include/asm/unistd.h |  2 +-
 arch/arm64/include/asm/unistd32.h   |  2 ++
 arch/ia64/kernel/syscalls/syscall.tbl   |  1 +
 arch/m68k/kernel/syscalls/syscall.tbl   |  1 +
 arch/microblaze/kernel/syscalls/syscall.tbl |  1 +
 arch/mips/kernel/syscalls/syscall_n32.tbl   |  1 +
 arch/mips/kernel/syscalls/syscall_n64.tbl   |  2 ++
 arch/mips/kernel/syscalls/syscall_o32.tbl   |  1 +
 arch/parisc/kernel/syscalls/syscall.tbl |  1 +
 arch/powerpc/kernel/syscalls/sysca

[PATCH v3 2/2] perf stat: Take cgroups into account for shadow stats

As of now it doesn't consider cgroups when collecting shadow stats and
metrics so counter values from different cgroups will be saved in a
same slot.  This resulted in an incorrect numbers when those cgroups
have different workloads.

For example, let's look at the below - the cgroup A and C runs same
workload which burns a cpu while cgroup B runs a light workload.

  $ perf stat -a -e cycles,instructions --for-each-cgroup A,B,C  sleep 1

   Performance counter stats for 'system wide':

 3,958,116,522  cyclesA
 6,722,650,929  instructions  A #2.53  insn per cycle
 1,132,741  cyclesB
   571,743  instructions  B #0.00  insn per cycle
 4,007,799,935  cyclesC
 6,793,181,523  instructions  C #2.56  insn per cycle

   1.001050869 seconds time elapsed

When I run perf stat with single workload, it usually shows IPC around 1.7.
We can verify it (6,722,650,929.0 / 3,958,116,522 = 1.698) for cgroup A.

But in this case, since cgroups are ignored, cycles are averaged so it
used the lower value for IPC calculation and resulted in around 2.5.

  avg cycle: (3958116522 + 1132741 + 4007799935) / 3 = 2655683066
  IPC (A)  :  6722650929 / 2655683066 = 2.531
  IPC (B)  :  571743 / 2655683066 = 0.0002
  IPC (C)  :  6793181523 / 2655683066 = 2.557

We can simply compare cgroup pointers in the evsel and it'll be NULL
when cgroups are not specified.  With this patch, I can see correct
numbers like below:

  $ perf stat -a -e cycles,instructions --for-each-cgroup A,B,C  sleep 1

  Performance counter stats for 'system wide':

 4,171,051,687  cyclesA
 7,219,793,922  instructions  A #1.73  insn per cycle
 1,051,189  cyclesB
   583,102  instructions  B #0.55  insn per cycle
 4,171,124,710  cyclesC
 7,192,944,580  instructions  C #1.72  insn per cycle

   1.007909814 seconds time elapsed

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/stat-shadow.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index a1565b6e38f2..12eafd12a693 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -8,6 +8,7 @@
 #include "evlist.h"
 #include "expr.h"
 #include "metricgroup.h"
+#include "cgroup.h"
 #include 
 
 /*
@@ -28,6 +29,7 @@ struct saved_value {
enum stat_type type;
int ctx;
int cpu;
+   struct cgroup *cgrp;
struct runtime_stat *stat;
struct stats stats;
u64 metric_total;
@@ -57,6 +59,9 @@ static int saved_value_cmp(struct rb_node *rb_node, const 
void *entry)
if (a->ctx != b->ctx)
return a->ctx - b->ctx;
 
+   if (a->cgrp != b->cgrp)
+   return (char *)a->cgrp < (char *)b->cgrp ? -1 : +1;
+
if (a->evsel == NULL && b->evsel == NULL) {
if (a->stat == b->stat)
return 0;
@@ -100,7 +105,8 @@ static struct saved_value *saved_value_lookup(struct evsel 
*evsel,
  bool create,
  enum stat_type type,
  int ctx,
- struct runtime_stat *st)
+ struct runtime_stat *st,
+ struct cgroup *cgrp)
 {
struct rblist *rblist;
struct rb_node *nd;
@@ -110,6 +116,7 @@ static struct saved_value *saved_value_lookup(struct evsel 
*evsel,
.type = type,
.ctx = ctx,
.stat = st,
+   .cgrp = cgrp,
};
 
rblist = &st->value_list;
@@ -197,6 +204,7 @@ void perf_stat__reset_shadow_per_stat(struct runtime_stat 
*st)
 
 struct runtime_stat_data {
int ctx;
+   struct cgroup *cgrp;
 };
 
 static void update_runtime_stat(struct runtime_stat *st,
@@ -205,7 +213,7 @@ static void update_runtime_stat(struct runtime_stat *st,
struct runtime_stat_data *rsd)
 {
struct saved_value *v = saved_value_lookup(NULL, cpu, true, type,
-  rsd->ctx, st);
+  rsd->ctx, st, rsd->cgrp);
 
if (v)
update_stats(&v->stats, count);
@@ -223,6 +231,7 @@ void perf_stat__update_shadow_stats(struct evsel *counter, 
u64 count,
struct saved_value *v;
struct runtime_stat_data rsd = {
.ctx = evsel_context(counter),
+   .cgrp = counter->cgrp,
};
 
count *= counter->scale;
@@ -290,13 +299,14 @@ void perf_stat__update_shadow_stats(struct evsel 
*counter, u64 count,
update

[PATCH v3 1/2] perf stat: Introduce struct runtime_stat_data

To pass more info to the saved_value in the runtime_stat, add a new
struct runtime_stat_data.  Currently it only has 'ctx' field but later
patch will add more.

Note that we intentionally pass 0 as ctx to clock-related events for
compatibility.  It was already there in a few places.  So move the
code into the saved_value_lookup() explicitly and add a comment.

Suggested-by: Andi Kleen 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/stat-shadow.c | 346 +-
 1 file changed, 173 insertions(+), 173 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 901265127e36..a1565b6e38f2 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -114,6 +114,10 @@ static struct saved_value *saved_value_lookup(struct evsel 
*evsel,
 
rblist = &st->value_list;
 
+   /* don't use context info for clock events */
+   if (type == STAT_NSECS)
+   dm.ctx = 0;
+
nd = rblist__find(rblist, &dm);
if (nd)
return container_of(nd, struct saved_value, rb_node);
@@ -191,12 +195,17 @@ void perf_stat__reset_shadow_per_stat(struct runtime_stat 
*st)
reset_stat(st);
 }
 
+struct runtime_stat_data {
+   int ctx;
+};
+
 static void update_runtime_stat(struct runtime_stat *st,
enum stat_type type,
-   int ctx, int cpu, u64 count)
+   int cpu, u64 count,
+   struct runtime_stat_data *rsd)
 {
-   struct saved_value *v = saved_value_lookup(NULL, cpu, true,
-  type, ctx, st);
+   struct saved_value *v = saved_value_lookup(NULL, cpu, true, type,
+  rsd->ctx, st);
 
if (v)
update_stats(&v->stats, count);
@@ -210,73 +219,75 @@ static void update_runtime_stat(struct runtime_stat *st,
 void perf_stat__update_shadow_stats(struct evsel *counter, u64 count,
int cpu, struct runtime_stat *st)
 {
-   int ctx = evsel_context(counter);
u64 count_ns = count;
struct saved_value *v;
+   struct runtime_stat_data rsd = {
+   .ctx = evsel_context(counter),
+   };
 
count *= counter->scale;
 
if (evsel__is_clock(counter))
-   update_runtime_stat(st, STAT_NSECS, 0, cpu, count_ns);
+   update_runtime_stat(st, STAT_NSECS, cpu, count_ns, &rsd);
else if (evsel__match(counter, HARDWARE, HW_CPU_CYCLES))
-   update_runtime_stat(st, STAT_CYCLES, ctx, cpu, count);
+   update_runtime_stat(st, STAT_CYCLES, cpu, count, &rsd);
else if (perf_stat_evsel__is(counter, CYCLES_IN_TX))
-   update_runtime_stat(st, STAT_CYCLES_IN_TX, ctx, cpu, count);
+   update_runtime_stat(st, STAT_CYCLES_IN_TX, cpu, count, &rsd);
else if (perf_stat_evsel__is(counter, TRANSACTION_START))
-   update_runtime_stat(st, STAT_TRANSACTION, ctx, cpu, count);
+   update_runtime_stat(st, STAT_TRANSACTION, cpu, count, &rsd);
else if (perf_stat_evsel__is(counter, ELISION_START))
-   update_runtime_stat(st, STAT_ELISION, ctx, cpu, count);
+   update_runtime_stat(st, STAT_ELISION, cpu, count, &rsd);
else if (perf_stat_evsel__is(counter, TOPDOWN_TOTAL_SLOTS))
update_runtime_stat(st, STAT_TOPDOWN_TOTAL_SLOTS,
-   ctx, cpu, count);
+   cpu, count, &rsd);
else if (perf_stat_evsel__is(counter, TOPDOWN_SLOTS_ISSUED))
update_runtime_stat(st, STAT_TOPDOWN_SLOTS_ISSUED,
-   ctx, cpu, count);
+   cpu, count, &rsd);
else if (perf_stat_evsel__is(counter, TOPDOWN_SLOTS_RETIRED))
update_runtime_stat(st, STAT_TOPDOWN_SLOTS_RETIRED,
-   ctx, cpu, count);
+   cpu, count, &rsd);
else if (perf_stat_evsel__is(counter, TOPDOWN_FETCH_BUBBLES))
update_runtime_stat(st, STAT_TOPDOWN_FETCH_BUBBLES,
-   ctx, cpu, count);
+   cpu, count, &rsd);
else if (perf_stat_evsel__is(counter, TOPDOWN_RECOVERY_BUBBLES))
update_runtime_stat(st, STAT_TOPDOWN_RECOVERY_BUBBLES,
-   ctx, cpu, count);
+   cpu, count, &rsd);
else if (perf_stat_evsel__is(counter, TOPDOWN_RETIRING))
update_runtime_stat(st, STAT_TOPDOWN_RETIRING,
-   ctx, cpu, count);
+   cpu, count, &rsd);
else if (perf_stat_evsel__is(counter, TOPDOWN_BAD_SPEC))
update_runtime_stat(st, STAT_TOPDOWN_BAD_SPEC,
-

Re: [v2] Old platforms: bring out your dead

2021-01-14 Thread Wei Xu

Hi Arnd,

On 2021/1/14 0:14, Arnd Bergmann wrote:
> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann  wrote:
> 
> Just to catch up on the replies I received on my initial email, here
> is the updated status of all the Arm platforms I listed earlier, thanks
> for everyone that contributed information on these platforms!
> 
> These platforms were listed as likely unused and are now going to
> be kept around, as we wait for work on them to resume:
> 
> * axxia -- added in 2014, no notable changes after 2015
>   (Alexander Sverdlin has patches and volunteered as a maintainer)
> * bcm/kona -- added in 2013, no notable changes after 2014
>   (Found activity in PostmarketOS, waiting for usptreaming)
> * digicolor -- added in 2014, no notable changes after 2015
>   (Baruch still uses it, no changes needed)
> * dove -- added in 2009, obsoleted by mach-mvebu in 2015
>   (Russell still has patches for cubox, we might remove the other
>boards that are converted to DT though)
> * nspire -- added in 2013, no notable changes after 2015
>   (Fabian and Daniel confirmed this is alive and well, more
>hardware support is planned)
> * spear -- added in 2010, no notable changes since 2015
>   (My mistake in reading the changelog, should have been
>   on the second list. The platform is still active, and Mattias
>   Wallin plans to send more hardware support and cleanup
>   patches)
> 
> These platforms are confirmed to be dead upstream, and are going to
> be removed:
> 
> * efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
> * picoxcell -- added in 2011, already queued for removal
> * prima2 -- added in 20111, no notable changes since 2015
> * tango -- added in 2015, sporadic changes until 2017, but abandoned
> * u300 -- added in 2009, no notable changes since 2013
> * zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes
> 
> No reply yet, still planning for  removal. Oleksij and Tony, please
> confirm this is ok or let us know if we should keep them:
> 
> * asm9260 -- added in 2014, no notable changes after 2015
> * vt8500 -- added in 2010, no notable changes since 2014
> 
> These were on the original list of platforms that are likely still
> maintained and used despite their age, and I received a
> confirmation that this is true (some of them off-list)
> 
> * clps711x -- prehistoric, converted to multiplatform+DT in 2016
> * ep93xx -- added in 2006, LinusW still working on it, any users left?
> * footbridge -- added in prehistory, stable since ~2013, rmk and LinusW have 
> one
> * gemini -- added in 2009, LinusW still working on it
> * highbank -- added in 2011, no changes after 2015, but Andre still uses it
> * iop32x -- added in 2006, no notable changes other than my cleanup, still 
> used
> * ixp4xx -- prehistoric, but LinusW and I are still working on it
> * lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
> * nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
> * orion5x -- DT support still active, board files support to get reviewed
>  for removal and conversion to DT individually
> * oxnas -- added in 2016, but already old then, few changes later
> * pxa -- prehistoric, but a few boards may still have users
> * rpc -- prehistoric, but I think Russell still uses his machine
> * sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
> 
> For these I received no reply yet. Again, these will stay for the moment
> unless I get a reply, but if anyone has more information, please reply
> here to document the status (adding a few more people to Cc):
> 
> * mmp -- added in 2009, DT support is active, but board files might go
> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
> * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016

I think it is OK to drop the support of the hip01(arm32) and hip05(arm64).
Could you also help to drop the support of the hip04(arm32) which I think 
nobody use as well?
Thanks!

Best Regards,
Wei

[PATCH] scsi: target: iscsi: Fix typo in comment

2021-01-14 Thread Valdis Klētnieks

Correct the spelling of Nagle's name in a comment.

Signed-off-by: Valdis Kletnieks 

diff --git a/drivers/target/iscsi/iscsi_target_login.c 
b/drivers/target/iscsi/iscsi_target_login.c
index 893d1b406c29..1a9c50401bdb 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -896,7 +896,7 @@ int iscsit_setup_np(
else
len = sizeof(struct sockaddr_in);
/*
-* Set SO_REUSEADDR, and disable Nagel Algorithm with TCP_NODELAY.
+* Set SO_REUSEADDR, and disable Nagle Algorithm with TCP_NODELAY.
 */
if (np->np_network_transport == ISCSI_TCP)
tcp_sock_set_nodelay(sock->sk);

[PATCH v3 2/2] drm/bridge: anx7625: disable regulators when power off

2021-01-14 Thread Hsin-Yi Wang

When suspending the driver, anx7625_power_standby() will be called to
turn off reset-gpios and enable-gpios. However, power supplies are not
disabled. To save power, the driver can get the power supply regulators
and turn off them in anx7625_power_standby().

Signed-off-by: Hsin-Yi Wang 
---
Change:
v3: add delays between regulators power on
---
 drivers/gpu/drm/bridge/analogix/anx7625.c | 34 +++
 drivers/gpu/drm/bridge/analogix/anx7625.h |  1 +
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 65cc05982f82..23283ba0c4f9 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -875,12 +876,25 @@ static int sp_tx_edid_read(struct anx7625_data *ctx,
 static void anx7625_power_on(struct anx7625_data *ctx)
 {
struct device *dev = &ctx->client->dev;
+   int ret, i;
 
if (!ctx->pdata.low_power_mode) {
DRM_DEV_DEBUG_DRIVER(dev, "not low power mode!\n");
return;
}
 
+   for (i = 0; i < ARRAY_SIZE(ctx->pdata.supplies); i++) {
+   ret = regulator_enable(ctx->pdata.supplies[i].consumer);
+   if (ret < 0) {
+   DRM_DEV_DEBUG_DRIVER(dev, "cannot enable supply %d: 
%d\n",
+i, ret);
+   goto reg_err;
+   }
+   usleep_range(2000, 2100);
+   }
+
+   usleep_range(4000, 4100);
+
/* Power on pin enable */
gpiod_set_value(ctx->pdata.gpio_p_on, 1);
usleep_range(1, 11000);
@@ -889,11 +903,16 @@ static void anx7625_power_on(struct anx7625_data *ctx)
usleep_range(1, 11000);
 
DRM_DEV_DEBUG_DRIVER(dev, "power on !\n");
+   return;
+reg_err:
+   for (--i; i >= 0; i--)
+   regulator_disable(ctx->pdata.supplies[i].consumer);
 }
 
 static void anx7625_power_standby(struct anx7625_data *ctx)
 {
struct device *dev = &ctx->client->dev;
+   int ret;
 
if (!ctx->pdata.low_power_mode) {
DRM_DEV_DEBUG_DRIVER(dev, "not low power mode!\n");
@@ -904,6 +923,12 @@ static void anx7625_power_standby(struct anx7625_data *ctx)
usleep_range(1000, 1100);
gpiod_set_value(ctx->pdata.gpio_p_on, 0);
usleep_range(1000, 1100);
+
+   ret = regulator_bulk_disable(ARRAY_SIZE(ctx->pdata.supplies),
+ctx->pdata.supplies);
+   if (ret < 0)
+   DRM_DEV_DEBUG_DRIVER(dev, "cannot disable supplies %d\n", ret);
+
DRM_DEV_DEBUG_DRIVER(dev, "power down\n");
 }
 
@@ -1742,6 +1767,15 @@ static int anx7625_i2c_probe(struct i2c_client *client,
platform->client = client;
i2c_set_clientdata(client, platform);
 
+   pdata->supplies[0].supply = "vdd10";
+   pdata->supplies[1].supply = "vdd18";
+   pdata->supplies[2].supply = "vdd33";
+   ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "fail to get power supplies: %d\n", ret);
+   return ret;
+   }
anx7625_init_gpio(platform);
 
atomic_set(&platform->power_status, 0);
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h 
b/drivers/gpu/drm/bridge/analogix/anx7625.h
index 193ad86c5450..e4a086b3a3d7 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.h
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
@@ -350,6 +350,7 @@ struct s_edid_data {
 struct anx7625_platform_data {
struct gpio_desc *gpio_p_on;
struct gpio_desc *gpio_reset;
+   struct regulator_bulk_data supplies[3];
struct drm_bridge *panel_bridge;
int intp_irq;
u32 low_power_mode;
-- 
2.30.0.284.gd98b1dd5eaa7-goog

Re: [PATCH v2] module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for undefined symbols

2021-01-14 Thread Marco Elver

On Thu, 14 Jan 2021 at 22:54, Fangrui Song  wrote:
> clang-12 -fno-pic (since
> https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de008232da3f1d6)
> can emit `call __stack_chk_fail@PLT` instead of `call __stack_chk_fail`
> on x86.  The two forms should have identical behaviors on x86-64 but the
> former causes GNU as<2.37 to produce an unreferenced undefined symbol
> _GLOBAL_OFFSET_TABLE_.
>
> (On x86-32, there is an R_386_PC32 vs R_386_PLT32 difference but the
> linker behavior is identical as far as Linux kernel is concerned.)
>
> Simply ignore _GLOBAL_OFFSET_TABLE_ for now, like what
> scripts/mod/modpost.c:ignore_undef_symbol does. This also fixes the
> problem for gcc/clang -fpie and -fpic, which may emit `call foo@PLT` for
> external function calls on x86.
>
> Note: ld -z defs and dynamic loaders do not error for unreferenced
> undefined symbols so the module loader is reading too much.  If we ever
> need to ignore more symbols, the code should be refactored to ignore
> unreferenced symbols.
>
> Reported-by: Marco Elver 
> Link: https://github.com/ClangBuiltLinux/linux/issues/1250
> Signed-off-by: Fangrui Song 

Tested-by: Marco Elver 

Thank you for the patch!

> ---
>  kernel/module.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> ---
> Changes in v2:
> * Fix Marco's email address
> * Add a function ignore_undef_symbol similar to 
> scripts/mod/modpost.c:ignore_undef_symbol
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 4bf30e4b3eaa..278f5129bde2 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2348,6 +2348,20 @@ static int verify_exported_symbols(struct module *mod)
> return 0;
>  }
>
> +static int ignore_undef_symbol(Elf_Half emachine, const char *name)

Why not 'bool' return-type?

> +{
> +   /* On x86, PIC code and Clang non-PIC code may have call foo@PLT. GNU 
> as

Not sure if checkpatch.pl warns about this, but this multi-line
comment does not follow the normal kernel-style (see elsewhere in
file):

/*
 * ...
 */

> +* before 2.37 produces an unreferenced _GLOBAL_OFFSET_TABLE_ on 
> x86-64.
> +* i386 has a similar problem but may not deserve a fix.
> +*
> +* If we ever have to ignore many symbols, consider refactoring the 
> code to
> +* only warn if referenced by a relocation.
> +*/
> +   if (emachine == EM_386 || emachine == EM_X86_64)
> +   return !strcmp(name, "_GLOBAL_OFFSET_TABLE_");
> +   return 0;
> +}
> +
>  /* Change all symbols so that st_value encodes the pointer directly. */
>  static int simplify_symbols(struct module *mod, const struct load_info *info)
>  {
> @@ -2395,8 +2409,10 @@ static int simplify_symbols(struct module *mod, const 
> struct load_info *info)
> break;
> }
>
> -   /* Ok if weak.  */
> -   if (!ksym && ELF_ST_BIND(sym[i].st_info) == STB_WEAK)
> +   /* Ok if weak or ignored.  */
> +   if (!ksym &&
> +   (ELF_ST_BIND(sym[i].st_info) == STB_WEAK ||
> +ignore_undef_symbol(info->hdr->e_machine, name)))
> break;
>
> ret = PTR_ERR(ksym) ?: -ENOENT;
> --
> 2.30.0.296.g2bfb1c46d8-goog
>

[PATCH] Adds a new ioctl32 syscall for backwards compatibility layers

2021-01-14 Thread sonicadvance1

From: Ryan Houdek 

Problem presented:
A backwards compatibility layer that allows running x86-64 and x86
processes inside of an AArch64 process.
  - CPU is emulated
  - Syscall interface is mostly passthrough
  - Some syscalls require patching or emulation depending on behaviour
  - Not viable from the emulator design to use an AArch32 host process

x86-64 and x86 userspace emulator source:
https://github.com/FEX-Emu/FEX
Usage of ioctl32 is currently in a downstream fork. This will be the
first user of the syscall.

Cross documentation:
https://github.com/FEX-Emu/FEX/wiki/32Bit-x86-Woes#ioctl---54

ioctls are opaque from the emulator perspective and the data wants to be
passed through a syscall as unimpeded as possible.
Sadly due to ioctl struct differences between x86 and x86-64, we need a
syscall that exposes the compatibility ioctl handler to userspace in a
64bit process.

This is necessary behaves of the behaviour differences that occur
between an x86 process doing an ioctl and an x86-64 process doing an
ioctl.

Both of which are captured and passed through the AArch64 ioctl space.
This is implementing a new ioctl32 syscall that allows us to pass 32bit
x86 ioctls through to the kernel with zero or minimal manipulation.

The only supported hosts where we care about this currently is AArch64
and x86-64 (For testing purposes).
PPC64LE, MIPS64LE, and RISC-V64 might be interesting to support in the
future; But I don't have any platforms that get anywhere near Cortex-A77
performance in those architectures. Nor do I have the time to bring up
the emulator on them.
x86-64 can get to the compatibility ioctl through the int $0x80 handler.

This does not solve the following problems:
1) compat_alloc_user_space inside ioctl
2) ioctls that check task mode instead of entry point for behaviour
3) ioctls allocating memory
4) struct packing problems between architectures

Workarounds for the problems presented:
1a) Do a stack pivot to the lower 32bits from userspace
  - Forces host 64bit process to have its thread stacks to live in 32bit
  space. Not ideal.
  - Only do a stack pivot on ioctl to save previous 32bit VA space
1b) Teach kernel that compat_alloc_userspace can return a 64bit pointer
  - x86-64 truncates stack from this function
  - AArch64 returns the full stack pointer
  - Only ~29 users. Validating all of them support a 64bit stack is
  trivial?

2a) Any application using these can be checked for compatibility in
userspace and put on a block list.
2b) Fix any ioctls doing broken behaviour based on task mode rather than
ioctl entry point

3a) Userspace consumes all VA space above 32bit. Forcing allocations to
occur in lower 32bits
  - This is the current implementation
3b) Ensure any allocation in the ioctl handles ioctl entrypoint rather
than just allow generic memory allocations in full VA space
  - This is hard to guarantee

4a) Blocklist any application using ioctls that have different struct
packing across the boundary
  - Can happen when struct packing of 32bit x86 application goes down
  the aarch64 compat_ioctl path
  - Userspace is a AArch64 process passing 32bit x86 ioctl structures
  through the compat_ioctl path which is typically for AArch32 processes
  - None currently identified
4b) Work with upstream kernel and userspace projects to evaluate and fix
  - Identify the problem ioctls
  - Implement a new ioctl with more sane struct packing that matches
  cross-arch
  - Implement new ioctl while maintaining backwards compatibility with
  previous ioctl handler
  - Change upstream project to use the new compatibility ioctl
  - ioctl deprecation will be case by case per device and project
4b) Userspace implements a full ioctl emulation layer
  - Parses the full ioctl tree
  - Either passes through ioctls that it doesn't understand or
  transforms ioctls that it knows are trouble
  - Has the downside that it can still run in to edge cases that will
  fail
  - Performance of additional tracking is a concern
  - Prone to failure keeping the kernel ioctl and userspace ioctl
  handling in sync
  - Really want to have it in the kernel space as much as possible

Signed-off-by: Ryan Houdek 
---
 arch/alpha/kernel/syscalls/syscall.tbl  |  1 +
 arch/arm/tools/syscall.tbl  |  1 +
 arch/arm64/include/asm/unistd.h |  2 +-
 arch/arm64/include/asm/unistd32.h   |  2 ++
 arch/ia64/kernel/syscalls/syscall.tbl   |  1 +
 arch/m68k/kernel/syscalls/syscall.tbl   |  1 +
 arch/microblaze/kernel/syscalls/syscall.tbl |  1 +
 arch/mips/kernel/syscalls/syscall_n32.tbl   |  1 +
 arch/mips/kernel/syscalls/syscall_n64.tbl   |  2 ++
 arch/mips/kernel/syscalls/syscall_o32.tbl   |  1 +
 arch/parisc/kernel/syscalls/syscall.tbl |  1 +
 arch/powerpc/kernel/syscalls/syscall.tbl|  1 +
 arch/s390/kernel/syscalls/syscall.tbl   |  1 +
 arch/sh/kernel/syscalls/syscall.tbl |  1 +
 arch/sparc/kernel/syscalls/syscall.tbl  |  1 +
 arch/x86/entry/syscalls/syscall_32.tbl

[PATCH v3 1/2] dt-bindings: drm/bridge: anx7625: Add power supplies

2021-01-14 Thread Hsin-Yi Wang

anx7625 requires 3 power supply regulators.

Signed-off-by: Hsin-Yi Wang 
Reviewed-by: Rob Herring 
---
 .../bindings/display/bridge/analogix,anx7625.yaml | 15 +++
 1 file changed, 15 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 60585a4fc22b..3ae97d9523e5 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -34,6 +34,15 @@ properties:
 description: used for reset chip control, RESET_N pin B7.
 maxItems: 1
 
+  vdd10-supply:
+description: Regulator that provides the supply 1.0V power.
+
+  vdd18-supply:
+description: Regulator that provides the supply 1.8V power.
+
+  vdd33-supply:
+description: Regulator that provides the supply 3.3V power.
+
   ports:
 type: object
 
@@ -55,6 +64,9 @@ properties:
 required:
   - compatible
   - reg
+  - vdd10-supply
+  - vdd18-supply
+  - vdd33-supply
   - ports
 
 additionalProperties: false
@@ -72,6 +84,9 @@ examples:
 reg = <0x58>;
 enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
 reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
+vdd10-supply = <&pp1000_mipibrdg>;
+vdd18-supply = <&pp1800_mipibrdg>;
+vdd33-supply = <&pp3300_mipibrdg>;
 
 ports {
 #address-cells = <1>;
-- 
2.30.0.284.gd98b1dd5eaa7-goog

Re: [PATCH v2 1/2] perf stat: Introduce struct runtime_stat_data

On Thu, Jan 14, 2021 at 10:22 PM Jiri Olsa  wrote:
>
> On Thu, Jan 14, 2021 at 12:25:39PM +0900, Namhyung Kim wrote:
> > Hi Jiri,
> >
> > On Wed, Jan 13, 2021 at 8:19 PM Jiri Olsa  wrote:
> > >
> > > On Tue, Jan 12, 2021 at 03:14:30PM +0900, Namhyung Kim wrote:
> > > > To pass more info to the saved_value in the runtime_stat, add a new
> > > > struct runtime_stat_data.  Currently it only has 'ctx' field but later
> > > > patch will add more.
> > > >
> > > > Suggested-by: Andi Kleen 
> > > > Signed-off-by: Namhyung Kim 
> > > > ---
> > > >  tools/perf/util/stat-shadow.c | 346 +-
> > > >  1 file changed, 173 insertions(+), 173 deletions(-)
> > > >
> > > > diff --git a/tools/perf/util/stat-shadow.c 
> > > > b/tools/perf/util/stat-shadow.c
> > > > index 901265127e36..a1565b6e38f2 100644
> > > > --- a/tools/perf/util/stat-shadow.c
> > > > +++ b/tools/perf/util/stat-shadow.c
> > > > @@ -114,6 +114,10 @@ static struct saved_value 
> > > > *saved_value_lookup(struct evsel *evsel,
> > > >
> > > >   rblist = &st->value_list;
> > > >
> > > > + /* don't use context info for clock events */
> > > > + if (type == STAT_NSECS)
> > > > + dm.ctx = 0;
> > > > +
> > >
> > > I think this should go to separate patch and be explained,
> > > the change is advertised as adding struct for arguments
> >
> > Actually it was already there and I found it during this work.
> > Basically it passes ctx for lookup but it uses 0 for time.
> > Please see below..
>
> ah nice, did not see that.. could be mentioned in the changelog ;-)

OK, will send v3.

Thanks,
Namhyung

Re: [PATCH 1/2] KVM: x86: Add emulation support for #GP triggered by VM instructions

2021-01-14 Thread Wei Huang




On 1/12/21 8:01 AM, Paolo Bonzini wrote:
> On 12/01/21 07:37, Wei Huang wrote:
>>   static int gp_interception(struct vcpu_svm *svm)
>>   {
>>   struct kvm_vcpu *vcpu = &svm->vcpu;
>>   u32 error_code = svm->vmcb->control.exit_info_1;
>> -
>> -    WARN_ON_ONCE(!enable_vmware_backdoor);
>> +    int rc;
>>     /*
>> - * VMware backdoor emulation on #GP interception only handles IN{S},
>> - * OUT{S}, and RDPMC, none of which generate a non-zero error code.
>> + * Only VMware backdoor and SVM VME errata are handled. Neither of
>> + * them has non-zero error codes.
>>    */
>>   if (error_code) {
>>   kvm_queue_exception_e(vcpu, GP_VECTOR, error_code);
>>   return 1;
>>   }
>> -    return kvm_emulate_instruction(vcpu, EMULTYPE_VMWARE_GP);
>> +
>> +    rc = kvm_emulate_instruction(vcpu, EMULTYPE_PARAVIRT_GP);
>> +    if (rc > 1)
>> +    rc = svm_emulate_vm_instr(vcpu, rc);
>> +    return rc;
>>   }
>>   
> 
> Passing back the third byte is quick hacky.  Instead of this change to
> kvm_emulate_instruction, I'd rather check the instruction bytes in
> gp_interception before calling kvm_emulate_instruction.  That would be
> something like:
> 
> - move "kvm_clear_exception_queue(vcpu);" inside the "if
> (!(emulation_type & EMULTYPE_NO_DECODE))".  It doesn't apply when you
> are coming back from userspace.
> 
> - extract the "if (!(emulation_type & EMULTYPE_NO_DECODE))" body to a
> new function x86_emulate_decoded_instruction.  Call it from
> gp_interception, we know this is not a pagefault and therefore
> vcpu->arch.write_fault_to_shadow_pgtable must be false.

If the whole body inside if-statement is moved out, do you expect the
interface of x86_emulate_decoded_instruction to be something like:

int x86_emulate_decoded_instruction(struct kvm_vcpu *vcpu,
gpa_t cr2_or_gpa,
int emulation_type, void *insn,
int insn_len,
bool write_fault_to_spt)

And if so, what is the emulation type to use when calling this function
from svm.c? EMULTYPE_VMWARE_GP?

> 
> - check ctxt->insn_bytes for an SVM instruction
> 
> - if not an SVM instruction, call kvm_emulate_instruction(vcpu,
> EMULTYPE_VMWARE_GP|EMULTYPE_NO_DECODE).
> 
> Thanks,
> 
> Paolo
>

Related work to MAINTAINERS truth and fiction

2021-01-14 Thread Lukas Bulwahn

Hi Jonathan,

thanks for your interesting article, MAINTAINERS truth and fiction,
https://lwn.net/Articles/842415/.

Just some pointers to related work:

Pia Eichinger has done some related analysis and work in this area as
part of her bachelor's thesis on Maintainers Expectations vs.
Maintainers Reality: An Analysis of Organisational and Maintenance
Structure of the Linux Kernel. Simply quoting her conclusion:

"We showed that around 20% of all patches were theoretically wrongly
integrated when strictly analysing MAINTAINERS. The reality of
integration and maintenance structure is more complicated than that,
which we also explored. Furthermore, we identified 12 major subsystems
of the Linux kernel. This is very helpful for an overview of the
organisational structure, realistic grouping of subsystems and further
Linux kernel topology discussions."

Announcement and thesis here:
https://lists.elisa.tech/g/devel/message/1269
https://drive.google.com/file/d/12ta2YxgEzEfrIcmWid8kwIyVEywbUjbA/view?usp=sharing

As you might have noticed as well, ./scripts/get_maintainer.pl
--self-test provides a few checks and warnings on the MAINTAINERS
file. For a few months by now, I have been following up on new
warnings appearing with ./scripts/get_maintainer.pl
--self-test=patterns, excluding Documentation/devicetree/bindings/, as
Mauro takes care of those often before my patches usually get
accepted.

In the past, I also did an analysis of what is only in THE REST, see
some discussion here:

https://lore.kernel.org/lkml/alpine.DEB.2.21.2003090702440.3325@felia/

After a few manual clean-up attempts for files in include, I concluded
that this activity needs to be at least semi-automatically done with
some scripted heuristics and then sanity-checked by experts. I have
not made any progress beyond that, though; it is certainly a good task
for an interested student or mentee.

Thanks again for your interesting article.


Best regards,

Lukas

Re: cBPF socket filters failing - inexplicably?

2021-01-14 Thread Alexei Starovoitov

Adding appropriate mailing list to cc...

My wild guess is that as soon as socket got created:
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
the packets were already queued to it.
So later setsockopt() is too late to filter.

Eric, thoughts?

On Wed, Jan 6, 2021 at 6:55 AM Tom Cook  wrote:
>
> Another factoid to add to this:  I captured all traffic on an
> interface while the test program was running using
>
> tcpdump -i wlo1 -w capture.pcap
>
> observing that multiple packets got through the filter.  I then built
> the bpf_dbg program from the kernel source tree and ran the same
> filter and capture file through it:
>
> $ tools/bpf_dbg
> > load bpf 1,6 0 0 0
> > load pcap capture.pcap
> > run
> bpf passes:0 fails:269288
>
> So bpf_dbg thinks the filter is correct; it's only when the filter is
> attached to an actual socket that it fails occasionally.
>
> Regards,
> Tom
>
> On Wed, Jan 6, 2021 at 10:07 AM Tom Cook  wrote:
> >
> > Just to note I have also reproduced this on a 5.10.0 kernel.
> >
> > On Tue, Jan 5, 2021 at 1:42 PM Tom Cook  wrote:
> > >
> > > In the course of tracking down a defect in some existing software,
> > > I've found the failure demonstrated by the short program below.
> > > Essentially, a cBPF program that just rejects every frame (ie always
> > > returns zero) and is attached to a socket using setsockopt(SOL_SOCKET,
> > > SO_ATTACH_FILTER, ...) still occasionally lets frames through to
> > > userspace.
> > >
> > > The code is based on the first example in
> > > Documentation/networking/filter.txt, except that I've changed the
> > > content of the filter program and added a timeout on the socket.
> > >
> > > To reproduce the problem:
> > >
> > > # gcc test.c -o test
> > > # sudo ./test
> > > ... and in another console start a large network operation.
> > >
> > > In my case, I copied a ~300MB core file I had lying around to another
> > > host on the LAN.  The test code should print the string "Failed to
> > > read from socket" 100 times.  In practice, it produces about 10%
> > > "Received packet with ethertype..." messages.
> > >
> > > I've observed the same result on Ubuntu amd64 glibc system running a
> > > 5.9.0 kernel and also on Alpine arm64v8 muslc system running a 4.9.1
> > > kernel.  I've written test code in both C and Python.  I'm fairly sure
> > > this is not something I'm doing wrong - but very keen to have things
> > > thrown at me if it is.
> > >
> > > Regards,
> > > Tom Cook
> > >
> > >
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > >
> > > struct sock_filter code[] = {
> > > { 0x06,0,0,0x00 }  /* BPF_RET | BPF_K   0   0   0 */
> > > };
> > >
> > > struct sock_fprog bpf = {
> > > .len = 1,
> > > .filter = code,
> > > };
> > >
> > > void test() {
> > > uint8_t buf[2048];
> > >
> > > int sock = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
> > > if (sock < 0) {
> > > printf("Failed to open socket\n");
> > > return;
> > > }
> > > int ret = setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER, &bpf, 
> > > sizeof(bpf));
> > > if (ret < 0) {
> > > printf("Failed to set socket filter\n");
> > > return;
> > > }
> > > struct timeval tv = {
> > > .tv_sec = 1
> > > };
> > >
> > > ret = setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));
> > > if (ret < 0) {
> > > printf("Failed to set socket timeout\n");
> > > return;
> > > }
> > >
> > > ssize_t count = recv(sock, buf, 2048, 0);
> > > if (count <= 0) {
> > > printf("Failed to read from socket\n");
> > > return;
> > > }
> > >
> > > close(sock);
> > >
> > > uint16_t *ethertype = (short*)(buf + 12);
> > > uint8_t *proto = (unsigned char *)(buf + 23);
> > > uint16_t *dport = (uint16_t *)(buf + 14 + 20);
> > >
> > > printf("Received packet with ethertype 0x%04hu, protocol 0x%02hhu
> > > and dport 0x%04hu\n", *ethertype, *proto, *dport);
> > > }
> > >
> > > int main() {
> > > for (size_t ii = 0; ii < 100; ++ii) {
> > > test();
> > > }
> > > }

linux-next: Tree for Jan 15

2021-01-14 Thread Stephen Rothwell

Hi all,

Changes since 20210114:

The drm tree still had its build failure so I used the version from
next-20210107.

The amdgpu tree gained a conflict against Linus' tree.  It also gained
a build failure for which I disabled CONFIG_DRM_AMDGPU.

The drm-intel tree still had its build failure from merging the drm tree,
so I have used the version from next-20210108.

The drm-misc tree lost its build failure.

The tip tree still had its build failure for which I reverted a commit.

I still reverted a commit from the iomem-mmap-vs-gup tree that caused
a boot failure on PowerPC.

Non-merge commits (relative to Linus' tree): 3401
 3532 files changed, 134847 insertions(+), 55272 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 331 trees (counting Linus' and 85 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (65f0d2414b70 Merge tag 'sound-5.11-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound)
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (5625dcfbbcf8 Documentation: kbuild: Fix section 
reference)
Merging arc-current/for-curr (7c53f6b671f4 Linux 5.11-rc3)
Merging arm-current/fixes (e64ab473ddda ARM: 9034/1: __div64_32(): straighten 
up inline asm constraints)
Merging arm64-fixes/for-next/fixes (73a7c155a2b2 arm64: selftests: Fix spelling 
of 'Mismatch')
Merging arm-soc-fixes/arm/fixes (bac717171971 ARM: picoxcell: fix missing 
interrupt-parent properties)
Merging drivers-memory-fixes/fixes (5c8fe583cce5 Linux 5.11-rc1)
Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry)
Merging powerpc-fixes/fixes (41131a5e54ae powerpc/vdso: Fix 
clock_gettime_fallback for vdso32)
Merging s390-fixes/fixes (a1a322a62dba s390/vfio-ap: clean up vfio_ap resources 
when KVM pointer invalidated)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption 
not used on new files)
Merging net/master (13a9499e8333 mptcp: fix locking in mptcp_disconnect())
Merging bpf/master (4237e9f4a962 selftests/bpf: Add verifier test for 
PTR_TO_MEM spill)
Merging ipsec/master (da64ae2d35d3 xfrm: Fix wraparound in 
xfrm_policy_addr_delta())
Merging netfilter/master (c8a8ead01736 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (869f4fdaf4ca netfilter: nf_nat: Fix memleak in nf_nat_init)
Merging wireless-drivers/master (a6616bc9a0af iwlwifi: dbg: Don't touch the tlv 
data)
Merging mac80211/master (51d62f2f2c50 cfg80211: Save the regulatory domain with 
a lock)
Merging rdma-fixes/for-rc (7c7b3e5d9aee RDMA/cma: Fix error flow in 
default_roce_mode_store)
Merging sound-current/for-linus (67ea698c3950 ALSA: hda/via: Add minimum mute 
flag)
Merging sound-asoc-fixes/for-linus (530aef25e6ad Merge remote-tracking branch 
'asoc/for-5.11' into asoc-linus)
Merging regmap-fixes/for-linus (7c53f6b671f4 Linux 5.11-rc3)
Merging regulator-fixes/for-linus (17f953176384 Merge remote-tracking branch 
'regulator/for-5.11' into regulator-linus)
Merging spi-fixes/for-linus (7a2da5d7960a spi: fsl: Fix driver breakage when 
SPI_CS_HIGH is not set in spi->mode)
Merging pci

Re: [RFC v3 2/2] vfio/platform: msi: add Broadcom platform devices

2021-01-14 Thread Vikas Gupta

Hi Eric,

On Tue, Jan 12, 2021 at 2:52 PM Auger Eric  wrote:
>
> Hi Vikas,
>
> On 12/14/20 6:45 PM, Vikas Gupta wrote:
> > Add msi support for Broadcom platform devices
> >
> > Signed-off-by: Vikas Gupta 
> > ---
> >  drivers/vfio/platform/Kconfig |  1 +
> >  drivers/vfio/platform/Makefile|  1 +
> >  drivers/vfio/platform/msi/Kconfig |  9 
> >  drivers/vfio/platform/msi/Makefile|  2 +
> >  .../vfio/platform/msi/vfio_platform_bcmplt.c  | 49 +++
> >  5 files changed, 62 insertions(+)
> >  create mode 100644 drivers/vfio/platform/msi/Kconfig
> >  create mode 100644 drivers/vfio/platform/msi/Makefile
> >  create mode 100644 drivers/vfio/platform/msi/vfio_platform_bcmplt.c
> what does plt mean?
This(plt) is a generic name for Broadcom platform devices, which we`ll
 plan to add in this file. Currently we have only one in this file.
Do you think this name does not sound good here?
> >
> > diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig
> > index dc1a3c44f2c6..7b8696febe61 100644
> > --- a/drivers/vfio/platform/Kconfig
> > +++ b/drivers/vfio/platform/Kconfig
> > @@ -21,3 +21,4 @@ config VFIO_AMBA
> > If you don't know what to do here, say N.
> >
> >  source "drivers/vfio/platform/reset/Kconfig"
> > +source "drivers/vfio/platform/msi/Kconfig"
> > diff --git a/drivers/vfio/platform/Makefile b/drivers/vfio/platform/Makefile
> > index 3f3a24e7c4ef..9ccdcdbf0e7e 100644
> > --- a/drivers/vfio/platform/Makefile
> > +++ b/drivers/vfio/platform/Makefile
> > @@ -5,6 +5,7 @@ vfio-platform-y := vfio_platform.o
> >  obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform.o
> >  obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform-base.o
> >  obj-$(CONFIG_VFIO_PLATFORM) += reset/
> > +obj-$(CONFIG_VFIO_PLATFORM) += msi/
> >
> >  vfio-amba-y := vfio_amba.o
> >
> > diff --git a/drivers/vfio/platform/msi/Kconfig 
> > b/drivers/vfio/platform/msi/Kconfig
> > new file mode 100644
> > index ..54d6b70e1e32
> > --- /dev/null
> > +++ b/drivers/vfio/platform/msi/Kconfig
> > @@ -0,0 +1,9 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +config VFIO_PLATFORM_BCMPLT_MSI
> > + tristate "MSI support for Broadcom platform devices"
> > + depends on VFIO_PLATFORM && (ARCH_BCM_IPROC || COMPILE_TEST)
> > + default ARCH_BCM_IPROC
> > + help
> > +   Enables the VFIO platform driver to handle msi for Broadcom devices
> > +
> > +   If you don't know what to do here, say N.
> > diff --git a/drivers/vfio/platform/msi/Makefile 
> > b/drivers/vfio/platform/msi/Makefile
> > new file mode 100644
> > index ..27422d45cecb
> > --- /dev/null
> > +++ b/drivers/vfio/platform/msi/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +obj-$(CONFIG_VFIO_PLATFORM_BCMPLT_MSI) += vfio_platform_bcmplt.o
> > diff --git a/drivers/vfio/platform/msi/vfio_platform_bcmplt.c 
> > b/drivers/vfio/platform/msi/vfio_platform_bcmplt.c
> > new file mode 100644
> > index ..a074b5e92d77
> > --- /dev/null
> > +++ b/drivers/vfio/platform/msi/vfio_platform_bcmplt.c
> > @@ -0,0 +1,49 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright 2020 Broadcom.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "../vfio_platform_private.h"
> > +
> > +#define RING_SIZE(64 << 10)
> > +
> > +#define RING_MSI_ADDR_LS 0x03c
> > +#define RING_MSI_ADDR_MS 0x040
> > +#define RING_MSI_DATA_VALUE  0x064
> Those 3 defines would not be needed anymore with that implementation option.
> > +
> > +static u32 bcm_num_msi(struct vfio_platform_device *vdev)
> > +{
> > + struct vfio_platform_region *reg = &vdev->regions[0];
> > +
> > + return (reg->size / RING_SIZE);
> > +}
> > +
> > +static struct vfio_platform_msi_node vfio_platform_bcmflexrm_msi_node = {
> > + .owner = THIS_MODULE,
> > + .compat = "brcm,iproc-flexrm-mbox",
> > + .of_get_msi = bcm_num_msi,
> > +};
> > +
> > +static int __init vfio_platform_bcmflexrm_msi_module_init(void)
> > +{
> > + __vfio_platform_register_msi(&vfio_platform_bcmflexrm_msi_node);
> > +
> > + return 0;
> > +}
> > +
> > +static void __exit vfio_platform_bcmflexrm_msi_module_exit(void)
> > +{
> > + vfio_platform_unregister_msi("brcm,iproc-flexrm-mbox");
> > +}
> > +
> > +module_init(vfio_platform_bcmflexrm_msi_module_init);
> > +module_exit(vfio_platform_bcmflexrm_msi_module_exit);
> One thing I would like to discuss with Alex.
>
> As the reset module is mandated (except if reset_required is forced to
> 0), I am wondering if we shouldn't try to turn the reset module into a
> "specialization" module and put the msi hooks there. I am afraid we may
> end up having modules for each and every vfio platform feature
> specialization. At the moment that's fully bearable but I can't predict
> what's next.
>
> As the mandated feature is the reset capability maybe we could just keep
> the config/modul

Re: [PATCH] lib: dynamic_queue_limits: use memset and offsetof init

2021-01-14 Thread Yejune Deng

My patch is applied to linux-next/master tree.I also built in arch
arm64 and x86_64,is OK.Is something wrong with that?

On Fri, Jan 15, 2021 at 12:45 PM kernel test robot  wrote:
>
> Hi Yejune,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v5.11-rc3 next-20210114]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url:
> https://github.com/0day-ci/linux/commits/Yejune-Deng/lib-dynamic_queue_limits-use-memset-and-offsetof-init/20210115-112707
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> 146620506274bd24d52fb1c589110a30eed8240b
> config: nds32-randconfig-m031-20210115 (attached as .config)
> compiler: nds32le-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # 
> https://github.com/0day-ci/linux/commit/9be25b076f67d15d29016cb613b95d2ae190a9b4
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Yejune-Deng/lib-dynamic_queue_limits-use-memset-and-offsetof-init/20210115-112707
> git checkout 9be25b076f67d15d29016cb613b95d2ae190a9b4
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
> ARCH=nds32
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
>
> All error/warnings (new ones prefixed by >>):
>
>lib/dynamic_queue_limits.c: In function 'dql_reset':
> >> lib/dynamic_queue_limits.c:119:2: error: implicit declaration of function 
> >> 'memset' [-Werror=implicit-function-declaration]
>  119 |  memset(dql, 0, offsetof(struct dql, lowest_slack));
>  |  ^~
> >> lib/dynamic_queue_limits.c:119:2: warning: incompatible implicit 
> >> declaration of built-in function 'memset'
>lib/dynamic_queue_limits.c:11:1: note: include '' or provide a 
> declaration of 'memset'
>   10 | #include 
>  +++ |+#include 
>   11 | #include 
>cc1: some warnings being treated as errors
>
>
> vim +/memset +119 lib/dynamic_queue_limits.c
>
>115
>116  void dql_reset(struct dql *dql)
>117  {
>118  /* Reset all dynamic values */
>  > 119  memset(dql, 0, offsetof(struct dql, lowest_slack));
>120  dql->lowest_slack = UINT_MAX;
>121  dql->slack_start_time = jiffies;
>122  }
>123  EXPORT_SYMBOL(dql_reset);
>124
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH v2] nvme: allow use of cmb on v1.4 controllers

2021-01-14 Thread Klaus Jensen

On Jan 15 07:30, Klaus Jensen wrote:
> From: Klaus Jensen 
> 
> Since NVMe v1.4 the Controller Memory Buffer must be explicitly enabled
> by the host.
> 

Sorry, messed up and missed adding the changes for v2.

v2:
  - Do not explicitly check the NVMe version, rely on the presence of
the new register instead. (Christoph)
  - Use hi_lo_writeq. (Christoph, Keith)
  - Fix missing offset and use pci_bus_address(). (Keith)


signature.asc
Description: PGP signature

Re: [RFC PATCH v3 1/2] iommu: Add capability IOMMU_CAP_VIOMMU

2021-01-14 Thread Leon Romanovsky

On Fri, Jan 15, 2021 at 07:49:47AM +0800, Lu Baolu wrote:
> Hi Leon,
>
> On 1/14/21 9:26 PM, Leon Romanovsky wrote:
> > On Thu, Jan 14, 2021 at 09:30:02AM +0800, Lu Baolu wrote:
> > > Some vendor IOMMU drivers are able to declare that it is running in a VM
> > > context. This is very valuable for the features that only want to be
> > > supported on bare metal. Add a capability bit so that it could be used.
> >
> > And how is it used? Who and how will set it?
>
> Use the existing iommu_capable(). I should add more descriptions about
> who and how to use it.

I want to see the code that sets this capability.

Thanks

[PATCH v2] nvme: allow use of cmb on v1.4 controllers

2021-01-14 Thread Klaus Jensen

From: Klaus Jensen 

Since NVMe v1.4 the Controller Memory Buffer must be explicitly enabled
by the host.

Signed-off-by: Klaus Jensen 
---
 drivers/nvme/host/pci.c | 13 -
 include/linux/nvme.h|  6 ++
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 50d9a20568a2..62eb83030a5a 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1787,7 +1788,7 @@ static u32 nvme_cmb_size(struct nvme_dev *dev)
 
 static void nvme_map_cmb(struct nvme_dev *dev)
 {
-   u64 size, offset;
+   u64 size, offset, cmbmsc;
resource_size_t bar_size;
struct pci_dev *pdev = to_pci_dev(dev->dev);
int bar;
@@ -1795,6 +1796,9 @@ static void nvme_map_cmb(struct nvme_dev *dev)
if (dev->cmb_size)
return;
 
+   if (NVME_CAP_CMBS(dev->ctrl.cap))
+   writel(NVME_CMBMSC_CRE, dev->bar + NVME_REG_CMBMSC);
+
dev->cmbsz = readl(dev->bar + NVME_REG_CMBSZ);
if (!dev->cmbsz)
return;
@@ -1808,6 +1812,13 @@ static void nvme_map_cmb(struct nvme_dev *dev)
if (offset > bar_size)
return;
 
+   if (NVME_CAP_CMBS(dev->ctrl.cap)) {
+   cmbmsc = pci_bus_address(pdev, bar) + offset;
+   cmbmsc |= (NVME_CMBMSC_CRE | NVME_CMBMSC_CMSE);
+
+   hi_lo_writeq(cmbmsc, dev->bar + NVME_REG_CMBMSC);
+   }
+
/*
 * Controllers may support a CMB size larger than their BAR,
 * for example, due to being behind a bridge. Reduce the CMB to
diff --git a/include/linux/nvme.h b/include/linux/nvme.h
index d92535997687..bfed36e342cc 100644
--- a/include/linux/nvme.h
+++ b/include/linux/nvme.h
@@ -116,6 +116,9 @@ enum {
NVME_REG_BPMBL  = 0x0048,   /* Boot Partition Memory Buffer
 * Location
 */
+   NVME_REG_CMBMSC = 0x0050,   /* Controller Memory Buffer Memory
+* Space Control
+*/
NVME_REG_PMRCAP = 0x0e00,   /* Persistent Memory Capabilities */
NVME_REG_PMRCTL = 0x0e04,   /* Persistent Memory Region Control */
NVME_REG_PMRSTS = 0x0e08,   /* Persistent Memory Region Status */
@@ -135,6 +138,7 @@ enum {
 #define NVME_CAP_CSS(cap)  (((cap) >> 37) & 0xff)
 #define NVME_CAP_MPSMIN(cap)   (((cap) >> 48) & 0xf)
 #define NVME_CAP_MPSMAX(cap)   (((cap) >> 52) & 0xf)
+#define NVME_CAP_CMBS(cap) (((cap) >> 57) & 0x1)
 
 #define NVME_CMB_BIR(cmbloc)   ((cmbloc) & 0x7)
 #define NVME_CMB_OFST(cmbloc)  (((cmbloc) >> 12) & 0xf)
@@ -192,6 +196,8 @@ enum {
NVME_CSTS_SHST_OCCUR= 1 << 2,
NVME_CSTS_SHST_CMPLT= 2 << 2,
NVME_CSTS_SHST_MASK = 3 << 2,
+   NVME_CMBMSC_CRE = 1 << 0,
+   NVME_CMBMSC_CMSE= 1 << 1,
 };
 
 struct nvme_id_power_state {
-- 
2.30.0

Re: [PATCH v3] tty: make pl011 serial port driver support 485 mode

2021-01-14 Thread Greg KH

On Fri, Jan 15, 2021 at 02:32:39AM +, zhangqiumiao wrote:
> On Thu, Jan 14, 2021 at 08:28:30PM +0800, zhangqiumi...@huawei.com wrote:
> > From: Qiumiao Zhang 
> > 
> > make pl011 serial port support 485 mode full duplex communication
> > 
> > Signed-off-by: Qiumiao Zhang 
> > ---
> > Changes in v3:
> >   -Fix busy loop forever in pl011_tx_empty
> >   -Move the definition of cr into uart_amba_port
> >   -run checkpatch with no error or warning
> > 
> > Changes in v2:
> >   -Fix two compilation errors
> > 
> >  drivers/tty/serial/amba-pl011.c | 32 
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/drivers/tty/serial/amba-pl011.c 
> > b/drivers/tty/serial/amba-pl011.c index c255476..9da10a4 100644
> > --- a/drivers/tty/serial/amba-pl011.c
> > +++ b/drivers/tty/serial/amba-pl011.c
> > @@ -44,6 +44,7 @@
> > 
> >  #include "amba-pl011.h"
> > 
> > +#define ISEMPTY1
> >  #define UART_NR14
> > 
> >  #define SERIAL_AMBA_MAJOR  204
> > @@ -264,6 +265,7 @@ struct uart_amba_port {
> > unsigned intfifosize;   /* vendor-specific */
> > unsigned intold_cr; /* state during shutdown */
> > unsigned intfixed_baud; /* vendor-set fixed baud rate */
> > +   unsigned intcr;
> > chartype[12];
> >  #ifdef CONFIG_DMA_ENGINE
> > /* DMA stuff */
> > @@ -1284,6 +1286,8 @@ static inline bool pl011_dma_rx_running(struct 
> > uart_amba_port *uap)
> >  #define pl011_dma_flush_buffer NULL
> >  #endif
> > 
> > +static unsigned int pl011_tx_empty(struct uart_port *port);
> > +
> >  static void pl011_stop_tx(struct uart_port *port)  {
> > struct uart_amba_port *uap =
> > @@ -1292,6 +1296,17 @@ static void pl011_stop_tx(struct uart_port *port)
> > uap->im &= ~UART011_TXIM;
> > pl011_write(uap->im, uap, REG_IMSC);
> > pl011_dma_tx_stop(uap);
> > +   if (port->rs485.flags & SER_RS485_ENABLED) {
> > +   while(pl011_tx_empty(port) != ISEMPTY) ;
> 
> I intend to change this to:
> while(pl011_tx_empty(port) != ISEMPTY)
>   cpu_relax();
> Is this ok?

See other comments on this same list (linux-serial) for a patch for a
different driver a few days ago about why doing that would not be a good
idea.  Did you not review that change when it was submitted?

> > +
> > +   uap->cr = pl011_read(uap, REG_CR);
> > +   if (port->rs485.flags & SER_RS485_RTS_AFTER_SEND) {
> > +   uap->cr |= UART011_CR_RTS;
> > +   } else {
> > +   uap->cr &= ~UART011_CR_RTS;
> > +   }
> 
> Checkpatch doesn't find the problem here. Please tell me what's wrong here?

No braces should be needed, have you read the coding style rules?

thanks,

greg k-h

Re: [RFC v3 1/2] vfio/platform: add support for msi

2021-01-14 Thread Vikas Gupta

Hi Eric,

On Tue, Jan 12, 2021 at 2:30 PM Auger Eric  wrote:
>
> Hi Vikas,
>
> On 1/5/21 6:53 AM, Vikas Gupta wrote:
> > On Tue, Dec 22, 2020 at 10:57 PM Auger Eric  wrote:
> >>
> >> Hi Vikas,
> >>
> >> On 12/14/20 6:45 PM, Vikas Gupta wrote:
> >>> MSI support for platform devices.The MSI block
> >>> is added as an extended IRQ which exports caps
> >>> VFIO_IRQ_INFO_CAP_TYPE and VFIO_IRQ_INFO_CAP_MSI_DESCS.
> >>>
> >>> Signed-off-by: Vikas Gupta 
> >>> ---
> >>>  drivers/vfio/platform/vfio_platform_common.c  | 179 +++-
> >>>  drivers/vfio/platform/vfio_platform_irq.c | 260 +-
> >>>  drivers/vfio/platform/vfio_platform_private.h |  32 +++
> >>>  include/uapi/linux/vfio.h |  44 +++
> >>>  4 files changed, 496 insertions(+), 19 deletions(-)
> >>>
> >>> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> >>> b/drivers/vfio/platform/vfio_platform_common.c
> >>> index fb4b385191f2..c936852f35d7 100644
> >>> --- a/drivers/vfio/platform/vfio_platform_common.c
> >>> +++ b/drivers/vfio/platform/vfio_platform_common.c
> >>> @@ -16,6 +16,7 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>
> >>>  #include "vfio_platform_private.h"
> >>>
> >>> @@ -26,6 +27,8 @@
> >>>  #define VFIO_PLATFORM_IS_ACPI(vdev) ((vdev)->acpihid != NULL)
> >>>
> >>>  static LIST_HEAD(reset_list);
> >>> +/* devices having MSI support */
> >> nit: for devices using MSIs?
> >>> +static LIST_HEAD(msi_list);
> >>>  static DEFINE_MUTEX(driver_lock);
> >>>
> >>>  static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char 
> >>> *compat,
> >>> @@ -47,6 +50,25 @@ static vfio_platform_reset_fn_t 
> >>> vfio_platform_lookup_reset(const char *compat,
> >>>   return reset_fn;
> >>>  }
> >>>
> >>> +static bool vfio_platform_lookup_msi(struct vfio_platform_device *vdev)
> >>> +{
> >>> + bool has_msi = false;
> >>> + struct vfio_platform_msi_node *iter;
> >>> +
> >>> + mutex_lock(&driver_lock);
> >>> + list_for_each_entry(iter, &msi_list, link) {
> >>> + if (!strcmp(iter->compat, vdev->compat) &&
> >>> + try_module_get(iter->owner)) {
> >>> + vdev->msi_module = iter->owner;
> >>> + vdev->of_get_msi = iter->of_get_msi;
> >>> + has_msi = true;
> >>> + break;
> >>> + }
> >>> + }
> >>> + mutex_unlock(&driver_lock);
> >>> + return has_msi;
> >>> +}
> >>> +
> >>>  static int vfio_platform_acpi_probe(struct vfio_platform_device *vdev,
> >>>   struct device *dev)
> >>>  {
> >>> @@ -126,6 +148,19 @@ static int vfio_platform_get_reset(struct 
> >>> vfio_platform_device *vdev)
> >>>   return vdev->of_reset ? 0 : -ENOENT;
> >>>  }
> >>>
> >>> +static int vfio_platform_get_msi(struct vfio_platform_device *vdev)
> >>> +{
> >>> + bool has_msi;
> >>> +
> >>> + has_msi = vfio_platform_lookup_msi(vdev);
> >>> + if (!has_msi) {
> >>> + request_module("vfio-msi:%s", vdev->compat);
> >>> + has_msi = vfio_platform_lookup_msi(vdev);
> >>> + }
> >>> +
> >>> + return has_msi ? 0 : -ENOENT;
> >>> +}
> >>> +
> >>>  static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
> >>>  {
> >>>   if (VFIO_PLATFORM_IS_ACPI(vdev))
> >>> @@ -135,6 +170,12 @@ static void vfio_platform_put_reset(struct 
> >>> vfio_platform_device *vdev)
> >>>   module_put(vdev->reset_module);
> >>>  }
> >>>
> >>> +static void vfio_platform_put_msi(struct vfio_platform_device *vdev)
> >>> +{
> >>> + if (vdev->of_get_msi)
> >>> + module_put(vdev->msi_module);
> >>> +}
> >>> +
> >>>  static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
> >>>  {
> >>>   int cnt = 0, i;
> >>> @@ -343,9 +384,17 @@ static long vfio_platform_ioctl(void *device_data,
> >>>
> >>>   } else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {
> >>>   struct vfio_irq_info info;
> >>> + struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
> >>> + struct vfio_irq_info_cap_msi *msi_info = NULL;
> >>> + int ext_irq_index = vdev->num_irqs - vdev->num_ext_irqs;
> >>> + unsigned long capsz;
> >>> + u32 index;
> >>>
> >>>   minsz = offsetofend(struct vfio_irq_info, count);
> >>>
> >>> + /* For backward compatibility, cannot require this */
> >>> + capsz = offsetofend(struct vfio_irq_info, cap_offset);
> >>> +
> >>>   if (copy_from_user(&info, (void __user *)arg, minsz))
> >>>   return -EFAULT;
> >>>
> >>> @@ -355,8 +404,94 @@ static long vfio_platform_ioctl(void *device_data,
> >>>   if (info.index >= vdev->num_irqs)
> >>>   return -EINVAL;
> >>>
> >>> - info.flags = vdev->irqs[info.index].flags;
> >>> - info.count = vdev->irqs[info.index].count;
> >>> + if (info.argsz

[tip:master] BUILD SUCCESS 2c2adbc40b7276518921864053f3c02034b2290f

2021-01-14 Thread kernel test robot

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
branch HEAD: 2c2adbc40b7276518921864053f3c02034b2290f  Merge branch 'irq/urgent'

elapsed time: 723m

configs tested: 106
configs skipped: 2

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
arm   imx_v4_v5_defconfig
arc  axs103_smp_defconfig
sh  r7785rp_defconfig
m68km5272c3_defconfig
armoxnas_v6_defconfig
sh  defconfig
powerpcsocrates_defconfig
arm   spitz_defconfig
shmigor_defconfig
arm   sunxi_defconfig
powerpc  tqm8xx_defconfig
xtensasmp_lx200_defconfig
arm vf610m4_defconfig
mips  rb532_defconfig
sh shx3_defconfig
powerpc mpc837x_mds_defconfig
i386 alldefconfig
powerpc redwood_defconfig
armlart_defconfig
armpleb_defconfig
sh sh7710voipgw_defconfig
sh magicpanelr2_defconfig
mipsmalta_kvm_guest_defconfig
c6x dsk6455_defconfig
arm ezx_defconfig
arm  integrator_defconfig
powerpc   lite5200b_defconfig
archsdk_defconfig
riscvnommu_virt_defconfig
mips  maltaaprp_defconfig
arm  imote2_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a002-20210114
i386 randconfig-a005-20210114
i386 randconfig-a006-20210114
i386 randconfig-a001-20210114
i386 randconfig-a003-20210114
i386 randconfig-a004-20210114
x86_64   randconfig-a015-20210114
x86_64   randconfig-a012-20210114
x86_64   randconfig-a013-20210114
x86_64   randconfig-a016-20210114
x86_64   randconfig-a014-20210114
x86_64   randconfig-a011-20210114
i386 randconfig-a012-20210114
i386 randconfig-a011-20210114
i386 randconfig-a016-20210114
i386 randconfig-a015-20210114
i386 randconfig-a013-20210114
i386 randconfig-a014-20210114
riscvnommu_k210_defconfig
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64

Re: [PATCH v6 2/8] regulator: dt-bindings: Document max8997-pmic nodes

2021-01-14 Thread Timon Baetz

On Fri, 8 Jan 2021 16:16:53 +, Mark Brown wrote:
> On Fri, Jan 08, 2021 at 03:16:48PM +, Timon Baetz wrote:
> 
> > Muic needs a node to be used with extcon_get_edev_by_phandle().
> > Charger needs a node to reference a regulator.  
> 
> The pattern is to use the parent device's node.

So is extcon going to be a self-reference then?

Just for my understanding: I can see sub-nodes for MFD all over the
place. It is still not clear to me why sub-nodes aren't the right
choice in this specific case?

Thanks for the feedback,
Timon

[PATCH 1/2] ASoC: codecs: soundwire: increase resume timeout

From: Pierre-Louis Bossart 

The resume operation relies on multiple transactions to synchronize
the regmap state, make sure the timeout is one order of magnitude
larger than an individual transaction, so that timeouts of failed
transactions are detected first.

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Bard Liao 
---
 sound/soc/codecs/max98373-sdw.c | 4 +++-
 sound/soc/codecs/rt1308-sdw.c   | 2 +-
 sound/soc/codecs/rt5682.h   | 2 +-
 sound/soc/codecs/rt700-sdw.c| 2 +-
 sound/soc/codecs/rt711-sdw.c| 2 +-
 sound/soc/codecs/rt715-sdw.c| 2 +-
 6 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/sound/soc/codecs/max98373-sdw.c b/sound/soc/codecs/max98373-sdw.c
index ec2e79c57357..ad2d5d6a2fe4 100644
--- a/sound/soc/codecs/max98373-sdw.c
+++ b/sound/soc/codecs/max98373-sdw.c
@@ -251,6 +251,8 @@ static __maybe_unused int max98373_suspend(struct device 
*dev)
return 0;
 }
 
+#define MAX98373_PROBE_TIMEOUT 5000
+
 static __maybe_unused int max98373_resume(struct device *dev)
 {
struct sdw_slave *slave = dev_to_sdw_dev(dev);
@@ -264,7 +266,7 @@ static __maybe_unused int max98373_resume(struct device 
*dev)
goto regmap_sync;
 
time = wait_for_completion_timeout(&slave->initialization_complete,
-  msecs_to_jiffies(2000));
+  
msecs_to_jiffies(MAX98373_PROBE_TIMEOUT));
if (!time) {
dev_err(dev, "Initialization not complete, timed out\n");
return -ETIMEDOUT;
diff --git a/sound/soc/codecs/rt1308-sdw.c b/sound/soc/codecs/rt1308-sdw.c
index ec5564f780e8..afd2c3b687cc 100644
--- a/sound/soc/codecs/rt1308-sdw.c
+++ b/sound/soc/codecs/rt1308-sdw.c
@@ -701,7 +701,7 @@ static int __maybe_unused rt1308_dev_suspend(struct device 
*dev)
return 0;
 }
 
-#define RT1308_PROBE_TIMEOUT 2000
+#define RT1308_PROBE_TIMEOUT 5000
 
 static int __maybe_unused rt1308_dev_resume(struct device *dev)
 {
diff --git a/sound/soc/codecs/rt5682.h b/sound/soc/codecs/rt5682.h
index 99b85cfe6248..1f9c51a5b9bf 100644
--- a/sound/soc/codecs/rt5682.h
+++ b/sound/soc/codecs/rt5682.h
@@ -1356,7 +1356,7 @@
 #define RT5682_SAR_SOUR_TYPE   (0x0)
 
 /* soundwire timeout */
-#define RT5682_PROBE_TIMEOUT   2000
+#define RT5682_PROBE_TIMEOUT   5000
 
 
 #define RT5682_STEREO_RATES SNDRV_PCM_RATE_8000_192000
diff --git a/sound/soc/codecs/rt700-sdw.c b/sound/soc/codecs/rt700-sdw.c
index fb77e77a4ebd..ce9255b881d4 100644
--- a/sound/soc/codecs/rt700-sdw.c
+++ b/sound/soc/codecs/rt700-sdw.c
@@ -490,7 +490,7 @@ static int __maybe_unused rt700_dev_suspend(struct device 
*dev)
return 0;
 }
 
-#define RT700_PROBE_TIMEOUT 2000
+#define RT700_PROBE_TIMEOUT 5000
 
 static int __maybe_unused rt700_dev_resume(struct device *dev)
 {
diff --git a/sound/soc/codecs/rt711-sdw.c b/sound/soc/codecs/rt711-sdw.c
index fc7df79c3b91..756c0ada3b31 100644
--- a/sound/soc/codecs/rt711-sdw.c
+++ b/sound/soc/codecs/rt711-sdw.c
@@ -493,7 +493,7 @@ static int __maybe_unused rt711_dev_suspend(struct device 
*dev)
return 0;
 }
 
-#define RT711_PROBE_TIMEOUT 2000
+#define RT711_PROBE_TIMEOUT 5000
 
 static int __maybe_unused rt711_dev_resume(struct device *dev)
 {
diff --git a/sound/soc/codecs/rt715-sdw.c b/sound/soc/codecs/rt715-sdw.c
index 8f0aa1e8a273..71dd3b97a459 100644
--- a/sound/soc/codecs/rt715-sdw.c
+++ b/sound/soc/codecs/rt715-sdw.c
@@ -533,7 +533,7 @@ static int __maybe_unused rt715_dev_suspend(struct device 
*dev)
return 0;
 }
 
-#define RT715_PROBE_TIMEOUT 2000
+#define RT715_PROBE_TIMEOUT 5000
 
 static int __maybe_unused rt715_dev_resume(struct device *dev)
 {
-- 
2.17.1

[PATCH 2/2] soundwire: cadence: reduce timeout on transactions

From: Pierre-Louis Bossart 

Currently the timeout for SoundWire individual transactions is 2s.

This is too large in comparison with the enumeration and completion
timeouts used in codec drivers.

A command will typically be handled in less than 100us, so 500ms for
the command completion is more than generous.

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/cadence_master.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
index 9fa55164354a..f0b0ec173f8b 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -188,7 +188,7 @@ MODULE_PARM_DESC(cdns_mcp_int_mask, "Cadence MCP IntMask");
 #define CDNS_PDI_CONFIG_PORT   GENMASK(4, 0)
 
 /* Driver defaults */
-#define CDNS_TX_TIMEOUT2000
+#define CDNS_TX_TIMEOUT500
 
 #define CDNS_SCP_RX_FIFOLEVEL  0x2
 
-- 
2.17.1

[PATCH 0/2] ASoC/SoundWire: fix timeout values

The timeout for an individual transaction w/ the Cadence IP is the same as
the entire resume operation for codecs.
This doesn't make sense, we need to have at least one order of magnitude
between individual transactions and the entire resume operation.

Set the timeout on the Cadence side to 500ms and 5s for the codec resume.

Both ASoC and SoundWire trees are fine for this series.

Pierre-Louis Bossart (2):
  ASoC: codecs: soundwire: increase resume timeout
  soundwire: cadence: reduce timeout on transactions

 drivers/soundwire/cadence_master.c | 2 +-
 sound/soc/codecs/max98373-sdw.c| 4 +++-
 sound/soc/codecs/rt1308-sdw.c  | 2 +-
 sound/soc/codecs/rt5682.h  | 2 +-
 sound/soc/codecs/rt700-sdw.c   | 2 +-
 sound/soc/codecs/rt711-sdw.c   | 2 +-
 sound/soc/codecs/rt715-sdw.c   | 2 +-
 7 files changed, 9 insertions(+), 7 deletions(-)

-- 
2.17.1

Re: [PATCH] mailbox: arm_mhuv2: Fix sparse warnings

2021-01-14 Thread Viresh Kumar

On 30-12-20, 10:12, Viresh Kumar wrote:
> This patch fixes a bunch of sparse warnings in the newly added arm_mhuv2
> driver.
> 
> drivers/mailbox/arm_mhuv2.c:506:24: warning: incorrect type in argument 1 
> (different address spaces)
> drivers/mailbox/arm_mhuv2.c:506:24:expected void const volatile [noderef] 
> __iomem *addr
> drivers/mailbox/arm_mhuv2.c:506:24:got unsigned int [usertype] *
> drivers/mailbox/arm_mhuv2.c:547:42: warning: incorrect type in argument 2 
> (different address spaces)
> drivers/mailbox/arm_mhuv2.c:547:42:expected unsigned int [usertype] *reg
> drivers/mailbox/arm_mhuv2.c:547:42:got unsigned int [noderef] __iomem *
> drivers/mailbox/arm_mhuv2.c:625:42: warning: incorrect type in argument 2 
> (different address spaces)
> drivers/mailbox/arm_mhuv2.c:625:42:expected unsigned int [usertype] *reg
> drivers/mailbox/arm_mhuv2.c:625:42:got unsigned int [noderef] __iomem *
> drivers/mailbox/arm_mhuv2.c:972:24: warning: dereference of noderef expression
> drivers/mailbox/arm_mhuv2.c:973:22: warning: dereference of noderef expression
> drivers/mailbox/arm_mhuv2.c:993:25: warning: dereference of noderef expression
> drivers/mailbox/arm_mhuv2.c:1026:24: warning: dereference of noderef 
> expression
> drivers/mailbox/arm_mhuv2.c:1027:22: warning: dereference of noderef 
> expression
> drivers/mailbox/arm_mhuv2.c:1048:17: warning: dereference of noderef 
> expression
> 
> Reported-by: kernel test robot 
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/mailbox/arm_mhuv2.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)

Jassi, can you please send this for 5.11-rc4 ?

-- 
viresh

Re: [PATCH 00/10] Fix documentation warnings at linux-next

2021-01-14 Thread Lukas Bulwahn

[reduced the recipient list to the main responsible ones and list]

Hi Mauro, hi Jonathan,

We both, Mauro and I, have been submitting patches to address the
documentation warnings on linux-next. If it is okay with you, Mauro, I
would like to take responsibility for the task to send out the patches
to address all warnings on linux-next in make htmldocs and follow up
with all the discussions. I can also provide a short weekly summary
(probably always on Friday) on what is pending where and what I could
not resolve by myself.

Is that okay for you?

If at some point I do not have the time to take care anymore, I will
let you know.


Best regards,

Lukas

[PATCH net] udp: ipv4: manipulate network header of NATed UDP GRO fraglist

2021-01-14 Thread Dongseok Yi

UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
forwarding. Only the header of head_skb from ip_finish_output_gso ->
skb_gso_segment is updated but following frag_skbs are not updated.

A call path skb_mac_gso_segment -> inet_gso_segment ->
udp4_ufo_fragment -> __udp_gso_segment -> __udp_gso_segment_list
does not try to update UDP/IP header of the segment list.

Update dport, daddr and checksums of each skb of the segment list
after __udp_gso_segment.

Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.)
Signed-off-by: Dongseok Yi 
---
Steffen Klassert said, there could be 2 options.
https://lore.kernel.org/patchwork/patch/1362257/

I was trying to write a quick fix, but it was not easy to forward
segmented list. Currently, assuming DNAT only. Should we consider
SNAT too?

 net/ipv4/udp_offload.c | 45 +
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index ff39e94..7e24928 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -309,10 +309,12 @@ static struct sk_buff *udp4_ufo_fragment(struct sk_buff 
*skb,
 netdev_features_t features)
 {
struct sk_buff *segs = ERR_PTR(-EINVAL);
+   struct sk_buff *seg;
unsigned int mss;
__wsum csum;
-   struct udphdr *uh;
-   struct iphdr *iph;
+   struct udphdr *uh, *uh2;
+   struct iphdr *iph, *iph2;
+   bool is_fraglist = false;
 
if (skb->encapsulation &&
(skb_shinfo(skb)->gso_type &
@@ -327,8 +329,43 @@ static struct sk_buff *udp4_ufo_fragment(struct sk_buff 
*skb,
if (!pskb_may_pull(skb, sizeof(struct udphdr)))
goto out;
 
-   if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
-   return __udp_gso_segment(skb, features);
+   if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4) {
+   if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST)
+   is_fraglist = true;
+
+   segs = __udp_gso_segment(skb, features);
+   if (IS_ERR_OR_NULL(segs) || !is_fraglist)
+   return segs;
+
+   seg = segs;
+   uh = udp_hdr(seg);
+   iph = ip_hdr(seg);
+
+   while ((seg = seg->next)) {
+   uh2 = udp_hdr(seg);
+   iph2 = ip_hdr(seg);
+
+   if (uh->dest == uh2->dest && iph->daddr == iph2->daddr)
+   continue;
+
+   if (uh2->check) {
+   inet_proto_csum_replace4(&uh2->check, seg,
+iph2->daddr,
+iph->daddr, true);
+   inet_proto_csum_replace2(&uh2->check, seg,
+uh2->dest, uh->dest,
+false);
+   if (!uh2->check)
+   uh2->check = CSUM_MANGLED_0;
+   }
+   uh2->dest = uh->dest;
+
+   csum_replace4(&iph2->check, iph2->daddr, iph->daddr);
+   iph2->daddr = iph->daddr;
+   }
+
+   return segs;
+   }
 
mss = skb_shinfo(skb)->gso_size;
if (unlikely(skb->len <= mss))
-- 
2.7.4

[PATCH v6 1/2] dt-bindings: PCI: sprd: Document Unisoc PCIe RC host controller

2021-01-14 Thread Hongtao Wu

From: Hongtao Wu 

This series adds PCIe bindings for Unisoc SoCs.
This controller is based on DesignWare PCIe IP.

Reviewed-by: Rob Herring 
Signed-off-by: Hongtao Wu 
---
 .../devicetree/bindings/pci/sprd-pcie.yaml | 93 ++
 1 file changed, 93 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/sprd-pcie.yaml

diff --git a/Documentation/devicetree/bindings/pci/sprd-pcie.yaml 
b/Documentation/devicetree/bindings/pci/sprd-pcie.yaml
new file mode 100644
index 000..ede06a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/sprd-pcie.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/sprd-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SoC PCIe Host Controller Device Tree Bindings
+
+maintainers:
+  - Hongtao Wu 
+
+allOf:
+  - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+  compatible:
+items:
+  - const: sprd,ums9520-pcie
+
+  reg:
+minItems: 2
+items:
+  - description: Controller control and status registers.
+  - description: PCIe configuration registers.
+
+  reg-names:
+items:
+  - const: dbi
+  - const: config
+
+  ranges:
+maxItems: 2
+
+  num-lanes:
+maximum: 1
+description: Number of lanes to use for this port.
+
+  interrupts:
+minItems: 1
+description: Builtin MSI controller and PCIe host controller.
+
+  interrupt-names:
+items:
+  - const: msi
+
+  sprd,regmap-aon:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description:
+  Phandle to the AON system controller node (to access the
+  AON_ACCESS_PCIE_EN register on ums9520).
+  sprd,regmap-pmu:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description:
+  Phandle to the PMU system controller node (to access the PERST_N_ASSERT
+  register on ums9520).
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - num-lanes
+  - ranges
+  - interrupts
+  - interrupt-names
+
+additionalProperties: true
+
+examples:
+  - |
+#include 
+
+ipa {
+#address-cells = <2>;
+#size-cells = <2>;
+
+pcie0: pcie@2b10 {
+compatible = "sprd,ums9520-pcie";
+reg = <0x0 0x2b10 0x0 0x2000>,
+  <0x2 0x 0x0 0x2000>;
+reg-names = "dbi", "config";
+#address-cells = <3>;
+#size-cells = <2>;
+device_type = "pci";
+ranges = <0x0100 0x0 0x 0x2 0x2000 0x0 0x0001>,
+ <0x0300 0x0 0x1000 0x2 0x1000 0x1 0xefff>;
+num-lanes = <1>;
+interrupts = ;
+interrupt-names = "msi";
+
+sprd,regmap-aon = <&aon_regs>;
+sprd,regmap-pmu = <&pmu_regs>;
+};
+};
--
2.7.4

[PATCH v6 0/2] PCI: Add new Unisoc PCIe driver

2021-01-14 Thread Hongtao Wu

From: Hongtao Wu 

This series adds PCIe controller driver for Unisoc SoCs.
This controller is based on DesignWare PCIe IP.

Changes from v1:
1) Test this patch on top of Rob Herring's 40 part series of DWC clean-ups:
   https://lore.kernel.org/linux-pci/20200821035420.380495-1-r...@kernel.org/

2) Delete empty function

3) Document property "sprd,pcie-poweron-syscons" and
   'sprd,pcie-poweroff-syscons'

4) Delete runtime suspend/resume function

5) Add COMPILE_TEST which CONFIG_PCIE_SPRD depends on

Changes from v2:
1) Change RC mode to host mode in drivers/pci/controller/dwc/Kconfig

2) Change Signed-off-by from Billows Wu to Hongtao Wu

Changes from v3:
1) Split the property 'sprd,pcie-poweron-syscons' and
   'sprd,pcie-poweroff-syscons' into reset, power domains, phy and so on.

2) Delete the function to get resource 'msi' and 'dbi' which were parsed by the
   DW core.

3) Delete the function 'sprd_pcie_host_init', because the DW core has done it.

Changes from v4:
1) Install 'yamllint' and upgrade dt-schema in order to solve the yamllint and
dtschema/dtc warnings/errors:

Changes from v5:
1) Change "GPL v2" to "GPL".
2) Remove exit_p wrapper which used to define remove callback.

Hongtao Wu (2):
  dt-bindings: PCI: sprd: Document Unisoc PCIe RC host controller
  PCI: sprd: Add support for Unisoc SoCs' PCIe controller

 .../devicetree/bindings/pci/sprd-pcie.yaml |  93 +++
 drivers/pci/controller/dwc/Kconfig |  12 +
 drivers/pci/controller/dwc/Makefile|   1 +
 drivers/pci/controller/dwc/pcie-sprd.c | 293 +
 4 files changed, 399 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/sprd-pcie.yaml
 create mode 100644 drivers/pci/controller/dwc/pcie-sprd.c

--
2.7.4

[PATCH v6 2/2] PCI: sprd: Add support for Unisoc SoCs' PCIe controller

2021-01-14 Thread Hongtao Wu

From: Hongtao Wu 

This series adds PCIe controller driver for Unisoc SoCs.
This controller is based on DesignWare PCIe IP.

Signed-off-by: Hongtao Wu 
---
 drivers/pci/controller/dwc/Kconfig |  12 ++
 drivers/pci/controller/dwc/Makefile|   1 +
 drivers/pci/controller/dwc/pcie-sprd.c | 293 +
 3 files changed, 306 insertions(+)
 create mode 100644 drivers/pci/controller/dwc/pcie-sprd.c

diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index 22c5529..61f0b79 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -318,4 +318,16 @@ config PCIE_AL
  required only for DT-based platforms. ACPI platforms with the
  Annapurna Labs PCIe controller don't need to enable this.

+config PCIE_SPRD
+   tristate "Unisoc PCIe controller - Host Mode"
+   depends on ARCH_SPRD || COMPILE_TEST
+   depends on PCI_MSI_IRQ_DOMAIN
+   select PCIE_DW_HOST
+   help
+ Unisoc PCIe controller uses the DesignWare core. It can be configured
+ as an Endpoint (EP) or a Root complex (RC). In order to enable host
+ mode (the controller works as RC), PCIE_SPRD must be selected.
+ Say Y or M here if you want to PCIe RC controller support on Unisoc
+ SoCs.
+
 endmenu
diff --git a/drivers/pci/controller/dwc/Makefile 
b/drivers/pci/controller/dwc/Makefile
index a751553..eb546e9 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PCI_MESON) += pci-meson.o
 obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
 obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
 obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
+obj-$(CONFIG_PCIE_SPRD) += pcie-sprd.o

 # The following drivers are for devices that use the generic ACPI
 # pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/controller/dwc/pcie-sprd.c 
b/drivers/pci/controller/dwc/pcie-sprd.c
new file mode 100644
index 000..03e2064
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-sprd.c
@@ -0,0 +1,293 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCIe host controller driver for Unisoc SoCs
+ *
+ * Copyright (C) 2020-2021 Unisoc, Inc.
+ *
+ * Author: Hongtao Wu 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pcie-designware.h"
+
+/* aon apb syscon */
+#define IPA_ACCESS_CFG 0xcd8
+#define  AON_ACCESS_PCIE_ENBIT(1)
+
+/* pmu apb syscon */
+#define SNPS_PCIE3_SLP_CTRL0xac
+#define  PERST_N_ASSERTBIT(1)
+#define  PERST_N_AUTO_EN   BIT(0)
+#define PD_PCIE_CFG_0  0x3e8
+#define  PCIE_FORCE_SHUTDOWN   BIT(25)
+
+#define PCIE_SS_REG_BASE   0xE00
+#define APB_CLKFREQ_TIMEOUT0x4
+#define  BUSERR_EN BIT(12)
+#define  APB_TIMER_DIS BIT(10)
+#define  APB_TIMER_LIMIT   GENMASK(31, 16)
+
+#define PE0_GEN_CTRL_3 0x58
+#define  LTSSM_EN  BIT(0)
+
+struct sprd_pcie_soc_data {
+   u32 syscon_offset;
+};
+
+static const struct sprd_pcie_soc_data ums9520_syscon_data = {
+   .syscon_offset = 0x1000,/* The offset of set/clear register */
+};
+
+struct sprd_pcie {
+   u32 syscon_offset;
+   struct device   *dev;
+   struct dw_pcie  *pci;
+   struct regmap   *aon_map;
+   struct regmap   *pmu_map;
+   const struct sprd_pcie_soc_data *socdata;
+};
+
+enum sprd_pcie_syscon_type {
+   normal_syscon,  /* it's not a set/clear register */
+   set_syscon, /* set a set/clear register */
+   clr_syscon, /* clear a set/clear register */
+};
+
+static void sprd_pcie_buserr_enable(struct dw_pcie *pci)
+{
+   u32 val;
+
+   val = dw_pcie_readl_dbi(pci, PCIE_SS_REG_BASE + APB_CLKFREQ_TIMEOUT);
+   val &= ~APB_TIMER_DIS;
+   val |= BUSERR_EN;
+   val |= APB_TIMER_LIMIT & (0x1f4 << 16);
+   dw_pcie_writel_dbi(pci, PCIE_SS_REG_BASE + APB_CLKFREQ_TIMEOUT, val);
+}
+
+static void sprd_pcie_ltssm_enable(struct dw_pcie *pci, bool enable)
+{
+   u32 val;
+
+   val = dw_pcie_readl_dbi(pci, PCIE_SS_REG_BASE + PE0_GEN_CTRL_3);
+   if (enable)
+   dw_pcie_writel_dbi(pci, PCIE_SS_REG_BASE + PE0_GEN_CTRL_3,
+  val | LTSSM_EN);
+   else
+   dw_pcie_writel_dbi(pci, PCIE_SS_REG_BASE + PE0_GEN_CTRL_3,
+  val & ~LTSSM_EN);
+}
+
+static int sprd_pcie_syscon_set(struct sprd_pcie *ctrl, struct regmap *map,
+   u32 reg, u32 mask, u32 val,
+   enum sprd_pcie_syscon_type type)
+{
+   int ret = 0;
+   u32 read_val;
+   u32 offset = ctrl->syscon_offset;
+   struct device *dev = ctrl->pci->dev;
+
+   /*
+* Each set/clear register has three registers:
+

Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys

2021-01-14 Thread Sumit Garg

On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen  wrote:
>
> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > Hi Jarkko,
> >
> > On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen  wrote:
> > >
> > > On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > Add support for TEE based trusted keys where TEE provides the 
> > > > functionality
> > > > to seal and unseal trusted keys using hardware unique key.
> > > >
> > > > Refer to Documentation/tee.txt for detailed information about TEE.
> > > >
> > > > Signed-off-by: Sumit Garg 
> > >
> > > I haven't yet got QEMU environment working with aarch64, this produces
> > > just a blank screen:
> > >
> > > ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 
> > > -kernel output/images/Image -initrd output/images/rootfs.cpio -serial 
> > > stdio
> > >
> > > My BuildRoot fork for TPM and keyring testing is located over here:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > >
> > > The "ARM version" is at this point in aarch64 branch. Over time I will
> > > define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > in the master branch.
> > >
> > > To create identical images you just need to
> > >
> > > $ make tpmdd_defconfig && make
> > >
> > > Can you check if you see anything obviously wrong? I'm eager to test this
> > > patch set, and in bigger picture I really need to have ready to run
> > > aarch64 environment available.
> >
> > I would rather suggest you to follow steps listed here [1] as to test
> > this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > system [2]. And then it would be easier to migrate them to your
> > buildroot environment as well.
> >
> > [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/27.html
> > [2] 
> > https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> >
> > -Sumit
>
> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
>

$ cat keyctl_change
diff --git a/common.mk b/common.mk
index aeb7b41..663e528 100644
--- a/common.mk
+++ b/common.mk
@@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
 BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
 BR2_PACKAGE_STRACE ?= y
 BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
$(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
+BR2_PACKAGE_KEYUTILS := y

 # All BR2_* variables from the makefile or the environment are appended to
 # ../out-br/extra.conf. All values are quoted "..." except y and n.
diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
index 368c18a..832ab74 100644
--- a/kconfigs/qemu.conf
+++ b/kconfigs/qemu.conf
@@ -20,3 +20,5 @@ CONFIG_9P_FS=y
 CONFIG_9P_FS_POSIX_ACL=y
 CONFIG_HW_RANDOM=y
 CONFIG_HW_RANDOM_VIRTIO=y
+CONFIG_TRUSTED_KEYS=y
+CONFIG_ENCRYPTED_KEYS=y

> After I've successfully tested 2/4, I'd suggest that you roll out one more
> version and CC the documentation patch to Elaine and Mini, and clearly
> remark in the commit message that TEE is a standard, with a link to the
> specification.
>

Sure, I will roll out the next version after your testing.

-Sumit

> /Jarkko

Re: [PATCH v2] cgroup-v1: add disabled controller check in cgroup1_parse_param()

2021-01-14 Thread chenzhou




On 2021/1/15 11:17, Tejun Heo wrote:
> Hello,
>
> On Fri, Jan 15, 2021 at 09:55:43AM +0800, chenzhou wrote:
>> Yeah, this will select all enabled controllers, but which doesn't the 
>> behavior we want.
>> I think the case should return error with information "Disabled controller 
>> xx" rather than
>> attaching all the other enabled controllers.
>>
>> For example, boot with cgroup_no_v1=cpu, and then mount with
>> "mount -t cgroup -o cpu cpu /sys/fs/cgroup/cpu", then all enabled 
>> controllers will
>> be attached expect cpu.
> Okay, that explanation actually makes sense. Can you please update the
> description to include what's broken and how it's being fixed? It really
> isn't clear what the patch is trying to achieve from the current
> description.
Ok, will update the description.
>
> Thanks.
>

Re: [PATCH] dmaengine: qcom: bam_dma: Add LOCK and UNLOCK flag bit support

2021-01-14 Thread Vinod Koul

On 14-01-21, 01:20, mda...@codeaurora.org wrote:
> On 2021-01-12 15:40, Vinod Koul wrote:
> > On 12-01-21, 15:01, mda...@codeaurora.org wrote:
> > > On 2020-12-21 23:03, mda...@codeaurora.org wrote:
> > > > On 2020-12-21 14:53, Vinod Koul wrote:
> > > > > Hello,
> > > > >
> > > > > On 17-12-20, 20:07, Md Sadre Alam wrote:
> > > > > > This change will add support for LOCK & UNLOCK flag bit support
> > > > > > on CMD descriptor.
> > > > > >
> > > > > > If DMA_PREP_LOCK flag passed in prep_slave_sg then requester of this
> > > > > > transaction wanted to lock the DMA controller for this transaction 
> > > > > > so
> > > > > > BAM driver should set LOCK bit for the HW descriptor.
> > > > > >
> > > > > > If DMA_PREP_UNLOCK flag passed in prep_slave_sg then requester
> > > > > > of this
> > > > > > transaction wanted to unlock the DMA controller.so BAM driver
> > > > > > should set
> > > > > > UNLOCK bit for the HW descriptor.
> > > > >
> > > > > Can you explain why would we need to first lock and then unlock..? How
> > > > > would this be used in real world.
> > > > >
> > > > > I have read a bit of documentation but is unclear to me. Also should
> > > > > this be exposed as an API to users, sounds like internal to driver..?
> > > > >
> > > >
> > > > IPQ5018 SoC having only one Crypto Hardware Engine. This Crypto Hardware
> > > > Engine
> > > > will be shared between A53 core & ubi32 core. There is two separate
> > > > driver dedicated
> > > > to A53 core and ubi32 core. So to use Crypto Hardware Engine
> > > > parallelly for encryption/description
> > > > we need bam locking mechanism. if one driver will submit the request
> > > > for encryption/description
> > > > to Crypto then first it has to set LOCK flag bit on command descriptor
> > > > so that other pipes will
> > > > get locked.
> > > >
> > > > The Pipe Locking/Unlocking will be only on command-descriptor. Upon
> > > > encountering a command descriptor
> > 
> > Can you explain what is a cmd descriptor?
> 
>   In BAM pipe descriptor structure there is a field called CMD (Command
> descriptor).
>   CMD allows the SW to create descriptors of type Command which does not
> generate any data transmissions
>   but configures registers in the Peripheral (write operations, and read
> registers operations ).
>   Using command descriptor enables the SW to queue new configurations
> between data transfers in advance.

What and when is the CMD descriptor used for..?

> > 
> > > > with LOCK bit set, The BAM will lock all other pipes not related to
> > > > the current pipe group, and keep
> > > > handling the current pipe only until it sees the UNLOCK set then it
> > > > will release all locked pipes.
> > > > locked pipe will not fetch new descriptors even if it got event/events
> > > > adding more descriptors for
> > > > this pipe (locked pipe).
> > > >
> > > > No need to expose as an API to user because its internal to driver, so
> > > > while preparing command descriptor
> > > > just we have to update the LOCK/UNLOCK flag.
> > 
> > So IIUC, no api right? it would be internal to driver..?
> 
>   Yes its totally internal to deriver.

So no need for this patch then, right?

-- 
~Vinod

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

2021-01-14 Thread Huang Rui

On Fri, Jan 15, 2021 at 01:35:05PM +0800, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the amdgpu tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c: In function 
> 'vangogh_get_smu_metrics_data':
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:300:10: error: 
> 'boot_cpu_data' undeclared (first use in this function); did you mean 
> 'boot_cpuid'?

Ah, vangogh is an x86 cpu, let me look at this issue.

Could you share me the config file you tested?

Thanks,
Ray

>   300 |  boot_cpu_data.x86_max_cores * sizeof(uint16_t));
>   |  ^
>   |  boot_cpuid
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c: In function 
> 'vangogh_read_sensor':
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1320:11: error: 
> 'boot_cpu_data' undeclared (first use in this function); did you mean 
> 'boot_cpuid'?
>  1320 |   *size = boot_cpu_data.x86_max_cores * sizeof(uint16_t);
>   |   ^
>   |   boot_cpuid
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c: In function 
> 'vangogh_od_edit_dpm_table':
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1460:19: error: 
> 'boot_cpu_data' undeclared (first use in this function); did you mean 
> 'boot_cpuid'?
>  1460 |   if (input[0] >= boot_cpu_data.x86_max_cores) {
>   |   ^
>   |   boot_cpuid
> 
> Caused by commits
> 
>   517cb957c43b ("drm/amd/pm: implement the processor clocks which read by 
> metric")
>   0d90d0ddd10e ("drm/amd/pm: implement processor fine grain feature for 
> vangogh (v3)")
> 
> The only thing I could do easily is to disable CONFIG_DRM_AMDGPU for today.
> 
> -- 
> Cheers,
> Stephen Rothwell

Re: [Patch v2 0/4] Add Nvidia Tegra GPC-DMA driver

2021-01-14 Thread Vinod Koul

On 14-01-21, 10:11, Jon Hunter wrote:
> 
> On 06/08/2020 08:30, Rajesh Gumasta wrote:
> > Changes in patch v2:
> > Addressed review comments in patch v1
> 
> 
> Is there any update on this series? Would be good to get this upstream.

Not sure why, this is is not in my queue, can someone please resend this
to me

Thanks
-- 
~Vinod

[PATCH] mmc: sdhci-pci-gli: Enlarge ASPM L1 entry delay of GL9763E (v2)

2021-01-14 Thread Renius Chen

GL9763E enters ASPM L1 state after a very short idle in default,
even during a burst of request. So the R/W performance of GL9763E
is low with some platforms, which support ASPM mechanism, due to
entering ASPM L1 state very frequently in R/W process. Set the L1
entry delay bits in vendor-specific register to 0x3FF to enlarge
the idle period to 260us for improving the R/W performance
of GL9763E.

Signed-off-by: Renius Chen 
---
 drivers/mmc/host/sdhci-pci-gli.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c
index c6a107d7c742..fb14f70cb9a0 100644
--- a/drivers/mmc/host/sdhci-pci-gli.c
+++ b/drivers/mmc/host/sdhci-pci-gli.c
@@ -88,6 +88,10 @@
 #define PCIE_GLI_9763E_SCR  0x8E0
 #define   GLI_9763E_SCR_AXI_REQ   BIT(9)
 
+#define PCIE_GLI_9763E_CFG2  0x8A4
+#define   GLI_9763E_CFG2_L1DLY GENMASK(28, 19)
+#define   GLI_9763E_CFG2_L1DLY_MAX 0x3FF
+
 #define PCIE_GLI_9763E_MMC_CTRL  0x960
 #define   GLI_9763E_HS400_SLOW BIT(3)
 
@@ -792,6 +796,12 @@ static void gli_set_gl9763e(struct sdhci_pci_slot *slot)
value &= ~GLI_9763E_HS400_SLOW;
pci_write_config_dword(pdev, PCIE_GLI_9763E_MMC_CTRL, value);
 
+   pci_read_config_dword(pdev, PCIE_GLI_9763E_CFG2, &value);
+   value &= ~GLI_9763E_CFG2_L1DLY;
+   /* set ASPM L1 entry delay to 260us */
+   value |= FIELD_PREP(GLI_9763E_CFG2_L1DLY, GLI_9763E_CFG2_L1DLY_MAX);
+   pci_write_config_dword(pdev, PCIE_GLI_9763E_CFG2, value);
+
pci_read_config_dword(pdev, PCIE_GLI_9763E_VHS, &value);
value &= ~GLI_9763E_VHS_REV;
value |= FIELD_PREP(GLI_9763E_VHS_REV, GLI_9763E_VHS_REV_R);
-- 
2.27.0

Re: [PATCH] mmc: sdhci-pci-gli: Enlarge ASPM L1 entry delay of GL9763E

2021-01-14 Thread Renius Chen

> Ulf Hansson  於 2021年1月14日 週四 下午8:04寫道：
>
> On Thu, 14 Jan 2021 at 07:25, 陳建宏  wrote:
> >
> > > Ulf Hansson  於 2021年1月13日 週三 下午6:53寫道：
> > >
> > > On Wed, 6 Jan 2021 at 10:27, Renius Chen  wrote:
> > > >
> > > > The R/W performance of GL9763E is low with some platforms, which
> > > > support ASPM mechanism, due to entering L1 state very frequently
> > > > in R/W process. Enlarge its ASPM L1 entry delay to improve the
> > > > R/W performance of GL9763E.
> > >
> > > What do you mean by frequently? In between a burst of request or
> > > during a burst of request?
> >
> > GL9763E enters ASPM L1 state after a very short idle in default, even
> > during a burst of request.
>
> Okay, then it certainly makes sense to extend the idle period.
>
> Would you mind extending the commit message with some of this
> information, as I think it's useful.
>
> >
> > > I am thinking that this could have an effect on energy instead, but I
> > > guess it's not always straightforward to decide what's most important.
> > >
> > > Anyway, what does it mean when you change to use 0x3FF? Are you
> > > increasing the idle period? Then for how long?
> >
> > Yes, we considered that having high performance is more important than
> > saving power during a burst of request.
> > So we increased the idle period for 260us, by setting 0x3FF to the
> > ASPM L1 entry delay bits of our vendor-specific register.
> > Anyway, GL9763E can still enter ASPM L1 state by a longer idle.
>
> Most mmc controllers that uses runtime PM autosuspend for the same
> reasons, uses and idle period time of ~50us. 260us is in the same
> ballpark, so I am fine with that, if that works for you.
>
> However, can you please add a comment in the code (and preferably also
> to the commit message) that 0x3FF means using a 260us idle period?

OK, I'll extend the commit message with some of these information and
add a comment in the code to describe that the idle period is set to
260us.

Then I'll submit a newer version: mmc: sdhci-pci-gli: Enlarge ASPM L1
entry delay of GL9763E (v2).

Thank you.

>
> [...]
>
> Kind regards
> Uffe

Re: [PATCH v3 10/21] x86/fpu/xstate: Update xstate save function to support dynamic xstate

2021-01-14 Thread Liu, Jing2




On 1/15/2021 12:59 PM, Bae, Chang Seok wrote:

On Jan 11, 2021, at 18:52, Liu, Jing2  wrote:

On 1/8/2021 2:40 AM, Bae, Chang Seok wrote:

On Jan 7, 2021, at 17:41, Liu, Jing2  wrote:

static void kvm_save_current_fpu(struct fpu *fpu)  {
+   struct fpu *src_fpu = ¤t->thread.fpu;
+
/*
 * If the target FPU state is not resident in the CPU registers, just
 * memcpy() from current, else save CPU state directly to the target.
 */
-   if (test_thread_flag(TIF_NEED_FPU_LOAD))
-   memcpy(&fpu->state, ¤t->thread.fpu.state,
+   if (test_thread_flag(TIF_NEED_FPU_LOAD)) {
+   memcpy(&fpu->state, &src_fpu->state,
   fpu_kernel_xstate_min_size);




-   else
+   } else {
+   if (fpu->state_mask != src_fpu->state_mask)
+   fpu->state_mask = src_fpu->state_mask;

Though dynamic feature is not supported in kvm now, this function still need
consider more things for fpu->state_mask.

Can you elaborate this? Which path might be affected by fpu->state_mask
without dynamic state supported in KVM?


I suggest that we can set it before if...else (for both cases) and not change 
other.

I tried a minimum change here.  The fpu->state_mask value does not impact the
memcpy(). So, why do we need to change it for both?

Sure, what I'm considering is that "mask" is the first time introduced into 
"fpu",
representing the usage, so not only set it when needed, but also make it as a
representation, in case of anywhere using it (especially between the interval
of this series and kvm series in future).

Thank you for the feedback. Sorry, I don't get any logical reason to set the
mask always here.


Sure, I'd like to see if fx_init()->memset is the case,

though maybe no hurt so far in test.

Thanks,

Jing


  Perhaps, KVM code can be updated like you mentioned when
supporting the dynamic states there.

Please let me know if I’m missing any functional issues.

Thanks,
Chang

Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing

2021-01-14 Thread Sai Prakash Ranjan


Hello Mathieu, Suzuki

On 2020-10-15 21:32, Mathieu Poirier wrote:

On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:

On production systems with ETMs enabled, it is preferred to
exclude kernel mode(NS EL1) tracing for security concerns and
support only userspace(NS EL0) tracing. So provide an option
via kconfig to exclude kernel mode tracing if it is required.
This config is disabled by default and would not affect the
current configuration which has both kernel and userspace
tracing enabled by default.



One requires root access (or be part of a special trace group) to be 
able to use
the cs_etm PMU.  With this kind of elevated access restricting tracing 
at EL1

provides little in terms of security.



Apart from the VM usecase discussed, I am told there are other
security concerns here regarding need to exclude kernel mode tracing
even for the privileged users/root. One such case being the ability
to analyze cryptographic code execution since ETMs can record all
branch instructions including timestamps in the kernel and there may
be other cases as well which I may not be aware of and hence have
added Denis and Mattias. Please let us know if you have any questions
further regarding this not being a security concern.

After this discussion, I would like to post a v2 based on Suzuki's
feedback earlier. @Suzuki, I have a common config for ETM3 and ETM4
but couldn't get much idea on how to implement it for Intel PTs, if
you have any suggestions there, please do share or we can have this
only for Coresight ETMs.

Thanks,
Sai

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

of Code Aurora Forum, hosted by The Linux Foundation

[RFC PATCH v2 12/13] vhost/vsock: support for SOCK_SEQPACKET socket.

This adds transport ops and removes ignore of non-stream type of packets.

Signed-off-by: Arseny Krasnov 
---
 drivers/vhost/vsock.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 5e78fb719602..4d60a99aed14 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -354,8 +354,7 @@ vhost_vsock_alloc_pkt(struct vhost_virtqueue *vq,
return NULL;
}
 
-   if (le16_to_cpu(pkt->hdr.type) == VIRTIO_VSOCK_TYPE_STREAM)
-   pkt->len = le32_to_cpu(pkt->hdr.len);
+   pkt->len = le32_to_cpu(pkt->hdr.len);
 
/* No payload */
if (!pkt->len)
@@ -424,6 +423,10 @@ static struct virtio_transport vhost_transport = {
.stream_is_active = virtio_transport_stream_is_active,
.stream_allow = virtio_transport_stream_allow,
 
+   .seqpacket_seq_send_len   = 
virtio_transport_seqpacket_seq_send_len,
+   .seqpacket_seq_get_len= 
virtio_transport_seqpacket_seq_get_len,
+   .seqpacket_dequeue= virtio_transport_seqpacket_dequeue,
+
.notify_poll_in   = virtio_transport_notify_poll_in,
.notify_poll_out  = virtio_transport_notify_poll_out,
.notify_recv_init = virtio_transport_notify_recv_init,
-- 
2.25.1

[RFC PATCH v2 13/13] vsock_test: add SOCK_SEQPACKET tests.

This adds two tests of SOCK_SEQPACKET socket: both transfer data and then
test MSG_EOR and MSG_TRUNC flags. Cases for connect(), bind(),  etc. are
not tested, because it is same as for stream socket.

Signed-off-by: Arseny Krasnov 
---
 tools/testing/vsock/util.c   |  32 ++--
 tools/testing/vsock/util.h   |   3 +
 tools/testing/vsock/vsock_test.c | 126 +++
 3 files changed, 156 insertions(+), 5 deletions(-)

diff --git a/tools/testing/vsock/util.c b/tools/testing/vsock/util.c
index 93cbd6f603f9..2acbb7703c6a 100644
--- a/tools/testing/vsock/util.c
+++ b/tools/testing/vsock/util.c
@@ -84,7 +84,7 @@ void vsock_wait_remote_close(int fd)
 }
 
 /* Connect to  and return the file descriptor. */
-int vsock_stream_connect(unsigned int cid, unsigned int port)
+static int vsock_connect(unsigned int cid, unsigned int port, int type)
 {
union {
struct sockaddr sa;
@@ -101,7 +101,7 @@ int vsock_stream_connect(unsigned int cid, unsigned int 
port)
 
control_expectln("LISTENING");
 
-   fd = socket(AF_VSOCK, SOCK_STREAM, 0);
+   fd = socket(AF_VSOCK, type, 0);
 
timeout_begin(TIMEOUT);
do {
@@ -120,11 +120,21 @@ int vsock_stream_connect(unsigned int cid, unsigned int 
port)
return fd;
 }
 
+int vsock_stream_connect(unsigned int cid, unsigned int port)
+{
+   return vsock_connect(cid, port, SOCK_STREAM);
+}
+
+int vsock_seqpacket_connect(unsigned int cid, unsigned int port)
+{
+   return vsock_connect(cid, port, SOCK_SEQPACKET);
+}
+
 /* Listen on  and return the first incoming connection.  The remote
  * address is stored to clientaddrp.  clientaddrp may be NULL.
  */
-int vsock_stream_accept(unsigned int cid, unsigned int port,
-   struct sockaddr_vm *clientaddrp)
+static int vsock_accept(unsigned int cid, unsigned int port,
+   struct sockaddr_vm *clientaddrp, int type)
 {
union {
struct sockaddr sa;
@@ -145,7 +155,7 @@ int vsock_stream_accept(unsigned int cid, unsigned int port,
int client_fd;
int old_errno;
 
-   fd = socket(AF_VSOCK, SOCK_STREAM, 0);
+   fd = socket(AF_VSOCK, type, 0);
 
if (bind(fd, &addr.sa, sizeof(addr.svm)) < 0) {
perror("bind");
@@ -189,6 +199,18 @@ int vsock_stream_accept(unsigned int cid, unsigned int 
port,
return client_fd;
 }
 
+int vsock_stream_accept(unsigned int cid, unsigned int port,
+   struct sockaddr_vm *clientaddrp)
+{
+   return vsock_accept(cid, port, clientaddrp, SOCK_STREAM);
+}
+
+int vsock_seqpacket_accept(unsigned int cid, unsigned int port,
+  struct sockaddr_vm *clientaddrp)
+{
+   return vsock_accept(cid, port, clientaddrp, SOCK_SEQPACKET);
+}
+
 /* Transmit one byte and check the return value.
  *
  * expected_ret:
diff --git a/tools/testing/vsock/util.h b/tools/testing/vsock/util.h
index e53dd09d26d9..a3375ad2fb7f 100644
--- a/tools/testing/vsock/util.h
+++ b/tools/testing/vsock/util.h
@@ -36,8 +36,11 @@ struct test_case {
 void init_signals(void);
 unsigned int parse_cid(const char *str);
 int vsock_stream_connect(unsigned int cid, unsigned int port);
+int vsock_seqpacket_connect(unsigned int cid, unsigned int port);
 int vsock_stream_accept(unsigned int cid, unsigned int port,
struct sockaddr_vm *clientaddrp);
+int vsock_seqpacket_accept(unsigned int cid, unsigned int port,
+  struct sockaddr_vm *clientaddrp);
 void vsock_wait_remote_close(int fd);
 void send_byte(int fd, int expected_ret, int flags);
 void recv_byte(int fd, int expected_ret, int flags);
diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
index 5a4fb80fa832..db6cc49fa5e4 100644
--- a/tools/testing/vsock/vsock_test.c
+++ b/tools/testing/vsock/vsock_test.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "timeout.h"
 #include "control.h"
@@ -279,6 +281,120 @@ static void test_stream_msg_peek_server(const struct 
test_opts *opts)
close(fd);
 }
 
+#define MESSAGES_CNT 7
+#define MESSAGE_EOR_IDX (MESSAGES_CNT / 2)
+static void test_seqpacket_msg_send_client(const struct test_opts *opts)
+{
+   int fd;
+
+   fd = vsock_seqpacket_connect(opts->peer_cid, 1234);
+   if (fd < 0) {
+   perror("connect");
+   exit(EXIT_FAILURE);
+   }
+
+   /* Send several messages, one with MSG_EOR flag */
+   for (int i = 0; i < MESSAGES_CNT; i++)
+   send_byte(fd, 1, (i != MESSAGE_EOR_IDX) ? 0 : MSG_EOR);
+
+   control_writeln("SENDDONE");
+   close(fd);
+}
+
+static void test_seqpacket_msg_send_server(const struct test_opts *opts)
+{
+   int fd;
+   char buf[16];
+   struct msghdr msg = {0};
+   struct iovec iov = {0};
+
+   fd = vsock_seqpacket_accept(VMADDR_CID_ANY, 1234, NULL);
+   if (fd < 0) {
+   perror("accept");
+

Re: [PATCH] of: unittest: Statically apply overlays using fdtoverlay

2021-01-14 Thread Viresh Kumar

+David,

On 14-01-21, 09:01, Rob Herring wrote:
> On Wed, Jan 13, 2021 at 11:03 PM Viresh Kumar  wrote:
> >
> > On 11-01-21, 09:46, Rob Herring wrote:
> > > On Fri, Jan 8, 2021 at 2:41 AM Viresh Kumar  
> > > wrote:
> > > >
> > > > Now that fdtoverlay is part of the kernel build, start using it to test
> > > > the unitest overlays we have by applying them statically.
> > >
> > > Nice idea.
> > >
> > > > The file overlay_base.dtb have symbols of its own and we need to apply
> > > > overlay.dtb to overlay_base.dtb alone first to make it work, which gives
> > > > us intermediate-overlay.dtb file.
> > >
> > > Okay? If restructuring things helps we should do that. Frank?
> >
> > Frank, do we want to do something about it ? Maybe make overlay_base.dts an 
> > dtsi
> > and include it from testcases.dts like the other ones ?
> 
> No, because overlay_base.dts is an overlay dt.

What property of a file makes it an overlay ? Just the presence of /plugin/; ?

David, we are talking about the overlay base[1] file here. The fdtoverlay tool
fails to apply it to testcases.dts file (in the same directory) because none of
its nodes have the __overlay__ label and the dtc routine overlay_merge() [2]
skips them intentionally.

> I think we need an
> empty, minimal base.dtb to apply overlay_base.dtbo to.

One way out is adding an (almost-empty) testcase-data-2 in testcases.dtb, that
will make it work.

> And then fdtoverlay needs a fix to apply overlays to the root node?

It isn't just root node I think, but any node for which the __overlay__ label
isn't there.

So this can make it all work if everyone is fine with it:

diff --git a/drivers/of/unittest-data/overlay_base.dts 
b/drivers/of/unittest-data/overlay_base.dts
index 99ab9d12d00b..59172c4c9e5a 100644
--- a/drivers/of/unittest-data/overlay_base.dts
+++ b/drivers/of/unittest-data/overlay_base.dts
@@ -11,8 +11,7 @@
  * dtc will create nodes "/__symbols__" and "/__local_fixups__".
  */
 
-/ {
-   testcase-data-2 {
+   &overlay_base {
#address-cells = <1>;
#size-cells = <1>;
 
@@ -89,5 +88,3 @@ retail_1: vending@5 {
};
 
};
-};
-
diff --git a/drivers/of/unittest-data/testcases.dts 
b/drivers/of/unittest-data/testcases.dts
index a85b5e1c381a..539dc7d9eddc 100644
--- a/drivers/of/unittest-data/testcases.dts
+++ b/drivers/of/unittest-data/testcases.dts
@@ -11,6 +11,11 @@ node-remove {
};
};
};
+
+   overlay_base: testcase-data-2 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };

-8<-

And then we can do this to the Makefile over my changes.

-8<-

diff --git a/drivers/of/unittest-data/Makefile 
b/drivers/of/unittest-data/Makefile
index 9f3eb30b78f1..8cc23311b778 100644
--- a/drivers/of/unittest-data/Makefile
+++ b/drivers/of/unittest-data/Makefile
@@ -41,7 +41,6 @@ DTC_FLAGS_testcases += -Wno-interrupts_property
 
 # Apply all overlays (except overlay_bad_* as they are not supposed to apply 
and
 # fail build) statically with fdtoverlay
-intermediate-overlay   := overlay.dtb
 master := overlay_0.dtb overlay_1.dtb overlay_2.dtb \
   overlay_3.dtb overlay_4.dtb overlay_5.dtb \
   overlay_6.dtb overlay_7.dtb overlay_8.dtb \
@@ -50,15 +49,12 @@ master  := overlay_0.dtb overlay_1.dtb 
overlay_2.dtb \
   overlay_gpio_01.dtb overlay_gpio_02a.dtb \
   overlay_gpio_02b.dtb overlay_gpio_03.dtb \
   overlay_gpio_04a.dtb overlay_gpio_04b.dtb \
-  intermediate-overlay.dtb
+  overlay_base.dtb overlay.dtb
 
 quiet_cmd_fdtoverlay = fdtoverlay $@
   cmd_fdtoverlay = $(objtree)/scripts/dtc/fdtoverlay -o $@ -i $^
 
-$(obj)/intermediate-overlay.dtb: $(obj)/overlay_base.dtb $(addprefix 
$(obj)/,$(intermediate-overlay))
-   $(call if_changed,fdtoverlay)
-
 $(obj)/master.dtb: $(obj)/testcases.dtb $(addprefix $(obj)/,$(master))
$(call if_changed,fdtoverlay)
 
-always-$(CONFIG_OF_OVERLAY) += intermediate-overlay.dtb master.dtb
+always-$(CONFIG_OF_OVERLAY) += master.dtb

-- 
viresh

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/unittest-data/overlay_base.dts
[2] 
https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/libfdt/fdt_overlay.c#n628

Re: [PATCH v2] initramfs: Provide a common initrd reserve function




On 2021/1/15 10:33, Palmer Dabbelt wrote:
On Wed, 13 Jan 2021 18:33:58 PST (-0800), wangkefeng.w...@huawei.com 
wrote:

The ARM and riscv have same logic to check and reserve
the memory of initrd, let's provide a common function to
reduce duplicated code.

Add __LINUX_INITRD_H define in initrd.h to prevent build error
(found by kernel test robot ) from the multiple
inclusion of same header file multiple time.


This is doing a bunch of different things:

* Fixing the lack of a preprocessor guard in initrd.h
* Adding some generic code.
* Converting two architectures over to that generic code.

It needs to be split into four patches.  I'm happy to take them via 
the RISC-V tree (with an Ack from for the arch/arm/ stuff), but not 
all together.


It looks like csky copied this as well, they at least have exactly the 
same message.


Send v3， according to the suggestion，thanks.

[RFC PATCH v2 11/13] virtio/vsock: rest of SOCK_SEQPACKET support

This adds rest of logic for SEQPACKET:
1) Shared functions for packet sending now set valid type of packet
   according socket type.
2) SEQPACKET specific function like SEQ_BEGIN send and data dequeue.
3) Ops for virtio transport.
4) TAP support for SEQPACKET is not so easy if it is necessary to send
   whole record to TAP interface. This could be done by allocating
   new packet when whole record is received, data of record must be
   copied to TAP packet.

Signed-off-by: Arseny Krasnov 
---
 include/linux/virtio_vsock.h|  7 
 net/vmw_vsock/virtio_transport.c|  4 ++
 net/vmw_vsock/virtio_transport_common.c | 54 ++---
 3 files changed, 59 insertions(+), 6 deletions(-)

diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
index af8705ea8b95..ad9783df97c9 100644
--- a/include/linux/virtio_vsock.h
+++ b/include/linux/virtio_vsock.h
@@ -84,7 +84,14 @@ virtio_transport_dgram_dequeue(struct vsock_sock *vsk,
   struct msghdr *msg,
   size_t len, int flags);
 
+bool virtio_transport_seqpacket_seq_send_len(struct vsock_sock *vsk, size_t 
len);
 size_t virtio_transport_seqpacket_seq_get_len(struct vsock_sock *vsk);
+ssize_t
+virtio_transport_seqpacket_dequeue(struct vsock_sock *vsk,
+  struct msghdr *msg,
+  size_t len,
+  int type);
+
 s64 virtio_transport_stream_has_data(struct vsock_sock *vsk);
 s64 virtio_transport_stream_has_space(struct vsock_sock *vsk);
 
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 2700a63ab095..5a7ab1befee8 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -469,6 +469,10 @@ static struct virtio_transport virtio_transport = {
.stream_is_active = virtio_transport_stream_is_active,
.stream_allow = virtio_transport_stream_allow,
 
+   .seqpacket_seq_send_len   = 
virtio_transport_seqpacket_seq_send_len,
+   .seqpacket_seq_get_len= 
virtio_transport_seqpacket_seq_get_len,
+   .seqpacket_dequeue= virtio_transport_seqpacket_dequeue,
+
.notify_poll_in   = virtio_transport_notify_poll_in,
.notify_poll_out  = virtio_transport_notify_poll_out,
.notify_recv_init = virtio_transport_notify_recv_init,
diff --git a/net/vmw_vsock/virtio_transport_common.c 
b/net/vmw_vsock/virtio_transport_common.c
index c3e07eb1c666..5fdf1adfdaab 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -139,6 +139,7 @@ static struct sk_buff *virtio_transport_build_skb(void 
*opaque)
break;
case VIRTIO_VSOCK_OP_CREDIT_UPDATE:
case VIRTIO_VSOCK_OP_CREDIT_REQUEST:
+   case VIRTIO_VSOCK_OP_SEQ_BEGIN:
hdr->op = cpu_to_le16(AF_VSOCK_OP_CONTROL);
break;
default:
@@ -157,6 +158,10 @@ static struct sk_buff *virtio_transport_build_skb(void 
*opaque)
 
 void virtio_transport_deliver_tap_pkt(struct virtio_vsock_pkt *pkt)
 {
+   /* TODO: implement tap support for SOCK_SEQPACKET. */
+   if (le32_to_cpu(pkt->hdr.type) == VIRTIO_VSOCK_TYPE_SEQPACKET)
+   return;
+
if (pkt->tap_delivered)
return;
 
@@ -405,6 +410,19 @@ static u16 virtio_transport_get_type(struct sock *sk)
return VIRTIO_VSOCK_TYPE_SEQPACKET;
 }
 
+bool virtio_transport_seqpacket_seq_send_len(struct vsock_sock *vsk, size_t 
len)
+{
+   struct virtio_vsock_pkt_info info = {
+   .type = VIRTIO_VSOCK_TYPE_SEQPACKET,
+   .op = VIRTIO_VSOCK_OP_SEQ_BEGIN,
+   .vsk = vsk,
+   .flags = len
+   };
+
+   return virtio_transport_send_pkt_info(vsk, &info);
+}
+EXPORT_SYMBOL_GPL(virtio_transport_seqpacket_seq_send_len);
+
 static inline void virtio_transport_del_n_free_pkt(struct virtio_vsock_pkt 
*pkt)
 {
list_del(&pkt->list);
@@ -576,6 +594,18 @@ virtio_transport_stream_dequeue(struct vsock_sock *vsk,
 }
 EXPORT_SYMBOL_GPL(virtio_transport_stream_dequeue);
 
+ssize_t
+virtio_transport_seqpacket_dequeue(struct vsock_sock *vsk,
+  struct msghdr *msg,
+  size_t len, int flags)
+{
+   if (flags & MSG_PEEK)
+   return -EOPNOTSUPP;
+
+   return virtio_transport_seqpacket_do_dequeue(vsk, msg, len);
+}
+EXPORT_SYMBOL_GPL(virtio_transport_seqpacket_dequeue);
+
 int
 virtio_transport_dgram_dequeue(struct vsock_sock *vsk,
   struct msghdr *msg,
@@ -659,13 +689,15 @@ EXPORT_SYMBOL_GPL(virtio_transport_do_socket_init);
 void virtio_transport_notify_buffer_size(struct vsock_sock *vsk, u64 *val)
 {
struct virtio_vsock_sock *vvs = vsk->trans;
+   int type;
 
if (*val >

[RFC PATCH v2 10/13] virtio/vsock: update receive logic

This modifies current receive logic for SEQPACKET support:
1) Add 'SEQ_BEGIN' packet to socket's rx queue.
2) Add 'RW' packet to rx queue, but without merging inside buffer of last
   packet in queue.
3) Perform check for packet type and socket type on receive(if mismatch,
   then reset connection).

Signed-off-by: Arseny Krasnov 
---
 net/vmw_vsock/virtio_transport_common.c | 79 ++---
 1 file changed, 58 insertions(+), 21 deletions(-)

diff --git a/net/vmw_vsock/virtio_transport_common.c 
b/net/vmw_vsock/virtio_transport_common.c
index fe1272e74517..c3e07eb1c666 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -397,6 +397,14 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk,
return err;
 }
 
+static u16 virtio_transport_get_type(struct sock *sk)
+{
+   if (sk->sk_type == SOCK_STREAM)
+   return VIRTIO_VSOCK_TYPE_STREAM;
+   else
+   return VIRTIO_VSOCK_TYPE_SEQPACKET;
+}
+
 static inline void virtio_transport_del_n_free_pkt(struct virtio_vsock_pkt 
*pkt)
 {
list_del(&pkt->list);
@@ -1050,39 +1058,49 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk,
  struct virtio_vsock_pkt *pkt)
 {
struct virtio_vsock_sock *vvs = vsk->trans;
-   bool can_enqueue, free_pkt = false;
+   bool free_pkt = false;
 
pkt->len = le32_to_cpu(pkt->hdr.len);
pkt->off = 0;
 
spin_lock_bh(&vvs->rx_lock);
 
-   can_enqueue = virtio_transport_inc_rx_pkt(vvs, pkt);
-   if (!can_enqueue) {
+   if (!virtio_transport_inc_rx_pkt(vvs, pkt)) {
free_pkt = true;
goto out;
}
 
-   /* Try to copy small packets into the buffer of last packet queued,
-* to avoid wasting memory queueing the entire buffer with a small
-* payload.
-*/
-   if (pkt->len <= GOOD_COPY_LEN && !list_empty(&vvs->rx_queue)) {
-   struct virtio_vsock_pkt *last_pkt;
+   switch (le32_to_cpu(pkt->hdr.type)) {
+   case VIRTIO_VSOCK_TYPE_STREAM: {
+   /* Try to copy small packets into the buffer of last packet 
queued,
+* to avoid wasting memory queueing the entire buffer with a 
small
+* payload.
+*/
+   if (pkt->len <= GOOD_COPY_LEN && !list_empty(&vvs->rx_queue)) {
+   struct virtio_vsock_pkt *last_pkt;
 
-   last_pkt = list_last_entry(&vvs->rx_queue,
-  struct virtio_vsock_pkt, list);
+   last_pkt = list_last_entry(&vvs->rx_queue,
+  struct virtio_vsock_pkt, 
list);
 
-   /* If there is space in the last packet queued, we copy the
-* new packet in its buffer.
-*/
-   if (pkt->len <= last_pkt->buf_len - last_pkt->len) {
-   memcpy(last_pkt->buf + last_pkt->len, pkt->buf,
-  pkt->len);
-   last_pkt->len += pkt->len;
-   free_pkt = true;
-   goto out;
+   /* If there is space in the last packet queued, we copy 
the
+* new packet in its buffer.
+*/
+   if (pkt->len <= last_pkt->buf_len - last_pkt->len) {
+   memcpy(last_pkt->buf + last_pkt->len, pkt->buf,
+  pkt->len);
+   last_pkt->len += pkt->len;
+   free_pkt = true;
+   goto out;
+   }
}
+
+   break;
+   }
+   case VIRTIO_VSOCK_TYPE_SEQPACKET: {
+   break;
+   }
+   default:
+   goto out;
}
 
list_add_tail(&pkt->list, &vvs->rx_queue);
@@ -1101,6 +1119,14 @@ virtio_transport_recv_connected(struct sock *sk,
int err = 0;
 
switch (le16_to_cpu(pkt->hdr.op)) {
+   case VIRTIO_VSOCK_OP_SEQ_BEGIN: {
+   struct virtio_vsock_sock *vvs = vsk->trans;
+
+   spin_lock_bh(&vvs->rx_lock);
+   list_add_tail(&pkt->list, &vvs->rx_queue);
+   spin_unlock_bh(&vvs->rx_lock);
+   return err;
+   }
case VIRTIO_VSOCK_OP_RW:
virtio_transport_recv_enqueue(vsk, pkt);
sk->sk_data_ready(sk);
@@ -1247,6 +1273,12 @@ virtio_transport_recv_listen(struct sock *sk, struct 
virtio_vsock_pkt *pkt,
return 0;
 }
 
+static bool virtio_transport_valid_type(u16 type)
+{
+   return (type == VIRTIO_VSOCK_TYPE_STREAM) ||
+  (type == VIRTIO_VSOCK_TYPE_SEQPACKET);
+}
+
 /* We are under the virtio-vsock's vsock->rx_lock or vhost-vsock's vq->mutex
  * lock.
  */
@@ -1272,7 +1304,7 @@ void virtio_transport_recv_pkt(struct vir

[RFC PATCH v2 08/13] virtio/vsock: dequeue callback for SOCK_SEQPACKET.

This adds transport callback and it's logic for SEQPACKET dequeue.
Callback fetches RW packets from rx queue of socket until whole record
is copied(if user's buffer is full, user is not woken up). This is done
to not stall sender, because if we wake up user and it leaves syscall,
nobody will send credit update for rest of record, and sender will wait
for next enter of read syscall at receiver's side. So if user buffer is
full, we just send credit update and drop data. If during copy SEQ_BEGIN
was found(and not all data was copied), copying is restarted by reset
user's iov iterator(previous unfinished data is dropped).

Signed-off-by: Arseny Krasnov 
---
 include/linux/virtio_vsock.h|   4 +
 include/uapi/linux/virtio_vsock.h   |   9 ++
 net/vmw_vsock/virtio_transport_common.c | 128 
 3 files changed, 141 insertions(+)

diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
index dc636b727179..7f0ef5204e33 100644
--- a/include/linux/virtio_vsock.h
+++ b/include/linux/virtio_vsock.h
@@ -36,6 +36,10 @@ struct virtio_vsock_sock {
u32 rx_bytes;
u32 buf_alloc;
struct list_head rx_queue;
+
+   /* For SOCK_SEQPACKET */
+   u32 user_read_seq_len;
+   u32 user_read_copied;
 };
 
 struct virtio_vsock_pkt {
diff --git a/include/uapi/linux/virtio_vsock.h 
b/include/uapi/linux/virtio_vsock.h
index 1d57ed3d84d2..058908bc19fc 100644
--- a/include/uapi/linux/virtio_vsock.h
+++ b/include/uapi/linux/virtio_vsock.h
@@ -65,6 +65,7 @@ struct virtio_vsock_hdr {
 
 enum virtio_vsock_type {
VIRTIO_VSOCK_TYPE_STREAM = 1,
+   VIRTIO_VSOCK_TYPE_SEQPACKET = 2,
 };
 
 enum virtio_vsock_op {
@@ -83,6 +84,9 @@ enum virtio_vsock_op {
VIRTIO_VSOCK_OP_CREDIT_UPDATE = 6,
/* Request the peer to send the credit info to us */
VIRTIO_VSOCK_OP_CREDIT_REQUEST = 7,
+
+   /* Record begin for SOCK_SEQPACKET */
+   VIRTIO_VSOCK_OP_SEQ_BEGIN = 8,
 };
 
 /* VIRTIO_VSOCK_OP_SHUTDOWN flags values */
@@ -91,4 +95,9 @@ enum virtio_vsock_shutdown {
VIRTIO_VSOCK_SHUTDOWN_SEND = 2,
 };
 
+/* VIRTIO_VSOCK_OP_RW flags values for SOCK_SEQPACKET type */
+enum virtio_vsock_rw_seqpacket {
+   VIRTIO_VSOCK_RW_EOR = 1,
+};
+
 #endif /* _UAPI_LINUX_VIRTIO_VSOCK_H */
diff --git a/net/vmw_vsock/virtio_transport_common.c 
b/net/vmw_vsock/virtio_transport_common.c
index 5956939eebb7..4328f653a477 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -397,6 +397,132 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk,
return err;
 }
 
+static inline void virtio_transport_del_n_free_pkt(struct virtio_vsock_pkt 
*pkt)
+{
+   list_del(&pkt->list);
+   virtio_transport_free_pkt(pkt);
+}
+
+static size_t virtio_transport_drop_until_seq_begin(struct virtio_vsock_sock 
*vvs)
+{
+   struct virtio_vsock_pkt *pkt, *n;
+   size_t bytes_dropped = 0;
+
+   list_for_each_entry_safe(pkt, n, &vvs->rx_queue, list) {
+   if (le16_to_cpu(pkt->hdr.op) == VIRTIO_VSOCK_OP_SEQ_BEGIN)
+   break;
+
+   bytes_dropped += le32_to_cpu(pkt->hdr.len);
+   virtio_transport_dec_rx_pkt(vvs, pkt);
+   virtio_transport_del_n_free_pkt(pkt);
+   }
+
+   return bytes_dropped;
+}
+
+static ssize_t virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk,
+struct msghdr *msg,
+size_t user_buf_len)
+{
+   struct virtio_vsock_sock *vvs = vsk->trans;
+   struct virtio_vsock_pkt *pkt;
+   size_t bytes_handled = 0;
+   int err = 0;
+
+   spin_lock_bh(&vvs->rx_lock);
+
+   if (user_buf_len == 0) {
+   /* User's buffer is full, we processing rest of
+* record and drop it. If 'SEQ_BEGIN' is found
+* while iterating, user will be woken up,
+* because record is already copied, and we
+* don't care about absent of some tail RW packets
+* of it. Return number of bytes(rest of record),
+* but ignore credit update for such absent bytes.
+*/
+   bytes_handled = virtio_transport_drop_until_seq_begin(vvs);
+   vvs->user_read_copied += bytes_handled;
+
+   if (!list_empty(&vvs->rx_queue) &&
+   vvs->user_read_copied < vvs->user_read_seq_len) {
+   /* 'SEQ_BEGIN' found, but record isn't complete.
+* Set number of copied bytes to fit record size
+* and force counters to finish receiving.
+*/
+   bytes_handled += (vvs->user_read_seq_len - 
vvs->user_read_copied);
+   vvs->user_read_copied = vvs->user_read_seq_len;
+   }
+   }
+
+   /* Now start copying. */
+   while (vvs->use

[RFC PATCH v2 09/13] virtio/vsock: implement fetch of record length

This adds transport callback which tries to fetch record begin marker from
socket's rx queue. It is called from af_vsock.c before reading data
packets of record.

Signed-off-by: Arseny Krasnov 
---
 include/linux/virtio_vsock.h|  1 +
 net/vmw_vsock/virtio_transport_common.c | 33 +
 2 files changed, 34 insertions(+)

diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
index 7f0ef5204e33..af8705ea8b95 100644
--- a/include/linux/virtio_vsock.h
+++ b/include/linux/virtio_vsock.h
@@ -84,6 +84,7 @@ virtio_transport_dgram_dequeue(struct vsock_sock *vsk,
   struct msghdr *msg,
   size_t len, int flags);
 
+size_t virtio_transport_seqpacket_seq_get_len(struct vsock_sock *vsk);
 s64 virtio_transport_stream_has_data(struct vsock_sock *vsk);
 s64 virtio_transport_stream_has_space(struct vsock_sock *vsk);
 
diff --git a/net/vmw_vsock/virtio_transport_common.c 
b/net/vmw_vsock/virtio_transport_common.c
index 4328f653a477..fe1272e74517 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -420,6 +420,39 @@ static size_t virtio_transport_drop_until_seq_begin(struct 
virtio_vsock_sock *vv
return bytes_dropped;
 }
 
+size_t virtio_transport_seqpacket_seq_get_len(struct vsock_sock *vsk)
+{
+   struct virtio_vsock_sock *vvs = vsk->trans;
+   struct virtio_vsock_pkt *pkt;
+   size_t bytes_dropped;
+
+   spin_lock_bh(&vvs->rx_lock);
+
+   /* Fetch all orphaned 'RW', packets, and
+* send credit update.
+*/
+   bytes_dropped = virtio_transport_drop_until_seq_begin(vvs);
+
+   if (list_empty(&vvs->rx_queue))
+   goto out;
+
+   pkt = list_first_entry(&vvs->rx_queue, struct virtio_vsock_pkt, list);
+
+   vvs->user_read_copied = 0;
+   vvs->user_read_seq_len = le32_to_cpu(pkt->hdr.flags);
+   virtio_transport_del_n_free_pkt(pkt);
+out:
+   spin_unlock_bh(&vvs->rx_lock);
+
+   if (bytes_dropped)
+   virtio_transport_send_credit_update(vsk,
+   VIRTIO_VSOCK_TYPE_SEQPACKET,
+   NULL);
+
+   return vvs->user_read_seq_len;
+}
+EXPORT_SYMBOL_GPL(virtio_transport_seqpacket_seq_get_len);
+
 static ssize_t virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk,
 struct msghdr *msg,
 size_t user_buf_len)
-- 
2.25.1

[RFC PATCH v2 07/13] af_vsock: update comments for stream sockets.

This replaces 'stream' to 'connect oriented' in comments as SEQPACKET is
also connect oriented.

Signed-off-by: Arseny Krasnov 
---
 net/vmw_vsock/af_vsock.c | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index d0ef066e9352..97dcaa410ee4 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -415,8 +415,8 @@ static void vsock_deassign_transport(struct vsock_sock *vsk)
 
 /* Assign a transport to a socket and call the .init transport callback.
  *
- * Note: for stream socket this must be called when vsk->remote_addr is set
- * (e.g. during the connect() or when a connection request on a listener
+ * Note: for connect oriented socket this must be called when vsk->remote_addr
+ * is set (e.g. during the connect() or when a connection request on a listener
  * socket is received).
  * The vsk->remote_addr is used to decide which transport to use:
  *  - remote CID == VMADDR_CID_LOCAL or g2h->local_cid or VMADDR_CID_HOST if
@@ -477,10 +477,10 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct 
vsock_sock *psk)
return 0;
 
/* transport->release() must be called with sock lock acquired.
-* This path can only be taken during vsock_stream_connect(),
-* where we have already held the sock lock.
-* In the other cases, this function is called on a new socket
-* which is not assigned to any transport.
+* This path can only be taken during vsock_connect(), where we
+* have already held the sock lock. In the other cases, this
+* function is called on a new socket which is not assigned to
+* any transport.
 */
vsk->transport->release(vsk);
vsock_deassign_transport(vsk);
@@ -657,9 +657,10 @@ static int __vsock_bind_connectible(struct vsock_sock *vsk,
 
vsock_addr_init(&vsk->local_addr, new_addr.svm_cid, new_addr.svm_port);
 
-   /* Remove stream sockets from the unbound list and add them to the hash
-* table for easy lookup by its address.  The unbound list is simply an
-* extra entry at the end of the hash table, a trick used by AF_UNIX.
+   /* Remove connect oriented sockets from the unbound list and add them
+* to the hash table for easy lookup by its address.  The unbound list
+* is simply an extra entry at the end of the hash table, a trick used
+* by AF_UNIX.
 */
__vsock_remove_bound(vsk);
__vsock_insert_bound(vsock_bound_sockets(&vsk->local_addr), vsk);
@@ -950,10 +951,10 @@ static int vsock_shutdown(struct socket *sock, int mode)
if ((mode & ~SHUTDOWN_MASK) || !mode)
return -EINVAL;
 
-   /* If this is a STREAM socket and it is not connected then bail out
-* immediately.  If it is a DGRAM socket then we must first kick the
-* socket so that it wakes up from any sleeping calls, for example
-* recv(), and then afterwards return the error.
+   /* If this is a connect oriented socket and it is not connected then
+* bail out immediately.  If it is a DGRAM socket then we must first
+* kick the socket so that it wakes up from any sleeping calls, for
+* example recv(), and then afterwards return the error.
 */
 
sk = sock->sk;
@@ -1758,7 +1759,9 @@ static int vsock_connectible_sendmsg(struct socket *sock, 
struct msghdr *msg,
 
lock_sock(sk);
 
-   /* Callers should not provide a destination with stream sockets. */
+   /* Callers should not provide a destination with connect oriented
+* sockets.
+*/
if (msg->msg_namelen) {
err = sk->sk_state == TCP_ESTABLISHED ? -EISCONN : -EOPNOTSUPP;
goto out;
-- 
2.25.1

[RFC PATCH v2 06/13] af_vsock: general support of SOCK_SEQPACKET type.

This adds socket operations for SOCK_SEQPACKET and adds this type of
socket for conditions where SOCK_STREAM is involved because both type of
sockets are connect oriented.

Signed-off-by: Arseny Krasnov 
---
 net/vmw_vsock/af_vsock.c | 108 +--
 1 file changed, 92 insertions(+), 16 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 4a7cdf7756c0..d0ef066e9352 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -452,6 +452,7 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct 
vsock_sock *psk)
new_transport = transport_dgram;
break;
case SOCK_STREAM:
+   case SOCK_SEQPACKET:
if (vsock_use_local_transport(remote_cid))
new_transport = transport_local;
else if (remote_cid <= VMADDR_CID_HOST || !transport_h2g ||
@@ -459,6 +460,13 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct 
vsock_sock *psk)
new_transport = transport_g2h;
else
new_transport = transport_h2g;
+
+   if (sk->sk_type == SOCK_SEQPACKET) {
+   if (!new_transport->seqpacket_seq_send_len ||
+   !new_transport->seqpacket_seq_get_len ||
+   !new_transport->seqpacket_dequeue)
+   return -ENODEV;
+   }
break;
default:
return -ESOCKTNOSUPPORT;
@@ -604,8 +612,8 @@ static void vsock_pending_work(struct work_struct *work)
 
 / SOCKET OPERATIONS /
 
-static int __vsock_bind_stream(struct vsock_sock *vsk,
-  struct sockaddr_vm *addr)
+static int __vsock_bind_connectible(struct vsock_sock *vsk,
+   struct sockaddr_vm *addr)
 {
static u32 port;
struct sockaddr_vm new_addr;
@@ -684,8 +692,9 @@ static int __vsock_bind(struct sock *sk, struct sockaddr_vm 
*addr)
 
switch (sk->sk_socket->type) {
case SOCK_STREAM:
+   case SOCK_SEQPACKET:
spin_lock_bh(&vsock_table_lock);
-   retval = __vsock_bind_stream(vsk, addr);
+   retval = __vsock_bind_connectible(vsk, addr);
spin_unlock_bh(&vsock_table_lock);
break;
 
@@ -767,6 +776,11 @@ static struct sock *__vsock_create(struct net *net,
return sk;
 }
 
+static bool sock_type_connectible(u16 type)
+{
+   return (type == SOCK_STREAM || type == SOCK_SEQPACKET);
+}
+
 static void __vsock_release(struct sock *sk, int level)
 {
if (sk) {
@@ -785,7 +799,7 @@ static void __vsock_release(struct sock *sk, int level)
 
if (vsk->transport)
vsk->transport->release(vsk);
-   else if (sk->sk_type == SOCK_STREAM)
+   else if (sock_type_connectible(sk->sk_type))
vsock_remove_sock(vsk);
 
sock_orphan(sk);
@@ -945,7 +959,7 @@ static int vsock_shutdown(struct socket *sock, int mode)
sk = sock->sk;
if (sock->state == SS_UNCONNECTED) {
err = -ENOTCONN;
-   if (sk->sk_type == SOCK_STREAM)
+   if (sock_type_connectible(sk->sk_type))
return err;
} else {
sock->state = SS_DISCONNECTING;
@@ -960,7 +974,7 @@ static int vsock_shutdown(struct socket *sock, int mode)
sk->sk_state_change(sk);
release_sock(sk);
 
-   if (sk->sk_type == SOCK_STREAM) {
+   if (sock_type_connectible(sk->sk_type)) {
sock_reset_flag(sk, SOCK_DONE);
vsock_send_shutdown(sk, mode);
}
@@ -1013,7 +1027,7 @@ static __poll_t vsock_poll(struct file *file, struct 
socket *sock,
if (!(sk->sk_shutdown & SEND_SHUTDOWN))
mask |= EPOLLOUT | EPOLLWRNORM | EPOLLWRBAND;
 
-   } else if (sock->type == SOCK_STREAM) {
+   } else if (sock_type_connectible(sk->sk_type)) {
const struct vsock_transport *transport = vsk->transport;
lock_sock(sk);
 
@@ -1259,8 +1273,8 @@ static void vsock_connect_timeout(struct work_struct 
*work)
sock_put(sk);
 }
 
-static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
-   int addr_len, int flags)
+static int vsock_connect(struct socket *sock, struct sockaddr *addr,
+int addr_len, int flags)
 {
int err;
struct sock *sk;
@@ -1410,7 +1424,7 @@ static int vsock_accept(struct socket *sock, struct 
socket *newsock, int flags,
 
lock_sock(listener);
 
-   if (sock->type != SOCK_STREAM) {
+   if (!sock_type_connectible(sock->type)) {
err = -EOPNOTSUPP;
goto out;
}
@@ -1477,6 +1491,18 @@ static int vsock_acce

[RFC PATCH v2 05/13] af_vsock: implement send logic for SOCK_SEQPACKET

This adds some logic to current stream enqueue function for SEQPACKET
support:
1) Send record begin marker with length of record.
2) Return value from enqueue function is wholevrecord length or error for
   SOCK_SEQPACKET.

Signed-off-by: Arseny Krasnov 
---
 include/net/af_vsock.h   |  1 +
 net/vmw_vsock/af_vsock.c | 32 
 2 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
index 46073842d489..ec6bf4600ef8 100644
--- a/include/net/af_vsock.h
+++ b/include/net/af_vsock.h
@@ -136,6 +136,7 @@ struct vsock_transport {
bool (*stream_allow)(u32 cid, u32 port);
 
/* SEQ_PACKET. */
+   bool (*seqpacket_seq_send_len)(struct vsock_sock *, size_t len);
size_t (*seqpacket_seq_get_len)(struct vsock_sock *);
ssize_t (*seqpacket_dequeue)(struct vsock_sock *, struct msghdr *,
 size_t len, int flags);
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 5bf887190881..4a7cdf7756c0 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1683,8 +1683,8 @@ static int vsock_stream_getsockopt(struct socket *sock,
return 0;
 }
 
-static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
-   size_t len)
+static int vsock_connectible_sendmsg(struct socket *sock, struct msghdr *msg,
+size_t len)
 {
struct sock *sk;
struct vsock_sock *vsk;
@@ -1737,6 +1737,12 @@ static int vsock_stream_sendmsg(struct socket *sock, 
struct msghdr *msg,
if (err < 0)
goto out;
 
+   if (sk->sk_type == SOCK_SEQPACKET) {
+   err = transport->seqpacket_seq_send_len(vsk, len);
+   if (err < 0)
+   goto out;
+   }
+
while (total_written < len) {
ssize_t written;
 
@@ -1815,13 +1821,31 @@ static int vsock_stream_sendmsg(struct socket *sock, 
struct msghdr *msg,
}
 
 out_err:
-   if (total_written > 0)
-   err = total_written;
+   if (total_written > 0) {
+   /* Return number of written bytes only if:
+* 1) SOCK_STREAM socket.
+* 2) SOCK_SEQPACKET socket when whole buffer is sent.
+*/
+   if (sk->sk_type == SOCK_STREAM || total_written == len)
+   err = total_written;
+   }
 out:
release_sock(sk);
return err;
 }
 
+static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
+   size_t len)
+{
+   return vsock_connectible_sendmsg(sock, msg, len);
+}
+
+static int vsock_seqpacket_sendmsg(struct socket *sock, struct msghdr *msg,
+  size_t len)
+{
+   return vsock_connectible_sendmsg(sock, msg, len);
+}
+
 static int vsock_wait_data(struct sock *sk, struct wait_queue_entry *wait,
   long timeout,
   struct vsock_transport_recv_notify_data *recv_data,
-- 
2.25.1

[PATCH v2] HID: google: Get HID report on probe to confirm tablet switch state

2021-01-14 Thread Nicolas Boichat

This forces reading the base folded state anytime the device is
probed, to make sure it's in sync.

This is useful after a reboot, if the device re-enumerates for
any reason (e.g. ESD shock), or if the driver is unbound/rebound
(debugging/testing).

Without this, the tablet switch state is only synchronized after a
key is pressed (since the device would then send a report that
includes the switch state), leading to strange UX (e.g. UI
mode changes when a key is pressed after reboot).

This is not a problem on detachable base attach, as the device,
by itself, sends a report after it is booted up.

Signed-off-by: Nicolas Boichat 
---
Instead of all this manual parsing, it'd be easier to just call:
hid_hw_request(hdev, report, HID_REQ_GET_REPORT);
However, that fails silently as hdev->driver_input_lock is held
during probe (or even some callbacks like input_configured.

Changes in v2:
 - Improve commit message description.

 drivers/hid/hid-google-hammer.c | 85 +
 1 file changed, 66 insertions(+), 19 deletions(-)

diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 85a054f1ce38..d9319622da44 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -392,30 +392,34 @@ static int hammer_input_mapping(struct hid_device *hdev, 
struct hid_input *hi,
return 0;
 }
 
-static int hammer_event(struct hid_device *hid, struct hid_field *field,
-   struct hid_usage *usage, __s32 value)
+static void hammer_folded_event(struct hid_device *hdev, bool folded)
 {
unsigned long flags;
 
-   if (usage->hid == HID_USAGE_KBD_FOLDED) {
-   spin_lock_irqsave(&cbas_ec_lock, flags);
+   spin_lock_irqsave(&cbas_ec_lock, flags);
 
-   /*
-* If we are getting events from Whiskers that means that it
-* is attached to the lid.
-*/
-   cbas_ec.base_present = true;
-   cbas_ec.base_folded = value;
-   hid_dbg(hid, "%s: base: %d, folded: %d\n", __func__,
-   cbas_ec.base_present, cbas_ec.base_folded);
-
-   if (cbas_ec.input) {
-   input_report_switch(cbas_ec.input,
-   SW_TABLET_MODE, value);
-   input_sync(cbas_ec.input);
-   }
+   /*
+* If we are getting events from Whiskers that means that it
+* is attached to the lid.
+*/
+   cbas_ec.base_present = true;
+   cbas_ec.base_folded = folded;
+   hid_dbg(hdev, "%s: base: %d, folded: %d\n", __func__,
+   cbas_ec.base_present, cbas_ec.base_folded);
 
-   spin_unlock_irqrestore(&cbas_ec_lock, flags);
+   if (cbas_ec.input) {
+   input_report_switch(cbas_ec.input, SW_TABLET_MODE, folded);
+   input_sync(cbas_ec.input);
+   }
+
+   spin_unlock_irqrestore(&cbas_ec_lock, flags);
+}
+
+static int hammer_event(struct hid_device *hid, struct hid_field *field,
+   struct hid_usage *usage, __s32 value)
+{
+   if (usage->hid == HID_USAGE_KBD_FOLDED) {
+   hammer_folded_event(hid, value);
return 1; /* We handled this event */
}
 
@@ -457,6 +461,47 @@ static bool hammer_has_backlight_control(struct hid_device 
*hdev)
HID_GD_KEYBOARD, HID_AD_BRIGHTNESS);
 }
 
+static void hammer_get_folded_state(struct hid_device *hdev)
+{
+   struct hid_report *report;
+   char *buf;
+   int len, rlen;
+   int a;
+
+   report = hdev->report_enum[HID_INPUT_REPORT].report_id_hash[0x0];
+
+   if (!report || report->maxfield < 1)
+   return;
+
+   len = hid_report_len(report) + 1;
+
+   buf = kmalloc(len, GFP_KERNEL);
+   if (!buf)
+   return;
+
+   rlen = hid_hw_raw_request(hdev, report->id, buf, len, report->type, 
HID_REQ_GET_REPORT);
+
+   if (rlen != len) {
+   hid_warn(hdev, "Unable to read base folded state: %d (expected 
%d)\n", rlen, len);
+   goto out;
+   }
+
+   for (a = 0; a < report->maxfield; a++) {
+   struct hid_field *field = report->field[a];
+
+   if (field->usage->hid == HID_USAGE_KBD_FOLDED) {
+   u32 value = hid_field_extract(hdev, buf+1,
+   field->report_offset, 
field->report_size);
+
+   hammer_folded_event(hdev, value);
+   break;
+   }
+   }
+
+out:
+   kfree(buf);
+}
+
 static int hammer_probe(struct hid_device *hdev,
const struct hid_device_id *id)
 {
@@ -481,6 +526,8 @@ static int hammer_probe(struct hid_device *hdev,
error = hid_hw_open(hdev);
if (error)
return error;
+
+   hammer_get_folded_state(hdev);
}

[RFC PATCH v2 04/13] af_vsock: replace previous stream rx loop.

This removes previous 'vsock_stream_recvmsg()' and uses newly implemented
receive loops. Moved to separate patch to make review easier.

Signed-off-by: Arseny Krasnov 
---
 net/vmw_vsock/af_vsock.c | 184 +++
 1 file changed, 12 insertions(+), 172 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 38afaa90d141..5bf887190881 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -2072,178 +2072,6 @@ static int __vsock_stream_recvmsg(struct sock *sk, 
struct msghdr *msg,
return err;
 }
 
-static int
-vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
-int flags)
-{
-   struct sock *sk;
-   struct vsock_sock *vsk;
-   const struct vsock_transport *transport;
-   int err;
-   size_t target;
-   ssize_t copied;
-   long timeout;
-   struct vsock_transport_recv_notify_data recv_data;
-
-   DEFINE_WAIT(wait);
-
-   sk = sock->sk;
-   vsk = vsock_sk(sk);
-   transport = vsk->transport;
-   err = 0;
-
-   lock_sock(sk);
-
-   if (!transport || sk->sk_state != TCP_ESTABLISHED) {
-   /* Recvmsg is supposed to return 0 if a peer performs an
-* orderly shutdown. Differentiate between that case and when a
-* peer has not connected or a local shutdown occured with the
-* SOCK_DONE flag.
-*/
-   if (sock_flag(sk, SOCK_DONE))
-   err = 0;
-   else
-   err = -ENOTCONN;
-
-   goto out;
-   }
-
-   if (flags & MSG_OOB) {
-   err = -EOPNOTSUPP;
-   goto out;
-   }
-
-   /* We don't check peer_shutdown flag here since peer may actually shut
-* down, but there can be data in the queue that a local socket can
-* receive.
-*/
-   if (sk->sk_shutdown & RCV_SHUTDOWN) {
-   err = 0;
-   goto out;
-   }
-
-   /* It is valid on Linux to pass in a zero-length receive buffer.  This
-* is not an error.  We may as well bail out now.
-*/
-   if (!len) {
-   err = 0;
-   goto out;
-   }
-
-   /* We must not copy less than target bytes into the user's buffer
-* before returning successfully, so we wait for the consume queue to
-* have that much data to consume before dequeueing.  Note that this
-* makes it impossible to handle cases where target is greater than the
-* queue size.
-*/
-   target = sock_rcvlowat(sk, flags & MSG_WAITALL, len);
-   if (target >= transport->stream_rcvhiwat(vsk)) {
-   err = -ENOMEM;
-   goto out;
-   }
-   timeout = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
-   copied = 0;
-
-   err = transport->notify_recv_init(vsk, target, &recv_data);
-   if (err < 0)
-   goto out;
-
-
-   while (1) {
-   s64 ready;
-
-   prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
-   ready = vsock_stream_has_data(vsk);
-
-   if (ready == 0) {
-   if (sk->sk_err != 0 ||
-   (sk->sk_shutdown & RCV_SHUTDOWN) ||
-   (vsk->peer_shutdown & SEND_SHUTDOWN)) {
-   finish_wait(sk_sleep(sk), &wait);
-   break;
-   }
-   /* Don't wait for non-blocking sockets. */
-   if (timeout == 0) {
-   err = -EAGAIN;
-   finish_wait(sk_sleep(sk), &wait);
-   break;
-   }
-
-   err = transport->notify_recv_pre_block(
-   vsk, target, &recv_data);
-   if (err < 0) {
-   finish_wait(sk_sleep(sk), &wait);
-   break;
-   }
-   release_sock(sk);
-   timeout = schedule_timeout(timeout);
-   lock_sock(sk);
-
-   if (signal_pending(current)) {
-   err = sock_intr_errno(timeout);
-   finish_wait(sk_sleep(sk), &wait);
-   break;
-   } else if (timeout == 0) {
-   err = -EAGAIN;
-   finish_wait(sk_sleep(sk), &wait);
-   break;
-   }
-   } else {
-   ssize_t read;
-
-   finish_wait(sk_sleep(sk), &wait);
-
-   if (ready < 0) {
-   /* Invalid queue pair content. XXX This should
-   *

[RFC PATCH v2 03/13] af_vsock: implement rx loops entry point

This adds entry point for STREAM/SEQPACKET rx loops. As both types are
connect oriented, so there are same checks before reading data from
socket. All this checks are performed in this entry point, then specific
rx loop is called.

Signed-off-by: Arseny Krasnov 
---
 net/vmw_vsock/af_vsock.c | 55 
 1 file changed, 55 insertions(+)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index afacbe9f4231..38afaa90d141 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -2244,6 +2244,61 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr 
*msg, size_t len,
return err;
 }
 
+static int vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg,
+size_t len, int flags)
+{
+   struct sock *sk;
+   int err = 0;
+   struct vsock_sock *vsk;
+   const struct vsock_transport *transport;
+
+   sk = sock->sk;
+
+   lock_sock(sk);
+
+   vsk = vsock_sk(sk);
+   transport = vsk->transport;
+
+   if (!transport || sk->sk_state != TCP_ESTABLISHED) {
+   /* Recvmsg is supposed to return 0 if a peer performs an
+* orderly shutdown. Differentiate between that case and when a
+* peer has not connected or a local shutdown occurred with the
+* SOCK_DONE flag.
+*/
+   if (!sock_flag(sk, SOCK_DONE))
+   err = -ENOTCONN;
+
+   goto out;
+   }
+
+   if (flags & MSG_OOB) {
+   err = -EOPNOTSUPP;
+   goto out;
+   }
+
+   /* We don't check peer_shutdown flag here since peer may actually shut
+* down, but there can be data in the queue that a local socket can
+* receive.
+*/
+   if (sk->sk_shutdown & RCV_SHUTDOWN)
+   goto out;
+
+   /* It is valid on Linux to pass in a zero-length receive buffer.  This
+* is not an error.  We may as well bail out now.
+*/
+   if (!len)
+   goto out;
+
+   if (sk->sk_type == SOCK_STREAM)
+   err = __vsock_stream_recvmsg(sk, msg, len, flags);
+   else
+   err = __vsock_seqpacket_recvmsg(sk, msg, len, flags);
+
+out:
+   release_sock(sk);
+   return err;
+}
+
 static const struct proto_ops vsock_stream_ops = {
.family = PF_VSOCK,
.owner = THIS_MODULE,
-- 
2.25.1

[RFC PATCH v2 02/13] af_vsock: separate rx loops for STREAM/SEQPACKET.

This adds two receive loops: for SOCK_STREAM and SOCK_SEQPACKET. Both are
look like twins, but SEQPACKET is a little bit different from STREAM:
1) It doesn't call notify callbacks.
2) It doesn't care about 'SO_SNDLOWAT' and 'SO_RCVLOWAT' values, because
   there is no sense for these values in SEQPACKET case.
3) It waits until whole record is received or error is found during
   receiving.
4) It processes and sets 'MSG_TRUNC' flag.

So to avoid extra conditions for two types of socket inside on loop, two
independent functions were created.

Signed-off-by: Arseny Krasnov 
---
 include/net/af_vsock.h   |   5 +
 net/vmw_vsock/af_vsock.c | 202 +++
 2 files changed, 207 insertions(+)

diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
index b1c717286993..46073842d489 100644
--- a/include/net/af_vsock.h
+++ b/include/net/af_vsock.h
@@ -135,6 +135,11 @@ struct vsock_transport {
bool (*stream_is_active)(struct vsock_sock *);
bool (*stream_allow)(u32 cid, u32 port);
 
+   /* SEQ_PACKET. */
+   size_t (*seqpacket_seq_get_len)(struct vsock_sock *);
+   ssize_t (*seqpacket_dequeue)(struct vsock_sock *, struct msghdr *,
+size_t len, int flags);
+
/* Notification. */
int (*notify_poll_in)(struct vsock_sock *, size_t, bool *);
int (*notify_poll_out)(struct vsock_sock *, size_t, bool *);
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index af716f5a93a4..afacbe9f4231 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1870,6 +1870,208 @@ static int vsock_wait_data(struct sock *sk, struct 
wait_queue_entry *wait,
return err;
 }
 
+static int __vsock_seqpacket_recvmsg(struct sock *sk, struct msghdr *msg,
+size_t len, int flags)
+{
+   int err = 0;
+   size_t record_len;
+   struct vsock_sock *vsk;
+   const struct vsock_transport *transport;
+   long timeout;
+   ssize_t dequeued_total = 0;
+   unsigned long orig_nr_segs;
+   const struct iovec *orig_iov;
+   DEFINE_WAIT(wait);
+
+   vsk = vsock_sk(sk);
+   transport = vsk->transport;
+
+   timeout = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
+   msg->msg_flags &= ~MSG_EOR;
+   orig_nr_segs = msg->msg_iter.nr_segs;
+   orig_iov = msg->msg_iter.iov;
+
+   while (1) {
+   s64 ready;
+
+   prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
+   ready = vsock_stream_has_data(vsk);
+
+   if (ready == 0) {
+   if (vsock_wait_data(sk, &wait, timeout, NULL, 0)) {
+   /* In case of any loop break(timeout, signal
+* interrupt or shutdown), we report user that
+* nothing was copied.
+*/
+   dequeued_total = 0;
+   break;
+   }
+   } else {
+   ssize_t dequeued;
+
+   finish_wait(sk_sleep(sk), &wait);
+
+   if (ready < 0) {
+   err = -ENOMEM;
+   goto out;
+   }
+
+   if (dequeued_total == 0) {
+   record_len =
+   transport->seqpacket_seq_get_len(vsk);
+
+   if (record_len == 0)
+   continue;
+   }
+
+   /* 'msg_iter.count' is number of unused bytes in iov.
+* On every copy to iov iterator it is decremented at
+* size of data.
+*/
+   dequeued = transport->seqpacket_dequeue(vsk, msg,
+   msg->msg_iter.count, flags);
+
+   if (dequeued < 0) {
+   dequeued_total = 0;
+
+   if (dequeued == -EAGAIN) {
+   iov_iter_init(&msg->msg_iter, READ,
+ orig_iov, orig_nr_segs,
+ len);
+   msg->msg_flags &= ~MSG_EOR;
+   continue;
+   }
+
+   err = -ENOMEM;
+   break;
+   }
+
+   dequeued_total += dequeued;
+
+   if (dequeued_total >= record_len)
+   break;
+   }
+   }
+   if (sk->sk_err)
+   err = -sk->sk_err;
+   else if (sk->sk_shutdown & RCV_SHUTDOWN)
+   err = 0;
+
+   if (dequeued_total >

[PATCH v3 2/4] initramfs: Provide a common initrd reserve function

Some architectures(eg, ARM and riscv) have similar logic to
check and reserve the memory of initrd, let's provide a common
function reserve_initrd_mem() to reduce duplicated code.

Signed-off-by: Kefeng Wang 
---
 include/linux/initrd.h |  6 ++
 init/initramfs.c   | 45 ++
 2 files changed, 51 insertions(+)

diff --git a/include/linux/initrd.h b/include/linux/initrd.h
index fc30ac30e10e..85c15717af34 100644
--- a/include/linux/initrd.h
+++ b/include/linux/initrd.h
@@ -18,6 +18,12 @@ extern int initrd_below_start_ok;
 extern unsigned long initrd_start, initrd_end;
 extern void free_initrd_mem(unsigned long, unsigned long);
 
+#ifdef CONFIG_BLK_DEV_INITRD
+extern void __init reserve_initrd_mem(void);
+#else
+static inline void __init reserve_initrd_mem(void) {}
+#endif
+
 extern phys_addr_t phys_initrd_start;
 extern unsigned long phys_initrd_size;
 
diff --git a/init/initramfs.c b/init/initramfs.c
index 55b74d7e5260..f75c89e9d602 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -535,6 +535,51 @@ extern unsigned long __initramfs_size;
 #include 
 #include 
 
+void __init reserve_initrd_mem(void)
+{
+   phys_addr_t start;
+   unsigned long size;
+
+   /* Ignore the virtul address computed during device tree parsing */
+   initrd_start = initrd_end = 0;
+
+   if (!phys_initrd_size)
+   return;
+   /*
+* Round the memory region to page boundaries as per free_initrd_mem()
+* This allows us to detect whether the pages overlapping the initrd
+* are in use, but more importantly, reserves the entire set of pages
+* as we don't want these pages allocated for other purposes.
+*/
+   start = round_down(phys_initrd_start, PAGE_SIZE);
+   size = phys_initrd_size + (phys_initrd_start - start);
+   size = round_up(size, PAGE_SIZE);
+
+   if (!memblock_is_region_memory(start, size)) {
+   pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region",
+  (u64)start, size);
+   goto disable;
+   }
+
+   if (memblock_is_region_reserved(start, size)) {
+   pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory 
region\n",
+  (u64)start, size);
+   goto disable;
+   }
+
+   memblock_reserve(start, size);
+   /* Now convert initrd to virtual addresses */
+   initrd_start = (unsigned long)__va(phys_initrd_start);
+   initrd_end = initrd_start + phys_initrd_size;
+   initrd_below_start_ok = 1;
+
+   return;
+disable:
+   pr_cont(" - disabling initrd\n");
+   initrd_start = 0;
+   initrd_end = 0;
+}
+
 void __weak __init free_initrd_mem(unsigned long start, unsigned long end)
 {
 #ifdef CONFIG_ARCH_KEEP_MEMBLOCK
-- 
2.26.2

[PATCH v3 4/4] riscv: Covert to reserve_initrd_mem()

Covert to the generic reserve_initrd_mem() function.

Signed-off-by: Kefeng Wang 
---
 arch/riscv/mm/init.c | 54 +---
 1 file changed, 1 insertion(+), 53 deletions(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index bf5379135e39..1eaae54c8ea1 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -105,55 +105,6 @@ void __init mem_init(void)
print_vm_layout();
 }
 
-#ifdef CONFIG_BLK_DEV_INITRD
-static void __init setup_initrd(void)
-{
-   phys_addr_t start;
-   unsigned long size;
-
-   /* Ignore the virtul address computed during device tree parsing */
-   initrd_start = initrd_end = 0;
-
-   if (!phys_initrd_size)
-   return;
-   /*
-* Round the memory region to page boundaries as per free_initrd_mem()
-* This allows us to detect whether the pages overlapping the initrd
-* are in use, but more importantly, reserves the entire set of pages
-* as we don't want these pages allocated for other purposes.
-*/
-   start = round_down(phys_initrd_start, PAGE_SIZE);
-   size = phys_initrd_size + (phys_initrd_start - start);
-   size = round_up(size, PAGE_SIZE);
-
-   if (!memblock_is_region_memory(start, size)) {
-   pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region",
-  (u64)start, size);
-   goto disable;
-   }
-
-   if (memblock_is_region_reserved(start, size)) {
-   pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory 
region\n",
-  (u64)start, size);
-   goto disable;
-   }
-
-   memblock_reserve(start, size);
-   /* Now convert initrd to virtual addresses */
-   initrd_start = (unsigned long)__va(phys_initrd_start);
-   initrd_end = initrd_start + phys_initrd_size;
-   initrd_below_start_ok = 1;
-
-   pr_info("Initial ramdisk at: 0x%p (%lu bytes)\n",
-   (void *)(initrd_start), size);
-   return;
-disable:
-   pr_cont(" - disabling initrd\n");
-   initrd_start = 0;
-   initrd_end = 0;
-}
-#endif /* CONFIG_BLK_DEV_INITRD */
-
 void __init setup_bootmem(void)
 {
phys_addr_t mem_start = 0;
@@ -186,10 +137,7 @@ void __init setup_bootmem(void)
dma32_phys_limit = min(4UL * SZ_1G, (unsigned 
long)PFN_PHYS(max_low_pfn));
set_max_mapnr(max_low_pfn);
 
-#ifdef CONFIG_BLK_DEV_INITRD
-   setup_initrd();
-#endif /* CONFIG_BLK_DEV_INITRD */
-
+   reserve_initrd_mem();
/*
 * Avoid using early_init_fdt_reserve_self() since __pa() does
 * not work for DTB pointers that are fixmap addresses
-- 
2.26.2

[PATCH v3 3/4] ARM: Covert to reserve_initrd_mem()

Covert to the generic reserve_initrd_mem() function.

Signed-off-by: Kefeng Wang 
---
 arch/arm/mm/init.c | 43 +--
 1 file changed, 1 insertion(+), 42 deletions(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 828a2561b229..a29e14cd626c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -153,47 +153,6 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, 
phys_addr_t align)
return phys;
 }
 
-static void __init arm_initrd_init(void)
-{
-#ifdef CONFIG_BLK_DEV_INITRD
-   phys_addr_t start;
-   unsigned long size;
-
-   initrd_start = initrd_end = 0;
-
-   if (!phys_initrd_size)
-   return;
-
-   /*
-* Round the memory region to page boundaries as per free_initrd_mem()
-* This allows us to detect whether the pages overlapping the initrd
-* are in use, but more importantly, reserves the entire set of pages
-* as we don't want these pages allocated for other purposes.
-*/
-   start = round_down(phys_initrd_start, PAGE_SIZE);
-   size = phys_initrd_size + (phys_initrd_start - start);
-   size = round_up(size, PAGE_SIZE);
-
-   if (!memblock_is_region_memory(start, size)) {
-   pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - 
disabling initrd\n",
-  (u64)start, size);
-   return;
-   }
-
-   if (memblock_is_region_reserved(start, size)) {
-   pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory region 
- disabling initrd\n",
-  (u64)start, size);
-   return;
-   }
-
-   memblock_reserve(start, size);
-
-   /* Now convert initrd to virtual addresses */
-   initrd_start = __phys_to_virt(phys_initrd_start);
-   initrd_end = initrd_start + phys_initrd_size;
-#endif
-}
-
 #ifdef CONFIG_CPU_ICACHE_MISMATCH_WORKAROUND
 void check_cpu_icache_size(int cpuid)
 {
@@ -215,7 +174,7 @@ void __init arm_memblock_init(const struct machine_desc 
*mdesc)
/* Register the kernel text, kernel data and initrd with memblock. */
memblock_reserve(__pa(KERNEL_START), KERNEL_END - KERNEL_START);
 
-   arm_initrd_init();
+   reserve_initrd_mem();
 
arm_mm_memblock_reserve();
 
-- 
2.26.2

[PATCH v3 1/4] initrd: Add the preprocessor guard in initrd.h

Add the preprocessor guard in initrd.h to prevent possible
build error from the multiple inclusion of same header file
multiple time.

Signed-off-by: Kefeng Wang 
---
 include/linux/initrd.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/initrd.h b/include/linux/initrd.h
index 8db6f8c8030b..fc30ac30e10e 100644
--- a/include/linux/initrd.h
+++ b/include/linux/initrd.h
@@ -1,5 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 
+#ifndef __LINUX_INITRD_H
+#define __LINUX_INITRD_H
+
 #define INITRD_MINOR 250 /* shouldn't collide with /dev/ram* too soon ... */
 
 /* starting block # of image */
@@ -24,3 +27,5 @@ extern char __initramfs_start[];
 extern unsigned long __initramfs_size;
 
 void console_on_rootfs(void);
+
+#endif /* __LINUX_INITRD_H */
-- 
2.26.2

[PATCH v3 0/4] initrd: Use unified initrd reserve function in ARM/RISCV

Use the same implementation of initrd reserve to avoid duplication.

v3:
- split into four patches, suggested-by Palmer Dabbelt
v2:
- fix build error found by kernel test robot

Kefeng Wang (4):
  initrd: Add the preprocessor guard in initrd.h
  initramfs: Provide a common initrd reserve function
  ARM: Covert to reserve_initrd_mem()
  riscv: Covert to reserve_initrd_mem()

 arch/arm/mm/init.c | 43 +
 arch/riscv/mm/init.c   | 54 +-
 include/linux/initrd.h | 11 +
 init/initramfs.c   | 45 +++
 4 files changed, 58 insertions(+), 95 deletions(-)

-- 
2.26.2

[RFC PATCH v2 01/13] af_vsock: implement 'vsock_wait_data()'.

This adds 'vsock_wait_data()' function which is called from user's read
syscall and waits until new socket data is arrived. It was based on code
from stream dequeue logic and moved to separate function because it will
be called both from SOCK_STREAM and SOCK_SEQPACKET receive loops.

Signed-off-by: Arseny Krasnov 
---
 net/vmw_vsock/af_vsock.c | 47 
 1 file changed, 47 insertions(+)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index b12d3a322242..af716f5a93a4 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1822,6 +1822,53 @@ static int vsock_stream_sendmsg(struct socket *sock, 
struct msghdr *msg,
return err;
 }
 
+static int vsock_wait_data(struct sock *sk, struct wait_queue_entry *wait,
+  long timeout,
+  struct vsock_transport_recv_notify_data *recv_data,
+  size_t target)
+{
+   int err = 0;
+   struct vsock_sock *vsk;
+   const struct vsock_transport *transport;
+
+   vsk = vsock_sk(sk);
+   transport = vsk->transport;
+
+   if (sk->sk_err != 0 ||
+   (sk->sk_shutdown & RCV_SHUTDOWN) ||
+   (vsk->peer_shutdown & SEND_SHUTDOWN)) {
+   finish_wait(sk_sleep(sk), wait);
+   return -1;
+   }
+   /* Don't wait for non-blocking sockets. */
+   if (timeout == 0) {
+   err = -EAGAIN;
+   finish_wait(sk_sleep(sk), wait);
+   return err;
+   }
+
+   if (recv_data) {
+   err = transport->notify_recv_pre_block(vsk, target, recv_data);
+   if (err < 0) {
+   finish_wait(sk_sleep(sk), wait);
+   return err;
+   }
+   }
+
+   release_sock(sk);
+   timeout = schedule_timeout(timeout);
+   lock_sock(sk);
+
+   if (signal_pending(current)) {
+   err = sock_intr_errno(timeout);
+   finish_wait(sk_sleep(sk), wait);
+   } else if (timeout == 0) {
+   err = -EAGAIN;
+   finish_wait(sk_sleep(sk), wait);
+   }
+
+   return err;
+}
 
 static int
 vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
-- 
2.25.1

[PATCH 5/5] soundwire: cadence: adjust verbosity in response handling

From: Pierre-Louis Bossart 

There are too many logs on startup, e.g.

[ 8811.851497] cdns_fill_msg_resp: 2 callbacks suppressed
[ 8811.851497] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851498] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851499] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851499] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851500] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851500] intel-sdw intel-sdw.0: Msg Ack not received
[ 8811.851502] intel-sdw intel-sdw.0: Msg ignored for Slave 0
[ 8811.851503] soundwire sdw-master-0: No more devices to enumerate

We can skip the 'Msg Ack not received' since it's typical of the
enumeration end, and conversely add the information on which command
fails.

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/cadence_master.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
index d3c9cf920cbd..8d7166ffd4ad 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -483,11 +483,11 @@ cdns_fill_msg_resp(struct sdw_cdns *cdns,
for (i = 0; i < count; i++) {
if (!(cdns->response_buf[i] & CDNS_MCP_RESP_ACK)) {
no_ack = 1;
-   dev_dbg_ratelimited(cdns->dev, "Msg Ack not 
received\n");
+   dev_vdbg(cdns->dev, "Msg Ack not received, cmd %d\n", 
i);
}
if (cdns->response_buf[i] & CDNS_MCP_RESP_NACK) {
nack = 1;
-   dev_err_ratelimited(cdns->dev, "Msg NACK received\n");
+   dev_err_ratelimited(cdns->dev, "Msg NACK received, cmd 
%d\n", i);
}
}
 
-- 
2.17.1

[PATCH 4/5] soundwire: cadence: fix ACK/NAK handling

From: Pierre-Louis Bossart 

The existing code reports a NAK only when ACK=0
This is not aligned with the SoundWire 1.x specifications.

Table 32 in the SoundWire 1.2 specification shows that a Device shall
not set NAK=1 if ACK=1. But Table 33 shows the Combined Response
may very well be NAK=1/ACK=1, e.g. if another Device than the one
addressed reports a parity error.

NAK=1 signals a 'Command_Aborted', regardless of the ACK bit value.

Move the tests for NAK so that the NAK=1/ACK=1 combination is properly
detected according to the specification.

Fixes: 956baa1992f9a ('soundwire: cdns: Add sdw_master_ops and IO transfer 
support')
Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/cadence_master.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
index 801e1fef59d8..d3c9cf920cbd 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -484,10 +484,10 @@ cdns_fill_msg_resp(struct sdw_cdns *cdns,
if (!(cdns->response_buf[i] & CDNS_MCP_RESP_ACK)) {
no_ack = 1;
dev_dbg_ratelimited(cdns->dev, "Msg Ack not 
received\n");
-   if (cdns->response_buf[i] & CDNS_MCP_RESP_NACK) {
-   nack = 1;
-   dev_err_ratelimited(cdns->dev, "Msg NACK 
received\n");
-   }
+   }
+   if (cdns->response_buf[i] & CDNS_MCP_RESP_NACK) {
+   nack = 1;
+   dev_err_ratelimited(cdns->dev, "Msg NACK received\n");
}
}
 
-- 
2.17.1

[PATCH 3/5] soundwire: bus: add more details to track failed transfers

The current error log does not provide details on the type of
transfers and which address/count was requested. All this information
can help locate in which parts of the configuration process an error
occurred.

Co-developed-by: Pierre-Louis Bossart 
Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/bus.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 3cc006bfae71..6e1c988f3845 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -267,8 +267,10 @@ static int sdw_transfer_unlocked(struct sdw_bus *bus, 
struct sdw_msg *msg)
 
ret = do_transfer(bus, msg);
if (ret != 0 && ret != -ENODATA)
-   dev_err(bus->dev, "trf on Slave %d failed:%d\n",
-   msg->dev_num, ret);
+   dev_err(bus->dev, "trf on Slave %d failed:%d %s addr %x count 
%d\n",
+   msg->dev_num, ret,
+   (msg->flags & SDW_MSG_FLAG_WRITE) ? "write" : "read",
+   msg->addr, msg->len);
 
if (msg->page)
sdw_reset_page(bus, msg->dev_num);
-- 
2.17.1

[PATCH 2/5] soundwire: cadence: add status in dev_dbg 'State change' log

From: Pierre-Louis Bossart 

The existing debug log only mentions a state change, without providing
any details. For integration and stress-tests, it's helpful to see in
the dmesg log the reason for the state change.

The value is intended for power users and isn't converted as
human-readable values. But for the record each device has a 4-bit
status:

BIT(0): Unattached
BIT(1): Attached
BIT(2): Alert
BIT(3): Reserved (should not happen)

Example:

[  121.891288] intel-sdw intel-sdw.0: Slave status change: 0x2

<< this shows a Device0 Attached

[  121.891295] soundwire sdw-master-0: Slave attached, programming device number
[  121.891629] soundwire sdw-master-0: SDW Slave Addr: 30025d071101
[  121.891632] soundwire sdw-master-0: SDW Slave class_id 1, part_id 711, 
mfg_id 25d, unique_id 0, version 3
[  121.892011] intel-sdw intel-sdw.0: Msg ignored for Slave 0
[  121.892013] soundwire sdw-master-0: No more devices to enumerate
[  121.892200] intel-sdw intel-sdw.0: Slave status change: 0x21

<< this shows the device now Attached as Device1 and Unattached as
Device0, i.e. a successful enumeration.

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/cadence_master.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
index 9fa55164354a..801e1fef59d8 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -734,21 +734,18 @@ static void cdns_read_response(struct sdw_cdns *cdns)
 }
 
 static int cdns_update_slave_status(struct sdw_cdns *cdns,
-   u32 slave0, u32 slave1)
+   u64 slave_intstat)
 {
enum sdw_slave_status status[SDW_MAX_DEVICES + 1];
bool is_slave = false;
-   u64 slave;
u32 mask;
int i, set_status;
 
-   /* combine the two status */
-   slave = ((u64)slave1 << 32) | slave0;
memset(status, 0, sizeof(status));
 
for (i = 0; i <= SDW_MAX_DEVICES; i++) {
-   mask = (slave >> (i * CDNS_MCP_SLAVE_STATUS_NUM)) &
-   CDNS_MCP_SLAVE_STATUS_BITS;
+   mask = (slave_intstat >> (i * CDNS_MCP_SLAVE_STATUS_NUM)) &
+   CDNS_MCP_SLAVE_STATUS_BITS;
if (!mask)
continue;
 
@@ -918,13 +915,17 @@ static void cdns_update_slave_status_work(struct 
work_struct *work)
struct sdw_cdns *cdns =
container_of(work, struct sdw_cdns, work);
u32 slave0, slave1;
-
-   dev_dbg_ratelimited(cdns->dev, "Slave status change\n");
+   u64 slave_intstat;
 
slave0 = cdns_readl(cdns, CDNS_MCP_SLAVE_INTSTAT0);
slave1 = cdns_readl(cdns, CDNS_MCP_SLAVE_INTSTAT1);
 
-   cdns_update_slave_status(cdns, slave0, slave1);
+   /* combine the two status */
+   slave_intstat = ((u64)slave1 << 32) | slave0;
+
+   dev_dbg_ratelimited(cdns->dev, "Slave status change: 0x%llx\n", 
slave_intstat);
+
+   cdns_update_slave_status(cdns, slave_intstat);
cdns_writel(cdns, CDNS_MCP_SLAVE_INTSTAT0, slave0);
cdns_writel(cdns, CDNS_MCP_SLAVE_INTSTAT1, slave1);
 
-- 
2.17.1

[PATCH 1/5] soundwire: use consistent format for Slave devID logs

From: Pierre-Louis Bossart 

We mix decimal and hexadecimal values, this leads to confusions in
dmesg logs and bug reports. Let's add a 0x prefix for all hexadecimal
values and a format when more than 4 bits are used.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/bus.c   |  5 ++---
 drivers/soundwire/slave.c | 10 --
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index d1e8c3a54976..3cc006bfae71 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -679,9 +679,8 @@ void sdw_extract_slave_id(struct sdw_bus *bus,
id->class_id = SDW_CLASS_ID(addr);
 
dev_dbg(bus->dev,
-   "SDW Slave class_id %x, part_id %x, mfg_id %x, unique_id %x, 
version %x\n",
-   id->class_id, id->part_id, id->mfg_id,
-   id->unique_id, id->sdw_version);
+   "SDW Slave class_id 0x%02x, mfg_id 0x%04x, part_id 0x%04x, 
unique_id 0x%x, version 0x%x\n",
+   id->class_id, id->mfg_id, id->part_id, id->unique_id, 
id->sdw_version);
 }
 
 static int sdw_program_device_num(struct sdw_bus *bus)
diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c
index a08f4081c1c4..180f38bd003b 100644
--- a/drivers/soundwire/slave.c
+++ b/drivers/soundwire/slave.c
@@ -163,15 +163,13 @@ int sdw_acpi_find_slaves(struct sdw_bus *bus)
 
if (id.unique_id != id2.unique_id) {
dev_dbg(bus->dev,
-   "Valid unique IDs %x %x for Slave mfg 
%x part %d\n",
-   id.unique_id, id2.unique_id,
-   id.mfg_id, id.part_id);
+   "Valid unique IDs 0x%x 0x%x for Slave 
mfg_id 0x%04x, part_id 0x%04x\n",
+   id.unique_id, id2.unique_id, id.mfg_id, 
id.part_id);
ignore_unique_id = false;
} else {
dev_err(bus->dev,
-   "Invalid unique IDs %x %x for Slave mfg 
%x part %d\n",
-   id.unique_id, id2.unique_id,
-   id.mfg_id, id.part_id);
+   "Invalid unique IDs 0x%x 0x%x for Slave 
mfg_id 0x%04x, part_id 0x%04x\n",
+   id.unique_id, id2.unique_id, id.mfg_id, 
id.part_id);
return -ENODEV;
}
}
-- 
2.17.1

[PATCH 0/5] soundwire: fix ACK/NAK handling and improve log

The existing code reports a NAK only when ACK=0
This is not aligned with the SoundWire 1.x specifications.

Table 32 in the SoundWire 1.2 specification shows that a Device shall
not set NAK=1 if ACK=1. But Table 33 shows the Combined Response
may very well be NAK=1/ACK=1, e.g. if another Device than the one
addressed reports a parity error.

NAK=1 signals a 'Command_Aborted', regardless of the ACK bit value.

Move the tests for NAK so that the NAK=1/ACK=1 combination is properly
detected according to the specification.

Also, improve the demesg log to get more information for debugging.

Bard Liao (1):
  soundwire: bus: add more details to track failed transfers

Pierre-Louis Bossart (4):
  soundwire: use consistent format for Slave devID logs
  soundwire: cadence: add status in dev_dbg 'State change' log
  soundwire: cadence: fix ACK/NAK handling
  soundwire: cadence: adjust verbosity in response handling

 drivers/soundwire/bus.c| 11 ++-
 drivers/soundwire/cadence_master.c | 29 +++--
 drivers/soundwire/slave.c  | 10 --
 3 files changed, 25 insertions(+), 25 deletions(-)

-- 
2.17.1

[RFC PATCH v2 00/13] virtio/vsock: introduce SOCK_SEQPACKET support.

This patchset impelements support of SOCK_SEQPACKET for virtio
transport.
As SOCK_SEQPACKET guarantees to save record boundaries, so to
do it, new packet operation was added: it marks start of record (with
record length in header), such packet doesn't carry any data.  To send
record, packet with start marker is sent first, then all data is sent
as usual 'RW' packets. On receiver's side, length of record is known
from packet with start record marker. Now as  packets of one socket
are not reordered neither on vsock nor on vhost transport layers, such
marker allows to restore original record on receiver's side. If user's
buffer is smaller that record length, when all out of size data is
dropped.
Maximum length of datagram is not limited as in stream socket,
because same credit logic is used. Difference with stream socket is
that user is not woken up until whole record is received or error
occurred. Implementation also supports 'MSG_EOR' and 'MSG_TRUNC' flags.
Tests also implemented.

 Arseny Krasnov (13):
  af_vsock: implement 'vsock_wait_data()'.
  af_vsock: separate rx loops for STREAM/SEQPACKET.
  af_vsock: implement rx loops entry point
  af_vsock: replace previous stream rx loop.
  af_vsock: implement send logic for SOCK_SEQPACKET
  af_vsock: general support of SOCK_SEQPACKET type.
  af_vsock: update comments for stream sockets.
  virtio/vsock: dequeue callback for SOCK_SEQPACKET.
  virtio/vsock: implement fetch of record length
  virtio/vsock: update receive logic
  virtio/vsock: rest of SOCK_SEQPACKET support
  vhost/vsock: support for SOCK_SEQPACKET socket.
  vsock_test: add SOCK_SEQPACKET tests.

 drivers/vhost/vsock.c   |   7 +-
 include/linux/virtio_vsock.h|  12 +
 include/net/af_vsock.h  |   6 +
 include/uapi/linux/virtio_vsock.h   |   9 +
 net/vmw_vsock/af_vsock.c| 483 --
 net/vmw_vsock/virtio_transport.c|   4 +
 net/vmw_vsock/virtio_transport_common.c | 294 +++--
 tools/testing/vsock/util.c  |  32 +-
 tools/testing/vsock/util.h  |   3 +
 tools/testing/vsock/vsock_test.c| 126 ++
 10 files changed, 824 insertions(+), 152 deletions(-)

 v1 -> v2:
 - patches reordered: af_vsock.c changes now before virtio vsock
 - patches reorganized: more small patches, where +/- are not mixed
 - tests for SOCK_SEQPACKET added
 - all commit messages updated
 - af_vsock.c: 'vsock_pre_recv_check()' inlined to
   'vsock_connectible_recvmsg()'
 - af_vsock.c: 'vsock_assign_transport()' returns ENODEV if transport
   was not found
 - virtio_transport_common.c: transport callback for seqpacket dequeue
 - virtio_transport_common.c: simplified
   'virtio_transport_recv_connected()'
 - virtio_transport_common.c: send reset on socket and packet type
  mismatch.

Signed-off-by: Arseny Krasnov 

-- 
2.25.1

Re: [PATCH v2 7/7] arm64: dts: pmi8998: Add the right interrupts for LAB/IBB SCP and OCP

On Wed 13 Jan 13:42 CST 2021, AngeloGioacchino Del Regno wrote:

> In commit 208921bae696 ("arm64: dts: qcom: pmi8998: Add nodes for
> LAB and IBB regulators") bindings for the lab/ibb regulators were
> added to the pmi8998 dt, but the original committer has never
> specified what the interrupts were for.
> LAB and IBB regulators provide two interrupts, SC-ERR (short
> circuit error) and VREG-OK but, in that commit, the regulators
> were provided with two different types of interrupts;
> specifically, IBB had the SC-ERR interrupt, while LAB had the
> VREG-OK one, none of which were (luckily) used, since the driver
> didn't actually use these at all.
> Assuming that the original intention was to have the SC IRQ in
> both LAB and IBB, as per the names appearing in documentation,
> fix the SCP interrupt.
> 
> While at it, also add the OCP interrupt in order to be able to
> enable the Over-Current Protection feature, if requested.
> 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  arch/arm64/boot/dts/qcom/pmi8998.dtsi | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/pmi8998.dtsi 
> b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
> index d016b12967eb..d230c510d4b7 100644
> --- a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
> @@ -30,11 +30,15 @@ labibb {
>   compatible = "qcom,pmi8998-lab-ibb";
>  
>   ibb: ibb {
> - interrupts = <0x3 0xdc 0x2 
> IRQ_TYPE_EDGE_RISING>;
> + interrupts = <0x3 0xdc 0x2 
> IRQ_TYPE_EDGE_RISING>,
> +  <0x3 0xdc 0x0 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "sc-err", "ocp";
>   };
>  
>   lab: lab {
> - interrupts = <0x3 0xde 0x0 
> IRQ_TYPE_EDGE_RISING>;
> + interrupts = <0x3 0xde 0x1 
> IRQ_TYPE_EDGE_RISING>,
> +  <0x3 0xde 0x0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "sc-err", "ocp";
>   };
>   };
>   };
> -- 
> 2.29.2
>

linux-next: build failure after merge of the amdgpu tree

2021-01-14 Thread Stephen Rothwell

Hi all,

After merging the amdgpu tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c: In function 
'vangogh_get_smu_metrics_data':
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:300:10: error: 
'boot_cpu_data' undeclared (first use in this function); did you mean 
'boot_cpuid'?
  300 |  boot_cpu_data.x86_max_cores * sizeof(uint16_t));
  |  ^
  |  boot_cpuid
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c: In function 
'vangogh_read_sensor':
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1320:11: error: 
'boot_cpu_data' undeclared (first use in this function); did you mean 
'boot_cpuid'?
 1320 |   *size = boot_cpu_data.x86_max_cores * sizeof(uint16_t);
  |   ^
  |   boot_cpuid
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c: In function 
'vangogh_od_edit_dpm_table':
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1460:19: error: 
'boot_cpu_data' undeclared (first use in this function); did you mean 
'boot_cpuid'?
 1460 |   if (input[0] >= boot_cpu_data.x86_max_cores) {
  |   ^
  |   boot_cpuid

Caused by commits

  517cb957c43b ("drm/amd/pm: implement the processor clocks which read by 
metric")
  0d90d0ddd10e ("drm/amd/pm: implement processor fine grain feature for vangogh 
(v3)")

The only thing I could do easily is to disable CONFIG_DRM_AMDGPU for today.

-- 
Cheers,
Stephen Rothwell


pgp6AvAOeDolz.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 6/7] dt-bindings: regulator: qcom-labibb: Document SCP/OCP interrupts

On Wed 13 Jan 13:42 CST 2021, AngeloGioacchino Del Regno wrote:

> Short-Circuit Protection (SCP) and Over-Current Protection (OCP) are
> now implemented in the driver: document the interrupts.
> This also fixes wrong documentation about the SCP interrupt for LAB.
> 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  .../regulator/qcom-labibb-regulator.yaml  | 20 +++
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml 
> b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
> index 7a507692f1ba..cf784bd1f5e5 100644
> --- a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
> +++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
> @@ -29,9 +29,10 @@ properties:
>  default: 200
>  
>interrupts:
> -maxItems: 1
> +minItems: 1
> +maxItems: 2
>  description:
> -  Short-circuit interrupt for lab.
> +  Short-circuit and over-current interrupts for lab.
>  
>  required:
>- interrupts
> @@ -47,9 +48,10 @@ properties:
>  default: 300
>  
>interrupts:
> -maxItems: 1
> +minItems: 1
> +maxItems: 2
>  description:
> -  Short-circuit interrupt for lab.
> +  Short-circuit and over-current interrupts for ibb.
>  
>  required:
>- interrupts
> @@ -67,13 +69,15 @@ examples:
>compatible = "qcom,pmi8998-lab-ibb";
>  
>lab {
> -interrupts = <0x3 0x0 IRQ_TYPE_EDGE_RISING>;
> -interrupt-names = "sc-err";
> +interrupts = <0x3 0xde 0x1 IRQ_TYPE_EDGE_RISING>,
> + <0x3 0xde 0x0 IRQ_TYPE_LEVEL_LOW>;
> +interrupt-names = "sc-err", "ocp";
>};
>  
>ibb {
> -interrupts = <0x3 0x2 IRQ_TYPE_EDGE_RISING>;
> -interrupt-names = "sc-err";
> +interrupts = <0x3 0xdc 0x2 IRQ_TYPE_EDGE_RISING>,
> + <0x3 0xdc 0x0 IRQ_TYPE_LEVEL_LOW>;
> +interrupt-names = "sc-err", "ocp";
>};
>  };
>  
> -- 
> 2.29.2
>

Re: [PATCH] HID: google: Get HID report on probe to confirm tablet switch state

2021-01-14 Thread Nicolas Boichat

On Thu, Jan 14, 2021 at 8:15 PM Jiri Kosina  wrote:
>
> On Thu, 24 Dec 2020, Nicolas Boichat wrote:
>
> > This forces reading the base folded status anytime the device is
> > probed.
>
> Could you please provide a little bit more verbose changelog (namely what
> is the actual problem this patch is fixing)? Thanks.

Sure, I should have done this in the first place... v2 on the way.

>
> --
> Jiri Kosina
> SUSE Labs
>

Re: [PATCH v2 5/7] regulator: qcom-labibb: Implement short-circuit and over-current IRQs

On Wed 13 Jan 13:42 CST 2021, AngeloGioacchino Del Regno wrote:

> Short-Circuit Protection (SCP) and Over-Current Protection (OCP) are
> very important for regulators like LAB and IBB, which are designed to
> provide from very small to relatively big amounts of current to the
> device (normally, a display).
> 
> Now that this regulator supports both voltage setting and current
> limiting in this driver, to me it looked like being somehow essential
> to provide support for SCP and OCP, for two reasons:
> 1. SCP is a drastic measure to prevent damaging "more" hardware in
>the worst situations, if any was damaged, preventing potentially
>drastic issues;
> 2. OCP is a great way to protect the hardware that we're powering
>through these regulators as if anything bad happens, the HW will
>draw more current than expected: in this case, the OCP interrupt
>will fire and the regulators will be immediately shut down,
>preventing hardware damage in many cases.

So when the OCP fires it stops the regulator? Is it automatically
enabled by the re-enabling of the OCP interrupt (if so please mention
this in a comment or so in the code), or does it simply signal the
client driver and it will have to re-enable the regulator?

> 
> Both interrupts were successfully tested in a "sort-of" controlled
> manner, with the following methodology:
> 
> Short-Circuit Protection (SCP):
> 1. Set LAB/IBB to 4.6/-1.4V, current limit 200mA/50mA;
> 2. Connect a 10 KOhm resistor to LAB/IBB by poking the right traces
>on a FxTec Pro1 smartphone for a very brief time (in short words,
>"just a rapid touch with flying wires");
> 3. The Short-Circuit protection trips: IRQ raises, regulators get
>cut. Recovery OK, test repeated without rebooting, OK.
> 
> Over-Current Protection (OCP):
> 1. Set LAB/IBB to the expected voltage to power up the display of
>a Sony Xperia XZ Premium smartphone (Sharp LS055D1SX04), set
>current limit to LAB 200mA, IBB 50mA (the values that this
>display unit needs are 200/800mA);
> 2. Boot the kernel: OCP fires. Recovery never happens because
>the selected current limit is too low, but that's expected.
>Test OK.
> 
> 3. Set LAB/IBB to the expected current limits for XZ Premium
>(LAB 200mA, IBB 800mA), but lower than expected voltage,
>specifically LAB 5.4V, IBB -5.6V (instead of 5.6, -5.8V);
> 4. Boot the kernel: OCP fires. Recovery never happens because
>the selected voltage (still in the working range limits)
>is producing a current draw of more than 200mA on LAB.
>Test OK.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  drivers/regulator/qcom-labibb-regulator.c | 447 +-
>  1 file changed, 444 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/regulator/qcom-labibb-regulator.c 
> b/drivers/regulator/qcom-labibb-regulator.c
> index 38ab1eba1c59..38763625241e 100644
> --- a/drivers/regulator/qcom-labibb-regulator.c
> +++ b/drivers/regulator/qcom-labibb-regulator.c
> @@ -17,8 +17,20 @@
>  
>  #define PMI8998_LAB_REG_BASE 0xde00
>  #define PMI8998_IBB_REG_BASE 0xdc00
> +#define PMI8998_IBB_LAB_REG_OFFSET   0x200
>  
>  #define REG_LABIBB_STATUS1   0x08
> + #define LABIBB_STATUS1_SC_BIT   BIT(6)
> + #define LABIBB_STATUS1_VREG_OK_BIT  BIT(7)
> +
> +#define REG_LABIBB_INT_SET_TYPE  0x11
> +#define REG_LABIBB_INT_POLARITY_HIGH 0x12
> +#define REG_LABIBB_INT_POLARITY_LOW  0x13
> +#define REG_LABIBB_INT_LATCHED_CLR   0x14
> +#define REG_LABIBB_INT_EN_SET0x15
> +#define REG_LABIBB_INT_EN_CLR0x16
> + #define LABIBB_INT_VREG_OK  BIT(0)
> + #define LABIBB_INT_VREG_TYPE_LEVEL  0
>  
>  #define REG_LABIBB_VOLTAGE   0x41
>   #define LABIBB_VOLTAGE_OVERRIDE_EN  BIT(7)
> @@ -26,8 +38,7 @@
>   #define IBB_VOLTAGE_SET_MASKGENMASK(5, 0)
>  
>  #define REG_LABIBB_ENABLE_CTL0x46
> -#define LABIBB_STATUS1_VREG_OK_BIT   BIT(7)
> -#define LABIBB_CONTROL_ENABLEBIT(7)
> + #define LABIBB_CONTROL_ENABLE   BIT(7)
>  
>  #define REG_LABIBB_PD_CTL0x47
>   #define LAB_PD_CTL_MASK GENMASK(1, 0)
> @@ -56,6 +67,11 @@
>  #define LAB_ENABLE_TIME  (LABIBB_OFF_ON_DELAY * 2)
>  #define IBB_ENABLE_TIME  (LABIBB_OFF_ON_DELAY * 10)
>  #define LABIBB_POLL_ENABLED_TIME 1000
> +#define OCP_RECOVERY_INTERVAL_MS 500
> +#define SC_RECOVERY_INTERVAL_MS  250
> +#define LABIBB_MAX_OCP_COUNT 4
> +#define LABIBB_MAX_SC_COUNT  3
> +#define LABIBB_MAX_FATAL_COUNT   2
>  
>  struct labibb_current_limits {
>   u32 uA_min;
> @@ -69,10 +85,17 @@ struct labibb_regulator {
>   struct regmap   *regmap;
>   struct regulator_dev*rdev;
>   struct labibb_current_limitsuA_limits;
> + struct delayed_work ocp_recovery_work;

Re: [PATCH v6 06/33] of/device: Move dma_range_map before of_iommu_configure

2021-01-14 Thread Yong Wu

On Thu, 2021-01-14 at 13:27 -0600, Rob Herring wrote:
> On Mon, Jan 11, 2021 at 07:18:47PM +0800, Yong Wu wrote:
> > "dev->dma_range_map" contains the devices' dma_ranges information,
> > This patch moves dma_range_map before of_iommu_configure. The iommu
> > driver may need to know the dma_address requirements of its iommu
> > consumer devices.
> > 
> > CC: Rob Herring 
> > CC: Frank Rowand 
> > Signed-off-by: Yong Wu 
> > ---
> >  drivers/of/device.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > index aedfaaafd3e7..1d84636149df 100644
> > --- a/drivers/of/device.c
> > +++ b/drivers/of/device.c
> > @@ -170,9 +170,11 @@ int of_dma_configure_id(struct device *dev, struct 
> > device_node *np,
> > dev_dbg(dev, "device is%sdma coherent\n",
> > coherent ? " " : " not ");
> >  
> > +   dev->dma_range_map = map;
> > iommu = of_iommu_configure(dev, np, id);
> > if (PTR_ERR(iommu) == -EPROBE_DEFER) {
> > kfree(map);
> > +   dev->dma_range_map = NULL;
> 
> Not really going to matter, but you should probably clear dma_range_map 
> before what it points to is freed.
> 
> With that,
> 
> Reviewed-by: Rob Herring 

Thanks for the review. I will move it before "kfree(map)" in next
version.

> 
> > return -EPROBE_DEFER;
> > }
> >  
> > @@ -181,7 +183,6 @@ int of_dma_configure_id(struct device *dev, struct 
> > device_node *np,
> >  
> > arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
> >  
> > -   dev->dma_range_map = map;
> > return 0;
> >  }
> >  EXPORT_SYMBOL_GPL(of_dma_configure_id);
> > -- 
> > 2.18.0
> >

Re: [PATCH V2 10/11] coresight: sink: Add TRBE driver

2021-01-14 Thread Anshuman Khandual




On 1/13/21 8:58 PM, Suzuki K Poulose wrote:
> Hi Anshuman,
> 
> The driver looks overall good to me. Please find some minor comments below
> 
> On 1/13/21 4:18 AM, Anshuman Khandual wrote:
>> Trace Buffer Extension (TRBE) implements a trace buffer per CPU which is
>> accessible via the system registers. The TRBE supports different addressing
>> modes including CPU virtual address and buffer modes including the circular
>> buffer mode. The TRBE buffer is addressed by a base pointer (TRBBASER_EL1),
>> an write pointer (TRBPTR_EL1) and a limit pointer (TRBLIMITR_EL1). But the
>> access to the trace buffer could be prohibited by a higher exception level
>> (EL3 or EL2), indicated by TRBIDR_EL1.P. The TRBE can also generate a CPU
>> private interrupt (PPI) on address translation errors and when the buffer
>> is full. Overall implementation here is inspired from the Arm SPE driver.
>>
>> Cc: Mathieu Poirier 
>> Cc: Mike Leach 
>> Cc: Suzuki K Poulose 
>> Signed-off-by: Anshuman Khandual 
>> ---
>> Changes in V2:
>>
>> - Dropped irq from coresight sysfs documentation
>> - Renamed get_trbe_limit() as compute_trbe_buffer_limit()
>> - Dropped SYSTEM_RUNNING check for system_state
>> - Dropped .data value from arm_trbe_of_match[]
>> - Dropped [set|get]_trbe_[trig|fill]_mode() helpers
>> - Dropped clearing TRBSR_FSC_MASK from TRBE status register
>> - Added a comment in arm_trbe_update_buffer()
>> - Updated comment for ETE_IGNORE_PACKET
>> - Updated comment for basic TRBE operation
>> - Updated TRBE buffer and trigger mode macros
>> - Restructured trbe_enable_hw()
>> - Updated trbe_snapshot_offset() to use the entire buffer
>> - Changed dsb(ish) as dsb(nsh) during the buffer flush
>> - Renamed set_trbe_flush() as trbe_drain_buffer()
>> - Renamed trbe_disable_and_drain_local() as trbe_drain_and_disable_local()
>> - Reworked sync in trbe_enable_hw(), trbe_update_buffer() and 
>> arm_trbe_irq_handler()
>>
>>   Documentation/trace/coresight/coresight-trbe.rst |  39 +
>>   arch/arm64/include/asm/sysreg.h  |   2 +
>>   drivers/hwtracing/coresight/Kconfig  |  11 +
>>   drivers/hwtracing/coresight/Makefile |   1 +
>>   drivers/hwtracing/coresight/coresight-trbe.c | 966 
>> +++
>>   drivers/hwtracing/coresight/coresight-trbe.h | 216 +
>>   6 files changed, 1235 insertions(+)
>>   create mode 100644 Documentation/trace/coresight/coresight-trbe.rst
>>   create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
>>   create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h
>>
>> diff --git a/Documentation/trace/coresight/coresight-trbe.rst 
>> b/Documentation/trace/coresight/coresight-trbe.rst
>> new file mode 100644
>> index 000..1cbb819
>> --- /dev/null
>> +++ b/Documentation/trace/coresight/coresight-trbe.rst
>> @@ -0,0 +1,39 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +==
>> +Trace Buffer Extension (TRBE).
>> +==
>> +
>> +    :Author:   Anshuman Khandual 
>> +    :Date: November 2020
>> +
>> +Hardware Description
>> +
>> +
>> +Trace Buffer Extension (TRBE) is a percpu hardware which captures in system
>> +memory, CPU traces generated from a corresponding percpu tracing unit. This
>> +gets plugged in as a coresight sink device because the corresponding trace
>> +genarators (ETE), are plugged in as source device.
>> +
>> +The TRBE is not compliant to CoreSight architecture specifications, but is
>> +driven via the CoreSight driver framework to support the ETE (which is
>> +CoreSight compliant) integration.
>> +
>> +Sysfs files and directories
>> +---
>> +
>> +The TRBE devices appear on the existing coresight bus alongside the other
>> +coresight devices::
>> +
>> +    >$ ls /sys/bus/coresight/devices
>> +    trbe0  trbe1  trbe2 trbe3
>> +
>> +The ``trbe`` named TRBEs are associated with a CPU.::
>> +
>> +    >$ ls /sys/bus/coresight/devices/trbe0/
>> +    align dbm
>> +
>> +*Key file items are:-*
>> +   * ``align``: TRBE write pointer alignment
>> +   * ``dbm``: TRBE updates memory with access and dirty flags
>> +
>> diff --git a/arch/arm64/include/asm/sysreg.h 
>> b/arch/arm64/include/asm/sysreg.h
>> index d60750e7..d7e65f0 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -97,6 +97,7 @@
>>   #define SET_PSTATE_UAO(x)    __emit_inst(0xd500401f | PSTATE_UAO | 
>> ((!!x) << PSTATE_Imm_shift))
>>   #define SET_PSTATE_SSBS(x)    __emit_inst(0xd500401f | PSTATE_SSBS | 
>> ((!!x) << PSTATE_Imm_shift))
>>   #define SET_PSTATE_TCO(x)    __emit_inst(0xd500401f | PSTATE_TCO | 
>> ((!!x) << PSTATE_Imm_shift))
>> +#define TSB_CSYNC    __emit_inst(0xd503225f)
>>     #define set_pstate_pan(x)    asm volatile(SET_PSTATE_PAN(x))
>>   #define set_pstate_uao(x)    asm volatile(SET_PSTATE_UAO(x))
>> @@ -880,6 +881,7 @@
>>   #define ID_AA64MMFR2_CNP_SHIFT    0
>>     /

Re: [PATCH 15/21] x86/xen/pvh: Convert indirect jump to retpoline

2021-01-14 Thread Jürgen Groß


On 14.01.21 20:40, Josh Poimboeuf wrote:

It's kernel policy to not have (unannotated) indirect jumps because of
Spectre v2.  This one's probably harmless, but better safe than sorry.
Convert it to a retpoline.

Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Signed-off-by: Josh Poimboeuf 
---
  arch/x86/platform/pvh/head.S | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S
index 43b4d864817e..d87cebd08d32 100644
--- a/arch/x86/platform/pvh/head.S
+++ b/arch/x86/platform/pvh/head.S
@@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  	__HEAD

@@ -105,7 +106,7 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
/* startup_64 expects boot_params in %rsi. */
mov $_pa(pvh_bootparams), %rsi
mov $_pa(startup_64), %rax
-   jmp *%rax
+   JMP_NOSPEC rax


I'd rather have it annotated only.

Using ALTERNATIVE in very early boot code is just adding needless
clutter, as the retpoline variant won't ever be active.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 00/21] objtool: vmlinux.o and CLANG LTO support

2021-01-14 Thread Sedat Dilek

On Fri, Jan 15, 2021 at 5:51 AM Sedat Dilek  wrote:
>
> On Thu, Jan 14, 2021 at 8:40 PM Josh Poimboeuf  wrote:
> >
> > Add support for proper vmlinux.o validation, which will be needed for
> > Sami's upcoming x86 LTO set.  (And vmlinux validation is the future for
> > objtool anyway, for other reasons.)
> >
> > This isn't 100% done -- most notably, crypto still needs to be supported
> > -- but I think this gets us most of the way there.
> >
> > This can also be found at
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git 
> > objtool-vmlinux
> >
> > And for more testing it can be combined with Sami's x86 LTO patches:
> >
> >   https://github.com/samitolvanen/linux clang-lto
> >
> >
> >
> > Josh Poimboeuf (21):
> >   objtool: Fix seg fault in BT_FUNC() with fake jump
> >   objtool: Fix error handling for STD/CLD warnings
> >   objtool: Fix retpoline detection in asm code
> >   objtool: Fix ".cold" section suffix check for newer versions of GCC
> >   objtool: Support retpoline jump detection for vmlinux.o
> >   x86/ftrace: Add UNWIND_HINT_FUNC annotation for ftrace_stub
> >   objtool: Assume only ELF functions do sibling calls
> >   objtool: Add asm version of STACK_FRAME_NON_STANDARD
> >   objtool: Combine UNWIND_HINT_RET_OFFSET and UNWIND_HINT_FUNC
> >   objtool: Add xen_start_kernel() to noreturn list
> >   objtool: Move unsuffixed symbol conversion to a helper function
> >   objtool: Add CONFIG_CFI_CLANG support
> >   x86/xen: Support objtool validation in xen-asm.S
> >   x86/xen: Support objtool vmlinux.o validation in xen-head.S
> >   x86/xen/pvh: Convert indirect jump to retpoline
> >   x86/ftrace: Support objtool vmlinux.o validation in ftrace_64.S
> >   x86/acpi: Convert indirect jump to retpoline
> >   x86/acpi: Support objtool validation in wakeup_64.S
> >   x86/power: Convert indirect jumps to retpolines
> >   x86/power: Move restore_registers() to top of the file
> >   x86/power: Support objtool validation in hibernate_asm_64.S
> >
> >  arch/x86/include/asm/unwind_hints.h |  13 +---
> >  arch/x86/kernel/acpi/Makefile   |   1 -
> >  arch/x86/kernel/acpi/wakeup_64.S|   5 +-
> >  arch/x86/kernel/ftrace_64.S |   8 +--
> >  arch/x86/lib/retpoline.S|   2 +-
> >  arch/x86/platform/pvh/head.S|   3 +-
> >  arch/x86/power/Makefile |   1 -
> >  arch/x86/power/hibernate_asm_64.S   | 105 ++--
> >  arch/x86/xen/Makefile   |   1 -
> >  arch/x86/xen/xen-asm.S  |  29 +---
> >  arch/x86/xen/xen-head.S |   5 +-
> >  include/linux/objtool.h |  13 +++-
> >  tools/include/linux/objtool.h   |  13 +++-
> >  tools/objtool/arch/x86/decode.c |   4 +-
> >  tools/objtool/arch/x86/special.c|   2 +-
> >  tools/objtool/check.c   |  91 +---
> >  tools/objtool/check.h   |  12 +++-
> >  tools/objtool/elf.c |  87 +--
> >  tools/objtool/elf.h |   2 +-
> >  19 files changed, 241 insertions(+), 156 deletions(-)
> >
> > --
> > 2.29.2
> >
>
> I tried this series on top of clang-cfi and it segfaults here.
>
> + info OBJTOOL vmlinux.o
> + [  != silent_ ]
> + printf   %-7s %s\n OBJTOOL vmlinux.o
>  OBJTOOL vmlinux.o
> + tools/objtool/objtool orc generate --duplicate --mcount --vmlinux
> --no-fp --no-unreachable --retpoline --uaccess vmlinux.o
> Segmentation fault
> + on_exit
> + [ 139 -ne 0 ]
> + cleanup
> + rm -f .btf.*
> + rm -f .tmp_System.map
> + rm -f .tmp_initcalls.lds
> + rm -f .tmp_symversions.lds
> + rm -f .tmp_vmlinux*
> + rm -f System.map
> + rm -f vmlinux
> + rm -f vmlinux.o
> make[3]: *** [Makefile:1213: vmlinux] Error 139
>

I did:

$ git diff scripts/link-vmlinux.sh
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 2d0b28758aa5..cd0948bd29ea 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -142,7 +142,8 @@ objtool_link()
   objtoolopt="${objtoolopt} --uaccess"
   fi
   info OBJTOOL ${1}
-   tools/objtool/objtool ${objtoolcmd} ${objtoolopt} ${1}
+   info OBJTOOL SEGFAULTS
+   ##tools/objtool/objtool ${objtoolcmd} ${objtoolopt} ${1}
   fi
}

To save the vmlinux* files and archived them in case you want me to look at it.
Give me clear instructions, Thanks.

- Sedat -

Re: [PATCH 14/21] x86/xen: Support objtool vmlinux.o validation in xen-head.S

2021-01-14 Thread Jürgen Groß


On 14.01.21 20:40, Josh Poimboeuf wrote:

The Xen hypercall page is filled with zeros, causing objtool to fall
through all the empty hypercall functions until it reaches a real
function, resulting in a stack state mismatch.

The build-time contents of the hypercall page don't matter, since it
gets mapped to the hypervisor.


This sentence is technically wrong: the contents don't matter, as the
page will be rewritten by the hypervisor.


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v3 10/21] x86/fpu/xstate: Update xstate save function to support dynamic xstate

2021-01-14 Thread Bae, Chang Seok


> On Jan 11, 2021, at 18:52, Liu, Jing2  wrote:
> 
> On 1/8/2021 2:40 AM, Bae, Chang Seok wrote:
>>> On Jan 7, 2021, at 17:41, Liu, Jing2  wrote:
>>> 
>>> static void kvm_save_current_fpu(struct fpu *fpu)  {
>>> +   struct fpu *src_fpu = ¤t->thread.fpu;
>>> +
>>> /*
>>>  * If the target FPU state is not resident in the CPU registers, just
>>>  * memcpy() from current, else save CPU state directly to the target.
>>>  */
>>> -   if (test_thread_flag(TIF_NEED_FPU_LOAD))
>>> -   memcpy(&fpu->state, ¤t->thread.fpu.state,
>>> +   if (test_thread_flag(TIF_NEED_FPU_LOAD)) {
>>> +   memcpy(&fpu->state, &src_fpu->state,
>>>fpu_kernel_xstate_min_size);



>>> -   else
>>> +   } else {
>>> +   if (fpu->state_mask != src_fpu->state_mask)
>>> +   fpu->state_mask = src_fpu->state_mask;
>>> 
>>> Though dynamic feature is not supported in kvm now, this function still need
>>> consider more things for fpu->state_mask.
>> Can you elaborate this? Which path might be affected by fpu->state_mask
>> without dynamic state supported in KVM?
>> 
>>> I suggest that we can set it before if...else (for both cases) and not 
>>> change other.
>> I tried a minimum change here.  The fpu->state_mask value does not impact the
>> memcpy(). So, why do we need to change it for both?
> 
> Sure, what I'm considering is that "mask" is the first time introduced into 
> "fpu",
> representing the usage, so not only set it when needed, but also make it as a
> representation, in case of anywhere using it (especially between the interval
> of this series and kvm series in future).

Thank you for the feedback. Sorry, I don't get any logical reason to set the
mask always here. Perhaps, KVM code can be updated like you mentioned when
supporting the dynamic states there.

Please let me know if I’m missing any functional issues.

Thanks,
Chang

[git pull] drm nouveau ampere modesetting support

2021-01-14 Thread Dave Airlie

Hi Linus,

As mentioned in the previous pull, Ben has requested if we can include
Ampere modesetting support under fixes, it's for new GPUs and
shouldn't affect existing hardware. It's a bit bigger than just adding
a PCI ID, and I'm fine if you think we should hold it off until later.

Dave.

topic/nouveau-ampere-modeset-2021-01-15:
drm nouveau ampere display support.

This is a pull request to add display support for new Ampere hardware.

It has no effect on older GPUs.
The following changes since commit c8f6364f35f32786dd40336cfa35b9166d91b8ab:

  Merge branch '04.00-ampere-lite-fixes' of
git://github.com/skeggsb/linux into drm-fixes (2021-01-15 13:26:44
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm
tags/topic/nouveau-ampere-modeset-2021-01-15

for you to fetch changes up to 584265dfec70e78ce2085b82ed389f27e06fbca0:

  Merge branch '04.01-ampere-lite' of git://github.com/skeggsb/linux
into topic/nouveau-ampere-modeset (2021-01-15 14:48:18 +1000)


drm nouveau ampere display support.

This is a pull request to add display support for new Ampere hardware.

It has no effect on older GPUs.


Ben Skeggs (15):
  drm/nouveau/core: recognise GA10[024]
  drm/nouveau/pci/ga10[024]: initial support
  drm/nouveau/bios/ga10[024]: initial support
  drm/nouveau/devinit/ga10[024]: initial support
  drm/nouveau/mc/ga10[024]: initial support
  drm/nouveau/privring/ga10[024]: initial support
  drm/nouveau/imem/ga10[024]: initial support
  drm/nouveau/fb/ga10[024]: initial support
  drm/nouveau/timer/ga10[024]: initial support
  drm/nouveau/mmu/ga10[024]: initial support
  drm/nouveau/bar/ga10[024]: initial support
  drm/nouveau/gpio/ga10[024]: initial support
  drm/nouveau/i2c/ga10[024]: initial support
  drm/nouveau/dmaobj/ga10[24]: initial support
  drm/nouveau/disp/ga10[24]: initial support

Dave Airlie (1):
  Merge branch '04.01-ampere-lite' of
git://github.com/skeggsb/linux into topic/nouveau-ampere-modeset

 drivers/gpu/drm/nouveau/dispnv50/Kbuild|   1 +
 drivers/gpu/drm/nouveau/dispnv50/core.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/curs.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wimm.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wndw.c|   1 +
 drivers/gpu/drm/nouveau/dispnv50/wndw.h|   8 ++
 drivers/gpu/drm/nouveau/dispnv50/wndwc57e.c|  10 +-
 drivers/gpu/drm/nouveau/dispnv50/wndwc67e.c| 106 
 drivers/gpu/drm/nouveau/include/nvif/cl0080.h  |   1 +
 drivers/gpu/drm/nouveau/include/nvif/class.h   |   5 +
 drivers/gpu/drm/nouveau/include/nvkm/core/device.h |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/engine/disp.h |   1 +
 .../gpu/drm/nouveau/include/nvkm/subdev/devinit.h  |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h   |   2 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/gpio.h |   1 +
 drivers/gpu/drm/nouveau/include/nvkm/subdev/mc.h   |   1 +
 drivers/gpu/drm/nouveau/nouveau_backlight.c|   1 +
 drivers/gpu/drm/nouveau/nvif/disp.c|   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  75 ++-
 drivers/gpu/drm/nouveau/nvkm/engine/device/user.c  |   1 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild|   3 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c  |  33 -
 drivers/gpu/drm/nouveau/nvkm/engine/disp/ga102.c   |  46 +++
 drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h |   4 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.h|   2 +
 .../gpu/drm/nouveau/nvkm/engine/disp/rootga102.c   |  52 
 .../gpu/drm/nouveau/nvkm/engine/disp/rootnv50.h|   1 +
 .../gpu/drm/nouveau/nvkm/engine/disp/sorga102.c| 140 +
 .../gpu/drm/nouveau/nvkm/engine/disp/sortu102.c|   2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/tu102.c   |   2 +-
 .../gpu/drm/nouveau/nvkm/subdev/bios/shadowramin.c |   3 +
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/Kbuild |   1 +
 .../gpu/drm/nouveau/nvkm/subdev/devinit/ga100.c|  76 +++
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/priv.h |   1 +
 .../gpu/drm/nouveau/nvkm/subdev/devinit/tu102.c|   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild  |   3 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga100.c |  40 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga102.c |  40 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gv100.c |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h  |   2 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h   |   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramga102.c  |  40 ++
 drivers/gpu/drm/nouveau/nvkm/subdev/gpio/Kbuild|   1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/gpio/ga102.c   | 118 +
 drivers/gpu/drm/nouveau/nvkm/subdev/mc/Kbuild  |   1 +
 drivers/gpu/drm/nouveau/

Re: [PATCH v2 4/7] dt-bindings: regulator: qcom-labibb: Document soft start properties

On Wed 13 Jan 13:42 CST 2021, AngeloGioacchino Del Regno wrote:

> Document properties to configure soft start and discharge resistor
> for LAB and IBB respectively.
> 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  .../bindings/regulator/qcom-labibb-regulator.yaml  | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml 
> b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
> index 53853ec20fe2..7a507692f1ba 100644
> --- a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
> +++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
> @@ -22,6 +22,11 @@ properties:
>  type: object
>  
>  properties:
> +  qcom,soft-start-us:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Regulator soft start time in microseconds.
> +enum: [200, 400, 600, 800]
> +default: 200
>  
>interrupts:
>  maxItems: 1
> @@ -35,6 +40,11 @@ properties:
>  type: object
>  
>  properties:
> +  qcom,discharge-resistor-kohms:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Discharge resistor value in KiloOhms.
> +enum: [300, 64, 32, 16]
> +default: 300
>  
>interrupts:
>  maxItems: 1
> -- 
> 2.29.2
>

Re: [PATCH v2 3/7] regulator: qcom-labibb: Implement pull-down, softstart, active discharge