Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo
On Sun, Oct 11, 2020 at 12:37 AM Randy Dunlap wrote: > > Hi, > > On 10/10/20 3:38 AM, Muchun Song wrote: > > The amount of memory allocated to sockets buffer can become significant. > > However, we do not display the amount of memory consumed by sockets > > buffer. In this case, knowing where the memory is consumed by the kernel > > is very difficult. On our server with 500GB RAM, sometimes we can see > > 25GB disappear through /proc/meminfo. After our analysis, we found the > > following memory allocation path which consumes the memory with page_owner > > enabled. > > > > 849698 times: > > Page allocated via order 3, mask > > 0x4052c0(GFP_NOWAIT|__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP) > >__alloc_pages_nodemask+0x11d/0x290 > >skb_page_frag_refill+0x68/0xf0 > >sk_page_frag_refill+0x19/0x70 > >tcp_sendmsg_locked+0x2f4/0xd10 > >tcp_sendmsg+0x29/0xa0 > >sock_sendmsg+0x30/0x40 > >sock_write_iter+0x8f/0x100 > >__vfs_write+0x10b/0x190 > >vfs_write+0xb0/0x190 > >ksys_write+0x5a/0xd0 > >do_syscall_64+0x5d/0x110 > >entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > Signed-off-by: Muchun Song > > --- > > drivers/base/node.c | 2 ++ > > drivers/net/virtio_net.c | 3 +-- > > fs/proc/meminfo.c| 1 + > > include/linux/mmzone.h | 1 + > > include/linux/skbuff.h | 43 ++-- > > kernel/exit.c| 3 +-- > > mm/page_alloc.c | 7 +-- > > mm/vmstat.c | 1 + > > net/core/sock.c | 8 > > net/ipv4/tcp.c | 3 +-- > > net/xfrm/xfrm_state.c| 3 +-- > > 11 files changed, 59 insertions(+), 16 deletions(-) > > Thanks for finding that. > > Please update Documentation/filesystems/proc.rst "meminfo" section also. Will do. Thanks for your suggestions. > > -- > ~Randy > -- Yours, Muchun
[PATCH] net: Avoid allocing memory on memoryless numa node
In architecture like powerpc, we can have cpus without any local memory attached to it. In such cases the node does not have real memory. Use local_memory_node(), which is guaranteed to have memory. local_memory_node is a noop in other architectures that does not support memoryless nodes. Signed-off-by: Xianting Tian --- net/core/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 266073e30..dcb4533ef 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2590,7 +2590,7 @@ static struct xps_map *expand_xps_map(struct xps_map *map, int attr_index, new_map = kzalloc(XPS_MAP_SIZE(alloc_len), GFP_KERNEL); else new_map = kzalloc_node(XPS_MAP_SIZE(alloc_len), GFP_KERNEL, - cpu_to_node(attr_index)); + local_memory_node(cpu_to_node(attr_index))); if (!new_map) return NULL; -- 2.17.1
[PATCH] risc-v: kernel: ftrace: Fixes improper SPDX comment style
Signed-off-by: Ryan Kosta --- arch/riscv/kernel/ftrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c index 99e12faa549..765b62434f3 100644 --- a/arch/riscv/kernel/ftrace.c +++ b/arch/riscv/kernel/ftrace.c @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0 */ +// SPDX-License-Identifier: GPL-2.0 /* * Copyright (C) 2013 Linaro Limited * Author: AKASHI Takahiro -- 2.20.1
[PATCH 3/5] gpio: msc313: MStar MSC313 GPIO driver
This adds a driver that supports the GPIO block found in MStar/SigmaStar ARMv7 SoCs. The controller seems to support 128 lines but where they are wired up differs between chips and no currently known chip uses anywhere near 128 lines so there needs to be some per-chip data to collect together what lines actually have physical pins attached and map the right names to them. The core peripherals seem to use the same lines on the currently known chips but the lines used for the sensor interface, lcd controller etc pins seem to be totally different between the infinity and mercury chips The code tries to collect all of the re-usable names, offsets etc together so that it's easy to build the extra per-chip data for other chips in the future. So far this only supports the MSC313 and MSC313E chips. Support for the SSC8336N (mercury5) is trivial to add once all of the lines have been mapped out. Signed-off-by: Daniel Palmer --- MAINTAINERS| 1 + drivers/gpio/Kconfig | 9 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-msc313.c | 341 + 4 files changed, 352 insertions(+) create mode 100644 drivers/gpio/gpio-msc313.c diff --git a/MAINTAINERS b/MAINTAINERS index ec5b49b9955f..d20e8935dd4c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2158,6 +2158,7 @@ F:Documentation/devicetree/bindings/arm/mstar/* F: Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml F: arch/arm/boot/dts/mstar-* F: arch/arm/mach-mstar/ +F: drivers/gpio/gpio-msc313.c F: include/dt-bindings/gpio/msc313-gpio.h ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 8030fd91a3cc..d85226cb2a07 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -712,6 +712,15 @@ config GPIO_AMD_FCH Note: This driver doesn't registers itself automatically, as it needs to be provided with platform specific configuration. (See eg. CONFIG_PCENGINES_APU2.) + +config GPIO_MSC313 + bool "MStar MSC313 GPIO support" + default y if ARCH_MSTARV7 + depends on ARCH_MSTARV7 + select GPIO_GENERIC + help + Say Y here to support GPIO on MStar MSC313 and later SoCs. + endmenu menu "Port-mapped I/O GPIO drivers" diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index 4f9abff4f2dc..7c675b502cc4 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -102,6 +102,7 @@ obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o obj-$(CONFIG_GPIO_MOXTET) += gpio-moxtet.o obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o +obj-$(CONFIG_GPIO_MSC313) += gpio-msc313.o obj-$(CONFIG_GPIO_MSIC)+= gpio-msic.o obj-$(CONFIG_GPIO_MT7621) += gpio-mt7621.o obj-$(CONFIG_GPIO_MVEBU) += gpio-mvebu.o diff --git a/drivers/gpio/gpio-msc313.c b/drivers/gpio/gpio-msc313.c new file mode 100644 index ..6bdab77674ae --- /dev/null +++ b/drivers/gpio/gpio-msc313.c @@ -0,0 +1,341 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Daniel Palmer + */ + +#include +#include +#include + +#include + +#define DRIVER_NAME "gpio-msc313" + +#define MSC313_GPIO_IN BIT(0) +#define MSC313_GPIO_OUT BIT(4) +#define MSC313_GPIO_OEN BIT(5) + +#define MSC313_GPIO_BITSTOSAVE (MSC313_GPIO_OUT | MSC313_GPIO_OEN) + +#define FUART_NAMES\ + MSC313_PINNAME_FUART_RX,\ + MSC313_PINNAME_FUART_TX,\ + MSC313_PINNAME_FUART_CTS, \ + MSC313_PINNAME_FUART_RTS + +#define OFF_FUART_RX 0x50 +#define OFF_FUART_TX 0x54 +#define OFF_FUART_CTS 0x58 +#define OFF_FUART_RTS 0x5c + +#define FUART_OFFSETS \ + OFF_FUART_RX, \ + OFF_FUART_TX, \ + OFF_FUART_CTS, \ + OFF_FUART_RTS + +#define SR_NAMES \ + MSC313_PINNAME_SR_IO2, \ + MSC313_PINNAME_SR_IO3, \ + MSC313_PINNAME_SR_IO4, \ + MSC313_PINNAME_SR_IO5, \ + MSC313_PINNAME_SR_IO6, \ + MSC313_PINNAME_SR_IO7, \ + MSC313_PINNAME_SR_IO8, \ + MSC313_PINNAME_SR_IO9, \ + MSC313_PINNAME_SR_IO10, \ + MSC313_PINNAME_SR_IO11, \ + MSC313_PINNAME_SR_IO12, \ + MSC313_PINNAME_SR_IO13, \ + MSC313_PINNAME_SR_IO14, \ + MSC313_PINNAME_SR_IO15, \ + MSC313_PINNAME_SR_IO16, \ + MSC313_PINNAME_SR_IO17 + +#define OFF_SR_IO2 0x88 +#define OFF_SR_IO3 0x8c +#define OFF_SR_IO4 0x90 +#define OFF_SR_IO5 0x94 +#define OFF_SR_IO6 0x98 +#define OFF_SR_IO7 0x9c +#define OFF_SR_IO8 0xa0 +#define OFF_SR_IO9 0xa4 +#define OFF_SR_IO100xa8 +#define OFF_SR_IO110xac +#define OFF_SR_IO120xb0 +#define OFF_SR_IO130xb4 +#define OFF_SR_IO140xb8 +#define OFF_SR_IO150xbc +#define OFF_SR_IO160xc0 +#define OFF_SR_IO170xc4 + +#define SR_OFFSETS
[PATCH 0/5] Add GPIO support for MStar/SigmaStar ARMv7
At the moment the MStar/SigmaStar support is only really capable of shell from an initramfs and not much else. Most of the interesting drivers are blocked on clock and pinctrl drivers and those are going to take me a little while to get cleaned up. Clock and pinctrl aren't needed for basic GPIO to work (all pins start off as GPIOs..) and it makes it possible to actually do something so this series adds everything that is needed for the main GPIO block in these chips. Daniel Palmer (5): dt-bindings: gpio: Binding for MStar MSC313 GPIO controller dt-bindings: gpio: Add a binding header for the MSC313 GPIO driver gpio: msc313: MStar MSC313 GPIO driver ARM: mstar: Add gpio controller to MStar base dtsi ARM: mstar: Fill in GPIO controller properties for infinity .../bindings/gpio/mstar,msc313-gpio.yaml | 69 MAINTAINERS | 3 + arch/arm/boot/dts/mstar-infinity.dtsi | 16 + arch/arm/boot/dts/mstar-v7.dtsi | 7 + drivers/gpio/Kconfig | 9 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-msc313.c| 341 ++ include/dt-bindings/gpio/msc313-gpio.h| 95 + 8 files changed, 541 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml create mode 100644 drivers/gpio/gpio-msc313.c create mode 100644 include/dt-bindings/gpio/msc313-gpio.h -- 2.27.0
[PATCH 1/5] dt-bindings: gpio: Binding for MStar MSC313 GPIO controller
Add a binding description for the MStar/SigmaStar GPIO controller
found in the MSC313 and later ARMv7 SoCs.
Signed-off-by: Daniel Palmer
---
.../bindings/gpio/mstar,msc313-gpio.yaml | 69 +++
MAINTAINERS | 1 +
2 files changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
diff --git a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
new file mode 100644
index ..07ef463273d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/mstar,msc313-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MStar/SigmaStar GPIO controller
+
+maintainers:
+ - Daniel Palmer
+
+properties:
+ $nodename:
+pattern: "^gpio@[0-9a-f]+$"
+
+ compatible:
+const: mstar,msc313-gpio
+
+ reg:
+maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+const: 2
+
+ gpio-ranges: true
+
+ gpio-ranges-group-names:
+$ref: /schemas/types.yaml#/definitions/string-array
+
+ interrupts: true
+
+ interrupt-names:
+description: |
+ The interrupt name should match the pin that the interrupt
+ is connected to.
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+examples:
+ - |
+#include
+#include
+#include
+
+gpio: gpio@207800 {
+ compatible = "mstar,msc313e-gpio";
+ #gpio-cells = <2>;
+ reg = <0x207800 0x200>;
+ gpio-controller;
+ gpio-ranges = < 0 36 22>,
+< 22 63 4>,
+< 26 68 6>;
+ interrupt-parent = <_fiq>;
+ interrupt-names = MSC313_PINNAME_SPI0_CZ,
+MSC313_PINNAME_SPI0_CK,
+MSC313_PINNAME_SPI0_DI,
+MSC313_PINNAME_SPI0_DO;
+ interrupts = ,
+ ,
+ ,
+ ;
+ status = "okay";
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 75b04ba10f21..4594b70f2e3a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2155,6 +2155,7 @@ L:linux-arm-ker...@lists.infradead.org (moderated
for non-subscribers)
S: Maintained
W: http://linux-chenxing.org/
F: Documentation/devicetree/bindings/arm/mstar/*
+F: Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
F: arch/arm/boot/dts/mstar-*
F: arch/arm/mach-mstar/
--
2.27.0
[PATCH 5/5] ARM: mstar: Fill in GPIO controller properties for infinity
Fill in the properties needed to use the GPIO controller
in the infinity and infinity3 chips.
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/mstar-infinity.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity.dtsi
b/arch/arm/boot/dts/mstar-infinity.dtsi
index cd911adef014..6432b2976c2c 100644
--- a/arch/arm/boot/dts/mstar-infinity.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity.dtsi
@@ -6,6 +6,22 @@
#include "mstar-v7.dtsi"
+#include
+
{
reg = <0xa000 0x16000>;
};
+
+ {
+ compatible = "mstar,msc313-gpio";
+ interrupt-parent = <_fiq>;
+ interrupt-names = MSC313_PINNAME_SPI0_CZ,
+ MSC313_PINNAME_SPI0_CK,
+ MSC313_PINNAME_SPI0_DI,
+ MSC313_PINNAME_SPI0_DO;
+ interrupts = ,
+,
+,
+;
+ status = "okay";
+};
--
2.27.0
[PATCH 2/5] dt-bindings: gpio: Add a binding header for the MSC313 GPIO driver
The driver uses the pin names to find the right interrupt for a pin from the device tree so this header reduces the need to have multiple copies of the same string all over the place. This header also adds defines for the gpio number of each pin from the driver view. The gpio block seems to support 128 lines but what line is mapped to a physical pin depends on the chip. The driver itself uses the index of a pin's offset in an array of the possible offsets for a chip as the gpio number. The defines remove the need to work out that index to consume a pin in the device tree. Signed-off-by: Daniel Palmer --- MAINTAINERS| 1 + include/dt-bindings/gpio/msc313-gpio.h | 95 ++ 2 files changed, 96 insertions(+) create mode 100644 include/dt-bindings/gpio/msc313-gpio.h diff --git a/MAINTAINERS b/MAINTAINERS index 4594b70f2e3a..ec5b49b9955f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2158,6 +2158,7 @@ F:Documentation/devicetree/bindings/arm/mstar/* F: Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml F: arch/arm/boot/dts/mstar-* F: arch/arm/mach-mstar/ +F: include/dt-bindings/gpio/msc313-gpio.h ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT M: Michael Petchkovsky diff --git a/include/dt-bindings/gpio/msc313-gpio.h b/include/dt-bindings/gpio/msc313-gpio.h new file mode 100644 index ..655fe03de519 --- /dev/null +++ b/include/dt-bindings/gpio/msc313-gpio.h @@ -0,0 +1,95 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * GPIO definitions for MStar/SigmaStar MSC313 and later SoCs + * + * Copyright (C) 2020 Daniel Palmer + */ + +#ifndef _DT_BINDINGS_MSC313_GPIO_H +#define _DT_BINDINGS_MSC313_GPIO_H + +/* pin names for fuart, same for all SoCs so far */ +#define MSC313_PINNAME_FUART_RX"fuart_rx" +#define MSC313_PINNAME_FUART_TX"fuart_tx" +#define MSC313_PINNAME_FUART_CTS "fuart_cts" +#define MSC313_PINNAME_FUART_RTS "fuart_rts" + +/* pin names for sr, mercury5 is different */ +#define MSC313_PINNAME_SR_IO2 "sr_io2" +#define MSC313_PINNAME_SR_IO3 "sr_io3" +#define MSC313_PINNAME_SR_IO4 "sr_io4" +#define MSC313_PINNAME_SR_IO5 "sr_io5" +#define MSC313_PINNAME_SR_IO6 "sr_io6" +#define MSC313_PINNAME_SR_IO7 "sr_io7" +#define MSC313_PINNAME_SR_IO8 "sr_io8" +#define MSC313_PINNAME_SR_IO9 "sr_io9" +#define MSC313_PINNAME_SR_IO10 "sr_io10" +#define MSC313_PINNAME_SR_IO11 "sr_io11" +#define MSC313_PINNAME_SR_IO12 "sr_io12" +#define MSC313_PINNAME_SR_IO13 "sr_io13" +#define MSC313_PINNAME_SR_IO14 "sr_io14" +#define MSC313_PINNAME_SR_IO15 "sr_io15" +#define MSC313_PINNAME_SR_IO16 "sr_io16" +#define MSC313_PINNAME_SR_IO17 "sr_io17" + +/* pin names for sd, same for all SoCs so far */ +#define MSC313_PINNAME_SD_CLK "sd_clk" +#define MSC313_PINNAME_SD_CMD "sd_cmd" +#define MSC313_PINNAME_SD_D0 "sd_d0" +#define MSC313_PINNAME_SD_D1 "sd_d1" +#define MSC313_PINNAME_SD_D2 "sd_d2" +#define MSC313_PINNAME_SD_D3 "sd_d3" + +/* pin names for i2c1, same for all SoCs so for */ +#define MSC313_PINNAME_I2C1_SCL"i2c1_scl" +#define MSC313_PINNAME_I2C1_SCA"i2c1_sda" + +/* pin names for spi0, same for all SoCs so far */ +#define MSC313_PINNAME_SPI0_CZ "spi0_cz" +#define MSC313_PINNAME_SPI0_CK "spi0_ck" +#define MSC313_PINNAME_SPI0_DI "spi0_di" +#define MSC313_PINNAME_SPI0_DO "spi0_do" + +#define MSC313_GPIO_FUART 0 +#define MSC313_GPIO_FUART_RX (MSC313_GPIO_FUART + 0) +#define MSC313_GPIO_FUART_TX (MSC313_GPIO_FUART + 1) +#define MSC313_GPIO_FUART_CTS (MSC313_GPIO_FUART + 2) +#define MSC313_GPIO_FUART_RTS (MSC313_GPIO_FUART + 3) + +#define MSC313_GPIO_SR (MSC313_GPIO_FUART_RTS + 1) +#define MSC313_GPIO_SR_IO2 (MSC313_GPIO_SR + 0) +#define MSC313_GPIO_SR_IO3 (MSC313_GPIO_SR + 1) +#define MSC313_GPIO_SR_IO4 (MSC313_GPIO_SR + 2) +#define MSC313_GPIO_SR_IO5 (MSC313_GPIO_SR + 3) +#define MSC313_GPIO_SR_IO6 (MSC313_GPIO_SR + 4) +#define MSC313_GPIO_SR_IO7 (MSC313_GPIO_SR + 5) +#define MSC313_GPIO_SR_IO8 (MSC313_GPIO_SR + 6) +#define MSC313_GPIO_SR_IO9 (MSC313_GPIO_SR + 7) +#define MSC313_GPIO_SR_IO10(MSC313_GPIO_SR + 8) +#define MSC313_GPIO_SR_IO11(MSC313_GPIO_SR + 9) +#define MSC313_GPIO_SR_IO12(MSC313_GPIO_SR + 10) +#define MSC313_GPIO_SR_IO13(MSC313_GPIO_SR + 11) +#define MSC313_GPIO_SR_IO14(MSC313_GPIO_SR + 12) +#define MSC313_GPIO_SR_IO15(MSC313_GPIO_SR + 13) +#define MSC313_GPIO_SR_IO16(MSC313_GPIO_SR + 14) +#define MSC313_GPIO_SR_IO17(MSC313_GPIO_SR + 15) + +#define MSC313_GPIO_SD (MSC313_GPIO_SR_IO17 + 1) +#define MSC313_GPIO_SD_CLK (MSC313_GPIO_SD + 0) +#define MSC313_GPIO_SD_CMD (MSC313_GPIO_SD + 1) +#define MSC313_GPIO_SD_D0
[PATCH 4/5] ARM: mstar: Add gpio controller to MStar base dtsi
The GPIO controller is at the same address in all of the
currently known chips so create a node for it in the base
dtsi.
Some extra properties are needed to actually use it so
disable it by default.
Signed-off-by: Daniel Palmer
---
arch/arm/boot/dts/mstar-v7.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
index f07880561e11..669aada6f286 100644
--- a/arch/arm/boot/dts/mstar-v7.dtsi
+++ b/arch/arm/boot/dts/mstar-v7.dtsi
@@ -109,6 +109,13 @@ l3bridge: l3bridge@204400 {
reg = <0x204400 0x200>;
};
+ gpio: gpio@207800 {
+ #gpio-cells = <2>;
+ reg = <0x207800 0x200>;
+ gpio-controller;
+ status = "disabled";
+ };
+
pm_uart: uart@221000 {
compatible = "ns16550a";
reg = <0x221000 0x100>;
--
2.27.0
Re: [PATCH 4/4] soc: mediatek: mmsys: Use an array for setting the routing registers
Hi, Matthias: Matthias Brugger 於 2020年10月8日 週四 下午6:22寫道： > > Hi Enric and CK, > > On 06/10/2020 21:33, Enric Balletbo i Serra wrote: > > From: CK Hu > > > > Actually, setting the registers for routing, use multiple 'if-else' for > > different > > routes, but this code would be more and more complicated while we > > support more and more SoCs. Change that and use a table per SoC so the > > code will be more portable and clear. > > > > I'd like to have some clarifications on this patch. Now we use one big if-else > structure to decide which value and address we need. As this values work for a > large set of SoCs I suppose the hardware block is the same. > > When we add new HW like mt8183, mt8192 or mt6779 we will need different > values. > But my question is, if the HW between theses new platforms will be different > (read values change for every SoC). Or will it be the same HW block for all > these SoCs so that we could add three new functions ddp_mout_en, ddp_sout_sel > and ddp_sel_in. > As I know, routes in mt8173, mt2701, mt2712 are different. That means in the same register address, it control different input/output selection for each SoC. But they use a very tricky way to use the same table: some register's default value (the default routes) meet their requirement, they do not set it and just set the register whose default value does not meet the requirement. But this tricky way fail when support more SoC, so mt8183 and mt8192 need an independent route. So we have better have different route for each SoC, but we don't have the complete route information for these three SoC, so just keep them in the same table. After we've more information, we could separate mt2701, mt2712 to an independent table. > Why I'm asking? Because right now it seems like double the work we have to do > for every SoC. We will need to define the components in the DRM driver and > then > we need to add the values for the routing. The double work are two different function work. mmsys driver provide full routing control and drm choose the route according to its application. For example: mmsys provide the three route: rdma0 -> dsi0 rdma1 -> dsi0 rdma2 -> dsi0 and drm could only choose one at some moment. Even drm now just choose rdma0 -> dsi0, I think mmsys still should provide the full route control like clock driver (even though some clock is not use by client driver, clock driver should implement all clock control function) > > More comments below. > > > Signed-off-by: CK Hu > > Signed-off-by: Enric Balletbo i Serra > > --- > > > > drivers/soc/mediatek/mtk-mmsys.c | 393 +-- > > 1 file changed, 210 insertions(+), 183 deletions(-) > > > > diff --git a/drivers/soc/mediatek/mtk-mmsys.c > > b/drivers/soc/mediatek/mtk-mmsys.c > > index da2de8f6969e..f00d6d08c9c5 100644 > > --- a/drivers/soc/mediatek/mtk-mmsys.c > > +++ b/drivers/soc/mediatek/mtk-mmsys.c > > @@ -42,39 +42,61 @@ > > #define RDMA0_SOUT_DSI1 0x1 > > #define RDMA0_SOUT_DSI2 0x4 > > #define RDMA0_SOUT_DSI3 0x5 > > +#define RDMA0_SOUT_MASK 0x7 > > #define RDMA1_SOUT_DPI0 0x2 > > #define RDMA1_SOUT_DPI1 0x3 > > #define RDMA1_SOUT_DSI1 0x1 > > #define RDMA1_SOUT_DSI2 0x4 > > #define RDMA1_SOUT_DSI3 0x5 > > +#define RDMA1_SOUT_MASK 0x7 > > #define RDMA2_SOUT_DPI0 0x2 > > #define RDMA2_SOUT_DPI1 0x3 > > #define RDMA2_SOUT_DSI1 0x1 > > #define RDMA2_SOUT_DSI2 0x4 > > #define RDMA2_SOUT_DSI3 0x5 > > +#define RDMA2_SOUT_MASK 0x7 > > #define DPI0_SEL_IN_RDMA1 0x1 > > #define DPI0_SEL_IN_RDMA2 0x3 > > +#define DPI0_SEL_IN_MASK 0x3 > > #define DPI1_SEL_IN_RDMA1 (0x1 << 8) > > #define DPI1_SEL_IN_RDMA2 (0x3 << 8) > > +#define DPI1_SEL_IN_MASK (0x3 << 8) > > #define DSI0_SEL_IN_RDMA1 0x1 > > #define DSI0_SEL_IN_RDMA2 0x4 > > +#define DSI0_SEL_IN_MASK 0x7 > > #define DSI1_SEL_IN_RDMA1 0x1 > > #define DSI1_SEL_IN_RDMA2 0x4 > > +#define DSI1_SEL_IN_MASK 0x7 > > #define DSI2_SEL_IN_RDMA1 (0x1 << 16) > > #define DSI2_SEL_IN_RDMA2 (0x4 << 16) > > +#define DSI2_SEL_IN_MASK (0x7 << 16) > > #define DSI3_SEL_IN_RDMA1 (0x1 << 16) > > #define DSI3_SEL_IN_RDMA2 (0x4 << 16) > > +#define DSI3_SEL_IN_MASK (0x7 << 16) > > #define
Re: [PATCH 0/3] add support for metadata encryption to F2FS
On 2020/10/5 15:36, Satya Tangirala wrote: This patch series adds support for metadata encryption to F2FS using blk-crypto. It looks this implementation is based on hardware crypto engine, could you please add this info into f2fs.rst as well like inlinecrypt... Patch 1 replaces fscrypt_get_devices (which took an array of request_queues and filled it up) with fscrypt_get_device, which takes a index of the desired device and returns the device at that index (so the index passed to fscrypt_get_device must be between 0 and (fscrypt_get_num_devices() - 1) inclusive). This allows callers to avoid having to allocate an array to pass to fscrypt_get_devices() when they only need to iterate through each element in the array (and have no use for the array itself). Patch 2 introduces some functions to fscrypt that help filesystems perform metadata encryption. Any filesystem that wants to use metadata encryption can call fscrypt_setup_metadata_encryption() with the super_block of the filesystem, the encryption algorithm and the descriptor of the encryption key. The descriptor is looked up in the logon keyring of the current session with "fscrypt:" as the prefix of the descriptor. The patch also introduces fscrypt_metadata_crypt_bio() which an FS should call on a bio that the FS wants metadata crypted. The function will add an encryption context with the metadata encryption key set up by the call to the above mentioned fscrypt_setup_metadata_encryption(). The patch also introduces fscrypt_metadata_crypt_prepare_all_devices(). Filesystems that use multiple devices should call this function once all the underlying devices have been determined. An FS might only be able to determine all the underlying devices after some initial processing that might already require metadata en/decryption, which is why this function is separate from fscrypt_setup_metadata_encryption(). Patch 3 wires up F2FS with the functions introduced in Patch 2. F2FS will encrypt every block (that's not being encrypted by some other encryption key, e.g. a per-file key) with the metadata encryption key except the superblock (and the redundant copy of the superblock). The DUN of a block is the offset of the block from the start of the F2FS filesystem. Why not using nid as DUN, then GC could migrate encrypted node block directly via meta inode's address space like we do for encrypted data block, rather than decrypting node block to node page and then encrypting node page with DUN of new blkaddr it migrates to. Thanks, Please refer to the commit message for why the superblock was excluded from en/decryption, and other limitations. The superblock and its copy are stored in plaintext on disk. The encryption algorithm used for metadata encryption is stored within the superblock itself. Changes to the userspace tools (that are required to test out metadata encryption with F2FS) are also being sent out - I'll post a link as a reply to this mail once it's out. Satya Tangirala (3): fscrypt, f2fs: replace fscrypt_get_devices with fscrypt_get_device fscrypt: Add metadata encryption support f2fs: Add metadata encryption support Documentation/filesystems/f2fs.rst | 12 ++ fs/crypto/Kconfig | 6 + fs/crypto/Makefile | 1 + fs/crypto/fscrypt_private.h| 19 +++ fs/crypto/inline_crypt.c | 37 + fs/crypto/metadata_crypt.c | 220 + fs/f2fs/data.c | 24 ++-- fs/f2fs/f2fs.h | 2 + fs/f2fs/super.c| 83 +-- include/linux/f2fs_fs.h| 3 +- include/linux/fs.h | 3 + include/linux/fscrypt.h| 51 ++- 12 files changed, 410 insertions(+), 51 deletions(-) create mode 100644 fs/crypto/metadata_crypt.c
Re: [PATCH v1 10/10] bus: mhi: core: Mark device inactive soon after host issues a shutdown
On 9/19/2020 7:32 AM, Bhaumik Bhatt wrote:
> Clients on the host may see the device in an active state for a short
> period of time after the host detects a device error or power down.
What scenario is referred as 'device error' here?
And power down is the non-graceful power_down by controller?
> Prevent any further host activity which could lead to race conditions
> or multiple callbacks to the controller or any timeouts seen by
> clients attempting to push data as they must be notified of the host
> intent sooner rather than later. This also allows the host and device
> states to be in sync with one another and prevents unnecessary host
> operations.
>
> Signed-off-by: Bhaumik Bhatt
> ---
> drivers/bus/mhi/core/main.c | 4
> drivers/bus/mhi/core/pm.c | 31 +++
> 2 files changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 1c8e332..5ec89e9 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -400,6 +400,10 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number,
> void *priv)
>
>/* If device supports RDDM don't bother processing SYS error */
> if (mhi_cntrl->rddm_image) {
> + /* host may be performing a device power down already */
> + if (!mhi_is_active(mhi_cntrl))
> + goto exit_intvec;
> +
> if (mhi_cntrl->ee == MHI_EE_RDDM && mhi_cntrl->ee != ee) {
> /* prevent clients from queueing any more packets */
> write_lock_irq(_cntrl->pm_lock);
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index 16c04ab..4e2cb41 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -469,15 +469,10 @@ static void mhi_pm_disable_transition(struct
> mhi_controller *mhi_cntrl,
> write_lock_irq(_cntrl->pm_lock);
> prev_state = mhi_cntrl->pm_state;
> cur_state = mhi_tryset_pm_state(mhi_cntrl, transition_state);
> - if (cur_state == transition_state) {
> - mhi_cntrl->ee = MHI_EE_DISABLE_TRANSITION;
> + if (cur_state == MHI_PM_SYS_ERR_PROCESS)
> mhi_cntrl->dev_state = MHI_STATE_RESET;
> - }
> write_unlock_irq(_cntrl->pm_lock);
>
> - /* Wake up threads waiting for state transition */
> - wake_up_all(_cntrl->state_event);
> -
> if (cur_state != transition_state) {
> dev_err(dev, "Failed to transition to state: %s from: %s\n",
> to_mhi_pm_state_str(transition_state),
> @@ -486,6 +481,11 @@ static void mhi_pm_disable_transition(struct
> mhi_controller *mhi_cntrl,
> return;
> }
>
> + mhi_cntrl->ee = MHI_EE_DISABLE_TRANSITION;
> +
> + /* Wake up threads waiting for state transition */
> + wake_up_all(_cntrl->state_event);
> +
> /* Trigger MHI RESET so that the device will not access host memory */
> if (MHI_REG_ACCESS_VALID(prev_state)) {
> u32 in_reset = -1;
> @@ -1051,22 +1051,29 @@ void mhi_power_down(struct mhi_controller *mhi_cntrl,
> bool graceful)
> enum dev_st_transition next_state = DEV_ST_TRANSITION_DISABLE;
> struct device *dev = _cntrl->mhi_dev->dev;
>
> + mutex_lock(_cntrl->pm_mutex);
> + write_lock_irq(_cntrl->pm_lock);
> +
> /* If it's not a graceful shutdown, force MHI to linkdown state */
> if (!graceful) {
> - mutex_lock(_cntrl->pm_mutex);
> - write_lock_irq(_cntrl->pm_lock);
> cur_state = mhi_tryset_pm_state(mhi_cntrl,
> MHI_PM_LD_ERR_FATAL_DETECT);
> - write_unlock_irq(_cntrl->pm_lock);
> - mutex_unlock(_cntrl->pm_mutex);
> - if (cur_state != MHI_PM_LD_ERR_FATAL_DETECT)
> + if (cur_state != MHI_PM_LD_ERR_FATAL_DETECT) {
> dev_dbg(dev, "Failed to move to state: %s from: %s\n",
> to_mhi_pm_state_str(MHI_PM_LD_ERR_FATAL_DETECT),
> to_mhi_pm_state_str(mhi_cntrl->pm_state));
> - else
> + } else {
> next_state = DEV_ST_TRANSITION_FATAL;
> + wake_up_all(_cntrl->state_event);
> + }
> }
>
> + /* mark device inactive to avoid any further host processing */
> + mhi_cntrl->dev_state = MHI_STATE_RESET;
> +
> + write_unlock_irq(_cntrl->pm_lock);
> + mutex_unlock(_cntrl->pm_mutex);
> +
> mhi_queue_state_transition(mhi_cntrl, next_state);
>
> /* Wait for shutdown to complete */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] kernel: acct.c: fix some kernel-doc nits
From: Randy Dunlap
Fix kernel-doc notation to use the documented Returns: syntax
and place the function description for acct_process() on the
first line where it should be.
Signed-off-by: Randy Dunlap
Cc: Andrew Morton
Cc: Alexander Viro
---
kernel/acct.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
--- linux-next-20201009.orig/kernel/acct.c
+++ linux-next-20201009/kernel/acct.c
@@ -263,12 +263,12 @@ static DEFINE_MUTEX(acct_on_mutex);
* sys_acct - enable/disable process accounting
* @name: file name for accounting records or NULL to shutdown accounting
*
- * Returns 0 for success or negative errno values for failure.
- *
* sys_acct() is the only system call needed to implement process
* accounting. It takes the name of the file where accounting records
* should be written. If the filename is NULL, accounting will be
* shutdown.
+ *
+ * Returns: 0 for success or negative errno values for failure.
*/
SYSCALL_DEFINE1(acct, const char __user *, name)
{
@@ -586,9 +586,7 @@ static void slow_acct_process(struct pid
}
/**
- * acct_process
- *
- * handles process accounting for an exiting task
+ * acct_process - handles process accounting for an exiting task
*/
void acct_process(void)
{
Re: [PATCH v1 06/10] bus: mhi: core: Improve shutdown handling after link down detection
On 9/19/2020 7:32 AM, Bhaumik Bhatt wrote:
> If MHI were to attempt a device shutdown following an assumption
> that the device is inaccessible, the host currently moves to a state
> where device register accesses are allowed when they should not be.
> This would end up allowing accesses to the device register space when
> the link is inaccessible and can result in bus errors observed on the
> host. Improve shutdown handling to prevent these outcomes and do not
> move the MHI PM state to a register accessible state after device is
Which state are you referring to when you say 'register accessible state'?
Would it be possible to provide more details on current handling here?
> assumed to be inaccessible.
>
> Signed-off-by: Bhaumik Bhatt
> ---
> drivers/bus/mhi/core/init.c | 1 +
> drivers/bus/mhi/core/internal.h | 1 +
> drivers/bus/mhi/core/pm.c | 18 +-
> 3 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index 9ae4c19..fa33dde 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -37,6 +37,7 @@ const char * const
> dev_state_tran_str[DEV_ST_TRANSITION_MAX] = {
> [DEV_ST_TRANSITION_MISSION_MODE] = "MISSION_MODE",
> [DEV_ST_TRANSITION_SYS_ERR] = "SYS_ERR",
> [DEV_ST_TRANSITION_DISABLE] = "DISABLE",
> + [DEV_ST_TRANSITION_FATAL] = "FATAL SHUTDOWN",
> };
>
> const char * const mhi_state_str[MHI_STATE_MAX] = {
> diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
> index 7989269..f3b9e5a 100644
> --- a/drivers/bus/mhi/core/internal.h
> +++ b/drivers/bus/mhi/core/internal.h
> @@ -388,6 +388,7 @@ enum dev_st_transition {
> DEV_ST_TRANSITION_MISSION_MODE,
> DEV_ST_TRANSITION_SYS_ERR,
> DEV_ST_TRANSITION_DISABLE,
> + DEV_ST_TRANSITION_FATAL,
> DEV_ST_TRANSITION_MAX,
> };
>
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index 3462d82..bce1f62 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -37,9 +37,10 @@
> * M0 -> FW_DL_ERR
> * M0 -> M3_ENTER -> M3 -> M3_EXIT --> M0
> * L1: SYS_ERR_DETECT -> SYS_ERR_PROCESS --> POR
> - * L2: SHUTDOWN_PROCESS -> DISABLE
> + * L2: SHUTDOWN_PROCESS -> LD_ERR_FATAL_DETECT
> + * SHUTDOWN_PROCESS -> DISABLE
> * L3: LD_ERR_FATAL_DETECT <--> LD_ERR_FATAL_DETECT
> - * LD_ERR_FATAL_DETECT -> SHUTDOWN_PROCESS
> + * LD_ERR_FATAL_DETECT -> DISABLE
> */
> static struct mhi_pm_transitions const dev_state_transitions[] = {
> /* L0 States */
> @@ -72,7 +73,7 @@ static struct mhi_pm_transitions const
> dev_state_transitions[] = {
> {
> MHI_PM_M3,
> MHI_PM_M3_EXIT | MHI_PM_SYS_ERR_DETECT |
> - MHI_PM_SHUTDOWN_PROCESS | MHI_PM_LD_ERR_FATAL_DETECT
> + MHI_PM_LD_ERR_FATAL_DETECT
> },
> {
> MHI_PM_M3_EXIT,
> @@ -103,7 +104,7 @@ static struct mhi_pm_transitions const
> dev_state_transitions[] = {
> /* L3 States */
> {
> MHI_PM_LD_ERR_FATAL_DETECT,
> - MHI_PM_LD_ERR_FATAL_DETECT | MHI_PM_SHUTDOWN_PROCESS
> + MHI_PM_LD_ERR_FATAL_DETECT | MHI_PM_DISABLE
> },
> };
>
> @@ -670,6 +671,10 @@ void mhi_pm_st_worker(struct work_struct *work)
> mhi_pm_disable_transition
> (mhi_cntrl, MHI_PM_SHUTDOWN_PROCESS);
> break;
> + case DEV_ST_TRANSITION_FATAL:
> + mhi_pm_disable_transition
> + (mhi_cntrl, MHI_PM_LD_ERR_FATAL_DETECT);
> + break;
> default:
> break;
> }
> @@ -1039,6 +1044,7 @@ EXPORT_SYMBOL_GPL(mhi_async_power_up);
> void mhi_power_down(struct mhi_controller *mhi_cntrl, bool graceful)
> {
> enum mhi_pm_state cur_state;
> + enum dev_st_transition next_state = DEV_ST_TRANSITION_DISABLE;
> struct device *dev = _cntrl->mhi_dev->dev;
>
> /* If it's not a graceful shutdown, force MHI to linkdown state */
> @@ -1053,9 +1059,11 @@ void mhi_power_down(struct mhi_controller *mhi_cntrl,
> bool graceful)
> dev_dbg(dev, "Failed to move to state: %s from: %s\n",
> to_mhi_pm_state_str(MHI_PM_LD_ERR_FATAL_DETECT),
> to_mhi_pm_state_str(mhi_cntrl->pm_state));
> + else
> + next_state = DEV_ST_TRANSITION_FATAL;
> }
>
> - mhi_queue_state_transition(mhi_cntrl, DEV_ST_TRANSITION_DISABLE);
> + mhi_queue_state_transition(mhi_cntrl, next_state);
>
> /* Wait for shutdown to complete */
> flush_work(_cntrl->st_worker);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2 3/4 RESEND] MIPS: Loongson64: Add /proc/boardinfo
Add /proc/boardinfo to get mainboard and BIOS info easily on the Loongson
platform, this is useful to point out the current used mainboard type and
BIOS version when there exists problems related with hardware or firmware.
E.g. with this patch:
[loongson@linux ~]$ cat /proc/boardinfo
Board Info
Manufacturer: LEMOTE
Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc
Family : LOONGSON3
BIOS Info
Vendor : Kunlun
Version : Kunlun-A1901-V4.1.3-20200414093938
ROM Size: 4 KB
Release Date: 2020-04-14
Signed-off-by: Tiezhu Yang
---
v2: no changes
arch/mips/include/asm/mach-loongson64/boot_param.h | 4 +++
arch/mips/loongson64/Makefile | 2 +-
arch/mips/loongson64/boardinfo.c | 40 ++
arch/mips/loongson64/env.c | 10 ++
4 files changed, 55 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/loongson64/boardinfo.c
diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h
b/arch/mips/include/asm/mach-loongson64/boot_param.h
index afc92b7..4592841 100644
--- a/arch/mips/include/asm/mach-loongson64/boot_param.h
+++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
@@ -228,6 +228,10 @@ struct loongson_system_configuration {
extern struct efi_memory_map_loongson *loongson_memmap;
extern struct loongson_system_configuration loongson_sysconf;
+extern struct board_devices *eboard;
+extern struct interface_info *einter;
+extern struct loongson_special_attribute *especial;
+
extern u32 node_id_offset;
extern void ls7a_early_config(void);
extern void rs780e_early_config(void);
diff --git a/arch/mips/loongson64/Makefile b/arch/mips/loongson64/Makefile
index 39c06f5..bc77b5a 100644
--- a/arch/mips/loongson64/Makefile
+++ b/arch/mips/loongson64/Makefile
@@ -3,7 +3,7 @@
# Makefile for Loongson-3 family machines
#
obj-$(CONFIG_MACH_LOONGSON64) += cop2-ex.o platform.o dma.o \
- setup.o init.o env.o time.o reset.o \
+ setup.o init.o env.o time.o reset.o boardinfo.o\
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_NUMA) += numa.o
diff --git a/arch/mips/loongson64/boardinfo.c b/arch/mips/loongson64/boardinfo.c
new file mode 100644
index 000..2e8086b
--- /dev/null
+++ b/arch/mips/loongson64/boardinfo.c
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int loongson_boardinfo_proc_show(struct seq_file *m, void *v)
+{
+ char board_manufacturer[64] = {0};
+ char *tmp_board_manufacturer = board_manufacturer;
+ char bios_vendor[64] = {0};
+ char *tmp_bios_vendor = bios_vendor;
+
+ strcpy(board_manufacturer, eboard->name);
+ strcpy(bios_vendor, einter->description);
+
+ seq_puts(m, "Board Info\n");
+ seq_printf(m, "Manufacturer\t\t: %s\n", strsep(_board_manufacturer,
"-"));
+ seq_printf(m, "Board Name\t\t: %s\n", eboard->name);
+ seq_puts(m, "Family\t\t\t: LOONGSON3\n");
+ seq_puts(m, "\n");
+
+ seq_puts(m, "BIOS Info\n");
+ seq_printf(m, "Vendor\t\t\t: %s\n", strsep(_bios_vendor, "-"));
+ seq_printf(m, "Version\t\t\t: %s\n", einter->description);
+ seq_printf(m, "ROM Size\t\t: %d KB\n", einter->size);
+ seq_printf(m, "Release Date\t\t: %s\n", especial->special_name);
+
+ return 0;
+}
+
+static int __init proc_boardinfo_init(void)
+{
+ proc_create_single("boardinfo", 0, NULL, loongson_boardinfo_proc_show);
+ return 0;
+}
+
+module_init(proc_boardinfo_init);
diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
index 134cb8e..51a5d05 100644
--- a/arch/mips/loongson64/env.c
+++ b/arch/mips/loongson64/env.c
@@ -28,6 +28,10 @@ EXPORT_SYMBOL(cpu_clock_freq);
struct efi_memory_map_loongson *loongson_memmap;
struct loongson_system_configuration loongson_sysconf;
+struct board_devices *eboard;
+struct interface_info *einter;
+struct loongson_special_attribute *especial;
+
u64 loongson_chipcfg[MAX_PACKAGES] = {0xbfc00180};
u64 loongson_chiptemp[MAX_PACKAGES];
u64 loongson_freqctrl[MAX_PACKAGES];
@@ -57,6 +61,12 @@ void __init prom_init_env(void)
((u64)loongson_p + loongson_p->system_offset);
ecpu = (struct efi_cpuinfo_loongson *)
((u64)loongson_p + loongson_p->cpu_offset);
+ eboard = (struct board_devices *)
+ ((u64)loongson_p + loongson_p->boarddev_table_offset);
+ einter = (struct interface_info *)
+ ((u64)loongson_p + loongson_p->interface_offset);
+ especial = (struct loongson_special_attribute *)
+ ((u64)loongson_p + loongson_p->special_offset);
eirq_source = (struct irq_source_routing_table *)
((u64)loongson_p + loongson_p->irq_offset);
loongson_memmap = (struct efi_memory_map_loongson *)
--
2.1.0
[PATCH v2 1/4 RESEND] MIPS: Loongson64: Select SMP in Kconfig to avoid build error
In the current code, CONFIG_SMP can be set as N by user on the Loongson platform, then there exists the following build error under !CONFIG_SMP: CC arch/mips/kernel/asm-offsets.s In file included from ./include/linux/gfp.h:9:0, from ./include/linux/xarray.h:14, from ./include/linux/radix-tree.h:18, from ./include/linux/fs.h:15, from ./include/linux/compat.h:17, from arch/mips/kernel/asm-offsets.c:12: ./include/linux/topology.h: In function 'numa_node_id': ./include/linux/topology.h:119:2: error: implicit declaration of function 'cpu_logical_map' [-Werror=implicit-function-declaration] return cpu_to_node(raw_smp_processor_id()); ^ cc1: some warnings being treated as errors scripts/Makefile.build:117: recipe for target 'arch/mips/kernel/asm-offsets.s' failed make[1]: *** [arch/mips/kernel/asm-offsets.s] Error 1 Select SMP in Kconfig to avoid the above build error and then remove CONFIG_SMP=y in loongson3_defconfig. Signed-off-by: Tiezhu Yang --- v2: no changes arch/mips/Kconfig | 1 + arch/mips/configs/loongson3_defconfig | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index b557fa5..75f26d1 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -488,6 +488,7 @@ config MACH_LOONGSON64 select SYS_SUPPORTS_ZBOOT select ZONE_DMA32 select NUMA + select SMP select COMMON_CLK select USE_OF select BUILTIN_DTB diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig index a5005c8..38a817e 100644 --- a/arch/mips/configs/loongson3_defconfig +++ b/arch/mips/configs/loongson3_defconfig @@ -30,7 +30,6 @@ CONFIG_EMBEDDED=y CONFIG_PERF_EVENTS=y CONFIG_MACH_LOONGSON64=y CONFIG_CPU_HAS_MSA=y -CONFIG_SMP=y CONFIG_NR_CPUS=16 CONFIG_HZ_256=y CONFIG_KEXEC=y -- 2.1.0
[PATCH v2 0/4 RESEND] Avoid build error, clean up numa.c and add /proc/boardinfo
[RESEND due to the following reason: Can not connect to recipient's server because of unstable network or firewall filter. rcpt handle timeout,last handle info: Host vger.kernel.org(23.128.96.18) command RCPT TO respond timeout or disconnected] v2: add patch #4 suggested by Jiaxun Tiezhu Yang (4): MIPS: Loongson64: Select SMP in Kconfig to avoid build error MIPS: Loongson64: Clean up numa.c MIPS: Loongson64: Add /proc/boardinfo docs: fs: proc.rst: Add boardinfo description for Loongson64 Documentation/filesystems/proc.rst | 1 + arch/mips/Kconfig | 1 + arch/mips/configs/loongson3_defconfig | 1 - arch/mips/include/asm/mach-loongson64/boot_param.h | 4 +++ arch/mips/include/asm/mach-loongson64/mmzone.h | 6 +--- arch/mips/loongson64/Makefile | 2 +- arch/mips/loongson64/boardinfo.c | 40 ++ arch/mips/loongson64/env.c | 10 ++ arch/mips/loongson64/numa.c| 29 ++-- 9 files changed, 61 insertions(+), 33 deletions(-) create mode 100644 arch/mips/loongson64/boardinfo.c -- 2.1.0
[PATCH v2 4/4 RESEND] docs: fs: proc.rst: Add boardinfo description for Loongson64
Add a description for /proc/boardinfo on the Loongson platform. Signed-off-by: Tiezhu Yang --- v2: new added patch Documentation/filesystems/proc.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 533c79e..3c4cb65 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -664,6 +664,7 @@ files are there, and which are missing. File Content === apm Advanced power management info + boardinfoMainboard and BIOS info for Loongson64 buddyinfoKernel memory allocator information (see text) (2.5) bus Directory containing bus specific information cmdline Kernel command line -- 2.1.0
[PATCH v2 2/4 RESEND] MIPS: Loongson64: Clean up numa.c
(1) Replace nid_to_addroffset() with nid_to_addrbase() and then remove the
related useless code.
(2) Since end_pfn = start_pfn + node_psize, use "node_psize" instead of
"end_pfn - start_pfn" to avoid the redundant calculation.
(3) After commit 6fbde6b492df ("MIPS: Loongson64: Move files to the
top-level directory"), CONFIG_ZONE_DMA32 is always set for Loongson64
due to MACH_LOONGSON64 selects ZONE_DMA32, so no need to use ifdef any
more, just remove it.
Signed-off-by: Tiezhu Yang
Reviewed-by: Jiaxun Yang
---
v2: no changes, just add Reviewed-by tag
arch/mips/include/asm/mach-loongson64/mmzone.h | 6 +-
arch/mips/loongson64/numa.c| 29 +++---
2 files changed, 4 insertions(+), 31 deletions(-)
diff --git a/arch/mips/include/asm/mach-loongson64/mmzone.h
b/arch/mips/include/asm/mach-loongson64/mmzone.h
index 3a25dbd..c3f0f7a 100644
--- a/arch/mips/include/asm/mach-loongson64/mmzone.h
+++ b/arch/mips/include/asm/mach-loongson64/mmzone.h
@@ -11,13 +11,9 @@
#include
#define NODE_ADDRSPACE_SHIFT 44
-#define NODE0_ADDRSPACE_OFFSET 0xUL
-#define NODE1_ADDRSPACE_OFFSET 0x1000UL
-#define NODE2_ADDRSPACE_OFFSET 0x2000UL
-#define NODE3_ADDRSPACE_OFFSET 0x3000UL
#define pa_to_nid(addr) (((addr) & 0xf000) >> NODE_ADDRSPACE_SHIFT)
-#define nid_to_addrbase(nid) ((nid) << NODE_ADDRSPACE_SHIFT)
+#define nid_to_addrbase(nid) ((unsigned long)(nid) << NODE_ADDRSPACE_SHIFT)
extern struct pglist_data *__node_data[];
diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
index ea8bb1b..cf9459f 100644
--- a/arch/mips/loongson64/numa.c
+++ b/arch/mips/loongson64/numa.c
@@ -98,27 +98,6 @@ static void __init init_topology_matrix(void)
}
}
-static unsigned long nid_to_addroffset(unsigned int nid)
-{
- unsigned long result;
- switch (nid) {
- case 0:
- default:
- result = NODE0_ADDRSPACE_OFFSET;
- break;
- case 1:
- result = NODE1_ADDRSPACE_OFFSET;
- break;
- case 2:
- result = NODE2_ADDRSPACE_OFFSET;
- break;
- case 3:
- result = NODE3_ADDRSPACE_OFFSET;
- break;
- }
- return result;
-}
-
static void __init szmem(unsigned int node)
{
u32 i, mem_type;
@@ -146,7 +125,7 @@ static void __init szmem(unsigned int node)
pr_info(" start_pfn:0x%llx, end_pfn:0x%llx,
num_physpages:0x%lx\n",
start_pfn, end_pfn, num_physpages);
memblock_add_node(PFN_PHYS(start_pfn),
- PFN_PHYS(end_pfn - start_pfn), node);
+ PFN_PHYS(node_psize), node);
break;
case SYSTEM_RAM_HIGH:
start_pfn = ((node_id << 44) + mem_start) >> PAGE_SHIFT;
@@ -158,7 +137,7 @@ static void __init szmem(unsigned int node)
pr_info(" start_pfn:0x%llx, end_pfn:0x%llx,
num_physpages:0x%lx\n",
start_pfn, end_pfn, num_physpages);
memblock_add_node(PFN_PHYS(start_pfn),
- PFN_PHYS(end_pfn - start_pfn), node);
+ PFN_PHYS(node_psize), node);
break;
case SYSTEM_RAM_RESERVED:
pr_info("Node%d: mem_type:%d, mem_start:0x%llx,
mem_size:0x%llx MB\n",
@@ -175,7 +154,7 @@ static void __init node_mem_init(unsigned int node)
unsigned long node_addrspace_offset;
unsigned long start_pfn, end_pfn;
- node_addrspace_offset = nid_to_addroffset(node);
+ node_addrspace_offset = nid_to_addrbase(node);
pr_info("Node%d's addrspace_offset is 0x%lx\n",
node, node_addrspace_offset);
@@ -242,9 +221,7 @@ void __init paging_init(void)
unsigned long zones_size[MAX_NR_ZONES] = {0, };
pagetable_init();
-#ifdef CONFIG_ZONE_DMA32
zones_size[ZONE_DMA32] = MAX_DMA32_PFN;
-#endif
zones_size[ZONE_NORMAL] = max_low_pfn;
free_area_init(zones_size);
}
--
2.1.0
Re: [PATCH v1 05/10] bus: mhi: core: Disable IRQs when powering down
Hi
On 9/19/2020 7:32 AM, Bhaumik Bhatt wrote:
> While powering down, the device may or may not acknowledge the MHI
> RESET issued by host for graceful shutdown scenario which can lead
> to a rogue device sending an interrupt after the clean-up has been
> done. This can result in a tasklet being scheduled after it has
> been killed and access already freed memory causing a NULL pointer
> exception. Avoid this corner case by disabling the interrupts as a
> part of host clean up.
>
> Signed-off-by: Bhaumik Bhatt
> ---
> drivers/bus/mhi/core/pm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index 1862960..3462d82 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -517,6 +517,7 @@ static void mhi_pm_disable_transition(struct
> mhi_controller *mhi_cntrl,
> for (i = 0; i < mhi_cntrl->total_ev_rings; i++, mhi_event++) {
> if (mhi_event->offload_ev)
> continue;
> + disable_irq(mhi_cntrl->irq[mhi_event->irq]);
> tasklet_kill(_event->task);
> }
>
What about sys_err handling? IRQ may be left disabled?
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] usb: host: fsl-mph-dr-of: check return of dma_set_mask()
On 20-10-10 14:03:08, Ran Wang wrote:
> fsl_usb2_device_register() should stop init if dma_set_mask() return
> error.
>
> Fixes: cae058610465 ("drivers/usb/host: fsl: Set DMA_MASK of usb platform
> device")
> Signed-off-by: Ran Wang
> ---
> drivers/usb/host/fsl-mph-dr-of.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/host/fsl-mph-dr-of.c
> b/drivers/usb/host/fsl-mph-dr-of.c
> index ae8f60f..44a7e58 100644
> --- a/drivers/usb/host/fsl-mph-dr-of.c
> +++ b/drivers/usb/host/fsl-mph-dr-of.c
> @@ -94,10 +94,13 @@ static struct platform_device *fsl_usb2_device_register(
>
> pdev->dev.coherent_dma_mask = ofdev->dev.coherent_dma_mask;
>
> - if (!pdev->dev.dma_mask)
> + if (!pdev->dev.dma_mask) {
> pdev->dev.dma_mask = >dev.coherent_dma_mask;
> - else
> - dma_set_mask(>dev, DMA_BIT_MASK(32));
> + } else {
> + retval = dma_set_mask(>dev, DMA_BIT_MASK(32));
> + if (retval)
> + goto error;
> + }
>
> retval = platform_device_add_data(pdev, pdata, sizeof(*pdata));
> if (retval)
> --
> 2.7.4
>
Reviewed-by: Peter Chen
One more place need to fix, if platform_device_alloc returns NULL,
it should not call platform_device_put to release platform
device memory.
pdev = platform_device_alloc(name, id);
if (!pdev) {
retval = -ENOMEM;
goto error;
}
...
error:
platform_device_put(pdev);
return ERR_PTR(retval);
--
Thanks,
Peter Chen
Re: [PATCH 3/3] MIPS: Loongson64: Add /proc/boardinfo
On 10/10/2020 04:01 PM, Jiaxun Yang wrote: 在 2020/10/9 下午6:57, Tiezhu Yang 写道: Add /proc/boardinfo to get mainboard and BIOS info easily on the Loongson platform, this is useful to point out the current used mainboard type and BIOS version when there exists problems related with hardware or firmware. Hi Tiezhu, You're touching Kernel userspace API and I believe it should be documented. Also linux-api list should be informed. [RESEND due to the following reason: Can not connect to recipient's server because of unstable network or firewall filter. rcpt handle timeout,last handle info: Host vger.kernel.org(23.128.96.18) command RCPT TO respond timeout or disconnected] Hi Jiaxun, Thanks for your suggestion. I will do it as soon as possible and then send v2. Also I'd like to know if it's really useful for mainline kernel. For user who wants to check board information, dmidecode is already useful enough. There is no SMBIOS and dmidecode can see nothing on some machines, like this: [root@linux loongson]# dmidecode # dmidecode 2.12 # No SMBIOS nor DMI entry point found, sorry. So I think it is useful. Thanks, Tiezhu Yang Thanks. - Jiaxun E.g. with this patch: [loongson@linux ~]$ cat /proc/boardinfo Board Info Manufacturer: LEMOTE Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc Family : LOONGSON3 BIOS Info Vendor : Kunlun Version : Kunlun-A1901-V4.1.3-20200414093938 ROM Size: 4 KB Release Date: 2020-04-14 Signed-off-by: Tiezhu Yang ---
Re: [PATCH] power: supply: ltc2941: Fix ptr to enum cast
Hi, On Sat, Oct 10, 2020 at 09:55:26AM +0300, Iskren Chernev wrote: > clang complains about casting pointers to smaller enum types. > > Signed-off-by: Iskren Chernev > --- Thanks, queued. -- Sebastian > drivers/power/supply/ltc2941-battery-gauge.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/power/supply/ltc2941-battery-gauge.c > b/drivers/power/supply/ltc2941-battery-gauge.c > index 30a9014b2f95e..10cd617516ec2 100644 > --- a/drivers/power/supply/ltc2941-battery-gauge.c > +++ b/drivers/power/supply/ltc2941-battery-gauge.c > @@ -473,7 +473,8 @@ static int ltc294x_i2c_probe(struct i2c_client *client, > > np = of_node_get(client->dev.of_node); > > - info->id = (enum ltc294x_id)of_device_get_match_data(>dev); > + info->id = (enum ltc294x_id) (uintptr_t) of_device_get_match_data( > + >dev); > info->supply_desc.name = np->name; > > /* r_sense can be negative, when sense+ is connected to the battery > > base-commit: 411643e949f4e616f758e2c6079f333b0e704c49 > -- > 2.28.0 > signature.asc Description: PGP signature
Re: [PULL REQUEST] i2c for v5.9
The pull request you sent on Sat, 10 Oct 2020 20:28:52 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/da690031a5d6d50a361e3f19f3eeabd086a6f20d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH 14/18] dt-bindings: usb: dwc3: Add Frame Length Adj restrictions
In accordance with the IP core databook the snps,quirk-frame-length-adjustment property can be set within [0, 0x3F]. Let's make sure the DT schema applies a correct restriction on the property. Signed-off-by: Serge Semin --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 36d4b8060d7c..f1e6c3dab1ff 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -226,6 +226,8 @@ properties: length adjustment when the fladj_30mhz_sdbnd signal is invalid or incorrect. $ref: /schemas/types.yaml#/definitions/uint32 +minimum: 0 +maximum: 0x3f snps,rx-thr-num-pkt-prd: description: | -- 2.27.0
[PATCH 10/18] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
DWC USB3 DT node is supposed to be compliant with the Generic xHCI Controller schema, but with additional vendor-specific properties, the controller-specific reference clocks and PHYs. So let's convert the currently available legacy text-based DWC USB3 bindings to the DT schema and make sure the DWC USB3 nodes are also validated against the usb-xhci.yaml schema. Note we have to discard the nodename restriction of being prefixed with "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes are supposed to be named as "^usb(@.*)". Signed-off-by: Serge Semin --- Alas applying the usb-hcd.yaml schema on the DWC USB3 nodes will cause dtbs_check failures since a lot of "snps,dwc3"-compatible DT nodes are named with prefixes like "^dwc3@", "^usb[0-9]@" and even "^dwusb@", while usb-hcd.yaml permits the "^usb@" prefix only. As I see it the better but more painful solution would be to fix the corresponding DTS files (it's some of the Qualcomm, HiSilicon, Exynos, Allwinner, Omap, Stih, APM and Freescale DTS'es) so the DWC USB3 DT nodes would comply with the generic USB HCD node naming schema. Alternatively we could either extend the naming space in the usb-hcd.yaml or extract the generic properties to a dedicated DT schema file. What do you think? --- .../devicetree/bindings/usb/dwc3.txt | 125 .../devicetree/bindings/usb/snps,dwc3.yaml| 295 ++ 2 files changed, 295 insertions(+), 125 deletions(-) delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt deleted file mode 100644 index d03edf9d3935.. --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ /dev/null @@ -1,125 +0,0 @@ -synopsys DWC3 CORE - -DWC3- USB3 CONTROLLER. Complies to the generic USB binding properties - as described in 'usb/generic.txt' - -Required properties: - - compatible: must be "snps,dwc3" - - reg : Address and length of the register set for the device - - interrupts: Interrupts used by the dwc3 controller. - - clock-names: list of clock names. Ideally should be "ref", -"bus_early", "suspend" but may be less or more. - - clocks: list of phandle and clock specifier pairs corresponding to - entries in the clock-names property. - -Exception for clocks: - clocks are optional if the parent node (i.e. glue-layer) is compatible to - one of the following: -"cavium,octeon-7130-usb-uctl" -"qcom,dwc3" -"samsung,exynos5250-dwusb3" -"samsung,exynos5433-dwusb3" -"samsung,exynos7-dwusb3" -"sprd,sc9860-dwc3" -"st,stih407-dwc3" -"ti,am437x-dwc3" -"ti,dwc3" -"ti,keystone-dwc3" -"rockchip,rk3399-dwc3" -"xlnx,zynqmp-dwc3" - -Optional properties: - - usb-phy : array of phandle for the PHY device. The first element - in the array is expected to be a handle to the USB2/HS PHY and - the second element is expected to be a handle to the USB3/SS PHY - - phys: from the *Generic PHY* bindings - - phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy" - or "usb3-phy". - - resets: set of phandle and reset specifier pairs - - snps,usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM - - snps,usb3_lpm_capable: determines if platform is USB3 LPM capable - - snps,dis-start-transfer-quirk: when set, disable isoc START TRANSFER command - failure SW work-around for DWC_usb31 version 1.70a-ea06 - and prior. - - snps,disable_scramble_quirk: true when SW should disable data scrambling. - Only really useful for FPGA builds. - - snps,has-lpm-erratum: true when DWC3 was configured with LPM Erratum enabled - - snps,lpm-nyet-threshold: LPM NYET threshold - - snps,u2exit_lfps_quirk: set if we want to enable u2exit lfps quirk - - snps,u2ss_inp3_quirk: set if we enable P3 OK for U2/SS Inactive quirk - - snps,req_p1p2p3_quirk: when set, the core will always request for - P1/P2/P3 transition sequence. - - snps,del_p1p2p3_quirk: when set core will delay P1/P2/P3 until a certain - amount of 8B10B errors occur. - - snps,del_phy_power_chg_quirk: when set core will delay PHY power change - from P0 to P1/P2/P3. - - snps,lfps_filter_quirk: when set core will filter LFPS reception. - - snps,rx_detect_poll_quirk: when set core will disable a 400us delay to start - Polling LFPS after RX.Detect. - - snps,tx_de_emphasis_quirk: when set core will set Tx de-emphasis value. - - snps,tx_de_emphasis: the value driven to the PHY is controlled by the - LTSSM during USB3 Compliance mode. - - snps,dis_u3_susphy_quirk: when set core will disable USB3 suspend phy. - - snps,dis_u2_susphy_quirk: when set core will disable USB2 suspend phy. - - snps,dis_enblslpm_quirk:
Re: SD_LOAD_BALANCE
Hello, Previously, I was wondering about why starting in Linux v5.8 my unblocking threads were moving to different sockets more frequently than in previous releases. Now, I think that I have found the reason. The first issue is the change from runnable load average to load average in computing wake_affine_weight: --- commit 11f10e5420f6cecac7d4823638bff040c257aba9 Author: Vincent Guittot Date: Fri Oct 18 15:26:36 2019 +0200 sched/fair: Use load instead of runnable load in wakeup path Runnable load was originally introduced to take into account the case where blocked load biases the wake up path which may end to select an overloaded CPU with a large number of runnable tasks instead of an underutilized CPU with a huge blocked load. Tha wake up path now starts looking for idle CPUs before comparing runnable load and it's worth aligning the wake up path with the load_balance() logic. --- The unfortunate case is illustrated by the following trace (*** on the important lines): trace-cmd-8006 [118] 451.444751: sched_migrate_task: comm=containerd pid=2481 prio=120 orig_cpu=114 dest_cpu=118 ua.B.x-8007 [105] 451.444752: sched_switch: ua.B.x:8007 [120] S ==> swapper/105:0 [120] trace-cmd-8006 [118] 451.444769: sched_switch: ua.B.x:8006 [120] S ==> containerd:2481 [120] *** containerd-2481 [118] 451.444859: sched_switch: containerd:2481 [120] S ==> swapper/118:0 [120] *** ua.B.x-8148 [016] 451.444910: sched_switch: ua.B.x:8148 [120] S ==> swapper/16:0 [120] ua.B.x-8154 [127] 451.445186: sched_switch: ua.B.x:8154 [120] S ==> swapper/127:0 [120] ua.B.x-8145 [047] 451.445199: sched_switch: ua.B.x:8145 [120] S ==> swapper/47:0 [120] ua.B.x-8138 [147] 451.445200: sched_switch: ua.B.x:8138 [120] S ==> swapper/147:0 [120] ua.B.x-8152 [032] 451.445210: sched_switch: ua.B.x:8152 [120] S ==> swapper/32:0 [120] ua.B.x-8144 [067] 451.445215: sched_switch: ua.B.x:8144 [120] S ==> swapper/67:0 [120] ua.B.x-8137 [000] 451.445219: sched_switch: ua.B.x:8137 [120] S ==> swapper/0:0 [120] ua.B.x-8140 [075] 451.445225: sched_switch: ua.B.x:8140 [120] S ==> swapper/75:0 [120] ua.B.x-8155 [084] 451.445229: sched_switch: ua.B.x:8155 [120] S ==> swapper/84:0 [120] ua.B.x-8161 [155] 451.445232: sched_switch: ua.B.x:8161 [120] S ==> swapper/155:0 [120] ua.B.x-8156 [095] 451.445261: sched_switch: ua.B.x:8156 [120] S ==> swapper/95:0 [120] ua.B.x-8153 [134] 451.445268: sched_switch: ua.B.x:8153 [120] S ==> swapper/134:0 [120] ua.B.x-8151 [154] 451.445268: sched_switch: ua.B.x:8151 [120] S ==> swapper/154:0 [120] ua.B.x-8141 [107] 451.445273: sched_switch: ua.B.x:8141 [120] S ==> swapper/107:0 [120] ua.B.x-8146 [131] 451.445275: sched_switch: ua.B.x:8146 [120] S ==> swapper/131:0 [120] ua.B.x-8160 [035] 451.445286: sched_switch: ua.B.x:8160 [120] S ==> swapper/35:0 [120] ua.B.x-8136 [088] 451.445286: sched_switch: ua.B.x:8136 [120] S ==> swapper/88:0 [120] ua.B.x-8159 [056] 451.445290: sched_switch: ua.B.x:8159 [120] S ==> swapper/56:0 [120] ua.B.x-8147 [036] 451.445294: sched_switch: ua.B.x:8147 [120] S ==> swapper/36:0 [120] ua.B.x-8150 [150] 451.445298: sched_switch: ua.B.x:8150 [120] S ==> swapper/150:0 [120] ua.B.x-8142 [159] 451.445300: sched_switch: ua.B.x:8142 [120] S ==> swapper/159:0 [120] ua.B.x-8157 [058] 451.445309: sched_switch: ua.B.x:8157 [120] S ==> swapper/58:0 [120] ua.B.x-8149 [123] 451.445311: sched_switch: ua.B.x:8149 [120] S ==> swapper/123:0 [120] ua.B.x-8162 [156] 451.445313: sched_switch: ua.B.x:8162 [120] S ==> swapper/156:0 [120] ua.B.x-8164 [019] 451.445317: sched_switch: ua.B.x:8164 [120] S ==> swapper/19:0 [120] ua.B.x-8139 [068] 451.445319: sched_switch: ua.B.x:8139 [120] S ==> swapper/68:0 [120] ua.B.x-8143 [126] 451.445335: sched_switch: ua.B.x:8143 [120] S ==> swapper/126:0 [120] ua.B.x-8163 [062] 451.445361: sched_switch: ua.B.x:8163 [120] S ==> swapper/62:0 [120] ua.B.x-8158 [129] 451.445371: sched_switch: ua.B.x:8158 [120] S ==> swapper/129:0 [120] ua.B.x-8040 [043] 451.445413: sched_wake_idle_without_ipi: cpu=0 ua.B.x-8165 [098] 451.445451: sched_switch: ua.B.x:8165 [120] S ==> swapper/98:0 [120] ua.B.x-8069 [009] 451.445622: sched_waking: comm=ua.B.x pid=8007 prio=120 target_cpu=105 ua.B.x-8069
[PATCH 06/18] dt-bindings: usb: usb-hcd: Add generic "usb-phy" property
Even though the Generic PHY framework is the more preferable way of setting the USB PHY up, there are still many dts-files and DT bindings which rely on having the legacy "usb-phy" specified to attach particular USB PHYs to USB cores. Let's have the "usb-phy" property described in the generic USB HCD binding file so it would be validated against the nodes in which it's specified. Mark the property as deprecated to discourage the developers from using it. Signed-off-by: Serge Semin --- Documentation/devicetree/bindings/usb/usb-hcd.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml index c898166a8c6c..95b1dbf2a4f2 100644 --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml @@ -22,6 +22,13 @@ properties: description: Name specifier for the USB PHY + usb-phy: +$ref: /schemas/types.yaml#/definitions/phandle-array +description: | + List of all the USB PHYs on this HCD to be accepted by the legacy USB + Physical Layer subsystem. +deprecated: true + maximum-speed: description: | Tells USB controllers we want to work up to a certain speed. In case this -- 2.27.0
Re: [PATCH v6 10/10] vfio/fsl-mc: Add support for device reset
Hi Diana,
On 10/5/20 7:36 PM, Diana Craciun wrote:
> Currently only resetting the DPRC container is supported which
> will reset all the objects inside it. Resetting individual
> objects is possible from the userspace by issueing commands
> towards MC firmware.
>
> Signed-off-by: Diana Craciun
Reviewed-by: Eric Auger
Eric
> ---
> drivers/vfio/fsl-mc/vfio_fsl_mc.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> index d95568cd8021..d009f873578c 100644
> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> @@ -217,6 +217,10 @@ static long vfio_fsl_mc_ioctl(void *device_data,
> unsigned int cmd,
> return -EINVAL;
>
> info.flags = VFIO_DEVICE_FLAGS_FSL_MC;
> +
> + if (is_fsl_mc_bus_dprc(mc_dev))
> + info.flags |= VFIO_DEVICE_FLAGS_RESET;
> +
> info.num_regions = mc_dev->obj_desc.region_count;
> info.num_irqs = mc_dev->obj_desc.irq_count;
>
> @@ -299,7 +303,19 @@ static long vfio_fsl_mc_ioctl(void *device_data,
> unsigned int cmd,
> }
> case VFIO_DEVICE_RESET:
> {
> - return -ENOTTY;
> + int ret;
> + struct fsl_mc_device *mc_dev = vdev->mc_dev;
> +
> + /* reset is supported only for the DPRC */
> + if (!is_fsl_mc_bus_dprc(mc_dev))
> + return -ENOTTY;
> +
> + ret = dprc_reset_container(mc_dev->mc_io, 0,
> +mc_dev->mc_handle,
> +mc_dev->obj_desc.id,
> +DPRC_RESET_OPTION_NON_RECURSIVE);
> + return ret;
> +
> }
> default:
> return -ENOTTY;
>
Re: [PATCH v6 16/17] dt-bindings: arm: hisilicon: convert hisilicon,hi3798cv200-perictrl bindings to json-schema
On 2020/10/1 14:35, Krzysztof Kozlowski wrote: > On Wed, Sep 30, 2020 at 11:17:11AM +0800, Zhen Lei wrote: >> Convert the Hisilicon Hi3798CV200 Peripheral Controller binding to DT >> schema format using json-schema. >> >> Signed-off-by: Zhen Lei >> --- >> .../hisilicon/controller/hi3798cv200-perictrl.yaml | 64 >> ++ >> .../controller/hisilicon,hi3798cv200-perictrl.txt | 21 --- >> 2 files changed, 64 insertions(+), 21 deletions(-) >> create mode 100644 >> Documentation/devicetree/bindings/arm/hisilicon/controller/hi3798cv200-perictrl.yaml >> delete mode 100644 >> Documentation/devicetree/bindings/arm/hisilicon/controller/hisilicon,hi3798cv200-perictrl.txt >> >> diff --git >> a/Documentation/devicetree/bindings/arm/hisilicon/controller/hi3798cv200-perictrl.yaml >> >> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hi3798cv200-perictrl.yaml >> new file mode 100644 >> index 000..cba1937aad9a8d3 >> --- /dev/null >> +++ >> b/Documentation/devicetree/bindings/arm/hisilicon/controller/hi3798cv200-perictrl.yaml >> @@ -0,0 +1,64 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: >> http://devicetree.org/schemas/arm/hisilicon/controller/hi3798cv200-perictrl.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Hisilicon Hi3798CV200 Peripheral Controller >> + >> +maintainers: >> + - Wei Xu >> + >> +description: | >> + The Hi3798CV200 Peripheral Controller controls peripherals, queries >> + their status, and configures some functions of peripherals. >> + >> +properties: >> + compatible: >> +items: >> + - const: hisilicon,hi3798cv200-perictrl >> + - const: syscon >> + - const: simple-mfd >> + >> + reg: >> +maxItems: 1 >> + >> + "#address-cells": >> +const: 1 >> + >> + "#size-cells": >> +const: 1 >> + >> + ranges: true >> + >> +required: >> + - compatible >> + - reg >> + - "#address-cells" >> + - "#size-cells" >> + - ranges >> + >> +additionalProperties: >> + type: object > > You need to describe all additional properties or objects. OK, I will do it in v5.11 > > Best regards, > Krzysztof > > . >
Re: [PATCH net-next] drivers/net/wan/hdlc_fr: Move the skb_headroom check out of fr_hard_header
On Wed, 7 Oct 2020 11:32:03 -0700 Xie He wrote: > Move the skb_headroom check out of fr_hard_header and into pvc_xmit. > This has two benefits: > > 1. Originally we only do this check for skbs sent by users on Ethernet- > emulating PVC devices. After the change we do this check for skbs sent on > normal PVC devices, too. > (Also add a comment to make it clear that this is only a protection > against upper layers that don't take dev->needed_headroom into account. > Such upper layers should be rare and I believe they should be fixed.) > > 2. After the change we can simplify the parameter list of fr_hard_header. > We no longer need to use a pointer to pointers (skb_p) because we no > longer need to replace the skb inside fr_hard_header. > > Cc: Krzysztof Halasa > Signed-off-by: Xie He Applied, thanks!
Re: [PATCH] checkpatch: Check for .byte-spelled insn opcodes documentation on x86
On Sat, 2020-10-10 at 18:11 +0200, Borislav Petkov wrote:
> On Sat, Oct 10, 2020 at 08:27:20AM -0700, Joe Perches wrote:
> > Then this could use:
> >
> > /"\s*\.byte\s+(?:0x[0-9a-fA-F]{1,2}\s*,\s*){2,4}/
>
> Yes, this is getting close.
>
> I've tweaked it a bit to:
>
> '/\s*\.byte\s+(?:0x[0-9a-f]{1,2}[\s,]*){2,}/i'
^^^ ^
now useless without the " matches .BYTE
you probably want (?i:0x[etc...]
I'd prefer to add an upper bound to the {m,n} use.
Unbounded multiple
matches {m,} can cause perl aborts.
This regex would also match
.byte 0x020x02
(which admittedly wouldn't compile, but I've seen really
bad patches submitted too)
> which assumes at least 2 opcode bytes; upper limit can be more than 4.
> It still has some false positives in crypto but I'd say that's good
> enough. I'll play more with it later
A readability convenience would be to add and use:
our $Hex_byte = qr{(?i)0x[0-9a-f]{1,2}\b};
So if the minimum length if the isns .byte block is 2,
with a separating comma then the regex could be:
/\.byte\s+$Hex_byte\s*,\s*$Hex_byte\b/
which I think is pretty readable.
$ git grep -P '\.byte\s+(?i:0x[0-9a-f]{1,2}\s*,\s*0x[0-9a-f]{1,2})\b' --
'arch/x86/*.[ch]'
arch/x86/include/asm/bug.h:#define ASM_UD0 ".byte 0x0f, 0xff" /* +
ModRM (for Intel) */
arch/x86/include/asm/bug.h:#define ASM_UD1 ".byte 0x0f, 0xb9" /* +
ModRM */
arch/x86/include/asm/bug.h:#define ASM_UD2 ".byte 0x0f, 0x0b"
arch/x86/include/asm/inst.h:.byte 0x0f, 0xc7
arch/x86/include/asm/intel_pconfig.h:#define PCONFIG ".byte 0x0f, 0x01, 0xc5"
arch/x86/include/asm/mwait.h: asm volatile(".byte 0x0f, 0x01, 0xc8;"
arch/x86/include/asm/mwait.h: asm volatile(".byte 0x0f, 0x01, 0xfa;"
arch/x86/include/asm/mwait.h: asm volatile(".byte 0x0f, 0x01, 0xc9;"
arch/x86/include/asm/mwait.h: asm volatile(".byte 0x0f, 0x01, 0xfb;"
arch/x86/include/asm/mwait.h: asm volatile("sti; .byte 0x0f, 0x01, 0xc9;"
arch/x86/include/asm/mwait.h: asm volatile(".byte 0x66, 0x0f, 0xae, 0xf1\t\n"
arch/x86/include/asm/segment.h: ".byte 0xf3,0x0f,0xc7,0xf8", /*
RDPID %eax/rax */
arch/x86/include/asm/smap.h:#define __ASM_CLAC ".byte 0x0f,0x01,0xca"
arch/x86/include/asm/smap.h:#define __ASM_STAC ".byte 0x0f,0x01,0xcb"
arch/x86/include/asm/special_insns.h: asm volatile(".byte 0x0f,0x01,0xee\n\t"
arch/x86/include/asm/special_insns.h: asm volatile(".byte 0x0f,0x01,0xef\n\t"
arch/x86/include/asm/special_insns.h: ".byte 0x66, 0x0f, 0xae, 0x30",
/* clwb (%%rax) */
arch/x86/include/asm/special_insns.h: asm volatile(".byte 0x66, 0x0f, 0x38,
0xf8, 0x02"
arch/x86/include/asm/special_insns.h: asm volatile(".byte 0xf3, 0x0f, 0x38,
0xf8, 0x02, 0x66, 0x90"
arch/x86/include/asm/special_insns.h: asm volatile(".byte 0xf, 0x1, 0xe8" :::
"memory");
Re: [PATCH v2 2/4] time: make getboottime64 aware of time namespace
Michael, On Sat, Oct 10 2020 at 13:50, Michael Weiß wrote: > On 10.10.20 09:19, Andrei Vagin wrote: >> And I think we need to consider an option to not change getbootime64 and >> apply a timens offset right in the show_stat(fs/proc/stat.c) >> function. That's what I meant and failed to express correctly. > Since the problems in softirq context mentioned from Thomas, > I would agree to Andrei's option to just patch proc/stat.c and leave > getboottime64 unchanged. > > Digging around in the kernel tree, I just found /proc/stat as the only > place where boottime is exposed to userspace, thus it seems a valid > option. Yes, I thought about a wrapper function which adds the namespace offset, but as it is the only place, open coding is fine. Thanks, tglx
[PATCH 1/2] cx82310_eth: re-enable ethernet mode after router reboot
When the router is rebooted without a power cycle, the USB device
remains connected but its configuration is reset. This results in
a non-working ethernet connection with messages like this in syslog:
usb 2-2: RX packet too long: 65535 B
Re-enable ethernet mode when receiving a packet with invalid size of
0x.
Signed-off-by: Ondrej Zary
---
drivers/net/usb/cx82310_eth.c | 50 ++-
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/cx82310_eth.c b/drivers/net/usb/cx82310_eth.c
index 32b08b18e120..043679311399 100644
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx82310_eth.c
@@ -40,6 +40,11 @@ enum cx82310_status {
#define CX82310_MTU1514
#define CMD_EP 0x01
+struct cx82310_priv {
+ struct work_struct reenable_work;
+ struct usbnet *dev;
+};
+
/*
* execute control command
* - optionally send some data (command parameters)
@@ -115,6 +120,23 @@ static int cx82310_cmd(struct usbnet *dev, enum
cx82310_cmd cmd, bool reply,
return ret;
}
+static int cx82310_enable_ethernet(struct usbnet *dev)
+{
+ int ret = cx82310_cmd(dev, CMD_ETHERNET_MODE, true, "\x01", 1, NULL, 0);
+
+ if (ret)
+ netdev_err(dev->net, "unable to enable ethernet mode: %d\n",
+ ret);
+ return ret;
+}
+
+static void cx82310_reenable_work(struct work_struct *work)
+{
+ struct cx82310_priv *priv = container_of(work, struct cx82310_priv,
+reenable_work);
+ cx82310_enable_ethernet(priv->dev);
+}
+
#define partial_lendata[0] /* length of partial packet data */
#define partial_remdata[1] /* remaining (missing) data length */
#define partial_data data[2] /* partial packet data */
@@ -126,6 +148,7 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
struct usb_device *udev = dev->udev;
u8 link[3];
int timeout = 50;
+ struct cx82310_priv *priv;
/* avoid ADSL modems - continue only if iProduct is "USB NET CARD" */
if (usb_string(udev, udev->descriptor.iProduct, buf, sizeof(buf)) > 0
@@ -152,6 +175,15 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
if (!dev->partial_data)
return -ENOMEM;
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ ret = -ENOMEM;
+ goto err_partial;
+ }
+ dev->driver_priv = priv;
+ INIT_WORK(>reenable_work, cx82310_reenable_work);
+ priv->dev = dev;
+
/* wait for firmware to become ready (indicated by the link being up) */
while (--timeout) {
ret = cx82310_cmd(dev, CMD_GET_LINK_STATUS, true, NULL, 0,
@@ -168,12 +200,8 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
}
/* enable ethernet mode (?) */
- ret = cx82310_cmd(dev, CMD_ETHERNET_MODE, true, "\x01", 1, NULL, 0);
- if (ret) {
- dev_err(>dev, "unable to enable ethernet mode: %d\n",
- ret);
+ if (cx82310_enable_ethernet(dev))
goto err;
- }
/* get the MAC address */
ret = cx82310_cmd(dev, CMD_GET_MAC_ADDR, true, NULL, 0,
@@ -190,13 +218,19 @@ static int cx82310_bind(struct usbnet *dev, struct
usb_interface *intf)
return 0;
err:
+ kfree(dev->driver_priv);
+err_partial:
kfree((void *)dev->partial_data);
return ret;
}
static void cx82310_unbind(struct usbnet *dev, struct usb_interface *intf)
{
+ struct cx82310_priv *priv = dev->driver_priv;
+
kfree((void *)dev->partial_data);
+ cancel_work_sync(>reenable_work);
+ kfree(dev->driver_priv);
}
/*
@@ -211,6 +245,7 @@ static int cx82310_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
{
int len;
struct sk_buff *skb2;
+ struct cx82310_priv *priv = dev->driver_priv;
/*
* If the last skb ended with an incomplete packet, this skb contains
@@ -245,7 +280,10 @@ static int cx82310_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
break;
}
- if (len > CX82310_MTU) {
+ if (len == 0x) {
+ netdev_info(dev->net, "router was rebooted, re-enabling
ethernet mode");
+ schedule_work(>reenable_work);
+ } else if (len > CX82310_MTU) {
dev_err(>udev->dev, "RX packet too long: %d B\n",
len);
return 0;
--
Ondrej Zary
Re: [PATCH v4 0/3] pinctrl: Ingenic: Add support for SSI and I2S pins.
Hi Linus, Zhou, The first patch is bogus. Half of the SSI pins are wrong (GPIO chip D/E start at 0x60/0x80 respectively). Sorry for not catching that before. -Paul Le mar. 29 sept. 2020 à 14:48, Linus Walleij a écrit : On Sun, Sep 13, 2020 at 8:59 AM 周琰杰 (Zhou Yanjie) wrote: 1.Add SSI pins support for JZ4770 and JZ4780. 2.Correct the pullup and pulldown parameters of JZ4780. 3.Add I2S pins support for JZ4780, X1000, X1500, and X1830. v2->v3: 1.Add Paul Cercueil's Reviewed-by. 2.Fix bug about PE15's pull-up parameter. This v3 patch set applied! Thank you so much for your hard work! Yours, Linus Walleij
Re: [PATCH v3 3/3] dt-bindings: iio: dac: ad5686: add binding
On Tue, 29 Sep 2020 13:53:00 -0500 Rob Herring wrote: > On Thu, 24 Sep 2020 14:52:14 -0500, Michael Auchter wrote: > > Add a binding for AD5686 > > > > Signed-off-by: Michael Auchter > > --- > > Changes since v1: > > - Keep supported device sorted > > - fix adc -> dac typo in schema path > > since v2: > > - drop address-cells and size-cells from binding doc > > - add "additionalProperties: false" > > - end with ... > > > > .../bindings/iio/dac/adi,ad5686.yaml | 57 +++ > > 1 file changed, 57 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml > > > > Reviewed-by: Rob Herring Series applied with a slight tweak to patch 1 to constify the channel macro inline with recent tidy up patch doing the same to other instances in the driver. Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to poke at it and see if we missed anything. Thanks, Jonathan
Re: [PATCH] irqbypass: fix error handle when irq_bypass_register_producer() return fails
On Sat, 10 Oct 2020 19:01:30 +0800
gchen chen wrote:
> Alex Williamson 于2020年10月10日周六 上午2:44写道：
> >
> > On Fri, 9 Oct 2020 12:30:04 +0800
> > gchen chen wrote:
> >
> > > Alex Williamson 于2020年9月30日周三 下午10:09写道：
> > > >
> > > >
> > > > Please version your postings so we know which one to consider as the
> > > > current proposal.
> > > >
> > > > On Wed, 30 Sep 2020 20:54:39 +0800
> > > > guomin_c...@sina.com wrote:
> > > >
> > > > > From: guomin chen
> > > > >
> > > > > When the producer object registration fails,In the future, due to
> > > > > incorrect matching when unregistering, list_del(>node)
> > > > > may still be called, then trigger a BUG:
> > > > >
> > > > > vfio-pci :db:00.0: irq bypass producer (token
> > > > > 60c8cda5) registration fails: -16
> > > > > vfio-pci :db:00.0: irq bypass producer (token
> > > > > 60c8cda5) registration fails: -16
> > > > > vfio-pci :db:00.0: irq bypass producer (token
> > > > > 60c8cda5) registration fails: -16
> > > > > ...
> > > > > list_del corruption, 8f7fb8ba0828->next is LIST_POISON1
> > > > > (dead0100)
> > > > > [ cut here ]
> > > > > kernel BUG at lib/list_debug.c:47!
> > > > > invalid opcode: [#1] SMP NOPTI
> > > > > CPU: 29 PID: 3914 Comm: qemu-kvm Kdump: loaded Tainted: G E
> > > > > - -4.18.0-193.6.3.el8.x86_64 #1
> > > > > Hardware name: Lenovo ThinkSystem SR650
> > > > > -[7X06CTO1WW]-/-[7X06CTO1WW]-,
> > > > > BIOS -[IVE636Z-2.13]- 07/18/2019
> > > > > RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x4c
> > > > > Code: ce ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 40 85 4d 88 e8 8c bc
> > > > > ce ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 d0 85 4d 88 e8 78 bc
> > > > > ce ff <0f> 0b 48 c7 c7 80 86 4d 88 e8 6a bc ce ff 0f 0b 48
> > > > > 89 f2 48 89 fe
> > > > > RSP: 0018:aa9d60197d20 EFLAGS: 00010246
> > > > > RAX: 004e RBX: 8f7fb8ba0828 RCX:
> > > > > RDX: RSI: 8f7fbf4d6a08 RDI: 8f7fbf4d6a08
> > > > > RBP: R08: 084b R09: 005d
> > > > > R10: R11: aa9d60197bd0 R12: 8f4fbe863000
> > > > > R13: 00c2 R14: R15:
> > > > > FS: 7f7cb97fa700() GS:8f7fbf4c()
> > > > > knlGS:
> > > > > CS: 0010 DS: ES: CR0: 80050033
> > > > > CR2: 7fcf31da4000 CR3: 005f6d404001 CR4: 007626e0
> > > > > DR0: DR1: DR2:
> > > > > DR3: DR6: fffe0ff0 DR7: 0400
> > > > > PKRU: 5554
> > > > > Call Trace:
> > > > > irq_bypass_unregister_producer+0x9b/0xf0 [irqbypass]
> > > > > vfio_msi_set_vector_signal+0x8c/0x290 [vfio_pci]
> > > > > ? load_fixmap_gdt+0x22/0x30
> > > > > vfio_msi_set_block+0x6e/0xd0 [vfio_pci]
> > > > > vfio_pci_ioctl+0x218/0xbe0 [vfio_pci]
> > > > > ? kvm_vcpu_ioctl+0xf2/0x5f0 [kvm]
> > > > > do_vfs_ioctl+0xa4/0x630
> > > > > ? syscall_trace_enter+0x1d3/0x2c0
> > > > > ksys_ioctl+0x60/0x90
> > > > > __x64_sys_ioctl+0x16/0x20
> > > > > do_syscall_64+0x5b/0x1a0
> > > > > entry_SYSCALL_64_after_hwframe+0x65/0xca
> > > > >
> > > > > Cc: Alex Williamson
> > > > > Cc: Cornelia Huck
> > > > > Cc: Jiang Yi
> > > > > Cc: Marc Zyngier
> > > > > Cc: Peter Xu
> > > > > Cc: Eric Auger
> > > > > Cc: "Michael S. Tsirkin"
> > > > > Cc: Jason Wang
> > > > > Cc: k...@vger.kernel.org
> > > > > Cc: linux-kernel@vger.kernel.org
> > > > > Signed-off-by: guomin chen
> > > > > ---
> > > > > drivers/vfio/pci/vfio_pci_intrs.c | 13 +++--
> > > > > drivers/vhost/vdpa.c | 7 +++
> > > > > 2 files changed, 18 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
> > > > > b/drivers/vfio/pci/vfio_pci_intrs.c
> > > > > index 1d9fb25..c371943 100644
> > > > > --- a/drivers/vfio/pci/vfio_pci_intrs.c
> > > > > +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> > > > > @@ -352,12 +352,21 @@ static int vfio_msi_set_vector_signal(struct
> > > > > vfio_pci_device *vdev,
> > > > > vdev->ctx[vector].producer.token = trigger;
> > > > > vdev->ctx[vector].producer.irq = irq;
> > > > > ret = irq_bypass_register_producer(>ctx[vector].producer);
> > > > > - if (unlikely(ret))
> > > > > + if (unlikely(ret)) {
> > > > > dev_info(>dev,
> > > > > "irq bypass producer (token %p) registration fails:
> > > > > %d\n",
> > > > > vdev->ctx[vector].producer.token, ret);
> > > > >
> > > > > - vdev->ctx[vector].trigger = trigger;
> > > > > + kfree(vdev->ctx[vector].name);
> > > > > +
Re: [net-next PATCH v1] net: phy: Move of_mdio from drivers/of to drivers/net/mdio
On Thu, 8 Oct 2020 20:17:06 +0530 Calvin Johnson wrote: > Better place for of_mdio.c is drivers/net/mdio. > Move of_mdio.c from drivers/of to drivers/net/mdio > > Signed-off-by: Calvin Johnson Applied, thank you.
Re: [PATCH 3/8] staging: wfx: standardize the error when vif does not exist
On Saturday 10 October 2020 14:40:34 CEST Greg Kroah-Hartman wrote:
> On Sat, Oct 10, 2020 at 02:22:13PM +0200, Jérôme Pouiller wrote:
> > On Friday 9 October 2020 20:52:47 CEST Kalle Valo wrote:
> > > Jerome Pouiller writes:
> > >
> > > > From: Jérôme Pouiller
> > > >
> > > > Smatch complains:
> > > >
> > > >drivers/staging/wfx/hif_rx.c:177 hif_scan_complete_indication()
> > > > warn: potential NULL parameter dereference 'wvif'
> > > >drivers/staging/wfx/data_tx.c:576 wfx_flush() warn: potential NULL
> > > > parameter dereference 'wvif'
> > > >
> > > > Indeed, if the vif id returned by the device does not exist anymore,
> > > > wdev_to_wvif() could return NULL.
> > > >
> > > > In add, the error is not handled uniformly in the code, sometime a
> > > > WARN() is displayed but code continue, sometime a dev_warn() is
> > > > displayed, sometime it is just not tested, ...
> > > >
> > > > This patch standardize that.
> > > >
> > > > Reported-by: Dan Carpenter
> > > > Signed-off-by: Jérôme Pouiller
> > > > ---
> > > > drivers/staging/wfx/data_tx.c | 5 -
> > > > drivers/staging/wfx/hif_rx.c | 34 --
> > > > drivers/staging/wfx/sta.c | 4
> > > > 3 files changed, 32 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/wfx/data_tx.c
> > > > b/drivers/staging/wfx/data_tx.c
> > > > index b4d5dd3d2d23..8db0be08daf8 100644
> > > > --- a/drivers/staging/wfx/data_tx.c
> > > > +++ b/drivers/staging/wfx/data_tx.c
> > > > @@ -431,7 +431,10 @@ static void wfx_skb_dtor(struct wfx_vif *wvif,
> > > > struct sk_buff *skb)
> > > > sizeof(struct hif_req_tx) +
> > > > req->fc_offset;
> > > >
> > > > - WARN_ON(!wvif);
> > > > + if (!wvif) {
> > > > + pr_warn("%s: vif associated with the skb does not exist
> > > > anymore\n", __func__);
> > > > + return;
> > > > + }
> > >
> > > I'm not really a fan of using function names in warning or error
> > > messages as it clutters the log. In debug messages I think they are ok.
> >
> > In the initial code, I used WARN() that far more clutters the log (I
> > have stated that a backtrace won't provide any useful information, so
> > pr_warn() was better suited).
> >
> > In add, in my mind, these warnings are debug messages. If they appears,
> > the user should probably report a bug.
> >
> > Finally, in this patch, I use the same message several times (ok, not
> > this particular one). So the function name is a way to differentiate
> > them.
>
> You should use dev_*() for these, that way you can properly determine
> the exact device as well.
Totally agree. I initially did that. However, the device is a field of
wvif which is NULL in this case.
I could have changed the code to get the real pointer to the device. But
I didn't want to clutter the code just for a debug message (and also
because I was a bit lazy).
--
Jérôme Pouiller
[PATCH 13/18] dt-bindings: usb: dwc3: Add Tx De-emphasis restrictions
In accordance with the driver comments the PIPE3 de-emphasis can be tunned to be either -6dB, or -2.5dB or disabled. Let's add the de-emphasis property restriction so the DT schema would make sure the controller DT node is equipped with correct values. Signed-off-by: Serge Semin --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index fe1b372fda80..36d4b8060d7c 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -145,6 +145,10 @@ properties: The value driven to the PHY is controlled by the LTSSM during USB3 Compliance mode. $ref: /schemas/types.yaml#/definitions/uint8 +enum: + - 0 # -6dB de-emphasis + - 1 # -3.5dB de-emphasis + - 2 # No de-emphasis snps,dis_u3_susphy_quirk: description: When set core will disable USB3 suspend phy -- 2.27.0
Re: inconsistent lock state in sco_conn_del
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:e8878ab8 Merge tag 'spi-fix-v5.9-rc4' of
git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1213075990
> kernel config:
https://syzkaller.appspot.com/x/.config?x=c61610091f4ca8c4
> dashboard link:
https://syzkaller.appspot.com/bug?extid=65684128cd7c35bc66a1
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro:
https://syzkaller.appspot.com/x/repro.syz?x=121ef0fd90
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16c3a85390
>
> IMPORTANT: if you fix the issue, please add the following tag to the
commit:
> Reported-by: syzbot+65684128cd7c35bc6...@syzkaller.appspotmail.com
>
>
> WARNING: inconsistent lock state
> 5.9.0-rc4-syzkaller #0 Not tainted
>
> inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
> syz-executor675/31233 [HC0[0]:SC0[0]:HE1:SE1] takes:
> 8880a75c50a0 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.?.}-{2:2}, at:
spin_lock include/linux/spinlock.h:354 [inline]
> 8880a75c50a0 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.?.}-{2:2}, at:
sco_conn_del+0x128/0x270 net/bluetooth/sco.c:176
> {IN-SOFTIRQ-W} state was registered at:
>lock_acquire+0x1f3/0xae0 kernel/locking/lockdep.c:5006
>__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
>_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
>spin_lock include/linux/spinlock.h:354 [inline]
>sco_sock_timeout+0x24/0x140 net/bluetooth/sco.c:83
>call_timer_fn+0x1ac/0x760 kernel/time/timer.c:1413
>expire_timers kernel/time/timer.c:1458 [inline]
>__run_timers.part.0+0x67c/0xaa0 kernel/time/timer.c:1755
>__run_timers kernel/time/timer.c:1736 [inline]
>run_timer_softirq+0xae/0x1a0 kernel/time/timer.c:1768
>__do_softirq+0x1f7/0xa91 kernel/softirq.c:298
>asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:706
>__run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
>run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
>do_softirq_own_stack+0x9d/0xd0 arch/x86/kernel/irq_64.c:77
>invoke_softirq kernel/softirq.c:393 [inline]
>__irq_exit_rcu kernel/softirq.c:423 [inline]
>irq_exit_rcu+0x235/0x280 kernel/softirq.c:435
>sysvec_apic_timer_interrupt+0x51/0xf0 arch/x86/kernel/apic/apic.c:1091
>asm_sysvec_apic_timer_interrupt+0x12/0x20
arch/x86/include/asm/idtentry.h:581
>unwind_next_frame+0x139a/0x1f90 arch/x86/kernel/unwind_orc.c:607
>arch_stack_walk+0x81/0xf0 arch/x86/kernel/stacktrace.c:25
>stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:123
>kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
>kasan_set_track mm/kasan/common.c:56 [inline]
>__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461
>slab_post_alloc_hook mm/slab.h:518 [inline]
>slab_alloc mm/slab.c:3312 [inline]
>kmem_cache_alloc+0x13a/0x3a0 mm/slab.c:3482
>__d_alloc+0x2a/0x950 fs/dcache.c:1709
>d_alloc+0x4a/0x230 fs/dcache.c:1788
>d_alloc_parallel+0xe9/0x18e0 fs/dcache.c:2540
>lookup_open.isra.0+0x9ac/0x1350 fs/namei.c:3030
>open_last_lookups fs/namei.c:3177 [inline]
>path_openat+0x96d/0x2730 fs/namei.c:3365
>do_filp_open+0x17e/0x3c0 fs/namei.c:3395
>do_sys_openat2+0x16d/0x420 fs/open.c:1168
>do_sys_open fs/open.c:1184 [inline]
>__do_sys_open fs/open.c:1192 [inline]
>__se_sys_open fs/open.c:1188 [inline]
>__x64_sys_open+0x119/0x1c0 fs/open.c:1188
>do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>entry_SYSCALL_64_after_hwframe+0x44/0xa9
> irq event stamp: 853
> hardirqs last enabled at (853): []
__raw_spin_unlock_irq include/linux/spinlock_api_smp.h:168 [inline]
> hardirqs last enabled at (853): []
_raw_spin_unlock_irq+0x1f/0x80 kernel/locking/spinlock.c:199
> hardirqs last disabled at (852): []
__raw_spin_lock_irq include/linux/spinlock_api_smp.h:126 [inline]
> hardirqs last disabled at (852): []
_raw_spin_lock_irq+0xa4/0xd0 kernel/locking/spinlock.c:167
> softirqs last enabled at (0): []
copy_process+0x1a99/0x6920 kernel/fork.c:2018
> softirqs last disabled at (0): [<>] 0x0
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
>
>lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
>
> lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
>
> *** DEADLOCK ***
>
> 3 locks held by syz-executor675/31233:
> #0: 88809f104f40 (>req_lock){+.+.}-{3:3}, at:
hci_dev_do_close+0xf5/0x1080 net/bluetooth/hci_core.c:1720
> #1: 88809f104078 (>lock){+.+.}-{3:3}, at:
hci_dev_do_close+0x253/0x1080 net/bluetooth/hci_core.c:1757
> #2: 8a9188c8 (hci_cb_list_lock){+.+.}-{3:3}, at:
hci_disconn_cfm include/net/bluetooth/hci_core.h:1435 [inline]
> #2: 8a9188c8 (hci_cb_list_lock){+.+.}-{3:3}, at:
hci_conn_hash_flush+0xc7/0x220 net/bluetooth/hci_conn.c:1557
>
> stack backtrace:
> CPU: 1
RE: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue
> -Original Message-
> From: ChiYuan Huang
> Sent: Saturday, October 10, 2020 12:06 AM
> To: Jun Li
> Cc: Jun Li ; Guenter Roeck ;
> Greg KH ; Heikki Krogerus
> ; Linux USB List
> ; lkml ;
> cy_huang
> Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count
> not reset issue
>
> Jun Li 於 2020年10月9日 週五 下午2:12寫道：
> >
> >
> >
> > > -Original Message-
> > > From: ChiYuan Huang
> > > Sent: Wednesday, October 7, 2020 6:13 PM
> > > To: Jun Li
> > > Cc: Guenter Roeck ; Greg KH
> > > ; Heikki Krogerus
> > > ; Linux USB List
> > > ; lkml ;
> > > cy_huang ; Jun Li
> > > Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc,
> > > hard_reset_count not reset issue
> > >
> > > ChiYuan Huang 於 2020年10月7日 週三 上午1:39寫
> 道：
> > > >
> > > > Jun Li 於 2020年10月7日 週三 上午12:52寫
> 道：
> > > > >
> > > > > ChiYuan Huang 于2020年10月6日周二 下午12:38
> 写
> > > 道：
> > > > > >
> > > > > > Guenter Roeck 於 2020年10月5日 週一 下午
> 11:30
> > > 寫道：
> > > > > > >
> > > > > > > On 10/5/20 4:08 AM, Greg KH wrote:
> > > > > > > [ ... ]
> > > > > > > >>> What ever happened with this patch, is there still
> > > > > > > >>> disagreement?
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >> Yes, there is. I wouldn't have added the conditional
> > > > > > > >> without reason, and I am concerned that removing it
> > > > > > > >> entirely will open
> > > another problem.
> > > > > > > >> Feel free to apply, though - I can't prove that my
> > > > > > > >> concern is valid, and after all we'll get reports from
> > > > > > > >> the field later if
> > > it is.
> > > > > > > >
> > > > > > > > Ok, can I get an ack so I know who to come back to in the
> > > > > > > > future if there are issues? :)
> > > > > > > >
> > > > > > >
> > > > > > > Not from me, for the reasons I stated. I would be ok with
> > > > > > > something
> > > like:
> > > > > > >
> > > > > > > - if (tcpm_port_is_disconnected(port))
> > > > > > > + if (tcpm_port_is_disconnected(port) ||
> > > > > > > + (tcpm_cc_is_open(port->cc1) &&
> > > > > > > + tcpm_cc_is_open(port->cc2)))
> > > > > > >
> > > > > > > to narrow down the condition.
> > > > > >
> > > > > > I have tried the above comment and It doesn't work.
> > > > > > How about to change the judgement like as below
> > > > > >
> > > > > > - if (tcpm_port_is_disconnected(port))
> > > > > > + if (tcpm_port_is_disconnected(port) ||
> > > > > > + !port->vbus_present)
> > > > > >
> > > > > > The hard_reset_count not reset issue is following by the below
> > > > > > order 1. VBUS off ( at the same time, cc is still detected as
> > > > > > attached)
> > > > > > port->attached become false and cc is not open
> > > > > > 2. After that, cc detached.
> > > > > > due to port->attached is false, tcpm_detach() directly return.
> > > > >
> > > > > If tcpm_detach() return directly, then how your patch can reset
> > > > > hard_reset_count?
> > > > >
> > > > Yes, it can. We know vbus_present change from true to false and cc
> > > > detach both trigger tcpm_detach.
> > > > My change is whenever tcpm_detach to be called, hard_reset_count
> > > > will be reset to zero.
> > > >
> > > > > I am seeing the same issue on my platform, the proposed change:
> > > > > - if (tcpm_port_is_disconnected(port))
> > > > > - port->hard_reset_count = 0;
> > > > > + port->hard_reset_count = 0;
> > > > > can't resolve it on my platform.
> > > > >
> > > > I'm not sure what's your condition. Could you directly paste the
> > > > tcpm log for the check?
> > > > > How about reset hard_reset_count in SNK_READY?
> > > > > @@ -3325,6 +3329,7 @@ static void run_state_machine(struct
> > > > > tcpm_port
> > > *port)
> > > > > case SNK_READY:
> > > > > port->try_snk_count = 0;
> > > > > port->update_sink_caps = false;
> > > > > + port->hard_reset_count = 0;
> > > > > if (port->explicit_contract) {
> > > > > typec_set_pwr_opmode(port->typec_port,
> > > > > TYPEC_PWR_MODE_PD);
> > > > >
> > > > > can this resolve your problem?
> > > > I'm not sure. It need to have a try, then I can answer you.
> > > > But from USBPD spec, the hard_reset_count need to reset zero only
> > > > when 1. At src state, pe_src_send_cap and receive GoodCRC 2. At
> > > > snk state, pe_snk_evaluate_cap need to reset hard_reset_count
> >
> > 3.
> > 8.3.3.3.8 PE_SNK_Hard_Reset state
> > "Note: The HardResetCounter is reset on a power cycle or Detach."
> >
> > > > >
> > > > > Li Jun
> > > > > >
> > > > > > And that's why hard_reset_count is not reset to 0.
> > >
> > > I tried in snk_ready to reset hard_reset_count.
> > > At normal case, it works.
> > > But it seems still the possible fail case like as below.
> > > 200ms -> cc debounce max time
> > > 240ms -> snk_waitcap max time
> > > If the plugin/out period is between (200+240) and (200+ 2* 240)ms ,
> > > and the src side plug out
[PATCH 05/18] dt-bindings: usb: usb-hcd: Add "tpl-support" property
The host controller device might be designed to work for the particular
products or applications. In that case it' DT node is supposed to be
equipped with the tpl-support property.
Signed-off-by: Serge Semin
---
Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
index 1eddcbf0a9d8..c898166a8c6c 100644
--- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
@@ -97,6 +97,12 @@ properties:
enum: ["host", "peripheral"]
default: "peripheral"
+ tpl-support:
+description: |
+ Indicates if the Targeted Peripheral List is supported for given
+ targeted hosts (non-PC hosts).
+type: boolean
+
examples:
- |
usb {
--
2.27.0
Re: [PATCH 2/8] staging: wfx: check memory allocation
On Friday 9 October 2020 20:51:01 CEST Kalle Valo wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> Jerome Pouiller writes:
>
> > From: Jérôme Pouiller
> >
> > Smatch complains:
> >
> >main.c:228 wfx_send_pdata_pds() warn: potential NULL parameter
> > dereference 'tmp_buf'
> >227 tmp_buf = kmemdup(pds->data, pds->size, GFP_KERNEL);
> >228 ret = wfx_send_pds(wdev, tmp_buf, pds->size);
> > ^^^
> >229 kfree(tmp_buf);
> >
> > Reported-by: Dan Carpenter
> > Signed-off-by: Jérôme Pouiller
> > ---
> > drivers/staging/wfx/main.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
> > index df11c091e094..a8dc2c033410 100644
> > --- a/drivers/staging/wfx/main.c
> > +++ b/drivers/staging/wfx/main.c
> > @@ -222,12 +222,18 @@ static int wfx_send_pdata_pds(struct wfx_dev *wdev)
> > if (ret) {
> > dev_err(wdev->dev, "can't load PDS file %s\n",
> > wdev->pdata.file_pds);
> > - return ret;
> > + goto err1;
> > }
> > tmp_buf = kmemdup(pds->data, pds->size, GFP_KERNEL);
> > + if (!tmp_buf) {
> > + ret = -ENOMEM;
> > + goto err2;
> > + }
> > ret = wfx_send_pds(wdev, tmp_buf, pds->size);
> > kfree(tmp_buf);
> > +err2:
> > release_firmware(pds);
> > +err1:
> > return ret;
> > }
>
> A minor style issue but using more descriptive error labels make the
> code more readable and maintainable, especially in a bigger function.
> For example, err2 could be called err_release_firmware.
>
> And actually err1 could be removed and the goto replaced with just
> "return ret;". Then err2 could be renamed to a simple err.
It was the case in the initial code. However, I have preferred to not
mix 'return' and 'goto' inside the same function. Probably a matter of
taste.
Greg has already applied the series, but I don't forget this review. I
will take it into account in the series I am going to send you (probably
in the v2, in order to not defer the v1).
--
Jérôme Pouiller
Re: [PATCH 3/8] staging: wfx: standardize the error when vif does not exist
On Friday 9 October 2020 20:52:47 CEST Kalle Valo wrote:
> Jerome Pouiller writes:
>
> > From: Jérôme Pouiller
> >
> > Smatch complains:
> >
> >drivers/staging/wfx/hif_rx.c:177 hif_scan_complete_indication() warn:
> > potential NULL parameter dereference 'wvif'
> >drivers/staging/wfx/data_tx.c:576 wfx_flush() warn: potential NULL
> > parameter dereference 'wvif'
> >
> > Indeed, if the vif id returned by the device does not exist anymore,
> > wdev_to_wvif() could return NULL.
> >
> > In add, the error is not handled uniformly in the code, sometime a
> > WARN() is displayed but code continue, sometime a dev_warn() is
> > displayed, sometime it is just not tested, ...
> >
> > This patch standardize that.
> >
> > Reported-by: Dan Carpenter
> > Signed-off-by: Jérôme Pouiller
> > ---
> > drivers/staging/wfx/data_tx.c | 5 -
> > drivers/staging/wfx/hif_rx.c | 34 --
> > drivers/staging/wfx/sta.c | 4
> > 3 files changed, 32 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
> > index b4d5dd3d2d23..8db0be08daf8 100644
> > --- a/drivers/staging/wfx/data_tx.c
> > +++ b/drivers/staging/wfx/data_tx.c
> > @@ -431,7 +431,10 @@ static void wfx_skb_dtor(struct wfx_vif *wvif, struct
> > sk_buff *skb)
> > sizeof(struct hif_req_tx) +
> > req->fc_offset;
> >
> > - WARN_ON(!wvif);
> > + if (!wvif) {
> > + pr_warn("%s: vif associated with the skb does not exist
> > anymore\n", __func__);
> > + return;
> > + }
>
> I'm not really a fan of using function names in warning or error
> messages as it clutters the log. In debug messages I think they are ok.
In the initial code, I used WARN() that far more clutters the log (I
have stated that a backtrace won't provide any useful information, so
pr_warn() was better suited).
In add, in my mind, these warnings are debug messages. If they appears,
the user should probably report a bug.
Finally, in this patch, I use the same message several times (ok, not
this particular one). So the function name is a way to differentiate
them.
--
Jérôme Pouiller
Re: [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize new kmap_thread()
-ira.we...@intel.com wrote: -
>To: "Andrew Morton" , "Thomas Gleixner"
>, "Ingo Molnar" , "Borislav
>Petkov" , "Andy Lutomirski" , "Peter
>Zijlstra"
>From: ira.we...@intel.com
>Date: 10/09/2020 09:52PM
>Cc: "Ira Weiny" , "Mike Marciniszyn"
>, "Dennis Dalessandro"
>, "Doug Ledford" ,
>"Jason Gunthorpe" , "Faisal Latif"
>, "Shiraz Saleem" ,
>"Bernard Metzler" , x...@kernel.org, "Dave Hansen"
>, "Dan Williams"
>, "Fenghua Yu" ,
>linux-...@vger.kernel.org, linux-kernel@vger.kernel.org,
>linux-nvd...@lists.01.org, linux-fsde...@vger.kernel.org,
>linux...@kvack.org, linux-kselft...@vger.kernel.org,
>linuxppc-...@lists.ozlabs.org, k...@vger.kernel.org,
>net...@vger.kernel.org, b...@vger.kernel.org,
>ke...@lists.infradead.org, linux-bca...@vger.kernel.org,
>linux-...@lists.infradead.org, de...@driverdev.osuosl.org,
>linux-...@vger.kernel.org, linux-...@vger.kernel.org,
>linux-s...@vger.kernel.org, target-de...@vger.kernel.org,
>linux-...@vger.kernel.org, ceph-de...@vger.kernel.org,
>linux-e...@vger.kernel.org, linux-...@kvack.org,
>io-ur...@vger.kernel.org, linux-er...@lists.ozlabs.org,
>linux...@lists.infradead.org, linux-ntfs-...@lists.sourceforge.net,
>reiserfs-de...@vger.kernel.org,
>linux-f2fs-de...@lists.sourceforge.net, linux-ni...@vger.kernel.org,
>cluster-de...@redhat.com, ecryp...@vger.kernel.org,
>linux-c...@vger.kernel.org, linux-bt...@vger.kernel.org,
>linux-...@lists.infradead.org, linux-r...@vger.kernel.org,
>amd-...@lists.freedesktop.org, dri-de...@lists.freedesktop.org,
>intel-...@lists.freedesktop.org, drbd-...@tron.linbit.com,
>linux-bl...@vger.kernel.org, xen-de...@lists.xenproject.org,
>linux-cach...@redhat.com, samba-techni...@lists.samba.org,
>intel-wired-...@lists.osuosl.org
>Subject: [EXTERNAL] [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize
>new kmap_thread()
>
>From: Ira Weiny
>
>The kmap() calls in these drivers are localized to a single thread.
>To
>avoid the over head of global PKRS updates use the new kmap_thread()
>call.
>
>Cc: Mike Marciniszyn
>Cc: Dennis Dalessandro
>Cc: Doug Ledford
>Cc: Jason Gunthorpe
>Cc: Faisal Latif
>Cc: Shiraz Saleem
>Cc: Bernard Metzler
>Signed-off-by: Ira Weiny
>---
> drivers/infiniband/hw/hfi1/sdma.c | 4 ++--
> drivers/infiniband/hw/i40iw/i40iw_cm.c | 10 +-
> drivers/infiniband/sw/siw/siw_qp_tx.c | 14 +++---
> 3 files changed, 14 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/infiniband/hw/hfi1/sdma.c
>b/drivers/infiniband/hw/hfi1/sdma.c
>index 04575c9afd61..09d206e3229a 100644
>--- a/drivers/infiniband/hw/hfi1/sdma.c
>+++ b/drivers/infiniband/hw/hfi1/sdma.c
>@@ -3130,7 +3130,7 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata
>*dd, struct sdma_txreq *tx,
> }
>
> if (type == SDMA_MAP_PAGE) {
>- kvaddr = kmap(page);
>+ kvaddr = kmap_thread(page);
> kvaddr += offset;
> } else if (WARN_ON(!kvaddr)) {
> __sdma_txclean(dd, tx);
>@@ -3140,7 +3140,7 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata
>*dd, struct sdma_txreq *tx,
> memcpy(tx->coalesce_buf + tx->coalesce_idx, kvaddr, len);
> tx->coalesce_idx += len;
> if (type == SDMA_MAP_PAGE)
>- kunmap(page);
>+ kunmap_thread(page);
>
> /* If there is more data, return */
> if (tx->tlen - tx->coalesce_idx)
>diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c
>b/drivers/infiniband/hw/i40iw/i40iw_cm.c
>index a3b95805c154..122d7a5642a1 100644
>--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
>+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
>@@ -3721,7 +3721,7 @@ int i40iw_accept(struct iw_cm_id *cm_id, struct
>iw_cm_conn_param *conn_param)
> ibmr->device = iwpd->ibpd.device;
> iwqp->lsmm_mr = ibmr;
> if (iwqp->page)
>- iwqp->sc_qp.qp_uk.sq_base = kmap(iwqp->page);
>+ iwqp->sc_qp.qp_uk.sq_base = kmap_thread(iwqp->page);
> dev->iw_priv_qp_ops->qp_send_lsmm(>sc_qp,
> iwqp->ietf_mem.va,
> (accept.size +
> conn_param->private_data_len),
>@@ -3729,12 +3729,12 @@ int i40iw_accept(struct iw_cm_id *cm_id,
>struct iw_cm_conn_param *conn_param)
>
> } else {
> if (iwqp->page)
>- iwqp->sc_qp.qp_uk.sq_base = kmap(iwqp->page);
>+ iwqp->sc_qp.qp_uk.sq_base = kmap_thread(iwqp->page);
> dev->iw_priv_qp_ops->qp_send_lsmm(>sc_qp, NULL, 0, 0);
> }
>
> if (iwqp->page)
>- kunmap(iwqp->page);
>+ kunmap_thread(iwqp->page);
>
> iwqp->cm_id = cm_id;
> cm_node->cm_id = cm_id;
>@@ -4102,10 +4102,10 @@ static void i40iw_cm_event_connected(struct
>i40iw_cm_event *event)
> i40iw_cm_init_tsa_conn(iwqp, cm_node);
> read0 =
[PATCH] kthread: Add kthread_work tracepoints
From: Rob Clark
While migrating some code from wq to kthread_worker, I found that I
missed the execute_start/end tracepoints. So add similar tracepoints
for kthread_work. And for completeness, queue_work tracepoint (although
this one differs slightly from the matching workqueue tracepoint).
Signed-off-by: Rob Clark
---
include/trace/events/sched.h | 84
kernel/kthread.c | 9
2 files changed, 93 insertions(+)
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index fec25b9cfbaf..349d9872e807 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -5,6 +5,7 @@
#if !defined(_TRACE_SCHED_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_SCHED_H
+#include
#include
#include
#include
@@ -51,6 +52,89 @@ TRACE_EVENT(sched_kthread_stop_ret,
TP_printk("ret=%d", __entry->ret)
);
+/**
+ * sched_kthread_work_queue_work - called when a work gets queued
+ * @worker:pointer to the kthread_worker
+ * @work: pointer to struct kthread_work
+ *
+ * This event occurs when a work is queued immediately or once a
+ * delayed work is actually queued (ie: once the delay has been
+ * reached).
+ */
+TRACE_EVENT(sched_kthread_work_queue_work,
+
+ TP_PROTO(struct kthread_worker *worker,
+struct kthread_work *work),
+
+ TP_ARGS(worker, work),
+
+ TP_STRUCT__entry(
+ __field( void *,work)
+ __field( void *,function)
+ __field( void *,worker)
+ ),
+
+ TP_fast_assign(
+ __entry->work = work;
+ __entry->function = work->func;
+ __entry->worker = worker;
+ ),
+
+ TP_printk("work struct=%p function=%ps worker=%p",
+ __entry->work, __entry->function, __entry->worker)
+);
+
+/**
+ * sched_kthread_work_execute_start - called immediately before the work
callback
+ * @work: pointer to struct kthread_work
+ *
+ * Allows to track kthread work execution.
+ */
+TRACE_EVENT(sched_kthread_work_execute_start,
+
+ TP_PROTO(struct kthread_work *work),
+
+ TP_ARGS(work),
+
+ TP_STRUCT__entry(
+ __field( void *,work)
+ __field( void *,function)
+ ),
+
+ TP_fast_assign(
+ __entry->work = work;
+ __entry->function = work->func;
+ ),
+
+ TP_printk("work struct %p: function %ps", __entry->work,
__entry->function)
+);
+
+/**
+ * sched_kthread_work_execute_end - called immediately after the work callback
+ * @work: pointer to struct work_struct
+ * @function: pointer to worker function
+ *
+ * Allows to track workqueue execution.
+ */
+TRACE_EVENT(sched_kthread_work_execute_end,
+
+ TP_PROTO(struct kthread_work *work, kthread_work_func_t function),
+
+ TP_ARGS(work, function),
+
+ TP_STRUCT__entry(
+ __field( void *,work)
+ __field( void *,function)
+ ),
+
+ TP_fast_assign(
+ __entry->work = work;
+ __entry->function = function;
+ ),
+
+ TP_printk("work struct %p: function %ps", __entry->work,
__entry->function)
+);
+
/*
* Tracepoint for waking up a task:
*/
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 3edaa380dc7b..c1e59d6bf802 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -704,8 +704,15 @@ int kthread_worker_fn(void *worker_ptr)
raw_spin_unlock_irq(>lock);
if (work) {
+ kthread_work_func_t func = work->func;
__set_current_state(TASK_RUNNING);
+ trace_sched_kthread_work_execute_start(work);
work->func(work);
+ /*
+* Avoid dereferencing work after this point. The trace
+* event only cares about the address.
+*/
+ trace_sched_kthread_work_execute_end(work, func);
} else if (!freezing(current))
schedule();
@@ -834,6 +841,8 @@ static void kthread_insert_work(struct kthread_worker
*worker,
{
kthread_insert_work_sanity_check(worker, work);
+ trace_sched_kthread_work_queue_work(worker, work);
+
list_add_tail(>node, pos);
work->worker = worker;
if (!worker->current_work && likely(worker->task))
--
2.26.2
Re: [PATCH v4 0/4] iio: adc: at91: misc driver cleanups
On Wed, 30 Sep 2020 16:50:44 +0300
Alexandru Ardelean wrote:
> This whole thing started because the lkp bot haunted me for a while with
> this build warning:
>
> >> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable
> >> 'at91_adc_dt_ids' [-Wunused-const-variable]
>static const struct of_device_id at91_adc_dt_ids[] = {
> ^
>1 warning generated.
>
> The fix may likely be patch 'iio: adc: at91_adc: add Kconfig dependency
> on the OF symbol'; was pointed out by Jonathan.
Series applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it and see what we missed.
Thanks,
Jonathan
>
> Changelog v3 -> v4:
> -
> https://lore.kernel.org/linux-iio/20200930125216.90424-1-alexandru.ardel...@analog.com/T/#t
> - for patch: 'iio: adc: at91_adc: remove platform data and move defs in
> driver file'
>* updated/cleand up commit description
>* remove redundant pdata erorr message
>* return error code from at91_adc_probe_dt()
>* remove 'if (!node)' null check in at91_adc_probe_dt()
> - added 'Reviewed-by: Alexandre Belloni '
> for patch: 'iio: adc: at91_adc: add Kconfig dep on the OF symbol and remove
> of_match_ptr()'
>
> Changelog v2 -> v3:
> -
> https://lore.kernel.org/linux-iio/20200930060008.42134-1-alexandru.ardel...@analog.com/T/#t
> - added 'Reviewed-by: Alexandre Belloni '
> for patches:
> iio: adc: at91_adc: use of_device_get_match_data() helper
> iio: adc: at91_adc: const-ify some driver data
> - fixed description for patch 'iio: adc: at91_adc: add Kconfig dependency on
> the OF symbol'
> - squash patches:
> iio: adc: at91_adc: add Kconfig dependency on the OF symbol
> iio: adc: at91_adc: remove of_match_ptr() usage
> - added patch: 'iio: adc: at91_adc: remove platform data and move defs in
> driver file'
>
> Changelog v1 -> v2:
> -
> https://lore.kernel.org/linux-iio/CA+U=dspd11n-pxxnny_5csznp50irr7h16zxtcxo8fk+v48...@mail.gmail.com/T/#m7c0efef4dc623776fe8bafdb5f734b0eaca50f82
> - for patch 'iio: adc: at91_adc: use of_device_get_match_data() helper'
> changed description; it's just tidy-up patch, not a fix
> - added 2 more patches:
> - iio: adc: at91_adc: add Kconfig dependency on the OF symbol
> - iio: adc: at91_adc: remove of_match_ptr() usage
>
> Alexandru Ardelean (4):
> iio: adc: at91_adc: use of_device_get_match_data() helper
> iio: adc: at91_adc: const-ify some driver data
> iio: adc: at91_adc: add Kconfig dep on the OF symbol and remove
> of_match_ptr()
> iio: adc: at91_adc: remove platform data and move defs in driver file
>
> drivers/iio/adc/Kconfig| 2 +-
> drivers/iio/adc/at91_adc.c | 73 ++
> include/linux/platform_data/at91_adc.h | 49 -
> 3 files changed, 28 insertions(+), 96 deletions(-)
> delete mode 100644 include/linux/platform_data/at91_adc.h
>
Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn
Hi Mauro,
On Fri, Oct 9, 2020 at 2:37 PM Mauro Carvalho Chehab
wrote:
>
> Em Fri, 9 Oct 2020 09:21:11 -0300
> Jason Gunthorpe escreveu:
>
> > On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote:
> > > Hi,
> > >
> > > Em Fri, 9 Oct 2020 09:59:26 +0200
> > > Daniel Vetter escreveu:
> > >
> > > > Way back it was a reasonable assumptions that iomem mappings never
> > > > change the pfn range they point at. But this has changed:
> > > >
> > > > - gpu drivers dynamically manage their memory nowadays, invalidating
> > > > ptes with unmap_mapping_range when buffers get moved
> > > >
> > > > - contiguous dma allocations have moved from dedicated carvetouts to
> > > > cma regions. This means if we miss the unmap the pfn might contain
> > > > pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
> > > >
> > > > - even /dev/mem now invalidates mappings when the kernel requests that
> > > > iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
> > > > ("/dev/mem: Revoke mappings when a driver claims the region")
> > > >
> > > > Accessing pfns obtained from ptes without holding all the locks is
> > > > therefore no longer a good idea.
> > > >
> > > > Unfortunately there's some users where this is not fixable (like v4l
> > > > userptr of iomem mappings) or involves a pile of work (vfio type1
> > > > iommu). For now annotate these as unsafe and splat appropriately.
> > > >
> > > > This patch adds an unsafe_follow_pfn, which later patches will then
> > > > roll out to all appropriate places.
> > >
> > > NACK, as this breaks an existing userspace API on media.
> >
> > It doesn't break it. You get a big warning the thing is broken and it
> > keeps working.
> >
> > We can't leave such a huge security hole open - it impacts other
> > subsystems, distros need to be able to run in a secure mode.
>
> Well, if distros disable it, then apps will break.
>
Do we have any information on userspace that actually needs this functionality?
Note that we're _not_ talking here about the complete USERPTR
functionality, but rather just the very corner case of carveout memory
not backed by struct pages.
Given that the current in-tree ways of reserving carveout memory, such
as shared-dma-pool, actually give memory backed by struct pages, do we
even have a source of such legacy memory in the kernel today?
I think that given that this is a very niche functionality, we could
have it disabled by default for security reasons and if someone
_really_ (i.e. there is no replacement) needs it, they probably need
to use a custom kernel build anyway for their exotic hardware setup
(with PFN-backed carveout memory), so they can enable it.
> > > While I agree that using the userptr on media is something that
> > > new drivers may not support, as DMABUF is a better way of
> > > handling it, changing this for existing ones is a big no,
> > > as it may break usersapace.
> >
> > media community needs to work to fix this, not pretend it is OK to
> > keep going as-is.
>
> > Dealing with security issues is the one case where an uABI break might
> > be acceptable.
> >
> > If you want to NAK it then you need to come up with the work to do
> > something here correctly that will support the old drivers without the
> > kernel taint.
> >
> > Unfortunately making things uncomfortable for the subsystem is the big
> > hammer the core kernel needs to use to actually get this security work
> > done by those responsible.
>
>
> I'm not pretending that this is ok. Just pointing that the approach
> taken is NOT OK.
>
> I'm not a mm/ expert, but, from what I understood from Daniel's patch
> description is that this is unsafe *only if* __GFP_MOVABLE is used.
>
> Well, no drivers inside the media subsystem uses such flag, although
> they may rely on some infrastructure that could be using it behind
> the bars.
>
> If this is the case, the proper fix seems to have a GFP_NOT_MOVABLE
> flag that it would be denying the core mm code to set __GFP_MOVABLE.
>
> Please let address the issue on this way, instead of broken an
> userspace API that it is there since 1991.
Note that USERPTR as a whole generally has been considered deprecated
in V4L2 for many years and people have been actively discouraged to
use it. And, still, we're just talking here about the very rare corner
case, not the whole USERPTR API.
Best regards,
Tomasz
Re: [PATCH] net: usb: rtl8150: don't incorrectly assign random MAC addresses
On Sun, 11 Oct 2020 00:14:05 +0530 Anant Thazhemadam wrote: > Ah, my apologies. You're right. It doesn't look like those helpers have made > their way into the networking tree yet. > > (This gets mentioned here as well, > https://www.mail-archive.com/netdev@vger.kernel.org/msg357843.html) > > The commit ID pointed to by the fixes tag is correct. > The change introduced by said commit looks right, but is logically incorrect. > > get_registers() directly returns the return value of usb_control_msg_recv(), > and usb_control_msg_recv() returns 0 on success and negative error number > otherwise. > > (You can find more about the new helpers here > > https://lore.kernel.org/alsa-devel/20200914153756.3412156-1-gre...@linuxfoundation.org/ > ) > > The commit ID mentioned introduces a change that is supposed to copy over > the ethernet only when get_registers() succeeds, i.e., a complete read occurs, > and generate and set a random ethernet address otherwise (reading the > commit message should give some more insight). > > The condition that checks if get_registers() succeeds (as specified in > f45a4248ea4c) > was, > ret == sizeof(node_id) > where ret is the return value of get_registers(). > > However, ret will never equal sizeof(node_id), since ret can only be equal to > 0 > or a negative number. > > Thus, even in case where get_registers() succeeds, a randomly generated MAC > address would get copied over, instead of copying the appropriate ethernet > address, which is logically incorrect and not optimal. > > Hence, we need to modify this to check if (ret == 0), and copy over the > correct > ethernet address in that case, instead of randomly generating one and > assigning > that. I see... so we ended up with your fix applied to net, and Petko's rework applied to the usb/usb-next tree. What you're actually fixing is the improper resolution of the resulting conflict in linux-next! CCing Stephen and linux-next.
[PATCH 2/2] fs: ext4: Modify inode-test.c to use KUnit parameterized testing feature
Modifies fs/ext4/inode-test.c to use the parameterized testing
feature of KUnit.
Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
---
fs/ext4/inode-test.c | 64 +---
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git a/fs/ext4/inode-test.c b/fs/ext4/inode-test.c
index d62d802c9c12..691ef0a4ffe1 100644
--- a/fs/ext4/inode-test.c
+++ b/fs/ext4/inode-test.c
@@ -72,6 +72,8 @@
#define UPPER_BOUND_NONNEG_EXTRA_BITS_1_CASE\
"2446-05-10 Upper bound of 32bit >=0 timestamp. All extra sec bits on"
+#define NUMBER_OF_TESTCASES 16
+
struct timestamp_expectation {
const char *test_case_name;
struct timespec64 expected;
@@ -101,7 +103,36 @@ static time64_t get_32bit_time(const struct
timestamp_expectation * const test)
*/
static void inode_test_xtimestamp_decoding(struct kunit *test)
{
- const struct timestamp_expectation test_data[] = {
+ struct timespec64 timestamp;
+
+ struct timestamp_expectation *test_data =
+ (struct timestamp_expectation *)get_test_case_parameters(test);
+
+ timestamp.tv_sec = get_32bit_time(test_data);
+ ext4_decode_extra_time(,
+ cpu_to_le32(test_data->extra_bits));
+
+ KUNIT_EXPECT_EQ_MSG(test,
+ test_data->expected.tv_sec,
+ timestamp.tv_sec,
+ CASE_NAME_FORMAT,
+ test_data->test_case_name,
+ test_data->msb_set,
+ test_data->lower_bound,
+ test_data->extra_bits);
+ KUNIT_EXPECT_EQ_MSG(test,
+ test_data->expected.tv_nsec,
+ timestamp.tv_nsec,
+ CASE_NAME_FORMAT,
+ test_data->test_case_name,
+ test_data->msb_set,
+ test_data->lower_bound,
+ test_data->extra_bits);
+}
+
+struct timestamp_expectation *get_test_parameters(void)
+{
+ static struct timestamp_expectation test_data[] = {
{
.test_case_name = LOWER_BOUND_NEG_NO_EXTRA_BITS_CASE,
.msb_set = true,
@@ -231,36 +262,13 @@ static void inode_test_xtimestamp_decoding(struct kunit
*test)
.expected = {.tv_sec = 0x37fffLL, .tv_nsec = 0L},
}
};
-
- struct timespec64 timestamp;
- int i;
-
- for (i = 0; i < ARRAY_SIZE(test_data); ++i) {
- timestamp.tv_sec = get_32bit_time(_data[i]);
- ext4_decode_extra_time(,
- cpu_to_le32(test_data[i].extra_bits));
-
- KUNIT_EXPECT_EQ_MSG(test,
- test_data[i].expected.tv_sec,
- timestamp.tv_sec,
- CASE_NAME_FORMAT,
- test_data[i].test_case_name,
- test_data[i].msb_set,
- test_data[i].lower_bound,
- test_data[i].extra_bits);
- KUNIT_EXPECT_EQ_MSG(test,
- test_data[i].expected.tv_nsec,
- timestamp.tv_nsec,
- CASE_NAME_FORMAT,
- test_data[i].test_case_name,
- test_data[i].msb_set,
- test_data[i].lower_bound,
- test_data[i].extra_bits);
- }
+ return test_data;
}
static struct kunit_case ext4_inode_test_cases[] = {
- KUNIT_CASE(inode_test_xtimestamp_decoding),
+ KUNIT_CASE_PARAM(inode_test_xtimestamp_decoding,
+ get_test_parameters, NUMBER_OF_TESTCASES,
+ sizeof(struct timestamp_expectation)),
{}
};
--
2.25.1
Re: [PATCH v3] iio: adc: exynos: do not rely on 'users' counter in ISR
On Tue, 6 Oct 2020 14:55:09 -0700
dmitry.torok...@gmail.com wrote:
> The order in which 'users' counter is decremented vs calling drivers'
> close() method is implementation specific, and we should not rely on
> it. Let's introduce driver private flag and use it to signal ISR
> to exit when device is being closed.
>
> This has a side-effect of fixing issue of accessing inut->users
> outside of input->mutex protection.
>
> Reported-by: Andrzej Pietrasiewicz
> Acked-by: Krzysztof Kozlowski
> Reviewed-by: Michał Mirosław
> Signed-off-by: Dmitry Torokhov
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to work their magic.
Given this doesn't have a fixes tag etc I'm assuming it isn't
high priority etc. Let me know if it is!
Thanks,
Jonathan
> ---
>
> v3: fixed typo in exynos_adc_ts_close() per Michał Mirosław
> v2: switched from ordinary read/write to READ_ONCE/WRITE_ONCE per Michał
> Mirosław
>
> drivers/iio/adc/exynos_adc.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index 22131a677445..908df4b9b93c 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -7,6 +7,7 @@
> * Copyright (C) 2013 Naveen Krishna Chatradhi
> */
>
> +#include
> #include
> #include
> #include
> @@ -135,6 +136,8 @@ struct exynos_adc {
> u32 value;
> unsigned intversion;
>
> + boolts_enabled;
> +
> boolread_ts;
> u32 ts_x;
> u32 ts_y;
> @@ -633,7 +636,7 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
> bool pressed;
> int ret;
>
> - while (info->input->users) {
> + while (READ_ONCE(info->ts_enabled)) {
> ret = exynos_read_s3c64xx_ts(dev, , );
> if (ret == -ETIMEDOUT)
> break;
> @@ -712,6 +715,7 @@ static int exynos_adc_ts_open(struct input_dev *dev)
> {
> struct exynos_adc *info = input_get_drvdata(dev);
>
> + WRITE_ONCE(info->ts_enabled, true);
> enable_irq(info->tsirq);
>
> return 0;
> @@ -721,6 +725,7 @@ static void exynos_adc_ts_close(struct input_dev *dev)
> {
> struct exynos_adc *info = input_get_drvdata(dev);
>
> + WRITE_ONCE(info->ts_enabled, false);
> disable_irq(info->tsirq);
> }
>
Re: [PATCH v6 01/10] vfio/fsl-mc: Add VFIO framework skeleton for fsl-mc devices
Hi Diana, On 10/5/20 7:36 PM, Diana Craciun wrote: > From: Bharat Bhushan > > DPAA2 (Data Path Acceleration Architecture) consists in > mechanisms for processing Ethernet packets, queue management, > accelerators, etc. > > The Management Complex (mc) is a hardware entity that manages the DPAA2 > hardware resources. It provides an object-based abstraction for software > drivers to use the DPAA2 hardware. The MC mediates operations such as > create, discover, destroy of DPAA2 objects. > The MC provides memory-mapped I/O command interfaces (MC portals) which > DPAA2 software drivers use to operate on DPAA2 objects. > > A DPRC is a container object that holds other types of DPAA2 objects. > Each object in the DPRC is a Linux device and bound to a driver. > The MC-bus driver is a platform driver (different from PCI or platform > bus). The DPRC driver does runtime management of a bus instance. It > performs the initial scan of the DPRC and handles changes in the DPRC > configuration (adding/removing objects). > > All objects inside a container share the same hardware isolation > context, meaning that only an entire DPRC can be assigned to > a virtual machine. > When a container is assigned to a virtual machine, all the objects > within that container are assigned to that virtual machine. > The DPRC container assigned to the virtual machine is not allowed > to change contents (add/remove objects) by the guest. The restriction > is set by the host and enforced by the mc hardware. > > The DPAA2 objects can be directly assigned to the guest. However > the MC portals (the memory mapped command interface to the MC) need > to be emulated because there are commands that configure the > interrupts and the isolation IDs which are virtual in the guest. > > Example: > echo vfio-fsl-mc > /sys/bus/fsl-mc/devices/dprc.2/driver_override > echo dprc.2 > /sys/bus/fsl-mc/drivers/vfio-fsl-mc/bind > > The dprc.2 is bound to the VFIO driver and all the objects within > dprc.2 are going to be bound to the VFIO driver. > > This patch adds the infrastructure for VFIO support for fsl-mc > devices. Subsequent patches will add support for binding and secure > assigning these devices using VFIO. > > More details about the DPAA2 objects can be found here: > Documentation/networking/device_drivers/freescale/dpaa2/overview.rst > > Signed-off-by: Bharat Bhushan > Signed-off-by: Diana Craciun Reviewed-by: Eric Auger Thanks Eric > --- > MAINTAINERS | 6 + > drivers/vfio/Kconfig | 1 + > drivers/vfio/Makefile | 1 + > drivers/vfio/fsl-mc/Kconfig | 9 ++ > drivers/vfio/fsl-mc/Makefile | 4 + > drivers/vfio/fsl-mc/vfio_fsl_mc.c | 157 ++ > drivers/vfio/fsl-mc/vfio_fsl_mc_private.h | 14 ++ > include/uapi/linux/vfio.h | 1 + > 8 files changed, 193 insertions(+) > create mode 100644 drivers/vfio/fsl-mc/Kconfig > create mode 100644 drivers/vfio/fsl-mc/Makefile > create mode 100644 drivers/vfio/fsl-mc/vfio_fsl_mc.c > create mode 100644 drivers/vfio/fsl-mc/vfio_fsl_mc_private.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 33b27e62ce19..1046f4065ac1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -18258,6 +18258,12 @@ F: drivers/vfio/ > F: include/linux/vfio.h > F: include/uapi/linux/vfio.h > > +VFIO FSL-MC DRIVER > +M: Diana Craciun > +L: k...@vger.kernel.org > +S: Maintained > +F: drivers/vfio/fsl-mc/ > + > VFIO MEDIATED DEVICE DRIVERS > M: Kirti Wankhede > L: k...@vger.kernel.org > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig > index fd17db9b432f..5533df91b257 100644 > --- a/drivers/vfio/Kconfig > +++ b/drivers/vfio/Kconfig > @@ -47,4 +47,5 @@ menuconfig VFIO_NOIOMMU > source "drivers/vfio/pci/Kconfig" > source "drivers/vfio/platform/Kconfig" > source "drivers/vfio/mdev/Kconfig" > +source "drivers/vfio/fsl-mc/Kconfig" > source "virt/lib/Kconfig" > diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile > index de67c4725cce..fee73f3d9480 100644 > --- a/drivers/vfio/Makefile > +++ b/drivers/vfio/Makefile > @@ -9,3 +9,4 @@ obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o > obj-$(CONFIG_VFIO_PCI) += pci/ > obj-$(CONFIG_VFIO_PLATFORM) += platform/ > obj-$(CONFIG_VFIO_MDEV) += mdev/ > +obj-$(CONFIG_VFIO_FSL_MC) += fsl-mc/ > diff --git a/drivers/vfio/fsl-mc/Kconfig b/drivers/vfio/fsl-mc/Kconfig > new file mode 100644 > index ..b1a527d6b6f2 > --- /dev/null > +++ b/drivers/vfio/fsl-mc/Kconfig > @@ -0,0 +1,9 @@ > +config VFIO_FSL_MC > + tristate "VFIO support for QorIQ DPAA2 fsl-mc bus devices" > + depends on VFIO && FSL_MC_BUS && EVENTFD > + help > + Driver to enable support for the VFIO QorIQ DPAA2 fsl-mc > + (Management Complex) devices. This is required to passthrough > + fsl-mc bus devices using the VFIO framework. > + > + If you don't know what to do here, say N. > diff
Re: [PATCH v3 0/6] iio: sx9310: Support setting various settings
On Tue, 6 Oct 2020 18:17:29 -0700 Stephen Boyd wrote: > I need to configure various settings such as thresholds, gain factors, > etc. on this device. Some settings matter at boot, while others can wait > for userspace to configure things. This patch series adds support to > set these various bits in the registers of this device. Looks good to me. I've applied them to the togreg branch of iio.git and pushed out as testing for the autobuilders to see if they can find any issues. Note that I can still add tags etc for now if anyone wants to send any! Thanks, Jonathan > > Changes from v2 > (https://lore.kernel.org/r/20200930075728.2410327-1-swb...@chromium.org) > - Rolled in a fix from Gwendal on last patch to simplify if-else logic > - Fixed binding and picked up Rob's reviewed-by tag > > Changes from v1 > (https://lore.kernel.org/r/20200903221828.3657250-1-swb...@chromium.org) > - A bunch more patches for userspace settings > - Removed body thresholds as they're probably not used > - Removed compensate common as it probably doesn't matter > - Moved thresholds, gain factor, hysteresis, debounce to userspace > > Stephen Boyd (6): > iio: sx9310: Support hardware gain factor > iio: sx9310: Support setting proximity thresholds > iio: sx9310: Support setting hysteresis values > iio: sx9310: Support setting debounce values > dt-bindings: iio: sx9310: Add various settings as DT properties > iio: sx9310: Set various settings from DT > > .../iio/proximity/semtech,sx9310.yaml | 63 +++ > drivers/iio/proximity/sx9310.c| 508 +- > 2 files changed, 565 insertions(+), 6 deletions(-) > > Cc: Daniel Campello > Cc: Lars-Peter Clausen > Cc: Peter Meerwald-Stadler > Cc: Douglas Anderson > Cc: Gwendal Grignou > Cc: Evan Green > Cc: Rob Herring > Cc: > > base-commit: 1bebdcb928eba880f3a119bacb8149216206958a
Re: [PATCH] checkpatch: Check for .byte-spelled insn opcodes documentation on x86
On Sat, 2020-10-10 at 12:54 +0200, Borislav Petkov wrote:
> > checkpatch uses only a single line output only before $herecurr
> > Output line length doesn't matter.
[]
> WARNING: Please document which binutils version supports these .byte-spelled
> insn opcodes by adding "binutils version " in a comment above
> them.
> #90: FILE: arch/x86/include/asm/special_insns.h:254:
> + asm volatile(".byte 0x66, 0x0f, 0x38, 0xf8, 0x02"
>
>
> is easier readable than this:
>
> WARNING: Please document which binutils version supports these
> .byte-spelledinsn opcodes by adding "binutils version " in a comment
> above them.
> #90: FILE: arch/x86/include/asm/special_insns.h:254:
> + asm volatile(".byte 0x66, 0x0f, 0x38, 0xf8, 0x02"
Readability is a consideration but it still must be a single line.
using --terse requires single line error output
Perhaps:
if ($comment !~ /\bbinutils version [0-9.]+/ms) {
WARN("MISSING_BINUTILS_VERSION",
"Please add a comment for .byte-spelled
insn opcodes with \"binutils version \"\n" .
$herecurr);
Re: [PATCH] x86/boot/64: Initialize 5-level paging variables earlier
On Sat, Oct 10, 2020 at 03:11:10PM -0400, Arvind Sankar wrote:
> Commit
> ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")
> started using a new set of pagetables even without KASLR.
>
> After that commit, initialize_identity_maps() is called before the
> 5-level paging variables are setup in choose_random_location(), which
> will not work if 5-level paging is actually enabled.
Note that I don't have hardware that supports 5-level paging, so this
is not actually tested with 5-level, but based on code inspection, it
shouldn't work.
>
> Fix this by moving the initialization of __pgtable_l5_enabled,
> pgdir_shift and ptrs_per_p4d into cleanup_trampoline(), which is called
> immediately after the finalization of whether the kernel is executing
> with 4- or 5-level paging. This will be earlier than anything that might
> require those variables, and keeps the 4- vs 5-level paging code all in
> one place.
>
> Signed-off-by: Arvind Sankar
> ---
> arch/x86/boot/compressed/ident_map_64.c | 6 --
> arch/x86/boot/compressed/kaslr.c| 8
> arch/x86/boot/compressed/pgtable_64.c | 16
> 3 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/ident_map_64.c
> b/arch/x86/boot/compressed/ident_map_64.c
> index a3613857c532..505d6299b76e 100644
> --- a/arch/x86/boot/compressed/ident_map_64.c
> +++ b/arch/x86/boot/compressed/ident_map_64.c
> @@ -34,12 +34,6 @@
> #define __PAGE_OFFSET __PAGE_OFFSET_BASE
> #include "../../mm/ident_map.c"
>
> -#ifdef CONFIG_X86_5LEVEL
> -unsigned int __pgtable_l5_enabled;
> -unsigned int pgdir_shift = 39;
> -unsigned int ptrs_per_p4d = 1;
> -#endif
> -
> /* Used by PAGE_KERN* macros: */
> pteval_t __default_kernel_pte_mask __read_mostly = ~0;
>
> diff --git a/arch/x86/boot/compressed/kaslr.c
> b/arch/x86/boot/compressed/kaslr.c
> index 489fabc051d7..9eabd8bc7673 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -835,14 +835,6 @@ void choose_random_location(unsigned long input,
> return;
> }
>
> -#ifdef CONFIG_X86_5LEVEL
> - if (__read_cr4() & X86_CR4_LA57) {
> - __pgtable_l5_enabled = 1;
> - pgdir_shift = 48;
> - ptrs_per_p4d = 512;
> - }
> -#endif
> -
> boot_params->hdr.loadflags |= KASLR_FLAG;
>
> if (IS_ENABLED(CONFIG_X86_32))
> diff --git a/arch/x86/boot/compressed/pgtable_64.c
> b/arch/x86/boot/compressed/pgtable_64.c
> index 46d761f7faa6..0976c2d2ab2f 100644
> --- a/arch/x86/boot/compressed/pgtable_64.c
> +++ b/arch/x86/boot/compressed/pgtable_64.c
> @@ -9,6 +9,13 @@
> #define BIOS_START_MIN 0x2U/* 128K, less than this
> is insane */
> #define BIOS_START_MAX 0x9f000U/* 640K, absolute
> maximum */
>
> +#ifdef CONFIG_X86_5LEVEL
> +/* __pgtable_l5_enabled needs to be in .data to avoid being cleared along
> with .bss */
> +unsigned int __section(.data) __pgtable_l5_enabled;
> +unsigned int __section(.data) pgdir_shift = 39;
> +unsigned int __section(.data) ptrs_per_p4d = 1;
> +#endif
> +
> struct paging_config {
> unsigned long trampoline_start;
> unsigned long l5_required;
> @@ -195,4 +202,13 @@ void cleanup_trampoline(void *pgtable)
>
> /* Restore trampoline memory */
> memcpy(trampoline_32bit, trampoline_save, TRAMPOLINE_32BIT_SIZE);
> +
> + /* Initialize variables for 5-level paging */
> +#ifdef CONFIG_X86_5LEVEL
> + if (__read_cr4() & X86_CR4_LA57) {
> + __pgtable_l5_enabled = 1;
> + pgdir_shift = 48;
> + ptrs_per_p4d = 512;
> + }
> +#endif
> }
> --
> 2.26.2
>
[PATCH 1/1] tracing/boot: Add ftrace.instance.*.alloc_snapshot option
Add ftrace.instance.*.alloc_snapshot option.
This option has been described in Documentation/trace/boottime-trace.rst
but not implemented yet.
ftrace.[instance.INSTANCE.]alloc_snapshot
Allocate snapshot buffer.
The difference from kernel.alloc_snapshot is that the kernel.alloc_snapshot
will allocate the buffer only for the main instance, but this can allocate
buffer for any new instances.
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace_boot.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/trace/trace_boot.c b/kernel/trace/trace_boot.c
index 754e3cf2df3a..c22a152ef0b4 100644
--- a/kernel/trace/trace_boot.c
+++ b/kernel/trace/trace_boot.c
@@ -284,6 +284,12 @@ trace_boot_enable_tracer(struct trace_array *tr, struct
xbc_node *node)
if (tracing_set_tracer(tr, p) < 0)
pr_err("Failed to set given tracer: %s\n", p);
}
+
+ /* Since tracer can free snapshot buffer, allocate snapshot here.*/
+ if (xbc_node_find_value(node, "alloc_snapshot", NULL)) {
+ if (tracing_alloc_snapshot_instance(tr) < 0)
+ pr_err("Failed to allocate snapshot buffer\n");
+ }
}
static void __init
[PATCH 0/1] tracing/boot: Add alloc_snapshot for instance option
Hi,
Here is a patch to add ftrace[.instance.INSTANCE].alloc_snapshot option
to allocate snapshot buffer for specific isntance. Actually, this has
been described in Documentation/trace/boottime-trace.rst but I forgot
to implement it. (Maybe I confused it with kernel.alloc_snapshot)
Anyway, it is better to have this option with currnet ftrace implementation,
because if user sets ftrace.instance.X.event.*.*.actions = "snapshot" and
ftrace.instance.X.tracer at same bootconfig, the snapshot buffer always
removed (even if the tracer is not a max-tracer).
This seems buggy, but I'm not sure the reason why.
So if someone wants to use snapshot event action with e.g. function tracer,
they must use this option. For example,
ftrace.instance.foo {
tracer = function
event.signal.signal_deliver {
enable
actions = "snapshot if sig = 7"
}
alloc_snapshot
}
Steve and Tom, would you know why tracing_set_tracer() removes
snapshot buffer even if the tracer is not a max-tracer?
int tracing_set_tracer(struct trace_array *tr, const char *buf)
{
...
#ifdef CONFIG_TRACER_MAX_TRACE
had_max_tr = tr->allocated_snapshot;
if (had_max_tr && !t->use_max_tr) {
/*
* We need to make sure that the update_max_tr sees that
* current_trace changed to nop_trace to keep it from
* swapping the buffers after we resize it.
* The update_max_tr is called from interrupts disabled
* so a synchronized_sched() is sufficient.
*/
synchronize_rcu();
free_snapshot(tr);
}
#endif
}
It seems had_max_tr is true even if the previous tracer is nop and
snapshot buffer was traced by snapshot trigger action.
This actually causes a problem except for the boot time tracing,
for example,
1) boot kernel with nop tracer
2) add snapshot trigger action to an event
(snapshot buffer is allocated here)
3) set function tracer to current tracer
(snapshot buffer is freed)
4) run the tracer
-> the event trigger can not take a snapshot.
Thank you,
---
Masami Hiramatsu (1):
tracing/boot: Add ftrace.instance.*.alloc_snapshot option
kernel/trace/trace_boot.c |6 ++
1 file changed, 6 insertions(+)
--
Masami Hiramatsu (Linaro)
Re: [PATCH] checkpatch: Check for .byte-spelled insn opcodes documentation on x86
On Sat, Oct 10, 2020 at 08:27:20AM -0700, Joe Perches wrote:
> Then this could use:
>
> /"\s*\.byte\s+(?:0x[0-9a-fA-F]{1,2}\s*,\s*){2,4}/
Yes, this is getting close.
I've tweaked it a bit to:
'/\s*\.byte\s+(?:0x[0-9a-f]{1,2}[\s,]*){2,}/i'
which assumes at least 2 opcode bytes; upper limit can be more than 4.
It still has some false positives in crypto but I'd say that's good
enough. I'll play more with it later.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Re: [kbuild-all] Re: arceb-elf-ld: include/linux/leds.h:193: undefined reference to `devm_led_classdev_register_ext'
On 10/10/20 12:13 AM, Rong Chen wrote: > > > On 10/10/20 11:49 AM, Randy Dunlap wrote: >> On 10/9/20 8:19 PM, Rong Chen wrote: >>> >>> On 10/8/20 3:15 PM, Pavel Machek wrote: Hi! > tree: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > head: c85fb28b6f999db9928b841f63f1beeb3074eeca > commit: 92a81562e695628086acb92f95090ab09d9b9ec0 leds: lp55xx: Add > multicolor framework support to lp55xx > date: 3 months ago > config: arc-randconfig-r035-20201008 (attached as .config) > compiler: arceb-elf-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=92a81562e695628086acb92f95090ab09d9b9ec0 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 92a81562e695628086acb92f95090ab09d9b9ec0 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=arc > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot Hi robot. Do you have human around to talk to? > All errors (new ones prefixed by >>): > > arceb-elf-ld: lib/stackdepot.o: in function `filter_irq_stacks': > lib/stackdepot.c:331: undefined reference to `__irqentry_text_start' > arceb-elf-ld: lib/stackdepot.c:331: undefined reference to > `__irqentry_text_start' > arceb-elf-ld: lib/stackdepot.o: in function `in_irqentry_text': > lib/stackdepot.c:323: undefined reference to `__irqentry_text_end' > arceb-elf-ld: lib/stackdepot.c:323: undefined reference to > `__irqentry_text_end' > arceb-elf-ld: lib/stackdepot.c:324: undefined reference to > `__softirqentry_text_start' > arceb-elf-ld: lib/stackdepot.c:324: undefined reference to > `__softirqentry_text_start' > arceb-elf-ld: lib/stackdepot.c:325: undefined reference to > `__softirqentry_text_end' > arceb-elf-ld: lib/stackdepot.c:325: undefined reference to What is going on here? Did you just start testing arc? The commit is... really old. >>> Hi Pavel, >>> >>> Only this error "arceb-elf-ld: include/linux/leds.h:193: undefined >>> reference to `devm_led_classdev_register_ext'" was found in this commit, >>> other errors are for reference only, and the test config is a rand config, >>> so it's discovered by chance. >> Hi, >> Just for the record, I could not reproduce the build error >> with the config file that was provided. >> > > Hi Randy, > > I can reproduce it with the above reproduce steps: > > ➜ linux git:(92a81562e695) ✗ make > CROSS_COMPILE=/home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf- > ARCH=arc > CALL scripts/checksyscalls.sh > CALL scripts/atomic/check-atomics.sh > CHK include/generated/compile.h > GEN .version > CHK include/generated/compile.h > UPD include/generated/compile.h > CC init/version.o > AR init/built-in.a > LD vmlinux.o > MODPOST vmlinux.symvers > MODINFO modules.builtin.modinfo > GEN modules.builtin > LD .tmp_vmlinux.kallsyms1 > /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: lib/stackdepot.o: > in function `filter_irq_stacks': > /home/nfs/linux/lib/stackdepot.c:331: undefined reference to > `__irqentry_text_start' > /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: > /home/nfs/linux/lib/stackdepot.c:331: undefined reference to > `__irqentry_text_start' > /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: lib/stackdepot.o: > in function `in_irqentry_text': > /home/nfs/linux/lib/stackdepot.c:323: undefined reference to > `__irqentry_text_end' > /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: > /home/nfs/linux/lib/stackdepot.c:323: undefined reference to > `__irqentry_text_end' > /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: > /home/nfs/linux/lib/stackdepot.c:324: undefined reference to > `__softirqentry_text_start' > /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: > /home/nfs/linux/lib/stackdepot.c:324: undefined reference to > `__softirqentry_text_start' > /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: > /home/nfs/linux/lib/stackdepot.c:325: undefined reference to > `__softirqentry_text_end' > /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: > /home/nfs/linux/lib/stackdepot.c:325: undefined reference to > `__softirqentry_text_end' > /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: >
Re: [PATCH v6 02/10] vfio/fsl-mc: Scan DPRC objects on vfio-fsl-mc driver bind
Hi Diana,
On 10/5/20 7:36 PM, Diana Craciun wrote:
> The DPRC (Data Path Resource Container) device is a bus device and has
> child devices attached to it. When the vfio-fsl-mc driver is probed
> the DPRC is scanned and the child devices discovered and initialized.
>
> Signed-off-by: Bharat Bhushan
> Signed-off-by: Diana Craciun
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> drivers/vfio/fsl-mc/vfio_fsl_mc.c | 91 +++
> drivers/vfio/fsl-mc/vfio_fsl_mc_private.h | 1 +
> 2 files changed, 92 insertions(+)
>
> diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> index a7a483a1e90b..594760203268 100644
> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> @@ -15,6 +15,8 @@
>
> #include "vfio_fsl_mc_private.h"
>
> +static struct fsl_mc_driver vfio_fsl_mc_driver;
> +
> static int vfio_fsl_mc_open(void *device_data)
> {
> if (!try_module_get(THIS_MODULE))
> @@ -84,6 +86,80 @@ static const struct vfio_device_ops vfio_fsl_mc_ops = {
> .mmap = vfio_fsl_mc_mmap,
> };
>
> +static int vfio_fsl_mc_bus_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct vfio_fsl_mc_device *vdev = container_of(nb,
> + struct vfio_fsl_mc_device, nb);
> + struct device *dev = data;
> + struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
> + struct fsl_mc_device *mc_cont = to_fsl_mc_device(mc_dev->dev.parent);
> +
> + if (action == BUS_NOTIFY_ADD_DEVICE &&
> + vdev->mc_dev == mc_cont) {
> + mc_dev->driver_override = kasprintf(GFP_KERNEL, "%s",
> + vfio_fsl_mc_ops.name);
> + if (!mc_dev->driver_override)
> + dev_warn(dev, "VFIO_FSL_MC: Setting driver override for
> device in dprc %s failed\n",
> + dev_name(_cont->dev));
> + else
> + dev_info(dev, "VFIO_FSL_MC: Setting driver override for
> device in dprc %s\n",
> + dev_name(_cont->dev));
> + } else if (action == BUS_NOTIFY_BOUND_DRIVER &&
> + vdev->mc_dev == mc_cont) {
> + struct fsl_mc_driver *mc_drv = to_fsl_mc_driver(dev->driver);
> +
> + if (mc_drv && mc_drv != _fsl_mc_driver)
> + dev_warn(dev, "VFIO_FSL_MC: Object %s bound to driver
> %s while DPRC bound to vfio-fsl-mc\n",
> + dev_name(dev), mc_drv->driver.name);
> + }
> +
> + return 0;
> +}
> +
> +static int vfio_fsl_mc_init_device(struct vfio_fsl_mc_device *vdev)
> +{
> + struct fsl_mc_device *mc_dev = vdev->mc_dev;
> + int ret;
> +
> + /* Non-dprc devices share mc_io from parent */
> + if (!is_fsl_mc_bus_dprc(mc_dev)) {
> + struct fsl_mc_device *mc_cont =
> to_fsl_mc_device(mc_dev->dev.parent);
> +
> + mc_dev->mc_io = mc_cont->mc_io;
> + return 0;
> + }
> +
> + vdev->nb.notifier_call = vfio_fsl_mc_bus_notifier;
> + ret = bus_register_notifier(_mc_bus_type, >nb);
> + if (ret)
> + return ret;
> +
> + /* open DPRC, allocate a MC portal */
> + ret = dprc_setup(mc_dev);
> + if (ret) {
> + dev_err(_dev->dev, "VFIO_FSL_MC: Failed to setup DPRC
> (%d)\n", ret);
> + goto out_nc_unreg;
> + }
> +
> + ret = dprc_scan_container(mc_dev, false);
> + if (ret) {
> + dev_err(_dev->dev, "VFIO_FSL_MC: Container scanning failed
> (%d)\n", ret);
> + goto out_dprc_cleanup;
> + }
> +
> + return 0;
> +
> +out_dprc_cleanup:
> + dprc_remove_devices(mc_dev, NULL, 0);
> + dprc_cleanup(mc_dev);
> +out_nc_unreg:
> + bus_unregister_notifier(_mc_bus_type, >nb);
> + vdev->nb.notifier_call = NULL;
> +
> + return ret;
> +}
> +
> static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev)
> {
> struct iommu_group *group;
> @@ -110,8 +186,15 @@ static int vfio_fsl_mc_probe(struct fsl_mc_device
> *mc_dev)
> dev_err(dev, "VFIO_FSL_MC: Failed to add to vfio group\n");
> goto out_group_put;
> }
> +
> + ret = vfio_fsl_mc_init_device(vdev);
> + if (ret)
> + goto out_group_dev;
> +
> return 0;
>
> +out_group_dev:
> + vfio_del_group_dev(dev);
> out_group_put:
> vfio_iommu_group_put(group, dev);
> return ret;
> @@ -126,6 +209,14 @@ static int vfio_fsl_mc_remove(struct fsl_mc_device
> *mc_dev)
> if (!vdev)
> return -EINVAL;
>
> + if (is_fsl_mc_bus_dprc(mc_dev)) {
> + dprc_remove_devices(mc_dev, NULL, 0);
> + dprc_cleanup(mc_dev);
> + }
> +
> + if (vdev->nb.notifier_call)
> + bus_unregister_notifier(_mc_bus_type, >nb);
> +
> vfio_iommu_group_put(mc_dev->dev.iommu_group, dev);
>
> return 0;
>
Re: [PATCH] coccinelle: api: kfree_sensitive: print memset position
On Fri, 9 Oct 2020, Denis Efremov wrote: > Print memset() call position in addition to the kfree() position to > ease issues identification. > > Signed-off-by: Denis Efremov Applied, thanks. julia > --- > scripts/coccinelle/api/kfree_sensitive.cocci | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/scripts/coccinelle/api/kfree_sensitive.cocci > b/scripts/coccinelle/api/kfree_sensitive.cocci > index e4a066a0b77d..8d980ebf3223 100644 > --- a/scripts/coccinelle/api/kfree_sensitive.cocci > +++ b/scripts/coccinelle/api/kfree_sensitive.cocci > @@ -85,14 +85,16 @@ type T; > > @script:python depends on report@ > p << r.p; > +m << r.m; > @@ > > -coccilib.report.print_report(p[0], > - "WARNING: opportunity for kfree_sensitive/kvfree_sensitive") > +msg = "WARNING opportunity for kfree_sensitive/kvfree_sensitive (memset at > line %s)" > +coccilib.report.print_report(p[0], msg % (m[0].line)) > > @script:python depends on org@ > p << r.p; > +m << r.m; > @@ > > -coccilib.org.print_todo(p[0], > - "WARNING: opportunity for kfree_sensitive/kvfree_sensitive") > +msg = "WARNING opportunity for kfree_sensitive/kvfree_sensitive (memset at > line %s)" > +coccilib.org.print_todo(p[0], msg % (m[0].line)) > -- > 2.26.2 > >
Re: [PATCH] net: stmmac: Don't call _irqoff() with hardirqs enabled
On Sat, 10 Oct 2020 15:08:15 +0200 Heiner Kallweit wrote: > On 09.10.2020 18:06, Heiner Kallweit wrote: > > On 09.10.2020 17:58, Jakub Kicinski wrote: > >> On Fri, 9 Oct 2020 16:54:06 +0200 Heiner Kallweit wrote: > >>> I'm thinking about a __napi_schedule version that disables hard irq's > >>> conditionally, based on variable force_irqthreads, exported by the irq > >>> subsystem. This would allow to behave correctly with threadirqs set, > >>> whilst not loosing the _irqoff benefit with threadirqs unset. > >>> Let me come up with a proposal. > >> > >> I think you'd need to make napi_schedule_irqoff() behave like that, > >> right? Are there any uses of napi_schedule_irqoff() that are disabling > >> irqs and not just running from an irq handler? > >> > > Right, the best approach depends on the answer to the latter question. > > I didn't check this yet, therefore I described the least intrusive approach. > > > > With some help from coccinelle I identified the following functions that > call napi_schedule_irqoff() or __napi_schedule_irqoff() and do not run > from an irq handler (at least not at the first glance). > > dpaa2_caam_fqdan_cb > qede_simd_fp_handler > mlx4_en_rx_irq > mlx4_en_tx_irq Don't know the others but FWIW the mlx4 ones run from an IRQ handler, AFAICT: static irqreturn_t mlx4_interrupt(int irq, void *dev_ptr) static irqreturn_t mlx4_msi_x_interrupt(int irq, void *eq_ptr) mlx4_eq_int() mlx4_cq_completion cq->comp() > qeth_qdio_poll > netvsc_channel_cb > napi_watchdog This one runs from a hrtimer, which I believe will be a hard irq context on anything but RT. I could be wrong.
[PATCH v3] lockdep: Allow tuning tracing capacity constants.
Since syzkaller continues various test cases until the kernel crashes, syzkaller tends to examine more locking dependencies than normal systems. As a result, syzbot is reporting that the fuzz testing was terminated due to hitting upper limits lockdep can track [1] [2] [3]. Peter Zijlstra does not want to allow tuning these limits via kernel config options, for such change discourages thinking. But currently we are not actionable, for lockdep does not report the culprit for hitting these limits [4]. Therefore, I propose this patch again, with a caveat that this patch is expected to be reverted after lockdep becomes capable of reporting the culprit, for I consider that "postpone fixing lock related problems in existing code" is less painful than "not detecting lock related problems introduced by new patches". [1] https://syzkaller.appspot.com/bug?id=3d97ba93fb3566000c1c59691ea427370d33ea1b [2] https://syzkaller.appspot.com/bug?id=381cb436fe60dc03d7fd2a092b46d7f09542a72a [3] https://syzkaller.appspot.com/bug?id=a588183ac34c1437fc0785e8f220e88282e5a29f [4] https://lkml.kernel.org/r/CACT4Y+agTiEF-1i9LbAgp-q_02oYF0kAPZGAAJ==-wx2xh7...@mail.gmail.com Reported-by: syzbot Reported-by: syzbot Reported-by: syzbot Signed-off-by: Tetsuo Handa Acked-by: Dmitry Vyukov --- kernel/locking/lockdep.c | 2 +- kernel/locking/lockdep_internals.h | 8 +++--- lib/Kconfig.debug | 40 ++ 3 files changed, 45 insertions(+), 5 deletions(-) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 2facbbd146ec..2144708a867c 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -1349,7 +1349,7 @@ static int add_lock_to_list(struct lock_class *this, /* * For good efficiency of modular, we use power of 2 */ -#define MAX_CIRCULAR_QUEUE_SIZE4096UL +#define MAX_CIRCULAR_QUEUE_SIZE(1UL << CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS) #define CQ_MASK(MAX_CIRCULAR_QUEUE_SIZE-1) /* diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h index b0be1560ed17..cf7752847eb7 100644 --- a/kernel/locking/lockdep_internals.h +++ b/kernel/locking/lockdep_internals.h @@ -96,16 +96,16 @@ static const unsigned long LOCKF_USED_IN_IRQ_READ = #define MAX_STACK_TRACE_ENTRIES262144UL #define STACK_TRACE_HASH_SIZE 8192 #else -#define MAX_LOCKDEP_ENTRIES32768UL +#define MAX_LOCKDEP_ENTRIES(1UL << CONFIG_LOCKDEP_BITS) -#define MAX_LOCKDEP_CHAINS_BITS16 +#define MAX_LOCKDEP_CHAINS_BITSCONFIG_LOCKDEP_CHAINS_BITS /* * Stack-trace: tightly packed array of stack backtrace * addresses. Protected by the hash_lock. */ -#define MAX_STACK_TRACE_ENTRIES524288UL -#define STACK_TRACE_HASH_SIZE 16384 +#define MAX_STACK_TRACE_ENTRIES(1UL << CONFIG_LOCKDEP_STACK_TRACE_BITS) +#define STACK_TRACE_HASH_SIZE (1 << CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS) #endif /* diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 0c781f912f9f..41d083be7ec3 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1311,6 +1311,46 @@ config LOCKDEP config LOCKDEP_SMALL bool +config LOCKDEP_BITS + int "Bitsize for MAX_LOCKDEP_ENTRIES" + depends on LOCKDEP && !LOCKDEP_SMALL + range 10 30 + default 15 + help + Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message. + +config LOCKDEP_CHAINS_BITS + int "Bitsize for MAX_LOCKDEP_CHAINS" + depends on LOCKDEP && !LOCKDEP_SMALL + range 10 30 + default 16 + help + Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message. + +config LOCKDEP_STACK_TRACE_BITS + int "Bitsize for MAX_STACK_TRACE_ENTRIES" + depends on LOCKDEP && !LOCKDEP_SMALL + range 10 30 + default 19 + help + Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message. + +config LOCKDEP_STACK_TRACE_HASH_BITS + int "Bitsize for STACK_TRACE_HASH_SIZE" + depends on LOCKDEP && !LOCKDEP_SMALL + range 10 30 + default 14 + help + Try increasing this value if you need large MAX_STACK_TRACE_ENTRIES. + +config LOCKDEP_CIRCULAR_QUEUE_BITS + int "Bitsize for elements in circular_queue struct" + depends on LOCKDEP + range 10 30 + default 12 + help + Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure. + config DEBUG_LOCKDEP bool "Lock dependency engine debugging" depends on DEBUG_KERNEL && LOCKDEP -- 2.18.4
[PATCH] ext2: Remove unnecessary blank
Remove unnecessary blank when calling kmalloc_array().
Signed-off-by: Xianting Tian
---
fs/ext2/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index 7fab2b3b5..551e69755 100644
--- a/fs/ext2/super.c
+++ b/fs/ext2/super.c
@@ -1070,7 +1070,7 @@ static int ext2_fill_super(struct super_block *sb, void
*data, int silent)
/ EXT2_BLOCKS_PER_GROUP(sb)) + 1;
db_count = (sbi->s_groups_count + EXT2_DESC_PER_BLOCK(sb) - 1) /
EXT2_DESC_PER_BLOCK(sb);
- sbi->s_group_desc = kmalloc_array (db_count,
+ sbi->s_group_desc = kmalloc_array(db_count,
sizeof(struct buffer_head *),
GFP_KERNEL);
if (sbi->s_group_desc == NULL) {
--
2.17.1
Re: [PATCH v4 1/5] arm64: Add framework to turn IPI as NMI
On Sat, Oct 10, 2020 at 10:34:04AM +0100, Marc Zyngier wrote:
> On Sat, 10 Oct 2020 02:58:55 +0100,
> Masayoshi Mizuma wrote:
>
> [...]
>
> > > +void ipi_nmi_setup(int cpu)
> > > +{
> > > + if (!ipi_desc)
> > > + return;
> >
> > ipi_nmi_setup() may be called twice for CPU0:
> >
> > set_smp_ipi_range => set_smp_ipi_nmi => ipi_nmi_setup
> > => ipi_setup => ipi_nmi_setup
> >
> > Actually, I got the following error message via the second ipi_nmi_setup():
> >
> > GICv3: Pseudo-NMIs enabled using relaxed ICC_PMR_EL1 synchronisation
> > GICv3: Cannot set NMI property of enabled IRQ 8
> > genirq: Failed to setup NMI delivery: irq 8
> >
> > Why don't we have a check to prevent that? Like as:
> >
> >if (cpumask_test_cpu(cpu, ipi_desc->percpu_enabled))
> >return;
>
> That's definitely the wrong thing to do. prepare_nmi_setup() shouldn't
> be called twice, and papering over it isn't acceptable.
Got it. How about moving ipi_nmi_setup() from ipi_setup() to
secondary_start_kernel() ? so that CPU0 can call ipi_nmi_setup() only
from set_smp_ipi_nmi().
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -245,6 +245,7 @@ asmlinkage notrace void secondary_start_kernel(void)
notify_cpu_starting(cpu);
ipi_setup(cpu);
+ ipi_nmi_setup(cpu);
store_cpu_topology(cpu);
numa_add_cpu(cpu);
@@ -966,8 +967,6 @@ static void ipi_setup(int cpu)
for (i = 0; i < nr_ipi; i++)
enable_percpu_irq(ipi_irq_base + i, 0);
-
- ipi_nmi_setup(cpu);
}
#ifdef CONFIG_HOTPLUG_CPU
Thanks,
Masa
Re: [PATCH] iio: dac: ad7303: remove platform data header
On Thu, 1 Oct 2020 17:10:04 +0300
Alexandru Ardelean wrote:
> The information in the ad7303 platform_data header is unused, so it's dead
> code.
> This change removes it and it's inclusion from the driver.
>
> Signed-off-by: Alexandru Ardelean
Applied.
Thanks,
Jonathan
> ---
> drivers/iio/dac/ad7303.c | 2 --
> include/linux/platform_data/ad7303.h | 20
> 2 files changed, 22 deletions(-)
> delete mode 100644 include/linux/platform_data/ad7303.h
>
> diff --git a/drivers/iio/dac/ad7303.c b/drivers/iio/dac/ad7303.c
> index 2e46def9d8ee..dbb4645ab6b1 100644
> --- a/drivers/iio/dac/ad7303.c
> +++ b/drivers/iio/dac/ad7303.c
> @@ -17,8 +17,6 @@
> #include
> #include
>
> -#include
> -
> #define AD7303_CFG_EXTERNAL_VREF BIT(15)
> #define AD7303_CFG_POWER_DOWN(ch) BIT(11 + (ch))
> #define AD7303_CFG_ADDR_OFFSET 10
> diff --git a/include/linux/platform_data/ad7303.h
> b/include/linux/platform_data/ad7303.h
> deleted file mode 100644
> index c2bd0a13bea1..
> --- a/include/linux/platform_data/ad7303.h
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -/*
> - * Analog Devices AD7303 DAC driver
> - *
> - * Copyright 2013 Analog Devices Inc.
> - */
> -
> -#ifndef __IIO_ADC_AD7303_H__
> -#define __IIO_ADC_AD7303_H__
> -
> -/**
> - * struct ad7303_platform_data - AD7303 platform data
> - * @use_external_ref: If set to true use an external voltage reference
> connected
> - * to the REF pin, otherwise use the internal reference derived from Vdd.
> - */
> -struct ad7303_platform_data {
> - bool use_external_ref;
> -};
> -
> -#endif
Low Rate Loan./n.
Hello Dear, We are Investment Company offering Corporate and Personal Loan at 3% Interest Rate for a duration of 10Years. We also pay 1% commission to brokers, who introduce project owners for finance or other opportunities. Please get back to me if you are interested for more details. Yours faithfully, Hashim Bin
Re: [PATCH v6 04/10] vfio/fsl-mc: Implement VFIO_DEVICE_GET_REGION_INFO ioctl call
Hi Diana,
On 10/5/20 7:36 PM, Diana Craciun wrote:
> Expose to userspace information about the memory regions.
>
> Signed-off-by: Bharat Bhushan
> Signed-off-by: Diana Craciun
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> drivers/vfio/fsl-mc/vfio_fsl_mc.c | 79 ++-
> drivers/vfio/fsl-mc/vfio_fsl_mc_private.h | 18 ++
> 2 files changed, 96 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> index 161c2cbe07dc..05dace5ddc2c 100644
> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> @@ -17,16 +17,71 @@
>
> static struct fsl_mc_driver vfio_fsl_mc_driver;
>
> +static int vfio_fsl_mc_regions_init(struct vfio_fsl_mc_device *vdev)
> +{
> + struct fsl_mc_device *mc_dev = vdev->mc_dev;
> + int count = mc_dev->obj_desc.region_count;
> + int i;
> +
> + vdev->regions = kcalloc(count, sizeof(struct vfio_fsl_mc_region),
> + GFP_KERNEL);
> + if (!vdev->regions)
> + return -ENOMEM;
> +
> + for (i = 0; i < count; i++) {
> + struct resource *res = _dev->regions[i];
> +
> + vdev->regions[i].addr = res->start;
> + vdev->regions[i].size = resource_size(res);
> + vdev->regions[i].flags = 0;
> + vdev->regions[i].type = mc_dev->regions[i].flags &
> IORESOURCE_BITS;
> + }
> +
> + return 0;
> +}
> +
> +static void vfio_fsl_mc_regions_cleanup(struct vfio_fsl_mc_device *vdev)
> +{
> + kfree(vdev->regions);
> +}
> +
> static int vfio_fsl_mc_open(void *device_data)
> {
> + struct vfio_fsl_mc_device *vdev = device_data;
> + int ret;
> +
> if (!try_module_get(THIS_MODULE))
> return -ENODEV;
>
> + mutex_lock(>driver_lock);
> + if (!vdev->refcnt) {
> + ret = vfio_fsl_mc_regions_init(vdev);
> + if (ret)
> + goto err_reg_init;
> + }
> + vdev->refcnt++;
> +
> + mutex_unlock(>driver_lock);
> +
> return 0;
> +
> +err_reg_init:
> + mutex_unlock(>driver_lock);
> + module_put(THIS_MODULE);
> + return ret;
> }
>
> static void vfio_fsl_mc_release(void *device_data)
> {
> + struct vfio_fsl_mc_device *vdev = device_data;
> +
> + mutex_lock(>driver_lock);
> +
> + if (!(--vdev->refcnt))
> + vfio_fsl_mc_regions_cleanup(vdev);
> +
> + mutex_unlock(>driver_lock);
> +
> module_put(THIS_MODULE);
> }
>
> @@ -59,7 +114,25 @@ static long vfio_fsl_mc_ioctl(void *device_data, unsigned
> int cmd,
> }
> case VFIO_DEVICE_GET_REGION_INFO:
> {
> - return -ENOTTY;
> + struct vfio_region_info info;
> +
> + minsz = offsetofend(struct vfio_region_info, offset);
> +
> + if (copy_from_user(, (void __user *)arg, minsz))
> + return -EFAULT;
> +
> + if (info.argsz < minsz)
> + return -EINVAL;
> +
> + if (info.index >= mc_dev->obj_desc.region_count)
> + return -EINVAL;
> +
> + /* map offset to the physical address */
> + info.offset = VFIO_FSL_MC_INDEX_TO_OFFSET(info.index);
> + info.size = vdev->regions[info.index].size;
> + info.flags = vdev->regions[info.index].flags;
> +
> + return copy_to_user((void __user *)arg, , minsz);
> }
> case VFIO_DEVICE_GET_IRQ_INFO:
> {
> @@ -210,6 +283,8 @@ static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev)
> if (ret)
> goto out_group_dev;
>
> + mutex_init(>driver_lock);
> +
> return 0;
>
> out_group_dev:
> @@ -228,6 +303,8 @@ static int vfio_fsl_mc_remove(struct fsl_mc_device
> *mc_dev)
> if (!vdev)
> return -EINVAL;
>
> + mutex_destroy(>driver_lock);
> +
> if (is_fsl_mc_bus_dprc(mc_dev)) {
> dprc_remove_devices(mc_dev, NULL, 0);
> dprc_cleanup(mc_dev);
> diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> b/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> index 37d61eaa58c8..be60f41af30f 100644
> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> @@ -7,9 +7,27 @@
> #ifndef VFIO_FSL_MC_PRIVATE_H
> #define VFIO_FSL_MC_PRIVATE_H
>
> +#define VFIO_FSL_MC_OFFSET_SHIFT40
> +#define VFIO_FSL_MC_OFFSET_MASK (((u64)(1) << VFIO_FSL_MC_OFFSET_SHIFT) - 1)
> +
> +#define VFIO_FSL_MC_OFFSET_TO_INDEX(off) ((off) >> VFIO_FSL_MC_OFFSET_SHIFT)
> +
> +#define VFIO_FSL_MC_INDEX_TO_OFFSET(index) \
> + ((u64)(index) << VFIO_FSL_MC_OFFSET_SHIFT)
> +
> +struct vfio_fsl_mc_region {
> + u32 flags;
> + u32 type;
> + u64 addr;
> + resource_size_t size;
> +};
> +
> struct vfio_fsl_mc_device {
> struct fsl_mc_device*mc_dev;
> struct
INFO: task can't die in congestion_wait
Hello,
syzbot found the following issue on:
HEAD commit:a804ab08 Add linux-next specific files for 20201006
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=141b7afb90
kernel config: https://syzkaller.appspot.com/x/.config?x=26c1b4cc4a62ccb
dashboard link: https://syzkaller.appspot.com/bug?extid=9d67ed950b326f4f35c3
compiler: gcc (GCC) 10.1.0-syz 20200507
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+9d67ed950b326f4f3...@syzkaller.appspotmail.com
INFO: task syz-executor.0:8666 can't die for more than 143 seconds.
task:syz-executor.0 state:D stack:26592 pid: 8666 ppid: 6885 flags:0x4006
Call Trace:
context_switch kernel/sched/core.c:3772 [inline]
__schedule+0xec5/0x2200 kernel/sched/core.c:4521
schedule+0xcf/0x270 kernel/sched/core.c:4599
schedule_timeout+0x148/0x250 kernel/time/timer.c:1881
io_schedule_timeout+0xc6/0x140 kernel/sched/core.c:6281
congestion_wait+0xff/0x450 mm/backing-dev.c:960
f2fs_get_meta_page_nofail+0x60/0x70 fs/f2fs/checkpoint.c:117
get_current_nat_page fs/f2fs/node.c:112 [inline]
__f2fs_build_free_nids+0x46f/0xe10 fs/f2fs/node.c:2403
f2fs_build_free_nids fs/f2fs/node.c:2446 [inline]
f2fs_build_node_manager+0x2549/0x3310 fs/f2fs/node.c:3180
f2fs_fill_super+0x3b7b/0x7410 fs/f2fs/super.c:3695
mount_bdev+0x32e/0x3f0 fs/super.c:1419
legacy_get_tree+0x105/0x220 fs/fs_context.c:592
vfs_get_tree+0x89/0x2f0 fs/super.c:1549
do_new_mount fs/namespace.c:2896 [inline]
path_mount+0x12ae/0x1e70 fs/namespace.c:3227
__do_sys_mount fs/namespace.c:3438 [inline]
__se_sys_mount fs/namespace.c:3411 [inline]
__x64_sys_mount+0x278/0x2f0 fs/namespace.c:3411
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x46087a
Code: Unable to access opcode bytes at RIP 0x460850.
RSP: 002b:7f4166abba88 EFLAGS: 0202 ORIG_RAX: 00a5
RAX: ffda RBX: 7f4166abbb20 RCX: 0046087a
RDX: 2000 RSI: 2100 RDI: 7f4166abbae0
RBP: 7f4166abbae0 R08: 7f4166abbb20 R09: 2000
R10: R11: 0202 R12: 2000
R13: 2100 R14: 2200 R15: 20012400
Showing all locks held in the system:
3 locks held by kworker/u4:3/39:
#0: 8880ae436058 (>lock){-.-.}-{2:2}, at: rq_lock
kernel/sched/sched.h:1292 [inline]
#0: 8880ae436058 (>lock){-.-.}-{2:2}, at: __schedule+0x284/0x2200
kernel/sched/core.c:4439
#1: 8880ae420ec8 (_cpu_ptr(group->pcpu, cpu)->seq){-.-.}-{0:0}, at:
psi_task_switch+0x305/0x440 kernel/sched/psi.c:833
#2: 8a554da0 (rcu_read_lock){}-{1:2}, at:
batadv_nc_purge_orig_hash net/batman-adv/network-coding.c:405 [inline]
#2: 8a554da0 (rcu_read_lock){}-{1:2}, at:
batadv_nc_worker+0xf3/0xe50 net/batman-adv/network-coding.c:718
1 lock held by khungtaskd/1181:
#0: 8a554da0 (rcu_read_lock){}-{1:2}, at:
debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6242
1 lock held by in:imklog/6770:
#0: 8880a75216b0 (>f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100
fs/file.c:930
2 locks held by agetty/6781:
#0: 8880973f4098 (>ldisc_sem){}-{0:0}, at:
tty_ldisc_ref_wait+0x22/0x80 drivers/tty/tty_ldisc.c:266
#1: c900010cc2e8 (>atomic_read_lock){+.+.}-{3:3}, at:
n_tty_read+0x223/0x1a70 drivers/tty/n_tty.c:2156
3 locks held by syz-executor.0/8666:
=
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCHSET RFC v3 0/6] Add support for TIF_NOTIFY_SIGNAL
On 10/9/20 9:21 AM, Jens Axboe wrote: > On 10/9/20 2:01 AM, Miroslav Benes wrote: >> On Thu, 8 Oct 2020, Oleg Nesterov wrote: >> >>> On 10/05, Jens Axboe wrote: Hi, The goal is this patch series is to decouple TWA_SIGNAL based task_work from real signals and signal delivery. >>> >>> I think TIF_NOTIFY_SIGNAL can have more users. Say, we can move >>> try_to_freeze() from get_signal() to tracehook_notify_signal(), kill >>> fake_signal_wake_up(), and remove freezing() from recalc_sigpending(). >>> >>> Probably the same for TIF_PATCH_PENDING, klp_send_signals() can use >>> set_notify_signal() rather than signal_wake_up(). >> >> Yes, that was my impression from the patch set too, when I accidentally >> noticed it. >> >> Jens, could you CC our live patching ML when you submit v4, please? It >> would be a nice cleanup. > > Definitely, though it'd be v5 at this point. But we really need to get > all archs supporting TIF_NOTIFY_SIGNAL first. Once we have that, there's > a whole slew of cleanups that'll fall out naturally: > > - Removal of JOBCTL_TASK_WORK > - Removal of special path for TWA_SIGNAL in task_work > - TIF_PATCH_PENDING can be converted and then removed > - try_to_freeze() cleanup that Oleg mentioned > > And probably more I'm not thinking of right now :-) Here's the current series, I took a stab at converting all archs to support TIF_NOTIFY_SIGNAL so we have a base to build on top of. Most of them were straight forward, but I need someone to fixup powerpc, verify arm and s390. But it's a decent start I think, and means that we can drop various bits as is done at the end of the series. I could swap things around a bit and avoid having the intermediate step, but I envision that getting this in all archs will take a bit longer than just signing off on the generic/x86 bits. So probably best to keep the series as it is for now, and work on getting the arch bits verified/fixed/tested. https://git.kernel.dk/cgit/linux-block/log/?h=tif-task_work -- Jens Axboe
Re: [PATCH] iio: accel: mma8452: Constify static struct attribute_group
On Thu, 1 Oct 2020 01:29:39 +0200
Rikard Falkeborn wrote:
> The only usage of mma8452_event_attribute_group is to assign its address
> to the event_attrs field in the iio_info struct, which is a const
> pointer. Make it const to allow the compiler to put it in read-only
> memory. This was the only non-const static struct in drivers/iio.
>
> Signed-off-by: Rikard Falkeborn
applied.
Thanks,
Jonathan
> ---
> drivers/iio/accel/mma8452.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index bf1d2c8afdbd..b0176d936423 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1187,7 +1187,7 @@ static struct attribute *mma8452_event_attributes[] = {
> NULL,
> };
>
> -static struct attribute_group mma8452_event_attribute_group = {
> +static const struct attribute_group mma8452_event_attribute_group = {
> .attrs = mma8452_event_attributes,
> };
>
[PATCH v2 4/5] arm64: mm: Dynamically resize zone_dma_bits based on system's constraints
With the help of of_dma_safe_phys_limit() we can get the topmost
physical address accessible for DMA to the whole system and use that
information to properly setup zone_dma_bits.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/include/asm/processor.h | 1 +
arch/arm64/mm/init.c | 5 ++---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index fce8cbecd6bc..c09d3f1a9a6b 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -97,6 +97,7 @@
extern phys_addr_t arm64_dma_phys_limit;
#define ARCH_LOW_ADDRESS_LIMIT (arm64_dma_phys_limit - 1)
+#define ZONE_DMA_BITS_DEFAULT 32
struct debug_info {
#ifdef CONFIG_HAVE_HW_BREAKPOINT
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 0eca5865dcb1..5934df93bf4d 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -42,8 +42,6 @@
#include
#include
-#define ARM64_ZONE_DMA_BITS30
-
/*
* We need to be able to catch inadvertent references to memstart_addr
* that occur (potentially in generic code) before arm64_memblock_init()
@@ -196,7 +194,8 @@ static void __init zone_sizes_init(unsigned long min,
unsigned long max)
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
#ifdef CONFIG_ZONE_DMA
- zone_dma_bits = ARM64_ZONE_DMA_BITS;
+ zone_dma_bits = min(zone_dma_bits,
+ (unsigned int)ilog2(of_dma_safe_phys_limit()));
if (IS_ENABLED(CONFIG_ACPI)) {
extern unsigned int acpi_iort_get_zone_dma_size(void);
--
2.28.0
Re: [PATCH] net: usb: usbnet: update __usbnet_{read|write}_cmd() to use new API
On Sat, 10 Oct 2020 12:26:23 +0530 Anant Thazhemadam wrote: > GPF_KERNEL You haven't even built this, let alone tested :/
Re: [PATCH v9 1/6] fpga: dfl: fix the definitions of type & feature_id for dfl devices
On 10/10/20 12:09 AM, Xu Yilun wrote:
> The value of the field dfl_device.type comes from the 12 bits register
> field DFH_ID according to DFL spec. So this patch changes the definition
> of the type field to u16.
>
> Also it is not necessary to illustrate the valid bits of the type field
> in comments. Instead we should explicitly define the possible values in
> the enumeration type for it, because they are shared by hardware spec.
> We should not let the compiler decide these values.
>
> Similar changes are also applied to dfl_device.feature_id.
>
> This patch also fixed the MODALIAS format according to the changes
> above.
>
> Signed-off-by: Xu Yilun
> ---
> v9: no change
> ---
> drivers/fpga/dfl.c | 3 +--
> drivers/fpga/dfl.h | 14 +++---
> 2 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index b450870..5a6ba3b 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -298,8 +298,7 @@ static int dfl_bus_uevent(struct device *dev, struct
> kobj_uevent_env *env)
> {
> struct dfl_device *ddev = to_dfl_dev(dev);
>
> - /* The type has 4 valid bits and feature_id has 12 valid bits */
> - return add_uevent_var(env, "MODALIAS=dfl:t%01Xf%03X",
> + return add_uevent_var(env, "MODALIAS=dfl:t%04Xf%04X",
> ddev->type, ddev->feature_id);
> }
>
> diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
> index 5dc758f..ac373b1 100644
> --- a/drivers/fpga/dfl.h
> +++ b/drivers/fpga/dfl.h
> @@ -520,19 +520,19 @@ long dfl_feature_ioctl_set_irq(struct platform_device
> *pdev,
> * enum dfl_id_type - define the DFL FIU types
> */
> enum dfl_id_type {
> - FME_ID,
> - PORT_ID,
> + FME_ID = 0,
> + PORT_ID = 1,
This is redundant, why make this change ?
Tom
> DFL_ID_MAX,
> };
>
> /**
> * struct dfl_device_id - dfl device identifier
> - * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
> - * @feature_id: contains 12 bits feature identifier local to its DFL FIU
> type.
> + * @type: DFL FIU type of the device. See enum dfl_id_type.
> + * @feature_id: feature identifier local to its DFL FIU type.
> * @driver_data: driver specific data.
> */
> struct dfl_device_id {
> - u8 type;
> + u16 type;
> u16 feature_id;
> unsigned long driver_data;
> };
> @@ -543,7 +543,7 @@ struct dfl_device_id {
> * @dev: generic device interface.
> * @id: id of the dfl device.
> * @type: type of DFL FIU of the device. See enum dfl_id_type.
> - * @feature_id: 16 bits feature identifier local to its DFL FIU type.
> + * @feature_id: feature identifier local to its DFL FIU type.
> * @mmio_res: mmio resource of this dfl device.
> * @irqs: list of Linux IRQ numbers of this dfl device.
> * @num_irqs: number of IRQs supported by this dfl device.
> @@ -553,7 +553,7 @@ struct dfl_device_id {
> struct dfl_device {
> struct device dev;
> int id;
> - u8 type;
> + u16 type;
> u16 feature_id;
> struct resource mmio_res;
> int *irqs;
[PATCH 16/18] dt-bindings: usb: meson-g12a-usb: Validate DWC2/DWC3 sub-nodes
Amlogic G12A USB DT sub-nodes are supposed to be compatible with the generic DWC USB2 and USB3 devices. Since now we've got DT schemas for both of the later IP cores let's make sure that the Amlogic G12A USB DT nodes are fully evaluated including the DWC sub-nodes. Signed-off-by: Serge Semin --- .../bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml index 88184d7e26cc..3e8ac0ff90de 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml @@ -78,7 +78,20 @@ properties: patternProperties: "^usb@[0-9a-f]+$": -type: object +allOf: + - if: + properties: +compatible: + contains: +const: snps,dwc2 +then: + $ref: dwc2.yaml# + - if: + properties: +compatible: + const: snps,dwc3 +then: + $ref: snps,dwc3.yaml# additionalProperties: false -- 2.27.0
Re: [PATCH 1/2] net: store KCOV remote handle in sk_buff
On Sat, 10 Oct 2020 09:54:57 +0200 Dmitry Vyukov wrote: > On Sat, Oct 10, 2020 at 1:16 AM Jakub Kicinski wrote: > > On Wed, 7 Oct 2020 10:17:25 + Aleksandr Nogikh wrote: > > > From: Aleksandr Nogikh > > > > > > Remote KCOV coverage collection enables coverage-guided fuzzing of the > > > code that is not reachable during normal system call execution. It is > > > especially helpful for fuzzing networking subsystems, where it is > > > common to perform packet handling in separate work queues even for the > > > packets that originated directly from the user space. > > > > > > Enable coverage-guided frame injection by adding a kcov_handle > > > parameter to sk_buff structure. Initialization in __alloc_skb ensures > > > that no socket buffer that was generated during a system call will be > > > missed. > > > > > > Code that is of interest and that performs packet processing should be > > > annotated with kcov_remote_start()/kcov_remote_stop(). > > > > > > An alternative approach is to determine kcov_handle solely on the > > > basis of the device/interface that received the specific socket > > > buffer. However, in this case it would be impossible to distinguish > > > between packets that originated from normal background network > > > processes and those that were intentionally injected from the user > > > space. > > > > > > Signed-off-by: Aleksandr Nogikh > > > > Could you use skb_extensions for this? > > Why? If for space, this is already under a non-production ifdef. I understand, but the skb_ext infra is there for uncommon use cases like this one. Any particular reason you don't want to use it? The slight LoC increase? Is there any precedent for adding the kcov field to other performance critical structures?
[PATCH v2 1/5] arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
There no use for initializing it earlier in arm64_memblock_init().
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f6902a2b4ea6..0eca5865dcb1 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -196,14 +196,16 @@ static void __init zone_sizes_init(unsigned long min,
unsigned long max)
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
#ifdef CONFIG_ZONE_DMA
+ zone_dma_bits = ARM64_ZONE_DMA_BITS;
+
if (IS_ENABLED(CONFIG_ACPI)) {
extern unsigned int acpi_iort_get_zone_dma_size(void);
zone_dma_bits = min(zone_dma_bits,
acpi_iort_get_zone_dma_size());
- arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
}
+ arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
#endif
#ifdef CONFIG_ZONE_DMA32
@@ -394,11 +396,6 @@ void __init arm64_memblock_init(void)
early_init_fdt_scan_reserved_mem();
- if (IS_ENABLED(CONFIG_ZONE_DMA)) {
- zone_dma_bits = ARM64_ZONE_DMA_BITS;
- arm64_dma_phys_limit = max_zone_phys(ARM64_ZONE_DMA_BITS);
- }
-
if (IS_ENABLED(CONFIG_ZONE_DMA32))
arm64_dma32_phys_limit = max_zone_phys(32);
else
--
2.28.0
[PATCH 15/18] dt-bindings: usb: meson-g12a-usb: Discard FL-adj property
An empty snps,quirk-frame-length-adjustment won't cause any change performed by the driver. Moreover the DT schema validation will fail, since it expects the property being assigned with some value. So just discard the property declaration then from the example. Signed-off-by: Serge Semin --- Note the same problem is in the DT source file arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi . --- .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml index 5b04a7dfa018..88184d7e26cc 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml @@ -209,6 +209,5 @@ examples: interrupts = <30>; dr_mode = "host"; snps,dis_u2_susphy_quirk; - snps,quirk-frame-length-adjustment; }; }; -- 2.27.0
[PATCH v2 5/5] mm: Update DMA zones description
The default behavior for arm64 changed, so reflect that.
Signed-off-by: Nicolas Saenz Julienne
Acked-by: Catalin Marinas
---
include/linux/mmzone.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index fb3bf696c05e..4ee2306351b9 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -363,8 +363,9 @@ enum zone_type {
* - arm only uses ZONE_DMA, the size, up to 4G, may vary depending on
*the specific device.
*
-* - arm64 has a fixed 1G ZONE_DMA and ZONE_DMA32 for the rest of the
-*lower 4G.
+* - arm64 uses a single 4GB ZONE_DMA, except on the Raspberry Pi 4,
+*in which ZONE_DMA covers the first GB and ZONE_DMA32 the rest of
+*the lower 4GB.
*
* - powerpc only uses ZONE_DMA, the size, up to 2G, may vary
*depending on the specific device.
--
2.28.0
Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711
On Sat, 2020-10-10 at 12:36 +0200, Ard Biesheuvel wrote: > On Fri, 9 Oct 2020 at 19:10, Catalin Marinas wrote: > > On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote: > > > On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi > > > wrote: > > > > We can move this check to IORT code and call it from arm64 if it > > > > can be made to work. > > > > > > Finding the smallest value in the IORT, and assigning it to > > > zone_dma_bits if it is < 32 should be easy. But as I understand it, > > > having these separate DMA and DMA32 zones is what breaks kdump, no? So > > > how is this going to fix the underlying issue? > > > > If zone_dma_bits is 32, ZONE_DMA32 disappears into ZONE_DMA (GFP_DMA32 > > allocations fall back to ZONE_DMA). > > > > kdump wants DMA-able memory and, without a 30-bit ZONE_DMA, that would > > be the bottom 32-bit. With the introduction of ZONE_DMA, this suddenly > > became 1GB. We could change kdump to allocate ZONE_DMA32 but this one > > may also be small as it lost 1GB to ZONE_DMA. However, the kdump kernel > > would need to be rebuilt without ZONE_DMA since it won't have any. IIRC > > (it's been a while since I looked), the kdump allocation couldn't span > > multiple zones. > > > > In a separate thread, we try to fix kdump to use allocations above 4G as > > a fallback but this only fixes platforms with enough RAM (and maybe it's > > only those platforms that care about kdump). > > > > One thing that strikes me as odd is that we are applying the same > shifting logic to ZONE_DMA as we are applying to ZONE_DMA32, i.e., if > DRAM starts outside of the zone, it is shifted upwards. > > On a typical ARM box, this gives me > > [0.00] Zone ranges: > [0.00] DMA [mem 0x8000-0xbfff] > [0.00] DMA32[mem 0xc000-0x] > [0.00] Normal [mem 0x0001-0x000f] > > i.e., the 30-bit addressable range has bit 31 set, which is weird. Yes I agree it's weird, and IMO plain useless. I sent a series this summer to address this[1], which ultimately triggered the discussion we're having right now. Although with with your latest patch and the DT counterpart, we should be OK. It would be weird for a HW description to define DMA constraints that are impossible to reach on that system. > I wonder if it wouldn't be better (and less problematic in the general > case) to drop this logic for ZONE_DMA, and simply let it remain empty > unless there is really some memory there. From my experience, you can't have empty ZONE_DMA when enabled. Empty ZONE_DMA32 is OK though. Although I'm sure it's something that can be changed. Regards, Nicolas [1] https://lkml.org/lkml/2020/8/19/1022 signature.asc Description: This is a digitally signed message part
[PATCH 18/18] dt-bindings: usb: qcom,dwc3: Validate DWC3 sub-node
Qualcomm msm8996/sc7180/sdm845 DWC3 compatible DT nodes are supposed to
have a DWC USB3 compatible sub-node to describe a fully functioning USB
interface. Let's use the available DWC USB3 DT schema to validate
the Qualcomm DWC3 sub-nodes.
Note since the generic DWC USB3 DT node is supposed to be named as
generic USB HCD ("^usb(@.*)?") we have to accordingly extend the sub-nodes
naming space and fix the DT node example.
Signed-off-by: Serge Semin
---
Alas there are many Qualcomm DTS files, which have got the Qualcomm DWC3
node defined with sub-nodes named as "^dwc3@.*". Since the generic DWC USB3
DT schema will be automatically selected for them and the naming doesn't
comply with the USB HCD DT schema, the dtbs_check procedure will fail.
I don't really know what is a most suitable way to fix that. It's either
to alter all the Qualcomm DTS files, or extend the USB HCD schema to
accept the "dwc3@.*" nodes, or redesign the usb-hcd.yaml schema. What do
you think?
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index dac10848dd7f..b3737f0e4dc1 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -103,11 +103,8 @@ properties:
# Required child node:
patternProperties:
- "^dwc3@[0-9a-f]+$":
-type: object
-description:
- A child node must exist to represent the core DWC3 IP block
- The content of the node is defined in dwc3.txt.
+ "^(usb|dwc3)@[0-9a-f]+$":
+$ref: snps,dwc3.yaml#
required:
- compatible
@@ -160,7 +157,7 @@ examples:
resets = < GCC_USB30_PRIM_BCR>;
-dwc3@a60 {
+usb@a60 {
compatible = "snps,dwc3";
reg = <0 0x0a60 0 0xcd00>;
interrupts = ;
--
2.27.0
[PATCH 17/18] dt-bindings: usb: keystone-dwc3: Validate DWC3 sub-node
TI Keystone DWC3 compatible DT node is supposed to have a DWC USB3 compatible sub-node to describe a fully functioning USB interface. Since DWC USB3 has now got a DT schema describing it' DT node, let's make sure the TI Keystone DWC3 sub-node passes validation against it. Signed-off-by: Serge Semin --- Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index c1b19fc5d0a2..ca7fbe3ed22e 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -64,9 +64,7 @@ properties: patternProperties: "usb@[a-f0-9]+$": -type: object -description: This is the node representing the DWC3 controller instance - Documentation/devicetree/bindings/usb/dwc3.txt +$ref: snps,dwc3.yaml# required: - compatible -- 2.27.0
[PATCH] watchdog: via_wdt: add VX900 support
Adds watchdog support for the VIA VX900 chip-set, which is fully
backwards compatible to the older VIA chip-set watchdogs.
Signed-off-by: Wilken Gottwalt
---
drivers/watchdog/via_wdt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/watchdog/via_wdt.c b/drivers/watchdog/via_wdt.c
index eeb39f96e72e..b452ab253ac7 100644
--- a/drivers/watchdog/via_wdt.c
+++ b/drivers/watchdog/via_wdt.c
@@ -244,6 +244,7 @@ static const struct pci_device_id wdt_pci_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_CX700) },
{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VX800) },
{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VX855) },
+ { PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VX900) },
{ 0 }
};
--
2.28.0
Re: [PATCH 5/5] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID
On Sat, Oct 10 2020 at 11:06, David Woodhouse wrote: > On Fri, 2020-10-09 at 01:27 +0200, Thomas Gleixner wrote: >> On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote: >> For the next submission, can you please >> >> - pick up the -ENODEV changes for HPET/IOAPIC which I posted earlier > > I think the world will be a nicer place if HPET and IOAPIC have their > own struct device and their drivers can just use dev_get_msi_domain(). > > The IRQ remapping drivers already plug into the device-add notifier and > can fill in the appropriate MSI domain just like they do¹ for PCI and > ACPI devices. > > Using platform_add_bundle() for HPET looks trivial enough; I'll have a > play with that and then do IOAPIC too if/when the initialisation order > and hotplug handling all works out OK to install the correct > msi_domain. Yes, I was wondering about that when I made PCI at least use that mechanism, but had not had time to actually look at it. Thanks, tglx
Re: [PATCH 5/5] selftests/ftrace: Change synthetic event name for inter-event-combined test
On Fri, 9 Oct 2020 10:17:11 -0500 Tom Zanussi wrote: > This test uses waking+wakeup_latency as an event name, which doesn't > make sense since it includes an operator. Illegal names are now > detected by the synthetic event command parsing, which causes this > test to fail. Change the name to 'waking_plus_wakeup_latency' to > prevent this. Good catch! Acked-by: Masami Hiramatsu Thanks! > > Fixes: f06eec4d0f2c (selftests: ftrace: Add inter-event hist triggers > testcases) > Signed-off-by: Tom Zanussi > --- > .../inter-event/trigger-inter-event-combined-hist.tc | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git > a/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-inter-event-combined-hist.tc > > b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-inter-event-combined-hist.tc > index 7449a4b8f1f9..9098f1e7433f 100644 > --- > a/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-inter-event-combined-hist.tc > +++ > b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-inter-event-combined-hist.tc > @@ -25,12 +25,12 @@ echo 'wakeup_latency u64 lat pid_t pid' >> > synthetic_events > echo 'hist:keys=pid:ts1=common_timestamp.usecs if comm=="ping"' >> > events/sched/sched_wakeup/trigger > echo > 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts1:onmatch(sched.sched_wakeup).wakeup_latency($wakeup_lat,next_pid) > if next_comm=="ping"' > events/sched/sched_switch/trigger > > -echo 'waking+wakeup_latency u64 lat; pid_t pid' >> synthetic_events > -echo > 'hist:keys=pid,lat:sort=pid,lat:ww_lat=$waking_lat+$wakeup_lat:onmatch(synthetic.wakeup_latency).waking+wakeup_latency($ww_lat,pid)' > >> events/synthetic/wakeup_latency/trigger > -echo 'hist:keys=pid,lat:sort=pid,lat' >> > events/synthetic/waking+wakeup_latency/trigger > +echo 'waking_plus_wakeup_latency u64 lat; pid_t pid' >> synthetic_events > +echo > 'hist:keys=pid,lat:sort=pid,lat:ww_lat=$waking_lat+$wakeup_lat:onmatch(synthetic.wakeup_latency).waking_plus_wakeup_latency($ww_lat,pid)' > >> events/synthetic/wakeup_latency/trigger > +echo 'hist:keys=pid,lat:sort=pid,lat' >> > events/synthetic/waking_plus_wakeup_latency/trigger > > ping $LOCALHOST -c 3 > -if ! grep -q "pid:" events/synthetic/waking+wakeup_latency/hist; then > +if ! grep -q "pid:" events/synthetic/waking_plus_wakeup_latency/hist; then > fail "Failed to create combined histogram" > fi > > -- > 2.17.1 > -- Masami Hiramatsu
Re: [PATCH v2] iio: adc: ad7887: invert/rework external ref logic
On Fri, 2 Oct 2020 11:27:23 +0300
Alexandru Ardelean wrote:
> This change inverts/reworks the logic to use an external reference via a
> provided regulator.
>
> Now the driver tries to obtain a regulator. If one is found, then it is
> used. The rest of the driver logic already checks if there is a non-NULL
> reference to a regulator, so it should be fine.
>
> Signed-off-by: Alexandru Ardelean
Applied to the togreg branch of iio.git and pushed out as testing for
all the normal reasons.
Interestingly it seems something odd happened to my email and I was missing
random threads/part threads. I've pulled them off lore.kernel.org but if
I seem to have lost anything let me know.
If anyone has a bounce message from me, please send it over as I'm curious
as to what went wrong!
Thanks,
Jonathan
> ---
>
> Changelog v1 -> v2:
> * remove omitted '!pdata->use_onchip_ref' check; the field was removed from
> the platform data, but was still used
>
> drivers/iio/adc/ad7887.c | 12
> include/linux/platform_data/ad7887.h | 4
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/adc/ad7887.c b/drivers/iio/adc/ad7887.c
> index 037bcb47693c..99a480ad3985 100644
> --- a/drivers/iio/adc/ad7887.c
> +++ b/drivers/iio/adc/ad7887.c
> @@ -246,11 +246,15 @@ static int ad7887_probe(struct spi_device *spi)
>
> st = iio_priv(indio_dev);
>
> - if (!pdata || !pdata->use_onchip_ref) {
> - st->reg = devm_regulator_get(>dev, "vref");
> - if (IS_ERR(st->reg))
> + st->reg = devm_regulator_get_optional(>dev, "vref");
> + if (IS_ERR(st->reg)) {
> + if (PTR_ERR(st->reg) != -ENODEV)
> return PTR_ERR(st->reg);
>
> + st->reg = NULL;
> + }
> +
> + if (st->reg) {
> ret = regulator_enable(st->reg);
> if (ret)
> return ret;
> @@ -269,7 +273,7 @@ static int ad7887_probe(struct spi_device *spi)
> /* Setup default message */
>
> mode = AD7887_PM_MODE4;
> - if (!pdata || !pdata->use_onchip_ref)
> + if (!st->reg)
> mode |= AD7887_REF_DIS;
> if (pdata && pdata->en_dual)
> mode |= AD7887_DUAL;
> diff --git a/include/linux/platform_data/ad7887.h
> b/include/linux/platform_data/ad7887.h
> index 732af46b2d16..9b4dca6ae70b 100644
> --- a/include/linux/platform_data/ad7887.h
> +++ b/include/linux/platform_data/ad7887.h
> @@ -13,13 +13,9 @@
> * second input channel, and Vref is internally connected to Vdd. If set to
> * false the device is used in single channel mode and AIN1/Vref is used as
> * VREF input.
> - * @use_onchip_ref: Whether to use the onchip reference. If set to true the
> - * internal 2.5V reference is used. If set to false a external reference is
> - * used.
> */
> struct ad7887_platform_data {
> bool en_dual;
> - bool use_onchip_ref;
> };
>
> #endif /* IIO_ADC_AD7887_H_ */
Re: [PATCH v1 5/6] staging: qlge: clean up debugging code in the QL_ALL_DUMP ifdef land
On 2020-10-10 18:00 +0800, Coiby Xu wrote: [...] > > > > Please also update drivers/staging/qlge/TODO accordingly. There is still > > a lot of debugging code IMO (the netif_printk statements - kernel > > tracing can be used instead of those) but this patch is a substantial > > improvement. > > Thank you for the reminding! To move qlge out of staging tree would be > interesting exercise for me:) If you would like to work more on the driver, I would highly suggest getting one or two adapters to be able to test your changes. They can be had for relatively cheap on ebay. Just search for "qle8142".
Re: [PATCH v4 seccomp 5/5] seccomp/cache: Report cache data through /proc/pid/seccomp_cache
On Fri, Oct 9, 2020 at 6:14 PM Kees Cook wrote: > HAVE_ARCH_SECCOMP_CACHE isn't used any more. I think this was left over > from before. Oh, I was meant to add this to the dependencies of SECCOMP_CACHE_DEBUG. Is this something that would make sense? YiFei Zhu
[GIT PULL] irqchip updates for 5.10
Hi Thomas,
This is the rather large set of irqchip updates for 5.10.
This time around, we have three new drivers (MStar, Owl SIRQ and
PRUSS), some cross-architecture updates (the arm/arm64 switch to
standard IRQs for IPIs and the corresponding changes to their primary
irqchip drivers), a number of fixes as the fallout from these updates
(the Tegra bug is tasty), some driver updates (QC PDC, WD APB ICTL,
GIC...), and a couple of mundane bug fixes.
Please pull,
M.
The following changes since commit f4d51dffc6c01a9e94650d95ce0104964f8ae822:
Linux 5.9-rc4 (2020-09-06 17:11:40 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
tags/irqchip-5.10
for you to fetch changes up to 63ea38a402213d8c9c16e58ee4901ff51bc8fe3c:
Merge branch 'irq/mstar' into irq/irqchip-next (2020-10-10 12:46:54 +0100)
irqchip updates for Linux 5.10
Core changes:
- Allow irq retriggering to follow a hierarchy
- Allow interrupt hierarchies to be trimmed at allocation time
- Allow interrupts to be hidden from /proc/interrupts (IPIs)
- Introduce stub for set_handle_irq() when !GENERIC_IRQ_MULTI_HANDLER
- New per-cpu IPI handling flow
Architecture changes:
- Move arm/arm64 IPI handling to the core interrupt code, removing
the home brewed accounting
Driver updates:
- New driver for the MStar (and more recently Mediatek) platforms
- New driver for the Actions Owl SIRQ controller
- New driver for the TI PRUSS infrastructure
- Wake-up support for the Qualcomm PDC controller
- Primary interrupt controller support for the Designware APB ICTL
- Convert the IPI code for GIC, GICv3, hip04, armada-270-xp and bcm2836
to using standard interrupts
- Improve GICv3 pseudo-NMI support to deal with both non-secure and secure
priorities on arm64
- Convert the GIC/GICv3 drivers to using HW-based irq retrigger
- A sprinkling of dev_err_probe() conversion
- A set of NVIDIA Tegra fixes for interrupt hierarchy corruption
- A reset fix for the Loongson HTVEC driver
- A couple of error handling fixes in the TI SCI drivers
Alexandru Elisei (2):
irqchip/gic-v3: Spell out when pseudo-NMIs are enabled
irqchip/gic-v3: Support pseudo-NMIs when SCR_EL3.FIQ == 0
Anson Huang (2):
irqchip/imx-intmux: Use dev_err_probe() to simplify error handling
irqchip/imx-irqsteer: Use dev_err_probe() to simplify error handling
Cristian Ciocaltea (3):
dt-bindings: interrupt-controller: Add Actions SIRQ controller binding
irqchip: Add Actions Semi Owl SIRQ controller
MAINTAINERS: Add entries for Actions Semi Owl SIRQ controller
David Lechner (1):
irqchip/irq-pruss-intc: Implement irq_{get, set}_irqchip_state ops
Grzegorz Jaszczyk (1):
irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts
Huacai Chen (1):
irqchip/loongson-htvec: Fix initial interrupt clearing
Krzysztof Kozlowski (1):
irqchip/ti-sci: Simplify with dev_err_probe()
Lad Prabhakar (1):
irqchip: Kconfig: Update description for RENESAS_IRQC config
Marc Zyngier (36):
genirq: Walk the irq_data hierarchy when resending an interrupt
irqchip/git-v3-its: Implement irq_retrigger callback for device-triggered
LPIs
genirq: Add fasteoi IPI flow
genirq: Allow interrupts to be excluded from /proc/interrupts
arm64: Allow IPIs to be handled as normal interrupts
ARM: Allow IPIs to be handled as normal interrupts
irqchip/gic-v3: Describe the SGI range
irqchip/gic-v3: Configure SGIs as standard interrupts
irqchip/gic: Refactor SMP configuration
irqchip/gic: Configure SGIs as standard interrupts
irqchip/gic-common: Don't enable SGIs by default
irqchip/bcm2836: Configure mailbox interrupts as standard interrupts
irqchip/hip04: Configure IPIs as standard interrupts
irqchip/armada-370-xp: Configure IPIs as standard interrupts
arm64: Kill __smp_cross_call and co
arm64: Remove custom IRQ stat accounting
ARM: Kill __smp_cross_call and co
ARM: Remove custom IRQ stat accounting
irqchip/bcm2836: Provide mask/unmask dummy methods for IPIs
irqchip/gic: Cleanup Franken-GIC handling
Merge remote-tracking branch 'origin/irq/misc-5.10' into irq/irqchip-next
Merge remote-tracking branch 'origin/irq/dev_err_probe' into
irq/irqchip-next
Merge remote-tracking branch 'origin/irq/gic-v3-nmi-ns' into
irq/irqchip-next
Merge remote-tracking branch 'origin/irq/ipi-as-irq' into irq/irqchip-next
Merge remote-tracking branch 'origin/irq/gic-retrigger' into
irq/irqchip-next
arm: Move ipi_teardown() to a CONFIG_HOTPLUG_CPU section
ARM: Handle no IPI being registered in show_ipi_list()
Merge branch 'irq/ipi-as-irq', remote-tracking branches 'origin/irq/dw'
and 'origin/irq/owl' into
Re: [PATCH] mm: validate inode in mapping_set_error
On Fri, 2020-10-09 at 17:06 -0700, Minchan Kim wrote: > The swap address_space doesn't have host. Thus, it makes kernel crash once > swap write meets error. Fix it. > > [1] 735e4ae5ba28, vfs: track per-sb writeback errors and report them to syncfs > Signed-off-by: Minchan Kim > --- > include/linux/pagemap.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h > index 17ba0fe59290..9cf540447e73 100644 > --- a/include/linux/pagemap.h > +++ b/include/linux/pagemap.h > @@ -55,7 +55,8 @@ static inline void mapping_set_error(struct address_space > *mapping, int error) > __filemap_set_wb_err(mapping, error); > > /* Record it in superblock */ > - errseq_set(>host->i_sb->s_wb_err, error); > + if (mapping->host) > + errseq_set(>host->i_sb->s_wb_err, error); > > /* Record it in flags for now, for legacy callers */ > if (error == -ENOSPC) Good catch. Acked-by: Jeff Layton
Re: [PATCH 2/5] tracing: Move is_good_name() from trace_probe.h to trace.h
On Fri, 9 Oct 2020 10:17:08 -0500
Tom Zanussi wrote:
> is_good_name() is useful for other trace infrastructure, such as
> synthetic events, so make it available via trace.h.
>
This looks good to me.
Acked-by: Masami Hiramatsu
Thanks!
> Signed-off-by: Tom Zanussi
> ---
> kernel/trace/trace.h | 13 +
> kernel/trace/trace_probe.h | 13 -
> 2 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 5b0e797cacdd..a94852838491 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef CONFIG_FTRACE_SYSCALLS
> #include /* For NR_SYSCALLS */
> @@ -2090,4 +2091,16 @@ static __always_inline void
> trace_iterator_reset(struct trace_iterator *iter)
> iter->pos = -1;
> }
>
> +/* Check the name is good for event/group/fields */
> +static inline bool is_good_name(const char *name)
> +{
> + if (!isalpha(*name) && *name != '_')
> + return false;
> + while (*++name != '\0') {
> + if (!isalpha(*name) && !isdigit(*name) && *name != '_')
> + return false;
> + }
> + return true;
> +}
> +
> #endif /* _LINUX_KERNEL_TRACE_H */
> diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
> index 04d00987da69..2f703a20c724 100644
> --- a/kernel/trace/trace_probe.h
> +++ b/kernel/trace/trace_probe.h
> @@ -16,7 +16,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -348,18 +347,6 @@ bool trace_probe_match_command_args(struct trace_probe
> *tp,
> #define trace_probe_for_each_link_rcu(pos, tp) \
> list_for_each_entry_rcu(pos, &(tp)->event->files, list)
>
> -/* Check the name is good for event/group/fields */
> -static inline bool is_good_name(const char *name)
> -{
> - if (!isalpha(*name) && *name != '_')
> - return false;
> - while (*++name != '\0') {
> - if (!isalpha(*name) && !isdigit(*name) && *name != '_')
> - return false;
> - }
> - return true;
> -}
> -
> #define TPARG_FL_RETURN BIT(0)
> #define TPARG_FL_KERNEL BIT(1)
> #define TPARG_FL_FENTRY BIT(2)
> --
> 2.17.1
>
--
Masami Hiramatsu
Re: [PATCH 1/5] tracing: Don't show dynamic string internals in synthetic event description
Hi Tom,
On Fri, 9 Oct 2020 10:17:07 -0500
Tom Zanussi wrote:
> For synthetic event dynamic fields, the type contains "__data_loc",
> which is basically an internal part of the type which is only meant to
> be displayed in the format, not in the event description itself, which
> is confusing to users since they can't use __data_loc on the
> command-line to define an event field, which printing it would lead
> them to believe.
>
> So filter it out from the description, while leaving it in the type.
>
OK, I confirmed this removes __data_loc from synth_events interface.
However, I also found another issue.
/sys/kernel/debug/tracing # echo "myevent char str[]; int v" >>
synthetic_events
/sys/kernel/debug/tracing # cat synthetic_events
myevent char[]; str; int v
It seems that the type "char[]" includes ";" as a type, this results
/sys/kernel/debug/tracing # cat events/synthetic/myevent/format
name: myevent
ID: 1220
format:
field:unsigned short common_type; offset:0; size:2;
signed:0;
field:unsigned char common_flags; offset:2; size:1;
signed:0;
field:unsigned char common_preempt_count; offset:3; size:1;
signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[]; str; offset:8; size:8; signed:1;
field:int v;offset:16; size:4; signed:1;
print fmt: "str=%.*s, v=%d", __get_str(str), REC->v
As you can see, the field type has ";" in format file too. This will prevent
parsing event information correctly.
I also try to remove ";" as below, it seems to work correctly.
/sys/kernel/debug/tracing # echo "myevent char[] str; int v" >>
synthetic_events
/sys/kernel/debug/tracing # cat events/synthetic/myevent/format
name: myevent
ID: 1221
format:
field:unsigned short common_type; offset:0; size:2;
signed:0;
field:unsigned char common_flags; offset:2; size:1;
signed:0;
field:unsigned char common_preempt_count; offset:3; size:1;
signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] str;offset:8; size:8; signed:1;
field:int v;offset:16; size:4; signed:1;
print fmt: "str=%.*s, v=%d", __get_str(str), REC->v
Thank you,
> Reported-by: Masami Hiramatsu
> Signed-off-by: Tom Zanussi
> ---
> kernel/trace/trace_events_synth.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace_events_synth.c
> b/kernel/trace/trace_events_synth.c
> index 3b2dcc42b8ee..b19e2f4159ab 100644
> --- a/kernel/trace/trace_events_synth.c
> +++ b/kernel/trace/trace_events_synth.c
> @@ -1867,14 +1867,22 @@ static int __synth_event_show(struct seq_file *m,
> struct synth_event *event)
> {
> struct synth_field *field;
> unsigned int i;
> + char *type, *t;
>
> seq_printf(m, "%s\t", event->name);
>
> for (i = 0; i < event->n_fields; i++) {
> field = event->fields[i];
>
> + type = field->type;
> + t = strstr(type, "__data_loc");
> + if (t) { /* __data_loc belongs in format but not event desc */
> + t += sizeof("__data_loc");
> + type = t;
> + }
> +
> /* parameter values */
> - seq_printf(m, "%s %s%s", field->type, field->name,
> + seq_printf(m, "%s %s%s", type, field->name,
> i == event->n_fields - 1 ? "" : "; ");
> }
>
> --
> 2.17.1
>
--
Masami Hiramatsu
Re: [PATCH 1/2] mm/mprotect: Call arch_validate_prot under mmap_lock and with length
Hi Khalid,
On Wed, Oct 07, 2020 at 02:14:09PM -0600, Khalid Aziz wrote:
> On 10/7/20 1:39 AM, Jann Horn wrote:
> > arch_validate_prot() is a hook that can validate whether a given set of
> > protection flags is valid in an mprotect() operation. It is given the set
> > of protection flags and the address being modified.
> >
> > However, the address being modified can currently not actually be used in
> > a meaningful way because:
> >
> > 1. Only the address is given, but not the length, and the operation can
> >span multiple VMAs. Therefore, the callee can't actually tell which
> >virtual address range, or which VMAs, are being targeted.
> > 2. The mmap_lock is not held, meaning that if the callee were to check
> >the VMA at @addr, that VMA would be unrelated to the one the
> >operation is performed on.
> >
> > Currently, custom arch_validate_prot() handlers are defined by
> > arm64, powerpc and sparc.
> > arm64 and powerpc don't care about the address range, they just check the
> > flags against CPU support masks.
> > sparc's arch_validate_prot() attempts to look at the VMA, but doesn't take
> > the mmap_lock.
> >
> > Change the function signature to also take a length, and move the
> > arch_validate_prot() call in mm/mprotect.c down into the locked region.
[...]
> As Chris pointed out, the call to arch_validate_prot() from do_mmap2()
> is made without holding mmap_lock. Lock is not acquired until
> vm_mmap_pgoff(). This variance is uncomfortable but I am more
> uncomfortable forcing all implementations of validate_prot to require
> mmap_lock be held when non-sparc implementations do not have such need
> yet. Since do_mmap2() is in powerpc specific code, for now this patch
> solves a current problem.
I still think sparc should avoid walking the vmas in
arch_validate_prot(). The core code already has the vmas, though not
when calling arch_validate_prot(). That's one of the reasons I added
arch_validate_flags() with the MTE patches. For sparc, this could be
(untested, just copied the arch_validate_prot() code):
static inline bool arch_validate_flags(unsigned long vm_flags)
{
if (!(vm_flags & VM_SPARC_ADI))
return true;
if (!adi_capable())
return false;
/* ADI can not be enabled on PFN mapped pages */
if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
return false;
/*
* Mergeable pages can become unmergeable if ADI is enabled on
* them even if they have identical data on them. This can be
* because ADI enabled pages with identical data may still not
* have identical ADI tags on them. Disallow ADI on mergeable
* pages.
*/
if (vma->vm_flags & VM_MERGEABLE)
return false;
return true;
}
> That leaves open the question of should
> generic mmap call arch_validate_prot and return EINVAL for invalid
> combination of protection bits, but that is better addressed in a
> separate patch.
The above would cover mmap() as well.
The current sparc_validate_prot() relies on finding the vma for the
corresponding address. However, if you call this early in the mmap()
path, there's no such vma. It is only created later in mmap_region()
which no longer has the original PROT_* flags (all converted to VM_*
flags).
Calling arch_validate_flags() on mmap() has a small side-effect on the
user ABI: if the CPU is not adi_capable(), PROT_ADI is currently ignored
on mmap() but rejected by sparc_validate_prot(). Powerpc already does
this already and I think it should be fine for arm64 (it needs checking
though as we have another flag, PROT_BTI, hopefully dynamic loaders
don't pass this flag unconditionally).
However, as I said above, it doesn't solve the mmap() PROT_ADI checking
for sparc since there's no vma yet. I'd strongly recommend the
arch_validate_flags() approach and reverting the "start" parameter added
to arch_validate_prot() if you go for the flags route.
Thanks.
--
Catalin
Re: [PATCH] net: usb: rtl8150: don't incorrectly assign random MAC addresses
On Sat, 10 Oct 2020 12:14:59 +0530 Anant Thazhemadam wrote:
> get_registers() directly returns the return value of
> usb_control_msg_recv() - 0 if successful, and negative error number
> otherwise.
Are you expecting Greg to take this as a part of some USB subsystem
changes? I don't see usb_control_msg_recv() in my tree, and the
semantics of usb_control_msg() are not what you described.
> However, in set_ethernet_addr(), this return value is incorrectly
> checked.
>
> Since this return value will never be equal to sizeof(node_id), a
> random MAC address will always be generated and assigned to the
> device; even in cases when get_registers() is successful.
>
> Correctly modifying the condition that checks if get_registers() was
> successful or not fixes this problem, and copies the ethernet address
> appropriately.
>
> Fixes: f45a4248ea4c ("set random MAC address when set_ethernet_addr() fails")
> Signed-off-by: Anant Thazhemadam
The fixes tag does not follow the standard format:
Fixes tag: Fixes: f45a4248ea4c ("set random MAC address when
set_ethernet_addr() fails")
Has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
Please put the relevant maintainer in the To: field of the email, and
even better - also mark the patch as [PATCH net], since it's a
networking fix.
Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711
On Sat, Oct 10, 2020 at 12:53:19PM +0200, Nicolas Saenz Julienne wrote: > On Sat, 2020-10-10 at 12:36 +0200, Ard Biesheuvel wrote: > > On Fri, 9 Oct 2020 at 19:10, Catalin Marinas > > wrote: > > > On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote: > > > > On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi > > > > wrote: > > > > > We can move this check to IORT code and call it from arm64 if it > > > > > can be made to work. > > > > > > > > Finding the smallest value in the IORT, and assigning it to > > > > zone_dma_bits if it is < 32 should be easy. But as I understand it, > > > > having these separate DMA and DMA32 zones is what breaks kdump, no? So > > > > how is this going to fix the underlying issue? > > > > > > If zone_dma_bits is 32, ZONE_DMA32 disappears into ZONE_DMA (GFP_DMA32 > > > allocations fall back to ZONE_DMA). > > > > > > kdump wants DMA-able memory and, without a 30-bit ZONE_DMA, that would > > > be the bottom 32-bit. With the introduction of ZONE_DMA, this suddenly > > > became 1GB. We could change kdump to allocate ZONE_DMA32 but this one > > > may also be small as it lost 1GB to ZONE_DMA. However, the kdump kernel > > > would need to be rebuilt without ZONE_DMA since it won't have any. IIRC > > > (it's been a while since I looked), the kdump allocation couldn't span > > > multiple zones. > > > > > > In a separate thread, we try to fix kdump to use allocations above 4G as > > > a fallback but this only fixes platforms with enough RAM (and maybe it's > > > only those platforms that care about kdump). > > > > > > > One thing that strikes me as odd is that we are applying the same > > shifting logic to ZONE_DMA as we are applying to ZONE_DMA32, i.e., if > > DRAM starts outside of the zone, it is shifted upwards. > > > > On a typical ARM box, this gives me > > > > [0.00] Zone ranges: > > [0.00] DMA [mem 0x8000-0xbfff] > > [0.00] DMA32[mem 0xc000-0x] > > [0.00] Normal [mem 0x0001-0x000f] > > > > i.e., the 30-bit addressable range has bit 31 set, which is weird. > > Yes I agree it's weird, and IMO plain useless. I sent a series this summer to > address this[1], which ultimately triggered the discussion we're having right > now. I don't mind assuming that ZONE_DMA is always from pfn 0 (i.e. no dma_offset for such constrained devices). But if ZONE_DMA32 is squeezed out with ZONE_DMA extended to 4GB, it should allow non-zero upper 32 bits. IIRC we do have SoCs with RAM starting above 4GB. However, your patch didn't completely solve the problem for non-RPi4 platforms as there's hardware with RAM starting at 0 that doesn't need the 1GB ZONE_DMA. We may end up with a combination of the two approaches. > Although with with your latest patch and the DT counterpart, we should be OK. > It would be weird for a HW description to define DMA constraints that are > impossible to reach on that system. I don't remember the difficulties with parsing a DT early for inferring the ZONE_DMA requirements. Could we not check the dma-ranges property in the soc node? I can see bcm2711.dtsi defines a 30-bit address range. We are not interested in the absolute physical/bus addresses, just the size to check whether it's smaller than 32-bit. > > I wonder if it wouldn't be better (and less problematic in the general > > case) to drop this logic for ZONE_DMA, and simply let it remain empty > > unless there is really some memory there. > > From my experience, you can't have empty ZONE_DMA when enabled. Empty > ZONE_DMA32 is OK though. Although I'm sure it's something that can be changed. Indeed, because we still have GFP_DMA around which can't fall back to ZONE_DMA32 (well, unless CONFIG_ZONE_DMA is disabled). -- Catalin
Re: [PATCH v6 2/3] i2c: imx: Check for I2SR_IAL after every byte
On Fri, Oct 09, 2020 at 01:03:19PM +0200, Christian Eggers wrote: > Arbitration Lost (IAL) can happen after every single byte transfer. If > arbitration is lost, the I2C hardware will autonomously switch from > master mode to slave. If a transfer is not aborted in this state, > consecutive transfers will not be executed by the hardware and will > timeout. > > Signed-off-by: Christian Eggers > Tested (not extensively) on Vybrid VF500 (Toradex VF50): > Tested-by: Krzysztof Kozlowski > Acked-by: Oleksij Rempel > Cc: sta...@vger.kernel.org Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH v6 0/3] i2c: imx: Fix handling of arbitration loss
> Changes in v5: Changes in v6 were missing... Because patch 1 was updated, I reverted it from for-current and will apply this series to for-next instead to give it some more time for testing. signature.asc Description: PGP signature
Re: [CRAZY-RFF] debugfs: track open files and release on remove
On Sat, 2020-10-10 at 11:38 +0200, Greg KH wrote: > On Fri, Oct 09, 2020 at 10:48:09AM +0200, Johannes Berg wrote: > > On Fri, 2020-10-09 at 10:47 +0200, Greg KH wrote: > > > > > > I think adding the .owner everywhere would be good, and perhaps we can > > > > somehow put a check somewhere like > > > > > > > > WARN_ON(is_module_address((unsigned long)fops) && !fops->owner); > > > > > > > > to prevent the issue in the future? > > > > > > That will fail for all of the debugfs_create_* operations, as there is > > > only one set of file operations for all of the different files created > > > with these calls. > > > > Why would it fail? Those have their fops in the core debugfs code, which > > might have a .owner assigned but is probably built-in anyway? > > Bad choice of terms, it would "fail" in that this type of check would > never actually work because the debugfs code is built into the kernel, > and there is no module owner for it. But the value it is referencing is > an address in a module. Ahh. Yes and no. I mean, yes, the check wouldn't really work. But OTOH, this is exactly what the proxy_fops protects against. The _only_ thing that proxy_fops *doesn't* proxy is the ->release() method. If you have a debugfs file that's say debugfs_create_u32(), then the code is all built into the kernel, and - if ->release() even exists, I didn't check now - it would surely not dereference the pointer you gave to debugfs_create_u32(). So as long as the file is debugfs_remove()d before the pointer becomes invalid, there's no issue. The check I'm proposing (and actually wrote in my separate RFC patch that didn't seem quite as crazy) would basically protect the ->release() method only, if needed. Everything else is handled by proxy_fops. > > > Which, now that I remember it, is why we went down the proxy "solution" > > > in the first place :( > > > > Not sure I understand. That was related more to (arbitrary) files having > > to be disappeared rather than anything else? > > Isn't this the same issue? Well, not exactly? The difference is that proxy_fops basically protects the *value*, read/write/etc., but not ->release(). So it protects more against bus unbind or the like, where the *device* disappears, rather than the *code* disappearing. Now, you still need to be careful that ->release() doesn't actually access anything related to the device, of course. As long as we don't have a general revoke() at least. I guess in that sense this crazy patch actually makes things *better* than the RFC patch because it *does* call the ->release() during debugfs_remove() and therefore allows even ->release() to access data of the device or other data structures that are being removed; whereas the RFC patch I also sent doesn't protect that, it just protects the code itself. johannes
Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711
On Fri, 9 Oct 2020 at 19:10, Catalin Marinas wrote: > > On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote: > > On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi > > wrote: > > > We can move this check to IORT code and call it from arm64 if it > > > can be made to work. > > > > Finding the smallest value in the IORT, and assigning it to > > zone_dma_bits if it is < 32 should be easy. But as I understand it, > > having these separate DMA and DMA32 zones is what breaks kdump, no? So > > how is this going to fix the underlying issue? > > If zone_dma_bits is 32, ZONE_DMA32 disappears into ZONE_DMA (GFP_DMA32 > allocations fall back to ZONE_DMA). > > kdump wants DMA-able memory and, without a 30-bit ZONE_DMA, that would > be the bottom 32-bit. With the introduction of ZONE_DMA, this suddenly > became 1GB. We could change kdump to allocate ZONE_DMA32 but this one > may also be small as it lost 1GB to ZONE_DMA. However, the kdump kernel > would need to be rebuilt without ZONE_DMA since it won't have any. IIRC > (it's been a while since I looked), the kdump allocation couldn't span > multiple zones. > > In a separate thread, we try to fix kdump to use allocations above 4G as > a fallback but this only fixes platforms with enough RAM (and maybe it's > only those platforms that care about kdump). > One thing that strikes me as odd is that we are applying the same shifting logic to ZONE_DMA as we are applying to ZONE_DMA32, i.e., if DRAM starts outside of the zone, it is shifted upwards. On a typical ARM box, this gives me [0.00] Zone ranges: [0.00] DMA [mem 0x8000-0xbfff] [0.00] DMA32[mem 0xc000-0x] [0.00] Normal [mem 0x0001-0x000f] i.e., the 30-bit addressable range has bit 31 set, which is weird. I wonder if it wouldn't be better (and less problematic in the general case) to drop this logic for ZONE_DMA, and simply let it remain empty unless there is really some memory there.
