* Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Aleksa Sarai @ 2019-09-05 19:56 UTC (permalink / raw)
To: Al Viro
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Christian Brauner, Shuah Khan, linux-arch, linux-s390,
Tycho Andersen, Aleksa Sarai, Jiri Olsa, Alexander Shishkin,
Ingo Molnar, linux-arm-kernel, linux-mips, linux-xtensa,
Kees Cook, Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, linux-api,
Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
containers
In-Reply-To: <20190905182801.GR1131@ZenIV.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1283 bytes --]
On 2019-09-05, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Thu, Sep 05, 2019 at 08:23:03PM +0200, Christian Brauner wrote:
>
> > Because every caller of that function right now has that limit set
> > anyway iirc. So we can either remove it from here and place it back for
> > the individual callers or leave it in the helper.
> > Also, I'm really asking, why not? Is it unreasonable to have an upper
> > bound on the size (for a long time probably) or are you disagreeing with
> > PAGE_SIZE being used? PAGE_SIZE limit is currently used by sched, perf,
> > bpf, and clone3 and in a few other places.
>
> For a primitive that can be safely used with any size (OK, any within
> the usual 2Gb limit)? Why push the random policy into the place where
> it doesn't belong?
>
> Seriously, what's the point? If they want to have a large chunk of
> userland memory zeroed or checked for non-zeroes - why would that
> be a problem?
Thinking about it some more, there isn't really any r/w amplification --
so there isn't much to gain by passing giant structs. Though, if we are
going to permit 2GB buffers, isn't that also an argument to use
memchr_inv()? :P
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 4/4] arm64: dts: add support for A1 based Amlogic AD401
From: Martin Blumenstingl @ 2019-09-05 20:15 UTC (permalink / raw)
To: Jianxin Pan
Cc: devicetree, Hanjie Lin, Victor Wan, Neil Armstrong, Kevin Hilman,
linux-kernel, Qiufang Dai, Rob Herring, Jian Hu, Xingyu Chen,
Tao Zeng, Carlo Caione, linux-amlogic, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <1567667251-33466-5-git-send-email-jianxin.pan@amlogic.com>
Hi Jianxin,
(it's great to see that you and your team are upstreaming this early)
On Thu, Sep 5, 2019 at 9:08 AM Jianxin Pan <jianxin.pan@amlogic.com> wrote:
[...]
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x8000000>;
> + /*linux,usable-memory = <0x0 0x0 0x0 0x8000000>;*/
why do we need that comment here (I don't understand it - why doesn't
the "reg" property cover this)?
> + };
> +};
> +
> +&uart_AO_B {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
> new file mode 100644
> index 00000000..4d476ac
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
> @@ -0,0 +1,122 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
> + */
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + compatible = "amlogic,a1";
> +
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <0x2>;
> + #size-cells = <0x0>;
only now I notice that all our other .dtsi also use hex values
(instead of decimal as just a few lines above) here
do you know if there is a particular reason for this?
[...]
> + uart_AO_B: serial@fe002000 {
> + compatible = "amlogic,meson-gx-uart",
> + "amlogic,meson-ao-uart";
> + reg = <0x0 0xfe002000 0x0 0x18>;
the indentation of the "reg" property is off here
also I'm a bit surprised to see no busses (like aobus, cbus, periphs, ...) here
aren't there any busses defined in the A1 SoC implementation or are
were you planning to add them later?
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] i2c: uniphier(-f): use devm_platform_ioremap_resource()
From: Wolfram Sang @ 2019-09-05 20:34 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: Wolfram Sang, linux-i2c, linux-arm-kernel, linux-kernel
In-Reply-To: <20190905034533.9842-1-yamada.masahiro@socionext.com>
[-- Attachment #1.1: Type: text/plain, Size: 397 bytes --]
On Thu, Sep 05, 2019 at 12:45:32PM +0900, Masahiro Yamada wrote:
> Replace the chain of platform_get_resource() and devm_ioremap_resource()
> with devm_platform_ioremap_resource().
>
> This allows to remove the local variable for (struct resource *), and
> have one function call less.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied to for-next, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] i2c: uniphier(-f): remove all dev_dbg()
From: Wolfram Sang @ 2019-09-05 20:35 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: Wolfram Sang, linux-i2c, linux-arm-kernel, linux-kernel
In-Reply-To: <20190905044648.7632-1-yamada.masahiro@socionext.com>
[-- Attachment #1.1: Type: text/plain, Size: 445 bytes --]
On Thu, Sep 05, 2019 at 01:46:48PM +0900, Masahiro Yamada wrote:
> I have fixed various bugs, and these drivers are (I hope) pretty
> stable now. Remove all dev_dbg() for code clean-up.
>
> If I end up with debugging the drivers again, I will locally revert
> this commit. I no longer need the debug code in upstream.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Yay, tasty one! Applied to for-next, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
From: Qian Cai @ 2019-09-05 21:08 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Peter Zijlstra, linux-kernel, linux-mm, Waiman Long, Dan Williams,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <1566509603.5576.10.camel@lca.pw>
Another data point is if change CONFIG_DEBUG_OBJECTS_TIMERS from =y to =n, it
will also fix it.
On Thu, 2019-08-22 at 17:33 -0400, Qian Cai wrote:
> https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
>
> Booting an arm64 ThunderX2 server with page_alloc.shuffle=1 [1] +
> CONFIG_PROVE_LOCKING=y results in hanging.
>
> [1] https://lore.kernel.org/linux-mm/154899811208.3165233.17623209031065121886.s
> tgit@dwillia2-desk3.amr.corp.intel.com/
>
> ...
> [ 125.142689][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: option mask 0x2
> [ 125.149687][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: ias 44-bit, oas 44-bit
> (features 0x0000170d)
> [ 125.165198][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: allocated 524288 entries
> for cmdq
> [ 125.239425][ [ 125.251484][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: option
> mask 0x2
> [ 125.258233][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: ias 44-bit, oas 44-bit
> (features 0x0000170d)
> [ 125.282750][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: allocated 524288 entries
> for cmdq
> [ 125.320097][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: allocated 524288 entries
> for evtq
> [ 125.332667][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: option mask 0x2
> [ 125.339427][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas 44-bit
> (features 0x0000170d)
> [ 125.354846][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries
> for cmdq
> [ 125.375295][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries
> for evtq
> [ 125.387371][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2
> [ 125.393955][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas 44-bit
> (features 0x0000170d)
> [ 125.522605][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries
> for cmdq
> [ 125.543338][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries
> for evtq
> [ 126.694742][ T1] EFI Variables Facility v0.08 2004-May-17
> [ 126.799291][ T1] NET: Registered protocol family 17
> [ 126.978632][ T1] zswap: loaded using pool lzo/zbud
> [ 126.989168][ T1] kmemleak: Kernel memory leak detector initialized
> [ 126.989191][ T1577] kmemleak: Automatic memory scanning thread started
> [ 127.044079][ T1335] pcieport 0000:0f:00.0: Adding to iommu group 0
> [ 127.388074][ T1] Freeing unused kernel memory: 22528K
> [ 133.527005][ T1] Checked W+X mappings: passed, no W+X pages found
> [ 133.533474][ T1] Run /init as init process
> [ 133.727196][ T1] systemd[1]: System time before build time, advancing
> clock.
> [ 134.576021][ T1587] modprobe (1587) used greatest stack depth: 27056 bytes
> left
> [ 134.764026][ T1] systemd[1]: systemd 239 running in system mode. (+PAM
> +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT
> +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-
> hierarchy=legacy)
> [ 134.799044][ T1] systemd[1]: Detected architecture arm64.
> [ 134.804818][ T1] systemd[1]: Running in initial RAM disk.
> <...hang...>
>
> Fix it by either set page_alloc.shuffle=0 or CONFIG_PROVE_LOCKING=n which allow
> it to continue successfully.
>
>
> [ 121.093846][ T1] systemd[1]: Set hostname to <hpe-apollo-cn99xx>.
> [ 123.157524][ T1] random: systemd: uninitialized urandom read (16 bytes
> read)
> [ 123.168562][ T1] systemd[1]: Listening on Journal Socket.
> [ OK ] Listening on Journal Socket.
> [ 123.203932][ T1] random: systemd: uninitialized urandom read (16 bytes
> read)
> [ 123.212813][ T1] systemd[1]: Listening on udev Kernel Socket.
> [ OK ] Listening on udev Kernel Socket.
> ...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] bus: ti-sysc: Fix handling of invalid clocks
From: Tony Lindgren @ 2019-09-05 21:53 UTC (permalink / raw)
To: linux-omap
Cc: Nishanth Menon, Tero Kristo, Dave Gerlach, Keerthy, linux-kernel,
Andrew F . Davis, Peter Ujfalusi, Faiz Abbas, Greg Kroah-Hartman,
linux-arm-kernel, Roger Quadros
We can currently get "Unable to handle kernel paging request at
virtual address" for invalid clocks with dts node but no driver:
(__clk_get_hw) from [<c0138ebc>] (ti_sysc_find_one_clockdomain+0x18/0x34)
(ti_sysc_find_one_clockdomain) from [<c0138f0c>] (ti_sysc_clkdm_init+0x34/0xdc)
(ti_sysc_clkdm_init) from [<c0584660>] (sysc_probe+0xa50/0x10e8)
(sysc_probe) from [<c065c6ac>] (platform_drv_probe+0x58/0xa8)
Let's add IS_ERR checks to ti_sysc_clkdm_init() as And let's start treating
clk_get() with -ENOENT as a proper error. If the clock name is specified
in device tree we must succeed with clk_get() to continue. For modules with
no clock names specified in device tree we will just ignore the clocks.
Fixes: 2b2f7def058a ("bus: ti-sysc: Add support for missing clockdomain handling")
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/pdata-quirks.c | 4 ++--
drivers/bus/ti-sysc.c | 5 +----
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -491,11 +491,11 @@ static int ti_sysc_clkdm_init(struct device *dev,
struct clk *fck, struct clk *ick,
struct ti_sysc_cookie *cookie)
{
- if (fck)
+ if (!IS_ERR(fck))
cookie->clkdm = ti_sysc_find_one_clockdomain(fck);
if (cookie->clkdm)
return 0;
- if (ick)
+ if (!IS_ERR(ick))
cookie->clkdm = ti_sysc_find_one_clockdomain(ick);
if (cookie->clkdm)
return 0;
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -280,9 +280,6 @@ static int sysc_get_one_clock(struct sysc *ddata, const char *name)
ddata->clocks[index] = devm_clk_get(ddata->dev, name);
if (IS_ERR(ddata->clocks[index])) {
- if (PTR_ERR(ddata->clocks[index]) == -ENOENT)
- return 0;
-
dev_err(ddata->dev, "clock get error for %s: %li\n",
name, PTR_ERR(ddata->clocks[index]));
@@ -357,7 +354,7 @@ static int sysc_get_clocks(struct sysc *ddata)
continue;
error = sysc_get_one_clock(ddata, name);
- if (error && error != -ENOENT)
+ if (error)
return error;
}
--
2.23.0
_______________________________________________
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 v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Al Viro @ 2019-09-05 22:31 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Christian Brauner, Shuah Khan, linux-arch, linux-s390,
Tycho Andersen, Aleksa Sarai, Jiri Olsa, Alexander Shishkin,
Ingo Molnar, linux-arm-kernel, linux-mips, linux-xtensa,
Kees Cook, Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, linux-api,
Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
containers
In-Reply-To: <20190905195618.pwzgvuzadkfpznfz@yavin.dot.cyphar.com>
On Fri, Sep 06, 2019 at 05:56:18AM +1000, Aleksa Sarai wrote:
> On 2019-09-05, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Thu, Sep 05, 2019 at 08:23:03PM +0200, Christian Brauner wrote:
> >
> > > Because every caller of that function right now has that limit set
> > > anyway iirc. So we can either remove it from here and place it back for
> > > the individual callers or leave it in the helper.
> > > Also, I'm really asking, why not? Is it unreasonable to have an upper
> > > bound on the size (for a long time probably) or are you disagreeing with
> > > PAGE_SIZE being used? PAGE_SIZE limit is currently used by sched, perf,
> > > bpf, and clone3 and in a few other places.
> >
> > For a primitive that can be safely used with any size (OK, any within
> > the usual 2Gb limit)? Why push the random policy into the place where
> > it doesn't belong?
> >
> > Seriously, what's the point? If they want to have a large chunk of
> > userland memory zeroed or checked for non-zeroes - why would that
> > be a problem?
>
> Thinking about it some more, there isn't really any r/w amplification --
> so there isn't much to gain by passing giant structs. Though, if we are
> going to permit 2GB buffers, isn't that also an argument to use
> memchr_inv()? :P
I'm not sure I understand the last bit. If you look at what copy_from_user()
does on misaligned source/destination, especially on architectures that
really, really do not like unaligned access...
Case in point: alpha (and it's not unusual in that respect). What it boils
down to is
copy bytes until the destination is aligned
if source and destination are both aligned
copy word by word
else
read word by word, storing the mix of two adjacent words
copy the rest byte by byte
The unpleasant case (to and from having different remainders modulo 8) is
basically
if (count >= 8) {
u64 *aligned = (u64 *)(from & ~7);
u64 *dest = (u64 *)to;
int bitshift = (from & 7) * 8;
u64 prev, next;
prev = aligned[0];
do {
next = aligned[1];
prev <<= bitshift;
prev |= next >> (64 - bitshift);
*dest++ = prev;
aligned++;
prev = next;
from += 8;
to += 8;
count -= 8;
} while (count >= 8);
}
Now, mix that with "... and do memchr_inv() on the copy to find if we'd
copied any non-zeroes, nevermind where" and it starts looking really
ridiculous.
We should just read the fscking source, aligned down to word boundary
and check each word being read. The first and the last ones - masked.
All there is to it. On almost all architectures that'll work well
enough; s390 might want something more elaborate (there even word-by-word
copies are costly, but I'd suggest talking to them for details).
Something like bool all_zeroes_user(const void __user *p, size_t count)
would probably be a sane API...
_______________________________________________
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 1/2] drm/mediatek: Support CMDQ interface in ddp component
From: Nicolas Boichat @ 2019-09-05 22:49 UTC (permalink / raw)
To: Bibby Hsieh
Cc: Yongqiang Niu, David Airlie, Daniel Vetter, lkml, dri-devel,
Tomasz Figa, YT Shen, CK Hu, Thierry Reding,
moderated list:ARM/Mediatek SoC support, Philipp Zabel,
Matthias Brugger, Guenter Roeck, linux-arm Mailing List
In-Reply-To: <20190830074103.16671-2-bibby.hsieh@mediatek.com>
On Fri, Aug 30, 2019 at 3:41 PM Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
>
> The CMDQ (Command Queue) in MT8183 is used to help
> update all relevant display controller registers
> with critical time limation.
> This patch add cmdq interface in ddp_comp interface,
> let all ddp_comp interface can support cpu/cmdq function
> at the same time.
>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> Signed-off-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> --- [snip]
> static void mtk_gamma_set(struct mtk_ddp_comp *comp,
> - struct drm_crtc_state *state)
> + struct drm_crtc_state *state,
> + struct cmdq_pkt *cmdq_pkt)
> {
> - unsigned int i, reg;
> + unsigned int i;
> struct drm_color_lut *lut;
> void __iomem *lut_base;
> u32 word;
>
> if (state->gamma_lut) {
> - reg = readl(comp->regs + DISP_GAMMA_CFG);
> - reg = reg | GAMMA_LUT_EN;
> - writel(reg, comp->regs + DISP_GAMMA_CFG);
> + mtk_ddp_write_mask(cmdq_pkt, GAMMA_LUT_EN, comp,
> + DISP_GAMMA_CFG, GAMMA_LUT_EN);
> lut_base = comp->regs + DISP_GAMMA_LUT;
> lut = (struct drm_color_lut *)state->gamma_lut->data;
> for (i = 0; i < MTK_LUT_SIZE; i++) {
> word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
> (((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
> ((lut[i].blue >> 6) & LUT_10BIT_MASK);
> - writel(word, (lut_base + i * 4));
> + mtk_ddp_write(cmdq_pkt, word, comp,
> + (unsigned int)(lut_base + i * 4));
Guenter pointed out that this looks quite wrong. We should have:
unsigned int lut_base;
lut_base = DISP_GAMMA_LUT;
mtk_ddp_write(cmdq_pkt, word, comp, lut_base + i * 4);
Or more simply:
mtk_ddp_write(cmdq_pkt, word, comp, DISP_GAMMA_LUT + i * 4);
> }
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver
From: Nicolas Boichat @ 2019-09-05 22:58 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, devicetree, srv_heupstream, shengnan.wang,
Tomasz Figa, Louis Kuo, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <20190905160512.GG5475@paasikivi.fi.intel.com>
On Fri, Sep 6, 2019 at 12:05 AM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> On Thu, Sep 05, 2019 at 07:53:37PM +0900, Tomasz Figa wrote:
> > On Thu, Sep 5, 2019 at 7:45 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:
> > >
> > > Hi Dongchun,
> > >
> > > On Thu, Sep 05, 2019 at 05:41:05PM +0800, Dongchun Zhu wrote:
> > >
> > > ...
> > >
> > > > > > + ret = regulator_bulk_enable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
> > > > > > + if (ret < 0) {
> > > > > > + dev_err(dev, "Failed to enable regulators\n");
> > > > > > + goto disable_clk;
> > > > > > + }
> > > > > > + msleep_range(7);
> > > > >
> > > > > This has some potential of clashing with more generic functions in the
> > > > > future. Please use usleep_range directly, or msleep.
> > > > >
> > > >
> > > > Did you mean using usleep_range(7*1000, 8*1000), as used in patch v1?
> > > > https://patchwork.kernel.org/patch/10957225/
> > >
> > > Yes, please.
> >
> > Why not just msleep()?
>
> msleep() is usually less accurate. I'm not sure it makes a big different in
> this case. Perhaps, if someone wants that the sensor is powered on and
> streaming as soon as possible.
https://elixir.bootlin.com/linux/latest/source/Documentation/timers/timers-howto.txt#L70
Use usleep_range for delays up to 20ms (at least that's what the
documentation (still) says?)
> --
> Sakari Ailus
> sakari.ailus@linux.intel.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 v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Aleksa Sarai @ 2019-09-05 23:00 UTC (permalink / raw)
To: Al Viro
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Jiri Olsa, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Shuah Khan, Alexander Shishkin, Ingo Molnar,
linux-arm-kernel, linux-mips, linux-xtensa, Kees Cook,
Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, linux-api,
Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
containers
In-Reply-To: <20190905180750.GQ1131@ZenIV.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 3988 bytes --]
On 2019-09-05, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> > +/*
> > + * "memset(p, 0, size)" but for user space buffers. Caller must have already
> > + * checked access_ok(p, size).
> > + */
> > +static int __memzero_user(void __user *p, size_t s)
> > +{
> > + const char zeros[BUFFER_SIZE] = {};
> > + while (s > 0) {
> > + size_t n = min(s, sizeof(zeros));
> > +
> > + if (__copy_to_user(p, zeros, n))
> > + return -EFAULT;
> > +
> > + p += n;
> > + s -= n;
> > + }
> > + return 0;
> > +}
>
> That's called clear_user().
Already switched, I didn't know about clear_user() -- I assumed it
would've been called bzero_user() or memzero_user() and didn't find it
when looking.
> > +int copy_struct_to_user(void __user *dst, size_t usize,
> > + const void *src, size_t ksize)
> > +{
> > + size_t size = min(ksize, usize);
> > + size_t rest = abs(ksize - usize);
> > +
> > + if (unlikely(usize > PAGE_SIZE))
> > + return -EFAULT;
>
> Why?
>
> > + } else if (usize > ksize) {
> > + if (__memzero_user(dst + size, rest))
> > + return -EFAULT;
> > + }
> > + /* Copy the interoperable parts of the struct. */
> > + if (__copy_to_user(dst, src, size))
> > + return -EFAULT;
>
> Why not simply clear_user() and copy_to_user()?
I'm not sure I understand what you mean -- are you asking why we need to
do memchr_inv(src + size, 0, rest) earlier?
>
> > +int copy_struct_from_user(void *dst, size_t ksize,
> > + const void __user *src, size_t usize)
> > +{
> > + size_t size = min(ksize, usize);
> > + size_t rest = abs(ksize - usize);
>
> Cute, but... you would be just as well without that 'rest' thing.
I would argue it's harder to mess up using "rest" compared to getting
"ksize - usize" and "usize - ksize" mixed up (and it's a bit more
readable).
> > +
> > + if (unlikely(usize > PAGE_SIZE))
> > + return -EFAULT;
>
> Again, why?
As discussed in a sister thread, I will leave this in the callers
(though I would argue callers should always do some kind of sanity check
like this).
>
> > + if (unlikely(!access_ok(src, usize)))
> > + return -EFAULT;
>
> Why not simply copy_from_user() here?
>
> > + /* Deal with trailing bytes. */
> > + if (usize < ksize)
> > + memset(dst + size, 0, rest);
> > + else if (usize > ksize) {
> > + const void __user *addr = src + size;
> > + char buffer[BUFFER_SIZE] = {};
> > +
> > + while (rest > 0) {
> > + size_t bufsize = min(rest, sizeof(buffer));
> > +
> > + if (__copy_from_user(buffer, addr, bufsize))
> > + return -EFAULT;
> > + if (memchr_inv(buffer, 0, bufsize))
> > + return -E2BIG;
>
> Frankly, that looks like a candidate for is_all_zeroes_user().
> With the loop like above serving as a dumb default. And on
> badly alighed address it _will_ be dumb. Probably too much
> so - something like
> if ((unsigned long)addr & 1) {
> u8 v;
> if (get_user(v, (__u8 __user *)addr))
> return -EFAULT;
> if (v)
> return -E2BIG;
> addr++;
> }
> if ((unsigned long)addr & 2) {
> u16 v;
> if (get_user(v, (__u16 __user *)addr))
> return -EFAULT;
> if (v)
> return -E2BIG;
> addr +=2;
> }
> if ((unsigned long)addr & 4) {
> u32 v;
> if (get_user(v, (__u32 __user *)addr))
> return -EFAULT;
> if (v)
> return -E2BIG;
> }
> <read the rest like you currently do>
> would be saner, and things like x86 could trivially add an
> asm variant - it's not hard. Incidentally, memchr_inv() is
> an overkill in this case...
Why is memchr_inv() overkill?
But yes, breaking this out to an asm-generic is_all_zeroes_user()
wouldn't hurt -- and I'll put a cleaned-up version of the alignment
handling there too. Should I drop it in asm-generic/uaccess.h, or
somewhere else?
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] ARM: omap3: Enable HWMODS for HW Random Number Generator
From: Tony Lindgren @ 2019-09-05 23:04 UTC (permalink / raw)
To: Adam Ford
Cc: Mark Rutland, devicetree, Paul Walmsley, aaro.koskinen,
Russell King, linux-kernel, t-kristo, Rob Herring,
Benoît Cousson, pali.rohar, linux-omap, adam.ford,
linux-arm-kernel
In-Reply-To: <20190828150037.2640-1-aford173@gmail.com>
Hi,
* Adam Ford <aford173@gmail.com> [190828 15:01]:
> The datasheet for the AM3517 shows the RNG is connected to L4.
> It shows the module address for the RNG is 0x480A0000, and it
> matches the omap2.dtsi description. Since the driver can support
> omap2 and omap4, it seems reasonable to assume the omap3 would
> use the same core for the RNG.
>
> This RFC, mimics much of the omap2 hwmods on the OMAP3. It
> also adds the necessary clock for driving the RNG. Unfortunately,
> it appears non-functional. If anyone has any suggestions on how
> to finish the hwmod (or port it to the newer l4 device tree
> format), feedback is requested.
Yup I'll take the bait :) The patch below seems to do the trick
for me on dm3730 based on translating your patch to probe with
ti-sysc.
Not sure about 34xx, it seems we're missing rng_clk? Care
to give it a try and attempt simlar patches for 34xx and
3517?
At least I'm not needing the "ti,no-reset-on-init" property
that your patch has a comment for. Maybe that's needed on
some other omap3.
Oh and this needs to default to status = "disabled" for
HS devices like n900 as it needs to use the omap3-rom-rng.
Regards,
Tony
8< -----------------------
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -140,6 +140,29 @@
};
};
+ rng_target: target-module@480a0000 {
+ compatible = "ti,sysc-omap2", "ti,sysc";
+ reg = <0x480a003c 0x4>,
+ <0x480a0040 0x4>,
+ <0x480a0044 0x4>;
+ reg-names = "rev", "sysc", "syss";
+ ti,sysc-mask = <(SYSC_OMAP2_AUTOIDLE)>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>;
+ ti,syss-mask = <1>;
+ clocks = <&rng_ick>;
+ clock-names = "ick";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x480a0000 0x2000>;
+
+ rng: rng@0 {
+ compatible = "ti,omap2-rng";
+ reg = <0x0 0x2000>;
+ interrupts = <52>;
+ };
+ };
+
/*
* Note that the sysconfig register layout is a subset of the
* "ti,sysc-omap4" type register with just sidle and midle bits
_______________________________________________
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 v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Al Viro @ 2019-09-05 23:49 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Jiri Olsa, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Shuah Khan, Alexander Shishkin, Ingo Molnar,
linux-arm-kernel, linux-mips, linux-xtensa, Kees Cook,
Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, linux-api,
Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
containers
In-Reply-To: <20190905230003.bek7vqdvruzi4ybx@yavin.dot.cyphar.com>
On Fri, Sep 06, 2019 at 09:00:03AM +1000, Aleksa Sarai wrote:
> > > + return -EFAULT;
> > > + }
> > > + /* Copy the interoperable parts of the struct. */
> > > + if (__copy_to_user(dst, src, size))
> > > + return -EFAULT;
> >
> > Why not simply clear_user() and copy_to_user()?
>
> I'm not sure I understand what you mean -- are you asking why we need to
> do memchr_inv(src + size, 0, rest) earlier?
I'm asking why bother with __ and separate access_ok().
> > if ((unsigned long)addr & 1) {
> > u8 v;
> > if (get_user(v, (__u8 __user *)addr))
> > return -EFAULT;
> > if (v)
> > return -E2BIG;
> > addr++;
> > }
> > if ((unsigned long)addr & 2) {
> > u16 v;
> > if (get_user(v, (__u16 __user *)addr))
> > return -EFAULT;
> > if (v)
> > return -E2BIG;
> > addr +=2;
> > }
> > if ((unsigned long)addr & 4) {
> > u32 v;
> > if (get_user(v, (__u32 __user *)addr))
> > return -EFAULT;
> > if (v)
> > return -E2BIG;
> > }
> > <read the rest like you currently do>
Actually, this is a dumb way to do it - page size on anything
is going to be a multiple of 8, so you could just as well
read 8 bytes from an address aligned down. Then mask the
bytes you don't want to check out and see if there's anything
left.
You can have readability boundaries inside a page - it's either
the entire page (let alone a single word) being readable, or
it's EFAULT for all parts.
> > would be saner, and things like x86 could trivially add an
> > asm variant - it's not hard. Incidentally, memchr_inv() is
> > an overkill in this case...
>
> Why is memchr_inv() overkill?
Look at its implementation; you only care if there are
non-zeroes, you don't give a damn where in the buffer
the first one would be. All you need is the same logics
as in "from userland" case
if (!count)
return true;
offset = (unsigned long)from & 7
p = (u64 *)(from - offset);
v = *p++;
if (offset) { // unaligned
count += offset;
v &= ~aligned_byte_mask(offset); // see strnlen_user.c
}
while (count > 8) {
if (v)
return false;
v = *p++;
count -= 8;
}
if (count != 8)
v &= aligned_byte_mask(count);
return v == 0;
All there is to it...
_______________________________________________
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 v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Aleksa Sarai @ 2019-09-06 0:09 UTC (permalink / raw)
To: Al Viro
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Jiri Olsa, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Shuah Khan, Alexander Shishkin, Ingo Molnar,
linux-arm-kernel, linux-mips, linux-xtensa, Kees Cook,
Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, linux-api,
Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
containers
In-Reply-To: <20190905234944.GT1131@ZenIV.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 2932 bytes --]
On 2019-09-06, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Sep 06, 2019 at 09:00:03AM +1000, Aleksa Sarai wrote:
> > > > + return -EFAULT;
> > > > + }
> > > > + /* Copy the interoperable parts of the struct. */
> > > > + if (__copy_to_user(dst, src, size))
> > > > + return -EFAULT;
> > >
> > > Why not simply clear_user() and copy_to_user()?
> >
> > I'm not sure I understand what you mean -- are you asking why we need to
> > do memchr_inv(src + size, 0, rest) earlier?
>
> I'm asking why bother with __ and separate access_ok().
Ah right, it was a dumb "optimisation" (since we need to do access_ok()
anyway since we should early -EFAULT in that case). I've dropped the __
usages in my working copy.
> > > if ((unsigned long)addr & 1) {
> > > u8 v;
> > > if (get_user(v, (__u8 __user *)addr))
> > > return -EFAULT;
> > > if (v)
> > > return -E2BIG;
> > > addr++;
> > > }
> > > if ((unsigned long)addr & 2) {
> > > u16 v;
> > > if (get_user(v, (__u16 __user *)addr))
> > > return -EFAULT;
> > > if (v)
> > > return -E2BIG;
> > > addr +=2;
> > > }
> > > if ((unsigned long)addr & 4) {
> > > u32 v;
> > > if (get_user(v, (__u32 __user *)addr))
> > > return -EFAULT;
> > > if (v)
> > > return -E2BIG;
> > > }
> > > <read the rest like you currently do>
>
> Actually, this is a dumb way to do it - page size on anything
> is going to be a multiple of 8, so you could just as well
> read 8 bytes from an address aligned down. Then mask the
> bytes you don't want to check out and see if there's anything
> left.
>
> You can have readability boundaries inside a page - it's either
> the entire page (let alone a single word) being readable, or
> it's EFAULT for all parts.
>
> > > would be saner, and things like x86 could trivially add an
> > > asm variant - it's not hard. Incidentally, memchr_inv() is
> > > an overkill in this case...
> >
> > Why is memchr_inv() overkill?
>
> Look at its implementation; you only care if there are
> non-zeroes, you don't give a damn where in the buffer
> the first one would be. All you need is the same logics
> as in "from userland" case
> if (!count)
> return true;
> offset = (unsigned long)from & 7
> p = (u64 *)(from - offset);
> v = *p++;
> if (offset) { // unaligned
> count += offset;
> v &= ~aligned_byte_mask(offset); // see strnlen_user.c
> }
> while (count > 8) {
> if (v)
> return false;
> v = *p++;
> count -= 8;
> }
> if (count != 8)
> v &= aligned_byte_mask(count);
> return v == 0;
>
> All there is to it...
Alright, will do (for some reason I hadn't made the connection that
memchr_inv() is doing effectively the same word-by-word comparison but
also detecting where the first byte is).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Al Viro @ 2019-09-06 0:14 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Jiri Olsa, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Shuah Khan, Alexander Shishkin, Ingo Molnar,
linux-arm-kernel, linux-mips, linux-xtensa, Kees Cook,
Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, linux-api,
Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
containers
In-Reply-To: <20190905234944.GT1131@ZenIV.linux.org.uk>
On Fri, Sep 06, 2019 at 12:49:44AM +0100, Al Viro wrote:
> On Fri, Sep 06, 2019 at 09:00:03AM +1000, Aleksa Sarai wrote:
> > > > + return -EFAULT;
> > > > + }
> > > > + /* Copy the interoperable parts of the struct. */
> > > > + if (__copy_to_user(dst, src, size))
> > > > + return -EFAULT;
> > >
> > > Why not simply clear_user() and copy_to_user()?
> >
> > I'm not sure I understand what you mean -- are you asking why we need to
> > do memchr_inv(src + size, 0, rest) earlier?
>
> I'm asking why bother with __ and separate access_ok().
>
> > > if ((unsigned long)addr & 1) {
> > > u8 v;
> > > if (get_user(v, (__u8 __user *)addr))
> > > return -EFAULT;
> > > if (v)
> > > return -E2BIG;
> > > addr++;
> > > }
> > > if ((unsigned long)addr & 2) {
> > > u16 v;
> > > if (get_user(v, (__u16 __user *)addr))
> > > return -EFAULT;
> > > if (v)
> > > return -E2BIG;
> > > addr +=2;
> > > }
> > > if ((unsigned long)addr & 4) {
> > > u32 v;
> > > if (get_user(v, (__u32 __user *)addr))
> > > return -EFAULT;
> > > if (v)
> > > return -E2BIG;
> > > }
> > > <read the rest like you currently do>
>
> Actually, this is a dumb way to do it - page size on anything
> is going to be a multiple of 8, so you could just as well
> read 8 bytes from an address aligned down. Then mask the
> bytes you don't want to check out and see if there's anything
> left.
>
> You can have readability boundaries inside a page - it's either
> the entire page (let alone a single word) being readable, or
> it's EFAULT for all parts.
>
> > > would be saner, and things like x86 could trivially add an
> > > asm variant - it's not hard. Incidentally, memchr_inv() is
> > > an overkill in this case...
> >
> > Why is memchr_inv() overkill?
>
> Look at its implementation; you only care if there are
> non-zeroes, you don't give a damn where in the buffer
> the first one would be. All you need is the same logics
> as in "from userland" case
> if (!count)
> return true;
> offset = (unsigned long)from & 7
> p = (u64 *)(from - offset);
> v = *p++;
> if (offset) { // unaligned
> count += offset;
> v &= ~aligned_byte_mask(offset); // see strnlen_user.c
> }
> while (count > 8) {
> if (v)
> return false;
> v = *p++;
> count -= 8;
> }
> if (count != 8)
> v &= aligned_byte_mask(count);
> return v == 0;
>
> All there is to it...
... and __user case would be pretty much this with
if (user_access_begin(from, count)) {
....
user_access_end();
}
wrapped around the damn thing - again, see strnlen_user.c, with
unsafe_get_user(v, p++, efault);
instead of those
v = *p++;
Calling conventions might need some thinking - it might be
* all read, all zeroes
* non-zero found
* read failed
so we probably want to map the "all zeroes" case to 0,
"read failed" to -EFAULT and "non-zero found" to something
else. Might be positive, might be some other -E.... - not
sure if E2BIG (or EFBIG) makes much sense here. Need to
look at the users...
_______________________________________________
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 1/2] clk: imx8mm: Move 1443X/1416X PLL clock structure to common place
From: Anson Huang @ 2019-09-06 1:03 UTC (permalink / raw)
To: Leonard Crestez, Abel Vesa, Jacky Bai
Cc: Aisheng Dong, S.j. Wang, Peng Fan, sfr@canb.auug.org.au,
sboyd@kernel.org, shawnguo@kernel.org, mturquette@baylibre.com,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
dl-linux-imx, kernel@pengutronix.de, Fancy Fang,
festevam@gmail.com, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org, l.stach@pengutronix.de
In-Reply-To: <VI1PR04MB7023460FBB9FB8D034ECC2A1EEBB0@VI1PR04MB7023.eurprd04.prod.outlook.com>
Hi, Leonard
> On 05.09.2019 12:59, Anson Huang wrote:
> > Many i.MX8M SoCs use same 1443X/1416X PLL, such as i.MX8MM,
> i.MX8MN
> > and later i.MX8M SoCs, moving these PLL definitions to common place
> > can save a lot of duplicated code on each platform.
>
> There are lots of similarities between imx8m clocks, do you plan to do
> combine them further?
I will consider it later, maybe we can create a new clock file named clk-imx8m.c
as common clock for i.MX8M SoCs which are similar.
>
> > Meanwhile, no need to define PLL clock structure for every module
> > which uses same type of PLL, e.g., audio/video/dram use 1443X PLL,
> > arm/gpu/vpu/sys use 1416X PLL, define 2 PLL clock structure for each
> > group is enough.
>
> > diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
>
> > +const struct imx_pll14xx_rate_table imx_pll1416x_tbl[] = {
> > + PLL_1416X_RATE(1800000000U, 225, 3, 0),
> > + PLL_1416X_RATE(1600000000U, 200, 3, 0),
> > + PLL_1416X_RATE(1200000000U, 300, 3, 1),
> > + PLL_1416X_RATE(1000000000U, 250, 3, 1),
> > + PLL_1416X_RATE(800000000U, 200, 3, 1),
> > + PLL_1416X_RATE(750000000U, 250, 2, 2),
> > + PLL_1416X_RATE(700000000U, 350, 3, 2),
> > + PLL_1416X_RATE(600000000U, 300, 3, 2), };
> > +
> > +const struct imx_pll14xx_rate_table imx_pll1443x_tbl[] = {
> > + PLL_1443X_RATE(650000000U, 325, 3, 2, 0),
> > + PLL_1443X_RATE(594000000U, 198, 2, 2, 0),
> > + PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
> > + PLL_1443X_RATE(361267200U, 361, 3, 3, 17511), };
> > +
> > +struct imx_pll14xx_clk imx_1443x_pll = {
> > + .type = PLL_1443X,
> > + .rate_table = imx_pll1443x_tbl,
> > + .rate_count = ARRAY_SIZE(imx_pll1443x_tbl), };
> > +
> > +struct imx_pll14xx_clk imx_1416x_pll = {
> > + .type = PLL_1416X,
> > + .rate_table = imx_pll1416x_tbl,
> > + .rate_count = ARRAY_SIZE(imx_pll1416x_tbl), };
>
> Perhaps these consts should be in clk-pll14xx.c? That way they won't be
> compiled for imx6 as well.
Make sense, I will do it in V2.
Thanks,
Anson
_______________________________________________
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 2/2] ARM: exynos: Enable support for ARM architected timers
From: Chanwoo Choi @ 2019-09-06 1:10 UTC (permalink / raw)
To: Marek Szyprowski, linux-samsung-soc, linux-arm-kernel
Cc: Marc Zyngier, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <20190828121005.29368-3-m.szyprowski@samsung.com>
Dear Marek,
On 19. 8. 28. 오후 9:10, Marek Szyprowski wrote:
> ARM architected timer can be used together with Exynos MultiCore Timer
> driver, so enable support for it. Support for ARM architected timers is
> essential for enabling proper KVM support.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mach-exynos/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index f83786640f94..9dab1f50a02f 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -19,6 +19,7 @@ menuconfig ARCH_EXYNOS
> select EXYNOS_SROM
> select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
> select GPIOLIB
> + select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5 && VIRTUALIZATION
> select HAVE_ARM_SCU if SMP
> select HAVE_S3C2410_I2C if I2C
> select HAVE_S3C2410_WATCHDOG if WATCHDOG
>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
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/2] ARM: dts: exynos: Add support ARM architected timers on Exynos5
From: Chanwoo Choi @ 2019-09-06 1:14 UTC (permalink / raw)
To: Marek Szyprowski, linux-samsung-soc, linux-arm-kernel
Cc: Marc Zyngier, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <20190828121005.29368-2-m.szyprowski@samsung.com>
Dear Marek,
On 19. 8. 28. 오후 9:10, Marek Szyprowski wrote:
> All CortexA7/A15 based Exynos5 SoCs have ARM architected timers, so enable
> support for them directly in the base dtsi. None of the known firmware
> properly configures CNTFRQ arch timer register, so force clock frequency
> to 24MHz, which is the only configuration supported by the remaining
> clock drivers so far.
>
> Stock firmware for Peach Pit and Pi Chromebooks also doesn't reset
> properly other arch timer registers, so add respective properties
> indicating that. Other Exynos5-based boards behaves correctly in this area,
> what finally allows to enable support for KVM-based virtualization.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 ++++
> arch/arm/boot/dts/exynos54xx.dtsi | 9 +++++++++
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> 3 files changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index f78db6809cca..77e08a4c7300 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -1064,6 +1064,10 @@
> status = "okay";
> };
>
> +&timer {
> + arm,cpu-registers-not-fw-configured;
> +};
> +
> &tmu_cpu0 {
> vtmu-supply = <&ldo10_reg>;
> };
> diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi
> index 9c3b63b7cac6..02d34957cd83 100644
> --- a/arch/arm/boot/dts/exynos54xx.dtsi
> +++ b/arch/arm/boot/dts/exynos54xx.dtsi
> @@ -45,6 +45,15 @@
> status = "disabled";
> };
>
> + timer: timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> + clock-frequency = <24000000>;
> + };
> +
> soc: soc {
> sysram@2020000 {
> compatible = "mmio-sram";
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index e0f470fe54c8..5e8cec736444 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -1033,6 +1033,10 @@
> status = "okay";
> };
>
> +&timer {
> + arm,cpu-registers-not-fw-configured;
> +};
> +
> &tmu_cpu0 {
> vtmu-supply = <&ldo10_reg>;
> };
>
I tested it on odroid-xu3 to enable arch-timer for KVM.
In result, I could just initialize KVM on xu3 without problem.
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver
From: Dongchun Zhu @ 2019-09-06 1:33 UTC (permalink / raw)
To: Nicolas Boichat
Cc: Mark Rutland, devicetree, srv_heupstream, shengnan.wang,
Tomasz Figa, Louis Kuo, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Sakari Ailus,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <CANMq1KDVMGkeBvu1nO5WHopWwec9mxHfhmLmX2BzvaYVLzxoXw@mail.gmail.com>
On Fri, 2019-09-06 at 06:58 +0800, Nicolas Boichat wrote:
> On Fri, Sep 6, 2019 at 12:05 AM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > On Thu, Sep 05, 2019 at 07:53:37PM +0900, Tomasz Figa wrote:
> > > On Thu, Sep 5, 2019 at 7:45 PM Sakari Ailus
> > > <sakari.ailus@linux.intel.com> wrote:
> > > >
> > > > Hi Dongchun,
> > > >
> > > > On Thu, Sep 05, 2019 at 05:41:05PM +0800, Dongchun Zhu wrote:
> > > >
> > > > ...
> > > >
> > > > > > > + ret = regulator_bulk_enable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
> > > > > > > + if (ret < 0) {
> > > > > > > + dev_err(dev, "Failed to enable regulators\n");
> > > > > > > + goto disable_clk;
> > > > > > > + }
> > > > > > > + msleep_range(7);
> > > > > >
> > > > > > This has some potential of clashing with more generic functions in the
> > > > > > future. Please use usleep_range directly, or msleep.
> > > > > >
> > > > >
> > > > > Did you mean using usleep_range(7*1000, 8*1000), as used in patch v1?
> > > > > https://patchwork.kernel.org/patch/10957225/
> > > >
> > > > Yes, please.
> > >
> > > Why not just msleep()?
> >
> > msleep() is usually less accurate. I'm not sure it makes a big different in
> > this case. Perhaps, if someone wants that the sensor is powered on and
> > streaming as soon as possible.
>
> https://elixir.bootlin.com/linux/latest/source/Documentation/timers/timers-howto.txt#L70
>
> Use usleep_range for delays up to 20ms (at least that's what the
> documentation (still) says?)
>
Thank you for your clarifications.
From the doc,
"msleep(1~20) may not do what the caller intends, and
will often sleep longer (~20 ms actual sleep for any
value given in the 1~20ms range). In many cases this
is not the desired behavior."
So, it is supposed to use usleep_range in shorter sleep case,
such as 5ms.
> > --
> > Sakari Ailus
> > sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2 1/2] clk: imx8mm: Move 1443X/1416X PLL clock structure to common place
From: Anson Huang @ 2019-09-06 13:34 UTC (permalink / raw)
To: mturquette, sboyd, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, abel.vesa, peng.fan, ping.bai, chen.fang,
shengjiu.wang, aisheng.dong, sfr, l.stach, linux-clk,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
Many i.MX8M SoCs use same 1443X/1416X PLL, such as i.MX8MM,
i.MX8MN and later i.MX8M SoCs, moving these PLL definitions
to pll14xx driver can save a lot of duplicated code on each
platform.
Meanwhile, no need to define PLL clock structure for every
module which uses same type of PLL, e.g., audio/video/dram use
1443X PLL, arm/gpu/vpu/sys use 1416X PLL, define 2 PLL clock
structure for each group is enough.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V1:
- Move 1443X/1416X PLL clock table/structure to pll14xx driver.
---
drivers/clk/imx/clk-imx8mm.c | 87 +++++--------------------------------------
drivers/clk/imx/clk-pll14xx.c | 30 +++++++++++++++
drivers/clk/imx/clk.h | 3 ++
3 files changed, 43 insertions(+), 77 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 2758e3f..9649250 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -26,73 +26,6 @@ static u32 share_count_disp;
static u32 share_count_pdm;
static u32 share_count_nand;
-static const struct imx_pll14xx_rate_table imx8mm_pll1416x_tbl[] = {
- PLL_1416X_RATE(1800000000U, 225, 3, 0),
- PLL_1416X_RATE(1600000000U, 200, 3, 0),
- PLL_1416X_RATE(1200000000U, 300, 3, 1),
- PLL_1416X_RATE(1000000000U, 250, 3, 1),
- PLL_1416X_RATE(800000000U, 200, 3, 1),
- PLL_1416X_RATE(750000000U, 250, 2, 2),
- PLL_1416X_RATE(700000000U, 350, 3, 2),
- PLL_1416X_RATE(600000000U, 300, 3, 2),
-};
-
-static const struct imx_pll14xx_rate_table imx8mm_audiopll_tbl[] = {
- PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
- PLL_1443X_RATE(361267200U, 361, 3, 3, 17511),
-};
-
-static const struct imx_pll14xx_rate_table imx8mm_videopll_tbl[] = {
- PLL_1443X_RATE(650000000U, 325, 3, 2, 0),
- PLL_1443X_RATE(594000000U, 198, 2, 2, 0),
-};
-
-static const struct imx_pll14xx_rate_table imx8mm_drampll_tbl[] = {
- PLL_1443X_RATE(650000000U, 325, 3, 2, 0),
-};
-
-static struct imx_pll14xx_clk imx8mm_audio_pll = {
- .type = PLL_1443X,
- .rate_table = imx8mm_audiopll_tbl,
- .rate_count = ARRAY_SIZE(imx8mm_audiopll_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mm_video_pll = {
- .type = PLL_1443X,
- .rate_table = imx8mm_videopll_tbl,
- .rate_count = ARRAY_SIZE(imx8mm_videopll_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mm_dram_pll = {
- .type = PLL_1443X,
- .rate_table = imx8mm_drampll_tbl,
- .rate_count = ARRAY_SIZE(imx8mm_drampll_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mm_arm_pll = {
- .type = PLL_1416X,
- .rate_table = imx8mm_pll1416x_tbl,
- .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mm_gpu_pll = {
- .type = PLL_1416X,
- .rate_table = imx8mm_pll1416x_tbl,
- .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mm_vpu_pll = {
- .type = PLL_1416X,
- .rate_table = imx8mm_pll1416x_tbl,
- .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mm_sys_pll = {
- .type = PLL_1416X,
- .rate_table = imx8mm_pll1416x_tbl,
- .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl),
-};
-
static const char *pll_ref_sels[] = { "osc_24m", "dummy", "dummy", "dummy", };
static const char *audio_pll1_bypass_sels[] = {"audio_pll1", "audio_pll1_ref_sel", };
static const char *audio_pll2_bypass_sels[] = {"audio_pll2", "audio_pll2_ref_sel", };
@@ -396,16 +329,16 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
clks[IMX8MM_SYS_PLL2_REF_SEL] = imx_clk_mux("sys_pll2_ref_sel", base + 0x104, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
clks[IMX8MM_SYS_PLL3_REF_SEL] = imx_clk_mux("sys_pll3_ref_sel", base + 0x114, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
- clks[IMX8MM_AUDIO_PLL1] = imx_clk_pll14xx("audio_pll1", "audio_pll1_ref_sel", base, &imx8mm_audio_pll);
- clks[IMX8MM_AUDIO_PLL2] = imx_clk_pll14xx("audio_pll2", "audio_pll2_ref_sel", base + 0x14, &imx8mm_audio_pll);
- clks[IMX8MM_VIDEO_PLL1] = imx_clk_pll14xx("video_pll1", "video_pll1_ref_sel", base + 0x28, &imx8mm_video_pll);
- clks[IMX8MM_DRAM_PLL] = imx_clk_pll14xx("dram_pll", "dram_pll_ref_sel", base + 0x50, &imx8mm_dram_pll);
- clks[IMX8MM_GPU_PLL] = imx_clk_pll14xx("gpu_pll", "gpu_pll_ref_sel", base + 0x64, &imx8mm_gpu_pll);
- clks[IMX8MM_VPU_PLL] = imx_clk_pll14xx("vpu_pll", "vpu_pll_ref_sel", base + 0x74, &imx8mm_vpu_pll);
- clks[IMX8MM_ARM_PLL] = imx_clk_pll14xx("arm_pll", "arm_pll_ref_sel", base + 0x84, &imx8mm_arm_pll);
- clks[IMX8MM_SYS_PLL1] = imx_clk_pll14xx("sys_pll1", "sys_pll1_ref_sel", base + 0x94, &imx8mm_sys_pll);
- clks[IMX8MM_SYS_PLL2] = imx_clk_pll14xx("sys_pll2", "sys_pll2_ref_sel", base + 0x104, &imx8mm_sys_pll);
- clks[IMX8MM_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel", base + 0x114, &imx8mm_sys_pll);
+ clks[IMX8MM_AUDIO_PLL1] = imx_clk_pll14xx("audio_pll1", "audio_pll1_ref_sel", base, &imx_1443x_pll);
+ clks[IMX8MM_AUDIO_PLL2] = imx_clk_pll14xx("audio_pll2", "audio_pll2_ref_sel", base + 0x14, &imx_1443x_pll);
+ clks[IMX8MM_VIDEO_PLL1] = imx_clk_pll14xx("video_pll1", "video_pll1_ref_sel", base + 0x28, &imx_1443x_pll);
+ clks[IMX8MM_DRAM_PLL] = imx_clk_pll14xx("dram_pll", "dram_pll_ref_sel", base + 0x50, &imx_1443x_pll);
+ clks[IMX8MM_GPU_PLL] = imx_clk_pll14xx("gpu_pll", "gpu_pll_ref_sel", base + 0x64, &imx_1416x_pll);
+ clks[IMX8MM_VPU_PLL] = imx_clk_pll14xx("vpu_pll", "vpu_pll_ref_sel", base + 0x74, &imx_1416x_pll);
+ clks[IMX8MM_ARM_PLL] = imx_clk_pll14xx("arm_pll", "arm_pll_ref_sel", base + 0x84, &imx_1416x_pll);
+ clks[IMX8MM_SYS_PLL1] = imx_clk_pll14xx("sys_pll1", "sys_pll1_ref_sel", base + 0x94, &imx_1416x_pll);
+ clks[IMX8MM_SYS_PLL2] = imx_clk_pll14xx("sys_pll2", "sys_pll2_ref_sel", base + 0x104, &imx_1416x_pll);
+ clks[IMX8MM_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel", base + 0x114, &imx_1416x_pll);
/* PLL bypass out */
clks[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass", base, 4, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), CLK_SET_RATE_PARENT);
diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index b721302..4a61743 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -41,6 +41,36 @@ struct clk_pll14xx {
#define to_clk_pll14xx(_hw) container_of(_hw, struct clk_pll14xx, hw)
+const struct imx_pll14xx_rate_table imx_pll1416x_tbl[] = {
+ PLL_1416X_RATE(1800000000U, 225, 3, 0),
+ PLL_1416X_RATE(1600000000U, 200, 3, 0),
+ PLL_1416X_RATE(1200000000U, 300, 3, 1),
+ PLL_1416X_RATE(1000000000U, 250, 3, 1),
+ PLL_1416X_RATE(800000000U, 200, 3, 1),
+ PLL_1416X_RATE(750000000U, 250, 2, 2),
+ PLL_1416X_RATE(700000000U, 350, 3, 2),
+ PLL_1416X_RATE(600000000U, 300, 3, 2),
+};
+
+const struct imx_pll14xx_rate_table imx_pll1443x_tbl[] = {
+ PLL_1443X_RATE(650000000U, 325, 3, 2, 0),
+ PLL_1443X_RATE(594000000U, 198, 2, 2, 0),
+ PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
+ PLL_1443X_RATE(361267200U, 361, 3, 3, 17511),
+};
+
+struct imx_pll14xx_clk imx_1443x_pll = {
+ .type = PLL_1443X,
+ .rate_table = imx_pll1443x_tbl,
+ .rate_count = ARRAY_SIZE(imx_pll1443x_tbl),
+};
+
+struct imx_pll14xx_clk imx_1416x_pll = {
+ .type = PLL_1416X,
+ .rate_table = imx_pll1416x_tbl,
+ .rate_count = ARRAY_SIZE(imx_pll1416x_tbl),
+};
+
static const struct imx_pll14xx_rate_table *imx_get_pll_settings(
struct clk_pll14xx *pll, unsigned long rate)
{
diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h
index f7a389a..bc5bb6a 100644
--- a/drivers/clk/imx/clk.h
+++ b/drivers/clk/imx/clk.h
@@ -50,6 +50,9 @@ struct imx_pll14xx_clk {
int flags;
};
+extern struct imx_pll14xx_clk imx_1416x_pll;
+extern struct imx_pll14xx_clk imx_1443x_pll;
+
#define imx_clk_cpu(name, parent_name, div, mux, pll, step) \
imx_clk_hw_cpu(name, parent_name, div, mux, pll, step)->clk
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V2 2/2] clk: imx8mn: Use common 1443X/1416X PLL clock structure
From: Anson Huang @ 2019-09-06 13:34 UTC (permalink / raw)
To: mturquette, sboyd, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, abel.vesa, peng.fan, ping.bai, chen.fang,
shengjiu.wang, aisheng.dong, sfr, l.stach, linux-clk,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1567776846-6373-1-git-send-email-Anson.Huang@nxp.com>
Use common 1413X/1416X PLL clock structure to save a lot
of duplicated code on i.MX8MN clock driver.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V1:
- Changes according to patch 1/2, now PLL table/structure is in pll14xx driver.
---
drivers/clk/imx/clk-imx8mn.c | 89 +++++--------------------------------------
drivers/clk/imx/clk-pll14xx.c | 2 +
2 files changed, 12 insertions(+), 79 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index cc65c13..91b6da8 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -39,75 +39,6 @@ enum {
NR_PLLS,
};
-static const struct imx_pll14xx_rate_table imx8mn_pll1416x_tbl[] = {
- PLL_1416X_RATE(1800000000U, 225, 3, 0),
- PLL_1416X_RATE(1600000000U, 200, 3, 0),
- PLL_1416X_RATE(1500000000U, 375, 3, 1),
- PLL_1416X_RATE(1400000000U, 350, 3, 1),
- PLL_1416X_RATE(1200000000U, 300, 3, 1),
- PLL_1416X_RATE(1000000000U, 250, 3, 1),
- PLL_1416X_RATE(800000000U, 200, 3, 1),
- PLL_1416X_RATE(750000000U, 250, 2, 2),
- PLL_1416X_RATE(700000000U, 350, 3, 2),
- PLL_1416X_RATE(600000000U, 300, 3, 2),
-};
-
-static const struct imx_pll14xx_rate_table imx8mn_audiopll_tbl[] = {
- PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
- PLL_1443X_RATE(361267200U, 361, 3, 3, 17511),
-};
-
-static const struct imx_pll14xx_rate_table imx8mn_videopll_tbl[] = {
- PLL_1443X_RATE(650000000U, 325, 3, 2, 0),
- PLL_1443X_RATE(594000000U, 198, 2, 2, 0),
-};
-
-static const struct imx_pll14xx_rate_table imx8mn_drampll_tbl[] = {
- PLL_1443X_RATE(650000000U, 325, 3, 2, 0),
-};
-
-static struct imx_pll14xx_clk imx8mn_audio_pll = {
- .type = PLL_1443X,
- .rate_table = imx8mn_audiopll_tbl,
- .rate_count = ARRAY_SIZE(imx8mn_audiopll_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mn_video_pll = {
- .type = PLL_1443X,
- .rate_table = imx8mn_videopll_tbl,
- .rate_count = ARRAY_SIZE(imx8mn_videopll_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mn_dram_pll = {
- .type = PLL_1443X,
- .rate_table = imx8mn_drampll_tbl,
- .rate_count = ARRAY_SIZE(imx8mn_drampll_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mn_arm_pll = {
- .type = PLL_1416X,
- .rate_table = imx8mn_pll1416x_tbl,
- .rate_count = ARRAY_SIZE(imx8mn_pll1416x_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mn_gpu_pll = {
- .type = PLL_1416X,
- .rate_table = imx8mn_pll1416x_tbl,
- .rate_count = ARRAY_SIZE(imx8mn_pll1416x_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mn_vpu_pll = {
- .type = PLL_1416X,
- .rate_table = imx8mn_pll1416x_tbl,
- .rate_count = ARRAY_SIZE(imx8mn_pll1416x_tbl),
-};
-
-static struct imx_pll14xx_clk imx8mn_sys_pll = {
- .type = PLL_1416X,
- .rate_table = imx8mn_pll1416x_tbl,
- .rate_count = ARRAY_SIZE(imx8mn_pll1416x_tbl),
-};
-
static const char * const pll_ref_sels[] = { "osc_24m", "dummy", "dummy", "dummy", };
static const char * const audio_pll1_bypass_sels[] = {"audio_pll1", "audio_pll1_ref_sel", };
static const char * const audio_pll2_bypass_sels[] = {"audio_pll2", "audio_pll2_ref_sel", };
@@ -409,16 +340,16 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
clks[IMX8MN_SYS_PLL2_REF_SEL] = imx_clk_mux("sys_pll2_ref_sel", base + 0x104, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
clks[IMX8MN_SYS_PLL3_REF_SEL] = imx_clk_mux("sys_pll3_ref_sel", base + 0x114, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
- clks[IMX8MN_AUDIO_PLL1] = imx_clk_pll14xx("audio_pll1", "audio_pll1_ref_sel", base, &imx8mn_audio_pll);
- clks[IMX8MN_AUDIO_PLL2] = imx_clk_pll14xx("audio_pll2", "audio_pll2_ref_sel", base + 0x14, &imx8mn_audio_pll);
- clks[IMX8MN_VIDEO_PLL1] = imx_clk_pll14xx("video_pll1", "video_pll1_ref_sel", base + 0x28, &imx8mn_video_pll);
- clks[IMX8MN_DRAM_PLL] = imx_clk_pll14xx("dram_pll", "dram_pll_ref_sel", base + 0x50, &imx8mn_dram_pll);
- clks[IMX8MN_GPU_PLL] = imx_clk_pll14xx("gpu_pll", "gpu_pll_ref_sel", base + 0x64, &imx8mn_gpu_pll);
- clks[IMX8MN_VPU_PLL] = imx_clk_pll14xx("vpu_pll", "vpu_pll_ref_sel", base + 0x74, &imx8mn_vpu_pll);
- clks[IMX8MN_ARM_PLL] = imx_clk_pll14xx("arm_pll", "arm_pll_ref_sel", base + 0x84, &imx8mn_arm_pll);
- clks[IMX8MN_SYS_PLL1] = imx_clk_pll14xx("sys_pll1", "sys_pll1_ref_sel", base + 0x94, &imx8mn_sys_pll);
- clks[IMX8MN_SYS_PLL2] = imx_clk_pll14xx("sys_pll2", "sys_pll2_ref_sel", base + 0x104, &imx8mn_sys_pll);
- clks[IMX8MN_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel", base + 0x114, &imx8mn_sys_pll);
+ clks[IMX8MN_AUDIO_PLL1] = imx_clk_pll14xx("audio_pll1", "audio_pll1_ref_sel", base, &imx_1443x_pll);
+ clks[IMX8MN_AUDIO_PLL2] = imx_clk_pll14xx("audio_pll2", "audio_pll2_ref_sel", base + 0x14, &imx_1443x_pll);
+ clks[IMX8MN_VIDEO_PLL1] = imx_clk_pll14xx("video_pll1", "video_pll1_ref_sel", base + 0x28, &imx_1443x_pll);
+ clks[IMX8MN_DRAM_PLL] = imx_clk_pll14xx("dram_pll", "dram_pll_ref_sel", base + 0x50, &imx_1443x_pll);
+ clks[IMX8MN_GPU_PLL] = imx_clk_pll14xx("gpu_pll", "gpu_pll_ref_sel", base + 0x64, &imx_1416x_pll);
+ clks[IMX8MN_VPU_PLL] = imx_clk_pll14xx("vpu_pll", "vpu_pll_ref_sel", base + 0x74, &imx_1416x_pll);
+ clks[IMX8MN_ARM_PLL] = imx_clk_pll14xx("arm_pll", "arm_pll_ref_sel", base + 0x84, &imx_1416x_pll);
+ clks[IMX8MN_SYS_PLL1] = imx_clk_pll14xx("sys_pll1", "sys_pll1_ref_sel", base + 0x94, &imx_1416x_pll);
+ clks[IMX8MN_SYS_PLL2] = imx_clk_pll14xx("sys_pll2", "sys_pll2_ref_sel", base + 0x104, &imx_1416x_pll);
+ clks[IMX8MN_SYS_PLL3] = imx_clk_pll14xx("sys_pll3", "sys_pll3_ref_sel", base + 0x114, &imx_1416x_pll);
/* PLL bypass out */
clks[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_mux_flags("audio_pll1_bypass", base, 4, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), CLK_SET_RATE_PARENT);
diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index 4a61743..3741b01 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -44,6 +44,8 @@ struct clk_pll14xx {
const struct imx_pll14xx_rate_table imx_pll1416x_tbl[] = {
PLL_1416X_RATE(1800000000U, 225, 3, 0),
PLL_1416X_RATE(1600000000U, 200, 3, 0),
+ PLL_1416X_RATE(1500000000U, 375, 3, 1),
+ PLL_1416X_RATE(1400000000U, 350, 3, 1),
PLL_1416X_RATE(1200000000U, 300, 3, 1),
PLL_1416X_RATE(1000000000U, 250, 3, 1),
PLL_1416X_RATE(800000000U, 200, 3, 1),
--
2.7.4
_______________________________________________
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: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator
From: Walter Wu @ 2019-09-06 3:15 UTC (permalink / raw)
To: Vlastimil Babka
Cc: wsd_upstream, Arnd Bergmann, linux-mm, linux-mediatek,
linux-kernel, kasan-dev, Martin Schwidefsky, Alexander Potapenko,
linux-arm-kernel, Matthias Brugger, Andrey Ryabinin,
Andrew Morton, Dmitry Vyukov
In-Reply-To: <99913463-0e2c-7dab-c1eb-8b9e149b3ee3@suse.cz>
On Thu, 2019-09-05 at 10:03 +0200, Vlastimil Babka wrote:
> On 9/4/19 4:24 PM, Walter Wu wrote:
> > On Wed, 2019-09-04 at 16:13 +0200, Vlastimil Babka wrote:
> >> On 9/4/19 4:06 PM, Walter Wu wrote:
> >>
> >> The THP fix is not required for the rest of the series, it was even merged to
> >> mainline separately.
> >>
> >>> And It looks like something is different, because we only need last
> >>> stack of page, so it can decrease memory overhead.
> >>
> >> That would save you depot_stack_handle_t (which is u32) per page. I guess that's
> >> nothing compared to KASAN overhead?
> >>
> > If we can use less memory, we can achieve what we want. Why not?
>
> In my experience to solve some UAFs, it's important to know not only the
> freeing stack, but also the allocating stack. Do they make sense together,
> or not? In some cases, even longer history of alloc/free would be nice :)
>
We think it only has free stack to find out the root cause. Maybe we can
refer to other people's experience and ideas.
> Also by simply recording the free stack in the existing depot handle,
> you might confuse existing page_owner file consumers, who won't know
> that this is a freeing stack.
>
Don't worry it.
1. Our feature option has this description about last stack of page.
when consumer enable our feature, they should know the changing.
2. We add to print text message for alloc or free stack before dump the
stack of page. so consumers should know what is it.
> All that just doesn't seem to justify saving an u32 per page.
Actually, We want to slim memory usage instead of increasing the memory
usage at another mail discussion. Maybe, maintainer or reviewer can
provide some ideas. That will be great.
> >
> >
>
_______________________________________________
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/2] vhost: re-introducing metadata acceleration through kernel virtual address
From: Hillf Danton @ 2019-09-06 3:21 UTC (permalink / raw)
To: Jason Wang
Cc: aarcange, Christoph Hellwig, linux-parisc, kvm, mst, netdev,
linux-kernel, virtualization, James Bottomley, linux-mm, jglisse,
jgg, David Miller, linux-arm-kernel
In-Reply-To: <20190905122736.19768-1-jasowang@redhat.com>
On Thu, 5 Sep 2019 20:27:36 +0800 From: Jason Wang <jasowang@redhat.com>
>
> +static void vhost_set_map_dirty(struct vhost_virtqueue *vq,
> + struct vhost_map *map, int index)
> +{
> + struct vhost_uaddr *uaddr = &vq->uaddrs[index];
> + int i;
> +
> + if (uaddr->write) {
> + for (i = 0; i < map->npages; i++)
> + set_page_dirty(map->pages[i]);
> + }
Not sure need to set page dirty under page lock.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1] PCI: iproc: Invalidate PAXB address mapping before programming it
From: Abhishek Shah @ 2019-09-06 3:58 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Ray Jui, Scott Branden
Cc: linux-pci, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, Abhishek Shah
Invalidate PAXB inbound/outbound address mapping each time before
programming it. This is helpful for the cases where we need to
reprogram inbound/outbound address mapping without resetting PAXB.
kexec kernel is one such example.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Vikram Mysore Prakash <vikram.prakash@broadcom.com>
---
drivers/pci/controller/pcie-iproc.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
index e3ca46497470..99a9521ba7ab 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -1245,6 +1245,32 @@ static int iproc_pcie_map_dma_ranges(struct iproc_pcie *pcie)
return ret;
}
+static void iproc_pcie_invalidate_mapping(struct iproc_pcie *pcie)
+{
+ struct iproc_pcie_ib *ib = &pcie->ib;
+ struct iproc_pcie_ob *ob = &pcie->ob;
+ int idx;
+
+ if (pcie->ep_is_internal)
+ return;
+
+ if (pcie->need_ob_cfg) {
+ /* iterate through all OARR mapping regions */
+ for (idx = ob->nr_windows - 1; idx >= 0; idx--) {
+ iproc_pcie_write_reg(pcie,
+ MAP_REG(IPROC_PCIE_OARR0, idx), 0);
+ }
+ }
+
+ if (pcie->need_ib_cfg) {
+ /* iterate through all IARR mapping regions */
+ for (idx = 0; idx < ib->nr_regions; idx++) {
+ iproc_pcie_write_reg(pcie,
+ MAP_REG(IPROC_PCIE_IARR0, idx), 0);
+ }
+ }
+}
+
static int iproce_pcie_get_msi(struct iproc_pcie *pcie,
struct device_node *msi_node,
u64 *msi_addr)
@@ -1517,6 +1543,8 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)
iproc_pcie_perst_ctrl(pcie, true);
iproc_pcie_perst_ctrl(pcie, false);
+ iproc_pcie_invalidate_mapping(pcie);
+
if (pcie->need_ob_cfg) {
ret = iproc_pcie_map_ranges(pcie, res);
if (ret) {
--
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 related
* Re: [RESEND PATCH next v2 0/6] ARM: keystone: update dt and enable cpts support
From: santosh.shilimkar @ 2019-09-06 4:52 UTC (permalink / raw)
To: Grygorii Strashko, Santosh Shilimkar
Cc: devicetree, Murali Karicheri, Sekhar Nori, linux-kernel,
linux-arm-kernel
In-Reply-To: <323c1835-e6b0-9153-8d1e-06200d5e2201@ti.com>
On 9/5/19 12:33 PM, Grygorii Strashko wrote:
> Hi Santosh,
>
> On 06/07/2019 02:48, santosh.shilimkar@oracle.com wrote:
>> On 7/5/19 8:12 AM, Grygorii Strashko wrote:
>>> Hi Santosh,
>>>
>>> This series is set of platform changes required to enable NETCP CPTS
>>> reference
>>> clock selection and final patch to enable CPTS for Keystone
>>> 66AK2E/L/HK SoCs.
>>>
>>> Those patches were posted already [1] together with driver's changes,
>>> so this
>>> is re-send of DT/platform specific changes only, as driver's changes
>>> have
>>> been merged already.
>>>
>>> Patches 1-5: CPTS DT nodes update for TI Keystone 2 66AK2HK/E/L SoCs.
>>> Patch 6: enables CPTS for TI Keystone 2 66AK2HK/E/L SoCs.
>>>
>>> [1] https://patchwork.kernel.org/cover/10980037/
>>>
>>> Grygorii Strashko (6):
>>> ARM: dts: keystone-clocks: add input fixed clocks
>>> ARM: dts: k2e-clocks: add input ext. fixed clocks tsipclka/b
>>> ARM: dts: k2e-netcp: add cpts refclk_mux node
>>> ARM: dts: k2hk-netcp: add cpts refclk_mux node
>>> ARM: dts: k2l-netcp: add cpts refclk_mux node
>>> ARM: configs: keystone: enable cpts
>>>
>> Will add these for 5.4 queue. Thanks !!
>
> Sry, that I'm disturbing you, but I do not see those patches applied?
>
Sorry I missed this one. Will queue this up for next merge window.
Will push this out to next early once rc1 is out. If you don't
see it, please ping me.
Regards,
Santosh
_______________________________________________
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 3/4] dt-bindings: Add Qualcomm USB SuperSpeed PHY bindings
From: Stephen Boyd @ 2019-09-06 5:26 UTC (permalink / raw)
To: Jack Pham, Jorge Ramirez
Cc: mark.rutland, robh, kishon, gregkh, linux-usb, khasim.mohammed,
linux-kernel, Bjorn Andersson, devicetree, linux-arm-msm,
andy.gross, shawn.guo, linux-arm-kernel
In-Reply-To: <20190905175802.GA19599@jackp-linux.qualcomm.com>
Quoting Jack Pham (2019-09-05 10:58:02)
> Hi Jorge, Bjorn,
>
> On Thu, Sep 05, 2019 at 09:18:57AM +0200, Jorge Ramirez wrote:
> > On 9/4/19 01:34, Bjorn Andersson wrote:
> > > On Tue 03 Sep 14:45 PDT 2019, Stephen Boyd wrote:
> > >> that would need an of_regulator_get() sort of API that can get the
> > >> regulator out of there? Or to make the connector into a struct device
> > >> that can get the regulator out per some generic connector driver and
> > >> then pass it through to the USB controller when it asks for it. Maybe
> > >> try to prototype that out?
> > >>
> > >
> > > The examples given in the DT bindings describes the connector as a child
> > > of a PMIC, with of_graph somehow tying it to the various inputs. But in
> > > these examples vbus is handled by implicitly inside the MFD, where
> > > extcon is informed about the plug event they toggle vbus as well.
> > >
> > > In our case we have a extcon-usb-gpio to detect mode, which per Jorge's
> > > proposal will trickle down to the PHY and become a regulator calls on
> > > either some external regulator or more typically one of the chargers in
> > > the system.
>
> Interesting you mention extcon-usb-gpio. I thought extcon at least from
> bindings perspective is passé now. Maybe this is what you need (just
> landed in usb-next):
>
> usb: common: add USB GPIO based connection detection driver
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=4602f3bff2669012c1147eecfe74c121765f5c56
>
> dt-bindings: usb: add binding for USB GPIO based connection detection driver
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=f651c73e71f53f65e9846677d79d8e120452b59f
>
> Fortunately this new driver might check the right boxes for you:
> - usb connector binding
> - ID detect GPIO
> - vbus-supply regulator
>
> With that, I think you can also keep the connector subnode out of the
> SSPHY node well, and similarly get rid of the vbus toggle handling from
> the PHY driver.
>
> The big thing missing now is that this driver replaces extcon
> completely, so we'll need handling in dwc3/dwc3-qcom to retrieve the
> role switch state to know when host mode is entered. I saw this a while
> back but don't think it got picked up:
>
> https://patchwork.kernel.org/patch/10909981/
>
Yes this looks like the approach that should be taken. One question
though, is this a micro-b connector or a type-c connector on the board?
I thought it was a type-c, so then this USB gpio based connection driver
isn't an exact fit?
_______________________________________________
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