[PATCH v2 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
and 6.18 inches size. It is found in some of the Poco F1 phones.
Signed-off-by: Sumit Semwal
Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16
---
v2: remove ports node, making port@0 directly under panel@0 node.
---
.../display/panel/tianma,nt36672a.yaml| 104 ++
1 file changed, 104 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
new file mode 100644
index ..cb1799fbbd32
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tianma model NT36672A DSI Panel display driver
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a panel from Tianma is a FHD+ LCD display panel with a resolution
+ of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: tianma,nt36672a
+
+ reg:
+description: DSI virtual channel of the peripheral
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ pinctrl-names:
+description: Pinctrl for panel active and suspend
+
+ pinctrl-0:
+description: Active pinctrls
+
+ pinctrl-1:
+description: Suspend pinctrls
+
+ port@0:
+type: object
+description: DSI input port driven by master DSI
+properties:
+ reg:
+const: 0
+
+required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - pinctrl-names
+ - pinctrl-0
+ - pinctrl-1
+ - port@0
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+pinctrl-names = "panel_active", "panel_suspend";
+pinctrl-0 = <_dsi_active>;
+pinctrl-1 = <_dsi_suspend>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+ reg = <0>;
+ tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
+
+...
--
2.27.0
[PATCH v2 2/2] drm: panel: Add tianma nt36672a panel driver
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
With current AOSP, we need to increase it to 200ms - this seems to be a safe
high value to avoid a white screen occassionally.
Signed-off-by: Sumit Semwal
Cc: Benni Steini
Change-Id: Ib822ef12464abcb50d2e539d11b8983be87c31f2
---
v2: increase reset sequence timing to a safe 200ms
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++
4 files changed, 878 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b4a43a9e7fbc..2d384e51353b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5544,6 +5544,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 39055c1f0e2f..da9d74c1ec91 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1
Say Y here if you want to enable support for TPO TD043MTEA1 800x480
4.3" panel (found on the OMAP3 Pandora board).
+config DRM_PANEL_TIANMA_FHD_NT36672A
+ tristate "TIANMA NT36672A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Tianma NT36672A
+ panel. It is seen mostly in Xiaomi Poco F1 mobile phone.
+ The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel.
+ It provides a MIPI DSI interface to the host.
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index de74f282c433..303e44eb50fa 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
new file mode 100644
index ..0af3a6ff5d55
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
@@ -0,0 +1,859 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const char * const regulator_names[] = {
+ "vddio",
+ "vddpos",
+ "vddneg",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100
+};
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ const char *panel_name;
+
+ unsigned int width_mm;
+ unsigned int height_mm;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+
+ const struct panel_cmd *on_cmds_1;
+ const struct panel_cmd *on_cmds_2;
+
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+
+ struct pinctrl *pinctrl;
[PATCH v2 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is here [1] --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Tianma nt36672a panel drm: panel: Add tianma nt36672a panel driver .../display/panel/tianma,nt36672a.yaml| 104 +++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++ 5 files changed, 982 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c -- 2.27.0
Re: [PATCH v2 3/5] MIPS: Loongson64: Enlarge IO_SPACE_LIMIT
在 2020/7/21 下午10:17, Jiaxun Yang 写道: It can be very big on LS7A PCH systems. Signed-off-by: Jiaxun Yang --- arch/mips/include/asm/io.h | 3 ++- arch/mips/include/asm/mach-loongson64/spaces.h | 3 +-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h index 346fffd9e972..0072489325fa 100644 --- a/arch/mips/include/asm/io.h +++ b/arch/mips/include/asm/io.h @@ -50,8 +50,9 @@ # define __relaxed_ioswabq ioswabq /* ioswab[bwlq], __mem_ioswab[bwlq] are defined in mangle-port.h */ - +#ifndef IO_SPACE_LIMIT #define IO_SPACE_LIMIT 0x +#endif /* * On MIPS I/O ports are memory mapped, so we access them using normal diff --git a/arch/mips/include/asm/mach-loongson64/spaces.h b/arch/mips/include/asm/mach-loongson64/spaces.h index 3de0ac9d8829..fa5ea4ee8b6c 100644 --- a/arch/mips/include/asm/mach-loongson64/spaces.h +++ b/arch/mips/include/asm/mach-loongson64/spaces.h @@ -11,8 +11,7 @@ #define PCI_IOSIZESZ_16M #define MAP_BASE (PCI_IOBASE + PCI_IOSIZE) -/* Reserved at the start of PCI_IOBASE for legacy drivers */ -#define MMIO_LOWER_RESERVED0x1 +#define IO_SPACE_LIMIT PCI_IOSIZE Oops, it should be (PCI_IOSIZE - 1), will fix in next revision. Sorry for the noise. Thanks. - Jiaxun #include #endif
Re: [PATCH 1/1] ARM:dts:aspeed: Initial device tree for AMD EthanolX
On Mon, 20 Jul 2020 at 16:02, Supreeth Venkatesh
wrote:
>
> Initial introduction of AMD EthanolX platform equipped with an
> Aspeed ast2500 BMC manufactured by AMD.
>
> AMD EthanolX platform is an AMD customer reference board with an
> Aspeed ast2500 BMC manufactured by AMD.
> This adds AMD EthanolX device tree file including the flash layout
> used by EthanolX BMC machines.
>
> This also adds an entry of AMD EthanolX device tree file in Makefile.
>
> Signed-off-by: Supreeth Venkatesh
Reviewed-by: Joel Stanley
Looks good. One question about the licence.
> +++ b/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: Apache-2.0
> +// Copyright (c) 2020 AMD Inc.
Can you have a read of the licence rules and add a preferred licence.
The rules are here:
https://www.kernel.org/doc/html/latest/process/license-rules.html
This very hacky one liner will give you an idea of common licences
used by device trees:
$ git grep -h SPDX -- arch/arm/boot/dts/ | cut -c3- |sort -b | uniq -c
| sort -hr
579 SPDX-License-Identifier: GPL-2.0
305 SPDX-License-Identifier: GPL-2.0-only
222 SPDX-License-Identifier: GPL-2.0-or-later
188 SPDX-License-Identifier: (GPL-2.0+ OR MIT)
91 SPDX-License-Identifier: GPL-2.0+
72 SPDX-License-Identifier: (GPL-2.0 OR MIT)
57 SPDX-License-Identifier: GPL-2.0+ OR MIT
46 SPDX-License-Identifier: GPL-2.0-or-later OR MIT
38 SPDX-License-Identifier: GPL-2.0 OR X11
29 SPDX-License-Identifier: GPL-2.0 OR MIT
19 SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
16 SPDX-License-Identifier: GPL-2.0-only */
6 SPDX-License-Identifier: ISC
5 SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
4 SPDX-License-Identifier: (GPL-2.0+ OR X11)
4 SPDX-License-Identifier: (GPL-2.0 or MIT)
4 SPDX-License-Identifier: GPL-2.0 */
3 SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
2 SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-3-Clause) */
2 SPDX-License-Identifier: GPL-2.0-or-later */
2 SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
2 SPDX-License-Identifier: (GPL-2.0+)
2 SPDX-License-Identifier: (GPL-2.0)
2 SPDX-License-Identifier: GPL-2.0
1 SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
1 SPDX-License-Identifier: GPL-2.0+
1 SPDX-License-Identifier: GPL-2.0+
1 SPDX-License-Identifier: BSD-3-Clause
> +// Author: Supreeth Venkatesh
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include
> +
> +/ {
> + model = "AMD EthanolX BMC";
> + compatible = "amd,ethanolx-bmc", "aspeed,ast2500";
> +
> + memory@8000 {
> + reg = <0x8000 0x2000>;
> + };
> + aliases {
> + serial0 =
> + serial4 =
> + };
> + chosen {
> + stdout-path =
> + bootargs = "console=ttyS4,115200 earlyprintk";
> + };
> + leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + gpios = < ASPEED_GPIO(A, 2) GPIO_ACTIVE_LOW>;
> + };
> +
> + identify {
> + gpios = < ASPEED_GPIO(A, 3) GPIO_ACTIVE_LOW>;
> + };
> + };
> + iio-hwmon {
> + compatible = "iio-hwmon";
> + io-channels = < 0>, < 1>, < 2>, < 3>, <
> 4>;
> + };
> +};
> +
> + {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + m25p,fast-read;
> + #include "openbmc-flash-layout.dtsi"
> + };
> +};
> +
> +
> + {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_rmii1_default>;
> + clocks = < ASPEED_CLK_GATE_MAC1CLK>,
> +< ASPEED_CLK_MAC1RCLK>;
> + clock-names = "MACCLK", "RCLK";
> +};
> +
> + {
> + //Host Console
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_txd1_default
> +_rxd1_default>;
> +};
> +
> + {
> + //BMC Console
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_adc0_default
> +_adc1_default
> +_adc2_default
> +_adc3_default
> +_adc4_default>;
> +};
> +
> +// Thermal Sensors
> + {
> + status = "okay";
> +
> + lm75a@48 {
> + compatible = "national,lm75a";
> + reg = <0x48>;
> + };
> +
> + lm75a@49 {
> + compatible = "national,lm75a";
> + reg = <0x49>;
> + };
> +
> + lm75a@4a {
> + compatible = "national,lm75a";
> + reg = <0x4a>;
> + };
> +
> + lm75a@4b {
> + compatible = "national,lm75a";
> + reg = <0x4b>;
> + };
> +
> +
KMSAN: uninit-value in video_usercopy
Hello, syzbot found the following issue on: HEAD commit:14525656 compiler.h: reinstate missing KMSAN_INIT git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=15be838090 kernel config: https://syzkaller.appspot.com/x/.config?x=c534a9fad6323722 dashboard link: https://syzkaller.appspot.com/bug?extid=79d751604cb6f29fbf59 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17eb93d090 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=116da33b10 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+79d751604cb6f29fb...@syzkaller.appspotmail.com = BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 mm/kmsan/kmsan_hooks.c:428 CPU: 0 PID: 8471 Comm: syz-executor794 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1df/0x240 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 kmsan_internal_check_memory+0x238/0x3d0 mm/kmsan/kmsan.c:423 kmsan_check_memory+0xd/0x10 mm/kmsan/kmsan_hooks.c:428 instrument_copy_to_user include/linux/instrumented.h:91 [inline] _copy_to_user+0x100/0x1d0 lib/usercopy.c:30 copy_to_user include/linux/uaccess.h:161 [inline] video_put_user drivers/media/v4l2-core/v4l2-ioctl.c:3226 [inline] video_usercopy+0x248a/0x2c00 drivers/media/v4l2-core/v4l2-ioctl.c:3325 video_ioctl2+0x9f/0xb0 drivers/media/v4l2-core/v4l2-ioctl.c:3335 v4l2_ioctl+0x23f/0x270 drivers/media/v4l2-core/v4l2-dev.c:360 vfs_ioctl fs/ioctl.c:48 [inline] ksys_ioctl fs/ioctl.c:753 [inline] __do_sys_ioctl fs/ioctl.c:762 [inline] __se_sys_ioctl+0x2e9/0x410 fs/ioctl.c:760 __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:760 do_syscall_64+0xb0/0x150 arch/x86/entry/common.c:386 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x444009 Code: Bad RIP value. RSP: 002b:7ffd83706aa8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 004002e0 RCX: 00444009 RDX: 2100 RSI: c0505611 RDI: 0003 RBP: 006ce018 R08: 004002e0 R09: 004002e0 R10: R11: 0246 R12: 00401c90 R13: 00401d20 R14: R15: Local variable vb32.i@video_usercopy created at: video_put_user drivers/media/v4l2-core/v4l2-ioctl.c:3210 [inline] video_usercopy+0x20bd/0x2c00 drivers/media/v4l2-core/v4l2-ioctl.c:3325 video_put_user drivers/media/v4l2-core/v4l2-ioctl.c:3210 [inline] video_usercopy+0x20bd/0x2c00 drivers/media/v4l2-core/v4l2-ioctl.c:3325 Bytes 52-55 of 80 are uninitialized Memory access of size 80 starts at a41d80dcfce0 = --- 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. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
KMSAN: uninit-value in ucma_connect
Hello, syzbot found the following issue on: HEAD commit:14525656 compiler.h: reinstate missing KMSAN_INIT git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=124a081710 kernel config: https://syzkaller.appspot.com/x/.config?x=c534a9fad6323722 dashboard link: https://syzkaller.appspot.com/bug?extid=7446526858b83c8828b2 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13db936f10 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16c18d7d10 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+7446526858b83c882...@syzkaller.appspotmail.com = BUG: KMSAN: uninit-value in ucma_connect+0x2aa/0xab0 drivers/infiniband/core/ucma.c:1091 CPU: 0 PID: 8457 Comm: syz-executor069 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1df/0x240 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 ucma_connect+0x2aa/0xab0 drivers/infiniband/core/ucma.c:1091 ucma_write+0x5c5/0x630 drivers/infiniband/core/ucma.c:1764 do_loop_readv_writev fs/read_write.c:737 [inline] do_iter_write+0x710/0xdc0 fs/read_write.c:1020 vfs_writev fs/read_write.c:1091 [inline] do_writev+0x42d/0x8f0 fs/read_write.c:1134 __do_sys_writev fs/read_write.c:1207 [inline] __se_sys_writev+0x9b/0xb0 fs/read_write.c:1204 __x64_sys_writev+0x4a/0x70 fs/read_write.c:1204 do_syscall_64+0xb0/0x150 arch/x86/entry/common.c:386 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4402a9 Code: Bad RIP value. RSP: 002b:7ffd6e4541e8 EFLAGS: 0246 ORIG_RAX: 0014 RAX: ffda RBX: 004002c8 RCX: 004402a9 RDX: 0001 RSI: 20c0 RDI: 0005 RBP: 006ca018 R08: 004002c8 R09: 004002c8 R10: R11: 0246 R12: 00401ab0 R13: 00401b40 R14: R15: Local variable cmd@ucma_connect created at: ucma_connect+0xe1/0xab0 drivers/infiniband/core/ucma.c:1082 ucma_connect+0xe1/0xab0 drivers/infiniband/core/ucma.c:1082 = --- 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. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
KMSAN: uninit-value in geneve_xmit
Hello, syzbot found the following issue on: HEAD commit:14525656 compiler.h: reinstate missing KMSAN_INIT git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=1339608710 kernel config: https://syzkaller.appspot.com/x/.config?x=c534a9fad6323722 dashboard link: https://syzkaller.appspot.com/bug?extid=7ebc2e088af5e4c0c9fa compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1105601710 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=102dbc1090 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+7ebc2e088af5e4c0c...@syzkaller.appspotmail.com = BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:909 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x2a59/0x2bf0 drivers/net/geneve.c:1005 CPU: 1 PID: 2303 Comm: kworker/1:2 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events iterate_cleanup_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1df/0x240 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 geneve_xmit_skb drivers/net/geneve.c:909 [inline] geneve_xmit+0x2a59/0x2bf0 drivers/net/geneve.c:1005 __netdev_start_xmit include/linux/netdevice.h:4611 [inline] netdev_start_xmit include/linux/netdevice.h:4625 [inline] xmit_one net/core/dev.c:3556 [inline] dev_hard_start_xmit+0x50e/0xa70 net/core/dev.c:3572 __dev_queue_xmit+0x2f8d/0x3b20 net/core/dev.c:4131 dev_queue_xmit+0x4b/0x60 net/core/dev.c:4164 neigh_hh_output include/net/neighbour.h:498 [inline] neigh_output include/net/neighbour.h:507 [inline] ip6_finish_output2+0x2057/0x2620 net/ipv6/ip6_output.c:117 __ip6_finish_output+0x824/0x8e0 net/ipv6/ip6_output.c:143 ip6_finish_output+0x166/0x410 net/ipv6/ip6_output.c:153 NF_HOOK_COND include/linux/netfilter.h:296 [inline] ip6_output+0x60a/0x770 net/ipv6/ip6_output.c:176 dst_output include/net/dst.h:443 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] mld_sendpack+0xeba/0x13d0 net/ipv6/mcast.c:1679 mld_send_cr net/ipv6/mcast.c:1975 [inline] mld_ifc_timer_expire+0x1158/0x1750 net/ipv6/mcast.c:2474 call_timer_fn+0x218/0x510 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers+0xd20/0x11c0 kernel/time/timer.c:1773 run_timer_softirq+0x2d/0x50 kernel/time/timer.c:1786 __do_softirq+0x311/0x83d kernel/softirq.c:293 asm_call_on_stack+0x12/0x20 arch/x86/entry/entry_64.S:711 __run_on_irqstack arch/x86/include/asm/irq_stack.h:23 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:50 [inline] do_softirq_own_stack+0x7c/0xa0 arch/x86/kernel/irq_64.c:77 invoke_softirq kernel/softirq.c:390 [inline] __irq_exit_rcu+0x226/0x270 kernel/softirq.c:420 irq_exit_rcu+0xe/0x10 kernel/softirq.c:432 sysvec_apic_timer_interrupt+0x107/0x130 arch/x86/kernel/apic/apic.c:1091 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:593 RIP: 0010:rcu_all_qs+0x1/0x240 kernel/rcu/tree_plugin.h:808 Code: 00 4c 89 ff e8 20 d2 ff ff 5b 41 5e 41 5f 5d c3 41 8b be 88 0c 00 00 e8 4d 9e 8d 00 eb c9 90 66 2e 0f 1f 84 00 00 00 00 00 55 <48> 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 20 65 48 8b 04 25 28 RSP: 0018:b5cc8513bac0 EFLAGS: 0286 RAX: 8000 RBX: 0001 RCX: RDX: RSI: 0004 RDI: 00016d0c RBP: b5cc8513bae0 R08: f187000f R09: 9ba6afffb000 R10: 0004 R11: acbc7b70 R12: b0221158 R13: R14: 9ba6a7bc46d8 R15: 0e06 get_next_corpse net/netfilter/nf_conntrack_core.c:2239 [inline] nf_ct_iterate_cleanup+0x5c6/0x710 net/netfilter/nf_conntrack_core.c:2261 nf_ct_iterate_cleanup_net+0x182/0x230 net/netfilter/nf_conntrack_core.c:2346 iterate_cleanup_work+0x97/0x1c0 net/netfilter/nf_nat_masquerade.c:216 process_one_work+0x1540/0x1f30 kernel/workqueue.c:2269 worker_thread+0xed2/0x23f0 kernel/workqueue.c:2415 kthread+0x515/0x550 kernel/kthread.c:292 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:310 __msan_chain_origin+0x50/0x90 mm/kmsan/kmsan_instr.c:165 geneve_changelink+0xcbb/0xee0 drivers/net/geneve.c:1652 __rtnl_newlink net/core/rtnetlink.c:3255 [inline] rtnl_newlink+0x3032/0x3900 net/core/rtnetlink.c:3397 rtnetlink_rcv_msg+0x1184/0x15c0 net/core/rtnetlink.c:5460 netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2469 rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5478 netlink_unicast_kernel net/netlink/af_netlink.c:1303
KMSAN: uninit-value in xa_load
Hello, syzbot found the following issue on: HEAD commit:14525656 compiler.h: reinstate missing KMSAN_INIT git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=105d732090 kernel config: https://syzkaller.appspot.com/x/.config?x=c534a9fad6323722 dashboard link: https://syzkaller.appspot.com/bug?extid=086ab5ca9eafd2379aa6 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1303736f10 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1209608710 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+086ab5ca9eafd2379...@syzkaller.appspotmail.com = BUG: KMSAN: uninit-value in xas_start lib/xarray.c:190 [inline] BUG: KMSAN: uninit-value in xas_load lib/xarray.c:233 [inline] BUG: KMSAN: uninit-value in xa_load+0x83b/0x8a0 lib/xarray.c:1305 CPU: 0 PID: 8440 Comm: syz-executor560 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1df/0x240 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 xas_start lib/xarray.c:190 [inline] xas_load lib/xarray.c:233 [inline] xa_load+0x83b/0x8a0 lib/xarray.c:1305 _ucma_find_context drivers/infiniband/core/ucma.c:139 [inline] ucma_get_ctx+0x7f/0x310 drivers/infiniband/core/ucma.c:152 ucma_get_ctx_dev drivers/infiniband/core/ucma.c:175 [inline] ucma_accept+0x259/0xc90 drivers/infiniband/core/ucma.c:1148 ucma_write+0x5c5/0x630 drivers/infiniband/core/ucma.c:1764 do_loop_readv_writev fs/read_write.c:737 [inline] do_iter_write+0x710/0xdc0 fs/read_write.c:1020 vfs_writev fs/read_write.c:1091 [inline] do_writev+0x42d/0x8f0 fs/read_write.c:1134 __do_sys_writev fs/read_write.c:1207 [inline] __se_sys_writev+0x9b/0xb0 fs/read_write.c:1204 __x64_sys_writev+0x4a/0x70 fs/read_write.c:1204 do_syscall_64+0xb0/0x150 arch/x86/entry/common.c:386 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4402e9 Code: Bad RIP value. RSP: 002b:7fffa058a4f8 EFLAGS: 0246 ORIG_RAX: 0014 RAX: ffda RBX: 004002c8 RCX: 004402e9 RDX: 0001 RSI: 20c0 RDI: 0003 RBP: 006ca018 R08: R09: 004002c8 R10: R11: 0246 R12: 00401af0 R13: 00401b80 R14: R15: Local variable cmd@ucma_accept created at: ucma_accept+0x95/0xc90 drivers/infiniband/core/ucma.c:1137 ucma_accept+0x95/0xc90 drivers/infiniband/core/ucma.c:1137 = --- 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. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
linux-next: manual merge of the devicetree tree with the drm tree
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
between commit:
5a2e9b658cdc ("dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml")
from the drm tree and commit:
382646090f7f ("dt-bindings: drm/bridge: Replace HTTP links with HTTPS ones")
from the devicetree tree.
I fixed it up (I delete the file and adde the following merge fix
patch) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
From: Stephen Rothwell
Date: Wed, 22 Jul 2020 15:47:22 +1000
Subject: [PATCH] fix for "dt-bindings: drm/bridge: Replace HTTP links with
HTTPS ones"
Signed-off-by: Stephen Rothwell
---
.../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
index be10e8cf31e1..f8622bd0f61e 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -11,7 +11,7 @@ maintainers:
description: |
The Texas Instruments SN65DSI86 bridge takes MIPI DSI in and outputs eDP.
-
http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
+
https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
properties:
compatible:
--
2.27.0
--
Cheers,
Stephen Rothwell
pgp8hHh07BimE.pgp
Description: OpenPGP digital signature
RE: [EXT] Re: [PATCH] net: dsa: Add protocol support for 802.1AD when adding or deleting vlan for dsa switch and port
Hi Florian, Thanks for your reply! I had posted my patch for switch port driver, the email title is "net: dsa: ocelot: Add support for QinQ Operation", Best Regards! hongbo -Original Message- From: Florian Fainelli Sent: 2020年7月22日 1:55 To: Hongbo Wang ; Xiaoliang Yang ; allan.niel...@microchip.com; Po Liu ; Claudiu Manoil ; Alexandru Marginean ; Vladimir Oltean ; Leo Li ; Mingkai Hu ; and...@lunn.ch; vivien.dide...@gmail.com; da...@davemloft.net; j...@resnulli.us; ido...@idosch.org; k...@kernel.org; vinicius.go...@intel.com; niko...@cumulusnetworks.com; ro...@cumulusnetworks.com; net...@vger.kernel.org; linux-kernel@vger.kernel.org; horatiu.vul...@microchip.com; alexandre.bell...@bootlin.com; unglinuxdri...@microchip.com; linux-de...@linux.nxdi.nxp.com Subject: [EXT] Re: [PATCH] net: dsa: Add protocol support for 802.1AD when adding or deleting vlan for dsa switch and port Caution: EXT Email On 7/21/20 4:02 AM, hongbo.w...@nxp.com wrote: > From: "hongbo.wang" > > the following command will be supported: > Add VLAN: > ip link add link swp1 name swp1.100 type vlan protocol 802.1ad id > 100 Delete VLAN: > ip link del link swp1 name swp1.100 > > when adding vlan, this patch only set protocol for user port, cpu port > don't care it, so set parameter proto to 0 for cpu port. My previous feedback has been partially addressed, can you also post the switch driver changes that are going to implement the driver side changes? Presumably you must act on the 802.1AD programming request in the switch driver somehow, right? -- Florian
Re: [PATCH v3 2/3] coccinelle: api: extend memdup_user rule with vmemdup_user()
>>> +@depends on patch@ >>> +expression from,to,size; >>> +identifier l1,l2; >>> +@@ >>> + >>> +- to = \(kvmalloc\|kvzalloc\)(size,\(GFP_KERNEL\|GFP_USER\)); >>> ++ to = vmemdup_user(from,size); >> >> I propose to combine the desired adjustment with the previous SmPL rule >> by using another disjunction. How do you think about to check run time characteristics for the following SmPL script sketches? A) @R1@ @@ // Change something @R2@ @@ // Change another thing B) @Replacement_with_disjunction@ @@ ( // R1: Change something | // R2: Change another thing ) >>> +@rv depends on !patch@ >>> +expression from,to,size; >>> +position p; >>> +statement S1,S2; >>> +@@ >>> + >>> +* to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\)); >>> + if (to==NULL || ...) S1 >>> + if (copy_from_user(to, from, size) != 0) >>> + S2 >> >> * Can it be helpful to omit the SmPL asterisk functionality from >> the operation modes “org” and “report”? >> >> * Should the operation mode “context” work without an extra position >> metavariable? > > This is fine as is in all three aspects. Is every technique from the Coccinelle software required for each operation mode in such data processing approaches? Regards, Markus
Re: [PATCH v2 02/10] powerpc/smp: Merge Power9 topology with Power topology
On Tue, Jul 21, 2020 at 05:08:06PM +0530, Srikar Dronamraju wrote:
> A new sched_domain_topology_level was added just for Power9. However the
> same can be achieved by merging powerpc_topology with power9_topology
> and makes the code more simpler especially when adding a new sched
> domain.
>
> Cc: linuxppc-dev
> Cc: LKML
> Cc: Michael Ellerman
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Nick Piggin
> Cc: Oliver OHalloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Anton Blanchard
> Cc: Gautham R Shenoy
> Cc: Vaidyanathan Srinivasan
> Cc: Jordan Niethe
> Signed-off-by: Srikar Dronamraju
> ---
> Changelog v1 -> v2:
> powerpc/smp: Merge Power9 topology with Power topology
> Replaced a reference to cpu_smt_mask with per_cpu(cpu_sibling_map, cpu)
> since cpu_smt_mask is only defined under CONFIG_SCHED_SMT
>
> arch/powerpc/kernel/smp.c | 33 ++---
> 1 file changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 680c0edcc59d..0e0b118d9b6e 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1315,7 +1315,7 @@ int setup_profiling_timer(unsigned int multiplier)
> }
>
> #ifdef CONFIG_SCHED_SMT
> -/* cpumask of CPUs with asymetric SMT dependancy */
> +/* cpumask of CPUs with asymmetric SMT dependency */
> static int powerpc_smt_flags(void)
> {
> int flags = SD_SHARE_CPUCAPACITY | SD_SHARE_PKG_RESOURCES;
> @@ -1328,14 +1328,6 @@ static int powerpc_smt_flags(void)
> }
> #endif
>
> -static struct sched_domain_topology_level powerpc_topology[] = {
> -#ifdef CONFIG_SCHED_SMT
> - { cpu_smt_mask, powerpc_smt_flags, SD_INIT_NAME(SMT) },
> -#endif
> - { cpu_cpu_mask, SD_INIT_NAME(DIE) },
> - { NULL, },
> -};
> -
> /*
> * P9 has a slightly odd architecture where pairs of cores share an L2 cache.
> * This topology makes it *much* cheaper to migrate tasks between adjacent
> cores
> @@ -1353,7 +1345,13 @@ static int powerpc_shared_cache_flags(void)
> */
> static const struct cpumask *shared_cache_mask(int cpu)
> {
> - return cpu_l2_cache_mask(cpu);
> + if (shared_caches)
> + return cpu_l2_cache_mask(cpu);
> +
> + if (has_big_cores)
> + return cpu_smallcore_mask(cpu);
> +
> + return per_cpu(cpu_sibling_map, cpu);
> }
It might be helpful to enumerate the consequences of this change:
With this patch, on POWER7 and POWER8
SMT and CACHE domains' cpumasks will both be
per_cpu(cpu_sibling_map, cpu).
On POWER7 SMT level flags has the following
(SD_SHARE_CPUCAPACITY | SD_SHARE_PKG_RESOURCES | SD_ASYM_PACKING)
On POWER8 SMT level flags has the following
(SD_SHARE_CPUCAPACITY | SD_SHARE_PKG_RESOURCES).
On both POWER7 and POWER8, CACHE level flags only has
SD_SHARE_PKG_RESOURCES
Thus, on both POWER7 and POWER8, since the SMT and CACHE cpumasks
are the same and since CACHE has no additional flags which SMT does
not, the parent domain CACHE will be degenerated.
Hence we will have SMT --> DIE --> NUMA as before without the
patch. So the patch introduces no behavioural change. Only change
is an additional degeneration of the CACHE domain.
On POWER9 : Baremetal.
SMT level cpumask = per_cpu(cpu_sibling_map, cpu)
Since the caches are shared for a pair of two cores,
CACHE level cpumask = cpu_l2_cache_mask(cpu)
Thus, we will have SMT --> CACHE --> DIE --> NUMA as before. No
behavioural change.
On POWER9 : LPAR
SMT level cpumask = cpu_smallcore_mask(cpu).
Since the caches are shared,
CACHE level cpumask = cpu_l2_cache_mask(cpu).
Thus, we will have SMT --> CACHE --> DIE --> NUMA as before. Again
no change in behaviour.
Reviewed-by: Gautham R. Shenoy
--
Thanks and Regards
gautham.
[PATCH] net: dsa: ocelot: Add support for QinQ Operation
From: "hongbo.wang"
This featue can be test using network test tools
TX-tool -> swp0 -> swp1 -> RX-tool
TX-tool simulates Customer that will send and receive packets with single
VLAN tag(CTAG), RX-tool simulates Service-Provider that will send and
receive packets with double VLAN tag(STAG and CTAG). This refers to
"4.3.3 Provider Bridges and Q-in-Q Operation" in VSC99599_1_00_TS.pdf.
The related test commands:
1.
ip link add dev br0 type bridge
ip link set dev swp0 master br0
ip link set dev swp1 master br0
2.
ip link add link swp0 name swp0.111 type vlan id 111
ip link add link swp1 name swp1.111 type vlan protocol 802.1ad id 111
3.
bridge vlan add dev swp0 vid 100 pvid
bridge vlan add dev swp1 vid 100
bridge vlan del dev swp1 vid 1 pvid
bridge vlan add dev swp1 vid 200 pvid untagged
Result:
Customer(tpid:8100 vid:111) -> swp0 -> swp1 -> Service-Provider(STAG \
tpid:88A8 vid:100, CTAG tpid:8100 vid:111)
Signed-off-by: hongbo.wang
---
drivers/net/dsa/ocelot/felix.c | 8 ++
drivers/net/ethernet/mscc/ocelot.c | 44 --
include/soc/mscc/ocelot.h | 1 +
3 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index c69d9592a2b7..12b46cb6549c 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -132,9 +132,13 @@ static void felix_vlan_add(struct dsa_switch *ds, int port,
{
struct ocelot *ocelot = ds->priv;
u16 flags = vlan->flags;
+ struct ocelot_port *ocelot_port = ocelot->ports[port];
u16 vid;
int err;
+ if (vlan->proto == ETH_P_8021AD)
+ ocelot_port->qinq_mode = true;
+
if (dsa_is_cpu_port(ds, port))
flags &= ~BRIDGE_VLAN_INFO_UNTAGGED;
@@ -154,9 +158,13 @@ static int felix_vlan_del(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan)
{
struct ocelot *ocelot = ds->priv;
+ struct ocelot_port *ocelot_port = ocelot->ports[port];
u16 vid;
int err;
+ if (vlan->proto == ETH_P_8021AD)
+ ocelot_port->qinq_mode = false;
+
for (vid = vlan->vid_begin; vid <= vlan->vid_end; vid++) {
err = ocelot_vlan_del(ocelot, port, vid);
if (err) {
diff --git a/drivers/net/ethernet/mscc/ocelot.c
b/drivers/net/ethernet/mscc/ocelot.c
index f2d94b026d88..621277e875a5 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -144,6 +144,8 @@ static int ocelot_port_set_native_vlan(struct ocelot
*ocelot, int port,
{
struct ocelot_port *ocelot_port = ocelot->ports[port];
u32 val = 0;
+ u32 tag_tpid = 0;
+ u32 port_tpid = 0;
if (ocelot_port->vid != vid) {
/* Always permit deleting the native VLAN (vid = 0) */
@@ -156,8 +158,14 @@ static int ocelot_port_set_native_vlan(struct ocelot
*ocelot, int port,
ocelot_port->vid = vid;
}
- ocelot_rmw_gix(ocelot, REW_PORT_VLAN_CFG_PORT_VID(vid),
- REW_PORT_VLAN_CFG_PORT_VID_M,
+ if (ocelot_port->qinq_mode)
+ port_tpid = REW_PORT_VLAN_CFG_PORT_TPID(ETH_P_8021AD);
+ else
+ port_tpid = REW_PORT_VLAN_CFG_PORT_TPID(ETH_P_8021Q);
+
+ ocelot_rmw_gix(ocelot, REW_PORT_VLAN_CFG_PORT_VID(vid) | port_tpid,
+ REW_PORT_VLAN_CFG_PORT_VID_M |
+ REW_PORT_VLAN_CFG_PORT_TPID_M,
REW_PORT_VLAN_CFG, port);
if (ocelot_port->vlan_aware && !ocelot_port->vid)
@@ -180,12 +188,28 @@ static int ocelot_port_set_native_vlan(struct ocelot
*ocelot, int port,
else
/* Tag all frames */
val = REW_TAG_CFG_TAG_CFG(3);
+
+ if (ocelot_port->qinq_mode)
+ tag_tpid = REW_TAG_CFG_TAG_TPID_CFG(1);
+ else
+ tag_tpid = REW_TAG_CFG_TAG_TPID_CFG(0);
} else {
- /* Port tagging disabled. */
- val = REW_TAG_CFG_TAG_CFG(0);
+ if (ocelot_port->qinq_mode) {
+ if (ocelot_port->vid)
+ val = REW_TAG_CFG_TAG_CFG(1);
+ else
+ val = REW_TAG_CFG_TAG_CFG(3);
+
+ tag_tpid = REW_TAG_CFG_TAG_TPID_CFG(1);
+ } else {
+ /* Port tagging disabled. */
+ val = REW_TAG_CFG_TAG_CFG(0);
+ tag_tpid = REW_TAG_CFG_TAG_TPID_CFG(0);
+ }
}
- ocelot_rmw_gix(ocelot, val,
- REW_TAG_CFG_TAG_CFG_M,
+
+ ocelot_rmw_gix(ocelot, val | tag_tpid,
+ REW_TAG_CFG_TAG_CFG_M | REW_TAG_CFG_TAG_TPID_CFG_M,
REW_TAG_CFG, port);
return
Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone
On Tue, 21 Jul 2020 21:50:42 PDT (-0700), m...@ellerman.id.au wrote: Benjamin Herrenschmidt writes: On Tue, 2020-07-21 at 16:48 -0700, Palmer Dabbelt wrote: > Why ? Branch distance limits ? You can't use trampolines ? Nothing fundamental, it's just that we don't have a large code model in the C compiler. As a result all the global symbols are resolved as 32-bit PC-relative accesses. We could fix this with a fast large code model, but then the kernel would need to relax global symbol references in modules and we don't even do that for the simple code models we have now. FWIW, some of the proposed large code models are essentially just split-PLT/GOT and therefor don't require relaxation, but at that point we're essentially PIC until we have more that 2GiB of kernel text -- and even then, we keep all the performance issues. My memory might be out of date but I *think* we do it on powerpc without going to a large code model, but just having the in-kernel linker insert trampolines. We build modules with the large code model, and always have AFAIK: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/Makefile?commit=4fa640dc52302b5e62b01b05c755b055549633ae#n129 # -mcmodel=medium breaks modules because it uses 32bit offsets from # the TOC pointer to create pointers where possible. Pointers into the # percpu data area are created by this method. # # The kernel module loader relocates the percpu data section from the # original location (starting with 0xd...) to somewhere in the base # kernel percpu data space (starting with 0xc...). We need a full # 64bit relocation for this to work, hence -mcmodel=large. KBUILD_CFLAGS_MODULE += -mcmodel=large Well, a fast large code model would solve a lot of problems :). Unfortunately we just don't have enough people working on this stuff to do that. It's a somewhat tricky thing to do on RISC-V as there aren't any quick sequences for long addresses, but I don't think we're that much worse off than everyone else. At some point I had a bunch of designs written up, but they probably went along with my SiFive computer. I think we ended up decided that the best bet would be to distribute constant tables throughout the text such that they're accessible via the 32-bit PC-relative loads at any point -- essentially the multi-GOT stuff that MIPS used for big objects. Doing that well is a lot of work and doing it poorly is just as slow as PIC, so we never got around to it. We also insert trampolines for branches, but IIUC that's a separate issue. "PowerPC branch trampolines" points me here https://sourceware.org/binutils/docs-2.20/ld/PowerPC-ELF32.html . That sounds like what we're doing already in the medium code models: we have short and medium control transfer sequences, linker relaxation optimizes them when possible. Since we rely on linker relaxation pretty heavily we just don't bother with the smaller code model: it'd be a 12-bit address space for data and a 21-bit address space for text (with 13-bit maximum function size). Instead of building out such a small code model we just spent time improving the linker.
Re: [PATCH v3] Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation
On 2020-07-22, Masahiro Yamada wrote: On Wed, Jul 22, 2020 at 9:14 AM Fangrui Song wrote: On 2020-07-22, Masahiro Yamada wrote: >On Wed, Jul 22, 2020 at 2:31 AM 'Fangrui Song' via Clang Built Linux > wrote: >> >> When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if >> $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit, >> GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to >> /usr/bin/ and Clang as of 11 will search for both >> $(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle. >> >> GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle, >> $(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice, >> $(prefix)aarch64-linux-gnu/$needle rarely contains executables. >> >> To better model how GCC's -B/--prefix takes in effect in practice, newer >> Clang (since >> https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90) >> only searches for $(prefix)$needle. Currently it will find /usr/bin/as >> instead of /usr/bin/aarch64-linux-gnu-as. >> >> Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE) >> (/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the >> appropriate cross compiling GNU as (when -no-integrated-as is in >> effect). >> >> Cc: sta...@vger.kernel.org >> Reported-by: Nathan Chancellor >> Signed-off-by: Fangrui Song >> Reviewed-by: Nathan Chancellor >> Tested-by: Nathan Chancellor >> Tested-by: Nick Desaulniers >> Link: https://github.com/ClangBuiltLinux/linux/issues/1099 >> --- >> Changes in v2: >> * Updated description to add tags and the llvm-project commit link. >> * Fixed a typo. >> >> Changes in v3: >> * Add Cc: sta...@vger.kernel.org >> --- >> Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Makefile b/Makefile >> index 0b5f8538bde5..3ac83e375b61 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -567,7 +567,7 @@ ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),) >> ifneq ($(CROSS_COMPILE),) >> CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%)) >> GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) >> -CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR) >> +CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE) > > > >CROSS_COMPILE may contain the directory path >to the cross toolchains. > > >For example, I use aarch64-linux-gnu-* >installed in >/home/masahiro/tools/aarch64-linaro-7.5/bin > > > >Basically, there are two ways to use it. > >[1] >PATH=$PATH:/home/masahiro/tools/aarch64-linaro-7.5/bin >CROSS_COMPILE=aarch64-linux-gnu- > > >[2] >Without setting PATH, >CROSS_COMPILE=~/tools/aarch64-linaro-7.5/bin/aarch64-linux-gnu- > > > >I usually do [2] (and so does intel's 0day bot). > > > >This patch works for the use-case [1] >but if I do [2], --prefix is set to a strange path: > >--prefix=/home/masahiro/tools/aarch64-linaro-7.5/bin//home/masahiro/tools/aarch64-linaro-7.5/bin/aarch64-linux-gnu- Thanks. I did not know the use-case [2]. This explains why there is a `$(notdir ...)` in `CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))` > > >Interestingly, the build is still successful. >Presumably Clang searches for more paths >when $(prefix)$needle is not found ? The priority order is: -B(--prefix), COMPILER_PATH, detected gcc-cross paths (In GCC, -B paths get prepended to the COMPILER_PATH list. Clang<=11 incorrectly adds -B to the COMPILER_PATH list. I have fixed it for 12.0.0) If -B fails, the detected gcc-cross paths may still be able to find /usr/bin/aarch64-linux-gnu- For example, on my machine (a variant of Debian testing), Clang finds $(realpath /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/as), which is /usr/bin/aarch64-linux-gnu-as > >I applied your patch and added -v option >to see which assembler was internally invoked: > > "/home/masahiro/tools/aarch64-linaro-7.5/lib/gcc/aarch64-linux-gnu/7.5.0/../../../../aarch64-linux-gnu/bin/as" >-EL -I ./arch/arm64/include -I ./arch/arm64/include/generated -I >./include -I ./arch/arm64/include/uapi -I >./arch/arm64/include/generated/uapi -I ./include/uapi -I >./include/generated/uapi -o kernel/smp.o /tmp/smp-2ec2c7.s > > >Ok, it looks like Clang found an alternative path >to the correct 'as'. > > > > >But, to keep the original behavior for both [1] and [2], >how about this? > >CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) > > > >Then, I can get this: > > "/home/masahiro/tools/aarch64-linaro-7.5/bin/aarch64-linux-gnu-as" >-EL -I ./arch/arm64/include -I ./arch/arm64/include/generated -I >./include -I ./arch/arm64/include/uapi -I >./arch/arm64/include/generated/uapi -I ./include/uapi -I >./include/generated/uapi -o kernel/smp.o /tmp/smp-16d76f.s This looks good. Agreed that `--prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))` should work for both [1] and [2]. Shall I send a v4? Or you are kind enough that you'll just add your Signed-off-by: tag and fix that for me? :) I fixed
[RFC PATCH] bpftool btf: Add prefix option to dump C
When bpftool dumps types and enum members into a header file for
inclusion the names match those in the original source. If the same
header file needs to be included in the original source and the bpf
program, the names of structs, unions, typedefs and enum members will
have naming collisions.
To avoid these collisions an approach is to redeclare the header file
types and enum members, which leads to duplication and possible
inconsistencies. Another approach is to use preprocessor macros
to rename conflicting names, but this can be cumbersome if there are
many conflicts.
This patch adds a prefix option for the dumped names. Use of this option
can avoid name conflicts and compile time errors.
Signed-off-by: Ian Rogers
---
.../bpf/bpftool/Documentation/bpftool-btf.rst | 7 ++-
tools/bpf/bpftool/btf.c | 18 ++---
tools/lib/bpf/btf.h | 1 +
tools/lib/bpf/btf_dump.c | 20 +--
4 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/tools/bpf/bpftool/Documentation/bpftool-btf.rst
b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
index 896f4c6c2870..85d66bc69634 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-btf.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
@@ -20,7 +20,7 @@ BTF COMMANDS
=
| **bpftool** **btf** { **show** | **list** } [**id** *BTF_ID*]
-| **bpftool** **btf dump** *BTF_SRC* [**format** *FORMAT*]
+| **bpftool** **btf dump** *BTF_SRC* [**format** *FORMAT*] [**prefix**
*PREFIX*]
| **bpftool** **btf help**
|
| *BTF_SRC* := { **id** *BTF_ID* | **prog** *PROG* | **map** *MAP*
[{**key** | **value** | **kv** | **all**}] | **file** *FILE* }
@@ -66,6 +66,11 @@ DESCRIPTION
output format. Raw (**raw**) or C-syntax (**c**) output
formats are supported.
+ With the C-syntax format the **prefix** option can
+ be used to prefix all identifiers and enum members
+ with *PREFIX*. This is useful to avoid naming
+ collisions.
+
**bpftool btf help**
Print short help message.
diff --git a/tools/bpf/bpftool/btf.c b/tools/bpf/bpftool/btf.c
index fc9bc7a23db6..6a428636fa6f 100644
--- a/tools/bpf/bpftool/btf.c
+++ b/tools/bpf/bpftool/btf.c
@@ -379,12 +379,15 @@ static void __printf(2, 0) btf_dump_printf(void *ctx,
}
static int dump_btf_c(const struct btf *btf,
- __u32 *root_type_ids, int root_type_cnt)
+ __u32 *root_type_ids, int root_type_cnt, const char
*name_prefix)
{
struct btf_dump *d;
int err = 0, i;
+ struct btf_dump_opts opts = {
+ .name_prefix = name_prefix,
+ };
- d = btf_dump__new(btf, NULL, NULL, btf_dump_printf);
+ d = btf_dump__new(btf, NULL, , btf_dump_printf);
if (IS_ERR(d))
return PTR_ERR(d);
@@ -478,6 +481,7 @@ static int do_dump(int argc, char **argv)
bool dump_c = false;
__u32 btf_id = -1;
const char *src;
+ const char *c_prefix = NULL;
int fd = -1;
int err;
@@ -583,6 +587,14 @@ static int do_dump(int argc, char **argv)
goto done;
}
NEXT_ARG();
+ } else if (is_prefix(*argv, "prefix")) {
+ NEXT_ARG();
+ if (argc < 1 || !*argv) {
+ p_err("expecting value for 'prefix' option\n");
+ goto done;
+ }
+ c_prefix = *argv;
+ NEXT_ARG();
} else {
p_err("unrecognized option: '%s'", *argv);
goto done;
@@ -608,7 +620,7 @@ static int do_dump(int argc, char **argv)
err = -ENOTSUP;
goto done;
}
- err = dump_btf_c(btf, root_type_ids, root_type_cnt);
+ err = dump_btf_c(btf, root_type_ids, root_type_cnt, c_prefix);
} else {
err = dump_btf_raw(btf, root_type_ids, root_type_cnt);
}
diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
index 491c7b41ffdc..fea4baab00bd 100644
--- a/tools/lib/bpf/btf.h
+++ b/tools/lib/bpf/btf.h
@@ -117,6 +117,7 @@ struct btf_dump;
struct btf_dump_opts {
void *ctx;
+ const char *name_prefix;
};
typedef void (*btf_dump_printf_fn_t)(void *ctx, const char *fmt, va_list args);
diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c
index e1c344504cae..baf2b4d82e1e 100644
--- a/tools/lib/bpf/btf_dump.c
+++ b/tools/lib/bpf/btf_dump.c
@@ -138,6 +138,7 @@ struct btf_dump *btf_dump__new(const struct btf *btf,
d->btf_ext = btf_ext;
d->printf_fn = printf_fn;
d->opts.ctx = opts ? opts->ctx : NULL;
+ d->opts.name_prefix =
[no subject]
Schönen Tag,Wir sind zuverlässige, vertrauenswürdige Kreditgeber, Wir bieten Darlehen an Unternehmen und Privatpersonen zu niedrigen und günstigen Zinssatz von 2%. Sind Sie auf der Suche nach einem Business-Darlehen, persönliche Darlehen, Schuldenkonsolidierung, unbesicherte Darlehen, Venture Capital. Kontaktieren Sie uns mit Name, Land, Darlehensbetrag, Dauer und Telefonnummer.GrüßeHerr DA COSTA DARREN FAY
Re: [PATCH 0/3] Add 3 new keycodes and use them for 3 new hotkeys on new Lenovo Thinkpads
On Sun, Jul 19, 2020 at 07:56:49PM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 17 Jul 2020, Hans de Goede wrote: > > This is a simple patch-series adding support for 3 new hotkeys found > > on various new Lenovo Thinkpad models. > > For all three patches, pending an ack for the new keycodes by the input > maintainers: > > Acked-by: Henrique de Moraes Holschuh Do you want me to merge all 3 through input tree? Thanks. -- Dmitry
RE
Hallo, Sie haben eine Spende in Hhe von 2.800.000,00 . Ich habe die America-Lotterie in Amerika im Wert von 343 Millionen Dollar gewonnen und einen Teil davon an fnf glckliche Menschen und Wohlttigkeitsorganisationen gespendet, um an das Leben meines verstorbenen Sohnes zu erinnern, der an Krebs gestorben ist Viele Menschen, die von diesem Coronavirus betroffen sind, kontaktieren mich fr weitere Informationen unter; callumfoundatio...@outlook.com Gre Mrs.Lerynne West
[PATCH 1/2] xtensa: move vmlinux.bin[.gz] to boot subdirectory
vmlinux.bin and vmlinux.bin.gz are always rebuilt in the kernel build process. Add them to 'targets' and move them to the boot subdirectory where their rules are. Update make rules that refer to them. Signed-off-by: Max Filippov --- arch/xtensa/boot/Makefile | 11 ++- arch/xtensa/boot/boot-elf/Makefile | 4 ++-- arch/xtensa/boot/boot-redboot/Makefile | 4 ++-- 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/arch/xtensa/boot/Makefile b/arch/xtensa/boot/Makefile index 1a14d38d9b33..801fe30b4dfe 100644 --- a/arch/xtensa/boot/Makefile +++ b/arch/xtensa/boot/Makefile @@ -17,6 +17,7 @@ BIG_ENDIAN:= $(shell echo __XTENSA_EB__ | $(CC) -E - | grep -v "\#") export BIG_ENDIAN subdir-y := lib +targets+= vmlinux.bin vmlinux.bin.gz # Subdirs for the boot loader(s) @@ -35,19 +36,19 @@ boot-elf boot-redboot: $(addprefix $(obj)/,$(subdir-y)) OBJCOPYFLAGS = --strip-all -R .comment -R .notes -O binary -vmlinux.bin: vmlinux FORCE +$(obj)/vmlinux.bin: vmlinux FORCE $(call if_changed,objcopy) -vmlinux.bin.gz: vmlinux.bin FORCE +$(obj)/vmlinux.bin.gz: $(obj)/vmlinux.bin FORCE $(call if_changed,gzip) -boot-elf: vmlinux.bin -boot-redboot: vmlinux.bin.gz +boot-elf: $(obj)/vmlinux.bin +boot-redboot: $(obj)/vmlinux.bin.gz UIMAGE_LOADADDR = $(CONFIG_KERNEL_LOAD_ADDRESS) UIMAGE_COMPRESSION = gzip -$(obj)/uImage: vmlinux.bin.gz FORCE +$(obj)/uImage: $(obj)/vmlinux.bin.gz FORCE $(call if_changed,uimage) $(Q)$(kecho) ' Kernel: $@ is ready' diff --git a/arch/xtensa/boot/boot-elf/Makefile b/arch/xtensa/boot/boot-elf/Makefile index badee63dae27..0ebc9827f7e5 100644 --- a/arch/xtensa/boot/boot-elf/Makefile +++ b/arch/xtensa/boot/boot-elf/Makefile @@ -19,9 +19,9 @@ targets += $(boot-y) boot.lds OBJS := $(addprefix $(obj)/,$(boot-y)) -$(obj)/Image.o: vmlinux.bin $(OBJS) +$(obj)/Image.o: $(obj)/../vmlinux.bin $(OBJS) $(Q)$(OBJCOPY) $(OBJCOPY_ARGS) -R .comment \ - --add-section image=vmlinux.bin \ + --add-section image=$< \ --set-section-flags image=contents,alloc,load,load,data \ $(OBJS) $@ diff --git a/arch/xtensa/boot/boot-redboot/Makefile b/arch/xtensa/boot/boot-redboot/Makefile index 1a277dd57b2a..07cb24afedc2 100644 --- a/arch/xtensa/boot/boot-redboot/Makefile +++ b/arch/xtensa/boot/boot-redboot/Makefile @@ -20,9 +20,9 @@ LIBS := arch/xtensa/boot/lib/lib.a arch/xtensa/lib/lib.a LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name) -$(obj)/zImage.o: vmlinux.bin.gz $(OBJS) +$(obj)/zImage.o: $(obj)/../vmlinux.bin.gz $(OBJS) $(Q)$(OBJCOPY) $(OBJCOPY_ARGS) -R .comment \ - --add-section image=vmlinux.bin.gz \ + --add-section image=$< \ --set-section-flags image=contents,alloc,load,load,data \ $(OBJS) $@ -- 2.20.1
Re: [PATCH] Input: ati_remote2 - add missing newlines when printing module parameters
On Mon, Jul 20, 2020 at 05:21:48PM +0800, Xiongfeng Wang wrote: > When I cat some module parameters by sysfs, it displays as follows. It's > better to add a newline for easy reading. > > root@syzkaller:~# cat /sys/module/ati_remote2/parameters/mode_mask > 0x1froot@syzkaller:~# cat /sys/module/ati_remote2/parameters/channel_mask > 0xroot@syzkaller:~# > > Signed-off-by: Xiongfeng Wang Applied, thank you. -- Dmitry
Re: [PATCH] Input: psmouse: add a newline when printing 'proto' by sysfs
On Mon, Jul 20, 2020 at 03:38:46PM +0800, Xiongfeng Wang wrote: > When I cat parameter 'proto' by sysfs, it displays as follows. It's > better to add a newline for easy reading. > > root@syzkaller:~# cat /sys/module/psmouse/parameters/proto > autoroot@syzkaller:~# > > Signed-off-by: Xiongfeng Wang Applied, thank you. -- Dmitry
[PATCH 0/2] xtensa: boot targets cleanup
Hello, this small clean up in the xtensa boot subdirectory adds more targets to the 'targets' variable to avoid unnecessary rebuils. Max Filippov (2): xtensa: move vmlinux.bin[.gz] to boot subdirectory xtensa: add uImage and xipImage to targets arch/xtensa/boot/Makefile | 12 +++- arch/xtensa/boot/boot-elf/Makefile | 4 ++-- arch/xtensa/boot/boot-redboot/Makefile | 4 ++-- 3 files changed, 11 insertions(+), 9 deletions(-) -- 2.20.1
Re: [PATCH 4.19 123/133] thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power
On 21-07-20, 13:43, Pavel Machek wrote:
> On Mon 2020-07-20 17:37:50, Greg Kroah-Hartman wrote:
> > From: Finley Xiao
> >
> > commit 371a3bc79c11b707d7a1b7a2c938dc3cc042fffb upstream.
> >
> > The function cpu_power_to_freq is used to find a frequency and set the
> > cooling device to consume at most the power to be converted. For example,
> > if the power to be converted is 80mW, and the em table is as follow.
> > struct em_cap_state table[] = {
> > /* KHz mW */
> > { 1008000, 36, 0 },
> > { 120, 49, 0 },
> > { 1296000, 59, 0 },
> > { 1416000, 72, 0 },
> > { 1512000, 86, 0 },
> > };
> > The target frequency should be 1416000KHz, not 1512000KHz.
> >
> > Fixes: 349d39dc5739 ("thermal: cpu_cooling: merge frequency and power
> > tables")
>
> Wow, this is completely different from the upstream patch.
Right, I have mentioned this in the patch I sent for stable.
https://lore.kernel.org/lkml/bc3978d0b7472c140e4d87f61138168a2a7b995c.1594194577.git.viresh.ku...@linaro.org/
> There the
> loops goes down, not up. The code does not match the changelog here.
Yes, the order is different in earlier kernels but I would say that
the changelog still matches as it doesn't necessarily talks about any
ordering here.
> > --- a/drivers/thermal/cpu_cooling.c
> > +++ b/drivers/thermal/cpu_cooling.c
> > @@ -278,11 +278,11 @@ static u32 cpu_power_to_freq(struct cpuf
> > int i;
> > struct freq_table *freq_table = cpufreq_cdev->freq_table;
> >
> > - for (i = 1; i <= cpufreq_cdev->max_level; i++)
> > - if (power > freq_table[i].power)
> > + for (i = 0; i < cpufreq_cdev->max_level; i++)
> > + if (power >= freq_table[i].power)
> > break;
> >
> > - return freq_table[i - 1].frequency;
> > + return freq_table[i].frequency;
> > }
>
>
> Something is very wrong here, if table is sorted like described in the
> changelog, it will always break at i==0 or i==1... not working at all
> in the old or the new version.
As I understand from the other email you sent, this works fine now.
Right ?
--
viresh
[PATCH 2/2] xtensa: add uImage and xipImage to targets
uImage and xipImage are always rebuilt in the xtensa kernel build process. Add them to 'targets' to avoid that. Signed-off-by: Max Filippov --- arch/xtensa/boot/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/xtensa/boot/Makefile b/arch/xtensa/boot/Makefile index 801fe30b4dfe..f6bb352f94b4 100644 --- a/arch/xtensa/boot/Makefile +++ b/arch/xtensa/boot/Makefile @@ -18,6 +18,7 @@ export BIG_ENDIAN subdir-y := lib targets+= vmlinux.bin vmlinux.bin.gz +targets+= uImage xipImage # Subdirs for the boot loader(s) -- 2.20.1
Re: [PATCH v5 0/6] Add support for GPU DDR BW scaling
On 21-07-20, 07:28, Rob Clark wrote: > With your ack, I can add the patch the dev_pm_opp_set_bw patch to my > tree and merge it via msm-next -> drm-next -> linus I wanted to send it via my tree, but its okay. Pick this patch from linux-next and add my Ack, I will drop it after that. a8351c12c6c7 OPP: Add and export helper to set bandwidth > Otherwise I can send a second later pull req that adds the final patch > after has rebased to 5.9-rc1 (by which point the opp next tree will > have presumably been merged The PM stuff gets pushed fairly early and so I was asking you to rebase just on my tree, so you could have sent the pull request right after the PM tree landed there instead of waiting for rc1. But its fine now. -- viresh
Re: [PATCH RFC V2 17/17] x86/entry: Preserve PKRS MSR across exceptions
On Fri, Jul 17, 2020 at 12:06:10PM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:56AM -0700, ira.we...@intel.com wrote:
> > First I'm not sure if adding this state to idtentry_state and having
> > that state copied is the right way to go. It seems like we should start
> > passing this by reference instead of value. But for now this works as
> > an RFC. Comments?
>
> As long as you keep sizeof(struct idtentry_state_t) <= sizeof(u64) or
> possibly 2*sizeof(unsigned long), code gen shouldn't be too horrid IIRC.
> You'll have to look at what the compiler makes of it.
>
> > Second, I'm not 100% happy with having to save the reference count in
> > the exception handler. It seems like a very ugly layering violation but
> > I don't see a way around it at the moment.
>
> So I've been struggling with that API, all the way from
> pks_update_protection() to that dev_access_{en,dis}able(). I _really_
> hate it, but I see how you ended up with it.
>
> I wanted to propose something like:
>
> u32 current_pkey_save(int pkey, unsigned flags)
> {
> u32 *lpkr = get_cpu_ptr(_pkr);
> u32 pkr, saved = *lpkr;
>
> pkr = update_pkey_reg(saved, pkey, flags);
> if (pkr != saved)
> wrpkr(pkr);
>
> put_cpu_ptr(_pkr);
> return saved;
> }
>
> void current_pkey_restore(u32 pkr)
> {
> u32 *lpkr = get_cpu_ptr(_pkr);
> if (*lpkr != pkr)
> wrpkr(pkr);
> put_cpu_ptr(_pkr);
> }
>
> Together with:
>
> void pkey_switch(struct task_struct *prev, struct task_struct *next)
> {
> prev->pkr = this_cpu_read(local_pkr);
> if (prev->pkr != next->pkr)
> wrpkr(next->pkr);
> }
>
> But that's actually hard to frob into the kmap() model :-( The upside is
> that you only have 1 word of state, instead of the 2 you have now.
I'm still mulling over if what you have really helps us. It seems like we may
be able to remove the percpu pkrs_cache variable... But I'm hesitant to do so.
Regardless that is not the big issue right now...
>
> > Third, this patch has gone through a couple of revisions as I've had
> > crashes which just don't make sense to me. One particular issue I've
> > had is taking a MCE during memcpy_mcsafe causing my WARN_ON() to fire.
> > The code path was a pmem copy and the ref count should have been
> > elevated due to dev_access_enable() but why was
> > idtentry_enter()->idt_save_pkrs() not called I don't know.
>
> Because MCEs are NMI-like and don't go through the normal interrupt
> path. MCEs are an abomination, please wear all the protective devices
> you can lay hands on when delving into that.
I've been really digging into this today and I'm very concerned that I'm
completely missing something WRT idtentry_enter() and idtentry_exit().
I've instrumented idt_{save,restore}_pkrs(), and __dev_access_{en,dis}able()
with trace_printk()'s.
With this debug code, I have found an instance where it seems like
idtentry_enter() is called without a corresponding idtentry_exit(). This has
left the thread ref counter at 0 which results in very bad things happening
when __dev_access_disable() is called and the ref count goes negative.
Effectively this seems to be happening:
...
// ref == 0
dev_access_enable() // ref += 1 ==> disable protection
// exception (which one I don't know)
idtentry_enter()
// ref = 0
_handler() // or whatever code...
// *_exit() not called [at least there is no
trace_printk() output]...
// Regardless of trace output, the ref is left at 0
dev_access_disable() // ref -= 1 ==> -1 ==> does not enable protection
(Bad stuff is bound to happen now...)
...
The ref count ends up completely messed up after this sequence... and the PKRS
register gets out of sync as well. This is starting to make some sense of how
I was getting what seemed like random crashes before.
Unfortunately I don't understand the idt entry/exit code well enough to see
clearly what is going on. Is there any reason idtentry_exit() is not called
after idtentry_enter()? Perhaps some NMI/MCE or 'not normal' exception code
path I'm not seeing? In my searches I see a corresponding exit for every
enter. But MCE is pretty hard to follow.
Also is there any chance that the process could be getting scheduled and that
is causing an issue?
Thanks,
Ira
Re: [PATCH v6 1/6] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
On 21-07-20, 01:43, Stephen Boyd wrote: > It seems that dev_pm_opp_set_rate() calls _find_opp_table() and finds > something that isn't an error pointer but then dev_pm_opp_of_add_table() > returns an error value because there isn't an operating-points property > in DT. We're getting saved because this driver also happens to call > dev_pm_opp_set_clkname() which allocates the OPP table a second time > (because the first time it got freed when dev_pm_opp_of_add_table() > return -ENODEV because the property was missing). > > Why do we need 'has_opp_table' logic? It seems that we have to keep > track of the fact that dev_pm_opp_of_add_table() failed so that we don't > put the table again, but then dev_pm_opp_set_clkname() can be called > to allocate the table regardless. > > This maintainer is paying very close attention :) > to super confusing code like > this: > > if (drv->has_opp_table) > dev_pm_opp_of_remove_table(dev); > dev_pm_opp_put_clkname(drv->opp_table); > > which reads as "if I have an opp table remove it and oh by the way > remove the clk name for this opp table pointer I also happen to always > have". > > Maybe I would be happier if dev_pm_opp_of_table() went away and we just > had dev_pm_opp_add_table(const struct opp_config *config) that did all > the things for us like set a clk name, set the supported hw, set the > prop name, etc. based on the single config struct pointer and also > parsed out the OPP table from DT or just ignored that if there isn't any > operating-points property. Then the caller wouldn't need to keep track > of 'if has_opp_table' because it doesn't seem to actually care and the > core is happy to allocate a table for the device anyway so long as it > sets a clk name. The config style wouldn't work as well as we don't really want to allocate an OPP table if the property isn't found in DT. All the mess is coming from the fact that I wanted to make it easy for the generic drivers to have code which can do opp-set-rate or clk-set-rate depending on how the platform is configured. While the intention was fine, the end result is still not great as you figured out. Because we need to keep a flag to make the right decision anyway, I wonder if doing this is the best solution we have at hand. if (opp-table-present) opp_set_rate(); else clk_set_rate(); Or maybe stop printing errors from dev_pm_opp_of_remove_table() if the OPP table isn't found. And so we can get rid of the flag. -- viresh
[PATCH 0/1] MIPS: X2000: Add X2000 system type.
1.Add "PRID_COMP_INGENIC_13" and "PRID_IMP_XBURST2" for X2000. 2.Add X2000 system type for cat /proc/cpuinfo to give out X2000. 周琰杰 (Zhou Yanjie) (1): MIPS: X2000: Add X2000 system type. arch/mips/include/asm/bootinfo.h | 1 + arch/mips/include/asm/cpu.h | 6 -- arch/mips/jz4740/setup.c | 4 arch/mips/kernel/cpu-probe.c | 11 +++ 4 files changed, 20 insertions(+), 2 deletions(-) -- 2.11.0
[PATCH 1/1] MIPS: X2000: Add X2000 system type.
1.Add "PRID_COMP_INGENIC_13" and "PRID_IMP_XBURST2" for X2000.
2.Add X2000 system type for cat /proc/cpuinfo to give out X2000.
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
arch/mips/include/asm/bootinfo.h | 1 +
arch/mips/include/asm/cpu.h | 6 --
arch/mips/jz4740/setup.c | 4
arch/mips/kernel/cpu-probe.c | 11 +++
4 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/mips/include/asm/bootinfo.h b/arch/mips/include/asm/bootinfo.h
index 26f267d5649f..147c9327ce04 100644
--- a/arch/mips/include/asm/bootinfo.h
+++ b/arch/mips/include/asm/bootinfo.h
@@ -80,6 +80,7 @@ enum ingenic_machine_type {
MACH_INGENIC_JZ4780,
MACH_INGENIC_X1000,
MACH_INGENIC_X1830,
+ MACH_INGENIC_X2000,
};
extern char *system_type;
diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index 104a509312b3..f5b04e8f6061 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -46,6 +46,7 @@
#define PRID_COMP_NETLOGIC 0x0c
#define PRID_COMP_CAVIUM 0x0d
#define PRID_COMP_LOONGSON 0x14
+#define PRID_COMP_INGENIC_13 0x13/* X2000 */
#define PRID_COMP_INGENIC_D0 0xd0/* JZ4740, JZ4750, X1830 */
#define PRID_COMP_INGENIC_D1 0xd1/* JZ4770, JZ4775, X1000 */
#define PRID_COMP_INGENIC_E1 0xe1/* JZ4780 */
@@ -185,8 +186,9 @@
* These are the PRID's for when 23:16 == PRID_COMP_INGENIC_*
*/
-#define PRID_IMP_XBURST_REV1 0x0200 /* XBurst with MXU SIMD ISA
*/
-#define PRID_IMP_XBURST_REV2 0x0100 /* XBurst with MXU2 SIMD ISA*/
+#define PRID_IMP_XBURST_REV1 0x0200 /* XBurst®1 with MXU1.0/MXU1.1 SIMD ISA
*/
+#define PRID_IMP_XBURST_REV2 0x0100 /* XBurst®1 with MXU2.0 SIMD ISA
*/
+#define PRID_IMP_XBURST2 0x2000 /* XBurst®2 with MXU2.1 SIMD
ISA*/
/*
* These are the PRID's for when 23:16 == PRID_COMP_NETLOGIC
diff --git a/arch/mips/jz4740/setup.c b/arch/mips/jz4740/setup.c
index 61468a87775c..7d6cd087c5a9 100644
--- a/arch/mips/jz4740/setup.c
+++ b/arch/mips/jz4740/setup.c
@@ -49,6 +49,8 @@ static void __init jz4740_detect_mem(void)
static unsigned long __init get_board_mach_type(const void *fdt)
{
+ if (!fdt_node_check_compatible(fdt, 0, "ingenic,x2000"))
+ return MACH_INGENIC_X2000;
if (!fdt_node_check_compatible(fdt, 0, "ingenic,x1830"))
return MACH_INGENIC_X1830;
if (!fdt_node_check_compatible(fdt, 0, "ingenic,x1000"))
@@ -91,6 +93,8 @@ void __init device_tree_init(void)
const char *get_system_type(void)
{
switch (mips_machtype) {
+ case MACH_INGENIC_X2000:
+ return "X2000";
case MACH_INGENIC_X1830:
return "X1830";
case MACH_INGENIC_X1000:
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index def1659fe262..90b11bc59d97 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -2110,6 +2110,8 @@ static inline void cpu_probe_ingenic(struct cpuinfo_mips
*c, unsigned int cpu)
BUG_ON(!__builtin_constant_p(cpu_has_counter) || cpu_has_counter);
switch (c->processor_id & PRID_IMP_MASK) {
+
+ /* XBurst®1 with MXU1.0/MXU1.1 SIMD ISA */
case PRID_IMP_XBURST_REV1:
/*
@@ -2148,12 +2150,20 @@ static inline void cpu_probe_ingenic(struct
cpuinfo_mips *c, unsigned int cpu)
break;
}
fallthrough;
+
+ /* XBurst®1 with MXU2.0 SIMD ISA */
case PRID_IMP_XBURST_REV2:
c->cputype = CPU_XBURST;
c->writecombine = _CACHE_UNCACHED_ACCELERATED;
__cpu_name[cpu] = "Ingenic XBurst";
break;
+ /* XBurst®2 with MXU2.1 SIMD ISA */
+ case PRID_IMP_XBURST2:
+ c->cputype = CPU_XBURST;
+ __cpu_name[cpu] = "Ingenic XBurst II";
+ break;
+
default:
panic("Unknown Ingenic Processor ID!");
break;
@@ -2299,6 +2309,7 @@ void cpu_probe(void)
case PRID_COMP_LOONGSON:
cpu_probe_loongson(c, cpu);
break;
+ case PRID_COMP_INGENIC_13:
case PRID_COMP_INGENIC_D0:
case PRID_COMP_INGENIC_D1:
case PRID_COMP_INGENIC_E1:
--
2.11.0
[PATCH] drm/virtio: fix memory leak in virtio_gpu_cleanup_object()
Before setting shmem->pages to NULL, kfree() should be called. Signed-off-by: Xin He Reviewed-by: Qi Liu --- drivers/gpu/drm/virtio/virtgpu_object.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index 6ccbd01cd888..703b5cd51751 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -79,6 +79,7 @@ void virtio_gpu_cleanup_object(struct virtio_gpu_object *bo) } sg_free_table(shmem->pages); + kfree(shmem->pages); shmem->pages = NULL; drm_gem_shmem_unpin(>base.base); } -- 2.21.1 (Apple Git-122.3)
Re: [PATCH] raid: md_p.h: drop duplicated word in a comment
On Fri, Jul 17, 2020 at 4:37 PM Randy Dunlap wrote:
>
> From: Randy Dunlap
>
> Drop the doubled word "the" in a comment.
>
> Signed-off-by: Randy Dunlap
> Cc: Song Liu
> Cc: linux-r...@vger.kernel.org
Applied to md-next. Thanks!
> ---
> include/uapi/linux/raid/md_p.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20200714.orig/include/uapi/linux/raid/md_p.h
> +++ linux-next-20200714/include/uapi/linux/raid/md_p.h
> @@ -123,7 +123,7 @@ typedef struct mdp_device_descriptor_s {
>
> /*
> * Notes:
> - * - if an array is being reshaped (restriped) in order to change the
> + * - if an array is being reshaped (restriped) in order to change
> * the number of active devices in the array, 'raid_disks' will be
> * the larger of the old and new numbers. 'delta_disks' will
> * be the "new - old". So if +ve, raid_disks is the new value, and
>
Re: [PATCH] perf-c2c: Fix the wrong description.
On Thu, Jul 9, 2020 at 9:07 PM qianjun wrote: > > From: qianjun > > Use L1Miss to replace L1Hit to describe the correct scene > > Signed-off-by: qianjun > --- > tools/perf/Documentation/perf-c2c.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/perf/Documentation/perf-c2c.txt > b/tools/perf/Documentation/perf-c2c.txt > index 98efdab..083e99a 100644 > --- a/tools/perf/Documentation/perf-c2c.txt > +++ b/tools/perf/Documentation/perf-c2c.txt > @@ -186,7 +186,7 @@ For each cacheline in the 1) list we display following > data: >Store Reference - Total, L1Hit, L1Miss > Total - all store accesses > L1Hit - store accesses that hit L1 > -L1Hit - store accesses that missed L1 > +L1Miss - store accesses that missed L1 > >Load Dram >- count of local and remote DRAM accesses > -- > 1.8.3.1 > hi man I think it's a problem :)
Re: [PATCH v2] perf evsel: Don't set sample_regs_intr/sample_regs_user for dummy event
Hi Jiri,
On 7/20/2020 5:17 PM, Jiri Olsa wrote:
On Mon, Jul 20, 2020 at 09:00:13AM +0800, Jin Yao wrote:
Since commit 0a892c1c9472 ("perf record: Add dummy event during system wide
synthesis"),
a dummy event is added to capture mmaps.
But if we run perf-record as,
# perf record -e cycles:p -IXMM0 -a -- sleep 1
Error:
dummy:HG: PMU Hardware doesn't support sampling/overflow-interrupts. Try
'perf stat'
The issue is, if we enable the extended regs (-IXMM0), but the
pmu->capabilities is not set with PERF_PMU_CAP_EXTENDED_REGS, the kernel
will return -EOPNOTSUPP error.
See following code:
/* in kernel/events/core.c */
static int perf_try_init_event(struct pmu *pmu, struct perf_event *event)
{
if (!(pmu->capabilities & PERF_PMU_CAP_EXTENDED_REGS) &&
has_extended_regs(event))
ret = -EOPNOTSUPP;
}
For software dummy event, the PMU should not be set with
PERF_PMU_CAP_EXTENDED_REGS. But unfortunately now, the dummy
event has possibility to be set with PERF_REG_EXTENDED_MASK bit.
In evsel__config, /* tools/perf/util/evsel.c */
if (opts->sample_intr_regs) {
attr->sample_regs_intr = opts->sample_intr_regs;
}
If we use -IXMM0, the attr>sample_regs_intr will be set with
PERF_REG_EXTENDED_MASK bit.
It doesn't make sense to set attr->sample_regs_intr for a
software dummy event.
This patch adds dummy event checking before setting
attr->sample_regs_intr and attr->sample_regs_user.
After:
# ./perf record -e cycles:p -IXMM0 -a -- sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.413 MB perf.data (45 samples) ]
v2:
---
Rebase to perf/core
Fixes: 0a892c1c9472 ("perf record: Add dummy event during system wide
synthesis")
Signed-off-by: Jin Yao
---
tools/perf/util/evsel.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 9aa51a65593d..11794d3b7879 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1014,12 +1014,14 @@ void evsel__config(struct evsel *evsel, struct
record_opts *opts,
if (callchain && callchain->enabled && !evsel->no_aux_samples)
evsel__config_callchain(evsel, opts, callchain);
- if (opts->sample_intr_regs && !evsel->no_aux_samples) {
+ if (opts->sample_intr_regs && !evsel->no_aux_samples &&
+ !evsel__is_dummy_event(evsel)) {
hum, I thought it'd look something like this:
if (opts->sample_intr_regs && (!evsel->no_aux_samples ||
!evsel__is_dummy_event(evsel))
but I'm not sure how no_aux_samples flag works exactly.. so it might be
correct.. just making sure ;-)
cc-ing Adrian
jirka
no_aux_samples is set to false by default and it's only set to true by pt,
right?
So most of the time, !evsel->no_aux_samples is always true.
if (opts->sample_intr_regs && (!evsel->no_aux_samples ||
!evsel__is_dummy_event(evsel)) {
attr->sample_regs_intr = opts->sample_intr_regs;
evsel__set_sample_bit(evsel, REGS_INTR);
}
So even if the evsel is dummy event, the condition check is true. :(
Or maybe I misunderstand anything?
Thanks
Jin Yao
attr->sample_regs_intr = opts->sample_intr_regs;
evsel__set_sample_bit(evsel, REGS_INTR);
}
- if (opts->sample_user_regs && !evsel->no_aux_samples) {
+ if (opts->sample_user_regs && !evsel->no_aux_samples &&
+ !evsel__is_dummy_event(evsel)) {
attr->sample_regs_user |= opts->sample_user_regs;
evsel__set_sample_bit(evsel, REGS_USER);
}
--
2.17.1
Re: [RFC PATCH v2] Softirq:avoid large sched delay from the pending softirqs
Hi Peter & Uladzislau
Are there any issues that have not been considered in this patch? Can
you give me some suggestions on this issue. If the situation I
described is indeed a problem，how about this modification. Thanks a
lot.
On Mon, Jul 20, 2020 at 9:09 PM wrote:
>
> From: jun qian
>
> When get the pending softirqs, it need to process all the pending
> softirqs in the while loop. If the processing time of each pending
> softirq is need more than 2 msec in this loop, or one of the softirq
> will running a long time, according to the original code logic, it
> will process all the pending softirqs without wakeuping ksoftirqd,
> which will cause a relatively large scheduling delay on the
> corresponding CPU, which we do not wish to see. The patch will check
> the total time to process pending softirq, if the time exceeds 2 ms
> we need to wakeup the ksofirqd to aviod large sched delay.
>
> Signed-off-by: jun qian
> ---
> kernel/softirq.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index c4201b7f..f8e5be9 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -210,7 +210,7 @@ void __local_bh_enable_ip(unsigned long ip, unsigned int
> cnt)
> * we want to handle softirqs as soon as possible, but they
> * should not be able to lock up the box.
> */
> -#define MAX_SOFTIRQ_TIME msecs_to_jiffies(2)
> +#define MAX_SOFTIRQ_TIME 2000 /* In microseconds */
> #define MAX_SOFTIRQ_RESTART 10
>
> #ifdef CONFIG_TRACE_IRQFLAGS
> @@ -248,7 +248,8 @@ static inline void lockdep_softirq_end(bool in_hardirq) {
> }
>
> asmlinkage __visible void __softirq_entry __do_softirq(void)
> {
> - unsigned long end = jiffies + MAX_SOFTIRQ_TIME;
> + ktime_t end, start;
> + s64 delta;
> unsigned long old_flags = current->flags;
> int max_restart = MAX_SOFTIRQ_RESTART;
> struct softirq_action *h;
> @@ -256,6 +257,8 @@ asmlinkage __visible void __softirq_entry
> __do_softirq(void)
> __u32 pending;
> int softirq_bit;
>
> + start = ktime_get();
> +
> /*
> * Mask out PF_MEMALLOC as the current task context is borrowed for
> the
> * softirq. A softirq handled, such as network RX, might set
> PF_MEMALLOC
> @@ -299,6 +302,15 @@ asmlinkage __visible void __softirq_entry
> __do_softirq(void)
> }
> h++;
> pending >>= softirq_bit;
> +
> + end = ktime_get();
> + delta = ktime_to_us(end - start);
> + /*
> +* the softirq's action has been running for too much time
> +* so it may need to wakeup the ksoftirqd
> +*/
> + if (delta > MAX_SOFTIRQ_TIME && need_resched())
> + break;
> }
>
> if (__this_cpu_read(ksoftirqd) == current)
> @@ -307,7 +319,9 @@ asmlinkage __visible void __softirq_entry
> __do_softirq(void)
>
> pending = local_softirq_pending();
> if (pending) {
> - if (time_before(jiffies, end) && !need_resched() &&
> + end = ktime_get();
> + delta = ktime_to_us(end - start);
> + if (delta < MAX_SOFTIRQ_TIME && !need_resched() &&
> --max_restart)
> goto restart;
>
> --
> 1.8.3.1
>
[GIT PULL] exfat fixes for 5.8-rc7
Hi Linus, This is exfat fixes pull request for v5.8-rc7. I add description of this pull request on below. Please pull exfat with following fixes. Thanks! The following changes since commit ba47d845d715a010f7b51f6f89bae32845e6acb7: Linux 5.8-rc6 (2020-07-19 15:41:18 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat.git tags/exfat-for-5.8-rc7 for you to fetch changes up to db415f7aae07cadcabd5d2a659f8ad825c905299: exfat: fix name_hash computation on big endian systems (2020-07-21 10:44:19 +0900) Description for this pull request: - fix overflow issue at sector calculation. - fix wrong hint_stat initialization. - fix wrong size update of stream entry. - fix endianness of upname in name_hash computation. Hyeongseok Kim (1): exfat: fix wrong size update of stream entry by typo Ilya Ponetayev (1): exfat: fix name_hash computation on big endian systems Namjae Jeon (2): exfat: fix overflow issue in exfat_cluster_to_sector() exfat: fix wrong hint_stat initialization in exfat_find_dir_entry() fs/exfat/dir.c | 2 +- fs/exfat/exfat_fs.h | 2 +- fs/exfat/file.c | 2 +- fs/exfat/nls.c | 8 4 files changed, 7 insertions(+), 7 deletions(-)
[PATCH] Makefile.extrawarn: Move sign-compare from W=2 to W=3
This -Wsign-compare compiler warning can be very noisy and most of the suggested conversions are unnecessary. Make the warning W=3 so it's described under the "can most likely be ignored" block. Signed-off-by: Joe Perches --- On Tue, 2020-07-21 at 14:32 -0700, Joe Perches wrote: > On Tue, 2020-07-21 at 19:06 +, Corentin Labbe wrote: > > This patch fixes the warning: > > warning: comparison of integer expressions of different signedness: 'int' > > and 'long unsigned int' [-Wsign-compare] > > I think these do not really need conversion. > Are these useful compiler warnings ? Perhaps move the warning from W=2 to W=3 so it's described as "can most likely be ignored" scripts/Makefile.extrawarn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn index 62c275685b75..95e4cdb94fe9 100644 --- a/scripts/Makefile.extrawarn +++ b/scripts/Makefile.extrawarn @@ -66,7 +66,6 @@ KBUILD_CFLAGS += -Wnested-externs KBUILD_CFLAGS += -Wshadow KBUILD_CFLAGS += $(call cc-option, -Wlogical-op) KBUILD_CFLAGS += -Wmissing-field-initializers -KBUILD_CFLAGS += -Wsign-compare KBUILD_CFLAGS += -Wtype-limits KBUILD_CFLAGS += $(call cc-option, -Wmaybe-uninitialized) KBUILD_CFLAGS += $(call cc-option, -Wunused-macros) @@ -87,6 +86,7 @@ KBUILD_CFLAGS += -Wpacked KBUILD_CFLAGS += -Wpadded KBUILD_CFLAGS += -Wpointer-arith KBUILD_CFLAGS += -Wredundant-decls +KBUILD_CFLAGS += -Wsign-compare KBUILD_CFLAGS += -Wswitch-default KBUILD_CFLAGS += $(call cc-option, -Wpacked-bitfield-compat)
Re: [PATCH v4 2/3] powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable
On Tue, Jul 21, 2020 at 09:07:07PM +0530, Pratik Rajesh Sampat wrote:
> Replace the variable name from using "pnv_first_spr_loss_level" to
> "deep_spr_loss_state".
>
> pnv_first_spr_loss_level is supposed to be the earliest state that
> has OPAL_PM_LOSE_FULL_CONTEXT set, in other places the kernel uses the
> "deep" states as terminology. Hence renaming the variable to be coherent
> to its semantics.
>
> Signed-off-by: Pratik Rajesh Sampat
Acked-by: Gautham R. Shenoy
> ---
> arch/powerpc/platforms/powernv/idle.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/idle.c
> b/arch/powerpc/platforms/powernv/idle.c
> index 642abf0b8329..28462d59a8e1 100644
> --- a/arch/powerpc/platforms/powernv/idle.c
> +++ b/arch/powerpc/platforms/powernv/idle.c
> @@ -48,7 +48,7 @@ static bool default_stop_found;
> * First stop state levels when SPR and TB loss can occur.
> */
> static u64 pnv_first_tb_loss_level = MAX_STOP_STATE + 1;
> -static u64 pnv_first_spr_loss_level = MAX_STOP_STATE + 1;
> +static u64 deep_spr_loss_state = MAX_STOP_STATE + 1;
>
> /*
> * psscr value and mask of the deepest stop idle state.
> @@ -657,7 +657,7 @@ static unsigned long power9_idle_stop(unsigned long
> psscr, bool mmu_on)
> */
> mmcr0 = mfspr(SPRN_MMCR0);
> }
> - if ((psscr & PSSCR_RL_MASK) >= pnv_first_spr_loss_level) {
> + if ((psscr & PSSCR_RL_MASK) >= deep_spr_loss_state) {
> sprs.lpcr = mfspr(SPRN_LPCR);
> sprs.hfscr = mfspr(SPRN_HFSCR);
> sprs.fscr = mfspr(SPRN_FSCR);
> @@ -741,7 +741,7 @@ static unsigned long power9_idle_stop(unsigned long
> psscr, bool mmu_on)
>* just always test PSSCR for SPR/TB state loss.
>*/
> pls = (psscr & PSSCR_PLS) >> PSSCR_PLS_SHIFT;
> - if (likely(pls < pnv_first_spr_loss_level)) {
> + if (likely(pls < deep_spr_loss_state)) {
> if (sprs_saved)
> atomic_stop_thread_idle();
> goto out;
> @@ -1088,7 +1088,7 @@ static void __init pnv_power9_idle_init(void)
>* the deepest loss-less (OPAL_PM_STOP_INST_FAST) stop state.
>*/
> pnv_first_tb_loss_level = MAX_STOP_STATE + 1;
> - pnv_first_spr_loss_level = MAX_STOP_STATE + 1;
> + deep_spr_loss_state = MAX_STOP_STATE + 1;
> for (i = 0; i < nr_pnv_idle_states; i++) {
> int err;
> struct pnv_idle_states_t *state = _idle_states[i];
> @@ -1099,8 +1099,8 @@ static void __init pnv_power9_idle_init(void)
> pnv_first_tb_loss_level = psscr_rl;
>
> if ((state->flags & OPAL_PM_LOSE_FULL_CONTEXT) &&
> - (pnv_first_spr_loss_level > psscr_rl))
> - pnv_first_spr_loss_level = psscr_rl;
> + (deep_spr_loss_state > psscr_rl))
> + deep_spr_loss_state = psscr_rl;
>
> /*
>* The idle code does not deal with TB loss occurring
> @@ -,8 +,8 @@ static void __init pnv_power9_idle_init(void)
>* compatibility.
>*/
> if ((state->flags & OPAL_PM_TIMEBASE_STOP) &&
> - (pnv_first_spr_loss_level > psscr_rl))
> - pnv_first_spr_loss_level = psscr_rl;
> + (deep_spr_loss_state > psscr_rl))
> + deep_spr_loss_state = psscr_rl;
>
> err = validate_psscr_val_mask(>psscr_val,
> >psscr_mask,
> @@ -1158,7 +1158,7 @@ static void __init pnv_power9_idle_init(void)
> }
>
> pr_info("cpuidle-powernv: First stop level that may lose SPRs =
> 0x%llx\n",
> - pnv_first_spr_loss_level);
> + deep_spr_loss_state);
>
> pr_info("cpuidle-powernv: First stop level that may lose timebase =
> 0x%llx\n",
> pnv_first_tb_loss_level);
> --
> 2.25.4
>
Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone
Benjamin Herrenschmidt writes: > On Tue, 2020-07-21 at 16:48 -0700, Palmer Dabbelt wrote: >> > Why ? Branch distance limits ? You can't use trampolines ? >> >> Nothing fundamental, it's just that we don't have a large code model in the C >> compiler. As a result all the global symbols are resolved as 32-bit >> PC-relative accesses. We could fix this with a fast large code model, but >> then >> the kernel would need to relax global symbol references in modules and we >> don't >> even do that for the simple code models we have now. FWIW, some of the >> proposed large code models are essentially just split-PLT/GOT and therefor >> don't require relaxation, but at that point we're essentially PIC until we >> have more that 2GiB of kernel text -- and even then, we keep all the >> performance issues. > > My memory might be out of date but I *think* we do it on powerpc > without going to a large code model, but just having the in-kernel > linker insert trampolines. We build modules with the large code model, and always have AFAIK: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/Makefile?commit=4fa640dc52302b5e62b01b05c755b055549633ae#n129 # -mcmodel=medium breaks modules because it uses 32bit offsets from # the TOC pointer to create pointers where possible. Pointers into the # percpu data area are created by this method. # # The kernel module loader relocates the percpu data section from the # original location (starting with 0xd...) to somewhere in the base # kernel percpu data space (starting with 0xc...). We need a full # 64bit relocation for this to work, hence -mcmodel=large. KBUILD_CFLAGS_MODULE += -mcmodel=large We also insert trampolines for branches, but IIUC that's a separate issue. cheers
linux-next: manual merge of the input tree with Linus' tree
Hi all,
Today's linux-next merge of the input tree got a conflict in:
drivers/input/mouse/elan_i2c_core.c
between commit:
966334dfc472 ("Input: elan_i2c - only increment wakeup count on touch")
from Linus' tree and commit:
04d5ce620f79 ("Input: elan_i2c - add support for high resolution reports")
from the input tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/input/mouse/elan_i2c_core.c
index 6291fb5fa015,4b6e2dffc0ea..
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@@ -951,13 -997,12 +997,14 @@@ static void elan_report_absolute(struc
u8 hover_info = packet[ETP_HOVER_INFO_OFFSET];
bool contact_valid, hover_event;
+ pm_wakeup_event(>client->dev, 0);
+
- hover_event = hover_info & 0x40;
- for (i = 0; i < ETP_MAX_FINGERS; i++) {
- contact_valid = tp_info & (1U << (3 + i));
- elan_report_contact(data, i, contact_valid, finger_data);
+ hover_event = hover_info & BIT(6);
+ for (i = 0; i < ETP_MAX_FINGERS; i++) {
+ contact_valid = tp_info & BIT(3 + i);
+ elan_report_contact(data, i, contact_valid, high_precision,
+ packet, finger_data);
if (contact_valid)
finger_data += ETP_FINGER_DATA_LEN;
}
@@@ -1019,9 -1063,14 +1066,12 @@@ static irqreturn_t elan_isr(int irq, vo
if (error)
goto out;
- pm_wakeup_event(dev, 0);
-
switch (report[ETP_REPORT_ID_OFFSET]) {
case ETP_REPORT_ID:
- elan_report_absolute(data, report);
+ elan_report_absolute(data, report, false);
+ break;
+ case ETP_REPORT_ID2:
+ elan_report_absolute(data, report, true);
break;
case ETP_TP_REPORT_ID:
elan_report_trackpoint(data, report);
pgp4_P1M38PQL.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 1/4] dt-bindings: hwlock: qcom: Migrate binding to YAML
On Tue 21 Jul 08:13 PDT 2020, Rob Herring wrote:
> On Mon, Jun 22, 2020 at 1:59 AM Bjorn Andersson
> wrote:
> >
> > Migrate the Qualcomm TCSR mutex binding to YAML to allow validation.
> >
> > Reviewed-by: Vinod Koul
> > Signed-off-by: Bjorn Andersson
> > ---
> >
> > Changes since v1:
> > - Actually remove the old binding doc
> >
> > .../bindings/hwlock/qcom-hwspinlock.txt | 39 --
> > .../bindings/hwlock/qcom-hwspinlock.yaml | 51 +++
> > 2 files changed, 51 insertions(+), 39 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
> > create mode 100644
> > Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
>
> [...]
>
> > diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
> > b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
> > new file mode 100644
> > index ..71e63b52edd5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
> > @@ -0,0 +1,51 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/hwlock/qcom-hwspinlock.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Qualcomm Hardware Mutex Block
> > +
> > +maintainers:
> > + - Bjorn Andersson
> > +
> > +description:
> > + The hardware block provides mutexes utilized between different
> > processors on
> > + the SoC as part of the communication protocol used by these processors.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - qcom,sfpb-mutex
> > + - qcom,tcsr-mutex
> > +
> > + '#hwlock-cells':
> > +const: 1
> > +
> > + syscon:
> > +$ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +description:
> > + Should be a triple of phandle referencing the TCSR mutex syscon,
> > offset
> > + of first mutex within the syscon and stride between each mutex.
> > +
> > +required:
> > + - compatible
> > + - '#hwlock-cells'
> > + - syscon
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +tcsr_mutex_block: syscon@fd484000 {
> > +compatible = "syscon";
>
> 'syscon' alone now generates warnings. Can you drop this node or add a
> specific compatible.
>
In the binding examples or in the dts files as well?
The hardware block here is named "TCSR_MUTEX", so the natural compatible
to add here would be "qcom,tcsr-mutex", but that already has a meaning -
and the syscon node here doesn't carry all required properties...
Should we perhaps just remove the split model (syscon and
qcom,tcsr-mutex as different nodes) from the example and dts files?
(While maintaining backwards compatibility in the binding and driver)
For the platforms where we have other drivers that needs to poke in this
syscon it seems to work fine to say:
compatible = "qcom,tcsr-mutex", "syscon";
Regards,
Bjorn
> > +reg = <0xfd484000 0x2000>;
> > +};
> > +
> > +hwlock {
> > +compatible = "qcom,tcsr-mutex";
> > +syscon = <_mutex_block 0 0x80>;
> > +
> > +#hwlock-cells = <1>;
> > +};
> > +...
> > --
> > 2.26.2
> >
Re: [PATCH] riscv: Select ARCH_HAS_DEBUG_VM_PGTABLE
On Tue, 14 Jul 2020 14:26:11 PDT (-0700), ker...@esmil.dk wrote: This allows the pgtable tests to be built. Signed-off-by: Emil Renner Berthing --- The tests seem to succeed both in Qemu and on the HiFive Unleashed Both with and without the recent additions in https://lore.kernel.org/linux-riscv/1594610587-4172-1-git-send-email-anshuman.khand...@arm.com/ Documentation/features/debug/debug-vm-pgtable/arch-support.txt | 2 +- arch/riscv/Kconfig | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt index c527d05c0459..c9a764c3c795 100644 --- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt @@ -23,7 +23,7 @@ |openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | -| riscv: | TODO | +| riscv: | ok | |s390: | ok | | sh: | TODO | | sparc: | TODO | diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 3230c1d48562..b4e674b1e857 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -15,6 +15,7 @@ config RISCV select ARCH_CLOCKSOURCE_INIT select ARCH_HAS_BINFMT_FLAT select ARCH_HAS_DEBUG_VIRTUAL if MMU + select ARCH_HAS_DEBUG_VM_PGTABLE select ARCH_HAS_DEBUG_WX select ARCH_HAS_GCOV_PROFILE_ALL select ARCH_HAS_GIGANTIC_PAGE This is on for-next. Thanks!
Re: [BUG RT] dump-capture kernel not executed for panic in interrupt context
Hi Andrew, it's been two month now and no reaction from you. Maybe you did not see this mail from Steven. Please look at this issue. Greets, Jörg On 5/28/2020 2:46 PM, Steven Rostedt wrote: Hi Joerg, This does look like Andrew's commit (from 2008) is buggy (and this is a mainline bug, not an RT one). (top posting this so Andrew knows to look further ;-) On Thu, 28 May 2020 13:41:08 +0200 Joerg Vehlow wrote: Hi, I think I found a bug in the kernel with rt patches (or maybe even without). This applies to all kernels propably starting at 2.6.27. When a kernel panic is triggered from an interrupt handler, the dump-capture kernel is not started, instead the system acts as if it was not installed. The reason for this is, that panic calls __crash_kexec, which is protected by a mutex. On an rt kernel this mutex is an rt mutex and when trylock is called on an rt mutex, the first check is whether the current kthread is in an nmi or irq handler. If it is, the function just returns 0 -> locking failed. According to rt_mutex_trylock documentation, it is not allowed to call this function from an irq handler, but panic can be called from everywhere and thus rt_mutex_trylock can be called from everywhere. Actually even mutex_trylock has the comment, that it is not supposed to be used from interrupt context, but it still locks the mutex. I guess this could also be a bug in the non-rt kernel. I found this problem using a test module, that triggers the softlock detection. It is a pretty simple module, that creates a kthread, that disables preemption, spins 60 seconds in an endless loop and then reenables preemption and terminates the thread. This reliably triggers the softlock detection and if kernel.softlockup_panic=0, the system resumes perfectly fine afterwards. If kernel.softlockup_panic=1 I would expect the dump-capture kernel to be executed, but it is not due to the bug (without rt patches it works), instead the panic function is executed until the end to the endless loop. A stacktrace captured at the trylock call inside kexec_code looks like this: #0 __rt_mutex_trylock (lock=0x81701aa0 ) at /usr/src/kernel/kernel/locking/rtmutex.c:2110 #1 0x8087601a in _mutex_trylock (lock=) at /usr/src/kernel/kernel/locking/mutex-rt.c:185 #2 0x803022a0 in __crash_kexec (regs=0x0 ) at /usr/src/kernel/kernel/kexec_core.c:941 #3 0x8027af59 in panic (fmt=0x80fa3d66 "softlockup: hung tasks") at /usr/src/kernel/kernel/panic.c:198 #4 0x80325b6d in watchdog_timer_fn (hrtimer=) at /usr/src/kernel/kernel/watchdog.c:464 #5 0x802e6b90 in __run_hrtimer (flags=, now=, timer=, base=, cpu_base=) at /usr/src/kernel/kernel/time/hrtimer.c:1417 #6 __hrtimer_run_queues (cpu_base=0x88807db1c000, now=, flags=, active_mask=) at /usr/src/kernel/kernel/time/hrtimer.c:1479 #7 0x802e7704 in hrtimer_interrupt (dev=) at /usr/src/kernel/kernel/time/hrtimer.c:1539 #8 0x80a020f2 in local_apic_timer_interrupt () at /usr/src/kernel/arch/x86/kernel/apic/apic.c:1067 #9 smp_apic_timer_interrupt (regs=) at /usr/src/kernel/arch/x86/kernel/apic/apic.c:1092 #10 0x80a015df in apic_timer_interrupt () at /usr/src/kernel/arch/x86/entry/entry_64.S:909 Obviously and as expected the panic was triggered in the context of the apic interrupt. So in_irq() is true and trylock fails. About 12 years ago this was not implemented using a mutex, but using xchg. See: 8c5a1cf0ad3ac5fcdf51314a63b16a440870f6a2 Yes, that commit is wrong, because mutex_trylock() is not to be taken in interrupt context, where crash_kexec() looks like it can be called. Unless back then crash_kexec() wasn't called in interrupt context, then the commit that calls it from that combined with this commit is the issue. -- Steve Since my knowledege about mutexes inside the kernel is very limited, I do not know how this can be fixed and whether it should be fixed in the rt patches or if this really is a bug in mainline kernel (because trylock is also not allowed to be used in interrupt handlers. Jörg
linux-next: manual merge of the amdgpu tree with Linus' tree
Hi all,
[I can't find a previous email about this, sorry ...]
There is a semantic conflict between Linus' tree and the amdgpu tree
between commit
d7a6634a4cfb ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir")
from Linus' tree and commts
fe098a5d6443 ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir")
836dab851903 ("drm/amdgpu/atomfirmware: update vram info handling for renoir")
The automted git merge leaves two "case 12" labels. I have been
reverting commit d7a6634a4cfb since July 3 ... This will need to be
fixed up when the amdgpu tree is next merged into the drm tree, or a back
merge of d7a6634a4cfb could be done into the amdgpu tree and the older
"case 12" label removed in that merge.
--
Cheers,
Stephen Rothwell
pgpQu8f1cb2HF.pgp
Description: OpenPGP digital signature
Re: [PATCH 3/3] soc: mediatek: pwrap: add pwrap driver for MT6873/8192 SoCs
Hi,
On Wed, 2020-07-22 at 00:51 +0200, Matthias Brugger wrote:
>
> On 14/07/2020 11:53, Hsin-Hsiung Wang wrote:
> > MT6873/8192 are highly integrated SoCs and use PMIC_MT6359 for
> > power management. This patch adds pwrap master driver to
> > access PMIC_MT6359.
> >
> > Signed-off-by: Hsin-Hsiung Wang
> > ---
> > drivers/soc/mediatek/mtk-pmic-wrap.c | 98
> >
> > 1 file changed, 87 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > index c897205..6e7f796f 100644
> > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > @@ -24,11 +24,13 @@
> > #define PWRAP_MT8135_BRIDGE_WDT_SRC_EN0x54
> >
> > /* macro for wrapper status */
> > +#define PWRAP_GET_SWINF_2_FSM(x) (((x) >> 1) & 0x0007)
> > #define PWRAP_GET_WACS_RDATA(x) (((x) >> 0) & 0x)
> > #define PWRAP_GET_WACS_FSM(x) (((x) >> 16) & 0x0007)
> > #define PWRAP_GET_WACS_REQ(x) (((x) >> 19) & 0x0001)
> > #define PWRAP_STATE_SYNC_IDLE0BIT(20)
> > #define PWRAP_STATE_INIT_DONE0BIT(21)
> > +#define PWRAP_STATE_INIT_DONE1 BIT(15)
> >
> > /* macro for WACS FSM */
> > #define PWRAP_WACS_FSM_IDLE 0x00
> > @@ -74,6 +76,7 @@
> > #define PWRAP_CAP_DCM BIT(2)
> > #define PWRAP_CAP_INT1_EN BIT(3)
> > #define PWRAP_CAP_WDT_SRC1BIT(4)
> > +#define PWRAP_CAP_ARB BIT(5)
>
> This commit should be two patches (at least). One adding PWRAP_CAP_ARB and
> then
> another one adding MT6873 support.
>
> Regards,
> Matthias
>
Thanks for the comment. I will update it in next patch.
> >
> > /* defines for slave device wrapper registers */
> > enum dew_regs {
> > @@ -348,6 +351,10 @@ enum pwrap_regs {
[Delete]
Re: [PATCH -next] soc: qcom: geni: Fix unused lable warning
On Tue 21 Jul 19:06 PDT 2020, YueHaibing wrote:
> If CONFIG_SERIAL_EARLYCON is not set, gcc warns this:
>
> drivers/soc/qcom/qcom-geni-se.c: In function ‘geni_se_probe’:
> drivers/soc/qcom/qcom-geni-se.c:914:1: warning: label ‘exit’ defined but not
> used [-Wunused-label]
> exit:
> ^~~~
>
> Fixes: 048eb908a1f2 ("soc: qcom-geni-se: Add interconnect support to fix
> earlycon crash")
Reviewed-by: Bjorn Andersson
> Signed-off-by: YueHaibing
and applied.
Thanks,
Bjorn
> ---
> drivers/soc/qcom/qcom-geni-se.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
> index 3413129d73ef..d0e4f520cff8 100644
> --- a/drivers/soc/qcom/qcom-geni-se.c
> +++ b/drivers/soc/qcom/qcom-geni-se.c
> @@ -910,8 +910,8 @@ static int geni_se_probe(struct platform_device *pdev)
> if (of_get_compatible_child(pdev->dev.of_node, "qcom,geni-debug-uart"))
> earlycon_wrapper = wrapper;
> of_node_put(pdev->dev.of_node);
> -#endif
> exit:
> +#endif
> dev_set_drvdata(dev, wrapper);
> dev_dbg(dev, "GENI SE Driver probed\n");
> return devm_of_platform_populate(dev);
> --
> 2.17.1
>
>
Re: [PATCH v4 07/12] ppc64/kexec_file: add support to relocate purgatory
Hari Bathini writes: > Right now purgatory implementation is only minimal. But if purgatory > code is to be enhanced to copy memory to the backup region and verify > sha256 digest, relocations may have to be applied to the purgatory. > So, add support to relocate purgatory in kexec_file_load system call > by setting up TOC pointer and applying RELA relocations as needed. > > Reported-by: kernel test robot > [lkp: In v1, 'struct mem_sym' was declared in parameter list] > Signed-off-by: Hari Bathini > --- > > * Michael, can you share your opinion on the below: > - https://lore.kernel.org/patchwork/patch/1272027/ > - My intention in cover note. It seems like a lot of complexity for little benefit. AFAICS your final purgatory_64.c is only 36 lines, and all it does is a single (open coded) memcpy(). It seems like we could write that in not many more lines of assembler and avoid all this code. What am I missing? cheers
Re: [PATCH v2 2/2] remoteproc: qcom_q6v5_mss: Add MBA log extraction support
On Tue 21 Jul 04:29 PDT 2020, Sibi Sankar wrote:
> On SC7180 the MBA firmware stores the bootup text logs in a 4K segment
> at the beginning of the MBA region. Add support to extract the logs
> which will be useful to debug mba boot/authentication issues.
>
> Signed-off-by: Sibi Sankar
Reviewed-by: Bjorn Andersson
Afaict this is completely independent from the other patch in the
series, so I applied this.
Regards,
Bjorn
> ---
>
> V2:
> * Don't dump logs in mba_reclaim path [Bjorn]
> * Move has_mba_logs check to q6v5_dump_mba_logs [Bjorn]
> * SDM845 mss was incorrectly marked to support mba logs
>
> drivers/remoteproc/qcom_q6v5_mss.c | 38 +-
> 1 file changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index 49cd16e050533..945ca2652e7d6 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -9,6 +9,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -37,6 +38,8 @@
>
> #define MPSS_CRASH_REASON_SMEM 421
>
> +#define MBA_LOG_SIZE SZ_4K
> +
> /* RMB Status Register Values */
> #define RMB_PBL_SUCCESS 0x1
>
> @@ -141,6 +144,7 @@ struct rproc_hexagon_res {
> int version;
> bool need_mem_protection;
> bool has_alt_reset;
> + bool has_mba_logs;
> bool has_spare_reg;
> };
>
> @@ -202,6 +206,7 @@ struct q6v5 {
> struct qcom_sysmon *sysmon;
> bool need_mem_protection;
> bool has_alt_reset;
> + bool has_mba_logs;
> bool has_spare_reg;
> int mpss_perm;
> int mba_perm;
> @@ -521,6 +526,26 @@ static int q6v5_rmb_mba_wait(struct q6v5 *qproc, u32
> status, int ms)
> return val;
> }
>
> +static void q6v5_dump_mba_logs(struct q6v5 *qproc)
> +{
> + struct rproc *rproc = qproc->rproc;
> + void *data;
> +
> + if (!qproc->has_mba_logs)
> + return;
> +
> + if (q6v5_xfer_mem_ownership(qproc, >mba_perm, true, false,
> qproc->mba_phys,
> + qproc->mba_size))
> + return;
> +
> + data = vmalloc(MBA_LOG_SIZE);
> + if (!data)
> + return;
> +
> + memcpy(data, qproc->mba_region, MBA_LOG_SIZE);
> + dev_coredumpv(>dev, data, MBA_LOG_SIZE, GFP_KERNEL);
> +}
> +
> static int q6v5proc_reset(struct q6v5 *qproc)
> {
> u32 val;
> @@ -839,6 +864,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> {
> int ret;
> int xfermemop_ret;
> + bool mba_load_err = false;
>
> qcom_q6v5_prepare(>q6v5);
>
> @@ -932,7 +958,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_q6);
> q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_modem);
> q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_nc);
> -
> + mba_load_err = true;
> reclaim_mba:
> xfermemop_ret = q6v5_xfer_mem_ownership(qproc, >mba_perm, true,
> false, qproc->mba_phys,
> @@ -940,6 +966,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> if (xfermemop_ret) {
> dev_err(qproc->dev,
> "Failed to reclaim mba buffer, system may become
> unstable\n");
> + } else if (mba_load_err) {
> + q6v5_dump_mba_logs(qproc);
> }
>
> disable_active_clks:
> @@ -1298,6 +1326,7 @@ static int q6v5_start(struct rproc *rproc)
>
> reclaim_mpss:
> q6v5_mba_reclaim(qproc);
> + q6v5_dump_mba_logs(qproc);
>
> return ret;
> }
> @@ -1717,6 +1746,7 @@ static int q6v5_probe(struct platform_device *pdev)
>
> qproc->version = desc->version;
> qproc->need_mem_protection = desc->need_mem_protection;
> + qproc->has_mba_logs = desc->has_mba_logs;
>
> ret = qcom_q6v5_init(>q6v5, pdev, rproc, MPSS_CRASH_REASON_SMEM,
>qcom_msa_handover);
> @@ -1808,6 +1838,7 @@ static const struct rproc_hexagon_res sc7180_mss = {
> },
> .need_mem_protection = true,
> .has_alt_reset = false,
> + .has_mba_logs = true,
> .has_spare_reg = true,
> .version = MSS_SC7180,
> };
> @@ -1843,6 +1874,7 @@ static const struct rproc_hexagon_res sdm845_mss = {
> },
> .need_mem_protection = true,
> .has_alt_reset = true,
> + .has_mba_logs = false,
> .has_spare_reg = false,
> .version = MSS_SDM845,
> };
> @@ -1870,6 +1902,7 @@ static const struct rproc_hexagon_res msm8998_mss = {
> },
> .need_mem_protection = true,
> .has_alt_reset = false,
> + .has_mba_logs = false,
> .has_spare_reg = false,
> .version = MSS_MSM8998,
> };
> @@ -1900,6 +1933,7 @@ static const struct rproc_hexagon_res msm8996_mss = {
> },
> .need_mem_protection = true,
> .has_alt_reset = false,
> + .has_mba_logs = false,
>
Re: [PATCH 3/3] soc: mediatek: pwrap: add pwrap driver for MT6873/8192 SoCs
Hi,
On Wed, 2020-07-22 at 00:51 +0200, Matthias Brugger wrote:
>
> On 14/07/2020 11:53, Hsin-Hsiung Wang wrote:
> > MT6873/8192 are highly integrated SoCs and use PMIC_MT6359 for
> > power management. This patch adds pwrap master driver to
> > access PMIC_MT6359.
> >
> > Signed-off-by: Hsin-Hsiung Wang
> > ---
> > drivers/soc/mediatek/mtk-pmic-wrap.c | 98
> >
> > 1 file changed, 87 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > index c897205..6e7f796f 100644
> > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > @@ -24,11 +24,13 @@
> > #define PWRAP_MT8135_BRIDGE_WDT_SRC_EN0x54
> >
> > /* macro for wrapper status */
> > +#define PWRAP_GET_SWINF_2_FSM(x) (((x) >> 1) & 0x0007)
> > #define PWRAP_GET_WACS_RDATA(x) (((x) >> 0) & 0x)
> > #define PWRAP_GET_WACS_FSM(x) (((x) >> 16) & 0x0007)
> > #define PWRAP_GET_WACS_REQ(x) (((x) >> 19) & 0x0001)
> > #define PWRAP_STATE_SYNC_IDLE0BIT(20)
> > #define PWRAP_STATE_INIT_DONE0BIT(21)
> > +#define PWRAP_STATE_INIT_DONE1 BIT(15)
> >
> > /* macro for WACS FSM */
> > #define PWRAP_WACS_FSM_IDLE 0x00
> > @@ -74,6 +76,7 @@
> > #define PWRAP_CAP_DCM BIT(2)
> > #define PWRAP_CAP_INT1_EN BIT(3)
> > #define PWRAP_CAP_WDT_SRC1BIT(4)
> > +#define PWRAP_CAP_ARB BIT(5)
>
> This commit should be two patches (at least). One adding PWRAP_CAP_ARB and
> then
> another one adding MT6873 support.
>
> Regards,
> Matthias
>
Thanks for the comment. I will update it in next patch.
> >
> > /* defines for slave device wrapper registers */
> > enum dew_regs {
[Delete]
Re: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support
Avri, > Martin - Can we move forward with this one? CHECK drivers/scsi/ufs/ufshcd-pltfrm.c drivers/scsi/ufs/ufsfeature.c:90:20: warning: symbol 'ufshpb_dev_type' was not declared. Should it be static? drivers/scsi/ufs/ufsfeature.c:104:17: warning: symbol 'ufsf_bus_type' was not declared. Should it be static? CC [M] drivers/scsi/ufs/ufsfeature.o CC [M] drivers/scsi/ufs/ufs_bsg.o CC [M] drivers/scsi/ufs/ufs-sysfs.o drivers/scsi/ufs/ufshpb.c:18:14: warning: symbol 'ufshpb_host_map_kbytes' was not declared. Should it be static? drivers/scsi/ufs/ufshpb.c:793:28: warning: mixing different enum types: drivers/scsi/ufs/ufshpb.c:793:28:unsigned int enum HPB_RGN_STATE drivers/scsi/ufs/ufshpb.c:793:28:unsigned int enum HPB_SRGN_STATE CC [M] drivers/scsi/ufs/ufshcd.o drivers/scsi/ufs/ufshpb.c:1026:31: warning: context imbalance in 'ufshpb_run_active_subregion_list' - different lock contexts for basic block -- Martin K. Petersen Oracle Linux Engineering
OF: Can't handle multiple dma-ranges with different offsets
Hi,
I've just fired up linux kernel v5.7 on a p2040 based system and I'm
getting the following new warning
OF: Can't handle multiple dma-ranges with different offsets on
node(/pcie@ffe202000)
OF: Can't handle multiple dma-ranges with different offsets on
node(/pcie@ffe202000)
The warning itself was added in commit 9d55bebd9816 ("of/address:
Support multiple 'dma-ranges' entries") but I gather it's pointing out
something about the dts. My boards dts is based heavily on p2041rdb.dts
and the relevant pci2 section is identical (reproduced below for reference).
pci2: pcie@ffe202000 {
reg = <0xf 0xfe202000 0 0x1000>;
ranges = <0x0200 0 0xe000 0xc 0x4000 0 0x2000
0x0100 0 0x 0xf 0xf802 0 0x0001>;
pcie@0 {
ranges = <0x0200 0 0xe000
0x0200 0 0xe000
0 0x2000
0x0100 0 0x
0x0100 0 0x
0 0x0001>;
};
};
I haven't noticed any ill effect (aside from the scary message). I'm not
sure if there's something missing in the dts or in the code that checks
the ranges. Any guidance would be appreciated.
Thanks,
Chris
Re: [PATCH v2 1/2] remoteproc: qcom_q6v5_mss: Add modem debug policy support
On 2020-07-22 09:24, Bjorn Andersson wrote:
On Tue 21 Jul 04:29 PDT 2020, Sibi Sankar wrote:
Add modem debug policy support which will enable coredumps and live
debug support when the msadp firmware is present on secure devices.
Signed-off-by: Sibi Sankar
---
v2:
* Use request_firmware_direct [Bjorn]
* Use Bjorn's template to show if debug policy is present
* Add size check to prevent memcpy out of bounds [Bjorn]
drivers/remoteproc/qcom_q6v5_mss.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 0b6f260eb5349..49cd16e050533 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -189,6 +189,7 @@ struct q6v5 {
phys_addr_t mba_phys;
void *mba_region;
size_t mba_size;
+ size_t dp_size;
phys_addr_t mpss_phys;
phys_addr_t mpss_reloc;
@@ -408,6 +409,14 @@ static int q6v5_xfer_mem_ownership(struct q6v5
*qproc, int *current_perm,
static int q6v5_load(struct rproc *rproc, const struct firmware *fw)
{
struct q6v5 *qproc = rproc->priv;
+ const struct firmware *dp_fw;
+
+ if (!request_firmware_direct(_fw, "msadp", qproc->dev) &&
fw->size <= SZ_1M &&
+ (SZ_1M + dp_fw->size) <= qproc->mba_size) {
+ memcpy(qproc->mba_region + SZ_1M, dp_fw->data, dp_fw->size);
+ qproc->dp_size = dp_fw->size;
+ release_firmware(dp_fw);
If request_firmware_direct() succeeds, but return a firmware blob
bigger
than mba_size - SZ_1M you won't get here and will end up leaking dp_fw.
Additionally, there really isn't a need for requesting the firmware in
the first place if fw->size > SZ_1M.
So I think it's better if you break this out in it's own function where
you don't need to squeeze everything into one or two conditionals.
I'll fix dp_fw leak and move it
to a new func. Thanks for the
review.
Regards,
Bjorn
+ }
memcpy(qproc->mba_region, fw->data, fw->size);
@@ -896,6 +905,10 @@ static int q6v5_mba_load(struct q6v5 *qproc)
}
writel(qproc->mba_phys, qproc->rmb_base + RMB_MBA_IMAGE_REG);
+ if (qproc->dp_size) {
+ writel(qproc->mba_phys + SZ_1M, qproc->rmb_base +
RMB_PMI_CODE_START_REG);
+ writel(qproc->dp_size, qproc->rmb_base +
RMB_PMI_CODE_LENGTH_REG);
+ }
ret = q6v5proc_reset(qproc);
if (ret)
@@ -1257,7 +1270,8 @@ static int q6v5_start(struct rproc *rproc)
if (ret)
return ret;
- dev_info(qproc->dev, "MBA booted, loading mpss\n");
+ dev_info(qproc->dev, "MBA booted with%s debug policy, loading
mpss\n",
+qproc->dp_size ? "" : "out");
ret = q6v5_mpss_load(qproc);
if (ret)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: WARNING in pvr2_i2c_core_done
Hello, syzbot has tested the proposed patch but the reproducer is still triggering an issue: general protection fault in kernfs_find_ns pvrusb2: Invalid write control endpoint pvrusb2: Invalid write control endpoint pvrusb2: Invalid write control endpoint pvrusb2: Invalid write control endpoint general protection fault, probably for non-canonical address 0xdc0e: [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0070-0x0077] CPU: 0 PID: 78 Comm: pvrusb2-context Not tainted 5.7.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:kernfs_find_ns+0x31/0x370 fs/kernfs/dir.c:829 Code: 49 89 d6 41 55 41 54 55 48 89 fd 53 48 83 ec 08 e8 f4 61 af ff 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 1e 03 00 00 48 8d bd 98 00 00 00 48 8b 5d 70 48 RSP: 0018:8881d419f938 EFLAGS: 00010202 RAX: dc00 RBX: 863789c0 RCX: 85a79ba7 RDX: 000e RSI: 81901d1c RDI: 0070 RBP: R08: R09: 873ed1e7 R10: fbfff0e7da3c R11: 0001 R12: R13: R14: R15: 863790e0 FS: () GS:8881db20() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f3a7e248000 CR3: 0001d2224000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: kernfs_find_and_get_ns+0x2f/0x60 fs/kernfs/dir.c:906 kernfs_find_and_get include/linux/kernfs.h:548 [inline] sysfs_unmerge_group+0x5d/0x160 fs/sysfs/group.c:366 dpm_sysfs_remove+0x62/0xb0 drivers/base/power/sysfs.c:790 device_del+0x18b/0xd20 drivers/base/core.c:2834 device_unregister+0x22/0xc0 drivers/base/core.c:2889 i2c_unregister_device include/linux/err.h:41 [inline] i2c_client_dev_release+0x39/0x50 drivers/i2c/i2c-core-base.c:465 device_release+0x71/0x200 drivers/base/core.c:1559 kobject_cleanup lib/kobject.c:693 [inline] kobject_release lib/kobject.c:722 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x245/0x540 lib/kobject.c:739 put_device drivers/base/core.c:2779 [inline] device_unregister+0x34/0xc0 drivers/base/core.c:2890 i2c_unregister_device+0x38/0x40 include/linux/err.h:41 v4l2_i2c_new_subdev_board+0x159/0x2c0 drivers/media/v4l2-core/v4l2-i2c.c:114 v4l2_i2c_new_subdev+0xb8/0xf0 drivers/media/v4l2-core/v4l2-i2c.c:135 pvr2_hdw_load_subdev drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2023 [inline] pvr2_hdw_load_modules drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2075 [inline] pvr2_hdw_setup_low drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2156 [inline] pvr2_hdw_setup drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2262 [inline] pvr2_hdw_initialize+0xc8d/0x3600 drivers/media/usb/pvrusb2/pvrusb2-hdw.c:2339 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:109 [inline] pvr2_context_thread_func+0x250/0x850 drivers/media/usb/pvrusb2/pvrusb2-context.c:158 kthread+0x392/0x470 kernel/kthread.c:291 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351 Modules linked in: ---[ end trace a2576a16aa8e791c ]--- RIP: 0010:kernfs_find_ns+0x31/0x370 fs/kernfs/dir.c:829 Code: 49 89 d6 41 55 41 54 55 48 89 fd 53 48 83 ec 08 e8 f4 61 af ff 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 1e 03 00 00 48 8d bd 98 00 00 00 48 8b 5d 70 48 RSP: 0018:8881d419f938 EFLAGS: 00010202 RAX: dc00 RBX: 863789c0 RCX: 85a79ba7 RDX: 000e RSI: 81901d1c RDI: 0070 RBP: R08: R09: 873ed1e7 R10: fbfff0e7da3c R11: 0001 R12: R13: R14: R15: 863790e0 FS: () GS:8881db20() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f3a7e248000 CR3: 0001d2224000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Tested on: commit: b791d1bd Merge tag 'locking-kcsan-2020-06-11' of git://git.. git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=1208f43710 kernel config: https://syzkaller.appspot.com/x/.config?x=ccf1899337a6e343 dashboard link: https://syzkaller.appspot.com/bug?extid=e74a998ca8f1df9cc332 compiler: gcc (GCC) 10.1.0-syz 20200507 patch: https://syzkaller.appspot.com/x/patch.diff?x=14d5643090
Re: [PATCH v2] xtensa: add boot subdirectories targets to extra-y
On Tue, Jul 21, 2020 at 5:53 PM Masahiro Yamada wrote:
> On Tue, Jul 21, 2020 at 6:37 PM Max Filippov wrote:
> > The commit 8fe87a92f262 ("kbuild: always create directories of targets")
> > exposed an issue in the xtensa makefiles that results in the following
> > build error in a clean directory:
>
> But, we need to fix this in the kbuild tree
> to retain the bisectability.
>
> I will insert the following before the offending commit.
> https://patchwork.kernel.org/patch/11676883/
>
> I used 'targets' instead of 'extra-y'
> because they are built on demand
> while building the final boot image.
Sure, please go ahead with your version.
Thank you for taking care of it.
-- Max
Re: [PATCH] xtensa: add boot subdirectories build artifacts to 'targets'
On Tue, Jul 21, 2020 at 5:47 PM Masahiro Yamada wrote: > > Xtensa always rebuilds the following even if nothing in the source code > has been changed. Passing V=2 shows the reason. > > AS arch/xtensa/boot/boot-elf/bootstrap.o - due to bootstrap.o not in > $(targets) > LDS arch/xtensa/boot/boot-elf/boot.lds - due to boot.lds not in > $(targets) > > They are built by if_changed(_dep). Add them to 'targets' so .*.cmd files > are included. > > Signed-off-by: Masahiro Yamada > --- > > arch/xtensa/boot/boot-elf/Makefile | 1 + > arch/xtensa/boot/boot-redboot/Makefile | 1 + > 2 files changed, 2 insertions(+) Acked-by: Max Filippov -- Thanks. -- Max
Re: [PATCH v2 1/2] remoteproc: qcom_q6v5_mss: Add modem debug policy support
On Tue 21 Jul 04:29 PDT 2020, Sibi Sankar wrote:
> Add modem debug policy support which will enable coredumps and live
> debug support when the msadp firmware is present on secure devices.
>
> Signed-off-by: Sibi Sankar
> ---
>
> v2:
> * Use request_firmware_direct [Bjorn]
> * Use Bjorn's template to show if debug policy is present
> * Add size check to prevent memcpy out of bounds [Bjorn]
>
> drivers/remoteproc/qcom_q6v5_mss.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index 0b6f260eb5349..49cd16e050533 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -189,6 +189,7 @@ struct q6v5 {
> phys_addr_t mba_phys;
> void *mba_region;
> size_t mba_size;
> + size_t dp_size;
>
> phys_addr_t mpss_phys;
> phys_addr_t mpss_reloc;
> @@ -408,6 +409,14 @@ static int q6v5_xfer_mem_ownership(struct q6v5 *qproc,
> int *current_perm,
> static int q6v5_load(struct rproc *rproc, const struct firmware *fw)
> {
> struct q6v5 *qproc = rproc->priv;
> + const struct firmware *dp_fw;
> +
> + if (!request_firmware_direct(_fw, "msadp", qproc->dev) && fw->size
> <= SZ_1M &&
> + (SZ_1M + dp_fw->size) <= qproc->mba_size) {
> + memcpy(qproc->mba_region + SZ_1M, dp_fw->data, dp_fw->size);
> + qproc->dp_size = dp_fw->size;
> + release_firmware(dp_fw);
If request_firmware_direct() succeeds, but return a firmware blob bigger
than mba_size - SZ_1M you won't get here and will end up leaking dp_fw.
Additionally, there really isn't a need for requesting the firmware in
the first place if fw->size > SZ_1M.
So I think it's better if you break this out in it's own function where
you don't need to squeeze everything into one or two conditionals.
Regards,
Bjorn
> + }
>
> memcpy(qproc->mba_region, fw->data, fw->size);
>
> @@ -896,6 +905,10 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> }
>
> writel(qproc->mba_phys, qproc->rmb_base + RMB_MBA_IMAGE_REG);
> + if (qproc->dp_size) {
> + writel(qproc->mba_phys + SZ_1M, qproc->rmb_base +
> RMB_PMI_CODE_START_REG);
> + writel(qproc->dp_size, qproc->rmb_base +
> RMB_PMI_CODE_LENGTH_REG);
> + }
>
> ret = q6v5proc_reset(qproc);
> if (ret)
> @@ -1257,7 +1270,8 @@ static int q6v5_start(struct rproc *rproc)
> if (ret)
> return ret;
>
> - dev_info(qproc->dev, "MBA booted, loading mpss\n");
> + dev_info(qproc->dev, "MBA booted with%s debug policy, loading mpss\n",
> + qproc->dp_size ? "" : "out");
>
> ret = q6v5_mpss_load(qproc);
> if (ret)
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH v4 4/4] dt-bindings: timer: Add CLINT bindings
On Tue, Jul 21, 2020 at 5:48 PM Sean Anderson wrote: > > On 7/20/20 9:15 PM, Atish Patra wrote: > > On Fri, Jul 17, 2020 at 12:52 AM Anup Patel wrote: > >> > >> We add DT bindings documentation for CLINT device. > >> > >> Signed-off-by: Anup Patel > >> Reviewed-by: Palmer Dabbelt > >> Tested-by: Emil Renner Berhing > >> --- > >> .../bindings/timer/sifive,clint.yaml | 58 +++ > >> 1 file changed, 58 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/timer/sifive,clint.yaml > >> > >> diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml > >> b/Documentation/devicetree/bindings/timer/sifive,clint.yaml > >> new file mode 100644 > >> index ..8ad115611860 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml > >> @@ -0,0 +1,58 @@ > >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >> +%YAML 1.2 > >> +--- > >> +$id: http://devicetree.org/schemas/timer/sifive,clint.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: SiFive Core Local Interruptor > >> + > >> +maintainers: > >> + - Palmer Dabbelt > >> + - Anup Patel > >> + > >> +description: > >> + SiFive (and other RISC-V) SOCs include an implementation of the SiFive > >> + Core Local Interruptor (CLINT) for M-mode timer and M-mode > >> inter-processor > >> + interrupts. It directly connects to the timer and inter-processor > >> interrupt > >> + lines of various HARTs (or CPUs) so RISC-V per-HART (or per-CPU) local > >> + interrupt controller is the parent interrupt controller for CLINT > >> device. > >> + The clock frequency of CLINT is specified via "timebase-frequency" DT > >> + property of "/cpus" DT node. The "timebase-frequency" DT property is > >> + described in Documentation/devicetree/bindings/riscv/cpus.yaml > >> + > >> +properties: > >> + compatible: > >> +items: > >> + - const: sifive,clint0 > >> + - const: sifive,fu540-c000-clint > >> + > >> +description: > >> + Should be "sifive,-clint" and "sifive,clint". > >> + Supported compatible strings are - > >> + "sifive,fu540-c000-clint" for the SiFive CLINT v0 as integrated > >> + onto the SiFive FU540 chip, and "sifive,clint0" for the SiFive > >> + CLINT v0 IP block with no chip integration tweaks. > >> + Please refer to sifive-blocks-ip-versioning.txt for details > >> + > > > > As the DT binding suggests that the clint device should be named as > > "sifive,**", > > I think we should change the DT property in kendryte dts as well. > > The kendryte device is based on Rocket Chip, not any SiFive IP/device. > If anything, the general binding should be "chipsalliance,clint" and the > specific bindings should be "sifive,clint" and "kendryte,clint" (or > "canaan,clint"). AFAIK, Palmer clearly mentioned in previous discussion that CLINT spec is still owned by SiFive. No matter who implements CLINT device in their SOC, we will need one compatible string to represent the spec version (i.e. "sifive,clint0") and another compatible representing specific implementation (for kendryte this can be "kendryte,k210-clint"). Regards, Anup
Re: [PATCH] xtensa: fix access check in csum_and_copy_from_user
On Tue, Jul 21, 2020 at 4:04 PM Al Viro wrote:
>
> On Tue, Jul 21, 2020 at 03:00:35PM -0700, Max Filippov wrote:
> > Commit d341659f470b ("xtensa: switch to providing
> > csum_and_copy_from_user()") introduced access check, but incorrectly
> > tested dst instead of src.
> > Fix access_ok argument in csum_and_copy_from_user.
>
> Applied, with apologies... Which tree do you want it to go through?
> I'm dropping it into vfs.git#fixes, will send to Linus unless you
> prefer it to go some other way...
NP. Anything that will go into 5.8 is good.
--
Thanks.
-- Max
Re: [PATCH v3 2/2] soc: mediatek: add mtk-devapc driver
Hi Chun-Kuang,
On Wed, 2020-07-22 at 07:21 +0800, Chun-Kuang Hu wrote:
> Hi, Neal:
>
> Neal Liu 於 2020年7月21日 週二 下午12:00寫道：
> >
> > MediaTek bus fabric provides TrustZone security support and data
> > protection to prevent slaves from being accessed by unexpected
> > masters.
> > The security violation is logged and sent to the processor for
> > further analysis or countermeasures.
> >
> > Any occurrence of security violation would raise an interrupt, and
> > it will be handled by mtk-devapc driver. The violation
> > information is printed in order to find the murderer.
> >
> > Signed-off-by: Neal Liu
> > ---
>
> [snip]
>
> > +
> > +static u32 get_shift_group(struct mtk_devapc_context *ctx, u32 vio_idx)
>
> vio_idx is useless, so remove it.
Okay, I'll remove it in next patch.
>
> > +{
> > + u32 vio_shift_sta;
> > + void __iomem *reg;
> > +
> > + reg = ctx->devapc_pd_base + ctx->offset->vio_shift_sta;
> > + vio_shift_sta = readl(reg);
> > +
> > + if (vio_shift_sta)
> > + return __ffs(vio_shift_sta);
> > +
> > + return 31;
> > +}
> > +
>
> [snip]
>
> > +
> > +/*
> > + * mtk_devapc_dump_vio_dbg - get the violation index and dump the full
> > violation
> > + * debug information.
> > + */
> > +static bool mtk_devapc_dump_vio_dbg(struct mtk_devapc_context *ctx, u32
> > vio_idx)
> > +{
> > + u32 shift_bit;
> > +
> > + if (check_vio_mask(ctx, vio_idx))
> > + return false;
> > +
> > + if (!check_vio_status(ctx, vio_idx))
> > + return false;
> > +
> > + shift_bit = get_shift_group(ctx, vio_idx);
> > +
> > + if (sync_vio_dbg(ctx, shift_bit))
> > + return false;
> > +
> > + devapc_extract_vio_dbg(ctx);
>
> I think get_shift_group(), sync_vio_dbg(), and
> devapc_extract_vio_dbg() should be moved out of vio_idx for-loop (the
> loop in devapc_violation_irq()) because these three function is not
> related to vio_idx.
> Another question: when multiple vio_idx violation occur, vio_addr is
> related to which one vio_idx? The latest happened one?
>
Actually, it's related to vio_idx. But we don't use it directly on these
function. I think below snip code might be better way to understand it.
for (...)
{
check_vio_mask()
check_vio_status()
// if get vio_idx, mask it temporarily
mask_module_irq(true)
clear_vio_status()
// dump violation info
get_shift_group()
sync_vio_dbg()
devapc_extract_vio_dbg()
// unmask
mask_module_irq(false)
}
About your question, vio_addr would be the first one.
> > +
> > + return true;
> > +}
> > +
> > +/*
> > + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR) will
> > dump
> > + *violation information including which master
> > violates
> > + *access slave.
> > + */
> > +static irqreturn_t devapc_violation_irq(int irq_number,
> > + struct mtk_devapc_context *ctx)
> > +{
> > + u32 vio_idx;
> > +
> > + for (vio_idx = 0; vio_idx < ctx->vio_idx_num; vio_idx++) {
> > + if (!mtk_devapc_dump_vio_dbg(ctx, vio_idx))
> > + continue;
> > +
> > + /* Ensure that violation info are written before
> > +* further operations
> > +*/
> > + smp_mb();
> > +
> > + /*
> > +* Mask slave's irq before clearing vio status.
> > +* Must do it to avoid nested interrupt and prevent
> > +* unexpected behavior.
> > +*/
> > + mask_module_irq(ctx, vio_idx, true);
> > +
> > + clear_vio_status(ctx, vio_idx);
> > +
> > + mask_module_irq(ctx, vio_idx, false);
> > + }
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +/*
> > + * start_devapc - initialize devapc status and start receiving interrupt
> > + *while devapc violation is triggered.
> > + */
> > +static int start_devapc(struct mtk_devapc_context *ctx)
> > +{
> > + void __iomem *pd_vio_shift_sta_reg;
> > + void __iomem *pd_apc_con_reg;
> > + u32 vio_shift_sta;
> > + u32 vio_idx;
> > +
> > + pd_apc_con_reg = ctx->devapc_pd_base + ctx->offset->apc_con;
> > + pd_vio_shift_sta_reg = ctx->devapc_pd_base +
> > ctx->offset->vio_shift_sta;
> > + if (!pd_apc_con_reg || !pd_vio_shift_sta_reg)
> > + return -EINVAL;
> > +
> > + /* Clear devapc violation status */
> > + writel(BIT(31), pd_apc_con_reg);
> > +
> > + /* Clear violation shift status */
> > + vio_shift_sta = readl(pd_vio_shift_sta_reg);
> > + if (vio_shift_sta)
> > + writel(vio_shift_sta, pd_vio_shift_sta_reg);
> > +
> > + /* Clear slave violation status */
> > + for (vio_idx = 0; vio_idx <
Re: [PATCH V2] arm64: dts: qcom: sc7180: Include xo clock to sdhc clocks list
On Tue 21 Jul 03:44 PDT 2020, Shaik Sajida Bhanu wrote: > From: Veerabhadrarao Badiganti > > Include xo clock to sdhc clocks list which will be used > in calculating MCLK_FREQ field of DLL_CONFIG2 register. > Can you please describe why this is useful, perhaps required? What difference does this make and what problem does it resolve? If required please include a Fixes: tag here to show that you're fixing the previous commit. Thanks, Bjorn > Signed-off-by: Veerabhadrarao Badiganti > Signed-off-by: Shaik Sajida Bhanu > --- > arch/arm64/boot/dts/qcom/sc7180.dtsi | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi > b/arch/arm64/boot/dts/qcom/sc7180.dtsi > index d78a066..7ccb780 100644 > --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi > @@ -682,8 +682,9 @@ > interrupt-names = "hc_irq", "pwr_irq"; > > clocks = < GCC_SDCC1_APPS_CLK>, > - < GCC_SDCC1_AHB_CLK>; > - clock-names = "core", "iface"; > + < GCC_SDCC1_AHB_CLK>, > + <_board>; > + clock-names = "core", "iface", "xo"; > interconnects = <_noc MASTER_EMMC _virt > SLAVE_EBI1>, > <_noc MASTER_APPSS_PROC _noc > SLAVE_EMMC_CFG>; > interconnect-names = "sdhc-ddr","cpu-sdhc"; > @@ -2481,8 +2482,9 @@ > interrupt-names = "hc_irq", "pwr_irq"; > > clocks = < GCC_SDCC2_APPS_CLK>, > - < GCC_SDCC2_AHB_CLK>; > - clock-names = "core", "iface"; > + < GCC_SDCC2_AHB_CLK>, > + <_board>; > + clock-names = "core", "iface", "xo"; > > interconnects = <_noc MASTER_SDCC_2 _virt > SLAVE_EBI1>, > <_noc MASTER_APPSS_PROC _noc > SLAVE_SDCC_2>; > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation >
Re: [PATCH][next] PCI: rcar-gen2: Use fallthrough pseudo-keyword
Hi Geert, On 7/17/20 02:18, Geert Uytterhoeven wrote: > Hi Gustavo, > > Thanks for your patch! > > On Thu, Jul 16, 2020 at 11:11 PM Gustavo A. R. Silva > wrote: >> Replace the existing /* fall through */ comments and its variants with >> the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary >> fall-through markings when it is the case. > > Which unnecessary marking is being removed? > I don't see any. > There is none. I will remove those lines and send v2 with a URL to the proper documentation for Linux v5.7 instead of 'lastest', see: https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through I'll add your Reviewed-by tag. :) >> >> [1] >> https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through >> >> Signed-off-by: Gustavo A. R. Silva > > For the actual patch contents: > Reviewed-by: Geert Uytterhoeven > Thanks! -- Gustavo
Re: [PATCH V2] arm64: dts: qcom: sc7180: SD-card GPIO pin set bias-pull up
On Tue 21 Jul 03:44 PDT 2020, Shaik Sajida Bhanu wrote:
> From: Veerabhadrarao Badiganti
>
> On some sc7180 based platforms where external pull is not present on cd-gpio,
> this gpio state is getting read as HIGH when sleep config is applied on it.
> This is resulting in SDcard rescan after suspend-resume even though SDcard
> is not present.
>
This is exactly why pinconf properties (such as bias, drive-strength)
should be defined in the board specific file.
Please move the "pinconf-sd-cd" node to sc7180-idp.dts.
Regards,
Bjorn
> Update cd-gpio sleep config with bais-pull to fix this issue.
>
> Signed-off-by: Veerabhadrarao Badiganti
> Signed-off-by: Shaik Sajida Bhanu
> ---
>
> Changes since V1:
> - Incorporated review comments by Bjorn Andersson.
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index d78a066..a3527c3 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -1819,7 +1819,7 @@
>
> pinconf-sd-cd {
> pins = "gpio69";
> - bias-disable;
> + bias-pull-up;
> drive-strength = <2>;
> };
> };
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
Re: [PATCH][next] PCI: imx6: Use fallthrough pseudo-keyword
Hi Bjorn, On 7/16/20 17:06, Bjorn Helgaas wrote: > On Thu, Jul 16, 2020 at 04:10:52PM -0500, Gustavo A. R. Silva wrote: >> Replace the existing /* fall through */ comments and its variants with >> the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary >> fall-through markings when it is the case. >> >> [1] >> https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through > > Hi Gustavo, > > I'm certainly fine with these patches, and thanks for doing them! > > And thanks for providing a link to the rationale. But the URL > contains "latest", so I think it may break if deprecated.rst or the > section is ever renamed. > > I think I would prefer if we could reference the current text, e.g., > via > > > https://www.kernel.org/doc/html/v5.7-rc7/process/deprecated.html#implicit-switch-case-fall-through > I already sent v2 with a URL to proper documentation for Linux v5.7: https://lore.kernel.org/lkml/20200722031903.GA3711@embeddedor/ > (The v5.7 doc would be better but doesn't seem to be generated yet; I > pinged the helpdesk about that.) > Thanks for doing that. I wasn't aware that one could ask helpdesk about this. -- Gustavo
Re: [PATCH v4 2/4] clocksource/drivers: Add CLINT timer driver
On Tue, Jul 21, 2020 at 5:45 PM Daniel Lezcano
wrote:
>
> On 21/07/2020 13:49, Anup Patel wrote:
> > On Tue, Jul 21, 2020 at 4:32 PM Daniel Lezcano
> > wrote:
> >>
> >> On 17/07/2020 09:50, Anup Patel wrote:
> >>> We add a separate CLINT timer driver for Linux RISC-V M-mode (i.e.
> >>> RISC-V NoMMU kernel).
> >>>
> >>> The CLINT MMIO device provides three things:
> >>> 1. 64bit free running counter register
> >>> 2. 64bit per-CPU time compare registers
> >>> 3. 32bit per-CPU inter-processor interrupt registers
> >>>
> >>> Unlike other timer devices, CLINT provides IPI registers along with
> >>> timer registers. To use CLINT IPI registers, the CLINT timer driver
> >>> provides IPI related callbacks to arch/riscv.
> >>>
> >>> Signed-off-by: Anup Patel
> >>> Tested-by: Emil Renner Berhing
> >>> ---
> >>> drivers/clocksource/Kconfig | 9 ++
> >>> drivers/clocksource/Makefile | 1 +
> >>> drivers/clocksource/timer-clint.c | 231 ++
> >>> include/linux/cpuhotplug.h| 1 +
> >>> 4 files changed, 242 insertions(+)
> >>> create mode 100644 drivers/clocksource/timer-clint.c
> >>>
> >>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> >>> index 91418381fcd4..e1ce0d510a03 100644
> >>> --- a/drivers/clocksource/Kconfig
> >>> +++ b/drivers/clocksource/Kconfig
> >>> @@ -658,6 +658,15 @@ config RISCV_TIMER
> >>> is accessed via both the SBI and the rdcycle instruction. This is
> >>> required for all RISC-V systems.
> >>>
> >>> +config CLINT_TIMER
> >>> + bool "Timer for the RISC-V platform"
> >>> + depends on GENERIC_SCHED_CLOCK && RISCV_M_MODE
> >>> + select TIMER_PROBE
> >>> + select TIMER_OF
> >>> + help
> >>> + This option enables the CLINT timer for RISC-V systems. The CLINT
> >>> + driver is usually used for NoMMU RISC-V systems.
> >>
> >> V3 has a comment about fixing the Kconfig option.
> >
> > I have removed "default y" from the Kconfig option as-per your suggestions.
> >
> > I looked at other Timer Kconfig options. Most of them have menuconfig name.
> > Also, we can certainly have different timer MMIO timer drivers in future. Do
> > you still insist on making this kconfig option totally silent ??
>
> Yes, and there is an effort to change the entries to be silent as much
> as possible.
>
> Just add:
>
> bool "Timer for the RISC-V platform" if COMPILE_TEST
Okay, I will update.
>
> and remove the RISCV_M_MODE dependency.
CLINT driver depends on RISC-V specific symbols from asm/smp.h
so we should at least have "depends on RISCV" so that compile
test does not fail.
Agree ??
>
> Or alternatively:
>
> replace the RISCV_M_MODE dependency with COMPILE_TEST
>
> The goal is to be able to compile the driver on different platforms for
> compilation test covering.
Please see the above comment.
>
> Then when more mmio drivers will added we will figure out.
>
> >> [ ... ]
> >>
> >>> +{
> >>> + bool *registered = per_cpu_ptr(_clock_event_registered, cpu);
> >>> + struct clock_event_device *ce = per_cpu_ptr(_clock_event,
> >>> cpu);
> >>> +
> >>> + if (!(*registered)) {
> >>> + ce->cpumask = cpumask_of(cpu);
> >>> + clockevents_config_and_register(ce, clint_timer_freq, 200,
> >>> + ULONG_MAX);
> >>> + *registered = true;
> >>> + }
> >>
> >>
> >> I was unsure about the clockevents_config_and_register() multiple calls
> >> when doing the comment. It seems like it is fine to call it several
> >> times and that is done in several places like riscv or arch_arm_timer.
> >>
> >> It is probably safe to drop the 'registered' code here, sorry for the
> >> confusion.
> >
> > Okay, will revert these changes.
> >
> >>
> >>> + enable_percpu_irq(clint_timer_irq,
> >>> + irq_get_trigger_type(clint_timer_irq));
> >>> + return 0;
> >>> +}
> >>> +
> >>
> >> [ ... ]
> >>
> >>
> >> --
> >> Facebook |
> >> Twitter |
> >> Facebook |
> Twitter |
>
Re: [PATCH][next] sparc: Use fallthrough pseudo-keyword
On 7/21/20 20:29, David Miller wrote: > From: "Gustavo A. R. Silva" > Date: Tue, 7 Jul 2020 12:24:36 -0500 > >> Replace the existing /* fall through */ comments and its variants with >> the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary >> fall-through markings when it is the case. >> >> [1] >> https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through >> >> Signed-off-by: Gustavo A. R. Silva > > Applied. > Thanks, Dave. -- Gustavo
[PATCH v2][next] PCI: rcar-gen2: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1].
[1]
https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
- Update URL. Use proper URL to Linux v5.7 documentation.
- Add Geert's Reviewed-by tag.
- Update changelog text.
drivers/pci/controller/pci-rcar-gen2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-rcar-gen2.c
b/drivers/pci/controller/pci-rcar-gen2.c
index 326171cb1a97..2ec7093a7588 100644
--- a/drivers/pci/controller/pci-rcar-gen2.c
+++ b/drivers/pci/controller/pci-rcar-gen2.c
@@ -228,7 +228,7 @@ static int rcar_pci_setup(int nr, struct pci_sys_data *sys)
pr_warn("unknown window size %ld - defaulting to 256M\n",
priv->window_size);
priv->window_size = SZ_256M;
- /* fall-through */
+ fallthrough;
case SZ_256M:
val |= RCAR_USBCTR_PCIAHB_WIN1_256M;
break;
--
2.27.0
linux-next: manual merge of the bpf-next tree with the net tree
Hi all,
Today's linux-next merge of the bpf-next tree got conflicts in:
net/ipv4/udp.c
net/ipv6/udp.c
between commit:
efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.")
from the net tree and commits:
7629c73a1466 ("udp: Extract helper for selecting socket from reuseport group")
2a08748cd384 ("udp6: Extract helper for selecting socket from reuseport
group")
from the bpf-next tree.
I fixed it up (I wasn't sure how to proceed, so I used the latter
version) and can carry the fix as necessary. This is now fixed as far
as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpC9FYjIIpMa.pgp
Description: OpenPGP digital signature
[rcu:dev.2020.07.14a] BUILD SUCCESS aace6daf32cce6b644083754c7be6260aae439db
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2020.07.14a branch HEAD: aace6daf32cce6b644083754c7be6260aae439db refperf: Avoid null pointer dereference when buf fails to allocate elapsed time: 2074m configs tested: 91 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig sh alldefconfig mips bigsur_defconfig arm sama5_defconfig arm omap1_defconfig mipse55_defconfig s390 debug_defconfig arm pxa3xx_defconfig m68km5407c3_defconfig sh sdk7780_defconfig c6x dsk6455_defconfig arm h5000_defconfig i386 allyesconfig i386defconfig i386 debian-10.3 i386 allnoconfig ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20200721 i386 randconfig-a005-20200721 i386 randconfig-a004-20200721 i386 randconfig-a006-20200721 i386 randconfig-a002-20200721 i386 randconfig-a001-20200721 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64 kexec x86_64 rhel x86_64lkp x86_64 fedora-25 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
On 7/22/20 11:07 AM, Lu Baolu wrote: On 7/22/20 11:03 AM, Jun Miao wrote: On 7/22/20 10:40 AM, Lu Baolu wrote: Hi Jun, On 7/22/20 10:26 AM, Miao, Jun wrote: Kernel panic - not syncing: DMAR hardware is malfunctioning CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019 Call Trace: dump_stack+0x59/0x75 panic+0xff/0x2d4 iommu_disable_translation+0x88/0x90 iommu_suspend+0x12f/0x1b0 syscore_suspend+0x6c/0x220 suspend_devices_and_enter+0x313/0x840 pm_suspend+0x30d/0x390 state_store+0x82/0xf0 kobj_attr_store+0x12/0x20 sysfs_kf_write+0x3c/0x50 kernfs_fop_write+0x11d/0x190 __vfs_write+0x1b/0x40 vfs_write+0xc6/0x1d0 ksys_write+0x5e/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x4d/0x150 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f97b8080113 Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18 RSP: 002b:7ffcfa6f48b8 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 0004 RCX: 7f97b8080113 RDX: 0004 RSI: 55e7db03b700 RDI: 0004 RBP: 55e7db03b700 R08: 55e7db03b700 R09: 0004 R10: 0004 R11: 0246 R12: 0004 R13: 55e7db039380 R14: 0004 R15: 7f97b814d700 Kernel Offset: 0x38a0 from 0x8100 (relocation range: 0x8000-0xbfff) ---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]--- Do you mean that system hangs in iommu_disable_translation() without this fix. Yes ,From the call trace and i also read the DMARD_GCMD_RGS is wrong without this patch. Okay! Thanks a lot for confirming this. Best regards, baolu [S3 successfully with the patch] And, this failure disappeared after you applied this fix? YES , the log is too long , only head and tail . this failure disappereared. Best regards, baolu
[PATCH v2] i2c: fix WARNING in pvr2_i2c_core_done
#syz test: https://github.com/google/kasan.git usb-fuzzer
fix WARNING in pvr2_i2c_core_done by
unregistering device in the release handler
instead of the disconnect handler, setting the
linked flag after adding adapter to i2c,
and removing a call to acpi_ut_delete_generic_state()
Reported-by: syzbot+e74a998ca8f1df9cc...@syzkaller.appspotmail.com
Signed-off-by: B K Karthik
---
v1 -> v2:
remove a call to acpi_ut_delete_generic state
and set linked flag after adding adapter to
i2c as suggested by Hillf Danton
drivers/acpi/acpica/utdelete.c | 5 -
drivers/i2c/i2c-core-base.c | 2 +-
drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c | 4 ++--
3 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpica/utdelete.c b/drivers/acpi/acpica/utdelete.c
index c365faf4e6cd..e36f51725854 100644
--- a/drivers/acpi/acpica/utdelete.c
+++ b/drivers/acpi/acpica/utdelete.c
@@ -648,11 +648,6 @@ acpi_ut_update_object_reference(union acpi_operand_object
*object, u16 action)
/* Free any stacked Update State objects */
- while (state_list) {
- state = acpi_ut_pop_generic_state(_list);
- acpi_ut_delete_generic_state(state);
- }
-
return (status);
}
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 26f03a14a478..2d377d2e89f1 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -462,6 +462,7 @@ static void i2c_device_shutdown(struct device *dev)
static void i2c_client_dev_release(struct device *dev)
{
+ i2c_unregister_device(to_i2c_client(dev));
kfree(to_i2c_client(dev));
}
@@ -1527,7 +1528,6 @@ void i2c_del_adapter(struct i2c_adapter *adap)
dev_dbg(>dev, "Removing %s at 0x%x\n", client->name,
client->addr);
list_del(>detected);
- i2c_unregister_device(client);
}
mutex_unlock(>userspace_clients_lock);
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c
b/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c
index 63db04fe12d3..09b2c878f459 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c
@@ -623,9 +623,9 @@ void pvr2_i2c_core_init(struct pvr2_hdw *hdw)
hdw->i2c_adap.dev.parent = >usb_dev->dev;
hdw->i2c_adap.algo = >i2c_algo;
hdw->i2c_adap.algo_data = hdw;
- hdw->i2c_linked = !0;
i2c_set_adapdata(>i2c_adap, >v4l2_dev);
- i2c_add_adapter(>i2c_adap);
+ if (!i2c_add_adapter(>i2c_adap))
+ hdw->i2c_linked =!0;
if (hdw->i2c_func[0x18] == i2c_24xxx_ir) {
/* Probe for a different type of IR receiver on this
device. This is really the only way to differentiate
--
2.20.1
signature.asc
Description: PGP signature
Re: [PATCH v2 2/2] ASoC: qcom: sc7180: Add machine driver for sound card registration
On Tue, Jul 21, 2020 at 6:44 PM Cheng-Yi Chiang wrote:
> diff --git a/sound/soc/qcom/sc7180.c b/sound/soc/qcom/sc7180.c
> new file mode 100644
> index ..3beb2b129d01
> --- /dev/null
> +++ b/sound/soc/qcom/sc7180.c
> @@ -0,0 +1,380 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +//Copyright (c) 2020, The Linux Foundation. All rights reserved.
> +//
> +//sc7180.c -- ALSA SoC Machine driver for SC7180
Insert an extra space between // and text to make it look better.
> +static int sc7180_headset_init(struct snd_soc_component *component);
> +
> +static struct snd_soc_aux_dev sc7180_headset_dev = {
> + .dlc = COMP_EMPTY(),
> + .init = sc7180_headset_init,
> +};
Move definition of sc7180_headset_dev after sc7180_headset_init( ) so
that you don't need forward declaration of sc7180_headset_init( ).
> +static unsigned int primary_dai_fmt = SND_SOC_DAIFMT_CBS_CFS |
> + SND_SOC_DAIFMT_NB_NF |
> + SND_SOC_DAIFMT_I2S;
> +
> +static int sc7180_snd_startup(struct snd_pcm_substream *substream)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct snd_soc_card *card = rtd->card;
> + struct sc7180_snd_data *data = snd_soc_card_get_drvdata(card);
> + struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
> + struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
> + int ret;
> +
> + switch (cpu_dai->id) {
> + case MI2S_PRIMARY:
> + if (++data->pri_mi2s_clk_count == 1) {
> + snd_soc_dai_set_sysclk(cpu_dai,
> + LPASS_MCLK0,
> + DEFAULT_MCLK_RATE,
> + SNDRV_PCM_STREAM_PLAYBACK);
> + }
> + snd_soc_dai_set_fmt(codec_dai, primary_dai_fmt);
My comment on the previous thread may mislead. My original intent:
move the DAIFMT setting to DAI link->dai_fmt in sc7180_parse_of( ).
If you need to keep it as is: inline the SND_SOC_DAIFMT_* into
snd_soc_dai_set_fmt( ) (i.e. eliminate primary_dai_fmt).
> +static int sc7180_parse_of(struct snd_soc_card *card)
> +{
> + struct device_node *np;
> + struct device_node *codec = NULL;
> + struct device_node *platform = NULL;
The function doesn't use platform.
> + struct device_node *cpu = NULL;
> + struct device *dev = card->dev;
> + struct snd_soc_dai_link *link;
> + struct of_phandle_args args;
> + struct snd_soc_dai_link_component *dlc;
> + int ret, num_links;
> +
> + ret = snd_soc_of_parse_card_name(card, "model");
> + if (ret) {
> + dev_err(dev, "Error parsing card name: %d\n", ret);
> + return ret;
> + }
> +
> + /* DAPM routes */
> + if (of_property_read_bool(dev->of_node, "audio-routing")) {
> + ret = snd_soc_of_parse_audio_routing(card,
> +"audio-routing");
> + if (ret)
> + return ret;
> + }
> +
> + /* headset aux dev. */
> + sc7180_headset_dev.dlc.of_node = of_parse_phandle(
> + dev->of_node, "aux-dev", 0);
> + if (!sc7180_headset_dev.dlc.of_node) {
> + dev_err(dev,
> + "Property 'aux-dev' missing/invalid\n");
> + return -EINVAL;
> + }
> +
> + /* Populate links */
> + num_links = of_get_child_count(dev->of_node);
Eliminate num_links but use card->num_links directly.
> +
> + /* Allocate the DAI link array */
> + card->dai_link = devm_kcalloc(dev, num_links, sizeof(*link),
> + GFP_KERNEL);
> + if (!card->dai_link)
> + return -ENOMEM;
> +
> + card->num_links = num_links;
Ditto, eliminate it.
> + link = card->dai_link;
> +
Eliminate the blank line to make "link = card->dai_link" and the
following for-loop "a whole thing".
> + for_each_child_of_node(dev->of_node, np) {
> + dlc = devm_kzalloc(dev, 2 * sizeof(*dlc), GFP_KERNEL);
> + if (!dlc)
> + return -ENOMEM;
> +
> + link->cpus = [0];
> + link->platforms = [1];
> +
> + link->num_cpus = 1;
> + link->num_platforms = 1;
> +
> + ret = of_property_read_string(np, "link-name", >name);
> + if (ret) {
> + dev_err(card->dev,
> + "error getting codec dai_link name\n");
> + goto err;
> + }
> +
> + link->playback_only = of_property_read_bool(np,
> + "playback_only");
> + link->capture_only = of_property_read_bool(np,
> +
[PATCH v2][next] PCI: imx6: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva --- Changes in v2: - Update URL. Use proper URL to Linux v5.7 documentation. drivers/pci/controller/dwc/pci-imx6.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c index 8f08ae53f53e..6c78903b49be 100644 --- a/drivers/pci/controller/dwc/pci-imx6.c +++ b/drivers/pci/controller/dwc/pci-imx6.c @@ -439,7 +439,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie) regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0); break; - case IMX6QP:/* FALLTHROUGH */ + case IMX6QP: case IMX6Q: /* power up core phy and enable ref clock */ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, @@ -642,7 +642,7 @@ static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie) regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, IMX6SX_GPR12_PCIE_RX_EQ_MASK, IMX6SX_GPR12_PCIE_RX_EQ_2); - /* FALLTHROUGH */ + fallthrough; default: regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, IMX6Q_GPR12_PCIE_CTL_2, 0 << 10); @@ -1107,7 +1107,7 @@ static int imx6_pcie_probe(struct platform_device *pdev) dev_err(dev, "pcie_aux clock source missing or invalid\n"); return PTR_ERR(imx6_pcie->pcie_aux); } - /* fall through */ + fallthrough; case IMX7D: if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR) imx6_pcie->controller_id = 1; -- 2.27.0
Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
On 7/22/20 11:03 AM, Jun Miao wrote: On 7/22/20 10:40 AM, Lu Baolu wrote: Hi Jun, On 7/22/20 10:26 AM, Miao, Jun wrote: Kernel panic - not syncing: DMAR hardware is malfunctioning CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019 Call Trace: dump_stack+0x59/0x75 panic+0xff/0x2d4 iommu_disable_translation+0x88/0x90 iommu_suspend+0x12f/0x1b0 syscore_suspend+0x6c/0x220 suspend_devices_and_enter+0x313/0x840 pm_suspend+0x30d/0x390 state_store+0x82/0xf0 kobj_attr_store+0x12/0x20 sysfs_kf_write+0x3c/0x50 kernfs_fop_write+0x11d/0x190 __vfs_write+0x1b/0x40 vfs_write+0xc6/0x1d0 ksys_write+0x5e/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x4d/0x150 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f97b8080113 Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18 RSP: 002b:7ffcfa6f48b8 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 0004 RCX: 7f97b8080113 RDX: 0004 RSI: 55e7db03b700 RDI: 0004 RBP: 55e7db03b700 R08: 55e7db03b700 R09: 0004 R10: 0004 R11: 0246 R12: 0004 R13: 55e7db039380 R14: 0004 R15: 7f97b814d700 Kernel Offset: 0x38a0 from 0x8100 (relocation range: 0x8000-0xbfff) ---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]--- Do you mean that system hangs in iommu_disable_translation() without this fix. Yes ,From the call trace and i also read the DMARD_GCMD_RGS is wrong without this patch. Okay! Thanks a lot for confirming this. Best regards, baolu [S3 successfully with the patch] And, this failure disappeared after you applied this fix? Best regards, baolu
Re: [PATCH v2] drivers/net/wan/x25_asy: Fix to make it work
On Tue, Jul 21, 2020 at 6:30 PM -0700 David Miller wrote: > > Applied, thank you. Thank you so much, David!
[PATCH v2 0/2] Remove MT6779 UART3 clock support
remove the redundant clk interface of uart. CLK_INFRA_UART3 is a dummy clk interface, it has no effect on the operation of the read/write instruction. Change since v2: Commit "dt-bindings: clock: remove UART3 clock support" -- remove Fixes tag Commit "clk: mediatek: remove UART3 clock support" -- remove Fixes tag Hanks Chen (2): dt-bindings: clock: remove UART3 clock support clk: mediatek: remove UART3 clock support drivers/clk/mediatek/clk-mt6779.c | 2 -- include/dt-bindings/clock/mt6779-clk.h | 1 - 2 files changed, 3 deletions(-) -- 2.18.0
Re: [PATCH 1/2] dt-bindings: clock: remove UART3 clock support
On Wed, 2020-07-22 at 00:10 +0200, Matthias Brugger wrote:
>
> On 21/07/2020 07:40, Hanks Chen wrote:
> > remove the redundant clk interface of uart.
> >
> > Fixes: 710774e04861 ("clk: mediatek: Add MT6779 clock support")
>
> These are cosmetic changes. They don't fix any bug, so we won't need a Fixes
> tag
> here. Neither on 2/2.
>
> Regards,
> Matthias
>
Got it, I'll remove it in next version.
Thanks!
Hanks
> > Signed-off-by: Hanks Chen
> > ---
> > include/dt-bindings/clock/mt6779-clk.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/include/dt-bindings/clock/mt6779-clk.h
> > b/include/dt-bindings/clock/mt6779-clk.h
> > index b083139afbd2..2b5f2354d7eb 100644
> > --- a/include/dt-bindings/clock/mt6779-clk.h
> > +++ b/include/dt-bindings/clock/mt6779-clk.h
> > @@ -229,7 +229,6 @@
> > #define CLK_INFRA_UART0 21
> > #define CLK_INFRA_UART1 22
> > #define CLK_INFRA_UART2 23
> > -#define CLK_INFRA_UART324
> > #define CLK_INFRA_GCE_26M 25
> > #define CLK_INFRA_CQ_DMA_FPC 26
> > #define CLK_INFRA_BTIF27
> >
[PATCH v2 2/2] clk: mediatek: remove UART3 clock support
CLK_INFRA_UART3 is a dummy clk interface,
it has no effect on the operation of the read/write instruction.
Signed-off-by: Hanks Chen
---
drivers/clk/mediatek/clk-mt6779.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt6779.c
b/drivers/clk/mediatek/clk-mt6779.c
index 9766cccf5844..75f2235486be 100644
--- a/drivers/clk/mediatek/clk-mt6779.c
+++ b/drivers/clk/mediatek/clk-mt6779.c
@@ -923,8 +923,6 @@ static const struct mtk_gate infra_clks[] = {
"uart_sel", 23),
GATE_INFRA0(CLK_INFRA_UART2, "infra_uart2",
"uart_sel", 24),
- GATE_INFRA0(CLK_INFRA_UART3, "infra_uart3",
- "uart_sel", 25),
GATE_INFRA0(CLK_INFRA_GCE_26M, "infra_gce_26m",
"axi_sel", 27),
GATE_INFRA0(CLK_INFRA_CQ_DMA_FPC, "infra_cqdma_fpc",
--
2.18.0
[PATCH v2 1/2] dt-bindings: clock: remove UART3 clock support
remove the redundant clk interface of uart. Signed-off-by: Hanks Chen --- include/dt-bindings/clock/mt6779-clk.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/dt-bindings/clock/mt6779-clk.h b/include/dt-bindings/clock/mt6779-clk.h index b083139afbd2..2b5f2354d7eb 100644 --- a/include/dt-bindings/clock/mt6779-clk.h +++ b/include/dt-bindings/clock/mt6779-clk.h @@ -229,7 +229,6 @@ #define CLK_INFRA_UART021 #define CLK_INFRA_UART122 #define CLK_INFRA_UART223 -#define CLK_INFRA_UART324 #define CLK_INFRA_GCE_26M 25 #define CLK_INFRA_CQ_DMA_FPC 26 #define CLK_INFRA_BTIF 27 -- 2.18.0
Re: [PATCH 02/10] block: virtio-blk: check logical block size
Christoph, > Hmm, I wonder if we should simply add the check and warning to > blk_queue_logical_block_size and add an error in that case. Then > drivers only have to check the error return, which might add a lot > less boiler plate code. Yep, I agree. -- Martin K. Petersen Oracle Linux Engineering
Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
On 7/22/20 10:40 AM, Lu Baolu wrote: Hi Jun, On 7/22/20 10:26 AM, Miao, Jun wrote: Kernel panic - not syncing: DMAR hardware is malfunctioning CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019 Call Trace: dump_stack+0x59/0x75 panic+0xff/0x2d4 iommu_disable_translation+0x88/0x90 iommu_suspend+0x12f/0x1b0 syscore_suspend+0x6c/0x220 suspend_devices_and_enter+0x313/0x840 pm_suspend+0x30d/0x390 state_store+0x82/0xf0 kobj_attr_store+0x12/0x20 sysfs_kf_write+0x3c/0x50 kernfs_fop_write+0x11d/0x190 __vfs_write+0x1b/0x40 vfs_write+0xc6/0x1d0 ksys_write+0x5e/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x4d/0x150 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f97b8080113 Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18 RSP: 002b:7ffcfa6f48b8 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 0004 RCX: 7f97b8080113 RDX: 0004 RSI: 55e7db03b700 RDI: 0004 RBP: 55e7db03b700 R08: 55e7db03b700 R09: 0004 R10: 0004 R11: 0246 R12: 0004 R13: 55e7db039380 R14: 0004 R15: 7f97b814d700 Kernel Offset: 0x38a0 from 0x8100 (relocation range: 0x8000-0xbfff) ---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]--- Do you mean that system hangs in iommu_disable_translation() without this fix. Yes ,From the call trace and i also read the DMARD_GCMD_RGS is wrong without this patch. [S3 successfully with the patch] And, this failure disappeared after you applied this fix? Best regards, baolu
Re: [PATCH] x86/xen/time: set the X86_FEATURE_TSC_KNOWN_FREQ flag in xen_tsc_khz()
On 7/21/20 12:12 PM, Hayato Ohhashi wrote: > If the TSC frequency is known from the pvclock page, > the TSC frequency does not need to be recalibrated. > We can avoid recalibration by setting X86_FEATURE_TSC_KNOWN_FREQ. > > Signed-off-by: Hayato Ohhashi Reviewed-by: Boris Ostrovsky
Re: [PATCH] x86/PCI: Use MMCONFIG by default for KVM guests
On Wed, Jul 22, 2020 at 02:15:13AM +0200, Julia Suvorova wrote:
> @@ -264,6 +265,10 @@ void __init pci_direct_init(int type)
> {
> if (type == 0)
> return;
> +
> + if (raw_pci_ext_ops && kvm_para_available())
> + return;
This is a bit of a subtle way of saying "If mmconfig exists, don't use
the cf8 mechanism". There's probably a better way of doing this, but
the x86 pci init sequence is already byzantine and I don't understand it
well enough to offer you an alternative.
Re: [PATCH 2/2] riscv: Simplify the checking for SR_PP
On Mon, 13 Jul 2020 01:32:16 PDT (-0700), greentime...@sifive.com wrote: This patch simplifies the checking for SR_MPP and SR_SPP. It uses SR_PP in the code flow for both m-mode and s-mode then we can remove the ifdef here. Signed-off-by: Greentime Hu --- arch/riscv/kernel/entry.S | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 000984695cd6..597beae0d238 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -210,13 +210,8 @@ ret_from_syscall_rejected: ret_from_exception: REG_L s0, PT_STATUS(sp) csrc CSR_STATUS, SR_IE -#ifdef CONFIG_RISCV_M_MODE - /* the MPP value is too large to be used as an immediate arg for addi */ - li t0, SR_MPP + li t0, SR_PP and s0, s0, t0 -#else - andi s0, s0, SR_SPP -#endif bnez s0, resume_kernel resume_userspace: This one is actually on a fairly fast path, so I can buy it's worth saving the cycle.
Re: [PATCH 1/2] riscv: Fix building error in entry.S when CONFIG_RISCV_M_MODE is enabled
On Mon, 13 Jul 2020 01:32:15 PDT (-0700), greentime...@sifive.com wrote: arch/riscv/kernel/entry.S: Assembler messages: arch/riscv/kernel/entry.S:106: Error: illegal operands `andi a0,s1,0x1800' This building error is because of the SR_MPP value is too large to be used as an immediate value for andi. To fix this issue I use li to set the immediate value to t0, then it can use t0 and s1 to do and operation. Reported-by: kernel test robot Signed-off-by: Greentime Hu --- arch/riscv/kernel/entry.S | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 6ed579fc1073..000984695cd6 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -99,7 +99,8 @@ _save_context: #ifdef CONFIG_CONTEXT_TRACKING /* If previous state is in user mode, call context_tracking_user_exit. */ - andi a0, s1, SR_SPP + li t0, SR_PP + and a0, s1, t0 bnez a0, skip_context_tracking call context_tracking_user_exit Looks like this one already got fixed, I guess I saw the build report go by and fixed it? I don't remember if I actually pulled this in, but I ended up with a 3-register andi so I guess I didn't do it that well. I'm not sure why my build test aren't catching the M-mode stuff, as the defconfigs are in the list. I'll go take a look...
Re: [PATCH 3/3] soc: mediatek: pwrap: add pwrap driver for MT6873/8192 SoCs
Hi, On Wed, 2020-07-22 at 00:51 +0200, Matthias Brugger wrote: > > On 14/07/2020 11:53, Hsin-Hsiung Wang wrote: > > MT6873/8192 are highly integrated SoCs and use PMIC_MT6359 for > > power management. This patch adds pwrap master driver to > > access PMIC_MT6359. > > > > Signed-off-by: Hsin-Hsiung Wang > > --- > > drivers/soc/mediatek/mtk-pmic-wrap.c | 98 > > > > 1 file changed, 87 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c > > b/drivers/soc/mediatek/mtk-pmic-wrap.c > > index c897205..6e7f796f 100644 > > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c > > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c > > @@ -24,11 +24,13 @@ > > #define PWRAP_MT8135_BRIDGE_WDT_SRC_EN0x54 > > > > /* macro for wrapper status */ > > +#define PWRAP_GET_SWINF_2_FSM(x) (((x) >> 1) & 0x0007) > > #define PWRAP_GET_WACS_RDATA(x) (((x) >> 0) & 0x) > > #define PWRAP_GET_WACS_FSM(x) (((x) >> 16) & 0x0007) > > #define PWRAP_GET_WACS_REQ(x) (((x) >> 19) & 0x0001) > > #define PWRAP_STATE_SYNC_IDLE0BIT(20) > > #define PWRAP_STATE_INIT_DONE0BIT(21) > > +#define PWRAP_STATE_INIT_DONE1 BIT(15) > > > > /* macro for WACS FSM */ > > #define PWRAP_WACS_FSM_IDLE 0x00 > > @@ -74,6 +76,7 @@ > > #define PWRAP_CAP_DCM BIT(2) > > #define PWRAP_CAP_INT1_EN BIT(3) > > #define PWRAP_CAP_WDT_SRC1BIT(4) > > +#define PWRAP_CAP_ARB BIT(5) > > This commit should be two patches (at least). One adding PWRAP_CAP_ARB and > then > another one adding MT6873 support. > > Regards, > Matthias > Thanks for your comment, I will update it in next patch.
Re: [PATCH] SPARC: backoff.h: delete a duplicated word
On 7/21/20 6:22 PM, David Miller wrote: >> @David: >> In arch/sparc/include/asm/cpu_type.h, line 12, >> is that duplicated "ploos" correct? >> sun4u = 0x03, /* V8 ploos ploos */ > > Yes, it's a funny way of saying "++" :-) I see. Thanks for the explanation. -- ~Randy
RE: [PATCH 1/3] Input: elan_i2c - Do no operation for elan_smbus_set_mode function
Dear Dmitry,
Should this be moved into core? Or we only plan on using this on SMbus?
=> using on smbus.
What will happen after firmware update? How can userspace verify that the
firmware update completed successfully if we always return static data?
=> FW modified the architecture that reading register cmd in P/S2 and then
updating flow in SMbus.
As a result, it would not get success result while updating firmware in
SMbus driver.
Elan will use the tool to update firmware.
Can the device still be accessed via PS/2 while also using SMbus?
=> Yes, the device could still be accessed via PS/2 while also using SMbus.
However, we cannot use P/S2 driver and SMbus driver to read register
simultaneously because of the limitation of driver (elantench (ps2) driver
would be unmounted before loading into SMbus driver). So we use tool to
update firmware in SMbus interface.
Best regards,
Dave
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, July 22, 2020 12:13 AM
To: Dave Wang
Cc: linux-in...@vger.kernel.org; Linux-kernel@vger.kernel.org;
phoe...@emc.com.tw; josh.c...@emc.com.tw; jingle...@emc.com.tw;
kai.heng.f...@canonical.com
Subject: Re: [PATCH 1/3] Input: elan_i2c - Do no operation for
elan_smbus_set_mode function
Hi Dave,
On Mon, Dec 09, 2019 at 06:11:07AM -0500, Dave Wang wrote:
> Some touchpads might get error while triggerring the set_mode command
> in SMBus interface. Do no operation for elan_smbus_set_mode function.
Are there devices that do not trigger errors? How do we put SMbus devices
into low power mode?
>
> Signed-off-by: Dave Wang
> ---
> drivers/input/mouse/elan_i2c_smbus.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/input/mouse/elan_i2c_smbus.c
> b/drivers/input/mouse/elan_i2c_smbus.c
> index 8c3185d54c73..bcb9ec4a7a6b 100644
> --- a/drivers/input/mouse/elan_i2c_smbus.c
> +++ b/drivers/input/mouse/elan_i2c_smbus.c
> @@ -84,10 +84,7 @@ static int elan_smbus_initialize(struct i2c_client
> *client)
>
> static int elan_smbus_set_mode(struct i2c_client *client, u8 mode) {
> - u8 cmd[4] = { 0x00, 0x07, 0x00, mode };
> -
> - return i2c_smbus_write_block_data(client, ETP_SMBUS_IAP_CMD,
> - sizeof(cmd), cmd);
> + return 0; /* A no-op */
> }
>
> static int elan_smbus_sleep_control(struct i2c_client *client, bool
> sleep)
> --
> 2.17.1
>
Thanks.
--
Dmitry
[PATCH 1/1] iommu/vt-d: Rename intel-pasid.h to pasid.h
As Intel VT-d files have been move to its own subdirectory, the prefix
makes no sense.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/debugfs.c | 2 +-
drivers/iommu/intel/iommu.c| 2 +-
drivers/iommu/intel/pasid.c| 2 +-
drivers/iommu/intel/{intel-pasid.h => pasid.h} | 2 +-
drivers/iommu/intel/svm.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
rename drivers/iommu/intel/{intel-pasid.h => pasid.h} (98%)
diff --git a/drivers/iommu/intel/debugfs.c b/drivers/iommu/intel/debugfs.c
index cf1ebb98e418..efea7f02abd9 100644
--- a/drivers/iommu/intel/debugfs.c
+++ b/drivers/iommu/intel/debugfs.c
@@ -15,7 +15,7 @@
#include
-#include "intel-pasid.h"
+#include "pasid.h"
struct tbl_walk {
u16 bus;
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 5228f2c18a90..60de9daea62e 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -48,7 +48,7 @@
#include
#include "../irq_remapping.h"
-#include "intel-pasid.h"
+#include "pasid.h"
#define ROOT_SIZE VTD_PAGE_SIZE
#define CONTEXT_SIZE VTD_PAGE_SIZE
diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
index fa0154cce537..e6faedf42fd4 100644
--- a/drivers/iommu/intel/pasid.c
+++ b/drivers/iommu/intel/pasid.c
@@ -19,7 +19,7 @@
#include
#include
-#include "intel-pasid.h"
+#include "pasid.h"
/*
* Intel IOMMU system wide PASID name space:
diff --git a/drivers/iommu/intel/intel-pasid.h b/drivers/iommu/intel/pasid.h
similarity index 98%
rename from drivers/iommu/intel/intel-pasid.h
rename to drivers/iommu/intel/pasid.h
index c5318d40e0fa..c9850766c3a9 100644
--- a/drivers/iommu/intel/intel-pasid.h
+++ b/drivers/iommu/intel/pasid.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * intel-pasid.h - PASID idr, table and entry header
+ * pasid.h - PASID idr, table and entry header
*
* Copyright (C) 2018 Intel Corporation
*
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 85ce8daa3177..442623ac4b47 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -20,7 +20,7 @@
#include
#include
-#include "intel-pasid.h"
+#include "pasid.h"
static irqreturn_t prq_event_thread(int irq, void *d);
static void intel_svm_drain_prq(struct device *dev, int pasid);
--
2.17.1
Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
Hi Jun, On 7/22/20 10:26 AM, Miao, Jun wrote: Kernel panic - not syncing: DMAR hardware is malfunctioning CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019 Call Trace: dump_stack+0x59/0x75 panic+0xff/0x2d4 iommu_disable_translation+0x88/0x90 iommu_suspend+0x12f/0x1b0 syscore_suspend+0x6c/0x220 suspend_devices_and_enter+0x313/0x840 pm_suspend+0x30d/0x390 state_store+0x82/0xf0 kobj_attr_store+0x12/0x20 sysfs_kf_write+0x3c/0x50 kernfs_fop_write+0x11d/0x190 __vfs_write+0x1b/0x40 vfs_write+0xc6/0x1d0 ksys_write+0x5e/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x4d/0x150 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f97b8080113 Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18 RSP: 002b:7ffcfa6f48b8 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 0004 RCX: 7f97b8080113 RDX: 0004 RSI: 55e7db03b700 RDI: 0004 RBP: 55e7db03b700 R08: 55e7db03b700 R09: 0004 R10: 0004 R11: 0246 R12: 0004 R13: 55e7db039380 R14: 0004 R15: 7f97b814d700 Kernel Offset: 0x38a0 from 0x8100 (relocation range: 0x8000-0xbfff) ---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]--- Do you mean that system hangs in iommu_disable_translation() without this fix. [S3 successfully with the patch] And, this failure disappeared after you applied this fix? Best regards, baolu
Re: [PATCH v2 7/9] usb: cdns3: core: removed 'goto not_otg'
On 20-07-13 12:05:52, Pawel Laszczak wrote:
> Patch removes 'goto not_otg' instruction from
> cdns3_hw_role_state_machine function.
>
> Signed-off-by: Pawel Laszczak
> ---
> drivers/usb/cdns3/core.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> index c498b585eb13..8e3996f211a8 100644
> --- a/drivers/usb/cdns3/core.c
> +++ b/drivers/usb/cdns3/core.c
> @@ -191,11 +191,17 @@ static int cdns3_core_init_role(struct cdns3 *cdns)
> */
> static enum usb_role cdns3_hw_role_state_machine(struct cdns3 *cdns)
> {
> - enum usb_role role;
> + enum usb_role role = USB_ROLE_NONE;
> int id, vbus;
>
> - if (cdns->dr_mode != USB_DR_MODE_OTG)
> - goto not_otg;
> + if (cdns->dr_mode != USB_DR_MODE_OTG) {
> + if (cdns3_is_host(cdns))
> + role = USB_ROLE_HOST;
> + if (cdns3_is_device(cdns))
> + role = USB_ROLE_DEVICE;
> +
> + return role;
> + }
Would you please improve it a bit like below:
if (cdns->dr_mode != USB_DR_MODE_OTG) {
if (cdns3_is_host(cdns))
role = USB_ROLE_HOST;
else if (cdns3_is_device(cdns))
role = USB_ROLE_DEVICE;
else
role = USB_ROLE_NONE;
return role;
}
Peter
>
> id = cdns3_get_id(cdns);
> vbus = cdns3_get_vbus(cdns);
> @@ -232,14 +238,6 @@ static enum usb_role cdns3_hw_role_state_machine(struct
> cdns3 *cdns)
> dev_dbg(cdns->dev, "role %d -> %d\n", cdns->role, role);
>
> return role;
> -
> -not_otg:
> - if (cdns3_is_host(cdns))
> - role = USB_ROLE_HOST;
> - if (cdns3_is_device(cdns))
> - role = USB_ROLE_DEVICE;
> -
> - return role;
> }
>
> static int cdns3_idle_role_start(struct cdns3 *cdns)
> --
> 2.17.1
>
--
Thanks,
Peter Chen
[PATCH v1] clk: Export __clk_lookup()
Export __clk_lookup() to support user built as module. ERROR: drivers/clk/rockchip/clk.ko: In function `rockchip_clk_protect_critical': drivers/clk/rockchip/clk.c:741: undefined reference to `__clk_lookup' Signed-off-by: Elaine Zhang --- drivers/clk/clk.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 3f588ed06ce3..600284fbb257 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -618,6 +618,7 @@ struct clk *__clk_lookup(const char *name) return !core ? NULL : core->hw->clk; } +EXPORT_SYMBOL_GPL(__clk_lookup); static void clk_core_get_boundaries(struct clk_core *core, unsigned long *min_rate, -- 2.17.1
Re: [PATCH] sh: add missing EXPORT_SYMBOL() for __delay
On Thu, Dec 12, 2019 at 11:38:43AM +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> __delay() is used from kernel module.
> We need EXPORT_SYMBOL(), otherwise we will get compile error.
>
> ERROR: "__delay" [drivers/net/phy/mdio-cavium.ko] undefined!
>
> Signed-off-by: Kuninori Morimoto
I must admit that this patch completely baffles me. __delay was
already exported, only elsewhere in the file. With this patch
in place, it is exported twice, and all sh builds in -next fail
with
In file included from include/linux/linkage.h:7,
from arch/sh/include/asm/bug.h:5,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from include/asm-generic/current.h:5,
from ./arch/sh/include/generated/asm/current.h:1,
from include/linux/sched.h:12,
from arch/sh/lib/delay.c:8:
include/linux/export.h:67:36: error: redefinition of '__ksymtab___delay'
Guenter
> ---
> arch/sh/lib/delay.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/sh/lib/delay.c b/arch/sh/lib/delay.c
> index dad8e6a..540e670 100644
> --- a/arch/sh/lib/delay.c
> +++ b/arch/sh/lib/delay.c
> @@ -29,6 +29,7 @@ void __delay(unsigned long loops)
> : "0" (loops)
> : "t");
> }
> +EXPORT_SYMBOL(__delay);
>
> inline void __const_udelay(unsigned long xloops)
> {
Re: [PATCH RFC v2 2/3] io_uring: add IOURING_REGISTER_RESTRICTIONS opcode
On Wed, 22 Jul 2020 at 03:11, Jens Axboe wrote:
>
> On 7/21/20 4:40 AM, Stefano Garzarella wrote:
> > On Thu, Jul 16, 2020 at 03:26:51PM -0600, Jens Axboe wrote:
> >> On 7/16/20 6:48 AM, Stefano Garzarella wrote:
> >>> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
> >>> index efc50bd0af34..0774d5382c65 100644
> >>> --- a/include/uapi/linux/io_uring.h
> >>> +++ b/include/uapi/linux/io_uring.h
> >>> @@ -265,6 +265,7 @@ enum {
> >>> IORING_REGISTER_PROBE,
> >>> IORING_REGISTER_PERSONALITY,
> >>> IORING_UNREGISTER_PERSONALITY,
> >>> + IORING_REGISTER_RESTRICTIONS,
> >>>
> >>> /* this goes last */
> >>> IORING_REGISTER_LAST
> >>> @@ -293,4 +294,30 @@ struct io_uring_probe {
> >>> struct io_uring_probe_op ops[0];
> >>> };
> >>>
> >>> +struct io_uring_restriction {
> >>> + __u16 opcode;
> >>> + union {
> >>> + __u8 register_op; /* IORING_RESTRICTION_REGISTER_OP */
> >>> + __u8 sqe_op; /* IORING_RESTRICTION_SQE_OP */
> >>> + };
> >>> + __u8 resv;
> >>> + __u32 resv2[3];
> >>> +};
> >>> +
> >>> +/*
> >>> + * io_uring_restriction->opcode values
> >>> + */
> >>> +enum {
> >>> + /* Allow an io_uring_register(2) opcode */
> >>> + IORING_RESTRICTION_REGISTER_OP,
> >>> +
> >>> + /* Allow an sqe opcode */
> >>> + IORING_RESTRICTION_SQE_OP,
> >>> +
> >>> + /* Only allow fixed files */
> >>> + IORING_RESTRICTION_FIXED_FILES_ONLY,
> >>> +
> >>> + IORING_RESTRICTION_LAST
> >>> +};
> >>> +
> >>
> >> Not sure I totally love this API. Maybe it'd be cleaner to have separate
> >> ops for this, instead of muxing it like this. One for registering op
> >> code restrictions, and one for disallowing other parts (like fixed
> >> files, etc).
> >>
> >> I think that would look a lot cleaner than the above.
> >>
> >
> > Talking with Stefan, an alternative, maybe more near to your suggestion,
> > would be to remove the 'struct io_uring_restriction' and add the
> > following register ops:
> >
> > /* Allow an sqe opcode */
> > IORING_REGISTER_RESTRICTION_SQE_OP
> >
> > /* Allow an io_uring_register(2) opcode */
> > IORING_REGISTER_RESTRICTION_REG_OP
> >
> > /* Register IORING_RESTRICTION_* */
> > IORING_REGISTER_RESTRICTION_OP
> >
> >
> > enum {
> > /* Only allow fixed files */
> > IORING_RESTRICTION_FIXED_FILES_ONLY,
> >
> > IORING_RESTRICTION_LAST
> > }
> >
> >
> > We can also enable restriction only when the rings started, to avoid to
> > register IORING_REGISTER_ENABLE_RINGS opcode. Once rings are started,
> > the restrictions cannot be changed or disabled.
>
> My concerns are largely:
>
> 1) An API that's straight forward to use
> 2) Something that'll work with future changes
>
> The "allow these opcodes" is straightforward, and ditto for the register
> opcodes. The fixed file I guess is the odd one out. So if we need to
> disallow things in the future, we'll need to add a new restriction
> sub-op. Should this perhaps be "these flags must be set", and that could
> easily be augmented with "these flags must not be set"?
>
> --
> Jens Axboe
>
This is starting to sound a lot like seccomp filtering.
Perhaps we should go straight to adding a BPF hook that fires when
reading off the submission queue?
[PATCH -next] scsi: lpfc: Add dependency on CPU_FREQ
Since commit 317aeb83c92b ("scsi: lpfc: Add blk_io_poll support for
latency improvment"), the lpfc driver depends on CPUFREQ. Without it,
builds fail with
drivers/scsi/lpfc/lpfc_sli.c: In function 'lpfc_init_idle_stat_hb':
drivers/scsi/lpfc/lpfc_sli.c:7329:26: error:
implicit declaration of function 'get_cpu_idle_time'
Add the missing dependency.
Fixes: 317aeb83c92b ("scsi: lpfc: Add blk_io_poll support for latency
improvment")
Cc: Dick Kennedy
Cc: James Smart
Signed-off-by: Guenter Roeck
---
drivers/scsi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 571473a58f98..701b61ec76ee 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1154,6 +1154,7 @@ source "drivers/scsi/qedf/Kconfig"
config SCSI_LPFC
tristate "Emulex LightPulse Fibre Channel Support"
depends on PCI && SCSI
+ depends on CPU_FREQ
depends on SCSI_FC_ATTRS
depends on NVME_TARGET_FC || NVME_TARGET_FC=n
depends on NVME_FC || NVME_FC=n
--
2.17.1
RE: [PATCH 1/3] Input: elan_i2c - Do no operation for elan_smbus_set_mode function
Dear Dmitry,
Are there devices that do not trigger errors?
=> Yes, there exist devices that would act normally. However, our team
cannot organize the rule to recognize which devices could trigger this
command without error.
What I sure about is that some devices would get TP no function while
triggering this command.
Besides, ABS mode had been set in P/S2 protocol, so there is no need to set
ABS mode again in SMBUS driver.
How do we put SMbus devices into low power mode?
=> As far as I am concerned, core.c only set the mode into ABS mode or
ENABLE_CALIBRATE mode after updating firmware.
I don't know what or when to set SMbus devices into low power mode.
Best regards,
Dave
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, July 22, 2020 12:13 AM
To: Dave Wang
Cc: linux-in...@vger.kernel.org; Linux-kernel@vger.kernel.org;
phoe...@emc.com.tw; josh.c...@emc.com.tw; jingle...@emc.com.tw;
kai.heng.f...@canonical.com
Subject: Re: [PATCH 1/3] Input: elan_i2c - Do no operation for
elan_smbus_set_mode function
Hi Dave,
On Mon, Dec 09, 2019 at 06:11:07AM -0500, Dave Wang wrote:
> Some touchpads might get error while triggerring the set_mode command
> in SMBus interface. Do no operation for elan_smbus_set_mode function.
Are there devices that do not trigger errors? How do we put SMbus devices
into low power mode?
>
> Signed-off-by: Dave Wang
> ---
> drivers/input/mouse/elan_i2c_smbus.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/input/mouse/elan_i2c_smbus.c
> b/drivers/input/mouse/elan_i2c_smbus.c
> index 8c3185d54c73..bcb9ec4a7a6b 100644
> --- a/drivers/input/mouse/elan_i2c_smbus.c
> +++ b/drivers/input/mouse/elan_i2c_smbus.c
> @@ -84,10 +84,7 @@ static int elan_smbus_initialize(struct i2c_client
> *client)
>
> static int elan_smbus_set_mode(struct i2c_client *client, u8 mode) {
> - u8 cmd[4] = { 0x00, 0x07, 0x00, mode };
> -
> - return i2c_smbus_write_block_data(client, ETP_SMBUS_IAP_CMD,
> - sizeof(cmd), cmd);
> + return 0; /* A no-op */
> }
>
> static int elan_smbus_sleep_control(struct i2c_client *client, bool
> sleep)
> --
> 2.17.1
>
Thanks.
--
Dmitry
Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone
On Tue, 2020-07-21 at 16:48 -0700, Palmer Dabbelt wrote: > > Why ? Branch distance limits ? You can't use trampolines ? > > Nothing fundamental, it's just that we don't have a large code model in the C > compiler. As a result all the global symbols are resolved as 32-bit > PC-relative accesses. We could fix this with a fast large code model, but > then > the kernel would need to relax global symbol references in modules and we > don't > even do that for the simple code models we have now. FWIW, some of the > proposed large code models are essentially just split-PLT/GOT and therefor > don't require relaxation, but at that point we're essentially PIC until we > have more that 2GiB of kernel text -- and even then, we keep all the > performance issues. My memory might be out of date but I *think* we do it on powerpc without going to a large code model, but just having the in-kernel linker insert trampolines. Cheers, Ben.
[PATCH] PCI: Disallow ASPM on ASMedia ASM1083/1085 PCIe-PCI bridge
Recently ASPM handling was changed to no longer disable ASPM on all
PCIe to PCI bridges. Unfortunately these ASMedia PCIe to PCI bridge
devices don't seem to function properly with ASPM enabled, as they
cause the parent PCIe root port to cause repeated AER timeout errors.
In addition to flooding the kernel log, this also causes the machine
to wake up immediately after suspend is initiated.
Fixes: 66ff14e59e8a ("PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X
Bridges")
Cc: sta...@vger.kernel.org
Signed-off-by: Robert Hancock
---
drivers/pci/quirks.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 812bfc32ecb8..e5713114f2ab 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2330,6 +2330,19 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10f1,
quirk_disable_aspm_l0s);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10f4, quirk_disable_aspm_l0s);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1508, quirk_disable_aspm_l0s);
+static void quirk_disable_aspm_l0s_l1(struct pci_dev *dev)
+{
+ pci_info(dev, "Disabling ASPM L0s/L1\n");
+ pci_disable_link_state(dev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1);
+}
+
+/*
+ * ASM1083/1085 PCIe-PCI bridge devices cause AER timeout errors on the
+ * upstream PCIe root port when ASPM is enabled. At least L0s mode is affected,
+ * disable both L0s and L1 for now to be safe.
+ */
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ASMEDIA, 0x1080,
quirk_disable_aspm_l0s_l1);
+
/*
* Some Pericom PCIe-to-PCI bridges in reverse mode need the PCIe Retrain
* Link bit cleared after starting the link retrain process to allow this
--
2.26.2
Re: [PATCH v3] lib: Convert test_user_copy to KUnit test
On Tue, Jul 21, 2020 at 07:19:12PM -0300, Vitor Massaru Iha wrote: > When you talk about end-of-test summary, is it what is written in > dmesg and not the kunit-tool? Right, if I build this as a module and do "modprobe user_copy_kunit", what will show up in dmesg? -- Kees Cook
[PATCH net-next] net: qed: Remove unneeded cast from memory allocation
Remove casting the values returned by memory allocation function.
Coccinelle emits WARNING: casting value returned by memory allocation
unction to (struct roce_destroy_qp_req_output_params *) is useless.
This issue was detected by using the Coccinelle software.
Signed-off-by: Wang Hai
---
drivers/net/ethernet/qlogic/qed/qed_roce.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_roce.c
b/drivers/net/ethernet/qlogic/qed/qed_roce.c
index a1423ec0edf7..f16a157bb95a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_roce.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_roce.c
@@ -757,8 +757,7 @@ static int qed_roce_sp_destroy_qp_requester(struct qed_hwfn
*p_hwfn,
if (!qp->req_offloaded)
return 0;
- p_ramrod_res = (struct roce_destroy_qp_req_output_params *)
- dma_alloc_coherent(_hwfn->cdev->pdev->dev,
+ p_ramrod_res = dma_alloc_coherent(_hwfn->cdev->pdev->dev,
sizeof(*p_ramrod_res),
_res_phys, GFP_KERNEL);
if (!p_ramrod_res) {
--
2.17.1
