Re: [PATCH] x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area.
On Mon, Sep 16, 2019 at 12:00:58PM +0300, Kirill A. Shutemov wrote: > On Fri, Sep 13, 2019 at 10:14:15AM -0500, Steve Wahl wrote: > > On Thu, Sep 12, 2019 at 01:19:17PM +0300, Kirill A. Shutemov wrote: > > > On Wed, Sep 11, 2019 at 03:08:35PM -0500, Steve Wahl wrote: > > > > Thank you for your time looking into this with me! > > > > > > With all this explanation the original patch looks sane to me. > > > > > > But I would like to see more information from this thread in the commit > > > message and some comments in the code on why it's crucial not to map more > > > than needed. > > > > I am working on this. > > > > > I think we also need to make it clear that this is workaround for a broken > > > hardware: speculative execution must not trigger a halt. > > > > I think the word broken is a bit loaded here. According to the UEFI > > spec (version 2.8, page 167), "Regions that are backed by the physical > > hardware, but are not supposed to be accessed by the OS, must be > > returned as EfiReservedMemoryType." Our interpretation is that > > includes speculative accesses. > > +Dave. > > I don't think it is. Speculative access is done by hardware, not OS. But the OS controls speculative access to physical addresses by their presence or absence in the page tables. Speculation is done with calculations based on virtual addresses, without a valid translation to physical addresses it doesn't progress to an externally visible action. > BTW, isn't it a BIOS issue? > > I believe it should have a way to hide a range of physical address space > from OS or force a caching mode on to exclude it from speculative > execution. Like setup MTRRs or something. This is their intent in marking it as reserved in the memory tables. They have explored many other avenues (I've even suggested a couple since pinning down this problem) and for each one there is a reason it doesn't work. > > I'd lean more toward "tightening of adherence to the spec required by > > some particular hardware." Does that work for you? > > Not really, no. I still believe it's issue of the platform, not OS. My current wording for a comment to go above the code is: /* * Only the region occupied by the kernel has so far been checked against * the table of usable memory regions provided by the firmware, so * invalidate pages outside that region. A page table entry that maps to * a reserved area of memory would allow processor speculation into that * area, and on some hardware (particularly the UV platform) speculation * into reserved areas can cause a system halt. */ How close does that come to working for you? (I'm going to dive specifically into the phrase "region occupied by the kernel" in a reply to Dave in another message; I understand that phrase may need work. I'm more asking about the remainder of it here.) --> Steve > -- > Kirill A. Shutemov -- Steve Wahl, Hewlett Packard Enterprise
Re: Linux 5.3-rc8
On Sun, Sep 15, 2019 at 11:13 PM Willy Tarreau wrote: > > > > > So three out of four flag combinations end up being mostly "don't > > use", and the fourth one isn't what you'd normally want (which is just > > plain /dev/urandom semantics). > > I'm seeing it from a different angle. I now understand better why > getrandom() absolutely wants to have an initialized pool, it's to > encourage private key producers to use a secure, infinite source of > randomness. Right. There is absolutely no question that that is a useful thing to have. And that's what GRND_RANDOM _should_ have meant. But didn't. So the semantics that getrandom() should have had are: getrandom(0) - just give me reasonable random numbers for any of a million non-strict-long-term-security use (ie the old urandom) - the nonblocking flag makes no sense here and would be a no-op getrandom(GRND_RANDOM) - get me actual _secure_ random numbers with blocking until entropy pool fills (but not the completely invalid entropy decrease accounting) - the nonblocking flag is useful for bootup and for "I will actually try to generate entropy". and both of those are very very sensible actions. That would actually have _fixed_ the problems we had with /dev/[u]random, both from a performance standpoint and for a filesystem access standpoint. But that is sadly not what we have right now. And I suspect we can't fix it, since people have grown to depend on the old behavior, and already know to avoid GRND_RANDOM because it's useless with old kernels even if we fixed it with new ones. Does anybody really seriously debate the above? Ted? Are you seriously trying to claim that the existing GRND_RANDOM has any sensible use? Are you seriously trying to claim that the fact that we don't have a sane urandom source is a "feature"? Linus
[PATCH v5 7/8] clk: Add common clock driver for BM1880 SoC
Add common clock driver for Bitmain BM1880 SoC. The clock controller on
BM1880 has supplies clocks to all peripherals in the form of gate clocks
and composite clocks (fixed factor + gate).
Signed-off-by: Manivannan Sadhasivam
---
drivers/clk/Kconfig | 7 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-bm1880.c | 966 +++
3 files changed, 974 insertions(+)
create mode 100644 drivers/clk/clk-bm1880.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 801fa1cd0321..e70c64e43ff9 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -139,6 +139,13 @@ config COMMON_CLK_SI570
This driver supports Silicon Labs 570/571/598/599 programmable
clock generators.
+config COMMON_CLK_BM1880
+ bool "Clock driver for Bitmain BM1880 SoC"
+ depends on ARCH_BITMAIN || COMPILE_TEST
+ default ARCH_BITMAIN
+ help
+ This driver supports the clocks on Bitmain BM1880 SoC.
+
config COMMON_CLK_CDCE706
tristate "Clock driver for TI CDCE706 clock synthesizer"
depends on I2C
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 0cad76021297..2c1ae6289a78 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_MACH_ASM9260)+= clk-asm9260.o
obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)+= clk-axi-clkgen.o
obj-$(CONFIG_ARCH_AXXIA) += clk-axm5516.o
obj-$(CONFIG_COMMON_CLK_BD718XX) += clk-bd718x7.o
+obj-$(CONFIG_COMMON_CLK_BM1880)+= clk-bm1880.o
obj-$(CONFIG_COMMON_CLK_CDCE706) += clk-cdce706.o
obj-$(CONFIG_COMMON_CLK_CDCE925) += clk-cdce925.o
obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
diff --git a/drivers/clk/clk-bm1880.c b/drivers/clk/clk-bm1880.c
new file mode 100644
index ..3b10de929fd4
--- /dev/null
+++ b/drivers/clk/clk-bm1880.c
@@ -0,0 +1,966 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bitmain BM1880 SoC clock driver
+ *
+ * Copyright (c) 2019 Linaro Ltd.
+ * Author: Manivannan Sadhasivam
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define BM1880_CLK_MPLL_CTL0x00
+#define BM1880_CLK_SPLL_CTL0x04
+#define BM1880_CLK_FPLL_CTL0x08
+#define BM1880_CLK_DDRPLL_CTL 0x0c
+
+#define BM1880_CLK_ENABLE0 0x00
+#define BM1880_CLK_ENABLE1 0x04
+#define BM1880_CLK_SELECT 0x20
+#define BM1880_CLK_DIV00x40
+#define BM1880_CLK_DIV10x44
+#define BM1880_CLK_DIV20x48
+#define BM1880_CLK_DIV30x4c
+#define BM1880_CLK_DIV40x50
+#define BM1880_CLK_DIV50x54
+#define BM1880_CLK_DIV60x58
+#define BM1880_CLK_DIV70x5c
+#define BM1880_CLK_DIV80x60
+#define BM1880_CLK_DIV90x64
+#define BM1880_CLK_DIV10 0x68
+#define BM1880_CLK_DIV11 0x6c
+#define BM1880_CLK_DIV12 0x70
+#define BM1880_CLK_DIV13 0x74
+#define BM1880_CLK_DIV14 0x78
+#define BM1880_CLK_DIV15 0x7c
+#define BM1880_CLK_DIV16 0x80
+#define BM1880_CLK_DIV17 0x84
+#define BM1880_CLK_DIV18 0x88
+#define BM1880_CLK_DIV19 0x8c
+#define BM1880_CLK_DIV20 0x90
+#define BM1880_CLK_DIV21 0x94
+#define BM1880_CLK_DIV22 0x98
+#define BM1880_CLK_DIV23 0x9c
+#define BM1880_CLK_DIV24 0xa0
+#define BM1880_CLK_DIV25 0xa4
+#define BM1880_CLK_DIV26 0xa8
+#define BM1880_CLK_DIV27 0xac
+#define BM1880_CLK_DIV28 0xb0
+
+#define to_bm1880_pll_clk(_hw) container_of(_hw, struct bm1880_pll_hw_clock,
hw)
+#define to_bm1880_div_clk(_hw) container_of(_hw, struct bm1880_div_hw_clock,
hw)
+
+static DEFINE_SPINLOCK(bm1880_clk_lock);
+
+struct bm1880_clock_data {
+ void __iomem *pll_base;
+ void __iomem *sys_base;
+ struct clk_hw_onecell_data *clk_data;
+};
+
+struct bm1880_gate_clock {
+ unsigned intid;
+ const char *name;
+ const char *parent;
+ u32 gate_reg;
+ s8 gate_shift;
+ unsigned long flags;
+};
+
+struct bm1880_mux_clock {
+ unsigned intid;
+ const char *name;
+ const char * const *parents;
+ s8 num_parents;
+ u32 reg;
+ s8 shift;
+ unsigned long flags;
+};
+
+struct bm1880_div_clock {
+ unsigned intid;
+ const char *name;
+ u32 reg;
+ u8 shift;
+ u8 width;
+ u32 initval;
+ const struct clk_div_table *table;
+ unsigned long flags;
+};
+
+struct bm1880_div_hw_clock {
+ struct bm1880_div_clock div;
+ void __iomem *base;
+ spinlock_t *lock;
+ struct clk_hw hw;
+ struct clk_init_data init;
+};
+
+struct bm1880_composite_clock {
+ unsigned intid;
+ const char *name;
+
[PATCH v5 8/8] MAINTAINERS: Add entry for BM1880 SoC clock driver
Add MAINTAINERS entry for Bitmain BM1880 SoC clock driver. Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 997a4f8fe88e..280defec35b2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1503,8 +1503,10 @@ M: Manivannan Sadhasivam L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm64/boot/dts/bitmain/ +F: drivers/clk/clk-bm1880.c F: drivers/pinctrl/pinctrl-bm1880.c F: Documentation/devicetree/bindings/arm/bitmain.yaml +F: Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml F: Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt ARM/CALXEDA HIGHBANK ARCHITECTURE -- 2.17.1
Re: [PATCH 2/2] selftests: watchdog: Add command line option to show watchdog_info
Hello Shuah,
On Mon, Sep 16, 2019 at 10:05:17AM -0600, shuah wrote:
> On 9/16/19 7:57 AM, Eugeniu Rosca wrote:
> >Hi Shuah,
> >CC George
> >
> >On Mon, Sep 16, 2019 at 07:26:41AM -0600, shuah wrote:
> >[..]
> >>> case 'f':
> >>> /* Handled above */
> >>> break;
> >>>+ case 'i':
> >>>+ /*
> >>>+ * watchdog_info was obtained as part of file open
> >>>+ * validation. So we just show it here.
> >>>+ */
> >>>+ oneshot = 1;
> >>>+ printf("watchdog_info:\n");
> >>>+ printf(" identity:\t\t%s\n", info.identity);
> >>>+ printf(" firmware_version:\t%u\n",
> >>>+ info.firmware_version);
> >>>+ printf(" options:\t\t%08x\n", info.options);
> >>>+ break;
> >>> default:
> >>> usage(argv[0]);
> >>>
> >>
> >>I would like to see these combined. Please don't add another argument.
> >>Combine patch and 1&2.
> >
> >With all my appreciation for your comment, why do you think it is better
> >to get rid of the new argument? I don't think it is user-friendly to
> >always report the watchdog_info to the user. Just look at outputs [1-2]
> >and imagine that the watchdog_info part would pop up unconditionally.
> >It looks too busy to me.
>
> Yes it does look busy. I am okay with adding a second options
> based on what you both said.
>
> I don't like the commit log.
Agreed, I didn't like it either - it was rather a draft.
>
> Unfortunately this thread no longer contains the commit log.
>
> I would like to see the commit log without any references to side
> effects. It make it rather confusing.
>
> "A side of affect of commit "selftests: watchdog: Add optional file
> argument" is that arbitrary files may be opened for watchdog testing, e.g.
> /dev/null. To prevent watchdog-test from operating on non-watchdog device
> files, commit "selftests: watchdog: Validate optional file argument" was
> added to validate that a file is indeed a watchdog device via an
> ioctl(WDIOC_GETSUPPORT) call. Since the watchdog_info is available as a
> result of the ioctl(WDIOC_GETSUPPORT) call, add a command line option to
> show the watchdog_info."
>
> I would drop all references to that.
How about the following commit message for the squash commit for [1] and [2]?:
"
selftests: watchdog: Validate optional file argument
As reported by Eugeniu Rosca, a side of affect of commit c3f2490d6e92
("selftests: watchdog: Add optional file argument") is that arbitrary files
may be opened for watchdog testing, e.g.
./watchdog-test -f /dev/zero
Watchdog Ticking Away!
To prevent watchdog-test from operating on non-watchdog device files,
validate that a file is indeed a watchdog device via an
ioctl(WDIOC_GETSUPPORT) call.
While we're at it, since the watchdog_info is available as a result of the
ioctl(WDIOC_GETSUPPORT) call, add a command line option to optionally show
the watchdog_info.
"
Thanks!
>
> thanks,
> -- Shuah
--
Regards,
George
[PATCH v5 2/8] clk: Warn if clk_init_data is not zero initialized
The new implementation for determining parent map uses multiple ways to pass parent info. The order in which it gets processed depends on the first available member. Hence, it is necessary to zero init the clk_init_data struct so that the expected member gets processed correctly. So, add a warning if multiple clk_init_data members are available during clk registration. Signed-off-by: Manivannan Sadhasivam --- drivers/clk/clk.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index c0990703ce54..7d6d6984c979 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -3497,6 +3497,14 @@ static int clk_core_populate_parent_map(struct clk_core *core) if (!num_parents) return 0; + /* +* Check for non-zero initialized clk_init_data struct. This is +* required because, we only require one of the (parent_names/ +* parent_data/parent_hws) to be set at a time. Otherwise, the +* current code would use first available member. +*/ + WARN_ON((parent_names && parent_data) || (parent_names && parent_hws)); + /* * Avoid unnecessary string look-ups of clk_core's possible parents by * having a cache of names/clk_hw pointers to clk_core pointers. -- 2.17.1
[PATCH v5 5/8] arm64: dts: bitmain: Add clock controller support for BM1880 SoC
Add clock controller support for Bitmain BM1880 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/bitmain/bm1880.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/bitmain/bm1880.dtsi
b/arch/arm64/boot/dts/bitmain/bm1880.dtsi
index d65453f99a99..8471662413da 100644
--- a/arch/arm64/boot/dts/bitmain/bm1880.dtsi
+++ b/arch/arm64/boot/dts/bitmain/bm1880.dtsi
@@ -4,6 +4,7 @@
* Author: Manivannan Sadhasivam
*/
+#include
#include
#include
@@ -66,6 +67,12 @@
;
};
+ osc: osc {
+ compatible = "fixed-clock";
+ clock-frequency = <2500>;
+ #clock-cells = <0>;
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -94,6 +101,15 @@
reg = <0x400 0x120>;
};
+ clk: clock-controller@e8 {
+ compatible = "bitmain,bm1880-clk";
+ reg = <0xe8 0x0c>, <0x800 0xb0>;
+ reg-names = "pll", "sys";
+ clocks = <>;
+ clock-names = "osc";
+ #clock-cells = <1>;
+ };
+
rst: reset-controller@c00 {
compatible = "bitmain,bm1880-reset";
reg = <0xc00 0x8>;
--
2.17.1
[PATCH v5 6/8] arm64: dts: bitmain: Source common clock for UART controllers
Remove fixed clock and source common clock for UART controllers.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/bitmain/bm1880-sophon-edge.dts | 9 -
arch/arm64/boot/dts/bitmain/bm1880.dtsi| 12
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/bitmain/bm1880-sophon-edge.dts
b/arch/arm64/boot/dts/bitmain/bm1880-sophon-edge.dts
index 3e8c70778e24..7a2c7f9c2660 100644
--- a/arch/arm64/boot/dts/bitmain/bm1880-sophon-edge.dts
+++ b/arch/arm64/boot/dts/bitmain/bm1880-sophon-edge.dts
@@ -49,12 +49,6 @@
reg = <0x1 0x 0x0 0x4000>; // 1GB
};
- uart_clk: uart-clk {
- compatible = "fixed-clock";
- clock-frequency = <5>;
- #clock-cells = <0>;
- };
-
soc {
gpio0: gpio@50027000 {
porta: gpio-controller@0 {
@@ -173,21 +167,18 @@
{
status = "okay";
- clocks = <_clk>;
pinctrl-names = "default";
pinctrl-0 = <_uart0_default>;
};
{
status = "okay";
- clocks = <_clk>;
pinctrl-names = "default";
pinctrl-0 = <_uart1_default>;
};
{
status = "okay";
- clocks = <_clk>;
pinctrl-names = "default";
pinctrl-0 = <_uart2_default>;
};
diff --git a/arch/arm64/boot/dts/bitmain/bm1880.dtsi
b/arch/arm64/boot/dts/bitmain/bm1880.dtsi
index 8471662413da..fa6e6905f588 100644
--- a/arch/arm64/boot/dts/bitmain/bm1880.dtsi
+++ b/arch/arm64/boot/dts/bitmain/bm1880.dtsi
@@ -174,6 +174,9 @@
uart0: serial@58018000 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x58018000 0x0 0x2000>;
+ clocks = < BM1880_CLK_UART_500M>,
+< BM1880_CLK_APB_UART>;
+ clock-names = "baudclk", "apb_pclk";
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
@@ -184,6 +187,9 @@
uart1: serial@5801A000 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x5801a000 0x0 0x2000>;
+ clocks = < BM1880_CLK_UART_500M>,
+< BM1880_CLK_APB_UART>;
+ clock-names = "baudclk", "apb_pclk";
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
@@ -194,6 +200,9 @@
uart2: serial@5801C000 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x5801c000 0x0 0x2000>;
+ clocks = < BM1880_CLK_UART_500M>,
+< BM1880_CLK_APB_UART>;
+ clock-names = "baudclk", "apb_pclk";
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
@@ -204,6 +213,9 @@
uart3: serial@5801E000 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x5801e000 0x0 0x2000>;
+ clocks = < BM1880_CLK_UART_500M>,
+< BM1880_CLK_APB_UART>;
+ clock-names = "baudclk", "apb_pclk";
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
--
2.17.1
[PATCH v5 4/8] dt-bindings: clock: Add devicetree binding for BM1880 SoC
Add YAML devicetree binding for Bitmain BM1880 SoC.
Signed-off-by: Manivannan Sadhasivam
---
.../bindings/clock/bitmain,bm1880-clk.yaml| 76 +
include/dt-bindings/clock/bm1880-clock.h | 82 +++
2 files changed, 158 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
create mode 100644 include/dt-bindings/clock/bm1880-clock.h
diff --git a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
new file mode 100644
index ..e63827399c1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bindings/clock/bitmain,bm1880-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bitmain BM1880 Clock Controller
+
+maintainers:
+ - Manivannan Sadhasivam
+
+description: |
+ The Bitmain BM1880 clock controller generates and supplies clock to
+ various peripherals within the SoC.
+
+ This binding uses common clock bindings
+ [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+properties:
+ compatible:
+const: bitmain,bm1880-clk
+
+ reg:
+items:
+ - description: pll registers
+ - description: system registers
+
+ reg-names:
+items:
+ - const: pll
+ - const: sys
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: osc
+
+ '#clock-cells':
+const: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ # Clock controller node:
+ - |
+clk: clock-controller@e8 {
+compatible = "bitmain,bm1880-clk";
+reg = <0xe8 0x0c>, <0x800 0xb0>;
+reg-names = "pll", "sys";
+clocks = <>;
+clock-names = "osc";
+#clock-cells = <1>;
+};
+
+ # Example UART controller node that consumes clock generated by the clock
controller:
+ - |
+uart0: serial@58018000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x58018000 0x0 0x2000>;
+ clocks = < 45>, < 46>;
+ clock-names = "baudclk", "apb_pclk";
+ interrupts = <0 9 4>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+};
+
+...
diff --git a/include/dt-bindings/clock/bm1880-clock.h
b/include/dt-bindings/clock/bm1880-clock.h
new file mode 100644
index ..b46732361b25
--- /dev/null
+++ b/include/dt-bindings/clock/bm1880-clock.h
@@ -0,0 +1,82 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Device Tree binding constants for Bitmain BM1880 SoC
+ *
+ * Copyright (c) 2019 Linaro Ltd.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_BM1880_H
+#define __DT_BINDINGS_CLOCK_BM1880_H
+
+#define BM1880_CLK_OSC 0
+#define BM1880_CLK_MPLL1
+#define BM1880_CLK_SPLL2
+#define BM1880_CLK_FPLL3
+#define BM1880_CLK_DDRPLL 4
+#define BM1880_CLK_A53 5
+#define BM1880_CLK_50M_A53 6
+#define BM1880_CLK_AHB_ROM 7
+#define BM1880_CLK_AXI_SRAM8
+#define BM1880_CLK_DDR_AXI 9
+#define BM1880_CLK_EFUSE 10
+#define BM1880_CLK_APB_EFUSE 11
+#define BM1880_CLK_AXI5_EMMC 12
+#define BM1880_CLK_EMMC13
+#define BM1880_CLK_100K_EMMC 14
+#define BM1880_CLK_AXI5_SD 15
+#define BM1880_CLK_SD 16
+#define BM1880_CLK_100K_SD 17
+#define BM1880_CLK_500M_ETH0 18
+#define BM1880_CLK_AXI4_ETH0 19
+#define BM1880_CLK_500M_ETH1 20
+#define BM1880_CLK_AXI4_ETH1 21
+#define BM1880_CLK_AXI1_GDMA 22
+#define BM1880_CLK_APB_GPIO23
+#define BM1880_CLK_APB_GPIO_INTR 24
+#define BM1880_CLK_GPIO_DB 25
+#define BM1880_CLK_AXI1_MINER 26
+#define BM1880_CLK_AHB_SF 27
+#define BM1880_CLK_SDMA_AXI28
+#define BM1880_CLK_SDMA_AUD29
+#define BM1880_CLK_APB_I2C 30
+#define BM1880_CLK_APB_WDT 31
+#define BM1880_CLK_APB_JPEG32
+#define BM1880_CLK_JPEG_AXI33
+#define BM1880_CLK_AXI5_NF 34
+#define BM1880_CLK_APB_NF 35
+#define BM1880_CLK_NF 36
+#define BM1880_CLK_APB_PWM 37
+#define BM1880_CLK_DIV_0_RV38
+#define BM1880_CLK_DIV_1_RV39
+#define BM1880_CLK_MUX_RV 40
+#define BM1880_CLK_RV 41
+#define BM1880_CLK_APB_SPI 42
+#define BM1880_CLK_TPU_AXI 43
+#define BM1880_CLK_DIV_UART_500M 44
+#define BM1880_CLK_UART_500M 45
+#define BM1880_CLK_APB_UART46
+#define BM1880_CLK_APB_I2S 47
+#define BM1880_CLK_AXI4_USB48
+#define
[PATCH v5 3/8] clk: Add clk_hw_unregister_composite helper function definition
This function has been delcared but not defined anywhere. Hence, this
commit adds definition for it.
Signed-off-by: Manivannan Sadhasivam
---
drivers/clk/clk-composite.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 4d579f9d20f6..ccca58a6d271 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -344,3 +344,14 @@ void clk_unregister_composite(struct clk *clk)
clk_unregister(clk);
kfree(composite);
}
+
+void clk_hw_unregister_composite(struct clk_hw *hw)
+{
+ struct clk_composite *composite;
+
+ composite = to_clk_composite(hw);
+
+ clk_hw_unregister(hw);
+ kfree(composite);
+}
+EXPORT_SYMBOL_GPL(clk_hw_unregister_composite);
--
2.17.1
[PATCH v5 0/8] Add Bitmain BM1880 clock driver
Hello,
This patchset adds common clock driver for Bitmain BM1880 SoC clock
controller. The clock controller consists of gate, divider, mux
and pll clocks with different compositions. Hence, the driver uses
composite clock structure in place where multiple clocking units are
combined together.
This patchset also removes UART fixed clock and sources clocks from clock
controller for Sophon Edge board where the driver has been validated.
Thanks,
Mani
Changes in v5:
* Incorporated review comments from Rob on dt binding
Changes in v4:
* Fixed devicetree binding issue
* Added ARCH_BITMAIN as the default for the clk driver
Changes in v3:
* Switched to clk_hw_{register/unregister} APIs
* Returned clk_hw from the in-driver registration helpers
Changes in v2:
* Converted the dt binding to YAML
* Incorporated review comments from Stephen (majority of change is switching
to new way of specifying clk parents)
Manivannan Sadhasivam (8):
clk: Zero init clk_init_data in helpers
clk: Warn if clk_init_data is not zero initialized
clk: Add clk_hw_unregister_composite helper function definition
dt-bindings: clock: Add devicetree binding for BM1880 SoC
arm64: dts: bitmain: Add clock controller support for BM1880 SoC
arm64: dts: bitmain: Source common clock for UART controllers
clk: Add common clock driver for BM1880 SoC
MAINTAINERS: Add entry for BM1880 SoC clock driver
.../bindings/clock/bitmain,bm1880-clk.yaml| 76 ++
MAINTAINERS | 2 +
.../boot/dts/bitmain/bm1880-sophon-edge.dts | 9 -
arch/arm64/boot/dts/bitmain/bm1880.dtsi | 28 +
drivers/clk/Kconfig | 7 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-bm1880.c | 966 ++
drivers/clk/clk-composite.c | 13 +-
drivers/clk/clk-divider.c | 2 +-
drivers/clk/clk-fixed-rate.c | 2 +-
drivers/clk/clk-gate.c| 2 +-
drivers/clk/clk-mux.c | 2 +-
drivers/clk/clk.c | 8 +
include/dt-bindings/clock/bm1880-clock.h | 82 ++
14 files changed, 1186 insertions(+), 14 deletions(-)
create mode 100644
Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
create mode 100644 drivers/clk/clk-bm1880.c
create mode 100644 include/dt-bindings/clock/bm1880-clock.h
--
2.17.1
[PATCH v5 1/8] clk: Zero init clk_init_data in helpers
The clk_init_data struct needs to be initialized to zero for the new
parent_map implementation to work correctly. Otherwise, the member which
is available first will get processed.
Signed-off-by: Manivannan Sadhasivam
---
drivers/clk/clk-composite.c | 2 +-
drivers/clk/clk-divider.c| 2 +-
drivers/clk/clk-fixed-rate.c | 2 +-
drivers/clk/clk-gate.c | 2 +-
drivers/clk/clk-mux.c| 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index b06038b8f658..4d579f9d20f6 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -208,7 +208,7 @@ struct clk_hw *clk_hw_register_composite(struct device
*dev, const char *name,
unsigned long flags)
{
struct clk_hw *hw;
- struct clk_init_data init;
+ struct clk_init_data init = { NULL };
struct clk_composite *composite;
struct clk_ops *clk_composite_ops;
int ret;
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 3f9ff78c4a2a..65dd8137f9ec 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -471,7 +471,7 @@ static struct clk_hw *_register_divider(struct device *dev,
const char *name,
{
struct clk_divider *div;
struct clk_hw *hw;
- struct clk_init_data init;
+ struct clk_init_data init = { NULL };
int ret;
if (clk_divider_flags & CLK_DIVIDER_HIWORD_MASK) {
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index a7e4aef7a376..746c3ecdc5b3 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -58,7 +58,7 @@ struct clk_hw
*clk_hw_register_fixed_rate_with_accuracy(struct device *dev,
{
struct clk_fixed_rate *fixed;
struct clk_hw *hw;
- struct clk_init_data init;
+ struct clk_init_data init = { NULL };
int ret;
/* allocate fixed-rate clock */
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 1b99fc962745..8ed83ec730cb 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -141,7 +141,7 @@ struct clk_hw *clk_hw_register_gate(struct device *dev,
const char *name,
{
struct clk_gate *gate;
struct clk_hw *hw;
- struct clk_init_data init;
+ struct clk_init_data init = { NULL };
int ret;
if (clk_gate_flags & CLK_GATE_HIWORD_MASK) {
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 66e91f740508..2caa6b2a9ee5 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -153,7 +153,7 @@ struct clk_hw *clk_hw_register_mux_table(struct device
*dev, const char *name,
{
struct clk_mux *mux;
struct clk_hw *hw;
- struct clk_init_data init;
+ struct clk_init_data init = { NULL };
u8 width = 0;
int ret;
--
2.17.1
Re: [v6 1/2] mtd: rawnand: Add new Cadence NAND driver to MTD subsystem
Hi Piotr,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190915]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Piotr-Sroka/mtd-rawnand-Add-Cadence-NAND-controller-driver/20190916-205004
config: parisc-allyesconfig (attached as .config)
compiler: hppa-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=parisc
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/mtd/nand/raw/cadence-nand-controller.c: In function
'cadence_nand_read_buf':
>> drivers/mtd/nand/raw/cadence-nand-controller.c:1877:3: error: implicit
>> declaration of function 'readsl'; did you mean 'readl'?
>> [-Werror=implicit-function-declaration]
readsl(cdns_ctrl->io.virt, buf, len_in_words);
^~
readl
drivers/mtd/nand/raw/cadence-nand-controller.c: In function
'cadence_nand_write_buf':
>> drivers/mtd/nand/raw/cadence-nand-controller.c:1930:3: error: implicit
>> declaration of function 'writesl'; did you mean 'writel'?
>> [-Werror=implicit-function-declaration]
writesl(cdns_ctrl->io.virt, buf, len_in_words);
^~~
writel
cc1: some warnings being treated as errors
vim +1877 drivers/mtd/nand/raw/cadence-nand-controller.c
1860
1861 static int cadence_nand_read_buf(struct cdns_nand_ctrl *cdns_ctrl,
1862 u8 *buf, int len)
1863 {
1864 u8 thread_nr = 0;
1865 u32 sdma_size;
1866 int status;
1867
1868 /* Wait until slave DMA interface is ready to data transfer. */
1869 status = cadence_nand_wait_on_sdma(cdns_ctrl, _nr,
_size);
1870 if (status)
1871 return status;
1872
1873 if (!cdns_ctrl->caps1->has_dma) {
1874 int len_in_words = len >> 2;
1875
1876 /* read alingment data */
> 1877 readsl(cdns_ctrl->io.virt, buf, len_in_words);
1878 if (sdma_size > len) {
1879 /* read rest data from slave DMA interface if
any */
1880 readsl(cdns_ctrl->io.virt, cdns_ctrl->buf,
1881 sdma_size / 4 - len_in_words);
1882 /* copy rest of data */
1883 memcpy(buf + (len_in_words << 2),
cdns_ctrl->buf,
1884 len - (len_in_words << 2));
1885 }
1886 return 0;
1887 }
1888
1889 if (cdns_ctrl->dmac && cadence_nand_dma_buf_ok(cdns_ctrl, buf,
len)) {
1890 status = cadence_nand_slave_dma_transfer(cdns_ctrl, buf,
1891
cdns_ctrl->io.dma,
1892 len,
DMA_FROM_DEVICE);
1893 if (status == 0)
1894 return 0;
1895
1896 dev_warn(cdns_ctrl->dev,
1897 "Slave DMA transfer failed. Try again using
bounce buffer.");
1898 }
1899
1900 /* If DMA transfer is not possible or failed then use bounce
buffer. */
1901 status = cadence_nand_slave_dma_transfer(cdns_ctrl,
cdns_ctrl->buf,
1902 cdns_ctrl->io.dma,
1903 sdma_size,
DMA_FROM_DEVICE);
1904
1905 if (status) {
1906 dev_err(cdns_ctrl->dev, "Slave DMA transfer failed");
1907 return status;
1908 }
1909
1910 memcpy(buf, cdns_ctrl->buf, len);
1911
1912 return 0;
1913 }
1914
1915 static int cadence_nand_write_buf(struct cdns_nand_ctrl *cdns_ctrl,
1916const u8 *buf, int len)
1917 {
1918 u8 thread_nr = 0;
1919 u32 sdma_size;
1920 int status;
1921
1922 /* Wait until slave DMA interface is ready to data transfer. */
1923 status = cadence_nand_wait_on_sdma(cdns_ctrl, _nr,
_size);
1924 if (status)
1925 return status;
1926
1927 if (!cdns_ctrl->caps1->has_dma) {
1928 int len_in_words = len >> 2;
1929
> 1930 writesl(cdns_ctrl->io.virt, buf, len_in_words);
1931
RE: [PATCH 2/3] spi: dw: Add basic runtime PM support
Hi Geert,
I appreciate the feedback.
> On Mon, Sep 16, 2019 at 15:36 PM Geert Uytterhoeven
> wrote:
> Hi Gareth,
>
> On Fri, Sep 13, 2019 at 2:13 PM Gareth Williams
> wrote:
> > From: Phil Edworthy
> >
> > Enable runtime PM so that the clock used to access the registers in
> > the peripheral is turned on using a clock domain.
> >
> > Signed-off-by: Phil Edworthy
> > Signed-off-by: Gareth Williams
>
> Thanks for your patch!
>
> > --- a/drivers/spi/spi-dw.c
> > +++ b/drivers/spi/spi-dw.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -497,6 +498,9 @@ int dw_spi_add_host(struct device *dev, struct
> dw_spi *dws)
> > if (dws->set_cs)
> > master->set_cs = dws->set_cs;
> >
> > + pm_runtime_enable(dev);
> > + pm_runtime_get_sync(dev);
>
> The second line keeps the device powered all the time.
> What about setting spi_controller.auto_runtime_pm = true, so the SPI code
> can manage its Runtime PM status?
That makes sense and works on target, I will change this for V2.
>
> > +
> > /* Basic HW init */
> > spi_hw_init(dev, dws);
> >
>
> What about the error path?
> Don't you need to disable Runtime PM again in dw_spi_remove_host()?
I will add a call to disable pm in dw_spi_remove_host() and the err path in
dw_spi_add_host for v2.
>
> I assume this will be called from drivers/spi/spi-dw-mmio.c, which already
> enables the clock explicitly all the timer?
Yes, spi-dw-mmio.c already enables the bus clock, however we want to use clock
domain to enable the clock and not explicitly provide pclk in the dts. If there
are
no other uses of that pclk, we can remove that later on.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-
> m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Kind Regards,
Gareth
Re: [RFC PATCH 0/2] Add support for SBI version to 0.2
On Sun, 15 Sep 2019 23:54:46 PDT (-0700), Christoph Hellwig wrote: On Fri, Sep 13, 2019 at 08:54:27AM -0700, Palmer Dabbelt wrote: On Tue, Sep 3, 2019 at 12:38 AM h...@infradead.org wrote: > On Fri, Aug 30, 2019 at 11:13:25PM +, Atish Patra wrote: > > If I understood you clearly, you want to call it legacy in the spec and > > just say v0.1 extensions. > > > > The whole idea of marking them as legacy extensions to indicate that it > > would be obsolete in the future. > > > > But I am not too worried about the semantics here. So I am fine with > > just changing the text to v0.1 if that avoids confusion. > > So my main problems is that we are lumping all the "legacy" extensions > together. While some of them are simply a bad idea and shouldn't > really be implemented for anything new ever, others like the sfence.vma > and ipi ones are needed until we have hardware support to avoid them > and possibly forever for virtualization. > > So either we use different markers of legacy for them, or we at least > define new extensions that replace them at the same time. What I > want to avoid is the possibіly of an implementation using the really > legacy bits and new extensions at the same time. > Nominally we've got to replace these as well because we didn't include the length of the hart mask. Well, let's do that as part of definining the first real post-0.1 SBI then, and don't bother defining the old ones as legacy at all. Just two different specs that don't interact except that we reserve extension space in the new one for the old one so that one SBI spec can implement both. Makes sense. We're getting finish with this "just go write everything down" exercise, so we can start actually doing things now :).
Re: [PATCH] serial/sifive: select SERIAL_EARLYCON
On Sun, 15 Sep 2019 23:42:53 PDT (-0700), Christoph Hellwig wrote: On Fri, Sep 13, 2019 at 01:40:27PM -0700, Palmer Dabbelt wrote: OpenEmbedded passes "earlycon=sbi", which I can find in the doumentation. I can't find anything about just "earlycon". I've sent a patch adding sbi to the list of earlycon arguments. earlycon without arguments is documented, although just for ARM64. I can send a patch to update it to properly cover all DT platforms in addition. Thanks. I've kind of lost track of the thread, but assuming that does the "automatically pick an earlycon" stuff then that's probably what we should be using in the distros.
[RFC PATCH] mm/slub: remove left-over debugging code
SLUB_RESILIENCY_TEST and SLUB_DEBUG_CMPXCHG look like some left-over
debugging code during the internal development that probably nobody uses
it anymore. Remove them to make the world greener.
---
mm/slub.c | 110 --
1 file changed, 110 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 8834563cdb4b..f97155ba097d 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -150,12 +150,6 @@ static inline bool kmem_cache_has_cpu_partial(struct
kmem_cache *s)
* - Variable sizing of the per node arrays
*/
-/* Enable to test recovery from slab corruption on boot */
-#undef SLUB_RESILIENCY_TEST
-
-/* Enable to log cmpxchg failures */
-#undef SLUB_DEBUG_CMPXCHG
-
/*
* Mininum number of partial slabs. These will be left on the partial
* lists even if they are empty. kmem_cache_shrink may reclaim them.
@@ -392,10 +386,6 @@ static inline bool __cmpxchg_double_slab(struct kmem_cache
*s, struct page *page
cpu_relax();
stat(s, CMPXCHG_DOUBLE_FAIL);
-#ifdef SLUB_DEBUG_CMPXCHG
- pr_info("%s %s: cmpxchg double redo ", n, s->name);
-#endif
-
return false;
}
@@ -433,10 +423,6 @@ static inline bool cmpxchg_double_slab(struct kmem_cache
*s, struct page *page,
cpu_relax();
stat(s, CMPXCHG_DOUBLE_FAIL);
-#ifdef SLUB_DEBUG_CMPXCHG
- pr_info("%s %s: cmpxchg double redo ", n, s->name);
-#endif
-
return false;
}
@@ -2004,45 +1990,11 @@ static inline unsigned long next_tid(unsigned long tid)
return tid + TID_STEP;
}
-static inline unsigned int tid_to_cpu(unsigned long tid)
-{
- return tid % TID_STEP;
-}
-
-static inline unsigned long tid_to_event(unsigned long tid)
-{
- return tid / TID_STEP;
-}
-
static inline unsigned int init_tid(int cpu)
{
return cpu;
}
-static inline void note_cmpxchg_failure(const char *n,
- const struct kmem_cache *s, unsigned long tid)
-{
-#ifdef SLUB_DEBUG_CMPXCHG
- unsigned long actual_tid = __this_cpu_read(s->cpu_slab->tid);
-
- pr_info("%s %s: cmpxchg redo ", n, s->name);
-
-#ifdef CONFIG_PREEMPT
- if (tid_to_cpu(tid) != tid_to_cpu(actual_tid))
- pr_warn("due to cpu change %d -> %d\n",
- tid_to_cpu(tid), tid_to_cpu(actual_tid));
- else
-#endif
- if (tid_to_event(tid) != tid_to_event(actual_tid))
- pr_warn("due to cpu running other code. Event %ld->%ld\n",
- tid_to_event(tid), tid_to_event(actual_tid));
- else
- pr_warn("for unknown reason: actual=%lx was=%lx target=%lx\n",
- actual_tid, tid, next_tid(tid));
-#endif
- stat(s, CMPXCHG_DOUBLE_CPU_FAIL);
-}
-
static void init_kmem_cache_cpus(struct kmem_cache *s)
{
int cpu;
@@ -2751,7 +2703,6 @@ static __always_inline void *slab_alloc_node(struct
kmem_cache *s,
object, tid,
next_object, next_tid(tid {
- note_cmpxchg_failure("slab_alloc", s, tid);
goto redo;
}
prefetch_freepointer(s, next_object);
@@ -4694,66 +4645,6 @@ static int list_locations(struct kmem_cache *s, char
*buf,
}
#endif /* CONFIG_SLUB_DEBUG */
-#ifdef SLUB_RESILIENCY_TEST
-static void __init resiliency_test(void)
-{
- u8 *p;
- int type = KMALLOC_NORMAL;
-
- BUILD_BUG_ON(KMALLOC_MIN_SIZE > 16 || KMALLOC_SHIFT_HIGH < 10);
-
- pr_err("SLUB resiliency testing\n");
- pr_err("---\n");
- pr_err("A. Corruption after allocation\n");
-
- p = kzalloc(16, GFP_KERNEL);
- p[16] = 0x12;
- pr_err("\n1. kmalloc-16: Clobber Redzone/next pointer 0x12->0x%p\n\n",
- p + 16);
-
- validate_slab_cache(kmalloc_caches[type][4]);
-
- /* Hmmm... The next two are dangerous */
- p = kzalloc(32, GFP_KERNEL);
- p[32 + sizeof(void *)] = 0x34;
- pr_err("\n2. kmalloc-32: Clobber next pointer/next slab 0x34 ->
-0x%p\n",
- p);
- pr_err("If allocated object is overwritten then not detectable\n\n");
-
- validate_slab_cache(kmalloc_caches[type][5]);
- p = kzalloc(64, GFP_KERNEL);
- p += 64 + (get_cycles() & 0xff) * sizeof(void *);
- *p = 0x56;
- pr_err("\n3. kmalloc-64: corrupting random byte 0x56->0x%p\n",
- p);
- pr_err("If allocated object is overwritten then not detectable\n\n");
- validate_slab_cache(kmalloc_caches[type][6]);
-
- pr_err("\nB. Corruption after free\n");
- p = kzalloc(128, GFP_KERNEL);
- kfree(p);
- *p = 0x78;
- pr_err("1. kmalloc-128: Clobber first word 0x78->0x%p\n\n", p);
- validate_slab_cache(kmalloc_caches[type][7]);
-
- p = kzalloc(256, GFP_KERNEL);
- kfree(p);
- p[50] = 0x9a;
- pr_err("\n2. kmalloc-256: Clobber 50th byte 0x9a->0x%p\n\n", p);
-
[PATCH] pinctrl: devicetree: Avoid taking direct reference to device name string
When populating the pinctrl mapping table entries for a device, the
'dev_name' field for each entry is initialised to point directly at the
string returned by 'dev_name()' for the device and subsequently used by
'create_pinctrl()' when looking up the mappings for the device being
probed.
This is unreliable in the presence of calls to 'dev_set_name()', which may
reallocate the device name string leaving the pinctrl mappings with a
dangling reference. This then leads to a use-after-free every time the
name is dereferenced by a device probe:
| BUG: KASAN: invalid-access in strcmp+0x20/0x64
| Read of size 1 at addr 13c153494b00 by task modprobe/590
| Pointer tag: [13], memory tag: [fe]
|
| Call trace:
| __kasan_report+0x16c/0x1dc
| kasan_report+0x10/0x18
| check_memory_region
| __hwasan_load1_noabort+0x4c/0x54
| strcmp+0x20/0x64
| create_pinctrl+0x18c/0x7f4
| pinctrl_get+0x90/0x114
| devm_pinctrl_get+0x44/0x98
| pinctrl_bind_pins+0x5c/0x450
| really_probe+0x1c8/0x9a4
| driver_probe_device+0x120/0x1d8
Follow the example of sysfs, and duplicate the device name string before
stashing it away in the pinctrl mapping entries.
Cc: Linus Walleij
Reported-by: Elena Petrova
Tested-by: Elena Petrova
Signed-off-by: Will Deacon
---
drivers/pinctrl/devicetree.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index 88ddbb2e30de..9721ad30c541 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -29,6 +29,13 @@ struct pinctrl_dt_map {
static void dt_free_map(struct pinctrl_dev *pctldev,
struct pinctrl_map *map, unsigned num_maps)
{
+ int i;
+
+ for (i = 0; i < num_maps; ++i) {
+ kfree_const(map[i].dev_name);
+ map[i].dev_name = NULL;
+ }
+
if (pctldev) {
const struct pinctrl_ops *ops = pctldev->desc->pctlops;
if (ops->dt_free_map)
@@ -63,7 +70,13 @@ static int dt_remember_or_free_map(struct pinctrl *p, const
char *statename,
/* Initialize common mapping table entry fields */
for (i = 0; i < num_maps; i++) {
- map[i].dev_name = dev_name(p->dev);
+ const char *devname;
+
+ devname = kstrdup_const(dev_name(p->dev), GFP_KERNEL);
+ if (!devname)
+ goto err_free_map;
+
+ map[i].dev_name = devname;
map[i].name = statename;
if (pctldev)
map[i].ctrl_dev_name = dev_name(pctldev->dev);
@@ -71,10 +84,8 @@ static int dt_remember_or_free_map(struct pinctrl *p, const
char *statename,
/* Remember the converted mapping table entries */
dt_map = kzalloc(sizeof(*dt_map), GFP_KERNEL);
- if (!dt_map) {
- dt_free_map(pctldev, map, num_maps);
- return -ENOMEM;
- }
+ if (!dt_map)
+ goto err_free_map;
dt_map->pctldev = pctldev;
dt_map->map = map;
@@ -82,6 +93,10 @@ static int dt_remember_or_free_map(struct pinctrl *p, const
char *statename,
list_add_tail(_map->node, >dt_maps);
return pinctrl_register_map(map, num_maps, false);
+
+err_free_map:
+ dt_free_map(pctldev, map, num_maps);
+ return -ENOMEM;
}
struct pinctrl_dev *of_pinctrl_get(struct device_node *np)
--
2.23.0.237.gc6a4ce50a0-goog
memory leak in h5_rx_pkt_start
Hello, syzbot found the following crash on: HEAD commit:1609d760 Merge tag 'for-linus' of git://git.kernel.org/pub.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1494a08160 kernel config: https://syzkaller.appspot.com/x/.config?x=90cbcb59581ed842 dashboard link: https://syzkaller.appspot.com/bug?extid=6ce141c55b2f7aafd1c4 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1218547960 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1238c46560 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+6ce141c55b2f7aafd...@syzkaller.appspotmail.com executing program executing program executing program executing program executing program BUG: memory leak unreferenced object 0x88811469e100 (size 224): comm "syz-executor068", pid 6860, jiffies 4294949784 (age 13.480s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0 bf 20 81 88 ff ff 00 00 00 00 00 00 00 00 ... backtrace: [<36b71133>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<36b71133>] slab_post_alloc_hook mm/slab.h:522 [inline] [<36b71133>] slab_alloc_node mm/slab.c:3262 [inline] [<36b71133>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574 [] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197 [<97f6a43a>] alloc_skb include/linux/skbuff.h:1055 [inline] [<97f6a43a>] bt_skb_alloc include/net/bluetooth/bluetooth.h:339 [inline] [<97f6a43a>] h5_rx_pkt_start+0x57/0xd0 drivers/bluetooth/hci_h5.c:474 [ ] h5_recv+0x13f/0x1d0 drivers/bluetooth/hci_h5.c:563 [ ] hci_uart_tty_receive+0xba/0x200 drivers/bluetooth/hci_ldisc.c:613 [<39786cc4>] tiocsti drivers/tty/tty_io.c:2197 [inline] [<39786cc4>] tty_ioctl+0x81c/0xa30 drivers/tty/tty_io.c:2573 [ ] vfs_ioctl fs/ioctl.c:46 [inline] [ ] file_ioctl fs/ioctl.c:509 [inline] [ ] do_vfs_ioctl+0x62a/0x810 fs/ioctl.c:696 [ ] ksys_ioctl+0x86/0xb0 fs/ioctl.c:713 [ ] __do_sys_ioctl fs/ioctl.c:720 [inline] [ ] __se_sys_ioctl fs/ioctl.c:718 [inline] [ ] __x64_sys_ioctl+0x1e/0x30 fs/ioctl.c:718 [ ] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296 [<8887ecc0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 --- This bug 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 bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH] selftests/net: replace AF_MAX with INT_MAX in socket.c
On 9/16/19 9:03 AM, Marcelo Henrique Cerri wrote:
Use INT_MAX instead of AF_MAX, since libc might have a smaller value
of AF_MAX than the kernel, what causes the test to fail.
Signed-off-by: Marcelo Henrique Cerri
---
tools/testing/selftests/net/socket.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/socket.c
b/tools/testing/selftests/net/socket.c
index afca1ead677f..10e75ba90124 100644
--- a/tools/testing/selftests/net/socket.c
+++ b/tools/testing/selftests/net/socket.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
struct socket_testcase {
int domain;
@@ -24,7 +25,10 @@ struct socket_testcase {
};
static struct socket_testcase tests[] = {
- { AF_MAX, 0, 0, -EAFNOSUPPORT,0 },
+ /* libc might have a smaller value of AF_MAX than the kernel
+* actually supports, so use INT_MAX instead.
+*/
+ { INT_MAX, 0, 0, -EAFNOSUPPORT,0 },
{ AF_INET, SOCK_STREAM, IPPROTO_TCP, 0,1 },
{ AF_INET, SOCK_DGRAM, IPPROTO_TCP, -EPROTONOSUPPORT, 1 },
{ AF_INET, SOCK_DGRAM, IPPROTO_UDP, 0,1 },
What failure are you seeing? It sounds arbitrary to use INT_MAX
instead of AF_MAX. I think it is important to understand the
failure first.
Please note that AF_MAX is widely used in the kernel.
thanks,
-- Shuah
possible deadlock in usb_deregister_dev (2)
Hello,
syzbot found the following crash on:
HEAD commit:f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=1742f15960
kernel config: https://syzkaller.appspot.com/x/.config?x=5c6633fa4ed00be5
dashboard link: https://syzkaller.appspot.com/bug?extid=f9549f5ee8a5416f0b95
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f9549f5ee8a5416f0...@syzkaller.appspotmail.com
usb 5-1: USB disconnect, device number 27
==
WARNING: possible circular locking dependency detected
5.3.0-rc7+ #0 Not tainted
--
kworker/1:5/2876 is trying to acquire lock:
6f0f0bc3 (minor_rwsem){}, at: usb_deregister_dev+0x95/0x230
drivers/usb/core/file.c:239
but task is already holding lock:
175691a3 (open_disc_mutex){+.+.}, at: tower_disconnect+0x45/0x300
drivers/usb/misc/legousbtower.c:945
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (open_disc_mutex){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:930 [inline]
__mutex_lock+0x158/0x1360 kernel/locking/mutex.c:1077
tower_open+0xce/0x9b0 drivers/usb/misc/legousbtower.c:335
usb_open+0x1df/0x270 drivers/usb/core/file.c:48
chrdev_open+0x219/0x5c0 fs/char_dev.c:414
do_dentry_open+0x494/0x1120 fs/open.c:797
do_last fs/namei.c:3416 [inline]
path_openat+0x1430/0x3f50 fs/namei.c:3533
do_filp_open+0x1a1/0x280 fs/namei.c:3563
do_sys_open+0x3c0/0x580 fs/open.c:1089
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (minor_rwsem){}:
check_prev_add kernel/locking/lockdep.c:2405 [inline]
check_prevs_add kernel/locking/lockdep.c:2507 [inline]
validate_chain kernel/locking/lockdep.c:2897 [inline]
__lock_acquire+0x1f7c/0x3b50 kernel/locking/lockdep.c:3880
lock_acquire+0x127/0x320 kernel/locking/lockdep.c:4412
down_write+0x92/0x150 kernel/locking/rwsem.c:1500
usb_deregister_dev+0x95/0x230 drivers/usb/core/file.c:239
tower_disconnect+0xa8/0x300 drivers/usb/misc/legousbtower.c:951
usb_unbind_interface+0x1bd/0x8a0 drivers/usb/core/driver.c:423
__device_release_driver drivers/base/dd.c:1134 [inline]
device_release_driver_internal+0x42f/0x500 drivers/base/dd.c:1165
bus_remove_device+0x2dc/0x4a0 drivers/base/bus.c:556
device_del+0x420/0xb10 drivers/base/core.c:2339
usb_disable_device+0x211/0x690 drivers/usb/core/message.c:1237
usb_disconnect+0x284/0x8d0 drivers/usb/core/hub.c:2199
hub_port_connect drivers/usb/core/hub.c:4949 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1454/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(open_disc_mutex);
lock(minor_rwsem);
lock(open_disc_mutex);
lock(minor_rwsem);
*** DEADLOCK ***
6 locks held by kworker/1:5/2876:
#0: ecb9dcf5 ((wq_completion)usb_hub_wq){+.+.}, at:
__write_once_size include/linux/compiler.h:226 [inline]
#0: ecb9dcf5 ((wq_completion)usb_hub_wq){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: ecb9dcf5 ((wq_completion)usb_hub_wq){+.+.}, at: atomic64_set
include/asm-generic/atomic-instrumented.h:855 [inline]
#0: ecb9dcf5 ((wq_completion)usb_hub_wq){+.+.}, at:
atomic_long_set include/asm-generic/atomic-long.h:40 [inline]
#0: ecb9dcf5 ((wq_completion)usb_hub_wq){+.+.}, at: set_work_data
kernel/workqueue.c:620 [inline]
#0: ecb9dcf5 ((wq_completion)usb_hub_wq){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:647 [inline]
#0: ecb9dcf5 ((wq_completion)usb_hub_wq){+.+.}, at:
process_one_work+0x827/0x1530 kernel/workqueue.c:2240
#1: 09747c0c ((work_completion)(>events)){+.+.}, at:
process_one_work+0x85b/0x1530 kernel/workqueue.c:2244
#2: 4bd4f175 (>mutex){}, at: device_lock
include/linux/device.h:1223 [inline]
#2: 4bd4f175 (>mutex){}, at: hub_event+0x17c/0x3640
drivers/usb/core/hub.c:5387
#3: 668c8b60 (>mutex){}, at: device_lock
Re: [PATCH 2/2] selftests: watchdog: Add command line option to show watchdog_info
On 9/16/19 7:57 AM, Eugeniu Rosca wrote:
Hi Shuah,
CC George
On Mon, Sep 16, 2019 at 07:26:41AM -0600, shuah wrote:
[..]
case 'f':
/* Handled above */
break;
+ case 'i':
+ /*
+* watchdog_info was obtained as part of file open
+* validation. So we just show it here.
+*/
+ oneshot = 1;
+ printf("watchdog_info:\n");
+ printf(" identity:\t\t%s\n", info.identity);
+ printf(" firmware_version:\t%u\n",
+ info.firmware_version);
+ printf(" options:\t\t%08x\n", info.options);
+ break;
default:
usage(argv[0]);
I would like to see these combined. Please don't add another argument.
Combine patch and 1&2.
With all my appreciation for your comment, why do you think it is better
to get rid of the new argument? I don't think it is user-friendly to
always report the watchdog_info to the user. Just look at outputs [1-2]
and imagine that the watchdog_info part would pop up unconditionally.
It looks too busy to me.
Yes it does look busy. I am okay with adding a second options
based on what you both said.
I don't like the commit log.
Unfortunately this thread no longer contains the commit log.
I would like to see the commit log without any references to side
effects. It make it rather confusing.
"A side of affect of commit "selftests: watchdog: Add optional file
argument" is that arbitrary files may be opened for watchdog testing, e.g.
/dev/null. To prevent watchdog-test from operating on non-watchdog device
files, commit "selftests: watchdog: Validate optional file argument" was
added to validate that a file is indeed a watchdog device via an
ioctl(WDIOC_GETSUPPORT) call. Since the watchdog_info is available as a
result of the ioctl(WDIOC_GETSUPPORT) call, add a command line option to
show the watchdog_info."
I would drop all references to that.
thanks,
-- Shuah
Re: [PATCH v5 0/7] mm, slab: Make kmalloc_info[] contain all types of names
On Mon, 16 Sep 2019, Pengfei Li wrote: > The name of KMALLOC_NORMAL is contained in kmalloc_info[].name, > but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically > generated by kmalloc_cache_name(). > > Patch1 predefines the names of all types of kmalloc to save > the time spent dynamically generating names. > > These changes make sense, and the time spent by new_kmalloc_cache() > has been reduced by approximately 36.3%. This is time spend during boot and does not affect later system performance. > Time spent by new_kmalloc_cache() > (CPU cycles) > 5.3-rc7 66264 > 5.3-rc7+patch_1-342188 Ok. 15k cycles during boot saved. So we save 5 microseconds during bootup? The current approach was created with the view on future setups allowing a dynamic configuration of kmalloc caches based on need. I.e. ZONE_DMA may not be needed once the floppy driver no longer makes use of it.
Re: [Patch 05/13] media: am437x-vpfe: Streamlined vb2 buffer cleanup
On Mon, Sep 16, 2019 at 3:51 PM Benoit Parrot wrote:
>
> Lad, Prabhakar wrote on Mon [2019-Sep-16
> 09:00:03 +0100]:
> > Hi Benoit,
> >
> > Thank you for the patch.
> >
> > On Mon, Sep 9, 2019 at 5:26 PM Benoit Parrot wrote:
> > >
> > > Returning queued vb2 buffers back to user space is a common
> > > task best handled by a helper function.
> > >
> > > Signed-off-by: Benoit Parrot
> > > ---
> > > drivers/media/platform/am437x/am437x-vpfe.c | 54 ++---
> > > 1 file changed, 26 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
> > > b/drivers/media/platform/am437x/am437x-vpfe.c
> > > index 3a8ad9bdf283..52f7fc6e11dd 100644
> > > --- a/drivers/media/platform/am437x/am437x-vpfe.c
> > > +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> > > @@ -1949,6 +1949,29 @@ static void vpfe_buffer_queue(struct vb2_buffer
> > > *vb)
> > > spin_unlock_irqrestore(>dma_queue_lock, flags);
> > > }
> > >
> > > +static void vpfe_return_all_buffers(struct vpfe_device *vpfe,
> > > + enum vb2_buffer_state state)
> > > +{
> > > + struct vpfe_cap_buffer *buf, *node;
> > > + unsigned long flags;
> > > +
> > > + spin_lock_irqsave(>dma_queue_lock, flags);
> > > + list_for_each_entry_safe(buf, node, >dma_queue, list) {
> > > + vb2_buffer_done(>vb.vb2_buf, state);
> > > + list_del(>list);
> > > + }
> > > +
> > > + if (vpfe->cur_frm)
> > > + vb2_buffer_done(>cur_frm->vb.vb2_buf, state);
> > > +
> > > + if (vpfe->next_frm && vpfe->next_frm != vpfe->cur_frm)
> > > + vb2_buffer_done(>next_frm->vb.vb2_buf, state);
> > > +
> > > + vpfe->cur_frm = NULL;
> > > + vpfe->next_frm = NULL;
> > > + spin_unlock_irqrestore(>dma_queue_lock, flags);
> > > +}
> > > +
> > > /*
> > > * vpfe_start_streaming : Starts the DMA engine for streaming
> > > * @vb: ptr to vb2_buffer
> > > @@ -1957,7 +1980,6 @@ static void vpfe_buffer_queue(struct vb2_buffer *vb)
> > > static int vpfe_start_streaming(struct vb2_queue *vq, unsigned int count)
> > > {
> > > struct vpfe_device *vpfe = vb2_get_drv_priv(vq);
> > > - struct vpfe_cap_buffer *buf, *tmp;
> > > struct vpfe_subdev_info *sdinfo;
> > > unsigned long flags;
> > > unsigned long addr;
> > > @@ -2003,11 +2025,8 @@ static int vpfe_start_streaming(struct vb2_queue
> > > *vq, unsigned int count)
> > > return 0;
> > >
> > > err:
> > > - list_for_each_entry_safe(buf, tmp, >dma_queue, list) {
> > > - list_del(>list);
> > > - vb2_buffer_done(>vb.vb2_buf, VB2_BUF_STATE_QUEUED);
> > > - }
> > > -
> > > + vpfe_return_all_buffers(vpfe, VB2_BUF_STATE_QUEUED);
> > > + vpfe_pcr_enable(>ccdc, 0);
> >
> > please create a seperate patch for the above change.
>
> You mean a separate patch just for the vpfe_pcr_enable() call?
>
yes, as the call to vpfe_pcr_enable() is to disable the CCDC and it
doesn't match the patch
description.
Cheers,
--Prabhakar Lad
Re: linux-next: manual merge of the modules tree with the compiler-attributes tree
On Sun, Sep 15, 2019 at 11:27:20PM +0100, Mark Brown wrote: > Since this conflcit is non-trivial, it's late and there's a good chance > I'm not going to actually finish building -next today I've just used the > commit from the last time -next was built, 3b5be16c7e90a69c, for the > modules tree - sorry. I'll have another go tomorrow. This means none > of the changes in modules-next are in -next as they were all committed > in the past week. I had another look but I'm still not comfortable doing this merge in a sensible timeframe so I punted again, sorry. I'll probably carry on doing this. signature.asc Description: PGP signature
Re: [PATCH v3] mm/kasan: dump alloc and free stack for page allocator
On 9/16/19 12:42 PM, Vlastimil Babka wrote:
> On 9/12/19 7:05 PM, Andrey Ryabinin wrote:
>>
>> Or another alternative option (and actually easier one to implement), leave
>> PAGE_OWNER as is (no "select"s in Kconfigs)
>> Make PAGE_OWNER_FREE_STACK like this:
>>
>> +config PAGE_OWNER_FREE_STACK
>> +def_bool KASAN || DEBUG_PAGEALLOC
>> +depends on PAGE_OWNER
>> +
>>
>> So, users that want alloc/free stack will have to enable CONFIG_PAGE_OWNER=y
>> and add page_owner=on to boot cmdline.
>>
>>
>> Basically the difference between these alternative is whether we enable
>> page_owner by default or not. But there is always a possibility to disable
>> it.
>
> OK, how about this?
>
...
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c5d62f1c2851..d9e44671af3f 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -710,8 +710,12 @@ static int __init early_debug_pagealloc(char *buf)
> if (kstrtobool(buf, ))
> return -EINVAL;
>
> - if (enable)
> + if (enable) {
> static_branch_enable(&_debug_pagealloc_enabled);
> +#ifdef CONFIG_PAGE_OWNER
> + page_owner_free_stack_disabled = false;
I think this won't work with CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y
> +#endif
> + }
>
> return 0;
> }
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index dee931184788..b589bfbc4795 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -24,13 +24,15 @@ struct page_owner {
> short last_migrate_reason;
> gfp_t gfp_mask;
> depot_stack_handle_t handle;
> -#ifdef CONFIG_DEBUG_PAGEALLOC
> +#ifdef CONFIG_PAGE_OWNER_FREE_STACK
> depot_stack_handle_t free_handle;
> #endif
> };
>
> static bool page_owner_disabled = true;
> +bool page_owner_free_stack_disabled = true;
> DEFINE_STATIC_KEY_FALSE(page_owner_inited);
> +static DEFINE_STATIC_KEY_FALSE(page_owner_free_stack);
>
> static depot_stack_handle_t dummy_handle;
> static depot_stack_handle_t failure_handle;
> @@ -46,6 +48,9 @@ static int __init early_page_owner_param(char *buf)
> if (strcmp(buf, "on") == 0)
> page_owner_disabled = false;
>
> + if (!page_owner_disabled && IS_ENABLED(CONFIG_KASAN))
I'd rather keep all logic in one place, i.e. "if (!page_owner_disabled &&
(IS_ENABLED(CONFIG_KASAN) || debug_pagealloc_enabled())"
With this no changes in early_debug_pagealloc() required and
CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y should also work correctly.
> + page_owner_free_stack_disabled = false;
> +
> return 0;
> }
> early_param("page_owner", early_page_owner_param);
Re: [PATCH v5 7/7] mm, slab_common: Modify kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
On Mon, 16 Sep 2019, Pengfei Li wrote: > KMALLOC_NORMAL is the most frequently accessed, and kmalloc_caches[] > is initialized by different types of the same size. > > So modifying kmalloc_caches[type][idx] to kmalloc_caches[idx][type] > will benefit performance. Why would that increase performance? Using your scheme means that the KMALLOC_NORMAL pointers are spread over more cachelines. Since KMALLOC_NORMAL is most frequently accessed this would cause a performance regression.
Re: [PATCH 0/6] ARM, arm64: Remove arm_pm_restart()
On Mon, Sep 16, 2019 at 08:43:36AM -0700, Guenter Roeck wrote: > On Mon, Sep 16, 2019 at 03:49:20PM +0200, Thierry Reding wrote: > > On Mon, Sep 16, 2019 at 06:17:01AM -0700, Guenter Roeck wrote: > > > On 9/16/19 12:49 AM, Arnd Bergmann wrote: > > > > On Sat, Sep 14, 2019 at 5:26 PM Guenter Roeck > > > > wrote: > > > > > On Mon, Jan 30, 2017 at 12:05:06PM +0100, Thierry Reding wrote: > > > > > > From: Thierry Reding > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > This small series is preparatory work for a series that I'm working > > > > > > on > > > > > > which attempts to establish a formal framework for system restart > > > > > > and > > > > > > power off. > > > > > > > > > > > > Guenter has done a lot of good work in this area, but it never got > > > > > > merged. I think this set is a valuable addition to the kernel > > > > > > because > > > > > > it converts all odd providers to the established mechanism for > > > > > > restart. > > > > > > > > > > > > Since this is stretched across both 32-bit and 64-bit ARM, as well > > > > > > as > > > > > > PSCI, and given the SoC/board level of functionality, I think it > > > > > > might > > > > > > make sense to take this through the ARM SoC tree in order to > > > > > > simplify > > > > > > the interdependencies. But it should also be possible to take > > > > > > patches > > > > > > 1-4 via their respective trees this cycle and patches 5-6 through > > > > > > the > > > > > > ARM and arm64 trees for the next cycle, if that's preferred. > > > > > > > > > > > > > > > > We tried this twice now, and it seems to go nowhere. What does it take > > > > > to get it applied ? > > > > > > > > Can you send a pull request to s...@kernel.org after the merge window, > > > > with everyone else on Cc? If nobody objects, I'll merge it through > > > > the soc tree. > > > > > > > > > > Sure, I'll rebase and do that. > > > > I've uploaded a rebased tree here: > > > > https://github.com/thierryreding/linux/tree/for-5.5/system-power-reset > > > > The first 6 patches in that tree correspond to this series. There were a > > couple of conflicts I had to resolve and I haven't fully tested the > > series yet, but if you haven't done any of the rebasing, the above may > > be useful to you. > > > > Maybe Arnd can just use your branch (or rather part of it if you would > split it off) since you already did the work ? Yeah, I can just send the pull request for the 6 patches after -rc1. Thierry signature.asc Description: PGP signature
Re: [PATCH v3] usbip: vhci_hcd indicate failed message
On 9/16/19 9:09 AM, Mao Wenan wrote:
If the return value of vhci_init_attr_group and
sysfs_create_group is non-zero, which mean they failed
to init attr_group and create sysfs group, so it would
better add 'failed' message to indicate that.
This patch also change pr_err to dev_err to trace which
device is failed.
Fixes: 0775a9cbc694 ("usbip: vhci extension: modifications to vhci driver")
Signed-off-by: Mao Wenan
---
v2: change pr_err to dev_err.
v3: add error code in failed messages.
drivers/usb/usbip/vhci_hcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 000ab7225717..144507751eae 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1185,12 +1185,12 @@ static int vhci_start(struct usb_hcd *hcd)
if (id == 0 && usb_hcd_is_primary_hcd(hcd)) {
err = vhci_init_attr_group();
if (err) {
- pr_err("init attr group\n");
+ dev_err(hcd_dev(hcd), "init attr group failed, err =
%d\n", err);
return err;
}
err = sysfs_create_group(_dev(hcd)->kobj, _attr_group);
if (err) {
- pr_err("create sysfs files\n");
+ dev_err(hcd_dev(hcd), "create sysfs files failed, err =
%d\n", err);
vhci_finish_attr_group();
return err;
}
Looks good to me.
Acked-by: Shuah Khan
thanks,
-- Shuah
[PATCH v4 6/7] MAINTAINERS: Add entry for Actions Semi SD/MMC driver and binding
Add MAINTAINERS entry for Actions Semi SD/MMC driver with its binding. Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c31e6492b601..d13138330b97 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1375,6 +1375,7 @@ F:drivers/clk/actions/ F: drivers/clocksource/timer-owl* F: drivers/dma/owl-dma.c F: drivers/i2c/busses/i2c-owl.c +F: drivers/mmc/host/owl-mmc.c F: drivers/pinctrl/actions/* F: drivers/soc/actions/ F: include/dt-bindings/power/owl-* @@ -1383,6 +1384,7 @@ F: Documentation/devicetree/bindings/arm/actions.yaml F: Documentation/devicetree/bindings/clock/actions,owl-cmu.txt F: Documentation/devicetree/bindings/dma/owl-dma.txt F: Documentation/devicetree/bindings/i2c/i2c-owl.txt +F: Documentation/devicetree/bindings/mmc/owl-mmc.yaml F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt F: Documentation/devicetree/bindings/power/actions,owl-sps.txt F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt -- 2.17.1
[PATCH v4 5/7] mmc: Add Actions Semi Owl SoCs SD/MMC driver
Add SD/MMC driver for Actions Semi Owl SoCs. This driver currently supports standard, high speed, SDR12, SDR25 and SDR50. DDR50 mode is supported but it is untested. There is no SDIO support for now. Signed-off-by: Manivannan Sadhasivam --- drivers/mmc/host/Kconfig | 8 + drivers/mmc/host/Makefile | 1 + drivers/mmc/host/owl-mmc.c | 696 + 3 files changed, 705 insertions(+) create mode 100644 drivers/mmc/host/owl-mmc.c diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 14d89a108edd..2c38e36953af 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -1006,3 +1006,11 @@ config MMC_SDHCI_AM654 If you have a controller with this interface, say Y or M here. If unsure, say N. + +config MMC_OWL + tristate "Actions Semi Owl SD/MMC Host Controller support" + depends on HAS_DMA + depends on ARCH_ACTIONS || COMPILE_TEST + help + This selects support for the SD/MMC Host Controller on + Actions Semi Owl SoCs. diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile index 73578718f119..41a0b1728389 100644 --- a/drivers/mmc/host/Makefile +++ b/drivers/mmc/host/Makefile @@ -73,6 +73,7 @@ obj-$(CONFIG_MMC_SUNXI) += sunxi-mmc.o obj-$(CONFIG_MMC_USDHI6ROL0) += usdhi6rol0.o obj-$(CONFIG_MMC_TOSHIBA_PCI) += toshsd.o obj-$(CONFIG_MMC_BCM2835) += bcm2835.o +obj-$(CONFIG_MMC_OWL) += owl-mmc.o obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o diff --git a/drivers/mmc/host/owl-mmc.c b/drivers/mmc/host/owl-mmc.c new file mode 100644 index ..771e3d00f1bb --- /dev/null +++ b/drivers/mmc/host/owl-mmc.c @@ -0,0 +1,696 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Actions Semi Owl SoCs SD/MMC driver + * + * Copyright (c) 2014 Actions Semi Inc. + * Copyright (c) 2019 Manivannan Sadhasivam + * + * TODO: SDIO support + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * SDC registers + */ +#define OWL_REG_SD_EN 0x +#define OWL_REG_SD_CTL 0x0004 +#define OWL_REG_SD_STATE 0x0008 +#define OWL_REG_SD_CMD 0x000c +#define OWL_REG_SD_ARG 0x0010 +#define OWL_REG_SD_RSPBUF0 0x0014 +#define OWL_REG_SD_RSPBUF1 0x0018 +#define OWL_REG_SD_RSPBUF2 0x001c +#define OWL_REG_SD_RSPBUF3 0x0020 +#define OWL_REG_SD_RSPBUF4 0x0024 +#define OWL_REG_SD_DAT 0x0028 +#define OWL_REG_SD_BLK_SIZE0x002c +#define OWL_REG_SD_BLK_NUM 0x0030 +#define OWL_REG_SD_BUF_SIZE0x0034 + +/* SD_EN Bits */ +#define OWL_SD_EN_RANE BIT(31) +#define OWL_SD_EN_RAN_SEED(x) (((x) & 0x3f) << 24) +#define OWL_SD_EN_S18ENBIT(12) +#define OWL_SD_EN_RESE BIT(10) +#define OWL_SD_EN_DAT1_S BIT(9) +#define OWL_SD_EN_CLK_SBIT(8) +#define OWL_SD_ENABLE BIT(7) +#define OWL_SD_EN_BSEL BIT(6) +#define OWL_SD_EN_SDIOEN BIT(3) +#define OWL_SD_EN_DDRENBIT(2) +#define OWL_SD_EN_DATAWID(x) (((x) & 0x3) << 0) + +/* SD_CTL Bits */ +#define OWL_SD_CTL_TOUTEN BIT(31) +#define OWL_SD_CTL_TOUTCNT(x) (((x) & 0x7f) << 24) +#define OWL_SD_CTL_DELAY_MSK GENMASK(23, 16) +#define OWL_SD_CTL_RDELAY(x) (((x) & 0xf) << 20) +#define OWL_SD_CTL_WDELAY(x) (((x) & 0xf) << 16) +#define OWL_SD_CTL_CMDLEN BIT(13) +#define OWL_SD_CTL_SCC BIT(12) +#define OWL_SD_CTL_TCN(x) (((x) & 0xf) << 8) +#define OWL_SD_CTL_TS BIT(7) +#define OWL_SD_CTL_LBE BIT(6) +#define OWL_SD_CTL_C7ENBIT(5) +#define OWL_SD_CTL_TM(x) (((x) & 0xf) << 0) + +#define OWL_SD_DELAY_LOW_CLK 0x0f +#define OWL_SD_DELAY_MID_CLK 0x0a +#define OWL_SD_DELAY_HIGH_CLK 0x09 +#define OWL_SD_RDELAY_DDR500x0a +#define OWL_SD_WDELAY_DDR500x08 + +/* SD_STATE Bits */ +#define OWL_SD_STATE_DAT1BSBIT(18) +#define OWL_SD_STATE_SDIOB_P BIT(17) +#define OWL_SD_STATE_SDIOB_EN BIT(16) +#define OWL_SD_STATE_TOUTE BIT(15) +#define OWL_SD_STATE_BAEP BIT(14) +#define OWL_SD_STATE_MEMRDYBIT(12) +#define OWL_SD_STATE_CMDS BIT(11) +#define OWL_SD_STATE_DAT1ASBIT(10) +#define OWL_SD_STATE_SDIOA_P BIT(9) +#define OWL_SD_STATE_SDIOA_EN BIT(8) +#define OWL_SD_STATE_DAT0S BIT(7) +#define OWL_SD_STATE_TEIE BIT(6) +#define OWL_SD_STATE_TEI BIT(5) +#define OWL_SD_STATE_CLNR BIT(4) +#define
[PATCH v4 7/7] arm64: configs: Enable Actions Semi platform in defconfig
Since the Actions Semi platform can now boot a distro, enable it in ARM64 defconfig. Signed-off-by: Manivannan Sadhasivam --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 0e58ef02880c..8e2d6687 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -29,6 +29,7 @@ CONFIG_BLK_DEV_INITRD=y CONFIG_KALLSYMS_ALL=y # CONFIG_COMPAT_BRK is not set CONFIG_PROFILING=y +CONFIG_ARCH_ACTIONS=y CONFIG_ARCH_AGILEX=y CONFIG_ARCH_SUNXI=y CONFIG_ARCH_ALPINE=y -- 2.17.1
[PATCH v4 3/7] arm64: dts: actions: Add MMC controller support for S900
Add MMC controller support for Actions Semi S900 SoC. There are 4 MMC
controllers in this SoC which can be used for accessing SD/MMC/SDIO cards.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 45 +++
1 file changed, 45 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index df3a68a3ac97..eb35cf78ab73 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
@@ -284,5 +285,49 @@
dma-requests = <46>;
clocks = < CLK_DMAC>;
};
+
+ mmc0: mmc@e033 {
+ compatible = "actions,owl-mmc";
+ reg = <0x0 0xe033 0x0 0x4000>;
+ interrupts = ;
+ clocks = < CLK_SD0>;
+ resets = < RESET_SD0>;
+ dmas = < 2>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc1: mmc@e0334000 {
+ compatible = "actions,owl-mmc";
+ reg = <0x0 0xe0334000 0x0 0x4000>;
+ interrupts = ;
+ clocks = < CLK_SD1>;
+ resets = < RESET_SD1>;
+ dmas = < 3>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc2: mmc@e0338000 {
+ compatible = "actions,owl-mmc";
+ reg = <0x0 0xe0338000 0x0 0x4000>;
+ interrupts = ;
+ clocks = < CLK_SD2>;
+ resets = < RESET_SD2>;
+ dmas = < 4>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc3: mmc@e033c000 {
+ compatible = "actions,owl-mmc";
+ reg = <0x0 0xe033c000 0x0 0x4000>;
+ interrupts = ;
+ clocks = < CLK_SD3>;
+ resets = < RESET_SD3>;
+ dmas = < 46>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
};
};
--
2.17.1
[PATCH v4 4/7] arm64: dts: actions: Add uSD and eMMC support for Bubblegum96
Add uSD and eMMC support for Bubblegum96 board based on Actions Semi
S900 SoC. SD0 is connected to uSD slot and SD2 is connected to eMMC.
Since there is no PMIC support added yet, fixed regulator has been
used as a regulator node.
Signed-off-by: Manivannan Sadhasivam
---
.../boot/dts/actions/s900-bubblegum-96.dts| 62 +++
1 file changed, 62 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
index 732daaa6e9d3..59291e0ea1ee 100644
--- a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
+++ b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
@@ -12,6 +12,9 @@
model = "Bubblegum-96";
aliases {
+ mmc0 =
+ mmc1 =
+ mmc2 =
serial5 =
};
@@ -23,6 +26,24 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>;
};
+
+ /* Fixed regulator used in the absence of PMIC */
+ vcc_3v1: vcc-3v1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <310>;
+ regulator-max-microvolt = <310>;
+ regulator-always-on;
+ };
+
+ /* Fixed regulator used in the absence of PMIC */
+ sd_vcc: sd-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <310>;
+ regulator-max-microvolt = <310>;
+ regulator-always-on;
+ };
};
{
@@ -241,6 +262,47 @@
bias-pull-up;
};
};
+
+ mmc0_default: mmc0_default {
+ pinmux {
+ groups = "sd0_d0_mfp", "sd0_d1_mfp", "sd0_d2_d3_mfp",
+"sd0_cmd_mfp", "sd0_clk_mfp";
+ function = "sd0";
+ };
+ };
+
+ mmc2_default: mmc2_default {
+ pinmux {
+ groups = "nand0_d0_ceb3_mfp";
+ function = "sd2";
+ };
+ };
+};
+
+/* uSD */
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+ no-sdio;
+ no-mmc;
+ no-1-8-v;
+ cd-gpios = < 120 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ vmmc-supply = <_vcc>;
+ vqmmc-supply = <_vcc>;
+};
+
+/* eMMC */
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+ no-sdio;
+ no-sd;
+ non-removable;
+ bus-width = <8>;
+ vmmc-supply = <_3v1>;
};
{
--
2.17.1
[PATCH v4 2/7] dt-bindings: mmc: Add Actions Semi SD/MMC/SDIO controller binding
Add devicetree YAML binding for Actions Semi Owl SoC's SD/MMC/SDIO
controller.
Signed-off-by: Manivannan Sadhasivam
---
.../devicetree/bindings/mmc/owl-mmc.yaml | 59 +++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/owl-mmc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
new file mode 100644
index ..12b40213426d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/owl-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl SoCs SD/MMC/SDIO controller
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+maintainers:
+ - Manivannan Sadhasivam
+
+properties:
+ compatible:
+const: actions,owl-mmc
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+minItems: 1
+
+ resets:
+maxItems: 1
+
+ dmas:
+maxItems: 1
+
+ dma-names:
+const: mmc
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - dmas
+ - dma-names
+
+examples:
+ - |
+mmc0: mmc@e033 {
+compatible = "actions,owl-mmc";
+reg = <0x0 0xe033 0x0 0x4000>;
+interrupts = <0 42 4>;
+clocks = < 56>;
+resets = < 23>;
+dmas = < 2>;
+dma-names = "mmc";
+bus-width = <4>;
+};
+
+...
--
2.17.1
[PATCH v4 1/7] clk: actions: Fix factor clk struct member access
Since the helper "owl_factor_helper_round_rate" is shared between factor
and composite clocks, using the factor clk specific helper function
like "hw_to_owl_factor" to access its members will create issues when
called from composite clk specific code. Hence, pass the "factor_hw"
struct pointer directly instead of fetching it using factor clk specific
helpers.
This issue has been observed when a composite clock like "sd0_clk" tried
to call "owl_factor_helper_round_rate" resulting in pointer dereferencing
error.
While we are at it, let's rename the "clk_val_best" function to
"owl_clk_val_best" since this is an owl SoCs specific helper.
Fixes: 4bb78fc9744a ("clk: actions: Add factor clock support")
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Stephen Boyd
---
drivers/clk/actions/owl-factor.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/actions/owl-factor.c b/drivers/clk/actions/owl-factor.c
index 317d4a9e112e..f15e2621fa18 100644
--- a/drivers/clk/actions/owl-factor.c
+++ b/drivers/clk/actions/owl-factor.c
@@ -64,11 +64,10 @@ static unsigned int _get_table_val(const struct
clk_factor_table *table,
return val;
}
-static int clk_val_best(struct clk_hw *hw, unsigned long rate,
+static int owl_clk_val_best(const struct owl_factor_hw *factor_hw,
+ struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate)
{
- struct owl_factor *factor = hw_to_owl_factor(hw);
- struct owl_factor_hw *factor_hw = >factor_hw;
const struct clk_factor_table *clkt = factor_hw->table;
unsigned long parent_rate, try_parent_rate, best = 0, cur_rate;
unsigned long parent_rate_saved = *best_parent_rate;
@@ -126,7 +125,7 @@ long owl_factor_helper_round_rate(struct owl_clk_common
*common,
const struct clk_factor_table *clkt = factor_hw->table;
unsigned int val, mul = 0, div = 1;
- val = clk_val_best(>hw, rate, parent_rate);
+ val = owl_clk_val_best(factor_hw, >hw, rate, parent_rate);
_get_table_div_mul(clkt, val, , );
return *parent_rate * mul / div;
--
2.17.1
[PATCH v4 0/7] Add SD/MMC driver for Actions Semi S900 SoC
Hello, This patchset adds SD/MMC driver for Actions Semi S900 SoC from Owl family SoCs. There are 4 SD/MMC controller present in this SoC but only 2 are enabled currently for Bubblegum96 board to access uSD and onboard eMMC. SDIO support for this driver is not currently implemented. Note: Currently, driver uses 2 completion mechanisms for maintaining the coherency between SDC and DMA interrupts and I know that it is not efficient. Hence, I'd like to hear any suggestions for reimplementing the logic if anyone has. With this driver, this patchset also fixes one clk driver issue and enables the Actions Semi platform in ARM64 defconfig. Thanks, Mani Changes in v4: * Incorporated review comments from Rob on dt binding Changes in v3: * Incorporated a review comment from Andreas on board dts patch * Modified the MAINTAINERS entry for devicetree YAML binding Changes in v2: * Converted the devicetree bindings to YAML * Misc changes to bubblegum devicetree as per the review from Andreas * Dropped the read/write wrappers and renamed all functions to use owl- prefix as per the review from Ulf * Renamed clk_val_best to owl_clk_val_best and added Reviewed-by tag from Stephen Manivannan Sadhasivam (7): clk: actions: Fix factor clk struct member access dt-bindings: mmc: Add Actions Semi SD/MMC/SDIO controller binding arm64: dts: actions: Add MMC controller support for S900 arm64: dts: actions: Add uSD and eMMC support for Bubblegum96 mmc: Add Actions Semi Owl SoCs SD/MMC driver MAINTAINERS: Add entry for Actions Semi SD/MMC driver and binding arm64: configs: Enable Actions Semi platform in defconfig .../devicetree/bindings/mmc/owl-mmc.yaml | 59 ++ MAINTAINERS | 2 + .../boot/dts/actions/s900-bubblegum-96.dts| 62 ++ arch/arm64/boot/dts/actions/s900.dtsi | 45 ++ arch/arm64/configs/defconfig | 1 + drivers/clk/actions/owl-factor.c | 7 +- drivers/mmc/host/Kconfig | 8 + drivers/mmc/host/Makefile | 1 + drivers/mmc/host/owl-mmc.c| 696 ++ 9 files changed, 877 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/owl-mmc.yaml create mode 100644 drivers/mmc/host/owl-mmc.c -- 2.17.1
Re: [PATCH 0/6] ARM, arm64: Remove arm_pm_restart()
On Mon, Sep 16, 2019 at 03:49:20PM +0200, Thierry Reding wrote: > On Mon, Sep 16, 2019 at 06:17:01AM -0700, Guenter Roeck wrote: > > On 9/16/19 12:49 AM, Arnd Bergmann wrote: > > > On Sat, Sep 14, 2019 at 5:26 PM Guenter Roeck wrote: > > > > On Mon, Jan 30, 2017 at 12:05:06PM +0100, Thierry Reding wrote: > > > > > From: Thierry Reding > > > > > > > > > > Hi everyone, > > > > > > > > > > This small series is preparatory work for a series that I'm working on > > > > > which attempts to establish a formal framework for system restart and > > > > > power off. > > > > > > > > > > Guenter has done a lot of good work in this area, but it never got > > > > > merged. I think this set is a valuable addition to the kernel because > > > > > it converts all odd providers to the established mechanism for > > > > > restart. > > > > > > > > > > Since this is stretched across both 32-bit and 64-bit ARM, as well as > > > > > PSCI, and given the SoC/board level of functionality, I think it might > > > > > make sense to take this through the ARM SoC tree in order to simplify > > > > > the interdependencies. But it should also be possible to take patches > > > > > 1-4 via their respective trees this cycle and patches 5-6 through the > > > > > ARM and arm64 trees for the next cycle, if that's preferred. > > > > > > > > > > > > > We tried this twice now, and it seems to go nowhere. What does it take > > > > to get it applied ? > > > > > > Can you send a pull request to s...@kernel.org after the merge window, > > > with everyone else on Cc? If nobody objects, I'll merge it through > > > the soc tree. > > > > > > > Sure, I'll rebase and do that. > > I've uploaded a rebased tree here: > > https://github.com/thierryreding/linux/tree/for-5.5/system-power-reset > > The first 6 patches in that tree correspond to this series. There were a > couple of conflicts I had to resolve and I haven't fully tested the > series yet, but if you haven't done any of the rebasing, the above may > be useful to you. > Maybe Arnd can just use your branch (or rather part of it if you would split it off) since you already did the work ? Thanks, Guenter
[PATCH] mm/memcontrol: fix a -Wunused-function warning
mem_cgroup_id_get() was introduced in the commit 73f576c04b94
("mm:memcontrol: fix cgroup creation failure after many small jobs").
Later, it no longer has any user since the commits,
1f47b61fb407 ("mm: memcontrol: fix swap counter leak on swapout from offline
cgroup")
58fa2a5512d9 ("mm: memcontrol: add sanity checks for memcg->id.ref on get/put")
so safe to remove it.
Signed-off-by: Qian Cai
---
mm/memcontrol.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 9ec5e12486a7..9a375b376157 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4675,11 +4675,6 @@ static void mem_cgroup_id_put_many(struct mem_cgroup
*memcg, unsigned int n)
}
}
-static inline void mem_cgroup_id_get(struct mem_cgroup *memcg)
-{
- mem_cgroup_id_get_many(memcg, 1);
-}
-
static inline void mem_cgroup_id_put(struct mem_cgroup *memcg)
{
mem_cgroup_id_put_many(memcg, 1);
--
1.8.3.1
Re: [PATCH] locking: locktorture: Do not include rwlock.h directly
On Mon, Sep 16, 2019 at 04:54:04PM +0200, Sebastian Andrzej Siewior wrote: > From: Wolfgang M. Reimer > > Including rwlock.h directly will cause kernel builds to fail > if CONFIG_PREEMPT_RT is defined. The correct header file > (rwlock_rt.h OR rwlock.h) will be included by spinlock.h which > is included by locktorture.c anyway. > > Remove the include of linux/rwlock.h. > > Signed-off-by: Wolfgang M. Reimer > Signed-off-by: Sebastian Andrzej Siewior Queued for further review and testing, thank you both! Thanx, Paul > --- > kernel/locking/locktorture.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c > index c513031cd7e33..9fb042d610d23 100644 > --- a/kernel/locking/locktorture.c > +++ b/kernel/locking/locktorture.c > @@ -16,7 +16,6 @@ > #include > #include > #include > -#include > #include > #include > #include > -- > 2.23.0 >
[GIT PULL] cgroup changes for v5.4-rc1
Hello, Linus. Three minor cleanup patches. Thanks. The following changes since commit ad5e427e0f6b702e52c11d1f7b2b7be3bac7de82: Merge branch 'parisc-5.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux (2019-07-23 15:34:59 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-5.4 for you to fetch changes up to 653a23ca7e1e1ae907654e91d028bc6dfc7fce0c: Use kvmalloc in cgroups-v1 (2019-08-07 11:37:58 -0700) Marc Koderer (1): Use kvmalloc in cgroups-v1 Markus Elfring (1): cgroup: Replace a seq_printf() call by seq_puts() in cgroup_print_ss_mask() Peng Wang (1): cgroup: minor tweak for logic to get cgroup css kernel/cgroup/cgroup-v1.c | 27 --- kernel/cgroup/cgroup.c| 4 ++-- 2 files changed, 6 insertions(+), 25 deletions(-) -- tejun
Re: INFO: rcu detected stall in dummy_timer
On Fri, Sep 13, 2019 at 10:35 PM Alan Stern wrote: > > On Fri, 13 Sep 2019, syzbot wrote: > > > syzbot has found a reproducer for the following crash on: > > > > HEAD commit:f0df5c1b usb-fuzzer: main usb gadget fuzzer driver > > git tree: https://github.com/google/kasan.git usb-fuzzer > > console output: https://syzkaller.appspot.com/x/log.txt?x=1146550d60 > > kernel config: https://syzkaller.appspot.com/x/.config?x=5c6633fa4ed00be5 > > dashboard link: https://syzkaller.appspot.com/bug?extid=b24d736f18a1541ad550 > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11203fa560 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=162cd33560 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+b24d736f18a1541ad...@syzkaller.appspotmail.com > > > > yurex 3-1:0.101: yurex_interrupt - unknown status received: -71 > > yurex 5-1:0.101: yurex_interrupt - unknown status received: -71 > > yurex 6-1:0.101: yurex_interrupt - unknown status received: -71 > > rcu: INFO: rcu_sched self-detected stall on CPU > > Andrey: > > This problem may be a result of overloading dummy_timer. The kernel > config you are using has CONFIG_HZ=100, but dummy-hcd needs > CONFIG_HZ=1000 (see the comment on line 1789). That is, lower values > of HZ will occasionally lead to trouble, and this may be an example. > > Can you change the config value for HZ and see if the bug still > reproduces? Hi Alan, I've tried running the reproducer with CONFIG_HZ=1000 and still got the same stall message. It's accompanied by countless "yurex 6-1:0.101: yurex_interrupt - unknown status received: -71" messages, so I believe this is an issue in the yurex driver. Why does dumy_hcd require CONFIG_HZ=1000? The comment doesn't really explain the reason. Thanks!
[tip: x86/mm] x86/cpu: Clean up intel_tlb_table[]
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 77df779de742d6616d4ddd177cba152a75259104
Gitweb:
https://git.kernel.org/tip/77df779de742d6616d4ddd177cba152a75259104
Author:Sylvain 'ythier' Hitier
AuthorDate:Sun, 15 Sep 2019 11:09:25 +02:00
Committer: Ingo Molnar
CommitterDate: Mon, 16 Sep 2019 17:23:46 +02:00
x86/cpu: Clean up intel_tlb_table[]
- Remove the unneeded backslash at EOL: that's not a macro.
And let's please checkpatch by aligning to open parenthesis.
- For 0x4f descriptor, remove " */" from the info field.
- For 0xc2 descriptor, sync the beginning of info to match the tlb_type.
(The value of info fields could be made more regular, but it's unused by
the code and will be read only by developers, so don't bother.)
Signed-off-by: Sylvain 'ythier' Hitier
Cc: Alex Shi
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: H. Peter Anvin
Cc: Hans de Goede
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Ricardo Neri
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: triv...@kernel.org
Link: https://lkml.kernel.org/r/20190915090917.GA5086@lilas
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/cpu/intel.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 8d6d92e..24e619d 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -813,7 +813,7 @@ static const struct _tlb_table intel_tlb_table[] = {
{ 0x04, TLB_DATA_4M,8, " TLB_DATA 4 MByte pages, 4-way
set associative" },
{ 0x05, TLB_DATA_4M,32, " TLB_DATA 4 MByte pages, 4-way
set associative" },
{ 0x0b, TLB_INST_4M,4, " TLB_INST 4 MByte pages, 4-way
set associative" },
- { 0x4f, TLB_INST_4K,32, " TLB_INST 4 KByte pages */" },
+ { 0x4f, TLB_INST_4K,32, " TLB_INST 4 KByte pages" },
{ 0x50, TLB_INST_ALL, 64, " TLB_INST 4 KByte and 2-MByte
or 4-MByte pages" },
{ 0x51, TLB_INST_ALL, 128," TLB_INST 4 KByte and 2-MByte
or 4-MByte pages" },
{ 0x52, TLB_INST_ALL, 256," TLB_INST 4 KByte and 2-MByte
or 4-MByte pages" },
@@ -841,7 +841,7 @@ static const struct _tlb_table intel_tlb_table[] = {
{ 0xba, TLB_DATA_4K,64, " TLB_DATA 4 KByte pages, 4-way
associative" },
{ 0xc0, TLB_DATA_4K_4M, 8, " TLB_DATA 4 KByte and 4 MByte
pages, 4-way associative" },
{ 0xc1, STLB_4K_2M, 1024, " STLB 4 KByte and 2 MByte
pages, 8-way associative" },
- { 0xc2, TLB_DATA_2M_4M, 16, " DTLB 2 MByte/4MByte pages,
4-way associative" },
+ { 0xc2, TLB_DATA_2M_4M, 16, " TLB_DATA 2 MByte/4MByte
pages, 4-way associative" },
{ 0xca, STLB_4K,512," STLB 4 KByte pages, 4-way
associative" },
{ 0x00, 0, 0 }
};
@@ -853,8 +853,8 @@ static void intel_tlb_lookup(const unsigned char desc)
return;
/* look up this descriptor in the table */
- for (k = 0; intel_tlb_table[k].descriptor != desc && \
- intel_tlb_table[k].descriptor != 0; k++)
+ for (k = 0; intel_tlb_table[k].descriptor != desc &&
+intel_tlb_table[k].descriptor != 0; k++)
;
if (intel_tlb_table[k].tlb_type == 0)
Re: [PATCH] arm64: psci: Use udelay() instead of msleep() to reduce waiting time
On 2019/9/12 16:48, David Laight wrote:
> From: Yunfeng Ye
>> Sent: 11 September 2019 09:50
>> We want to reduce the time of cpu_down() for saving power, found that
>> cpu_psci_cpu_kill() cost 10ms after psci_ops.affinity_info() fail.
>>
>> Normally the time cpu dead is very short, it is no need to wait 10ms.
>> so use udelay 10us to instead msleep 10ms in every waiting loop, and add
>> cond_resched() to give a chance to run a higher-priority process.
>>
>> Signed-off-by: Yunfeng Ye
>> ---
>> arch/arm64/kernel/psci.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
>> index 85ee7d0..9e9d8a6 100644
>> --- a/arch/arm64/kernel/psci.c
>> +++ b/arch/arm64/kernel/psci.c
>> @@ -86,15 +86,15 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
>> * while it is dying. So, try again a few times.
>> */
>>
>> -for (i = 0; i < 10; i++) {
>> +for (i = 0; i < 1; i++) {
>> err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
>> if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
>> pr_info("CPU%d killed.\n", cpu);
>> return 0;
>> }
>>
>> -msleep(10);
>> -pr_info("Retrying again to check for CPU kill\n");
>> +cond_resched();
>> +udelay(10);
>
> You really don't want to be doing 1 udelay(10) before giving up.
>
> If udelay(10) is long enough for the normal case, then do that once.
> After that use usleep_range().
> > David
>
Thanks for your advice. the delay depend on the num of cores, range
from 50us to 500us, I have test the time on the 140+ cores cpu：
(10us every time)
[ 1177.979642] psci: CPU1 killed. total wait 4 times
[ 1178.011369] psci: CPU2 killed. total wait 6 times
[ 1178.035247] psci: CPU3 killed. total wait 3 times
[ 1178.071134] psci: CPU4 killed. total wait 8 times
..
[ 1190.128202] psci: CPU139 killed. total wait 50 times
[ 1190.156266] psci: CPU140 killed. total wait 48 times
[ 1190.192082] psci: CPU141 killed. total wait 46 times
[ 1190.224104] psci: CPU142 killed. total wait 46 times
Can I bust-wait 1ms，which is 100 tiems udelay(10), after that, use
usleep_range(1000, 1) ? I don't want other process occupy cpu
for a long time when I let out the cpu. thanks.
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>
Re: [PATCH v3] mm: memory: fix /proc/meminfo reporting for MLOCK_ONFAULT
On Fri, Sep 13, 2019 at 02:11:19PM -0700, Lucian Adrian Grijincu wrote:
> As pages are faulted in MLOCK_ONFAULT correctly updates
> /proc/self/smaps, but doesn't update /proc/meminfo's Mlocked field.
I don't think there's something wrong with this behaviour. It is okay to
keep the page an evictable LRU list (and not account it to NR_MLOCKED).
Some pages, like partly mapped THP will never be on unevictable LRU,
others will be found by vmscan later.
So, it's not bug per se.
Said that, we probably should try to put pages on unevictable LRU sooner
rather than later.
>
> - Before this /proc/meminfo fields didn't change as pages were faulted in:
>
> = Start =
> /proc/meminfo
> Unevictable: 10128 kB
> Mlocked: 10132 kB
> = Creating testfile =
>
> = after mlock2(MLOCK_ONFAULT) =
> /proc/meminfo
> Unevictable: 10128 kB
> Mlocked: 10132 kB
> /proc/self/smaps
> 7f871400-7f875400 rw-s 08:04 50857050 /root/testfile
> Locked:0 kB
>
> = after reading half of the file =
> /proc/meminfo
> Unevictable: 10128 kB
> Mlocked: 10132 kB
> /proc/self/smaps
> 7f871400-7f875400 rw-s 08:04 50857050 /root/testfile
> Locked: 524288 kB
>
> = after reading the entire the file =
> /proc/meminfo
> Unevictable: 10128 kB
> Mlocked: 10132 kB
> /proc/self/smaps
> 7f871400-7f875400 rw-s 08:04 50857050 /root/testfile
> Locked: 1048576 kB
>
> = after munmap =
> /proc/meminfo
> Unevictable: 10128 kB
> Mlocked: 10132 kB
> /proc/self/smaps
>
> - After: /proc/meminfo fields are properly updated as pages are touched:
>
> = Start =
> /proc/meminfo
> Unevictable: 60 kB
> Mlocked: 60 kB
> = Creating testfile =
>
> = after mlock2(MLOCK_ONFAULT) =
> /proc/meminfo
> Unevictable: 60 kB
> Mlocked: 60 kB
> /proc/self/smaps
> 7f2b9c60-7f2bdc60 rw-s 08:04 63045798 /root/testfile
> Locked:0 kB
>
> = after reading half of the file =
> /proc/meminfo
> Unevictable: 524220 kB
> Mlocked: 524220 kB
> /proc/self/smaps
> 7f2b9c60-7f2bdc60 rw-s 08:04 63045798 /root/testfile
> Locked: 524288 kB
>
> = after reading the entire the file =
> /proc/meminfo
> Unevictable: 1048496 kB
> Mlocked: 1048508 kB
> /proc/self/smaps
> 7f2b9c60-7f2bdc60 rw-s 08:04 63045798 /root/testfile
> Locked: 1048576 kB
>
> = after munmap =
> /proc/meminfo
> Unevictable: 176 kB
> Mlocked: 60 kB
> /proc/self/smaps
>
> Repro code.
> ---
>
> int mlock2wrap(const void* addr, size_t len, int flags) {
> return syscall(SYS_mlock2, addr, len, flags);
> }
>
> void smaps() {
> char smapscmd[1000];
> snprintf(
> smapscmd,
> sizeof(smapscmd) - 1,
> "grep testfile -A 20 /proc/%d/smaps | grep -E '(testfile|Locked)'",
> getpid());
> printf("/proc/self/smaps\n");
> fflush(stdout);
> system(smapscmd);
> }
>
> void meminfo() {
> const char* meminfocmd = "grep -E '(Mlocked|Unevictable)' /proc/meminfo";
> printf("/proc/meminfo\n");
> fflush(stdout);
> system(meminfocmd);
> }
>
> { \
> int rc = (call);\
> if (rc != 0) { \
> printf("error %d %s\n", rc, strerror(errno)); \
> exit(1); \
> } \
> }
> int main(int argc, char* argv[]) {
> printf("= Start =\n");
> meminfo();
>
> printf("= Creating testfile =\n");
> size_t size = 1 << 30; // 1 GiB
> int fd = open("testfile", O_CREAT | O_RDWR, 0666);
> {
> void* buf = malloc(size);
> write(fd, buf, size);
> free(buf);
> }
> int ret = 0;
> void* addr = NULL;
> addr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
>
> if (argc > 1) {
> PCHECK(mlock2wrap(addr, size, MLOCK_ONFAULT));
> printf("= after mlock2(MLOCK_ONFAULT) =\n");
> meminfo();
> smaps();
>
> for (size_t i = 0; i < size / 2; i += 4096) {
> ret += ((char*)addr)[i];
> }
> printf("= after reading half of the file =\n");
> meminfo();
> smaps();
>
> for (size_t i = 0; i < size; i += 4096) {
> ret += ((char*)addr)[i];
> }
> printf("= after reading the entire the file =\n");
> meminfo();
> smaps();
>
> } else {
> PCHECK(mlock(addr, size));
> printf("= after mlock =\n");
> meminfo();
> smaps();
> }
>
> PCHECK(munmap(addr, size));
> printf("= after munmap =\n");
> meminfo();
> smaps();
>
> return ret;
> }
>
> ---
>
> Signed-off-by: Lucian Adrian Grijincu
> Acked-by: Souptick Joarder
> ---
> mm/memory.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index e0c232fe81d9..55da24f33bc4 100644
> ---
Re: Documentation for plain accesses and data races
On Mon, 16 Sep 2019, Boqun Feng wrote: > > In other words, we can define ->vis as: > > > > let vis = prop ; ((strong-fence ; [Marked] ; xbstar) | (xbstar & int)) > > > > Hmm.. so the problem with this approach is that the (xbstar & int) part > doesn't satisfy the requirement of visibility... i.e. > > X ->prop Z ->(xbstar & int) Y > > may not guarantee when Y executes, X is already propagated to Y's CPU. Yes, it doesn't guarantee this. But the reason it doesn't guarantee this is because of the prop. The (xbstar & int) part is okay. In other words, if Z ->(xbstar & int) Y then it is certainly true that any store propagating to Z's CPU before Z executes also propagates to Y's CPU (which is the same one) before Y executes. Alan
Re: [PATCH 2/9] perf/core: Add PERF_SAMPLE_CGROUP feature
Hello, Song. On Sat, Sep 14, 2019 at 03:02:51PM +0100, Song Liu wrote: > I think we don't need a perfect identifier in this case. IIUC, the goal of I really don't want different versions of imperfect identifiers proliferating. > this patchset is to map each sample with a cgroup name (or full path). > To achieve this, we need > > 1. PERF_RECORD_CGROUP, that maps >"64-bit number" => cgroup name/path > 2. PERF_SAMPLE_CGROUP, that adds "64-bit number" to each sample. > > I call the id a "64-bit number" because it is not required to be a globally > unique id. As long as it is consistent within the same perf-record session, > we won't get any confusion. Since we add PERF_RECORD_CGROUP > for each cgroup creation, we will map most of samples correctly even > when the "64-bit number" is recycled within the same perf-record session. > > At the moment, I think ino is good enough for the "64-bit number" even > for 32-bit systems. If we don't call it "ino" (just call it "cgroup_tag" or > "cgroup_id", we can change it when kernfs provides a better 64-bit id. So, a firm nack on this direction. > About full path name: The user names the full path here. If the user gives > two different workloads the same name/path, we really cannot change that. > Reasonable users would be able to make sense from the full path. I don't see why we wanna be causing this avoidable problem to users. Thanks. -- tejun
Re: Documentation for plain accesses and data races
On Mon, 16 Sep 2019, Boqun Feng wrote: > > executes if Y is a store.) This is expressed by the visibility > > relation (vis), where X ->vis Y is defined to hold if there is an > > intermediate event Z such that: > > > > X is connected to Z by a possibly empty sequence of > > cumul-fence links followed by an optional rfe link (if none of > > these links are present, X and Z are the same event), > > > > I wonder whehter we could add an optional ->coe or ->fre between X and > the possibly empty sequence of cumul-fence, smiliar to the definition > of ->prop. This makes sense because if we have > > X ->coe X' (and X' in on CPU C) > > , X must be already propagated to C before X' executed, according to our > operation model: > > "... In particular, it must arrange for the store to be co-later than > (i.e., to overwrite) any other store to the same location which has > already propagated to CPU C." You have misinterpreted the text. The operational model says that if X propagates to CPU C before X' executes then X ->coe X'. It does _not_ say that if X ->coe X' then X propagates to CPU C before X' executes. > In other words, we can define ->vis as: > > let vis = prop ; ((strong-fence ; [Marked] ; xbstar) | (xbstar & int)) > > , and for this document, reference the "prop" section in > explanation.txt. This could make the model simple (both for description > and explanation), and one better thing is that we won't need commit in > Paul's dev branch: > > c683f2c807d2 "tools/memory-model: Fix data race detection for unordered > store and load" > > , and data race rules will look more symmetrical ;-) > > Thoughts? Or am I missing something subtle here? See above. Alan
[GIT PULL] RISC-V updates for v5.4-rc1
Linus,
The following changes since commit a256f2e329df0773022d28df2c3d206b9aaf1e61:
RISC-V: Fix FIXMAP area corruption on RV32 systems (2019-08-28 15:30:12 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
tags/riscv/for-v5.4-rc1
for you to fetch changes up to 9ce06497c2722a0f9109e4cc3ce35b7a69617886:
irqchip/sifive-plic: set max threshold for ignored handlers (2019-09-05
01:59:55 -0700)
RISC-V updates for v5.4-rc1
Add the following new features:
- Generic CPU topology description support for DT-based platforms,
including ARM64, ARM and RISC-V.
- Sparsemem support
- Perf callchain support
- SiFive PLIC irqchip modifications, in preparation for M-mode Linux
and clean up the code base:
- Clean up chip-specific register (CSR) manipulation code, IPIs, TLB
flushing, and the RISC-V CPU-local timer code
- Kbuild cleanup from one of the Kbuild maintainers
Atish Patra (4):
dt-binding: cpu-topology: Move cpu-map to a common binding.
cpu-topology: Move cpu topology code to common code.
arm: Use common cpu_topology structure and functions.
RISC-V: Parse cpu topology during boot.
Bin Meng (1):
riscv: Using CSR numbers to access CSRs
Christoph Hellwig (7):
riscv: refactor the IPI code
riscv: cleanup send_ipi_mask
riscv: optimize send_ipi_single
riscv: cleanup riscv_cpuid_to_hartid_mask
riscv: don't use the rdtime(h) pseudo-instructions
riscv: move the TLB flush logic out of line
irqchip/sifive-plic: set max threshold for ignored handlers
Logan Gunthorpe (1):
RISC-V: Implement sparsemem
Mao Han (3):
riscv: Add perf callchain support
riscv: Add support for perf registers sampling
riscv: Add support for libdw
Masahiro Yamada (1):
riscv: add arch/riscv/Kbuild
Paul Walmsley (1):
Merge tag 'common/for-v5.4-rc1/cpu-topology' into for-v5.4-rc1-branch
Sudeep Holla (3):
Documentation: DT: arm: add support for sockets defining package
boundaries
base: arch_topology: update Kconfig help description
MAINTAINERS: Add an entry for generic architecture topology
.../{arm/topology.txt => cpu/cpu-topology.txt} | 256 +++--
MAINTAINERS| 7 +
arch/arm/include/asm/topology.h| 20 --
arch/arm/kernel/topology.c | 60 +---
arch/arm64/include/asm/topology.h | 23 --
arch/arm64/kernel/topology.c | 303 +
arch/riscv/Kbuild | 3 +
arch/riscv/Kconfig | 24 ++
arch/riscv/Makefile| 5 +-
arch/riscv/include/asm/page.h | 2 +
arch/riscv/include/asm/pgtable.h | 13 +
arch/riscv/include/asm/smp.h | 6 -
arch/riscv/include/asm/sparsemem.h | 11 +
arch/riscv/include/asm/timex.h | 44 ++-
arch/riscv/include/asm/tlbflush.h | 38 +--
arch/riscv/include/uapi/asm/perf_regs.h| 42 +++
arch/riscv/kernel/Makefile | 4 +-
arch/riscv/kernel/entry.S | 6 +-
arch/riscv/kernel/fpu.S| 8 +-
arch/riscv/kernel/head.S | 2 +-
arch/riscv/kernel/perf_callchain.c | 94 +++
arch/riscv/kernel/perf_regs.c | 44 +++
arch/riscv/kernel/smp.c| 60 ++--
arch/riscv/kernel/smpboot.c| 3 +
arch/riscv/kernel/stacktrace.c | 4 +-
arch/riscv/lib/uaccess.S | 12 +-
arch/riscv/mm/Makefile | 3 +
arch/riscv/mm/cacheflush.c | 1 -
arch/riscv/mm/context.c| 7 +-
arch/riscv/mm/init.c | 12 +-
arch/riscv/mm/tlbflush.c | 35 +++
drivers/base/Kconfig | 2 +-
drivers/base/arch_topology.c | 298
drivers/clocksource/timer-riscv.c | 17 +-
drivers/irqchip/irq-sifive-plic.c | 12 +-
include/linux/arch_topology.h | 26 ++
include/linux/topology.h | 1 +
tools/arch/riscv/include/uapi/asm/perf_regs.h | 42 +++
tools/perf/Makefile.config | 6 +-
tools/perf/arch/riscv/Build| 1 +
tools/perf/arch/riscv/Makefile | 4 +
tools/perf/arch/riscv/include/perf_regs.h | 96 +++
tools/perf/arch/riscv/util/Build | 2
Re: [PATCH 8/9] select/restart_block: Convert poll's timeout to u64
On 9/9/19 2:07 PM, David Laight wrote:
> From: Dmitry Safonov
>> Sent: 09 September 2019 11:24
>>
>> All preparations have been done - now poll() can set u64 timeout in
>> restart_block. It allows to do the next step - unifying all timeouts in
>> restart_block and provide ptrace() API to read it.
>>
>> Signed-off-by: Dmitry Safonov
>> ---
>> fs/select.c | 27 +++
>> include/linux/restart_block.h | 4 +---
>> 2 files changed, 8 insertions(+), 23 deletions(-)
>>
>> diff --git a/fs/select.c b/fs/select.c
>> index 4af88feaa2fe..ff2b9c4865cd 100644
>> --- a/fs/select.c
>> +++ b/fs/select.c
> ...
>> @@ -1037,16 +1030,10 @@ SYSCALL_DEFINE3(poll, struct pollfd __user *, ufds,
>> unsigned int, nfds,
>> struct restart_block *restart_block;
>>
>> restart_block = >restart_block;
>> -restart_block->fn = do_restart_poll;
>> -restart_block->poll.ufds = ufds;
>> -restart_block->poll.nfds = nfds;
>> -
>> -if (timeout_msecs >= 0) {
>> -restart_block->poll.tv_sec = end_time.tv_sec;
>> -restart_block->poll.tv_nsec = end_time.tv_nsec;
>> -restart_block->poll.has_timeout = 1;
>> -} else
>> -restart_block->poll.has_timeout = 0;
>> +restart_block->fn = do_restart_poll;
>> +restart_block->poll.ufds= ufds;
>> +restart_block->poll.nfds= nfds;
>> +restart_block->poll.timeout = timeout;
>
> What is all that whitespace for?
Aligned them with tabs just to make it look better.
I've no hard feelings about this - I can do it with spaces or drop the
align at all.
Thanks,
Dmitry
Re: [RESEND v4 5/7] mm, slab_common: Make kmalloc_caches[] start at size KMALLOC_MIN_SIZE
On Mon, Sep 16, 2019 at 12:54 PM kbuild test robot wrote: > > Hi Pengfei, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on linus/master] > [cannot apply to v5.3 next-20190915] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Pengfei-Li/mm-slab-Make-kmalloc_info-contain-all-types-of-names/20190916-065820 > reproduce: > # apt-get install sparse > # sparse version: v0.6.1-rc1-7-g2b96cd8-dirty > make ARCH=x86_64 allmodconfig > make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' > > If you fix the issue, kindly add following tag > Reported-by: kbuild test robot > > > sparse warnings: (new ones prefixed by >>) > > >> mm/slab_common.c:1121:34: sparse: sparse: symbol 'all_kmalloc_info' was > >> not declared. Should it be static? Thanks. I will fix it in v5. > > Please review and possibly fold the followup patch. > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [RESEND v4 5/7] mm, slab_common: Make kmalloc_caches[] start at size KMALLOC_MIN_SIZE
On Mon, Sep 16, 2019 at 9:46 AM kbuild test robot wrote: > > Hi Pengfei, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [cannot apply to v5.3 next-20190904] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Pengfei-Li/mm-slab-Make-kmalloc_info-contain-all-types-of-names/20190916-065820 > config: parisc-allmodconfig (attached as .config) > compiler: hppa-linux-gcc (GCC) 7.4.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > GCC_VERSION=7.4.0 make.cross ARCH=parisc > > If you fix the issue, kindly add following tag > Reported-by: kbuild test robot > > All errors (new ones prefixed by >>): > > >> mm/slab_common.c:1144:34: error: 'KMALLOC_INFO_START_IDX' undeclared here > >> (not in a function); did you mean 'VMALLOC_START'? > kmalloc_info = _kmalloc_info[KMALLOC_INFO_START_IDX]; > ^~ > VMALLOC_START > > vim +1144 mm/slab_common.c > > 1142 > 1143 const struct kmalloc_info_struct * const __initconst > > 1144 kmalloc_info = _kmalloc_info[KMALLOC_INFO_START_IDX]; > 1145 > Thanks. This error is caused by I was mistakenly placed KMALLOC_INFO_SHIFT_LOW and KMALLOC_INFO_START_IDX in the wrong place. (ARCH=sh is the same) I will fix it in v5. > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH] media: usb: tm6000: Use the correct style for SPDX License Identifier
This patch corrects the SPDX License Identifier style in header files for TV Master Media USB Adapter drivers. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46. Suggested-by: Joe Perches Signed-off-by: Nishad Kamdar --- drivers/media/usb/tm6000/tm6000-regs.h | 2 +- drivers/media/usb/tm6000/tm6000-usb-isoc.h | 2 +- drivers/media/usb/tm6000/tm6000.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/usb/tm6000/tm6000-regs.h b/drivers/media/usb/tm6000/tm6000-regs.h index d10424673db9..6a181f2e7ef2 100644 --- a/drivers/media/usb/tm6000/tm6000-regs.h +++ b/drivers/media/usb/tm6000/tm6000-regs.h @@ -1,5 +1,5 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* - * SPDX-License-Identifier: GPL-2.0 * tm6000-regs.h - driver for TM5600/TM6000/TM6010 USB video capture devices * * Copyright (c) 2006-2007 Mauro Carvalho Chehab diff --git a/drivers/media/usb/tm6000/tm6000-usb-isoc.h b/drivers/media/usb/tm6000/tm6000-usb-isoc.h index b275dbce3a1b..e3c6933f854d 100644 --- a/drivers/media/usb/tm6000/tm6000-usb-isoc.h +++ b/drivers/media/usb/tm6000/tm6000-usb-isoc.h @@ -1,5 +1,5 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* - * SPDX-License-Identifier: GPL-2.0 * tm6000-buf.c - driver for TM5600/TM6000/TM6010 USB video capture devices * * Copyright (c) 2006-2007 Mauro Carvalho Chehab diff --git a/drivers/media/usb/tm6000/tm6000.h b/drivers/media/usb/tm6000/tm6000.h index bf396544da9a..c08c95312739 100644 --- a/drivers/media/usb/tm6000/tm6000.h +++ b/drivers/media/usb/tm6000/tm6000.h @@ -1,5 +1,5 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* - * SPDX-License-Identifier: GPL-2.0 * tm6000.h - driver for TM5600/TM6000/TM6010 USB video capture devices * * Copyright (c) 2006-2007 Mauro Carvalho Chehab -- 2.17.1
Re: [PATCH v2 2/2] powerpc/83xx: map IMMR with a BAT.
On Mon, 2019-09-16 at 06:42 +, Christophe Leroy wrote:
> @@ -145,6 +147,15 @@ void __init mpc83xx_setup_arch(void)
> if (ppc_md.progress)
> ppc_md.progress("mpc83xx_setup_arch()", 0);
>
> + if (!__map_without_bats) {
> + phys_addr_t immrbase = get_immrbase();
> + int immrsize = IS_ALIGNED(immrbase, SZ_2M) ? SZ_2M : SZ_1M;
> + unsigned long va = __fix_to_virt(FIX_IMMR_BASE);
Why __fix_to_virt() and not fix_to_virt()?
-Scott
Re: [RESEND v4 6/7] mm, slab_common: Initialize the same size of kmalloc_caches[]
On Mon, Sep 16, 2019 at 5:38 AM David Rientjes wrote:
Thanks for your review comments!
>
> On Mon, 16 Sep 2019, Pengfei Li wrote:
>
> > diff --git a/mm/slab_common.c b/mm/slab_common.c
> > index 2aed30deb071..e7903bd28b1f 100644
> > --- a/mm/slab_common.c
> > +++ b/mm/slab_common.c
> > @@ -1165,12 +1165,9 @@ void __init setup_kmalloc_cache_index_table(void)
> > size_index[size_index_elem(i)] = 0;
> > }
> >
> > -static void __init
> > +static __always_inline void __init
> > new_kmalloc_cache(int idx, enum kmalloc_cache_type type, slab_flags_t
> > flags)
> > {
> > - if (type == KMALLOC_RECLAIM)
> > - flags |= SLAB_RECLAIM_ACCOUNT;
> > -
> > kmalloc_caches[type][idx] = create_kmalloc_cache(
> > kmalloc_info[idx].name[type],
> > kmalloc_info[idx].size, flags, 0,
> > @@ -1185,30 +1182,22 @@ new_kmalloc_cache(int idx, enum kmalloc_cache_type
> > type, slab_flags_t flags)
> > void __init create_kmalloc_caches(slab_flags_t flags)
> > {
> > int i;
> > - enum kmalloc_cache_type type;
> >
> > - for (type = KMALLOC_NORMAL; type <= KMALLOC_RECLAIM; type++) {
> > - for (i = 0; i < KMALLOC_CACHE_NUM; i++) {
> > - if (!kmalloc_caches[type][i])
> > - new_kmalloc_cache(i, type, flags);
> > - }
> > - }
> > + for (i = 0; i < KMALLOC_CACHE_NUM; i++) {
> > + if (!kmalloc_caches[KMALLOC_NORMAL][i])
> > + new_kmalloc_cache(i, KMALLOC_NORMAL, flags);
> >
> > - /* Kmalloc array is now usable */
> > - slab_state = UP;
> > + new_kmalloc_cache(i, KMALLOC_RECLAIM,
> > + flags | SLAB_RECLAIM_ACCOUNT);
>
> This seems less robust, no? Previously we verified that the cache doesn't
> exist before creating a new cache over top of it (for NORMAL and RECLAIM).
> Now we presume that the RECLAIM cache never exists.
>
Agree, this is really less robust.
I have checked the code and found that there is no place to initialize
kmalloc-rcl-xxx before create_kmalloc_caches(). So I assume that
kmalloc-rcl-xxx is NULL.
> Can we just move a check to new_kmalloc_cache() to see if
> kmalloc_caches[type][idx] already exists and, if so, just return? This
> should be more robust and simplify create_kmalloc_caches() slightly more.
For better robustness, I will do it as you suggested in v5.
[PATCH] selftests/net: replace AF_MAX with INT_MAX in socket.c
Use INT_MAX instead of AF_MAX, since libc might have a smaller value
of AF_MAX than the kernel, what causes the test to fail.
Signed-off-by: Marcelo Henrique Cerri
---
tools/testing/selftests/net/socket.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/socket.c
b/tools/testing/selftests/net/socket.c
index afca1ead677f..10e75ba90124 100644
--- a/tools/testing/selftests/net/socket.c
+++ b/tools/testing/selftests/net/socket.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
struct socket_testcase {
int domain;
@@ -24,7 +25,10 @@ struct socket_testcase {
};
static struct socket_testcase tests[] = {
- { AF_MAX, 0, 0, -EAFNOSUPPORT,0 },
+ /* libc might have a smaller value of AF_MAX than the kernel
+* actually supports, so use INT_MAX instead.
+*/
+ { INT_MAX, 0, 0, -EAFNOSUPPORT,0 },
{ AF_INET, SOCK_STREAM, IPPROTO_TCP, 0,1 },
{ AF_INET, SOCK_DGRAM, IPPROTO_TCP, -EPROTONOSUPPORT, 1 },
{ AF_INET, SOCK_DGRAM, IPPROTO_UDP, 0,1 },
--
2.20.1
[tip: x86/mm] x86/mm: Enable 5-level paging support by default
The following commit has been merged into the x86/mm branch of tip: Commit-ID: 18ec1eaf58fbf2d9009a752a102a3d8e0d905a0f Gitweb: https://git.kernel.org/tip/18ec1eaf58fbf2d9009a752a102a3d8e0d905a0f Author:Kirill A. Shutemov AuthorDate:Fri, 13 Sep 2019 12:54:52 +03:00 Committer: Ingo Molnar CommitterDate: Mon, 16 Sep 2019 16:51:20 +02:00 x86/mm: Enable 5-level paging support by default Support of boot-time switching between 4- and 5-level paging mode is upstream since 4.17. We run internal testing with 5-level paging support enabled for a while and it doesn't not cause any functional or performance regression on 4-level paging hardware. The only 5-level paging related regressions I saw were in early boot code that runs independently from CONFIG_X86_5LEVEL. The next major release of distributions expected to have CONFIG_X86_5LEVEL=y. Enable the option by default. It may help to catch obscure bugs early. Signed-off-by: Kirill A. Shutemov Acked-by: Dave Hansen Cc: Andy Lutomirski Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: linux...@kvack.org Link: https://lkml.kernel.org/r/20190913095452.40592-1-kirill.shute...@linux.intel.com Signed-off-by: Ingo Molnar --- arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 58eae28..d4bbebe 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1483,6 +1483,7 @@ config X86_PAE config X86_5LEVEL bool "Enable 5-level page tables support" + default y select DYNAMIC_MEMORY_LAYOUT select SPARSEMEM_VMEMMAP depends on X86_64
[PATCH] locking: locktorture: Do not include rwlock.h directly
From: Wolfgang M. Reimer Including rwlock.h directly will cause kernel builds to fail if CONFIG_PREEMPT_RT is defined. The correct header file (rwlock_rt.h OR rwlock.h) will be included by spinlock.h which is included by locktorture.c anyway. Remove the include of linux/rwlock.h. Signed-off-by: Wolfgang M. Reimer Signed-off-by: Sebastian Andrzej Siewior --- kernel/locking/locktorture.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c index c513031cd7e33..9fb042d610d23 100644 --- a/kernel/locking/locktorture.c +++ b/kernel/locking/locktorture.c @@ -16,7 +16,6 @@ #include #include #include -#include #include #include #include -- 2.23.0
Re: [PATCH] x86/mm: Enable 5-level paging support by default
* Dave Hansen wrote: > On 9/13/19 2:54 AM, Kirill A. Shutemov wrote: > > The next major release of distributions expected to have > > CONFIG_X86_5LEVEL=y. > > It's probably worth noting that this exposes to two kinds of possible > performance issues: > > First is the overhead of having the 5-level code on 4-level hardware. > We haven't seen any regressions there in quite a while. Kirill talked > about this in the changelog. > > Second is the overhead of having 5-level paging active on 5-level > hardware versus using 4-level paging on hardware *capable* of 5-level. > That is, of course, much harder to measure since 5-level hardware is not > publicly available. But, we've tested this quite a bit and we're pretty > confident that it will not cause regressions, especially on systems > where apps don't opt in to the larger address space. > > I do think endeavoring to have mainline's defaults match the most common > distro configs is a good idea, and now is as good of a time as any. > > Acked-by: Dave Hansen Ok - in terms of timing it's obviously *way* too late for v5.4, so I've queued it up for the v5.5 merge window in tip:x86/mm. This should give it 2-3 months of additional testing to shake out any weird interactions and quirks. Thanks, Ingo
[PATCH v3] usbip: vhci_hcd indicate failed message
If the return value of vhci_init_attr_group and
sysfs_create_group is non-zero, which mean they failed
to init attr_group and create sysfs group, so it would
better add 'failed' message to indicate that.
This patch also change pr_err to dev_err to trace which
device is failed.
Fixes: 0775a9cbc694 ("usbip: vhci extension: modifications to vhci driver")
Signed-off-by: Mao Wenan
---
v2: change pr_err to dev_err.
v3: add error code in failed messages.
drivers/usb/usbip/vhci_hcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 000ab7225717..144507751eae 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1185,12 +1185,12 @@ static int vhci_start(struct usb_hcd *hcd)
if (id == 0 && usb_hcd_is_primary_hcd(hcd)) {
err = vhci_init_attr_group();
if (err) {
- pr_err("init attr group\n");
+ dev_err(hcd_dev(hcd), "init attr group failed, err =
%d\n", err);
return err;
}
err = sysfs_create_group(_dev(hcd)->kobj, _attr_group);
if (err) {
- pr_err("create sysfs files\n");
+ dev_err(hcd_dev(hcd), "create sysfs files failed, err =
%d\n", err);
vhci_finish_attr_group();
return err;
}
--
2.20.1
Re: [RESEND v4 1/7] mm, slab: Make kmalloc_info[] contain all types of names
On Mon, Sep 16, 2019 at 5:38 AM David Rientjes wrote: > > On Mon, 16 Sep 2019, Pengfei Li wrote: > > > There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM > > and KMALLOC_DMA. > > > > The name of KMALLOC_NORMAL is contained in kmalloc_info[].name, > > but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically > > generated by kmalloc_cache_name(). > > > > This patch predefines the names of all types of kmalloc to save > > the time spent dynamically generating names. > > > > Besides, remove the kmalloc_cache_name() that is no longer used. > > > > Signed-off-by: Pengfei Li > > Acked-by: Vlastimil Babka > > Acked-by: Roman Gushchin > > Acked-by: David Rientjes > Thanks. > It's unfortunate the existing names are kmalloc-, dma-kmalloc-, and > kmalloc-rcl- since they aren't following any standard naming convention. > > Also not sure I understand the SET_KMALLOC_SIZE naming since this isn't > just setting a size. Maybe better off as INIT_KMALLOC_INFO? Yes, this name is really better. I will rename SET_KMALLOC_SIZE to INIT_KMALLOC_INFO in v5. > > Nothing major though, so: > > Acked-by: David Rientjes
Re: [Patch 05/13] media: am437x-vpfe: Streamlined vb2 buffer cleanup
Lad, Prabhakar wrote on Mon [2019-Sep-16 09:00:03
+0100]:
> Hi Benoit,
>
> Thank you for the patch.
>
> On Mon, Sep 9, 2019 at 5:26 PM Benoit Parrot wrote:
> >
> > Returning queued vb2 buffers back to user space is a common
> > task best handled by a helper function.
> >
> > Signed-off-by: Benoit Parrot
> > ---
> > drivers/media/platform/am437x/am437x-vpfe.c | 54 ++---
> > 1 file changed, 26 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
> > b/drivers/media/platform/am437x/am437x-vpfe.c
> > index 3a8ad9bdf283..52f7fc6e11dd 100644
> > --- a/drivers/media/platform/am437x/am437x-vpfe.c
> > +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> > @@ -1949,6 +1949,29 @@ static void vpfe_buffer_queue(struct vb2_buffer *vb)
> > spin_unlock_irqrestore(>dma_queue_lock, flags);
> > }
> >
> > +static void vpfe_return_all_buffers(struct vpfe_device *vpfe,
> > + enum vb2_buffer_state state)
> > +{
> > + struct vpfe_cap_buffer *buf, *node;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(>dma_queue_lock, flags);
> > + list_for_each_entry_safe(buf, node, >dma_queue, list) {
> > + vb2_buffer_done(>vb.vb2_buf, state);
> > + list_del(>list);
> > + }
> > +
> > + if (vpfe->cur_frm)
> > + vb2_buffer_done(>cur_frm->vb.vb2_buf, state);
> > +
> > + if (vpfe->next_frm && vpfe->next_frm != vpfe->cur_frm)
> > + vb2_buffer_done(>next_frm->vb.vb2_buf, state);
> > +
> > + vpfe->cur_frm = NULL;
> > + vpfe->next_frm = NULL;
> > + spin_unlock_irqrestore(>dma_queue_lock, flags);
> > +}
> > +
> > /*
> > * vpfe_start_streaming : Starts the DMA engine for streaming
> > * @vb: ptr to vb2_buffer
> > @@ -1957,7 +1980,6 @@ static void vpfe_buffer_queue(struct vb2_buffer *vb)
> > static int vpfe_start_streaming(struct vb2_queue *vq, unsigned int count)
> > {
> > struct vpfe_device *vpfe = vb2_get_drv_priv(vq);
> > - struct vpfe_cap_buffer *buf, *tmp;
> > struct vpfe_subdev_info *sdinfo;
> > unsigned long flags;
> > unsigned long addr;
> > @@ -2003,11 +2025,8 @@ static int vpfe_start_streaming(struct vb2_queue
> > *vq, unsigned int count)
> > return 0;
> >
> > err:
> > - list_for_each_entry_safe(buf, tmp, >dma_queue, list) {
> > - list_del(>list);
> > - vb2_buffer_done(>vb.vb2_buf, VB2_BUF_STATE_QUEUED);
> > - }
> > -
> > + vpfe_return_all_buffers(vpfe, VB2_BUF_STATE_QUEUED);
> > + vpfe_pcr_enable(>ccdc, 0);
>
> please create a seperate patch for the above change.
You mean a separate patch just for the vpfe_pcr_enable() call?
Benoit
>
> Cheers,
> --Prabhakar Lad
>
> > return ret;
> > }
> >
> > @@ -2022,7 +2041,6 @@ static void vpfe_stop_streaming(struct vb2_queue *vq)
> > {
> > struct vpfe_device *vpfe = vb2_get_drv_priv(vq);
> > struct vpfe_subdev_info *sdinfo;
> > - unsigned long flags;
> > int ret;
> >
> > vpfe_pcr_enable(>ccdc, 0);
> > @@ -2040,27 +2058,7 @@ static void vpfe_stop_streaming(struct vb2_queue *vq)
> > vpfe_dbg(1, vpfe, "stream off failed in subdev\n");
> >
> > /* release all active buffers */
> > - spin_lock_irqsave(>dma_queue_lock, flags);
> > - if (vpfe->cur_frm == vpfe->next_frm) {
> > - vb2_buffer_done(>cur_frm->vb.vb2_buf,
> > - VB2_BUF_STATE_ERROR);
> > - } else {
> > - if (vpfe->cur_frm != NULL)
> > - vb2_buffer_done(>cur_frm->vb.vb2_buf,
> > - VB2_BUF_STATE_ERROR);
> > - if (vpfe->next_frm != NULL)
> > - vb2_buffer_done(>next_frm->vb.vb2_buf,
> > - VB2_BUF_STATE_ERROR);
> > - }
> > -
> > - while (!list_empty(>dma_queue)) {
> > - vpfe->next_frm = list_entry(vpfe->dma_queue.next,
> > - struct vpfe_cap_buffer,
> > list);
> > - list_del(>next_frm->list);
> > - vb2_buffer_done(>next_frm->vb.vb2_buf,
> > - VB2_BUF_STATE_ERROR);
> > - }
> > - spin_unlock_irqrestore(>dma_queue_lock, flags);
> > + vpfe_return_all_buffers(vpfe, VB2_BUF_STATE_ERROR);
> > }
> >
> > static int vpfe_g_pixelaspect(struct file *file, void *priv,
> > --
> > 2.17.1
> >
[PATCH v5 7/7] mm, slab_common: Modify kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
KMALLOC_NORMAL is the most frequently accessed, and kmalloc_caches[]
is initialized by different types of the same size.
So modifying kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
will benefit performance.
$ ./scripts/bloat-o-meter vmlinux.patch_1-6 vmlinux.patch_1-7
add/remove: 0/0 grow/shrink: 2/57 up/down: 8/-458 (-450)
Function old new delta
tg3_self_test 42554259 +4
nf_queue 666 670 +4
kmalloc_slab 97 93 -4
i915_sw_fence_await_dma_fence441 437 -4
__igmp_group_dropped 619 615 -4
gss_import_sec_context 176 170 -6
xhci_alloc_command 212 205 -7
xprt_switch_alloc136 128 -8
xhci_segment_alloc 297 289 -8
xhci_ring_alloc 369 361 -8
xhci_mem_init 36643656 -8
xhci_alloc_virt_device 496 488 -8
xhci_alloc_tt_info 346 338 -8
xhci_alloc_stream_info 718 710 -8
xhci_alloc_container_ctx 215 207 -8
xfrm_policy_alloc271 263 -8
tcp_sendmsg_locked 31203112 -8
tcp_md5_do_add 774 766 -8
tcp_fastopen_defer_connect 270 262 -8
sr_read_tochdr.isra 251 243 -8
sr_read_tocentry.isra328 320 -8
sr_is_xa 376 368 -8
sr_get_mcn 260 252 -8
selinux_sk_alloc_security113 105 -8
sdev_evt_send_simple 118 110 -8
sdev_evt_alloc79 71 -8
scsi_probe_and_add_lun 29382930 -8
sbitmap_queue_init_node 418 410 -8
ring_buffer_read_prepare 94 86 -8
request_firmware_nowait 396 388 -8
regulatory_hint_found_beacon 394 386 -8
ohci_urb_enqueue31763168 -8
nla_strdup 142 134 -8
nfs_alloc_seqid 87 79 -8
nfs4_get_state_owner10401032 -8
nfs4_do_close578 570 -8
nf_ct_tmpl_alloc 85 77 -8
mempool_create_node 164 156 -8
ip_setup_cork362 354 -8
ip6_setup_cork 10211013 -8
gss_create_cred 140 132 -8
drm_flip_work_allocate_task 70 62 -8
dma_pool_alloc 410 402 -8
devres_open_group214 206 -8
create_kmalloc_caches203 195 -8
cfg80211_stop_iface 260 252 -8
cfg80211_sinfo_alloc_tid_stats77 69 -8
cfg80211_port_authorized 212 204 -8
cfg80211_parse_mbssid_data 23972389 -8
cfg80211_ibss_joined 335 327 -8
call_usermodehelper_setup149 141 -8
bpf_prog_alloc_no_stats 182 174 -8
blk_alloc_flush_queue191 183 -8
bdi_alloc_node 195 187 -8
audit_log_d_path 196 188 -8
_netlbl_catmap_getnode 247 239 -8
ip_mc_inc_group 475 467 -8
__i915_sw_fence_await_sw_fence 417 405 -12
ida_alloc_range 955 934 -21
Total: Before=14788957, After=14788507, chg -0.00%
Signed-off-by: Pengfei Li
Acked-by: David Rientjes
---
include/linux/slab.h | 6 +++---
mm/slab.c| 4 ++--
mm/slab_common.c | 8
mm/slub.c| 12 ++--
4 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index f53bb6980110..0842db5f7053 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -340,7 +340,7 @@ enum kmalloc_cache_type {
#ifndef CONFIG_SLOB
extern struct kmem_cache *
-kmalloc_caches[NR_KMALLOC_TYPES][KMALLOC_CACHE_NUM];
+kmalloc_caches[KMALLOC_CACHE_NUM][NR_KMALLOC_TYPES];
static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags)
{
@@ -582,7 +582,7 @@
[PATCH v5 6/7] mm, slab_common: Initialize the same size of kmalloc_caches[]
In the current implementation, KMALLOC_RECLAIM is not initialized
until all the KMALLOC_NORMAL sizes have been initialized.
But for a particular size, create_kmalloc_caches() can be executed
faster by initializing different types of kmalloc in order.
$ ./scripts/bloat-o-meter vmlinux.patch_1-5 vmlinux.patch_1-6
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-11 (-11)
Function old new delta
create_kmalloc_caches214 203 -11
Total: Before=14788968, After=14788957, chg -0.00%
Although the benefits are small (more judgment is made for
robustness), create_kmalloc_caches() is much simpler.
Besides, KMALLOC_DMA will be initialized after "slab_state = UP",
this does not seem to be necessary.
Commit f97d5f634d3b ("slab: Common function to create the kmalloc
array") introduces create_kmalloc_caches().
And I found that for SLAB, KMALLOC_DMA is initialized before
"slab_state = UP". But for SLUB, KMALLOC_DMA is initialized after
"slab_state = UP".
Based on this fact, I think it is okay to initialize KMALLOC_DMA
before "slab_state = UP".
Signed-off-by: Pengfei Li
---
mm/slab_common.c | 35 +--
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index eeef5ac8d04d..00f2cfc66dbd 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1168,11 +1168,11 @@ void __init setup_kmalloc_cache_index_table(void)
size_index[size_index_elem(i)] = 0;
}
-static void __init
+static __always_inline void __init
new_kmalloc_cache(int idx, enum kmalloc_cache_type type, slab_flags_t flags)
{
- if (type == KMALLOC_RECLAIM)
- flags |= SLAB_RECLAIM_ACCOUNT;
+ if (kmalloc_caches[type][idx])
+ return;
kmalloc_caches[type][idx] = create_kmalloc_cache(
kmalloc_info[idx].name[type],
@@ -1188,30 +1188,21 @@ new_kmalloc_cache(int idx, enum kmalloc_cache_type
type, slab_flags_t flags)
void __init create_kmalloc_caches(slab_flags_t flags)
{
int i;
- enum kmalloc_cache_type type;
- for (type = KMALLOC_NORMAL; type <= KMALLOC_RECLAIM; type++) {
- for (i = 0; i < KMALLOC_CACHE_NUM; i++) {
- if (!kmalloc_caches[type][i])
- new_kmalloc_cache(i, type, flags);
- }
- }
+ for (i = 0; i < KMALLOC_CACHE_NUM; i++) {
+ new_kmalloc_cache(i, KMALLOC_NORMAL, flags);
- /* Kmalloc array is now usable */
- slab_state = UP;
+ new_kmalloc_cache(i, KMALLOC_RECLAIM,
+ flags | SLAB_RECLAIM_ACCOUNT);
#ifdef CONFIG_ZONE_DMA
- for (i = 0; i < KMALLOC_CACHE_NUM; i++) {
- struct kmem_cache *s = kmalloc_caches[KMALLOC_NORMAL][i];
-
- if (s) {
- kmalloc_caches[KMALLOC_DMA][i] = create_kmalloc_cache(
- kmalloc_info[i].name[KMALLOC_DMA],
- kmalloc_info[i].size,
- SLAB_CACHE_DMA | flags, 0, 0);
- }
- }
+ new_kmalloc_cache(i, KMALLOC_DMA,
+ flags | SLAB_CACHE_DMA);
#endif
+ }
+
+ /* Kmalloc array is now usable */
+ slab_state = UP;
}
#endif /* !CONFIG_SLOB */
--
2.21.0
[PATCH v5 5/7] mm, slab_common: Make kmalloc_caches[] start at size KMALLOC_MIN_SIZE
Currently, kmalloc_cache[] is not sorted by size, kmalloc_cache[0] is kmalloc-96, kmalloc_cache[1] is kmalloc-192 (when ARCH_DMA_MINALIGN is not defined). As suggested by Vlastimil Babka, "Since you're doing these cleanups, have you considered reordering kmalloc_info, size_index, kmalloc_index() etc so that sizes 96 and 192 are ordered naturally between 64, 128 and 256? That should remove various special casing such as in create_kmalloc_caches(). I can't guarantee it will be possible without breaking e.g. constant folding optimizations etc., but seems to me it should be feasible. (There are definitely more places to change than those I listed.)" So this patch reordered kmalloc_info[], kmalloc_caches[], and modified kmalloc_index() and kmalloc_slab() accordingly. As a result, there is no subtle judgment about size in create_kmalloc_caches(). And initialize kmalloc_cache[] from 0 instead of KMALLOC_SHIFT_LOW. I used ./scripts/bloat-o-meter to measure the impact of this patch on performance. The results show that it brings some benefits. Considering the size change of kmalloc_info[], the size of the code is actually about 641 bytes less. (Note: The original kmalloc_info[] was renamed to all_kmalloc_info[]) $ ./scripts/bloat-o-meter vmlinux.old vmlinux.patch_1-5 add/remove: 1/2 grow/shrink: 6/64 up/down: 872/-1113 (-241) Function old new delta all_kmalloc_info - 832+832 crypto_create_tfm211 225 +14 ieee80211_key_alloc 11591169 +10 nl80211_parse_sched_scan27872795 +8 ida_alloc_range 951 955 +4 find_get_context.isra634 637 +3 sd_probe 947 948 +1 nla_strdup 143 142 -1 trace_parser_get_init 71 69 -2 pkcs7_verify.cold318 316 -2 xhci_alloc_tt_info 349 346 -3 units323 320 -3 nl80211_set_reg 642 639 -3 i915_sw_fence_await_dma_fence445 441 -4 nf_queue 671 666 -5 kmalloc_slab 102 97 -5 xhci_segment_alloc 303 297 -6 xhci_alloc_container_ctx 221 215 -6 xfrm_policy_alloc277 271 -6 selinux_sk_alloc_security119 113 -6 sdev_evt_send_simple 124 118 -6 sdev_evt_alloc85 79 -6 sbitmap_queue_init_node 424 418 -6 regulatory_hint_found_beacon 400 394 -6 nf_ct_tmpl_alloc 91 85 -6 gss_create_cred 146 140 -6 drm_flip_work_allocate_task 76 70 -6 cfg80211_stop_iface 266 260 -6 cfg80211_sinfo_alloc_tid_stats83 77 -6 cfg80211_port_authorized 218 212 -6 cfg80211_ibss_joined 341 335 -6 call_usermodehelper_setup155 149 -6 bpf_prog_alloc_no_stats 188 182 -6 blk_alloc_flush_queue197 191 -6 bdi_alloc_node 201 195 -6 _netlbl_catmap_getnode 253 247 -6 ip_mc_inc_group 481 475 -6 pkcs7_verify15031495 -8 audit_log_d_path 204 196 -8 xprt_switch_alloc145 136 -9 xhci_ring_alloc 378 369 -9 xhci_mem_init 36733664 -9 xhci_alloc_virt_device 505 496 -9 xhci_alloc_stream_info 727 718 -9 xhci_alloc_command 221 212 -9 tcp_sendmsg_locked 31293120 -9 tcp_md5_do_add 783 774 -9 tcp_fastopen_defer_connect 279 270 -9 sr_read_tochdr.isra 260 251 -9 sr_read_tocentry.isra337 328 -9 sr_is_xa 385 376 -9 sr_get_mcn 269 260 -9 scsi_probe_and_add_lun 29472938 -9 ring_buffer_read_prepare 103 94 -9 request_firmware_nowait 405 396 -9
[PATCH v5 4/7] mm, slab: Return ZERO_SIZE_ALLOC for zero sized kmalloc requests
This is a preparation patch, just replace 0 with ZERO_SIZE_ALLOC
as the return value of zero sized requests.
Signed-off-by: Pengfei Li
Acked-by: David Rientjes
---
include/linux/slab.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index e773e5764b7b..1f05f68f2c3e 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -121,14 +121,20 @@
#define SLAB_DEACTIVATED ((slab_flags_t __force)0x1000U)
/*
- * ZERO_SIZE_PTR will be returned for zero sized kmalloc requests.
+ * ZERO_SIZE_ALLOC will be returned by kmalloc_index() if it was zero sized
+ * requests.
*
+ * After that, ZERO_SIZE_PTR will be returned by the function that called
+ * kmalloc_index().
+
* Dereferencing ZERO_SIZE_PTR will lead to a distinct access fault.
*
* ZERO_SIZE_PTR can be passed to kfree though in the same way that NULL can.
* Both make kfree a no-op.
*/
-#define ZERO_SIZE_PTR ((void *)16)
+#define ZERO_SIZE_ALLOC(UINT_MAX)
+
+#define ZERO_SIZE_PTR ((void *)16)
#define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \
(unsigned long)ZERO_SIZE_PTR)
@@ -350,7 +356,7 @@ static __always_inline enum kmalloc_cache_type
kmalloc_type(gfp_t flags)
static __always_inline unsigned int kmalloc_index(size_t size)
{
if (!size)
- return 0;
+ return ZERO_SIZE_ALLOC;
if (size <= KMALLOC_MIN_SIZE)
return KMALLOC_SHIFT_LOW;
@@ -546,7 +552,7 @@ static __always_inline void *kmalloc(size_t size, gfp_t
flags)
#ifndef CONFIG_SLOB
index = kmalloc_index(size);
- if (!index)
+ if (index == ZERO_SIZE_ALLOC)
return ZERO_SIZE_PTR;
return kmem_cache_alloc_trace(
@@ -564,7 +570,7 @@ static __always_inline void *kmalloc_node(size_t size,
gfp_t flags, int node)
size <= KMALLOC_MAX_CACHE_SIZE) {
unsigned int i = kmalloc_index(size);
- if (!i)
+ if (i == ZERO_SIZE_ALLOC)
return ZERO_SIZE_PTR;
return kmem_cache_alloc_node_trace(
--
2.21.0
[PATCH v5 3/7] mm, slab_common: Use enum kmalloc_cache_type to iterate over kmalloc caches
The type of local variable *type* of new_kmalloc_cache() should
be enum kmalloc_cache_type instead of int, so correct it.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
Acked-by: David Rientjes
---
mm/slab_common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index df030cf9f44f..23054b8b75b6 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1192,7 +1192,7 @@ void __init setup_kmalloc_cache_index_table(void)
}
static void __init
-new_kmalloc_cache(int idx, int type, slab_flags_t flags)
+new_kmalloc_cache(int idx, enum kmalloc_cache_type type, slab_flags_t flags)
{
if (type == KMALLOC_RECLAIM)
flags |= SLAB_RECLAIM_ACCOUNT;
@@ -1210,7 +1210,8 @@ new_kmalloc_cache(int idx, int type, slab_flags_t flags)
*/
void __init create_kmalloc_caches(slab_flags_t flags)
{
- int i, type;
+ int i;
+ enum kmalloc_cache_type type;
for (type = KMALLOC_NORMAL; type <= KMALLOC_RECLAIM; type++) {
for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++) {
--
2.21.0
[PATCH v5 2/7] mm, slab: Remove unused kmalloc_size()
The size of kmalloc can be obtained from kmalloc_info[],
so remove kmalloc_size() that will not be used anymore.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
Acked-by: David Rientjes
---
include/linux/slab.h | 20
mm/slab.c| 5 +++--
mm/slab_common.c | 5 ++---
3 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 56c9c7eed34e..e773e5764b7b 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -557,26 +557,6 @@ static __always_inline void *kmalloc(size_t size, gfp_t
flags)
return __kmalloc(size, flags);
}
-/*
- * Determine size used for the nth kmalloc cache.
- * return size or 0 if a kmalloc cache for that
- * size does not exist
- */
-static __always_inline unsigned int kmalloc_size(unsigned int n)
-{
-#ifndef CONFIG_SLOB
- if (n > 2)
- return 1U << n;
-
- if (n == 1 && KMALLOC_MIN_SIZE <= 32)
- return 96;
-
- if (n == 2 && KMALLOC_MIN_SIZE <= 64)
- return 192;
-#endif
- return 0;
-}
-
static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node)
{
#ifndef CONFIG_SLOB
diff --git a/mm/slab.c b/mm/slab.c
index c42b6211f42e..7bc4e90e1147 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1248,8 +1248,9 @@ void __init kmem_cache_init(void)
*/
kmalloc_caches[KMALLOC_NORMAL][INDEX_NODE] = create_kmalloc_cache(
kmalloc_info[INDEX_NODE].name[KMALLOC_NORMAL],
- kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS,
- 0, kmalloc_size(INDEX_NODE));
+ kmalloc_info[INDEX_NODE].size,
+ ARCH_KMALLOC_FLAGS, 0,
+ kmalloc_info[INDEX_NODE].size);
slab_state = PARTIAL_NODE;
setup_kmalloc_cache_index_table();
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 4e78490292df..df030cf9f44f 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1239,11 +1239,10 @@ void __init create_kmalloc_caches(slab_flags_t flags)
struct kmem_cache *s = kmalloc_caches[KMALLOC_NORMAL][i];
if (s) {
- unsigned int size = kmalloc_size(i);
-
kmalloc_caches[KMALLOC_DMA][i] = create_kmalloc_cache(
kmalloc_info[i].name[KMALLOC_DMA],
- size, SLAB_CACHE_DMA | flags, 0, 0);
+ kmalloc_info[i].size,
+ SLAB_CACHE_DMA | flags, 0, 0);
}
}
#endif
--
2.21.0
[PATCH v5 1/7] mm, slab: Make kmalloc_info[] contain all types of names
There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM
and KMALLOC_DMA.
The name of KMALLOC_NORMAL is contained in kmalloc_info[].name,
but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically
generated by kmalloc_cache_name().
This patch predefines the names of all types of kmalloc to save
the time spent dynamically generating names.
Besides, remove the kmalloc_cache_name() that is no longer used.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
Acked-by: David Rientjes
---
mm/slab.c| 2 +-
mm/slab.h| 2 +-
mm/slab_common.c | 91 ++--
3 files changed, 51 insertions(+), 44 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 9df370558e5d..c42b6211f42e 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1247,7 +1247,7 @@ void __init kmem_cache_init(void)
* structures first. Without this, further allocations will bug.
*/
kmalloc_caches[KMALLOC_NORMAL][INDEX_NODE] = create_kmalloc_cache(
- kmalloc_info[INDEX_NODE].name,
+ kmalloc_info[INDEX_NODE].name[KMALLOC_NORMAL],
kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS,
0, kmalloc_size(INDEX_NODE));
slab_state = PARTIAL_NODE;
diff --git a/mm/slab.h b/mm/slab.h
index 9057b8056b07..2fc8f956906a 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -76,7 +76,7 @@ extern struct kmem_cache *kmem_cache;
/* A table of kmalloc cache names and sizes */
extern const struct kmalloc_info_struct {
- const char *name;
+ const char *name[NR_KMALLOC_TYPES];
unsigned int size;
} kmalloc_info[];
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 807490fe217a..4e78490292df 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1092,26 +1092,56 @@ struct kmem_cache *kmalloc_slab(size_t size, gfp_t
flags)
return kmalloc_caches[kmalloc_type(flags)][index];
}
+#ifdef CONFIG_ZONE_DMA
+#define INIT_KMALLOC_INFO(__size, __short_size)\
+{ \
+ .name[KMALLOC_NORMAL] = "kmalloc-" #__short_size, \
+ .name[KMALLOC_RECLAIM] = "kmalloc-rcl-" #__short_size, \
+ .name[KMALLOC_DMA] = "dma-kmalloc-" #__short_size, \
+ .size = __size, \
+}
+#else
+#define INIT_KMALLOC_INFO(__size, __short_size)\
+{ \
+ .name[KMALLOC_NORMAL] = "kmalloc-" #__short_size, \
+ .name[KMALLOC_RECLAIM] = "kmalloc-rcl-" #__short_size, \
+ .size = __size, \
+}
+#endif
+
/*
* kmalloc_info[] is to make slub_debug=,kmalloc-xx option work at boot time.
* kmalloc_index() supports up to 2^26=64MB, so the final entry of the table is
* kmalloc-67108864.
*/
const struct kmalloc_info_struct kmalloc_info[] __initconst = {
- {NULL, 0}, {"kmalloc-96", 96},
- {"kmalloc-192", 192}, {"kmalloc-8", 8},
- {"kmalloc-16", 16}, {"kmalloc-32", 32},
- {"kmalloc-64", 64}, {"kmalloc-128", 128},
- {"kmalloc-256", 256}, {"kmalloc-512", 512},
- {"kmalloc-1k", 1024}, {"kmalloc-2k", 2048},
- {"kmalloc-4k", 4096}, {"kmalloc-8k", 8192},
- {"kmalloc-16k", 16384}, {"kmalloc-32k", 32768},
- {"kmalloc-64k", 65536}, {"kmalloc-128k", 131072},
- {"kmalloc-256k", 262144}, {"kmalloc-512k", 524288},
- {"kmalloc-1M",1048576}, {"kmalloc-2M",2097152},
- {"kmalloc-4M",4194304}, {"kmalloc-8M",8388608},
- {"kmalloc-16M", 16777216}, {"kmalloc-32M", 33554432},
- {"kmalloc-64M", 67108864}
+ INIT_KMALLOC_INFO(0, 0),
+ INIT_KMALLOC_INFO(96, 96),
+ INIT_KMALLOC_INFO(192, 192),
+ INIT_KMALLOC_INFO(8, 8),
+ INIT_KMALLOC_INFO(16, 16),
+ INIT_KMALLOC_INFO(32, 32),
+ INIT_KMALLOC_INFO(64, 64),
+ INIT_KMALLOC_INFO(128, 128),
+ INIT_KMALLOC_INFO(256, 256),
+ INIT_KMALLOC_INFO(512, 512),
+ INIT_KMALLOC_INFO(1024, 1k),
+ INIT_KMALLOC_INFO(2048, 2k),
+ INIT_KMALLOC_INFO(4096, 4k),
+ INIT_KMALLOC_INFO(8192, 8k),
+ INIT_KMALLOC_INFO(16384, 16k),
+ INIT_KMALLOC_INFO(32768, 32k),
+ INIT_KMALLOC_INFO(65536, 64k),
+ INIT_KMALLOC_INFO(131072, 128k),
+ INIT_KMALLOC_INFO(262144, 256k),
+ INIT_KMALLOC_INFO(524288, 512k),
+ INIT_KMALLOC_INFO(1048576, 1M),
+ INIT_KMALLOC_INFO(2097152, 2M),
+ INIT_KMALLOC_INFO(4194304, 4M),
+
[PATCH v5 0/7] mm, slab: Make kmalloc_info[] contain all types of names
Changes in v5 -- 1. patch 1/7: - rename SET_KMALLOC_SIZE to INIT_KMALLOC_INFO 2. patch 5/7: - fix build errors (Reported-by: kbuild test robot) - make all_kmalloc_info[] static (Reported-by: kbuild test robot) 3. patch 6/7: - for robustness, determine kmalloc_cache is !NULL in new_kmalloc_cache() 4. add ack tag from David Rientjes Changes in v4 -- 1. [old] abandon patch 4/4 2. [new] patch 4/7: - return ZERO_SIZE_ALLOC instead 0 for zero sized requests 3. [new] patch 5/7: - reorder kmalloc_info[], kmalloc_caches[] (in order of size) - hard to split, so slightly larger 4. [new] patch 6/7: - initialize kmalloc_cache[] with the same size but different types 5. [new] patch 7/7: - modify kmalloc_caches[type][idx] to kmalloc_caches[idx][type] Patch 4-7 are newly added, more information can be obtained from commit messages. Changes in v3 -- 1. restore __initconst (patch 1/4) 2. rename patch 3/4 3. add more clarification for patch 4/4 4. add ack tag from Roman Gushchin Changes in v2 -- 1. remove __initconst (patch 1/5) 2. squash patch 2/5 3. add ack tag from Vlastimil Babka There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM and KMALLOC_DMA. The name of KMALLOC_NORMAL is contained in kmalloc_info[].name, but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically generated by kmalloc_cache_name(). Patch1 predefines the names of all types of kmalloc to save the time spent dynamically generating names. These changes make sense, and the time spent by new_kmalloc_cache() has been reduced by approximately 36.3%. Time spent by new_kmalloc_cache() (CPU cycles) 5.3-rc7 66264 5.3-rc7+patch_1-342188 bloat-o-meter -- $ ./scripts/bloat-o-meter vmlinux_5.3 vmlinux_5.3+patch_1-7 add/remove: 1/2 grow/shrink: 6/65 up/down: 872/-1574 (-702) Function old new delta all_kmalloc_info - 832+832 crypto_create_tfm211 225 +14 ieee80211_key_alloc 11591169 +10 nl80211_parse_sched_scan27872795 +8 tg3_self_test 42554259 +4 find_get_context.isra634 637 +3 sd_probe 947 948 +1 nf_queue 671 670 -1 trace_parser_get_init 71 69 -2 pkcs7_verify.cold318 316 -2 units323 320 -3 nl80211_set_reg 642 639 -3 pkcs7_verify15031495 -8 i915_sw_fence_await_dma_fence445 437 -8 nla_strdup 143 134 -9 kmalloc_slab 102 93 -9 xhci_alloc_tt_info 349 338 -11 xhci_segment_alloc 303 289 -14 xhci_alloc_container_ctx 221 207 -14 xfrm_policy_alloc277 263 -14 selinux_sk_alloc_security119 105 -14 sdev_evt_send_simple 124 110 -14 sdev_evt_alloc85 71 -14 sbitmap_queue_init_node 424 410 -14 regulatory_hint_found_beacon 400 386 -14 nf_ct_tmpl_alloc 91 77 -14 gss_create_cred 146 132 -14 drm_flip_work_allocate_task 76 62 -14 cfg80211_stop_iface 266 252 -14 cfg80211_sinfo_alloc_tid_stats83 69 -14 cfg80211_port_authorized 218 204 -14 cfg80211_ibss_joined 341 327 -14 call_usermodehelper_setup155 141 -14 bpf_prog_alloc_no_stats 188 174 -14 blk_alloc_flush_queue197 183 -14 bdi_alloc_node 201 187 -14 _netlbl_catmap_getnode 253 239 -14 __igmp_group_dropped 629 615 -14 ip_mc_inc_group 481 467 -14 xhci_alloc_command 221 205 -16 audit_log_d_path 204 188 -16 xprt_switch_alloc145 128 -17 xhci_ring_alloc 378 361 -17 xhci_mem_init 36733656 -17 xhci_alloc_virt_device 505 488 -17 xhci_alloc_stream_info 727 710 -17
Re: [PATCH for 5.3 3/3] rseq/selftests: Fix: Namespace gettid() for compatibility with glibc 2.30
- On Sep 14, 2019, at 3:47 PM, Sasha Levin sas...@kernel.org wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.2.14, v4.19.72, v4.14.143,
> v4.9.192,
> v4.4.192.
>
> v5.2.14: Build OK!
> v4.19.72: Build OK!
> v4.14.143: Failed to apply! Possible dependencies:
>c960e9909d33 ("rseq/selftests: Provide parametrized tests")
>
> v4.9.192: Failed to apply! Possible dependencies:
>c960e9909d33 ("rseq/selftests: Provide parametrized tests")
>
> v4.4.192: Failed to apply! Possible dependencies:
>c960e9909d33 ("rseq/selftests: Provide parametrized tests")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
rseq was merged into 4.18, so none of those patches are needed prior to that
kernel version.
This applies to all 3 rseq patches.
Thanks,
Mathieu
>
> --
> Thanks,
> Sasha
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
On Thu, 12 Sep 2019 08:05:41 -0400
Qian Cai wrote:
> > drivers/char/random.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/char/random.c b/drivers/char/random.c
> > index 9b54cdb301d3..975015857200 100644
> > --- a/drivers/char/random.c
> > +++ b/drivers/char/random.c
> > @@ -1687,8 +1687,9 @@ static void _warn_unseeded_randomness(const char
> > *func_name, void *caller,
> > print_once = true;
> > #endif
> > if (__ratelimit(_warning))
> > - pr_notice("random: %s called from %pS with crng_init=%d\n",
> > - func_name, caller, crng_init);
> > + printk_deferred(KERN_NOTICE "random: %s called from %pS "
> > + "with crng_init=%d\n", func_name, caller,
> > + crng_init);
> > }
> >
> > /*
> > @@ -2462,4 +2463,4 @@ void add_bootloader_randomness(const void *buf,
> > unsigned int size)
> > else
> > add_device_randomness(buf, size);
> > }
> > -EXPORT_SYMBOL_GPL(add_bootloader_randomness);
> > \ No newline at end of file
> > +EXPORT_SYMBOL_GPL(add_bootloader_randomness);
>
> This will also fix the hang.
>
> Sergey, do you plan to submit this Ted?
Perhaps for a quick fix (and a comment that says this needs to be fixed
properly). I think the changes to printk() that was discussed at
Plumbers may also solve this properly.
-- Steve
Hi dear,
Hi dear, I'm Jessica Vail, from the United States,please i wish to have a communication with you. I am waiting for your answer, Jessica Vail.
Re: [PATCH v6 01/12] tools lib traceevent: Convert remaining %p[fF] users to %p[sS]
On Mon, 16 Sep 2019 14:41:59 +0300 Sakari Ailus wrote: > > Well, if you think that works, OK great. > > > > But could that work? > > How would an individual trace record know if > > another trace record used %pfw? > > > > Perhaps not reusing %pf, marking it reserved > > for a period of years, and using another unused > > prefix %p like %pnfw may be simpler. > > %p[Ff]w does not exist (I grepped for it) in older kernels since v3.0. So > kernel support for %p[fF] and %pfw are mutually exclusive. If you're ok > with that, I could change the patch to check %pf isn't followed by 'w', > in order to support %pf on older kernels. I think that's what I suggested to do. > > Although that still does not address using older tooling on newer kernels > with support for %pfw. That should be fine. I don't think it will crash those tools, they will just give out wrong information, and if people complain, we can try to get them to use the newer version of those tools ;-) (hopefully they don't complain to Linus). > > If you think that's an issue, I'll opt for another extension than %pfw, > which I chose originally since it's memorable --- fw for fwnode (names, > paths, and probably more in the future). > I'm fine with the switch, as long as newer tools know how to handle it. Make sure we also add a comment in the Linux kernel code that states that older kernels use to have 'f' and 'F' and that new tools look for 'fw' to denote that this isn't an older kernel. This way, people will hopefully not add another 'fX' pointer name. -- Steve
Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
On Sat, Sep 14, 2019 at 04:10:22AM +, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Andrew Murray
> > Sent: 2019年9月12日 20:50
> > To: Xiaowei Bao
> > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> > Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> > Lian ; Mingkai Hu ; Roy
> > Zang ; jingooh...@gmail.com;
> > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> > a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> >
> > Subject: Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for
> > ls1088a and ls2088a
> >
> > On Tue, Sep 03, 2019 at 01:47:36AM +, Xiaowei Bao wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Andrew Murray
> > > > Sent: 2019年9月2日 20:46
> > > > To: Xiaowei Bao
> > > > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > > > Leo Li ; kis...@ti.com; lorenzo.pieral...@arm.com;
> > M.h.
> > > > Lian ; Mingkai Hu ; Roy
> > > > Zang ; jingooh...@gmail.com;
> > > > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> > > > a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> > > >
> > > > Subject: Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support
> > > > for ls1088a and ls2088a
> > > >
> > > > On Mon, Sep 02, 2019 at 11:17:14AM +0800, Xiaowei Bao wrote:
> > > > > Add PCIe EP mode support for ls1088a and ls2088a, there are some
> > > > > difference between LS1 and LS2 platform, so refactor the code of
> > > > > the EP driver.
> > > > >
> > > > > Signed-off-by: Xiaowei Bao
> > > > > ---
> > > > > v2:
> > > > > - This is a new patch for supporting the ls1088a and ls2088a
> > > > > platform.
> > > > > v3:
> > > > > - Adjust the some struct assignment order in probe function.
> > > > >
> > > > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 72
> > > > > +++---
> > > > > 1 file changed, 53 insertions(+), 19 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > index 5f0cb99..723bbe5 100644
> > > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > @@ -20,27 +20,29 @@
> > > > >
> > > > > #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> > > > >
> > > > > -struct ls_pcie_ep {
> > > > > - struct dw_pcie *pci;
> > > > > - struct pci_epc_features *ls_epc;
> > > > > +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > > +
> > > > > +struct ls_pcie_ep_drvdata {
> > > > > + u32 func_offset;
> > > > > + const struct dw_pcie_ep_ops *ops;
> > > > > + const struct dw_pcie_ops*dw_pcie_ops;
> > > > > };
> > > > >
> > > > > -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > > +struct ls_pcie_ep {
> > > > > + struct dw_pcie *pci;
> > > > > + struct pci_epc_features *ls_epc;
> > > > > + const struct ls_pcie_ep_drvdata *drvdata; };
> > > > >
> > > > > static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > > > > +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > > > > .start_link = ls_pcie_establish_link, };
> > > > >
> > > > > -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > > > - { .compatible = "fsl,ls-pcie-ep",},
> > > > > - { },
> > > > > -};
> > > > > -
> > > > > static const struct pci_epc_features*
> > > > > ls_pcie_ep_get_features(struct dw_pcie_ep *ep) { @@ -87,10 +89,39
> > > > > @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > > > > }
> > > > > }
> > > > >
> > > > > -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > > > > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep
> > *ep,
> > > > > + u8 func_no)
> > > > > +{
> > > > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > > > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > > > +
> > > > > + WARN_ON(func_no && !pcie->drvdata->func_offset);
> > > > > + return pcie->drvdata->func_offset * func_no; }
> > > > > +
> > > > > +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > > > > .ep_init = ls_pcie_ep_init,
> > > > > .raise_irq = ls_pcie_ep_raise_irq,
> > > > > .get_features = ls_pcie_ep_get_features,
> > > > > + .func_conf_select = ls_pcie_ep_func_conf_select, };
> > > > > +
> > > > > +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > > > > + .ops = _pcie_ep_ops,
> > > >
Re: [PATCH 2/3] spi: dw: Add basic runtime PM support
Hi Gareth,
On Fri, Sep 13, 2019 at 2:13 PM Gareth Williams
wrote:
> From: Phil Edworthy
>
> Enable runtime PM so that the clock used to access the registers in the
> peripheral is turned on using a clock domain.
>
> Signed-off-by: Phil Edworthy
> Signed-off-by: Gareth Williams
Thanks for your patch!
> --- a/drivers/spi/spi-dw.c
> +++ b/drivers/spi/spi-dw.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -497,6 +498,9 @@ int dw_spi_add_host(struct device *dev, struct dw_spi
> *dws)
> if (dws->set_cs)
> master->set_cs = dws->set_cs;
>
> + pm_runtime_enable(dev);
> + pm_runtime_get_sync(dev);
The second line keeps the device powered all the time.
What about setting spi_controller.auto_runtime_pm = true, so the SPI
code can manage its Runtime PM status?
> +
> /* Basic HW init */
> spi_hw_init(dev, dws);
>
What about the error path?
Don't you need to disable Runtime PM again in dw_spi_remove_host()?
I assume this will be called from drivers/spi/spi-dw-mmio.c, which already
enables the clock explicitly all the timer?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] arm: fix page faults in do_alignment
Russell King - ARM Linux admin writes:
> On Fri, Sep 06, 2019 at 04:17:59PM +0100, Russell King - ARM Linux admin
> wrote:
>> On Mon, Sep 02, 2019 at 12:36:56PM -0500, Eric W. Biederman wrote:
>> > Russell King - ARM Linux admin writes:
>> >
>> > > On Fri, Aug 30, 2019 at 04:02:48PM -0500, Eric W. Biederman wrote:
>> > >> Russell King - ARM Linux admin writes:
>> > >>
>> > >> > On Fri, Aug 30, 2019 at 02:45:36PM -0500, Eric W. Biederman wrote:
>> > >> >> Russell King - ARM Linux admin writes:
>> > >> >>
>> > >> >> > On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
>> > >> >> >> The function do_alignment can handle misaligned address for user
>> > >> >> >> and
>> > >> >> >> kernel space. If it is a userspace access, do_alignment may fail
>> > >> >> >> on
>> > >> >> >> a low-memory situation, because page faults are disabled in
>> > >> >> >> probe_kernel_address.
>> > >> >> >>
>> > >> >> >> Fix this by using __copy_from_user stead of probe_kernel_address.
>> > >> >> >>
>> > >> >> >> Fixes: b255188 ("ARM: fix scheduling while atomic warning in
>> > >> >> >> alignment handling code")
>> > >> >> >> Signed-off-by: Jing Xiangfeng
>> > >> >> >
>> > >> >> > NAK.
>> > >> >> >
>> > >> >> > The "scheduling while atomic warning in alignment handling code" is
>> > >> >> > caused by fixing up the page fault while trying to handle the
>> > >> >> > mis-alignment fault generated from an instruction in atomic
>> > >> >> > context.
>> > >> >> >
>> > >> >> > Your patch re-introduces that bug.
>> > >> >>
>> > >> >> And the patch that fixed scheduling while atomic apparently
>> > >> >> introduced a
>> > >> >> regression. Admittedly a regression that took 6 years to track down
>> > >> >> but
>> > >> >> still.
>> > >> >
>> > >> > Right, and given the number of years, we are trading one regression
>> > >> > for
>> > >> > a different regression. If we revert to the original code where we
>> > >> > fix up, we will end up with people complaining about a "new"
>> > >> > regression
>> > >> > caused by reverting the previous fix. Follow this policy and we just
>> > >> > end up constantly reverting the previous revert.
>> > >> >
>> > >> > The window is very small - the page in question will have had to have
>> > >> > instructions read from it immediately prior to the handler being
>> > >> > entered,
>> > >> > and would have had to be made "old" before subsequently being
>> > >> > unmapped.
>> > >>
>> > >> > Rather than excessively complicating the code and making it even more
>> > >> > inefficient (as in your patch), we could instead retry executing the
>> > >> > instruction when we discover that the page is unavailable, which
>> > >> > should
>> > >> > cause the page to be paged back in.
>> > >>
>> > >> My patch does not introduce any inefficiencies. It onlys moves the
>> > >> check for user_mode up a bit. My patch did duplicate the code.
>> > >>
>> > >> > If the page really is unavailable, the prefetch abort should cause a
>> > >> > SEGV to be raised, otherwise the re-execution should replace the page.
>> > >> >
>> > >> > The danger to that approach is we page it back in, and it gets paged
>> > >> > back out before we're able to read the instruction indefinitely.
>> > >>
>> > >> I would think either a little code duplication or a function that looks
>> > >> at user_mode(regs) and picks the appropriate kind of copy to do would be
>> > >> the best way to go. Because what needs to happen in the two cases for
>> > >> reading the instruction are almost completely different.
>> > >
>> > > That is what I mean. I'd prefer to avoid that with the large chunk of
>> > > code. How about instead adding a local replacement for
>> > > probe_kernel_address() that just sorts out the reading, rather than
>> > > duplicating all the code to deal with thumb fixup.
>> >
>> > So something like this should be fine?
>> >
>> > Jing Xiangfeng can you test this please? I think this fixes your issue
>> > but I don't currently have an arm development box where I could test this.
>>
>> Sorry, only just got around to this again. What I came up with is this:
>
> I've heard nothing, so I've done nothing...
Sorry it wasn't clear you were looking for feedback.
This looks functionally equivalent to the last test version I posted and
that Jing Xiangfeng confirms solves his issue.
So I say please merge whichever version you like.
Eric
>> 8<===
>> From: Russell King
>> Subject: [PATCH] ARM: mm: fix alignment
>>
>> Signed-off-by: Russell King
>> ---
>> arch/arm/mm/alignment.c | 44
>> 1 file changed, 36 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
>> index 6067fa4de22b..529f54d94709 100644
>> --- a/arch/arm/mm/alignment.c
>> +++ b/arch/arm/mm/alignment.c
>> @@ -765,6 +765,36 @@ do_alignment_t32_to_handler(unsigned long *pinstr,
>> struct pt_regs *regs,
>> return NULL;
>> }
>>
>> +static int
Re: [PATCH 4/4] dmaengine: imx-sdma: drop redundant variable
On Mi, 2019-09-11 at 16:49 +0200, Philipp Puschmann wrote:
> In sdma_prep_dma_cyclic buf is redundant. Drop it.
>
> Signed-off-by: Philipp Puschmann
Reviewed-by: Lucas Stach
> ---
> drivers/dma/imx-sdma.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 6a5a84504858..5b6b9f0e 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -1544,7 +1544,7 @@ static struct dma_async_tx_descriptor
> *sdma_prep_dma_cyclic(
> struct sdma_engine *sdma = sdmac->sdma;
> int num_periods = buf_len / period_len;
> int channel = sdmac->channel;
> - int i = 0, buf = 0;
> + int i;
> struct sdma_desc *desc;
>
> dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
> @@ -1565,7 +1565,7 @@ static struct dma_async_tx_descriptor
> *sdma_prep_dma_cyclic(
> goto err_bd_out;
> }
>
> - while (buf < buf_len) {
> + for (i = 0; i < num_periods; i++) {
> struct sdma_buffer_descriptor *bd = >bd[i];
> int param;
>
> @@ -1592,9 +1592,6 @@ static struct dma_async_tx_descriptor
> *sdma_prep_dma_cyclic(
> bd->mode.status = param;
>
> dma_addr += period_len;
> - buf += period_len;
> -
> - i++;
> }
>
> return vchan_tx_prep(>vc, >vd, flags);
Re: printk meeting at LPC
On 2019-09-16, Steven Rostedt wrote:
6. A new may-sleep function pr_flush() will be made available to
wait for all previously printk'd messages to be output on all
consoles before proceeding. For example:
pr_cont("Running test ABC... ");
pr_flush();
do_test();
pr_cont("PASSED\n");
pr_flush();
>>>
>>> Don't we need to allow printk() callers to know the sequence number
>>> which the printk() has queued? Something like
>>>
>>> u64 seq;
>>> pr_info(...);
>>> pr_info(...);
>>> pr_info(...);
>>> seq = pr_current_seq();
>>> pr_wait_seq(seq);
>>>
>>> in case concurrently executed printk() flooding keeps adding a lot
>>> of pending output?
>>
>> My expectation is that pr_flush() would wait only until the current
>> message appears on all consoles. It will not wait for messages that
>> would get added later.
>
> Right, I believe we agreed that pr_flush() would take care of all this.
Yes, this is what we agreed on.
9. Support for printk dictionaries will be discontinued. I will
look into who is using this and why. If printk dictionaries are
important for you, speak up now!
>>>
>>> I think that dev_printk() is using "const char *dict, size_t
>>> dictlen," part via create_syslog_header(). Some userspace programs
>>> might depend on availability of such information.
>>
>> Yeah, but it seems to be the only dictionary writer. There were
>> doubts (during the meeting) whether anyone was actually using the
>> information.
>>
>> Hmm, it seems that journalctl is able to filer device specific
>> information, for example, I get:
>>
>> $> journalctl _KERNEL_DEVICE=+usb:2-1
>> -- Logs begin at Tue 2019-08-13 09:00:03 CEST, end at Mon 2019-09-16
>> 12:32:58 CEST. --
>> Aug 13 09:00:04 linux-qszd kernel: usb 2-1: new high-speed USB device number
>> 2 using ehci-pci
>>
>> One question is if anyone is using this filtering. Simple grep is
>> enough. Another question is whether it really needs to get passed
>> this way.
>>
>
> If worse comes to worse, perhaps we let the console decide what to do
> with it. Where all consoles but the "kmsg" one ignores it?
>
> Then journalctl should work as normal.
>
> Or will this break one of our other changes?
The consoles will just iterate the ringbuffer. So if any console needs
dictionary information, that information needs to be stored in the
ringbuffer as well.
The dictionary text and message text could be stored as concatenated
strings. The descriptor would point separately to the beginning of
dictionary and message. So the data-buffer would still be a clean
collection of text. But AFAIK Linus didn't want to see that "extra" text
at all.
If we want to keep dictionary text out of the data-buffer, we could have
a 2nd data-buffer dedicated for dictionary text. I expect it would not
really complicate things. Especially if the dictionary part was "best
effort" (i.e. if the dictionary text does not fit in the free part of
its data-buffer, it is dropped).
John Ogness
Re: [PATCH] x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area.
On 9/16/19 2:00 AM, Kirill A. Shutemov wrote: >>> I think we also need to make it clear that this is workaround for a broken >>> hardware: speculative execution must not trigger a halt. >> I think the word broken is a bit loaded here. According to the UEFI >> spec (version 2.8, page 167), "Regions that are backed by the physical >> hardware, but are not supposed to be accessed by the OS, must be >> returned as EfiReservedMemoryType." Our interpretation is that >> includes speculative accesses. > +Dave. > > I don't think it is. Speculative access is done by hardware, not OS. > > BTW, isn't it a BIOS issue? > > I believe it should have a way to hide a range of physical address space > from OS or force a caching mode on to exclude it from speculative > execution. Like setup MTRRs or something. Ugh. I bet that was a fun one to chase down. Have the hardware engineers learned a lesson or are they hiding behind the EFI spec in an act of pure cowardice? ;) The patch is small and fixes a real problem. The changelog is OK, although I'd prefer some differentiation between "occupied by the kernel" and the kernel *image*. The code is also gloriously free of any comments about what it's doing or why. But, I'm left with lots of questions: Why do PMD-level changes fix this? Is it because we 2MB pad the kernel image? Why can't we still get within 2MB of the memory address in question? Is it in the lower 1MB, by chance? If this is all about avoiding EFI reserved ranges, why doesn't the patch *LOOK* At EFI reserved ranges?
Re: [PATCH 3/4] serial: imx: adapt rx buffer and dma periods
On Mi, 2019-09-11 at 16:49 +0200, Philipp Puschmann wrote:
> Using only 4 DMA periods for UART RX is very few if we have a high
> frequency of small transfers - like in our case using Bluetooth with many
> small packets via UART - causing many dma transfers but in each only
> filling a fraction of a single buffer. Such a case may lead to the
> situation that DMA RX transfer is triggered but no buffer is available.
> While we have addressed the dma handling already we still want to avoid
> UART RX FIFO overrun. So we decrease the size of the buffers and increase
> their number and the total buffer size.
>
> Signed-off-by: Philipp Puschmann
Reasoning seems sound:
Reviewed-by: Lucas Stach
> ---
> drivers/tty/serial/imx.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 57d6e6ba556e..cdc51569237c 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1028,8 +1028,6 @@ static void imx_uart_timeout(struct timer_list *t)
> }
> }
>
> -#define RX_BUF_SIZE (PAGE_SIZE)
> -
> /*
> * There are two kinds of RX DMA interrupts(such as in the MX6Q):
> * [1] the RX DMA buffer is full.
> @@ -1112,7 +1110,8 @@ static void imx_uart_dma_rx_callback(void *data)
> }
>
> /* RX DMA buffer periods */
> -#define RX_DMA_PERIODS 4
> +#define RX_DMA_PERIODS 16
> +#define RX_BUF_SIZE (PAGE_SIZE / 4)
>
> static int imx_uart_start_rx_dma(struct imx_port *sport)
> {
Re: [PATCH 2/4] dmaengine: imx-sdma: fix dma freezes
On Mi, 2019-09-11 at 16:49 +0200, Philipp Puschmann wrote:
> For some years and since many kernel versions there are reports that the
> RX UART SDMA channel stops working at some point. The workaround was to
> disable DMA for RX. This commit tries to fix the problem itself.
>
> Due to its license i wasn't able to debug the sdma script itself but it
> somehow leads to blocking the scheduling of the channel script when a
> running sdma script does not find any usable destination buffer to put its
> data into.
>
> If we detect such a potential case we manually retrigger the sdma script
> for this channel and by this reenable the scipt being run by scheduler.
>
> As sdmac->desc is constant we can move desc out of the loop.
>
> Signed-off-by: Philipp Puschmann
> ---
> drivers/dma/imx-sdma.c | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 1abb14ff394d..6a5a84504858 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -775,21 +775,23 @@ static void sdma_start_desc(struct sdma_channel *sdmac)
> static void sdma_update_channel_loop(struct sdma_channel *sdmac)
> {
> struct sdma_buffer_descriptor *bd;
> - int error = 0;
> - enum dma_status old_status = sdmac->status;
> + struct sdma_desc *desc = sdmac->desc;
> + int error = 0, cnt = 0;
> + enum dma_status old_status = sdmac->status;
>
> /*
>* loop mode. Iterate over descriptors, re-setup them and
>* call callback function.
>*/
> - while (sdmac->desc) {
> - struct sdma_desc *desc = sdmac->desc;
> + while (desc) {
>
> bd = >bd[desc->buf_tail];
>
> if (bd->mode.status & BD_DONE)
> break;
>
> + cnt++;
> +
> if (bd->mode.status & BD_RROR) {
> bd->mode.status &= ~BD_RROR;
> sdmac->status = DMA_ERROR;
> @@ -821,6 +823,18 @@ static void sdma_update_channel_loop(struct sdma_channel
> *sdmac)
> if (error)
> sdmac->status = old_status;
> }
> +
> + /* In some situations it happens that the sdma stops serving
> + * dma interrupt requests. It happens when running dma script
> + * does not find any usable destination buffer to put its data into.
> + *
This part of the comment is slightly confusing, as what happens is that
the SDMA channel is stopped when there are no free descriptors in the
ring anymore. After the channel is stopped it needs to be kicked back
to life after there are descriptors available again.
But apart from this nitpick the change looks good to me:
Reviewed-by: Lucas Stach
Regards,
Lucas
> + * While there is no specific error condition we can check for, a
> + * necessary condition is that all available buffers for the current
> + * channel have been written to by the sdma script. In such a case we
> + * will trigger the sdma script manually.
> + */
> + if (cnt >= desc->num_bd)
> + sdma_enable_channel(sdmac->sdma, sdmac->channel);
> }
>
> static void mxc_sdma_handle_channel_normal(struct sdma_channel *data)
RE: [PATCH] x86_64: new and improved memset()
From: Alexey Dobriyan > Sent: 14 September 2019 11:34 ... > +ENTRY(memset0_rep_stosq) > + xor eax, eax > +.globl memsetx_rep_stosq > +memsetx_rep_stosq: > + lea rsi, [rdi + rcx] > + shr rcx, 3 > + rep stosq > + cmp rdi, rsi > + je 1f > +2: > + mov [rdi], al > + add rdi, 1 > + cmp rdi, rsi > + jne 2b > +1: > + ret You can do the 'trailing bytes' first with a potentially misaligned store. Something like (modulo asm syntax and argument ordering): lea rsi, [rdi + rdx] shr rcx, 3 jcxz1f # Short buffer mov -8[rsi], rax rep stosq ret 1: mov [rdi], al add rdi, 1 cmp rdi, rsi jne 1b ret The final loop can be one instruction shorter by arranging to do: 1: mov [rdi+rxx], al add rdi, 1 jnz 1b ret Last I looked 'jcxz' was 'ok' on all recent amd and intel cpus. OTOH 'loop' is horrid on intel ones. The same applies to the other versions. I suspect it isn't worth optimising to realign misaligned buffers they are unlikely to happen often enough. I also think that gcc's __builtin version does some of the short buffer optimisations already. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH 1/4] dmaengine: imx-sdma: fix buffer ownership
On Mi, 2019-09-11 at 16:49 +0200, Philipp Puschmann wrote: > BD_DONE flag marks ownership of the buffer. When 1 SDMA owns the buffer, > when 0 ARM owns it. When processing the buffers in > sdma_update_channel_loop the ownership of the currently processed buffer > was set to SDMA again before running the callback function of the the > buffer and while the sdma script may be running in parallel. So there was > the possibility to get the buffer overwritten by SDMA before it has been > processed by kernel leading to kind of random errors in the upper layers, > e.g. bluetooth. > > It may be further a good idea to make the status struct member volatile or > access it using writel or similar to rule out that the compiler sets the > BD_DONE flag before the callback routine has finished. > > Signed-off-by: Philipp Puschmann > --- > drivers/dma/imx-sdma.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c > index a01f4b5d793c..1abb14ff394d 100644 > --- a/drivers/dma/imx-sdma.c > +++ b/drivers/dma/imx-sdma.c > @@ -802,7 +802,6 @@ static void sdma_update_channel_loop(struct sdma_channel > *sdmac) > */ > > desc->chn_real_count = bd->mode.count; > - bd->mode.status |= BD_DONE; > bd->mode.count = desc->period_len; > desc->buf_ptail = desc->buf_tail; > desc->buf_tail = (desc->buf_tail + 1) % desc->num_bd; > @@ -817,6 +816,8 @@ static void sdma_update_channel_loop(struct sdma_channel > *sdmac) > dmaengine_desc_get_callback_invoke(>vd.tx, NULL); > spin_lock(>vc.lock); To address your comment from the second paragraph of the commit message there should be a dma_wmb() here before changing the status flag. Regards, Lucas > + bd->mode.status |= BD_DONE; > + > if (error) > sdmac->status = old_status; > }
Re: [PATCH v6 0/3] genirq/vfio: Introduce irq_update_devid() and optimize VFIO irq ops
On Fri, 13 Sep 2019, Alex Williamson wrote: > On Tue, 10 Sep 2019 14:30:16 +0800 > Ben Luo wrote: > > > A friendly reminder. > > The vfio patch looks ok to me. Thomas, do you have further comments or > a preference on how to merge these? I'd tend to prefer the vfio > changes through my branch for testing and can pull the irq changes with > your approval, but we could do the reverse or split them and I could > follow with the vfio change once the irq changes are in mainline. I can provide you a branch, once I looked again at that stuff. It's somewhere in that huge conference induced backlog. Thanks, tglx
Re: [PATCH v3 2/2] mm: fix double page fault on arm64 if PTE_AF is cleared
On Mon, Sep 16, 2019 at 09:35:21AM +, Justin He (Arm Technology China)
wrote:
>
> Hi Kirill
> > -Original Message-
> > From: Kirill A. Shutemov
> > Sent: 2019年9月16日 17:16
> > To: Justin He (Arm Technology China)
> > Cc: Catalin Marinas ; Will Deacon
> > ; Mark Rutland ; James Morse
> > ; Marc Zyngier ; Matthew
> > Wilcox ; Kirill A. Shutemov
> > ; linux-arm-ker...@lists.infradead.org;
> > linux-kernel@vger.kernel.org; linux...@kvack.org; Punit Agrawal
> > ; Anshuman Khandual
> > ; Jun Yao ;
> > Alex Van Brunt ; Robin Murphy
> > ; Thomas Gleixner ;
> > Andrew Morton ; Jérôme Glisse
> > ; Ralph Campbell ;
> > hejia...@gmail.com
> > Subject: Re: [PATCH v3 2/2] mm: fix double page fault on arm64 if PTE_AF
> > is cleared
> >
> > On Sat, Sep 14, 2019 at 12:32:39AM +0800, Jia He wrote:
> > > When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest,
> > there
> > > will be a double page fault in __copy_from_user_inatomic of
> > cow_user_page.
> > >
> > > Below call trace is from arm64 do_page_fault for debugging purpose
> > > [ 110.016195] Call trace:
> > > [ 110.016826] do_page_fault+0x5a4/0x690
> > > [ 110.017812] do_mem_abort+0x50/0xb0
> > > [ 110.018726] el1_da+0x20/0xc4
> > > [ 110.019492] __arch_copy_from_user+0x180/0x280
> > > [ 110.020646] do_wp_page+0xb0/0x860
> > > [ 110.021517] __handle_mm_fault+0x994/0x1338
> > > [ 110.022606] handle_mm_fault+0xe8/0x180
> > > [ 110.023584] do_page_fault+0x240/0x690
> > > [ 110.024535] do_mem_abort+0x50/0xb0
> > > [ 110.025423] el0_da+0x20/0x24
> > >
> > > The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> > > [9b007000] pgd=00023d4f8003, pud=00023da9b003,
> > pmd=00023d4b3003, pte=36298607bd3
> > >
> > > As told by Catalin: "On arm64 without hardware Access Flag, copying
> > from
> > > user will fail because the pte is old and cannot be marked young. So we
> > > always end up with zeroed page after fork() + CoW for pfn mappings. we
> > > don't always have a hardware-managed access flag on arm64."
> > >
> > > This patch fix it by calling pte_mkyoung. Also, the parameter is
> > > changed because vmf should be passed to cow_user_page()
> > >
> > > [1]
> > https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
> > >
> > > Reported-by: Yibo Cai
> > > Signed-off-by: Jia He
> > > ---
> > > mm/memory.c | 30 +-
> > > 1 file changed, 25 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index e2bb51b6242e..a64af6495f71 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> > > 2;
> > > #endif
> > >
> > > +#ifndef arch_faults_on_old_pte
> > > +static inline bool arch_faults_on_old_pte(void)
> > > +{
> > > + return false;
> > > +}
> > > +#endif
> > > +
> > > static int __init disable_randmaps(char *s)
> > > {
> > > randomize_va_space = 0;
> > > @@ -2140,7 +2147,8 @@ static inline int pte_unmap_same(struct
> > mm_struct *mm, pmd_t *pmd,
> > > return same;
> > > }
> > >
> > > -static inline void cow_user_page(struct page *dst, struct page *src,
> > unsigned long va, struct vm_area_struct *vma)
> > > +static inline void cow_user_page(struct page *dst, struct page *src,
> > > + struct vm_fault *vmf)
> > > {
> > > debug_dma_assert_idle(src);
> > >
> > > @@ -2152,20 +2160,32 @@ static inline void cow_user_page(struct page
> > *dst, struct page *src, unsigned lo
> > > */
> > > if (unlikely(!src)) {
> > > void *kaddr = kmap_atomic(dst);
> > > - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> > > + void __user *uaddr = (void __user *)(vmf->address &
> > PAGE_MASK);
> > > + pte_t entry;
> > >
> > > /*
> > > * This really shouldn't fail, because the page is there
> > > * in the page tables. But it might just be unreadable,
> > > * in which case we just give up and fill the result with
> > > -* zeroes.
> > > +* zeroes. If PTE_AF is cleared on arm64, it might
> > > +* cause double page fault. So makes pte young here
> > > */
> > > + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte))
> > {
> > > + spin_lock(vmf->ptl);
> > > + entry = pte_mkyoung(vmf->orig_pte);
> >
> > Should't you re-validate that orig_pte after re-taking ptl? It can be
> > stale by now.
> Thanks, do you mean flush_cache_page(vma, vmf->address,
> pte_pfn(vmf->orig_pte))
> before pte_mkyoung?
No. You need to check pte_same(*vmf->pte, vmf->orig_pte) before modifying
anything and bail out if *vmf->pte has changed under you.
--
Kirill A. Shutemov
[PATCH] connector: report comm change event when modifying /proc/pid/task/tid/comm
Commit f786ecba41588 ("connector: add comm change event report to proc
connector") added proc_comm_connector to report comm change event, and
prctl will report comm change event when dealing with PR_SET_NAME case.
prctl can only set the name of the calling thread. In order to set the name
of other threads in a process, modifying /proc/self/task/tid/comm is a
general way.It's exactly how pthread_setname_np do to set name of a thread.
It's unable to get comm change event of thread if the name of thread is set
by other thread via pthread_setname_np. This update provides a chance for
application to monitor and control threads whose name is set by other
threads.
Signed-off-by: KeMeng Shi
---
fs/proc/base.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ebea9501afb8..34ffe572ac69 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -94,6 +94,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
#include "fd.h"
@@ -1549,10 +1550,12 @@ static ssize_t comm_write(struct file *file, const char
__user *buf,
if (!p)
return -ESRCH;
- if (same_thread_group(current, p))
+ if (same_thread_group(current, p)) {
set_task_comm(p, buffer);
- else
+ proc_comm_connector(p);
+ } else {
count = -EINVAL;
+ }
put_task_struct(p);
--
2.19.1
Re: [HELP REQUESTED from the community] Was: Staging status of speakup
On Mon, Sep 16, 2019 at 03:47:28PM +0200, Samuel Thibault wrote: > Okash Khawaja, le dim. 15 sept. 2019 19:41:30 +0100, a ecrit: > > I have attached the descriptions. > > Attachment is missing :) I saw it :) Anyway, please put the Description: lines without a blank after that, with the description text starting on that same line. thanks! greg k-h
RE: [EXT] Re: [PATCH 0/4] Fix UART DMA freezes for iMX6
From: Philipp Puschmann Sent: Monday, September 16, 2019 9:55 PM > Hi Fabio, > > Am 12.09.19 um 20:23 schrieb Fabio Estevam: > > Hi Philipp, > > > > Thanks for submitting these fixes. > > > > On Wed, Sep 11, 2019 at 11:50 AM Philipp Puschmann > > wrote: > >> > >> For some years and since many kernel versions there are reports that > >> RX UART DMA channel stops working at one point. So far the usual > >> workaround was to disable RX DMA. This patches try to fix the underlying > problem. > >> > >> When a running sdma script does not find any usable destination > >> buffer to put its data into it just leads to stopping the channel > >> being scheduled again. As solution we we manually retrigger the sdma > >> script for this channel and by this dissolve the freeze. > >> > >> While this seems to work fine so far a further patch in this series > >> increases the number of RX DMA periods for UART to reduce use cases > >> running into such a situation. > >> > >> This patch series was tested with the current kernel and backported > >> to kernel 4.15 with a special use case using a WL1837MOD via UART and > >> provoking the hanging of UART RX DMA within seconds after starting a test > application. > >> It resulted in well known > >> "Bluetooth: hci0: command 0x0408 tx timeout" > >> errors and complete stop of UART data reception. Our Bluetooth > >> traffic consists of many independent small packets, mostly only a few > >> bytes, causing high usage of periods. > >> > >> > >> Philipp Puschmann (4): > >> dmaengine: imx-sdma: fix buffer ownership > >> dmaengine: imx-sdma: fix dma freezes > >> serial: imx: adapt rx buffer and dma periods > >> dmaengine: imx-sdma: drop redundant variable > > > > I have some suggestions: > > > > 1. Please split this in two series: one for dmaengine and other one > > for serial > > > > 2. Please add Fixes tag when appropriate, so that the fixes can be > > backported to stable kernels. > > > > 3. Please Cc Robin and Andy > > > > Thanks > > > > Thanks for the hints. I will apply them if the contentual feedback is > positive. > > p.s. Did you forget to add Andy? I don't see a Andy in the to- and cc-list. For dma and uart, please to- me and yibin.g...@nxp.com, thanks. Andy
Re: [PATCH 2/2] pwm: core: Add option to config PWM duty/period with u64 data length
Hi Guru, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3 next-20190915] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Guru-Das-Srinagesh/pwm-Add-different-PWM-output-types-support/20190916-151008 config: arm-multi_v4t_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=arm If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): drivers/pwm/pwm-clps711x.o: In function `clps711x_pwm_config': >> pwm-clps711x.c:(.text+0x64): undefined reference to `__aeabi_uldivmod' drivers/pwm/pwm-clps711x.o: In function `clps711x_pwm_enable': pwm-clps711x.c:(.text+0x168): undefined reference to `__aeabi_uldivmod' drivers/video/backlight/pwm_bl.o: In function `pwm_backlight_probe': >> pwm_bl.c:(.text+0x5fc): undefined reference to `__aeabi_uldivmod' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: linux-next: manual merge of the kselftest tree with the tpmdd tree
On 9/16/19 7:42 AM, Mark Brown wrote: On Mon, Sep 16, 2019 at 03:16:54PM +0200, Anders Roxell wrote: If I re-read the Documentation/dev-tools/kselftest.rst I think the patch from the kselftest tree should be dropped. I saw that I didn't send an email to the tpm maintainers or the tpm list when I sent the patch, I'm sorry. If the change is fine that might be more trouble than it's worth, it's a trivial add/add conflict. Up to those concerned though. I usually handle these with sending a note to Linus in my pull request and request him to pick the one from next. Dropping patch doesn't work very well. No worries I will handle this in my pull request. thanks, -- Shuah
Re: [PATCH v5 6/9] leds: multicolor: Introduce a multicolor class definition
Jacek
On 9/15/19 11:20 AM, Jacek Anaszewski wrote:
Dan,
On 9/11/19 8:01 PM, Dan Murphy wrote:
Introduce a multicolor class that groups colored LEDs
within a LED node.
The framework allows for dynamically setting individual LEDs
or setting brightness levels of LEDs and updating them virtually
simultaneously.
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile| 1 +
drivers/leds/led-class-multicolor.c | 387 +++
include/linux/led-class-multicolor.h | 96 +++
4 files changed, 494 insertions(+)
create mode 100644 drivers/leds/led-class-multicolor.c
create mode 100644 include/linux/led-class-multicolor.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1988de1d64c0..71e7fd4f6f15 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -30,6 +30,16 @@ config LEDS_CLASS_FLASH
for the flash related features of a LED device. It can be built
as a module.
+config LEDS_CLASS_MULTI_COLOR
+ tristate "LED Mulit Color LED Class Support"
+ depends on LEDS_CLASS
+ help
+ This option enables the multicolor LED sysfs class in /sys/class/leds.
+ It wraps LED class and adds multicolor LED specific sysfs attributes
+ and kernel internal API to it. You'll need this to provide support
+ for multicolor LEDs that are grouped together. This class is not
+ intended for single color LEDs. It can be built as a module.
+
config LEDS_BRIGHTNESS_HW_CHANGED
bool "LED Class brightness_hw_changed attribute support"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 41fb073a39c1..897b810257dd 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_NEW_LEDS)+= led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
obj-$(CONFIG_LEDS_CLASS_FLASH)+= led-class-flash.o
+obj-$(CONFIG_LEDS_CLASS_MULTI_COLOR) += led-class-multicolor.o
obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
# LED Platform Drivers
diff --git a/drivers/leds/led-class-multicolor.c
b/drivers/leds/led-class-multicolor.c
new file mode 100644
index ..c733192b31fa
--- /dev/null
+++ b/drivers/leds/led-class-multicolor.c
@@ -0,0 +1,387 @@
+// SPDX-License-Identifier: GPL-2.0
+// LED Multi Color class interface
+// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "leds.h"
+
+struct led_classdev_mc_priv {
I'd go for some more informative struct name here.
And also this is not going to be main classdev struct
so we can drop that from the name.
struct led_mc_color_entry ?
That would probably be better as a name.
+ struct led_classdev_mc *mcled_cdev;
+
+ struct device_attribute max_intensity_attr;
+ struct device_attribute intensity_attr;
+ struct device_attribute color_index_attr;
+
+ enum led_brightness max_intensity;
+ enum led_brightness intensity;
+
+ struct list_head list;
+
+ int led_color_id;
+ int color_seq_pos;
+};
+
+static int led_mc_calculate_brightness(int brightness, int intensity,
+ int max_intensity)
+{
+ if (brightness && intensity && max_intensity)
This check looks odd. I'd drop it entirely. One thing we could worry
about would be max_intensity == 0 but this should be secured by the
core on registration. Effectively I don't see the need for wrapping
below calculation in a function at all.
This was made into a function when I had the intensity and color_mix
files writing the values. This is no longer needed as a function.
+ return brightness * intensity / max_intensity;
+
+ return LED_OFF;
+}
+
+void led_mc_set_cluster_brightness(struct led_classdev_mc *mcled_cdev,
We really don't set cluster brightness but calculate it only here
(we can skip "cluster" as well):
s/led_mc_set_cluster_brightness/led_mc_calc_brightness/
Ack
+ enum led_brightness brightness, int adj_value[])
s/adj_value/brightness_val/
Ack
+{
+ struct led_classdev_mc_data *data = mcled_cdev->data;
+ struct led_classdev_mc_priv *priv;
+ int i = 0;
+
+ list_for_each_entry(priv, >color_list, list) {
+ adj_value[i] = led_mc_calculate_brightness(brightness,
+ priv->intensity,
+ priv->max_intensity);
brightness_val[i] = brightness * priv->intensity / priv->max_intensity;
Ack
+ i++;
+ }
+
+ data->cluster_brightness = brightness;
Why can't we use led_classdev_mc->led_cdev->brightness for storing
cluster brightness?
We could probably drop this altogether as I think you pointed out
Re: [PATCH 1/2] pwm: Add different PWM output types support
On Fri, Sep 13, 2019 at 03:57:43PM -0700, Guru Das Srinagesh wrote:
> From: Fenglin Wu
>
> Normally, PWM channel has fixed output until software request to change
> its settings. There are some PWM devices which their outputs could be
> changed autonomously according to a predefined pattern programmed in
> hardware. Add pwm_output_type enum type to identify these two different
> PWM types and add relevant helper functions to set and get PWM output
> types and pattern.
>
> Change-Id: Ia1f914a45ab4f4dd7be037a395eeb89d0e65a80e
> Signed-off-by: Fenglin Wu
> Signed-off-by: Guru Das Srinagesh
> ---
> drivers/pwm/core.c | 26
> drivers/pwm/sysfs.c | 50 ++
> include/linux/pwm.h | 70
> +
> 3 files changed, 146 insertions(+)
This doesn't seem right to me. Are you describing a PWM pin that's
actually driven in GPIO mode? We usually configure that using pinctrl.
Thierry
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 8edfac1..960a451 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -282,6 +282,7 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
> pwm->pwm = chip->base + i;
> pwm->hwpwm = i;
> pwm->state.polarity = polarity;
> + pwm->state.output_type = PWM_OUTPUT_FIXED;
>
> if (chip->ops->get_state)
> chip->ops->get_state(chip, pwm, >state);
> @@ -498,6 +499,31 @@ int pwm_apply_state(struct pwm_device *pwm, struct
> pwm_state *state)
> pwm->state.polarity = state->polarity;
> }
>
> + if (state->output_type != pwm->state.output_type) {
> + if (!pwm->chip->ops->set_output_type)
> + return -ENOTSUPP;
> +
> + err = pwm->chip->ops->set_output_type(pwm->chip, pwm,
> + state->output_type);
> + if (err)
> + return err;
> +
> + pwm->state.output_type = state->output_type;
> + }
> +
> + if (state->output_pattern != pwm->state.output_pattern &&
> + state->output_pattern != NULL) {
> + if (!pwm->chip->ops->set_output_pattern)
> + return -ENOTSUPP;
> +
> + err = pwm->chip->ops->set_output_pattern(pwm->chip,
> + pwm, state->output_pattern);
> + if (err)
> + return err;
> +
> + pwm->state.output_pattern = state->output_pattern;
> + }
> +
> if (state->period != pwm->state.period ||
> state->duty_cycle != pwm->state.duty_cycle) {
> err = pwm->chip->ops->config(pwm->chip, pwm,
> diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
> index 2389b86..ab703f2 100644
> --- a/drivers/pwm/sysfs.c
> +++ b/drivers/pwm/sysfs.c
> @@ -215,11 +215,60 @@ static ssize_t capture_show(struct device *child,
> return sprintf(buf, "%u %u\n", result.period, result.duty_cycle);
> }
>
> +static ssize_t output_type_show(struct device *child,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + const struct pwm_device *pwm = child_to_pwm_device(child);
> + const char *output_type = "unknown";
> + struct pwm_state state;
> +
> + pwm_get_state(pwm, );
> + switch (state.output_type) {
> + case PWM_OUTPUT_FIXED:
> + output_type = "fixed";
> + break;
> + case PWM_OUTPUT_MODULATED:
> + output_type = "modulated";
> + break;
> + default:
> + break;
> + }
> +
> + return snprintf(buf, PAGE_SIZE, "%s\n", output_type);
> +}
> +
> +static ssize_t output_type_store(struct device *child,
> + struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + struct pwm_export *export = child_to_pwm_export(child);
> + struct pwm_device *pwm = export->pwm;
> + struct pwm_state state;
> + int ret = -EINVAL;
> +
> + mutex_lock(>lock);
> + pwm_get_state(pwm, );
> + if (sysfs_streq(buf, "fixed"))
> + state.output_type = PWM_OUTPUT_FIXED;
> + else if (sysfs_streq(buf, "modulated"))
> + state.output_type = PWM_OUTPUT_MODULATED;
> + else
> + goto unlock;
> +
> + ret = pwm_apply_state(pwm, );
> +unlock:
> + mutex_unlock(>lock);
> +
> + return ret ? : size;
> +}
> +
> static DEVICE_ATTR_RW(period);
> static DEVICE_ATTR_RW(duty_cycle);
> static DEVICE_ATTR_RW(enable);
> static DEVICE_ATTR_RW(polarity);
> static DEVICE_ATTR_RO(capture);
> +static DEVICE_ATTR_RW(output_type);
>
> static struct attribute *pwm_attrs[]
Re: [Openipmi-developer] [PATCH 0/1] Fix race in ipmi timer cleanup
On 9/14/19 9:08 PM, Corey Minyard wrote:
>>
>>>
>>> {disable,enable}_si_irq() themselves are racy:
>>>
>>> static inline bool disable_si_irq(struct smi_info *smi_info)
>>> {
>>> if ((smi_info->io.irq) && (!smi_info->interrupt_disabled)) {
>>> smi_info->interrupt_disabled = true;
>>>
>>> Basically interrupt_disabled need to be atomic here to have any value,
>>> unless you ensure to have a spin lock around every access to it.
>>
>> It needs to be atomic, yes, but I think just adding the spinlock like
>> I suggested will work. You are right, the check for timer_running is
>> not necessary here, and I'm fine with removing it, but there are other
>> issues with interrupt_disabled (as you said) and with memory ordering
>> in the timer case. So even if you remove the timer running check, the
>> lock is still required here.
>
> It turns out you were right, all that really needs to be done is the
> del_timer_sync(). I've added your patch to my queue.
>
> Sorry for the trouble.
Awesome!
Sorry I was going to get back and look at it again, but Linux Plumbers
and playing sardine i a tin can got in the way.
Cheers,
Jes
Re: [PATCH v5 9/9] leds: Update the lp55xx to use the multi color framework
On 9/15/19 11:28 AM, Jacek Anaszewski wrote:
Hi Dan,
On 9/11/19 8:01 PM, Dan Murphy wrote:
Update the lp5523 to use the multi color framework.
Signed-off-by: Dan Murphy
---
drivers/leds/leds-lp5523.c| 13 +++
drivers/leds/leds-lp55xx-common.c | 131 ++
drivers/leds/leds-lp55xx-common.h | 9 ++
include/linux/platform_data/leds-lp55xx.h | 6 +
modules.builtin.modinfo | Bin 0 -> 43550 bytes
5 files changed, 137 insertions(+), 22 deletions(-)
create mode 100644 modules.builtin.modinfo
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index d0b931a136b9..8b2cdb98fed6 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -791,6 +791,18 @@ static ssize_t store_master_fader_leds(struct device *dev,
return ret;
}
[...]
struct lp55xx_predef_pattern {
Below file seems to have been added to the index by mistake.
I will remove it
Dan
diff --git a/modules.builtin.modinfo b/modules.builtin.modinfo
new file mode 100644
index
..e528d8f57796621b6cfef52ad0da44551a482481
GIT binary patch
literal 43550
zcmcJ2?Q+|=(x(2ta}}twKjNIV|YGNXqfd?pCE75g*+RpaC?x8;w!ycl>2BO|zrh@WId3MUofUG7gi1
zeg~})3e2M*O!DyPegBfbM`0dh(V~dbwg7R~*1raD%EP{%{_8
[...]
Re: [PATCH] mm/slub: fix a deadlock in shuffle_freelist()
On Mon, 2019-09-16 at 11:03 +0200, Sebastian Andrzej Siewior wrote: > On 2019-09-13 12:27:44 [-0400], Qian Cai wrote: > … > > Chain exists of: > > random_write_wait.lock --> >lock --> batched_entropy_u32.lock > > > > Possible unsafe locking scenario: > > > >CPU0CPU1 > > > > lock(batched_entropy_u32.lock); > >lock(>lock); > >lock(batched_entropy_u32.lock); > > lock(random_write_wait.lock); > > would this deadlock still occur if lockdep knew that > batched_entropy_u32.lock on CPU0 could be acquired at the same time > as CPU1 acquired its batched_entropy_u32.lock? I suppose that might fix it too if it can teach the lockdep the trick, but it would be better if there is a patch if you have something in mind that could be tested to make sure.
Re: [PATCH] RDMA/bnxt_re: fix spelling mistake "missin_resp" -> "missing_resp"
On Wed, Sep 11, 2019 at 10:28:56AM +0100, Colin King wrote: > From: Colin Ian King > > There is a spelling mistake in a literal string, fix it. > > Signed-off-by: Colin Ian King > --- > drivers/infiniband/hw/bnxt_re/hw_counters.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to for-next, thanks Jason
Re: [PATCH 2/2] pwm: core: Add option to config PWM duty/period with u64 data length
On Fri, Sep 13, 2019 at 03:57:44PM -0700, Guru Das Srinagesh wrote:
> From: Fenglin Wu
>
> Currently, PWM core driver provides interfaces for configuring PWM
> period and duty length in nanoseconds with an integer data type, so
> the max period can be only set to ~2.147 seconds. Add interfaces which
> can set PWM period and duty with u64 data type to remove this
> limitation.
>
> Change-Id: Ic8722088510d447fc939ab6a5014711aef1b832f
> Signed-off-by: Fenglin Wu
> Signed-off-by: Guru Das Srinagesh
> ---
> drivers/pwm/core.c | 20 ++---
> drivers/pwm/sysfs.c | 6 +--
> include/linux/pwm.h | 115
>
> 3 files changed, 126 insertions(+), 15 deletions(-)
pwm_ops->config() is considered legacy API and only remains for drivers
that haven't been converted to the atomic API yet. If you want to extend
the range for period and duty cycle, please add that to the atomic API,
which is pwm_ops->apply() and struct pwm_state.
Thierry
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 960a451..02ad16b 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -526,9 +526,19 @@ int pwm_apply_state(struct pwm_device *pwm, struct
> pwm_state *state)
>
> if (state->period != pwm->state.period ||
> state->duty_cycle != pwm->state.duty_cycle) {
> - err = pwm->chip->ops->config(pwm->chip, pwm,
> - state->duty_cycle,
> - state->period);
> + if (pwm->chip->ops->config_extend) {
> + err = pwm->chip->ops->config_extend(pwm->chip,
> + pwm, state->duty_cycle,
> + state->period);
> + } else {
> + if (state->period > UINT_MAX)
> + pr_warn("period %llu duty_cycle %llu
> will be truncated\n",
> + state->period,
> + state->duty_cycle);
> + err = pwm->chip->ops->config(pwm->chip, pwm,
> + state->duty_cycle,
> + state->period);
> + }
> if (err)
> return err;
>
> @@ -1181,8 +1191,8 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct
> seq_file *s)
> if (state.enabled)
> seq_puts(s, " enabled");
>
> - seq_printf(s, " period: %u ns", state.period);
> - seq_printf(s, " duty: %u ns", state.duty_cycle);
> + seq_printf(s, " period: %llu ns", state.period);
> + seq_printf(s, " duty: %llu ns", state.duty_cycle);
> seq_printf(s, " polarity: %s",
> state.polarity ? "inverse" : "normal");
>
> diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
> index ab703f2..ef78c40 100644
> --- a/drivers/pwm/sysfs.c
> +++ b/drivers/pwm/sysfs.c
> @@ -42,7 +42,7 @@ static ssize_t period_show(struct device *child,
>
> pwm_get_state(pwm, );
>
> - return sprintf(buf, "%u\n", state.period);
> + return sprintf(buf, "%llu\n", state.period);
> }
>
> static ssize_t period_store(struct device *child,
> @@ -77,7 +77,7 @@ static ssize_t duty_cycle_show(struct device *child,
>
> pwm_get_state(pwm, );
>
> - return sprintf(buf, "%u\n", state.duty_cycle);
> + return sprintf(buf, "%llu\n", state.duty_cycle);
> }
>
> static ssize_t duty_cycle_store(struct device *child,
> @@ -212,7 +212,7 @@ static ssize_t capture_show(struct device *child,
> if (ret)
> return ret;
>
> - return sprintf(buf, "%u %u\n", result.period, result.duty_cycle);
> + return sprintf(buf, "%llu %llu\n", result.period, result.duty_cycle);
> }
>
> static ssize_t output_type_show(struct device *child,
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 416f08e..d714385 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -39,7 +39,7 @@ enum pwm_polarity {
> * current PWM hardware state.
> */
> struct pwm_args {
> - unsigned int period;
> + u64 period;
> enum pwm_polarity polarity;
> };
>
> @@ -66,9 +66,9 @@ enum pwm_output_type {
> * @cycles_per_duty: number of PWM period cycles an entry stays at
> */
> struct pwm_output_pattern {
> - unsigned int *duty_pattern;
> + u64 *duty_pattern;
> unsigned int num_entries;
> - unsigned int cycles_per_duty;
> + u64 cycles_per_duty;
> };
>
> /*
> @@ -79,8 +79,8 @@ struct pwm_output_pattern {
> * @enabled: PWM enabled status
> */
> struct pwm_state {
> - unsigned int period;
> - unsigned int duty_cycle;
> + u64 period;
> + u64
Re: [PATCH 2/2] pwm: core: Add option to config PWM duty/period with u64 data length
Hi Guru,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190915]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Guru-Das-Srinagesh/pwm-Add-different-PWM-output-types-support/20190916-151008
config: i386-randconfig-h004-201937 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
ld: drivers/hwmon/pwm-fan.o: in function `pwm_fan_resume':
>> drivers/hwmon/pwm-fan.c:440: undefined reference to `__udivdi3'
vim +440 drivers/hwmon/pwm-fan.c
d82d57767c8598 Kamil Debski2014-07-16 420
d82d57767c8598 Kamil Debski2014-07-16 421 static int
pwm_fan_resume(struct device *dev)
d82d57767c8598 Kamil Debski2014-07-16 422 {
d82d57767c8598 Kamil Debski2014-07-16 423 struct pwm_fan_ctx *ctx
= dev_get_drvdata(dev);
2289711c9d4d58 Boris Brezillon 2016-04-14 424 struct pwm_args pargs;
48b9d5b4f40825 Kamil Debski2014-11-03 425 unsigned long duty;
48b9d5b4f40825 Kamil Debski2014-11-03 426 int ret;
d82d57767c8598 Kamil Debski2014-07-16 427
b57e1d42939721 Stefan Wahren 2019-02-22 428 if (ctx->reg_en) {
b57e1d42939721 Stefan Wahren 2019-02-22 429 ret =
regulator_enable(ctx->reg_en);
b57e1d42939721 Stefan Wahren 2019-02-22 430 if (ret) {
b57e1d42939721 Stefan Wahren 2019-02-22 431
dev_err(dev, "Failed to enable fan supply: %d\n", ret);
b57e1d42939721 Stefan Wahren 2019-02-22 432 return
ret;
b57e1d42939721 Stefan Wahren 2019-02-22 433 }
b57e1d42939721 Stefan Wahren 2019-02-22 434 }
b57e1d42939721 Stefan Wahren 2019-02-22 435
48b9d5b4f40825 Kamil Debski2014-11-03 436 if (ctx->pwm_value == 0)
d82d57767c8598 Kamil Debski2014-07-16 437 return 0;
48b9d5b4f40825 Kamil Debski2014-11-03 438
2289711c9d4d58 Boris Brezillon 2016-04-14 439 pwm_get_args(ctx->pwm,
);
2289711c9d4d58 Boris Brezillon 2016-04-14 @440 duty =
DIV_ROUND_UP(ctx->pwm_value * (pargs.period - 1), MAX_PWM);
2289711c9d4d58 Boris Brezillon 2016-04-14 441 ret =
pwm_config(ctx->pwm, duty, pargs.period);
48b9d5b4f40825 Kamil Debski2014-11-03 442 if (ret)
48b9d5b4f40825 Kamil Debski2014-11-03 443 return ret;
48b9d5b4f40825 Kamil Debski2014-11-03 444 return
pwm_enable(ctx->pwm);
d82d57767c8598 Kamil Debski2014-07-16 445 }
d82d57767c8598 Kamil Debski2014-07-16 446 #endif
d82d57767c8598 Kamil Debski2014-07-16 447
:: The code at line 440 was first introduced by commit
:: 2289711c9d4d588954ff86a06685f1579bf6c446 hwmon: pwm-fan: Use
pwm_get_args() where appropriate
:: TO: Boris Brezillon
:: CC: Thierry Reding
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 0/4] Fix UART DMA freezes for iMX6
Hi Philipp, On Mon, Sep 16, 2019 at 10:55 AM Philipp Puschmann wrote: > Thanks for the hints. I will apply them if the contentual feedback is > positive. > > p.s. Did you forget to add Andy? I don't see a Andy in the to- and cc-list. Andy's e-mail is fugang.d...@nxp.com, which I added on Cc. I think your patches look good and are in good shape to be resubmitted. Thanks for fixing these hard to debug issues!
