date:20210129

On Fri, 29 Jan 2021 11:15:43 + Oleksandr Mazur wrote:
> > Thinking about it again - if the action can be changed wouldn't it 
> > be best for the user to actually get a "HW condition hit" counter,
> > which would increment regardless of SW config (incl. policers)?  
> 
> > Otherwise if admin logs onto the box and temporarily enables a trap 
> > for debug this count would disappear.  
> 
> But still this counter makes sense only for 'drop' action.

Okay, well, "dropped while trap was disabled" seems a lot less useful
of a definition than "number of times this trap would trigger" but if
that's all the HW can provide then it is what it is.

Does the HW also count packets dropped because of overload / overflow
or some other event, or purely dropped because disabled?

Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG

2021-01-29 Thread Matthew Wilcox

On Fri, Jan 29, 2021 at 09:56:48AM -0800, Shoaib Rao wrote:
> On 1/25/21 3:36 PM, Jakub Kicinski wrote:
> > On Fri, 22 Jan 2021 15:06:37 + Matthew Wilcox (Oracle) wrote:
> > > From: Rao Shoaib 
> > > 
> > > TCP sockets allow SIGURG to be sent to the process holding the other
> > > end of the socket.  Extend Unix sockets to have the same ability.
> > > 
> > > The API is the same in that the sender uses sendmsg() with MSG_OOB to
> > > raise SIGURG.  Unix sockets behave in the same way as TCP sockets with
> > > SO_OOBINLINE set.
> > Noob question, if we only want to support the inline mode, why don't we
> > require SO_OOBINLINE to have been called on @other? Wouldn't that
> > provide more consistent behavior across address families?
> > 
> > With the current implementation the receiver will also not see MSG_OOB
> > set in msg->msg_flags, right?
> 
> SO_OOBINLINE does not control the delivery of signal, It controls how
> OOB Byte is delivered. It may not be obvious but this change does not
> deliver any Byte, just a signal. So, as long as sendmsg flag contains
> MSG_OOB, signal will be delivered just like it happens for TCP.

I don't think that's the question Jakub is asking.  As I understand it,
if you send a MSG_OOB on a TCP socket and the receiver calls recvmsg(),
it will see MSG_OOB set, even if SO_OOBINLINE is set.  That wouldn't
happen with Unix sockets.  I'm OK with that difference in behaviour,
because MSG_OOB on Unix sockets _is not_ for sending out of band data.
It's just for sending an urgent signal.

As you say, MSG_OOB does not require data to be sent for unix sockets
(unlike TCP which always requires at least one byte), but one can
choose to send data as part of a message which has MSG_OOB set.  It
won't be tagged in any special way.

To Jakub's other question, we could require SO_OOBINLINE to be set.
That'd provide another layer of insurance against applications being
surprised by a SIGURG they weren't expecting.  I don't know that it's
really worth it though.

One thing I wasn't clear about, and maybe you know, if we send a MSG_OOB,
does this patch cause this part of the tcp(7) manpage to be true for
unix sockets too?

   When out-of-band data is present, select(2) indicates the file descrip‐
   tor as having an exceptional condition and poll (2) indicates a POLLPRI
   event.

[PATCH v8 11/14] spmi: hisi-spmi-controller: move driver from staging

The Hisilicon 6421v600 SPMI driver is ready for mainstream.

So, move it from staging.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../spmi}/hisilicon,hisi-spmi-controller.yaml |  0
 MAINTAINERS   |  7 +++
 drivers/spmi/Kconfig  |  9 +
 drivers/spmi/Makefile |  1 +
 .../{staging/hikey9xx => spmi}/hisi-spmi-controller.c |  0
 drivers/staging/hikey9xx/Kconfig  | 11 ---
 drivers/staging/hikey9xx/Makefile |  1 -
 7 files changed, 17 insertions(+), 12 deletions(-)
 rename {drivers/staging/hikey9xx => 
Documentation/devicetree/bindings/spmi}/hisilicon,hisi-spmi-controller.yaml 
(100%)
 rename drivers/{staging/hikey9xx => spmi}/hisi-spmi-controller.c (100%)

diff --git a/drivers/staging/hikey9xx/hisilicon,hisi-spmi-controller.yaml 
b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
similarity index 100%
rename from drivers/staging/hikey9xx/hisilicon,hisi-spmi-controller.yaml
rename to 
Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
diff --git a/MAINTAINERS b/MAINTAINERS
index fb49e654a1db..406c2340f221 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8078,6 +8078,13 @@ F:   drivers/crypto/hisilicon/sec2/sec_crypto.c
 F: drivers/crypto/hisilicon/sec2/sec_crypto.h
 F: drivers/crypto/hisilicon/sec2/sec_main.c
 
+HISILICON SPMI CONTROLLER DRIVER FOR HIKEY 970
+M: Mauro Carvalho Chehab 
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: 
Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
+F: drivers/spmi/hisi-spmi-controller.c
+
 HISILICON STAGING DRIVERS FOR HIKEY 960/970
 M: Mauro Carvalho Chehab 
 L: de...@driverdev.osuosl.org
diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
index a53bad541f1a..2874b6c26028 100644
--- a/drivers/spmi/Kconfig
+++ b/drivers/spmi/Kconfig
@@ -11,6 +11,15 @@ menuconfig SPMI
 
 if SPMI
 
+config SPMI_HISI3670
+   tristate "Hisilicon 3670 SPMI Controller"
+   select IRQ_DOMAIN_HIERARCHY
+   depends on HAS_IOMEM
+   help
+ If you say yes to this option, support will be included for the
+ built-in SPMI PMIC Arbiter interface on Hisilicon 3670
+ processors.
+
 config SPMI_MSM_PMIC_ARB
tristate "Qualcomm MSM SPMI Controller (PMIC Arbiter)"
select IRQ_DOMAIN_HIERARCHY
diff --git a/drivers/spmi/Makefile b/drivers/spmi/Makefile
index 55a94cadeffe..6e092e6f290c 100644
--- a/drivers/spmi/Makefile
+++ b/drivers/spmi/Makefile
@@ -4,4 +4,5 @@
 #
 obj-$(CONFIG_SPMI) += spmi.o
 
+obj-$(CONFIG_SPMI_HISI3670)+= hisi-spmi-controller.o
 obj-$(CONFIG_SPMI_MSM_PMIC_ARB)+= spmi-pmic-arb.o
diff --git a/drivers/staging/hikey9xx/hisi-spmi-controller.c 
b/drivers/spmi/hisi-spmi-controller.c
similarity index 100%
rename from drivers/staging/hikey9xx/hisi-spmi-controller.c
rename to drivers/spmi/hisi-spmi-controller.c
diff --git a/drivers/staging/hikey9xx/Kconfig b/drivers/staging/hikey9xx/Kconfig
index 88bdf5655d20..49ce28ff55b2 100644
--- a/drivers/staging/hikey9xx/Kconfig
+++ b/drivers/staging/hikey9xx/Kconfig
@@ -1,16 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-# to be placed at drivers/spmi
-config SPMI_HISI3670
-   tristate "Hisilicon 3670 SPMI Controller"
-   select IRQ_DOMAIN_HIERARCHY
-   depends on HAS_IOMEM
-   depends on SPMI
-   help
- If you say yes to this option, support will be included for the
- built-in SPMI PMIC Arbiter interface on Hisilicon 3670
- processors.
-
 # to be placed at drivers/mfd
 config MFD_HI6421_SPMI
tristate "HiSilicon Hi6421v600 SPMI PMU/Codec IC"
diff --git a/drivers/staging/hikey9xx/Makefile 
b/drivers/staging/hikey9xx/Makefile
index 9371dcc3d35b..347880fd378f 100644
--- a/drivers/staging/hikey9xx/Makefile
+++ b/drivers/staging/hikey9xx/Makefile
@@ -1,5 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-$(CONFIG_SPMI_HISI3670)+= hisi-spmi-controller.o
 obj-$(CONFIG_MFD_HI6421_SPMI)  += hi6421-spmi-pmic.o
 obj-$(CONFIG_REGULATOR_HI6421V600) += hi6421v600-regulator.o
-- 
2.29.2

[PATCH v8 13/14] regulator: hi6421v600-regulator: move it from staging

This driver is ready for mainstream. Move it out of staging.

Signed-off-by: Mauro Carvalho Chehab 
---
 MAINTAINERS  |  7 +--
 drivers/regulator/Kconfig|  9 +
 drivers/regulator/Makefile   |  1 +
 .../hikey9xx => regulator}/hi6421v600-regulator.c|  0
 drivers/staging/Kconfig  |  2 --
 drivers/staging/Makefile |  1 -
 drivers/staging/hikey9xx/Kconfig | 12 
 drivers/staging/hikey9xx/Makefile|  3 ---
 drivers/staging/hikey9xx/TODO|  5 -
 9 files changed, 11 insertions(+), 29 deletions(-)
 rename drivers/{staging/hikey9xx => regulator}/hi6421v600-regulator.c (100%)
 delete mode 100644 drivers/staging/hikey9xx/Kconfig
 delete mode 100644 drivers/staging/hikey9xx/Makefile
 delete mode 100644 drivers/staging/hikey9xx/TODO

diff --git a/MAINTAINERS b/MAINTAINERS
index 241f11b7d48a..5c5ad946c5d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8091,12 +8091,7 @@ L:   linux-kernel@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
 F: drivers/mfd/hi6421-spmi-pmic.c
-
-HISILICON STAGING DRIVERS FOR HIKEY 960/970
-M: Mauro Carvalho Chehab 
-L: de...@driverdev.osuosl.org
-S: Maintained
-F: drivers/staging/hikey9xx/
+F: drivers/regulator/hi6421v600-regulator.c
 
 HISILICON TRUE RANDOM NUMBER GENERATOR V2 SUPPORT
 M: Zaibo Xu 
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 5abdd29fb9f3..a520c313a00d 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -423,6 +423,15 @@ config REGULATOR_HI655X
  This driver provides support for the voltage regulators of the
  Hisilicon Hi655x PMIC device.
 
+config REGULATOR_HI6421V600
+   tristate "HiSilicon Hi6421v600 PMIC voltage regulator support"
+   depends on MFD_HI6421_SPMI && OF
+   select REGMAP
+   help
+ This driver provides support for the voltage regulators on
+ HiSilicon Hi6421v600 PMU / Codec IC.
+ This is used on Kirin 3670 boards, like HiKey 970.
+
 config REGULATOR_ISL9305
tristate "Intersil ISL9305 regulator"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 680e539f6579..77e519d2bc68 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_REGULATOR_FAN53880) += fan53880.o
 obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
 obj-$(CONFIG_REGULATOR_HI6421) += hi6421-regulator.o
 obj-$(CONFIG_REGULATOR_HI6421V530) += hi6421v530-regulator.o
+obj-$(CONFIG_REGULATOR_HI6421V600) += hi6421v600-regulator.o
 obj-$(CONFIG_REGULATOR_HI655X) += hi655x-regulator.o
 obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
 obj-$(CONFIG_REGULATOR_ISL9305) += isl9305.o
diff --git a/drivers/staging/hikey9xx/hi6421v600-regulator.c 
b/drivers/regulator/hi6421v600-regulator.c
similarity index 100%
rename from drivers/staging/hikey9xx/hi6421v600-regulator.c
rename to drivers/regulator/hi6421v600-regulator.c
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index b22f73d7bfc4..db7ec218644f 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -112,6 +112,4 @@ source "drivers/staging/wimax/Kconfig"
 
 source "drivers/staging/wfx/Kconfig"
 
-source "drivers/staging/hikey9xx/Kconfig"
-
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 2245059e69c7..7b0ef538dcce 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -46,4 +46,3 @@ obj-$(CONFIG_KPC2000) += kpc2000/
 obj-$(CONFIG_QLGE) += qlge/
 obj-$(CONFIG_WIMAX)+= wimax/
 obj-$(CONFIG_WFX)  += wfx/
-obj-y  += hikey9xx/
diff --git a/drivers/staging/hikey9xx/Kconfig b/drivers/staging/hikey9xx/Kconfig
deleted file mode 100644
index b17c047aa700..
--- a/drivers/staging/hikey9xx/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-
-# to be placed at drivers/regulator
-config REGULATOR_HI6421V600
-   tristate "HiSilicon Hi6421v600 PMIC voltage regulator support"
-   depends on MFD_HI6421_SPMI && OF
-   depends on REGULATOR
-   select REGMAP
-   help
- This driver provides support for the voltage regulators on
- HiSilicon Hi6421v600 PMU / Codec IC.
- This is used on Kirin 3670 boards, like HiKey 970.
diff --git a/drivers/staging/hikey9xx/Makefile 
b/drivers/staging/hikey9xx/Makefile
deleted file mode 100644
index 4d63184e6086..
--- a/drivers/staging/hikey9xx/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-
-obj-$(CONFIG_REGULATOR_HI6421V600) += hi6421v600-regulator.o
diff --git a/drivers/staging/hikey9xx/TODO b/drivers/staging/hikey9xx/TODO

[PATCH v8 10/14] phy: phy-hi3670-usb3: move driver from staging into phy

The phy USB3 driver for Hisilicon 970 (hi3670) is ready
for mainstream. Mode it from staging into the main driver's
phy/ directory.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../bindings/phy/hisilicon,hi3670-usb3.yaml   |  0
 MAINTAINERS   |  9 -
 drivers/phy/hisilicon/Kconfig | 10 ++
 drivers/phy/hisilicon/Makefile|  1 +
 .../hikey9xx => phy/hisilicon}/phy-hi3670-usb3.c  |  0
 drivers/staging/hikey9xx/Kconfig  | 11 ---
 drivers/staging/hikey9xx/Makefile |  2 --
 7 files changed, 19 insertions(+), 14 deletions(-)
 rename drivers/staging/hikey9xx/phy-hi3670-usb3.yaml => 
Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml (100%)
 rename drivers/{staging/hikey9xx => phy/hisilicon}/phy-hi3670-usb3.c (100%)

diff --git a/drivers/staging/hikey9xx/phy-hi3670-usb3.yaml 
b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml
similarity index 100%
rename from drivers/staging/hikey9xx/phy-hi3670-usb3.yaml
rename to Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml
diff --git a/MAINTAINERS b/MAINTAINERS
index 992fe3b0900a..fb49e654a1db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18371,7 +18371,7 @@ L:  linux-...@vger.kernel.org
 S: Maintained
 F: drivers/usb/roles/intel-xhci-usb-role-switch.c
 
-USB IP DRIVER FOR HISILICON KIRIN
+USB IP DRIVER FOR HISILICON KIRIN 960
 M: Yu Chen 
 M: Binghui Wang 
 L: linux-...@vger.kernel.org
@@ -18379,6 +18379,13 @@ S: Maintained
 F: Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml
 F: drivers/phy/hisilicon/phy-hi3660-usb3.c
 
+USB IP DRIVER FOR HISILICON KIRIN 970
+M: Mauro Carvalho Chehab 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/phy/hisilicon,kirin970-usb3.yaml
+F: drivers/phy/hisilicon/phy-kirin970-usb3.c
+
 USB ISP116X DRIVER
 M: Olav Kongas 
 L: linux-...@vger.kernel.org
diff --git a/drivers/phy/hisilicon/Kconfig b/drivers/phy/hisilicon/Kconfig
index 1c73053bcc98..4d008cfc279c 100644
--- a/drivers/phy/hisilicon/Kconfig
+++ b/drivers/phy/hisilicon/Kconfig
@@ -23,6 +23,16 @@ config PHY_HI3660_USB
 
  To compile this driver as a module, choose M here.
 
+config PHY_HI3670_USB
+   tristate "hi3670 USB PHY support"
+   depends on (ARCH_HISI && ARM64) || COMPILE_TEST
+   select GENERIC_PHY
+   select MFD_SYSCON
+   help
+ Enable this to support the HISILICON HI3670 USB PHY.
+
+ To compile this driver as a module, choose M here.
+
 config PHY_HISTB_COMBPHY
tristate "HiSilicon STB SoCs COMBPHY support"
depends on (ARCH_HISI && ARM64) || COMPILE_TEST
diff --git a/drivers/phy/hisilicon/Makefile b/drivers/phy/hisilicon/Makefile
index 92e874ae9c74..51729868145b 100644
--- a/drivers/phy/hisilicon/Makefile
+++ b/drivers/phy/hisilicon/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_PHY_HI6220_USB)   += phy-hi6220-usb.o
 obj-$(CONFIG_PHY_HI3660_USB)   += phy-hi3660-usb3.o
+obj-$(CONFIG_PHY_HI3670_USB)   += phy-hi3670-usb3.o
 obj-$(CONFIG_PHY_HISTB_COMBPHY)+= phy-histb-combphy.o
 obj-$(CONFIG_PHY_HISI_INNO_USB2)   += phy-hisi-inno-usb2.o
 obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
diff --git a/drivers/staging/hikey9xx/phy-hi3670-usb3.c 
b/drivers/phy/hisilicon/phy-hi3670-usb3.c
similarity index 100%
rename from drivers/staging/hikey9xx/phy-hi3670-usb3.c
rename to drivers/phy/hisilicon/phy-hi3670-usb3.c
diff --git a/drivers/staging/hikey9xx/Kconfig b/drivers/staging/hikey9xx/Kconfig
index 82bb4a22b286..88bdf5655d20 100644
--- a/drivers/staging/hikey9xx/Kconfig
+++ b/drivers/staging/hikey9xx/Kconfig
@@ -1,16 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-# to be placed at drivers/phy
-config PHY_HI3670_USB
-   tristate "hi3670 USB PHY support"
-   depends on (ARCH_HISI && ARM64) || COMPILE_TEST
-   select GENERIC_PHY
-   select MFD_SYSCON
-   help
- Enable this to support the HISILICON HI3670 USB PHY.
-
- To compile this driver as a module, choose M here.
-
 # to be placed at drivers/spmi
 config SPMI_HISI3670
tristate "Hisilicon 3670 SPMI Controller"
diff --git a/drivers/staging/hikey9xx/Makefile 
b/drivers/staging/hikey9xx/Makefile
index 1924fadac952..9371dcc3d35b 100644
--- a/drivers/staging/hikey9xx/Makefile
+++ b/drivers/staging/hikey9xx/Makefile
@@ -1,7 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-$(CONFIG_PHY_HI3670_USB)   += phy-hi3670-usb3.o
-
 obj-$(CONFIG_SPMI_HISI3670)+= hisi-spmi-controller.o
 obj-$(CONFIG_MFD_HI6421_SPMI)  += hi6421-spmi-pmic.o
 obj-$(CONFIG_REGULATOR_HI6421V600) += hi6421v600-regulator.o
-- 
2.29.2

[PATCH net-next v1 0/6] lan743x speed boost

2021-01-29 Thread Sven Van Asbroeck

From: Sven Van Asbroeck 

The first patch of this series boosts the chip's rx performance by up to 3x
on cpus such as ARM. However it introduces a breaking change: the mtu
can no longer be changed while the network interface is up.

To get around this efficiently, the second patch adds driver support for
multi-buffer frames. This will allow us to change the mtu while the device
is up, without having to re-allocate all ring buffers.

Since this is an important change to the driver's rx logic, I have attempted
to very carefully test this. Test descriptions are included with each
commit message.

I invite all interested users of the lan743x to test out these changes, either
by testing them out "in the real world", or by repeating my artificial tests.

Suggestions for better tests are very welcome.

Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git # 
46eb3c108fe1

To: Bryan Whitehead 
To: unglinuxdri...@microchip.com
To: "David S. Miller" 
To: Jakub Kicinski 
Cc: Andrew Lunn 
Cc: Alexey Denisov 
Cc: Sergej Bauer 
Cc: Tim Harvey 
Cc: Anders Rønningen 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org (open list)

Sven Van Asbroeck (6):
  lan743x: boost performance on cpu archs w/o dma cache snooping
  lan743x: support rx multi-buffer packets
  lan743x: allow mtu change while network interface is up
  TEST ONLY: lan743x: limit rx ring buffer size to 500 bytes
  TEST ONLY: lan743x: skb_alloc failure test
  TEST ONLY: lan743x: skb_trim failure test

 drivers/net/ethernet/microchip/lan743x_main.c | 324 --
 drivers/net/ethernet/microchip/lan743x_main.h |   2 +
 2 files changed, 152 insertions(+), 174 deletions(-)

-- 
2.17.1

[PATCH v8 03/14] staging: hikey9xx: hi6421-spmi-pmic: rename some vars

- When referring to regmap, rename map to regmap
- inside hi6421-spmi-pmic, call private data struct as
  ddata.

No functional changes.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/hikey9xx/hi6421-spmi-pmic.c   | 104 +-
 .../staging/hikey9xx/hi6421v600-regulator.c   |  10 +-
 include/linux/mfd/hi6421-spmi-pmic.h  |   2 +-
 3 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c 
b/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
index 3d612bd46231..a4ffeb06ed6a 100644
--- a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
+++ b/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
@@ -43,17 +43,17 @@ static const struct mfd_cell hi6421v600_devs[] = {
 
 static irqreturn_t hi6421_spmi_irq_handler(int irq, void *priv)
 {
-   struct hi6421_spmi_pmic *pmic = (struct hi6421_spmi_pmic *)priv;
+   struct hi6421_spmi_pmic *ddata = (struct hi6421_spmi_pmic *)priv;
unsigned long pending;
unsigned int data;
int i, offset;
 
for (i = 0; i < HISI_IRQ_ARRAY; i++) {
-   regmap_read(pmic->map, offset, );
+   regmap_read(ddata->regmap, offset, );
data &= HISI_MASK_FIELD;
if (data != 0)
pr_debug("data[%d]=0x%d\n\r", i, data);
-   regmap_write(pmic->map, i + SOC_PMIC_IRQ0_ADDR, data);
+   regmap_write(ddata->regmap, i + SOC_PMIC_IRQ0_ADDR, data);
 
/* for_each_set_bit() macro requires unsigned long */
pending = data;
@@ -61,14 +61,14 @@ static irqreturn_t hi6421_spmi_irq_handler(int irq, void 
*priv)
/* solve powerkey order */
if ((i == HISI_IRQ_KEY_NUM) &&
((pending & HISI_IRQ_KEY_VALUE) == HISI_IRQ_KEY_VALUE)) {
-   generic_handle_irq(pmic->irqs[HISI_IRQ_KEY_DOWN]);
-   generic_handle_irq(pmic->irqs[HISI_IRQ_KEY_UP]);
+   generic_handle_irq(ddata->irqs[HISI_IRQ_KEY_DOWN]);
+   generic_handle_irq(ddata->irqs[HISI_IRQ_KEY_UP]);
pending &= (~HISI_IRQ_KEY_VALUE);
}
 
if (pending) {
for_each_set_bit(offset, , HISI_BITS)
-   generic_handle_irq(pmic->irqs[offset + i * 
HISI_BITS]);
+   generic_handle_irq(ddata->irqs[offset + i * 
HISI_BITS]);
}
}
 
@@ -77,7 +77,7 @@ static irqreturn_t hi6421_spmi_irq_handler(int irq, void 
*priv)
 
 static void hi6421_spmi_irq_mask(struct irq_data *d)
 {
-   struct hi6421_spmi_pmic *pmic = irq_data_get_irq_chip_data(d);
+   struct hi6421_spmi_pmic *ddata = irq_data_get_irq_chip_data(d);
unsigned long flags;
unsigned int data;
u32 offset;
@@ -85,28 +85,28 @@ static void hi6421_spmi_irq_mask(struct irq_data *d)
offset = (irqd_to_hwirq(d) >> 3);
offset += SOC_PMIC_IRQ_MASK_0_ADDR;
 
-   spin_lock_irqsave(>lock, flags);
+   spin_lock_irqsave(>lock, flags);
 
-   regmap_read(pmic->map, offset, );
+   regmap_read(ddata->regmap, offset, );
data |= (1 << (irqd_to_hwirq(d) & 0x07));
-   regmap_write(pmic->map, offset, data);
-   spin_unlock_irqrestore(>lock, flags);
+   regmap_write(ddata->regmap, offset, data);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static void hi6421_spmi_irq_unmask(struct irq_data *d)
 {
-   struct hi6421_spmi_pmic *pmic = irq_data_get_irq_chip_data(d);
+   struct hi6421_spmi_pmic *ddata = irq_data_get_irq_chip_data(d);
u32 data, offset;
unsigned long flags;
 
offset = (irqd_to_hwirq(d) >> 3);
offset += SOC_PMIC_IRQ_MASK_0_ADDR;
 
-   spin_lock_irqsave(>lock, flags);
-   regmap_read(pmic->map, offset, );
+   spin_lock_irqsave(>lock, flags);
+   regmap_read(ddata->regmap, offset, );
data &= ~(1 << (irqd_to_hwirq(d) & 0x07));
-   regmap_write(pmic->map, offset, data);
-   spin_unlock_irqrestore(>lock, flags);
+   regmap_write(ddata->regmap, offset, data);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static struct irq_chip hi6421_spmi_pmu_irqchip = {
@@ -120,11 +120,11 @@ static struct irq_chip hi6421_spmi_pmu_irqchip = {
 static int hi6421_spmi_irq_map(struct irq_domain *d, unsigned int virq,
   irq_hw_number_t hw)
 {
-   struct hi6421_spmi_pmic *pmic = d->host_data;
+   struct hi6421_spmi_pmic *ddata = d->host_data;
 
irq_set_chip_and_handler_name(virq, _spmi_pmu_irqchip,
  handle_simple_irq, "hisi");
-   irq_set_chip_data(virq, pmic);
+   irq_set_chip_data(virq, ddata);
irq_set_irq_type(virq, IRQ_TYPE_NONE);
 
return 0;
@@ -135,21 +135,21 @@ static const struct irq_domain_ops hi6421_spmi_domain_ops 
= {
.xlate  = irq_domain_xlate_twocell,
 };
 
-static void

[PATCH v8 09/14] staging: hikey9xx: hi6421-spmi-pmic: update copyright notes

At PMIC subsystem, C89 comments are preferred over C99.
While here, also update the copyrights of the header file.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 14 +++---
 include/linux/mfd/hi6421-spmi-pmic.h|  1 +
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c 
b/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
index 9c10f7c4e7c9..2301f4fcd48d 100644
--- a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
+++ b/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
@@ -1,11 +1,11 @@
 // SPDX-License-Identifier: GPL-2.0
-//
-// Device driver for regulators in HISI PMIC IC
-//
-// Copyright (c) 2013 Linaro Ltd.
-// Copyright (c) 2011 Hisilicon.
-//
-// Copyright (c) 2020-2021 Huawei Technologies Co., Ltd
+/*
+ * Device driver for regulators in HISI PMIC IC
+ *
+ * Copyright (c) 2013 Linaro Ltd.
+ * Copyright (c) 2011 Hisilicon.
+ * Copyright (c) 2020-2021 Huawei Technologies Co., Ltd
+ */
 
 #include 
 #include 
diff --git a/include/linux/mfd/hi6421-spmi-pmic.h 
b/include/linux/mfd/hi6421-spmi-pmic.h
index 4d61cb266a18..2660226138b8 100644
--- a/include/linux/mfd/hi6421-spmi-pmic.h
+++ b/include/linux/mfd/hi6421-spmi-pmic.h
@@ -4,6 +4,7 @@
  *
  * Copyright (c) 2013 Linaro Ltd.
  * Copyright (C) 2011 Hisilicon.
+ * Copyright (c) 2020-2021 Huawei Technologies Co., Ltd
  *
  * Guodong Xu 
  */
-- 
2.29.2

[PATCH v8 00/14] Move Hisilicon 6421v600 SPMI and USB drivers out of staging

Hi Greg/Mark/Lee/Vinod,

Another rebase , also the top of staging-testing.

This series contain the remaining patches for USB to start working,
except for a final DTS patch.

Patches 1 and 2 convert the SPMI and regulator
drivers to use regmap and simplifies the logic by using
regmap helpers.

Patches 3 to 9 address some issues pointed by Lee at the MFD driver.

I guess the best would be if Greg could apply patches 1 to 9
via the staging tree.

Patches 10 to 13 move the drivers and their corresponding
DT documentation bindings out of staging.

Patch 14 contains the DT which describes the regulator,
SPMI controller and MFD.

I'll submit the final patch with USB bindings after having
everything set (e.g. after 5.12-rc1).

-

v8: contains a fix for REGMAP dependencies and for a build breakage.

Mauro Carvalho Chehab (14):
  staging: hikey9xx: spmi driver: convert to regmap
  staging: hikey9xx: hi6421v600-regulator: use some regmap helpers
  staging: hikey9xx: hi6421-spmi-pmic: rename some vars
  staging: hikey9xx: hi6421-spmi-pmic: cleanup probe code
  staging: hikey9xx: hi6421-spmi-pmic: cleanup header file
  staging: hikey9xx: hi6421-spmi-pmic: fix IRQ handler code
  staging: hikey9xx: hi6421-spmi-pmic: cleanup IRQ handling code
  staging: hikey9xx: hi6421-spmi-pmic: document registers
  staging: hikey9xx: hi6421-spmi-pmic: update copyright notes
  phy: phy-hi3670-usb3: move driver from staging into phy
  spmi: hisi-spmi-controller: move driver from staging
  mfd: hi6421-spmi-pmic: move driver from staging
  regulator: hi6421v600-regulator: move it from staging
  dts: hisilicon: add support for the PMIC found on Hikey 970

 .../mfd}/hisilicon,hi6421-spmi-pmic.yaml  |   0
 .../bindings/phy/hisilicon,hi3670-usb3.yaml   |   0
 .../spmi}/hisilicon,hisi-spmi-controller.yaml |   0
 MAINTAINERS   |  24 +-
 .../boot/dts/hisilicon/hi3670-hikey970.dts|  22 +-
 .../boot/dts/hisilicon/hikey970-pmic.dtsi |  87 +
 drivers/mfd/Kconfig   |  16 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/hi6421-spmi-pmic.c| 297 
 drivers/phy/hisilicon/Kconfig |  10 +
 drivers/phy/hisilicon/Makefile|   1 +
 .../hisilicon}/phy-hi3670-usb3.c  |   0
 drivers/regulator/Kconfig |   9 +
 drivers/regulator/Makefile|   1 +
 .../hi6421v600-regulator.c|  63 +---
 drivers/spmi/Kconfig  |   9 +
 drivers/spmi/Makefile |   1 +
 .../hikey9xx => spmi}/hisi-spmi-controller.c  |   0
 drivers/staging/Kconfig   |   2 -
 drivers/staging/Makefile  |   1 -
 drivers/staging/hikey9xx/Kconfig  |  50 ---
 drivers/staging/hikey9xx/Makefile |   7 -
 drivers/staging/hikey9xx/TODO |   5 -
 drivers/staging/hikey9xx/hi6421-spmi-pmic.c   | 326 --
 include/linux/mfd/hi6421-spmi-pmic.h  |  28 +-
 25 files changed, 471 insertions(+), 489 deletions(-)
 rename {drivers/staging/hikey9xx => 
Documentation/devicetree/bindings/mfd}/hisilicon,hi6421-spmi-pmic.yaml (100%)
 rename drivers/staging/hikey9xx/phy-hi3670-usb3.yaml => 
Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml (100%)
 rename {drivers/staging/hikey9xx => 
Documentation/devicetree/bindings/spmi}/hisilicon,hisi-spmi-controller.yaml 
(100%)
 create mode 100644 arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi
 create mode 100644 drivers/mfd/hi6421-spmi-pmic.c
 rename drivers/{staging/hikey9xx => phy/hisilicon}/phy-hi3670-usb3.c (100%)
 rename drivers/{staging/hikey9xx => regulator}/hi6421v600-regulator.c (81%)
 rename drivers/{staging/hikey9xx => spmi}/hisi-spmi-controller.c (100%)
 delete mode 100644 drivers/staging/hikey9xx/Kconfig
 delete mode 100644 drivers/staging/hikey9xx/Makefile
 delete mode 100644 drivers/staging/hikey9xx/TODO
 delete mode 100644 drivers/staging/hikey9xx/hi6421-spmi-pmic.c

-- 
2.29.2

[PATCH v8 01/14] staging: hikey9xx: spmi driver: convert to regmap

Instead of doing its own SPMI I/O implementation, use the
already-existing regmap one.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/hikey9xx/Kconfig  |   2 +
 drivers/staging/hikey9xx/hi6421-spmi-pmic.c   | 115 ++
 .../staging/hikey9xx/hi6421v600-regulator.c   |  26 ++--
 include/linux/mfd/hi6421-spmi-pmic.h  |   7 +-
 4 files changed, 54 insertions(+), 96 deletions(-)

diff --git a/drivers/staging/hikey9xx/Kconfig b/drivers/staging/hikey9xx/Kconfig
index 2e48ded92a7e..82bb4a22b286 100644
--- a/drivers/staging/hikey9xx/Kconfig
+++ b/drivers/staging/hikey9xx/Kconfig
@@ -29,6 +29,7 @@ config MFD_HI6421_SPMI
depends on OF
depends on SPMI
select MFD_CORE
+   select REGMAP_SPMI
help
  Add support for HiSilicon Hi6421v600 SPMI PMIC. Hi6421 includes
  multi-functions, such as regulators, RTC, codec, Coulomb counter,
@@ -44,6 +45,7 @@ config REGULATOR_HI6421V600
tristate "HiSilicon Hi6421v600 PMIC voltage regulator support"
depends on MFD_HI6421_SPMI && OF
depends on REGULATOR
+   select REGMAP
help
  This driver provides support for the voltage regulators on
  HiSilicon Hi6421v600 PMU / Codec IC.
diff --git a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c 
b/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
index 69570876f93e..3d612bd46231 100644
--- a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
+++ b/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
@@ -41,81 +41,22 @@ static const struct mfd_cell hi6421v600_devs[] = {
{ .name = "hi6421v600-regulator", },
 };
 
-/*
- * The PMIC register is only 8-bit.
- * Hisilicon SoC use hardware to map PMIC register into SoC mapping.
- * At here, we are accessing SoC register with 32-bit.
- */
-int hi6421_spmi_pmic_read(struct hi6421_spmi_pmic *pmic, int reg)
+static irqreturn_t hi6421_spmi_irq_handler(int irq, void *priv)
 {
-   struct spmi_device *pdev;
-   u8 read_value = 0;
-   u32 ret;
-
-   pdev = to_spmi_device(pmic->dev);
-   if (!pdev) {
-   pr_err("%s: pdev get failed!\n", __func__);
-   return -ENODEV;
-   }
-
-   ret = spmi_ext_register_readl(pdev, reg, _value, 1);
-   if (ret) {
-   pr_err("%s: spmi_ext_register_readl failed!\n", __func__);
-   return ret;
-   }
-   return read_value;
-}
-EXPORT_SYMBOL(hi6421_spmi_pmic_read);
-
-int hi6421_spmi_pmic_write(struct hi6421_spmi_pmic *pmic, int reg, u32 val)
-{
-   struct spmi_device *pdev;
-   u32 ret;
-
-   pdev = to_spmi_device(pmic->dev);
-   if (!pdev) {
-   pr_err("%s: pdev get failed!\n", __func__);
-   return -ENODEV;
-   }
-
-   ret = spmi_ext_register_writel(pdev, reg, (unsigned char *), 1);
-   if (ret)
-   pr_err("%s: spmi_ext_register_writel failed!\n", __func__);
-
-   return ret;
-}
-EXPORT_SYMBOL(hi6421_spmi_pmic_write);
-
-int hi6421_spmi_pmic_rmw(struct hi6421_spmi_pmic *pmic, int reg,
-u32 mask, u32 bits)
-{
-   unsigned long flags;
-   u32 data;
-   int ret;
-
-   spin_lock_irqsave(>lock, flags);
-   data = hi6421_spmi_pmic_read(pmic, reg) & ~mask;
-   data |= mask & bits;
-   ret = hi6421_spmi_pmic_write(pmic, reg, data);
-   spin_unlock_irqrestore(>lock, flags);
-
-   return ret;
-}
-EXPORT_SYMBOL(hi6421_spmi_pmic_rmw);
-
-static irqreturn_t hi6421_spmi_irq_handler(int irq, void *data)
-{
-   struct hi6421_spmi_pmic *pmic = (struct hi6421_spmi_pmic *)data;
+   struct hi6421_spmi_pmic *pmic = (struct hi6421_spmi_pmic *)priv;
unsigned long pending;
+   unsigned int data;
int i, offset;
 
for (i = 0; i < HISI_IRQ_ARRAY; i++) {
-   pending = hi6421_spmi_pmic_read(pmic, (i + SOC_PMIC_IRQ0_ADDR));
-   pending &= HISI_MASK_FIELD;
-   if (pending != 0)
-   pr_debug("pending[%d]=0x%lx\n\r", i, pending);
+   regmap_read(pmic->map, offset, );
+   data &= HISI_MASK_FIELD;
+   if (data != 0)
+   pr_debug("data[%d]=0x%d\n\r", i, data);
+   regmap_write(pmic->map, i + SOC_PMIC_IRQ0_ADDR, data);
 
-   hi6421_spmi_pmic_write(pmic, (i + SOC_PMIC_IRQ0_ADDR), pending);
+   /* for_each_set_bit() macro requires unsigned long */
+   pending = data;
 
/* solve powerkey order */
if ((i == HISI_IRQ_KEY_NUM) &&
@@ -137,16 +78,18 @@ static irqreturn_t hi6421_spmi_irq_handler(int irq, void 
*data)
 static void hi6421_spmi_irq_mask(struct irq_data *d)
 {
struct hi6421_spmi_pmic *pmic = irq_data_get_irq_chip_data(d);
-   u32 data, offset;
unsigned long flags;
+   unsigned int data;
+   u32 offset;
 
offset = (irqd_to_hwirq(d) >> 3);
offset += SOC_PMIC_IRQ_MASK_0_ADDR;
 
spin_lock_irqsave(>lock,

Re: [PATCH] net: mdiobus: Prevent spike on MDIO bus reset signal

2021-01-29 Thread Andrew Lunn

On Thu, Jan 28, 2021 at 09:45:41AM +0100, Mike Looijmans wrote:
> Hi Andrew,
> 
> Response below...

Hi Mike

Everybody here knows that top posting is evil, we don't do it. We
expect the replay to be inline.

> > Hi Mike
> > 
> > Did you look at the per PHY reset? mdiobus_register_gpiod() gets the
> > GPIO with GPIOD_OUT_LOW. mdiobus_register_device() then immediately
> > sets it high.
> > 
> > So it looks like it suffers from the same problem.
> 
> Well, now that I have your attention...
> 
> The per PHY reset was more broken

It has history. It was designed to be used for PHYs which needed a
reset after the clock was changed. It assumed the PHY would probe,
which some do when held in reset.

But the GPIO is not the only problem. Some PHYs need a regulator
enabled, some need a clock enabled. The core has no idea what order to
do this in. It should be the PHY driver that does this, since it
should have knowledge of the PHY, and can do things in the correct
order. But if the PHY does not respond, it is not discovered, and so
the driver does not load. If that case, you can put the PHY ID into
the compatible string, and the core will load the correct driver and
probe it, allow it to turn on whatever it needs.

This has been discussed a few times and this is what we decided on.
Maybe we need to improve the documentation.

  Andrew

[PATCH net-next 8/9] net: ipa: expand last transaction check

2021-01-29 Thread Alex Elder

Transactions to send data for a network device can be allocated at
any time up until the point the TX queue is stopped.  It is possible
for ipa_start_xmit() to be called in one context just before a
the transmit queue is stopped in another.

Update gsi_channel_trans_last() so that for TX channels the
allocated and pending transaction lists are checked--in addition
to the completed and polled lists--to determine the "last"
transaction.  This means any transaction that has been allocated
before the TX queue is stopped will be allowed to complete before
we conclude the channel is quiesced.

Rework the function a bit to use a list pointer and gotos.

Signed-off-by: Alex Elder 
---
 drivers/net/ipa/gsi.c | 34 +-
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
index 74d1dd04ad6e9..217ca21bfe043 100644
--- a/drivers/net/ipa/gsi.c
+++ b/drivers/net/ipa/gsi.c
@@ -725,22 +725,38 @@ static void gsi_evt_ring_program(struct gsi *gsi, u32 
evt_ring_id)
gsi_evt_ring_doorbell(gsi, evt_ring_id, 0);
 }
 
-/* Return the last (most recent) transaction completed on a channel. */
+/* Find the transaction whose completion indicates a channel is quiesced */
 static struct gsi_trans *gsi_channel_trans_last(struct gsi_channel *channel)
 {
struct gsi_trans_info *trans_info = >trans_info;
+   const struct list_head *list;
struct gsi_trans *trans;
 
spin_lock_bh(_info->spinlock);
 
-   if (!list_empty(_info->complete))
-   trans = list_last_entry(_info->complete,
-   struct gsi_trans, links);
-   else if (!list_empty(_info->polled))
-   trans = list_last_entry(_info->polled,
-   struct gsi_trans, links);
-   else
-   trans = NULL;
+   /* There is a small chance a TX transaction got allocated just
+* before we disabled transmits, so check for that.
+*/
+   if (channel->toward_ipa) {
+   list = _info->alloc;
+   if (!list_empty(list))
+   goto done;
+   list = _info->pending;
+   if (!list_empty(list))
+   goto done;
+   }
+
+   /* Otherwise (TX or RX) we want to wait for anything that
+* has completed, or has been polled but not released yet.
+*/
+   list = _info->complete;
+   if (!list_empty(list))
+   goto done;
+   list = _info->polled;
+   if (list_empty(list))
+   list = NULL;
+done:
+   trans = list ? list_last_entry(list, struct gsi_trans, links) : NULL;
 
/* Caller will wait for this, so take a reference */
if (trans)
-- 
2.27.0

[PATCH 6/6] lib: add fast path for find_first_*_bit() and find_last_bit()

2021-01-29 Thread Yury Norov

Similarly to bitmap functions, users will benefit if we'll handle
a case of small-size bitmaps that fit into a single word.

While here, move the find_last_bit() declaration to bitops/find.h
where other find_*_bit() functions sit.

Signed-off-by: Yury Norov 
---
 include/asm-generic/bitops/find.h   | 50 +++--
 include/linux/bitops.h  | 12 --
 lib/find_bit.c  | 12 +++---
 tools/include/asm-generic/bitops/find.h | 28 --
 tools/lib/find_bit.c|  4 +-
 5 files changed, 79 insertions(+), 27 deletions(-)

diff --git a/include/asm-generic/bitops/find.h 
b/include/asm-generic/bitops/find.h
index 8bd7a33a889d..132dfb2da765 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -5,6 +5,9 @@
 extern unsigned long _find_next_bit(const unsigned long *addr1,
const unsigned long *addr2, unsigned long nbits,
unsigned long start, unsigned long invert, unsigned long le);
+extern unsigned long _find_first_bit(const unsigned long *addr, unsigned long 
size);
+extern unsigned long _find_first_zero_bit(const unsigned long *addr, unsigned 
long size);
+extern unsigned long _find_last_bit(const unsigned long *addr, unsigned long 
size);
 
 #ifndef find_next_bit
 /**
@@ -102,8 +105,17 @@ unsigned long find_next_zero_bit(const unsigned long 
*addr, unsigned long size,
  * Returns the bit number of the first set bit.
  * If no bits are set, returns @size.
  */
-extern unsigned long find_first_bit(const unsigned long *addr,
-   unsigned long size);
+static inline
+unsigned long find_first_bit(const unsigned long *addr, unsigned long size)
+{
+   if (SMALL_CONST(size - 1)) {
+   unsigned long val = *addr & BITS_FIRST_MASK(size - 1);
+
+   return val ? __ffs(val) : size;
+   }
+
+   return _find_first_bit(addr, size);
+}
 
 /**
  * find_first_zero_bit - find the first cleared bit in a memory region
@@ -113,8 +125,17 @@ extern unsigned long find_first_bit(const unsigned long 
*addr,
  * Returns the bit number of the first cleared bit.
  * If no bits are zero, returns @size.
  */
-extern unsigned long find_first_zero_bit(const unsigned long *addr,
-unsigned long size);
+static inline
+unsigned long find_first_zero_bit(const unsigned long *addr, unsigned long 
size)
+{
+   if (SMALL_CONST(size - 1)) {
+   unsigned long val = *addr | ~BITS_FIRST_MASK(size - 1);
+
+   return val == ~0UL ? size : ffz(val);
+   }
+
+   return _find_first_zero_bit(addr, size);
+}
 #else /* CONFIG_GENERIC_FIND_FIRST_BIT */
 
 #ifndef find_first_bit
@@ -126,6 +147,27 @@ extern unsigned long find_first_zero_bit(const unsigned 
long *addr,
 
 #endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
 
+#ifndef find_last_bit
+/**
+ * find_last_bit - find the last set bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The number of bits to search
+ *
+ * Returns the bit number of the last set bit, or size.
+ */
+static inline
+unsigned long find_last_bit(const unsigned long *addr, unsigned long size)
+{
+   if (SMALL_CONST(size - 1)) {
+   unsigned long val = *addr & BITS_FIRST_MASK(size - 1);
+
+   return val ? __fls(val) : size;
+   }
+
+   return _find_last_bit(addr, size);
+}
+#endif
+
 /**
  * find_next_clump8 - find next 8-bit clump with set bits in a memory region
  * @clump: location to store copy of found clump
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index a5a48303b0f1..26bf15e6cd35 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -286,17 +286,5 @@ static __always_inline void __assign_bit(long nr, volatile 
unsigned long *addr,
 })
 #endif
 
-#ifndef find_last_bit
-/**
- * find_last_bit - find the last set bit in a memory region
- * @addr: The address to start the search at
- * @size: The number of bits to search
- *
- * Returns the bit number of the last set bit, or size.
- */
-extern unsigned long find_last_bit(const unsigned long *addr,
-  unsigned long size);
-#endif
-
 #endif /* __KERNEL__ */
 #endif
diff --git a/lib/find_bit.c b/lib/find_bit.c
index 2470ae390f3c..e2c301d28568 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -75,7 +75,7 @@ EXPORT_SYMBOL(_find_next_bit);
 /*
  * Find the first set bit in a memory region.
  */
-unsigned long find_first_bit(const unsigned long *addr, unsigned long size)
+unsigned long _find_first_bit(const unsigned long *addr, unsigned long size)
 {
unsigned long idx;
 
@@ -86,14 +86,14 @@ unsigned long find_first_bit(const unsigned long *addr, 
unsigned long size)
 
return size;
 }
-EXPORT_SYMBOL(find_first_bit);
+EXPORT_SYMBOL(_find_first_bit);
 #endif
 
 #ifndef find_first_zero_bit
 /*
  * Find the first cleared bit in a memory region.
  */
-unsigned long

Re: [RFC][PATCH 05/13] mm/numa: automatically generate node migration order

2021-01-29 Thread Yang Shi

On Mon, Jan 25, 2021 at 4:41 PM Dave Hansen  wrote:
>
>
> From: Dave Hansen 
>
> When memory fills up on a node, memory contents can be
> automatically migrated to another node.  The biggest problems are
> knowing when to migrate and to where the migration should be
> targeted.
>
> The most straightforward way to generate the "to where" list
> would be to follow the page allocator fallback lists.  Those
> lists already tell us if memory is full where to look next.  It
> would also be logical to move memory in that order.
>
> But, the allocator fallback lists have a fatal flaw: most nodes
> appear in all the lists.  This would potentially lead to
> migration cycles (A->B, B->A, A->B, ...).
>
> Instead of using the allocator fallback lists directly, keep a
> separate node migration ordering.  But, reuse the same data used
> to generate page allocator fallback in the first place:
> find_next_best_node().
>
> This means that the firmware data used to populate node distances
> essentially dictates the ordering for now.  It should also be
> architecture-neutral since all NUMA architectures have a working
> find_next_best_node().
>
> The protocol for node_demotion[] access and writing is not
> standard.  It has no specific locking and is intended to be read
> locklessly.  Readers must take care to avoid observing changes
> that appear incoherent.  This was done so that node_demotion[]
> locking has no chance of becoming a bottleneck on large systems
> with lots of CPUs in direct reclaim.
>
> This code is unused for now.  It will be called later in the
> series.
>
> Signed-off-by: Dave Hansen 
> Cc: Yang Shi 
> Cc: David Rientjes 
> Cc: Huang Ying 
> Cc: Dan Williams 
> Cc: David Hildenbrand 
> Cc: osalvador 
> ---
>
>  b/mm/internal.h   |5 +
>  b/mm/migrate.c|  137 
> +-
>  b/mm/page_alloc.c |2
>  3 files changed, 142 insertions(+), 2 deletions(-)
>
> diff -puN mm/internal.h~auto-setup-default-migration-path-from-firmware 
> mm/internal.h
> --- a/mm/internal.h~auto-setup-default-migration-path-from-firmware 
> 2021-01-25 16:23:10.607866706 -0800
> +++ b/mm/internal.h 2021-01-25 16:23:10.616866706 -0800
> @@ -515,12 +515,17 @@ static inline void mminit_validate_memmo
>
>  #ifdef CONFIG_NUMA
>  extern int node_reclaim(struct pglist_data *, gfp_t, unsigned int);
> +extern int find_next_best_node(int node, nodemask_t *used_node_mask);
>  #else
>  static inline int node_reclaim(struct pglist_data *pgdat, gfp_t mask,
> unsigned int order)
>  {
> return NODE_RECLAIM_NOSCAN;
>  }
> +static inline int find_next_best_node(int node, nodemask_t *used_node_mask)
> +{
> +   return NUMA_NO_NODE;
> +}
>  #endif
>
>  extern int hwpoison_filter(struct page *p);
> diff -puN mm/migrate.c~auto-setup-default-migration-path-from-firmware 
> mm/migrate.c
> --- a/mm/migrate.c~auto-setup-default-migration-path-from-firmware  
> 2021-01-25 16:23:10.609866706 -0800
> +++ b/mm/migrate.c  2021-01-25 16:23:10.617866706 -0800
> @@ -1161,6 +1161,10 @@ out:
> return rc;
>  }
>
> +/*
> + * Writes to this array occur without locking.  READ_ONCE()
> + * is recommended for readers to ensure consistent reads.
> + */
>  static int node_demotion[MAX_NUMNODES] = {[0 ...  MAX_NUMNODES - 1] = 
> NUMA_NO_NODE};
>
>  /**
> @@ -1174,7 +1178,13 @@ static int node_demotion[MAX_NUMNODES] =
>   */
>  int next_demotion_node(int node)
>  {
> -   return node_demotion[node];
> +   /*
> +* node_demotion[] is updated without excluding
> +* this function from running.  READ_ONCE() avoids
> +* reading multiple, inconsistent 'node' values
> +* during an update.
> +*/

Don't we need a smp_rmb() here? The single write barrier might be not
enough in migration target set. Typically a write barrier should be
used in pairs with a read barrier.

> +   return READ_ONCE(node_demotion[node]);

Why not consolidate the patch #4 in this patch? The patch #4 just add
the definition of node_demotion and the function, then the function is
changed in this patch, and the function is not used by anyone between
the adding and changing.

>  }
>
>  /*
> @@ -3124,3 +3134,128 @@ void migrate_vma_finalize(struct migrate
>  }
>  EXPORT_SYMBOL(migrate_vma_finalize);
>  #endif /* CONFIG_DEVICE_PRIVATE */
> +
> +/* Disable reclaim-based migration. */
> +static void disable_all_migrate_targets(void)
> +{
> +   int node;
> +
> +   for_each_online_node(node)
> +   node_demotion[node] = NUMA_NO_NODE;
> +}
> +
> +/*
> + * Find an automatic demotion target for 'node'.
> + * Failing here is OK.  It might just indicate
> + * being at the end of a chain.
> + */
> +static int establish_migrate_target(int node, nodemask_t *used)
> +{
> +   int migration_target;
> +
> +   /*
> +* Can not set a migration target on a
> +* node with it already set.
> +*
> +* No need for

[PATCH 3/5] lib: inline _find_next_bit() wrappers

2021-01-29 Thread Yury Norov

lib/find_bit.c declares five single-line wrappers for _find_next_bit().
We may turn those wrappers to inline functions. It eliminates unneeded
function calls and opens room for compile-time optimizations.

Signed-off-by: Yury Norov 
---
 include/asm-generic/bitops/find.h   | 28 ++---
 include/asm-generic/bitops/le.h | 17 ++--
 lib/find_bit.c  | 56 +
 tools/include/asm-generic/bitops/find.h | 27 +---
 tools/lib/find_bit.c| 52 ++-
 5 files changed, 79 insertions(+), 101 deletions(-)

diff --git a/include/asm-generic/bitops/find.h 
b/include/asm-generic/bitops/find.h
index 9fdf21302fdf..7ad70dab8e93 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -2,6 +2,10 @@
 #ifndef _ASM_GENERIC_BITOPS_FIND_H_
 #define _ASM_GENERIC_BITOPS_FIND_H_
 
+extern unsigned long _find_next_bit(const unsigned long *addr1,
+   const unsigned long *addr2, unsigned long nbits,
+   unsigned long start, unsigned long invert, unsigned long le);
+
 #ifndef find_next_bit
 /**
  * find_next_bit - find the next set bit in a memory region
@@ -12,8 +16,12 @@
  * Returns the bit number for the next set bit
  * If no bits are set, returns @size.
  */
-extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
-   size, unsigned long offset);
+static inline
+unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
+   unsigned long offset)
+{
+   return _find_next_bit(addr, NULL, size, offset, 0UL, 0);
+}
 #endif
 
 #ifndef find_next_and_bit
@@ -27,9 +35,13 @@ extern unsigned long find_next_bit(const unsigned long 
*addr, unsigned long
  * Returns the bit number for the next set bit
  * If no bits are set, returns @size.
  */
-extern unsigned long find_next_and_bit(const unsigned long *addr1,
+static inline
+unsigned long find_next_and_bit(const unsigned long *addr1,
const unsigned long *addr2, unsigned long size,
-   unsigned long offset);
+   unsigned long offset)
+{
+   return _find_next_bit(addr1, addr2, size, offset, 0UL, 0);
+}
 #endif
 
 #ifndef find_next_zero_bit
@@ -42,8 +54,12 @@ extern unsigned long find_next_and_bit(const unsigned long 
*addr1,
  * Returns the bit number of the next zero bit
  * If no bits are zero, returns @size.
  */
-extern unsigned long find_next_zero_bit(const unsigned long *addr, unsigned
-   long size, unsigned long offset);
+static inline
+unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
+unsigned long offset)
+{
+   return _find_next_bit(addr, NULL, size, offset, ~0UL, 0);
+}
 #endif
 
 #ifdef CONFIG_GENERIC_FIND_FIRST_BIT
diff --git a/include/asm-generic/bitops/le.h b/include/asm-generic/bitops/le.h
index 188d3eba3ace..21305f6cea0b 100644
--- a/include/asm-generic/bitops/le.h
+++ b/include/asm-generic/bitops/le.h
@@ -2,6 +2,7 @@
 #ifndef _ASM_GENERIC_BITOPS_LE_H_
 #define _ASM_GENERIC_BITOPS_LE_H_
 
+#include 
 #include 
 #include 
 
@@ -32,13 +33,21 @@ static inline unsigned long find_first_zero_bit_le(const 
void *addr,
 #define BITOP_LE_SWIZZLE   ((BITS_PER_LONG-1) & ~0x7)
 
 #ifndef find_next_zero_bit_le
-extern unsigned long find_next_zero_bit_le(const void *addr,
-   unsigned long size, unsigned long offset);
+static inline
+unsigned long find_next_zero_bit_le(const void *addr, unsigned
+   long size, unsigned long offset)
+{
+   return _find_next_bit(addr, NULL, size, offset, ~0UL, 1);
+}
 #endif
 
 #ifndef find_next_bit_le
-extern unsigned long find_next_bit_le(const void *addr,
-   unsigned long size, unsigned long offset);
+static inline
+unsigned long find_next_bit_le(const void *addr, unsigned
+   long size, unsigned long offset)
+{
+   return _find_next_bit(addr, NULL, size, offset, 0UL, 1);
+}
 #endif
 
 #ifndef find_first_zero_bit_le
diff --git a/lib/find_bit.c b/lib/find_bit.c
index 8c2a71a18793..2470ae390f3c 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -29,7 +29,7 @@
  *searching it for one bits.
  *  - The optional "addr2", which is anded with "addr1" if present.
  */
-static unsigned long _find_next_bit(const unsigned long *addr1,
+unsigned long _find_next_bit(const unsigned long *addr1,
const unsigned long *addr2, unsigned long nbits,
unsigned long start, unsigned long invert, unsigned long le)
 {
@@ -68,37 +68,7 @@ static unsigned long _find_next_bit(const unsigned long 
*addr1,
 
return min(start + __ffs(tmp), nbits);
 }
-#endif
-
-#ifndef find_next_bit
-/*
- * Find the next set bit in a memory region.
- */
-unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
-   unsigned long offset)
-{
-   return _find_next_bit(addr, NULL, size, offset, 0UL, 0);
-}

Re: [PATCH v6 2/2] Kbuild: implement support for DWARF v5

On Fri, Jan 29, 2021 at 10:09 PM Nick Desaulniers
 wrote:
>
> On Fri, Jan 29, 2021 at 12:55 PM Sedat Dilek  wrote:
> >
> > On Fri, Jan 29, 2021 at 9:48 PM Nick Desaulniers
> >  wrote:
> > >
> > > On Fri, Jan 29, 2021 at 12:41 PM Sedat Dilek  
> > > wrote:
> > > >
> > > > On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers
> > > >  wrote:
> > > > >
> > > > > diff --git a/Makefile b/Makefile
> > > > > index 20141cd9319e..bed8b3b180b8 100644
> > > > > --- a/Makefile
> > > > > +++ b/Makefile
> > > > > @@ -832,8 +832,20 @@ endif
> > > > >
> > > > >  dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> > > > >  dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> > > > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
> > > > >  DEBUG_CFLAGS   += -gdwarf-$(dwarf-version-y)
> > > > >
> > > > > +# If using clang without the integrated assembler, we need to 
> > > > > explicitly tell
> > > > > +# GAS that we will be feeding it DWARF v5 assembler directives. 
> > > > > Kconfig should
> > > > > +# detect whether the version of GAS supports DWARF v5.
> > > > > +ifdef CONFIG_CC_IS_CLANG
> > > > > +ifneq ($(LLVM_IAS),1)
> > > > > +ifeq ($(dwarf-version-y),5)
> > > > > +DEBUG_CFLAGS   += -Wa,-gdwarf-5
> > > >
> > > > I noticed double "-g -gdwarf-5 -g -gdwarf-5" (a different issue) and
> > > > that's why I looked again into the top-level Makefile.
> > >
> > > That's...unexpected.  I don't see where that could be coming from.
> > > Can you tell me please what is the precise command line invocation of
> > > make and which source file you observed this on so that I can
> > > reproduce?
> > >
> >
> > That's everywhere...
> >
> > $ zstdgrep --color '\-g -gdwarf-5 -g -gdwarf-5'
> > build-log_5.11.0-rc5-8-amd64-clang12-lto.txt.zst
> > | wc -l
> > 29529
>
> I'm not able to reproduce.
>
> $ make LLVM=1 -j72 V=1 2>&1 | grep dwarf
> ...
> clang ... -g -gdwarf-5 -Wa,-gdwarf-5 ...
> ...
>
> $ make LLVM=1 LLVM_IAS=1 -j72 V=1 2>&1 | grep dwarf
> ...
> clang ... -g -gdwarf-5 ...
> ...
>

Hmm...

I do not see in my current build "-Wa,-gdwarf-5" is passed with v6.

$ grep '\-Wa,-gdwarf-5' build-log_5.11.0-rc5-10-amd64-clang12-lto-pgo.txt
[ empty ]


- Sedat




> Can you tell me please what is the precise command line invocation of
> make and which source file you observed this on so that I can
> reproduce?
> --
> Thanks,
> ~Nick Desaulniers

Re: [PATCH net-next v1 1/6] lan743x: boost performance on cpu archs w/o dma cache snooping

On Fri, 29 Jan 2021 14:52:35 -0500 Sven Van Asbroeck wrote:
> From: Sven Van Asbroeck 
> 
> The buffers in the lan743x driver's receive ring are always 9K,
> even when the largest packet that can be received (the mtu) is
> much smaller. This performs particularly badly on cpu archs
> without dma cache snooping (such as ARM): each received packet
> results in a 9K dma_{map|unmap} operation, which is very expensive
> because cpu caches need to be invalidated.
> 
> Careful measurement of the driver rx path on armv7 reveals that
> the cpu spends the majority of its time waiting for cache
> invalidation.
> 
> Optimize as follows:
> 
> 1. set rx ring buffer size equal to the mtu. this limits the
>amount of cache that needs to be invalidated per dma_map().
> 
> 2. when dma_unmap()ping, skip cpu sync. Sync only the packet data
>actually received, the size of which the chip will indicate in
>its rx ring descriptors. this limits the amount of cache that
>needs to be invalidated per dma_unmap().
> 
> These optimizations double the rx performance on armv7.
> Third parties report 3x rx speedup on armv8.
> 
> Performance on dma cache snooping architectures (such as x86)
> is expected to stay the same.
> 
> Tested with iperf3 on a freescale imx6qp + lan7430, both sides
> set to mtu 1500 bytes, measure rx performance:
> 
> Before:
> [ ID] Interval   Transfer Bandwidth   Retr
> [  4]   0.00-20.00  sec   550 MBytes   231 Mbits/sec0
> After:
> [ ID] Interval   Transfer Bandwidth   Retr
> [  4]   0.00-20.00  sec  1.33 GBytes   570 Mbits/sec0
> 
> Test by Anders Roenningen (and...@ronningen.priv.no) on armv8,
> rx iperf3:
> Before 102 Mbits/sec
> After  279 Mbits/sec
> 
> Signed-off-by: Sven Van Asbroeck 

You may need to rebase to see this:

drivers/net/ethernet/microchip/lan743x_main.c:2123:41: warning: restricted 
__le32 degrades to integer

Re: [git pull] drm fixes for 5.11-rc6

The pull request you sent on Fri, 29 Jan 2021 13:46:34 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-01-29

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6305d15e013a70a7f1c4ee65d3e035cd705e3517

Thank you!

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

Re: [GIT PULL][Resend] ACPI fixes for v5.11-rc6

The pull request you sent on Fri, 29 Jan 2021 19:11:17 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
> acpi-5.11-rc6

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/016decc0d836b746faac03de5e1ac976c53a3958

Thank you!

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

Re: [GIT PULL] arm64 fixes for 5.11-rc6

The pull request you sent on Fri, 29 Jan 2021 19:03:24 +:

> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0e9bcda5d286f4a26a5407bb38f55c55b453ecfb

Thank you!

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

Re: [git pull] IOMMU Fixes for Linux v5.11-rc5

The pull request you sent on Fri, 29 Jan 2021 17:41:29 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git 
> tags/iommu-fixes-v5.11-rc5

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8ef24c2011b77bd6344d16630d3cd95d63de63f8

Thank you!

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

Re: [PATCH v4 11/17] remoteproc: Introduce function __rproc_detach()

2021-01-29 Thread Mathieu Poirier

On Wed, Jan 27, 2021 at 09:46:58AM +0100, Arnaud POULIQUEN wrote:
> 
> 
> On 12/18/20 6:32 PM, Mathieu Poirier wrote:
> > Introduce function __rproc_detach() to perform the same kind of
> > operation as rproc_stop(), but instead of switching off the
> > remote processor using rproc->ops->stop(), it uses
> > rproc->ops->detach().  That way it is possible for the core
> > to release the resources associated with a remote processor while
> > the latter is kept operating.
> > 
> > Signed-off-by: Mathieu Poirier 
> > Reviewed-by: Peng Fan 
> > ---
> >  drivers/remoteproc/remoteproc_core.c | 42 
> >  1 file changed, 42 insertions(+)
> > 
> > diff --git a/drivers/remoteproc/remoteproc_core.c 
> > b/drivers/remoteproc/remoteproc_core.c
> > index fc28053c7f89..e665ed4776c3 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -1670,6 +1670,48 @@ static int rproc_stop(struct rproc *rproc, bool 
> > crashed)
> > return 0;
> >  }
> >  
> > +/*
> > + * __rproc_detach(): Does the opposite of rproc_attach()
> > + */
> > +static int __maybe_unused __rproc_detach(struct rproc *rproc)
> > +{
> > +   struct device *dev = >dev;
> > +   int ret;
> > +
> > +   /* No need to continue if a detach() operation has not been provided */
> > +   if (!rproc->ops->detach)
> > +   return -EINVAL;
> 
> I wonder if this ops should be optional.

Function rproc_validate() doesn't check for it so it is optional.  Returning an
error is to indicate to sysfs the operation is not supported if someone tries to
do a "detach" when rproc::ops doesn't provide it.

> 
> > +
> > +   /* Stop any subdevices for the remote processor */
> > +   rproc_stop_subdevices(rproc, false);
> > +
> > +   /*
> > +* If the remote processors was started by the core then a cached_table
> > +* is present and we must follow the same cleanup sequence as we would
> > +* for a shutdown().  As it is in rproc_stop(), use the cached resource
> > +* table for the rest of the detach process since ->table_ptr will
> > +* become invalid as soon as carveouts are released in
> > +* rproc_resource_cleanup().
> > +*/
> > +   if (rproc->cached_table)
> > +   rproc->table_ptr = rproc->cached_table;
> > +
> > +   /* Tell the remote processor the core isn't available anymore */
> > +   ret = rproc->ops->detach(rproc);
> > +   if (ret) {
> > +   dev_err(dev, "can't detach from rproc: %d\n", ret);
> > +   rproc_start_subdevices(rproc);
> 
> Not sure that this would be possible in all cases, without a unprepare and
> prepare. What about having the same behavior as the rproc_stop failure?

I thought rproc_stop()'s failure path was buggy and could be improved but as you
say, there might be other ramifications to take into account.  I agree that it
is more prudent to follow the current behavior from rproc_stop() and leave
enhancements for another patchset.

> 
> Thanks
> Arnaud.
> 
> > +   return ret;
> > +   }
> > +
> > +   rproc_unprepare_subdevices(rproc);
> > +
> > +   rproc->state = RPROC_DETACHED;
> > +
> > +   dev_info(dev, "detached remote processor %s\n", rproc->name);
> > +
> > +   return 0;
> > +}
> >  
> >  /**
> >   * rproc_trigger_recovery() - recover a remoteproc
> >

Re: [PATCH v2] misc: bcm-vk: only support ttyVK if CONFIG_TTY is set

2021-01-29 Thread Randy Dunlap

On 1/29/21 2:06 PM, Scott Branden wrote:
> Correct compile issue if CONFIG_TTY is not set by
> only adding ttyVK devices if CONFIG_TTY is set.
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Scott Branden 
> 
> ---
> Changes since v1:
> Add function stubs rather than compiling out code
> ---
>  drivers/misc/bcm-vk/Makefile |  4 ++--
>  drivers/misc/bcm-vk/bcm_vk.h | 35 +---
>  drivers/misc/bcm-vk/bcm_vk_dev.c |  3 +--
>  drivers/misc/bcm-vk/bcm_vk_tty.c |  6 ++
>  4 files changed, 41 insertions(+), 7 deletions(-)

Looks good. Thanks.

Acked-by: Randy Dunlap  # build-tested


-- 
~Randy

Re: [RFC PATCH v1 3/4] vfio: Try to enable IOPF for VFIO devices

2021-01-29 Thread Alex Williamson

On Mon, 25 Jan 2021 17:04:01 +0800
Shenming Lu  wrote:

> If IOMMU_DEV_FEAT_IOPF is set for the VFIO device, which means that
> the delivering of page faults of this device from the IOMMU is enabled,
> we register the VFIO page fault handler to complete the whole faulting
> path (HW+SW). And add a iopf_enabled field in struct vfio_device to
> record it.
> 
> Signed-off-by: Shenming Lu 
> ---
>  drivers/vfio/vfio.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index ff7797260d0f..fd885d99ee0f 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -97,6 +97,7 @@ struct vfio_device {
>   struct vfio_group   *group;
>   struct list_headgroup_next;
>   void*device_data;
> + booliopf_enabled;
>  };
>  
>  #ifdef CONFIG_VFIO_NOIOMMU
> @@ -532,6 +533,21 @@ static struct vfio_group *vfio_group_get_from_dev(struct 
> device *dev)
>  /**
>   * Device objects - create, release, get, put, search
>   */
> +
> +static void vfio_device_enable_iopf(struct vfio_device *device)
> +{
> + struct device *dev = device->dev;
> +
> + if (!iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_IOPF))
> + return;
> +
> + if (WARN_ON(iommu_register_device_fault_handler(dev,
> + vfio_iommu_dev_fault_handler, dev)))

The layering here is wrong, vfio-core doesn't manage the IOMMU, we have
backend IOMMU drivers for that.  We can't even assume we have IOMMU API
support here, that's what the type1 backend handles.  Thanks,

Alex

> + return;
> +
> + device->iopf_enabled = true;
> +}
> +
>  static
>  struct vfio_device *vfio_group_create_device(struct vfio_group *group,
>struct device *dev,
> @@ -549,6 +565,8 @@ struct vfio_device *vfio_group_create_device(struct 
> vfio_group *group,
>   device->group = group;
>   device->ops = ops;
>   device->device_data = device_data;
> + /* By default try to enable IOPF */
> + vfio_device_enable_iopf(device);
>   dev_set_drvdata(dev, device);
>  
>   /* No need to get group_lock, caller has group reference */
> @@ -573,6 +591,8 @@ static void vfio_device_release(struct kref *kref)
>   mutex_unlock(>device_lock);
>  
>   dev_set_drvdata(device->dev, NULL);
> + if (device->iopf_enabled)
> + WARN_ON(iommu_unregister_device_fault_handler(device->dev));
>  
>   kfree(device);
>

[PATCHv2] gnss: motmdm: Add support for Motorola Mapphone MDM6600 modem

2021-01-29 Thread Pavel Machek


Motorola is using a custom TS 27.010 based multiplexer protocol
for various devices on the modem. These devices can be accessed on
dedicated channels using Linux kernel serdev-ngsm driver.

For the GNSS on these devices, we need to kick the GNSS device at a
desired rate. Otherwise the GNSS device stops sending data after a
few minutes. The rate we poll data defaults to 1000 ms, and can be
specified with a module option rate_ms between 1 to 16 seconds.

[Tony Lindgren did most of the work here, I just converted it to be
normal serdev.]

Signed-off-by: Pavel Machek 

diff --git a/drivers/gnss/Kconfig b/drivers/gnss/Kconfig
index bd12e3d57baa..9fac72eba726 100644
--- a/drivers/gnss/Kconfig
+++ b/drivers/gnss/Kconfig
@@ -13,6 +13,14 @@ menuconfig GNSS
 
 if GNSS
 
+config GNSS_MOTMDM
+   tristate "Motorola Modem TS 27.010 serdev GNSS receiver support"
+   depends on SERIAL_DEV_BUS
+   help
+ Say Y here if you have a Motorola modem using TS 27.010
+ multiplexer protocol for GNSS such as a Motorola Mapphone
+ series device like Droid 4.
+
 config GNSS_SERIAL
tristate
 
diff --git a/drivers/gnss/Makefile b/drivers/gnss/Makefile
index 451f11401ecc..f5afc2c22a3b 100644
--- a/drivers/gnss/Makefile
+++ b/drivers/gnss/Makefile
@@ -6,6 +6,9 @@
 obj-$(CONFIG_GNSS) += gnss.o
 gnss-y := core.o
 
+obj-$(CONFIG_GNSS_MOTMDM)  += gnss-motmdm.o
+gnss-motmdm-y := motmdm.o
+
 obj-$(CONFIG_GNSS_SERIAL)  += gnss-serial.o
 gnss-serial-y := serial.o
 
diff --git a/drivers/gnss/motmdm.c b/drivers/gnss/motmdm.c
new file mode 100644
index ..00cab10b
--- /dev/null
+++ b/drivers/gnss/motmdm.c
@@ -0,0 +1,406 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Motorola Modem TS 27.010 serdev GNSS driver
+ *
+ * Copyright (C) 2018 - 2020 Tony Lindgren 
+ * Copyright (C) 2020 - 2021 Pavel Machek 
+ *
+ * Based on drivers/gnss/sirf.c driver example:
+ * Copyright (C) 2018 Johan Hovold 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MOTMDM_GNSS_TIMEOUT1000
+#define MOTMDM_GNSS_RATE   1000
+
+/*
+ * Motorola MDM GNSS device communicates over a dedicated TS 27.010 channel
+ * using custom data packets. The packets look like AT commands embedded into
+ * a Motorola invented packet using format like "U1234AT+MPDSTART=0,1,100,0".
+ * But it's not an AT compatible serial interface, it's a packet interface
+ * using AT like commands.
+ */
+#define MOTMDM_GNSS_HEADER_LEN 5   /* U1234 */
+#define MOTMDM_GNSS_RESP_LEN   (MOTMDM_GNSS_HEADER_LEN + 4)/* U1234+MPD */
+#define MOTMDM_GNSS_DATA_LEN   (MOTMDM_GNSS_RESP_LEN + 1)  /* U1234~+MPD */
+#define MOTMDM_GNSS_STATUS_LEN (MOTMDM_GNSS_DATA_LEN + 7) /* U1234~+MPDSTATUS= 
*/
+#define MOTMDM_GNSS_NMEA_LEN   (MOTMDM_GNSS_DATA_LEN + 8) /* 
U1234~+MPDNMEA=NN, */
+
+enum motmdm_gnss_status {
+   MOTMDM_GNSS_UNKNOWN,
+   MOTMDM_GNSS_INITIALIZED,
+   MOTMDM_GNSS_DATA_OR_TIMEOUT,
+   MOTMDM_GNSS_STARTED,
+   MOTMDM_GNSS_STOPPED,
+};
+
+struct motmdm_gnss_data {
+   struct gnss_device *gdev;
+   struct device *modem;
+   struct serdev_device *serdev;
+   struct delayed_work restart_work;
+   struct mutex mutex; /* For modem commands */
+   ktime_t last_update;
+   int status;
+   unsigned char *buf;
+   size_t len;
+   wait_queue_head_t read_queue;
+   unsigned int parsed:1;
+};
+
+static unsigned int rate_ms = MOTMDM_GNSS_RATE;
+module_param(rate_ms, uint, 0644);
+MODULE_PARM_DESC(rate_ms, "GNSS refresh rate between 1000 and 16000 ms 
(default 1000 ms)");
+
+/*
+ * Note that multiple commands can be sent in series with responses coming
+ * out-of-order. For GNSS, we don't need to care about the out-of-order
+ * responses, and can assume we have at most one command active at a time.
+ * For the commands, can use just a jiffies base packet ID and let the modem
+ * sort out the ID conflicts with the modem's unsolicited message ID
+ * numbering.
+ */
+int motmdm_gnss_send_command(struct motmdm_gnss_data *ddata,
+const u8 *buf, int len)
+{
+   struct gnss_device *gdev = ddata->gdev;
+   const int timeout_ms = 1000;
+   unsigned char cmd[128];
+   int ret, cmdlen;
+
+   cmdlen = len + MOTMDM_GNSS_HEADER_LEN + 1;
+   if (cmdlen > 128)
+   return -EINVAL;
+
+   mutex_lock(>mutex);
+   memset(ddata->buf, 0, ddata->len);
+   ddata->parsed = false;
+   snprintf(cmd, cmdlen, "U%04li%s", jiffies % 1, buf);
+
+   ret = serdev_device_write(ddata->serdev, cmd, cmdlen, 
MAX_SCHEDULE_TIMEOUT);
+   if (ret < 0)
+   goto out_unlock;
+
+   serdev_device_wait_until_sent(ddata->serdev, 0);
+
+   ret = wait_event_timeout(ddata->read_queue, ddata->parsed,
+msecs_to_jiffies(timeout_ms));
+   if (ret == 0) {
+

[PATCH net] rxrpc: Fix deadlock around release of dst cached on udp tunnel

2021-01-29 Thread David Howells

AF_RXRPC sockets use UDP ports in encap mode.  This causes socket and dst
from an incoming packet to get stolen and attached to the UDP socket from
whence it is leaked when that socket is closed.

When a network namespace is removed, the wait for dst records to be cleaned
up happens before the cleanup of the rxrpc and UDP socket, meaning that the
wait never finishes.

Fix this by moving the rxrpc (and, by dependence, the afs) private
per-network namespace registrations to the device group rather than subsys
group.  This allows cached rxrpc local endpoints to be cleared and their
UDP sockets closed before we try waiting for the dst records.

The symptom is that lines looking like the following:

unregister_netdevice: waiting for lo to become free

get emitted at regular intervals after running something like the
referenced syzbot test.

Thanks to Vadim for tracking this down and work out the fix.

Reported-by: syzbot+df400f2f24a1677cd...@syzkaller.appspotmail.com
Reported-by: Vadim Fedorenko 
Fixes: 5271953cad31 ("rxrpc: Use the UDP encap_rcv hook")
Signed-off-by: David Howells 
Acked-by: Vadim Fedorenko 
---

 fs/afs/main.c|6 +++---
 net/rxrpc/af_rxrpc.c |6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/afs/main.c b/fs/afs/main.c
index accdd8970e7c..b2975256dadb 100644
--- a/fs/afs/main.c
+++ b/fs/afs/main.c
@@ -193,7 +193,7 @@ static int __init afs_init(void)
goto error_cache;
 #endif
 
-   ret = register_pernet_subsys(_net_ops);
+   ret = register_pernet_device(_net_ops);
if (ret < 0)
goto error_net;
 
@@ -213,7 +213,7 @@ static int __init afs_init(void)
 error_proc:
afs_fs_exit();
 error_fs:
-   unregister_pernet_subsys(_net_ops);
+   unregister_pernet_device(_net_ops);
 error_net:
 #ifdef CONFIG_AFS_FSCACHE
fscache_unregister_netfs(_cache_netfs);
@@ -244,7 +244,7 @@ static void __exit afs_exit(void)
 
proc_remove(afs_proc_symlink);
afs_fs_exit();
-   unregister_pernet_subsys(_net_ops);
+   unregister_pernet_device(_net_ops);
 #ifdef CONFIG_AFS_FSCACHE
fscache_unregister_netfs(_cache_netfs);
 #endif
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 0a2f4817ec6c..41671af6b33f 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -990,7 +990,7 @@ static int __init af_rxrpc_init(void)
goto error_security;
}
 
-   ret = register_pernet_subsys(_net_ops);
+   ret = register_pernet_device(_net_ops);
if (ret)
goto error_pernet;
 
@@ -1035,7 +1035,7 @@ static int __init af_rxrpc_init(void)
 error_sock:
proto_unregister(_proto);
 error_proto:
-   unregister_pernet_subsys(_net_ops);
+   unregister_pernet_device(_net_ops);
 error_pernet:
rxrpc_exit_security();
 error_security:
@@ -1057,7 +1057,7 @@ static void __exit af_rxrpc_exit(void)
unregister_key_type(_type_rxrpc);
sock_unregister(PF_RXRPC);
proto_unregister(_proto);
-   unregister_pernet_subsys(_net_ops);
+   unregister_pernet_device(_net_ops);
ASSERTCMP(atomic_read(_n_tx_skbs), ==, 0);
ASSERTCMP(atomic_read(_n_rx_skbs), ==, 0);

RE: [PATCH] media: allegro-dvt: Use __packed sentence

2021-01-29 Thread David Laight

From: Emmanuel Arias
> Sent: 29 January 2021 20:02
> 
> Fix coding style using __packed sentece instead of
> __attribute__((__packed__)).
> 
> Signed-off-by: Emmanuel Arias 
> ---
>  drivers/staging/media/allegro-dvt/allegro-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/allegro-dvt/allegro-core.c 
> b/drivers/staging/media/allegro-
> dvt/allegro-core.c
> index 9f718f43282b..cee624dac61a 100644
> --- a/drivers/staging/media/allegro-dvt/allegro-core.c
> +++ b/drivers/staging/media/allegro-dvt/allegro-core.c
> @@ -670,7 +670,7 @@ static ssize_t allegro_mbox_read(struct allegro_mbox 
> *mbox,
>   struct {
>   u16 length;
>   u16 type;
> - } __attribute__ ((__packed__)) *header;
> + } __packed *header;
>   struct regmap *sram = mbox->dev->sram;

Does this actually need to be packed?
The only reason would be if the structure could exist on a 2n+1
boundary.
But that is only likely if part of some binary sequence.
In which case I'd expect it to be marked __be or __le.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

[PATCH 04/14] cxl/mem: Implement polled mode mailbox

2021-01-29 Thread Ben Widawsky

Provide enough functionality to utilize the mailbox of a memory device.
The mailbox is used to interact with the firmware running on the memory
device.

The CXL specification defines separate capabilities for the mailbox and
the memory device. The mailbox interface has a doorbell to indicate
ready to accept commands and the memory device has a capability register
that indicates the mailbox interface is ready. The expectation is that
the doorbell-ready is always later than the memory-device-indication
that the mailbox is ready.

Create a function to handle sending a command, optionally with a
payload, to the memory device, polling on a result, and then optionally
copying out the payload. The algorithm for doing this comes straight out
of the CXL 2.0 specification.

Primary mailboxes are capable of generating an interrupt when submitting
a command in the background. That implementation is saved for a later
time.

Secondary mailboxes aren't implemented at this time.

The flow is proven with one implemented command, "identify". Because the
class code has already told the driver this is a memory device and the
identify command is mandatory.

Signed-off-by: Ben Widawsky 
---
 drivers/cxl/Kconfig |  14 ++
 drivers/cxl/cxl.h   |  39 +
 drivers/cxl/mem.c   | 342 +++-
 3 files changed, 394 insertions(+), 1 deletion(-)

diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index 3b66b46af8a0..fe591f74af96 100644
--- a/drivers/cxl/Kconfig
+++ b/drivers/cxl/Kconfig
@@ -32,4 +32,18 @@ config CXL_MEM
  Chapter 2.3 Type 3 CXL Device in the CXL 2.0 specification.
 
  If unsure say 'm'.
+
+config CXL_MEM_INSECURE_DEBUG
+   bool "CXL.mem debugging"
+   depends on CXL_MEM
+   help
+ Enable debug of all CXL command payloads.
+
+ Some CXL devices and controllers support encryption and other
+ security features. The payloads for the commands that enable
+ those features may contain sensitive clear-text security
+ material. Disable debug of those command payloads by default.
+ If you are a kernel developer actively working on CXL
+ security enabling say Y, otherwise say N.
+
 endif
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index a3da7f8050c4..df3d97154b63 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -31,9 +31,36 @@
 #define CXLDEV_MB_CAPS_OFFSET 0x00
 #define   CXLDEV_MB_CAP_PAYLOAD_SIZE_MASK GENMASK(4, 0)
 #define CXLDEV_MB_CTRL_OFFSET 0x04
+#define   CXLDEV_MB_CTRL_DOORBELL BIT(0)
 #define CXLDEV_MB_CMD_OFFSET 0x08
+#define   CXLDEV_MB_CMD_COMMAND_OPCODE_MASK GENMASK(15, 0)
+#define   CXLDEV_MB_CMD_PAYLOAD_LENGTH_MASK GENMASK(36, 16)
 #define CXLDEV_MB_STATUS_OFFSET 0x10
+#define   CXLDEV_MB_STATUS_RET_CODE_MASK GENMASK(47, 32)
 #define CXLDEV_MB_BG_CMD_STATUS_OFFSET 0x18
+#define CXLDEV_MB_PAYLOAD_OFFSET 0x20
+
+/* Memory Device (CXL 2.0 - 8.2.8.5.1.1) */
+#define CXLMDEV_STATUS_OFFSET 0x0
+#define   CXLMDEV_DEV_FATAL BIT(0)
+#define   CXLMDEV_FW_HALT BIT(1)
+#define   CXLMDEV_STATUS_MEDIA_STATUS_MASK GENMASK(3, 2)
+#define CXLMDEV_MS_NOT_READY 0
+#define CXLMDEV_MS_READY 1
+#define CXLMDEV_MS_ERROR 2
+#define CXLMDEV_MS_DISABLED 3
+#define   CXLMDEV_READY(status) \
+   (CXL_GET_FIELD(status, CXLMDEV_STATUS_MEDIA_STATUS) == 
CXLMDEV_MS_READY)
+#define   CXLMDEV_MBOX_IF_READY BIT(4)
+#define   CXLMDEV_RESET_NEEDED_SHIFT 5
+#define   CXLMDEV_RESET_NEEDED_MASK GENMASK(7, 5)
+#define CXLMDEV_RESET_NEEDED_NOT 0
+#define CXLMDEV_RESET_NEEDED_COLD 1
+#define CXLMDEV_RESET_NEEDED_WARM 2
+#define CXLMDEV_RESET_NEEDED_HOT 3
+#define CXLMDEV_RESET_NEEDED_CXL 4
+#define   CXLMDEV_RESET_NEEDED(status) \
+   (CXL_GET_FIELD(status, CXLMDEV_RESET_NEEDED) != 
CXLMDEV_RESET_NEEDED_NOT)
 
 /**
  * struct cxl_mem - A CXL memory device
@@ -44,6 +71,16 @@ struct cxl_mem {
struct pci_dev *pdev;
void __iomem *regs;
 
+   struct {
+   struct range range;
+   } pmem;
+
+   struct {
+   struct range range;
+   } ram;
+
+   char firmware_version[0x10];
+
/* Cap 0001h - CXL_CAP_CAP_ID_DEVICE_STATUS */
struct {
void __iomem *regs;
@@ -51,6 +88,7 @@ struct cxl_mem {
 
/* Cap 0002h - CXL_CAP_CAP_ID_PRIMARY_MAILBOX */
struct {
+   struct mutex mutex; /* Protects device mailbox and firmware */
void __iomem *regs;
size_t payload_size;
} mbox;
@@ -89,5 +127,6 @@ struct cxl_mem {
 
 cxl_reg(status);
 cxl_reg(mbox);
+cxl_reg(mem);
 
 #endif /* __CXL_H__ */
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index fa14d51243ee..69ed15bfa5d4 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -6,6 +6,270 @@
 #include "pci.h"
 #include "cxl.h"
 
+#define cxl_doorbell_busy(cxlm)
\
+   (cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CTRL_OFFSET) &

Re: [PATCH V5 3/5] gpio: gpio-xilinx: Add interrupt support

2021-01-29 Thread Robert Hancock

Noticed one issue, see below:

On Fri, 2021-01-29 at 19:56 +0530, Srinivas Neeli wrote:
> Adds interrupt support to the Xilinx GPIO driver so that rising and
> falling edge line events can be supported. Since interrupt support is
> an optional feature in the Xilinx IP, the driver continues to support
> devices which have no interrupt provided.
> Depends on OF_GPIO framework for of_xlate function to translate
> gpiospec to the GPIO number and flags.
> 
> Signed-off-by: Robert Hancock 
> Signed-off-by: Shubhrajyoti Datta 
> Signed-off-by: Srinivas Neeli 
> ---
> Changes in V5:
> -Removed IRQ_DOMAIN_HIERARCHY from Kconfig and
>  #include  from includes.
> -Fixed "detected irqchip that is shared with multiple
>  gpiochips: please fix the driver"error message.
> -Added check for #gpio-cells and error message in failure case.
> Changes in V4:
> -Added more commit description.
> Changes in V3:
> -Created separate patch for Clock changes and runtime resume
>  and suspend.
> -Updated minor review comments.
> 
> Changes in V2:
> -Added check for return value of platform_get_irq() API.
> -Updated code to support rising edge and falling edge.
> -Added xgpio_xlate() API to support switch.
> -Added MAINTAINERS fragment.
> ---
>  drivers/gpio/Kconfig   |   2 +
>  drivers/gpio/gpio-xilinx.c | 246
> -
>  2 files changed, 244 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index c70f46e80a3b..2ee57797d908 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -690,6 +690,8 @@ config GPIO_XGENE_SB
>  
>  config GPIO_XILINX
>   tristate "Xilinx GPIO support"
> + select GPIOLIB_IRQCHIP
> + depends on OF_GPIO
>   help
> Say yes here to support the Xilinx FPGA GPIO device
>  
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index f88db56543c2..62deb755f910 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -10,7 +10,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -22,6 +24,11 @@
>  
>  #define XGPIO_CHANNEL_OFFSET 0x8
>  
> +#define XGPIO_GIER_OFFSET0x11c /* Global Interrupt Enable */
> +#define XGPIO_GIER_IEBIT(31)
> +#define XGPIO_IPISR_OFFSET   0x120 /* IP Interrupt Status */
> +#define XGPIO_IPIER_OFFSET   0x128 /* IP Interrupt Enable */
> +
>  /* Read/Write access to the GPIO registers */
>  #if defined(CONFIG_ARCH_ZYNQ) || defined(CONFIG_X86)
>  # define xgpio_readreg(offset)   readl(offset)
> @@ -36,9 +43,15 @@
>   * @gc: GPIO chip
>   * @regs: register block
>   * @gpio_width: GPIO width for every channel
> - * @gpio_state: GPIO state shadow register
> + * @gpio_state: GPIO write state shadow register
> + * @gpio_last_irq_read: GPIO read state register from last interrupt
>   * @gpio_dir: GPIO direction shadow register
>   * @gpio_lock: Lock used for synchronization
> + * @irq: IRQ used by GPIO device
> + * @irqchip: IRQ chip
> + * @irq_enable: GPIO IRQ enable/disable bitfield
> + * @irq_rising_edge: GPIO IRQ rising edge enable/disable bitfield
> + * @irq_falling_edge: GPIO IRQ falling edge enable/disable bitfield
>   * @clk: clock resource for this driver
>   */
>  struct xgpio_instance {
> @@ -46,8 +59,14 @@ struct xgpio_instance {
>   void __iomem *regs;
>   unsigned int gpio_width[2];
>   u32 gpio_state[2];
> + u32 gpio_last_irq_read[2];
>   u32 gpio_dir[2];
>   spinlock_t gpio_lock;   /* For serializing operations */
> + int irq;
> + struct irq_chip irqchip;
> + u32 irq_enable[2];
> + u32 irq_rising_edge[2];
> + u32 irq_falling_edge[2];
>   struct clk *clk;
>  };
>  
> @@ -277,6 +296,175 @@ static int xgpio_remove(struct platform_device *pdev)
>  }
>  
>  /**
> + * xgpio_irq_ack - Acknowledge a child GPIO interrupt.
> + * @irq_data: per IRQ and chip data passed down to chip functions
> + * This currently does nothing, but irq_ack is unconditionally called by
> + * handle_edge_irq and therefore must be defined.
> + */
> +static void xgpio_irq_ack(struct irq_data *irq_data)
> +{
> +}
> +
> +/**
> + * xgpio_irq_mask - Write the specified signal of the GPIO device.
> + * @irq_data: per IRQ and chip data passed down to chip functions
> + */
> +static void xgpio_irq_mask(struct irq_data *irq_data)
> +{
> + unsigned long flags;
> + struct xgpio_instance *chip = irq_data_get_irq_chip_data(irq_data);
> + int irq_offset = irqd_to_hwirq(irq_data);
> + int index = xgpio_index(chip, irq_offset);
> + int offset = xgpio_offset(chip, irq_offset);
> +
> + spin_lock_irqsave(>gpio_lock, flags);
> +
> + chip->irq_enable[index] &= ~BIT(offset);
> +
> + if (!chip->irq_enable[index]) {
> + /* Disable per channel interrupt */
> + u32 temp = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
> +
> + temp &= ~BIT(index);
> +

Re: [PATCH v2] btrfs: Avoid calling btrfs_get_chunk_map() twice

2021-01-29 Thread Filipe Manana

On Fri, Jan 29, 2021 at 5:54 PM David Sterba  wrote:
>
> On Fri, Jan 29, 2021 at 05:15:21PM +, Michal Rostecki wrote:
> > On Fri, Jan 29, 2021 at 11:22:48AM -0500, Josef Bacik wrote:
> > > On 1/27/21 8:57 AM, Michal Rostecki wrote:
> > > > From: Michal Rostecki 
> > > >
> > > > Before this change, the btrfs_get_io_geometry() function was calling
> > > > btrfs_get_chunk_map() to get the extent mapping, necessary for
> > > > calculating the I/O geometry. It was using that extent mapping only
> > > > internally and freeing the pointer after its execution.
> > > >
> > > > That resulted in calling btrfs_get_chunk_map() de facto twice by the
> > > > __btrfs_map_block() function. It was calling btrfs_get_io_geometry()
> > > > first and then calling btrfs_get_chunk_map() directly to get the extent
> > > > mapping, used by the rest of the function.
> > > >
> > > > This change fixes that by passing the extent mapping to the
> > > > btrfs_get_io_geometry() function as an argument.
> > > >
> > > > v2:
> > > > When btrfs_get_chunk_map() returns an error in btrfs_submit_direct():
> > > > - Use errno_to_blk_status(PTR_ERR(em)) as the status
> > > > - Set em to NULL
> > > >
> > > > Signed-off-by: Michal Rostecki 
> > >
> > > This panic'ed all of my test vms in their overnight xfstests runs, the 
> > > panic is this
> > >
> > > [ 2449.936502] BTRFS critical (device dm-7): mapping failed logical
> > > 1113825280 bio len 40960 len 24576
> > > [ 2449.937073] [ cut here ]
> > > [ 2449.937329] kernel BUG at fs/btrfs/volumes.c:6450!
> > > [ 2449.937604] invalid opcode:  [#1] SMP NOPTI
> > > [ 2449.937855] CPU: 0 PID: 259045 Comm: kworker/u5:0 Not tainted 
> > > 5.11.0-rc5+ #122
> > > [ 2449.938252] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> > > 1.13.0-2.fc32 04/01/2014
> > > [ 2449.938713] Workqueue: btrfs-worker-high btrfs_work_helper
> > > [ 2449.939016] RIP: 0010:btrfs_map_bio.cold+0x5a/0x5c
> > > [ 2449.939392] Code: 37 87 ff ff e8 ed d4 8a ff 48 83 c4 18 e9 b5 52 8b ff
> > > 49 89 c8 4c 89 fa 4c 89 f1 48 c7 c6 b0 c0 61 8b 48 89 ef e8 11 87 ff ff 
> > > <0f>
> > > 0b 4c 89 e7 e8 42 09 86 ff e9 fd 59 8b ff 49 8b 7a 50 44 89 f2
> > > [ 2449.940402] RSP: :9f24c1637d90 EFLAGS: 00010282
> > > [ 2449.940689] RAX: 0057 RBX: 90c78ff716b8 RCX: 
> > > 
> > > [ 2449.941080] RDX: 90c7fbc27ae0 RSI: 90c7fbc19110 RDI: 
> > > 90c7fbc19110
> > > [ 2449.941467] RBP: 90c7911d4000 R08:  R09: 
> > > 
> > > [ 2449.941853] R10: 9f24c1637b48 R11: 8b9723e8 R12: 
> > > 
> > > [ 2449.942243] R13:  R14: a000 R15: 
> > > 4263a000
> > > [ 2449.942632] FS:  () GS:90c7fbc0()
> > > knlGS:
> > > [ 2449.943072] CS:  0010 DS:  ES:  CR0: 80050033
> > > [ 2449.943386] CR2: 5575163c3080 CR3: 00010ad6c004 CR4: 
> > > 00370ef0
> > > [ 2449.943772] Call Trace:
> > > [ 2449.943915]  ? lock_release+0x1c3/0x290
> > > [ 2449.944135]  run_one_async_done+0x3a/0x60
> > > [ 2449.944360]  btrfs_work_helper+0x136/0x520
> > > [ 2449.944588]  process_one_work+0x26e/0x570
> > > [ 2449.944812]  worker_thread+0x55/0x3c0
> > > [ 2449.945016]  ? process_one_work+0x570/0x570
> > > [ 2449.945250]  kthread+0x137/0x150
> > > [ 2449.945430]  ? __kthread_bind_mask+0x60/0x60
> > > [ 2449.945666]  ret_from_fork+0x1f/0x30
> > >
> > > it happens when you run btrfs/060.  Please make sure to run xfstests 
> > > against
> > > patches before you submit them upstream.  Thanks,
> > >
> > > Josef
> >
> > Umm... I ran the xftests against v1 patch and didn't get that panic.
>
> It could have been caused by my fixups to v2 and I can reproduce the
> crash now too. I can't see any difference besides the u64/int switch and
> the 'goto out' removal in btrfs_bio_fits_in_stripe.

The problem is caused by what I mentioned earlier today:

The value of "logical" must be set at the start of each iteration of
the loop at btrfs_submit_direct(),
and not before starting the loop, since the start sector is
incremented at the end of each iteration of the loop.




-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

Re: [PATCH] vio: make remove callback return void

2021-01-29 Thread Tyrel Datwyler

On 1/27/21 1:50 PM, Uwe Kleine-König wrote:
> The driver core ignores the return value of struct bus_type::remove()
> because there is only little that can be done. To simplify the quest to
> make this function return void, let struct vio_driver::remove() return
> void, too. All users already unconditionally return 0, this commit makes
> it obvious that returning an error code is a bad idea and makes it
> obvious for future driver authors that returning an error code isn't
> intended.
> 
> Note there are two nominally different implementations for a vio bus:
> one in arch/sparc/kernel/vio.c and the other in
> arch/powerpc/platforms/pseries/vio.c. I didn't care to check which
> driver is using which of these busses (or if even some of them can be
> used with both) and simply adapt all drivers and the two bus codes in
> one go.
> 
> Note that for the powerpc implementation there is a semantical change:
> Before this patch for a device that was bound to a driver without a
> remove callback vio_cmo_bus_remove(viodev) wasn't called. As the device
> core still considers the device unbound after vio_bus_remove() returns
> calling this unconditionally is the consistent behaviour which is
> implemented here.
> 
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Tyrel Datwyler 

> ---
> Hello,
> 
> note that this change depends on
> https://lore.kernel.org/r/20210121062005.53271-1-...@linux.ibm.com which 
> removes
> an (ignored) return -EBUSY in drivers/net/ethernet/ibm/ibmvnic.c.
> I don't know when/if this latter patch will be applied, so it might take
> some time until my patch can go in.
> 
> Best regards
> Uwe
> 
>  arch/powerpc/include/asm/vio.h   | 2 +-
>  arch/powerpc/platforms/pseries/vio.c | 7 +++
>  arch/sparc/include/asm/vio.h | 2 +-
>  arch/sparc/kernel/ds.c   | 6 --
>  arch/sparc/kernel/vio.c  | 4 ++--
>  drivers/block/sunvdc.c   | 3 +--
>  drivers/char/hw_random/pseries-rng.c | 3 +--
>  drivers/char/tpm/tpm_ibmvtpm.c   | 4 +---
>  drivers/crypto/nx/nx-842-pseries.c   | 4 +---
>  drivers/crypto/nx/nx.c   | 4 +---
>  drivers/misc/ibmvmc.c| 4 +---
>  drivers/net/ethernet/ibm/ibmveth.c   | 4 +---
>  drivers/net/ethernet/ibm/ibmvnic.c   | 4 +---
>  drivers/net/ethernet/sun/ldmvsw.c| 4 +---
>  drivers/net/ethernet/sun/sunvnet.c   | 3 +--
>  drivers/scsi/ibmvscsi/ibmvfc.c   | 3 +--
>  drivers/scsi/ibmvscsi/ibmvscsi.c | 4 +---
>  drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 4 +---
>  drivers/tty/hvc/hvcs.c   | 3 +--
>  drivers/tty/vcc.c| 4 +---
>  20 files changed, 22 insertions(+), 54 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/vio.h b/arch/powerpc/include/asm/vio.h
> index 0cf52746531b..721c0d6715ac 100644
> --- a/arch/powerpc/include/asm/vio.h
> +++ b/arch/powerpc/include/asm/vio.h
> @@ -113,7 +113,7 @@ struct vio_driver {
>   const char *name;
>   const struct vio_device_id *id_table;
>   int (*probe)(struct vio_dev *dev, const struct vio_device_id *id);
> - int (*remove)(struct vio_dev *dev);
> + void (*remove)(struct vio_dev *dev);
>   /* A driver must have a get_desired_dma() function to
>* be loaded in a CMO environment if it uses DMA.
>*/
> diff --git a/arch/powerpc/platforms/pseries/vio.c 
> b/arch/powerpc/platforms/pseries/vio.c
> index b2797cfe4e2b..9cb4fc839fd5 100644
> --- a/arch/powerpc/platforms/pseries/vio.c
> +++ b/arch/powerpc/platforms/pseries/vio.c
> @@ -1261,7 +1261,6 @@ static int vio_bus_remove(struct device *dev)
>   struct vio_dev *viodev = to_vio_dev(dev);
>   struct vio_driver *viodrv = to_vio_driver(dev->driver);
>   struct device *devptr;
> - int ret = 1;
>  
>   /*
>* Hold a reference to the device after the remove function is called
> @@ -1270,13 +1269,13 @@ static int vio_bus_remove(struct device *dev)
>   devptr = get_device(dev);
>  
>   if (viodrv->remove)
> - ret = viodrv->remove(viodev);
> + viodrv->remove(viodev);
>  
> - if (!ret && firmware_has_feature(FW_FEATURE_CMO))
> + if (firmware_has_feature(FW_FEATURE_CMO))
>   vio_cmo_bus_remove(viodev);
>  
>   put_device(devptr);
> - return ret;
> + return 0;
>  }
>  
>  /**
> diff --git a/arch/sparc/include/asm/vio.h b/arch/sparc/include/asm/vio.h
> index 059f0eb678e0..8a1a83bbb6d5 100644
> --- a/arch/sparc/include/asm/vio.h
> +++ b/arch/sparc/include/asm/vio.h
> @@ -362,7 +362,7 @@ struct vio_driver {
>   struct list_headnode;
>   const struct vio_device_id  *id_table;
>   int (*probe)(struct vio_dev *dev, const struct vio_device_id *id);
> - int (*remove)(struct vio_dev *dev);
> + void (*remove)(struct vio_dev *dev);
>   void (*shutdown)(struct vio_dev *dev);
>   unsigned long   driver_data;
>   struct

Re: [REGRESSION] "ALSA: HDA: Early Forbid of runtime PM" broke my laptop's internal audio

2021-01-29 Thread Takashi Iwai

On Fri, 29 Jan 2021 18:24:16 +0100,
Michael Catanzaro wrote:
> 
> On Fri, Jan 29, 2021 at 5:17 pm, Takashi Iwai  wrote:
> > --- a/sound/pci/hda/hda_intel.c
> > +++ b/sound/pci/hda/hda_intel.c
> > @@ -2217,8 +2217,6 @@ static const struct snd_pci_quirk
> > power_save_denylist[] = {
> > /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
> > SND_PCI_QUIRK(0x1043, 0x8733, "Asus Prime X370-Pro", 0),
> > /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
> > -   SND_PCI_QUIRK(0x1558, 0x6504, "Clevo W65_67SB", 0),
> > -   /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
> > SND_PCI_QUIRK(0x1028, 0x0497, "Dell Precision T3600", 0),
> > /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
> > /* Note the P55A-UD3 and Z87-D3HP share the subsys id for the
> > HDA dev */
> 
> Hi,
> 
> This patch works fine on my laptop. I have no clue whether that means
> it's really safe to remove the quirk. I've never noticed any clicking
> noise myself, but I understand it has been a problem for other
> System76 laptops.

If you find no noticeable problem, that's fine, and I believe we can
drop from the deny list.  But it's no urgent issue and fit well as a
5.12 material.  Will submit a proper patch later.


thanks,

Takashi

Re: [PATCH] drm/amd/display: Simplify bool conversion

2021-01-29 Thread Alex Deucher

On Thu, Jan 28, 2021 at 2:45 PM Abaci Team
 wrote:
>
> Fix the following coccicheck warning:
> ./drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:3137:35-40:
> WARNING: conversion to bool not needed here
>
> Reported-by: Abaci Robot 
> Suggested-by: Yang Li 
> Signed-off-by: Abaci Team 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> index 017b67b8..fc03d91 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> @@ -3134,7 +3134,7 @@ void dcn10_setup_stereo(struct pipe_ctx *pipe_ctx, 
> struct dc *dc)
>
> pipe_ctx->stream_res.opp->funcs->opp_program_stereo(
> pipe_ctx->stream_res.opp,
> -   flags.PROGRAM_STEREO == 1 ? true:false,
> +   flags.PROGRAM_STEREO == 1,
> >timing);
>
> pipe_ctx->stream_res.tg->funcs->program_stereo(
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/2] i2c: i2c-amd-mp2: Clean up driver

2021-01-29 Thread mail

From: Richard Neumann 

Clean up i2c-amd-mp2-{pci,plat} drivers:
* Use pci_* logging functions provided by the kernel's PCI API.
* Remove unused macros.
* Remove useless __func__ from logging.

Changes since v1:
* Remove useless __func__ from logging.
* Assign pci_dev to local variable where applicable.

Richard Neumann (2):
  i2c: i2c-amd-mp2: Remove NIH logging functions
  i2c: i2c-amd-mp2: Remove unused macro

 drivers/i2c/busses/i2c-amd-mp2-pci.c  | 53 +--
 drivers/i2c/busses/i2c-amd-mp2-plat.c |  3 +-
 drivers/i2c/busses/i2c-amd-mp2.h  |  6 ---
 3 files changed, 27 insertions(+), 35 deletions(-)

-- 
2.30.0

Re: [PATCH V6] x86/mm: Tracking linear mapping split events

2021-01-29 Thread Johannes Weiner

On Thu, Jan 28, 2021 at 03:34:30PM -0800, Saravanan D wrote:
> To help with debugging the sluggishness caused by TLB miss/reload,
> we introduce monotonic hugepage [direct mapped] split event counts since
> system state: SYSTEM_RUNNING to be displayed as part of
> /proc/vmstat in x86 servers
> 
> The lifetime split event information will be displayed at the bottom of
> /proc/vmstat
> 
> swap_ra 0
> swap_ra_hit 0
> direct_map_level2_splits 94
> direct_map_level3_splits 4
> nr_unstable 0
> 
> 
> One of the many lasting sources of direct hugepage splits is kernel
> tracing (kprobes, tracepoints).
> 
> Note that the kernel's code segment [512 MB] points to the same
> physical addresses that have been already mapped in the kernel's
> direct mapping range.
> 
> Source : Documentation/x86/x86_64/mm.rst
> 
> When we enable kernel tracing, the kernel has to modify
> attributes/permissions
> of the text segment hugepages that are direct mapped causing them to
> split.
> 
> Kernel's direct mapped hugepages do not coalesce back after split and
> remain in place for the remainder of the lifetime.
> 
> An instance of direct page splits when we turn on
> dynamic kernel tracing
> 
> cat /proc/vmstat | grep -i direct_map_level
> direct_map_level2_splits 784
> direct_map_level3_splits 12
> bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @ [pid, comm] =
> count(); }'
> cat /proc/vmstat | grep -i
> direct_map_level
> direct_map_level2_splits 789
> direct_map_level3_splits 12
> 
> 
> Signed-off-by: Saravanan D 

Acked-by: Johannes Weiner

[PATCH v2 2/2] i2c: i2c-amd-mp2: Remove unused macro

2021-01-29 Thread mail

From: Richard Neumann 

Remove unused work_amd_i2c_common macro.

Signed-off-by: Richard Neumann 
---
 drivers/i2c/busses/i2c-amd-mp2.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-amd-mp2.h b/drivers/i2c/busses/i2c-amd-mp2.h
index 6b91e285745d..ddecd0c88656 100644
--- a/drivers/i2c/busses/i2c-amd-mp2.h
+++ b/drivers/i2c/busses/i2c-amd-mp2.h
@@ -185,9 +185,6 @@ struct amd_mp2_dev {
unsigned int probed;
 };
 
-#define work_amd_i2c_common(__work) \
-   container_of(__work, struct amd_i2c_common, work.work)
-
 /* PCIe communication driver */
 
 int amd_mp2_rw(struct amd_i2c_common *i2c_common, enum i2c_cmd reqcmd);
-- 
2.30.0

[PATCH v2 1/2] i2c: i2c-amd-mp2: Remove NIH logging functions

2021-01-29 Thread mail

From: Richard Neumann 

Use pci_{info,warn,err,dbg} functions of the kernel's PCI API.
Remove unnecessary ndev_pdev, ndev_name and ndev_dev macros.
Remove useless __func__ from logging.

Signed-off-by: Richard Neumann 
---
 drivers/i2c/busses/i2c-amd-mp2-pci.c  | 53 +--
 drivers/i2c/busses/i2c-amd-mp2-plat.c |  3 +-
 drivers/i2c/busses/i2c-amd-mp2.h  |  3 --
 3 files changed, 27 insertions(+), 32 deletions(-)

diff --git a/drivers/i2c/busses/i2c-amd-mp2-pci.c 
b/drivers/i2c/busses/i2c-amd-mp2-pci.c
index cd3fd5ee5f65..1067932f2457 100644
--- a/drivers/i2c/busses/i2c-amd-mp2-pci.c
+++ b/drivers/i2c/busses/i2c-amd-mp2-pci.c
@@ -30,7 +30,7 @@ static void amd_mp2_c2p_mutex_unlock(struct amd_i2c_common 
*i2c_common)
struct amd_mp2_dev *privdata = i2c_common->mp2_dev;
 
if (unlikely(privdata->c2p_lock_busid != i2c_common->bus_id)) {
-   dev_warn(ndev_dev(privdata),
+   pci_warn(privdata->pci_dev,
 "bus %d attempting to unlock C2P locked by bus %d\n",
 i2c_common->bus_id, privdata->c2p_lock_busid);
return;
@@ -59,8 +59,7 @@ int amd_mp2_bus_enable_set(struct amd_i2c_common *i2c_common, 
bool enable)
struct amd_mp2_dev *privdata = i2c_common->mp2_dev;
union i2c_cmd_base i2c_cmd_base;
 
-   dev_dbg(ndev_dev(privdata), "%s id: %d\n", __func__,
-   i2c_common->bus_id);
+   pci_dbg(privdata->pci_dev, "id: %d\n", i2c_common->bus_id);
 
i2c_cmd_base.ul = 0;
i2c_cmd_base.s.i2c_cmd = enable ? i2c_enable : i2c_disable;
@@ -111,20 +110,20 @@ EXPORT_SYMBOL_GPL(amd_mp2_rw);
 static void amd_mp2_pci_check_rw_event(struct amd_i2c_common *i2c_common)
 {
struct amd_mp2_dev *privdata = i2c_common->mp2_dev;
+   struct pci_dev *pdev = privdata->pci_dev;
int len = i2c_common->eventval.r.length;
u32 slave_addr = i2c_common->eventval.r.slave_addr;
bool err = false;
 
if (unlikely(len != i2c_common->msg->len)) {
-   dev_err(ndev_dev(privdata),
+   pci_err(pdev,
"length %d in event doesn't match buffer length %d!\n",
len, i2c_common->msg->len);
err = true;
}
 
if (unlikely(slave_addr != i2c_common->msg->addr)) {
-   dev_err(ndev_dev(privdata),
-   "unexpected slave address %x (expected: %x)!\n",
+   pci_err(pdev, "unexpected slave address %x (expected: %x)!\n",
slave_addr, i2c_common->msg->addr);
err = true;
}
@@ -136,13 +135,14 @@ static void amd_mp2_pci_check_rw_event(struct 
amd_i2c_common *i2c_common)
 static void __amd_mp2_process_event(struct amd_i2c_common *i2c_common)
 {
struct amd_mp2_dev *privdata = i2c_common->mp2_dev;
+   struct pci_dev *pdev = privdata->pci_dev;
enum status_type sts = i2c_common->eventval.r.status;
enum response_type res = i2c_common->eventval.r.response;
int len = i2c_common->eventval.r.length;
 
if (res != command_success) {
if (res != command_failed)
-   dev_err(ndev_dev(privdata), "invalid response to i2c 
command!\n");
+   pci_err(pdev, "invalid response to i2c command!\n");
return;
}
 
@@ -155,22 +155,22 @@ static void __amd_mp2_process_event(struct amd_i2c_common 
*i2c_common)
  privdata->mmio + AMD_C2P_MSG2,
  len);
} else if (sts != i2c_readfail_event) {
-   dev_err(ndev_dev(privdata),
-   "invalid i2c status after read (%d)!\n", sts);
+   pci_err(pdev, "invalid i2c status after read (%d)!\n",
+   sts);
}
break;
case i2c_write:
if (sts == i2c_writecomplete_event)
amd_mp2_pci_check_rw_event(i2c_common);
else if (sts != i2c_writefail_event)
-   dev_err(ndev_dev(privdata),
-   "invalid i2c status after write (%d)!\n", sts);
+   pci_err(pdev, "invalid i2c status after write (%d)!\n",
+   sts);
break;
case i2c_enable:
if (sts == i2c_busenable_complete)
i2c_common->cmd_success = true;
else if (sts != i2c_busenable_failed)
-   dev_err(ndev_dev(privdata),
+   pci_err(pdev,
"invalid i2c status after bus enable (%d)!\n",
sts);
break;
@@ -178,7 +178,7 @@ static void __amd_mp2_process_event(struct amd_i2c_common 
*i2c_common)
if (sts == i2c_busdisable_complete)

Re: [PATCH][next] drm/amdgpu: Fix memory leak of object caps on error return paths

2021-01-29 Thread Alex Deucher

On Fri, Jan 29, 2021 at 7:08 AM Colin King  wrote:
>
> From: Colin Ian King 
>
> Currently there are three error return paths that don't kfree object
> caps.  Fix this by performing the allocation of caps after the checks
> and error return paths to avoid the premature allocation and memory
> leaking.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: 555fc7fbb2a2 ("drm/amdgpu: add INFO ioctl support for querying video 
> caps")
> Signed-off-by: Colin Ian King 

Applied.  Thanks!

Alex


> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 84b666fcfaf6..730f4ac7487b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -988,10 +988,6 @@ int amdgpu_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *filp)
> struct drm_amdgpu_info_video_caps *caps;
> int r;
>
> -   caps = kzalloc(sizeof(*caps), GFP_KERNEL);
> -   if (!caps)
> -   return -ENOMEM;
> -
> switch (info->video_cap.type) {
> case AMDGPU_INFO_VIDEO_CAPS_DECODE:
> r = amdgpu_asic_query_video_codecs(adev, false, 
> );
> @@ -1009,6 +1005,11 @@ int amdgpu_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *filp)
>   info->video_cap.type);
> return -EINVAL;
> }
> +
> +   caps = kzalloc(sizeof(*caps), GFP_KERNEL);
> +   if (!caps)
> +   return -ENOMEM;
> +
> for (i = 0; i < codecs->codec_count; i++) {
> int idx = codecs->codec_array[i].codec_type;
>
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: dax alignment problem on arm64 (and other achitectures)

2021-01-29 Thread Pavel Tatashin

On Fri, Jan 29, 2021 at 2:12 PM Pavel Tatashin
 wrote:
>
> On Fri, Jan 29, 2021 at 2:06 PM Pavel Tatashin
>  wrote:
> >
> > > > Definitely, but we should try figuring out what's going on here. I
> > > > assume on x86-64 it behaves differently?
> > >
> > > Yes, we should root cause. I highly suspect that there is somewhere
> > > alignment miscalculations happen that cause this memory waste with the
> > > offset 16M. I am also not sure why the 2M label size was increased,
> > > and  why 16M is now an alignment requirement.
> >
> > This appears to be because even if we set vmemmap to be outside of the
> > dax device, the alignment calculates the maximum size of vmemmap for
> > this device, and subtracts it from the devdax size.
> > See [1], line 795 is where this offset is calculated.
> >
> > This also explains why with 64K pages, the 16M offset worked: because
> > fewer struct pages were able to fit within 16M - label size.
> >
> > [1] 
> > https://soleen.com/source/xref/linux/drivers/nvdimm/pfn_devs.c?r=b7b3c01b=18459=718#795
>
> Actually, strike the previous e-mail. The extra space is when we
> reserve vmemmap from devdax. IFF we do it from mem, the extra space is
> not added. Now, this alignment makes total sense.

commit 2522afb86a8cceba0f67dbf05772d21b76d79f06
Author: Dan Williams 
Date:   Thu Jan 30 12:06:23 2020 -0800

libnvdimm/region: Introduce an 'align' attribute


This is the patch that introduced the 16M alignment.

/*
 * PowerPC requires this alignment for memremap_pages(). All other archs
 * should be ok with SUBSECTION_SIZE (see memremap_compat_align()).
 */
#define MEMREMAP_COMPAT_ALIGN_MAX SZ_16M

static unsigned long default_align(struct nd_region *nd_region)
{
unsigned long align;
int i, mappings;
u32 remainder;

if (is_nd_blk(_region->dev))
align = PAGE_SIZE;
else
align = MEMREMAP_COMPAT_ALIGN_MAX;

Dan, is this logic correct? Why is_nd_pmem() cannot be set to
SUBSECTION_SIZE alignment?

Thank you,
Pasha

>
> Pasha

Re: [PATCH v18 02/25] x86/cet/shstk: Add Kconfig option for user-mode control-flow protection

2021-01-29 Thread Dave Hansen

On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
> + help
> +   Control-flow protection is a hardware security hardening feature
> +   that detects function-return address or jump target changes by
> +   malicious code.

It's not really one feature.  I also think it's not worth talking about
shadow stacks or indirect branch tracking in *here*.  Leave that for
Documentation/.

Just say:

Control-flow protection is a set of hardware features which
place additional restrictions on indirect branches.  These help
mitigate ROP attacks.

... and add more in the IBT patches.

>  Applications must be enabled to use it, and old
> +   userspace does not get protection "for free".
> +   Support for this feature is present on processors released in
> +   2020 or later.  Enabling this feature increases kernel text size
> +   by 3.7 KB.

Did any CPUs ever get released that have this?  If so, name them.  If
not, time to change this to 2021, I think.

[PATCH v6 0/2] Kbuild: DWARF v5 support

DWARF v5 is the latest standard of the DWARF debug info format.

DWARF5 wins significantly in terms of size and especially so when mixed
with compression (CONFIG_DEBUG_INFO_COMPRESSED).

Link: http://www.dwarfstd.org/doc/DWARF5.pdf

Patch 1 is a cleanup that lays the ground work and isn't DWARF
v5 specific.
Patch 2 implements Kconfig and Kbuild support for DWARFv5.

Changes from v5:
* Drop previous patch 1, it has been accepted into kbuild:

https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44
* Trying to set -Wa,-gdwarf-4 in the earlier patch was the source of
additional complexity. Drop it that part of the patch. We can revisit
clang without the integrated assembler setting -Wa,-gdwarf-4 later.
That is a separate problem from generally supporting DWARF v5.
* Rework the final patch for clang without the integrated assembler.
-Wa,-gdwarf-5 is required for DWARF5 in that case otherwise GAS will
not accept the assembler directives clang produces from C code when
generating asm.

Changes from v4:
* drop set -e from script as per Nathan.
* add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat.
* Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and
Masahiro. Sorry it took me a few tries to understand the point (I
might still not), but it looks much cleaner this way. Sorry Nathan, I
did not carry forward your previous reviews as a result, but I would
appreciate if you could look again.
* Add Nathan's reviewed by tag to patch 1.
* Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5
binutils addition later, and BTF issue.
* I still happen to see a pahole related error spew for the combination
of:
* LLVM=1
* LLVM_IAS=1
* CONFIG_DEBUG_INFO_DWARF4
* CONFIG_DEBUG_INFO_BTF
Though they're non-fatal to the build. I'm not sure yet why removing
any one of the above prevents the warning spew. Maybe we'll need a v6.

Changes from v3:

Changes as per Arvind:
* only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds.
* add -gdwarf-5 to Kconfig shell script.
* only run Kconfig shell script for Clang.

Apologies to Sedat and Nathan; I appreciate previous testing/review, but
I did no carry forward your Tested-by and Reviewed-by tags, as the
patches have changed too much IMO.

Changes from v2:
* Drop two of the earlier patches that have been accepted already.
* Add measurements with GCC 10.2 to commit message.
* Update help text as per Arvind with help from Caroline.
* Improve case/wording between DWARF Versions as per Masahiro.

Changes from the RFC:
* split patch in 3 patch series, include Fangrui's patch, too.
* prefer `DWARF vX` format, as per Fangrui.
* use spaces between assignment in Makefile as per Masahiro.
* simplify setting dwarf-version-y as per Masahiro.
* indent `prompt` in Kconfig change as per Masahiro.
* remove explicit default in Kconfig as per Masahiro.
* add comments to test_dwarf5_support.sh.
* change echo in test_dwarf5_support.sh as per Masahiro.
* remove -u from test_dwarf5_support.sh as per Masahiro.
* add a -gdwarf-5 cc-option check to Kconfig as per Jakub.

Nick Desaulniers (2):
Kbuild: make DWARF version a choice
Kbuild: implement support for DWARF v5

Makefile | 16 ++--
include/asm-generic/vmlinux.lds.h | 6 -
lib/Kconfig.debug | 41 ++-
scripts/test_dwarf5_support.sh| 8 ++
4 files changed, 62 insertions(+), 9 deletions(-)
create mode 100755 scripts/test_dwarf5_support.sh

--
2.30.0.365.g02bc693789-goog

[PATCH v6 1/2] Kbuild: make DWARF version a choice

Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
way that's forward compatible with existing configs, and makes adding
future versions more straightforward.

Suggested-by: Arvind Sankar 
Suggested-by: Fangrui Song 
Suggested-by: Nathan Chancellor 
Suggested-by: Masahiro Yamada 
Signed-off-by: Nick Desaulniers 
---
 Makefile  |  6 +++---
 lib/Kconfig.debug | 21 -
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index 95ab9856f357..20141cd9319e 100644
--- a/Makefile
+++ b/Makefile
@@ -830,9 +830,9 @@ ifneq ($(LLVM_IAS),1)
 KBUILD_AFLAGS  += -Wa,-gdwarf-2
 endif
 
-ifdef CONFIG_DEBUG_INFO_DWARF4
-DEBUG_CFLAGS   += -gdwarf-4
-endif
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+DEBUG_CFLAGS   += -gdwarf-$(dwarf-version-y)
 
 ifdef CONFIG_DEBUG_INFO_REDUCED
 DEBUG_CFLAGS   += $(call cc-option, -femit-struct-debug-baseonly) \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e906ea906cb7..1850728b23e6 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -256,13 +256,24 @@ config DEBUG_INFO_SPLIT
  to know about the .dwo files and include them.
  Incompatible with older versions of ccache.
 
+choice
+   prompt "DWARF version"
+   help
+ Which version of DWARF debug info to emit.
+
+config DEBUG_INFO_DWARF2
+   bool "Generate DWARF Version 2 debuginfo"
+   help
+ Generate DWARF v2 debug info.
+
 config DEBUG_INFO_DWARF4
-   bool "Generate dwarf4 debuginfo"
+   bool "Generate DWARF Version 4 debuginfo"
help
- Generate dwarf4 debug info. This requires recent versions
- of gcc and gdb. It makes the debug information larger.
- But it significantly improves the success of resolving
- variables in gdb on optimized code.
+ Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
+ It makes the debug information larger, but it significantly
+ improves the success of resolving variables in gdb on optimized code.
+
+endchoice # "DWARF version"
 
 config DEBUG_INFO_BTF
bool "Generate BTF typeinfo"
-- 
2.30.0.365.g02bc693789-goog

[PATCH v8 02/14] staging: hikey9xx: hi6421v600-regulator: use some regmap helpers

Now that the driver was ported to use regmap, let's use
some help functions in order to simplify the code a little
bit.

Suggested-by: Mark Brown 
Signed-off-by: Mauro Carvalho Chehab 
---
 .../staging/hikey9xx/hi6421v600-regulator.c   | 45 ++-
 1 file changed, 3 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/hikey9xx/hi6421v600-regulator.c 
b/drivers/staging/hikey9xx/hi6421v600-regulator.c
index 9e319fa11137..7090107b9ec2 100644
--- a/drivers/staging/hikey9xx/hi6421v600-regulator.c
+++ b/drivers/staging/hikey9xx/hi6421v600-regulator.c
@@ -95,17 +95,6 @@ static const unsigned int ldo34_voltages[] = {
.eco_uA = ecoamp,  \
}
 
-static int hi6421_spmi_regulator_is_enabled(struct regulator_dev *rdev)
-{
-   struct hi6421_spmi_reg_info *sreg = rdev_get_drvdata(rdev);
-   struct hi6421_spmi_pmic *pmic = sreg->pmic;
-   u32 reg_val;
-
-   regmap_read(pmic->map, rdev->desc->enable_reg, _val);
-
-   return ((reg_val & rdev->desc->enable_mask) != 0);
-}
-
 static int hi6421_spmi_regulator_enable(struct regulator_dev *rdev)
 {
struct hi6421_spmi_reg_info *sreg = rdev_get_drvdata(rdev);
@@ -136,34 +125,6 @@ static int hi6421_spmi_regulator_disable(struct 
regulator_dev *rdev)
  rdev->desc->enable_mask, 0);
 }
 
-static int hi6421_spmi_regulator_get_voltage_sel(struct regulator_dev *rdev)
-{
-   struct hi6421_spmi_reg_info *sreg = rdev_get_drvdata(rdev);
-   struct hi6421_spmi_pmic *pmic = sreg->pmic;
-   u32 reg_val;
-
-   regmap_read(pmic->map, rdev->desc->vsel_reg, _val);
-
-   return (reg_val & rdev->desc->vsel_mask) >> (ffs(rdev->desc->vsel_mask) 
- 1);
-}
-
-static int hi6421_spmi_regulator_set_voltage_sel(struct regulator_dev *rdev,
-unsigned int selector)
-{
-   struct hi6421_spmi_reg_info *sreg = rdev_get_drvdata(rdev);
-   struct hi6421_spmi_pmic *pmic = sreg->pmic;
-   u32 reg_val;
-
-   if (selector >= rdev->desc->n_voltages)
-   return -EINVAL;
-
-   reg_val = selector << (ffs(rdev->desc->vsel_mask) - 1);
-
-   /* set voltage selector */
-   return regmap_update_bits(pmic->map, rdev->desc->vsel_reg,
- rdev->desc->vsel_mask, reg_val);
-}
-
 static unsigned int hi6421_spmi_regulator_get_mode(struct regulator_dev *rdev)
 {
struct hi6421_spmi_reg_info *sreg = rdev_get_drvdata(rdev);
@@ -214,13 +175,13 @@ hi6421_spmi_regulator_get_optimum_mode(struct 
regulator_dev *rdev,
 }
 
 static const struct regulator_ops hi6421_spmi_ldo_rops = {
-   .is_enabled = hi6421_spmi_regulator_is_enabled,
+   .is_enabled = regulator_is_enabled_regmap,
.enable = hi6421_spmi_regulator_enable,
.disable = hi6421_spmi_regulator_disable,
.list_voltage = regulator_list_voltage_table,
.map_voltage = regulator_map_voltage_iterate,
-   .get_voltage_sel = hi6421_spmi_regulator_get_voltage_sel,
-   .set_voltage_sel = hi6421_spmi_regulator_set_voltage_sel,
+   .get_voltage_sel = regulator_get_voltage_sel_regmap,
+   .set_voltage_sel = regulator_set_voltage_sel_regmap,
.get_mode = hi6421_spmi_regulator_get_mode,
.set_mode = hi6421_spmi_regulator_set_mode,
.get_optimum_mode = hi6421_spmi_regulator_get_optimum_mode,
-- 
2.29.2

[PATCH v8 12/14] mfd: hi6421-spmi-pmic: move driver from staging

This driver is ready for mainstream. So, move it out of staging.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../mfd}/hisilicon,hi6421-spmi-pmic.yaml   |  0
 MAINTAINERS|  7 +++
 drivers/mfd/Kconfig| 16 
 drivers/mfd/Makefile   |  1 +
 .../hikey9xx => mfd}/hi6421-spmi-pmic.c|  0
 drivers/staging/hikey9xx/Kconfig   | 18 --
 drivers/staging/hikey9xx/Makefile  |  1 -
 7 files changed, 24 insertions(+), 19 deletions(-)
 rename {drivers/staging/hikey9xx => 
Documentation/devicetree/bindings/mfd}/hisilicon,hi6421-spmi-pmic.yaml (100%)
 rename drivers/{staging/hikey9xx => mfd}/hi6421-spmi-pmic.c (100%)

diff --git a/drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml 
b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
similarity index 100%
rename from drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml
rename to Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
diff --git a/MAINTAINERS b/MAINTAINERS
index 406c2340f221..241f11b7d48a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8085,6 +8085,13 @@ S:   Maintained
 F: 
Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
 F: drivers/spmi/hisi-spmi-controller.c
 
+HISILICON SPMI PMIC DRIVER FOR HIKEY 6421v600
+M: Mauro Carvalho Chehab 
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
+F: drivers/mfd/hi6421-spmi-pmic.c
+
 HISILICON STAGING DRIVERS FOR HIKEY 960/970
 M: Mauro Carvalho Chehab 
 L: de...@driverdev.osuosl.org
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index bdfce7b15621..1ad04fb6eefa 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -509,6 +509,22 @@ config MFD_HI6421_PMIC
  menus in order to enable them.
  We communicate with the Hi6421 via memory-mapped I/O.
 
+config MFD_HI6421_SPMI
+   tristate "HiSilicon Hi6421v600 SPMI PMU/Codec IC"
+   depends on OF
+   depends on SPMI
+   select MFD_CORE
+   select REGMAP_SPMI
+   help
+ Add support for HiSilicon Hi6421v600 SPMI PMIC. Hi6421 includes
+ multi-functions, such as regulators, RTC, codec, Coulomb counter,
+ etc.
+
+ This driver includes core APIs _only_. You have to select
+ individual components like voltage regulators under corresponding
+ menus in order to enable them.
+ We communicate with the Hi6421v600 via a SPMI bus.
+
 config MFD_HI655X_PMIC
tristate "HiSilicon Hi655X series PMU/Codec IC"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 14fdb188af02..b64e89ade44b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -234,6 +234,7 @@ obj-$(CONFIG_MFD_IPAQ_MICRO)+= ipaq-micro.o
 obj-$(CONFIG_MFD_IQS62X)   += iqs62x.o
 obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
 obj-$(CONFIG_MFD_HI6421_PMIC)  += hi6421-pmic-core.o
+obj-$(CONFIG_MFD_HI6421_SPMI)  += hi6421-spmi-pmic.o
 obj-$(CONFIG_MFD_HI655X_PMIC)   += hi655x-pmic.o
 obj-$(CONFIG_MFD_DLN2) += dln2.o
 obj-$(CONFIG_MFD_RT5033)   += rt5033.o
diff --git a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c 
b/drivers/mfd/hi6421-spmi-pmic.c
similarity index 100%
rename from drivers/staging/hikey9xx/hi6421-spmi-pmic.c
rename to drivers/mfd/hi6421-spmi-pmic.c
diff --git a/drivers/staging/hikey9xx/Kconfig b/drivers/staging/hikey9xx/Kconfig
index 49ce28ff55b2..b17c047aa700 100644
--- a/drivers/staging/hikey9xx/Kconfig
+++ b/drivers/staging/hikey9xx/Kconfig
@@ -1,23 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-# to be placed at drivers/mfd
-config MFD_HI6421_SPMI
-   tristate "HiSilicon Hi6421v600 SPMI PMU/Codec IC"
-   depends on HAS_IOMEM
-   depends on OF
-   depends on SPMI
-   select MFD_CORE
-   select REGMAP_SPMI
-   help
- Add support for HiSilicon Hi6421v600 SPMI PMIC. Hi6421 includes
- multi-functions, such as regulators, RTC, codec, Coulomb counter,
- etc.
-
- This driver includes core APIs _only_. You have to select
- individual components like voltage regulators under corresponding
- menus in order to enable them.
- We communicate with the Hi6421v600 via a SPMI bus.
-
 # to be placed at drivers/regulator
 config REGULATOR_HI6421V600
tristate "HiSilicon Hi6421v600 PMIC voltage regulator support"
diff --git a/drivers/staging/hikey9xx/Makefile 
b/drivers/staging/hikey9xx/Makefile
index 347880fd378f..4d63184e6086 100644
--- a/drivers/staging/hikey9xx/Makefile
+++ b/drivers/staging/hikey9xx/Makefile
@@ -1,4 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-$(CONFIG_MFD_HI6421_SPMI)  += hi6421-spmi-pmic.o
 obj-$(CONFIG_REGULATOR_HI6421V600) += hi6421v600-regulator.o
-- 
2.29.2

[PATCH v8 05/14] staging: hikey9xx: hi6421-spmi-pmic: cleanup header file

Remove the IRQ list from the header, as this is used only
inside the driver itself. Also, get rid of two unused
defines.

The net result is that only struct hi6421_spmi_pmic remains
on it, as this is used by the regulator driver.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 17 +
 include/linux/mfd/hi6421-spmi-pmic.h| 20 
 2 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c 
b/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
index c8e55b7b08e2..909f7b106af4 100644
--- a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
+++ b/drivers/staging/hikey9xx/hi6421-spmi-pmic.c
@@ -17,6 +17,23 @@
 #include 
 #include 
 
+enum hi6421_spmi_pmic_irq_list {
+   OTMP = 0,
+   VBUS_CONNECT,
+   VBUS_DISCONNECT,
+   ALARMON_R,
+   HOLD_6S,
+   HOLD_1S,
+   POWERKEY_UP,
+   POWERKEY_DOWN,
+   OCP_SCP_R,
+   COUL_R,
+   SIM0_HPD_R,
+   SIM0_HPD_F,
+   SIM1_HPD_R,
+   SIM1_HPD_F,
+   PMIC_IRQ_LIST_MAX,
+};
 /* 8-bit register offset in PMIC */
 #define HISI_MASK_STATE0xff
 
diff --git a/include/linux/mfd/hi6421-spmi-pmic.h 
b/include/linux/mfd/hi6421-spmi-pmic.h
index aa8d5382f559..4d61cb266a18 100644
--- a/include/linux/mfd/hi6421-spmi-pmic.h
+++ b/include/linux/mfd/hi6421-spmi-pmic.h
@@ -14,9 +14,6 @@
 #include 
 #include 
 
-#define HISI_ECO_MODE_ENABLE   (1)
-#define HISI_ECO_MODE_DISABLE  (0)
-
 struct hi6421_spmi_pmic {
struct resource *res;
struct device   *dev;
@@ -29,21 +26,4 @@ struct hi6421_spmi_pmic {
struct regmap   *regmap;
 };
 
-enum hi6421_spmi_pmic_irq_list {
-   OTMP = 0,
-   VBUS_CONNECT,
-   VBUS_DISCONNECT,
-   ALARMON_R,
-   HOLD_6S,
-   HOLD_1S,
-   POWERKEY_UP,
-   POWERKEY_DOWN,
-   OCP_SCP_R,
-   COUL_R,
-   SIM0_HPD_R,
-   SIM0_HPD_F,
-   SIM1_HPD_R,
-   SIM1_HPD_F,
-   PMIC_IRQ_LIST_MAX,
-};
 #endif /* __HISI_PMIC_H */
-- 
2.29.2

Re: [PATCH v18 02/25] x86/cet/shstk: Add Kconfig option for user-mode control-flow protection

2021-01-29 Thread Dave Hansen

On 1/29/21 11:58 AM, Andy Lutomirski wrote:
>> Did any CPUs ever get released that have this?  If so, name them.  If
>> not, time to change this to 2021, I think.
> Zen 3 :)

In that case is there any reason to keep the "depends on CPU_SUP_INTEL"?

Re: [PATCH] Documentation/llvm: Add a section about supported architectures

2021-01-29 Thread Nathan Chancellor

On Wed, Jan 13, 2021 at 05:34:47PM -0700, Nathan Chancellor wrote:
> The most common question around building the Linux kernel with clang is
> "does it work?" and the answer has always been "it depends on your
> architecture, configuration, and LLVM version" with no hard answers for
> users wanting to experiment. LLVM support has significantly improved
> over the past couple of years, resulting in more architectures and
> configurations supported, and continuous integration has made it easier
> to see what works and what does not.
> 
> Add a section that goes over what architectures are supported in the
> current kernel version, how they should be built (with just clang or the
> LLVM utilities as well), and the level of support they receive. This
> will make it easier for people to try out building their kernel with
> LLVM and reporting issues that come about from it.
> 
> Suggested-by: Miguel Ojeda 
> Signed-off-by: Nathan Chancellor 

Jonathan, did you need anything else from me on this, or does Masahiro
need to pick this up?

Cheers,
Nathan

drivers/net/ethernet/intel/e1000/e1000_osdep.h:13: warning: "CONFIG_RAM_BASE" redefined

2021-01-29 Thread kernel test robot

Hi Guo,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   bec4c2968fce2f44ce62d05288a633cd99a722eb
commit: 18c07d23da5a48525b2955aa269b8bb108c19300 csky: Fixup calltrace panic
date:   9 months ago
config: csky-randconfig-r024-20210130 (attached as .config)
compiler: csky-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18c07d23da5a48525b2955aa269b8bb108c19300
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 18c07d23da5a48525b2955aa269b8bb108c19300
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=csky 

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

All warnings (new ones prefixed by >>):

   In file included from drivers/net/ethernet/intel/e1000/e1000_hw.h:11,
from drivers/net/ethernet/intel/e1000/e1000.h:54,
from drivers/net/ethernet/intel/e1000/e1000_main.c:4:
>> drivers/net/ethernet/intel/e1000/e1000_osdep.h:13: warning: 
>> "CONFIG_RAM_BASE" redefined
  13 | #define CONFIG_RAM_BASE 0x6
 | 
   In file included from include/linux/kconfig.h:5,
from :
   ./include/generated/autoconf.h:1771: note: this is the location of the 
previous definition
1771 | #define CONFIG_RAM_BASE 0x0
 | 
--
   In file included from drivers/net/ethernet/intel/e1000/e1000_hw.h:11,
from drivers/net/ethernet/intel/e1000/e1000.h:54,
from drivers/net/ethernet/intel/e1000/e1000_hw.c:8:
>> drivers/net/ethernet/intel/e1000/e1000_osdep.h:13: warning: 
>> "CONFIG_RAM_BASE" redefined
  13 | #define CONFIG_RAM_BASE 0x6
 | 
   In file included from include/linux/kconfig.h:5,
from :
   ./include/generated/autoconf.h:1771: note: this is the location of the 
previous definition
1771 | #define CONFIG_RAM_BASE 0x0
 | 
   drivers/net/ethernet/intel/e1000/e1000_hw.c: In function 
'e1000_phy_init_script':
   drivers/net/ethernet/intel/e1000/e1000_hw.c:132:6: warning: variable 
'ret_val' set but not used [-Wunused-but-set-variable]
 132 |  u32 ret_val;
 |  ^~~
   drivers/net/ethernet/intel/e1000/e1000_hw.c: In function 'e1000_reset_hw':
   drivers/net/ethernet/intel/e1000/e1000_hw.c:380:6: warning: variable 'icr' 
set but not used [-Wunused-but-set-variable]
 380 |  u32 icr;
 |  ^~~
   drivers/net/ethernet/intel/e1000/e1000_hw.c: In function 
'e1000_check_for_link':
   drivers/net/ethernet/intel/e1000/e1000_hw.c:2378:6: warning: variable 
'signal' set but not used [-Wunused-but-set-variable]
2378 |  u32 signal = 0;
 |  ^~
   drivers/net/ethernet/intel/e1000/e1000_hw.c:2374:6: warning: variable 'ctrl' 
set but not used [-Wunused-but-set-variable]
2374 |  u32 ctrl;
 |  ^~~~
   drivers/net/ethernet/intel/e1000/e1000_hw.c:2373:6: warning: variable 'rxcw' 
set but not used [-Wunused-but-set-variable]
2373 |  u32 rxcw = 0;
 |  ^~~~
   drivers/net/ethernet/intel/e1000/e1000_hw.c: In function 
'e1000_clear_hw_cntrs':
   drivers/net/ethernet/intel/e1000/e1000_hw.c:4678:15: warning: variable 
'temp' set but not used [-Wunused-but-set-variable]
4678 |  volatile u32 temp;
 |   ^~~~


vim +/CONFIG_RAM_BASE +13 drivers/net/ethernet/intel/e1000/e1000_osdep.h

5377a4160bb65e drivers/net/e1000/e1000_osdep.h Dirk Brandewie 2011-01-06  12  
5377a4160bb65e drivers/net/e1000/e1000_osdep.h Dirk Brandewie 2011-01-06 @13  
#define CONFIG_RAM_BASE 0x6
5377a4160bb65e drivers/net/e1000/e1000_osdep.h Dirk Brandewie 2011-01-06  14  
#define GBE_CONFIG_OFFSET   0x0
5377a4160bb65e drivers/net/e1000/e1000_osdep.h Dirk Brandewie 2011-01-06  15  

:: The code at line 13 was first introduced by commit
:: 5377a4160bb65ee4dd11b4b1d081d86d56d92bff e1000: Add support for the 
CE4100 reference platform

:: TO: Dirk Brandewie 
:: CC: David S. Miller 

---
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 v6 2/2] Kbuild: implement support for DWARF v5

On Fri, Jan 29, 2021 at 9:48 PM Nick Desaulniers
 wrote:
>
> On Fri, Jan 29, 2021 at 12:41 PM Sedat Dilek  wrote:
> >
> > On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers
> >  wrote:
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 20141cd9319e..bed8b3b180b8 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -832,8 +832,20 @@ endif
> > >
> > >  dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> > >  dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
> > >  DEBUG_CFLAGS   += -gdwarf-$(dwarf-version-y)
> > >
> > > +# If using clang without the integrated assembler, we need to explicitly 
> > > tell
> > > +# GAS that we will be feeding it DWARF v5 assembler directives. Kconfig 
> > > should
> > > +# detect whether the version of GAS supports DWARF v5.
> > > +ifdef CONFIG_CC_IS_CLANG
> > > +ifneq ($(LLVM_IAS),1)
> > > +ifeq ($(dwarf-version-y),5)
> > > +DEBUG_CFLAGS   += -Wa,-gdwarf-5
> >
> > I noticed double "-g -gdwarf-5 -g -gdwarf-5" (a different issue) and
> > that's why I looked again into the top-level Makefile.
>
> That's...unexpected.  I don't see where that could be coming from.
> Can you tell me please what is the precise command line invocation of
> make and which source file you observed this on so that I can
> reproduce?
>

That's everywhere...

$ zstdgrep --color '\-g -gdwarf-5 -g -gdwarf-5'
build-log_5.11.0-rc5-8-amd64-clang12-lto.txt.zst
| wc -l
29529

> > Should this be...?
> >
> > KBUILD_AFLAGS += -Wa,-gdwarf-5
>
> No; under the set of conditions Clang is compiling .c to .S with DWARF
> v5 assembler directives. GAS will choke unless told -gdwarf-5 via
> -Wa,-gdwarf-5 for .c source files, hence it is a C flag, not an A
> flag. A flags are for .S assembler sources, not .c sources.
>

You are right. I mixed again C and A flags.

- Sedat -

Re: [PATCH] drm/i915: Remove unreachable code

2021-01-29 Thread Chris Wilson

Quoting Vinicius Tinti (2021-01-29 18:15:19)
> By enabling -Wunreachable-code-aggressive on Clang the following code
> paths are unreachable.

That code exists as commentary and, especially for sdvo, library
functions that we may need in future.

The ivb-gt1 case => as we now set the gt level for ivb, should we not
enable the optimisation for ivb unaffected by the w/a? Just no one has
taken the time to see if it causes a regression.

For error state, the question remains whether we should revert to
uncompressed data if the compressed stream is larger than the original.
-Chris

Re: [PATCH v6 2/2] Kbuild: implement support for DWARF v5

On Fri, Jan 29, 2021 at 12:55 PM Sedat Dilek  wrote:
>
> On Fri, Jan 29, 2021 at 9:48 PM Nick Desaulniers
>  wrote:
> >
> > On Fri, Jan 29, 2021 at 12:41 PM Sedat Dilek  wrote:
> > >
> > > On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers
> > >  wrote:
> > > >
> > > > diff --git a/Makefile b/Makefile
> > > > index 20141cd9319e..bed8b3b180b8 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -832,8 +832,20 @@ endif
> > > >
> > > >  dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> > > >  dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> > > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
> > > >  DEBUG_CFLAGS   += -gdwarf-$(dwarf-version-y)
> > > >
> > > > +# If using clang without the integrated assembler, we need to 
> > > > explicitly tell
> > > > +# GAS that we will be feeding it DWARF v5 assembler directives. 
> > > > Kconfig should
> > > > +# detect whether the version of GAS supports DWARF v5.
> > > > +ifdef CONFIG_CC_IS_CLANG
> > > > +ifneq ($(LLVM_IAS),1)
> > > > +ifeq ($(dwarf-version-y),5)
> > > > +DEBUG_CFLAGS   += -Wa,-gdwarf-5
> > >
> > > I noticed double "-g -gdwarf-5 -g -gdwarf-5" (a different issue) and
> > > that's why I looked again into the top-level Makefile.
> >
> > That's...unexpected.  I don't see where that could be coming from.
> > Can you tell me please what is the precise command line invocation of
> > make and which source file you observed this on so that I can
> > reproduce?
> >
>
> That's everywhere...
>
> $ zstdgrep --color '\-g -gdwarf-5 -g -gdwarf-5'
> build-log_5.11.0-rc5-8-amd64-clang12-lto.txt.zst
> | wc -l
> 29529

I'm not able to reproduce.

$ make LLVM=1 -j72 V=1 2>&1 | grep dwarf
...
clang ... -g -gdwarf-5 -Wa,-gdwarf-5 ...
...

$ make LLVM=1 LLVM_IAS=1 -j72 V=1 2>&1 | grep dwarf
...
clang ... -g -gdwarf-5 ...
...

Can you tell me please what is the precise command line invocation of
make and which source file you observed this on so that I can
reproduce?
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH RESEND] ata: ahci_brcm: Add back regulators management

2021-01-29 Thread Jens Axboe

On 1/29/21 11:28 AM, Florian Fainelli wrote:
> While reworking the resources management and departing from using
> ahci_platform_enable_resources() which did not allow a proper step
> separation like we need, we unfortunately lost the ability to control
> AHCI regulators. This broke some Broadcom STB systems that do expect
> regulators to be turned on to link up with attached hard drives.

Applied, thanks.

-- 
Jens Axboe

[PATCH v3] Bluetooth: Skip eSCO 2M params when not supported

2021-01-29 Thread Yu Liu

If a peer device doesn't support eSCO 2M we should skip the params that
use it when setting up sync connection since they will always fail.

Signed-off-by: Yu Liu 
Reviewed-by: Abhishek Pandit-Subedi 
---

Changes in v3:
- Use pkt_type instead of adding new field

Changes in v2:
- Fix title

Changes in v1:
- Initial change

 include/net/bluetooth/hci_core.h |  1 +
 net/bluetooth/hci_conn.c | 20 ++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 239ab72f16c6e..71468a9ea798a 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -1237,6 +1237,7 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
 #define lmp_le_capable(dev)((dev)->features[0][4] & LMP_LE)
 #define lmp_sniffsubr_capable(dev) ((dev)->features[0][5] & LMP_SNIFF_SUBR)
 #define lmp_pause_enc_capable(dev) ((dev)->features[0][5] & LMP_PAUSE_ENC)
+#define lmp_esco_2m_capable(dev)   ((dev)->features[0][5] & LMP_EDR_ESCO_2M)
 #define lmp_ext_inq_capable(dev)   ((dev)->features[0][6] & LMP_EXT_INQ)
 #define lmp_le_br_capable(dev) (!!((dev)->features[0][6] & 
LMP_SIMUL_LE_BR))
 #define lmp_ssp_capable(dev)   ((dev)->features[0][6] & LMP_SIMPLE_PAIR)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 07c34c55fc508..357ce0cfbc5c9 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -278,6 +278,20 @@ static void hci_add_sco(struct hci_conn *conn, __u16 
handle)
hci_send_cmd(hdev, HCI_OP_ADD_SCO, sizeof(cp), );
 }
 
+static bool find_next_esco_param(struct hci_conn *conn,
+const struct sco_param *esco_param, int size)
+{
+   for (; conn->attempt <= size; conn->attempt++) {
+   if (lmp_esco_2m_capable(conn->link) ||
+   (esco_param[conn->attempt - 1].pkt_type & ESCO_2EV3))
+   break;
+   BT_DBG("hcon %p skipped attempt %d, eSCO 2M not supported",
+  conn, conn->attempt);
+   }
+
+   return conn->attempt <= size;
+}
+
 bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
 {
struct hci_dev *hdev = conn->hdev;
@@ -299,13 +313,15 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
 
switch (conn->setting & SCO_AIRMODE_MASK) {
case SCO_AIRMODE_TRANSP:
-   if (conn->attempt > ARRAY_SIZE(esco_param_msbc))
+   if (!find_next_esco_param(conn, esco_param_msbc,
+ ARRAY_SIZE(esco_param_msbc)))
return false;
param = _param_msbc[conn->attempt - 1];
break;
case SCO_AIRMODE_CVSD:
if (lmp_esco_capable(conn->link)) {
-   if (conn->attempt > ARRAY_SIZE(esco_param_cvsd))
+   if (!find_next_esco_param(conn, esco_param_cvsd,
+ ARRAY_SIZE(esco_param_cvsd)))
return false;
param = _param_cvsd[conn->attempt - 1];
} else {
-- 
2.30.0.365.g02bc693789-goog

Re: [PATCH v6 2/2] Kbuild: implement support for DWARF v5

2021-01-29 Thread Jakub Jelinek

On Fri, Jan 29, 2021 at 02:05:59PM -0800, Nick Desaulniers wrote:
> Ah, I see.  Then I should update the script I add
> (scripts/test_dwarf5_support.sh) to feature detect that bug, since
> it's the latest of the bunch.  Also, should update my comment to note
> that this requires binutils greater than 2.35.1 (which is what I have,
> which fails, since the backport landed in ... what?!)  How was this
> backported to 2.35
> (https://sourceware.org/bugzilla/show_bug.cgi?id=27195#c12, Jan 26
> 2021) when binutils-2_35_1 was tagged sept 19 2020?  Or will there be
> a binutils 2.35.2 point release?

AFAIK yes, soon.

Jakub

Re: [PATCH v6 2/2] Kbuild: implement support for DWARF v5

On Fri, Jan 29, 2021 at 11:09 PM Nick Desaulniers
 wrote:
>
> On Fri, Jan 29, 2021 at 1:20 PM Sedat Dilek  wrote:
> >
> > On Fri, Jan 29, 2021 at 10:13 PM Sedat Dilek  wrote:
> > >
> > > On Fri, Jan 29, 2021 at 10:09 PM Nick Desaulniers
> > >  wrote:
> > > >
> > > > On Fri, Jan 29, 2021 at 12:55 PM Sedat Dilek  
> > > > wrote:
> > > > >
> > > > > On Fri, Jan 29, 2021 at 9:48 PM Nick Desaulniers
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, Jan 29, 2021 at 12:41 PM Sedat Dilek 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > diff --git a/Makefile b/Makefile
> > > > > > > > index 20141cd9319e..bed8b3b180b8 100644
> > > > > > > > --- a/Makefile
> > > > > > > > +++ b/Makefile
> > > > > > > > @@ -832,8 +832,20 @@ endif
> > > > > > > >
> > > > > > > >  dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> > > > > > > >  dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> > > > > > > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
> > > > > > > >  DEBUG_CFLAGS   += -gdwarf-$(dwarf-version-y)
> > > > > > > >
> > > > > > > > +# If using clang without the integrated assembler, we need to 
> > > > > > > > explicitly tell
> > > > > > > > +# GAS that we will be feeding it DWARF v5 assembler 
> > > > > > > > directives. Kconfig should
> > > > > > > > +# detect whether the version of GAS supports DWARF v5.
> > > > > > > > +ifdef CONFIG_CC_IS_CLANG
> > > > > > > > +ifneq ($(LLVM_IAS),1)
> > > > > > > > +ifeq ($(dwarf-version-y),5)
> > > > > > > > +DEBUG_CFLAGS   += -Wa,-gdwarf-5
> > > > > > >
> > > > > > > I noticed double "-g -gdwarf-5 -g -gdwarf-5" (a different issue) 
> > > > > > > and
> > > > > > > that's why I looked again into the top-level Makefile.
> > > > > >
> > > > > > That's...unexpected.  I don't see where that could be coming from.
> > > > > > Can you tell me please what is the precise command line invocation 
> > > > > > of
> > > > > > make and which source file you observed this on so that I can
> > > > > > reproduce?
> > > > > >
> > > > >
> > > > > That's everywhere...
> > > > >
> > > > > $ zstdgrep --color '\-g -gdwarf-5 -g -gdwarf-5'
> > > > > build-log_5.11.0-rc5-8-amd64-clang12-lto.txt.zst
> > > > > | wc -l
> > > > > 29529
> > > >
> > > > I'm not able to reproduce.
> > > >
> > > > $ make LLVM=1 -j72 V=1 2>&1 | grep dwarf
> > > > ...
> > > > clang ... -g -gdwarf-5 -Wa,-gdwarf-5 ...
> > > > ...
> > > >
> > > > $ make LLVM=1 LLVM_IAS=1 -j72 V=1 2>&1 | grep dwarf
> > > > ...
> > > > clang ... -g -gdwarf-5 ...
> > > > ...
> > > >
> > >
> > > Hmm...
> > >
> > > I do not see in my current build "-Wa,-gdwarf-5" is passed with v6.
> > >
> > > $ grep '\-Wa,-gdwarf-5' build-log_5.11.0-rc5-10-amd64-clang12-lto-pgo.txt
> > > [ empty ]
> > >
> >
> > That's the diff v5 -> v6...
> >
> > There is no more a dwarf-aflag / KBUILD_AFLAGS += $(dwarf-aflag) used.
>
> Yep; not sure that's relevant though to duplicate flags?
>
> > > > Can you tell me please what is the precise command line invocation of
> > > > make and which source file you observed this on so that I can
> > > > reproduce?
>
> If you don't send me your invocation of `make`, I cannot help you.
>

/usr/bin/perf_5.10 stat make V=1 -j4 LLVM=1 LLVM_IAS=1
PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-10-amd64-clang12
-lto-pgo KBUILD_VERBOSE=1 KBUILD_BUILD_HOST=iniza
KBUILD_BUILD_USER=sedat.di...@gmail.com
KBUILD_BUILD_TIMESTAMP=2021-01-29 bindeb-pkg
KDEB_PKGVERSION=5.11.0~rc5-10~bullseye+dileks1

- Sedat -

Re: [PATCH net-next v1 2/6] lan743x: support rx multi-buffer packets

2021-01-29 Thread Willem de Bruijn

On Fri, Jan 29, 2021 at 2:56 PM Sven Van Asbroeck  wrote:
>
> From: Sven Van Asbroeck 
>
> Multi-buffer packets enable us to use rx ring buffers smaller than
> the mtu. This will allow us to change the mtu on-the-fly, without
> having to stop the network interface in order to re-size the rx
> ring buffers.
>
> This is a big change touching a key driver function (process_packet),
> so care has been taken to test this extensively:
>
> Tests with debug logging enabled (add #define DEBUG).
>
> 1. Limit rx buffer size to 500, so mtu (1500) takes 3 buffers.
>Ping to chip, verify correct packet size is sent to OS.
>Ping large packets to chip (ping -s 1400), verify correct
>  packet size is sent to OS.
>Ping using packets around the buffer size, verify number of
>  buffers is changing, verify correct packet size is sent
>  to OS:
>  $ ping -s 472
>  $ ping -s 473
>  $ ping -s 992
>  $ ping -s 993
>Verify that each packet is followed by extension processing.
>
> 2. Limit rx buffer size to 500, so mtu (1500) takes 3 buffers.
>Run iperf3 -s on chip, verify that packets come in 3 buffers
>  at a time.
>Verify that packet size is equal to mtu.
>Verify that each packet is followed by extension processing.
>
> 3. Set chip and host mtu to 2000.
>Limit rx buffer size to 500, so mtu (2000) takes 4 buffers.
>Run iperf3 -s on chip, verify that packets come in 4 buffers
>  at a time.
>Verify that packet size is equal to mtu.
>Verify that each packet is followed by extension processing.
>
> Tests with debug logging DISabled (remove #define DEBUG).
>
> 4. Limit rx buffer size to 500, so mtu (1500) takes 3 buffers.
>Run iperf3 -s on chip, note sustained rx speed.
>Set chip and host mtu to 2000, so mtu takes 4 buffers.
>Run iperf3 -s on chip, note sustained rx speed.
>Verify no packets are dropped in both cases.
>
> Tests with DEBUG_KMEMLEAK on:
>  $ mount -t debugfs nodev /sys/kernel/debug/
>  $ echo scan > /sys/kernel/debug/kmemleak
>
> 5. Limit rx buffer size to 500, so mtu (1500) takes 3 buffers.
>Run the following tests concurrently for at least one hour:
>- iperf3 -s on chip
>- ping -> chip
>Monitor reported memory leaks.
>
> 6. Set chip and host mtu to 2000.
>Limit rx buffer size to 500, so mtu (2000) takes 4 buffers.
>Run the following tests concurrently for at least one hour:
>- iperf3 -s on chip
>- ping -> chip
>Monitor reported memory leaks.
>
> 7. Simulate low-memory in lan743x_rx_allocate_skb(): fail every
>  100 allocations.
>Repeat (5) and (6).
>Monitor reported memory leaks.
>
> 8. Simulate  low-memory in lan743x_rx_allocate_skb(): fail 10
>  allocations in a row in every 100.
>Repeat (5) and (6).
>Monitor reported memory leaks.
>
> 9. Simulate  low-memory in lan743x_rx_trim_skb(): fail 1 allocation
>  in every 100.
>Repeat (5) and (6).
>Monitor reported memory leaks.
>
> Signed-off-by: Sven Van Asbroeck 
> ---
>
> Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git # 
> 46eb3c108fe1
>
> To: Bryan Whitehead 
> To: unglinuxdri...@microchip.com
> To: "David S. Miller" 
> To: Jakub Kicinski 
> Cc: Andrew Lunn 
> Cc: Alexey Denisov 
> Cc: Sergej Bauer 
> Cc: Tim Harvey 
> Cc: Anders Rønningen 
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org (open list)
>
>  drivers/net/ethernet/microchip/lan743x_main.c | 321 --
>  drivers/net/ethernet/microchip/lan743x_main.h |   2 +
>  2 files changed, 143 insertions(+), 180 deletions(-)


> +static struct sk_buff *
> +lan743x_rx_trim_skb(struct sk_buff *skb, int frame_length)
> +{
> +   if (skb_linearize(skb)) {

Is this needed? That will be quite expensive

> +   dev_kfree_skb_irq(skb);
> +   return NULL;
> +   }
> +   frame_length = max_t(int, 0, frame_length - RX_HEAD_PADDING - 2);
> +   if (skb->len > frame_length) {
> +   skb->tail -= skb->len - frame_length;
> +   skb->len = frame_length;
> +   }
> +   return skb;
> +}
> +
>  static int lan743x_rx_process_packet(struct lan743x_rx *rx)
>  {
> -   struct skb_shared_hwtstamps *hwtstamps = NULL;
> +   struct lan743x_rx_descriptor *descriptor, *desc_ext;
> int result = RX_PROCESS_RESULT_NOTHING_TO_DO;
> int current_head_index = le32_to_cpu(*rx->head_cpu_ptr);
> struct lan743x_rx_buffer_info *buffer_info;
> -   struct lan743x_rx_descriptor *descriptor;
> +   struct skb_shared_hwtstamps *hwtstamps;
> +   int frame_length, buffer_length;
> +   struct sk_buff *skb;
> int extension_index = -1;
> -   int first_index = -1;
> -   int last_index = -1;
> +   bool is_last, is_first;
>
> if (current_head_index < 0 || current_head_index >= rx->ring_size)
> goto done;
> @@ -2068,170 +2075,126 @@ static int lan743x_rx_process_packet(struct 
> lan743x_rx *rx)
> if

Re: ARM: dts: mmp devicetree updates

2021-01-29 Thread Lubomir Rintel

On Fri, Jan 22, 2021 at 03:09:14PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 21, 2021 at 4:41 AM Lubomir Rintel  wrote:
> >
> > Hi,
> >
> > chained to this message is a handful of patches related to MMP device
> > trees and bindings. Please take a look and consider queueing them for
> > for 5.12.
> 
> These all look good to me, but I notice that a lot of them seem to be
> bugfixes, so please have another look and decide if any of them should
> go into v5.11 and perhaps backported to stable kernels as well.

I'm not sure any of these are worth backporting to stable. I believe
actually only these two are bugfixes:

  [PATCH 06/12] ARM: dts: mmp3: Extend the MPMU reg range
  [PATCH 12/12] ARM: dts: mmp3: Fix the CCIC interrupts

The first one only affects the audio, but the MMP I2S driver doesn't
work on MMP3 yet. The second one affects the camera, but the only board
DTS shipped at this point doesn't have one. Therefore both are somewhat
inconequential for older kernels.

> 
>Arnd

Thanks
Lubo

Re: [GIT PULL] Power management fixes for v5.11-rc6

The pull request you sent on Fri, 29 Jan 2021 17:26:04 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-5.11-rc6

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/32b0c410cda19df9f0e88edcae126d0a660cf8b9

Thank you!

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

[RFC PATCH v4 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors

2021-01-29 Thread Jyoti Bhayana

This change provides ARM SCMI Protocol based IIO device.
This driver provides support for Accelerometer and Gyroscope using
SCMI Sensor Protocol extensions added in the SCMIv3.0 ARM specification

Signed-off-by: Jyoti Bhayana 
---
 MAINTAINERS|   6 +
 drivers/iio/common/Kconfig |   1 +
 drivers/iio/common/Makefile|   1 +
 drivers/iio/common/scmi_sensors/Kconfig|  18 +
 drivers/iio/common/scmi_sensors/Makefile   |   5 +
 drivers/iio/common/scmi_sensors/scmi_iio.c | 742 +
 6 files changed, 773 insertions(+)
 create mode 100644 drivers/iio/common/scmi_sensors/Kconfig
 create mode 100644 drivers/iio/common/scmi_sensors/Makefile
 create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b516bb34a8d5..ccf37d43ab41 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8567,6 +8567,12 @@ S:   Maintained
 F: Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
 F: drivers/iio/multiplexer/iio-mux.c
 
+IIO SCMI BASED DRIVER
+M: Jyoti Bhayana 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/iio/common/scmi_sensors/scmi_iio.c
+
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
 R: Lars-Peter Clausen 
diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig
index 2b9ee9161abd..0334b4954773 100644
--- a/drivers/iio/common/Kconfig
+++ b/drivers/iio/common/Kconfig
@@ -6,5 +6,6 @@
 source "drivers/iio/common/cros_ec_sensors/Kconfig"
 source "drivers/iio/common/hid-sensors/Kconfig"
 source "drivers/iio/common/ms_sensors/Kconfig"
+source "drivers/iio/common/scmi_sensors/Kconfig"
 source "drivers/iio/common/ssp_sensors/Kconfig"
 source "drivers/iio/common/st_sensors/Kconfig"
diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile
index 4bc30bb548e2..fad40e1e1718 100644
--- a/drivers/iio/common/Makefile
+++ b/drivers/iio/common/Makefile
@@ -11,5 +11,6 @@
 obj-y += cros_ec_sensors/
 obj-y += hid-sensors/
 obj-y += ms_sensors/
+obj-y += scmi_sensors/
 obj-y += ssp_sensors/
 obj-y += st_sensors/
diff --git a/drivers/iio/common/scmi_sensors/Kconfig 
b/drivers/iio/common/scmi_sensors/Kconfig
new file mode 100644
index ..67e084cbb1ab
--- /dev/null
+++ b/drivers/iio/common/scmi_sensors/Kconfig
@@ -0,0 +1,18 @@
+#
+# IIO over SCMI
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "IIO SCMI Sensors"
+
+config IIO_SCMI
+   tristate "IIO SCMI"
+depends on ARM_SCMI_PROTOCOL
+select IIO_BUFFER
+select IIO_KFIFO_BUF
+   help
+  Say yes here to build support for IIO SCMI Driver.
+  This provides ARM SCMI Protocol based IIO device.
+  This driver provides support for accelerometer and gyroscope
+  sensors available on SCMI based platforms.
+endmenu
diff --git a/drivers/iio/common/scmi_sensors/Makefile 
b/drivers/iio/common/scmi_sensors/Makefile
new file mode 100644
index ..f13140a2575a
--- /dev/null
+++ b/drivers/iio/common/scmi_sensors/Makefile
@@ -0,0 +1,5 @@
+# SPDX - License - Identifier : GPL - 2.0 - only
+#
+# Makefile for the IIO over SCMI
+#
+obj-$(CONFIG_IIO_SCMI) += scmi_iio.o
diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c 
b/drivers/iio/common/scmi_sensors/scmi_iio.c
new file mode 100644
index ..331ffaffd06f
--- /dev/null
+++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
@@ -0,0 +1,742 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * System Control and Management Interface(SCMI) based IIO sensor driver
+ *
+ * Copyright (C) 2020 Google LLC
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ilog10(x) (ilog2(x) / const_ilog2(10))
+#define UHZ_PER_HZ 100UL
+#define ODR_EXPAND(odr, uodr) (((odr) * 100ULL) + (uodr))
+#define MAX_NUM_OF_CHANNELS 4
+#define H32(x) (FIELD_GET(GENMASK_ULL(63, 32), (x)))
+#define L32(x) (FIELD_GET(GENMASK_ULL(31, 0), (x)))
+
+struct scmi_iio_priv {
+   struct scmi_handle *handle;
+   const struct scmi_sensor_info *sensor_info;
+   struct iio_dev *indio_dev;
+   long long iio_buf[MAX_NUM_OF_CHANNELS];
+   struct notifier_block sensor_update_nb;
+   u32 *freq_avail;
+   /*
+* range_avail = [minRange resolution maxRange]
+* with IIO val type as IIO_VAL_FRACTIONAL.
+* Hence, array of size 6.
+*/
+   int range_avail[6];
+};
+
+static int scmi_iio_sensor_update_cb(struct notifier_block *nb,
+unsigned long event, void *data)
+{
+   struct scmi_sensor_update_report *sensor_update = data;
+   struct iio_dev *scmi_iio_dev;
+   struct scmi_iio_priv *sensor;
+   s8 tstamp_scale;
+   u64 time, time_ns;
+   int i;
+
+   if (sensor_update->readings_count == 0)
+   return NOTIFY_DONE;
+
+   sensor = container_of(nb, struct

Re: [PATCH v6 2/2] Kbuild: implement support for DWARF v5

On Fri, Jan 29, 2021 at 2:11 PM Sedat Dilek  wrote:
>
> On Fri, Jan 29, 2021 at 11:09 PM Nick Desaulniers
>  wrote:
> >
> > On Fri, Jan 29, 2021 at 1:20 PM Sedat Dilek  wrote:
> > >
> > > On Fri, Jan 29, 2021 at 10:13 PM Sedat Dilek  
> > > wrote:
> > > >
> > > > On Fri, Jan 29, 2021 at 10:09 PM Nick Desaulniers
> > > >  wrote:
> > > > >
> > > > > On Fri, Jan 29, 2021 at 12:55 PM Sedat Dilek  
> > > > > wrote:
> > > > > >
> > > > > > On Fri, Jan 29, 2021 at 9:48 PM Nick Desaulniers
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Fri, Jan 29, 2021 at 12:41 PM Sedat Dilek 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > diff --git a/Makefile b/Makefile
> > > > > > > > > index 20141cd9319e..bed8b3b180b8 100644
> > > > > > > > > --- a/Makefile
> > > > > > > > > +++ b/Makefile
> > > > > > > > > @@ -832,8 +832,20 @@ endif
> > > > > > > > >
> > > > > > > > >  dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> > > > > > > > >  dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> > > > > > > > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
> > > > > > > > >  DEBUG_CFLAGS   += -gdwarf-$(dwarf-version-y)
> > > > > > > > >
> > > > > > > > > +# If using clang without the integrated assembler, we need 
> > > > > > > > > to explicitly tell
> > > > > > > > > +# GAS that we will be feeding it DWARF v5 assembler 
> > > > > > > > > directives. Kconfig should
> > > > > > > > > +# detect whether the version of GAS supports DWARF v5.
> > > > > > > > > +ifdef CONFIG_CC_IS_CLANG
> > > > > > > > > +ifneq ($(LLVM_IAS),1)
> > > > > > > > > +ifeq ($(dwarf-version-y),5)
> > > > > > > > > +DEBUG_CFLAGS   += -Wa,-gdwarf-5
> > > > > > > >
> > > > > > > > I noticed double "-g -gdwarf-5 -g -gdwarf-5" (a different 
> > > > > > > > issue) and
> > > > > > > > that's why I looked again into the top-level Makefile.
> > > > > > >
> > > > > > > That's...unexpected.  I don't see where that could be coming from.
> > > > > > > Can you tell me please what is the precise command line 
> > > > > > > invocation of
> > > > > > > make and which source file you observed this on so that I can
> > > > > > > reproduce?
> > > > > > >
> > > > > >
> > > > > > That's everywhere...
> > > > > >
> > > > > > $ zstdgrep --color '\-g -gdwarf-5 -g -gdwarf-5'
> > > > > > build-log_5.11.0-rc5-8-amd64-clang12-lto.txt.zst
> > > > > > | wc -l
> > > > > > 29529
> > > > >
> > > > > I'm not able to reproduce.
> > > > >
> > > > > $ make LLVM=1 -j72 V=1 2>&1 | grep dwarf
> > > > > ...
> > > > > clang ... -g -gdwarf-5 -Wa,-gdwarf-5 ...
> > > > > ...
> > > > >
> > > > > $ make LLVM=1 LLVM_IAS=1 -j72 V=1 2>&1 | grep dwarf
> > > > > ...
> > > > > clang ... -g -gdwarf-5 ...
> > > > > ...
> > > > >
> > > >
> > > > Hmm...
> > > >
> > > > I do not see in my current build "-Wa,-gdwarf-5" is passed with v6.
> > > >
> > > > $ grep '\-Wa,-gdwarf-5' 
> > > > build-log_5.11.0-rc5-10-amd64-clang12-lto-pgo.txt
> > > > [ empty ]
> > > >
> > >
> > > That's the diff v5 -> v6...
> > >
> > > There is no more a dwarf-aflag / KBUILD_AFLAGS += $(dwarf-aflag) used.
> >
> > Yep; not sure that's relevant though to duplicate flags?
> >
> > > > > Can you tell me please what is the precise command line invocation of
> > > > > make and which source file you observed this on so that I can
> > > > > reproduce?
> >
> > If you don't send me your invocation of `make`, I cannot help you.
> >
>
> /usr/bin/perf_5.10 stat make V=1 -j4 LLVM=1 LLVM_IAS=1
> PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-10-amd64-clang12
> -lto-pgo KBUILD_VERBOSE=1 KBUILD_BUILD_HOST=iniza
> KBUILD_BUILD_USER=sedat.di...@gmail.com
> KBUILD_BUILD_TIMESTAMP=2021-01-29 bindeb-pkg
> KDEB_PKGVERSION=5.11.0~rc5-10~bullseye+dileks1

$ make LLVM=1 LLVM_IAS=1 -j72 defconfig
$ make LLVM=1 LLVM_IAS=1 -j72 menuconfig

$ make LLVM=1 LLVM_IAS=1 -j72 V=1 &> log.txt
$ grep '\-g -gdwarf-5 -g -gdwarf-5' log.txt | wc -l
0
$ grep '\-g -gdwarf-5' log.txt | wc -l
2517

Do have the patch applied twice, perhaps?

Is your compiler haunted, or is mine? (haha! they both are; false
dichotomy; they are one in the same).  Is zstdgrep haunted, or is GNU
grep haunted? :P
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform

2021-01-29 Thread Dmitry Baryshkov

On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas  wrote:
>
> On Fri, Jan 29, 2021 at 06:45:21AM +0300, Dmitry Baryshkov wrote:
> > On 28/01/2021 22:26, Rob Herring wrote:
> > > On Thu, Jan 28, 2021 at 11:52 AM Dmitry Baryshkov
> > >  wrote:
> > > >
> > > > Some Qualcomm platforms require to power up an external device before
> > > > probing the PCI bus. E.g. on RB5 platform the QCA6390 WiFi/BT chip needs
> > > > to be powered up before PCIe0 bus is probed. Add a quirk to the
> > > > respective PCIe root bridge to attach to the power domain if one is
> > > > required, so that the QCA chip is started before scanning the PCIe bus.
> > >
> > > This is solving a generic problem in a specific driver. It needs to be
> > > solved for any PCI host and any device.
> >
> > Ack. I see your point here.
> >
> > As this would require porting code from powerpc/spark of-pci code and
> > changing pcie port driver to apply power supply before bus probing happens,
> > I'd also ask for the comments from PCI maintainers. Will that solution be
> > acceptable to you?
>
> I can't say without seeing the code.  I don't know enough about this
> scenario to envision how it might look.
>
> I guess the QCA6390 is a PCIe device?  Why does it need to be powered
> up before probing?  Shouldn't we get a link-up interrupt when it is
> powered up so we could probe it then?

Not quite. QCA6390 is a multifunction device, with PCIe and serial
parts. It has internal power regulators which once enabled will
powerup the PCIe, serial and radio parts. There is no need to manage
regulators. Once enabled they will automatically handle device
suspend/resume, etc.

I'm not sure about link-up interrupt. I've just lightly tested using
PCIe HP on this port, getting no interrupts from it.
If I manually rescan the bus after enabling the qca6390 device (e.g.
via sysfs), it gets enabled, but then I see PCIe link errors (most
probably because the PCIe link was not retrained after the device
comes up).

> Nit: when changing any file, please take a look at the commit history
> and make yours match, e.g.,
>
>   pcie-qcom: provide a way to power up qca6390 chip on RB5 platform
>
> does not look like:

Ack.


-- 
With best wishes
Dmitry

Re: [RFC PATCH v1 1/4] vfio/type1: Add a bitmap to track IOPF mapped pages

2021-01-29 Thread Alex Williamson

On Mon, 25 Jan 2021 17:03:59 +0800
Shenming Lu  wrote:

> When IOPF enabled, the pages are pinned and mapped on demand, we add
> a bitmap to track them.
> 
> Signed-off-by: Shenming Lu 
> ---
>  drivers/vfio/vfio_iommu_type1.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 0b4dedaa9128..f1d4de5ab094 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -95,6 +95,7 @@ struct vfio_dma {
>   struct task_struct  *task;
>   struct rb_root  pfn_list;   /* Ex-user pinned pfn list */
>   unsigned long   *bitmap;
> + unsigned long   *iommu_mapped_bitmap;   /* IOPF mapped bitmap */
>  };
>  
>  struct vfio_group {
> @@ -143,6 +144,8 @@ struct vfio_regions {
>  #define DIRTY_BITMAP_PAGES_MAX((u64)INT_MAX)
>  #define DIRTY_BITMAP_SIZE_MAX 
> DIRTY_BITMAP_BYTES(DIRTY_BITMAP_PAGES_MAX)
>  
> +#define IOMMU_MAPPED_BITMAP_BYTES(n) DIRTY_BITMAP_BYTES(n)
> +
>  static int put_pfn(unsigned long pfn, int prot);
>  
>  static struct vfio_group *vfio_iommu_find_iommu_group(struct vfio_iommu 
> *iommu,
> @@ -949,6 +952,7 @@ static void vfio_remove_dma(struct vfio_iommu *iommu, 
> struct vfio_dma *dma)
>   vfio_unlink_dma(iommu, dma);
>   put_task_struct(dma->task);
>   vfio_dma_bitmap_free(dma);
> + kfree(dma->iommu_mapped_bitmap);
>   kfree(dma);
>   iommu->dma_avail++;
>  }
> @@ -1354,6 +1358,14 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
>   goto out_unlock;
>   }
>  
> + dma->iommu_mapped_bitmap = kvzalloc(IOMMU_MAPPED_BITMAP_BYTES(size / 
> PAGE_SIZE),
> + GFP_KERNEL);

This is a lot of bloat for all the platforms that don't support this
feature.  Thanks,

Alex

> + if (!dma->iommu_mapped_bitmap) {
> + ret = -ENOMEM;
> + kfree(dma);
> + goto out_unlock;
> + }
> +
>   iommu->dma_avail--;
>   dma->iova = iova;
>   dma->vaddr = vaddr;

[GIT PULL] Devicetree fixes for 5.11, take 2

2021-01-29 Thread Rob Herring

Linus,

Please pull some more DT fixes for 5.11.

Rob


The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:

  Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git 
tags/devicetree-fixes-for-5.11-2

for you to fetch changes up to 32ada6b0980d86133d080d62371a5787ea2ec5ed:

  dt-bindings: Cleanup standard unit properties (2021-01-29 16:36:06 -0600)


Devicetree fixes for v5.11, take 2:

- Cleanups on properties with standard unit suffixes

- Fix overwriting dma_range_map if there's no 'dma-ranges' property

- Fix a bug when creating a /chosen node from ARM ATAGs

- Add missing properties for TI j721e USB binding

- Several doc reference updates due to DT schema conversions


Grygorii Strashko (1):
  dt-bindings: usb: j721e: add ranges and dma-coherent props

Mauro Carvalho Chehab (4):
  ASoC: audio-graph-card: update audio-graph-card.yaml reference
  dt-bindings: display: mediatek: update mediatek,dpi.yaml reference
  dt-bindings: memory: mediatek: update mediatek,smi-larb.yaml references
  dt-bindings:iio:adc: update adc.yaml reference

Rob Herring (2):
  ARM: zImage: atags_to_fdt: Fix node names on added root nodes
  dt-bindings: Cleanup standard unit properties

Yong Wu (1):
  of/device: Update dma_range_map only when dev has valid dma-ranges

 Documentation/devicetree/bindings/arm/cpus.yaml|  1 -
 .../devicetree/bindings/display/bridge/sii902x.txt |  2 +-
 .../bindings/display/mediatek/mediatek,disp.txt|  4 +--
 .../devicetree/bindings/extcon/wlf,arizona.yaml|  1 -
 .../devicetree/bindings/hwmon/adi,ltc2947.yaml |  1 -
 .../devicetree/bindings/hwmon/baikal,bt1-pvt.yaml  |  8 ++---
 .../devicetree/bindings/hwmon/ti,tmp513.yaml   |  1 -
 .../devicetree/bindings/i2c/i2c-gpio.yaml  |  2 --
 .../bindings/i2c/snps,designware-i2c.yaml  |  3 --
 .../devicetree/bindings/iio/adc/adi,ad7192.yaml|  2 +-
 .../devicetree/bindings/iio/adc/maxim,max9611.yaml |  1 -
 .../devicetree/bindings/iio/adc/st,stm32-adc.yaml  |  1 -
 .../bindings/iio/adc/ti,palmas-gpadc.yaml  |  2 --
 .../devicetree/bindings/iio/dac/adi,ad5758.yaml| 41 ++
 .../bindings/iio/health/maxim,max30100.yaml|  1 -
 .../bindings/input/touchscreen/touchscreen.yaml|  2 --
 .../bindings/media/mediatek-jpeg-decoder.txt   |  2 +-
 .../bindings/media/mediatek-jpeg-encoder.txt   |  2 +-
 .../devicetree/bindings/media/mediatek-mdp.txt |  2 +-
 .../devicetree/bindings/mmc/mmc-controller.yaml|  1 -
 .../devicetree/bindings/mmc/mmc-pwrseq-simple.yaml |  2 --
 .../bindings/net/ethernet-controller.yaml  |  2 --
 .../devicetree/bindings/net/snps,dwmac.yaml|  1 -
 .../devicetree/bindings/power/supply/battery.yaml  |  3 --
 .../devicetree/bindings/power/supply/bq2515x.yaml  |  1 -
 .../devicetree/bindings/regulator/dlg,da9121.yaml  |  1 -
 .../bindings/regulator/fixed-regulator.yaml|  2 --
 Documentation/devicetree/bindings/rtc/rtc.yaml |  2 --
 .../devicetree/bindings/serial/pl011.yaml  |  2 --
 .../devicetree/bindings/sound/sgtl5000.yaml|  2 --
 .../devicetree/bindings/usb/ti,j721e-usb.yaml  |  4 +++
 .../devicetree/bindings/watchdog/watchdog.yaml |  1 -
 arch/arm/boot/compressed/atags_to_fdt.c|  3 +-
 drivers/of/device.c| 10 --
 34 files changed, 49 insertions(+), 67 deletions(-)

Re: [PATCH] tpm_tis: Add missing start/stop_tpm_chip calls

2021-01-29 Thread Jarkko Sakkinen

On Tue, Jan 26, 2021 at 04:46:07PM +0100, Łukasz Majczak wrote:
> Hi Jarkko, Guenter
> 
> Yes, here are the logs when failure occurs -
> https://gist.github.com/semihalf-majczak-lukasz/1575461f585f1e7fb1e9366b8eceaab9
> Look for a phrase "TPM returned invalid status"
> 
> Guenter - good suggestion - I will try to keep it as tight as possible.
> 
> Best regards,
> Lukasz

Is it possible for you try out with linux-next? Thanks. It's a known
issue, which ought to be fixed by now.

The log message is harmless, it'a warning not panic, and does not
endanger system stability. WARN()'s always dump stack trace. No oops
is happening.

/Jarkko

Re: [PATCH] tpm_tis: Add missing start/stop_tpm_chip calls

2021-01-29 Thread Jarkko Sakkinen

On Sat, Jan 30, 2021 at 12:59:09AM +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 26, 2021 at 04:46:07PM +0100, Łukasz Majczak wrote:
> > Hi Jarkko, Guenter
> > 
> > Yes, here are the logs when failure occurs -
> > https://gist.github.com/semihalf-majczak-lukasz/1575461f585f1e7fb1e9366b8eceaab9
> > Look for a phrase "TPM returned invalid status"
> > 
> > Guenter - good suggestion - I will try to keep it as tight as possible.
> > 
> > Best regards,
> > Lukasz
> 
> Is it possible for you try out with linux-next? Thanks. It's a known
> issue, which ought to be fixed by now.
> 
> The log message is harmless, it'a warning not panic, and does not
> endanger system stability. WARN()'s always dump stack trace. No oops
> is happening.

The regression itself originates from 2006. It has just been unmasked
with "improved" logging.

/Jarkko

Re: [PATCH] Updates Documentation/Makefile to use Python3 as fallback

2021-01-29 Thread Jonathan Corbet

Noa Sakurajin  writes:

[CC += kbuild maintainers]

>  Before the command python was needed for the documentation to build.
>  This patch checks if python is available and uses python3 as
>  fallback.
>
>  This is needed because a lot of distribution (at least Ubuntu)
>  only provide python3 and not python. scripts/sphinx-pre-install
>  checks for python3 first and does not check if python exists
>  which causes it to report that everything is installed even
>  if the documentation build failed.
>
> Signed-off-by: Noa Sakurajin 
> ---
>  Documentation/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 61a7310b49e0..8a4a7df3b74a 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -75,7 +75,8 @@ quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath 
> $(BUILDDIR)/$3/$4)
>cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
> $(build)=Documentation/userspace-api/media $2 && \
>   PYTHONDONTWRITEBYTECODE=1 \
>   BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
> $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
> - $(PYTHON) $(srctree)/scripts/jobserver-exec \
> + PY=$(shell command -v $(PYTHON) 2> /dev/null) \
> + $${PY:-"$(PYTHON3)"} $(srctree)/scripts/jobserver-exec \

So I see what you're trying to do, and we definitely want this to work.
I susped this isn't the right fix, though; it could leave us open to
similar issues elsewhere in the tree.

Personally, I think that $(PYTHON) should get a working Python if it's
installed, so I would suggest fixing the top-level Makefile to set it
correctly.  Masahiro, thoughts on that?

Alternatively, we could just say $(PYTHON3) and explicitly leave Python2
behind; that needs to happen in the not-too-distant future regardless
but we haven't decided to actually do it yet.

Thanks,

jon

[PATCH 2/3] IMA: update functions to read allow_dup policy condition

2021-01-29 Thread Tushar Sugandhi

IMA functions ima_get_action() and ima_match_policy() do not consume the
policy condition to allow measuring duplicate entries for integrity
critical data.

Update ima_get_action() and ima_match_policy() to consume the IMA policy
condition to measure duplicate buffer entries for integrity critical
data.

Signed-off-by: Tushar Sugandhi 
---
 security/integrity/ima/ima.h  | 4 ++--
 security/integrity/ima/ima_api.c  | 6 --
 security/integrity/ima/ima_appraise.c | 2 +-
 security/integrity/ima/ima_main.c | 6 +++---
 security/integrity/ima/ima_policy.c   | 7 ++-
 5 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index aa312472c7c5..59324173497f 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -257,7 +257,7 @@ static inline void ima_process_queued_keys(void) {}
 int ima_get_action(struct inode *inode, const struct cred *cred, u32 secid,
   int mask, enum ima_hooks func, int *pcr,
   struct ima_template_desc **template_desc,
-  const char *func_data);
+  const char *func_data, bool *allow_dup);
 int ima_must_measure(struct inode *inode, int mask, enum ima_hooks func);
 int ima_collect_measurement(struct integrity_iint_cache *iint,
struct file *file, void *buf, loff_t size,
@@ -286,7 +286,7 @@ const char *ima_d_path(const struct path *path, char 
**pathbuf, char *filename);
 int ima_match_policy(struct inode *inode, const struct cred *cred, u32 secid,
 enum ima_hooks func, int mask, int flags, int *pcr,
 struct ima_template_desc **template_desc,
-const char *func_data);
+const char *func_data, bool *allow_dup);
 void ima_init_policy(void);
 void ima_update_policy(void);
 void ima_update_policy_flag(void);
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index 1dd70dc68ffd..d273373e6be9 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -171,6 +171,8 @@ void ima_add_violation(struct file *file, const unsigned 
char *filename,
  * @pcr: pointer filled in if matched measure policy sets pcr=
  * @template_desc: pointer filled in if matched measure policy sets template=
  * @func_data: func specific data, may be NULL
+ * @allow_dup: pointer filled in to decide if a duplicate buffer entry
+ * should be measured
  *
  * The policy is defined in terms of keypairs:
  * subj=, obj=, type=, func=, mask=, fsmagic=
@@ -186,14 +188,14 @@ void ima_add_violation(struct file *file, const unsigned 
char *filename,
 int ima_get_action(struct inode *inode, const struct cred *cred, u32 secid,
   int mask, enum ima_hooks func, int *pcr,
   struct ima_template_desc **template_desc,
-  const char *func_data)
+  const char *func_data, bool *allow_dup)
 {
int flags = IMA_MEASURE | IMA_AUDIT | IMA_APPRAISE | IMA_HASH;
 
flags &= ima_policy_flag;
 
return ima_match_policy(inode, cred, secid, func, mask, flags, pcr,
-   template_desc, func_data);
+   template_desc, func_data, allow_dup);
 }
 
 /*
diff --git a/security/integrity/ima/ima_appraise.c 
b/security/integrity/ima/ima_appraise.c
index 46ffa38bab12..e317a7698a47 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -77,7 +77,7 @@ int ima_must_appraise(struct inode *inode, int mask, enum 
ima_hooks func)
 
security_task_getsecid(current, );
return ima_match_policy(inode, current_cred(), secid, func, mask,
-   IMA_APPRAISE | IMA_HASH, NULL, NULL, NULL);
+   IMA_APPRAISE | IMA_HASH, NULL, NULL, NULL, 
NULL);
 }
 
 static int ima_fix_xattr(struct dentry *dentry,
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index 6a429846f90a..2774139845b6 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -219,7 +219,7 @@ static int process_measurement(struct file *file, const 
struct cred *cred,
 * Included is the appraise submask.
 */
action = ima_get_action(inode, cred, secid, mask, func, ,
-   _desc, NULL);
+   _desc, NULL, NULL);
violation_check = ((func == FILE_CHECK || func == MMAP_CHECK) &&
   (ima_policy_flag & IMA_MEASURE));
if (!action && !violation_check)
@@ -432,7 +432,7 @@ int ima_file_mprotect(struct vm_area_struct *vma, unsigned 
long prot)
security_task_getsecid(current, );
inode = file_inode(vma->vm_file);
action = ima_get_action(inode, current_cred(), secid, MAY_EXEC,
-   MMAP_CHECK, , , 0);
+

[PATCH v7 1/2] Kbuild: make DWARF version a choice

Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice which is
the default. Does so in a way that's forward compatible with existing
configs, and makes adding future versions more straightforward.

GCC since ~4.8 has defaulted to this DWARF version implicitly.

Suggested-by: Arvind Sankar 
Suggested-by: Fangrui Song 
Suggested-by: Nathan Chancellor 
Suggested-by: Masahiro Yamada 
Signed-off-by: Nick Desaulniers 
---
 Makefile  |  5 ++---
 lib/Kconfig.debug | 16 +++-
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index 95ab9856f357..d2b4980807e0 100644
--- a/Makefile
+++ b/Makefile
@@ -830,9 +830,8 @@ ifneq ($(LLVM_IAS),1)
 KBUILD_AFLAGS  += -Wa,-gdwarf-2
 endif
 
-ifdef CONFIG_DEBUG_INFO_DWARF4
-DEBUG_CFLAGS   += -gdwarf-4
-endif
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+DEBUG_CFLAGS   += -gdwarf-$(dwarf-version-y)
 
 ifdef CONFIG_DEBUG_INFO_REDUCED
 DEBUG_CFLAGS   += $(call cc-option, -femit-struct-debug-baseonly) \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e906ea906cb7..94c1a7ed6306 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -256,13 +256,19 @@ config DEBUG_INFO_SPLIT
  to know about the .dwo files and include them.
  Incompatible with older versions of ccache.
 
+choice
+   prompt "DWARF version"
+   help
+ Which version of DWARF debug info to emit.
+
 config DEBUG_INFO_DWARF4
-   bool "Generate dwarf4 debuginfo"
+   bool "Generate DWARF Version 4 debuginfo"
help
- Generate dwarf4 debug info. This requires recent versions
- of gcc and gdb. It makes the debug information larger.
- But it significantly improves the success of resolving
- variables in gdb on optimized code.
+ Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
+ It makes the debug information larger, but it significantly
+ improves the success of resolving variables in gdb on optimized code.
+
+endchoice # "DWARF version"
 
 config DEBUG_INFO_BTF
bool "Generate BTF typeinfo"
-- 
2.30.0.365.g02bc693789-goog

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

2021-01-29 Thread Fāng-ruì Sòng

On Fri, Jan 29, 2021 at 4:46 PM 'Nick Desaulniers' via Clang Built
Linux  wrote:
>
> On Fri, Jan 29, 2021 at 4:08 PM Sedat Dilek  wrote:
> >
> > On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers
> >  wrote:
> > >
> > > DWARF v5 is the latest standard of the DWARF debug info format.
> > >
> > > DWARF5 wins significantly in terms of size and especially so when mixed
> > > with compression (CONFIG_DEBUG_INFO_COMPRESSED).
> > >
> > > Link: http://www.dwarfstd.org/doc/DWARF5.pdf
> > >
> > > Patch 1 is a cleanup that lays the ground work and isn't DWARF
> > > v5 specific.
> > > Patch 2 implements Kconfig and Kbuild support for DWARFv5.
> > >
> >
> > When you will do a v7...
> >
> > Can you look also at places where we have hardcoded DWARF-2 handling...
>
> Ah, sorry, I just saw this now, after sending v7.  Can we wait to
> purge DWARF v2 until after we have DWARF v5?
>
> In fact, if they are orthogonal like I suspect, why don't you send
> some patches and I will help you test them?
> --
> Thanks,
> ~Nick Desaulniers

Basically the distinction is just between DWARF v2 .debug_line and
DWARF v5 .debug_line .
(-gdwarf-4 adds an extra maximum_operations_per_instruction (constant
1) compared with -gdwarf-2 but that can mostly be ignored).

Refinement among -gdwarf-[234] just clarifies things and is not going
to affect debugging experience in any case.
So I agree with Nick that it can be done separately.
Note: such clarification can make things a bit ugly because binutils
before 2020 does not recognize -gdwarf-[345].

-- 
宋方睿

Re: [PATCH v2] kdb: kdb_support: Fix debugging information problem

2021-01-29 Thread Doug Anderson

Hi,

On Wed, Jan 27, 2021 at 11:50 PM Stephen Zhang
 wrote:
>
>  int kdbgetsymval(const char *symname, kdb_symtab_t *symtab)
>  {
> -   if (KDB_DEBUG(AR))
> -   kdb_printf("kdbgetsymval: symname=%s, symtab=%px\n", symname,
> -  symtab);
> +   kdb_dbg_printf(AR, "symname=%s, symtab=%px\n", symname,
> +   symtab);

nit: in this file it seems like convention is that alignment for
continued arguments is to match up with the first argument, so the
line starting with "symtab" needs to be indented more to line up under
"AR".  Similar in some cases below.

> memset(symtab, 0, sizeof(*symtab));
> symtab->sym_start = kallsyms_lookup_name(symname);
> if (symtab->sym_start) {
> -   if (KDB_DEBUG(AR))
> -   kdb_printf("kdbgetsymval: returns 1, "
> -  "symtab->sym_start=0x%lx\n",
> -  symtab->sym_start);
> +   kdb_dbg_printf(AR, "returns 1, "
> +   "symtab->sym_start=0x%lx\n",
> +   symtab->sym_start);

nit: This doesn't need to be 3 lines anymore.  Probably best is to
stop splitting the string.  In general the kernel convention considers
it better to not split strings even if you have to make long lines,
but in this case you won't even make a long line.

Other than those nits this looks really nice to me.

Reviewed-by: Douglas Anderson

Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG

On Fri, 29 Jan 2021 09:56:48 -0800 Shoaib Rao wrote:
> On 1/25/21 3:36 PM, Jakub Kicinski wrote:
> > On Fri, 22 Jan 2021 15:06:37 + Matthew Wilcox (Oracle) wrote:  
> >> From: Rao Shoaib 
> >>
> >> TCP sockets allow SIGURG to be sent to the process holding the other
> >> end of the socket.  Extend Unix sockets to have the same ability.
> >>
> >> The API is the same in that the sender uses sendmsg() with MSG_OOB to
> >> raise SIGURG.  Unix sockets behave in the same way as TCP sockets with
> >> SO_OOBINLINE set.  
> > Noob question, if we only want to support the inline mode, why don't we
> > require SO_OOBINLINE to have been called on @other? Wouldn't that
> > provide more consistent behavior across address families?
> >
> > With the current implementation the receiver will also not see MSG_OOB
> > set in msg->msg_flags, right?  
> 
> SO_OOBINLINE does not control the delivery of signal, It controls how
> OOB Byte is delivered. It may not be obvious but this change does not
> deliver any Byte, just a signal. So, as long as sendmsg flag contains
> MSG_OOB, signal will be delivered just like it happens for TCP.

Not as far as I can read this code. If MSG_OOB is set the data from the
message used to be discarded, and EOPNOTSUPP returned. Now the data gets
queued to the socket, and will be read inline.

Sure, you also add firing of the signal, which is fine. The removal of
the error check is the code I'm pointing at, so to speak.

> >> SIGURG is ignored by default, so applications which do not know about this
> >> feature will be unaffected.  In addition to installing a SIGURG handler,
> >> the receiving application must call F_SETOWN or F_SETOWN_EX to indicate
> >> which process or thread should receive the signal.
> >>
> >> Signed-off-by: Rao Shoaib 
> >> Signed-off-by: Matthew Wilcox (Oracle) 
> >> ---
> >>   net/unix/af_unix.c | 5 +++--
> >>   1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> >> index 41c3303c3357..849dff688c2c 100644
> >> --- a/net/unix/af_unix.c
> >> +++ b/net/unix/af_unix.c
> >> @@ -1837,8 +1837,6 @@ static int unix_stream_sendmsg(struct socket *sock, 
> >> struct msghdr *msg,
> >>return err;
> >>   
> >>err = -EOPNOTSUPP;
> >> -  if (msg->msg_flags_OOB)
> >> -  goto out_err;
> >>   
> >>if (msg->msg_namelen) {
> >>err = sk->sk_state == TCP_ESTABLISHED ? -EISCONN : -EOPNOTSUPP;
> >> @@ -1903,6 +1901,9 @@ static int unix_stream_sendmsg(struct socket *sock, 
> >> struct msghdr *msg,
> >>sent += size;
> >>}
> >>   
> >> +  if (msg->msg_flags & MSG_OOB)
> >> +  sk_send_sigurg(other);
> >> +
> >>scm_destroy();
> >>   
> >>return sent;

[PATCH 1/4] perf/core: Add support to exclude kernel mode instruction tracing

2021-01-29 Thread Sai Prakash Ranjan

Hardware assisted tracing families such as ARM Coresight, Intel PT
provides rich tracing capabilities including instruction level
tracing and accurate timestamps which are very useful for profiling
and also pose a significant security risk. One such example of
security risk is when kernel mode tracing is not excluded and these
hardware assisted tracing can be used to analyze cryptographic code
execution. In this case, even the root user must not be able to infer
anything.

To explain it more clearly in the words of a security team member
(credits: Mattias Nissler),

"Consider a system where disk contents are encrypted and the encryption
key is set up by the user when mounting the file system. From that point
on the encryption key resides in the kernel. It seems reasonable to
expect that the disk encryption key be protected from exfiltration even
if the system later suffers a root compromise (or even against insiders
that have root access), at least as long as the attacker doesn't
manage to compromise the kernel."

Here the idea is to protect such important information from all users
including root users since root privileges does not have to mean full
control over the kernel [1] and root compromise does not have to be
the end of the world.

Currently we can exclude kernel mode tracing via perf_event_paranoid
sysctl but it has following limitations,

 * It is applicable to all PMUs and not just the ones supporting
   instruction tracing.
 * No option to restrict kernel mode instruction tracing by the
   root user.
 * Not possible to restrict kernel mode instruction tracing when the
   hardware assisted tracing IPs like ARM Coresight ETMs use an
   additional interface via sysfs for tracing in addition to perf
   interface.

So introduce a new config CONFIG_EXCLUDE_KERNEL_HW_ITRACE to exclude
kernel mode instruction tracing which will be generic and applicable
to all hardware tracing families and which can also be used with other
interfaces like sysfs in case of ETMs.

[1] https://lwn.net/Articles/796866/

Suggested-by: Suzuki K Poulose 
Suggested-by: Al Grant 
Tested-by: Denis Nikitin 
Link: 
https://lore.kernel.org/lkml/20201015124522.1876-1-saiprakash.ran...@codeaurora.org/
Signed-off-by: Sai Prakash Ranjan 
---
 init/Kconfig | 12 
 kernel/events/core.c |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index af454a51f3c5..31b4d1f26bce 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1832,6 +1832,18 @@ config DEBUG_PERF_USE_VMALLOC
 
 endmenu
 
+config EXCLUDE_KERNEL_HW_ITRACE
+   bool "Exclude kernel mode hardware assisted instruction tracing"
+   depends on PERF_EVENTS
+   help
+ Exclude kernel mode instruction tracing by hardware tracing
+ family such as ARM Coresight ETM, Intel PT and so on.
+
+ This option allows to disable kernel mode instruction tracing
+ offered by hardware assisted tracing for all users(including root)
+ especially for production systems where only userspace tracing might
+ be preferred for security reasons.
+
 config VM_EVENT_COUNTERS
default y
bool "Enable VM event counters for /proc/vmstat" if EXPERT
diff --git a/kernel/events/core.c b/kernel/events/core.c
index aece2fe19693..044a774cef6d 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11866,6 +11866,12 @@ SYSCALL_DEFINE5(perf_event_open,
goto err_task;
}
 
+   if (IS_ENABLED(CONFIG_EXCLUDE_KERNEL_HW_ITRACE) &&
+   (event->pmu->capabilities & PERF_PMU_CAP_ITRACE) && 
!attr.exclude_kernel) {
+   err = -EACCES;
+   goto err_alloc;
+   }
+
if (is_sampling_event(event)) {
if (event->pmu->capabilities & PERF_PMU_CAP_NO_INTERRUPT) {
err = -EOPNOTSUPP;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH 2/4] perf evsel: Print warning for excluding kernel mode instruction tracing

2021-01-29 Thread Sai Prakash Ranjan

Add a warning message to check CONFIG_EXCLUDE_KERNEL_HW_ITRACE kernel
config which excludes kernel mode instruction tracing to help perf tool
users identify the perf event open failure when they attempt kernel mode
tracing with this config enabled.

Tested-by: Denis Nikitin 
Signed-off-by: Sai Prakash Ranjan 
---
 tools/perf/util/evsel.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index c26ea82220bd..09cc0349f883 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2630,7 +2630,8 @@ int evsel__open_strerror(struct evsel *evsel, struct 
target *target,
 ">= 1: Disallow CPU event access\n"
 ">= 2: Disallow kernel profiling\n"
 "To make the adjusted perf_event_paranoid setting permanent 
preserve it\n"
-"in /etc/sysctl.conf (e.g. kernel.perf_event_paranoid = 
)",
+"in /etc/sysctl.conf (e.g. kernel.perf_event_paranoid = 
)\n\n"
+"Also check CONFIG_EXCLUDE_KERNEL_HW_ITRACE if kernel mode 
tracing is allowed.",
 perf_event_paranoid());
case ENOENT:
return scnprintf(msg, size, "The %s event is not supported.", 
evsel__name(evsel));
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH 0/4] Add support to exclude kernel mode hardware assisted instruction tracing

2021-01-29 Thread Sai Prakash Ranjan

Hardware assisted tracing families such as ARM Coresight, Intel PT
provides rich tracing capabilities including instruction level
tracing and accurate timestamps which are very useful for profiling
and also pose a significant security risk. One such example of
security risk is when kernel mode tracing is not excluded and these
hardware assisted tracing can be used to analyze cryptographic code
execution. In this case, even the root user must not be able to infer
anything.

To explain it more clearly, here is the quote from a member of the
security team (credits: Mattias Nissler),

"Consider a system where disk contents are encrypted and the encryption
key is set up by the user when mounting the file system. From that point
on the encryption key resides in the kernel. It seems reasonable to
expect that the disk encryption key be protected from exfiltration even
if the system later suffers a root compromise (or even against insiders
that have root access), at least as long as the attacker doesn't
manage to compromise the kernel."

Here the idea is to protect such important information from all users
including root users since root privileges does not have to mean full
control over the kernel [1] and root compromise does not have to be
the end of the world.

Currently we can exclude kernel mode tracing via perf_event_paranoid
sysctl but it has following limitations,

 * It is applicable to all PMUs and not just the ones supporting
   instruction tracing.
 * No option to restrict kernel mode instruction tracing by the
   root user.
 * Not possible to restrict kernel mode instruction tracing when the
   hardware assisted tracing IPs like ARM Coresight ETMs use an
   additional interface via sysfs for tracing in addition to perf
   interface.

So introduce a new config CONFIG_EXCLUDE_KERNEL_HW_ITRACE to exclude
kernel mode instruction tracing which will be generic and applicable
to all hardware tracing families and which can also be used with other
interfaces like sysfs in case of ETMs.

Patch 1 adds this new config and the support in perf core to exclude
kernel mode tracing for PMUs which support instruction mode tracing.

Patch 2 adds the perf evsel warning message when the perf tool users
attempt to perform a kernel mode instruction trace with the config
enabled to exclude the kernel mode tracing.

Patch 3 and Patch 4 adds the support for excluding kernel mode for
ARM Coresight ETM{4,3}XX sysfs mode using the newly introduced generic
config.

[1] https://lwn.net/Articles/796866/

Sai Prakash Ranjan (4):
  perf/core: Add support to exclude kernel mode instruction tracing
  perf evsel: Print warning for excluding kernel mode instruction
tracing
  coresight: etm4x: Add support to exclude kernel mode tracing
  coresight: etm3x: Add support to exclude kernel mode tracing

 drivers/hwtracing/coresight/coresight-etm3x-core.c | 11 +++
 .../hwtracing/coresight/coresight-etm3x-sysfs.c|  3 ++-
 drivers/hwtracing/coresight/coresight-etm4x-core.c | 14 +-
 .../hwtracing/coresight/coresight-etm4x-sysfs.c|  3 ++-
 init/Kconfig   | 12 
 kernel/events/core.c   |  6 ++
 tools/perf/util/evsel.c|  3 ++-
 7 files changed, 48 insertions(+), 4 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] riscv: virt_addr_valid must check the address belongs to linear mapping

2021-01-29 Thread Atish Patra

On Fri, Jan 29, 2021 at 9:31 AM Alexandre Ghiti  wrote:
>
> virt_addr_valid macro checks that a virtual address is valid, ie that
> the address belongs to the linear mapping and that the corresponding
>  physical page exists.
>
> Add the missing check that ensures the virtual address belongs to the
> linear mapping, otherwise __virt_to_phys, when compiled with
> CONFIG_DEBUG_VIRTUAL enabled, raises a WARN that is interpreted as a
> kernel bug by syzbot.
>
> Signed-off-by: Alexandre Ghiti 
> ---
>  arch/riscv/include/asm/page.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
> index 2d50f76efe48..64a675c5c30a 100644
> --- a/arch/riscv/include/asm/page.h
> +++ b/arch/riscv/include/asm/page.h
> @@ -135,7 +135,10 @@ extern phys_addr_t __phys_addr_symbol(unsigned long x);
>
>  #endif /* __ASSEMBLY__ */
>
> -#define virt_addr_valid(vaddr) (pfn_valid(virt_to_pfn(vaddr)))
> +#define virt_addr_valid(vaddr) ({
>   \
> +   unsigned long _addr = (unsigned long)vaddr;   
>   \
> +   (unsigned long)(_addr) >= PAGE_OFFSET && 
> pfn_valid(virt_to_pfn(_addr)); \
> +})
>
>  #define VM_DATA_DEFAULT_FLAGS  VM_DATA_FLAGS_NON_EXEC
>
> --
> 2.20.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra 

-- 
Regards,
Atish

[Internal review][PATCH stable v5.4 1/2] ICMPv6: Add ICMPv6 Parameter Problem, code 3 definition

2021-01-29 Thread Aviraj CJ

From: Hangbin Liu 

commit b59e286be280fa3c2e94a0716ddcee6ba02bc8ba upstream.

Based on RFC7112, Section 6:

   IANA has added the following "Type 4 - Parameter Problem" message to
   the "Internet Control Message Protocol version 6 (ICMPv6) Parameters"
   registry:

  CODE NAME/DESCRIPTION
   3   IPv6 First Fragment has incomplete IPv6 Header Chain

Signed-off-by: Hangbin Liu 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Aviraj CJ 
---
 include/uapi/linux/icmpv6.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/icmpv6.h b/include/uapi/linux/icmpv6.h
index 2622b5a3e616..9a31ea2ad1cf 100644
--- a/include/uapi/linux/icmpv6.h
+++ b/include/uapi/linux/icmpv6.h
@@ -137,6 +137,7 @@ struct icmp6hdr {
 #define ICMPV6_HDR_FIELD   0
 #define ICMPV6_UNK_NEXTHDR 1
 #define ICMPV6_UNK_OPTION  2
+#define ICMPV6_HDR_INCOMP  3
 
 /*
  * constants for (set|get)sockopt
-- 
2.26.2.Cisco

[PATCH v6 2/2] Kbuild: implement support for DWARF v5

DWARF v5 is the latest standard of the DWARF debug info format.

Feature detection of DWARF5 is onerous, especially given that we've
removed $(AS), so we must query $(CC) for DWARF5 assembler directive
support.

The DWARF version of a binary can be validated with:
$ llvm-dwarfdump vmlinux | head -n 4 | grep version
or
$ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

363Mvmlinux.clang12.dwarf5.compressed
434Mvmlinux.clang12.dwarf4.compressed
439Mvmlinux.clang12.dwarf2.compressed
457Mvmlinux.clang12.dwarf5
536Mvmlinux.clang12.dwarf4
548Mvmlinux.clang12.dwarf2

515Mvmlinux.gcc10.2.dwarf5.compressed
599Mvmlinux.gcc10.2.dwarf4.compressed
624Mvmlinux.gcc10.2.dwarf2.compressed
630Mvmlinux.gcc10.2.dwarf5
765Mvmlinux.gcc10.2.dwarf4
809Mvmlinux.gcc10.2.dwarf2

Though the quality of debug info is harder to quantify; size is not a
proxy for quality.

Jakub notes:
  All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
  option that enabled some small DWARF subset (initially only a few
  DW_LANG_* codes newly added to DWARF5 drafts).  Only GCC 7 (released
  after DWARF 5 has been finalized) started emitting DWARF5 section
  headers and got most of the DWARF5 changes in...

Version check GCC so that we don't need to worry about the difference in
command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
validate the DWARF Version in the assembler feature detection script.

GNU `as` only recently gained support for specifying -gdwarf-5, so when
compiling with Clang but without Clang's integrated assembler
(LLVM_IAS=1 is not set), explicitly add -Wa,-gdwarf-5 to DEBUG_CFLAGS.

Disabled for now if CONFIG_DEBUG_INFO_BTF is set; pahole doesn't yet
recognize the new additions to the DWARF debug info. Thanks to Sedat for
the report.

Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Reported-by: Sedat Dilek 
Suggested-by: Arvind Sankar 
Suggested-by: Caroline Tice 
Suggested-by: Fangrui Song 
Suggested-by: Jakub Jelinek 
Suggested-by: Masahiro Yamada 
Suggested-by: Nathan Chancellor 
Signed-off-by: Nick Desaulniers 
---
 Makefile  | 12 
 include/asm-generic/vmlinux.lds.h |  6 +-
 lib/Kconfig.debug | 18 ++
 scripts/test_dwarf5_support.sh|  8 
 4 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100755 scripts/test_dwarf5_support.sh

diff --git a/Makefile b/Makefile
index 20141cd9319e..bed8b3b180b8 100644
--- a/Makefile
+++ b/Makefile
@@ -832,8 +832,20 @@ endif
 
 dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
 dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
 DEBUG_CFLAGS   += -gdwarf-$(dwarf-version-y)
 
+# If using clang without the integrated assembler, we need to explicitly tell
+# GAS that we will be feeding it DWARF v5 assembler directives. Kconfig should
+# detect whether the version of GAS supports DWARF v5.
+ifdef CONFIG_CC_IS_CLANG
+ifneq ($(LLVM_IAS),1)
+ifeq ($(dwarf-version-y),5)
+DEBUG_CFLAGS   += -Wa,-gdwarf-5
+endif
+endif
+endif
+
 ifdef CONFIG_DEBUG_INFO_REDUCED
 DEBUG_CFLAGS   += $(call cc-option, -femit-struct-debug-baseonly) \
   $(call cc-option,-fno-var-tracking)
diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 34b7e0d2346c..f8d5455cd87f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -843,7 +843,11 @@
.debug_types0 : { *(.debug_types) } \
/* DWARF 5 */   \
.debug_macro0 : { *(.debug_macro) } \
-   .debug_addr 0 : { *(.debug_addr) }
+   .debug_addr 0 : { *(.debug_addr) }  \
+   .debug_line_str 0 : { *(.debug_line_str) }  \
+   .debug_loclists 0 : { *(.debug_loclists) }  \
+   .debug_rnglists 0 : { *(.debug_rnglists) }  \
+   .debug_str_offsets  0 : { *(.debug_str_offsets) }
 
 /* Stabs debugging sections. */
 #define STABS_DEBUG\
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 1850728b23e6..09146b1af20d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -273,6 +273,24 @@ config DEBUG_INFO_DWARF4
  It makes the debug information larger, but it significantly
  improves the success of resolving variables in gdb on optimized code.
 
+config DEBUG_INFO_DWARF5
+   bool "Generate DWARF Version 5 debuginfo"
+   depends on GCC_VERSION >= 5 || CC_IS_CLANG
+   depends on CC_IS_GCC || 
$(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))
+   depends on !DEBUG_INFO_BTF
+   help
+ Generate DWARF v5

Re: [PATCH v2] btrfs: Avoid calling btrfs_get_chunk_map() twice

2021-01-29 Thread David Sterba

On Fri, Jan 29, 2021 at 07:02:41PM +, Michal Rostecki wrote:
> On Fri, Jan 29, 2021 at 06:47:53PM +0100, David Sterba wrote:
> > On Fri, Jan 29, 2021 at 05:15:21PM +, Michal Rostecki wrote:
> > > On Fri, Jan 29, 2021 at 11:22:48AM -0500, Josef Bacik wrote:
> > > > On 1/27/21 8:57 AM, Michal Rostecki wrote:
> > > > it happens when you run btrfs/060.  Please make sure to run xfstests 
> > > > against
> > > > patches before you submit them upstream.  Thanks,
> > > > 
> > > > Josef
> > > 
> > > Umm... I ran the xftests against v1 patch and didn't get that panic.
> > 
> > It could have been caused by my fixups to v2 and I can reproduce the
> > crash now too. I can't see any difference besides the u64/int switch and
> > the 'goto out' removal in btrfs_bio_fits_in_stripe.
> 
> I was able to fix the issue by the following diff. I will send it as the
> patch after confirming that all fstests are passing.

Thanks, can't reproduce the crash with that at least on test btrfs/060.

Re: [PATCH v7 01/14] staging: hikey9xx: spmi driver: convert to regmap

Em Fri, 29 Jan 2021 16:45:11 +0100
Greg Kroah-Hartman  escreveu:

> On Fri, Jan 29, 2021 at 04:03:36PM +0100, Mauro Carvalho Chehab wrote:
> > Instead of doing its own SPMI I/O implementation, use the
> > already-existing regmap one.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/staging/hikey9xx/hi6421-spmi-pmic.c   | 115 ++
> >  .../staging/hikey9xx/hi6421v600-regulator.c   |  26 ++--
> >  include/linux/mfd/hi6421-spmi-pmic.h  |   7 +-
> >  3 files changed, 52 insertions(+), 96 deletions(-)  
> 
> After applying this, I get a build failure:
> 
> ERROR: modpost: "__devm_regmap_init_spmi_ext" 
> [drivers/staging/hikey9xx/hi6421-spmi-pmic.ko] undefined!
> 
> So you need some sort of build dependancy here :(

It seems that it is missing REGMAP_SPMI.

> Also, when I apply the first 9 patches and stop, I get a build error
> that you should see as well, so I can't take any of these right now,
> sorry.

Gah, there was a rename patch which a hunk that went into the
following patch. Sorry. 

Added the missing select REGMAP_SPMI / REGMAP, fixed it and
tested, patch-per-patch.

I'll run a new test at the hardware to double-check if everything is
OK at the hardware and should be re-submitting the series soon enough.

Thanks,
Mauro

Re: [5.11 regression] "tty: implement write_iter" breaks TIOCCONS

2021-01-29 Thread Linus Torvalds

On Fri, Jan 29, 2021 at 11:17 AM Linus Torvalds
 wrote:
>
> On Fri, Jan 29, 2021 at 10:31 AM Hans de Goede  wrote:
> >
> > You are using Fedora now a days, right ?  In that case you should be
> > able to reproduce this yourself (depending on how custom your kernel
> > setup is) if you are using the standard Fedora initrd generated by
> > dracut and have "rhgb" on your kernel cmdline, then you can check
> > for this problem by doing:
>
> Thanks, I can see it, that should make it much easier to figure out.

Ahh, interesting.

It turns out that the problem isn't actually really in the tty layer,
it's that vfs_iocb_iter_write() is very very subtly buggy.

So the tty layer "trivial" conversion from using "vfs_write()" - for
the old redirected tty_write() call - to using "vfs_iocb_iter_write()"
caused problems.

Why? Because both vfs_write() and vfs_iocb_iter_write() take the
target "struct file *file" as an argument, but vfs_iocb_iter_write()
doesn't actually *use* that target file!

Well, to be specific, it does actually use the target file pointer for
two things:

 - the security checks

 - to pick the actual ->write_iter function.

But once you actually call ->write_iter() to do the IO, the 'file'
pointer isn't actually passed down at all, and the write_iter()
function depends not on 'file', but on 'iocb->ki_filp".

In other words, vfs_iocb_iter_write() is completely broken, because it
will do the preliminary work using one 'struct file *', but then do
the actual IO using _another_ 'struct file *' entirely.

In the case of the console redirect code, that meant that the
"redirect" never actually redirected anything, it really just called
tty_write() with the original iocb, which used the original target
file pointer.

Let's just say that I stared at those tty changes for a while, saying
"there is no *POSSIBLE* way that introduces a bug". And yeah, the tty
changes themselves were actually not the real culprit.

Of course, there is only one other user of vfs_iocb_iter_write() -
ovlfs - and that one fills in the iocb with the same file pointer that
it uses as the first argument, so nobody has ever noticed this oddity
before.

The function has been buggy like this since the very first
implementation, and vfs_iocb_iter_read() has the exact same issue.

It's fairly easy to work around in this in the tty layer by just
avoiding that function entirely, so I'll cook up a patch to do that.
But I'm adding the appropriate people to the participants here because
this really is very subtle if you ever hit it.

It might be best to just remove the "struct file *file" argument from
vfs_iocb_iter_{read,write}(), because it really is very wrong to use
anything but iocb.ki_file, and it's really subtle.

 Linus

Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG

On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote:
> >> SO_OOBINLINE does not control the delivery of signal, It controls how
> >> OOB Byte is delivered. It may not be obvious but this change does not
> >> deliver any Byte, just a signal. So, as long as sendmsg flag contains
> >> MSG_OOB, signal will be delivered just like it happens for TCP.  
> > Not as far as I can read this code. If MSG_OOB is set the data from the
> > message used to be discarded, and EOPNOTSUPP returned. Now the data gets
> > queued to the socket, and will be read inline.  
> 
> Data was discarded because the flag was not supported, this patch 
> changes that but does not support any urgent data.

When you say it does not support any urgent data do you mean the
message len must be == 0 because something is checking it, or that 
the code does not support its handling?

I'm perfectly fine with the former, just point me at the check, please.

> OOB data has some semantics that would have to be followed and if we 
> support SO_OOBINLINE we would have to support NOT SO_OOBINLINE.
> 
> One can argue that we add a socket option to allow this OR just do what 
> TCP does.

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

On Fri, Jan 29, 2021 at 8:43 PM Nick Desaulniers
 wrote:
>
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> DWARF5 wins significantly in terms of size and especially so when mixed
> with compression (CONFIG_DEBUG_INFO_COMPRESSED).
>
> Link: http://www.dwarfstd.org/doc/DWARF5.pdf
>
> Patch 1 is a cleanup that lays the ground work and isn't DWARF
> v5 specific.
> Patch 2 implements Kconfig and Kbuild support for DWARFv5.
>

Thanks for v6 - I queued it up in my custom patch-series.

- Sedat -

> Changes from v5:
> * Drop previous patch 1, it has been accepted into kbuild:
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44
> * Trying to set -Wa,-gdwarf-4 in the earlier patch was the source of
>   additional complexity. Drop it that part of the patch. We can revisit
>   clang without the integrated assembler setting -Wa,-gdwarf-4 later.
>   That is a separate problem from generally supporting DWARF v5.
> * Rework the final patch for clang without the integrated assembler.
>   -Wa,-gdwarf-5 is required for DWARF5 in that case otherwise GAS will
>   not accept the assembler directives clang produces from C code when
>   generating asm.
>
> Changes from v4:
> * drop set -e from script as per Nathan.
> * add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat.
> * Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and
>   Masahiro. Sorry it took me a few tries to understand the point (I
>   might still not), but it looks much cleaner this way. Sorry Nathan, I
>   did not carry forward your previous reviews as a result, but I would
>   appreciate if you could look again.
> * Add Nathan's reviewed by tag to patch 1.
> * Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5
>   binutils addition later, and BTF issue.
> * I still happen to see a pahole related error spew for the combination
>   of:
>   * LLVM=1
>   * LLVM_IAS=1
>   * CONFIG_DEBUG_INFO_DWARF4
>   * CONFIG_DEBUG_INFO_BTF
>   Though they're non-fatal to the build. I'm not sure yet why removing
>   any one of the above prevents the warning spew. Maybe we'll need a v6.
>
> Changes from v3:
>
> Changes as per Arvind:
> * only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds.
> * add -gdwarf-5 to Kconfig shell script.
> * only run Kconfig shell script for Clang.
>
> Apologies to Sedat and Nathan; I appreciate previous testing/review, but
> I did no carry forward your Tested-by and Reviewed-by tags, as the
> patches have changed too much IMO.
>
> Changes from v2:
> * Drop two of the earlier patches that have been accepted already.
> * Add measurements with GCC 10.2 to commit message.
> * Update help text as per Arvind with help from Caroline.
> * Improve case/wording between DWARF Versions as per Masahiro.
>
> Changes from the RFC:
> * split patch in 3 patch series, include Fangrui's patch, too.
> * prefer `DWARF vX` format, as per Fangrui.
> * use spaces between assignment in Makefile as per Masahiro.
> * simplify setting dwarf-version-y as per Masahiro.
> * indent `prompt` in Kconfig change as per Masahiro.
> * remove explicit default in Kconfig as per Masahiro.
> * add comments to test_dwarf5_support.sh.
> * change echo in test_dwarf5_support.sh as per Masahiro.
> * remove -u from test_dwarf5_support.sh as per Masahiro.
> * add a -gdwarf-5 cc-option check to Kconfig as per Jakub.
>
> Nick Desaulniers (2):
>   Kbuild: make DWARF version a choice
>   Kbuild: implement support for DWARF v5
>
>  Makefile  | 16 ++--
>  include/asm-generic/vmlinux.lds.h |  6 -
>  lib/Kconfig.debug | 41 ++-
>  scripts/test_dwarf5_support.sh|  8 ++
>  4 files changed, 62 insertions(+), 9 deletions(-)
>  create mode 100755 scripts/test_dwarf5_support.sh
>
> --
> 2.30.0.365.g02bc693789-goog
>

Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG

2021-01-29 Thread Shoaib Rao




On 1/29/21 11:54 AM, Shoaib Rao wrote:


On 1/29/21 11:19 AM, Matthew Wilcox wrote:

On Fri, Jan 29, 2021 at 09:56:48AM -0800, Shoaib Rao wrote:

On 1/25/21 3:36 PM, Jakub Kicinski wrote:

On Fri, 22 Jan 2021 15:06:37 + Matthew Wilcox (Oracle) wrote:

From: Rao Shoaib 

TCP sockets allow SIGURG to be sent to the process holding the other
end of the socket.  Extend Unix sockets to have the same ability.

The API is the same in that the sender uses sendmsg() with MSG_OOB to
raise SIGURG.  Unix sockets behave in the same way as TCP sockets 
with

SO_OOBINLINE set.
Noob question, if we only want to support the inline mode, why 
don't we

require SO_OOBINLINE to have been called on @other? Wouldn't that
provide more consistent behavior across address families?

With the current implementation the receiver will also not see MSG_OOB
set in msg->msg_flags, right?

SO_OOBINLINE does not control the delivery of signal, It controls how
OOB Byte is delivered. It may not be obvious but this change does not
deliver any Byte, just a signal. So, as long as sendmsg flag contains
MSG_OOB, signal will be delivered just like it happens for TCP.

I don't think that's the question Jakub is asking.  As I understand it,
if you send a MSG_OOB on a TCP socket and the receiver calls recvmsg(),
it will see MSG_OOB set, even if SO_OOBINLINE is set.

No it wont. Application just gets a signal.

   That wouldn't
happen with Unix sockets.  I'm OK with that difference in behaviour,
because MSG_OOB on Unix sockets _is not_ for sending out of band data.
It's just for sending an urgent signal.

That is what I just explained in my email


As you say, MSG_OOB does not require data to be sent for unix sockets
(unlike TCP which always requires at least one byte), but one can
choose to send data as part of a message which has MSG_OOB set. It
won't be tagged in any special way.

To Jakub's other question, we could require SO_OOBINLINE to be set.
That'd provide another layer of insurance against applications being
surprised by a SIGURG they weren't expecting.  I don't know that it's
really worth it though.


SO_OOBINLINE has a meaning, that the urgent byte is part of the stream 
and using SO_OOBLINE to allow signalling would be wrong/confusing. We 
could add a socket option on the receiver to indicate if it supports 
or wants the signal.




One thing I wasn't clear about, and maybe you know, if we send a 
MSG_OOB,

does this patch cause this part of the tcp(7) manpage to be true for
unix sockets too?

    When out-of-band data is present, select(2) indicates the 
file descrip‐
    tor as having an exceptional condition and poll (2) indicates 
a POLLPRI

    event.


No because there is no data involved. Poll is associated with data not 
signals.


Shoaib


SO_OOBINLINE implies there is urgent data inline -- This patch will send 
a signal even if there is no data.


Shoaib

Re: [PATCH 3/6] soundwire: qcom: set continue execution flag for ignored commands

2021-01-29 Thread Pierre-Louis Bossart





On 1/29/21 11:32 AM, Srinivas Kandagatla wrote:

version 1.5.1 and higher IPs of this controller required to set
continue execution on ingored command flag. This patch sets this flag.


typo: ignored.

Re: [PATCH 5/6] soundwire: qcom: update register read/write routine

2021-01-29 Thread Pierre-Louis Bossart





On 1/29/21 11:32 AM, Srinivas Kandagatla wrote:

In the existing code every soundwire register read and register write
are kinda blocked. Each of these are using a special command id that


what does 'kinda blocked' mean?


generates interrupt after it successfully finishes. This is really
overhead, limiting and not really necessary unless we are doing
something special.

We can simply read/write the fifo that should also give exactly
what we need! This will also allow to read/write registers in
interrupt context, which was not possible with the special
command approach.


This is really unclear, sorry.


+   if (id != SWR_BROADCAST_CMD_ID) {
+   if (id < 14)
+   id += 1;
+   else
+   id = 0;


that is really odd. if id=13 (group2) then id becomes 14 (master 
address). A comment is really needed here.



+   if (cmd_id == SWR_BROADCAST_CMD_ID) {
+   /*
+* sleep for 10ms for MSM soundwire variant to allow broadcast
+* command to complete.


that's also super-odd. There is nothing in SoundWire that makes any 
difference between a regular and a broadcast command. they all complete 
in the same time (a frame).

+*/
+   ret = wait_for_completion_timeout(>broadcast, (2 * 
HZ/10));


is this 10ms really or dependent on CONFIG_HZ?


+   if (!ret)
+   ret = SDW_CMD_IGNORED;
+   else
+   ret = SDW_CMD_OK;


no CMD_FAILED support?


+static int qcom_swrm_cmd_fifo_rd_cmd(struct qcom_swrm_ctrl *swrm,
+u8 dev_addr, u16 reg_addr,
+u32 len, u8 *rval)
+{
+   u32 val;
+   u32 retry_attempt = 0;
+   u32 cmd_data;
+   int ret = SDW_CMD_OK;
+
+   mutex_lock(>io_lock);
+   val = swrm_get_packed_reg_val(>rcmd_id, len, dev_addr, reg_addr);
+
+   /* wait for FIFO RD to complete to avoid overflow */
+   usleep_range(100, 105);
+   swrm->reg_write(swrm, SWRM_CMD_FIFO_RD_CMD, val);
+   /* wait for FIFO RD CMD complete to avoid overflow */
+   usleep_range(250, 255);
+
+retry_read:
+
+   swrm->reg_read(swrm, SWRM_CMD_FIFO_RD_FIFO_ADDR, _data);
+   rval[0] = cmd_data & 0xFF;
+
+   if cmd_data) & 0xF00) >> 8) != swrm->rcmd_id) {
+   if (retry_attempt < MAX_FIFO_RD_FAIL_RETRY) {
+   /* wait 500 us before retry on fifo read failure */
+   usleep_range(500, 505);
+   if (retry_attempt == (MAX_FIFO_RD_FAIL_RETRY - 1)) {
+   swrm->reg_write(swrm, SWRM_CMD_FIFO_CMD, 0x1);
+   swrm->reg_write(swrm, SWRM_CMD_FIFO_RD_CMD, 
val);
+   }
+   retry_attempt++;
+   goto retry_read;
+   } else {
+   dev_err(swrm->dev,
+   "failed to read fifo: reg: 0x%x, \
+   rcmd_id: 0x%x, dev_num: 0x%x, cmd_data: 
0x%x\n",
+   reg_addr, swrm->rcmd_id,
+   dev_addr, cmd_data);
+   ret = SDW_CMD_IGNORED;
+   }
}


the flow seems complicated with multiple tests and goto? Can this be 
simplified?

Re: [PATCH v6 1/2] Kbuild: make DWARF version a choice