* Re: [PATCH v3 1/9] mm: Introduce new vm_insert_range API
From: Souptick Joarder @ 2018-12-07 21:48 UTC (permalink / raw)
To: robin.murphy
Cc: Michal Hocko, Heiko Stuebner, Peter Zijlstra, dri-devel,
linux-kernel, Linux-MM, linux1394-devel, Marek Szyprowski,
Stephen Rothwell, oleksandr_andrushchenko, joro,
Russell King - ARM Linux, Matthew Wilcox, airlied,
linux-arm-kernel, linux-rockchip, treding, linux-media, Kees Cook,
pawel, Rik van Riel, iommu, rppt, Boris Ostrovsky, mchehab,
iamjoonsoo.kim, vbabka, Juergen Gross, hjc, xen-devel,
Kyungmin Park, stefanr, Andrew Morton, Kirill A. Shutemov
In-Reply-To: <67495f8f-2092-e42d-321e-5216c346513f@arm.com>
On Sat, Dec 8, 2018 at 2:40 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2018-12-07 7:28 pm, Souptick Joarder wrote:
> > On Fri, Dec 7, 2018 at 10:41 PM Matthew Wilcox <willy@infradead.org> wrote:
> >>
> >> On Fri, Dec 07, 2018 at 03:34:56PM +0000, Robin Murphy wrote:
> >>>> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> >>>> + struct page **pages, unsigned long page_count)
> >>>> +{
> >>>> + unsigned long uaddr = addr;
> >>>> + int ret = 0, i;
> >>>
> >>> Some of the sites being replaced were effectively ensuring that vma and
> >>> pages were mutually compatible as an initial condition - would it be worth
> >>> adding something here for robustness, e.g.:
> >>>
> >>> + if (page_count != vma_pages(vma))
> >>> + return -ENXIO;
> >>
> >> I think we want to allow this to be used to populate part of a VMA.
> >> So perhaps:
> >>
> >> if (page_count > vma_pages(vma))
> >> return -ENXIO;
> >
> > Ok, This can be added.
> >
> > I think Patch [2/9] is the only leftover place where this
> > check could be removed.
>
> Right, 9/9 could also have relied on my stricter check here, but since
> it's really testing whether it actually managed to allocate vma_pages()
> worth of pages earlier, Matthew's more lenient version won't help for
> that one.
(Why privcmd_buf_mmap() doesn't clean up and return an error
> as soon as that allocation loop fails, without taking the mutex under
> which it still does a bunch more pointless work to only undo it again,
> is a mind-boggling mystery, but that's not our problem here...)
I think some clean up can be done here in a separate patch.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] meson: Fix IRQ trigger type
From: Martin Blumenstingl @ 2018-12-07 21:56 UTC (permalink / raw)
To: ingrassia
Cc: mark.rutland, devicetree, ccaione, khilman, robh+dt,
linux-amlogic, linux-arm-kernel, jbrunet
In-Reply-To: <20181207182845.GA3779@ingrassia.epigenesys.com>
Hi Emiliano,
On Fri, Dec 7, 2018 at 7:28 PM Emiliano Ingrassia
<ingrassia@epigenesys.com> wrote:
[...]
> > All your test seems in show it the fact the Amlogic SoC usually prioritize the
> > TX traffic over RX, which is something we've known about for a while.
> >
>
> Is that normal and/or acceptable?
the public S805 datasheet mentions in the "Ethernet MAC" features
section (22.2) on page 120:
"RX FIFO 4KB, TX FIFO 2KB"
this suggests that
I did some tests using some Armbian 3.10 kernel on my Odroid-C1:
root@odroidc1:~# iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 4] local 192.168.1.163 port 44297 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 49.9 MBytes 419 Mbits/sec 0 809 KBytes
[ 4] 1.00-2.00 sec 48.7 MBytes 408 Mbits/sec 0 809 KBytes
[ 4] 2.00-3.00 sec 48.4 MBytes 407 Mbits/sec 0 809 KBytes
[ 4] 3.00-4.00 sec 48.9 MBytes 409 Mbits/sec 0 809 KBytes
[ 4] 4.00-5.00 sec 48.2 MBytes 406 Mbits/sec 0 809 KBytes
[ 4] 5.00-6.00 sec 48.8 MBytes 409 Mbits/sec 0 809 KBytes
[ 4] 6.00-7.00 sec 48.7 MBytes 408 Mbits/sec 0 809 KBytes
[ 4] 7.00-8.00 sec 48.0 MBytes 404 Mbits/sec 0 809 KBytes
[ 4] 8.00-9.00 sec 48.1 MBytes 403 Mbits/sec 0 809 KBytes
[ 4] 9.00-10.00 sec 48.1 MBytes 404 Mbits/sec 0 809 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 486 MBytes 408 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 485 MBytes 407 Mbits/sec receiver
iperf Done.
root@odroidc1:~# iperf3 -c 192.168.1.100 -R
Connecting to host 192.168.1.100, port 5201
Reverse mode, remote host 192.168.1.100 is sending
[ 4] local 192.168.1.163 port 44301 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 87.5 MBytes 734 Mbits/sec
[ 4] 1.00-2.00 sec 89.2 MBytes 748 Mbits/sec
[ 4] 2.00-3.00 sec 89.0 MBytes 747 Mbits/sec
[ 4] 3.00-4.00 sec 88.9 MBytes 746 Mbits/sec
[ 4] 4.00-5.00 sec 89.2 MBytes 748 Mbits/sec
[ 4] 5.00-6.00 sec 89.0 MBytes 747 Mbits/sec
[ 4] 6.00-7.00 sec 88.5 MBytes 742 Mbits/sec
[ 4] 7.00-8.00 sec 88.5 MBytes 742 Mbits/sec
[ 4] 8.00-9.00 sec 88.5 MBytes 742 Mbits/sec
[ 4] 9.00-10.00 sec 88.2 MBytes 740 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 889 MBytes 745 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 887 MBytes 744 Mbits/sec receiver
iperf Done.
root@odroidc1:~#
[...]
> Furthermore, as Martin reported in one of the previous mail,
> even Amlogic's buildroot kernel uses an edge rising IRQ type
> for the Meson8b MAC. Other evidence that is not so clear
> the need for the first patch on 32 bit Meson SoC.
please note that the dwc2 USB controllers are also using
IRQ_TYPE_EDGE_RISING in Amlogic's 3.10 kernel.
mainline on the other hand uses IRQ_TYPE_LEVEL_HIGH after your commit
291f45dd6da5fa "ARM: dts: meson: fixing USB support on Meson6, Meson8
and Meson8b"
what I want to say is: in some cases we need to use different settings
than the 3.10 kernel!
Regards
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] arm: dts: meson: Fix IRQ trigger type for macirq
From: Martin Blumenstingl @ 2018-12-07 22:06 UTC (permalink / raw)
To: ccaione
Cc: mark.rutland, devicetree, khilman, robh+dt, ingrassia,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20181207105231.25593-3-ccaione@baylibre.com>
Hi Carlo,
On Fri, Dec 7, 2018 at 11:52 AM Carlo Caione <ccaione@baylibre.com> wrote:
>
> A long running stress test on a custom board shipping an AXG SoCs and a
> Realtek RTL8211F PHY revealed that after a few hours the connection
> speed would drop drastically, from ~1000Mbps to ~3Mbps. At the same time
> the 'macirq' (eth0) IRQ would stop being triggered at all and as
> consequence the GMAC IRQs never ACKed.
>
> After a painful investigation the problem seemed to be due to a wrong
> defined IRQ type for the GMAC IRQ that should be LEVEL_HIGH instead of
> EDGE_RISING.
>
> The change in the macirq IRQ type also solved another long standing
> issue affecting this SoC/PHY where EEE was causing the network
> connection to die after stressing it with iperf3 (even though much
> sooner). It's now possible to remove the 'eee-broken-1000t' quirk as
> well.
I tested this on my Odroid-C1. however, I must admit that I never had
issues *without* eee-broken-1000t on any of my boards
without your changes:
[root@alarm ~]# iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 5] local 192.168.1.194 port 38870 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 80.6 MBytes 675 Mbits/sec 0 2.78 MBytes
[ 5] 1.00-2.00 sec 108 MBytes 904 Mbits/sec 0 3.04 MBytes
[ 5] 2.00-3.00 sec 106 MBytes 891 Mbits/sec 0 3.04 MBytes
[ 5] 3.00-4.00 sec 105 MBytes 880 Mbits/sec 0 3.04 MBytes
[ 5] 4.00-5.00 sec 65.0 MBytes 545 Mbits/sec 0 3.04 MBytes
[ 5] 5.00-6.00 sec 92.5 MBytes 777 Mbits/sec 0 3.04 MBytes
[ 5] 6.00-7.00 sec 72.5 MBytes 608 Mbits/sec 0 3.04 MBytes
[ 5] 7.00-8.19 sec 76.2 MBytes 537 Mbits/sec 0 3.04 MBytes
[ 5] 8.19-9.00 sec 48.8 MBytes 504 Mbits/sec 0 3.04 MBytes
[ 5] 9.00-10.00 sec 87.5 MBytes 736 Mbits/sec 0 3.04 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 842 MBytes 706 Mbits/sec 0 sender
[ 5] 0.00-10.05 sec 839 MBytes 701 Mbits/sec receiver
iperf Done.
[root@alarm ~]# iperf3 -c 192.168.1.100 -R
Connecting to host 192.168.1.100, port 5201
Reverse mode, remote host 192.168.1.100 is sending
[ 5] local 192.168.1.194 port 38874 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 21.0 MBytes 175 Mbits/sec
[ 5] 1.00-2.00 sec 20.7 MBytes 174 Mbits/sec
[ 5] 2.00-3.00 sec 22.4 MBytes 187 Mbits/sec
[ 5] 3.00-4.69 sec 25.2 MBytes 125 Mbits/sec
[ 5] 4.69-5.00 sec 7.56 MBytes 206 Mbits/sec
[ 5] 5.00-6.00 sec 23.4 MBytes 196 Mbits/sec
[ 5] 6.00-7.00 sec 14.6 MBytes 123 Mbits/sec
[ 5] 7.00-8.00 sec 23.3 MBytes 196 Mbits/sec
[ 5] 8.00-9.00 sec 27.8 MBytes 233 Mbits/sec
[ 5] 9.00-10.03 sec 24.9 MBytes 203 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-9.36 sec 212 MBytes 190 Mbits/sec 1588 sender
[ 5] 0.00-10.03 sec 211 MBytes 176 Mbits/sec receiver
iperf Done.
[root@alarm ~]#
with your changes:
[root@alarm ~]# iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 5] local 192.168.1.197 port 45020 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 74.4 MBytes 624 Mbits/sec 0 2.75 MBytes
[ 5] 1.00-2.00 sec 105 MBytes 881 Mbits/sec 0 3.03 MBytes
[ 5] 2.00-3.00 sec 106 MBytes 891 Mbits/sec 0 3.03 MBytes
[ 5] 3.00-4.00 sec 78.8 MBytes 661 Mbits/sec 0 3.03 MBytes
[ 5] 4.00-5.00 sec 73.8 MBytes 617 Mbits/sec 0 3.03 MBytes
[ 5] 5.00-6.00 sec 87.5 MBytes 735 Mbits/sec 0 3.03 MBytes
[ 5] 6.00-7.15 sec 81.2 MBytes 594 Mbits/sec 0 3.03 MBytes
[ 5] 7.15-8.00 sec 61.2 MBytes 603 Mbits/sec 0 3.03 MBytes
[ 5] 8.00-9.02 sec 76.2 MBytes 625 Mbits/sec 0 3.03 MBytes
[ 5] 9.02-10.00 sec 102 MBytes 880 Mbits/sec 0 3.03 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 847 MBytes 710 Mbits/sec 0 sender
[ 5] 0.00-10.05 sec 846 MBytes 706 Mbits/sec receiver
iperf Done.
[root@alarm ~]# iperf3 -c 192.168.1.100 -R
Connecting to host 192.168.1.100, port 5201
Reverse mode, remote host 192.168.1.100 is sending
[ 5] local 192.168.1.197 port 45024 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 22.6 MBytes 190 Mbits/sec
[ 5] 1.00-2.00 sec 19.3 MBytes 162 Mbits/sec
[ 5] 2.00-3.00 sec 22.1 MBytes 185 Mbits/sec
[ 5] 3.00-4.00 sec 29.6 MBytes 248 Mbits/sec
[ 5] 4.00-5.00 sec 30.1 MBytes 253 Mbits/sec
[ 5] 5.00-6.00 sec 16.7 MBytes 140 Mbits/sec
[ 5] 6.00-7.00 sec 21.5 MBytes 180 Mbits/sec
[ 5] 7.00-8.00 sec 14.0 MBytes 118 Mbits/sec
[ 5] 8.00-9.04 sec 20.4 MBytes 165 Mbits/sec
[ 5] 9.04-10.00 sec 19.6 MBytes 171 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 217 MBytes 181 Mbits/sec 1795 sender
[ 5] 0.00-10.00 sec 216 MBytes 181 Mbits/sec receiver
iperf Done.
[root@alarm ~]#
RX and TX speeds are within 10Mbit/s before and after the test, so I
would call the result "identical" (within a bit of measurement
tolerance)
I'll wait a few days and see what Emiliano finds out on his board,
then I'll send my Tested-by and Acked-by
Regards
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] arm64: defconfig: Enable scu-simple-card driver
From: Simon Horman @ 2018-12-07 22:06 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux-Renesas, Magnus Damm, Linux ARM
In-Reply-To: <CAMuHMdUZSqaW_Vk9GjrtKjRUKdmbFMC5CEswGc_wDWQ-d515hw@mail.gmail.com>
On Fri, Dec 07, 2018 at 09:28:22AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Thu, Dec 6, 2018 at 10:58 PM Simon Horman <horms+renesas@verge.net.au> wrote:
> > Enable the scu-simple-card which is used by
> > the R-Car E3 (r8a77990) based Ebisu board.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> > arch/arm64/configs/defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index f88190463481..9d0b42d96f03 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -491,6 +491,7 @@ CONFIG_SND_SOC_RT5514=m
> > CONFIG_SND_SOC_RT5514_SPI=m
> > CONFIG_SND_SOC_RT5645=m
> > CONFIG_SND_SIMPLE_CARD=m
> > +CONFIG_SND_SIMPLE_SCU_CARD=y
>
> Shouldn't this be "m"?
Thanks Geert,
I'll look into an incremental update for that.
>
> > CONFIG_SND_AUDIO_GRAPH_CARD=m
> > CONFIG_I2C_HID=m
> > CONFIG_USB=y
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Moving ARM dts files
From: Rob Herring @ 2018-12-07 22:33 UTC (permalink / raw)
To: ARM-SoC Maintainers
Cc: Andrew Lunn, Alexandre Belloni, Tony Lindgren, Linus Walleij,
Liviu Dudau, Masahiro Yamada, Thierry Reding, Florian Fainelli,
Kevin Hilman, Gregory CLEMENT, Michal Simek, Krzysztof Kozlowski,
Joel Stanley, Andy Gross, devicetree, Jason Cooper, Simon Horman,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Maxime Coquelin, Shawn Guo, Andreas Färber, Daniel Mack
In-Reply-To: <20181204183649.GA5716@bogus>
On Tue, Dec 4, 2018 at 12:36 PM Rob Herring <robh@kernel.org> wrote:
>
> Olof, Arnd,
>
> I've put together a script to move the dts files and update the
> makefiles. It doesn't handle files not following a common prefix which
> isn't many and some includes within the dts files will need some fixups
> by hand.
>
> MAINTAINERS will also need updating.
>
> A few questions:
>
> Do we want to move absolutely everything to subdirs? There's quite a
> few platforms with only 1-2 platforms. I haven't added these to the
> list yet, but can.
>
> Do any vendors need another level of directories? davinci, omap, nspire,
> etc. for TI for example.
>
> What to do with armv7m.dtsi? I guess it should remain and we just fixup
> the include. There may be a few other cross vendor things.
>
>
> Sub-arch maintainers,
> 'vendor_map' below is the mapping of file prefix to new subdirectory
> (the SoC vendor prefix). Please comment if there are any issues.
Here's an updated mapping filled out with the rest of the platforms
and using SoC family names in some cases as discussed. The move is
completely scripted now including include fixups (though any new
includes could break things). So mainly just need to bikeshed the
directory mapping. Not sure if marvell should be split up more or not.
I split out pxa2xx and pxa3xx, but then there's other pxa chips I
think aren't really related. TI is still all one directory except
nspire. I was going to split out davinci too, but it's only a couple
of files. Sub-arch maintainers need to chime in with what they want.
A branch is here including a fix to dtbs_install:
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move
vendor_map = {
'alphascale' : 'alphascale',
'alpine' : 'alpine',
'artpec' : 'axis',
'atlas' : 'sirf',
'prima' : 'sirf',
'axm' : 'lsi',
'cx9' : 'cnxt',
'ecx' : 'calxeda',
'highbank' : 'calxeda',
'efm' : 'efm32',
'ep7' : 'cirrus',
'mxs': 'mxs',
'imx23': 'mxs',
'imx28': 'mxs',
'imx': 'imx',
'ls': 'fsl',
'vf': 'fsl',
'qcom': 'qcom',
'am3' : 'ti',
'am4' : 'ti',
'am5' : 'ti',
'dra' : 'ti',
'keystone' : 'ti',
'omap' : 'ti',
'compulab' : 'ti',
'logicpd' : 'ti',
'elpida' : 'ti',
'motorola-cpcap' : 'ti',
'twl' : 'ti',
'da' : 'ti',
'dm' : 'ti',
'nspire' : 'nspire',
'armada' : 'marvell',
'dove' : 'marvell',
'kirkwood' : 'marvell',
'orion' : 'marvell',
'mvebu' : 'marvell',
'mmp2' : 'marvell',
'berlin' : 'berlin',
'pxa2' : 'pxa',
'pxa3' : 'pxa',
'pxa' : 'marvell',
'arm-' : 'arm',
'integ' : 'arm',
'mps' : 'arm',
've' : 'arm',
'aspeed' : 'aspeed',
'at91' : 'at91',
'sama' : 'at91',
'usb_' : 'at91',
'tny_' : 'at91',
'mpa1600' : 'at91',
'animeo_ip' : 'at91',
'aks-cdu' : 'at91',
'ethernut5' : 'at91',
'evk-pro3' : 'at91',
'pm9g45' : 'at91',
'ge86' : 'at91',
'bcm' : 'brcm',
'exynos' : 'exynos',
's3c' : 'samsung',
's5p' : 'samsung',
'gemini' : 'gemini',
'hi3' : 'hisilicon',
'hip' : 'hisilicon',
'hisi' : 'hisilicon',
'mt' : 'mediatek',
'meson' : 'meson',
'moxa' : 'moxa',
'nuvo' : 'nuvoton',
'lpc' : 'lpc',
'owl' : 'actions',
'ox8' : 'oxsemi',
'picox' : 'picoxcell',
'r7' : 'renesas',
'r8' : 'renesas',
'r9' : 'renesas',
'emev2' : 'renesas',
'sh73a' : 'renesas',
'gr-' : 'renesas',
'iwg' : 'renesas',
'rk' : 'rockchip',
'rv11' : 'rockchip',
'socfpga' : 'socfpga',
'stm' : 'stm32',
'sti' : 'sti',
'st-pin' : 'sti',
'ste' : 'st-ericsson',
'spear' : 'spear',
'sun' : 'allwinner',
'axp' : 'allwinner',
'tango' : 'sigma',
'tegra' : 'nvidia',
'uniph' : 'socionext',
'vt8500' : 'vt8500',
'wm8' : 'vt8500',
'xen' : 'xen',
'zx' : 'zte',
'zynq' : 'xilinx',
}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: increase stack size for KASAN_EXTRA
From: Qian Cai @ 2018-12-07 22:34 UTC (permalink / raw)
To: catalin.marinas, will.deacon
Cc: Qian Cai, arnd, linux-kernel, kasan-dev, linux-mm, glider,
linux-arm-kernel, aryabinin, dvyukov
In-Reply-To: <721E7B42-2D55-4866-9C1A-3E8D64F33F9C@gmx.us>
If the kernel is configured with KASAN_EXTRA, the stack size is
increasted significantly due to enable this option will set
-fstack-reuse to "none" in GCC [1]. As the results, it could trigger
stack overrun quite often with 32k stack size compiled using GCC 8. For
example, this reproducer
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/\
syscalls/madvise/madvise06.c
could trigger a "corrupted stack end detected inside scheduler" very
reliably with CONFIG_SCHED_STACK_END_CHECK enabled. Also, See other bug
reports,
https://lore.kernel.org/lkml/1542144497.12945.29.camel@gmx.us/
https://lore.kernel.org/lkml/721E7B42-2D55-4866-9C1A-3E8D64F33F9C@gmx.us/
There are just too many functions that could have a large stack with
KASAN_EXTRA due to large local variables that have been called over and
over again without being able to reuse the stacks. Some noticiable ones
are,
size
7536 shrink_inactive_list
7440 shrink_page_list
6560 fscache_stats_show
3920 jbd2_journal_commit_transaction
3216 try_to_unmap_one
3072 migrate_page_move_mapping
3584 migrate_misplaced_transhuge_page
3920 ip_vs_lblcr_schedule
4304 lpfc_nvme_info_show
3888 lpfc_debugfs_nvmestat_data.constprop
There are other 49 functions are over 2k in size while compiling kernel
with "-Wframe-larger-than=" on this machine. Hence, it is too much work
to change Makefiles for each object to compile without
-fsanitize-address-use-after-scope individually.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c23
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/arm64/include/asm/memory.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index b96442960aea..56562ff01076 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -76,12 +76,17 @@
/*
* KASAN requires 1/8th of the kernel virtual address space for the shadow
* region. KASAN can bloat the stack significantly, so double the (minimum)
- * stack size when KASAN is in use.
+ * stack size when KASAN is in use, and then double it again if KASAN_EXTRA is
+ * on.
*/
#ifdef CONFIG_KASAN
#define KASAN_SHADOW_SCALE_SHIFT 3
#define KASAN_SHADOW_SIZE (UL(1) << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
+#ifdef CONFIG_KASAN_EXTRA
+#define KASAN_THREAD_SHIFT 2
+#else
#define KASAN_THREAD_SHIFT 1
+#endif /* CONFIG_KASAN_EXTRA */
#else
#define KASAN_SHADOW_SIZE (0)
#define KASAN_THREAD_SHIFT 0
--
2.17.2 (Apple Git-113)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [GIT PULL] arm64 fixes for 4.20-rc6
From: pr-tracker-bot @ 2018-12-07 22:40 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Linus Torvalds, linux-kernel, linux-arm-kernel
In-Reply-To: <20181207183459.GA30569@arrakis.emea.arm.com>
The pull request you sent on Fri, 7 Dec 2018 18:35:01 +0000:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b8bf4692c98038a1ec98faf09e545d1a32429b54
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4 1/4] dt-bindings: fsl: scu: add thermal binding
From: Rob Herring @ 2018-12-07 23:13 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland@arm.com, heiko@sntech.de, catalin.marinas@arm.com,
will.deacon@arm.com, bjorn.andersson@linaro.org,
LW@KARO-electronics.de, daniel.lezcano@linaro.org, dl-linux-imx,
Andy Gross, rui.zhang@intel.com, devicetree@vger.kernel.org,
arnd@arndb.de, linux-pm@vger.kernel.org, edubezval@gmail.com,
enric.balletbo@collabora.com, robh+dt@kernel.org,
horms+renesas@verge.net.au, ezequiel@collabora.com,
linux-arm-kernel@lists.infradead.org, Aisheng DONG,
linux-kernel@vger.kernel.org, amit.kucheria@linaro.org,
olof@lixom.net, shawnguo@kernel.org
In-Reply-To: <1543458696-4741-2-git-send-email-Anson.Huang@nxp.com>
On Thu, 29 Nov 2018 02:37:24 +0000, Anson Huang wrote:
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> system controller, the system controller is in charge of system
> power, clock and thermal sensors etc. management, Linux kernel
> has to communicate with system controller via MU (message unit)
> IPC to get temperature from thermal sensors, this patch adds
> binding doc for i.MX system controller thermal driver.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> ChangeLog:
> V3->V4:
> *move binding doc to SCU since it is belonging to SCU;
> *change compatile string to start with "fsl" instead of "nxp" to align with other nodes in dtb.
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 4/5] ARM: dts: imx5: add gpu nodes
From: Fabio Estevam @ 2018-12-07 23:25 UTC (permalink / raw)
To: Jonathan Marek
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
freedreno, Sascha Hauer, linux-kernel, Rob Herring, Chris Healy,
Sascha Hauer, Fabio Estevam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
NXP Linux Team
In-Reply-To: <20181204151702.8514-4-jonathan@marek.ca>
On Tue, Dec 4, 2018 at 1:20 PM Jonathan Marek <jonathan@marek.ca> wrote:
>
> This adds the gpu nodes for the adreno 200 GPU on iMX51 and iMX53, now
> supported by the freedreno driver.
>
> The compatible for the iMX51 uses a patchid of 1, which is used by drm/msm
> driver to identify the smaller 128KiB GMEM size.
>
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 5/6] DEV: CLK: sunxi ccu: export clk_apb1 for sun8i-r40 soc pwm.
From: Rob Herring @ 2018-12-07 23:25 UTC (permalink / raw)
To: Hao Zhang
Cc: mark.rutland, devicetree, linux-gpio, maxime.ripard, mturquette,
linux-sunxi, linux-kernel, linux-pwm, hao5781286, sboyd, wens,
robh+dt, thierry.reding, linux-arm-kernel
In-Reply-To: <20181125162203.GA5392@arx-s1>
On Mon, 26 Nov 2018 00:22:03 +0800, Hao Zhang wrote:
> The clock source for sun8i R40 is from apb1, so export it for
> dt parses.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 4 +++-
> include/dt-bindings/clock/sun8i-r40-ccu.h | 2 ++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: interrupt-controller: Actions external interrupt controller
From: Rob Herring @ 2018-12-07 23:29 UTC (permalink / raw)
To: Parthiban Nallathambi
Cc: mark.rutland, devicetree, linux, jason, marc.zyngier,
catalin.marinas, laisa.costa, will.deacon, linux-kernel,
thomas.liau, edgar.righi, guilherme.simoes, mp-cs,
manivannan.sadhasivam, tglx, mkzuffo, afaerber, linux-arm-kernel,
Saravanan Sekar
In-Reply-To: <20181126100356.2840578-2-pn@denx.de>
On Mon, Nov 26, 2018 at 11:03:53AM +0100, Parthiban Nallathambi wrote:
> Actions Semi OWL family SoC's provides support for external interrupt
> controller to be connected and controlled using SIRQ pins. S500, S700
> and S900 provides 3 SIRQ lines and works independently for 3 external
> interrupt controllers.
>
> Signed-off-by: Parthiban Nallathambi <pn@denx.de>
> Signed-off-by: Saravanan Sekar <sravanhome@gmail.com>
> ---
> .../interrupt-controller/actions,owl-sirq.txt | 57 +++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.txt b/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.txt
> new file mode 100644
> index 000000000000..b3adc4bddf40
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.txt
> @@ -0,0 +1,57 @@
> +Actions Semi Owl SoCs SIRQ interrupt controller
> +
> +S500, S700 and S900 SoC's from Actions provides 3 SPI's from GIC,
Listing SoCs here means you have to update this line for every new SoC.
> +in which external interrupt controller can be connected. 3 SPI's
> +45, 46, 47 from GIC are directly exposed as SIRQ. It has
> +the following properties:
> +
> +- inputs three interrupt signal from external interrupt controller
> +
> +Required properties:
> +
> +- compatible: should be "actions,owl-sirq"
SoC specific compatibles needed.
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- interrupt-controller: identifies the node as an interrupt controller
> +- #interrupt-cells: specifies the number of cells needed to encode an interrupt
> + source, should be 2.
> +- actions,sirq-shared-reg: Applicable for S500 and S700 where SIRQ register
> + details are maintained at same offset/register.
> +- actions,sirq-reg-offset: register offset for SIRQ interrupts. When registers are
> + shared, all the three offsets will be same (S500 and S700).
These properties should be implied by the compatible string.
> +- actions,ext-irq-range: Identifies external irq number range in different SoCs.
Why is this needed? It appears to always be the same.
> +
> +Example for S900:
> +
> +sirq: interrupt-controller@e01b0000 {
> + compatible = "actions,owl-sirq";
> + reg = <0x0 0xe01b0000 0x0 0x1000>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + actions,sirq-offset = <0x200 0x528 0x52c>;
> + actions,ext-irq-range = <13 15>;
> +};
> +
> +Example for S700:
Examples are examples, not an enumeration of all possible dts entries.
So 1 should be sufficient.
> +
> +sirq: interrupt-controller@e01b0000 {
> + compatible = "actions,owl-sirq";
> + reg = <0x0 0xe01b0000 0x0 0x1000>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + actions,sirq-shared-reg;
> + actions,sirq-reg-offset = <0x200 0x200 0x200>;
> + actions,ext-irq-range = <13 15>;
> +};
> +
> +Example for S500:
> +
> +sirq: interrupt-controller@b01b0000 {
> + compatible = "actions,owl-sirq";
> + reg = <0x0 0xb01b0000 0x0 0x1000>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + actions,sirq-shared-reg;
> + actions,sirq-offset = <0x200 0x200 0x200>;
> + actions,ext-irq-range = <13 15>;
> +};
> --
> 2.17.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v11 5/8] interconnect: qcom: Add sdm845 interconnect provider driver
From: Matthias Kaehlcke @ 2018-12-07 23:30 UTC (permalink / raw)
To: Georgi Djakov
Cc: mark.rutland, sanjayc, maxime.ripard, mturquette, daidavid1,
bjorn.andersson, skannan, abailon, lorenzo.pieralisi,
vincent.guittot, seansw, khilman, evgreen, ksitaraman, devicetree,
arnd, linux-pm, linux-arm-msm, robh+dt, linux-tegra,
linux-arm-kernel, gregkh, rjw, dianders, amit.kucheria,
linux-kernel, thierry.reding
In-Reply-To: <20181207152917.4862-6-georgi.djakov@linaro.org>
Hi Georgi,
not a full review, only one thing I just stumbled across:
On Fri, Dec 07, 2018 at 05:29:14PM +0200, Georgi Djakov wrote:
> From: David Dai <daidavid1@codeaurora.org>
>
> Introduce Qualcomm SDM845 specific provider driver using the
> interconnect framework.
>
> Signed-off-by: David Dai <daidavid1@codeaurora.org>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> .../bindings/interconnect/qcom,sdm845.txt | 24 +
> drivers/interconnect/Kconfig | 5 +
> drivers/interconnect/Makefile | 1 +
> drivers/interconnect/qcom/Kconfig | 13 +
> drivers/interconnect/qcom/Makefile | 5 +
> drivers/interconnect/qcom/sdm845.c | 836 ++++++++++++++++++
> .../dt-bindings/interconnect/qcom,sdm845.h | 143 +++
> 7 files changed, 1027 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
> create mode 100644 drivers/interconnect/qcom/Kconfig
> create mode 100644 drivers/interconnect/qcom/Makefile
> create mode 100644 drivers/interconnect/qcom/sdm845.c
> create mode 100644 include/dt-bindings/interconnect/qcom,sdm845.h
>
> ...
>
> diff --git a/drivers/interconnect/qcom/sdm845.c b/drivers/interconnect/qcom/sdm845.c
> new file mode 100644
> index 000000000000..f594dd6f500f
> --- /dev/null
> +++ b/drivers/interconnect/qcom/sdm845.c
>
> ...
>
> +static int qcom_icc_bcm_init(struct qcom_icc_bcm *bcm, struct device *dev)
> +{
> + struct qcom_icc_node *qn;
> + int ret, i;
> +
> + bcm->addr = cmd_db_read_addr(bcm->name);
> + if (!bcm->addr) {
> + dev_err(dev, "%s could not find RPMh address\n",
> + bcm->name);
> + return -EINVAL;
> + }
> +
> + if (cmd_db_read_aux_data_len(bcm->name) < sizeof(struct bcm_db)) {
> + dev_err(dev, "%s command db missing or partial aux data\n",
> + bcm->name);
> + return -EINVAL;
> + }
cmd_db_read_aux_data_len() is in the process of being removed, see
ed3cafa79ea7 ("soc: qcom: cmd-db: Stop memcpy()ing in
cmd_db_read_aux_data()") in arm-soc/for-next
https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/commit/?h=for-next&id=ed3cafa79ea756be653d22087c017af95ea78a49
Cheers
Matthias
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 01/15] dt-bindings: Add RDA Micro vendor prefix
From: Rob Herring @ 2018-12-07 23:35 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, jason, arnd, marc.zyngier, gregkh, linus.walleij,
daniel.lezcano, linux-kernel, amit.kucheria, robh+dt,
linux-serial, jslaby, olof, tglx, overseas.sales,
Manivannan Sadhasivam, afaerber, linux-arm-kernel, zhao_steven
In-Reply-To: <20181128135106.9255-2-manivannan.sadhasivam@linaro.org>
On Wed, 28 Nov 2018 19:20:52 +0530, Manivannan Sadhasivam wrote:
> From: Andreas Färber <afaerber@suse.de>
>
> Add vendor prefix for RDA Micro which now merged into Unisoc
> Communications Inc.
>
> Cc: overseas.sales@unisoc.com
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Moving ARM dts files
From: Tony Lindgren @ 2018-12-07 23:35 UTC (permalink / raw)
To: Linus Walleij
Cc: Andrew Lunn, Alexandre Belloni, Liviu Dudau, Masahiro Yamada,
thierry.reding@gmail.com, Rob Herring, Florian Fainelli,
Kevin Hilman, Gregory Clement, Michal Simek, Krzysztof Kozlowski,
arm-soc, Joel Stanley, Uwe Kleine-König, Andy Gross,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jason Cooper, Simon Horman, Linux ARM, Jisheng Zhang,
Maxime Coquelin, Shawn Guo, Andreas Färber, Daniel Mack
In-Reply-To: <CACRpkdZ3X1BZtkjofftX2j4Z1FUdwGeU0swxLCyCQ844_h_-Nw@mail.gmail.com>
* Linus Walleij <linus.walleij@linaro.org> [181206 22:12]:
> On Thu, Dec 6, 2018 at 5:57 PM Rob Herring <robh@kernel.org> wrote:
> > On Thu, Dec 6, 2018 at 8:30 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > > We discussed merging all ARM reference design mach-* to one dir
> > > if I just name that mach-arm then we get a convergence to the
> > > vendor name in some organic way.
> >
> > TBC, you want .../boot/dts/arm/* for all the ARM, Ltd boards? Just
> > making sure as you were arguing against vendor names. :)
>
> I am not against vendor names, but I am also for SoC
> names because I think whatever makes most sense should
> be the rule, so both/and not either/or. One does not exclude
> the other. It's just a name.
>
> In this case what
> I meant was that while we (me and Arnd) originally discussed
> merging it all into mach-versatile (how would you know)
> if I instead merge it all into mach-arm, we get a 1:1 correspondence
> between mach-dir and vendor name and DTS dir so everyone
> is happy.
With the number of trade names we've already seen with
the TI SoCs, I'd probably prefer arch/arm/boot/dts/ti.
What used to be omap is now dra7 and am437x and so on.
And for timing, doing this just before -rc1 gets tagged
seems like a good time to do it. At least I have still
pending large dts changes waiting that I'd rather not
send a pull request out for until next week :)
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 02/15] dt-bindings: arm: Document RDA8810PL and reference boards
From: Rob Herring @ 2018-12-07 23:37 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, jason, arnd, marc.zyngier, gregkh, linus.walleij,
daniel.lezcano, linux-kernel, amit.kucheria, robh+dt,
linux-serial, jslaby, olof, tglx, overseas.sales,
Manivannan Sadhasivam, afaerber, linux-arm-kernel, zhao_steven
In-Reply-To: <20181128135106.9255-3-manivannan.sadhasivam@linaro.org>
On Wed, 28 Nov 2018 19:20:53 +0530, Manivannan Sadhasivam wrote:
> From: Andreas Färber <afaerber@suse.de>
>
> Add bindings for RDA Micro RDA8810PL SoC and below reference boards:
>
> 1. Orange Pi 2G-IoT - http://www.orangepi.org/OrangePi2GIOT/
> 2. Orange Pi i96 - https://www.96boards.org/product/orangepi-i96/
>
> Cc: overseas.sales@unisoc.com
> Cc: zhao_steven@263.net
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> Documentation/devicetree/bindings/arm/rda.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/rda.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 04/15] dt-bindings: interrupt-controller: Document RDA8810PL intc
From: Rob Herring @ 2018-12-07 23:38 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, jason, arnd, marc.zyngier, gregkh, linus.walleij,
daniel.lezcano, linux-kernel, amit.kucheria, robh+dt,
linux-serial, jslaby, olof, tglx, overseas.sales,
Manivannan Sadhasivam, afaerber, linux-arm-kernel, zhao_steven
In-Reply-To: <20181128135106.9255-5-manivannan.sadhasivam@linaro.org>
On Wed, 28 Nov 2018 19:20:55 +0530, Manivannan Sadhasivam wrote:
> Document interrupt controller in RDA Micro RDA8810PL SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../interrupt-controller/rda,8810pl-intc.txt | 61 +++++++++++++++++++
> 1 file changed, 61 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 09/15] dt-bindings: timer: Document RDA8810PL SoC timer
From: Rob Herring @ 2018-12-07 23:39 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, jason, arnd, marc.zyngier, gregkh, linus.walleij,
daniel.lezcano, linux-kernel, amit.kucheria, linux-serial, jslaby,
olof, tglx, overseas.sales, afaerber, linux-arm-kernel,
zhao_steven
In-Reply-To: <20181128135106.9255-10-manivannan.sadhasivam@linaro.org>
On Wed, Nov 28, 2018 at 07:21:00PM +0530, Manivannan Sadhasivam wrote:
> Document RDA Micro RDA8810PL SoC timer.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/timer/rda,8810pl-timer.txt | 21 +++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt b/Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt
> new file mode 100644
> index 000000000000..06cc2b00be12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt
> @@ -0,0 +1,21 @@
> +RDA Micro RDA8810PL Timer
> +
> +Required properties:
> +- compatible : "rda,8810pl-timer"
> +- reg : Offset and length of the register set for the device.
> +- interrupts : Should contain the interrupts.
How many?
> +- interrupt-names : Valid names are: "hwtimer", "ostimer".
It's more than just valid names, but rather must be those 2 strings.
> + See ../resource-names.txt
> +
> +Example:
> +
> + apb@20900000 {
> + compatible = "simple-bus";
> + ...
> + timer@10000 {
> + compatible = "rda,8810pl-timer";
> + reg = <0x10000 0x1000>;
> + interrupts = <16 IRQ_TYPE_LEVEL_HIGH>,
> + <17 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "hwtimer", "ostimer";
> + };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 12/15] dt-bindings: serial: Document RDA Micro UART
From: Rob Herring @ 2018-12-07 23:41 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, jason, arnd, marc.zyngier, gregkh, linus.walleij,
daniel.lezcano, linux-kernel, amit.kucheria, linux-serial, jslaby,
olof, tglx, overseas.sales, afaerber, linux-arm-kernel,
zhao_steven
In-Reply-To: <20181128135106.9255-13-manivannan.sadhasivam@linaro.org>
On Wed, Nov 28, 2018 at 07:21:03PM +0530, Manivannan Sadhasivam wrote:
> From: Andreas Färber <afaerber@suse.de>
>
> Add an initial binding for the UART in RDA Micro RDA8810PL SoC.
>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/serial/rda,8810pl-uart.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
>
> diff --git a/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
> new file mode 100644
> index 000000000000..ee03116d7415
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
> @@ -0,0 +1,15 @@
> +RDA Micro UART
> +
> +Required properties:
> +- compatible : "rda,8810pl-uart" for RDA8810PL SoCs.
> +- reg : Offset and length of the register set for the device.
> +- interrupts : Should contain UART interrupt.
Uarts generally need a clock.
> +
> +
> +Example:
> +
> + uart2: serial@20a90000 {
> + compatible = "rda,8810pl-uart";
> + reg = <0x20a90000 0x1000>;
> + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
> + };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: soc: Add a new binding for the BCM2835 PM node.
From: Rob Herring @ 2018-12-07 23:48 UTC (permalink / raw)
To: Eric Anholt
Cc: Mark Rutland, devicetree, Florian Fainelli, linux-watchdog,
Stefan Wahren, linux-kernel, Eric Anholt,
bcm-kernel-feedback-list, linux-rpi-kernel, Wim Van Sebroeck,
Guenter Roeck, linux-arm-kernel
In-Reply-To: <20181130202743.20585-2-eric@anholt.net>
On Fri, 30 Nov 2018 12:27:39 -0800, Eric Anholt wrote:
> This binding supersedes the bcm2835-pm-wdt binding which only covered
> enough to provide a watchdog, but the HW block is actually mostly
> about power domains.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> .../bindings/soc/bcm/brcm,bcm2835-pm.txt | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/5] soc: bcm: bcm2835-pm: Add support for power domains under a new binding.
From: Rob Herring @ 2018-12-07 23:49 UTC (permalink / raw)
To: Eric Anholt
Cc: Mark Rutland, devicetree, Florian Fainelli, linux-watchdog,
Stefan Wahren, linux-kernel, bcm-kernel-feedback-list,
linux-rpi-kernel, Wim Van Sebroeck, Guenter Roeck,
linux-arm-kernel
In-Reply-To: <20181130202743.20585-4-eric@anholt.net>
On Fri, Nov 30, 2018 at 12:27:41PM -0800, Eric Anholt wrote:
> This provides a free software alternative to raspberrypi-power.c's
> firmware calls to manage power domains. It also exposes a reset line,
> where previously the vc4 driver had to try to force power off the
> domain in order to trigger a reset.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> drivers/mfd/bcm2835-pm.c | 36 +-
> drivers/soc/bcm/Kconfig | 11 +
> drivers/soc/bcm/Makefile | 1 +
> drivers/soc/bcm/bcm2835-power.c | 661 +++++++++++++++++++++++++++
> include/dt-bindings/soc/bcm2835-pm.h | 28 ++
Acked-by: Rob Herring <robh@kernel.org>
> include/linux/mfd/bcm2835-pm.h | 1 +
> 6 files changed, 734 insertions(+), 4 deletions(-)
> create mode 100644 drivers/soc/bcm/bcm2835-power.c
> create mode 100644 include/dt-bindings/soc/bcm2835-pm.h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS
From: Andrey Smirnov @ 2018-12-07 23:57 UTC (permalink / raw)
To: niklas.cassel
Cc: Dong Aisheng, Richard Zhu, linux-arm-kernel, linux-pci,
linux-kernel, linux-imx, Bjorn Helgaas, Leonard Crestez,
Chris Healy, Lucas Stach
In-Reply-To: <20181207131113.GA427@centauri.lan>
On Fri, Dec 7, 2018 at 5:11 AM Niklas Cassel <niklas.cassel@linaro.org> wrote:
>
> On Thu, Dec 06, 2018 at 08:55:13PM -0800, Andrey Smirnov wrote:
> > On Thu, Dec 6, 2018 at 2:28 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> > >
> > > Am Mittwoch, den 05.12.2018, 23:45 -0800 schrieb Andrey Smirnov:
> > > > Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
> > > > produces a system where built-in PCIE bridge (16c3:abcd) isn't bound
> > > > to pcieport driver. This, in turn, results in a PCIE bus that is
> > > > capable of enumerating attached PCIE device, but lacks functional
> > > > interrupt support.
> > >
> > > This is odd. AFAIK PCI port services are a totally optional thing and
> > > them being absent should not lead to a non-functional PCI bus. So I
> > > would really like to see some deeper analysis what is going on here.
> > >
> >
> > AFAICT, this is due to pcieport driver enabling MSI of the bridge
> > device (16c3:abcd) via pcie_port_device_register() ->
> > pcie_init_service_irqs() -> pcie_port_enable_irq_vec() -> etc.
> >
> > I did an experiment on a i.MX8MQ/PCIE -> i210 setup I have: I disabled
> > CONFIG_PCIEPORTBUS and hacked igb_main.c enough to make the i210
> > driver believe it should fall back onto legacy interrupts. Even
> > without pcieport present in the system, i210 worked as expected via
> > legacy interrupts, which seems to collaborate my conjecture above.
> >
> > Thanks,
> > Andrey Smirnov
>
> IIUC PCIEPORTBUS should not be needed for MSIs to work,
> it is only needed if you want e.g. PME or AER.
>
> The difference is that if PCIEPORTBUS is enabled, a MSI irq vector will be
> allocated for the Root Complex itself, so that it can send an irq when
> e.g. AER has detected an error.
>
>
> If we disregard that MSI handling is currently broken on DWC PCIe:
> https://marc.info/?l=linux-pci&m=154214986924244&w=2
> It is very possible to have MSIs on dragonboard 820c, which also
> uses the DWC PCIe controller, without having PCIEPORTBUS selected:
>
> # zcat /proc/config.gz | grep -E "PCIE_QCOM|PCIEPORTBUS"
> # CONFIG_PCIEPORTBUS is not set
> CONFIG_PCIE_QCOM=y
>
>
> # lspci -v -s 0000:00:00.0
> 0000:00:00.0 PCI bridge: Qualcomm Device 0104 (prog-if 00 [Normal decode])
> ...
> Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
>
> # lspci -v -s 0000:01:00.0
> 0000:01:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
> ...
> Capabilities: [50] MSI: Enable+ Count=1/8 Maskable+ 64bit-
>
>
> # cat /proc/interrupts | grep MSI
> 70: 5620 0 0 0 PCI-MSI 524288 Edge ath10k_pci
>
> So perhaps this is a bug specific to imx6?
>
Yeah, that seems entirely plausible. I reached out to NXP via one of
the support channels to clarify. I'll report if I hear back from them.
Thanks,
Andrey Smirnov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/9] Improvements for i.MX7D PICO SoM and its baseboards
From: Otavio Salvador @ 2018-12-08 0:01 UTC (permalink / raw)
To: Otavio Salvador
Cc: Mark Rutland, devicetree, Sascha Hauer, Kernel development list,
Rob Herring, NXP Linux Team, Sascha Hauer, Fabio Estevam,
Shawn Guo, linux-arm-kernel
In-Reply-To: <CAP9ODKoG-XRSOekKJWkD3Wg_dPsS2baRzPhuuJmmoT7-omBOtA@mail.gmail.com>
Hello Shawn,
On Thu, Dec 6, 2018 at 8:44 AM Otavio Salvador <otavio@ossystems.com.br> wrote:
> On Thu, Dec 6, 2018 at 8:09 AM Otavio Salvador <otavio@ossystems.com.br> wrote:
> > This patchset rework the imx7d-pico SoM, its Pi baseboard
> > and add the Hobbit baseboard support as well.
> >
> > Changes in v2:
> > - replace fsl,uart-has-rtscts with uart-has-rtscts
> >
> > Fabio Estevam (8):
> > ARM: dts: imx7d-pico: Do not harcode the memory size
> > ARM: dts: imx7d-pico: Switch to SPDX identifier
> > ARM: dts: imx7d-pico-pi: Move SoM related part to imx7d-pico.dtsi
>
> I did the rebase; one thing worth mentioning is that I have "ARM: dts:
> imx7d-pico: Describe the Wifi clock" which is in your fixes tree.
Do you wish me to resent this now that the "ARM: dts: imx7d-pico:
Describe the Wifi clock" is on linux-next? If so I can rebase and
resend. Just let me know how to make it more convenient for you,
please?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3] arm64: Don't flush tlb while clearing the accessed bit
From: Alexander Van Brunt @ 2018-12-08 0:05 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland@arm.com, linux-kernel@vger.kernel.org, Sachin Nikam,
linux-tegra@vger.kernel.org, Ashish Mhetre,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181207175330.GC11430@edgewater-inn.cambridge.arm.com>
> > > My problem with that is it's not really much different to just skipping the
> > > page table update entirely. Skipping the DSB is closer to what is done on
> > > x86, where we bound the stale entry time to the next context-switch.
> >
> > Which of the three implementations is the "that" and "it" in the first sentence?
>
> that = it = skipping the whole invalidation + the DSB
The TLB is tiny compared to the size of the inactive list. Somehow a TLB has to
not be evicted during the page's life in the inactive list. That is not an easy
feat except for the hottest of pages.
If there is a context-switch, most of the original thread's TLBs will be
evicted because TLBs have a hard time to hold two thread's working sets. So, in
practice, that is almost the same as the x86 guarantee.
The worst case cannot have a large impact because the maximum number of pages
that will not have the TLB evicted is the number of pages in the TLB. For
example, a 1024 entry TLB can at worst result in 4 MB of pages erroneously
reclaimed. That is not bad on a system with 4+ GB of memory.
We did benchmark the extreme case where half the pages accessed where not
evicted from the TLB. In the read case, skipping the DSB was ~10% faster than
skipping the invalidate or doing the invalidate and the DSB.
Compared to the improvement in the average performance and variability in the
other cases we tested, the 10% loss in a carefully crafted test is not as
important.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: meson: Fix IRQ trigger type for macirq
From: Kevin Hilman @ 2018-12-08 0:20 UTC (permalink / raw)
To: Carlo Caione, robh+dt, mark.rutland, devicetree, linux-arm-kernel,
linux-amlogic, martin.blumenstingl, ingrassia
Cc: Carlo Caione
In-Reply-To: <20181207105231.25593-2-ccaione@baylibre.com>
Carlo Caione <ccaione@baylibre.com> writes:
> A long running stress test on a custom board shipping an AXG SoCs and a
> Realtek RTL8211F PHY revealed that after a few hours the connection
> speed would drop drastically, from ~1000Mbps to ~3Mbps. At the same time
> the 'macirq' (eth0) IRQ would stop being triggered at all and as
> consequence the GMAC IRQs never ACKed.
>
> After a painful investigation the problem seemed to be due to a wrong
> defined IRQ type for the GMAC IRQ that should be LEVEL_HIGH instead of
> EDGE_RISING.
>
> The change in the macirq IRQ type also solved another long standing
> issue affecting this SoC/PHY where EEE was causing the network
> connection to die after stressing it with iperf3 (even though much
> sooner). It's now possible to remove the 'eee-broken-1000t' quirk as
> well.
>
> Fixes: feb3cbea0946 ("ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage")
> Fixes: 6d28d577510f ("ARM64: dts: meson-axg: fix ethernet stability issue")
> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
> Tested-by: Jerome Brunet <jbrunet@baylibre.com>
> Acked-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Queuing this one for v4.21 (dt64 branch)
I'm going to wait for the dust to settle on 'PATCH v2 2/2' for the
32-bit SoCs (and will rely on Martin's recommendation for the final
decision there.)
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v11 5/8] interconnect: qcom: Add sdm845 interconnect provider driver
From: Georgi Djakov @ 2018-12-08 0:24 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: mark.rutland, sanjayc, maxime.ripard, mturquette, daidavid1,
bjorn.andersson, skannan, abailon, lorenzo.pieralisi,
vincent.guittot, seansw, khilman, evgreen, ksitaraman, devicetree,
arnd, linux-pm, linux-arm-msm, robh+dt, linux-tegra,
linux-arm-kernel, gregkh, rjw, dianders, amit.kucheria,
linux-kernel, thierry.reding
In-Reply-To: <20181207233010.GE14307@google.com>
Hi Matthias,
Thanks for looking into this.
On 8.12.18 1:30, Matthias Kaehlcke wrote:
> Hi Georgi,
>
> not a full review, only one thing I just stumbled across:
>
> On Fri, Dec 07, 2018 at 05:29:14PM +0200, Georgi Djakov wrote:
>> From: David Dai <daidavid1@codeaurora.org>
>>
>> Introduce Qualcomm SDM845 specific provider driver using the
>> interconnect framework.
>>
>> Signed-off-by: David Dai <daidavid1@codeaurora.org>
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>> ---
>> .../bindings/interconnect/qcom,sdm845.txt | 24 +
>> drivers/interconnect/Kconfig | 5 +
>> drivers/interconnect/Makefile | 1 +
>> drivers/interconnect/qcom/Kconfig | 13 +
>> drivers/interconnect/qcom/Makefile | 5 +
>> drivers/interconnect/qcom/sdm845.c | 836 ++++++++++++++++++
>> .../dt-bindings/interconnect/qcom,sdm845.h | 143 +++
>> 7 files changed, 1027 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
>> create mode 100644 drivers/interconnect/qcom/Kconfig
>> create mode 100644 drivers/interconnect/qcom/Makefile
>> create mode 100644 drivers/interconnect/qcom/sdm845.c
>> create mode 100644 include/dt-bindings/interconnect/qcom,sdm845.h
>>
>> ...
>>
>> diff --git a/drivers/interconnect/qcom/sdm845.c b/drivers/interconnect/qcom/sdm845.c
>> new file mode 100644
>> index 000000000000..f594dd6f500f
>> --- /dev/null
>> +++ b/drivers/interconnect/qcom/sdm845.c
>>
>> ...
>>
>> +static int qcom_icc_bcm_init(struct qcom_icc_bcm *bcm, struct device *dev)
>> +{
>> + struct qcom_icc_node *qn;
>> + int ret, i;
>> +
>> + bcm->addr = cmd_db_read_addr(bcm->name);
>> + if (!bcm->addr) {
>> + dev_err(dev, "%s could not find RPMh address\n",
>> + bcm->name);
>> + return -EINVAL;
>> + }
>> +
>> + if (cmd_db_read_aux_data_len(bcm->name) < sizeof(struct bcm_db)) {
>> + dev_err(dev, "%s command db missing or partial aux data\n",
>> + bcm->name);
>> + return -EINVAL;
>> + }
>
> cmd_db_read_aux_data_len() is in the process of being removed, see
> ed3cafa79ea7 ("soc: qcom: cmd-db: Stop memcpy()ing in
> cmd_db_read_aux_data()") in arm-soc/for-next
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/commit/?h=for-next&id=ed3cafa79ea756be653d22087c017af95ea78a49
Yes, exactly. I have a fix that lives as a separate patch [8/8] and will squash it here.
BR,
Georgi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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