* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Frank Rowand @ 2016-11-23 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5835DC2D.5080606@gmail.com>
On 11/23/16 10:13, Frank Rowand wrote:
> On 11/22/16 21:55, Sekhar Nori wrote:
>> On Tuesday 22 November 2016 11:51 PM, Frank Rowand wrote:
>>> Please note that the compatible property might contain several strings, not just
>>> a single string.
>>
>> So I guess the best thing to do is to use
>> of_property_read_string_index() and print the sting at index 0.
>>
>> Thanks,
>> Sekhar
>
> If you want to print just one compatible value, you could use that method.
>
> To give all of the information needed to understand the problem, the error
> message would need to include all of the strings contained in the compatible
> property and all of the .board values in the da8xx_ddrctl_board_confs[] array
> (currently only one entry, but coded to allow additional entries in the
> future).
>
> It is hard to justify an error message that complex.
>
> I would just print an error that no match was found.
>
> -Frank
I just needed to read some more emails. I see this approach was taken
in the "[PATCH v4 0/2] da8xx: fix section mismatch in new drivers"
series.
-Frank
^ permalink raw reply
* [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode
From: Matthias Brugger @ 2016-11-23 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1463021701.25171.5.camel@mussux00>
Hi Hongzhou,
On 12/05/16 04:55, Hongzhou Yang wrote:
> On Wed, 2016-05-11 at 19:09 -0700, Hongzhou Yang wrote:
>> On Thu, 2016-05-12 at 09:41 +0800, chunfeng yun wrote:
>>> Hi,
>>>
>>> On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote:
>>>> On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote:
>>>>> On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun
>>>>> <chunfeng.yun@mediatek.com> wrote:
>>>>>
>>>>>> the default mode of GPIO16 pin is gpio, when set EINT16 to
>>>>>> IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be
>>>>>> fixed when set its default mode as usb iddig.
>>>>>>
>>>>>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>>>>>
>>>>
>>>> Chunfeng, GPIO16 can be used as EINT16 mode, but the pinmux should be 0.
>>>> If you want to set its default mode to iddig, you should set it in dts.
>>>>
>>> I set it in DTS, but it didn't work, because when usb driver requested
>>> IRQ, pinmux was switched back to default mode set by
>>> MTK_EINT_FUNCTION().
>>>
>>
>> After confirmed, there are something wrong with data sheet and pinmux
>> table, and GPIO16 can only receive interrupt by mode 1. So
>>
>> Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
>>
>
> Linus,
>
> We find there are some other pins still have the same problem, so please
> hold on it. Sorry for so much noise.
>
Did you made any progress on this? I didn't see any patch on the mailing
list.
Regards,
Matthias
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-23 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123145916.GL14947@lunn.ch>
Hello Andrew,
On 11/23/2016 03:59 PM, Andrew Lunn wrote:
>>> CZ11NIC12 is indicated on my board.
>>
>> :-( Well, this board version has wrongly matched length of some
>> differential pairs, IRQ from 88E1514 is connected differently, there
>> are slight differences in power supplies and (if I am not mistaken)
>> something changed in RTC support circuitry. It looks like a huge
>> mistake on our side.
>
> Hi Tomas
>
> Would these problems also explain why the Ethernet links to the switch
> don't work? Maybe the differential pairs?
no this is not the problem. When booting the OpenWRT based system I can
communicate with the device via the switch. (Didn't test deeply, but my
Laptop got a dhcp lease from the Turris Omnia and I can ping it.) But
this convinces me, that the hardware is good enough.
If you have any ideas what I can try to make the switch work or help to
diagnose the problem, just let me know.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161123/3b35fee8/attachment.sig>
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: Florian Fainelli @ 2016-11-23 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123100106.15969-2-s.hauer@pengutronix.de>
On 11/23/2016 02:01 AM, Sascha Hauer wrote:
> With this patch the serial core provides LED triggers for RX and TX.
>
> As the serial core layer does not know when the hardware actually sends
> or receives characters, this needs help from the UART drivers.
Looking at 8250, we call serial8250_tx_chars from __start_tx which is
called form the uart_ops::start_tx, for RX I sort of agree, since this
happens in interrupt handler. I suppose some drivers could actually
queue work but not do it right away though?
> The LED triggers are registered in uart_add_led_triggers() called from
> the UART drivers which want to support LED triggers. All the driver
> has to do then is to call uart_led_trigger_[tx|rx] to indicate
> activity.
Could we somehow remedy the lack of knowledge from the core as whether
the HW sends/receives characters first before adding support for LED
triggers? It would be more generic and future proof to require UART
drivers to report to the core when they actually TX/RX, and then at the
core level, utilize that knowledge to perform the LED trigger.
Side note: are you positive using drv->dev_name is robust enough on
systems with many different UART drivers, yet all of them being ttyS*?
Thanks!
--
Florian
^ permalink raw reply
* [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()
From: Stephen Boyd @ 2016-11-23 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737isvwc6.wl%kuninori.morimoto.gx@renesas.com>
On 11/16, Kuninori Morimoto wrote:
>
> Hi Rob, Michael, Russell
>
>
> What is the conclusion of this patch ?
> We shouldn't add devm_of_clk_get() ? or can I continue ?
>
> The problem of current [devm_]clk_get() handles *dev only,
> but I need to get clocks from DT node, not dev
>
> sound_soc {
> ...
> cpu {
> ...
> => clocks = <&xxx>;
> };
> codec {
> ...
> => clocks = <&xxx>;
> };
> };
>
I've seen bindings that have the 'clocks' property at the top
level and the appropriate 'clock-names' property to relate the
clocks to a subnode.
sound_soc {
clocks = <&xxx>, <&xxx>;
clock-names = "cpu", "codec";
...
cpu {
...
};
codec {
...
};
};
Then the subnodes call clk_get() with the top level device and
the name of their node and things match up. I suppose this
binding is finalized though, so we can't really do that?
I see that the gpio framework has a similar design called
devm_get_gpiod_from_child(), so how about we add a
devm_get_clk_from_child() API? That would more closely match the
intent here, which is to restrict the clk_get() operation to
child nodes of the device passed as the first argument.
struct clk *devm_get_clk_from_child(struct device *dev,
const char *con_id,
struct device_node *child);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 19:15 UTC (permalink / raw)
To: linux-arm-kernel
All,
I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
board (Marvell Armada 370 SoC). Every day or so I get a consistent
crash that brings down the whole board. I've attached three oops I
captured on the serial port.
I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
at me as "this would fix it". And since it takes a day or so to trigger
the oops, bisecting would be a bit brutal. Does anyone have any insight
into this?
thx,
Jason.
------- oops from v4.2.8 ------------------------------------------
[ 3572.897994] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[ 3572.906134] pgd = c0004000
[ 3572.908891] [00000020] *pgd=00000000
[ 3572.912504] Internal error: Oops: 5 [#1] SMP ARM
[ 3572.917142] Modules linked in: tun ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge ipv6 ath9k ath9k_common ath9k_hw led_class ath
[ 3572.930749] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.2.8 #57
[ 3572.937915] Hardware name: Marvell Armada 370/XP (Device Tree)
[ 3572.943774] task: c06fdd30 ti: c06f8000 task.ti: c06f8000
[ 3572.949208] PC is at ath_cmn_process_fft+0xac/0x4a0 [ath9k_common]
[ 3572.955421] LR is at ath_cmn_process_fft+0xc8/0x4a0 [ath9k_common]
[ 3572.961631] pc : [<bf081f44>] lr : [<bf081f60>] psr: 80000153
[ 3572.961631] sp : c06f9ca0 ip : 00000000 fp : 00000000
[ 3572.973160] r10: dc9a8010 r9 : 00000000 r8 : c06fa4d0
[ 3572.978409] r7 : 0000006c r6 : dd3abfc0 r5 : c06fad88 r4 : 00000000
[ 3572.984965] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[ 3572.991522] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 3572.998951] Control: 10c5387d Table: 1c894019 DAC: 00000015
[ 3573.004723] Process swapper/0 (pid: 0, stack limit = 0xc06f8220)
[ 3573.010756] Stack: (0xc06f9ca0 to 0xc06fa000)
[ 3573.015137] 9ca0: c0734e31 dfbe3f40 c06f6f40 c06f6f40 c06fae34 c0734184 00989680 00000003
[ 3573.023356] 9cc0: dff6cde0 00000008 c06f9df4 00000069 dca0ab8c c0098b44 00000985 00000fc0
[ 3573.031573] 9ce0: c0733700 dffa0560 00000002 c001b6ac 000000c0 00000000 00000000 00000000
[ 3573.039790] 9d00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.048006] 9d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.056222] 9d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.064438] 9d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dc9a8010
[ 3573.072654] 9d80: 00000000 dc983d18 dc983d00 dc983d00 00000002 dd045c90 dca08d40 bf090e64
[ 3573.080872] 9da0: d364463c 00000000 edf3c980 0000033f 0000033f 000001fa dc9a8010 00000000
[ 3573.089090] 9dc0: d3644890 00000000 dc9a8038 dca083e0 dd3abfc0 00000000 dd3abfc0 dca097ac
[ 3573.097306] 9de0: dc9a8038 00000002 00000001 dca083e0 00000100 d364463c 2602006c 018eff80
[ 3573.105522] 9e00: 80808000 00808080 20000001 00000000 00000000 00000000 00000000 00000000
[ 3573.113739] 9e20: 00000000 00000000 c06f9e68 dca08d40 00000001 dc9a8010 dca09708 c06f9e68
[ 3573.121955] 9e40: c06f4294 c06f8000 00000006 bf08e698 bf08e5dc dca096d0 dca096d4 00000000
[ 3573.130172] 9e60: c0735bc0 c0027e4c 00000000 c06fa098 00000100 c06f8000 c06f9e88 40000006
[ 3573.138389] 9e80: c06fa080 c0028030 ed5b3300 0000033f c06fa080 c06f4308 0000000a c0735bc0
[ 3573.146606] 9ea0: c06fa100 0004fe8e c051e380 00200000 c06f8000 c06f5444 00000000 00000000
[ 3573.154823] 9ec0: 00000001 df405000 c06fa484 c0759f80 c06f8000 c00283d8 c06f5444 c005b838
[ 3573.163041] 9ee0: c0341814 00000001 c0759f80 c06f9f20 000003ff c0009410 c034180c c0341814
[ 3573.171257] 9f00: 80000153 ffffffff c06f9f54 ed5b20c4 0000033f ed5b20c4 c06f8000 c0013340
[ 3573.179474] 9f20: 00000000 fffffffa 1f4ed000 dfbe3f40 ecf52c5b 0000033f dfbe34d0 00000001
[ 3573.187691] 9f40: ed5b20c4 0000033f ed5b20c4 c06f8000 0000001a c06f9f68 c034180c c0341814
[ 3573.195908] 9f60: 80000153 ffffffff 00000000 00000000 ed5b20c4 0000033f dfbe34d0 c051e374
[ 3573.204125] 9f80: dfbe34d0 c072a608 c06f64c8 c06fa51c c06f4364 c06fa524 c06f8000 c00535ec
[ 3573.212343] 9fa0: c06f9fa0 c0734dd1 dfffce00 ffffffff dfffce00 c06b5c6c ffffffff ffffffff
[ 3573.220559] 9fc0: 00000000 c06b5670 00000000 c06ea990 00000000 c0735294 c06fa4c0 c06ea98c
[ 3573.228777] 9fe0: c06fee2c 00004059 561f5811 00000000 00000000 0000807c 00000000 00000000
[ 3573.237025] [<bf081f44>] (ath_cmn_process_fft [ath9k_common]) from [<bf090e64>] (ath_rx_tasklet+0xa14/0xafc [ath9k])
[ 3573.247613] [<bf090e64>] (ath_rx_tasklet [ath9k]) from [<bf08e698>] (ath9k_tasklet+0xbc/0x20c [ath9k])
[ 3573.256981] [<bf08e698>] (ath9k_tasklet [ath9k]) from [<c0027e4c>] (tasklet_action+0x7c/0x110)
[ 3573.265641] [<c0027e4c>] (tasklet_action) from [<c0028030>] (__do_softirq+0xf8/0x23c)
[ 3573.273513] [<c0028030>] (__do_softirq) from [<c00283d8>] (irq_exit+0x78/0xb0)
[ 3573.280778] [<c00283d8>] (irq_exit) from [<c005b838>] (__handle_domain_irq+0x60/0xb0)
[ 3573.288651] [<c005b838>] (__handle_domain_irq) from [<c0009410>] (armada_370_xp_handle_irq+0x50/0xbc)
[ 3573.297917] [<c0009410>] (armada_370_xp_handle_irq) from [<c0013340>] (__irq_svc+0x40/0x54)
[ 3573.306306] Exception stack(0xc06f9f20 to 0xc06f9f68)
[ 3573.311385] 9f20: 00000000 fffffffa 1f4ed000 dfbe3f40 ecf52c5b 0000033f dfbe34d0 00000001
[ 3573.319602] 9f40: ed5b20c4 0000033f ed5b20c4 c06f8000 0000001a c06f9f68 c034180c c0341814
[ 3573.327816] 9f60: 80000153 ffffffff
[ 3573.331331] [<c0013340>] (__irq_svc) from [<c0341814>] (cpuidle_enter_state+0xdc/0x248)
[ 3573.339385] [<c0341814>] (cpuidle_enter_state) from [<c00535ec>] (cpu_startup_entry+0x170/0x234)
[ 3573.348218] [<c00535ec>] (cpu_startup_entry) from [<c06b5c6c>] (start_kernel+0x3b0/0x3bc)
[ 3573.356436] Code: e59c9004 e3e0b000 e5938000 ea000002 (e7990102)
[ 3573.362634] ---[ end trace 47b32564cd3160db ]---
[ 3573.367281] Kernel panic - not syncing: Fatal exception in interrupt
[ 3573.373667] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
------- oops from v4.8.6 ---------------------------------------------
[231233.388543] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[231233.396804] pgd = c0004000
[231233.399614] [00000020] *pgd=00000000
[231233.403311] Internal error: Oops: 17 [#1] SMP ARM
[231233.408124] Modules linked in: ath9k ath9k_common ath9k_hw ath
[231233.414132] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
[231233.420165] Hardware name: Marvell Armada 370/XP (Device Tree)
[231233.426111] task: c0b091c0 task.stack: c0b00000
[231233.430760] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
[231233.437060] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
[231233.443357] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
[231233.443357] sp : c0b01cd0 ip : 00000000 fp : 00000000
[231233.455059] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
[231233.460394] r7 : 00000000 r6 : dbef9440 r5 : c0b03da0 r4 : 00000000
[231233.467037] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[231233.473682] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
[231233.481023] Control: 10c5387d Table: 1e614019 DAC: 00000051
[231233.486882] Process swapper/0 (pid: 0, stack limit = 0xc0b00220)
[231233.493001] Stack: (0xc0b01cd0 to 0xc0b02000)
[231233.497466] 1cc0: fffffffa 3b9ac9ff 003c8995 c0b44d30
[231233.505770] 1ce0: dda18010 00000000 c0b01e14 c017ad48 ffffffff dee1ac84 c0b44d30 c0b44b00
[231233.514073] 1d00: 0000099e 00000440 0001bef9 c01176f4 00000002 00000786 00000000 00000000
[231233.522377] 1d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.530680] 1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.538984] 1d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.547287] 1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.555591] 1da0: dda18010 dda18010 00000000 defaa3d8 defaa3c0 defaa3c0 dee18e40 de5b4a18
[231233.563895] 1dc0: dda18010 bf08a9d0 071a3710 00000056 00989680 00000000 071a393a 00000056
[231233.572199] 1de0: 000001fb dee18440 00000000 dbef9440 dee198b0 00000014 dda18038 dee1a97c
[231233.580504] 1e00: dbef9440 00000002 00000001 dee18440 0036f478 071a3710 2422006c 018fff07
[231233.588807] 1e20: 80252900 01168e85 40000000 00000000 00000000 00000000 00000000 00000000
[231233.597110] 1e40: 00000000 00000000 c0a4a2c0 dee18e40 dda18010 dee19808 00000001 c0b00000
[231233.605414] 1e60: c0a4a2c0 c0b02080 40000006 bf088810 dee197d0 dee197d4 00000000 c0b01e88
[231233.613717] 1e80: c0b00000 c0126b88 00000000 00000006 c0b00000 c0b02098 c0b02080 00000100
[231233.622021] 1ea0: c0b02080 c0126d74 df405000 c0b01f30 c0b01ea8 c0b3bf80 0000000a 0160605b
[231233.630324] 1ec0: c0b02100 00200100 df488a20 c0a4d500 00000000 00000000 00000001 df405000
[231233.638629] 1ee0: c0b01f30 00000000 c0b03524 c0127120 c0a4d500 c01635e4 c04b7318 20000153
[231233.646933] 1f00: c0b61040 00000001 c0b61040 c010145c c04b7318 20000153 ffffffff c0b01f64
[231233.655236] 1f20: 0028571c c0b00000 00000000 c010bd8c 00000000 0000d24e 1f194000 dfbe31c0
[231233.663540] 1f40: 37d25f82 0000d24e dfbe2590 00000001 0028571c 0000d24e 00000000 c0b03524
[231233.671843] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff 00000051 00000000
[231233.680148] 1f80: dfbe2590 c0b00000 c0b034d4 00000001 dfbe2590 c0b2e070 c0a4e588 c0b0352c
[231233.688452] 1fa0: c0b03524 c015a240 c0b01fa8 c0b3b0f4 00000000 ffffffff 00000000 c0a00c54
[231233.696756] 1fc0: ffffffff ffffffff 00000000 c0a0068c 00000000 c0a3ba28 c0b3b614 c0b034c0
[231233.705059] 1fe0: c0a3ba24 c0b0a3a8 00004059 561f5811 00000000 0000807c 00000000 00000000
[231233.713401] [<bf07bec4>] (ath_cmn_process_fft [ath9k_common]) from [<bf08a9d0>] (ath_rx_tasklet+0x47c/0xb20 [ath9k])
[231233.724079] [<bf08a9d0>] (ath_rx_tasklet [ath9k]) from [<bf088810>] (ath9k_tasklet+0x1dc/0x218 [ath9k])
[231233.733623] [<bf088810>] (ath9k_tasklet [ath9k]) from [<c0126b88>] (tasklet_action+0x74/0x110)
[231233.742367] [<c0126b88>] (tasklet_action) from [<c0126d74>] (__do_softirq+0xfc/0x218)
[231233.750324] [<c0126d74>] (__do_softirq) from [<c0127120>] (irq_exit+0x7c/0xb4)
[231233.757678] [<c0127120>] (irq_exit) from [<c01635e4>] (__handle_domain_irq+0x60/0xb4)
[231233.765637] [<c01635e4>] (__handle_domain_irq) from [<c010145c>] (armada_370_xp_handle_irq+0x48/0xa8)
[231233.774989] [<c010145c>] (armada_370_xp_handle_irq) from [<c010bd8c>] (__irq_svc+0x6c/0x90)
[231233.783463] Exception stack(0xc0b01f30 to 0xc0b01f78)
[231233.788625] 1f20: 00000000 0000d24e 1f194000 dfbe31c0
[231233.796930] 1f40: 37d25f82 0000d24e dfbe2590 00000001 0028571c 0000d24e 00000000 c0b03524
[231233.805232] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff
[231233.811974] [<c010bd8c>] (__irq_svc) from [<c04b7318>] (cpuidle_enter_state+0x18c/0x2b4)
[231233.820202] [<c04b7318>] (cpuidle_enter_state) from [<c015a240>] (cpu_startup_entry+0x17c/0x220)
[231233.829124] [<c015a240>] (cpu_startup_entry) from [<c0a00c54>] (start_kernel+0x368/0x374)
[231233.837430] Code: e5933000 e1d330b4 e58d3030 ea000002 (e7970102)
[231233.843714] ---[ end trace 0a5139f91be0a117 ]---
[231233.848460] Kernel panic - not syncing: Fatal exception in interrupt
[231233.854937] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
------- oops from v4.8.6 #2 ------------------------------------------
[42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[42059.311799] pgd = c0004000
[42059.314522] [00000020] *pgd=00000000
[42059.318162] Internal error: Oops: 17 [#1] SMP ARM
[42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
[42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
[42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
[42059.340613] task: c0b091c0 task.stack: c0b00000
[42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
[42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
[42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
[42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
[42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
[42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
[42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[42059.387487] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
[42059.394741] Control: 10c5387d Table: 1ef48019 DAC: 00000051
[42059.400513] Process swapper/0 (pid: 0, stack limit = 0xc0b00220)
[42059.406545] Stack: (0xc0b01cd0 to 0xc0b02000)
[42059.410924] 1cc0: fffffffa 3b9ac9ff 0047c6ce c0b44d30
[42059.419141] 1ce0: de6a0010 00000000 c0b01e14 c017ad48 ffffffff dee0ac84 c0b44d30 c0b44b00
[42059.427357] 1d00: 0000099e 00000340 0001cfbd c01176f4 00000002 00000786 00000080 00000000
[42059.435573] 1d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.443789] 1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.452005] 1d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.460220] 1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.468437] 1da0: de6a0010 de6a0010 00000000 deec5b58 deec5b40 deec5b40 dee08e40 de631ff0
[42059.476653] 1dc0: de6a0010 bf08a9d0 8918a8c8 00000002 00000000 00000000 8918aaa1 00000002
[42059.484869] 1de0: 00000200 dee08440 00000000 dcfbd340 dee098b0 00000014 de6a0038 dee0a97c
[42059.493085] 1e00: dcfbd340 00000002 00000001 dee08440 00fc2540 8918a8c8 0502006c 018e026c
[42059.501301] 1e20: 80202600 016d5ab7 40000100 00000000 00000000 00000000 00000000 00000000
[42059.509518] 1e40: 00000000 00000000 c0a4a2c0 dee08e40 de6a0010 dee09808 00000001 c0b00000
[42059.517734] 1e60: c0a4a2c0 c0b02080 40000006 bf088810 dee097d0 dee097d4 00000000 c0b01e88
[42059.525950] 1e80: c0b00000 c0126b88 00000000 00000006 c0b00000 c0b02098 c0b02080 00000100
[42059.534166] 1ea0: c0b02080 c0126d74 df405000 c0b01f30 c0b01ea8 c0b3bf80 0000000a 003fb83a
[42059.542382] 1ec0: c0b02100 00200100 df486a20 c0a4d500 00000000 00000000 00000001 df405000
[42059.550599] 1ee0: c0b01f30 00000000 c0b03524 c0127120 c0a4d500 c01635e4 c04b7318 20000153
[42059.558816] 1f00: c0b61040 00000001 c0b61040 c010145c c04b7318 20000153 ffffffff c0b01f64
[42059.567031] 1f20: 006895c7 c0b00000 00000000 c010bd8c 00000000 00002640 1f194000 dfbe31c0
[42059.575248] 1f40: b1708859 00002640 dfbe2590 00000001 006895c7 00002640 00000000 c0b03524
[42059.583464] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff 00000051 00000000
[42059.591681] 1f80: dfbe2590 c0b00000 c0b034d4 00000001 dfbe2590 c0b2e070 c0a4e588 c0b0352c
[42059.599897] 1fa0: c0b03524 c015a240 c0b01fa8 c0b3b0f4 00000000 ffffffff 00000000 c0a00c54
[42059.608114] 1fc0: ffffffff ffffffff 00000000 c0a0068c 00000000 c0a3ba28 c0b3b614 c0b034c0
[42059.616330] 1fe0: c0a3ba24 c0b0a3a8 00004059 561f5811 00000000 0000807c 00000000 00000000
[42059.624586] [<bf07bec4>] (ath_cmn_process_fft [ath9k_common]) from [<bf08a9d0>] (ath_rx_tasklet+0x47c/0xb20 [ath9k])
[42059.635176] [<bf08a9d0>] (ath_rx_tasklet [ath9k]) from [<bf088810>] (ath9k_tasklet+0x1dc/0x218 [ath9k])
[42059.644631] [<bf088810>] (ath9k_tasklet [ath9k]) from [<c0126b88>] (tasklet_action+0x74/0x110)
[42059.653288] [<c0126b88>] (tasklet_action) from [<c0126d74>] (__do_softirq+0xfc/0x218)
[42059.661157] [<c0126d74>] (__do_softirq) from [<c0127120>] (irq_exit+0x7c/0xb4)
[42059.668423] [<c0127120>] (irq_exit) from [<c01635e4>] (__handle_domain_irq+0x60/0xb4)
[42059.676295] [<c01635e4>] (__handle_domain_irq) from [<c010145c>] (armada_370_xp_handle_irq+0x48/0xa8)
[42059.685559] [<c010145c>] (armada_370_xp_handle_irq) from [<c010bd8c>] (__irq_svc+0x6c/0x90)
[42059.693946] Exception stack(0xc0b01f30 to 0xc0b01f78)
[42059.699021] 1f20: 00000000 00002640 1f194000 dfbe31c0
[42059.707237] 1f40: b1708859 00002640 dfbe2590 00000001 006895c7 00002640 00000000 c0b03524
[42059.715453] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff
[42059.722107] [<c010bd8c>] (__irq_svc) from [<c04b7318>] (cpuidle_enter_state+0x18c/0x2b4)
[42059.730247] [<c04b7318>] (cpuidle_enter_state) from [<c015a240>] (cpu_startup_entry+0x17c/0x220)
[42059.739081] [<c015a240>] (cpu_startup_entry) from [<c0a00c54>] (start_kernel+0x368/0x374)
[42059.747299] Code: e5933000 e1d330b4 e58d3030 ea000002 (e7970102)
[42059.753488] ---[ end trace d9b5665c4c165fb1 ]---
[42059.758151] Kernel panic - not syncing: Fatal exception in interrupt
[42059.764541] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Russell King - ARM Linux @ 2016-11-23 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123154829.GA2489@afzalpc>
On Wed, Nov 23, 2016 at 09:18:29PM +0530, Afzal Mohammed wrote:
> multi_v7_defconfig & MMU disabled, stderr was more verbose and was
> unhappy with Kconfig dependencies,
Well, !MMU and multiplatform _are_ exclusive in reality. One of the
things we work around in multiplatform is the different physical
address space layouts of the platforms, particularly with where RAM
is located. That's not possible in !MMU configurations. A kernel
built to support every platform in multiplatform will not boot on
most of them.
So efforts to make !MMU work with multiplatform are IMHO rather
misguided.
!MMU makes sense with classifications of systems (like the Cortex-M*
based systems) but not everything.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Kalle Valo @ 2016-11-23 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123191539.GF2799@io.lakedaemon.net>
Jason Cooper <jason@lakedaemon.net> writes:
> All,
>
> I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
> board (Marvell Armada 370 SoC). Every day or so I get a consistent
> crash that brings down the whole board. I've attached three oops I
> captured on the serial port.
>
> I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
> at me as "this would fix it". And since it takes a day or so to trigger
> the oops, bisecting would be a bit brutal. Does anyone have any insight
> into this?
Is this a regression, meaning that it didn't crash on older kernels but
crashes on newer ones? Or has it always crashed?
--
Kalle Valo
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a8cqgfpp.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
On Wed, Nov 23, 2016 at 09:26:42PM +0200, Kalle Valo wrote:
> Jason Cooper <jason@lakedaemon.net> writes:
> > I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
> > board (Marvell Armada 370 SoC). Every day or so I get a consistent
> > crash that brings down the whole board. I've attached three oops I
> > captured on the serial port.
> >
> > I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
> > at me as "this would fix it". And since it takes a day or so to trigger
> > the oops, bisecting would be a bit brutal. Does anyone have any insight
> > into this?
>
> Is this a regression, meaning that it didn't crash on older kernels but
> crashes on newer ones? Or has it always crashed?
iirc, it's always done this. It's one of my spare wifi backhauls that
spends most of it's time in a cardboard box waiting for a task,
collecting dust. Kinda like the toys in Toy Story.
I pulled it out a month or so ago and the behavior started. It had
4.2.8 on it at the time. I upgraded to latest stable a few weeks ago
(v4.8.6) and I'm getting the same issue.
When I originally set it up, it didn't run long enough for me to recall
if the issue occurred. Best I recall, that was with v4.2.8.
thx,
Jason.
^ permalink raw reply
* [PATCH 2/4] serial: 8250: Add LED trigger support
From: kbuild test robot @ 2016-11-23 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123100106.15969-3-s.hauer@pengutronix.de>
Hi Sascha,
[auto build test ERROR on tty/tty-testing]
[also build test ERROR on v4.9-rc6 next-20161123]
[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/Sascha-Hauer/serial-core-Add-LED-trigger-support/20161124-010846
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
config: m32r-m32104ut_defconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r
All errors (new ones prefixed by >>):
>> ERROR: "uart_led_trigger_rx" [drivers/tty/serial/8250/8250_base.ko] undefined!
>> ERROR: "uart_led_trigger_tx" [drivers/tty/serial/8250/8250_base.ko] undefined!
>> ERROR: "uart_remove_led_triggers" [drivers/tty/serial/8250/8250.ko] undefined!
>> ERROR: "uart_add_led_triggers" [drivers/tty/serial/8250/8250.ko] undefined!
--
>> ERROR: "uart_led_trigger_rx" [drivers/tty/serial/8250/8250_base.ko] undefined!
>> ERROR: "uart_led_trigger_tx" [drivers/tty/serial/8250/8250_base.ko] undefined!
>> ERROR: "uart_remove_led_triggers" [drivers/tty/serial/8250/8250.ko] undefined!
>> ERROR: "uart_add_led_triggers" [drivers/tty/serial/8250/8250.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 10628 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/2ef736c6/attachment.gz>
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Russell King - ARM Linux @ 2016-11-23 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123191539.GF2799@io.lakedaemon.net>
On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> ------- oops from v4.8.6 #2 ------------------------------------------
> [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> [42059.311799] pgd = c0004000
> [42059.314522] [00000020] *pgd=00000000
> [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> [42059.340613] task: c0b091c0 task.stack: c0b00000
> [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
Well, the good news is that it's reproducable.
It looks like it could be this:
static int
ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
{
for_each_online_cpu(i)
ret += relay_buf_full(rc->buf[i]);
where i = 8 (r2) and rc->buf is r7. That's just a guess though, as
there's precious little to go on with the Code: line - modern GCCs
don't give us much with the Code: line anymore to figure out what's
going on without the exact object files.
e5933000 ldr r3, [r3]
e1d330b4 ldrh r3, [r3, #4]
e58d3030 str r3, [sp, #48] ; 0x30
ea000002 b 1c <foo+0x1c>
e7970102 ldr r0, [r7, r2, lsl #2]
What makes me wonder though is that if i=8, that means you must have a
system with 9 online CPUs, which is probably unlikely - or maybe that's
the problem, for_each_online_cpu() is going wrong...
If it's not that line of code, I don't see what else it would be based
on the output of my compiler - there's only one case in my disassembly
that corresponds with the single code line that we have to go on, and
it's this:
a44: e5983020 ldr r3, [r8, #32]
a48: e793010a ldr r0, [r3, sl, lsl #2] <===
a4c: ebfffffe bl 0 <relay_buf_full>
a50: e0844000 add r4, r4, r0
a54: e59f9434 ldr r9, [pc, #1076]
a58: e28a2001 add r2, sl, #1
a5c: e3a01004 mov r1, #4
a60: e1a00009 mov r0, r9
a64: ebfffffe bl 0 <_find_next_bit_le>
a68: e5953000 ldr r3, [r5]
a6c: e1500003 cmp r0, r3
a70: e1a0a000 mov sl, r0
a74: bafffff2 blt a44 <ath_cmn_process_fft+0xa8>
I'm debating now about whether we need to dump more of the code in the
oops - both before and after the faulting instruction...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Robin Murphy @ 2016-11-23 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002b01d24340$5d56e730$1804b590$@codeaurora.org>
On 20/11/16 15:11, Sricharan wrote:
> Hi Robin,
>
>> Hi Robin,
>>
>>> Hi Robin,
>>>
>>>> On 04/11/16 15:16, Sricharan wrote:
>>>>> Hi Robin,
>>>>>
>>>>>>>> Yikes, on second look, that definitely shouldn't be happening.
>>>>>>>> Everything below is probably the resulting fallout.
>>>>>>>
>>>>>>> [ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>>>>>>>
>>>>>>> I think the above print which says "failed to setup iommu_ops"
>>>>>>> because the call ops->add_device failed in of_pci_iommu_configure
>>>>>>> is the reason for the failure, in my case i simply do not get this even with
>>>>>>> your scripts. ops->add_device succeeds in the rebind as well. So still
>>>>>>> checking what could be happening in your case.
>>>>>>
>>>>>> I was looking at your code base from [1].The ops->add_device
>>>>>> callback from of_pci_iommu_configure on the rebind is the
>>>>>> one which is causing the failure. But not able to spot out
>>>>> >from code which point is causing the failure. It would be very helpful
>>>>>> if i can know which is the return value from the add_device callback
>>>>>> or point inside add_device callback which fails in your setup.
>>>>>>
>>>>>>
>>>>>> [1] git://linux-arm.org/linux-rm iommu/misc
>>>>>
>>>>> With little more try, i saw an issue where i had an failure
>>>>> similar to what you reported. The issue happens when multiple
>>>>> devices fall in to same group due to matching sids. I ended up
>>>>> doing a fix like below and it would be nice to verify if it is the same
>>>>> that we are seeing in your setup and if the fix makes a difference ?
>>>>>
>>>>> From: Sricharan R <sricharan@codeaurora.org>
>>>>> Date: Fri, 4 Nov 2016 20:28:49 +0530
>>>>> Subject: [PATCH] iommu/arm-smmu: Fix group's reference counting
>>>>>
>>>>> iommu_group_get_for_dev which gets called in the add_device
>>>>> callback, increases the reference count of the iommu_group,
>>>>> so we do an iommu_group_put after that. iommu_group_get_for_dev
>>>>> inturn calls device_group callback and in the case of arm-smmu
>>>>> we call generic_device_group/pci_device_group which takes
>>>>> care of increasing the group's reference. But when we return
>>>>> an already existing group(when multiple devices have same group)
>>>>> the reference is not incremented, resulting in issues when the
>>>>> remove_device callback for the devices is invoked.
>>>>> Fixing the same here.
>>>>
>>>> Bah, yes, this does look like my fault - after flip-flopping between
>>>> about 3 different ways to keep refcounts for the S2CR entries, none of
>>>> which would quite work, I ripped it all out but apparently still got
>>>> things wrong, oh well. Thanks for figuring it out.
>>>>
>>>> On the probe-deferral angle, whilst it's useful to have uncovered this
>>>> bug, I don't think we should actually be calling remove_device() from
>>>> DMA teardown. I think it's preferable from a user perspective if group
>>>> numbering remains stable, rather than changing depending on the order in
>>>> which they unbind/rebind VFIO drivers. I'm really keen to try and get
>>>> this in shape for 4.10, so I've taken the liberty of hacking up my own
>>>> branch (iommu/defer) based on v3 - would you mind taking a look at the
>>>> two "iommu/of:" commits to see what you think? (Ignore the PCI changes
>>>> to your later patches - that was an experiment which didn't really work out)
>>>
>>> Ok, will take a look at this now and respond more on this.
>>>
>> Sorry for the delayed response on this. I was OOO for the last few days.
>> So i tested this branch and it worked fine. I tested it with a pci device
>> for both normal and deferred probe cases. The of/iommu patches
>> are the cleanup/preparation patches and it looks fine. One thing is without
>> calling the remove_device callback, the resources like (smes for exmaple)
>> and the group association of the device all remain allocated. That does not
>> feel correct, given that the associated device does not exist. So to
>> understand that, what happens with VFIO in this case which makes the
>> group renumbering/rebinding a problem ?
>>
>
> Would it be ok if i post a V4 based on your branch above ?
Sure, as long as none of the hacks slip through :) - I've just pushed
out a mild rework based on Lorenzo's v9, which I hope shouldn't break
anything for you.
Having thought a bit more about the add/remove thing, I'm inclined to
agree that the group numbering itself may not be that big an issue in
practice - sure, it could break my little script, but it looks like QEMU
and such work with the device ID rather than the group number directly,
so might not even notice. However, the fact remains that the callbacks
are intended to handle a device being added to/removed from its bus, and
will continue to do so on other platforms, so I don't like the idea of
introducing needlessly different behaviour. If you unbind a driver, the
stream IDs and everything don't stop existing at the hardware level; the
struct device to which the in-kernel data belongs still exists and
doesn't stop being associated with its bus. There's no good reason for
freeing SMEs that we'll only reallocate again (inadequately-specced
hardware with not enough SMRs/contexts is not a *good* reason), and
there are also some strong arguments against letting any stream IDs the
kernel knows about go back to bypass after a driver has been bound - by
keeping groups around as expected that's something we can implement
quite easily without having to completely lock down bypass for stream
IDs the kernel *doesn't* know about.
Robin.
>
> Regards,
> Sricharan
>
^ permalink raw reply
* [PATCH] clk: bcm2835: Fix ->fixed_divider of pllh_aux
From: Stephen Boyd @ 2016-11-23 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122204528.18435-1-eric@anholt.net>
On 11/22, Eric Anholt wrote:
> From: Boris Brezillon <boris.brezillon@free-electrons.com>
>
> There is no fixed divider on pllh_aux.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> Reviewed-by: Eric Anholt <eric@anholt.net>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: kbuild test robot @ 2016-11-23 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123100106.15969-2-s.hauer@pengutronix.de>
Hi Sascha,
[auto build test WARNING on tty/tty-testing]
[also build test WARNING on v4.9-rc6 next-20161123]
[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/Sascha-Hauer/serial-core-Add-LED-trigger-support/20161124-010846
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule.
include/linux/init.h:1: warning: no structured comments found
include/linux/workqueue.h:392: warning: No description found for parameter '...'
include/linux/workqueue.h:392: warning: Excess function parameter 'args' description in 'alloc_workqueue'
include/linux/workqueue.h:413: warning: No description found for parameter '...'
include/linux/workqueue.h:413: warning: Excess function parameter 'args' description in 'alloc_ordered_workqueue'
include/linux/kthread.h:26: warning: No description found for parameter '...'
kernel/sys.c:1: warning: no structured comments found
drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
include/linux/fence-array.h:61: warning: No description found for parameter 'fence'
>> drivers/tty/serial/serial_core.c:2773: warning: Excess function parameter 'drv' description in 'uart_remove_led_triggers'
include/sound/core.h:324: warning: No description found for parameter '...'
include/sound/core.h:335: warning: No description found for parameter '...'
include/sound/core.h:388: warning: No description found for parameter '...'
include/media/media-entity.h:1054: warning: No description found for parameter '...'
include/net/mac80211.h:2148: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:2153: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:3202: ERROR: Unexpected indentation.
include/net/mac80211.h:3205: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:3207: ERROR: Unexpected indentation.
include/net/mac80211.h:3208: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:1435: WARNING: Inline emphasis start-string without end-string.
include/net/mac80211.h:1172: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:1173: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:814: ERROR: Unexpected indentation.
include/net/mac80211.h:815: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:820: ERROR: Unexpected indentation.
include/net/mac80211.h:821: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:2489: ERROR: Unexpected indentation.
include/net/mac80211.h:1768: ERROR: Unexpected indentation.
include/net/mac80211.h:1772: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:1746: WARNING: Inline emphasis start-string without end-string.
kernel/sched/fair.c:7259: WARNING: Inline emphasis start-string without end-string.
kernel/time/timer.c:1240: ERROR: Unexpected indentation.
kernel/time/timer.c:1242: ERROR: Unexpected indentation.
kernel/time/timer.c:1243: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:121: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:124: ERROR: Unexpected indentation.
include/linux/wait.h:126: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/time/hrtimer.c:1021: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/signal.c:317: WARNING: Inline literal start-string without end-string.
drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent.
drivers/message/fusion/mptbase.c:5054: WARNING: Definition list ends without a blank line; unexpected unindent.
drivers/tty/serial/serial_core.c:1897: WARNING: Definition list ends without a blank line; unexpected unindent.
include/linux/spi/spi.h:369: ERROR: Unexpected indentation.
WARNING: dvipng command 'dvipng' cannot be run (needed for math display), check the imgmath_dvipng setting
vim +2773 drivers/tty/serial/serial_core.c
2757 err_alloc:
2758 kfree(uport->led_trigger_tx_name);
2759 kfree(uport->led_trigger_rx_name);
2760
2761 return ret;
2762 }
2763
2764 /**
2765 * uart_remove_led_triggers - remove LED triggers
2766 * @drv: pointer to the uart low level driver structure for this port
2767 * @uport: uart port structure to use for this port.
2768 *
2769 * Remove LED triggers previously registered with uart_add_led_triggers
2770 */
2771 void uart_remove_led_triggers(struct uart_port *uport)
2772 {
> 2773 if (uport->led_trigger_rx)
2774 led_trigger_unregister_simple(uport->led_trigger_rx);
2775 kfree(uport->led_trigger_rx_name);
2776
2777 if (uport->led_trigger_tx)
2778 led_trigger_unregister_simple(uport->led_trigger_tx);
2779 kfree(uport->led_trigger_tx_name);
2780 }
2781
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6425 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/298326e0/attachment.gz>
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Don Dutile @ 2016-11-23 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83d7bf8e-1aa9-b61b-4e83-ba9da1926d19@jonmasters.org>
On 11/21/2016 12:13 AM, Jon Masters wrote:
> On 11/07/2016 07:45 PM, Will Deacon wrote:
>
>> I figured this was a reasonable post to piggy-back on for the LPC minutes
>> relating to guest MSIs on arm64.
>
> Thanks for this Will. I'm still digging out post-LPC and SC16, but the
> summary was much appreciated, and I'm glad the conversation is helping.
>
>> 1. The physical memory map is not standardised (Jon pointed out that
>> this is something that was realised late on)
>
> Just to note, we discussed this one about 3-4 years ago. I recall making
> a vigorous slideshow at a committee meeting in defense of having a
> single memory map for ARMv8 servers and requiring everyone to follow it.
> I was weak. I listened to the comments that this was "unreasonable".
> Instead, I consider it was unreasonable of me to not get with the other
> OS vendors and force things to be done one way. The lack of a "map at
> zero" RAM location on ARMv8 has been annoying enough for 32-bit DMA only
> devices on 64-bit (behind an SMMU but in passthrough mode it doesn't
> help) and other issues beyond fixing the MSI doorbell regions. If I ever
> have a time machine, I tried harder.
>
>> Jon pointed out that most people are pretty conservative about hardware
>> choices when migrating between them -- that is, they may only migrate
>> between different revisions of the same SoC, or they know ahead of time
>> all of the memory maps they want to support and this could be communicated
>> by way of configuration to libvirt.
>
> I think it's certainly reasonable to assume this in an initial
> implementation and fix it later. Currently, we're very conservative
> about host CPU passthrough anyway and can't migrate from one microarch
> to another revision of the same microarch even. And on x86, nobody
> really supports e.g. Intel to AMD and back again. I've always been of
Thats primarily due to diff virt implentations ... vme vs svm.
1) thats not the case here; can argue cross arch variations .. gicv2 vs gicv3 vs gicv4 ...
but cross vendor should work if arch and common feature map (like x86 libvirt can resolve)
is provided
2) second chance to do it better; look n learn!
and common thread i am trying to drive home here ... learn from past mistakes *and* good choices.
> the mind that we should ensure the architecture can handle this, but
> then cautiously approach this with a default to not doing it.
>
>> Alex asked if there was a security
>> issue with DMA bypassing the SMMU, but there aren't currently any systems
>> where that is known to happen. Such a system would surely not be safe for
>> passthrough.
>
> There are other potential security issues that came up but don't need to
> be noted here (yet). I have wanted to clarify the SBSA for a long time
> when it comes to how IOMMUs should be implemented. It's past time that
> we went back and had a few conversations about that. I've poked.
>
>> Ben mused that a way to handle conflicts dynamically might be to hotplug
>> on the entire host bridge in the guest, passing firmware tables describing
>> the new reserved regions as a property of the host bridge. Whilst this
>> may well solve the issue, it was largely considered future work due to
>> its invasive nature and dependency on firmware tables (and guest support)
>> that do not currently exist.
>
> Indeed. It's an elegant solution (thanks Ben) that I gather POWER
> already does (good for them). We've obviously got a few things to clean
> up after we get the basics in place. Again, I think we can consider it
> reasonable that the MSI doorbell regions are predetermined on system A
> well ahead of any potential migration (that may or may not then work)
> for the moment. Vendors will want to loosen this later, and they can
> drive the work to do that, for example by hotplugging a host bridge.
>
> Jon.
>
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC r8a7745 SYSC Driver Updates for v4.10
From: Simon Horman @ 2016-11-23 20:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these Renesas ARM based SoC r8a7745 SYSC Driver updates for
v4.10.
This pull request is based on v4.9-rc1.
This pull request is broken out of an earlier pull request,
"Second Round of Renesas ARM Based SoC Drivers Updates for v4.10".
The motivation for breaking up the pull request is to provide
branches with minimal dependencies.
This pull request is targeted at the next/drivers branch of the arm-soc tree.
It introduces some minor merge conflicts in:
Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
drivers/soc/renesas/Makefile
drivers/soc/renesas/rcar-sysc.c
drivers/soc/renesas/rcar-sysc.h
The resolution is to take both sides. A sample merge resolution is
provided in the renesas-next-20161123v2-v4.9-rc1 tag of the renesas tree.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-r8a7745-sysc-for-v4.10
for you to fetch changes up to 141723e0cbdc1139410f77d8a572f17ce2de6bf5:
soc: renesas: rcar-sysc: add R8A7745 support (2016-11-23 14:28:41 +0100)
----------------------------------------------------------------
Renesas ARM Based SoC r8a7745 SYSC Driver Updates for v4.10
* Add support for the r8a7745 SoC to rcar-sysc
----------------------------------------------------------------
Sergei Shtylyov (2):
ARM: shmobile: r8a7745: add power domain index macros
soc: renesas: rcar-sysc: add R8A7745 support
.../bindings/power/renesas,rcar-sysc.txt | 1 +
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r8a7745-sysc.c | 32 ++++++++++++++++++++++
drivers/soc/renesas/rcar-sysc.c | 3 ++
drivers/soc/renesas/rcar-sysc.h | 1 +
include/dt-bindings/power/r8a7745-sysc.h | 25 +++++++++++++++++
6 files changed, 63 insertions(+)
create mode 100644 drivers/soc/renesas/r8a7745-sysc.c
create mode 100644 include/dt-bindings/power/r8a7745-sysc.h
^ permalink raw reply
* [PATCH 1/2] ARM: shmobile: r8a7745: add power domain index macros
From: Simon Horman @ 2016-11-23 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479929914.git.horms+renesas@verge.net.au>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Add macros usable by the device tree sources to reference R8A7745 SYSC power
domains by index.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
include/dt-bindings/power/r8a7745-sysc.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 include/dt-bindings/power/r8a7745-sysc.h
diff --git a/include/dt-bindings/power/r8a7745-sysc.h b/include/dt-bindings/power/r8a7745-sysc.h
new file mode 100644
index 000000000000..1844c1171c04
--- /dev/null
+++ b/include/dt-bindings/power/r8a7745-sysc.h
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __DT_BINDINGS_POWER_R8A7745_SYSC_H__
+#define __DT_BINDINGS_POWER_R8A7745_SYSC_H__
+
+/*
+ * These power domain indices match the numbers of the interrupt bits
+ * representing the power areas in the various Interrupt Registers
+ * (e.g. SYSCISR, Interrupt Status Register)
+ */
+
+#define R8A7745_PD_CA7_CPU0 5
+#define R8A7745_PD_CA7_CPU1 6
+#define R8A7745_PD_SGX 20
+#define R8A7745_PD_CA7_SCU 21
+
+/* Always-on power area */
+#define R8A7745_PD_ALWAYS_ON 32
+
+#endif /* __DT_BINDINGS_POWER_R8A7745_SYSC_H__ */
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 2/2] soc: renesas: rcar-sysc: add R8A7745 support
From: Simon Horman @ 2016-11-23 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479929914.git.horms+renesas@verge.net.au>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Add support for RZ/G1E (R8A7745) SoC power areas to the R-Car SYSC driver.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
.../bindings/power/renesas,rcar-sysc.txt | 1 +
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r8a7745-sysc.c | 32 ++++++++++++++++++++++
drivers/soc/renesas/rcar-sysc.c | 3 ++
drivers/soc/renesas/rcar-sysc.h | 1 +
5 files changed, 38 insertions(+)
create mode 100644 drivers/soc/renesas/r8a7745-sysc.c
diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
index 0725fb37a973..1375758307d2 100644
--- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
+++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
@@ -7,6 +7,7 @@ various coprocessors.
Required properties:
- compatible: Must contain exactly one of the following:
+ - "renesas,r8a7745-sysc" (RZ/G1E)
- "renesas,r8a7779-sysc" (R-Car H1)
- "renesas,r8a7790-sysc" (R-Car H2)
- "renesas,r8a7791-sysc" (R-Car M2-W)
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 623039c3514c..a25a628e90b5 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_ARCH_R8A7745) += rcar-sysc.o r8a7745-sysc.o
obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
obj-$(CONFIG_ARCH_R8A7791) += rcar-sysc.o r8a7791-sysc.o
diff --git a/drivers/soc/renesas/r8a7745-sysc.c b/drivers/soc/renesas/r8a7745-sysc.c
new file mode 100644
index 000000000000..d17887c08aa1
--- /dev/null
+++ b/drivers/soc/renesas/r8a7745-sysc.c
@@ -0,0 +1,32 @@
+/*
+ * Renesas RZ/G1E System Controller
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation; of the License.
+ */
+
+#include <linux/bug.h>
+#include <linux/kernel.h>
+
+#include <dt-bindings/power/r8a7745-sysc.h>
+
+#include "rcar-sysc.h"
+
+static const struct rcar_sysc_area r8a7745_areas[] __initconst = {
+ { "always-on", 0, 0, R8A7745_PD_ALWAYS_ON, -1, PD_ALWAYS_ON },
+ { "ca7-scu", 0x100, 0, R8A7745_PD_CA7_SCU, R8A7745_PD_ALWAYS_ON,
+ PD_SCU },
+ { "ca7-cpu0", 0x1c0, 0, R8A7745_PD_CA7_CPU0, R8A7745_PD_CA7_SCU,
+ PD_CPU_NOCR },
+ { "ca7-cpu1", 0x1c0, 1, R8A7745_PD_CA7_CPU1, R8A7745_PD_CA7_SCU,
+ PD_CPU_NOCR },
+ { "sgx", 0xc0, 0, R8A7745_PD_SGX, R8A7745_PD_ALWAYS_ON },
+};
+
+const struct rcar_sysc_info r8a7745_sysc_info __initconst = {
+ .areas = r8a7745_areas,
+ .num_areas = ARRAY_SIZE(r8a7745_areas),
+};
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 65c8e1eb90c0..a4e1bb046bc7 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -275,6 +275,9 @@ static void __init rcar_sysc_pd_setup(struct rcar_sysc_pd *pd)
}
static const struct of_device_id rcar_sysc_matches[] = {
+#ifdef CONFIG_ARCH_R8A7745
+ { .compatible = "renesas,r8a7745-sysc", .data = &r8a7745_sysc_info },
+#endif
#ifdef CONFIG_ARCH_R8A7779
{ .compatible = "renesas,r8a7779-sysc", .data = &r8a7779_sysc_info },
#endif
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 77dbe861473f..3048dd31288a 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -50,6 +50,7 @@ struct rcar_sysc_info {
unsigned int num_areas;
};
+extern const struct rcar_sysc_info r8a7745_sysc_info;
extern const struct rcar_sysc_info r8a7779_sysc_info;
extern const struct rcar_sysc_info r8a7790_sysc_info;
extern const struct rcar_sysc_info r8a7791_sysc_info;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [GIT PULL] Renesas ARM Based SoC Match Updates for v4.10
From: Simon Horman @ 2016-11-23 20:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these Renesas ARM based SoC match updates for v4.10.
This pull request is based on the pull request "soc_device_match()
interface for matching against soc_bus attributes" sent by Geert
Uytterhoeven which corresponds to the soc-device-match-tag1 tag in his
renesas-driver's tree. It provides infrastructure used by changes in this
pull request.
This pull request is broken out of an earlier pull request,
"Second Round of Renesas ARM Based SoC Drivers Updates for v4.10".
The motivation for breaking up the pull request is to provide
branches with minimal dependencies.
This pull request is targeted at the next/drivers branch of the arm-soc tree.
It introduces some minor merge conflicts in drivers/soc/renesas/Makefile.
The resolution is to take both sides. A sample merge resolution is
provided in the renesas-next-20161123v2-v4.9-rc1 tag of the renesas tree.
The following changes since commit da65a1589dacc7ec44ea0557a14d70a39d991f32:
base: soc: Provide a dummy implementation of soc_device_match() (2016-11-10 10:10:37 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-match-for-v4.10
for you to fetch changes up to 8d6799a9ba23acd675f3243580ee6f1756fb4381:
soc: renesas: Identify SoC and register with the SoC bus (2016-11-23 20:22:21 +0100)
----------------------------------------------------------------
Renesas ARM Based SoC Match Updates for v4.10
* Identify SoC and register with the SoC bus
----------------------------------------------------------------
Geert Uytterhoeven (2):
ARM: shmobile: Document DT bindings for Product Register
soc: renesas: Identify SoC and register with the SoC bus
Documentation/devicetree/bindings/arm/shmobile.txt | 18 ++
arch/arm/mach-shmobile/Kconfig | 1 +
arch/arm64/Kconfig.platforms | 1 +
drivers/soc/renesas/Makefile | 2 +
drivers/soc/renesas/renesas-soc.c | 257 +++++++++++++++++++++
5 files changed, 279 insertions(+)
create mode 100644 drivers/soc/renesas/renesas-soc.c
^ permalink raw reply
* [PATCH 1/2] ARM: shmobile: Document DT bindings for Product Register
From: Simon Horman @ 2016-11-23 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479928995.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add device tree binding documentation for the Product Register (PRR),
which provides product and revision information on most Renesas ARM
SoCs.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 2f0b7169f132..23c77315fdac 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -75,3 +75,21 @@ Boards:
compatible = "renesas,silk", "renesas,r8a7794"
- Wheat
compatible = "renesas,wheat", "renesas,r8a7792"
+
+
+Most Renesas ARM SoCs have a Product Register that allows to retrieve SoC
+product and revision information. If present, a device node for this register
+should be added.
+
+Required properties:
+ - compatible: Must be "renesas,prr".
+ - reg: Base address and length of the register block.
+
+
+Examples
+--------
+
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 2/2] soc: renesas: Identify SoC and register with the SoC bus
From: Simon Horman @ 2016-11-23 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479928995.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Identify the SoC type and revision, and register this information with
the SoC bus, so it is available under /sys/devices/soc0/, and can be
checked where needed using soc_device_match().
Identification is done using the Product Register or Common Chip Code
Register, as declared in DT (PRR only for now), or using a hardcoded
fallback if missing.
Example:
Detected Renesas R-Car Gen2 r8a7791 ES1.0
...
# cat /sys/devices/soc0/{machine,family,soc_id,revision}
Koelsch
R-Car Gen2
r8a7791
ES1.0
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/mach-shmobile/Kconfig | 1 +
arch/arm64/Kconfig.platforms | 1 +
drivers/soc/renesas/Makefile | 2 +
drivers/soc/renesas/renesas-soc.c | 257 ++++++++++++++++++++++++++++++++++++++
4 files changed, 261 insertions(+)
create mode 100644 drivers/soc/renesas/renesas-soc.c
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 09817bae4558..ebab13e8afa1 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -40,6 +40,7 @@ menuconfig ARCH_RENESAS
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select NO_IOPORT_MAP
select PINCTRL
+ select SOC_BUS
select GPIOLIB
select ZONE_DMA if ARM_LPAE
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index cfbdf02ef566..72f4eac5cbbc 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -143,6 +143,7 @@ config ARCH_RENESAS
select PM
select PM_GENERIC_DOMAINS
select RENESAS_IRQC
+ select SOC_BUS
help
This enables support for the ARMv8 based Renesas SoCs.
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 623039c3514c..f2737a9f96ae 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -1,3 +1,5 @@
+obj-$(CONFIG_SOC_BUS) += renesas-soc.o
+
obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
obj-$(CONFIG_ARCH_R8A7791) += rcar-sysc.o r8a7791-sysc.o
diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
new file mode 100644
index 000000000000..330960312296
--- /dev/null
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -0,0 +1,257 @@
+/*
+ * Renesas SoC Identification
+ *
+ * Copyright (C) 2014-2016 Glider bvba
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/sys_soc.h>
+
+
+struct renesas_family {
+ const char name[16];
+ u32 reg; /* CCCR or PRR, if not in DT */
+};
+
+static const struct renesas_family fam_rcar_gen1 __initconst __maybe_unused = {
+ .name = "R-Car Gen1",
+ .reg = 0xff000044, /* PRR (Product Register) */
+};
+
+static const struct renesas_family fam_rcar_gen2 __initconst __maybe_unused = {
+ .name = "R-Car Gen2",
+ .reg = 0xff000044, /* PRR (Product Register) */
+};
+
+static const struct renesas_family fam_rcar_gen3 __initconst __maybe_unused = {
+ .name = "R-Car Gen3",
+ .reg = 0xfff00044, /* PRR (Product Register) */
+};
+
+static const struct renesas_family fam_rmobile __initconst __maybe_unused = {
+ .name = "R-Mobile",
+ .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
+};
+
+static const struct renesas_family fam_rza __initconst __maybe_unused = {
+ .name = "RZ/A",
+};
+
+static const struct renesas_family fam_rzg __initconst __maybe_unused = {
+ .name = "RZ/G",
+ .reg = 0xff000044, /* PRR (Product Register) */
+};
+
+static const struct renesas_family fam_shmobile __initconst __maybe_unused = {
+ .name = "SH-Mobile",
+ .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
+};
+
+
+struct renesas_soc {
+ const struct renesas_family *family;
+ u8 id;
+};
+
+static const struct renesas_soc soc_rz_a1h __initconst __maybe_unused = {
+ .family = &fam_rza,
+};
+
+static const struct renesas_soc soc_rmobile_ape6 __initconst __maybe_unused = {
+ .family = &fam_rmobile,
+ .id = 0x3f,
+};
+
+static const struct renesas_soc soc_rmobile_a1 __initconst __maybe_unused = {
+ .family = &fam_rmobile,
+ .id = 0x40,
+};
+
+static const struct renesas_soc soc_rz_g1m __initconst __maybe_unused = {
+ .family = &fam_rzg,
+ .id = 0x47,
+};
+
+static const struct renesas_soc soc_rz_g1e __initconst __maybe_unused = {
+ .family = &fam_rzg,
+ .id = 0x4c,
+};
+
+static const struct renesas_soc soc_rcar_m1a __initconst __maybe_unused = {
+ .family = &fam_rcar_gen1,
+};
+
+static const struct renesas_soc soc_rcar_h1 __initconst __maybe_unused = {
+ .family = &fam_rcar_gen1,
+ .id = 0x3b,
+};
+
+static const struct renesas_soc soc_rcar_h2 __initconst __maybe_unused = {
+ .family = &fam_rcar_gen2,
+ .id = 0x45,
+};
+
+static const struct renesas_soc soc_rcar_m2_w __initconst __maybe_unused = {
+ .family = &fam_rcar_gen2,
+ .id = 0x47,
+};
+
+static const struct renesas_soc soc_rcar_v2h __initconst __maybe_unused = {
+ .family = &fam_rcar_gen2,
+ .id = 0x4a,
+};
+
+static const struct renesas_soc soc_rcar_m2_n __initconst __maybe_unused = {
+ .family = &fam_rcar_gen2,
+ .id = 0x4b,
+};
+
+static const struct renesas_soc soc_rcar_e2 __initconst __maybe_unused = {
+ .family = &fam_rcar_gen2,
+ .id = 0x4c,
+};
+
+static const struct renesas_soc soc_rcar_h3 __initconst __maybe_unused = {
+ .family = &fam_rcar_gen3,
+ .id = 0x4f,
+};
+
+static const struct renesas_soc soc_rcar_m3_w __initconst __maybe_unused = {
+ .family = &fam_rcar_gen3,
+ .id = 0x52,
+};
+
+static const struct renesas_soc soc_shmobile_ag5 __initconst __maybe_unused = {
+ .family = &fam_shmobile,
+ .id = 0x37,
+};
+
+
+static const struct of_device_id renesas_socs[] __initconst = {
+#ifdef CONFIG_ARCH_R7S72100
+ { .compatible = "renesas,r7s72100", .data = &soc_rz_a1h },
+#endif
+#ifdef CONFIG_ARCH_R8A73A4
+ { .compatible = "renesas,r8a73a4", .data = &soc_rmobile_ape6 },
+#endif
+#ifdef CONFIG_ARCH_R8A7740
+ { .compatible = "renesas,r8a7740", .data = &soc_rmobile_a1 },
+#endif
+#ifdef CONFIG_ARCH_R8A7743
+ { .compatible = "renesas,r8a7743", .data = &soc_rz_g1m },
+#endif
+#ifdef CONFIG_ARCH_R8A7745
+ { .compatible = "renesas,r8a7745", .data = &soc_rz_g1e },
+#endif
+#ifdef CONFIG_ARCH_R8A7778
+ { .compatible = "renesas,r8a7778", .data = &soc_rcar_m1a },
+#endif
+#ifdef CONFIG_ARCH_R8A7779
+ { .compatible = "renesas,r8a7779", .data = &soc_rcar_h1 },
+#endif
+#ifdef CONFIG_ARCH_R8A7790
+ { .compatible = "renesas,r8a7790", .data = &soc_rcar_h2 },
+#endif
+#ifdef CONFIG_ARCH_R8A7791
+ { .compatible = "renesas,r8a7791", .data = &soc_rcar_m2_w },
+#endif
+#ifdef CONFIG_ARCH_R8A7792
+ { .compatible = "renesas,r8a7792", .data = &soc_rcar_v2h },
+#endif
+#ifdef CONFIG_ARCH_R8A7793
+ { .compatible = "renesas,r8a7793", .data = &soc_rcar_m2_n },
+#endif
+#ifdef CONFIG_ARCH_R8A7794
+ { .compatible = "renesas,r8a7794", .data = &soc_rcar_e2 },
+#endif
+#ifdef CONFIG_ARCH_R8A7795
+ { .compatible = "renesas,r8a7795", .data = &soc_rcar_h3 },
+#endif
+#ifdef CONFIG_ARCH_R8A7796
+ { .compatible = "renesas,r8a7796", .data = &soc_rcar_m3_w },
+#endif
+#ifdef CONFIG_ARCH_SH73A0
+ { .compatible = "renesas,sh73a0", .data = &soc_shmobile_ag5 },
+#endif
+ { /* sentinel */ }
+};
+
+static int __init renesas_soc_init(void)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ const struct renesas_family *family;
+ const struct of_device_id *match;
+ const struct renesas_soc *soc;
+ void __iomem *chipid = NULL;
+ struct soc_device *soc_dev;
+ struct device_node *np;
+ unsigned int product;
+
+ match = of_match_node(renesas_socs, of_root);
+ if (!match)
+ return -ENODEV;
+
+ soc = match->data;
+ family = soc->family;
+
+ /* Try PRR first, then hardcoded fallback */
+ np = of_find_compatible_node(NULL, NULL, "renesas,prr");
+ if (np) {
+ chipid = of_iomap(np, 0);
+ of_node_put(np);
+ } else if (soc->id) {
+ chipid = ioremap(family->reg, 4);
+ }
+ if (chipid) {
+ product = readl(chipid);
+ iounmap(chipid);
+ if (soc->id && ((product >> 8) & 0xff) != soc->id) {
+ pr_warn("SoC mismatch (product = 0x%x)\n", product);
+ return -ENODEV;
+ }
+ }
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENOMEM;
+
+ np = of_find_node_by_path("/");
+ of_property_read_string(np, "model", &soc_dev_attr->machine);
+ of_node_put(np);
+
+ soc_dev_attr->family = kstrdup_const(family->name, GFP_KERNEL);
+ soc_dev_attr->soc_id = kstrdup_const(strchr(match->compatible, ',') + 1,
+ GFP_KERNEL);
+ if (chipid)
+ soc_dev_attr->revision = kasprintf(GFP_KERNEL, "ES%u.%u",
+ ((product >> 4) & 0x0f) + 1,
+ product & 0xf);
+
+ pr_info("Detected Renesas %s %s %s\n", soc_dev_attr->family,
+ soc_dev_attr->soc_id, soc_dev_attr->revision ?: "");
+
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ kfree(soc_dev_attr->revision);
+ kfree_const(soc_dev_attr->soc_id);
+ kfree_const(soc_dev_attr->family);
+ kfree(soc_dev_attr);
+ return PTR_ERR(soc_dev);
+ }
+
+ return 0;
+}
+core_initcall(renesas_soc_init);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 01/31] ARM: dts: alt: Fix PFC names for DU
From: Simon Horman @ 2016-11-23 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479931686.git.horms+renesas@verge.net.au>
From: Jacopo Mondi <jacopo@jmondi.org>
Update the PFC pin groups and function names of DU interface for
r8a7794 ALT board.
The currently specified pin groups and function names prevented PFC and
DU interfaces from being correctly configured:
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
rcar-du: probe of feb00000.display failed with error -22
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7794-alt.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
index 325d3f972c57..a3e74684289b 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -165,8 +165,8 @@
pinctrl-names = "default";
du_pins: du {
- groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_dotclkout0";
- function = "du";
+ groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_clk0_out";
+ function = "du1";
};
scif2_pins: scif2 {
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 02/31] ARM: dts: r8a7794: Correct hsusb parent clock
From: Simon Horman @ 2016-11-23 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479931686.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
The parent clock of the HSUSB clock is the HP clock, not the MP clock.
Fixes: c7bab9f929e51761 ("ARM: shmobile: r8a7794: Add USB clocks to device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7794.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 01816ac775a8..7d9f0601d3ca 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1262,7 +1262,7 @@
mstp7_clks: mstp7_clks at e615014c {
compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0 0xe615014c 0 4>, <0 0xe61501c4 0 4>;
- clocks = <&mp_clk>, <&mp_clk>,
+ clocks = <&mp_clk>, <&hp_clk>,
<&zs_clk>, <&p_clk>, <&p_clk>, <&zs_clk>,
<&zs_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
<&zx_clk>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 03/31] ARM: dts: r8a7794: Use SYSC "always-on" PM Domain for sound
From: Simon Horman @ 2016-11-23 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479931686.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Hook up the Audio-DMAC and sound device nodes to the SYSC "always-on" PM
Domain, for a more consistent device-power-area description in DT.
Cfr. commit 0761ff2ad0c581f3 ("ARM: dts: r8a7794: Add SYSC PM Domains").
Fixes: 320d6c5a08a4abd3 ("ARM: dts: r8a7794: add sound support")
Fixes: 298e4ee3d213a076 ("ARM: dts: r8a7794: add Audio-DMAC support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7794.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 7d9f0601d3ca..364b4aa8d1c1 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -319,7 +319,7 @@
"ch12";
clocks = <&mstp5_clks R8A7794_CLK_AUDIO_DMAC0>;
clock-names = "fck";
- power-domains = <&cpg_clocks>;
+ power-domains = <&sysc R8A7794_PD_ALWAYS_ON>;
#dma-cells = <1>;
dma-channels = <13>;
};
@@ -1485,7 +1485,7 @@
"mix.0", "mix.1",
"dvc.0", "dvc.1",
"clk_a", "clk_b", "clk_c", "clk_i";
- power-domains = <&cpg_clocks>;
+ power-domains = <&sysc R8A7794_PD_ALWAYS_ON>;
status = "disabled";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 04/31] ARM: dts: lager: rename and reindex i2cexio
From: Simon Horman @ 2016-11-23 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479931686.git.horms+renesas@verge.net.au>
The rename from i2cexio to i2cexio0 is in preparation for adding
i2cexio1 which will use the demuxer for IIC1/I2C1.
The reindexing from i2c8 to i2c10 is to allow space for grouping of
additional GPIO buses to be added by follow-up patches to support demuxing
of other i2c buses.
Also note that fallback to GPIO is not provided by the hardware for IIC0/I2C0.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[wsa: rebased, fixed alias and removed typo in commit message]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
arch/arm/boot/dts/r8a7790-lager.dts | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 434268262d88..5645444cd21a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -50,7 +50,7 @@
aliases {
serial0 = &scif0;
serial1 = &scifa1;
- i2c8 = "i2cexio";
+ i2c10 = &i2cexio0;
};
chosen {
@@ -273,11 +273,13 @@
* bus with IIC3 on pins 110 (SCL) + 112 (SDA), select I2C0 at runtime, and
* instantiate the slave device at runtime according to the documentation.
* You can then communicate with the slave via IIC3.
+ *
+ * IIC0/I2C0 does not appear to support fallback to GPIO.
*/
- i2cexio: i2c-8 {
+ i2cexio0: i2c-10 {
compatible = "i2c-demux-pinctrl";
i2c-parent = <&iic0>, <&i2c0>;
- i2c-bus-name = "i2c-exio";
+ i2c-bus-name = "i2c-exio0";
#address-cells = <1>;
#size-cells = <0>;
};
@@ -596,12 +598,12 @@
&i2c0 {
pinctrl-0 = <&i2c0_pins>;
- pinctrl-names = "i2c-exio";
+ pinctrl-names = "i2c-exio0";
};
&iic0 {
pinctrl-0 = <&iic0_pins>;
- pinctrl-names = "i2c-exio";
+ pinctrl-names = "i2c-exio0";
};
&iic1 {
--
2.7.0.rc3.207.g0ac5344
^ 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