Re: [PATCH net-next v2 01/11] dt-bindings: net: dsa: convert ksz bindings document to yaml

[Christian Eggers]

On Monday, 16 November 2020, 15:37:20 CET, Rob Herring wrote:
> On Thu, 12 Nov 2020 16:35:27 +0100, Christian Eggers wrote:
> > Convert the bindings document for Microchip KSZ Series Ethernet switches
> > from txt to yaml.
> > 
> > Signed-off-by: Christian Eggers 
> > ---
> > 
> >  .../devicetree/bindings/net/dsa/ksz.txt   | 125 ---
> >  .../bindings/net/dsa/microchip,ksz.yaml   | 150 ++
> >  MAINTAINERS   |   2 +-
> >  3 files changed, 151 insertions(+), 126 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/net/dsa/ksz.txt
> >  create mode 100644
> >  Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/dsa
> /microchip,ksz.yaml: 'oneOf' conditional failed, one must be fixed:
> 'unevaluatedProperties' is a required property
>   'additionalProperties' is a required property
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/dsa
> /microchip,ksz.yaml: ignoring, error in schema: warning: no schema found in
> file: ./Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> 
> 
> See https://patchwork.ozlabs.org/patch/1399036
> 
> The base for the patch is generally the last rc1. Any dependencies
> should be noted.
> 
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit.

with the latest dtschema I get further warnings:

/home/.../build-net-next/Documentation/devicetree/bindings/net/dsa/microchip,ksz.example.dt.yaml:
 switch@0: 'ethernet-ports', 'reg', 'spi-cpha', 'spi-cpol', 'spi-max-frequency' 
do not match any of the regexes: 'pinctrl-[0-9]+'
From schema: 
/home/.../Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
/home/.../build-net-next/Documentation/devicetree/bindings/net/dsa/microchip,ksz.example.dt.yaml:
 switch@1: 'ethernet-ports', 'reg', 'spi-cpha', 'spi-cpol', 'spi-max-frequency' 
do not match any of the regexes: 'pinctrl-[0-9]+'
From schema: 
/home/.../Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml

Which schema requires the regex 'pinctrl-[0-9]+'? I have tried to add pinctrl-0
properties to the switch@0 and switch@1 nodes, but that didn't help.

Current version of microchip,ksz.yaml is below.

regards
Christian


# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/dsa/microchip,ksz.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Microchip KSZ Series Ethernet switches

allOf:
  - $ref: dsa.yaml#

maintainers:
  - Marek Vasut 
  - Woojung Huh 

properties:
  # See Documentation/devicetree/bindings/net/dsa/dsa.yaml for a list of 
additional
  # required and optional properties.
  compatible:
enum:
  - microchip,ksz8765
  - microchip,ksz8794
  - microchip,ksz8795
  - microchip,ksz9477
  - microchip,ksz9897
  - microchip,ksz9896
  - microchip,ksz9567
  - microchip,ksz8565
  - microchip,ksz9893
  - microchip,ksz9563
  - microchip,ksz8563

  reset-gpios:
description:
  Should be a gpio specifier for a reset line.
maxItems: 1

  interrupts:
description:
  Interrupt specifier for the INTRP_N line from the device.
maxItems: 1

  microchip,synclko-125:
$ref: /schemas/types.yaml#/definitions/flag
description:
  Set if the output SYNCLKO frequency should be set to 125MHz instead of 
25MHz.

required:
  - compatible
  - reg

additionalProperties: false

examples:
  - |
#include 
#include 

// Ethernet switch connected via SPI to the host, CPU port wired to eth0:
eth0 {
fixed-link {
speed = <1000>;
full-duplex;
};
};

spi0 {
#address-cells = <1>;
#size-cells = <0>;

pinctrl-0 = <&pinctrl_spi_ksz>;
cs-gpios = <&pioC 25 0>;
id = <1>;

ksz9477: switch@0 {
compatible = "microchip,ksz9477";
reg = <0>;
reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
interrupts-extended = <&gpio5 1 IRQ_TYPE_LEVEL_LOW>;  /* INTRP_N 
line */

spi-max-frequency = <4400>;
spi-cpha;
spi-cpol;

ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan1";
};
port@1 {
reg = <1>;
label = "lan2";
};
port@2 {
reg = <2>;
label = "lan3";
};
port@3 {
r

Re: [FIX bpf,perf] bpf,perf: return EOPNOTSUPP for bpf handler on PERF_COUNT_SW_DUMMY

[Peter Zijlstra]

On Mon, Nov 16, 2020 at 01:02:09PM -0800, Martin KaFai Lau wrote:
> On Mon, Nov 16, 2020 at 07:37:52PM +0100, Florian Lehner wrote:
> > bpf handlers for perf events other than tracepoints, kprobes or uprobes
> > are attached to the overflow_handler of the perf event.
> > 
> > Perf events of type software/dummy are placeholder events. So when
> > attaching a bpf handle to an overflow_handler of such an event, the bpf
> > handler will not be triggered.
> > 
> > This fix returns the error EOPNOTSUPP to indicate that attaching a bpf
> > handler to a perf event of type software/dummy is not supported.
> > 
> > Signed-off-by: Florian Lehner 
> It is missing a Fixes tag.

I don't think it actually fixes anything. worse it could break things.

Atatching a bpf filter to a dummy event is pointless, but harmless. We
allow it now, disallowing it will break whatever programs out there are
doing harmless silly things.

I really don't see the point of this patch. It grows the kernel code for
absolutely no distinguishable benefit.

Re: [RFC][PATCH v2 00/21] x86/pti: Defer CR3 switch to C code

[Alexandre Chartre]

On 11/16/20 9:17 PM, Borislav Petkov wrote:

On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote:

This RFC proposes to defer the PTI CR3 switch until we reach C code.
The benefit is that this simplifies the assembly entry code, and make
the PTI CR3 switch code easier to understand. This also paves the way
for further possible projects such an easier integration of Address
Space Isolation (ASI), or the possibility to execute some selected
syscall or interrupt handlers without switching to the kernel page-table


What for? What is this going to be used for in the end?



In addition to simplify the assembly entry code, this will also simplify
the integration of Address Space Isolation (ASI) which will certainly be
the primary beneficiary of this change. The main goal of ASI is to provide
KVM address space isolation to mitigate guest-to-host speculative attacks
like L1TF or MDS. Current proposal of ASI is plugged into the CR3 switch
assembly macro which make the code brittle and complex. (see [1])

I am also expected this might help with some other ideas like having
syscall (or interrupt handler) which can run without switching the
page-table.



(and thus avoid the PTI page-table switch overhead).


Overhead of how much? Why do we care?



PTI has a measured overhead of roughly 5% for most workloads, but it can
be much higher in some cases. The overhead is mostly due to the page-table
switch (even with PCID) so if we can run a syscall or an interrupt handler
without switching the page-table then we can get this kind of performance
back.



What is the big picture justfication for this diffstat


  21 files changed, 874 insertions(+), 314 deletions(-)


and the diffstat for the ASI enablement?



The latest ASI RFC (RFC v4) is here [1]. This RFC has ASI plugged directly into
the CR3 switch assembly macro. We are working on a new implementation, based
on these changes which avoid having to deal with assembly code and makes the
implementation more robust.

alex.

[1] ASI RFCv4 - 
https://lore.kernel.org/lkml/20200504144939.11318-1-alexandre.char...@oracle.com/

suspicious capability check in ovl_ioctl_set_flags

[Dmitry Vyukov]

Hi Miklos,

We've detected a suspicious double-fetch of user-space data in
ovl_ioctl_set_flags using a prototype tool (see report below [1]).

It points to ovl_ioctl_set_flags that does a capability check using
flags, but then the real ioctl double-fetches flags and uses
potentially different value:

static long ovl_ioctl_set_flags(struct file *file, unsigned int cmd,
unsigned long arg, unsigned int flags)
{
...
/* Check the capability before cred override */
oldflags = ovl_iflags_to_fsflags(READ_ONCE(inode->i_flags));
ret = vfs_ioc_setflags_prepare(inode, oldflags, flags);
if (ret)
goto unlock;
...
ret = ovl_real_ioctl(file, cmd, arg);

All fs impls call vfs_ioc_setflags_prepare again, so the capability is
checked again.

But I think this makes the vfs_ioc_setflags_prepare check in overlayfs
pointless (?) and the "Check the capability before cred override"
comment misleading, user can skip this check by presenting benign
flags first and then overwriting them to non-benign flags. Or, if this
check is still needed... it is wrong (?). The code would need to
arrange for both ioctl's to operate on the same data then.
Does it make any sense?
Thanks

[1] BUG: multi-read in __x64_sys_ioctl  between ovl_ioctl and ext4_ioctl
=== First Address Range Stack ===
 df_save_stack+0x33/0x70 lib/df-detection.c:208
 add_address+0x2ac/0x352 lib/df-detection.c:47
 ovl_ioctl_set_fsflags fs/overlayfs/file.c:607 [inline]
 ovl_ioctl+0x7d/0x290 fs/overlayfs/file.c:654
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:739
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
=== Second Address Range Stack ===
 df_save_stack+0x33/0x70 lib/df-detection.c:208
 add_address+0x2ac/0x352 lib/df-detection.c:47
 ext4_ioctl+0x13b1/0x27f0 fs/ext4/ioctl.c:833
 vfs_ioctl+0x30/0x80 fs/ioctl.c:48
 ovl_real_ioctl+0xed/0x100 fs/overlayfs/file.c:539
 ovl_ioctl_set_flags+0x11d/0x180 fs/overlayfs/file.c:574
 ovl_ioctl_set_fsflags fs/overlayfs/file.c:610 [inline]
 ovl_ioctl+0x11e/0x290 fs/overlayfs/file.c:654
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:739
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
syscall number 16  System Call: __x64_sys_ioctl+0x0/0x140 fs/ioctl.c:800
First 2000 len 4 Caller vfs_ioctl fs/ioctl.c:48 [inline]
First 2000 len 4 Caller __do_sys_ioctl fs/ioctl.c:753 [inline]
First 2000 len 4 Caller __se_sys_ioctl fs/ioctl.c:739 [inline]
First 2000 len 4 Caller __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:739
Second 2000 len 4 Caller vfs_ioctl+0x30/0x80 fs/ioctl.c:48
==

[PATCH 3/3] dt-bindings: adc: ad7887: add binding doc for AD7887

[Alexandru Ardelean]

This change adds a simple device-tree binding for thhe Analog Devices
AD7887 ADC.

Signed-off-by: Alexandru Ardelean 
---
 .../bindings/iio/adc/adi,ad7887.yaml  | 70 +++
 1 file changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7887.yaml

diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7887.yaml 
b/Documentation/devicetree/bindings/iio/adc/adi,ad7887.yaml
new file mode 100644
index ..9b30f4569b4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7887.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7887.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD7887 low power, 12-bit ADC
+
+maintainers:
+  - Michael Hennerich 
+
+description: |
+  Analog Devices AD7887 low power, 12-bit analog-to-digital converter (ADC)
+  that operates from a single 2.7 V to 5.25 V power supply.
+
+properties:
+  compatible:
+enum:
+  - adi,ad7887
+
+  reg:
+maxItems: 1
+
+  spi-cpha: true
+
+  spi-cpol: true
+
+  avcc-supply: true
+
+  spi-max-frequency: true
+
+  vref-supply:
+description:
+  ADC reference voltage supply
+
+  adi,dual-channel-mode:
+description:
+  Configures dual-channel mode for the ADC. In dual-channel operation,
+  the AIN1/VREF pin assumes its AIN1 function, providing a second analog
+  input channel. In this case, he reference voltage for the part is 
provided
+  via the VDD pin. As a result, the input voltage range on both the AIN0 
and
+  AIN1 inputs is 0 to VDD.
+type: boolean
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - spi-cpha
+  - spi-cpol
+
+examples:
+  - |
+spi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+adc@0 {
+compatible = "adi,ad7887";
+reg = <0>;
+spi-max-frequency = <100>;
+spi-cpol;
+spi-cpha;
+
+avcc-supply = <&adc_supply>;
+vref-supply = <&adc_vref>;
+};
+};
+...
-- 
2.17.1

[PATCH 1/3] iio: adc: ad7887: convert dual-channel mode to DT/ACPI

[Alexandru Ardelean]

This change converts the configuration of the dual-channel mode from the
old platform-data, to the device_property_present() function, which
supports both device-tree and ACPI configuration setups.

With this change the old platform_data include of the driver can be
removed.

Signed-off-by: Alexandru Ardelean 
---
 drivers/iio/adc/ad7887.c | 10 +-
 include/linux/platform_data/ad7887.h | 21 -
 2 files changed, 5 insertions(+), 26 deletions(-)
 delete mode 100644 include/linux/platform_data/ad7887.h

diff --git a/drivers/iio/adc/ad7887.c b/drivers/iio/adc/ad7887.c
index 4f6f0e0e03ee..06f684c053a0 100644
--- a/drivers/iio/adc/ad7887.c
+++ b/drivers/iio/adc/ad7887.c
@@ -23,8 +23,6 @@
 #include 
 #include 
 
-#include 
-
 #define AD7887_REF_DIS BIT(5)  /* on-chip reference disable */
 #define AD7887_DUALBIT(4)  /* dual-channel mode */
 #define AD7887_CH_AIN1 BIT(3)  /* convert on channel 1, DUAL=1 */
@@ -241,9 +239,9 @@ static void ad7887_reg_disable(void *data)
 
 static int ad7887_probe(struct spi_device *spi)
 {
-   struct ad7887_platform_data *pdata = spi->dev.platform_data;
struct ad7887_state *st;
struct iio_dev *indio_dev;
+   bool dual_mode;
uint8_t mode;
int ret;
 
@@ -286,7 +284,9 @@ static int ad7887_probe(struct spi_device *spi)
mode = AD7887_PM_MODE4;
if (!st->reg)
mode |= AD7887_REF_DIS;
-   if (pdata && pdata->en_dual)
+
+   dual_mode = device_property_present(&spi->dev, "adi,dual-channel-mode");
+   if (dual_mode)
mode |= AD7887_DUAL;
 
st->tx_cmd_buf[0] = AD7887_CH_AIN0 | mode;
@@ -298,7 +298,7 @@ static int ad7887_probe(struct spi_device *spi)
spi_message_init(&st->msg[AD7887_CH0]);
spi_message_add_tail(&st->xfer[0], &st->msg[AD7887_CH0]);
 
-   if (pdata && pdata->en_dual) {
+   if (dual_mode) {
st->tx_cmd_buf[2] = AD7887_CH_AIN1 | mode;
 
st->xfer[1].rx_buf = &st->data[0];
diff --git a/include/linux/platform_data/ad7887.h 
b/include/linux/platform_data/ad7887.h
deleted file mode 100644
index 9b4dca6ae70b..
--- a/include/linux/platform_data/ad7887.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * AD7887 SPI ADC driver
- *
- * Copyright 2010 Analog Devices Inc.
- */
-#ifndef IIO_ADC_AD7887_H_
-#define IIO_ADC_AD7887_H_
-
-/**
- * struct ad7887_platform_data - AD7887 ADC driver platform data
- * @en_dual: Whether to use dual channel mode. If set to true AIN1 becomes the
- * second input channel, and Vref is internally connected to Vdd. If set to
- * false the device is used in single channel mode and AIN1/Vref is used as
- * VREF input.
- */
-struct ad7887_platform_data {
-   bool en_dual;
-};
-
-#endif /* IIO_ADC_AD7887_H_ */
-- 
2.17.1

linux-next: Tree for Nov 17

[Stephen Rothwell]

Hi all,

Changes since 20201116:

The amdgpu tree gained a conflict against the drm tree.

The phy-next tree gained a build failure so I used the version from
next-20201116.

The mhi tree gained a build failure so I used the version from
next-20201116.

The akpm-current tree gained a conflict against the block tree.
It also gained a boot failure for which I reverted a commit.

Non-merge commits (relative to Linus' tree): 5718
 5695 files changed, 539156 insertions(+), 93508 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 327 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 (09162bc32c88 Linux 5.10-rc4)
Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1)
Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in 
setuid/setgid directory)
Merging arc-current/for-curr (3b57533b460c ARC: [plat-hsdk] Remap CCMs super 
early in asm boot trampoline)
Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid 
fortify_panic() when copying optprobe template)
Merging arm64-fixes/for-next/fixes (23c216416056 arm64: cpu_errata: Apply 
Erratum 845719 to KRYO2XX Silver)
Merging arm-soc-fixes/arm/fixes (cc05af8e2e91 Merge tag 'imx-fixes-5.10-4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes)
Merging drivers-memory-fixes/fixes (275374b46da2 memory: pl353-smc: fix compile 
test on !ARM_AMBA)
Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver 
to platform driver)
Merging powerpc-fixes/fixes (75b49620267c KVM: PPC: Book3S HV: XIVE: Fix 
possible oops when accessing ESB page)
Merging s390-fixes/fixes (78d732e1f326 s390/cpum_sf.c: fix file permission for 
cpum_sfb_size)
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 (857524564eae MAINTAINERS: Add Martin Schiller as a 
maintainer for the X.25 stack)
Merging bpf/master (f782e2c300a7 bpf: Relax return code check for subprograms)
Merging ipsec/master (48f486e13ffd net: xfrm: fix memory leak in 
xfrm_user_policy())
Merging netfilter/master (e59d6e876580 netfilter: nftables_offload: build mask 
based from the matching bytes)
Merging ipvs/master (e59d6e876580 netfilter: nftables_offload: build mask based 
from the matching bytes)
Merging wireless-drivers/master (fe56d05ee6c8 iwlwifi: mvm: fix kernel panic in 
case of assert during CSA)
Merging mac80211/master (849920c70339 devlink: Add missing genlmsg_cancel() in 
devlink_nl_sb_port_pool_fill())
Merging rdma-fixes/for-rc (dabbd6abcdbe IB/hfi1: Fix error return code in 
hfi1_init_dd())
Merging sound-current/for-linus (d78359b25f7c ALSA: hda: Add Alderlake-S PCI ID 
and HDMI codec vid)
Merging sound-asoc-fixes/for-linus (ee57a9cf5438 Merge remote-tracking branch 
'asoc/for-5.10' into asoc-linus)
Merging regmap-fixes/for-linus (3650b228f83a Linux 5.10-rc1)
Merging regulator-fixes/for-linus (f5c042b23f74 regulator: workaround 
self-referent regulators)
Merging spi-fixes/for-linus (386eaa2deaba Merge remote-tracking branch 
'spi/for-5.10' into spi-linus)
Merging pci-current/for-linus (51e2e24504ad PCI:

[PATCH 2/3] iio: adc: ad7887: convert driver to full DT probing

[Alexandru Ardelean]

This change removes the SPI device table, adds an OF device table instead.
This should also be usable for ACPI via PRP0001.

This device is usually probed via device-tree, so it makes more sense to
use the OF device table.

Signed-off-by: Alexandru Ardelean 
---
 drivers/iio/adc/ad7887.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/adc/ad7887.c b/drivers/iio/adc/ad7887.c
index 06f684c053a0..4f68a1b17ec8 100644
--- a/drivers/iio/adc/ad7887.c
+++ b/drivers/iio/adc/ad7887.c
@@ -40,6 +40,7 @@ enum ad7887_channels {
 
 /**
  * struct ad7887_chip_info - chip specifc information
+ * @name:  the name of the part
  * @int_vref_mv:   the internal reference voltage
  * @channels:  channels specification
  * @num_channels:  number of channels
@@ -47,6 +48,7 @@ enum ad7887_channels {
  * @num_dual_channels: number of channels in dual mode
  */
 struct ad7887_chip_info {
+   const char  *name;
u16 int_vref_mv;
const struct iio_chan_spec  *channels;
unsigned intnum_channels;
@@ -218,6 +220,7 @@ static const struct ad7887_chip_info ad7887_chip_info_tbl[] 
= {
 * More devices added in future
 */
[ID_AD7887] = {
+   .name = "ad7887",
.channels = ad7887_channels,
.num_channels = ARRAY_SIZE(ad7887_channels),
.dual_channels = ad7887_dual_channels,
@@ -239,12 +242,17 @@ static void ad7887_reg_disable(void *data)
 
 static int ad7887_probe(struct spi_device *spi)
 {
+   const struct ad7887_chip_info *info;
struct ad7887_state *st;
struct iio_dev *indio_dev;
bool dual_mode;
uint8_t mode;
int ret;
 
+   info = device_get_match_data(&spi->dev);
+   if (!info)
+   return -ENODEV;
+
indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
if (indio_dev == NULL)
return -ENOMEM;
@@ -269,13 +277,12 @@ static int ad7887_probe(struct spi_device *spi)
return ret;
}
 
-   st->chip_info =
-   &ad7887_chip_info_tbl[spi_get_device_id(spi)->driver_data];
+   st->chip_info = info;
 
spi_set_drvdata(spi, indio_dev);
st->spi = spi;
 
-   indio_dev->name = spi_get_device_id(spi)->name;
+   indio_dev->name = st->chip_info->name;
indio_dev->info = &ad7887_info;
indio_dev->modes = INDIO_DIRECT_MODE;
 
@@ -336,18 +343,18 @@ static int ad7887_probe(struct spi_device *spi)
return devm_iio_device_register(&spi->dev, indio_dev);
 }
 
-static const struct spi_device_id ad7887_id[] = {
-   {"ad7887", ID_AD7887},
-   {}
+static const struct of_device_id ad7887_of_match[] = {
+   { .compatible = "adi,ad7887", .data = &ad7887_chip_info_tbl[ID_AD7887] 
},
+   { }
 };
-MODULE_DEVICE_TABLE(spi, ad7887_id);
+MODULE_DEVICE_TABLE(of, ad7887_of_match);
 
 static struct spi_driver ad7887_driver = {
.driver = {
.name   = "ad7887",
+   .of_match_table = ad7887_of_match,
},
.probe  = ad7887_probe,
-   .id_table   = ad7887_id,
 };
 module_spi_driver(ad7887_driver);
 
-- 
2.17.1

Re: [PATCH net-next v2 1/3] nfc: s3fwrn5: Remove the max_payload

[k...@kernel.org]

On Tue, Nov 17, 2020 at 10:16:11AM +0900, Bongsu Jeon wrote:
> max_payload is unused.

Why did you resend the patch ignoring my review? I already provided you
with a tag, so you should include it.

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH] video: fbdev: atmel_lcdfb: fixe return error code in atmel_lcdfb_of_init()

[Thomas Zimmermann]

Hi

Am 17.11.20 um 07:13 schrieb Yang Yingliang:
> If devm_kzalloc() failed after first time, atmel_lcdfb_of_init()
> cann't return -ENOMEM, fix this by putting the error code in loop.
> 
> Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport")
> Reported-by: Hulk Robot 
> Signed-off-by: Yang Yingliang 
> ---
>  drivers/video/fbdev/atmel_lcdfb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
> b/drivers/video/fbdev/atmel_lcdfb.c
> index 8c1d47e52b1a..355b6120dc4f 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -987,8 +987,8 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
> *sinfo)
>   }
>  
>   INIT_LIST_HEAD(&pdata->pwr_gpios);
> - ret = -ENOMEM;
>   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
> + ret = -ENOMEM;

I think that a better fix would have been to put it into the alloc's
error branch. But anyway

  Reviewed-by: Thomas Zimmermann 

Thanks for your patch. I'll add it to drm-misc-next.

Best regards
Thomas

>   gpiod = devm_gpiod_get_index(dev, "atmel,power-control",
>i, GPIOD_ASIS);
>   if (IS_ERR(gpiod))
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

Re: [PATCH net-next v2 2/3] nfc: s3fwrn5: Fix the misspelling in a comment

[k...@kernel.org]

On Tue, Nov 17, 2020 at 10:17:42AM +0900, Bongsu Jeon wrote:
> stucture should be replaced by structure.
> 
> Signed-off-by: Bongsu Jeon 

I already reviewed it.

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH net-next v2 3/3] nfc: s3fwrn5: Change the error code

[k...@kernel.org]

On Tue, Nov 17, 2020 at 10:18:50AM +0900, Bongsu Jeon wrote:
> ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP.
> 
> Signed-off-by: Bongsu Jeon 
> ---
>  drivers/nfc/s3fwrn5/s3fwrn5.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

I already reviewed it.

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH net] atl1c: fix error return code in atl1c_probe()

[Chris Snook]

The full text of the preceding comment explains the need:

/*
* The atl1c chip can DMA to 64-bit addresses, but it uses a single
* shared register for the high 32 bits, so only a single, aligned,
* 4 GB physical address range can be used at a time.
*
* Supporting 64-bit DMA on this hardware is more trouble than it's
* worth.  It is far easier to limit to 32-bit DMA than update
* various kernel subsystems to support the mechanics required by a
* fixed-high-32-bit system.
*/

Without this, we get data corruption and crashes on machines with 4 GB
of RAM or more.

- Chris

On Mon, Nov 16, 2020 at 11:14 PM Heiner Kallweit  wrote:
>
> Am 17.11.2020 um 03:55 schrieb Zhang Changzhong:
> > Fix to return a negative error code from the error handling
> > case instead of 0, as done elsewhere in this function.
> >
> > Fixes: 85eb5bc33717 ("net: atheros: switch from 'pci_' to 'dma_' API")
> > Reported-by: Hulk Robot 
> > Signed-off-by: Zhang Changzhong 
> > ---
> >  drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c 
> > b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> > index 0c12cf7..3f65f2b 100644
> > --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> > +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> > @@ -2543,8 +2543,8 @@ static int atl1c_probe(struct pci_dev *pdev, const 
> > struct pci_device_id *ent)
> >* various kernel subsystems to support the mechanics required by a
> >* fixed-high-32-bit system.
> >*/
> > - if ((dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)) != 0) ||
> > - (dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)) != 0)) {
> > + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
>
> I wonder whether you need this call at all, because 32bit is the default.
> See following
>
> "By default, the kernel assumes that your device can address 32-bits
> of DMA addressing."
>
> in https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt
>
> > + if (err) {
> >   dev_err(&pdev->dev, "No usable DMA configuration,aborting\n");
> >   goto err_dma;
> >   }
> >
>

Re: [RFC 2/3] ARM: sunxi: do not select COMMON_CLK to fix builds

[Krzysztof Kozlowski]

On Mon, Nov 16, 2020 at 10:36:12PM -0600, Samuel Holland wrote:
> On 11/15/20 11:09 AM, Krzysztof Kozlowski wrote:
> > COMMON_CLK is a user-selectable option with its own dependencies.  The
> > most important dependency is !HAVE_LEGACY_CLK.  User-selectable drivers
> > should not select COMMON_CLK because they will create a dependency cycle
> > and build failures.  For example on MIPS a configuration with COMMON_CLK
> > (selected by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (selected by
> > SOC_RT305X) is possible:
> 
> Ah, that makes sense.
> 
> > 
> >   WARNING: unmet direct dependencies detected for COMMON_CLK
> > Depends on [n]: !HAVE_LEGACY_CLK [=y]
> > Selected by [y]:
> > - SND_SUN8I_CODEC [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC 
> > [=y] &&
> >   (ARCH_SUNXI || COMPILE_TEST [=y]) && OF [=y] && (MACH_SUN8I || ARM64 
> > && ARCH_SUNXI || COMPILE_TEST [=y])
> > 
> > /usr/bin/mips-linux-gnu-ld: drivers/clk/clk.o: in function 
> > `clk_set_rate':
> > (.text+0xaeb4): multiple definition of `clk_set_rate'; 
> > arch/mips/ralink/clk.o:(.text+0x88): first defined here
> > 
> > Signed-off-by: Krzysztof Kozlowski 
> > ---
> >  arch/arm/mach-sunxi/Kconfig | 1 +
> >  sound/soc/sunxi/Kconfig | 2 +-
> >  2 files changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index eeadb1a4dcfe..4d9f9b6d329d 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -4,6 +4,7 @@ menuconfig ARCH_SUNXI
> > depends on ARCH_MULTI_V5 || ARCH_MULTI_V7
> > select ARCH_HAS_RESET_CONTROLLER
> > select CLKSRC_MMIO
> > +   select COMMON_CLK
> 
> This is not necessary, since ARCH_SUNXI depends (through ARCH_MULTI_V{5,7}) on
> ARCH_MULTIPLATFORM, which selects COMMON_CLK already.

Thanks. I'll send a v2 with changes and your review.

Best regards,
Krzysztof

[PATCH v5] perf_event_open.2: Update man page with recent changes

[Namhyung Kim]

From: Namhyung Kim 

There are lots of changes as usual.  I've tried to fill some missing
bits in the man page but it'd be nice if you could take a look and put
more info there.

Signed-off-by: Namhyung Kim 
[alx: ffix + tfix]
Cowritten-by : Alejandro Colomar 
Signed-off-by: Alejandro Colomar 
---
 man2/perf_event_open.2 | 280 -
 1 file changed, 278 insertions(+), 2 deletions(-)

diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
index e7b0aa132..62731bbac 100644
--- a/man2/perf_event_open.2
+++ b/man2/perf_event_open.2
@@ -247,8 +247,17 @@ struct perf_event_attr {
due to exec */
   use_clockid:  1,  /* use clockid for time fields */
   context_switch :  1,  /* context switch data */
+  write_backward :  1,  /* Write ring buffer from end
+   to beginning */
+  namespaces :  1,  /* include namespaces data */
+  ksymbol:  1,  /* include ksymbol events */
+  bpf_event  :  1,  /* include bpf events */
+  aux_output :  1,  /* generate AUX records
+   instead of events */
+  cgroup :  1,  /* include cgroup events */
+  text_poke  :  1,  /* include text poke events */
 
-  __reserved_1   : 37;
+  __reserved_1   : 30;
 
 union {
 __u32 wakeup_events;/* wakeup every n events */
@@ -867,6 +876,20 @@ is set higher than zero then the register
 values returned are those captured by
 hardware at the time of the sampled
 instruction's retirement.
+.TP
+.BR PERF_SAMPLE_PHYS_ADDR " (since Linux 4.13)"
+.\" commit fc7ce9c74c3ad232b084d80148654f926d01ece7
+Records physical address of data like in
+.B PERF_SAMPLE_ADDR .
+.TP
+.BR PERF_SAMPLE_CGROUP " (since Linux 5.7)"
+.\" commit 96aaab686505c449e24d76e76507290dcc30e008
+Records (perf_event) cgroup id of the process.
+This corresponds to the
+.I id
+field in the
+.B PERF_RECORD_CGROUP
+event.
 .RE
 .TP
 .I read_format
@@ -1202,6 +1225,49 @@ information even with strict
 .I perf_event_paranoid
 settings.
 .TP
+.IR write_backward " (since Linux 4.6)"
+.\" commit 9ecda41acb971ebd07c8fb35faf24005c0baea12
+This makes the ring buffer is written from end to beginning.
+This is to support reading from overwritable ring buffer.
+.TP
+.IR namespaces " (since Linux 4.11)"
+.\" commit e422267322cd319e2695a535e47c5b1feeac45eb
+This enables the generation of
+.B PERF_RECORD_NAMESPACES
+records when a task is entering to a new namespace.
+Each namespace has a combination of device and inode numbers.
+.TP
+.IR ksymbol " (since Linux 5.0)"
+.\" commit 76193a94522f1d4edf2447a536f3f796ce56343b
+This enables the generation of
+.B PERF_RECORD_KSYMBOL
+records when a new kernel symbols are registered or unregistered.
+This is analyzing dynamic kernel functions like eBPF.
+.TP
+.IR bpf_event " (since Linux 5.0)"
+.\" commit 6ee52e2a3fe4ea35520720736e6791df1fb67106
+This enables the generation of
+.B PERF_RECORD_BPF_EVENT
+records when a eBPF program is loaded or unloaded.
+.TP
+.IR auxevent " (since Linux 5.4)"
+.\" commit ab43762ef010967e4ccd53627f70a2eecbeafefb
+This allows normal (non-AUX) events to generate data for AUX events
+if the hardware supports it.
+.TP
+.IR cgroup " (since Linux 5.7)"
+.\" commit 96aaab686505c449e24d76e76507290dcc30e008
+This enables the generation of
+.B PERF_RECORD_CGROUP
+records when a new cgroup is created (and activated).
+.TP
+.IR text_poke " (since Linux 5.8)"
+.\" commit e17d43b93e544f5016c0251d2074c15568d5d963
+This enables the generation of
+.B PERF_RECORD_TEXT_POKE
+records when there's a changes to the kernel text
+(i.e. self-modifying code).
+.TP
 .IR wakeup_events ", " wakeup_watermark
 This union sets how many samples
 .RI ( wakeup_events )
@@ -2131,7 +2197,7 @@ struct {
 u64nr;  /* if PERF_SAMPLE_CALLCHAIN */
 u64ips[nr]; /* if PERF_SAMPLE_CALLCHAIN */
 u32size;/* if PERF_SAMPLE_RAW */
-char  data[size];   /* if PERF_SAMPLE_RAW */
+char   data[size];  /* if PERF_SAMPLE_RAW */
 u64bnr; /* if PERF_SAMPLE_BRANCH_STACK */
 struct perf_branch_entry lbr[bnr];
 /* if PERF_SAMPLE_BRANCH_STACK */
@@ -2148,6 +2214,8 @@ struct {
 u64abi; /* if PERF_SAMPLE_REGS_INTR */
 u64regs[weight(mask)];
 /* if PERF_SAMPLE_REGS_INTR */
+u64phys_addr;   /* if PERF_SAMPLE_PHYS_ADDR */
+u64cgroup;  /* if PERF_SAMPLE_CGROUP */
 };
 .EE
 .in
@@ -2570,6 +2638,18 @@ attr field.
 The number of values is the number of bits set in the
 .I sample_regs_intr
 bit mask.
+.TP
+.I phys_addr
+If the
+.B PERF_SAMPLE_PHYS_ADDR
+flag is set, then 64-bit physical address is recorded.
+.TP
+.I cgroup
+If the
+.B PERF_SAMPLE_CGROUP
+flag is set, then 64-bit cgroup id (for the perf_event subsystem) is recorded.
+To get the pathname of the cgroup, the id

Re: [PATCH 1/2] dt-bindings: crypto: update ccree optional params

[Gilad Ben-Yossef]

On Mon, Nov 16, 2020 at 8:54 PM Rob Herring  wrote:
>
> On Thu, Oct 22, 2020 at 1:18 AM Gilad Ben-Yossef  wrote:
> >
> >
> > Hi again,
> >
> > Any opinion on the suggested below?
>
> Sorry, lost in the pile...

No problem at all. I know how it is...


> >
> >
> > On Tue, Sep 29, 2020 at 9:08 PM Gilad Ben-Yossef  
> > wrote:
> >>
> >>
> >> On Wed, Sep 23, 2020 at 4:57 AM Rob Herring  wrote:
> >> >
> >> > On Wed, Sep 16, 2020 at 10:19:49AM +0300, Gilad Ben-Yossef wrote:
> >> > > Document ccree driver supporting new optional parameters allowing to
> >> > > customize the DMA transactions cache parameters and ACE bus sharability
> >> > > properties.
> >> > >
> >> > > Signed-off-by: Gilad Ben-Yossef 
> >> > > ---
> >> > >  Documentation/devicetree/bindings/crypto/arm-cryptocell.txt | 4 
> >> > >  1 file changed, 4 insertions(+)
> >> > >
> >> > > diff --git 
> >> > > a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt 
> >> > > b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
> >> > > index 6130e6eb4af8..1a1603e457a8 100644
> >> > > --- a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
> >> > > +++ b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
> >> > > @@ -13,6 +13,10 @@ Required properties:
> >> > >  Optional properties:
> >> > >  - clocks: Reference to the crypto engine clock.
> >> > >  - dma-coherent: Present if dma operations are coherent.
> >> > > +- awcache: Set write transactions cache attributes
> >> > > +- arcache: Set read transactions cache attributes
> >> >



> >> > These could also just be implied by the compatible string (and requiring
> >> > an SoC specific one).
> >>
> >> hm... we could do it but this will require us to know (and publicly
> >> acknowledge) of every SoC making use of this piece of hardware design.
>
> That's already a requirement in general. Sometimes we can avoid it,
> but that's cases of getting lucky.
>
> >> There is currently no other part of the driver that needs this.
>
> If your DT is part of firmware, then waiting until adding some driver
> feature or quirk based on a new DT property is too late. Whereas with
> a SoC specific compatible, you can handle any new feature or quirk
> without a DT change (e.g. just a stable kernel update). Some platforms
> may not care about that model, but in general that's the policy we
> follow. Not doing that, we end up with the DWC3 binding.
>
> A fallback compatible is how we avoid updating drivers for every
> single SoC unless needed.

OK, I now better understand what you meant and that does make some
sense and I will defer to your better judgment  about the proper way
to do this.

Having said that, there is still something that bugs me about this,
even just at the level of better understanding why we do things:

Way back when, before DT, we had SoC specific code that identified the
SoC somehow and set things up in a SoC specific way.
Then we introduced DT as a way to say - "hey look, this is how my
busses looks like, these are the devices I have, deal with it" and I
always assumed that this was meant as a way to release us from having
SoC specific setup code.

It seems now potentially every SoC vendor needs to modify not just the
device tree source (which makes sense of course) but also the driver
supporting their platform.
It now looks like we've come a full circle to me :-)

Thanks!
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!

Re: [PATCH] KVM: SVM: fix error return code in svm_create_vcpu()

[Paolo Bonzini]

On 17/11/20 03:54, Chen Zhou wrote:

Fix to return a negative error code from the error handling case
instead of 0 in function svm_create_vcpu(), as done elsewhere in this
function.

Fixes: f4c847a95654 ("KVM: SVM: refactor msr permission bitmap allocation")
Reported-by: Hulk Robot 
Signed-off-by: Chen Zhou 
---
  arch/x86/kvm/svm/svm.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 1e81cfebd491..79b3a564f1c9 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -1309,8 +1309,10 @@ static int svm_create_vcpu(struct kvm_vcpu *vcpu)
svm->avic_is_running = true;
  
  	svm->msrpm = svm_vcpu_alloc_msrpm();

-   if (!svm->msrpm)
+   if (!svm->msrpm) {
+   err = -ENOMEM;
goto error_free_vmcb_page;
+   }
  
  	svm_vcpu_init_msrpm(vcpu, svm->msrpm);
  



Queued, thanks.

Paolo

AW: [PATCH v2 2/3] rtc: rx6110: add ACPI bindings to I2C

[johannes-h...@siemens.com]

Hello Andy,

when comparing the ACPI IDs used in rtc-ds1307.c, which is already on mainline 

https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-ds1307.c#L1141

for example. Every ID listed there is also not formatted the ACPI ID , PNP ID 
way defined in the ACPI spec.

How about that ?

Best Regards,
Johannes

-Ursprüngliche Nachricht-
Von: Henning Schild  
Gesendet: Montag, 16. November 2020 16:30
An: Andy Shevchenko 
Cc: Claudius Heine ; Alessandro Zummo ; 
Alexandre Belloni ; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; Hahn, Johannes (DI FA CTR PLC PRC3) 
; Zeh, Werner (DI MC MTS R&D HW 1) 

Betreff: Re: [PATCH v2 2/3] rtc: rx6110: add ACPI bindings to I2C

Am Mon, 16 Nov 2020 16:46:31 +0200
schrieb Andy Shevchenko :

> On Thu, Nov 12, 2020 at 02:07:33PM +0100, Claudius Heine wrote:
> > From: Johannes Hahn 
> > 
> > This allows the RX6110 driver to be automatically assigned to the 
> > right device on the I2C bus.
> 
> Before adding new ACPI ID, can you provide an evidence (either from 
> vendor of the component, or a real snapshot of DSDT from device on
> market) that this is real ID?
> 
> Before that happens, NAK.
> 
> P.S. Seems to me that this is kinda cargo cult patch because proposed 
> ID is against ACPI and PNP registry and ACPI specification.

In fact we pushed it in coreboot and Linux at the same time.

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.coreboot.org%2Fc%2Fcoreboot%2F%2B%2F47235&data=04%7C01%7Cjohannes-hahn%40siemens.com%7C21c9e1fe99274df7951a08d88a448af5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637411374276831534%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7EVdO%2F77LNyvux0y3m9nEf2HZO%2BDm2WkWMfxzaJUoto%3D&reserved=0

That is the evidence. But in case this is wrong we can probably still change 
coreboot, even though the patches have been merged there already.

Maybe you can go into detail where you see the violations and maybe even 
suggest fixes that come to mind.

Henning

Re: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT Binding doc for soc unique ID

[Krzysztof Kozlowski]

On Tue, Nov 17, 2020 at 07:10:28AM +, Alice Guo wrote:
> 
> 
> > -Original Message-
> > From: Krzysztof Kozlowski 
> > Sent: 2020年11月17日 0:03
> > To: Alice Guo 
> > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> > dl-linux-imx ; Peng Fan ;
> > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org
> > Subject: Re: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT 
> > Binding
> > doc for soc unique ID
> > 
> > Caution: EXT Email
> > 
> > On Mon, Nov 16, 2020 at 07:04:13AM +, Alice Guo wrote:
> > >
> > > > -Original Message-
> > > > From: Krzysztof Kozlowski 
> > > > Sent: 2020年11月15日 0:50
> > > > To: Alice Guo 
> > > > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> > > > dl-linux-imx ; Peng Fan ;
> > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > linux-arm-ker...@lists.infradead.org
> > > > Subject: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT
> > > > Binding doc for soc unique ID
> > > >
> > > > Caution: EXT Email
> > > >
> > > > On Fri, Nov 13, 2020 at 07:04:06PM +0800, Alice Guo wrote:
> > > > > Add DT Binding doc for the Unique ID of i.MX 8M series.
> > > > >
> > > > > Signed-off-by: Alice Guo 
> > > > > ---
> > > > >  .../devicetree/bindings/arm/fsl.yaml  | 25
> > > > +++
> > > > >  1 file changed, 25 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > > b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > > index e4db0f9ed664..f4faebbb57da 100644
> > > > > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > > @@ -901,6 +901,31 @@ properties:
> > > > >- fsl,s32v234-evb   # S32V234-EVB2
> > Customer
> > > > Evaluation Board
> > > > >- const: fsl,s32v234
> > > > >
> > > > > +  soc:
> > > > > +type: object
> > > > > +properties:
> > > > > +  compatible:
> > > > > +oneOf:
> > > > > +  - description: i.MX8M SoCs
> > > > > +items:
> > > > > +  - enum:
> > > > > +  - fsl,imx8mm-soc
> > > > > +  - fsl,imx8mn-soc
> > > > > +  - fsl,imx8mp-soc
> > > > > +  - fsl,imx8mq-soc
> > > > > +  - const: simple-bus
> > > > > +
> > > > > +  - description: Other SoCs
> > > > > +items:
> > > > > +  - const: simple-bus
> > > > > +
> > > > > +  nvmem-cells:
> > > > > +maxItems: 1
> > > > > +description: Phandle to the SOC Unique ID provided by a
> > > > > + nvmem node
> > > > > +
> > > > > +  nvmem-cells-names:
> > > > > +const: soc_unique_id
> > > > > +
> > > > >  additionalProperties: true
> > > >
> > > > The "soc" node should be required for these compatibles. Otherwise
> > > > you will have to stay with this
> > > > backwards-compatible-DTB-device-initcall-glue for many years... I think 
> > > > you
> > can achieve it with allOf.
> > > >
> > > [Alice Guo]Hi,
> > > I find that my description for compatible is ambiguous. There are two 
> > > kinds of
> > compatible of the "soc" node:
> > > 1. For dtsi files used for SoCs other than imx8m series SoCs and old
> > > version dtsi files used for imx8m series SoCs, compatible of the "soc" 
> > > node is
> > "simple-bus".
> > > 2. For new version dtsi files used for imx8m series SoCs, compatible of 
> > > the
> > "soc" node is {"fsl,imx8mX-soc","simple-bus"}.
> > >
> > > "nvmem-cell" is an optional property.
> > >
> > > I do not understand what you mean. You mean that limit the compatible of
> > "soc" node must include " fsl,imx8mX-soc" in new version dts files. Is my
> > understanding correct?
> > 
> > All new DTS files should have soc node with "fsl,imx8mX-soc" and this 
> > should be
> > required by dtschema. The nvmem-cells and related properties do not look 
> > like
> > optional. From the hardware perspective - they are always present. From the
> > driver point of view: they are required and driver will fail to work.
> 
> [Alice Guo] 
> +  soc:
> +type: object
> +properties:
> +  compatible:
> +oneOf:
> +  - description: new version DTS for i.MX8M SoCs
> +items:
> +  - enum:
> +  - fsl,imx8mm-soc
> +  - fsl,imx8mn-soc
> +  - fsl,imx8mp-soc
> +  - fsl,imx8mq-soc
> +  - const: simple-bus
> +
> +  - description: other SoCs and old version DTS for i.MX8M SoCs
> +items:
> +  - const: simple-bus
> +
> +  nvmem-cells:
> +maxItems: 1
> +description: Phandle to the SOC Unique ID provided by a nvmem node
> +
> +  nvmem-cells-names:
> +const: soc_unique_id
> +
> +allOf:
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +  

Re: [RESEND v7, PATCH 4/7] mtk-mmsys: add mt8183 mmsys support

[Hsin-Yi Wang]

On Sat, Aug 8, 2020 at 2:53 AM Yongqiang Niu  wrote:
>
> add mt8183 mmsys support
>
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/soc/mediatek/mmsys/Makefile   |   1 +
>  drivers/soc/mediatek/mmsys/mt8183-mmsys.c | 154 
> ++
>  drivers/soc/mediatek/mtk-mmsys.c  |   1 +
>  3 files changed, 156 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mmsys/mt8183-mmsys.c
>
> diff --git a/drivers/soc/mediatek/mmsys/Makefile 
> b/drivers/soc/mediatek/mmsys/Makefile
> index 33b0dab..62cfedf 100644
> --- a/drivers/soc/mediatek/mmsys/Makefile
> +++ b/drivers/soc/mediatek/mmsys/Makefile
> @@ -1,2 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-y += mt2701-mmsys.o
> +obj-y += mt8183-mmsys.o
> diff --git a/drivers/soc/mediatek/mmsys/mt8183-mmsys.c 
> b/drivers/soc/mediatek/mmsys/mt8183-mmsys.c
> new file mode 100644
> index 000..e5170b5
> --- /dev/null
> +++ b/drivers/soc/mediatek/mmsys/mt8183-mmsys.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2020 MediaTek Inc.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DISP_OVL0_MOUT_EN  0xf00
> +#define DISP_OVL0_2L_MOUT_EN   0xf04
> +#define DISP_OVL1_2L_MOUT_EN   0xf08
> +#define DISP_DITHER0_MOUT_EN   0xf0c
> +#define DISP_PATH0_SEL_IN  0xf24
> +#define DISP_DSI0_SEL_IN   0xf2c
> +#define DISP_DPI0_SEL_IN   0xf30
> +#define DISP_RDMA0_SOUT_SEL_IN 0xf50
> +#define DISP_RDMA1_SOUT_SEL_IN 0xf54
> +
> +#define OVL0_MOUT_EN_OVL0_2L   BIT(4)
> +#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
> +#define OVL1_2L_MOUT_EN_RDMA1  BIT(4)
> +#define DITHER0_MOUT_IN_DSI0   BIT(0)
> +#define DISP_PATH0_SEL_IN_OVL0_2L  0x1
> +#define DSI0_SEL_IN_RDMA0  0x1
> +#define DSI0_SEL_IN_RDMA1  0x3
> +#define DPI0_SEL_IN_RDMA0  0x1
> +#define DPI0_SEL_IN_RDMA1  0x2
> +#define RDMA0_SOUT_COLOR0  0x1
> +#define RDMA1_SOUT_DSI00x1
> +
> +struct mmsys_path_sel {
> +   enum mtk_ddp_comp_id cur;
> +   enum mtk_ddp_comp_id next;
> +   u32 addr;
> +   u32 val;
> +};
> +
> +static struct mmsys_path_sel mmsys_mout_en[] = {
> +   {
> +   DDP_COMPONENT_OVL0, DDP_COMPONENT_OVL_2L0,
> +   DISP_OVL0_MOUT_EN, OVL0_MOUT_EN_OVL0_2L,
> +   },
> +   {
> +   DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> +   DISP_OVL0_2L_MOUT_EN, OVL0_2L_MOUT_EN_DISP_PATH0,
> +   },
> +   {
> +   DDP_COMPONENT_OVL_2L1, DDP_COMPONENT_RDMA1,
> +   DISP_OVL1_2L_MOUT_EN, OVL1_2L_MOUT_EN_RDMA1,
> +   },
> +   {
> +   DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
> +   DISP_DITHER0_MOUT_EN, DITHER0_MOUT_IN_DSI0,
> +   },
> +};
> +
> +static struct mmsys_path_sel mmsys_sel_in[] = {
> +   {
> +   DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> +   DISP_PATH0_SEL_IN, DISP_PATH0_SEL_IN_OVL0_2L,
> +   },
> +   {
> +   DDP_COMPONENT_RDMA1, DDP_COMPONENT_DPI0,
> +   DISP_DPI0_SEL_IN, DPI0_SEL_IN_RDMA1,
> +   },
> +};
> +
> +static struct mmsys_path_sel mmsys_sout_sel[] = {
> +   {
> +   DDP_COMPONENT_RDMA0, DDP_COMPONENT_COLOR0,
> +   DISP_RDMA0_SOUT_SEL_IN, RDMA0_SOUT_COLOR0,
> +   },
> +};
> +
> +static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
> + enum mtk_ddp_comp_id next,
> + unsigned int *addr)
> +{
> +   u32 i;
> +   struct mmsys_path_sel *path;
> +
> +   for (i = 0; i < ARRAY_SIZE(mmsys_mout_en); i++) {
> +   path = &mmsys_mout_en[i];
> +   if (cur == path->cur && next == path->next) {
> +   *addr = path->addr;
> +   return path->val;
> +   }
> +   }
> +
> +   return 0;
> +}
> +
> +static unsigned int mtk_mmsys_ddp_sel_in(enum mtk_ddp_comp_id cur,
> +enum mtk_ddp_comp_id next,
> +unsigned int *addr)
> +{
> +   u32 i;
> +   struct mmsys_path_sel *path;
> +
> +   for (i = 0; i < ARRAY_SIZE(mmsys_sel_in); i++) {
> +   path = &mmsys_sel_in[i];
> +   if (cur == path->cur && next == path->next) {
> +   *addr = path->addr;
> +   return path->val;
> +   }
> +   }
> +
> +   return 0;
> +}
> +
> +static void mtk_mmsys_ddp_sout_sel(void __iomem *config_regs,
> +  enum mtk_ddp_comp_id cur,
> +  enum mtk_ddp_comp_id next)
> +{
> +   u32 i;
> +   u32 val = 0;

This variable is

workqueue: Only kick a worker after thawed or for an unbound workqueue

[Yunfeng Ye]

In realtime scenario, We do not want to have interference on the
isolated cpu cores. but when invoking alloc_workqueue() for percpu wq
on the housekeeping cpu, it kick a kworker on the isolated cpu.

  alloc_workqueue
pwq_adjust_max_active
  wake_up_worker

The comment in pwq_adjust_max_active() said:
  "Need to kick a worker after thawed or an unbound wq's
   max_active is bumped"

So it is unnecessary to kick a kworker for percpu wq's when
alloc_workqueue. this patch only kick a worker after thawed or for an
unbound workqueue.

Signed-off-by: Yunfeng Ye 
---
 kernel/workqueue.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c41c3c17b86a..80f7bbd4889f 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3696,14 +3696,16 @@ static void pwq_unbound_release_workfn(struct 
work_struct *work)
 }

 /**
- * pwq_adjust_max_active - update a pwq's max_active to the current setting
+ * pwq_adjust_max_active_and_kick - update a pwq's max_active to the current 
setting
  * @pwq: target pool_workqueue
+ * @force_kick: force to kick a worker
  *
  * If @pwq isn't freezing, set @pwq->max_active to the associated
  * workqueue's saved_max_active and activate delayed work items
  * accordingly.  If @pwq is freezing, clear @pwq->max_active to zero.
  */
-static void pwq_adjust_max_active(struct pool_workqueue *pwq)
+static void pwq_adjust_max_active_and_kick(struct pool_workqueue *pwq,
+   bool force_kick)
 {
struct workqueue_struct *wq = pwq->wq;
bool freezable = wq->flags & WQ_FREEZABLE;
@@ -3733,9 +3735,10 @@ static void pwq_adjust_max_active(struct pool_workqueue 
*pwq)

/*
 * Need to kick a worker after thawed or an unbound wq's
-* max_active is bumped.  It's a slow path.  Do it always.
+* max_active is bumped.
 */
-   wake_up_worker(pwq->pool);
+   if (force_kick || (wq->flags & WQ_UNBOUND))
+   wake_up_worker(pwq->pool);
} else {
pwq->max_active = 0;
}
@@ -3743,6 +3746,11 @@ static void pwq_adjust_max_active(struct pool_workqueue 
*pwq)
raw_spin_unlock_irqrestore(&pwq->pool->lock, flags);
 }

+static void pwq_adjust_max_active(struct pool_workqueue *pwq)
+{
+   pwq_adjust_max_active_and_kick(pwq, false);
+}
+
 /* initialize newly alloced @pwq which is associated with @wq and @pool */
 static void init_pwq(struct pool_workqueue *pwq, struct workqueue_struct *wq,
 struct worker_pool *pool)
@@ -5252,7 +5260,7 @@ void thaw_workqueues(void)
list_for_each_entry(wq, &workqueues, list) {
mutex_lock(&wq->mutex);
for_each_pwq(pwq, wq)
-   pwq_adjust_max_active(pwq);
+   pwq_adjust_max_active_and_kick(pwq, true);
mutex_unlock(&wq->mutex);
}

-- 
2.18.4

[PATCH v6] tcp: fix race condition when creating child sockets from syncookies

[Ricardo Dias]

When the TCP stack is in SYN flood mode, the server child socket is
created from the SYN cookie received in a TCP packet with the ACK flag
set.

The child socket is created when the server receives the first TCP
packet with a valid SYN cookie from the client. Usually, this packet
corresponds to the final step of the TCP 3-way handshake, the ACK
packet. But is also possible to receive a valid SYN cookie from the
first TCP data packet sent by the client, and thus create a child socket
from that SYN cookie.

Since a client socket is ready to send data as soon as it receives the
SYN+ACK packet from the server, the client can send the ACK packet (sent
by the TCP stack code), and the first data packet (sent by the userspace
program) almost at the same time, and thus the server will equally
receive the two TCP packets with valid SYN cookies almost at the same
instant.

When such event happens, the TCP stack code has a race condition that
occurs between the momement a lookup is done to the established
connections hashtable to check for the existence of a connection for the
same client, and the moment that the child socket is added to the
established connections hashtable. As a consequence, this race condition
can lead to a situation where we add two child sockets to the
established connections hashtable and deliver two sockets to the
userspace program to the same client.

This patch fixes the race condition by checking if an existing child
socket exists for the same client when we are adding the second child
socket to the established connections socket. If an existing child
socket exists, we return that socket and use it to process the TCP
packet received, and discard the second child socket to the same client.

Signed-off-by: Ricardo Dias 
---
v6 (2020-11-17):
  * Moved the ehash bucket list search for its own helper function.

v5 (2020-11-16):
 - Not considered for review -
 
v4 (2020-11-12):
  * Added `struct sock **esk) parameter to `inet_ehash_insert`.
  * Fixed ref count increment in `inet_ehash_insert`.
  * Fixed callers of inet_ehash_nolisten.

v3 (2020-11-11):
  * Fixed IPv6 handling in inet_ehash_insert
  * Removed unecessary comparison while traversing the ehash bucket
list.
 
v2 (2020-11-09):
  * Changed the author's email domain.
  * Removed the helper function inet_ehash_insert_chk_dup and moved the
logic to the existing inet_ehash_insert.
  * Updated the callers of iner_ehash_nolisten to deal with the new
logic.

 include/net/inet_hashtables.h   |  4 +-
 net/dccp/ipv4.c |  2 +-
 net/dccp/ipv6.c |  2 +-
 net/ipv4/inet_connection_sock.c |  2 +-
 net/ipv4/inet_hashtables.c  | 72 +
 net/ipv4/syncookies.c   |  5 ++-
 net/ipv4/tcp_ipv4.c |  9 -
 net/ipv6/tcp_ipv6.c | 16 +++-
 8 files changed, 96 insertions(+), 16 deletions(-)

diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
index 92560974ea67..b0abc4dd6d49 100644
--- a/include/net/inet_hashtables.h
+++ b/include/net/inet_hashtables.h
@@ -247,8 +247,8 @@ void inet_hashinfo2_init(struct inet_hashinfo *h, const 
char *name,
 unsigned long high_limit);
 int inet_hashinfo2_init_mod(struct inet_hashinfo *h);
 
-bool inet_ehash_insert(struct sock *sk, struct sock *osk);
-bool inet_ehash_nolisten(struct sock *sk, struct sock *osk);
+bool inet_ehash_insert(struct sock *sk, struct sock *osk, struct sock **esk);
+bool inet_ehash_nolisten(struct sock *sk, struct sock *osk, struct sock **esk);
 int __inet_hash(struct sock *sk, struct sock *osk);
 int inet_hash(struct sock *sk);
 void inet_unhash(struct sock *sk);
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 9c28c8251125..098bae35ab76 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -427,7 +427,7 @@ struct sock *dccp_v4_request_recv_sock(const struct sock 
*sk,
 
if (__inet_inherit_port(sk, newsk) < 0)
goto put_and_exit;
-   *own_req = inet_ehash_nolisten(newsk, req_to_sk(req_unhash));
+   *own_req = inet_ehash_nolisten(newsk, req_to_sk(req_unhash), NULL);
if (*own_req)
ireq->ireq_opt = NULL;
else
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index ef4ab28cfde0..78ee1b5acf1f 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -533,7 +533,7 @@ static struct sock *dccp_v6_request_recv_sock(const struct 
sock *sk,
dccp_done(newsk);
goto out;
}
-   *own_req = inet_ehash_nolisten(newsk, req_to_sk(req_unhash));
+   *own_req = inet_ehash_nolisten(newsk, req_to_sk(req_unhash), NULL);
/* Clone pktoptions received with SYN, if we own the req */
if (*own_req && ireq->pktopts) {
newnp->pktoptions = skb_clone(ireq->pktopts, GFP_ATOMIC);
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index b457dd2d6c75..df26489e4f6c 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/i

Re: [PATCH v2] sched/deadline: Fix priority inheritance with multiple scheduling classes

[Daniel Bristot de Oliveira]

On 11/17/20 7:14 AM, Juri Lelli wrote:
> Glenn reported that "an application [he developed produces] a BUG in
> deadline.c when a SCHED_DEADLINE task contends with CFS tasks on nested
> PTHREAD_PRIO_INHERIT mutexes.  I believe the bug is triggered when a CFS
> task that was boosted by a SCHED_DEADLINE task boosts another CFS task
> (nested priority inheritance).
> 
>  [ cut here ]
>  kernel BUG at kernel/sched/deadline.c:1462!
>  invalid opcode:  [#1] PREEMPT SMP
>  CPU: 12 PID: 19171 Comm: dl_boost_bug Tainted: ...
>  Hardware name: ...
>  RIP: 0010:enqueue_task_dl+0x335/0x910
>  Code: ...
>  RSP: 0018:c9000c2bbc68 EFLAGS: 00010002
>  RAX: 0009 RBX: 888c0af94c00 RCX: 81e12500
>  RDX: 002e RSI: 888c0af94c00 RDI: 888c10b22600
>  RBP: c9000c2bbd08 R08: 0009 R09: 0078
>  R10: 81e12440 R11: 81e1236c R12: 888bc8932600
>  R13: 888c0af94eb8 R14: 888c10b22600 R15: 888bc8932600
>  FS:  7fa58ac55700() GS:888c10b0() knlGS:
>  CS:  0010 DS:  ES:  CR0: 80050033
>  CR2: 7fa58b523230 CR3: 000bf44ab003 CR4: 007606e0
>  DR0:  DR1:  DR2: 
>  DR3:  DR6: fffe0ff0 DR7: 0400
>  PKRU: 5554
>  Call Trace:
>   ? intel_pstate_update_util_hwp+0x13/0x170
>   rt_mutex_setprio+0x1cc/0x4b0
>   task_blocks_on_rt_mutex+0x225/0x260
>   rt_spin_lock_slowlock_locked+0xab/0x2d0
>   rt_spin_lock_slowlock+0x50/0x80
>   hrtimer_grab_expiry_lock+0x20/0x30
>   hrtimer_cancel+0x13/0x30
>   do_nanosleep+0xa0/0x150
>   hrtimer_nanosleep+0xe1/0x230
>   ? __hrtimer_init_sleeper+0x60/0x60
>   __x64_sys_nanosleep+0x8d/0xa0
>   do_syscall_64+0x4a/0x100
>   entry_SYSCALL_64_after_hwframe+0x49/0xbe
>  RIP: 0033:0x7fa58b52330d
>  ...
>  ---[ end trace 0002 ]—
> 
> He also provided a simple reproducer creating the situation below:
> 
>  So the execution order of locking steps are the following
>  (N1 and N2 are non-deadline tasks. D1 is a deadline task. M1 and M2
>  are mutexes that are enabled * with priority inheritance.)
> 
>  Time moves forward as this timeline goes down:
> 
>  N1  N2   D1
>  |   ||
>  |   ||
>  Lock(M1)||
>  |   ||
>  | Lock(M2)   |
>  |   ||
>  |   |  Lock(M2)
>  |   ||
>  | Lock(M1)   |
>  | (!!bug triggered!) |
> 
> Daniel reported a similar situation as well, by just letting ksoftirqd
> run with DEADLINE (and eventually block on a mutex).
> 
> Problem is that boosted entities (Priority Inheritance) use static
> DEADLINE parameters of the top priority waiter. However, there might be
> cases where top waiter could be a non-DEADLINE entity that is currently
> boosted by a DEADLINE entity from a different lock chain (i.e., nested
> priority chains involving entities of non-DEADLINE classes). In this
> case, top waiter static DEADLINE parameters could be null (initialized
> to 0 at fork()) and replenish_dl_entity() would hit a BUG().
> 
> Fix this by keeping track of the original donor and using its parameters
> when a task is boosted.
> 
> Reported-by: Glenn Elliott 
> Reported-by: Daniel Bristot de Oliveira 
> Signed-off-by: Juri Lelli 

Tested-by: Daniel Bristot de Oliveira 

Thanks!
-- Daniel

Re: [PATCH v9 2/2] fs: ext4: Modify inode-test.c to use KUnit parameterized testing feature

[David Gow]

On Mon, Nov 16, 2020 at 1:42 PM Arpitha Raghunandan <98.a...@gmail.com> wrote:
>
> Modify fs/ext4/inode-test.c to use the parameterized testing
> feature of KUnit.
>
> Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
> Signed-off-by: Marco Elver 
> ---
[Resending this because the HTML-email demon struck again! Sorry for the mess!]


Thanks: this is working well over here.
The only (minor) issue I've noticed is that the diagnostic output is
too big for the default log buffer if debugfs output is used, causing
some of the messages to be dropped from the debugfs results file. But
that's clearly not an issue with this patch, and the actual combined
result is still present (and the complete results should show up in
dmesg anyway).

Tested-by: David Gow 
Reviewed-by: David Gow 

Thanks!
-- David

Re: [PATCH v9 1/2] kunit: Support for Parameterized Testing

[David Gow]

On Mon, Nov 16, 2020 at 1:41 PM Arpitha Raghunandan <98.a...@gmail.com> wrote:
>
> Implementation of support for parameterized testing in KUnit. This
> approach requires the creation of a test case using the
> KUNIT_CASE_PARAM() macro that accepts a generator function as input.
>
> This generator function should return the next parameter given the
> previous parameter in parameterized tests. It also provides a macro to
> generate common-case generators based on arrays. Generators may also
> optionally provide a human-readable description of parameters, which is
> displayed where available.
>
> Note, currently the result of each parameter run is displayed in
> diagnostic lines, and only the overall test case output summarizes
> TAP-compliant success or failure of all parameter runs. In future, when
> supported by kunit-tool, these can be turned into subsubtest outputs.
>
> Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
> Co-developed-by: Marco Elver 
> Signed-off-by: Marco Elver 
> ---
[Resending this because my email client re-defaulted to HTML! Aarrgh!]

This looks good to me! I tested it in UML and x86-64 w/ KASAN, and
both worked fine.

Reviewed-by: David Gow 
Tested-by: David Gow 

Thanks for sticking with this!

-- David

Re: [PATCH v4 01/10] Add auxiliary bus support

[Leon Romanovsky]

On Tue, Nov 17, 2020 at 08:02:53AM +0100, Greg KH wrote:
> On Tue, Nov 17, 2020 at 07:30:00AM +0200, Leon Romanovsky wrote:
> > On Fri, Nov 13, 2020 at 08:18:50AM -0800, Dave Ertman wrote:
> > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> > > It enables drivers to create an auxiliary_device and bind an
> > > auxiliary_driver to it.
> > >
> > > The bus supports probe/remove shutdown and suspend/resume callbacks.
> > > Each auxiliary_device has a unique string based id; driver binds to
> > > an auxiliary_device based on this id through the bus.
> > >
> > > Co-developed-by: Kiran Patil 
> > > Signed-off-by: Kiran Patil 
> > > Co-developed-by: Ranjani Sridharan 
> > > Signed-off-by: Ranjani Sridharan 
> > > Co-developed-by: Fred Oh 
> > > Signed-off-by: Fred Oh 
> > > Co-developed-by: Leon Romanovsky 
> > > Signed-off-by: Leon Romanovsky 
> > > Reviewed-by: Pierre-Louis Bossart 
> > > Reviewed-by: Shiraz Saleem 
> > > Reviewed-by: Parav Pandit 
> > > Reviewed-by: Dan Williams 
> > > Signed-off-by: Dave Ertman 
> > > ---
> >
> > Greg,
> >
> > This horse was beaten to death, can we please progress with this patch?
> > Create special topic branch or ack so I'll prepare this branch.
> >
> > We are in -rc4 now and we (Mellanox) can't hold our submissions anymore.
> > My mlx5_core probe patches [1] were too intrusive and they are ready to
> > be merged, Parav's patches got positive review as well [2] and will be
> > taken next.
> >
> > We delayed and have in our internal queues the patches for VDPA, eswitch
> > and followup for mlx5_core probe rework, but trapped due to this AUX bus
> > patch.
>
> There are no deadlines for kernel patches here, sorry.  Give me some
> time to properly review this, core kernel changes should not be rushed.

And here comes the difference between our views, from my POV it is not
core kernel change that must to be done perfectly from the beginning,
but change that will need to be improved/extended over time once more
users will come.

>
> Also, if you really want to blame someone for the delay, look at the
> patch submitters, not the reviewers, as they are the ones that took a
> very long time with this over the lifecycle of this patchset, not me.  I
> have provided many "instant" reviews of this patchset, and then months
> went by between updates from them.

I'm not blaming anyone and especially you. It is just unfair that I
found myself in the middle of this disaster while care enough to remind
about the series.

Thanks

>
> greg k-h

Re: [PATCH] thermal: Fix NULL pointer dereference issue

[Zhang Rui]

On Mon, 2020-11-16 at 21:59 +0530, Mukesh Ojha wrote:
> Cooling stats variable inside thermal_cooling_device_stats_update()
> can get NULL. We should add a NULL check on stat inside for sanity.
> 
> Signed-off-by: Mukesh Ojha 
> ---
>  drivers/thermal/thermal_sysfs.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/thermal/thermal_sysfs.c
> b/drivers/thermal/thermal_sysfs.c
> index a6f371f..f52708f 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -754,6 +754,9 @@ void thermal_cooling_device_stats_update(struct
> thermal_cooling_device *cdev,
>  {
>   struct cooling_dev_stats *stats = cdev->stats;
>  
> + if (!stats)
> + return;
> +
May I know in which case stats can be NULL?
The only possibility I can see is that cdev->ops->get_max_state() fails
in cooling_device_stats_setup(), right?

thanks,
rui

>   spin_lock(&stats->lock);
>  
>   if (stats->state == new_state)

[PATCH] khugepaged: add couples parameter explanation for kernel-doc markup

[Alex Shi]

Add missed parameter explanation for some kernel-doc warnings:
mm/khugepaged.c:102: warning: Function parameter or member
'nr_pte_mapped_thp' not described in 'mm_slot'
mm/khugepaged.c:102: warning: Function parameter or member
'pte_mapped_thp' not described in 'mm_slot'
mm/khugepaged.c:1424: warning: Function parameter or member 'mm' not
described in 'collapse_pte_mapped_thp'
mm/khugepaged.c:1424: warning: Function parameter or member 'addr' not
described in 'collapse_pte_mapped_thp'
mm/khugepaged.c:1626: warning: Function parameter or member 'mm' not
described in 'collapse_file'
mm/khugepaged.c:1626: warning: Function parameter or member 'file' not
described in 'collapse_file'
mm/khugepaged.c:1626: warning: Function parameter or member 'start' not
described in 'collapse_file'
mm/khugepaged.c:1626: warning: Function parameter or member 'hpage' not
described in 'collapse_file'
mm/khugepaged.c:1626: warning: Function parameter or member 'node' not
described in 'collapse_file'

Signed-off-by: Alex Shi 
Cc: Andrew Morton 
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/khugepaged.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 757292532767..8f7aee4efdc3 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -90,6 +90,8 @@ static struct kmem_cache *mm_slot_cache __read_mostly;
  * @hash: hash collision list
  * @mm_node: khugepaged scan list headed in khugepaged_scan.mm_head
  * @mm: the mm that this information is valid for
+ * @nr_pte_mapped_thp: number of pte mapped THP
+ * @pte_mapped_thp: address array corresponding pte mapped THP
  */
 struct mm_slot {
struct hlist_node hash;
@@ -1414,7 +1416,11 @@ static int khugepaged_add_pte_mapped_thp(struct 
mm_struct *mm,
 }
 
 /**
- * Try to collapse a pte-mapped THP for mm at address haddr.
+ * collapse_pte_mapped_thp - Try to collapse a pte-mapped THP for mm at
+ * address haddr.
+ *
+ * @mm: process address space where collapse happens
+ * @addr: THP collapse address
  *
  * This function checks whether all the PTEs in the PMD are pointing to the
  * right THP. If so, retract the page table so the THP can refault in with
@@ -1605,6 +1611,12 @@ static void retract_page_tables(struct address_space 
*mapping, pgoff_t pgoff)
 /**
  * collapse_file - collapse filemap/tmpfs/shmem pages into huge one.
  *
+ * @mm: process address space where collapse happens
+ * @file: file that collapse on
+ * @start: collapse start address 
+ * @hpage: new allocated huge page for collapse
+ * @node: appointed node the new huge page allocate from
+ *
  * Basic scheme is simple, details are more complex:
  *  - allocate and lock a new huge page;
  *  - scan page cache replacing old pages with the new one
-- 
2.29.GIT

Re: drivers/net/ethernet/freescale/gianfar.c:580 gfar_parse_group() warn: 'grp->regs' not released on lines: 517.

[Dan Carpenter]

On Tue, Nov 17, 2020 at 01:41:15AM +, Leo Li wrote:
> > ee873fda3bec7c6 drivers/net/ethernet/freescale/gianfar.c Claudiu Manoil
> > 2013-01-29  513 gfar_irq(grp, ER)->irq =
> > irq_of_parse_and_map(np, 2);
> > fea0f6650979a4f drivers/net/ethernet/freescale/gianfar.c Mark Brown
> > 2015-11-26  514 if (!gfar_irq(grp, TX)->irq ||
> > fea0f6650979a4f drivers/net/ethernet/freescale/gianfar.c Mark Brown
> > 2015-11-26  515 !gfar_irq(grp, RX)->irq ||
> > fea0f6650979a4f drivers/net/ethernet/freescale/gianfar.c Mark Brown
> > 2015-11-26  516 !gfar_irq(grp, ER)->irq)
> > 46ceb60ca80fa07 drivers/net/gianfar.cSandeep Gopalpet 
> > 2009-11-
> > 02  517 return -EINVAL;
> > 
> > This should unmap "grp->regs".
> 
> This variable is unmapped in the caller with a wholesale cleanup function 
> unmap_group_regs().  Probably a false positive for smatch?
> 

Yeah.  Thanks.  Smatch doesn't consider that the variable might be freed
in the caller.

regards,
dan carpenter

[PATCH] usb: gadget: u_ether: Fix MTU size mismatch with RX packet size

[Manish Narani]

Fix the MTU size issue with RX packet size as the host sends the packet
with extra bytes containing ethernet header. This causes failure when
user sets the MTU size to the maximum i.e. 15412. In this case the
ethernet packet received will be of length 15412 plus the ethernet header
length. This patch fixes the issue where there is a check that RX packet
length must not be more than max packet length.

Fixes: bba787a860fa ("usb: gadget: ether: Allow jumbo frames")
Signed-off-by: Manish Narani 
---
 drivers/usb/gadget/function/u_ether.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/u_ether.c 
b/drivers/usb/gadget/function/u_ether.c
index 31ea76adcc0d..c019f2b0c0af 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -45,9 +45,10 @@
 #define UETH__VERSION  "29-May-2008"
 
 /* Experiments show that both Linux and Windows hosts allow up to 16k
- * frame sizes. Set the max size to 15k+52 to prevent allocating 32k
+ * frame sizes. Set the max MTU size to 15k+52 to prevent allocating 32k
  * blocks and still have efficient handling. */
-#define GETHER_MAX_ETH_FRAME_LEN 15412
+#define GETHER_MAX_MTU_SIZE 15412
+#define GETHER_MAX_ETH_FRAME_LEN (GETHER_MAX_MTU_SIZE + ETH_HLEN)
 
 struct eth_dev {
/* lock is held while accessing port_usb
@@ -786,7 +787,7 @@ struct eth_dev *gether_setup_name(struct usb_gadget *g,
 
/* MTU range: 14 - 15412 */
net->min_mtu = ETH_HLEN;
-   net->max_mtu = GETHER_MAX_ETH_FRAME_LEN;
+   net->max_mtu = GETHER_MAX_MTU_SIZE;
 
dev->gadget = g;
SET_NETDEV_DEV(net, &g->dev);
@@ -848,7 +849,7 @@ struct net_device *gether_setup_name_default(const char 
*netname)
 
/* MTU range: 14 - 15412 */
net->min_mtu = ETH_HLEN;
-   net->max_mtu = GETHER_MAX_ETH_FRAME_LEN;
+   net->max_mtu = GETHER_MAX_MTU_SIZE;
 
return net;
 }
-- 
2.17.1

Re: [PATCH] thermal: Fix slab-out-of-bounds in thermal_cooling_device_stats_update()

[Zhang Rui]

On Tue, 2020-09-15 at 13:58 +0800, zhuguangqin...@gmail.com wrote:
> From: zhuguangqing 
> 
> In function thermal_cooling_device_stats_update(), if the input
> parameter
> new_state is greater or equal to stats->max_states, then it will
> cause
> slab-out-of-bounds error when execute the code as follows:
> stats->trans_table[stats->state * stats->max_states + new_state]++;
> 
> Two functions call the function
> thermal_cooling_device_stats_update().
> 1. cur_state_store()
> 2. thermal_cdev_set_cur_state()
> Both of the two functions call cdev->ops->set_cur_state(cdev, state)
> before thermal_cooling_device_stats_update(), if the return value is
> not 0, then thermal_cooling_device_stats_update() will not be called.
> So if all cdev->ops->set_cur_state(cdev, state) check validity of the
> parameter state, then it's ok. Unfortunately, it's not now.
> 
> We have two methods to avoid the slab-out-of-bounds error in
> thermal_cooling_device_stats_update().
> 1. Check the validity of the parameter state in all
> cdev->ops->set_cur_state(cdev, state).
> 2. Check the validity of the parameter state in
> thermal_cooling_device_stats_update().
> 
> Use method 2 in this patch. Because the modification is simple and
> resolve the problem in the scope of "#ifdef
> CONFIG_THERMAL_STATISTICS".
> 
> Signed-off-by: zhuguangqing 

Hi, Daniel,

this patch is a similar fix as

https://patchwork.kernel.org/project/linux-pm/patch/20200408041917.2329-4-rui.zh...@intel.com/

I think we'd better take the original fix from Takashi Iwai.
And I will refresh and submit the patches that supports dynamic cooling
states later when I have time.

thanks,
rui
> ---
>  drivers/thermal/thermal_sysfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/thermal_sysfs.c
> b/drivers/thermal/thermal_sysfs.c
> index 8c231219e15d..9c49f744d79d 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -756,7 +756,7 @@ void thermal_cooling_device_stats_update(struct
> thermal_cooling_device *cdev,
>  
>   spin_lock(&stats->lock);
>  
> - if (stats->state == new_state)
> + if (stats->state == new_state || new_state >= stats-
> >max_states)
>   goto unlock;
>  
>   update_time_in_state(stats);

Re: [PATCH v2 1/1] kasan: fix object remain in offline per-cpu quarantine

[Dmitry Vyukov]

On Tue, Nov 17, 2020 at 7:46 AM Kuan-Ying Lee
 wrote:
>
> On Mon, 2020-11-16 at 10:26 +0100, Dmitry Vyukov wrote:
> > On Mon, Nov 16, 2020 at 7:30 AM Kuan-Ying Lee
> >  wrote:
> > >
> > > We hit this issue in our internal test.
> > > When enabling generic kasan, a kfree()'d object is put into per-cpu
> > > quarantine first. If the cpu goes offline, object still remains in
> > > the per-cpu quarantine. If we call kmem_cache_destroy() now, slub
> > > will report "Objects remaining" error.
> > >
> > > [   74.982625] 
> > > =
> > > [   74.983380] BUG test_module_slab (Not tainted): Objects remaining in 
> > > test_module_slab on __kmem_cache_shutdown()
> > > [   74.984145] 
> > > -
> > > [   74.984145]
> > > [   74.984883] Disabling lock debugging due to kernel taint
> > > [   74.985561] INFO: Slab 0x(ptrval) objects=34 used=1 
> > > fp=0x(ptrval) flags=0x20010200
> > > [   74.986638] CPU: 3 PID: 176 Comm: cat Tainted: GB 
> > > 5.10.0-rc1-7-g4525c8781ec0-dirty #10
> > > [   74.987262] Hardware name: linux,dummy-virt (DT)
> > > [   74.987606] Call trace:
> > > [   74.987924]  dump_backtrace+0x0/0x2b0
> > > [   74.988296]  show_stack+0x18/0x68
> > > [   74.988698]  dump_stack+0xfc/0x168
> > > [   74.989030]  slab_err+0xac/0xd4
> > > [   74.989346]  __kmem_cache_shutdown+0x1e4/0x3c8
> > > [   74.989779]  kmem_cache_destroy+0x68/0x130
> > > [   74.990176]  test_version_show+0x84/0xf0
> > > [   74.990679]  module_attr_show+0x40/0x60
> > > [   74.991218]  sysfs_kf_seq_show+0x128/0x1c0
> > > [   74.991656]  kernfs_seq_show+0xa0/0xb8
> > > [   74.992059]  seq_read+0x1f0/0x7e8
> > > [   74.992415]  kernfs_fop_read+0x70/0x338
> > > [   74.993051]  vfs_read+0xe4/0x250
> > > [   74.993498]  ksys_read+0xc8/0x180
> > > [   74.993825]  __arm64_sys_read+0x44/0x58
> > > [   74.994203]  el0_svc_common.constprop.0+0xac/0x228
> > > [   74.994708]  do_el0_svc+0x38/0xa0
> > > [   74.995088]  el0_sync_handler+0x170/0x178
> > > [   74.995497]  el0_sync+0x174/0x180
> > > [   74.996050] INFO: Object 0x(ptrval) @offset=15848
> > > [   74.996752] INFO: Allocated in test_version_show+0x98/0xf0 age=8188 
> > > cpu=6 pid=172
> > > [   75.000802]  stack_trace_save+0x9c/0xd0
> > > [   75.002420]  set_track+0x64/0xf0
> > > [   75.002770]  alloc_debug_processing+0x104/0x1a0
> > > [   75.003171]  ___slab_alloc+0x628/0x648
> > > [   75.004213]  __slab_alloc.isra.0+0x2c/0x58
> > > [   75.004757]  kmem_cache_alloc+0x560/0x588
> > > [   75.005376]  test_version_show+0x98/0xf0
> > > [   75.005756]  module_attr_show+0x40/0x60
> > > [   75.007035]  sysfs_kf_seq_show+0x128/0x1c0
> > > [   75.007433]  kernfs_seq_show+0xa0/0xb8
> > > [   75.007800]  seq_read+0x1f0/0x7e8
> > > [   75.008128]  kernfs_fop_read+0x70/0x338
> > > [   75.008507]  vfs_read+0xe4/0x250
> > > [   75.008990]  ksys_read+0xc8/0x180
> > > [   75.009462]  __arm64_sys_read+0x44/0x58
> > > [   75.010085]  el0_svc_common.constprop.0+0xac/0x228
> > > [   75.011006] kmem_cache_destroy test_module_slab: Slab cache still has 
> > > objects
> > >
> > > Register a cpu hotplug function to remove all objects in the offline
> > > per-cpu quarantine when cpu is going offline. Set a per-cpu variable
> > > to indicate this cpu is offline.
> > >
> > > Signed-off-by: Kuan-Ying Lee 
> > > Suggested-by: Dmitry Vyukov 
> > > Reported-by: Guangye Yang 
> > > Cc: Andrey Ryabinin 
> > > Cc: Alexander Potapenko 
> > > Cc: Andrew Morton 
> > > Cc: Matthias Brugger 
> > > ---
> > >  mm/kasan/quarantine.c | 35 +++
> > >  1 file changed, 35 insertions(+)
> > >
> > > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> > > index 4c5375810449..16e618ea805e 100644
> > > --- a/mm/kasan/quarantine.c
> > > +++ b/mm/kasan/quarantine.c
> > > @@ -29,6 +29,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #include "../slab.h"
> > >  #include "kasan.h"
> > > @@ -43,6 +44,7 @@ struct qlist_head {
> > > struct qlist_node *head;
> > > struct qlist_node *tail;
> > > size_t bytes;
> > > +   bool offline;
> > >  };
> > >
> > >  #define QLIST_INIT { NULL, NULL, 0 }
> > > @@ -188,6 +190,11 @@ void quarantine_put(struct kasan_free_meta *info, 
> > > struct kmem_cache *cache)
> > > local_irq_save(flags);
> > >
> > > q = this_cpu_ptr(&cpu_quarantine);
> > > +   if (q->offline) {
> > > +   qlink_free(&info->quarantine_link, cache);
> > > +   local_irq_restore(flags);
> > > +   return;
> > > +   }
>
> I think we need to make sure objects will not be put in per-cpu
> quarantine which is offline.
>
> > > qlist_put(q, &info->quarantine_link, cache->size);
> > > if (unlikely(q->bytes > QUARANTINE_PERCPU_SIZE)) {
> > > qlist_move_all(q, &temp);
> > >

Re: [PATCH] ath11k: use MHI provided APIs to allocate and free MHI controller

[Kalle Valo]

Bhaumik Bhatt  writes:

> Use MHI provided APIs to allocate and free MHI controller to
> improve MHI host driver handling.

How does it improve the handling?

> This also fixes a memory leak as the MHI controller was allocated but
> never freed.
>
> Signed-off-by: Bhaumik Bhatt 
> ---
>  drivers/net/wireless/ath/ath11k/mhi.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

For ath11k patches please CC ath11k and linux-wireless lists so that
patchwork sees it. So you need to resend this.

Is this a new API? I need to understand if there are any dependencies
between mhi and ath trees, or if I can apply this directly to my ath.git
tree.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH net] atl1c: fix error return code in atl1c_probe()

[Heiner Kallweit]

Am 17.11.2020 um 03:55 schrieb Zhang Changzhong:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
> 
> Fixes: 85eb5bc33717 ("net: atheros: switch from 'pci_' to 'dma_' API")
> Reported-by: Hulk Robot 
> Signed-off-by: Zhang Changzhong 
> ---
>  drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c 
> b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> index 0c12cf7..3f65f2b 100644
> --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> @@ -2543,8 +2543,8 @@ static int atl1c_probe(struct pci_dev *pdev, const 
> struct pci_device_id *ent)
>* various kernel subsystems to support the mechanics required by a
>* fixed-high-32-bit system.
>*/
> - if ((dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)) != 0) ||
> - (dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)) != 0)) {
> + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));

I wonder whether you need this call at all, because 32bit is the default.
See following

"By default, the kernel assumes that your device can address 32-bits
of DMA addressing."

in https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt

> + if (err) {
>   dev_err(&pdev->dev, "No usable DMA configuration,aborting\n");
>   goto err_dma;
>   }
> 

[PATCH] mm: add colon to fix kernel-doc markups error for check_pte

[Alex Shi]

The function check_pte needs a correct colon for kernel-doc markup,
otherwise, gcc has the following warning for W=1,
mm/page_vma_mapped.c:86: warning: Function parameter or member 'pvmw'
not described in 'check_pte'

Signed-off-by: Alex Shi 
Cc: Andrew Morton 
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/page_vma_mapped.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
index 5e77b269c330..86e3a3688d59 100644
--- a/mm/page_vma_mapped.c
+++ b/mm/page_vma_mapped.c
@@ -66,18 +66,19 @@ static inline bool pfn_is_match(struct page *page, unsigned 
long pfn)
 
 /**
  * check_pte - check if @pvmw->page is mapped at the @pvmw->pte
+ * @pvmw: page_vma_mapped_walk struct, includes a pair pte and page for 
checking
  *
  * page_vma_mapped_walk() found a place where @pvmw->page is *potentially*
  * mapped. check_pte() has to validate this.
  *
- * @pvmw->pte may point to empty PTE, swap PTE or PTE pointing to arbitrary
- * page.
+ * pvmw->pte may point to empty PTE, swap PTE or PTE pointing to
+ * arbitrary page.
  *
  * If PVMW_MIGRATION flag is set, returns true if @pvmw->pte contains migration
  * entry that points to @pvmw->page or any subpage in case of THP.
  *
- * If PVMW_MIGRATION flag is not set, returns true if @pvmw->pte points to
- * @pvmw->page or any subpage in case of THP.
+ * If PVMW_MIGRATION flag is not set, returns true if pvmw->pte points to
+ * pvmw->page or any subpage in case of THP.
  *
  * Otherwise, return false.
  *
-- 
2.29.GIT

RE: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT Binding doc for soc unique ID

[Alice Guo]

> -Original Message-
> From: Krzysztof Kozlowski 
> Sent: 2020年11月17日 0:03
> To: Alice Guo 
> Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> dl-linux-imx ; Peng Fan ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT Binding
> doc for soc unique ID
> 
> Caution: EXT Email
> 
> On Mon, Nov 16, 2020 at 07:04:13AM +, Alice Guo wrote:
> >
> > > -Original Message-
> > > From: Krzysztof Kozlowski 
> > > Sent: 2020年11月15日 0:50
> > > To: Alice Guo 
> > > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> > > dl-linux-imx ; Peng Fan ;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org
> > > Subject: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT
> > > Binding doc for soc unique ID
> > >
> > > Caution: EXT Email
> > >
> > > On Fri, Nov 13, 2020 at 07:04:06PM +0800, Alice Guo wrote:
> > > > Add DT Binding doc for the Unique ID of i.MX 8M series.
> > > >
> > > > Signed-off-by: Alice Guo 
> > > > ---
> > > >  .../devicetree/bindings/arm/fsl.yaml  | 25
> > > +++
> > > >  1 file changed, 25 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > index e4db0f9ed664..f4faebbb57da 100644
> > > > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > @@ -901,6 +901,31 @@ properties:
> > > >- fsl,s32v234-evb   # S32V234-EVB2
> Customer
> > > Evaluation Board
> > > >- const: fsl,s32v234
> > > >
> > > > +  soc:
> > > > +type: object
> > > > +properties:
> > > > +  compatible:
> > > > +oneOf:
> > > > +  - description: i.MX8M SoCs
> > > > +items:
> > > > +  - enum:
> > > > +  - fsl,imx8mm-soc
> > > > +  - fsl,imx8mn-soc
> > > > +  - fsl,imx8mp-soc
> > > > +  - fsl,imx8mq-soc
> > > > +  - const: simple-bus
> > > > +
> > > > +  - description: Other SoCs
> > > > +items:
> > > > +  - const: simple-bus
> > > > +
> > > > +  nvmem-cells:
> > > > +maxItems: 1
> > > > +description: Phandle to the SOC Unique ID provided by a
> > > > + nvmem node
> > > > +
> > > > +  nvmem-cells-names:
> > > > +const: soc_unique_id
> > > > +
> > > >  additionalProperties: true
> > >
> > > The "soc" node should be required for these compatibles. Otherwise
> > > you will have to stay with this
> > > backwards-compatible-DTB-device-initcall-glue for many years... I think 
> > > you
> can achieve it with allOf.
> > >
> > [Alice Guo]Hi,
> > I find that my description for compatible is ambiguous. There are two kinds 
> > of
> compatible of the "soc" node:
> > 1. For dtsi files used for SoCs other than imx8m series SoCs and old
> > version dtsi files used for imx8m series SoCs, compatible of the "soc" node 
> > is
> "simple-bus".
> > 2. For new version dtsi files used for imx8m series SoCs, compatible of the
> "soc" node is {"fsl,imx8mX-soc","simple-bus"}.
> >
> > "nvmem-cell" is an optional property.
> >
> > I do not understand what you mean. You mean that limit the compatible of
> "soc" node must include " fsl,imx8mX-soc" in new version dts files. Is my
> understanding correct?
> 
> All new DTS files should have soc node with "fsl,imx8mX-soc" and this should 
> be
> required by dtschema. The nvmem-cells and related properties do not look like
> optional. From the hardware perspective - they are always present. From the
> driver point of view: they are required and driver will fail to work.

[Alice Guo] 
[Alice Guo] 
+  soc:
+type: object
+properties:
+  compatible:
+oneOf:
+  - description: new version DTS for i.MX8M SoCs
+items:
+  - enum:
+  - fsl,imx8mm-soc
+  - fsl,imx8mn-soc
+  - fsl,imx8mp-soc
+  - fsl,imx8mq-soc
+  - const: simple-bus
+
+  - description: other SoCs and old version DTS for i.MX8M SoCs
+items:
+  - const: simple-bus
+
+  nvmem-cells:
+maxItems: 1
+description: Phandle to the SOC Unique ID provided by a nvmem 
+ node
+
+  nvmem-cells-names:
+const: soc_unique_id
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - fsl,imx8mm-soc
+  - fsl,imx8mn-soc
+  - fsl,imx8mp-soc
+  - fsl,imx8mq-soc
+const: simple-bus
+
+then:
+  required:
+- nvmem-cells
+- nvmem-cells-names

The above is my modification. Is that ok

Re: + mm-shmem-use-kmem_cache_zalloc-in-shmem_alloc_inode.patch added to -mm tree

[Stephen Rothwell]

Hi Hugh,

On Mon, 16 Nov 2020 22:17:20 -0800 (PST) Hugh Dickins  wrote:
>
> On Mon, 16 Nov 2020, a...@linux-foundation.org wrote:
> > 
> > The patch titled
> >  Subject: mm/shmem: use kmem_cache_zalloc in shmem_alloc_inode()
> > has been added to the -mm tree.  Its filename is
> >  mm-shmem-use-kmem_cache_zalloc-in-shmem_alloc_inode.patch
> > 
> > This patch should soon appear at
> > 
> > https://ozlabs.org/~akpm/mmots/broken-out/mm-shmem-use-kmem_cache_zalloc-in-shmem_alloc_inode.patch
> > and later at
> > 
> > https://ozlabs.org/~akpm/mmotm/broken-out/mm-shmem-use-kmem_cache_zalloc-in-shmem_alloc_inode.patch
> > 
> > Before you just go and hit "reply", please:
> >a) Consider who else should be cc'ed
> >b) Prefer to cc a suitable mailing list as well
> >c) Ideally: find the original patch on the mailing list and do a
> >   reply-to-all to that, adding suitable additional cc's
> > 
> > *** Remember to use Documentation/process/submit-checklist.rst when testing 
> > your code ***
> > 
> > The -mm tree is included into linux-next and is updated
> > there every 3-4 working days
> > 
> > --
> > From: Hui Su 
> > Subject: mm/shmem: use kmem_cache_zalloc in shmem_alloc_inode()  
> 
> Andrew, Stephen, please revert this untested "cleanup" from your
> trees a.s.a.p: it's a disaster for anyone using shmem/tmpfs.

Thanks for that.  I have also bisected my boot failures to that commit
and so have reverted it from linux-next today.

-- 
Cheers,
Stephen Rothwell


pgpuNyVry7gja.pgp
Description: OpenPGP digital signature

RE: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT Binding doc for soc unique ID

[Alice Guo]

> -Original Message-
> From: Krzysztof Kozlowski 
> Sent: 2020年11月17日 0:03
> To: Alice Guo 
> Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> dl-linux-imx ; Peng Fan ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT Binding
> doc for soc unique ID
> 
> Caution: EXT Email
> 
> On Mon, Nov 16, 2020 at 07:04:13AM +, Alice Guo wrote:
> >
> > > -Original Message-
> > > From: Krzysztof Kozlowski 
> > > Sent: 2020年11月15日 0:50
> > > To: Alice Guo 
> > > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> > > dl-linux-imx ; Peng Fan ;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org
> > > Subject: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT
> > > Binding doc for soc unique ID
> > >
> > > Caution: EXT Email
> > >
> > > On Fri, Nov 13, 2020 at 07:04:06PM +0800, Alice Guo wrote:
> > > > Add DT Binding doc for the Unique ID of i.MX 8M series.
> > > >
> > > > Signed-off-by: Alice Guo 
> > > > ---
> > > >  .../devicetree/bindings/arm/fsl.yaml  | 25
> > > +++
> > > >  1 file changed, 25 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > index e4db0f9ed664..f4faebbb57da 100644
> > > > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > @@ -901,6 +901,31 @@ properties:
> > > >- fsl,s32v234-evb   # S32V234-EVB2
> Customer
> > > Evaluation Board
> > > >- const: fsl,s32v234
> > > >
> > > > +  soc:
> > > > +type: object
> > > > +properties:
> > > > +  compatible:
> > > > +oneOf:
> > > > +  - description: i.MX8M SoCs
> > > > +items:
> > > > +  - enum:
> > > > +  - fsl,imx8mm-soc
> > > > +  - fsl,imx8mn-soc
> > > > +  - fsl,imx8mp-soc
> > > > +  - fsl,imx8mq-soc
> > > > +  - const: simple-bus
> > > > +
> > > > +  - description: Other SoCs
> > > > +items:
> > > > +  - const: simple-bus
> > > > +
> > > > +  nvmem-cells:
> > > > +maxItems: 1
> > > > +description: Phandle to the SOC Unique ID provided by a
> > > > + nvmem node
> > > > +
> > > > +  nvmem-cells-names:
> > > > +const: soc_unique_id
> > > > +
> > > >  additionalProperties: true
> > >
> > > The "soc" node should be required for these compatibles. Otherwise
> > > you will have to stay with this
> > > backwards-compatible-DTB-device-initcall-glue for many years... I think 
> > > you
> can achieve it with allOf.
> > >
> > [Alice Guo]Hi,
> > I find that my description for compatible is ambiguous. There are two kinds 
> > of
> compatible of the "soc" node:
> > 1. For dtsi files used for SoCs other than imx8m series SoCs and old
> > version dtsi files used for imx8m series SoCs, compatible of the "soc" node 
> > is
> "simple-bus".
> > 2. For new version dtsi files used for imx8m series SoCs, compatible of the
> "soc" node is {"fsl,imx8mX-soc","simple-bus"}.
> >
> > "nvmem-cell" is an optional property.
> >
> > I do not understand what you mean. You mean that limit the compatible of
> "soc" node must include " fsl,imx8mX-soc" in new version dts files. Is my
> understanding correct?
> 
> All new DTS files should have soc node with "fsl,imx8mX-soc" and this should 
> be
> required by dtschema. The nvmem-cells and related properties do not look like
> optional. From the hardware perspective - they are always present. From the
> driver point of view: they are required and driver will fail to work.

[Alice Guo] 
+  soc:
+type: object
+properties:
+  compatible:
+oneOf:
+  - description: new version DTS for i.MX8M SoCs
+items:
+  - enum:
+  - fsl,imx8mm-soc
+  - fsl,imx8mn-soc
+  - fsl,imx8mp-soc
+  - fsl,imx8mq-soc
+  - const: simple-bus
+
+  - description: other SoCs and old version DTS for i.MX8M SoCs
+items:
+  - const: simple-bus
+
+  nvmem-cells:
+maxItems: 1
+description: Phandle to the SOC Unique ID provided by a nvmem node
+
+  nvmem-cells-names:
+const: soc_unique_id
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - fsl,imx8mm-soc
+  - fsl,imx8mn-soc
+  - fsl,imx8mp-soc
+  - fsl,imx8mq-soc
+const: simple-bus
+
+then:
+  required:
+- nvmem-cells
+- nvmem-cells-names

The above is my modification. Is that ok?

Best regards,

linux-next: boot failure in next-20201117

[Stephen Rothwell]

Hi all,

My qemu boot tests failed this evening with the following logs:

0.021080T0 Mount-cache hash table entries: 8192 (order: 0, 65536 bytes, 
linear)
0.021201T0 Mountpoint-cache hash table entries: 8192 (order: 0, 65536 
bytes, linear)
0.030154T0  cut here 
0.031403T0 WARNING: CPU: 0 PID: 0 at mm/slub.c:2574 
___slab_alloc+0x2f8/0x7b0
0.031500T0 Modules linked in:
0.032048T0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-rc4 #2
0.032244T0 NIP:  c041aec8 LR: c041d7b0 CTR: 
c037fd00
0.032367T0 REGS: c13b36d0 TRAP: 0700   Not tainted  (5.10.0-rc4)
0.032435T0 MSR:  82029033   CR: 
4402  XER: 
0.032822T0 CFAR: c041ac28 IRQMASK: 1 
0.032822T0 GPR00: c041d7b0 c13b3960 c13b7d00 
c601c200 
0.032822T0 GPR04: 0dc0  c037fd2c 
c0007fc99db0 
0.032822T0 GPR08: 7eb2 c03801c0  
0010 
0.032822T0 GPR12: 24000222 c15b  
012b2958 
0.032822T0 GPR16: 012b2c70 012b2a88  
01368548 
0.032822T0 GPR20: 0100 c135c800 01b90008 
 
0.032822T0 GPR24: c601c2b8  c037fd2c 
0dc0 
0.032822T0 GPR28: c0007fc99db0 c601c200 0dc0 
 
0.033698T0 NIP c041aec8 ___slab_alloc+0x2f8/0x7b0
0.033829T0 LR c041d7b0 kmem_cache_alloc+0x3c0/0x440
0.034032T0 Call Trace:
0.034464T0 c13b3960 26af 0x26af (unreliable)
0.034670T0 c13b3a30 c041d7b0 
kmem_cache_alloc+0x3c0/0x440
0.034767T0 c13b3aa0 c037fd2c shmem_alloc_inode+0x2c/0x50
0.034841T0 c13b3ac0 c0488a08 alloc_inode+0x48/0x150
0.034913T0 c13b3b00 c04894b0 new_inode+0x30/0x140
0.034986T0 c13b3b40 c0386a74 shmem_get_inode+0xc4/0x5b0
0.035059T0 c13b3bf0 c038765c 
shmem_fill_super+0x19c/0x2f0
0.035134T0 c13b3c30 c0460db4 get_tree_nodev+0xb4/0x130
0.035207T0 c13b3c70 c037f788 shmem_get_tree+0x28/0x40
0.035285T0 c13b3c90 c045dfb8 vfs_get_tree+0x48/0x120
0.035357T0 c13b3d00 c04935e0 
vfs_kern_mount.part.0+0xd0/0x130
0.035427T0 c13b3d40 c0493704 kern_mount+0x34/0x70
0.035592T0 c13b3d60 c1041620 shmem_init+0x8c/0x174
0.035670T0 c13b3dd0 c104c500 mnt_init+0x184/0x2fc
0.035745T0 c13b3e70 c104bfa4 vfs_caches_init+0x110/0x138
0.035819T0 c13b3ef0 c1014294 start_kernel+0x67c/0x720
0.035898T0 c13b3f90 c000cb88 
start_here_common+0x1c/0x614
0.036095T0 Instruction dump:
0.036261T0 7a5207e0 7f1dc214 2d89 eaad0968 ebfc0018 2c3f 
40820498 e93d0048 
0.036426T0 2c29 41820014 2c14 4182000c <0fe0> 6042 
41920140 e8980008 
0.037330T0 --- end trace 5025492be6dd1f87 ---
0.091826T1 POWER8 performance monitor hardware support registered
0.093359T1 rcu: Hierarchical SRCU implementation.

So the WARN_ON is

WARN_ON_ONCE(s->ctor && (flags & __GFP_ZERO));

in new_slab_objects().

...

2.359086T1 Run /init as init process
2.622483   T52 mount (52) used greatest stack depth: 12560 bytes left
2.826397   T54 mount (54) used greatest stack depth: 12464 bytes left
Starting logging: OK
Initializing random number generator... 3.518701   T69 cat (69) used 
greatest stack depth: 12192 bytes left
3.554960   T70 BUG: Kernel NULL pointer dereference on write at 0x0008
3.555090   T70 Faulting instruction address: 0xc03a63ac
3.555600   T70 Oops: Kernel access of bad area, sig: 11 #1
3.555723   T70 LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
3.555827   T70 Modules linked in:
3.555987   T70 CPU: 0 PID: 70 Comm: rm Tainted: GW 
5.10.0-rc4 #2
3.556052   T70 NIP:  c03a63ac LR: c03a637c CTR: 
c0486d10
3.556122   T70 REGS: c83539e0 TRAP: 0300   Tainted: GW  
(5.10.0-rc4)
3.556183   T70 MSR:  80009033   CR: 22000442  
XER: 2000
3.556338   T70 CFAR: c00101c0 DAR: 0008 DSISR: 4200 
IRQMASK: 0 
3.556338   T70 GPR00: c03a637c c8353c70 c13b7d00 
 
3.556338   T70 GPR04: c6ea68f8 0064 0014 
 
3.556338   T70 GPR08:  c15b  
c74bac80 
3.556338   T70 GPR12: c

[PATCH v3 3/3] scsi: ufs: Print host regs in IRQ handler when AH8 error happens

[Can Guo]

When AH8 error happens, all the regs and states are dumped in err handler.
Sometime we need to look into host regs right after AH8 error happens,
which is before leaving the IRQ handler.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index cd7394e..a7857f6 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6057,7 +6057,8 @@ static irqreturn_t ufshcd_check_errors(struct ufs_hba 
*hba)
hba->saved_uic_err |= hba->uic_error;
 
/* dump controller state before resetting */
-   if ((hba->saved_err & (INT_FATAL_ERRORS)) ||
+   if ((hba->saved_err &
+(INT_FATAL_ERRORS | UFSHCD_UIC_HIBERN8_MASK)) ||
(hba->saved_uic_err &&
 (hba->saved_uic_err != UFSHCD_UIC_PA_GENERIC_ERROR))) {
dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 
0x%x\n",
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v3 1/3] scsi: ufs: Serialize eh_work with system PM events and async scan

[Can Guo]

Serialize eh_work with system PM events and async scan to make sure eh_work
does not run in parallel with them.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 64 +--
 drivers/scsi/ufs/ufshcd.h |  1 +
 2 files changed, 41 insertions(+), 24 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 1d8134e..7e764e8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5597,7 +5597,9 @@ static inline void ufshcd_schedule_eh_work(struct ufs_hba 
*hba)
 static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
 {
pm_runtime_get_sync(hba->dev);
-   if (pm_runtime_suspended(hba->dev)) {
+   if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
+   enum ufs_pm_op pm_op;
+
/*
 * Don't assume anything of pm_runtime_get_sync(), if
 * resume fails, irq and clocks can be OFF, and powers
@@ -5612,7 +5614,8 @@ static void ufshcd_err_handling_prepare(struct ufs_hba 
*hba)
if (!ufshcd_is_clkgating_allowed(hba))
ufshcd_setup_clocks(hba, true);
ufshcd_release(hba);
-   ufshcd_vops_resume(hba, UFS_RUNTIME_PM);
+   pm_op = hba->is_sys_suspended ? UFS_RUNTIME_PM : UFS_SYSTEM_PM;
+   ufshcd_vops_resume(hba, pm_op);
} else {
ufshcd_hold(hba, false);
if (hba->clk_scaling.is_allowed) {
@@ -5633,7 +5636,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba 
*hba)
 
 static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
 {
-   return (hba->ufshcd_state == UFSHCD_STATE_ERROR ||
+   return (!hba->is_powered || hba->ufshcd_state == UFSHCD_STATE_ERROR ||
(!(hba->saved_err || hba->saved_uic_err || hba->force_reset ||
ufshcd_is_link_broken(hba;
 }
@@ -5646,6 +5649,7 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
struct request_queue *q;
int ret;
 
+   hba->is_sys_suspended = false;
/*
 * Set RPM status of hba device to RPM_ACTIVE,
 * this also clears its runtime error.
@@ -5704,11 +5708,13 @@ static void ufshcd_err_handler(struct work_struct *work)
 
hba = container_of(work, struct ufs_hba, eh_work);
 
+   down(&hba->eh_sem);
spin_lock_irqsave(hba->host->host_lock, flags);
if (ufshcd_err_handling_should_stop(hba)) {
if (hba->ufshcd_state != UFSHCD_STATE_ERROR)
hba->ufshcd_state = UFSHCD_STATE_OPERATIONAL;
spin_unlock_irqrestore(hba->host->host_lock, flags);
+   up(&hba->eh_sem);
return;
}
ufshcd_set_eh_in_progress(hba);
@@ -5716,20 +5722,18 @@ static void ufshcd_err_handler(struct work_struct *work)
ufshcd_err_handling_prepare(hba);
spin_lock_irqsave(hba->host->host_lock, flags);
ufshcd_scsi_block_requests(hba);
-   /*
-* A full reset and restore might have happened after preparation
-* is finished, double check whether we should stop.
-*/
-   if (ufshcd_err_handling_should_stop(hba)) {
-   if (hba->ufshcd_state != UFSHCD_STATE_ERROR)
-   hba->ufshcd_state = UFSHCD_STATE_OPERATIONAL;
-   goto out;
-   }
hba->ufshcd_state = UFSHCD_STATE_RESET;
 
/* Complete requests that have door-bell cleared by h/w */
ufshcd_complete_requests(hba);
 
+   /*
+* A full reset and restore might have happened after preparation
+* is finished, double check whether we should stop.
+*/
+   if (ufshcd_err_handling_should_stop(hba))
+   goto skip_err_handling;
+
if (hba->dev_quirks & UFS_DEVICE_QUIRK_RECOVERY_FROM_DL_NAC_ERRORS) {
bool ret;
 
@@ -5737,17 +5741,10 @@ static void ufshcd_err_handler(struct work_struct *work)
/* release the lock as ufshcd_quirk_dl_nac_errors() may sleep */
ret = ufshcd_quirk_dl_nac_errors(hba);
spin_lock_irqsave(hba->host->host_lock, flags);
-   if (!ret && !hba->force_reset && ufshcd_is_link_active(hba))
+   if (!ret && ufshcd_err_handling_should_stop(hba))
goto skip_err_handling;
}
 
-   if (hba->force_reset || ufshcd_is_link_broken(hba) ||
-   ufshcd_is_saved_err_fatal(hba) ||
-   ((hba->saved_err & UIC_ERROR) &&
-(hba->saved_uic_err & (UFSHCD_UIC_DL_NAC_RECEIVED_ERROR |
-   UFSHCD_UIC_DL_TCx_REPLAY_ERROR
-   needs_reset = true;
-
if ((hba->saved_err & (INT_FATAL_ERRORS | UFSHCD_UIC_HIBERN8_MASK)) ||
(hba->saved_uic_err &&
 (hba->saved_uic_err != UFSHCD_UIC_PA_GENERIC_ERROR))) {
@@ -5767,8 +5764,14 @@ static void ufshcd_err_handler(struct work_st

Re: [PATCH v2] ttyprintk: optimize tpk_close flush code

[Greg KH]

On Tue, Nov 17, 2020 at 10:21:07AM +0800, Junyong Sun wrote:
> tpk_printk(NULL,0) do nothing but call tpk_flush to
> flush buffer, so why don't use tpk_flush diretcly?
> this is a small optimization.
> 
> Signed-off-by: Junyong Sun 
> ---
> changes in v2:
> - rm the flush comment as tpk_flush makes it obvious.
> ---
> ---
>  drivers/char/ttyprintk.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/char/ttyprintk.c b/drivers/char/ttyprintk.c
> index 6a0059e..1f82742 100644
> --- a/drivers/char/ttyprintk.c
> +++ b/drivers/char/ttyprintk.c
> @@ -103,8 +103,7 @@ static void tpk_close(struct tty_struct *tty, struct file 
> *filp)
>   unsigned long flags;
>  
>   spin_lock_irqsave(&tpkp->spinlock, flags);
> - /* flush tpk_printk buffer */
> - tpk_printk(NULL, 0);
> + tpk_flush();
>   spin_unlock_irqrestore(&tpkp->spinlock, flags);

Why did you not make the change to tpk_printk() as well that I asked you
to?

It is a static function, you control the callers, so the extra "is this
NULL, if so flush" logic makes no sense to keep around anymore, right?

thanks,

greg k-h

[PATCH v3 2/3] scsi: ufs: Fix a racing problem between ufshcd_abort and eh_work

[Can Guo]

In current task abort routine, if task abort happens to the device W-LU,
the code directly jumps to ufshcd_eh_host_reset_handler() to perform a
full reset and restore then returns FAIL or SUCCESS. Commands sent to the
device W-LU are most likely the SSU cmds sent during UFS PM operations. If
such SSU cmd enters task abort routine, when ufshcd_eh_host_reset_handler()
flushes eh_work, there will be racing because err_handler is serialized
with any PM operations.

Since the main idea of aborting one cmd to the device W-LU is to perform
a full reset and restore, in order to resolve the racing problem, we merely
clean up the lrb taken by this cmd, queue the eh_work and abort the cmd.
Since the cmd has been aborted, the PM operation which sends the cmd simply
errors out, thus err_handler will not be blocked by ongoing PM operations
and err_handler can also recover PM error if any, which comes as another
benefit of this change.

Because such cmd is aborted even before it is actually cleared from HW, set
the lrb->in_use flag to prevent subsequent cmds, including SCSI cmds and
dev cmds, from taking the lrb released by this cmd. Flag lrb->in_use shall
evetually be cleared in __ufshcd_transfer_req_compl() invoked by the full
reset and restore from err_handler.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 55 ---
 drivers/scsi/ufs/ufshcd.h |  2 ++
 2 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 7e764e8..cd7394e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2539,6 +2539,14 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *cmd)
(hba->clk_gating.state != CLKS_ON));
 
lrbp = &hba->lrb[tag];
+   if (unlikely(lrbp->in_use)) {
+   if (hba->pm_op_in_progress)
+   set_host_byte(cmd, DID_BAD_TARGET);
+   else
+   err = SCSI_MLQUEUE_HOST_BUSY;
+   ufshcd_release(hba);
+   goto out;
+   }
 
WARN_ON(lrbp->cmd);
lrbp->cmd = cmd;
@@ -2781,6 +2789,11 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
 
init_completion(&wait);
lrbp = &hba->lrb[tag];
+   if (unlikely(lrbp->in_use)) {
+   err = -EBUSY;
+   goto out;
+   }
+
WARN_ON(lrbp->cmd);
err = ufshcd_compose_dev_cmd(hba, lrbp, cmd_type, tag);
if (unlikely(err))
@@ -2797,6 +2810,7 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
 
err = ufshcd_wait_for_dev_cmd(hba, lrbp, timeout);
 
+out:
ufshcd_add_query_upiu_trace(hba, tag,
err ? "query_complete_err" : "query_complete");
 
@@ -4932,6 +4946,7 @@ static void __ufshcd_transfer_req_compl(struct ufs_hba 
*hba,
 
for_each_set_bit(index, &completed_reqs, hba->nutrs) {
lrbp = &hba->lrb[index];
+   lrbp->in_use = false;
lrbp->compl_time_stamp = ktime_get();
cmd = lrbp->cmd;
if (cmd) {
@@ -6374,8 +6389,12 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba 
*hba,
 
init_completion(&wait);
lrbp = &hba->lrb[tag];
-   WARN_ON(lrbp->cmd);
+   if (unlikely(lrbp->in_use)) {
+   err = -EBUSY;
+   goto out;
+   }
 
+   WARN_ON(lrbp->cmd);
lrbp->cmd = NULL;
lrbp->sense_bufflen = 0;
lrbp->sense_buffer = NULL;
@@ -6447,6 +6466,7 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba 
*hba,
}
}
 
+out:
blk_put_request(req);
 out_unlock:
up_read(&hba->clk_scaling_lock);
@@ -6696,16 +6716,6 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
BUG();
}
 
-   /*
-* Task abort to the device W-LUN is illegal. When this command
-* will fail, due to spec violation, scsi err handling next step
-* will be to send LU reset which, again, is a spec violation.
-* To avoid these unnecessary/illegal step we skip to the last error
-* handling stage: reset and restore.
-*/
-   if (lrbp->lun == UFS_UPIU_UFS_DEVICE_WLUN)
-   return ufshcd_eh_host_reset_handler(cmd);
-
ufshcd_hold(hba, false);
reg = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
/* If command is already aborted/completed, return SUCCESS */
@@ -6726,7 +6736,7 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
 * to reduce repeated printouts. For other aborted requests only print
 * basic details.
 */
-   scsi_print_command(hba->lrb[tag].cmd);
+   scsi_print_command(cmd);
if (!hba->req_abort_count) {
ufshcd_update_reg_hist(&hba->ufs_stats.task_abort, 0);
ufshcd_print_host_regs(hba);
@@ -6745,6 +6755,27 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
goto cl

Re: [PATCH] speakup: fix uninitialized flush_lock

[Samuel Thibault]

Yang Yingliang, le mar. 17 nov. 2020 09:22:29 +0800, a ecrit:
> The flush_lock is uninitialized, use DEFINE_SPINLOCK
> to define and initialize flush_lock.
> 
> Fixes: c6e3fd22cd53 ("Staging: add speakup to the staging directory")
> Reported-by: Hulk Robot 
> Signed-off-by: Yang Yingliang 

Reviewed-by: Samuel Thibault 

> ---
>  drivers/accessibility/speakup/speakup_dectlk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/accessibility/speakup/speakup_dectlk.c 
> b/drivers/accessibility/speakup/speakup_dectlk.c
> index 780214b5ca16..ab6d61e80b1c 100644
> --- a/drivers/accessibility/speakup/speakup_dectlk.c
> +++ b/drivers/accessibility/speakup/speakup_dectlk.c
> @@ -37,7 +37,7 @@ static unsigned char get_index(struct spk_synth *synth);
>  static int in_escape;
>  static int is_flushing;
>  
> -static spinlock_t flush_lock;
> +static DEFINE_SPINLOCK(flush_lock);
>  static DECLARE_WAIT_QUEUE_HEAD(flush);
>  
>  static struct var_t vars[] = {
> -- 
> 2.25.1
> 

Re: [PATCH v4 01/10] Add auxiliary bus support

[Greg KH]

On Tue, Nov 17, 2020 at 07:30:00AM +0200, Leon Romanovsky wrote:
> On Fri, Nov 13, 2020 at 08:18:50AM -0800, Dave Ertman wrote:
> > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> > It enables drivers to create an auxiliary_device and bind an
> > auxiliary_driver to it.
> >
> > The bus supports probe/remove shutdown and suspend/resume callbacks.
> > Each auxiliary_device has a unique string based id; driver binds to
> > an auxiliary_device based on this id through the bus.
> >
> > Co-developed-by: Kiran Patil 
> > Signed-off-by: Kiran Patil 
> > Co-developed-by: Ranjani Sridharan 
> > Signed-off-by: Ranjani Sridharan 
> > Co-developed-by: Fred Oh 
> > Signed-off-by: Fred Oh 
> > Co-developed-by: Leon Romanovsky 
> > Signed-off-by: Leon Romanovsky 
> > Reviewed-by: Pierre-Louis Bossart 
> > Reviewed-by: Shiraz Saleem 
> > Reviewed-by: Parav Pandit 
> > Reviewed-by: Dan Williams 
> > Signed-off-by: Dave Ertman 
> > ---
> 
> Greg,
> 
> This horse was beaten to death, can we please progress with this patch?
> Create special topic branch or ack so I'll prepare this branch.
> 
> We are in -rc4 now and we (Mellanox) can't hold our submissions anymore.
> My mlx5_core probe patches [1] were too intrusive and they are ready to
> be merged, Parav's patches got positive review as well [2] and will be
> taken next.
> 
> We delayed and have in our internal queues the patches for VDPA, eswitch
> and followup for mlx5_core probe rework, but trapped due to this AUX bus
> patch.

There are no deadlines for kernel patches here, sorry.  Give me some
time to properly review this, core kernel changes should not be rushed.

Also, if you really want to blame someone for the delay, look at the
patch submitters, not the reviewers, as they are the ones that took a
very long time with this over the lifecycle of this patchset, not me.  I
have provided many "instant" reviews of this patchset, and then months
went by between updates from them.

greg k-h

[PATCH rdma-next v5 0/3] Track memory allocation with restrack DB help (Part II)

[Leon Romanovsky]

From: Leon Romanovsky 

Changelog:
v5:
 * Reorder patches to postpone changes in rdma_restrack_add to be in next 
series.
v4: https://lore.kernel.org/linux-rdma/20201104144008.3808124-1-l...@kernel.org/
 * Rebased on latest for-upstream, all that time the patches were in
 our regression and didn't introduce any issues.
 * Took first five patches that hadn't any comments
v3: https://lore.kernel.org/lkml/20200926101938.2964394-1-l...@kernel.org
 * Rebased on already accepted patches.
 * Added mlx4 special QPs to the list of not-tracked QPs (dropped previous mlx4 
special QP patch).
 * Separated to two patches change in return value of cma_listen_* routines.
 * Changed commit messages and added Fixes as Jason requested.
v2: https://lore.kernel.org/linux-rdma/20200907122156.478360-1-l...@kernel.org/
 * Added new patch to fix mlx4 failure on SR-IOV, it didn't have port set.
 * Changed "RDMA/cma: Delete from restrack DB after successful destroy" patch.
v1: https://lore.kernel.org/lkml/20200830101436.108487-1-l...@kernel.org
 * Fixed rebase error, deleted second assignment of qp_type.
 * Rebased code on latests rdma-next, the changes in cma.c caused to change
   in patch "RDMA/cma: Delete from restrack DB after successful destroy".
 * Dropped patch of port assignment, it is already done as part of this
   series.
 * I didn't add @calller description, regular users should not use _named() 
funciton.
v0: https://lore.kernel.org/lkml/20200824104415.1090901-1-l...@kernel.org

--

Leon Romanovsky (3):
  RDMA/core: Track device memory MRs
  RDMA/core: Allow drivers to disable restrack DB
  RDMA/restrack: Support all QP types

 drivers/infiniband/core/core_priv.h   | 25 ++-
 drivers/infiniband/core/counters.c|  2 +-
 drivers/infiniband/core/restrack.c| 12 +++--
 drivers/infiniband/core/uverbs_cmd.c  |  4 +--
 drivers/infiniband/core/uverbs_std_types_mr.c |  4 +++
 drivers/infiniband/core/uverbs_std_types_qp.c |  4 +--
 drivers/infiniband/core/verbs.c   | 11 
 drivers/infiniband/hw/mlx4/qp.c   |  5 
 drivers/infiniband/hw/mlx5/qp.c   |  2 +-
 include/rdma/ib_verbs.h   | 10 ++--
 include/rdma/restrack.h   | 24 ++
 11 files changed, 70 insertions(+), 33 deletions(-)

--
2.28.0

Re: [PATCH] PCI: dwc: fix error return code in dw_pcie_host_init()

[wanghai (M)]

在 2020/11/17 9:49, Jisheng Zhang 写道:

On Mon, 16 Nov 2020 21:50:23 +0800 Wang Hai wrote:



Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

good catch.


Fixes: 07940c369a6b ("PCI: dwc: Fix MSI page leakage in suspend/resume")
Reported-by: Hulk Robot 
Signed-off-by: Wang Hai 

 if (dma_mapping_error(pci->dev, pp->msi_data)) {
 dev_err(pci->dev, "Failed to map MSI data\n");
 pp->msi_data = 0;
+   ret = -ENOMEM;

what about use the return value of dma_maping_error()? I.E

ret = dma_mapping_error()
if (ret) {

}



Thanks for your review,  I just sent v2

"[PATCH v2] PCI: dwc: fix error return code in dw_pcie_host_init()"


.

Re: [PATCH v2 10/13] arc: use FLATMEM with freeing of unused memory map instead of DISCONTIGMEM

[Mike Rapoport]

On Tue, Nov 17, 2020 at 06:40:16AM +, Vineet Gupta wrote:
> Hi Mike,
> 
> On 11/1/20 9:04 AM, Mike Rapoport wrote:
> > From: Mike Rapoport 
> >
> > Currently ARC uses DISCONTIGMEM to cope with sparse physical memory address
> > space on systems with 2 memory banks. While DISCONTIGMEM avoids wasting
> > memory on unpopulated memory map, it adds both memory and CPU overhead
> > relatively to FLATMEM. Moreover, DISCONTINGMEM is generally considered
> > deprecated.
> >
> > The obvious replacement for DISCONTIGMEM would be SPARSEMEM, but it is also
> > less efficient than FLATMEM in pfn_to_page() and page_to_pfn() conversions.
> > Besides it requires tuning of SECTION_SIZE which is not trivial for
> > possible ARC memory configuration.
> >
> > Since the memory map for both banks is always allocated from the "lowmem"
> > bank, it is possible to use FLATMEM for two-bank configuration and simply
> > free the unused hole in the memory map. All is required for that is to
> > provide ARC-specific pfn_valid() that will take into account actual
> > physical memory configuration and define HAVE_ARCH_PFN_VALID.
> >
> > The resulting kernel image configured with defconfig + HIGHMEM=y is
> > smaller:
> >
> > $ size a/vmlinux b/vmlinux
> > textdata bss dec hex filename
> > 4673503 1245456  279756 6198715  5e95bb a/vmlinux
> > 4658706 1246864  279756 6185326  5e616e b/vmlinux
> >
> > $ ./scripts/bloat-o-meter a/vmlinux b/vmlinux
> > add/remove: 28/30 grow/shrink: 42/399 up/down: 10986/-29025 (-18039)
> > ...
> > Total: Before=4709315, After=4691276, chg -0.38%
> >
> > Booting nSIM with haps_ns.dts results in the following memory usage
> > reports:
> >
> > a:
> > Memory: 1559104K/1572864K available (3531K kernel code, 595K rwdata, 752K 
> > rodata, 136K init, 275K bss, 13760K reserved, 0K cma-reserved, 1048576K 
> > highmem)
> >
> > b:
> > Memory: 1559112K/1572864K available (3519K kernel code, 594K rwdata, 752K 
> > rodata, 136K init, 280K bss, 13752K reserved, 0K cma-reserved, 1048576K 
> > highmem)
> >
> > Signed-off-by: Mike Rapoport 
> 
> Sorry this fell through the cracks. Do you have a branch I can checkout 
> and do a quick test.

It's in mmotm and in my tree:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git 
memory-models/rm-discontig/v0

> Thx,
> -Vineet
> 
> > ---
> >   arch/arc/Kconfig|  3 ++-
> >   arch/arc/include/asm/page.h | 20 +---
> >   arch/arc/mm/init.c  | 29 ++---
> >   3 files changed, 41 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> > index 0a89cc9def65..c874f8ab0341 100644
> > --- a/arch/arc/Kconfig
> > +++ b/arch/arc/Kconfig
> > @@ -67,6 +67,7 @@ config GENERIC_CSUM
> >   
> >   config ARCH_DISCONTIGMEM_ENABLE
> > def_bool n
> > +   depends on BROKEN
> >   
> >   config ARCH_FLATMEM_ENABLE
> > def_bool y
> > @@ -506,7 +507,7 @@ config LINUX_RAM_BASE
> >   
> >   config HIGHMEM
> > bool "High Memory Support"
> > -   select ARCH_DISCONTIGMEM_ENABLE
> > +   select HAVE_ARCH_PFN_VALID
> > help
> >   With ARC 2G:2G address split, only upper 2G is directly addressable by
> >   kernel. Enable this to potentially allow access to rest of 2G and PAE
> > diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h
> > index b0dfed0f12be..23e41e890eda 100644
> > --- a/arch/arc/include/asm/page.h
> > +++ b/arch/arc/include/asm/page.h
> > @@ -82,11 +82,25 @@ typedef pte_t * pgtable_t;
> >*/
> >   #define virt_to_pfn(kaddr)(__pa(kaddr) >> PAGE_SHIFT)
> >   
> > -#define ARCH_PFN_OFFSETvirt_to_pfn(CONFIG_LINUX_RAM_BASE)
> > +/*
> > + * When HIGHMEM is enabled we have holes in the memory map so we need
> > + * pfn_valid() that takes into account the actual extents of the physical
> > + * memory
> > + */
> > +#ifdef CONFIG_HIGHMEM
> > +
> > +extern unsigned long arch_pfn_offset;
> > +#define ARCH_PFN_OFFSETarch_pfn_offset
> > +
> > +extern int pfn_valid(unsigned long pfn);
> > +#define pfn_valid  pfn_valid
> >   
> > -#ifdef CONFIG_FLATMEM
> > +#else /* CONFIG_HIGHMEM */
> > +
> > +#define ARCH_PFN_OFFSETvirt_to_pfn(CONFIG_LINUX_RAM_BASE)
> >   #define pfn_valid(pfn)(((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
> > -#endif
> > +
> > +#endif /* CONFIG_HIGHMEM */
> >   
> >   /*
> >* __pa, __va, virt_to_page (ALERT: deprecated, don't use them)
> > diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> > index 3a35b82a718e..ce07e697916c 100644
> > --- a/arch/arc/mm/init.c
> > +++ b/arch/arc/mm/init.c
> > @@ -28,6 +28,8 @@ static unsigned long low_mem_sz;
> >   static unsigned long min_high_pfn, max_high_pfn;
> >   static phys_addr_t high_mem_start;
> >   static phys_addr_t high_mem_sz;
> > +unsigned long arch_pfn_offset;
> > +EXPORT_SYMBOL(arch_pfn_offset);
> >   #endif
> >   
> >   #ifdef CONFIG_DISCONTIGMEM
> > @@ -98,16 +100,11 @@ void __init setup_arch_memory(void)
> > init_mm

Re: [PATCH 1/8] phy: phy-hi3670-usb3: move driver from staging into phy

[Mauro Carvalho Chehab]

Em Mon, 16 Nov 2020 09:31:06 -0600
Rob Herring  escreveu:

> On Mon, Nov 16, 2020 at 01:59:27PM +0100, Mauro Carvalho Chehab wrote:
> > The phy USB3 driver for Hisilicon 970 (hi3670) is ready
> > for mainstream. Mode it from staging into the main driver's  
> 
> s/Mode/Move/
> 
> > phy/ directory.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  .../bindings/phy/phy-hi3670-usb3.yaml |  72 ++
> >  MAINTAINERS   |   9 +-
> >  drivers/phy/hisilicon/Kconfig |  10 +
> >  drivers/phy/hisilicon/Makefile|   1 +
> >  drivers/phy/hisilicon/phy-hi3670-usb3.c   | 671 ++
> >  drivers/staging/hikey9xx/Kconfig  |  11 -
> >  drivers/staging/hikey9xx/Makefile |   2 -
> >  drivers/staging/hikey9xx/phy-hi3670-usb3.c| 671 --
> >  drivers/staging/hikey9xx/phy-hi3670-usb3.yaml |  72 --  
> 
> I assume this is only a move? Use '-M' option.

This is a move, although I explicitly disabled -M on this series, as both
the driver code and DT may still require some review, as those patches
are for subsystems that I haven't made any relevant contributions
so far.

Thanks,
Mauro

Re: [PATCH v2] PCI: dwc: fix error return code in dw_pcie_host_init()

[Jisheng Zhang]

On Tue, 17 Nov 2020 14:41:42 +0800 Wang Hai  wrote:


> 
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
> 
> Fixes: 07940c369a6b ("PCI: dwc: Fix MSI page leakage in suspend/resume")
> Reported-by: Hulk Robot 
> Signed-off-by: Wang Hai 

Reviewed-by Jisheng Zhang 

> ---
> v1->v2: just add 'ret = xxx'
>  drivers/pci/controller/dwc/pcie-designware-host.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c 
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 44c2a6572199..42d8116a4a00 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -392,7 +392,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   sizeof(pp->msi_msg),
>   DMA_FROM_DEVICE,
>   DMA_ATTR_SKIP_CPU_SYNC);
> -   if (dma_mapping_error(pci->dev, pp->msi_data)) {
> +   ret = dma_mapping_error(pci->dev, pp->msi_data);
> +   if (ret) {
> dev_err(pci->dev, "Failed to map MSI data\n");
> pp->msi_data = 0;
> goto err_free_msi;
> --
> 2.17.1
> 

Re: rmk/for-next bisection: baseline.login on bcm2836-rpi-2-b

[Ard Biesheuvel]

On Mon, 16 Nov 2020 at 23:13, Guillaume Tucker
 wrote:
>
> On 16/11/2020 12:20, Ard Biesheuvel wrote:
> > On Mon, 16 Nov 2020 at 12:20, Ard Biesheuvel  wrote:
> >>
> >> On Sun, 15 Nov 2020 at 15:11, Ard Biesheuvel  wrote:
> >>>
> >>> On Fri, 13 Nov 2020 at 17:25, Ard Biesheuvel  wrote:
> 
>  On Fri, 13 Nov 2020 at 17:15, Ard Biesheuvel  wrote:
> >
> > On Fri, 13 Nov 2020 at 16:58, Russell King - ARM Linux admin
> >  wrote:
> >>
> >> On Fri, Nov 13, 2020 at 03:43:27PM +, Guillaume Tucker wrote:
> >>> On 13/11/2020 10:35, Ard Biesheuvel wrote:
>  On Fri, 13 Nov 2020 at 11:31, Guillaume Tucker
>   wrote:
> >
> > Hi Ard,
> >
> > Please see the bisection report below about a boot failure on
> > RPi-2b.
> >
> > Reports aren't automatically sent to the public while we're
> > trialing new bisection features on kernelci.org but this one
> > looks valid.
> >
> > There's nothing in the serial console log, probably because it's
> > crashing too early during boot.  I'm not sure if other platforms
> > on kernelci.org were hit by this in the same way, but there
> > doesn't seem to be any.
> >
> > The same regression can be see on rmk's for-next branch as well
> > as in linux-next.  It happens with both bcm2835_defconfig and
> > multi_v7_defconfig.
> >
> > Some more details can be found here:
> >
> >   https://kernelci.org/test/case/id/5fae44823818ee918adb8864/
> >
> > If this looks like a real issue but you don't have a platform at
> > hand to reproduce it, please let us know if you would like the
> > KernelCI test to be re-run with earlyprintk or some debug config
> > turned on, or if you have a fix to try.
> >
> > Best wishes,
> > Guillaume
> >
> 
>  Hello Guillaume,
> 
>  That patch did have an issue, but it was already fixed by
> 
>  https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9020/1
>  https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=fc2933c133744305236793025b00c2f7d258b687
> 
>  Could you please double check whether cherry-picking that on top of
>  the first bad commit fixes the problem?
> >>>
> >>> Sadly this doesn't appear to be fixing the issue.  I've
> >>> cherry-picked your patch on top of the commit found by the
> >>> bisection but it still didn't boot, here's the git log
> >>>
> >>> cbb9656e83ca ARM: 9020/1: mm: use correct section size macro to 
> >>> describe the FDT virtual address
> >>> 7a1be318f579 ARM: 9012/1: move device tree mapping out of linear 
> >>> region
> >>> e9a2f8b599d0 ARM: 9011/1: centralize phys-to-virt conversion of 
> >>> DT/ATAGS address
> >>> 3650b228f83a Linux 5.10-rc1
> >>>
> >>> Test log: 
> >>> https://people.collabora.com/~gtucker/lava/boot/rpi-2-b/v5.10-rc1-3-gcbb9656e83ca/
> >>>
> >>> There's no output so it's hard to tell what is going on, but
> >>> reverting the bad commmit does make the board to boot (that's
> >>> what "revert: PASS" means in the bisect report).  So it's
> >>> unlikely that there is another issue causing the boot failure.
> >>
> >> These silent boot failures are precisely what the DEBUG_LL stuff (and
> >> early_printk) is supposed to help with - getting the kernel messages
> >> out when there is an oops before the serial console is initialised.
> >>
> >
> > If this is indeed related to the FDT mapping, I would assume
> > earlycon=... to be usable here.
> >
> > I will try to reproduce this on a RPi3 but I don't have a RPi2 at
> > hand, unfortunately.
> >
> > Would you mind having a quick try whether you can reproduce this on
> > QEMU, using the raspi2 machine model? If so, that would be a *lot*
> > easier to diagnose.
> 
>  Also, please have a go with 'earlycon=pl011,0x3f201000' added to the
>  kernel command line.
> >>>
> >>> I cannot reproduce this - I don't have the exact same hardware, but
> >>> for booting the kernel, I think RPi2 and RPi3 should be sufficiently
> >>> similar, and I can boot on Rpi3 using a u-boot built for rpi2 using
> >>> your provided dtb for RPi2.
>
> There's a RPi 3b in BayLibre's lab and it's booting fine, here in
> 32-bit mode from the exact same kernel build as the earlier link
> showing the problem on RPi 2b:
>
>   https://kernelci.org/test/plan/id/5fae3fa710b60de7d2db8859/
>
> >>> What puzzles me is that u-boot reports itself as
> >>>
> >>> U-Boot 2016.03-rc1-00131-g39af3d8-dirty
> >>>
> >>> RPI Model B+ (0x10)
> >>>
> >>> which is the ARMv6 model not the ARMv7, but then the kernel reports
> >>>
> >>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10

Re: [PATCH v2 1/1] kasan: fix object remain in offline per-cpu quarantine

[Kuan-Ying Lee]

On Mon, 2020-11-16 at 10:26 +0100, Dmitry Vyukov wrote:
> On Mon, Nov 16, 2020 at 7:30 AM Kuan-Ying Lee
>  wrote:
> >
> > We hit this issue in our internal test.
> > When enabling generic kasan, a kfree()'d object is put into per-cpu
> > quarantine first. If the cpu goes offline, object still remains in
> > the per-cpu quarantine. If we call kmem_cache_destroy() now, slub
> > will report "Objects remaining" error.
> >
> > [   74.982625] 
> > =
> > [   74.983380] BUG test_module_slab (Not tainted): Objects remaining in 
> > test_module_slab on __kmem_cache_shutdown()
> > [   74.984145] 
> > -
> > [   74.984145]
> > [   74.984883] Disabling lock debugging due to kernel taint
> > [   74.985561] INFO: Slab 0x(ptrval) objects=34 used=1 
> > fp=0x(ptrval) flags=0x20010200
> > [   74.986638] CPU: 3 PID: 176 Comm: cat Tainted: GB 
> > 5.10.0-rc1-7-g4525c8781ec0-dirty #10
> > [   74.987262] Hardware name: linux,dummy-virt (DT)
> > [   74.987606] Call trace:
> > [   74.987924]  dump_backtrace+0x0/0x2b0
> > [   74.988296]  show_stack+0x18/0x68
> > [   74.988698]  dump_stack+0xfc/0x168
> > [   74.989030]  slab_err+0xac/0xd4
> > [   74.989346]  __kmem_cache_shutdown+0x1e4/0x3c8
> > [   74.989779]  kmem_cache_destroy+0x68/0x130
> > [   74.990176]  test_version_show+0x84/0xf0
> > [   74.990679]  module_attr_show+0x40/0x60
> > [   74.991218]  sysfs_kf_seq_show+0x128/0x1c0
> > [   74.991656]  kernfs_seq_show+0xa0/0xb8
> > [   74.992059]  seq_read+0x1f0/0x7e8
> > [   74.992415]  kernfs_fop_read+0x70/0x338
> > [   74.993051]  vfs_read+0xe4/0x250
> > [   74.993498]  ksys_read+0xc8/0x180
> > [   74.993825]  __arm64_sys_read+0x44/0x58
> > [   74.994203]  el0_svc_common.constprop.0+0xac/0x228
> > [   74.994708]  do_el0_svc+0x38/0xa0
> > [   74.995088]  el0_sync_handler+0x170/0x178
> > [   74.995497]  el0_sync+0x174/0x180
> > [   74.996050] INFO: Object 0x(ptrval) @offset=15848
> > [   74.996752] INFO: Allocated in test_version_show+0x98/0xf0 age=8188 
> > cpu=6 pid=172
> > [   75.000802]  stack_trace_save+0x9c/0xd0
> > [   75.002420]  set_track+0x64/0xf0
> > [   75.002770]  alloc_debug_processing+0x104/0x1a0
> > [   75.003171]  ___slab_alloc+0x628/0x648
> > [   75.004213]  __slab_alloc.isra.0+0x2c/0x58
> > [   75.004757]  kmem_cache_alloc+0x560/0x588
> > [   75.005376]  test_version_show+0x98/0xf0
> > [   75.005756]  module_attr_show+0x40/0x60
> > [   75.007035]  sysfs_kf_seq_show+0x128/0x1c0
> > [   75.007433]  kernfs_seq_show+0xa0/0xb8
> > [   75.007800]  seq_read+0x1f0/0x7e8
> > [   75.008128]  kernfs_fop_read+0x70/0x338
> > [   75.008507]  vfs_read+0xe4/0x250
> > [   75.008990]  ksys_read+0xc8/0x180
> > [   75.009462]  __arm64_sys_read+0x44/0x58
> > [   75.010085]  el0_svc_common.constprop.0+0xac/0x228
> > [   75.011006] kmem_cache_destroy test_module_slab: Slab cache still has 
> > objects
> >
> > Register a cpu hotplug function to remove all objects in the offline
> > per-cpu quarantine when cpu is going offline. Set a per-cpu variable
> > to indicate this cpu is offline.
> >
> > Signed-off-by: Kuan-Ying Lee 
> > Suggested-by: Dmitry Vyukov 
> > Reported-by: Guangye Yang 
> > Cc: Andrey Ryabinin 
> > Cc: Alexander Potapenko 
> > Cc: Andrew Morton 
> > Cc: Matthias Brugger 
> > ---
> >  mm/kasan/quarantine.c | 35 +++
> >  1 file changed, 35 insertions(+)
> >
> > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> > index 4c5375810449..16e618ea805e 100644
> > --- a/mm/kasan/quarantine.c
> > +++ b/mm/kasan/quarantine.c
> > @@ -29,6 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "../slab.h"
> >  #include "kasan.h"
> > @@ -43,6 +44,7 @@ struct qlist_head {
> > struct qlist_node *head;
> > struct qlist_node *tail;
> > size_t bytes;
> > +   bool offline;
> >  };
> >
> >  #define QLIST_INIT { NULL, NULL, 0 }
> > @@ -188,6 +190,11 @@ void quarantine_put(struct kasan_free_meta *info, 
> > struct kmem_cache *cache)
> > local_irq_save(flags);
> >
> > q = this_cpu_ptr(&cpu_quarantine);
> > +   if (q->offline) {
> > +   qlink_free(&info->quarantine_link, cache);
> > +   local_irq_restore(flags);
> > +   return;
> > +   }

I think we need to make sure objects will not be put in per-cpu
quarantine which is offline.

> > qlist_put(q, &info->quarantine_link, cache->size);
> > if (unlikely(q->bytes > QUARANTINE_PERCPU_SIZE)) {
> > qlist_move_all(q, &temp);
> > @@ -328,3 +335,31 @@ void quarantine_remove_cache(struct kmem_cache *cache)
> >
> > synchronize_srcu(&remove_cache_srcu);
> >  }
> > +
> > +static int kasan_cpu_online(unsigned int cpu)
> > +{
> > +   this_cpu_ptr(&cpu_quarantine)->offline = false;
> > +   return 0;
> > +}

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

[Guennadi Liakhovetski]

Hi Mathieu,

On Mon, Nov 16, 2020 at 03:40:03PM -0700, Mathieu Poirier wrote:
> On Mon, Nov 16, 2020 at 04:51:52PM +0100, Arnaud POULIQUEN wrote:

[snip]

> > Having said that, does this guarantee the probe, a good question!
> > Maybe you or Mathieu have the answer, not me...
> 
> I did a lot of probing, went deep in the bowels of the user mode helper
> subsystem and looked at sys_load_module().  Especially at do_init_module() 
> where
> function do_one_initcall()[1] is called on mod->init, which happens to be
> rpmsg_ns_init() where the name space driver is registered.  I am confident we
> can rely on this mechanism.

Thanks for investigating and confirming that! So, we can be confident, that 
if the module is already loaded at the time when the NS device is registered, 
the probing happens synchronously. Now, as for how to actually load the 
module, I'd really propose to move rpmsg_ns_register_device() into the .c 
file and then the problem will be resolved automatically: as a symbol 
dependence the module will be loaded whenever another module, calling 
rpmsg_ns_register_device() is loaded.

Thanks
Guennadi

Re: [PATCH v2 10/13] arc: use FLATMEM with freeing of unused memory map instead of DISCONTIGMEM

[Vineet Gupta]

Hi Mike,

On 11/1/20 9:04 AM, Mike Rapoport wrote:
> From: Mike Rapoport 
>
> Currently ARC uses DISCONTIGMEM to cope with sparse physical memory address
> space on systems with 2 memory banks. While DISCONTIGMEM avoids wasting
> memory on unpopulated memory map, it adds both memory and CPU overhead
> relatively to FLATMEM. Moreover, DISCONTINGMEM is generally considered
> deprecated.
>
> The obvious replacement for DISCONTIGMEM would be SPARSEMEM, but it is also
> less efficient than FLATMEM in pfn_to_page() and page_to_pfn() conversions.
> Besides it requires tuning of SECTION_SIZE which is not trivial for
> possible ARC memory configuration.
>
> Since the memory map for both banks is always allocated from the "lowmem"
> bank, it is possible to use FLATMEM for two-bank configuration and simply
> free the unused hole in the memory map. All is required for that is to
> provide ARC-specific pfn_valid() that will take into account actual
> physical memory configuration and define HAVE_ARCH_PFN_VALID.
>
> The resulting kernel image configured with defconfig + HIGHMEM=y is
> smaller:
>
> $ size a/vmlinux b/vmlinux
> textdata bss dec hex filename
> 4673503 1245456  279756 6198715  5e95bb a/vmlinux
> 4658706 1246864  279756 6185326  5e616e b/vmlinux
>
> $ ./scripts/bloat-o-meter a/vmlinux b/vmlinux
> add/remove: 28/30 grow/shrink: 42/399 up/down: 10986/-29025 (-18039)
> ...
> Total: Before=4709315, After=4691276, chg -0.38%
>
> Booting nSIM with haps_ns.dts results in the following memory usage
> reports:
>
> a:
> Memory: 1559104K/1572864K available (3531K kernel code, 595K rwdata, 752K 
> rodata, 136K init, 275K bss, 13760K reserved, 0K cma-reserved, 1048576K 
> highmem)
>
> b:
> Memory: 1559112K/1572864K available (3519K kernel code, 594K rwdata, 752K 
> rodata, 136K init, 280K bss, 13752K reserved, 0K cma-reserved, 1048576K 
> highmem)
>
> Signed-off-by: Mike Rapoport 

Sorry this fell through the cracks. Do you have a branch I can checkout 
and do a quick test.

Thx,
-Vineet

> ---
>   arch/arc/Kconfig|  3 ++-
>   arch/arc/include/asm/page.h | 20 +---
>   arch/arc/mm/init.c  | 29 ++---
>   3 files changed, 41 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 0a89cc9def65..c874f8ab0341 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -67,6 +67,7 @@ config GENERIC_CSUM
>   
>   config ARCH_DISCONTIGMEM_ENABLE
>   def_bool n
> + depends on BROKEN
>   
>   config ARCH_FLATMEM_ENABLE
>   def_bool y
> @@ -506,7 +507,7 @@ config LINUX_RAM_BASE
>   
>   config HIGHMEM
>   bool "High Memory Support"
> - select ARCH_DISCONTIGMEM_ENABLE
> + select HAVE_ARCH_PFN_VALID
>   help
> With ARC 2G:2G address split, only upper 2G is directly addressable by
> kernel. Enable this to potentially allow access to rest of 2G and PAE
> diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h
> index b0dfed0f12be..23e41e890eda 100644
> --- a/arch/arc/include/asm/page.h
> +++ b/arch/arc/include/asm/page.h
> @@ -82,11 +82,25 @@ typedef pte_t * pgtable_t;
>*/
>   #define virt_to_pfn(kaddr)  (__pa(kaddr) >> PAGE_SHIFT)
>   
> -#define ARCH_PFN_OFFSET  virt_to_pfn(CONFIG_LINUX_RAM_BASE)
> +/*
> + * When HIGHMEM is enabled we have holes in the memory map so we need
> + * pfn_valid() that takes into account the actual extents of the physical
> + * memory
> + */
> +#ifdef CONFIG_HIGHMEM
> +
> +extern unsigned long arch_pfn_offset;
> +#define ARCH_PFN_OFFSET  arch_pfn_offset
> +
> +extern int pfn_valid(unsigned long pfn);
> +#define pfn_validpfn_valid
>   
> -#ifdef CONFIG_FLATMEM
> +#else /* CONFIG_HIGHMEM */
> +
> +#define ARCH_PFN_OFFSET  virt_to_pfn(CONFIG_LINUX_RAM_BASE)
>   #define pfn_valid(pfn)  (((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
> -#endif
> +
> +#endif /* CONFIG_HIGHMEM */
>   
>   /*
>* __pa, __va, virt_to_page (ALERT: deprecated, don't use them)
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 3a35b82a718e..ce07e697916c 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -28,6 +28,8 @@ static unsigned long low_mem_sz;
>   static unsigned long min_high_pfn, max_high_pfn;
>   static phys_addr_t high_mem_start;
>   static phys_addr_t high_mem_sz;
> +unsigned long arch_pfn_offset;
> +EXPORT_SYMBOL(arch_pfn_offset);
>   #endif
>   
>   #ifdef CONFIG_DISCONTIGMEM
> @@ -98,16 +100,11 @@ void __init setup_arch_memory(void)
>   init_mm.brk = (unsigned long)_end;
>   
>   /* first page of system - kernel .vector starts here */
> - min_low_pfn = ARCH_PFN_OFFSET;
> + min_low_pfn = virt_to_pfn(CONFIG_LINUX_RAM_BASE);
>   
>   /* Last usable page of low mem */
>   max_low_pfn = max_pfn = PFN_DOWN(low_mem_start + low_mem_sz);
>   
> -#ifdef CONFIG_FLATMEM
> - /* pfn_valid() uses this */
> - max_mapnr = max_low_pfn - min_low_pfn;

[PATCH v2] PCI: dwc: fix error return code in dw_pcie_host_init()

[Wang Hai]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: 07940c369a6b ("PCI: dwc: Fix MSI page leakage in suspend/resume")
Reported-by: Hulk Robot 
Signed-off-by: Wang Hai 
---
v1->v2: just add 'ret = xxx'
 drivers/pci/controller/dwc/pcie-designware-host.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c 
b/drivers/pci/controller/dwc/pcie-designware-host.c
index 44c2a6572199..42d8116a4a00 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -392,7 +392,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
  sizeof(pp->msi_msg),
  DMA_FROM_DEVICE,
  DMA_ATTR_SKIP_CPU_SYNC);
-   if (dma_mapping_error(pci->dev, pp->msi_data)) {
+   ret = dma_mapping_error(pci->dev, pp->msi_data);
+   if (ret) {
dev_err(pci->dev, "Failed to map MSI data\n");
pp->msi_data = 0;
goto err_free_msi;
-- 
2.17.1

Re: [PATCH net-next v5] net: linux/skbuff.h: combine SKB_EXTENSIONS + KCOV handling

[Florian Westphal]

Randy Dunlap  wrote:
> The previous Kconfig patch led to some other build errors as
> reported by the 0day bot and my own overnight build testing.
> 
> These are all in  when KCOV is enabled but
> SKB_EXTENSIONS is not enabled, so fix those by combining those conditions
> in the header file.

Thanks Randy.

Acked-by: Florian Westphal 

[PATCH] bus: mhi: core: manager all mhi ctrl data in one segment

[carl . yin]

From: Carl Yin 

I test SDX24 and SDX55 modems on Dell-OptiPlex-7060 has 16GB memory.
So I set dma_data_width in mhi/pci_generic.c to 37,
then get next error:

[  538.338317] mhi :03:00.0: Requested to power ON
[  538.338441] mhi :03:00.0: Power on setup success
[  538.338519] mhi :03:00.0: Handling state transition: PBL
[  543.383661] mhi :03:00.0: Device in READY State
[  543.383667] mhi :03:00.0: Initializing MHI registers
[  545.612647] mhi :03:00.0: local ee:AMSS device ee:PASS THRU 
dev_state:READY
[  545.646114] mhi :03:00.0: Unhandled event type: 0
[  545.646150] mhi :03:00.0: tre: 0, 0, 0
[  545.656697] mhi :03:00.0: Unhandled event type: 0
[  545.656733] mhi :03:00.0: tre: 0, 0, 0

I refer to the QUALLCOMM Windows MHI driver,
manager all mhi ctrl data in one segment, above error can be solved.

Signed-off-by: Carl Yin 
---
 drivers/bus/mhi/core/init.c | 251 +++-
 drivers/bus/mhi/core/internal.h |   6 +-
 2 files changed, 123 insertions(+), 134 deletions(-)

diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 655d539c6808..996b0f61920b 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -112,23 +112,6 @@ static struct attribute *mhi_dev_attrs[] = {
 };
 ATTRIBUTE_GROUPS(mhi_dev);
 
-/* MHI protocol requires the transfer ring to be aligned with ring length */
-static int mhi_alloc_aligned_ring(struct mhi_controller *mhi_cntrl,
- struct mhi_ring *ring,
- u64 len)
-{
-   ring->alloc_size = len + (len - 1);
-   ring->pre_aligned = mhi_alloc_coherent(mhi_cntrl, ring->alloc_size,
-  &ring->dma_handle, GFP_KERNEL);
-   if (!ring->pre_aligned)
-   return -ENOMEM;
-
-   ring->iommu_base = (ring->dma_handle + (len - 1)) & ~(len - 1);
-   ring->base = ring->pre_aligned + (ring->iommu_base - ring->dma_handle);
-
-   return 0;
-}
-
 void mhi_deinit_free_irq(struct mhi_controller *mhi_cntrl)
 {
int i;
@@ -205,40 +188,136 @@ void mhi_deinit_dev_ctxt(struct mhi_controller 
*mhi_cntrl)
mhi_cmd = mhi_cntrl->mhi_cmd;
for (i = 0; i < NR_OF_CMD_RINGS; i++, mhi_cmd++) {
ring = &mhi_cmd->ring;
-   mhi_free_coherent(mhi_cntrl, ring->alloc_size,
- ring->pre_aligned, ring->dma_handle);
ring->base = NULL;
ring->iommu_base = 0;
}
 
-   mhi_free_coherent(mhi_cntrl,
- sizeof(*mhi_ctxt->cmd_ctxt) * NR_OF_CMD_RINGS,
- mhi_ctxt->cmd_ctxt, mhi_ctxt->cmd_ctxt_addr);
-
mhi_event = mhi_cntrl->mhi_event;
for (i = 0; i < mhi_cntrl->total_ev_rings; i++, mhi_event++) {
if (mhi_event->offload_ev)
continue;
 
ring = &mhi_event->ring;
-   mhi_free_coherent(mhi_cntrl, ring->alloc_size,
- ring->pre_aligned, ring->dma_handle);
ring->base = NULL;
ring->iommu_base = 0;
}
 
-   mhi_free_coherent(mhi_cntrl, sizeof(*mhi_ctxt->er_ctxt) *
- mhi_cntrl->total_ev_rings, mhi_ctxt->er_ctxt,
- mhi_ctxt->er_ctxt_addr);
-
-   mhi_free_coherent(mhi_cntrl, sizeof(*mhi_ctxt->chan_ctxt) *
- mhi_cntrl->max_chan, mhi_ctxt->chan_ctxt,
- mhi_ctxt->chan_ctxt_addr);
+   mhi_free_coherent(mhi_cntrl,
+ mhi_ctxt->ctrl_seg_len,
+ mhi_ctxt->ctrl_seg,
+ mhi_ctxt->ctrl_seg_addr);
 
kfree(mhi_ctxt);
mhi_cntrl->mhi_ctxt = NULL;
 }
 
+static struct mhi_ctxt *mhi_alloc_dev_ctxt(struct mhi_controller *mhi_cntrl)
+{
+   struct mhi_ctxt *mhi_ctxt;
+   struct mhi_chan *mhi_chan;
+   struct mhi_event *mhi_event;
+   struct mhi_cmd *mhi_cmd;
+   struct mhi_ring *ring;
+   int i;
+
+   mhi_ctxt = kzalloc(sizeof(*mhi_ctxt), GFP_KERNEL);
+   if (!mhi_ctxt)
+   return NULL;
+
+   mhi_ctxt->chan_ctxt_addr = mhi_ctxt->ctrl_seg_len;
+   mhi_ctxt->ctrl_seg_len += (sizeof(*mhi_ctxt->chan_ctxt) * 
mhi_cntrl->max_chan);
+
+   mhi_ctxt->er_ctxt_addr = mhi_ctxt->ctrl_seg_len;
+   mhi_ctxt->ctrl_seg_len += (sizeof(*mhi_ctxt->er_ctxt) * 
mhi_cntrl->total_ev_rings);
+
+   mhi_ctxt->cmd_ctxt_addr = mhi_ctxt->ctrl_seg_len;
+   mhi_ctxt->ctrl_seg_len += (sizeof(*mhi_ctxt->cmd_ctxt) * 
NR_OF_CMD_RINGS);
+
+/* MHI protocol requires the transfer ring to be aligned with ring length */
+#define mhi_aligned_ring(mhi_ctxt, ring) \
+   do { \
+   ring->el_size = sizeof(struct mhi_tre); \
+   ring->len = ring->el_size * ring->elements; \
+   mhi_ctxt->ctrl_seg_len = ALIGN(mhi_ctxt->ctrl_seg_len, 
ring->len); \
+   

Re: [RFC, v1 0/3] msi support for platform devices

[Vikas Gupta]

Hi Eric,

On Mon, Nov 16, 2020 at 6:44 PM Auger Eric  wrote:
>
> Hi Vikas,
>
> On 11/13/20 6:24 PM, Vikas Gupta wrote:
> > Hi Eric,
> >
> > On Fri, Nov 13, 2020 at 12:10 AM Auger Eric  wrote:
> >>
> >> Hi Vikas,
> >>
> >> On 11/12/20 6:58 PM, Vikas Gupta wrote:
> >>> This RFC adds support for MSI for platform devices.
> >>> a) MSI(s) is/are added in addition to the normal interrupts.
> >>> b) The vendor specific MSI configuration can be done using
> >>>callbacks which is implemented as msi module.
> >>> c) Adds a msi handling module for the Broadcom platform devices.
> >>>
> >>> Changes from:
> >>> -
> >>>  v0 to v1:
> >>>i)  Removed MSI device flag VFIO_DEVICE_FLAGS_MSI.
> >>>ii) Add MSI(s) at the end of the irq list of platform IRQs.
> >>>MSI(s) with first entry of MSI block has count and flag
> >>>information.
> >>>IRQ list: Allocation for IRQs + MSIs are allocated as below
> >>>Example: if there are 'n' IRQs and 'k' MSIs
> >>>---
> >>>|IRQ-0|IRQ-1||IRQ-n|MSI-0|MSI-1|MSI-2|..|MSI-k|
> >>>---
> >> I have not taken time yet to look at your series, but to me you should have
> >> |IRQ-0|IRQ-1||IRQ-n|MSI|MSIX
> >> then for setting a given MSIX (i) you would select the MSIx index and
> >> then set start=i count=1.
> >
> > As per your suggestion, we should have, if there are n-IRQs, k-MSIXs
> > and m-MSIs, allocation of IRQs should be done as below
> >
> > |IRQ0|IRQ1|..|IRQ-(n-1)|MSI|MSIX|
> >  ||
> >  |
> > |MSIX0||MSIX1||MSXI2||MSIX-(k-1)|
> >  
> > |MSI0||MSI1||MSI2||MSI-(m-1)|
> No I really meant this list of indices: IRQ0|IRQ1|..|IRQ-(n-1)|MSI|MSIX|
> and potentially later on IRQ0|IRQ1|..|IRQ-(n-1)|MSI|MSIX| ERR| REQ
> if ERR/REQ were to be added.
I agree on this. Actually the map I drew incorrectly above but wanted
to demonstrate the same. It was a child-parent relationship for MSI
and its members and similarly for MSIX as well.
>
> I think the userspace could query the total number of indices using
> VFIO_DEVICE_GET_INFO and retrieve num_irqs (corresponding to the n wire
> interrupts + MSI index + MSIX index)
>
> Then userspace can loop on all the indices using
> VFIO_DEVICE_GET_IRQ_INFO. For each index it uses count to determine the
> first indices related to wire interrupts (count = 1). Then comes the MSI
> index, and after the MSI index. If any of those is supported, count >1,
> otherwise count=0. The only thing I am dubious about is can the device
> use a single MSI/MSIX? Because my hypothesis here is we use count to
> discriminate between wire first indices and other indices.
I believe count can be one as well, especially for ERR/REQ as you
mentioned above.I think we can not rely on the count > 1. Now, this is
blocking and we are not left with options unless we consider adding
more enums in flags in vfio_irq_info to tell userspace that particular
index is wired, MSI, MSIX etc. for the platform device.
What do you think?
>
>
>
> > With this implementation user space can know that, at indexes n and
> > n+1, edge triggered interrupts are present.
> note wired interrupts can also be edge ones.
> >We may add an element in vfio_platform_irq itself to allocate MSIs/MSIXs
> >struct vfio_platform_irq{
> >.
> >.
> >struct vfio_platform_irq *block; => this points to the block
> > allocation for MSIs/MSIXs and all msi/msix are type of IRQs.As wired 
> > interrupts and MSI interrupts coexist, I would store in vdev an
> array of wired interrupts (the existing vdev->irqs) and a new array for
> MSI(x) as done in the PCI code.
>
> vdev->ctx = kcalloc(nvec, sizeof(struct vfio_pci_irq_ctx), GFP_KERNEL);
>
> Does it make sense?
Yes, we can use similar kinds of allocations.

Thanks,
Vikas
>
> >};
> >  OR
> > Another structure can be defined in 'vfio_pci_private.h'
> > struct vfio_msi_ctx {
> > struct eventfd_ctx  *trigger;
> > char*name;
> > };
> > and
> > struct vfio_platform_irq {
> >   .
> >   .
> >   struct vfio_msi_ctx *block; => this points to the block allocation
> > for MSIs/MSIXs
> > };
> > Which of the above two options sounds OK to you? Please suggest.
> >
> >> to me individual MSIs are encoded in the subindex and not in the index.
> >> The index just selects the "type" of interrupt.
> >>
> >> For PCI you just have:
> >> VFIO_PCI_INTX_IRQ_INDEX,
> >> VFIO_PCI_MSI_IRQ_INDEX, -> MSI index and then you play with
> >> start/count
> >> VFIO_PCI_MSIX_IRQ_INDEX,
> >> VFIO_PCI_ERR_IRQ_INDEX,
> >> VFIO_PCI_REQ_IRQ_INDEX,
> >>
> >> (include/uapi/linux/vfio.h)
> >
> > In pci case, type of interrupts is fixed so they can be 'inde

Re: [PATCH v2] memfd_secret.2: New page describing memfd_secret() system call

[Mike Rapoport]

On Mon, Nov 16, 2020 at 10:01:37PM +0100, Alejandro Colomar wrote:
> From: Mike Rapoport 
> 
> Signed-off-by: Mike Rapoport 
> Cowritten-by: Alejandro Colomar 
> Acked-by: Alejandro Colomar 
> Signed-off-by: Alejandro Colomar 
> ---
> 
> Hi Mike,
> 
> I added that note about not having a wrapper,
> fixed a few minor formatting and wording issues,
> and sorted ERRORS alphabetically.

Thanks, Alejandro!

> Cheers,
> 
> Alex
> 
>  man2/memfd_secret.2 | 178 
>  1 file changed, 178 insertions(+)
>  create mode 100644 man2/memfd_secret.2
> 
> diff --git a/man2/memfd_secret.2 b/man2/memfd_secret.2
> new file mode 100644
> index 0..4e617aa0e
> --- /dev/null
> +++ b/man2/memfd_secret.2
> @@ -0,0 +1,178 @@
> +.\" Copyright (c) 2020, IBM Corporation.
> +.\" Written by Mike Rapoport 
> +.\"
> +.\" Based on memfd_create(2) man page
> +.\" Copyright (C) 2014 Michael Kerrisk 
> +.\" and Copyright (C) 2014 David Herrmann 
> +.\"
> +.\" %%%LICENSE_START(GPLv2+)
> +.\"
> +.\" This program is free software; you can redistribute it and/or modify
> +.\" it under the terms of the GNU General Public License as published by
> +.\" the Free Software Foundation; either version 2 of the License, or
> +.\" (at your option) any later version.
> +.\"
> +.\" This program is distributed in the hope that it will be useful,
> +.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
> +.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +.\" GNU General Public License for more details.
> +.\"
> +.\" You should have received a copy of the GNU General Public
> +.\" License along with this manual; if not, see
> +.\" .
> +.\" %%%LICENSE_END
> +.\"
> +.TH MEMFD_SECRET 2 2020-08-02 Linux "Linux Programmer's Manual"
> +.SH NAME
> +memfd_secret \- create an anonymous file to map secret memory regions
> +.SH SYNOPSIS
> +.nf
> +.B #include 
> +.PP
> +.BI "int memfd_secret(unsigned long " flags ");"
> +.fi
> +.PP
> +.IR Note :
> +There is no glibc wrapper for this system call; see NOTES.
> +.SH DESCRIPTION
> +.BR memfd_secret ()
> +creates an anonymous file and returns a file descriptor that refers to it.
> +The file can only be memory-mapped;
> +the memory in such mapping
> +will have stronger protection than usual memory mapped files,
> +and so it can be used to store application secrets.
> +Unlike a regular file, a file created with
> +.BR memfd_secret ()
> +lives in RAM and has a volatile backing storage.
> +Once all references to the file are dropped, it is automatically released.
> +The initial size of the file is set to 0.
> +Following the call, the file size should be set using
> +.BR ftruncate (2).
> +.PP
> +The memory areas obtained with
> +.BR mmap (2)
> +from the file descriptor are exclusive to the owning context.
> +These areas are removed from the kernel page tables
> +and only the page table of the process holding the file descriptor
> +maps the corresponding physical memory.
> +.PP
> +The following values may be bitwise ORed in
> +.IR flags
> +to control the behavior of
> +.BR memfd_secret (2):
> +.TP
> +.BR FD_CLOEXEC
> +Set the close-on-exec flag on the new file descriptor.
> +See the description of the
> +.B O_CLOEXEC
> +flag in
> +.BR open (2)
> +for reasons why this may be useful.
> +.PP
> +.TP
> +.BR SECRETMEM_UNCACHED
> +In addition to excluding memory areas from the kernel page tables,
> +mark the memory mappings uncached in the page table of the owning process.
> +Such mappings can be used to prevent speculative loads
> +and cache-based side channels.
> +This mode of
> +.BR memfd_secret ()
> +is not supported on all architectures.
> +.PP
> +See also NOTES below.
> +.PP
> +As its return value,
> +.BR memfd_secret ()
> +returns a new file descriptor that can be used to refer to an anonymous file.
> +This file descriptor is opened for both reading and writing
> +.RB ( O_RDWR )
> +and
> +.B O_LARGEFILE
> +is set for the file descriptor.
> +.PP
> +With respect to
> +.BR fork (2)
> +and
> +.BR execve (2),
> +the usual semantics apply for the file descriptor created by
> +.BR memfd_secret ().
> +A copy of the file descriptor is inherited by the child produced by
> +.BR fork (2)
> +and refers to the same file.
> +The file descriptor is preserved across
> +.BR execve (2),
> +unless the close-on-exec flag has been set.
> +.PP
> +The memory regions backed with
> +.BR memfd_secret ()
> +are locked in the same way as
> +.BR mlock (2),
> +however the implementation will not try to
> +populate the whole range during the
> +.BR mmap ()
> +call.
> +The amount of memory allowed for memory mappings
> +of the file descriptor obeys the same rules as
> +.BR mlock (2)
> +and cannot exceed
> +.BR RLIMIT_MEMLOCK .
> +.SH RETURN VALUE
> +On success,
> +.BR memfd_secret ()
> +returns a new file descriptor.
> +On error, \-1 is returned and
> +.I errno
> +is set to indicate the error.
> +.SH ERRORS
> +.TP
> +.B EINVAL
> +.I flags
> +included unknow

[RFC, net-next] net: qos: introduce a redundancy flow action

[Xiaoliang Yang]

This patch introduce a redundancy flow action to implement frame
replication and elimination for reliability, which is defined in
IEEE P802.1CB.

There are two modes for redundancy action: generator and recover mode.
Generator mode add redundancy tag and replicate the frame to different
egress ports. Recover mode drop the repeat frames and remove redundancy
tag from the frame.

Below is the setting example in user space:
> tc qdisc add dev swp0 clsact
> tc filter add dev swp0 ingress protocol 802.1Q flower \
skip_hw dst_mac 00:01:02:03:04:05 vlan_id 1 \
action redundancy generator split dev swp1 dev swp2

> tc filter add dev swp0 ingress protocol 802.1Q flower
skip_hw dst_mac 00:01:02:03:04:06 vlan_id 1 \
action redundancy recover

Signed-off-by: Xiaoliang Yang 
---
 include/net/flow_offload.h|   6 +
 include/net/tc_act/tc_redundancy.h|  69 +++
 include/uapi/linux/if_ether.h |   1 +
 include/uapi/linux/pkt_cls.h  |   1 +
 include/uapi/linux/tc_act/tc_redundancy.h |  36 ++
 net/sched/Kconfig |  14 +
 net/sched/Makefile|   1 +
 net/sched/act_redundancy.c| 495 ++
 net/sched/cls_api.c   |  31 ++
 9 files changed, 654 insertions(+)
 create mode 100644 include/net/tc_act/tc_redundancy.h
 create mode 100644 include/uapi/linux/tc_act/tc_redundancy.h
 create mode 100644 net/sched/act_redundancy.c

diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
index 123b1e9ea304..aed41f3801b7 100644
--- a/include/net/flow_offload.h
+++ b/include/net/flow_offload.h
@@ -147,6 +147,7 @@ enum flow_action_id {
FLOW_ACTION_MPLS_POP,
FLOW_ACTION_MPLS_MANGLE,
FLOW_ACTION_GATE,
+   FLOW_ACTION_REDUNDANCY,
NUM_FLOW_ACTIONS,
 };
 
@@ -271,6 +272,11 @@ struct flow_action_entry {
u32 num_entries;
struct action_gate_entry *entries;
} gate;
+   struct {
+   u8  mode;
+   u32 split_num;
+   struct net_device **split_devs;
+   } redundancy;
};
struct flow_action_cookie *cookie; /* user defined action cookie */
 };
diff --git a/include/net/tc_act/tc_redundancy.h 
b/include/net/tc_act/tc_redundancy.h
new file mode 100644
index ..77b043636f93
--- /dev/null
+++ b/include/net/tc_act/tc_redundancy.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/* Copyright 2020 NXP */
+
+#ifndef __NET_TC_REDUNDANCY_H
+#define __NET_TC_REDUNDANCY_H
+
+#include 
+#include 
+
+struct tcf_redundancy_split_dev {
+   struct list_head list;
+   struct net_device *dev;
+};
+
+struct tcf_redundancy {
+   struct tc_actioncommon;
+   u8  mode;
+   struct list_headsplit_list;
+   u32 gen_seq_num;
+   u32 sequence_history;
+   u32 recov_seq_num;
+};
+
+#define to_redundancy(a) ((struct tcf_redundancy *)a)
+
+static inline bool is_tcf_redundancy(const struct tc_action *a)
+{
+#ifdef CONFIG_NET_CLS_ACT
+   if (a->ops && a->ops->id == TCA_ID_REDUNDANCY)
+   return true;
+#endif
+   return false;
+}
+
+static inline u8 tcf_redundancy_mode(const struct tc_action *a)
+{
+   u8 mode;
+
+   mode = to_redundancy(a)->mode;
+
+   return mode;
+}
+
+static inline struct net_device **
+   tcf_redundancy_create_dev_array(const struct tc_action *a, int *len)
+{
+   struct tcf_redundancy_split_dev *entry;
+   struct tcf_redundancy *red_act;
+   struct net_device **devices;
+   int i = 0;
+
+   red_act = to_redundancy(a);
+
+   list_for_each_entry(entry, &red_act->split_list, list)
+   i++;
+
+   devices = kcalloc(i, sizeof(*devices), GFP_ATOMIC);
+   if (!devices)
+   return NULL;
+   *len = i;
+
+   i = 0;
+   list_for_each_entry(entry, &red_act->split_list, list)
+   devices[i++] = entry->dev;
+
+   return devices;
+}
+
+#endif
diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index a0b637911d3c..c465d68b1d93 100644
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -114,6 +114,7 @@
 #define ETH_P_EDSA 0xDADA  /* Ethertype DSA [ NOT AN OFFICIALLY 
REGISTERED ID ] */
 #define ETH_P_DSA_8021Q0xDADB  /* Fake VLAN Header for DSA [ 
NOT AN OFFICIALLY REGISTERED ID ] */
 #define ETH_P_IFE  0xED3E  /* ForCES inter-FE LFB type */
+#define ETH_P_RTAG 0xF1C1  /* Redundancy Tag(IEEE 802.1CB) */
 #define ETH_P_AF_IUCV   0xFBFB /* IBM af_iucv [ NOT AN OFFICIALLY 
REGISTERED ID ] */
 
 #define ETH_P_802_3_MIN0x0600  /* If t

Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM

[Mike Rapoport]

Hi Adrian,

On Tue, Nov 17, 2020 at 06:24:51AM +0100, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> On 11/1/20 6:04 PM, Mike Rapoport wrote:
> > It's been a while since DISCONTIGMEM is generally considered deprecated,
> > but it is still used by four architectures. This set replaces DISCONTIGMEM
> > with a different way to handle holes in the memory map and marks
> > DISCONTIGMEM configuration as BROKEN in Kconfigs of these architectures with
> > the intention to completely remove it in several releases.
> > 
> > While for 64-bit alpha and ia64 the switch to SPARSEMEM is quite obvious
> > and was a matter of moving some bits around, for smaller 32-bit arc and
> > m68k SPARSEMEM is not necessarily the best thing to do.
> > 
> > On 32-bit machines SPARSEMEM would require large sections to make section
> > index fit in the page flags, but larger sections mean that more memory is
> > wasted for unused memory map.
> > 
> > Besides, pfn_to_page() and page_to_pfn() become less efficient, at least on
> > arc.
> > 
> > So I've decided to generalize arm's approach for freeing of unused parts of
> > the memory map with FLATMEM and enable it for both arc and m68k. The
> > details are in the description of patches 10 (arc) and 13 (m68k).
> 
> Apologies for the late reply. Is this still relevant for testing?
> 
> I have already successfully tested v1 of the patch set, shall I test v2?

There were minor differences only for m68k between the versions. I've
verified them on ARAnyM but if you have a real machine a run there would
be nice.

> Adrian
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v3 0/5] console: Miscellaneous clean-ups, do not use FNTCHARCNT() in fbcon.c

[Peilin Ye]

On Mon, Nov 16, 2020 at 11:09:49AM +0100, Daniel Vetter wrote:
> On Sat, Nov 14, 2020 at 07:47:16AM -0500, Peilin Ye wrote:
> > On Sat, Nov 14, 2020 at 01:22:22PM +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Nov 14, 2020 at 01:18:06PM +0100, Greg Kroah-Hartman wrote:
> > > > On Sat, Nov 14, 2020 at 03:10:21AM -0500, Peilin Ye wrote:
> > > > > Thanks for reviewing!  Questions about the last patch [5/5] though, it
> > > > > depends on the following assumption:
> > > > > 
> > > > > """
> > > > > For each console `idx`, `vc_cons[idx].d->vc_font.data` and
> > > > > `fb_display[idx].fontdata` always point to the same buffer.
> > > > > """
> > > > > 
> > > > > Is this true?  I think it is true by grepping for `fontdata`.  I also
> > > > > noticed that fbcon.c is using `vc->vc_font.data` and `p->fontdata`
> > > > > interchangeably, see fbcon_get_requirement():
> > > > > 
> > > > >   vc = vc_cons[fg_console].d;
> > > > >   [...]
> > > > >   p = &fb_display[fg_console];
> > > > >   caps->x = 1 << (vc->vc_font.width - 1);
> > > > >   ^^^
> > > > >   caps->y = 1 << (vc->vc_font.height - 1);
> > > > >   ^^^
> > > > >   caps->len = (p->userfont) ?
> > > > >   FNTCHARCNT(p->fontdata) : 256;
> > > > >  ^^^
> > > > > 
> > > > > If it is true, then what is the point of using `fontdata` in `struct
> > > > > fbcon_display`?  Just for the `userfont` flag?  Should we delete
> > > > > `fontdata`, when we no longer need the `userfont` flag?
> > > > 
> > > > Yes, after a quick look, I think your analysis here is correct.  So if
> > > > you can delete that, it would be nice if possible.
> > 
> > I see, at the moment we still need `userfont` for refcount handling, I
> > will try to delete both `fontdata` and `userfont` after refcount is
> > taken care of.
> 
> +1 on sunsetting fondata. I think there's a bunch of these in fbcon code,
> because the console subsystem is older than the standard "allow drivers to
> embed the subsystem struct into their own private struct" subclassing
> model. So lots of global arrays indexed by the console id :-/

Yeah, I saw your comments about registered_fb[] :(

> We're also trying to start some kind of test suite for fbdev chardev ioctl
> interface in the gpu test suite. fbcon tests are maybe more related to
> tty/vt, and I have no idea whether anything exists there already.
> 
> But if you want to do some automated testcases for fbcon and there's
> absolutely no other home for them, the gpu test suite might be an option
> of last resort too:
> 
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation

Oh, I didn't know about igt-gpu-tools, thanks for the pointer!  Now,
since charcount is taken care of, and font_desc now contains all fields
of console_font, I think it is a good time to replace console_font with
font_desc in vc_data.  Then we can get rid of FNTSUM(), FNTSIZE(), then
(finally) REFCOUNT().

I will start working on vc_data, after done enough testing on [5/5],
ofc. Thanks,

Peilin Ye

Re: + mm-shmem-use-kmem_cache_zalloc-in-shmem_alloc_inode.patch added to -mm tree

[Hugh Dickins]

On Mon, 16 Nov 2020, a...@linux-foundation.org wrote:
> 
> The patch titled
>  Subject: mm/shmem: use kmem_cache_zalloc in shmem_alloc_inode()
> has been added to the -mm tree.  Its filename is
>  mm-shmem-use-kmem_cache_zalloc-in-shmem_alloc_inode.patch
> 
> This patch should soon appear at
> 
> https://ozlabs.org/~akpm/mmots/broken-out/mm-shmem-use-kmem_cache_zalloc-in-shmem_alloc_inode.patch
> and later at
> 
> https://ozlabs.org/~akpm/mmotm/broken-out/mm-shmem-use-kmem_cache_zalloc-in-shmem_alloc_inode.patch
> 
> Before you just go and hit "reply", please:
>a) Consider who else should be cc'ed
>b) Prefer to cc a suitable mailing list as well
>c) Ideally: find the original patch on the mailing list and do a
>   reply-to-all to that, adding suitable additional cc's
> 
> *** Remember to use Documentation/process/submit-checklist.rst when testing 
> your code ***
> 
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
> 
> --
> From: Hui Su 
> Subject: mm/shmem: use kmem_cache_zalloc in shmem_alloc_inode()

Andrew, Stephen, please revert this untested "cleanup" from your
trees a.s.a.p: it's a disaster for anyone using shmem/tmpfs.

> 
> in shmem_get_inode():
> new_inode();
>   new_inode_pseudo();
> alloc_inode();
>   ops->alloc_inode(); -> shmem_alloc_inode()
> kmem_cache_alloc();
> 
> memset(info, 0, (char *)inode - (char *)info);
> 
> So use kmem_cache_zalloc() in shmem_alloc_inode(),
> and remove the memset in shmem_get_inode().

I could not follow that argument at all.  The shmem_inode_cachep
uses a constructor, and the memset shown is of only a portion of
the whole inode.  zeroing the entire inode quickly crashes the
kernel, after showing errors.

(If you're lucky enough to have a readable display at that point:
I did not, but got on better with framebuffer than drm/i915; and
I wonder if there's a separate bug in that area too, because fixing
this shmem issue is not enough to get my drm/i915 rc4-mm1 booting.)

> 
> Link: https://lkml.kernel.org/r/20201115174026.GA365412@rlk
> Signed-off-by: Hui Su 

NAK.  Hui Su, please test your "cleanups" before sending them.

I'm sorry for being slow to respond, but the priority appeared
to be to get Matthew Wilcox's series running reliably, so I had not
got around to checking the less urgent shmem patches before they
slipped into mmotm - there may well be more that I want to NAK,
but this is the dangerous one.

Thanks,
Hugh

> Cc: Hugh Dickins 
> Signed-off-by: Andrew Morton 
> ---
> 
>  mm/shmem.c |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> --- a/mm/shmem.c~mm-shmem-use-kmem_cache_zalloc-in-shmem_alloc_inode
> +++ a/mm/shmem.c
> @@ -2331,7 +2331,6 @@ static struct inode *shmem_get_inode(str
>   inode->i_atime = inode->i_mtime = inode->i_ctime = 
> current_time(inode);
>   inode->i_generation = prandom_u32();
>   info = SHMEM_I(inode);
> - memset(info, 0, (char *)inode - (char *)info);
>   spin_lock_init(&info->lock);
>   atomic_set(&info->stop_eviction, 0);
>   info->seals = F_SEAL_SEAL;
> @@ -3851,7 +3850,7 @@ static struct kmem_cache *shmem_inode_ca
>  static struct inode *shmem_alloc_inode(struct super_block *sb)
>  {
>   struct shmem_inode_info *info;
> - info = kmem_cache_alloc(shmem_inode_cachep, GFP_KERNEL);
> + info = kmem_cache_zalloc(shmem_inode_cachep, GFP_KERNEL);
>   if (!info)
>   return NULL;
>   return &info->vfs_inode;
> _
> 
> Patches currently in -mm which might be from sh_...@163.com are
> 
> mmslab_common-use-list_for_each_entry-in-dump_unreclaimable_slab.patch
> mm-shmem-use-kmem_cache_zalloc-in-shmem_alloc_inode.patch
> mm-page_counter-use-page_counter_read-in-page_counter_set_max.patch
> mm-hugetlbc-just-use-put_page_testzero-instead-of-page_count.patch
> mm-compaction-move-compaction_suitables-comment-to-right-place.patch
> mm-oom_kill-change-comment-and-rename-is_dump_unreclaim_slabs.patch
> acctc-use-elif-instead-of-end-and-elif.patch
> mm-memcontrol-rewrite-mem_cgroup_page_lruvec.patch

Re: [PATCH bpf-next v3 2/2] bpf: Add tests for bpf_lsm_set_bprm_opts

[Martin KaFai Lau]

On Tue, Nov 17, 2020 at 02:13:07AM +, KP Singh wrote:
> From: KP Singh 
> 
> The test forks a child process, updates the local storage to set/unset
> the securexec bit.
> 
> The BPF program in the test attaches to bprm_creds_for_exec which checks
> the local storage of the current task to set the secureexec bit on the
> binary parameters (bprm).
> 
> The child then execs a bash command with the environment variable
> TMPDIR set in the envp.  The bash command returns a different exit code
> based on its observed value of the TMPDIR variable.
> 
> Since TMPDIR is one of the variables that is ignored by the dynamic
> loader when the secureexec bit is set, one should expect the
> child execution to not see this value when the secureexec bit is set.
> 
> Signed-off-by: KP Singh 
Acked-by: Martin KaFai Lau 

[PATCH v2] sched/deadline: Fix priority inheritance with multiple scheduling classes

[Juri Lelli]

Glenn reported that "an application [he developed produces] a BUG in
deadline.c when a SCHED_DEADLINE task contends with CFS tasks on nested
PTHREAD_PRIO_INHERIT mutexes.  I believe the bug is triggered when a CFS
task that was boosted by a SCHED_DEADLINE task boosts another CFS task
(nested priority inheritance).

 [ cut here ]
 kernel BUG at kernel/sched/deadline.c:1462!
 invalid opcode:  [#1] PREEMPT SMP
 CPU: 12 PID: 19171 Comm: dl_boost_bug Tainted: ...
 Hardware name: ...
 RIP: 0010:enqueue_task_dl+0x335/0x910
 Code: ...
 RSP: 0018:c9000c2bbc68 EFLAGS: 00010002
 RAX: 0009 RBX: 888c0af94c00 RCX: 81e12500
 RDX: 002e RSI: 888c0af94c00 RDI: 888c10b22600
 RBP: c9000c2bbd08 R08: 0009 R09: 0078
 R10: 81e12440 R11: 81e1236c R12: 888bc8932600
 R13: 888c0af94eb8 R14: 888c10b22600 R15: 888bc8932600
 FS:  7fa58ac55700() GS:888c10b0() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 7fa58b523230 CR3: 000bf44ab003 CR4: 007606e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: fffe0ff0 DR7: 0400
 PKRU: 5554
 Call Trace:
  ? intel_pstate_update_util_hwp+0x13/0x170
  rt_mutex_setprio+0x1cc/0x4b0
  task_blocks_on_rt_mutex+0x225/0x260
  rt_spin_lock_slowlock_locked+0xab/0x2d0
  rt_spin_lock_slowlock+0x50/0x80
  hrtimer_grab_expiry_lock+0x20/0x30
  hrtimer_cancel+0x13/0x30
  do_nanosleep+0xa0/0x150
  hrtimer_nanosleep+0xe1/0x230
  ? __hrtimer_init_sleeper+0x60/0x60
  __x64_sys_nanosleep+0x8d/0xa0
  do_syscall_64+0x4a/0x100
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
 RIP: 0033:0x7fa58b52330d
 ...
 ---[ end trace 0002 ]—

He also provided a simple reproducer creating the situation below:

 So the execution order of locking steps are the following
 (N1 and N2 are non-deadline tasks. D1 is a deadline task. M1 and M2
 are mutexes that are enabled * with priority inheritance.)

 Time moves forward as this timeline goes down:

 N1  N2   D1
 |   ||
 |   ||
 Lock(M1)||
 |   ||
 | Lock(M2)   |
 |   ||
 |   |  Lock(M2)
 |   ||
 | Lock(M1)   |
 | (!!bug triggered!) |

Daniel reported a similar situation as well, by just letting ksoftirqd
run with DEADLINE (and eventually block on a mutex).

Problem is that boosted entities (Priority Inheritance) use static
DEADLINE parameters of the top priority waiter. However, there might be
cases where top waiter could be a non-DEADLINE entity that is currently
boosted by a DEADLINE entity from a different lock chain (i.e., nested
priority chains involving entities of non-DEADLINE classes). In this
case, top waiter static DEADLINE parameters could be null (initialized
to 0 at fork()) and replenish_dl_entity() would hit a BUG().

Fix this by keeping track of the original donor and using its parameters
when a task is boosted.

Reported-by: Glenn Elliott 
Reported-by: Daniel Bristot de Oliveira 
Signed-off-by: Juri Lelli 

---

v1->v2: Replace dl_boosted with inline funcion (Valentin)
v1: 20201105075021.1302386-1-juri.le...@redhat.com
---
 include/linux/sched.h   | 10 -
 kernel/sched/core.c | 11 ++---
 kernel/sched/deadline.c | 97 ++---
 3 files changed, 68 insertions(+), 50 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 3af9d52fe093..b99507597b51 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -552,7 +552,6 @@ struct sched_dl_entity {
 * overruns.
 */
unsigned intdl_throttled  : 1;
-   unsigned intdl_boosted: 1;
unsigned intdl_yielded: 1;
unsigned intdl_non_contending : 1;
unsigned intdl_overrun: 1;
@@ -571,6 +570,15 @@ struct sched_dl_entity {
 * time.
 */
struct hrtimer inactive_timer;
+
+#ifdef CONFIG_RT_MUTEXES
+   /*
+* Priority Inheritance. When a DEADLINE scheduling entity is boosted
+* pi_se points to the donor, otherwise points to the dl_se it belongs
+* to (the original one/itself).
+*/
+   struct sched_dl_entity *pi_se;
+#endif
 };
 
 #ifdef CONFIG_UCLAMP_TASK
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a6aaf9fb3400..2335e29b6bd8 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5405,20 +5405,21 @@ void rt_mutex_setprio(struct task_struct *p, struct 
task_struct *pi_task)
if (!dl_prio(p->normal_prio) ||
(pi_task && dl_prio(pi_task->prio) &&
   

Re: [PATCH v4 00/16] Tegra XHCI controller ELPG support

[JC Kuo]

On 11/14/20 12:44 AM, Thierry Reding wrote:
> On Fri, Oct 16, 2020 at 09:07:10PM +0800, JC Kuo wrote:
>> Tegra XHCI controler can be placed in ELPG (Engine Level PowerGated)
>> state for power saving when all of the connected USB devices are in
>> suspended state. This patch series includes clk, phy and pmc changes
>> that are required for properly place controller in ELPG and bring
>> controller out of ELPG.
>>
>> JC Kuo (16):
>>   clk: tegra: Add PLLE HW power sequencer control
>>   clk: tegra: Don't enable PLLE HW sequencer at init
>>   phy: tegra: xusb: Move usb3 port init for Tegra210
>>   phy: tegra: xusb: tegra210: Do not reset UPHY PLL
>>   phy: tegra: xusb: Rearrange UPHY init on Tegra210
>>   phy: tegra: xusb: Add Tegra210 lane_iddq operation
>>   phy: tegra: xusb: Add sleepwalk and suspend/resume
>>   soc/tegra: pmc: Provide USB sleepwalk register map
>>   arm64: tegra210: XUSB PADCTL add "nvidia,pmc" prop
>>   dt-bindings: phy: tegra-xusb: Add nvidia,pmc prop
>>   phy: tegra: xusb: Add wake/sleepwalk for Tegra210
>>   phy: tegra: xusb: Tegra210 host mode VBUS control
>>   phy: tegra: xusb: Add wake/sleepwalk for Tegra186
>>   arm64: tegra210/tegra186/tegra194: XUSB PADCTL irq
>>   usb: host: xhci-tegra: Unlink power domain devices
>>   xhci: tegra: Enable ELPG for runtime/system PM
>>
>>  .../phy/nvidia,tegra124-xusb-padctl.txt   |1 +
>>  arch/arm64/boot/dts/nvidia/tegra186.dtsi  |1 +
>>  arch/arm64/boot/dts/nvidia/tegra194.dtsi  |1 +
>>  arch/arm64/boot/dts/nvidia/tegra210.dtsi  |2 +
>>  drivers/clk/tegra/clk-pll.c   |   12 -
>>  drivers/clk/tegra/clk-tegra210.c  |   53 +-
>>  drivers/phy/tegra/xusb-tegra186.c |  558 -
>>  drivers/phy/tegra/xusb-tegra210.c | 1889 +
>>  drivers/phy/tegra/xusb.c  |   92 +-
>>  drivers/phy/tegra/xusb.h  |   22 +-
>>  drivers/soc/tegra/pmc.c   |   94 +
>>  drivers/usb/host/xhci-tegra.c |  610 --
>>  include/linux/clk/tegra.h |4 +-
>>  include/linux/phy/tegra/xusb.h|   10 +-
>>  14 files changed, 2785 insertions(+), 564 deletions(-)
> 
> I've been testing this, but I keep seeing the following oops on suspend
> on a Jetson TX1:
> 
> [  153.451108] tegra-xusb-padctl phy-usb2.0: > 
> tegra_xusb_padctl_suspend_noirq(dev=80917000)
> [  153.460353] tegra-xusb-padctl phy-usb2.0:   driver: 8000114453e0 
> (tegra_xusb_padctl_driver)
> [  153.469245] tegra-xusb-padctl phy-usb2.0:   padctl: 829f6480
> [  153.475772] tegra-xusb-padctl phy-usb2.0: soc: ef7bdd7f 
> (0xef7bdd7f)
> [  153.484061] Unable to handle kernel paging request at virtual address 
> 007bdd80004f
> [  153.492132] Mem abort info:
> [  153.495083]   ESR = 0x9604
> [  153.498308]   EC = 0x25: DABT (current EL), IL = 32 bits
> [  153.503771]   SET = 0, FnV = 0
> [  153.506979]   EA = 0, S1PTW = 0
> [  153.510260] Data abort info:
> [  153.513200]   ISV = 0, ISS = 0x0004
> [  153.517181]   CM = 0, WnR = 0
> [  153.520302] [007bdd80004f] address between user and kernel address 
> ranges
> [  153.527600] Internal error: Oops: 9604 [#1] PREEMPT SMP
> [  153.533231] Modules linked in: nouveau panel_simple tegra_video(C) 
> tegra_drm drm_ttm_helper videobuf2_dma_contig ttm videobuf2_memops cec 
> videobuf2_v4l2 videobuf2_common drm_kms_helper v4l2_fwnode videodev drm mc 
> snd_hda_codec_hdmi cdc_ether usbnet snd_hda_tegra r8152 crct10dif_ce 
> snd_hda_codec snd_hda_core tegra_xudc host1x lp855x_bl at24 ip_tables 
> x_tables ipv6
> [  153.566417] CPU: 0 PID: 300 Comm: systemd-sleep Tainted: G C   
>  5.10.0-rc3-next-20201113-00019-g5c064d5372b0-dirty #624
> [  153.578283] Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
> [  153.584281] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> [  153.590381] pc : tegra_xusb_padctl_suspend_noirq+0x88/0x100
> [  153.596016] lr : tegra_xusb_padctl_suspend_noirq+0x80/0x100
> [  153.601632] sp : 8000120dbb60
> [  153.604999] x29: 8000120dbb60 x28: 80a1df00
> [  153.610430] x27: 0002 x26: 8000106f8540
> [  153.615858] x25: 8000113ac4a4 x24: 80001148c198
> [  153.621277] x23: 800010c4538c x22: 0002
> [  153.626692] x21: 800010ccde80 x20: 829f6480
> [  153.632107] x19: 80917000 x18: 0030
> [  153.637521] x17:  x16: 
> [  153.642933] x15: 80a1e380 x14: 74636461702d6273
> [  153.648346] x13: 8000113ad058 x12: 0f39
> [  153.653759] x11: 0513 x10: 800011405058
> [  153.659176] x9 : f000 x8 : 8000113ad058
> [  153.664590] x7 : 800011405058 x6 : 
> [  153.670002] x5 :  x4 : fe908bc0
> [  153.675414] x3 : fe910228 x2 : 162ef67e0581e700
> [  153.680826] x1 : 162ef67e05

[PATCH] usb/max3421: fix return error code in max3421_probe()

[Yang Yingliang]

retval may be reassigned to 0 after max3421_of_vbus_en_pin(),
if allocate memory failed after this, max3421_probe() cann't
return ENOMEM, fix this by moving assign retval afther max3421_probe().

Fixes: 721fdc83b31b ("usb: max3421: Add devicetree support")
Reported-by: Hulk Robot 
Signed-off-by: Yang Yingliang 
---
 drivers/usb/host/max3421-hcd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index 0894f6caccb2..ebb8180b52ab 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -1847,7 +1847,7 @@ max3421_probe(struct spi_device *spi)
struct max3421_hcd *max3421_hcd;
struct usb_hcd *hcd = NULL;
struct max3421_hcd_platform_data *pdata = NULL;
-   int retval = -ENOMEM;
+   int retval;
 
if (spi_setup(spi) < 0) {
dev_err(&spi->dev, "Unable to setup SPI bus");
@@ -1889,6 +1889,7 @@ max3421_probe(struct spi_device *spi)
goto error;
}
 
+   retval = -ENOMEM;
hcd = usb_create_hcd(&max3421_hcd_desc, &spi->dev,
 dev_name(&spi->dev));
if (!hcd) {
-- 
2.25.1

Re: [PATCH bpf-next v3 1/2] bpf: Add bpf_lsm_set_bprm_opts helper

[Martin KaFai Lau]

On Tue, Nov 17, 2020 at 02:13:06AM +, KP Singh wrote:
> From: KP Singh 
> 
> The helper allows modification of certain bits on the linux_binprm
> struct starting with the secureexec bit which can be updated using the
> BPF_LSM_F_BPRM_SECUREEXEC flag.
> 
> secureexec can be set by the LSM for privilege gaining executions to set
> the AT_SECURE auxv for glibc.  When set, the dynamic linker disables the
> use of certain environment variables (like LD_PRELOAD).
> 
> Signed-off-by: KP Singh 
Acked-by: Martin KaFai Lau 

[PATCH] video: fbdev: atmel_lcdfb: fixe return error code in atmel_lcdfb_of_init()

[Yang Yingliang]

If devm_kzalloc() failed after first time, atmel_lcdfb_of_init()
cann't return -ENOMEM, fix this by putting the error code in loop.

Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport")
Reported-by: Hulk Robot 
Signed-off-by: Yang Yingliang 
---
 drivers/video/fbdev/atmel_lcdfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 8c1d47e52b1a..355b6120dc4f 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -987,8 +987,8 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
}
 
INIT_LIST_HEAD(&pdata->pwr_gpios);
-   ret = -ENOMEM;
for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
+   ret = -ENOMEM;
gpiod = devm_gpiod_get_index(dev, "atmel,power-control",
 i, GPIOD_ASIS);
if (IS_ERR(gpiod))
-- 
2.25.1

[PATCH] drm/omap: dmm_tiler: fix return error code in omap_dmm_probe()

[Yang Yingliang]

Return -ENOMEM when allocating refill memory failed.

Fixes: 71e8831f6407 ("drm/omap: DMM/TILER support for OMAP4+ platform")
Reported-by: Hulk Robot 
Signed-off-by: Yang Yingliang 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 42ec51bb7b1b..7f4317248812 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -889,6 +889,7 @@ static int omap_dmm_probe(struct platform_device *dev)
   &omap_dmm->refill_pa, GFP_KERNEL);
if (!omap_dmm->refill_va) {
dev_err(&dev->dev, "could not allocate refill memory\n");
+   ret = -ENOMEM;
goto fail;
}
 
-- 
2.25.1

Re: [PATCH v2] scsi: ufshcd: fix missing destroy_workqueue()

[Martin K. Petersen]

On Tue, 10 Nov 2020 15:42:23 +0800, Qinglang Miao wrote:

> Add the missing destroy_workqueue() before return from
> ufshcd_init in the error handling case as well as in
> ufshcd_remove.

Applied to 5.10/scsi-fixes, thanks!

[1/1] scsi: ufshcd: Fix missing destroy_workqueue()
  https://git.kernel.org/mkp/scsi/c/2e6f11a797a2

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [RFC PATCH v2 3/4] RISC-V: Initial DTS for Microchip ICICLE board

[Atish Patra]

On Mon, Nov 16, 2020 at 6:15 PM Bin Meng  wrote:
>
> On Sat, Nov 14, 2020 at 4:29 AM Atish Patra  wrote:
> >
> > Add initial DTS for Microchip ICICLE board having only
> > essential devcies (clocks, sdhci, ethernet, serial, etc).
>
> typo: devices
>

Thanks. Will fix it.

> > The device tree is based on the U-Boot patch.
> >
> > https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/
> >
> > Signed-off-by: Atish Patra 
> > ---
> >  arch/riscv/boot/dts/Makefile  |   1 +
> >  arch/riscv/boot/dts/microchip/Makefile|   2 +
> >  .../microchip/microchip-mpfs-icicle-kit.dts   |  54 +++
> >  .../boot/dts/microchip/microchip-mpfs.dtsi| 342 ++
> >  4 files changed, 399 insertions(+)
> >  create mode 100644 arch/riscv/boot/dts/microchip/Makefile
> >  create mode 100644 
> > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> >  create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> >
> > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> > index ca1f8cbd78c0..3ea94ea0a18a 100644
> > --- a/arch/riscv/boot/dts/Makefile
> > +++ b/arch/riscv/boot/dts/Makefile
> > @@ -1,5 +1,6 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  subdir-y += sifive
> >  subdir-y += kendryte
> > +subdir-y += microchip
> >
> >  obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
> > diff --git a/arch/riscv/boot/dts/microchip/Makefile 
> > b/arch/riscv/boot/dts/microchip/Makefile
> > new file mode 100644
> > index ..622b12771fd3
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
> > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts 
> > b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > new file mode 100644
> > index ..9a382ab0a799
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
> > @@ -0,0 +1,54 @@
> > +// SPDX-License-Identifier: GPL-2.0+
>
> Please make this dual-licensed, GPL or MIT.
> See 
> https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp/blob/master/recipes-kernel/linux/files/icicle-kit-es/icicle-kit-es-a000-microchip.dts
>

I had that originally. Checkpatch did not like that. I will revert it
and investigate the real cause for the checkpatch complaint.

> > +/* Copyright (c) 2020 Microchip Technology Inc */
> > +
> > +/dts-v1/;
> > +
> > +#include "microchip-mpfs.dtsi"
> > +
> > +/* Clock frequency (in Hz) of the rtcclk */
> > +#define RTCCLK_FREQ100
> > +
> > +/ {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +   model = "Microchip PolarFire-SoC Icicle Kit";
> > +   compatible = "microchip,mpfs-icicle-kit", "microchip,polarfire-soc";
> > +
> > +   chosen {
> > +   stdout-path = &serial0;
> > +   };
> > +
> > +   cpus {
> > +   timebase-frequency = ;
> > +   };
> > +
> > +   memory@8000 {
> > +   device_type = "memory";
> > +   reg = <0x0 0x8000 0x0 0x4000>;
> > +   clocks = <&clkcfg 26>;
> > +   };
> > +
> > +   soc {
> > +   };
> > +};
> > +
> > +&serial0 {
> > +   status = "okay";
> > +};
> > +
> > +&serial1 {
> > +   status = "okay";
> > +};
> > +
> > +&serial2 {
> > +   status = "okay";
> > +};
> > +
> > +&serial3 {
> > +   status = "okay";
> > +};
> > +
> > +&sdcard {
> > +   status = "okay";
> > +};
> > +
> > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi 
> > b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > new file mode 100644
> > index ..63ac60f345d8
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
> > @@ -0,0 +1,342 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/* Copyright (c) 2020 Microchip Technology Inc */
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +   model = "Microchip PolarFire-SoC";
> > +   compatible = "microchip,polarfire-soc";
> > +
> > +   chosen {
> > +   };
> > +
> > +   cpus {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   cpu@0 {
> > +   clock-frequency = <0>;
> > +   compatible = "sifive,rocket0", "riscv";
> > +   device_type = "cpu";
> > +   i-cache-block-size = <64>;
> > +   i-cache-sets = <128>;
> > +   i-cache-size = <16384>;
> > +   reg = <0>;
> > +   riscv,isa = "rv64imac";
> > +   status = "disabled";
> > +
> > +   cpu0_intc: interrupt-controller {
> > +   #interrupt-cells = <1>;
> > +  

Re: [PATCH 1/9] platform/surface: Add Surface Aggregator subsystem

[Maximilian Luz]

On 11/16/20 6:03 PM, Maximilian Luz wrote:

On 11/16/20 2:33 PM, Andy Shevchenko wrote:

On Sun, Nov 15, 2020 at 9:25 PM Maximilian Luz  wrote:


[...]


READ_ONCE and WRITE_ONCE are used to ensure proper access to state that
can be changed outside of the queue/pending locks (or under any one of
them). In general, I have tried to document all critical access of such
state with an explanation of why it is safe to do so.


I've looked at this again and noticed that I can guard the packet
timestamp by the pending lock and the packet priority by the queue lock
(after first submission). This makes reasoning about access to them
significantly easier and removes the need for WRITE_ONCE / READ_ONCE.

After that, READ_ONCE is used

- to access the controller state for smoke-testing to (hopefully) detect
  invalid request function usage (note that all other access to this
  state happens under the controller state lock)

- for the "safe counters", where access to the shared value is, after
  initialization, restricted to the increment function

- to update the timeout reaper, where access to the shared value
  (rtx_timeout.expires) is, after initialization, restricted to its
  modification function (ssh_ptl_timeout_reaper_mod() /
  ssh_rtl_timeout_reaper_mod()) and the timer function

- to access the request timestamp, which is, after initialization, only
  set once in the lifetime of a request (all other access is read-only)

- to access the 'ptl' reference of the packet, which, after
  initialization, is only set once, either at packet or request
  submission (all other access is read-only). Note due to this,
  READ_ONCE is only required for functions that can run concurrently
  with ssh_ptl_submit() and ssh_rtl_submit(), i.e. ssh_ptl_cancel() and
  ssh_rtl_cancel().

- to access request state outside of bit-ops when canceling

I'd argue that all of these cases can be checked and verified with a
reasonable amount of effort. Cancellation (last two points) is probably
the most complex one. Unfortunately, I don't see any way to simplify
that part without disallowing cancellation to run concurrently to
submission, which is something I'd like to support as this makes
implementing asynchronous requests in the future easier.

Regards,
Max

Re: [PATCH] Fix warning for static const char * array in audio_manager_module.c

[Greg KH]

On Mon, Nov 16, 2020 at 09:43:23PM +0100, Emmanouil Perselis wrote:
> On 11/15/20 9:17 AM, Greg Kroah-Hartman wrote:
> > On Sun, Nov 15, 2020 at 03:53:16PM +0100, Emmanouil Perselis wrote:
> >> This patch fixes the warning "static const char * array should
> >> probably be static const char * const" in
> >> drivers/staging/greybus/audio_manager_module.c
> 
> >> I think Greg's patch bot is telling you that you need
> >> to carbon-copy the mailing list on your patch submission,
> >> not just address it to the maintainers.
> 
> Added addresses to carbon copy.

Do you think this is the correct way to submit a patch that doesn't have
to be hand-edited in order to apply it?

Please make it match other submitted patches, but most importantly,
actually test-build your changes to ensure that they are correct.

thanks,

greg k-h

[PATCH] phy: amlogic: Replace devm_reset_control_array_get()

[Yejune Deng]

devm_reset_control_array_get_exclusive() looks more readable

Signed-off-by: Yejune Deng 
---
 drivers/phy/amlogic/phy-meson-axg-pcie.c   | 2 +-
 drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c | 2 +-
 drivers/soc/amlogic/meson-ee-pwrc.c| 3 +--
 drivers/soc/amlogic/meson-gx-pwrc-vpu.c| 2 +-
 4 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/amlogic/phy-meson-axg-pcie.c 
b/drivers/phy/amlogic/phy-meson-axg-pcie.c
index 377ed0d..3204f02 100644
--- a/drivers/phy/amlogic/phy-meson-axg-pcie.c
+++ b/drivers/phy/amlogic/phy-meson-axg-pcie.c
@@ -155,7 +155,7 @@ static int phy_axg_pcie_probe(struct platform_device *pdev)
if (IS_ERR(priv->regmap))
return PTR_ERR(priv->regmap);
 
-   priv->reset = devm_reset_control_array_get(dev, false, false);
+   priv->reset = devm_reset_control_array_get_exclusive(dev);
if (IS_ERR(priv->reset))
return PTR_ERR(priv->reset);
 
diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c 
b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
index 08e3227..bab6345 100644
--- a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
+++ b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
@@ -418,7 +418,7 @@ static int phy_g12a_usb3_pcie_probe(struct platform_device 
*pdev)
if (ret)
goto err_disable_clk_ref;
 
-   priv->reset = devm_reset_control_array_get(dev, false, false);
+   priv->reset = devm_reset_control_array_get_exclusive(dev);
if (IS_ERR(priv->reset))
return PTR_ERR(priv->reset);
 
diff --git a/drivers/soc/amlogic/meson-ee-pwrc.c 
b/drivers/soc/amlogic/meson-ee-pwrc.c
index ed7d2fb..3a879a4 100644
--- a/drivers/soc/amlogic/meson-ee-pwrc.c
+++ b/drivers/soc/amlogic/meson-ee-pwrc.c
@@ -413,8 +413,7 @@ static int meson_ee_pwrc_init_domain(struct platform_device 
*pdev,
dev_warn(&pdev->dev, "Invalid resets count %d for 
domain %s\n",
 count, dom->desc.name);
 
-   dom->rstc = devm_reset_control_array_get(&pdev->dev, false,
-false);
+   dom->rstc = devm_reset_control_array_get_exclusive(&pdev->dev);
if (IS_ERR(dom->rstc))
return PTR_ERR(dom->rstc);
}
diff --git a/drivers/soc/amlogic/meson-gx-pwrc-vpu.c 
b/drivers/soc/amlogic/meson-gx-pwrc-vpu.c
index 8790627..b4615b2 100644
--- a/drivers/soc/amlogic/meson-gx-pwrc-vpu.c
+++ b/drivers/soc/amlogic/meson-gx-pwrc-vpu.c
@@ -304,7 +304,7 @@ static int meson_gx_pwrc_vpu_probe(struct platform_device 
*pdev)
return PTR_ERR(regmap_hhi);
}
 
-   rstc = devm_reset_control_array_get(&pdev->dev, false, false);
+   rstc = devm_reset_control_array_get_exclusive(&pdev->dev);
if (IS_ERR(rstc)) {
if (PTR_ERR(rstc) != -EPROBE_DEFER)
dev_err(&pdev->dev, "failed to get reset lines\n");
-- 
1.9.1

Re: [PATCH] scsi: qla4xxx: Remove redundant assignment to variable rval

[Martin K. Petersen]

Jing,

> The variable rval has been initialized with 'QLA_ERROR'. The
> assignment is redundant in an error path. So remove it.

Applied to 5.11/scsi-staging, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v1 0/9] scsi: ufs: Refactoring and cleanups

[Martin K. Petersen]

Stanley,

> This series simply do some refactoring and cleanups in UFS drivers.

Applied to 5.11/scsi-staging, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2] docs: automarkup.py: Allow automatic cross-reference inside C namespace

[Mauro Carvalho Chehab]

Em Tue, 17 Nov 2020 02:12:01 +
Nícolas F. R. A. Prado  escreveu:

> Sphinx 3.1 introduced namespaces for C cross-references. With this,
> each C domain type/function declaration is put inside the namespace that
> was active at the time of its declaration.
> 
> Add support for automatic cross-referencing inside C namespaces by
> checking whether the corresponding source file had a C namespace Sphinx
> directive, and if so, try cross-referencing inside of it before going to
> the global scope.
> 
> This assumes there's only one namespace (if any) per rst file.
> 
> Signed-off-by: Nícolas F. R. A. Prado 
> ---
> 
> To those following from v1:
> 
> I ended up doing the simplest solution possible, which is to just directly 
> read
> the rst source corresponding to the doc page right before doing the 
> automarkup.
> It's not very efficient in the sense that the source is being read
> twice (first by Sphinx, then by this), but it sidesteps the "data sharing
> between processes" issue, so parallel_read_safe can be reenabled, and I didn't
> notice any performance hit from this patch (as opposed to the big hit from 
> v1).
> Works with both Sphinx 2 and 3.
> 
> Changes in v2:
> - Get C namespace from reading the corresponding source at the time of doing
>   automarkup instead of storing all namespaces beforehand at the source-read
>   phase
> - Add get_c_namespace()
> - Remove save_c_namespace()
> - Reenabled Sphinx's parallel_read_safe
> 
> v1: 
> https://lore.kernel.org/linux-doc/20201013231218.2750109-6-nfrapr...@protonmail.com/
> 
>  Documentation/sphinx/automarkup.py | 122 ++---
>  1 file changed, 75 insertions(+), 47 deletions(-)
> 
> diff --git a/Documentation/sphinx/automarkup.py 
> b/Documentation/sphinx/automarkup.py
> index 3e81ebab26ed..953b24b6e2b4 100644
> --- a/Documentation/sphinx/automarkup.py
> +++ b/Documentation/sphinx/automarkup.py
> @@ -53,6 +53,8 @@ RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', 
> flags=ascii_p3)
>  #
>  RE_doc = re.compile(r'\bDocumentation(/[\w\-_/]+)(\.\w+)*')
>  
> +RE_namespace = re.compile(r'^\s*..\s*c:namespace::\s*(\S+)\s*$')
> +
>  #
>  # Reserved C words that we should skip when cross-referencing
>  #
> @@ -70,6 +72,8 @@ Skipfuncs = [ 'open', 'close', 'read', 'write', 'fcntl', 
> 'mmap',
>'select', 'poll', 'fork', 'execve', 'clone', 'ioctl',
>'socket' ]
>  
> +c_namespace = ''
> +
>  def markup_refs(docname, app, node):
>  t = node.astext()
>  done = 0
> @@ -128,30 +132,38 @@ def markup_func_ref_sphinx3(docname, app, match):
>  #
>  # Go through the dance of getting an xref out of the C domain
>  #
> -target = match.group(2)
> +base_target = match.group(2)
>  target_text = nodes.Text(match.group(0))
>  xref = None
> -if not (target in Skipfuncs or target in Skipnames):
> -for class_s, reftype_s in zip(class_str, reftype_str):
> -lit_text = nodes.literal(classes=['xref', 'c', class_s])
> -lit_text += target_text
> -pxref = addnodes.pending_xref('', refdomain = 'c',
> -  reftype = reftype_s,
> -  reftarget = target, modname = None,
> -  classname = None)
> -#
> -# XXX The Latex builder will throw NoUri exceptions here,
> -# work around that by ignoring them.
> -#
> -try:
> -xref = cdom.resolve_xref(app.env, docname, app.builder,
> - reftype_s, target, pxref,
> - lit_text)
> -except NoUri:
> -xref = None
> +possible_targets = [base_target]
> +# Check if this document has a namespace, and if so, try
> +# cross-referencing inside it first.
> +if c_namespace:
> +possible_targets.insert(0, c_namespace + "." + base_target)
>  
> -if xref:
> -return xref
> +if base_target not in Skipnames:
> +for target in possible_targets:
> +if target not in Skipfuncs:

Hmm... do we still need to skip syscalls?

> +for class_s, reftype_s in zip(class_str, reftype_str):
> +lit_text = nodes.literal(classes=['xref', 'c', class_s])
> +lit_text += target_text
> +pxref = addnodes.pending_xref('', refdomain = 'c',
> +  reftype = reftype_s,
> +  reftarget = target, 
> modname = None,
> +  classname = None)
> +#
> +# XXX The Latex builder will throw NoUri exceptions here,
> +# work around that by ignoring them.
> +#
> +try:
> +x

[PATCH v3 1/2] PCI: move pci_match_device() ahead of new_id_store()

[Zhenzhong Duan]

Move pci_match_device() and it's dependencies (pci_match_id() and
pci_device_id_any) ahead of new_id_store().

This is preparation work for calling pci_match_device() in new_id_store().
No functional changes.

Signed-off-by: Zhenzhong Duan 
---
 drivers/pci/pci-driver.c | 144 +++
 1 file changed, 72 insertions(+), 72 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 8b587fc..e928cfa 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -90,6 +90,78 @@ static void pci_free_dynids(struct pci_driver *drv)
 }
 
 /**
+ * pci_match_id - See if a pci device matches a given pci_id table
+ * @ids: array of PCI device id structures to search in
+ * @dev: the PCI device structure to match against.
+ *
+ * Used by a driver to check whether a PCI device present in the
+ * system is in its list of supported devices.  Returns the matching
+ * pci_device_id structure or %NULL if there is no match.
+ *
+ * Deprecated, don't use this as it will not catch any dynamic ids
+ * that a driver might want to check for.
+ */
+const struct pci_device_id *pci_match_id(const struct pci_device_id *ids,
+struct pci_dev *dev)
+{
+   if (ids) {
+   while (ids->vendor || ids->subvendor || ids->class_mask) {
+   if (pci_match_one_device(ids, dev))
+   return ids;
+   ids++;
+   }
+   }
+   return NULL;
+}
+EXPORT_SYMBOL(pci_match_id);
+
+static const struct pci_device_id pci_device_id_any = {
+   .vendor = PCI_ANY_ID,
+   .device = PCI_ANY_ID,
+   .subvendor = PCI_ANY_ID,
+   .subdevice = PCI_ANY_ID,
+};
+
+/**
+ * pci_match_device - Tell if a PCI device structure has a matching PCI device 
id structure
+ * @drv: the PCI driver to match against
+ * @dev: the PCI device structure to match against
+ *
+ * Used by a driver to check whether a PCI device present in the
+ * system is in its list of supported devices.  Returns the matching
+ * pci_device_id structure or %NULL if there is no match.
+ */
+static const struct pci_device_id *pci_match_device(struct pci_driver *drv,
+   struct pci_dev *dev)
+{
+   struct pci_dynid *dynid;
+   const struct pci_device_id *found_id = NULL;
+
+   /* When driver_override is set, only bind to the matching driver */
+   if (dev->driver_override && strcmp(dev->driver_override, drv->name))
+   return NULL;
+
+   /* Look at the dynamic ids first, before the static ones */
+   spin_lock(&drv->dynids.lock);
+   list_for_each_entry(dynid, &drv->dynids.list, node) {
+   if (pci_match_one_device(&dynid->id, dev)) {
+   found_id = &dynid->id;
+   break;
+   }
+   }
+   spin_unlock(&drv->dynids.lock);
+
+   if (!found_id)
+   found_id = pci_match_id(drv->id_table, dev);
+
+   /* driver_override will always match, send a dummy id */
+   if (!found_id && dev->driver_override)
+   found_id = &pci_device_id_any;
+
+   return found_id;
+}
+
+/**
  * store_new_id - sysfs frontend to pci_add_dynid()
  * @driver: target device driver
  * @buf: buffer for scanning device ID data
@@ -208,78 +280,6 @@ static ssize_t remove_id_store(struct device_driver 
*driver, const char *buf,
 };
 ATTRIBUTE_GROUPS(pci_drv);
 
-/**
- * pci_match_id - See if a pci device matches a given pci_id table
- * @ids: array of PCI device id structures to search in
- * @dev: the PCI device structure to match against.
- *
- * Used by a driver to check whether a PCI device present in the
- * system is in its list of supported devices.  Returns the matching
- * pci_device_id structure or %NULL if there is no match.
- *
- * Deprecated, don't use this as it will not catch any dynamic ids
- * that a driver might want to check for.
- */
-const struct pci_device_id *pci_match_id(const struct pci_device_id *ids,
-struct pci_dev *dev)
-{
-   if (ids) {
-   while (ids->vendor || ids->subvendor || ids->class_mask) {
-   if (pci_match_one_device(ids, dev))
-   return ids;
-   ids++;
-   }
-   }
-   return NULL;
-}
-EXPORT_SYMBOL(pci_match_id);
-
-static const struct pci_device_id pci_device_id_any = {
-   .vendor = PCI_ANY_ID,
-   .device = PCI_ANY_ID,
-   .subvendor = PCI_ANY_ID,
-   .subdevice = PCI_ANY_ID,
-};
-
-/**
- * pci_match_device - Tell if a PCI device structure has a matching PCI device 
id structure
- * @drv: the PCI driver to match against
- * @dev: the PCI device structure to match against
- *
- * Used by a driver to check whether a PCI device present in the
- * system is in its list of supported devices.  Returns the matching
- * pci_device_id str

[PATCH v3 2/2] PCI: avoid duplicate IDs in dynamic IDs list

[Zhenzhong Duan]

When a device ID data is writen to /sys/bus/pci/drivers/.../new_id,
only static ID table is checked for duplicate and multiple dynamic ID
entries of same kind are allowed to exist in a dynamic IDs list.

This doesn't cause user-visible broken behavior, but not user friendly.
remove_id_store() only remove one of the duplicate IDs, so if we add an
ID several times, we would have to remove it the same number of times
before it's completely gone.

Fix it by calling pci_match_device() which checks both dynamic and static
IDs to avoid inserting duplicate IDs in dynamic IDs list.

After fix, it shows below result which is expected:

echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/new_id
echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/new_id
-bash: echo: write error: File exists

Signed-off-by: Zhenzhong Duan 
---
 drivers/pci/pci-driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index e928cfa..c4678d8 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -197,7 +197,7 @@ static ssize_t new_id_store(struct device_driver *driver, 
const char *buf,
pdev->subsystem_device = subdevice;
pdev->class = class;
 
-   if (pci_match_id(pdrv->id_table, pdev))
+   if (pci_match_device(pdrv, pdev))
retval = -EEXIST;
 
kfree(pdev);
-- 
1.8.3.1

[PATCH v3 0/2] avoid inserting duplicate IDs in dynids list

[Zhenzhong Duan]

vfio-pci and pci-stub use new_id to bind devices. But one can add same IDs
multiple times, for example:

# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/new_id
# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/new_id
# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/new_id
# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/remove_id
# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/remove_id
# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/remove_id
# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/remove_id
-bash: echo: write error: No such device

This doesn't cause user-visible broken behavior, but not user friendly.
he has to remove same IDs same times to ensure it's completely gone.

Changed to only allow one dynamic entry of the same kind, after fix:

# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/new_id
# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/new_id
-bash: echo: write error: File exists
# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/remove_id
# echo "1af4 1041" > /sys/bus/pci/drivers/vfio-pci/remove_id
-bash: echo: write error: No such device


v3: add a separate patch to process dependency issue per Bjorn
make commit log more clear per Bjorn
v2: revert the export of pci_match_device() per Christoph
combind PATCH1 and PATCH2 into one.

v2 link:https://lkml.org/lkml/2020/10/25/347

Zhenzhong Duan (2):
  PCI: move pci_match_device() ahead of new_id_store()
  PCI: avoid duplicate IDs in dynamic IDs list

 drivers/pci/pci-driver.c | 146 +++
 1 file changed, 73 insertions(+), 73 deletions(-)

-- 
1.8.3.1


Zhenzhong Duan (2):
  PCI: move pci_match_device() ahead of new_id_store()
  PCI: avoid duplicate IDs in dynamic IDs list

 drivers/pci/pci-driver.c | 146 +++
 1 file changed, 73 insertions(+), 73 deletions(-)

-- 
1.8.3.1

Re: [PATCH 2/7] dt: bindings: add mt7621-pll device tree binding documentation

[Sergio Paracuellos]

Hi Rob,

On Mon, Nov 16, 2020 at 8:16 PM Rob Herring  wrote:
>
> On Wed, 11 Nov 2020 17:30:08 +0100, Sergio Paracuellos wrote:
> > Adds device tree binding documentation for PLL controller in
> > the MT7621 SOC.
> >
> > Signed-off-by: Sergio Paracuellos 
> > ---
> >  .../bindings/clock/mediatek,mt7621-pll.yaml   | 51 +++
> >  1 file changed, 51 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.yaml
> >
>
> Reviewed-by: Rob Herring 

Thanks for the review. In that series there were two clock bindings
relating the pll and gates, There were finally joined in only one
binding and driver. This is done in the v3 of this series sent on
friday. Thanks for your time in looking also into this new version,

Best regards,
Sergio Paracuellos

Re: [PATCH v24 00/12] Landlock LSM

[James Morris]

On Thu, 12 Nov 2020, Mickaël Salaün wrote:

> Hi,
> 
> This patch series simplifies the code, makes stacked access-control more
> consistent (from the user point of view), properly handles memory
> allocation errors, and adds more tests (covering layered ruleset corner
> cases).  Most of these changes were sent as a separate patch series:
> https://lore.kernel.org/lkml/2020213442.434639-1-...@digikod.net/
> 
> James and Jann, could you please take a look at the main changes
> (patches 2, 7 and 8)?

We definitely need more review on these changes that came in. I'll drop 
the previous patchset from my tree and wait until the latest code is fully 
reviewed.

Fundamental locking issues and similar should be worked out before 
submitting for mainline merge.

-- 
James Morris

[PATCH net-next] net/nfc/nci: Support NCI 2.x initial sequence

[Bongsu Jeon]

implement the NCI 2.x initial sequence to support NCI 2.x NFCC.
Since NCI 2.0, CORE_RESET and CORE_INIT sequence have been changed.
If NFCEE supports NCI 2.x, then NCI 2.x initial sequence will work.

In NCI 1.0, Initial sequence and payloads are as below:
(DH) (NFCC)
 |  -- CORE_RESET_CMD --> |
 |  <-- CORE_RESET_RSP -- |
 |  -- CORE_INIT_CMD -->  |
 |  <-- CORE_INIT_RSP --  |
 CORE_RESET_RSP payloads are Status, NCI version, Configuration Status.
 CORE_INIT_CMD payloads are empty.
 CORE_INIT_RSP payloads are Status, NFCC Features,
Number of Supported RF Interfaces, Supported RF Interface,
Max Logical Connections, Max Routing table Size,
Max Control Packet Payload Size, Max Size for Large Parameters,
Manufacturer ID, Manufacturer Specific Information.

In NCI 2.0, Initial Sequence and Parameters are as below:
(DH) (NFCC)
 |  -- CORE_RESET_CMD --> |
 |  <-- CORE_RESET_RSP -- |
 |  <-- CORE_RESET_NTF -- |
 |  -- CORE_INIT_CMD -->  |
 |  <-- CORE_INIT_RSP --  |
 CORE_RESET_RSP payloads are Status.
 CORE_RESET_NTF payloads are Reset Trigger,
Configuration Status, NCI Version, Manufacturer ID,
Manufacturer Specific Information Length,
Manufacturer Specific Information.
 CORE_INIT_CMD payloads are Feature1, Feature2.
 CORE_INIT_RSP payloads are Status, NFCC Features,
Max Logical Connections, Max Routing Table Size,
Max Control Packet Payload Size,
Max Data Packet Payload Size of the Static HCI Connection,
Number of Credits of the Static HCI Connection,
Max NFC-V RF Frame Size, Number of Supported RF Interfaces,
Supported RF Interfaces.

Signed-off-by: Bongsu Jeon 
---
 include/net/nfc/nci.h | 39 ++
 net/nfc/nci/core.c| 23 +++--
 net/nfc/nci/ntf.c | 21 
 net/nfc/nci/rsp.c | 75 +--
 4 files changed, 146 insertions(+), 12 deletions(-)

diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
index 0550e0380b8d..b434f984bc8c 100644
--- a/include/net/nfc/nci.h
+++ b/include/net/nfc/nci.h
@@ -25,6 +25,8 @@
 #define NCI_MAX_PARAM_LEN  251
 #define NCI_MAX_PAYLOAD_SIZE   255
 #define NCI_MAX_PACKET_SIZE258
+#define NCI_MAX_LARGE_PARAMS_NCI_v215
+#define NCI_VER_2_MASK 0x20
 
 /* NCI Status Codes */
 #define NCI_STATUS_OK  0x00
@@ -131,6 +133,9 @@
 #define NCI_LF_CON_BITR_F_212  0x02
 #define NCI_LF_CON_BITR_F_424  0x04
 
+/* NCI 2.x Feature Enable Bit */
+#define NCI_FEATURE_DISABLE0x00
+
 /* NCI Reset types */
 #define NCI_RESET_TYPE_KEEP_CONFIG 0x00
 #define NCI_RESET_TYPE_RESET_CONFIG0x01
@@ -220,6 +225,11 @@ struct nci_core_reset_cmd {
 } __packed;
 
 #define NCI_OP_CORE_INIT_CMD   nci_opcode_pack(NCI_GID_CORE, 0x01)
+/* To support NCI 2.x */
+struct nci_core_init_v2_cmd {
+   __u8feature1;
+   __u8feature2;
+} __packed;
 
 #define NCI_OP_CORE_SET_CONFIG_CMD nci_opcode_pack(NCI_GID_CORE, 0x02)
 struct set_config_param {
@@ -316,6 +326,11 @@ struct nci_core_reset_rsp {
__u8config_status;
 } __packed;
 
+/* To support NCI ver 2.x */
+struct nci_core_reset_rsp_nci_ver2 {
+   __u8status;
+} __packed;
+
 #define NCI_OP_CORE_INIT_RSP   nci_opcode_pack(NCI_GID_CORE, 0x01)
 struct nci_core_init_rsp_1 {
__u8status;
@@ -334,6 +349,20 @@ struct nci_core_init_rsp_2 {
__le32  manufact_specific_info;
 } __packed;
 
+/* To support NCI ver 2.x */
+struct nci_core_init_rsp_nci_ver2 {
+   __u8status;
+   __le32  nfcc_features;
+   __u8max_logical_connections;
+   __le16  max_routing_table_size;
+   __u8max_ctrl_pkt_payload_len;
+   __u8max_data_pkt_hci_payload_len;
+   __u8number_of_hci_credit;
+   __le16  max_nfc_v_frame_size;
+   __u8num_supported_rf_interfaces;
+   __u8supported_rf_interfaces[];
+} __packed;
+
 #define NCI_OP_CORE_SET_CONFIG_RSP nci_opcode_pack(NCI_GID_CORE, 0x02)
 struct nci_core_set_config_rsp {
__u8status;
@@ -372,6 +401,16 @@ struct nci_nfcee_discover_rsp {
 /* --- */
 /*  NCI Notifications  */
 /* --- */
+#define NCI_OP_CORE_RESET_NTF  nci_opcode_pack(NCI_GID_CORE, 0x00)
+struct nci_core_reset_ntf {
+   __u8reset_trigger;
+   __u8config_status;
+   __u8nci_ver;
+   __u8manufact_id;
+   __u8manufacturer_specific_len;
+   __u32   manufact_specific_info;
+} __packed;
+
 #define NCI_OP_CORE_CONN_CREDITS_NTF   nci_opcode_pack(NCI_GID_CORE, 0x06)
 struct conn_credit_entry {
__u8conn_id;
diff --gi

Re: [PATCH 2/2] docs: hwmon: Document max127 driver

[Guenter Roeck]

On Mon, Nov 16, 2020 at 05:09:44PM -0800, rentao.b...@gmail.com wrote:
> From: Tao Ren 
> 
> Add documentation for max127 hardware monitoring driver.
> 
> Signed-off-by: Tao Ren 
> ---
>  Documentation/hwmon/index.rst  |  1 +
>  Documentation/hwmon/max127.rst | 43 ++
>  2 files changed, 44 insertions(+)
>  create mode 100644 Documentation/hwmon/max127.rst
> 
> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
> index 408760d13813..0a07b6000c20 100644
> --- a/Documentation/hwmon/index.rst
> +++ b/Documentation/hwmon/index.rst
> @@ -111,6 +111,7 @@ Hardware Monitoring Kernel Drivers
> ltc4245
> ltc4260
> ltc4261
> +   max127
> max16064
> max16065
> max1619
> diff --git a/Documentation/hwmon/max127.rst b/Documentation/hwmon/max127.rst
> new file mode 100644
> index ..e50225a61c1a
> --- /dev/null
> +++ b/Documentation/hwmon/max127.rst
> @@ -0,0 +1,43 @@
> +.. SPDX-License-Identifier: GPL-2.0-or-later
> +
> +Kernel driver max127
> +
> +
> +Author:
> +
> +  * Tao Ren 
> +
> +Supported chips:
> +
> +  * Maxim MAX127
> +
> +Prefix: 'max127'
> +
> +Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX127-MAX128.pdf
> +
> +Description
> +---
> +
> +The MAX127 is a multirange, 12-bit data acquisition system (DAS) providing
> +8 analog input channels that are independently software programmable for
> +a variety of ranges. The available ranges are {0,5V}, {0,10V}, {-5,5V}
> +and {-10,10V}.
> +
> +The MAX127 features a 2-wire, I2C-compatible serial interface that allows
> +communication among multiple devices using SDA and SCL lines.
> +
> +Sysfs interface
> +---
> +
> +  == 
> ==
> +  in[0-7]_input  The conversion value for the corresponding channel.
> +  RO
> +
> +  in[0-7]_minThe lower limit (in Volt) for the corresponding channel.
> +  For the MAX127, it will be adjusted to -10, -5, or 0.
> +  RW
> +
> +  in[0-7]_maxThe higher limit (in Volt) for the corresponding channel.
> +  For the MAX127, it will be adjusted to 0, 5, or 10.
> +  RW

This should explain that the limits set the ADC range.

> +  == 
> ==
> -- 
> 2.17.1
> 

Re: [PATCH 1/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring driver

[Guenter Roeck]

On Mon, Nov 16, 2020 at 05:09:43PM -0800, rentao.b...@gmail.com wrote:
> From: Tao Ren 
> 
> Add hardware monitoring driver for the Maxim MAX127 chip.
> 
> MAX127 min/max range handling code is inspired by the max197 driver.
> 
> Signed-off-by: Tao Ren 
> ---
>  drivers/hwmon/Kconfig  |   9 ++
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/max127.c | 286 +
>  3 files changed, 296 insertions(+)
>  create mode 100644 drivers/hwmon/max127.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 9d600e0c5584..716df51edc87 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -950,6 +950,15 @@ config SENSORS_MAX
> This driver can also be built as a module. If so, the module
> will be called max.
>  
> +config SENSORS_MAX127
> + tristate "Maxim MAX127 12-bit 8-channel Data Acquisition System"
> + depends on I2C
> + help
> +   Say y here to support Maxim's MAX127 DAS chips.
> +
> +   This driver can also be built as a module. If so, the module
> +   will be called max127.
> +
>  config SENSORS_MAX16065
>   tristate "Maxim MAX16065 System Manager and compatibles"
>   depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 1083bbfac779..01ca5d3fbad4 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -127,6 +127,7 @@ obj-$(CONFIG_SENSORS_LTC4260) += ltc4260.o
>  obj-$(CONFIG_SENSORS_LTC4261)+= ltc4261.o
>  obj-$(CONFIG_SENSORS_LTQ_CPUTEMP) += ltq-cputemp.o
>  obj-$(CONFIG_SENSORS_MAX)+= max.o
> +obj-$(CONFIG_SENSORS_MAX127) += max127.o
>  obj-$(CONFIG_SENSORS_MAX16065)   += max16065.o
>  obj-$(CONFIG_SENSORS_MAX1619)+= max1619.o
>  obj-$(CONFIG_SENSORS_MAX1668)+= max1668.o
> diff --git a/drivers/hwmon/max127.c b/drivers/hwmon/max127.c
> new file mode 100644
> index ..df74a95bcf28
> --- /dev/null
> +++ b/drivers/hwmon/max127.c
> @@ -0,0 +1,286 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Hardware monitoring driver for MAX127.
> + *
> + * Copyright (c) 2020 Facebook Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* MAX127 Control Byte. */
> +#define MAX127_CTRL_STARTBIT(7)
> +#define MAX127_CTRL_SEL_OFFSET   4

That would better be named _SHIFT.

> +#define MAX127_CTRL_RNG  BIT(3)
> +#define MAX127_CTRL_BIP  BIT(2)
> +#define MAX127_CTRL_PD1  BIT(1)
> +#define MAX127_CTRL_PD0  BIT(0)
> +
> +#define MAX127_NUM_CHANNELS  8
> +#define MAX127_SET_CHANNEL(ch)   (((ch) & 7) << (MAX127_CTRL_SEL_OFFSET))

() around MAX127_CTRL_SEL_OFFSET is unnecessary.

> +
> +#define MAX127_INPUT_LIMIT   10  /* 10V */
> +
> +/*
> + * MAX127 returns 2 bytes at read:
> + *   - the first byte contains data[11:4].
> + *   - the second byte contains data[3:0] (MSB) and 4 dummy 0s (LSB).
> + */
> +#define MAX127_DATA1_SHIFT   4
> +
> +struct max127_data {
> + struct mutex lock;
> + struct i2c_client *client;
> + int input_limit;
> + u8 ctrl_byte[MAX127_NUM_CHANNELS];
> +};
> +
> +static int max127_select_channel(struct max127_data *data, int channel)
> +{
> + int status;
> + struct i2c_client *client = data->client;
> + struct i2c_msg msg = {
> + .addr = client->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = &data->ctrl_byte[channel],
> + };
> +
> + status = i2c_transfer(client->adapter, &msg, 1);
> + if (status != 1)
> + return status;
> +

Other drivers assume that this function can return 0. Please
take that into account as well.

> + return 0;
> +}
> +
> +static int max127_read_channel(struct max127_data *data, int channel, u16 
> *vin)
> +{
> + int status;
> + u8 i2c_data[2];
> + struct i2c_client *client = data->client;
> + struct i2c_msg msg = {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = 2,
> + .buf = i2c_data,
> + };
> +
> + status = i2c_transfer(client->adapter, &msg, 1);
> + if (status != 1)
> + return status;

Same as above.

> +
> + *vin = ((i2c_data[0] << 8) | i2c_data[1]) >> MAX127_DATA1_SHIFT;

THis seems wrong. D4..D11 end up in but 8..15, and D0..D3 end up in bit
0..3. Seems to me the upper byte should be left shifted 4 bit.
The result then needs to be scaled to mV (see below).

Also, for consistency I would suggest to either use () for both
parts of the logical or operation or for none.

> + return 0;
> +}
> +
> +static ssize_t max127_input_show(struct device *dev,
> +  struct device_attribute *dev_attr,
> +  char *buf)
> +{
> + u16 vin;
> + int status;
> + struct max127_data *data = dev_get_drvdata(dev);
> + struct sensor_device_attribute *attr = to_sensor_dev_at

[PATCH] ring-buffer: remove obsolete rb_event_is_commit()

[Lukas Bulwahn]

Commit a389d86f7fd0 ("ring-buffer: Have nested events still record running
time stamp") removed the only uses of rb_event_is_commit() in
rb_update_event() and rb_update_write_stamp().

Hence, since then, make CC=clang W=1 warns:

  kernel/trace/ring_buffer.c:2763:1:
warning: unused function 'rb_event_is_commit' [-Wunused-function]

Remove this obsolete function.

Signed-off-by: Lukas Bulwahn 
---
applies cleanly on current master and next-20201116

Steven, please pick this minor non-urgent clean-up patch.

 kernel/trace/ring_buffer.c | 17 -
 1 file changed, 17 deletions(-)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index ab68f28b8f4b..799d790ab365 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -2629,9 +2629,6 @@ rb_add_time_stamp(struct ring_buffer_event *event, u64 
delta, bool abs)
return skip_time_extend(event);
 }
 
-static inline bool rb_event_is_commit(struct ring_buffer_per_cpu *cpu_buffer,
-struct ring_buffer_event *event);
-
 #ifndef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
 static inline bool sched_clock_stable(void)
 {
@@ -2759,20 +2756,6 @@ static unsigned rb_calculate_event_length(unsigned 
length)
return length;
 }
 
-static __always_inline bool
-rb_event_is_commit(struct ring_buffer_per_cpu *cpu_buffer,
-  struct ring_buffer_event *event)
-{
-   unsigned long addr = (unsigned long)event;
-   unsigned long index;
-
-   index = rb_event_index(event);
-   addr &= PAGE_MASK;
-
-   return cpu_buffer->commit_page->page == (void *)addr &&
-   rb_commit_index(cpu_buffer) == index;
-}
-
 static u64 rb_time_delta(struct ring_buffer_event *event)
 {
switch (event->type_len) {
-- 
2.17.1

Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM

[John Paul Adrian Glaubitz]

Hi!

On 11/1/20 6:04 PM, Mike Rapoport wrote:
> It's been a while since DISCONTIGMEM is generally considered deprecated,
> but it is still used by four architectures. This set replaces DISCONTIGMEM
> with a different way to handle holes in the memory map and marks
> DISCONTIGMEM configuration as BROKEN in Kconfigs of these architectures with
> the intention to completely remove it in several releases.
> 
> While for 64-bit alpha and ia64 the switch to SPARSEMEM is quite obvious
> and was a matter of moving some bits around, for smaller 32-bit arc and
> m68k SPARSEMEM is not necessarily the best thing to do.
> 
> On 32-bit machines SPARSEMEM would require large sections to make section
> index fit in the page flags, but larger sections mean that more memory is
> wasted for unused memory map.
> 
> Besides, pfn_to_page() and page_to_pfn() become less efficient, at least on
> arc.
> 
> So I've decided to generalize arm's approach for freeing of unused parts of
> the memory map with FLATMEM and enable it for both arc and m68k. The
> details are in the description of patches 10 (arc) and 13 (m68k).

Apologies for the late reply. Is this still relevant for testing?

I have already successfully tested v1 of the patch set, shall I test v2?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH v4 01/10] Add auxiliary bus support

[Leon Romanovsky]

On Fri, Nov 13, 2020 at 08:18:50AM -0800, Dave Ertman wrote:
> Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> It enables drivers to create an auxiliary_device and bind an
> auxiliary_driver to it.
>
> The bus supports probe/remove shutdown and suspend/resume callbacks.
> Each auxiliary_device has a unique string based id; driver binds to
> an auxiliary_device based on this id through the bus.
>
> Co-developed-by: Kiran Patil 
> Signed-off-by: Kiran Patil 
> Co-developed-by: Ranjani Sridharan 
> Signed-off-by: Ranjani Sridharan 
> Co-developed-by: Fred Oh 
> Signed-off-by: Fred Oh 
> Co-developed-by: Leon Romanovsky 
> Signed-off-by: Leon Romanovsky 
> Reviewed-by: Pierre-Louis Bossart 
> Reviewed-by: Shiraz Saleem 
> Reviewed-by: Parav Pandit 
> Reviewed-by: Dan Williams 
> Signed-off-by: Dave Ertman 
> ---

Greg,

This horse was beaten to death, can we please progress with this patch?
Create special topic branch or ack so I'll prepare this branch.

We are in -rc4 now and we (Mellanox) can't hold our submissions anymore.
My mlx5_core probe patches [1] were too intrusive and they are ready to
be merged, Parav's patches got positive review as well [2] and will be
taken next.

We delayed and have in our internal queues the patches for VDPA, eswitch
and followup for mlx5_core probe rework, but trapped due to this AUX bus
patch.

Thanks

[1] https://lore.kernel.org/linux-rdma/20201101201542.2027568-1-l...@kernel.org/
[2] 
https://lore.kernel.org/linux-rdma/by5pr12mb43229f23c101afbcd2971534dc...@by5pr12mb4322.namprd12.prod.outlook.com/T/#md25b9a2feb4c60d3fef5d57da41db559af1062d8

Re: linux-next: build warning after merge of the tip tree

[Balbir Singh]

On 11/16/20 9:23 AM, Balbir Singh wrote:
> 
> 
> On 10/28/20 2:23 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (htmldocs) produced
>> this warning:
>>
>> Documentation/admin-guide/hw-vuln/l1d_flush.rst:25: WARNING: undefined 
>> label: documentation/userspace-api/spec_ctrl.rst (if the link has no caption 
>> the label must precede a section header)
>>
>> Introduced by commit
>>
>>   767d46ab566d ("Documentation: Add L1D flushing Documentation")
>>
> 
> Looking at it thanks, I am no expert with sphinx, but it seems like I need 
> angular braces around the link
> 
> Balbir Singh.
> 

I am testing a fix by pointing the ref to a label, will send it out (hopefully 
soon), seems to work at my end.

Balbir Singh.

[PATCH 1/2] powerpc: Retire e200 core (mpc555x processor)

[Christophe Leroy]

There is no defconfig selecting CONFIG_E200, and no platform.

e200 is an earlier version of booke, a predecessor of e500,
with some particularities like an unified cache instead of both an
instruction cache and a data cache.

Remove it.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/Makefile |  1 -
 arch/powerpc/include/asm/cputable.h   | 11 -
 arch/powerpc/include/asm/mmu.h|  2 +-
 arch/powerpc/include/asm/reg.h|  5 --
 arch/powerpc/include/asm/reg_booke.h  | 12 -
 arch/powerpc/kernel/cpu_setup_fsl_booke.S |  9 
 arch/powerpc/kernel/cputable.c| 46 --
 arch/powerpc/kernel/head_booke.h  |  3 +-
 arch/powerpc/kernel/head_fsl_booke.S  | 57 +--
 arch/powerpc/kernel/setup_32.c|  2 -
 arch/powerpc/kernel/traps.c   | 25 --
 arch/powerpc/mm/nohash/fsl_booke.c| 12 ++---
 arch/powerpc/platforms/Kconfig.cputype| 13 ++
 13 files changed, 11 insertions(+), 187 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a4d56f0a41d9..16b8336f91dd 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -248,7 +248,6 @@ KBUILD_CFLAGS   += $(call cc-option,-mno-string)
 cpu-as-$(CONFIG_40x)   += -Wa,-m405
 cpu-as-$(CONFIG_44x)   += -Wa,-m440
 cpu-as-$(CONFIG_ALTIVEC)   += $(call as-option,-Wa$(comma)-maltivec)
-cpu-as-$(CONFIG_E200)  += -Wa,-me200
 cpu-as-$(CONFIG_E500)  += -Wa,-me500
 
 # When using '-many -mpower4' gas will first try and find a matching power4
diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 3d2f94afc13a..7d815a3e7206 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -41,7 +41,6 @@ extern int machine_check_4xx(struct pt_regs *regs);
 extern int machine_check_440A(struct pt_regs *regs);
 extern int machine_check_e500mc(struct pt_regs *regs);
 extern int machine_check_e500(struct pt_regs *regs);
-extern int machine_check_e200(struct pt_regs *regs);
 extern int machine_check_47x(struct pt_regs *regs);
 int machine_check_8xx(struct pt_regs *regs);
 int machine_check_83xx(struct pt_regs *regs);
@@ -383,10 +382,6 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTRS_440x6 (CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE | \
CPU_FTR_INDEXED_DCR)
 #define CPU_FTRS_47X   (CPU_FTRS_440x6)
-#define CPU_FTRS_E200  (CPU_FTR_SPE_COMP | \
-   CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \
-   CPU_FTR_NOEXECUTE | \
-   CPU_FTR_DEBUG_LVL_EXC)
 #define CPU_FTRS_E500  (CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
CPU_FTR_NOEXECUTE)
@@ -535,9 +530,6 @@ enum {
 #ifdef CONFIG_PPC_47x
CPU_FTRS_47X | CPU_FTR_476_DD2 |
 #endif
-#ifdef CONFIG_E200
-   CPU_FTRS_E200 |
-#endif
 #ifdef CONFIG_E500
CPU_FTRS_E500 | CPU_FTRS_E500_2 |
 #endif
@@ -608,9 +600,6 @@ enum {
 #ifdef CONFIG_44x
CPU_FTRS_44X & CPU_FTRS_440x6 &
 #endif
-#ifdef CONFIG_E200
-   CPU_FTRS_E200 &
-#endif
 #ifdef CONFIG_E500
CPU_FTRS_E500 & CPU_FTRS_E500_2 &
 #endif
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 255a1837e9f7..b724c38589a1 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -166,7 +166,7 @@ enum {
 #ifdef CONFIG_44x
MMU_FTR_TYPE_44x |
 #endif
-#if defined(CONFIG_E200) || defined(CONFIG_E500)
+#ifdef CONFIG_E500
MMU_FTR_TYPE_FSL_E | MMU_FTR_BIG_PHYS | MMU_FTR_USE_TLBILX |
 #endif
 #ifdef CONFIG_PPC_47x
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index f877a576b338..3c81a6efaf23 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1232,14 +1232,9 @@
 #define SPRN_SPRG_WSCRATCH_MC  SPRN_SPRG1
 #define SPRN_SPRG_RSCRATCH4SPRN_SPRG7R
 #define SPRN_SPRG_WSCRATCH4SPRN_SPRG7W
-#ifdef CONFIG_E200
-#define SPRN_SPRG_RSCRATCH_DBG SPRN_SPRG6R
-#define SPRN_SPRG_WSCRATCH_DBG SPRN_SPRG6W
-#else
 #define SPRN_SPRG_RSCRATCH_DBG SPRN_SPRG9
 #define SPRN_SPRG_WSCRATCH_DBG SPRN_SPRG9
 #endif
-#endif
 
 #ifdef CONFIG_PPC_8xx
 #define SPRN_SPRG_SCRATCH0 SPRN_SPRG0
diff --git a/arch/powerpc/include/asm/reg_booke.h 
b/arch/powerpc/include/asm/reg_booke.h
index 29a948e0c0f2..262782f08fd4 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -281,18 +281,6 @@
 #define MSRP_PMMP  0x0004 /* Protect MSR[PMM] */
 #endif
 
-#ifdef CONFIG_E200
-#define MCSR_MCP   0x8000UL /* Machine Check Input Pin */
-#define MCSR_CP_PERR   0x2000UL /* Cache Push Parity Error */
-#define MCSR_CPERR 0x1000UL /* Cache Parity Error */
-#define MCSR_EXCP_ERR  0x0800UL /* ISI, ITLB, or Bus Error on 1st insn
-  

[PATCH 2/2] powerpc: Remove ucache_bsize

[Christophe Leroy]

ppc601 and e200 were the users of ucache_bsize.
ppc601 and e200 are now gone.

Remove ucache_bsize.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/elf.h | 2 +-
 arch/powerpc/kernel/setup-common.c | 4 
 arch/powerpc/kernel/setup_32.c | 1 -
 3 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 53ed2ca40151..900b8d7fdffa 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -168,7 +168,7 @@ do {
\
/* Cache size items */  \
NEW_AUX_ENT(AT_DCACHEBSIZE, dcache_bsize);  \
NEW_AUX_ENT(AT_ICACHEBSIZE, icache_bsize);  \
-   NEW_AUX_ENT(AT_UCACHEBSIZE, ucache_bsize);  \
+   NEW_AUX_ENT(AT_UCACHEBSIZE, 0); \
VDSO_AUX_ENT(AT_SYSINFO_EHDR, current->mm->context.vdso_base);  \
ARCH_DLINFO_CACHE_GEOMETRY; \
 } while (0)
diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 808ec9fab605..c23449a93fef 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -90,8 +90,6 @@ EXPORT_SYMBOL_GPL(boot_cpuid);
  */
 int dcache_bsize;
 int icache_bsize;
-int ucache_bsize;
-
 
 unsigned long klimit = (unsigned long) _end;
 
@@ -802,8 +800,6 @@ static __init void print_system_info(void)
 
pr_info("dcache_bsize  = 0x%x\n", dcache_bsize);
pr_info("icache_bsize  = 0x%x\n", icache_bsize);
-   if (ucache_bsize != 0)
-   pr_info("ucache_bsize  = 0x%x\n", ucache_bsize);
 
pr_info("cpu_features  = 0x%016lx\n", cur_cpu_spec->cpu_features);
pr_info("  possible= 0x%016lx\n",
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 416e2c7a8b0a..8ba49a6bf515 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -222,5 +222,4 @@ __init void initialize_cache_info(void)
 */
dcache_bsize = cur_cpu_spec->dcache_bsize;
icache_bsize = cur_cpu_spec->icache_bsize;
-   ucache_bsize = 0;
 }
-- 
2.25.0

RE: [PATCH] iscsi: Do Not set param when sock is NULL

[Gulam Mohamed]

Gentle reminder.

Regards,
Gulam Mohamed.

-Original Message-
From: Gulam Mohamed 
Sent: Thursday, November 5, 2020 11:11 AM
To: Lee Duncan ; Chris Leech ; James E.J. 
Bottomley ; Martin K. Petersen 
; open-is...@googlegroups.com; 
linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
Cc: Junxiao Bi 
Subject: [PATCH] iscsi: Do Not set param when sock is NULL

Description
=
1. This Kernel panic could be due to a timing issue when there is a race 
between the sync thread and the initiator was processing of a login response 
from the target. The session re-open can be invoked from two places
  a.Sessions sync thread when the iscsid restart
  b.From iscsid through iscsi error handler
2. The session reopen sequence is as follows in user-space 
(iscsi-initiator-utils)
  a.Disconnect the connection
  b.Then send the stop connection request to the kernel which 
releases the connection (releases the socket)
  c.Queues the reopen for 2 seconds delay
 d. Once the delay expires, create the TCP connection again by 
calling the connect() call
 e. Poll for the connection
  f.When poll is successful i.e when the TCP connection is 
established, it performs
i. Creation of session and connection data structures
ii. Bind the connection to the session. This is the place where we 
assign the sock to tcp_sw_conn->sock
iii. Sets the parameters like target name, persistent address etc .
iv. Creates the login pdu
v. Sends the login pdu to kernel
vi. Returns to the main loop to process further events. The kernel then 
sends the login request over to the target node
g. Once login response with success is received, it enters into full 
feature phase and sets the negotiable parameters like max_recv_data_length, 
max_transmit_length, data_digest etc . 3. While setting the negotiable 
parameters by calling "iscsi_session_set_neg_params()", kernel panicked as sock 
was NULL

What happened here is

1.  Before initiator received the login response mentioned in above point 
2.f.v, another reopen request was sent from the error handler/sync session for 
the same session, as the initiator utils was in main loop to process further 
events (as 
mentioned in point 2.f.vi above). 
2.  While processing this reopen, it stopped the connection which released 
the socket and queued this connection and at this point of time the login 
response was received for the earlier one
3.  The kernel passed over this response to user-space which then sent the 
set_neg_params request to kernel
4.  As the connection was stopped, the sock was NULL and hence while the 
kernel was processing the set param request from user-space, it panicked

Fix

1.  While setting the set_param in kernel, we need to check if sock is NULL
2.  If the sock is NULL, then return EPERM (operation not permitted)
3.  Due to this error handler will be invoked in user-space again to 
recover the session

Signed-off-by: Gulam Mohamed 
Reviewed-by: Junxiao Bi 
---
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c index 
df47557a02a3..fd668a194053 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -711,6 +711,12 @@ static int iscsi_sw_tcp_conn_set_param(struct 
iscsi_cls_conn *cls_conn,
struct iscsi_tcp_conn *tcp_conn = conn->dd_data;
struct iscsi_sw_tcp_conn *tcp_sw_conn = tcp_conn->dd_data;

+   if (!tcp_sw_conn->sock) {
+   iscsi_conn_printk(KERN_ERR, conn,
+   "Cannot set param as sock is NULL\n");
+   return -ENOTCONN;
+   }
+
switch(param) {
case ISCSI_PARAM_HDRDGST_EN:
iscsi_set_param(cls_conn, param, buf, buflen);
--
2.18.4

[tip:ras/core] BUILD SUCCESS 098416e6986127f7e4c8ce4fd6bbbd80e55b0386

[kernel test robot]

 defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a003-20201116
x86_64   randconfig-a005-20201116
x86_64   randconfig-a004-20201116
x86_64   randconfig-a002-20201116
x86_64   randconfig-a001-20201116
x86_64   randconfig-a006-20201116
i386 randconfig-a006-20201116
i386 randconfig-a005-20201116
i386 randconfig-a001-20201116
i386 randconfig-a002-20201116
i386 randconfig-a004-20201116
i386 randconfig-a003-20201116
i386 randconfig-a006-20201115
i386 randconfig-a005-20201115
i386 randconfig-a001-20201115
i386 randconfig-a002-20201115
i386 randconfig-a004-20201115
i386 randconfig-a003-20201115
x86_64   randconfig-a015-20201115
x86_64   randconfig-a011-20201115
x86_64   randconfig-a016-20201115
x86_64   randconfig-a012-20201115
i386 randconfig-a012-20201116
i386 randconfig-a014-20201116
i386 randconfig-a016-20201116
i386 randconfig-a011-20201116
i386 randconfig-a015-20201116
i386 randconfig-a013-20201116
i386 randconfig-a012-20201115
i386 randconfig-a014-20201115
i386 randconfig-a016-20201115
i386 randconfig-a011-20201115
i386 randconfig-a015-20201115
i386 randconfig-a013-20201115
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a003-20201115
x86_64   randconfig-a005-20201115
x86_64   randconfig-a004-20201115
x86_64   randconfig-a002-20201115
x86_64   randconfig-a001-20201115
x86_64   randconfig-a006-20201115
x86_64   randconfig-a015-20201116
x86_64   randconfig-a011-20201116
x86_64   randconfig-a014-20201116
x86_64   randconfig-a013-20201116
x86_64   randconfig-a016-20201116
x86_64   randconfig-a012-20201116

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

linux-next: manual merge of the akpm-current tree with the block tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/filemap.c

between commit:

  0abed7c69b95 ("mm: never attempt async page lock if we've transferred data 
already")

from the block tree and commit:

  b5c7e73f6bd3 ("mm/filemap/c: break generic_file_buffered_read up into 
multiple functions")

from the akpm-current tree.

I just used the latter version for today, if more is needed, please let
me know.

This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpL6Ez_zuKsw.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] perf/core: Flush PMU internal buffers for per-CPU events

[Namhyung Kim]

Hello,

On Thu, Nov 12, 2020 at 4:54 AM Liang, Kan  wrote:
>
>
>
> On 11/11/2020 11:25 AM, Peter Zijlstra wrote:
> > On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote:
> >
> >> - When the large PEBS was introduced (9c964efa4330), the sched_task() 
> >> should
> >> be invoked to flush the PEBS buffer in each context switch. However, The
> >> perf_sched_events in account_event() is not updated accordingly. The
> >> perf_event_task_sched_* never be invoked for a pure per-CPU context. Only
> >> per-task event works.
> >> At that time, the perf_pmu_sched_task() is outside of
> >> perf_event_context_sched_in/out. It means that perf has to double
> >> perf_pmu_disable() for per-task event.
> >
> >> - The patch 1 tries to fix broken per-CPU events. The CPU context cannot be
> >> retrieved from the task->perf_event_ctxp. So it has to be tracked in the
> >> sched_cb_list. Yes, the code is very similar to the original codes, but it
> >> is actually the new code for per-CPU events. The optimization for per-task
> >> events is still kept.
> >>For the case, which has both a CPU context and a task context, yes, the
> >> __perf_pmu_sched_task() in this patch is not invoked. Because the
> >> sched_task() only need to be invoked once in a context switch. The
> >> sched_task() will be eventually invoked in the task context.
> >
> > The thing is; your first two patches rely on PERF_ATTACH_SCHED_CB and
> > only set that for large pebs. Are you sure the other users (Intel LBR
> > and PowerPC BHRB) don't need it?
>
> I didn't set it for LBR, because the perf_sched_events is always enabled
> for LBR. But, yes, we should explicitly set the PERF_ATTACH_SCHED_CB
> for LBR.
>
> if (has_branch_stack(event))
> inc = true;
>
> >
> > If they indeed do not require the pmu::sched_task() callback for CPU
> > events, then I still think the whole perf_sched_cb_{inc,dec}() interface
>
> No, LBR requires the pmu::sched_task() callback for CPU events.
>
> Now, The LBR registers have to be reset in sched in even for CPU events.
>
> To fix the shorter LBR callstack issue for CPU events, we also need to
> save/restore LBRs in pmu::sched_task().
> https://lore.kernel.org/lkml/1578495789-95006-4-git-send-email-kan.li...@linux.intel.com/
>
> > is confusing at best.
> >
> > Can't we do something like this instead?
> >
> I think the below patch may have two issues.
> - PERF_ATTACH_SCHED_CB is required for LBR (maybe PowerPC BHRB as well) now.
> - We may disable the large PEBS later if not all PEBS events support
> large PEBS. The PMU need a way to notify the generic code to decrease
> the nr_sched_task.

Any updates on this?  I've reviewed and tested Kan's patches
and they all look good.

Maybe we can talk to PPC folks to confirm the BHRB case?

Thanks,
Namhyung

Re: [PATCH bpf-next] libbpf: bpf__find_by_name[_kind] should use btf__get_nr_types()

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to bpf/bpf-next.git (refs/heads/master):

On Sun, 15 Nov 2020 10:46:35 + you wrote:
> When operating on split BTF, btf__find_by_name[_kind] will not
> iterate over all types since they use btf->nr_types to show
> the number of types to iterate over.  For split BTF this is
> the number of types _on top of base BTF_, so it will
> underestimate the number of types to iterate over, especially
> for vmlinux + module BTF, where the latter is much smaller.
> 
> [...]

Here is the summary with links:
  - [bpf-next] libbpf: bpf__find_by_name[_kind] should use btf__get_nr_types()
https://git.kernel.org/bpf/bpf-next/c/de91e631bdc7

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH bpf v6 1/2] lib/strncpy_from_user.c: Don't overcopy bytes after NUL terminator

[Daniel Xu]

Hi Linus,

On Mon, Nov 16, 2020 at 02:15:52PM -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2020 at 1:17 PM Daniel Xu  wrote:
> >
> > Based on on-list discussion and some off-list discussion with Alexei,
> > I'd like to propose the v4-style patch without the `(*out & ~mask)`
> > bit.
> 
> So I've verified that at least on x86-64, this doesn't really make
> code generation any worse, and I'm ok with the patch from that
> standpoint.
> 
> However, this was not what the discussion actually amended at as far
> as I'm concerned.
> 
> I mentioned that if BPF cares about the bytes past the end of the
> string, I want a *BIG COMMENT* about it. Yes, in strncpy_from_user()
> itself, but even more in the place that cares.

Sure, sorry. Will send another version with comments.

> And no, that does not mean bpf_probe_read_user_str().  That function
> clearly doesn't care at all, and doesn't access anything past the end
> of the string. I want a comment in whatever code that accesses past
> the end of the string.

If I'm reading things right, that place is technically in
kernel/bpf/hashtab.c:alloc_htab_elem. In line:

memcpy(l_new->key, key, key_size);

where `key_size` is the width of the hashtab key. The flow looks like:


  bpf_map_update_elem()
htab_map_update_elem()
  alloc_htab_elem()

It feels a bit weird to me to add a comment about strings in there
because the hash table code is string-agnostic, as mentioned in the
commit message.

> And your ABI point is actively misleading:
> 
> > We can't really zero out the rest of the buffer due to ABI issues.
> > The bpf docs state for bpf_probe_read_user_str():
> >
> > > In case the string length is smaller than *size*, the target is not
> > > padded with further NUL bytes.
> 
> This comment is actively wrong and misleading.
> 
> The code (after the patch) clearly *does* pad a bit with "further NUL
> bytes". It's just that it doesn't pad all the way to the end.

Right, it's a bit ugly and perhaps misleading. But it fixes the real
problem of keying a map with potentially random memory that
strncpy_from_user() might append on. If we pad a deterministic number of
zeros it should be ok.

> Where is the actual buffer zeroing done?

Usually the bpf prog does it. I believe (could be wrong) the verifier
enforces the key is initialized in some form.

For my specific use case, it's done in the bpftrace code:
https://github.com/iovisor/bpftrace/blob/0c88a1a4711a3d13e8c9475f7d08f83a5018fdfd/src/ast/codegen_llvm.cpp#L529-L530

> Because without the buffer zeroing, this whole patch is completely
> pointless. Which is why I want that comment, and I want a pointer to
> where that zeroing is done.
> 
> Really. You have two cases:
> 
>  (a) the buffer isn't zeroed before the strncpy_from_user()
> 
>  (b) the buffer is guaranteed to be zero before that
> 
> and in case (a), this patch is pointless, since the data after the
> string is already undefined.

See above -- I think the verifier enforces that the data is initialized.

> And in case (b), I want to see a comment and a pointer to the code
> that actually does the zeroing.

See above also.

> HOWEVER. Look at bpf_probe_read_user_str_common(), and notice how it
> ALREADY does the zeroing of the buffer past the end, it's just that it
> only does it in the error case.

I don't think the error case is very relevant here. I normally wouldn't
make any assumptions about the state of a buffer after a failed function
call.

> Why do you send this patch, instead of
> 
>  (a) get rid of the pointless pre-zeroing
> 
>  (b) change bpf_probe_read_user_str_common() to do
> 
> int ret;
> u32 offset;
> 
> ret = strncpy_from_user_nofault(dst, unsafe_ptr, size);
> offset = ret < 0 ? 0 : ret;
> memset(dst+offset, 0, size-offset);
> return ret;
> 
> which seems to be much simpler anyway. The comment you quote about
> "target is not padded with further NUL bytes" is clearly wrong anyway,
> since that error case *does* pad the target with NUL bytes, and always
> has.

I think on the bpf side there's the same concern about performance.
You can't really dynamically size buffers in bpf land so users usually
use a larger buffer than necessary, sometimes on the order of KBs. So if
we unnecessarily zero out the rest of the buffer it could cause perf
regressions.

[...]

Thanks,
Daniel

Re: [PATCH] mmc: xenon: enable ACPI support in the driver

[kernel test robot]

Hi Marcin,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on linux/master v5.10-rc4 next-20201116]
[cannot apply to ulf.hansson-mmc/next mmc/mmc-next]
[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/Marcin-Wojtas/mmc-xenon-enable-ACPI-support-in-the-driver/20201114-171221
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1
config: powerpc-randconfig-r026-20201116 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
ace9653c11c6308401dcda2e8b26bf97e6e66e30)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://github.com/0day-ci/linux/commit/6595d0b7fbf57c9f404669db45d3895aa578ea03
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Marcin-Wojtas/mmc-xenon-enable-ACPI-support-in-the-driver/20201114-171221
git checkout 6595d0b7fbf57c9f404669db45d3895aa578ea03
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

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

All warnings (new ones prefixed by >>):

>> drivers/mmc/host/sdhci-xenon.c:701:36: warning: unused variable 
>> 'sdhci_xenon_acpi_ids' [-Wunused-const-variable]
   static const struct acpi_device_id sdhci_xenon_acpi_ids[] = {
  ^
   1 warning generated.

vim +/sdhci_xenon_acpi_ids +701 drivers/mmc/host/sdhci-xenon.c

   700  
 > 701  static const struct acpi_device_id sdhci_xenon_acpi_ids[] = {
   702  { .id = "MRVL0002",},
   703  {}
   704  };
   705  MODULE_DEVICE_TABLE(acpi, sdhci_xenon_acpi_ids);
   706  

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


.config.gz
Description: application/gzip

Re: [PATCH v1] Bluetooth: hci_qca: Handle spurious wakeup from SoC

[Abhishek Pandit-Subedi]

Hi Venkata,

I think this code would be simplified by using a delayed_work struct
instead of a timer.

Based on your commit description:

On Sun, Nov 15, 2020 at 9:59 AM Venkata Lakshmi Narayana Gubba
 wrote:
>
> Added timer to handle spurious wakeup from SoC.
> Timer is started when wake indicator is received from SoC.
> Timer is restarted when valid data is received from SoC.
> Timer is stopped when sleep indicator is received from SoC.
> SSR is triggered upon timer expiry.
>
> Signed-off-by: Venkata Lakshmi Narayana Gubba 

in function qca_ibs_wake_ind: (timer started when wake indicator is
received from SoC)
  queue_delayed_work(qca->workqueue, &qca->spurious_wake,
IBS_SOC_SPURIOUS_WAKE_TIMEOUT_MS)

in function qca_ibs_sleep_ind: (Timer is stopped when sleep indicator
is received from SoC.)
  cancel_delayed_work(qca->workqueue, &qca->spurious_wake);

in  qca_recv_acl_data, qca_recv_sco_data and qca_recv_event: (Timer is
restarted when valid data is received from SoC.)
  if (!test_bit(QCA_IBS_DISABLED, &qca->flags))
mod_delayed_work(qca->workqueue, &qca->spurious_wake,
IBS_SOC_SPURIOUS_WAKE_TIMEOUT_MS)

and finally in qca_ibs_spurious_wake_timeout (originally named
hci_ibs_spurious_wake_timeout in your patch): (SSR is triggered upon
timer expiry.)
  if (!test_bit(QCA_HW_ERROR_EVENT, &qca->flags))
hci_reset_dev(hu->hdev);

That should trigger qca_hw_error so you don't need to duplicate the
crash dump triggering + waiting in multiple places (and if you get the
spurious wake bug WHILE doing SSR, it won't re-trigger the same
restart over and over).

Abhishek


> ---
>  drivers/bluetooth/hci_qca.c | 99 
> -
>  1 file changed, 97 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 5cc7b16..6953001 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -48,6 +48,7 @@
>  #define IBS_WAKE_RETRANS_TIMEOUT_MS100
>  #define IBS_BTSOC_TX_IDLE_TIMEOUT_MS   200
>  #define IBS_HOST_TX_IDLE_TIMEOUT_MS2000
> +#define IBS_SOC_SPURIOUS_WAKE_TIMEOUT_MS 1
>  #define CMD_TRANS_TIMEOUT_MS   100
>  #define MEMDUMP_TIMEOUT_MS 8000
>  #define IBS_DISABLE_SSR_TIMEOUT_MS (MEMDUMP_TIMEOUT_MS + 1000)
> @@ -147,7 +148,9 @@ struct qca_data {
> bool tx_vote;   /* Clock must be on for TX */
> bool rx_vote;   /* Clock must be on for RX */
> struct timer_list tx_idle_timer;
> +   struct timer_list spurious_wake_timer;
> u32 tx_idle_delay;
> +   u32 spurious_wake;
> struct timer_list wake_retrans_timer;
> u32 wake_retrans;
> struct workqueue_struct *workqueue;
> @@ -156,6 +159,7 @@ struct qca_data {
> struct work_struct ws_rx_vote_off;
> struct work_struct ws_tx_vote_off;
> struct work_struct ctrl_memdump_evt;
> +   struct work_struct spurious_wake_timeout;
> struct delayed_work ctrl_memdump_timeout;
> struct qca_memdump_data *qca_memdump;
> unsigned long flags;
> @@ -229,6 +233,7 @@ static void qca_regulator_disable(struct qca_serdev 
> *qcadev);
>  static void qca_power_shutdown(struct hci_uart *hu);
>  static int qca_power_off(struct hci_dev *hdev);
>  static void qca_controller_memdump(struct work_struct *work);
> +static void qca_wq_spurious_wake_timeout(struct work_struct *work);
>
>  static enum qca_btsoc_type qca_soc_type(struct hci_uart *hu)
>  {
> @@ -530,6 +535,15 @@ static void hci_ibs_wake_retrans_timeout(struct 
> timer_list *t)
> hci_uart_tx_wakeup(hu);
>  }
>
> +static void hci_ibs_spurious_wake_timeout(struct timer_list *t)
> +{
> +   struct qca_data *qca = from_timer(qca, t, spurious_wake_timer);
> +   struct hci_uart *hu = qca->hu;
> +
> +   bt_dev_warn(hu->hdev, "hu %p spurious wake timeout in %d state", hu, 
> qca->rx_ibs_state);
> +
> +   queue_work(qca->workqueue, &qca->spurious_wake_timeout);
> +}
>
>  static void qca_controller_memdump_timeout(struct work_struct *work)
>  {
> @@ -584,6 +598,7 @@ static int qca_open(struct hci_uart *hu)
> INIT_WORK(&qca->ws_rx_vote_off, qca_wq_serial_rx_clock_vote_off);
> INIT_WORK(&qca->ws_tx_vote_off, qca_wq_serial_tx_clock_vote_off);
> INIT_WORK(&qca->ctrl_memdump_evt, qca_controller_memdump);
> +   INIT_WORK(&qca->spurious_wake_timeout, qca_wq_spurious_wake_timeout);
> INIT_DELAYED_WORK(&qca->ctrl_memdump_timeout,
>   qca_controller_memdump_timeout);
> init_waitqueue_head(&qca->suspend_wait_q);
> @@ -615,6 +630,9 @@ static int qca_open(struct hci_uart *hu)
> timer_setup(&qca->tx_idle_timer, hci_ibs_tx_idle_timeout, 0);
> qca->tx_idle_delay = IBS_HOST_TX_IDLE_TIMEOUT_MS;
>
> +   timer_setup(&qca->spurious_wake_timer, hci_ibs_spurious_wake_timeout, 
> 0);
> +   qca->spurious_wake = IBS_SOC_SPURIOUS_WAKE_TIMEOUT_MS;
> +
> BT_DBG("HCI_UART_QCA open,