* [PATCH v2] PCI: keystone: fix interrupt-controller-node lookup
From: Bjorn Helgaas @ 2017-12-12 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211104233.GB3225@red-moon>
On Mon, Dec 11, 2017 at 10:42:33AM +0000, Lorenzo Pieralisi wrote:
> On Mon, Dec 11, 2017 at 11:29:55AM +0100, Johan Hovold wrote:
> > On Fri, Nov 17, 2017 at 02:38:31PM +0100, Johan Hovold wrote:
> > > Fix child-node lookup during initialisation which was using the wrong
> > > OF-helper and ended up searching the whole device tree depth-first
> > > starting at the parent rather than just matching on its children.
> > >
> > > To make things worse, the parent pci node could end up being prematurely
> > > freed as of_find_node_by_name() drops a reference to its first argument.
> > > Any matching child interrupt-controller node was also leaked.
> > >
> > > Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
> > > Cc: stable <stable@vger.kernel.org> # 3.18
> > > Acked-by: Murali Karicheri <m-karicheri2@ti.com>
> > > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > ---
> > >
> > > v2
> > > - amend commit message and mention explicitly that of_find_node_by_name()
> > > drops a reference to the start node
> > > - add Murali's and Lorenzo's acks
> >
> > This one hasn't shown up in linux-next, so sending a reminder to make
> > sure it doesn't fall between the cracks.
>
> Hi Johan,
>
> yes it is in the list of fixes to be sent upstream - I was about to
> ask Bjorn to apply it.
Is this something that needs to be merged for v4.15? If so, I need to
be able to defend it to Linus as being a critical fix. If the issue
been around for 3 years (v3.18 was tagged Dec 7 2014), that requires
pretty "clear and present danger."
>From the commit log, I see a sub-optimal search (not critical), a
possible use-after-free (could conceivably be critical if people are
tripping over this, but would need more specifics about that), and a
leak (not critical).
Given what I can see now, my inclination would be for Lorenzo to queue
it for v4.16, which would still get in linux-next soonish.
Bjorn
^ permalink raw reply
* [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU
From: Priit Laes @ 2017-12-12 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOi56cUjqjcZRz6VSwUWcrW=4RQyqyZHtm1vuM3HT2ypdPJ78g@mail.gmail.com>
On Mon, Dec 11, 2017 at 02:22:30PM -0800, Kevin Hilman wrote:
> On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes <plaes@plaes.org> wrote:
> > Convert sun4i-a10.dtsi to new CCU driver.
> >
> > Signed-off-by: Priit Laes <plaes@plaes.org>
>
> I finally got around to bisecting a mainline boot failure on
> sun4i-a10-cubieboard that's been happening for quite a while. Based
> on on kernelci.org, it showed up sometime during the v4.15 merge
> window[1]. It bisected down to this commit (in mainline as commit
> 41193869f2bdb585ce09bfdd16d9482aadd560ad).
>
> When it fails, there is no output on the serial console, so I don't
> know exactly how it's failing, just that it no longer boots.
We tried out latest 4.15 with various compilers and it works:
- gcc version 7.1.1 20170622 (Red Hat Cross 7.1.1-3) (GCC) - A10 Gemei G9 tablet
- gcc 7.2.0-debian - A10 Cubieboard
>
> Kevin
>
> [1] https://kernelci.org/boot/id/5a2e10cd59b51430a9afa173/
>
> > ---
> > arch/arm/boot/dts/sun4i-a10.dtsi | 636 ++++----------------------------
> > 1 file changed, 82 insertions(+), 554 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
> > index ba20b48..0d8320a 100644
> > --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> > +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> > @@ -45,7 +45,8 @@
> >
> > #include <dt-bindings/thermal/thermal.h>
> >
> > -#include <dt-bindings/clock/sun4i-a10-pll2.h>
> > +#include <dt-bindings/clock/sunxi-a10-a20-ccu.h>
> > +#include <dt-bindings/reset/sunxi-a10-a20-ccu.h>
> > #include <dt-bindings/dma/sun4i-a10.h>
> > #include <dt-bindings/pinctrl/sun4i-a10.h>
> >
> > @@ -65,9 +66,9 @@
> > compatible = "allwinner,simple-framebuffer",
> > "simple-framebuffer";
> > allwinner,pipeline = "de_be0-lcd0-hdmi";
> > - clocks = <&ahb_gates 36>, <&ahb_gates 43>,
> > - <&ahb_gates 44>, <&de_be0_clk>,
> > - <&tcon0_ch1_clk>, <&dram_gates 26>;
> > + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_HDMI1>,
> > + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_DE_BE0>,
> > + <&ccu CLK_TCON0_CH1>, <&ccu CLK_DRAM_DE_BE0>;
> > status = "disabled";
> > };
> >
> > @@ -75,10 +76,11 @@
> > compatible = "allwinner,simple-framebuffer",
> > "simple-framebuffer";
> > allwinner,pipeline = "de_fe0-de_be0-lcd0-hdmi";
> > - clocks = <&ahb_gates 36>, <&ahb_gates 43>,
> > - <&ahb_gates 44>, <&ahb_gates 46>,
> > - <&de_be0_clk>, <&de_fe0_clk>, <&tcon0_ch1_clk>,
> > - <&dram_gates 25>, <&dram_gates 26>;
> > + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_HDMI1>,
> > + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_AHB_DE_FE0>,
> > + <&ccu CLK_DE_BE0>, <&ccu CLK_DE_FE0>,
> > + <&ccu CLK_TCON0_CH1>,
> > + <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
> > status = "disabled";
> > };
> >
> > @@ -86,9 +88,10 @@
> > compatible = "allwinner,simple-framebuffer",
> > "simple-framebuffer";
> > allwinner,pipeline = "de_fe0-de_be0-lcd0";
> > - clocks = <&ahb_gates 36>, <&ahb_gates 44>, <&ahb_gates 46>,
> > - <&de_be0_clk>, <&de_fe0_clk>, <&tcon0_ch0_clk>,
> > - <&dram_gates 25>, <&dram_gates 26>;
> > + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_DE_BE0>,
> > + <&ccu CLK_AHB_DE_FE0>, <&ccu CLK_DE_BE0>,
> > + <&ccu CLK_DE_FE0>, <&ccu CLK_TCON0_CH1>,
> > + <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
> > status = "disabled";
> > };
> >
> > @@ -96,11 +99,11 @@
> > compatible = "allwinner,simple-framebuffer",
> > "simple-framebuffer";
> > allwinner,pipeline = "de_fe0-de_be0-lcd0-tve0";
> > - clocks = <&ahb_gates 34>, <&ahb_gates 36>,
> > - <&ahb_gates 44>, <&ahb_gates 46>,
> > - <&de_be0_clk>, <&de_fe0_clk>,
> > - <&tcon0_ch1_clk>, <&dram_gates 5>,
> > - <&dram_gates 25>, <&dram_gates 26>;
> > + clocks = <&ccu CLK_AHB_TVE0>, <&ccu CLK_AHB_LCD0>,
> > + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_AHB_DE_FE0>,
> > + <&ccu CLK_DE_BE0>, <&ccu CLK_DE_FE0>,
> > + <&ccu CLK_TCON0_CH1>, <&ccu CLK_DRAM_TVE0>,
> > + <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
> > status = "disabled";
> > };
> > };
> > @@ -112,7 +115,7 @@
> > device_type = "cpu";
> > compatible = "arm,cortex-a8";
> > reg = <0x0>;
> > - clocks = <&cpu>;
> > + clocks = <&ccu CLK_CPU>;
> > clock-latency = <244144>; /* 8 32k periods */
> > operating-points = <
> > /* kHz uV */
> > @@ -168,18 +171,6 @@
> > #size-cells = <1>;
> > ranges;
> >
> > - /*
> > - * This is a dummy clock, to be used as placeholder on
> > - * other mux clocks when a specific parent clock is not
> > - * yet implemented. It should be dropped when the driver
> > - * is complete.
> > - */
> > - dummy: dummy {
> > - #clock-cells = <0>;
> > - compatible = "fixed-clock";
> > - clock-frequency = <0>;
> > - };
> > -
> > osc24M: clk at 01c20050 {
> > #clock-cells = <0>;
> > compatible = "allwinner,sun4i-a10-osc-clk";
> > @@ -188,487 +179,12 @@
> > clock-output-names = "osc24M";
> > };
> >
> > - osc3M: osc3M_clk {
> > - compatible = "fixed-factor-clock";
> > - #clock-cells = <0>;
> > - clock-div = <8>;
> > - clock-mult = <1>;
> > - clocks = <&osc24M>;
> > - clock-output-names = "osc3M";
> > - };
> > -
> > osc32k: clk at 0 {
> > #clock-cells = <0>;
> > compatible = "fixed-clock";
> > clock-frequency = <32768>;
> > clock-output-names = "osc32k";
> > };
> > -
> > - pll1: clk at 01c20000 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-pll1-clk";
> > - reg = <0x01c20000 0x4>;
> > - clocks = <&osc24M>;
> > - clock-output-names = "pll1";
> > - };
> > -
> > - pll2: clk at 01c20008 {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-pll2-clk";
> > - reg = <0x01c20008 0x8>;
> > - clocks = <&osc24M>;
> > - clock-output-names = "pll2-1x", "pll2-2x",
> > - "pll2-4x", "pll2-8x";
> > - };
> > -
> > - pll3: clk at 01c20010 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-pll3-clk";
> > - reg = <0x01c20010 0x4>;
> > - clocks = <&osc3M>;
> > - clock-output-names = "pll3";
> > - };
> > -
> > - pll3x2: pll3x2_clk {
> > - compatible = "fixed-factor-clock";
> > - #clock-cells = <0>;
> > - clock-div = <1>;
> > - clock-mult = <2>;
> > - clocks = <&pll3>;
> > - clock-output-names = "pll3-2x";
> > - };
> > -
> > - pll4: clk at 01c20018 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-pll1-clk";
> > - reg = <0x01c20018 0x4>;
> > - clocks = <&osc24M>;
> > - clock-output-names = "pll4";
> > - };
> > -
> > - pll5: clk at 01c20020 {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-pll5-clk";
> > - reg = <0x01c20020 0x4>;
> > - clocks = <&osc24M>;
> > - clock-output-names = "pll5_ddr", "pll5_other";
> > - };
> > -
> > - pll6: clk at 01c20028 {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-pll6-clk";
> > - reg = <0x01c20028 0x4>;
> > - clocks = <&osc24M>;
> > - clock-output-names = "pll6_sata", "pll6_other", "pll6";
> > - };
> > -
> > - pll7: clk at 01c20030 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-pll3-clk";
> > - reg = <0x01c20030 0x4>;
> > - clocks = <&osc3M>;
> > - clock-output-names = "pll7";
> > - };
> > -
> > - pll7x2: pll7x2_clk {
> > - compatible = "fixed-factor-clock";
> > - #clock-cells = <0>;
> > - clock-div = <1>;
> > - clock-mult = <2>;
> > - clocks = <&pll7>;
> > - clock-output-names = "pll7-2x";
> > - };
> > -
> > - /* dummy is 200M */
> > - cpu: cpu at 01c20054 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-cpu-clk";
> > - reg = <0x01c20054 0x4>;
> > - clocks = <&osc32k>, <&osc24M>, <&pll1>, <&dummy>;
> > - clock-output-names = "cpu";
> > - };
> > -
> > - axi: axi at 01c20054 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-axi-clk";
> > - reg = <0x01c20054 0x4>;
> > - clocks = <&cpu>;
> > - clock-output-names = "axi";
> > - };
> > -
> > - axi_gates: clk at 01c2005c {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-axi-gates-clk";
> > - reg = <0x01c2005c 0x4>;
> > - clocks = <&axi>;
> > - clock-indices = <0>;
> > - clock-output-names = "axi_dram";
> > - };
> > -
> > - ahb: ahb at 01c20054 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-ahb-clk";
> > - reg = <0x01c20054 0x4>;
> > - clocks = <&axi>;
> > - clock-output-names = "ahb";
> > - };
> > -
> > - ahb_gates: clk at 01c20060 {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-ahb-gates-clk";
> > - reg = <0x01c20060 0x8>;
> > - clocks = <&ahb>;
> > - clock-indices = <0>, <1>,
> > - <2>, <3>,
> > - <4>, <5>, <6>,
> > - <7>, <8>, <9>,
> > - <10>, <11>, <12>,
> > - <13>, <14>, <16>,
> > - <17>, <18>, <20>,
> > - <21>, <22>, <23>,
> > - <24>, <25>, <26>,
> > - <32>, <33>, <34>,
> > - <35>, <36>, <37>,
> > - <40>, <41>, <43>,
> > - <44>, <45>,
> > - <46>, <47>,
> > - <50>, <52>;
> > - clock-output-names = "ahb_usb0", "ahb_ehci0",
> > - "ahb_ohci0", "ahb_ehci1",
> > - "ahb_ohci1", "ahb_ss", "ahb_dma",
> > - "ahb_bist", "ahb_mmc0", "ahb_mmc1",
> > - "ahb_mmc2", "ahb_mmc3", "ahb_ms",
> > - "ahb_nand", "ahb_sdram", "ahb_ace",
> > - "ahb_emac", "ahb_ts", "ahb_spi0",
> > - "ahb_spi1", "ahb_spi2", "ahb_spi3",
> > - "ahb_pata", "ahb_sata", "ahb_gps",
> > - "ahb_ve", "ahb_tvd", "ahb_tve0",
> > - "ahb_tve1", "ahb_lcd0", "ahb_lcd1",
> > - "ahb_csi0", "ahb_csi1", "ahb_hdmi",
> > - "ahb_de_be0", "ahb_de_be1",
> > - "ahb_de_fe0", "ahb_de_fe1",
> > - "ahb_mp", "ahb_mali400";
> > - };
> > -
> > - apb0: apb0 at 01c20054 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-apb0-clk";
> > - reg = <0x01c20054 0x4>;
> > - clocks = <&ahb>;
> > - clock-output-names = "apb0";
> > - };
> > -
> > - apb0_gates: clk at 01c20068 {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-apb0-gates-clk";
> > - reg = <0x01c20068 0x4>;
> > - clocks = <&apb0>;
> > - clock-indices = <0>, <1>,
> > - <2>, <3>,
> > - <5>, <6>,
> > - <7>, <10>;
> > - clock-output-names = "apb0_codec", "apb0_spdif",
> > - "apb0_ac97", "apb0_iis",
> > - "apb0_pio", "apb0_ir0",
> > - "apb0_ir1", "apb0_keypad";
> > - };
> > -
> > - apb1: clk at 01c20058 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-apb1-clk";
> > - reg = <0x01c20058 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&osc32k>;
> > - clock-output-names = "apb1";
> > - };
> > -
> > - apb1_gates: clk at 01c2006c {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-apb1-gates-clk";
> > - reg = <0x01c2006c 0x4>;
> > - clocks = <&apb1>;
> > - clock-indices = <0>, <1>,
> > - <2>, <4>,
> > - <5>, <6>,
> > - <7>, <16>,
> > - <17>, <18>,
> > - <19>, <20>,
> > - <21>, <22>,
> > - <23>;
> > - clock-output-names = "apb1_i2c0", "apb1_i2c1",
> > - "apb1_i2c2", "apb1_can",
> > - "apb1_scr", "apb1_ps20",
> > - "apb1_ps21", "apb1_uart0",
> > - "apb1_uart1", "apb1_uart2",
> > - "apb1_uart3", "apb1_uart4",
> > - "apb1_uart5", "apb1_uart6",
> > - "apb1_uart7";
> > - };
> > -
> > - nand_clk: clk at 01c20080 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c20080 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "nand";
> > - };
> > -
> > - ms_clk: clk at 01c20084 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c20084 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "ms";
> > - };
> > -
> > - mmc0_clk: clk at 01c20088 {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-mmc-clk";
> > - reg = <0x01c20088 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "mmc0",
> > - "mmc0_output",
> > - "mmc0_sample";
> > - };
> > -
> > - mmc1_clk: clk at 01c2008c {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-mmc-clk";
> > - reg = <0x01c2008c 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "mmc1",
> > - "mmc1_output",
> > - "mmc1_sample";
> > - };
> > -
> > - mmc2_clk: clk at 01c20090 {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-mmc-clk";
> > - reg = <0x01c20090 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "mmc2",
> > - "mmc2_output",
> > - "mmc2_sample";
> > - };
> > -
> > - mmc3_clk: clk at 01c20094 {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-mmc-clk";
> > - reg = <0x01c20094 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "mmc3",
> > - "mmc3_output",
> > - "mmc3_sample";
> > - };
> > -
> > - ts_clk: clk at 01c20098 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c20098 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "ts";
> > - };
> > -
> > - ss_clk: clk at 01c2009c {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c2009c 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "ss";
> > - };
> > -
> > - spi0_clk: clk at 01c200a0 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c200a0 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "spi0";
> > - };
> > -
> > - spi1_clk: clk at 01c200a4 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c200a4 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "spi1";
> > - };
> > -
> > - spi2_clk: clk at 01c200a8 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c200a8 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "spi2";
> > - };
> > -
> > - pata_clk: clk at 01c200ac {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c200ac 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "pata";
> > - };
> > -
> > - ir0_clk: clk at 01c200b0 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c200b0 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "ir0";
> > - };
> > -
> > - ir1_clk: clk at 01c200b4 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c200b4 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "ir1";
> > - };
> > -
> > - spdif_clk: clk at 01c200c0 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod1-clk";
> > - reg = <0x01c200c0 0x4>;
> > - clocks = <&pll2 SUN4I_A10_PLL2_8X>,
> > - <&pll2 SUN4I_A10_PLL2_4X>,
> > - <&pll2 SUN4I_A10_PLL2_2X>,
> > - <&pll2 SUN4I_A10_PLL2_1X>;
> > - clock-output-names = "spdif";
> > - };
> > -
> > - usb_clk: clk at 01c200cc {
> > - #clock-cells = <1>;
> > - #reset-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-usb-clk";
> > - reg = <0x01c200cc 0x4>;
> > - clocks = <&pll6 1>;
> > - clock-output-names = "usb_ohci0", "usb_ohci1",
> > - "usb_phy";
> > - };
> > -
> > - spi3_clk: clk at 01c200d4 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-mod0-clk";
> > - reg = <0x01c200d4 0x4>;
> > - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> > - clock-output-names = "spi3";
> > - };
> > -
> > - dram_gates: clk at 01c20100 {
> > - #clock-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-dram-gates-clk";
> > - reg = <0x01c20100 0x4>;
> > - clocks = <&pll5 0>;
> > - clock-indices = <0>,
> > - <1>, <2>,
> > - <3>,
> > - <4>,
> > - <5>, <6>,
> > - <15>,
> > - <24>, <25>,
> > - <26>, <27>,
> > - <28>, <29>;
> > - clock-output-names = "dram_ve",
> > - "dram_csi0", "dram_csi1",
> > - "dram_ts",
> > - "dram_tvd",
> > - "dram_tve0", "dram_tve1",
> > - "dram_output",
> > - "dram_de_fe1", "dram_de_fe0",
> > - "dram_de_be0", "dram_de_be1",
> > - "dram_de_mp", "dram_ace";
> > - };
> > -
> > - de_be0_clk: clk at 01c20104 {
> > - #clock-cells = <0>;
> > - #reset-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-display-clk";
> > - reg = <0x01c20104 0x4>;
> > - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> > - clock-output-names = "de-be0";
> > - };
> > -
> > - de_be1_clk: clk at 01c20108 {
> > - #clock-cells = <0>;
> > - #reset-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-display-clk";
> > - reg = <0x01c20108 0x4>;
> > - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> > - clock-output-names = "de-be1";
> > - };
> > -
> > - de_fe0_clk: clk at 01c2010c {
> > - #clock-cells = <0>;
> > - #reset-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-display-clk";
> > - reg = <0x01c2010c 0x4>;
> > - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> > - clock-output-names = "de-fe0";
> > - };
> > -
> > - de_fe1_clk: clk at 01c20110 {
> > - #clock-cells = <0>;
> > - #reset-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-display-clk";
> > - reg = <0x01c20110 0x4>;
> > - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> > - clock-output-names = "de-fe1";
> > - };
> > -
> > -
> > - tcon0_ch0_clk: clk at 01c20118 {
> > - #clock-cells = <0>;
> > - #reset-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
> > - reg = <0x01c20118 0x4>;
> > - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> > - clock-output-names = "tcon0-ch0-sclk";
> > -
> > - };
> > -
> > - tcon1_ch0_clk: clk at 01c2011c {
> > - #clock-cells = <0>;
> > - #reset-cells = <1>;
> > - compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
> > - reg = <0x01c2011c 0x4>;
> > - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> > - clock-output-names = "tcon1-ch0-sclk";
> > -
> > - };
> > -
> > - tcon0_ch1_clk: clk at 01c2012c {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
> > - reg = <0x01c2012c 0x4>;
> > - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> > - clock-output-names = "tcon0-ch1-sclk";
> > -
> > - };
> > -
> > - tcon1_ch1_clk: clk at 01c20130 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
> > - reg = <0x01c20130 0x4>;
> > - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> > - clock-output-names = "tcon1-ch1-sclk";
> > -
> > - };
> > -
> > - ve_clk: clk at 01c2013c {
> > - #clock-cells = <0>;
> > - #reset-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-ve-clk";
> > - reg = <0x01c2013c 0x4>;
> > - clocks = <&pll4>;
> > - clock-output-names = "ve";
> > - };
> > -
> > - codec_clk: clk at 01c20140 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun4i-a10-codec-clk";
> > - reg = <0x01c20140 0x4>;
> > - clocks = <&pll2 SUN4I_A10_PLL2_1X>;
> > - clock-output-names = "codec";
> > - };
> > };
> >
> > soc at 01c00000 {
> > @@ -717,7 +233,7 @@
> > compatible = "allwinner,sun4i-a10-dma";
> > reg = <0x01c02000 0x1000>;
> > interrupts = <27>;
> > - clocks = <&ahb_gates 6>;
> > + clocks = <&ccu CLK_AHB_DMA>;
> > #dma-cells = <2>;
> > };
> >
> > @@ -725,7 +241,7 @@
> > compatible = "allwinner,sun4i-a10-nand";
> > reg = <0x01c03000 0x1000>;
> > interrupts = <37>;
> > - clocks = <&ahb_gates 13>, <&nand_clk>;
> > + clocks = <&ccu CLK_AHB_NAND>, <&ccu CLK_NAND>;
> > clock-names = "ahb", "mod";
> > dmas = <&dma SUN4I_DMA_DEDICATED 3>;
> > dma-names = "rxtx";
> > @@ -738,7 +254,7 @@
> > compatible = "allwinner,sun4i-a10-spi";
> > reg = <0x01c05000 0x1000>;
> > interrupts = <10>;
> > - clocks = <&ahb_gates 20>, <&spi0_clk>;
> > + clocks = <&ccu CLK_AHB_SPI0>, <&ccu CLK_SPI0>;
> > clock-names = "ahb", "mod";
> > dmas = <&dma SUN4I_DMA_DEDICATED 27>,
> > <&dma SUN4I_DMA_DEDICATED 26>;
> > @@ -752,7 +268,7 @@
> > compatible = "allwinner,sun4i-a10-spi";
> > reg = <0x01c06000 0x1000>;
> > interrupts = <11>;
> > - clocks = <&ahb_gates 21>, <&spi1_clk>;
> > + clocks = <&ccu CLK_AHB_SPI1>, <&ccu CLK_SPI1>;
> > clock-names = "ahb", "mod";
> > dmas = <&dma SUN4I_DMA_DEDICATED 9>,
> > <&dma SUN4I_DMA_DEDICATED 8>;
> > @@ -766,7 +282,7 @@
> > compatible = "allwinner,sun4i-a10-emac";
> > reg = <0x01c0b000 0x1000>;
> > interrupts = <55>;
> > - clocks = <&ahb_gates 17>;
> > + clocks = <&ccu CLK_AHB_EMAC>;
> > allwinner,sram = <&emac_sram 1>;
> > status = "disabled";
> > };
> > @@ -782,10 +298,10 @@
> > mmc0: mmc at 01c0f000 {
> > compatible = "allwinner,sun4i-a10-mmc";
> > reg = <0x01c0f000 0x1000>;
> > - clocks = <&ahb_gates 8>,
> > - <&mmc0_clk 0>,
> > - <&mmc0_clk 1>,
> > - <&mmc0_clk 2>;
> > + clocks = <&ccu CLK_AHB_MMC0>,
> > + <&ccu CLK_MMC0>,
> > + <&ccu CLK_MMC0_OUTPUT>,
> > + <&ccu CLK_MMC0_SAMPLE>;
> > clock-names = "ahb",
> > "mmc",
> > "output",
> > @@ -799,10 +315,10 @@
> > mmc1: mmc at 01c10000 {
> > compatible = "allwinner,sun4i-a10-mmc";
> > reg = <0x01c10000 0x1000>;
> > - clocks = <&ahb_gates 9>,
> > - <&mmc1_clk 0>,
> > - <&mmc1_clk 1>,
> > - <&mmc1_clk 2>;
> > + clocks = <&ccu CLK_AHB_MMC1>,
> > + <&ccu CLK_MMC1>,
> > + <&ccu CLK_MMC1_OUTPUT>,
> > + <&ccu CLK_MMC1_SAMPLE>;
> > clock-names = "ahb",
> > "mmc",
> > "output",
> > @@ -816,10 +332,10 @@
> > mmc2: mmc at 01c11000 {
> > compatible = "allwinner,sun4i-a10-mmc";
> > reg = <0x01c11000 0x1000>;
> > - clocks = <&ahb_gates 10>,
> > - <&mmc2_clk 0>,
> > - <&mmc2_clk 1>,
> > - <&mmc2_clk 2>;
> > + clocks = <&ccu CLK_AHB_MMC2>,
> > + <&ccu CLK_MMC2>,
> > + <&ccu CLK_MMC2_OUTPUT>,
> > + <&ccu CLK_MMC2_SAMPLE>;
> > clock-names = "ahb",
> > "mmc",
> > "output",
> > @@ -833,10 +349,10 @@
> > mmc3: mmc at 01c12000 {
> > compatible = "allwinner,sun4i-a10-mmc";
> > reg = <0x01c12000 0x1000>;
> > - clocks = <&ahb_gates 11>,
> > - <&mmc3_clk 0>,
> > - <&mmc3_clk 1>,
> > - <&mmc3_clk 2>;
> > + clocks = <&ccu CLK_AHB_MMC3>,
> > + <&ccu CLK_MMC3>,
> > + <&ccu CLK_MMC3_OUTPUT>,
> > + <&ccu CLK_MMC3_SAMPLE>;
> > clock-names = "ahb",
> > "mmc",
> > "output",
> > @@ -850,7 +366,7 @@
> > usb_otg: usb at 01c13000 {
> > compatible = "allwinner,sun4i-a10-musb";
> > reg = <0x01c13000 0x0400>;
> > - clocks = <&ahb_gates 0>;
> > + clocks = <&ccu CLK_AHB_OTG>;
> > interrupts = <38>;
> > interrupt-names = "mc";
> > phys = <&usbphy 0>;
> > @@ -865,9 +381,11 @@
> > compatible = "allwinner,sun4i-a10-usb-phy";
> > reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>;
> > reg-names = "phy_ctrl", "pmu1", "pmu2";
> > - clocks = <&usb_clk 8>;
> > + clocks = <&ccu CLK_USB_PHY>;
> > clock-names = "usb_phy";
> > - resets = <&usb_clk 0>, <&usb_clk 1>, <&usb_clk 2>;
> > + resets = <&ccu RST_USB_PHY0>,
> > + <&ccu RST_USB_PHY1>,
> > + <&ccu RST_USB_PHY2>;
> > reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
> > status = "disabled";
> > };
> > @@ -876,7 +394,7 @@
> > compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
> > reg = <0x01c14000 0x100>;
> > interrupts = <39>;
> > - clocks = <&ahb_gates 1>;
> > + clocks = <&ccu CLK_AHB_EHCI0>;
> > phys = <&usbphy 1>;
> > phy-names = "usb";
> > status = "disabled";
> > @@ -886,7 +404,7 @@
> > compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> > reg = <0x01c14400 0x100>;
> > interrupts = <64>;
> > - clocks = <&usb_clk 6>, <&ahb_gates 2>;
> > + clocks = <&ccu CLK_USB_OHCI0>, <&ccu CLK_AHB_OHCI0>;
> > phys = <&usbphy 1>;
> > phy-names = "usb";
> > status = "disabled";
> > @@ -896,7 +414,7 @@
> > compatible = "allwinner,sun4i-a10-crypto";
> > reg = <0x01c15000 0x1000>;
> > interrupts = <86>;
> > - clocks = <&ahb_gates 5>, <&ss_clk>;
> > + clocks = <&ccu CLK_AHB_SS>, <&ccu CLK_SS>;
> > clock-names = "ahb", "mod";
> > };
> >
> > @@ -904,7 +422,7 @@
> > compatible = "allwinner,sun4i-a10-spi";
> > reg = <0x01c17000 0x1000>;
> > interrupts = <12>;
> > - clocks = <&ahb_gates 22>, <&spi2_clk>;
> > + clocks = <&ccu CLK_AHB_SPI2>, <&ccu CLK_SPI2>;
> > clock-names = "ahb", "mod";
> > dmas = <&dma SUN4I_DMA_DEDICATED 29>,
> > <&dma SUN4I_DMA_DEDICATED 28>;
> > @@ -918,7 +436,8 @@
> > compatible = "allwinner,sun4i-a10-ahci";
> > reg = <0x01c18000 0x1000>;
> > interrupts = <56>;
> > - clocks = <&pll6 0>, <&ahb_gates 25>;
> > + clocks = <&ccu CLK_PLL_PERIPH_SATA>,
> > + <&ccu CLK_AHB_SATA>;
> > status = "disabled";
> > };
> >
> > @@ -926,7 +445,7 @@
> > compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
> > reg = <0x01c1c000 0x100>;
> > interrupts = <40>;
> > - clocks = <&ahb_gates 3>;
> > + clocks = <&ccu CLK_AHB_EHCI1>;
> > phys = <&usbphy 2>;
> > phy-names = "usb";
> > status = "disabled";
> > @@ -936,7 +455,7 @@
> > compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> > reg = <0x01c1c400 0x100>;
> > interrupts = <65>;
> > - clocks = <&usb_clk 7>, <&ahb_gates 4>;
> > + clocks = <&ccu CLK_USB_OHCI1>, <&ccu CLK_AHB_OHCI1>;
> > phys = <&usbphy 2>;
> > phy-names = "usb";
> > status = "disabled";
> > @@ -946,7 +465,7 @@
> > compatible = "allwinner,sun4i-a10-spi";
> > reg = <0x01c1f000 0x1000>;
> > interrupts = <50>;
> > - clocks = <&ahb_gates 23>, <&spi3_clk>;
> > + clocks = <&ccu CLK_AHB_SPI3>, <&ccu CLK_SPI3>;
> > clock-names = "ahb", "mod";
> > dmas = <&dma SUN4I_DMA_DEDICATED 31>,
> > <&dma SUN4I_DMA_DEDICATED 30>;
> > @@ -956,6 +475,15 @@
> > #size-cells = <0>;
> > };
> >
> > + ccu: clock at 01c20000 {
> > + compatible = "allwinner,sun4i-a10-ccu";
> > + reg = <0x01c20000 0x400>;
> > + clocks = <&osc24M>, <&osc32k>;
> > + clock-names = "hosc", "losc";
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
> > +
> > intc: interrupt-controller at 01c20400 {
> > compatible = "allwinner,sun4i-a10-ic";
> > reg = <0x01c20400 0x400>;
> > @@ -967,7 +495,7 @@
> > compatible = "allwinner,sun4i-a10-pinctrl";
> > reg = <0x01c20800 0x400>;
> > interrupts = <28>;
> > - clocks = <&apb0_gates 5>, <&osc24M>, <&osc32k>;
> > + clocks = <&ccu CLK_APB0_PIO>, <&osc24M>, <&osc32k>;
> > clock-names = "apb", "hosc", "losc";
> > gpio-controller;
> > interrupt-controller;
> > @@ -1145,7 +673,7 @@
> > compatible = "allwinner,sun4i-a10-spdif";
> > reg = <0x01c21000 0x400>;
> > interrupts = <13>;
> > - clocks = <&apb0_gates 1>, <&spdif_clk>;
> > + clocks = <&ccu CLK_APB0_SPDIF>, <&ccu CLK_SPDIF>;
> > clock-names = "apb", "spdif";
> > dmas = <&dma SUN4I_DMA_NORMAL 2>,
> > <&dma SUN4I_DMA_NORMAL 2>;
> > @@ -1155,7 +683,7 @@
> >
> > ir0: ir at 01c21800 {
> > compatible = "allwinner,sun4i-a10-ir";
> > - clocks = <&apb0_gates 6>, <&ir0_clk>;
> > + clocks = <&ccu CLK_APB0_IR0>, <&ccu CLK_IR0>;
> > clock-names = "apb", "ir";
> > interrupts = <5>;
> > reg = <0x01c21800 0x40>;
> > @@ -1164,7 +692,7 @@
> >
> > ir1: ir at 01c21c00 {
> > compatible = "allwinner,sun4i-a10-ir";
> > - clocks = <&apb0_gates 7>, <&ir1_clk>;
> > + clocks = <&ccu CLK_APB0_IR1>, <&ccu CLK_IR1>;
> > clock-names = "apb", "ir";
> > interrupts = <6>;
> > reg = <0x01c21c00 0x40>;
> > @@ -1183,7 +711,7 @@
> > compatible = "allwinner,sun4i-a10-codec";
> > reg = <0x01c22c00 0x40>;
> > interrupts = <30>;
> > - clocks = <&apb0_gates 0>, <&codec_clk>;
> > + clocks = <&ccu CLK_APB0_CODEC>, <&ccu CLK_CODEC>;
> > clock-names = "apb", "codec";
> > dmas = <&dma SUN4I_DMA_NORMAL 19>,
> > <&dma SUN4I_DMA_NORMAL 19>;
> > @@ -1209,7 +737,7 @@
> > interrupts = <1>;
> > reg-shift = <2>;
> > reg-io-width = <4>;
> > - clocks = <&apb1_gates 16>;
> > + clocks = <&ccu CLK_APB1_UART0>;
> > status = "disabled";
> > };
> >
> > @@ -1219,7 +747,7 @@
> > interrupts = <2>;
> > reg-shift = <2>;
> > reg-io-width = <4>;
> > - clocks = <&apb1_gates 17>;
> > + clocks = <&ccu CLK_APB1_UART1>;
> > status = "disabled";
> > };
> >
> > @@ -1229,7 +757,7 @@
> > interrupts = <3>;
> > reg-shift = <2>;
> > reg-io-width = <4>;
> > - clocks = <&apb1_gates 18>;
> > + clocks = <&ccu CLK_APB1_UART2>;
> > status = "disabled";
> > };
> >
> > @@ -1239,7 +767,7 @@
> > interrupts = <4>;
> > reg-shift = <2>;
> > reg-io-width = <4>;
> > - clocks = <&apb1_gates 19>;
> > + clocks = <&ccu CLK_APB1_UART3>;
> > status = "disabled";
> > };
> >
> > @@ -1249,7 +777,7 @@
> > interrupts = <17>;
> > reg-shift = <2>;
> > reg-io-width = <4>;
> > - clocks = <&apb1_gates 20>;
> > + clocks = <&ccu CLK_APB1_UART4>;
> > status = "disabled";
> > };
> >
> > @@ -1259,7 +787,7 @@
> > interrupts = <18>;
> > reg-shift = <2>;
> > reg-io-width = <4>;
> > - clocks = <&apb1_gates 21>;
> > + clocks = <&ccu CLK_APB1_UART5>;
> > status = "disabled";
> > };
> >
> > @@ -1269,7 +797,7 @@
> > interrupts = <19>;
> > reg-shift = <2>;
> > reg-io-width = <4>;
> > - clocks = <&apb1_gates 22>;
> > + clocks = <&ccu CLK_APB1_UART6>;
> > status = "disabled";
> > };
> >
> > @@ -1279,7 +807,7 @@
> > interrupts = <20>;
> > reg-shift = <2>;
> > reg-io-width = <4>;
> > - clocks = <&apb1_gates 23>;
> > + clocks = <&ccu CLK_APB1_UART7>;
> > status = "disabled";
> > };
> >
> > @@ -1287,7 +815,7 @@
> > compatible = "allwinner,sun4i-a10-i2c";
> > reg = <0x01c2ac00 0x400>;
> > interrupts = <7>;
> > - clocks = <&apb1_gates 0>;
> > + clocks = <&ccu CLK_APB1_I2C0>;
> > status = "disabled";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > @@ -1297,7 +825,7 @@
> > compatible = "allwinner,sun4i-a10-i2c";
> > reg = <0x01c2b000 0x400>;
> > interrupts = <8>;
> > - clocks = <&apb1_gates 1>;
> > + clocks = <&ccu CLK_APB1_I2C1>;
> > status = "disabled";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > @@ -1307,7 +835,7 @@
> > compatible = "allwinner,sun4i-a10-i2c";
> > reg = <0x01c2b400 0x400>;
> > interrupts = <9>;
> > - clocks = <&apb1_gates 2>;
> > + clocks = <&ccu CLK_APB1_I2C2>;
> > status = "disabled";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > @@ -1317,7 +845,7 @@
> > compatible = "allwinner,sun4i-a10-ps2";
> > reg = <0x01c2a000 0x400>;
> > interrupts = <62>;
> > - clocks = <&apb1_gates 6>;
> > + clocks = <&ccu CLK_APB1_PS20>;
> > status = "disabled";
> > };
> >
> > @@ -1325,7 +853,7 @@
> > compatible = "allwinner,sun4i-a10-ps2";
> > reg = <0x01c2a400 0x400>;
> > interrupts = <63>;
> > - clocks = <&apb1_gates 7>;
> > + clocks = <&ccu CLK_APB1_PS21>;
> > status = "disabled";
> > };
> > };
> > --
> > git-series 0.9.1
> >
> > --
> > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Russell King - ARM Linux @ 2017-12-12 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AftAWz339Sy+oxQ8K9Dr04Jyf8SV0R0JGrcPaL-VQLMQ@mail.gmail.com>
On Tue, Dec 12, 2017 at 02:56:18PM -0200, Fabio Estevam wrote:
> Hi Paul,
>
> On Tue, Dec 12, 2017 at 2:49 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
>
> > On the perhaps unlikely off-chance that it is both useful and welcome,
> > the (untested, probably does not even build) patch below illustrates the
> > use of smp_call_function_single(). This is based on the patch Russell
> > sent -- for all I know, it might well be that there are other places
> > needing similar changes.
> >
> > But something to try out for anyone wishing to do so.
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > commit c579a1494ccbc7ebf5548115571a2988ea1a1fe5
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Date: Mon Dec 11 09:40:58 2017 -0800
> >
> > ARM: CPU hotplug: Delegate complete() to surviving CPU
> >
> > The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
> > does so after RCU has stopped watching the outgoing CPU, which results
> > in lockdep complaints because complete() invokes functions containing RCU
> > readers. This patch therefore uses Thomas Gleixner's trick of delegating
> > the complete() call to a surviving CPU via smp_call_function_single().
> >
> > This patch is untested, and probably does not even build.
> >
> > Reported-by: Peng Fan <van.freenix@gmail.com>
> > Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> With your patch applied I no longer get the RCU warning, thanks:
>
> Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
It's fundamentally unsafe.
You need to test with CONFIG_BL_SWITCHER enabled - there's spinlocks
in smp_call_function_single() path that are conditional on that symbol.
If CONFIG_BL_SWITCHER is disabled, then the spinlocks are not present.
The problem is that the IPI will be sent with the spinlock held. The
IPI'd CPU will then do the completion, and the CPU requesting the
death will continue, and could power down the dying CPU _before_ the
unlock of that spinlock becomes visible to other CPUs in the system.
So, we end up with a spinlock permanently held.
Whether this happens or not depends on timing, and whether the unlock
gets evicted from the dying CPU.
If you attempt to clean the caches after the unlock to force that unlock
out, then you need a way to make the requesting CPU wait for the dying
CPU to finish that action... oh, that's what this complete() is trying
to do here in the first place.
So we're back to exactly where we were without this patch.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU
From: Russell King - ARM Linux @ 2017-12-12 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212172059.GA11875@linux.vnet.ibm.com>
On Tue, Dec 12, 2017 at 09:20:59AM -0800, Paul E. McKenney wrote:
> The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
> does so after RCU has stopped watching the outgoing CPU, which results
> in lockdep complaints because complete() invokes functions containing RCU
> readers. This patch therefore uses Thomas Gleixner's trick of delegating
> the complete() call to a surviving CPU via smp_call_function_single().
>
> Reported-by: Peng Fan <van.freenix@gmail.com>
> Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Tested-by: Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: <linux-arm-kernel@lists.infradead.org>
As I just described in response to Fabio's testing, this doesn't solve
anything if CONFIG_BL_SWITCHER is enabled. We could lose the unlock of
a spinlock in the GIC code for sending the IPI. As I already said
previously in our discussion (but I guess you just don't believe me):
"2. there's some optional locking in the GIC driver that cause problems
for the cpu dying path.
The concensus last time around was that the IPI solution is a non-
starter, so the seven year proven-reliable solution (disregarding the
RCU warning) persists because I don't think anyone came up with a
better solution."
Using smp_call_function_single() invokes the IPI paths.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU
From: Baruch Siach @ 2017-12-12 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212172059.GA11875@linux.vnet.ibm.com>
Hi Paul,
On Tue, Dec 12, 2017 at 09:20:59AM -0800, Paul E. McKenney wrote:
> The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
> does so after RCU has stopped watching the outgoing CPU, which results
> in lockdep complaints because complete() invokes functions containing RCU
> readers. This patch therefore uses Thomas Gleixner's trick of delegating
> the complete() call to a surviving CPU via smp_call_function_single().
>
> Reported-by: Peng Fan <van.freenix@gmail.com>
> Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Tested-by: Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
Fabio reported only once, though he might have tested twice.
baruch
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: <linux-arm-kernel@lists.infradead.org>
>
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index b4fbf00ee4ad..75f85e20aafa 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -267,6 +267,14 @@ void __cpu_die(unsigned int cpu)
> }
>
> /*
> + * Invoke complete() on behalf of the outgoing CPU.
> + */
> +static void arch_cpu_idle_dead_complete(void *arg)
> +{
> + complete(&cpu_died);
> +}
> +
> +/*
> * Called from the idle thread for the CPU which has been shutdown.
> *
> * Note that we disable IRQs here, but do not re-enable them
> @@ -293,9 +301,11 @@ void arch_cpu_idle_dead(void)
> /*
> * Tell __cpu_die() that this CPU is now safe to dispose of. Once
> * this returns, power and/or clocks can be removed at any point
> - * from this CPU and its cache by platform_cpu_kill().
> + * from this CPU and its cache by platform_cpu_kill(). We cannot
> + * call complete() this late, so we delegate it to an online CPU.
> */
> - complete(&cpu_died);
> + smp_call_function_single(cpumask_first(cpu_online_mask),
> + arch_cpu_idle_dead_complete, NULL, 0);
>
> /*
> * Ensure that the cache lines associated with that completion are
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH] pinctrl: rockchip: enable clock when reading pin direction register
From: Brian Norris @ 2017-12-12 17:43 UTC (permalink / raw)
To: linux-arm-kernel
We generally leave the GPIO clock disabled, unless an interrupt is
requested or we're accessing IO registers. We forgot to do this for the
->get_direction() callback, which means we can sometimes [1] get
incorrect results [2] from, e.g., /sys/kernel/debug/gpio.
Enable the clock, so we get the right results!
[1] Sometimes, because many systems have 1 or mor interrupt requested on
each GPIO bank, so they always leave their clock on.
[2] Incorrect, meaning the register returns 0, and so we interpret that
as "input".
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
drivers/pinctrl/pinctrl-rockchip.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
index 2ba17548ad5b..073de6a9ed34 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -2014,8 +2014,16 @@ static int rockchip_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
{
struct rockchip_pin_bank *bank = gpiochip_get_data(chip);
u32 data;
+ int ret;
+ ret = clk_enable(bank->clk);
+ if (ret < 0) {
+ dev_err(bank->drvdata->dev,
+ "failed to enable clock for bank %s\n", bank->name);
+ return ret;
+ }
data = readl_relaxed(bank->reg_base + GPIO_SWPORT_DDR);
+ clk_disable(bank->clk);
return !(data & BIT(offset));
}
--
2.15.1.424.g9478a66081-goog
^ permalink raw reply related
* [PATCH 1/2] cpufreq: ARM: sort the Kconfig menu
From: Randy Dunlap @ 2017-12-12 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212165419.752-2-gregory.clement@free-electrons.com>
On 12/12/2017 08:54 AM, Gregory CLEMENT wrote:
> Group all the related big LITTLE configuration together and sort the
> other entries in alphabetic order.
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> drivers/cpufreq/Kconfig.arm | 82 ++++++++++++++++++++++-----------------------
> 1 file changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index bdce4488ded1..0baf43837b51 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -2,6 +2,23 @@
> # ARM CPU Frequency scaling drivers
> #
>
> +config ACPI_CPPC_CPUFREQ
> + tristate "CPUFreq driver based on the ACPI CPPC spec"
> + depends on ACPI_PROCESSOR
> + select ACPI_CPPC_LIB
> + default n
Drop "default n" since that is the default default.
> + help
> + This adds a CPUFreq driver which uses CPPC methods
> + as described in the ACPIv5.1 spec. CPPC stands for
> + Collaborative Processor Performance Controls. It
> + is based on an abstract continuous scale of CPU
> + performance values which allows the remote power
> + processor to flexibly optimize for power and
> + performance. CPPC relies on power management firmware
> + support for its operation.
> +
> + If in doubt, say N.
> +
> # big LITTLE core layer and glue drivers
> config ARM_BIG_LITTLE_CPUFREQ
> tristate "Generic ARM big LITTLE CPUfreq driver"
> @@ -12,6 +29,30 @@ config ARM_BIG_LITTLE_CPUFREQ
> help
> This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
>
> +config ARM_DT_BL_CPUFREQ
> + tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
> + depends on ARM_BIG_LITTLE_CPUFREQ && OF
> + help
> + This enables probing via DT for Generic CPUfreq driver for ARM
> + big.LITTLE platform. This gets frequency tables from DT.
> +
> +config ARM_SCPI_CPUFREQ
> + tristate "SCPI based CPUfreq driver"
> + depends on ARM_BIG_LITTLE_CPUFREQ && ARM_SCPI_PROTOCOL && COMMON_CLK_SCPI
> + help
Fix the help and tristate lines -- use tab instead of spaces.
> + This adds the CPUfreq driver support for ARM big.LITTLE platforms
> + using SCPI protocol for CPU power management.
> +
> + This driver uses SCPI Message Protocol driver to interact with the
> + firmware providing the CPU DVFS functionality.
> +
> +config ARM_VEXPRESS_SPC_CPUFREQ
> + tristate "Versatile Express SPC based CPUfreq driver"
> + depends on ARM_BIG_LITTLE_CPUFREQ && ARCH_VEXPRESS_SPC
> + help
Use tab instead of spaces above. Oh, and one line below.
> + This add the CPUfreq driver support for Versatile Express
> + big.LITTLE platforms using SPC for power management.
> +
> config ARM_BRCMSTB_AVS_CPUFREQ
> tristate "Broadcom STB AVS CPUfreq driver"
> depends on ARCH_BRCMSTB || COMPILE_TEST
--
~Randy
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Krzysztof Kozlowski @ 2017-12-12 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212074208.30753-1-javierm@redhat.com>
On Tue, Dec 12, 2017 at 08:42:08AM +0100, Javier Martinez Canillas wrote:
> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>
> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> ---
>
> Changes in v2:
> - Remove RFT tag.
> - Add Marek's Acked-by tag.
> - Add fixes tag.
>
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
Thanks, applied for current cycle (fixes).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/3] Enable DMA on STM32 MCU based on cortex-M7
From: Alexandre Torgue @ 2017-12-12 18:02 UTC (permalink / raw)
To: linux-arm-kernel
This series enable DMA on several STM32 MCU based on cortex-M7.
To make it possible, a dedicated dma pool memory area has to be
created. This patchset activate also ARM_MPU flag which will configure
MPU (Memory Protection Unit) according to devicetree information (mem
and dma-pool). Note that on cortex-M7 DMA has to use a NO cache-able
memory region.
Regards
Alex
Alexandre Torgue (3):
ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
ARM: configs: stm32: Enable ARM_MPU
ARM: dts: stm32: enable dma on MCU which embed a cortex-M7
arch/arm/boot/dts/stm32746g-eval.dts | 21 +++++++++++++++++++++
arch/arm/boot/dts/stm32f769-disco.dts | 21 +++++++++++++++++++++
arch/arm/boot/dts/stm32h743i-disco.dts | 21 +++++++++++++++++++++
arch/arm/boot/dts/stm32h743i-eval.dts | 21 +++++++++++++++++++++
arch/arm/configs/stm32_defconfig | 1 +
5 files changed, 85 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
From: Alexandre Torgue @ 2017-12-12 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513101746-18030-1-git-send-email-alexandre.torgue@st.com>
On cortex-M7 MCU, DMA have to use a non cache-able memory area. For this
reason a dedicated memory pool is created for DMA.
This patch creates a DMA memory pool of 1MB of each STM32 MCU which
embeds a cortex-M7 expect stm32f746-disco. Indeed, as stm32f746-disco has
only a 8MB SDRAM and it's tricky to reduce memory used by Kernel.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
diff --git a/arch/arm/boot/dts/stm32746g-eval.dts b/arch/arm/boot/dts/stm32746g-eval.dts
index 2d4e717..3f52a7b 100644
--- a/arch/arm/boot/dts/stm32746g-eval.dts
+++ b/arch/arm/boot/dts/stm32746g-eval.dts
@@ -57,6 +57,19 @@
reg = <0xc0000000 0x2000000>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ linux,dma {
+ compatible = "shared-dma-pool";
+ linux,dma-default;
+ no-map;
+ reg = <0xc1f00000 0x100000>;
+ };
+ };
+
aliases {
serial0 = &usart1;
};
diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
index 4463ca1..08699a2 100644
--- a/arch/arm/boot/dts/stm32f769-disco.dts
+++ b/arch/arm/boot/dts/stm32f769-disco.dts
@@ -57,6 +57,19 @@
reg = <0xC0000000 0x1000000>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ linux,dma {
+ compatible = "shared-dma-pool";
+ linux,dma-default;
+ no-map;
+ reg = <0xc0f00000 0x100000>;
+ };
+ };
+
aliases {
serial0 = &usart1;
};
diff --git a/arch/arm/boot/dts/stm32h743i-disco.dts b/arch/arm/boot/dts/stm32h743i-disco.dts
index 79e841d..104545a 100644
--- a/arch/arm/boot/dts/stm32h743i-disco.dts
+++ b/arch/arm/boot/dts/stm32h743i-disco.dts
@@ -57,6 +57,19 @@
reg = <0xd0000000 0x2000000>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ linux,dma {
+ compatible = "shared-dma-pool";
+ linux,dma-default;
+ no-map;
+ reg = <0xc1f00000 0x100000>;
+ };
+ };
+
aliases {
serial0 = &usart2;
};
diff --git a/arch/arm/boot/dts/stm32h743i-eval.dts b/arch/arm/boot/dts/stm32h743i-eval.dts
index 9f0e72c..5bd4b16 100644
--- a/arch/arm/boot/dts/stm32h743i-eval.dts
+++ b/arch/arm/boot/dts/stm32h743i-eval.dts
@@ -57,6 +57,19 @@
reg = <0xd0000000 0x2000000>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ linux,dma {
+ compatible = "shared-dma-pool";
+ linux,dma-default;
+ no-map;
+ reg = <0xc1f00000 0x100000>;
+ };
+ };
+
aliases {
serial0 = &usart1;
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: configs: stm32: Enable ARM_MPU
From: Alexandre Torgue @ 2017-12-12 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513101746-18030-1-git-send-email-alexandre.torgue@st.com>
STM32 MCUs embed a Memory Protection Unit. Enabling this setting will
allow the Kernel to configure the MPU according to devicetree.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index bb358ff..e642bdf9 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -24,6 +24,7 @@ CONFIG_SET_MEM_PARAM=y
CONFIG_DRAM_BASE=0x90000000
CONFIG_FLASH_MEM_BASE=0x08000000
CONFIG_FLASH_SIZE=0x00200000
+CONFIG_ARM_MPU=y
CONFIG_PREEMPT=y
# CONFIG_ATAGS is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: stm32: enable dma on MCU which embed a cortex-M7
From: Alexandre Torgue @ 2017-12-12 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513101746-18030-1-git-send-email-alexandre.torgue@st.com>
Enable dma1 and dma2 on:
-stm32746g-eval board
-stm32f769-disco board
-stm32h743i-disco board
-stm32h743i-eval board
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
diff --git a/arch/arm/boot/dts/stm32746g-eval.dts b/arch/arm/boot/dts/stm32746g-eval.dts
index 3f52a7b..2662a27 100644
--- a/arch/arm/boot/dts/stm32746g-eval.dts
+++ b/arch/arm/boot/dts/stm32746g-eval.dts
@@ -113,6 +113,14 @@
status = "okay";
};
+&dma1 {
+ status = "okay";
+};
+
+&dma2 {
+ status = "okay";
+};
+
&i2c1 {
pinctrl-0 = <&i2c1_pins_b>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
index 08699a2..b9b1ffd 100644
--- a/arch/arm/boot/dts/stm32f769-disco.dts
+++ b/arch/arm/boot/dts/stm32f769-disco.dts
@@ -86,6 +86,14 @@
clock-frequency = <25000000>;
};
+&dma1 {
+ status = "okay";
+};
+
+&dma2 {
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins_a>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/stm32h743i-disco.dts b/arch/arm/boot/dts/stm32h743i-disco.dts
index 104545a..2d9e553 100644
--- a/arch/arm/boot/dts/stm32h743i-disco.dts
+++ b/arch/arm/boot/dts/stm32h743i-disco.dts
@@ -79,6 +79,14 @@
clock-frequency = <125000000>;
};
+&dma1 {
+ status = "okay";
+};
+
+&dma2 {
+ status = "okay";
+};
+
&usart2 {
pinctrl-0 = <&usart2_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/stm32h743i-eval.dts b/arch/arm/boot/dts/stm32h743i-eval.dts
index 5bd4b16..3face6a 100644
--- a/arch/arm/boot/dts/stm32h743i-eval.dts
+++ b/arch/arm/boot/dts/stm32h743i-eval.dts
@@ -97,6 +97,14 @@
clock-frequency = <25000000>;
};
+&dma1 {
+ status = "okay";
+};
+
+&dma2 {
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins>;
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: verify size of zImage
From: Ard Biesheuvel @ 2017-12-12 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mv2oq67r.fsf@free-electrons.com>
On 12 December 2017 at 16:08, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi Ard,
>
> On mar., nov. 28 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> (+ Gregory)
>>
>> On 28 November 2017 at 16:27, Russell King <rmk+kernel@armlinux.org.uk> wrote:
>>> The linker can sometimes add additional sections to the zImage ELF file
>>> which results in the zImage binary being larger than expected. This
>>> causes appended DT blobs to fail.
>>>
>>> Verify that the zImage binary is the expected size, and fail the build
>>> if this is not the case.
>>>
>>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>>> ---
>>> As this patch is different, I've dropped Matthias' tested-by. I'd
>>> appreciate a replacement, thanks. Also, I seem to remember that
>>> Ard's toolchain was giving issues - maybe this alternative will
>>> finally resolve them.
>>>
>>
>> $ nm arch/arm/boot/compressed/vmlinux |grep _edata
>> 007b8200 D _edata
>> 007b8200 D _edata_real
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> although I don't remember seeing this fail. It think it may have been
>> Gregory who was having these issues?
>
> Thanks to remember me, I finally find time to test it, and with my setup
> I didn't have anymore issue while building it for a dtb append zImage
> for Armada XP:
>
> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
Thanks for confirming.
^ permalink raw reply
* [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports
From: Ladislav Michl @ 2017-12-12 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212170054.GD14441@atomide.com>
On Tue, Dec 12, 2017 at 09:00:54AM -0800, Tony Lindgren wrote:
> Hmm what do you mean? We don't want to export tons of custom functions from
> the timers in and then be in trouble when at some point we have a Linux
> generic hw timer framework. We already had to deal with these custom
> exports earlier with conversion to multiarch and then again with
> device tree.
>
> For now, it's best to pass the timer information to the pwm driver in
> platform data. In the long run that will be much easier to deal with than
> fixing random drivers tinkering with the timer registers directly.
All that register access would happen only in drivers/clocksource/timer-dm.c?
So platform data will hold all function pointers needed for event capture
and the pwm driver will do only interface to pwm framework.
> Ideally the pwm driver would just do a request_irq from the dmtimer code
> where dmtimer code would implement an interrupt controller. That would
> be already most fo the Linux generic hardware timer framework right there :)
I do not follow. Each general-purpose timer module has its own interrupt line,
so claiming that irq directly using request_irq seems enough. Could you
explain interrupt controller idea a bit more?
Thank you,
ladis
^ permalink raw reply
* [PATCH v2] PCI: keystone: fix interrupt-controller-node lookup
From: Lorenzo Pieralisi @ 2017-12-12 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212172537.GB53955@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Dec 12, 2017 at 11:25:37AM -0600, Bjorn Helgaas wrote:
> On Mon, Dec 11, 2017 at 10:42:33AM +0000, Lorenzo Pieralisi wrote:
> > On Mon, Dec 11, 2017 at 11:29:55AM +0100, Johan Hovold wrote:
> > > On Fri, Nov 17, 2017 at 02:38:31PM +0100, Johan Hovold wrote:
> > > > Fix child-node lookup during initialisation which was using the wrong
> > > > OF-helper and ended up searching the whole device tree depth-first
> > > > starting at the parent rather than just matching on its children.
> > > >
> > > > To make things worse, the parent pci node could end up being prematurely
> > > > freed as of_find_node_by_name() drops a reference to its first argument.
> > > > Any matching child interrupt-controller node was also leaked.
> > > >
> > > > Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
> > > > Cc: stable <stable@vger.kernel.org> # 3.18
> > > > Acked-by: Murali Karicheri <m-karicheri2@ti.com>
> > > > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > ---
> > > >
> > > > v2
> > > > - amend commit message and mention explicitly that of_find_node_by_name()
> > > > drops a reference to the start node
> > > > - add Murali's and Lorenzo's acks
> > >
> > > This one hasn't shown up in linux-next, so sending a reminder to make
> > > sure it doesn't fall between the cracks.
> >
> > Hi Johan,
> >
> > yes it is in the list of fixes to be sent upstream - I was about to
> > ask Bjorn to apply it.
>
> Is this something that needs to be merged for v4.15? If so, I need to
> be able to defend it to Linus as being a critical fix. If the issue
> been around for 3 years (v3.18 was tagged Dec 7 2014), that requires
> pretty "clear and present danger."
>
> From the commit log, I see a sub-optimal search (not critical), a
> possible use-after-free (could conceivably be critical if people are
> tripping over this, but would need more specifics about that), and a
> leak (not critical).
>
> Given what I can see now, my inclination would be for Lorenzo to queue
> it for v4.16, which would still get in linux-next soonish.
It is fine by me and I think, as already mentioned, that the stable
tag is dubious so I will probably drop it.
Lorenzo
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Fabio Estevam @ 2017-12-12 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212173450.GD10595@n2100.armlinux.org.uk>
Hi Russell,
On Tue, Dec 12, 2017 at 3:34 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> It's fundamentally unsafe.
>
> You need to test with CONFIG_BL_SWITCHER enabled - there's spinlocks
> in smp_call_function_single() path that are conditional on that symbol.
> If CONFIG_BL_SWITCHER is disabled, then the spinlocks are not present.
Ok, just tested with CONFIG_BL_SWITCHER=y on a imx6q-cubox-i:
# echo enabled > /sys/class/tty/ttymxc0/power/wakeup
# echo mem > /sys/power/state
[ 10.503462] PM: suspend entry (deep)
[ 10.507479] PM: Syncing filesystems ... done.
[ 10.555024] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 10.564511] OOM killer disabled.
[ 10.567760] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) d.
[ 10.577420] Suspending console(s) (use no_console_suspend to debug)
[ 10.657748] PM: suspend devices took 0.080 seconds
[ 10.669329] Disabling non-boot CPUs ...
[ 10.717049] IRQ17 no longer affine to CPU1
[ 10.837141] Enabling non-boot CPUs ...
[ 10.839386] CPU1 is up
[ 10.840342] CPU2 is up
[ 10.841300] CPU3 is up
[ 11.113735] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
[ 11.115676] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[ 11.117595] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[ 11.121014] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[ 11.124454] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[ 11.177299] ata1: SATA link down (SStatus 0 SControl 300)
[ 11.181930] PM: resume devices took 0.330 seconds
[ 11.243729] OOM killer enabled.
[ 11.246886] Restarting tasks ... done.
[ 11.253012] PM: suspend exit
^ permalink raw reply
* [PATCH v2] arm64: cpu_errata: Add Kryo to Falkor 1003 errata
From: Will Deacon @ 2017-12-12 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129230353.11809-1-sboyd@codeaurora.org>
Hi Stephen,
On Wed, Nov 29, 2017 at 03:03:53PM -0800, Stephen Boyd wrote:
> The Kryo CPUs are also affected by the Falkor 1003 errata, so
> we need to do the same workaround on Kryo CPUs. The MIDR is
> slightly more complicated here, where the PART number is not
> always the same when looking at all the bits from 15 to 4. Drop
> the lower 8 bits and just look at the top 4 to see if it's '2'
> and then consider those as Kryo CPUs. This covers all the
> combinations without having to list them all out.
>
> Introduce a new hardware cap bit for the combination of hardware
> PAN support and this errata so that we can disable support for
> software PAN at runtime if this errata is present and the CPU
> doesn't support HW PAN. This happens on some Kryo CPUs where the
> HW PAN feature isn't supported but we can't prevent software PAN
> from being selected in the configuration. Previously, Falkor CPUs
> were all known to have HW PAN support, so we didn't need to worry
> about this case.
>
> Fixes: 38fd94b0275c ("arm64: Work around Falkor erratum 1003")
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
Can you respin this on top of for-next/core please? The PAN bits should
be much simpler with the KPTI code.
Will
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Daniel Vetter @ 2017-12-12 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e506908-153f-2782-e7ef-7f2cc2c48662@samsung.com>
On Tue, Dec 12, 2017 at 12:38 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Hi All,
>
>
> On 2017-12-11 23:28, Javier Martinez Canillas wrote:
>>
>> [adding Marek and Shuah to cc list]
>>
>> On Mon, Dec 11, 2017 at 6:05 PM, Daniel Vetter <daniel.vetter@ffwll.ch>
>> wrote:
>>>
>>> On Mon, Dec 11, 2017 at 11:30 AM, Guillaume Tucker
>>> <guillaume.tucker@collabora.com> wrote:
>>>>
>>>> Hi Daniel,
>>>>
>>>> Please see below, I've had several bisection results pointing at
>>>> that commit over the week-end on mainline but also on linux-next
>>>> and net-next. While the peach-pi is a bit flaky at the moment
>>>> and is likely to have more than one issue, it does seem like this
>>>> commit is causing some well reproducible kernel hang.
>>>>
>>>> Here's a re-run with v4.15-rc3 showing the issue:
>>>>
>>>> https://lava.collabora.co.uk/scheduler/job/1018478
>>>>
>>>> and here's another one with the change mentioned below reverted:
>>>>
>>>> https://lava.collabora.co.uk/scheduler/job/1018479
>>>>
>>>> They both show a warning about "unbalanced disables for lcd_vdd",
>>>> I don't know if this is related as I haven't investigated any
>>>> further. It does appear to reliably hang with v4.15-rc3 and
>>>> boot most of the time with the commit reverted though.
>>>>
>>>> The automated kernelci.org bisection is still an experimental
>>>> tool and it may well be a false positive, so please take this
>>>> result with a pinch of salt...
>>>
>>> The patch just very minimal moves the connector cleanup around (so
>>> timing change), but except when you unload a driver (or maybe that
>>> funny EPROBE_DEFER stuff) it shouldn't matter. So if you don't have
>>> more info than "seems to hang a bit more" I have no idea what's wrong.
>>> The patch itself should work, at least it survived quite some serious
>>> testing we do on everything.
>>> -Daniel
>>>
>> Marek was pointing to a different culprit [0] in this [1] thread. I
>> see that both commits made it to v4.15-rc3, which is the first version
>> where boot fails. So maybe is a combination of both? Or rather
>> reverting one patch masks the error in the other.
>>
>> I've access to the machine but unfortunately not a lot of time to dig
>> on this, I could try to do it in the weekend though.
>
>
> After a recent discussion on the Javier's patch:
> https://patchwork.kernel.org/patch/10106417/
> I've managed to reproduce this issue also on Exynos5250 based Samsung
> Snow Chromebook and investigate a bit.
>
> It is caused by a deadlock in the main kernel workqueue. Here are details:
>
> 1. Exynos DRM fails to initialize due to missing regulators and gets moved
> to deferred probe device list
>
> 2. Deferred probe is triggered and kernel "events" workqueue calls
> deferred_probe_work_func()
>
> 3. exynos_drm_bind() is called, component_bind_all() fails due to missing
> Exynos Mixer device
>
> 4. error handling path is executed in exynos_drm_bind(), which calls
> drm_mode_config_cleanup()
>
> 5. drm_mode_config_cleanup() calls flush_scheduled_work(), what causes
> deadlock.
>
> Do You have idea how to fix this issue properly?
>
> Taking a look at git blame, this indeed shows that the issue has been
> introduced by the commit a703c55004e1 ("drm: safely free connectors from
> connector_ite"), which added a call to flush_scheduled_work() in
> drm_mode_config_cleanup().
>
> drm_mode_config_cleanup() should avoid calling flush_scheduled_work() if
> called from the workqueue, but I don't have idea how to check that. The
> other way of fixing it would be to resurrect separate workqueue for DRM
> related events.
We need to flush the work there, or things will go wrong on unload. I
think the real fix is to make sure that the connector cleanup work
isn't run on the same work stuff as any driver bind stuff, which yes
means new separate workqueue just for this.
I guess the simple fix is to do that in the drm, but tbh I'm surprised
that driver bind/deferred probe hasn't run into this problem anywhere
else yet.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [RESEND PATCH V2] arm64: fault: avoid send SIGBUS two times
From: James Morse @ 2017-12-12 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211160536.11600-1-gengdongjiu@huawei.com>
Hi Dongjiu Geng,
On 11/12/17 16:05, Dongjiu Geng wrote:
> do_sea() calls arm64_notify_die() which will always signal
> user-space. It also returns whether APEI claimed the external
> abort as a RAS notification. If it returns failure do_mem_abort()
> will signal user-space too.
>
> do_mem_abort() wants to know if we handled the error, we always
> call arm64_notify_die() so can always return success.
>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
Nit: Your 'RESEND V2' and 'V2' are not the same patch.
'RESEND' is to indicate you're reposting exactly the same patch, usually with a
fixed CC list. Anyone who receives both can ignore one as you've said they are
the same.
Thanks,
James
^ permalink raw reply
* [PATCH] pinctrl: rockchip: enable clock when reading pin direction register
From: Heiko Stuebner @ 2017-12-12 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212174343.192017-1-briannorris@chromium.org>
Hi Brian,
Am Dienstag, 12. Dezember 2017, 09:43:43 CET schrieb Brian Norris:
> We generally leave the GPIO clock disabled, unless an interrupt is
> requested or we're accessing IO registers. We forgot to do this for the
> ->get_direction() callback, which means we can sometimes [1] get
> incorrect results [2] from, e.g., /sys/kernel/debug/gpio.
>
> Enable the clock, so we get the right results!
>
> [1] Sometimes, because many systems have 1 or mor interrupt requested on
> each GPIO bank, so they always leave their clock on.
>
> [2] Incorrect, meaning the register returns 0, and so we interpret that
> as "input".
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
thanks for catching this and it looks good to me, so
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports
From: Tony Lindgren @ 2017-12-12 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212180317.GB10337@lenoch>
* Ladislav Michl <ladis@linux-mips.org> [171212 18:06]:
> On Tue, Dec 12, 2017 at 09:00:54AM -0800, Tony Lindgren wrote:
> > Hmm what do you mean? We don't want to export tons of custom functions from
> > the timers in and then be in trouble when at some point we have a Linux
> > generic hw timer framework. We already had to deal with these custom
> > exports earlier with conversion to multiarch and then again with
> > device tree.
> >
> > For now, it's best to pass the timer information to the pwm driver in
> > platform data. In the long run that will be much easier to deal with than
> > fixing random drivers tinkering with the timer registers directly.
>
> All that register access would happen only in drivers/clocksource/timer-dm.c?
> So platform data will hold all function pointers needed for event capture
> and the pwm driver will do only interface to pwm framework.
Yes please.
> > Ideally the pwm driver would just do a request_irq from the dmtimer code
> > where dmtimer code would implement an interrupt controller. That would
> > be already most fo the Linux generic hardware timer framework right there :)
>
> I do not follow. Each general-purpose timer module has its own interrupt line,
> so claiming that irq directly using request_irq seems enough. Could you
> explain interrupt controller idea a bit more?
Well let's assume we have drivers/clocksource/timer-dm.c implement
an irq controller. Then the pwm driver would just do:
pwm9: dmtimer-pwm {
compatible = "ti,omap-dmtimer-pwm";
#pwm-cells = <3>;
ti,timers = <&timer9>;
ti,clock-source = <0x00>; /* timer_sys_ck */
interrupts-extended = <&timer9 IRQ_TYPE_SOMETHING>;
};
Then you can do whatever you need to in the pwm driver with
enable_irq/disable_irq + a handler?
If reading the line status is needed.. Then maybe the GPIO framework
needs to have hardware timer support instead?
Anyways, just thinking out loud how we could have a Linux generic
hardware timer framework that drivers like pwm could then use.
Regards,
Tony
^ permalink raw reply
* [PATCH 0/5] Add Sound support for iWave RZ/G1M board
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
This series aims to add sound support for iWave RZ/G1M board.
This patch series has documentation dependency on
https://patchwork.kernel.org/patch/10108014/
Biju Das (5):
ARM: shmobile: defconfig: Enable SGTL5000 audio codec
ARM: dts: r8a7743: Add audio clocks
ARM: dts: r8a7743: Add audio DMAC support
ARM: dts: r8a7743: Add sound support
ARM: dts: iwg20d-q7-common: Enable SGTL5000 audio codec
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 24 +++
arch/arm/boot/dts/r8a7743.dtsi | 270 ++++++++++++++++++++++++++++++++
arch/arm/configs/shmobile_defconfig | 1 +
3 files changed, 295 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH 1/5] ARM: shmobile: defconfig: Enable SGTL5000 audio codec
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
The iWave RZ/G1M Q7 carrier board supports I2S audio codec "SGTL5000".
To increase hardware support enable the driver in the shmobile_defconfig
multiplatform configuration.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/configs/shmobile_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 7b4fc01..d60dbe1 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -173,6 +173,7 @@ CONFIG_SND_SOC=y
CONFIG_SND_SOC_SH4_FSI=y
CONFIG_SND_SOC_RCAR=y
CONFIG_SND_SOC_AK4642=y
+CONFIG_SND_SOC_SGTL5000=y
CONFIG_SND_SOC_WM8978=y
CONFIG_SND_SIMPLE_SCU_CARD=y
CONFIG_USB=y
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: r8a7743: Add audio clocks
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
Describe the external audio clocks required by the sound driver.
Boards that provide audio clocks need to override the clock frequencies.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index c09c667..2f0ec9d 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1238,6 +1238,29 @@
clock-frequency = <0>;
};
+ /*
+ * The external audio clocks are configured as 0 Hz fixed frequency
+ * clocks by default.
+ * Boards that provide audio clocks should override them.
+ */
+ audio_clk_a: audio_clk_a {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ audio_clk_b: audio_clk_b {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ audio_clk_c: audio_clk_c {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
/* External USB clock - can be overridden by the board */
usb_extal_clk: usb_extal {
compatible = "fixed-clock";
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: r8a7743: Add audio DMAC support
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
Instantiate the two audio DMA controllers on the r8a7743 device tree.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 62 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 2f0ec9d..b60527a 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -359,6 +359,68 @@
dma-channels = <15>;
};
+ audma0: dma-controller at ec700000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xec700000 0 0x10000>;
+ interrupts = <GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12";
+ clocks = <&cpg CPG_MOD 502>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 502>;
+ #dma-cells = <1>;
+ dma-channels = <13>;
+ };
+
+ audma1: dma-controller at ec720000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xec720000 0 0x10000>;
+ interrupts = <GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12";
+ clocks = <&cpg CPG_MOD 501>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 501>;
+ #dma-cells = <1>;
+ dma-channels = <13>;
+ };
+
usb_dmac0: dma-controller at e65a0000 {
compatible = "renesas,r8a7743-usb-dmac",
"renesas,usb-dmac";
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox