* Re: [PATCH] i2c: stm32f7: Make structure stm32f7_i2c_algo constant
From: Wolfram Sang @ 2019-09-04 21:12 UTC (permalink / raw)
To: Nishka Dasgupta
Cc: alexandre.torgue, linux-kernel, pierre-yves.mordret, linux-i2c,
mcoquelin.stm32, linux-stm32, linux-arm-kernel
In-Reply-To: <20190815055857.1944-1-nishkadg.linux@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 477 bytes --]
On Thu, Aug 15, 2019 at 11:28:57AM +0530, Nishka Dasgupta wrote:
> Static structure stm32f7_i2c_algo, of type i2c_algorithm, is used only
> when it is assigned to constant field algo of a variable having type
> i2c_adapter. As stm32f7_i2c_algo is therefore never modified, make it
> const as well to protect it from unintended modification.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.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 1/2] i2c: qcom-geni: Provide an option to select FIFO processing
From: Wolfram Sang @ 2019-09-04 21:23 UTC (permalink / raw)
To: Bjorn Andersson
Cc: mark.rutland, devicetree, linux-arm-msm, agross, robh+dt,
linux-kernel, alokc, linux-i2c, Lee Jones, linux-arm-kernel
In-Reply-To: <20190904203548.GC580@tuxbook-pro>
[-- Attachment #1.1: Type: text/plain, Size: 3020 bytes --]
On Wed, Sep 04, 2019 at 01:35:48PM -0700, Bjorn Andersson wrote:
> On Wed 04 Sep 04:36 PDT 2019, Lee Jones wrote:
>
> The subject implies that we select FIFO mode instead of DMA, but that's
> not really true, because with DMA enabled we still fall back to FIFO for
> messages below 32 bytes.
>
> So what this does it to disable DMA, which neither the subject or the DT
> property describes.
>
> Also missing is a description of why this is needed.
Yes.
I am willing to help to get this resolved soonish. However, I have
issues with the approach.
It looks like a workaround to me. It would be interesting to hear which
I2C client breaks with DMA and if it's driver can't be fixed somehow
instead. But even if we agree on a workaround short term, adding a
binding for this workaround seems like a no-go to me. We have to live
with this binding forever. Sidenote: I could think of a generic
'disable-dma' which could be reused everywhere but we probably won't get
that upstream that late in the cycle.
Is there no other way to disable DMA which is local to this driver so we
can easily revert the workaround later?
>
> Regards,
> Bjorn
>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/i2c/busses/i2c-qcom-geni.c | 14 ++++++++++----
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
> > index a89bfce5388e..dfdbce067827 100644
> > --- a/drivers/i2c/busses/i2c-qcom-geni.c
> > +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> > @@ -353,13 +353,16 @@ static void geni_i2c_tx_fsm_rst(struct geni_i2c_dev *gi2c)
> > static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
> > u32 m_param)
> > {
> > + struct device_node *np = gi2c->se.dev->of_node;
> > dma_addr_t rx_dma;
> > unsigned long time_left;
> > - void *dma_buf;
> > + void *dma_buf = NULL;
> > struct geni_se *se = &gi2c->se;
> > size_t len = msg->len;
> >
> > - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> > + if (!of_property_read_bool(np, "qcom,geni-se-fifo"))
> > + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> > +
> > if (dma_buf)
> > geni_se_select_mode(se, GENI_SE_DMA);
> > else
> > @@ -392,13 +395,16 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
> > static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
> > u32 m_param)
> > {
> > + struct device_node *np = gi2c->se.dev->of_node;
> > dma_addr_t tx_dma;
> > unsigned long time_left;
> > - void *dma_buf;
> > + void *dma_buf = NULL;
> > struct geni_se *se = &gi2c->se;
> > size_t len = msg->len;
> >
> > - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> > + if (!of_property_read_bool(np, "qcom,geni-se-fifo"))
> > + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> > +
> > if (dma_buf)
> > geni_se_select_mode(se, GENI_SE_DMA);
> > else
> > --
> > 2.17.1
> >
[-- 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
* linux-next: Fixes tag needs some work in the arm-soc tree
From: Stephen Rothwell @ 2019-09-04 21:24 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, ARM
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Manivannan Sadhasivam
[-- Attachment #1.1: Type: text/plain, Size: 388 bytes --]
Hi all,
In commit
ca33f735b119 ("arm64: dts: bitmain: Modify pin controller memory map")
Fixes tag
Fixes: af2ff87de413 ("arm64: dts: bitmain: Add pinctrl support for BM1880 SoC")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: c1294fb5cb78 ("arm64: dts: bitmain: Add pinctrl support for BM1880 SoC")
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 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: linux-next: manual merge of the slave-dma tree with the arm-soc tree
From: Arnd Bergmann @ 2019-09-04 21:34 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Randy Dunlap, Linux Kernel Mailing List, Vinod Koul,
Linux Next Mailing List, Olof Johansson, ARM
In-Reply-To: <20190904204427.1e1a064f@canb.auug.org.au>
On Wed, Sep 4, 2019 at 12:44 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> diff --cc drivers/dma/iop-adma.c
> index 03f4a588cf7f,003b753e4604..000000000000
> --- a/drivers/dma/iop-adma.c
> +++ b/drivers/dma/iop-adma.c
> @@@ -116,9 -116,9 +116,9 @@@ static void __iop_adma_slot_cleanup(str
> list_for_each_entry_safe(iter, _iter, &iop_chan->chain,
> chain_node) {
> pr_debug("\tcookie: %d slot: %d busy: %d "
> - "this_desc: %#x next_desc: %#llx ack: %d\n",
> - "this_desc: %pad next_desc: %#x ack: %d\n",
> ++ "this_desc: %pad next_desc: %#llx ack: %d\n",
> iter->async_tx.cookie, iter->idx, busy,
> - iter->async_tx.phys, (u64)iop_desc_get_next_desc(iter),
> - &iter->async_tx.phys, iop_desc_get_next_desc(iter),
> ++ &iter->async_tx.phys, (u64)iop_desc_get_next_desc(iter),
> async_tx_test_ack(&iter->async_tx));
> prefetch(_iter);
> prefetch(&_iter->async_tx);
The resolution looks correct to me. I had to research how I missed this,
and it turns out that the problem is me testing with clang-9 rather than gcc
at the moment. While clang is perfectly capable of warning about this
issue, the kernel turns off -Wno-format when building with clang.
Arnd
_______________________________________________
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 10/12] namei: aggressively check for nd->root escape on ".." resolution
From: Linus Torvalds @ 2019-09-04 21:35 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, linux-m68k,
Al Viro, 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,
alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <CAHk-=wiod1rQMU+6Zew=cLE8uX4tUdf42bM5eKngMnNVS2My7g@mail.gmail.com>
On Wed, Sep 4, 2019 at 2:09 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So you'd have three stages:
>
> 1) ".." always returns -EXDEV
>
> 2) ".." returns -EXDEV if there was a concurrent rename/mount
>
> 3) ".." returns -EXDEV if there was a concurrent rename/mount and we
> reset the sequence numbers and check if you escaped.
In fact, I wonder if this should return -EAGAIN instead - to say that
"retrying may work".
Because then:
> Also, I'm not 100% convinced that (3) is needed at all. I think the
> retry could be done in user space instead, which needs to have a
> fallback anyway. Yes? No?
Any user mode fallback would want to know whether it's a final error
or whether simply re-trying might make it work again.
I think that re-try case is valid for any of the possible "races
happened, we can't guarantee that it's safe", and retrying inside the
kernel (or doing that re-validation) could have latency issues.
Maybe ".." is the only such case. I can't think of any other ones in
your series, but at least conceptually they could happen. For example,
we've had people who wanted pathname lookup without any IO happening,
because if you have to wait for IO you could want to use another
thread etc if you're doing some server in user space..
Linus
_______________________________________________
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 10/12] namei: aggressively check for nd->root escape on ".." resolution
From: Linus Torvalds @ 2019-09-04 21:36 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, linux-m68k,
Al Viro, 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,
alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <CAHk-=wiHRW3Z9xPRiExi9jLjB0cdGhM=3vaW+b80mjuRcbORyw@mail.gmail.com>
On Wed, Sep 4, 2019 at 2:35 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, Sep 4, 2019 at 2:09 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So you'd have three stages:
> >
> > 1) ".." always returns -EXDEV
> >
> > 2) ".." returns -EXDEV if there was a concurrent rename/mount
> >
> > 3) ".." returns -EXDEV if there was a concurrent rename/mount and we
> > reset the sequence numbers and check if you escaped.
>
> In fact, I wonder if this should return -EAGAIN instead - to say that
> "retrying may work".
And here "this" was meant to be "case 2" - I was moving the quoted
text around and didn't fix my wording, so now it is ambiguous or
implies #3, which would be crazy.
Sorry for the confusion,
Linus
_______________________________________________
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 v1 1/1] i2c: iproc: Add i2c repeated start capability
From: Wolfram Sang @ 2019-09-04 21:37 UTC (permalink / raw)
To: Ray Jui
Cc: Mark Rutland, devicetree, Lori Hikichi, Florian Fainelli,
Shivaraj Shetty, Rayagonda Kokatanur, linux-kernel, Icarus Chau,
Rob Herring, bcm-kernel-feedback-list, linux-i2c,
linux-arm-kernel
In-Reply-To: <540c4e2d-0dd5-5260-30b2-e1589b279d71@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 1125 bytes --]
> I think you are right that the controller does not seem to support
> additional I2C features in addition to SMBUS.
>
> However, my concern of switching to the smbus_xfer API is:
>
> 1) Some customers might have used I2C_RDWR based API from i2cdev. Changing
> from master_xfer to smbus_xfer may break the existing applications that are
> already developed.
Well, given that you add new quirks in the original patch here, you are
kind of breaking it already. Most transfers which are not SMBus-alike
transfers would now be rejected. For SMBus-alike transfers which are
sent via I2C_RDWR (which is ugly), I have to think about it.
> 2) The sound subsystem I2C regmap based implementation seems to be using
> i2c_ based API instead of smbus_ based API. Does this mean this will also
> break most of the audio codec drivers with I2C regmap API based usage?
I don't think so. If you check regmap_get_i2c_bus() then it checks the
adapter functionality and chooses the best transfer option then. I may
be missing something but I would wonder if the sound system does
something special and different.
[-- 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 v12 10/12] namei: aggressively check for nd->root escape on ".." resolution
From: Aleksa Sarai @ 2019-09-04 21:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, linux-m68k,
Al Viro, 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,
alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <CAHk-=wiod1rQMU+6Zew=cLE8uX4tUdf42bM5eKngMnNVS2My7g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3439 bytes --]
On 2019-09-04, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, Sep 4, 2019 at 1:23 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
> > This patch allows for LOOKUP_BENEATH and LOOKUP_IN_ROOT to safely permit
> > ".." resolution (in the case of LOOKUP_BENEATH the resolution will still
> > fail if ".." resolution would resolve a path outside of the root --
> > while LOOKUP_IN_ROOT will chroot(2)-style scope it). Magic-link jumps
> > are still disallowed entirely because now they could result in
> > inconsistent behaviour if resolution encounters a subsequent ".."[*].
>
> This is the only patch in the series that makes me go "umm".
>
> Why is it ok to re-initialize m_seq, which is used by other things
> too? I think it's because we're out of RCU lookup, but there's no
> comment about it, and it looks iffy to me. I'd rather have a separate
> sequence count that doesn't have two users with different lifetime
> rules.
Yeah, the reasoning was that it's because we're out of RCU lookup and if
we didn't re-grab ->m_seq we'd hit path_is_under() on every subsequent
".." (even though we've checked that it's safe). But yes, I should've
used a different field to avoid confusion (and stop it looking
unnecessarily dodgy). I will fix that.
> But even apart from that, I think from a "patch continuity" standpoint
> it would be better to introduce the sequence counts as just an error
> condition first - iow, not have the "path_is_under()" check, but just
> return -EXDEV if the sequence number doesn't match.
Ack, will do.
> So you'd have three stages:
>
> 1) ".." always returns -EXDEV
>
> 2) ".." returns -EXDEV if there was a concurrent rename/mount
>
> 3) ".." returns -EXDEV if there was a concurrent rename/mount and we
> reset the sequence numbers and check if you escaped.
>
> becasue the sequence number reset really does make me go "hmm", plus I
> get this nagging little feeling in the back of my head that you can
> cause nasty O(n^2) lookup cost behavior with deep paths, lots of "..",
> and repeated path_is_under() calls.
The reason for doing the concurrent-{rename,mount} checks was to try to
avoid the O(n^2) in most cases, but you're right that if you have an
attacker that is spamming renames (or you're on a box with a lot of
renames and/or mounts going on *anywhere*) you will hit an O(n^2) here
(more pedantically, O(m*n) but who's counting?).
Unfortunately, I'm not sure what the best solution would be for this
one. If -EAGAIN retries are on the table, we could limit how many times
we're willing to do path_is_under() and then just return -EAGAIN.
> So (1) sounds safe. (2) sounds simple. And (3) is where I think subtle
> things start happening.
>
> Also, I'm not 100% convinced that (3) is needed at all. I think the
> retry could be done in user space instead, which needs to have a
> fallback anyway. Yes? No?
Hinting to userspace to do a retry (with -EAGAIN as you mention in your
other mail) wouldn't be a bad thing at all, though you'd almost
certainly get quite a few spurious -EAGAINs -- &{mount,rename}_lock are
global for the entire machine, after all.
But if the only significant roadblock is that (3) seems a bit too hairy,
I would be quite happy with landing (2) as a first step (with -EAGAIN).
--
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 -next 08/15] thermal: tsens: use devm_platform_ioremap_resource() to simplify code
From: Bjorn Andersson @ 2019-09-04 21:50 UTC (permalink / raw)
To: YueHaibing
Cc: mans, mmayer, eric, miquel.raynal, linux-stm32, heiko,
amit.kucheria, f.fainelli, daniel.lezcano, phil, linux-rockchip,
agross, bcm-kernel-feedback-list, linux-arm-msm, rui.zhang,
david.hernandezsanchez, alexandre.torgue, marc.w.gonzalez, rjui,
edubezval, linux-mediatek, linux-rpi-kernel, gregory.0xf0,
matthias.bgg, horms+renesas, talel, linux-arm-kernel, sbranden,
wsa+renesas, gregkh, linux-pm, linux-kernel, wahrenst,
mcoquelin.stm32, jun.nie, computersforpeace, shawnguo
In-Reply-To: <20190904122939.23780-9-yuehaibing@huawei.com>
On Wed 04 Sep 05:29 PDT 2019, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/thermal/qcom/tsens-common.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens-common.c b/drivers/thermal/qcom/tsens-common.c
> index 528df88..43ce4fb 100644
> --- a/drivers/thermal/qcom/tsens-common.c
> +++ b/drivers/thermal/qcom/tsens-common.c
> @@ -155,7 +155,6 @@ int __init init_common(struct tsens_priv *priv)
> {
> void __iomem *tm_base, *srot_base;
> struct device *dev = priv->dev;
> - struct resource *res;
> u32 enabled;
> int ret, i, j;
> struct platform_device *op = of_find_device_by_node(priv->dev->of_node);
> @@ -166,8 +165,7 @@ int __init init_common(struct tsens_priv *priv)
> if (op->num_resources > 1) {
> /* DT with separate SROT and TM address space */
> priv->tm_offset = 0;
> - res = platform_get_resource(op, IORESOURCE_MEM, 1);
> - srot_base = devm_ioremap_resource(&op->dev, res);
> + srot_base = devm_platform_ioremap_resource(op, 1);
> if (IS_ERR(srot_base)) {
> ret = PTR_ERR(srot_base);
> goto err_put_device;
> @@ -184,8 +182,7 @@ int __init init_common(struct tsens_priv *priv)
> priv->tm_offset = 0x1000;
> }
>
> - res = platform_get_resource(op, IORESOURCE_MEM, 0);
> - tm_base = devm_ioremap_resource(&op->dev, res);
> + tm_base = devm_platform_ioremap_resource(op, 0);
> if (IS_ERR(tm_base)) {
> ret = PTR_ERR(tm_base);
> goto err_put_device;
> --
> 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
* Re: [PATCH -next 07/36] spi: bcm63xx-hsspi: use devm_platform_ioremap_resource() to simplify code
From: Florian Fainelli @ 2019-09-04 22:10 UTC (permalink / raw)
To: YueHaibing, broonie, rjui, sbranden, eric, wahrenst, shc_work,
agross, khilman, matthias.bgg, shawnguo, s.hauer, kernel,
festevam, linux-imx, avifishman70, tmaimon77, tali.perry1,
venture, yuenn, benjaminfair, kgene, krzk, andi, palmer,
paul.walmsley, baohua, mripard, wens, ldewangan, thierry.reding,
jonathanh, yamada.masahiro, michal.simek
Cc: linux-samsung-soc, linux-arm-msm, openbmc, linux-mediatek,
linux-kernel, linux-spi, bcm-kernel-feedback-list,
linux-rpi-kernel, linux-tegra, linux-amlogic, linux-riscv,
linux-arm-kernel
In-Reply-To: <20190904135918.25352-8-yuehaibing@huawei.com>
On 9/4/2019 6:58 AM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
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 -next 26/36] spi: sifive: use devm_platform_ioremap_resource() to simplify code
From: Paul Walmsley @ 2019-09-04 22:20 UTC (permalink / raw)
To: YueHaibing
Cc: tmaimon77, palmer, tali.perry1, eric, ldewangan, linux-riscv,
festevam, linux-samsung-soc, f.fainelli, benjaminfair, shc_work,
khilman, openbmc, michal.simek, krzk, jonathanh, yuenn, wens,
agross, bcm-kernel-feedback-list, linux-imx, linux-arm-msm,
linux-tegra, andi, rjui, s.hauer, mripard, broonie,
linux-mediatek, linux-rpi-kernel, matthias.bgg, linux-amlogic,
linux-arm-kernel, baohua, sbranden, yamada.masahiro, avifishman70,
venture, linux-kernel, linux-spi, thierry.reding, wahrenst,
kernel, kgene, shawnguo
In-Reply-To: <20190904135918.25352-27-yuehaibing@huawei.com>
On Wed, 4 Sep 2019, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Paul Walmsley <paul.walmsley@sifive.com>
- Paul
_______________________________________________
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 10/12] namei: aggressively check for nd->root escape on ".." resolution
From: Linus Torvalds @ 2019-09-04 22:16 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, linux-m68k,
Al Viro, 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,
alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <20190904214856.vnvom7h5xontvngq@yavin.dot.cyphar.com>
On Wed, Sep 4, 2019 at 2:49 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
>
> Hinting to userspace to do a retry (with -EAGAIN as you mention in your
> other mail) wouldn't be a bad thing at all, though you'd almost
> certainly get quite a few spurious -EAGAINs -- &{mount,rename}_lock are
> global for the entire machine, after all.
I'd hope that we have some future (possibly very long-term)
alternative that is not quite system-global, but yes, right now they
are.
Which is one reason I'd rather see EAGAIN in user space - yes, it
probably makes it even easier to trigger, but it also means that user
space might be able to do something about it when it does trigger.
For example, maybe user space can first just use an untrusted path
as-is, and if it gets EAGAIN or EXDEV, it may be that user space can
simplify the path (ie turn "xyz/.../abc" into just "abc".
And even if user space doesn't do anything like that, I suspect a
performance problem is going to be a whole lot easier to debug and
report when somebody ends up seeing excessive retries happening. As a
developer you'll see it in profiles or in system call traces, rather
than it resulting in very odd possible slowdowns for the kernel.
And yeah, it would probably be best to then at least delay doing
option 3 indefinitely, just to make sure user space knows about and
actually has a test-case for that EAGAIN happening.
Linus
_______________________________________________
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 net-next v3 0/3] net: dsa: mt7530: Convert to PHYLINK and add support for port 5
From: David Miller @ 2019-09-04 22:28 UTC (permalink / raw)
To: opensource
Cc: andrew, f.fainelli, frank-w, netdev, sean.wang, linux, linux-mips,
linux-mediatek, john, matthias.bgg, vivien.didelot,
linux-arm-kernel
In-Reply-To: <20190902130226.26845-1-opensource@vdorst.com>
From: René van Dorst <opensource@vdorst.com>
Date: Mon, 2 Sep 2019 15:02:23 +0200
> 1. net: dsa: mt7530: Convert to PHYLINK API
> This patch converts mt7530 to PHYLINK API.
> 2. dt-bindings: net: dsa: mt7530: Add support for port 5
> 3. net: dsa: mt7530: Add support for port 5
> These 2 patches adding support for port 5 of the switch.
>
> v2->v3:
> * Removed 'status = "okay"' lines in patch #2
> * Change a port 5 setup message in a debug message in patch #3
> * Added ack-by and tested-by tags
> v1->v2:
> * Mostly phylink improvements after review.
> rfc -> v1:
> * Mostly phylink improvements after review.
> * Drop phy isolation patches. Adds no value for now.
Series applied.
_______________________________________________
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 10/12] namei: aggressively check for nd->root escape on ".." resolution
From: David Howells @ 2019-09-04 22:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, David Howells,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, Aleksa Sarai,
Al Viro, Andy Lutomirski, Shuah Khan, Namhyung Kim,
David Drysdale, Christian Brauner, J. Bruce Fields, linux-parisc,
linux-m68k, Linux API, Chanho Min, Jeff Layton, Oleg Nesterov,
Eric Biederman, alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <CAHk-=wgcJq21Hydh7Tx5-o8empoPp7ULDBw0Am-du_Pa+fcftQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > Hinting to userspace to do a retry (with -EAGAIN as you mention in your
> > other mail) wouldn't be a bad thing at all, though you'd almost
> > certainly get quite a few spurious -EAGAINs -- &{mount,rename}_lock are
> > global for the entire machine, after all.
>
> I'd hope that we have some future (possibly very long-term)
> alternative that is not quite system-global, but yes, right now they
> are.
It ought to be reasonably easy to make them per-sb at least, I think. We
don't allow cross-super rename, right?
David
_______________________________________________
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] media: meson: Add NULL check after the call to kmalloc()
From: Austin Kim @ 2019-09-04 22:39 UTC (permalink / raw)
To: Greg KH
Cc: mjourdan, devel, khilman, linux-kernel, linux-amlogic, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <20190904084525.GB4925@kroah.com>
2019년 9월 4일 (수) 오후 5:45, Greg KH <gregkh@linuxfoundation.org>님이 작성:
>
> On Wed, Sep 04, 2019 at 05:22:32PM +0900, Austin Kim wrote:
> > If the kmalloc() return NULL, the NULL pointer dereference will occur.
> > new_ts->ts = ts;
> >
> > Add exception check after the call to kmalloc() is made.
> >
> > Signed-off-by: Austin Kim <austindh.kim@gmail.com>
> > ---
> > drivers/staging/media/meson/vdec/vdec_helpers.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/staging/media/meson/vdec/vdec_helpers.c b/drivers/staging/media/meson/vdec/vdec_helpers.c
> > index f16948b..e7e56d5 100644
> > --- a/drivers/staging/media/meson/vdec/vdec_helpers.c
> > +++ b/drivers/staging/media/meson/vdec/vdec_helpers.c
> > @@ -206,6 +206,10 @@ void amvdec_add_ts_reorder(struct amvdec_session *sess, u64 ts, u32 offset)
> > unsigned long flags;
> >
> > new_ts = kmalloc(sizeof(*new_ts), GFP_KERNEL);
> > + if (!new_ts) {
> > + dev_err(sess->core->dev, "Failed to kmalloc()\n");
>
> Did you run this through checkpatch? I think it will say that this line
> is not ok.
>
> > + return;
>
> Shouldn't you return an -ENOMEM error somehow?
I agreed with your feedback.
Let me take a look at the code more and then resend the patch if necessary.
Thanks,
Austin Kim
>
> thanks,
>
> greg k-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 v12 10/12] namei: aggressively check for nd->root escape on ".." resolution
From: Linus Torvalds @ 2019-09-04 22:38 UTC (permalink / raw)
To: David Howells
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, J. Bruce Fields,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, Aleksa Sarai,
Al Viro, Andy Lutomirski, Shuah Khan, Namhyung Kim,
David Drysdale, Christian Brauner, linux-parisc, linux-m68k,
Linux API, Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <20592.1567636276@warthog.procyon.org.uk>
On Wed, Sep 4, 2019 at 3:31 PM David Howells <dhowells@redhat.com> wrote:
>
> It ought to be reasonably easy to make them per-sb at least, I think. We
> don't allow cross-super rename, right?
Right now the sequence count handling very much depends on it being a
global entity on the reader side, at least.
And while the rename sequence count could (and probably should) be
per-sb, the same is very much not true of the mount one.
So the rename seqcount is likely easier to fix than the mount one, but
neither of them are entirely trivial, afaik.
Linus
_______________________________________________
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] media: meson: Add NULL check after the call to kmalloc()
From: Austin Kim @ 2019-09-04 22:47 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: mjourdan, devel, khilman, linux-kernel, gregkh, linux-amlogic,
mchehab, linux-arm-kernel, linux-media
In-Reply-To: <a9ca05ec-55a9-a58c-267a-334771a1480a@rasmusvillemoes.dk>
2019년 9월 4일 (수) 오후 5:43, Rasmus Villemoes <linux@rasmusvillemoes.dk>님이 작성:
>
> On 04/09/2019 10.22, Austin Kim wrote:
> > If the kmalloc() return NULL, the NULL pointer dereference will occur.
> > new_ts->ts = ts;
> >
> > Add exception check after the call to kmalloc() is made.
> >
> > Signed-off-by: Austin Kim <austindh.kim@gmail.com>
> > ---
> > drivers/staging/media/meson/vdec/vdec_helpers.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/staging/media/meson/vdec/vdec_helpers.c b/drivers/staging/media/meson/vdec/vdec_helpers.c
> > index f16948b..e7e56d5 100644
> > --- a/drivers/staging/media/meson/vdec/vdec_helpers.c
> > +++ b/drivers/staging/media/meson/vdec/vdec_helpers.c
> > @@ -206,6 +206,10 @@ void amvdec_add_ts_reorder(struct amvdec_session *sess, u64 ts, u32 offset)
> > unsigned long flags;
> >
> > new_ts = kmalloc(sizeof(*new_ts), GFP_KERNEL);
> > + if (!new_ts) {
> > + dev_err(sess->core->dev, "Failed to kmalloc()\n");
> > + return;
> > + }
> > new_ts->ts = ts;
> > new_ts->offset = offset;
>
> No need to printk() on error, AFAIK the mm subsystem should already make
> some noise if an allocation fails.
Thanks for valuable feedback.
BTW, if the kmalloc return NULL, mm subsystem throws error log with 100%?
If no, please share error signature of kernel.
> This is not a proper fix - you need to make the function return an error
> (-ENOMEM) to let the caller know allocation failed, and allow that to
> propagate the error. There's only one caller, which already seems
> capable of returning errors (there's an -EAGAIN), so it shouldn't be
> that hard - though of course one needs to undo what has been done so far.
>
> Also, unrelated to the kmalloc() handling: amvdec_add_ts_reorder() could
> be moved to esparser.c and made static, or at the very least the
> EXPORT_SYMBOL can be removed since vdec_helpers.o is linked in to the
> same module as the sole user. That probably goes for all the
> EXPORT_SYMBOL(amvdec_*).
I agreed with your feedback.
- On memory allocation failure, it should have returned (-ENOMEM)
rather than 'return' statement.
- The call to amvdec_add_ts_reorder() is only made by esparser_queue().
Let me resend the patch if necessary.
Thanks,
Austin Kim
>
> Rasmus
_______________________________________________
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/1] mm/pgtable/debug: Add test validating architecture page table helpers
From: Dave Hansen @ 2019-09-04 23:14 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, Masahiro Yamada, Paul Mackerras,
sparclinux, Thomas Gleixner, linux-s390, Jason Gunthorpe,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Tetsuo Handa, linux-arm-kernel, linux-snps-arc,
Kees Cook, Shutemov, Kirill, Mark Brown, Dan Williams,
Vlastimil Babka, Sri Krishna chowdary, Ard Biesheuvel,
Greg Kroah-Hartman, linux-mips, Ralf Baechle, linux-kernel,
Paul Burton, Mike Rapoport, Vineet Gupta, Martin Schwidefsky,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1567497706-8649-2-git-send-email-anshuman.khandual@arm.com>
On 9/3/19 1:01 AM, Anshuman Khandual wrote:
> This adds a test module which will validate architecture page table helpers
> and accessors regarding compliance with generic MM semantics expectations.
> This will help various architectures in validating changes to the existing
> page table helpers or addition of new ones.
This looks really cool. The "only" complication on x86 is the large
number of compile and runtime options that we have. When this gets
merged, it would be really nice to make sure that the 0day guys have
good coverage of all the configurations.
I'm not _quite_ sure what kind of bugs it will catch on x86 and I
suspect it'll have more value for the other architectures, but it seems
harmless enough.
_______________________________________________
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 7/8] media: cedrus: Add support for holding capture buffer
From: Jernej Škrabec @ 2019-09-04 23:14 UTC (permalink / raw)
To: Hans Verkuil
Cc: devel, acourbot, pawel, jonas, gregkh, wens, mripard, tfiga,
paul.kocialkowski, kyungmin.park, linux-media, linux-arm-kernel,
mchehab, ezequiel, linux-kernel, m.szyprowski
In-Reply-To: <f105990c-e059-6bdd-433f-074388e3a2dc@xs4all.nl>
Dne četrtek, 29. avgust 2019 ob 13:23:29 CEST je Hans Verkuil napisal(a):
> On 8/22/19 9:44 PM, Jernej Skrabec wrote:
> > When frame contains multiple slices and driver works in slice mode, it's
> > more efficient to hold capture buffer in queue until all slices of a
> > same frame are decoded.
> >
> > Add support for that to Cedrus driver by exposing and implementing
> > V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 9 +++++++++
> > drivers/staging/media/sunxi/cedrus/cedrus_hw.c | 8 +++++---
> > drivers/staging/media/sunxi/cedrus/cedrus_video.c | 1 +
> > 3 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > d7b54accfe83..68462b99750e 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -31,6 +31,14 @@ void cedrus_device_run(void *priv)
> >
> > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > +
> > + if (v4l2_m2m_release_capture_buf(run.src, run.dst)) {
> > + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + v4l2_m2m_buf_done(run.dst, VB2_BUF_STATE_DONE);
> > + run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > + }
> > + run.dst->is_held = run.src->flags &
V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
> > +
> >
> > run.first_slice =
> >
> > run.src->vb2_buf.timestamp != run.dst-
>vb2_buf.timestamp;
> >
> > @@ -46,6 +54,7 @@ void cedrus_device_run(void *priv)
> >
> > V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
> >
> > run.mpeg2.quantization = cedrus_find_control_data(ctx,
> >
> > V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
> >
> > + run.dst->is_held = false;
> >
> > break;
> >
> > case V4L2_PIX_FMT_H264_SLICE:
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c index
> > a942cd9bed57..99fedec80224 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > @@ -122,7 +122,7 @@ static irqreturn_t cedrus_irq(int irq, void *data)
> >
> > dev->dec_ops[ctx->current_codec]->irq_clear(ctx);
> >
> > src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> >
> > - dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > if (!src_buf || !dst_buf) {
> >
> > v4l2_err(&dev->v4l2_dev,
> >
> > @@ -136,8 +136,10 @@ static irqreturn_t cedrus_irq(int irq, void *data)
> >
> > state = VB2_BUF_STATE_DONE;
> >
> > v4l2_m2m_buf_done(src_buf, state);
> >
> > - v4l2_m2m_buf_done(dst_buf, state);
> > -
> > + if (!dst_buf->is_held) {
> > + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + v4l2_m2m_buf_done(dst_buf, state);
> > + }
> >
> > v4l2_m2m_job_finish(ctx->dev->m2m_dev, ctx->fh.m2m_ctx);
> >
> > return IRQ_HANDLED;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_video.c index
> > eeee3efd247b..5153b2bba21e 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > @@ -515,6 +515,7 @@ int cedrus_queue_init(void *priv, struct vb2_queue
> > *src_vq,>
> > src_vq->type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
> > src_vq->io_modes = VB2_MMAP | VB2_DMABUF;
> > src_vq->drv_priv = ctx;
> >
> > + src_vq->subsystem_flags =
VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
>
> This isn't quite right: this flag should only be set for formats that
> support slicing. So cedrus_s_fmt_vid_out() should set this for H264, but
> clear it for MPEG2.
>
> Looking at the cedrus code it seems that it does not set an initial default
> output format after opening the video device. This seems wrong to me. If it
> did set a default output format, then src_vq->subsystem_flags should set
> this flag corresponding to the default output format.
Ok, I'll base v2 series on your "cedrus: v4l2-compliance fixes", because it has
some useful changes for this case.
Best regards,
Jernej
>
> > src_vq->buf_struct_size = sizeof(struct cedrus_buffer);
> > src_vq->min_buffers_needed = 1;
> > src_vq->ops = &cedrus_qops;
>
> Regards,
>
> Hans
_______________________________________________
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/4] gpio/aspeed: Fix incorrect number of banks
From: Rashmica Gupta @ 2019-09-04 23:17 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-aspeed, Bartosz Golaszewski, Andrew Jeffery, Linus Walleij,
Linux Kernel Mailing List, open list:GPIO SUBSYSTEM, Joel Stanley,
linux-arm Mailing List
In-Reply-To: <CAHp75Vd_6Rpt5=BjzV8YFCiFP7qsRrYHHo7+=gWwnZH-zT9jNw@mail.gmail.com>
On Wed, 2019-09-04 at 19:27 +0300, Andy Shevchenko wrote:
> On Wed, Sep 4, 2019 at 9:14 AM Rashmica Gupta <rashmica.g@gmail.com>
> wrote:
> > Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')
> >
> > Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> > /* Allocate a cache of the output registers */
> > - banks = gpio->config->nr_gpios >> 5;
> > + banks = (gpio->config->nr_gpios >> 5) + 1;
>
> Shouldn't be rather DIV_ROUND_UP(nr_gpios, sizeof(u32)) ?
I agree that DIV_ROUND_UP is the right thing to use here, but wouldn't
it be DIV_ROUND_UP(nr_gpios, 32)?
>
> > gpio->dcache = devm_kcalloc(&pdev->dev,
> > banks, sizeof(u32),
> > GFP_KERNEL);
>
>
_______________________________________________
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 4/4] gpio: Update documentation with ast2600 controllers
From: Rashmica Gupta @ 2019-09-04 23:22 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-aspeed, Andrew Jeffery, Linus Walleij, LKML, linux-gpio,
Joel Stanley, arm-soc
In-Reply-To: <CAMpxmJUGm3Zs8VHwHnXTQ2cKnpF0caR=7V4bBi1_sy1U2mWc0g@mail.gmail.com>
On Wed, 2019-09-04 at 09:02 +0200, Bartosz Golaszewski wrote:
> śr., 4 wrz 2019 o 08:13 Rashmica Gupta <rashmica.g@gmail.com>
> napisał(a):
>
> Again, this needs a proper commit description
I figured as similar patches have gone through with just the one line
and there isn't anything more to say that the one line message that
this would be ok.
>and the subject should
> start with "dt-bindings: ...".
>
True.
> You also need to Cc the device-tree maintainers. Use
> scripts/get_maintainer.pl to list all people that should get this
> patch.
Must have missed that one somehow.
>
> Bart
>
> > Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> > ---
> > Documentation/devicetree/bindings/gpio/gpio-aspeed.txt | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/gpio-
aspeed.txt
> > b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
> > index 7e9b586770b0..cd388797e07c 100644
> > --- a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
> > +++ b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
> > @@ -2,7 +2,8 @@ Aspeed GPIO controller Device Tree Bindings
> > -------------------------------------------
> >
> > Required properties:
> > -- compatible : Either "aspeed,ast2400-gpio" or
> > "aspeed,ast2500-gpio"
> > +- compatible : Either "aspeed,ast2400-gpio",
> > "aspeed,ast2500-gpio",
> > + "aspeed,ast2600-gpio", or
> > "aspeed,ast2600-1-8v-gpio"
> >
> > - #gpio-cells : Should be two
> > - First cell is the GPIO line number
> > --
> > 2.20.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 v12 10/12] namei: aggressively check for nd->root escape on ".." resolution
From: Al Viro @ 2019-09-04 23:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, J. Bruce Fields,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, Aleksa Sarai,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, David Howells, linux-parisc, linux-m68k,
Linux API, Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <CAHk-=wg7Wq1kj8kZ+SSpfU_o991woW60NWca9yBA2ccs2eNx8Q@mail.gmail.com>
On Wed, Sep 04, 2019 at 03:38:20PM -0700, Linus Torvalds wrote:
> On Wed, Sep 4, 2019 at 3:31 PM David Howells <dhowells@redhat.com> wrote:
> >
> > It ought to be reasonably easy to make them per-sb at least, I think. We
> > don't allow cross-super rename, right?
>
> Right now the sequence count handling very much depends on it being a
> global entity on the reader side, at least.
>
> And while the rename sequence count could (and probably should) be
> per-sb, the same is very much not true of the mount one.
Huh? That will cost us having to have a per-superblock dentry
hash table; recall that lockless lockup can give false negatives
if something gets moved from chain to chain, and rename_lock is
first and foremost used to catch those and retry. If we split
it on per-superblock basis, we can't have dentries from different
superblocks in the same chain anymore...
_______________________________________________
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 3/4] gpio: Add in ast2600 details to Aspeed driver
From: Rashmica Gupta @ 2019-09-04 23:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-aspeed, Bartosz Golaszewski, Andrew Jeffery, Linus Walleij,
Linux Kernel Mailing List, open list:GPIO SUBSYSTEM, Joel Stanley,
linux-arm Mailing List
In-Reply-To: <CAHp75Ve0zEkuD-75aZ6FU+A=DvX8NvVvY3n9p_pYDyfa76sxoQ@mail.gmail.com>
On Wed, 2019-09-04 at 19:30 +0300, Andy Shevchenko wrote:
> On Wed, Sep 4, 2019 at 9:14 AM Rashmica Gupta <rashmica.g@gmail.com>
> wrote:
> > The ast2600 has two gpio controllers, one for 3.6V GPIOS and one
> > for 1.8V GPIOS.
> >
> > Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> > - for (i = 0; i < ARRAY_SIZE(aspeed_gpio_banks); i++) {
> > + banks = (gpio->config->nr_gpios >> 5) + 1;
>
> Same comment as per the other patch.
>
> > + for (i = 0; i < banks; i++) {
> > +static const struct aspeed_bank_props ast2600_bank_props[] = {
> > + /* input output */
> > + {5, 0xffffffff, 0x0000ffff}, /* U/V/W/X */
> > + {6, 0xffff0000, 0x0fff0000}, /* Y/Z */
>
> Perhaps GENMASK() for all values?
Perhaps this and your other comments below would be best addressed in
an additional cleanup patch? This patch follows the formatting of the
existing code and it's not very clean to differ from that or to change
the formatting of the current code in this patch.
>
> > + { },
>
> Comma is not needed here.
>
> > +};
> > +
> > +static const struct aspeed_gpio_config ast2600_config =
> > + /* 208 3.6V GPIOs */
> > + { .nr_gpios = 208, .props = ast2600_bank_props, };
>
> Seems curly braces missed their places.
>
> > +static const struct aspeed_bank_props ast2600_1_8v_bank_props[] =
> > {
> > + /* input output */
> > + {1, 0x0000000f, 0x0000000f}, /* E */
>
> GENMASK()?
>
> > + { },
>
> No comma.
>
> > +};
> > +static const struct aspeed_gpio_config ast2600_1_8v_config =
> > + /* 36 1.8V GPIOs */
> > + { .nr_gpios = 36, .props = ast2600_1_8v_bank_props, };
>
> Location of the curly braces?
>
_______________________________________________
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 10/12] namei: aggressively check for nd->root escape on ".." resolution
From: Linus Torvalds @ 2019-09-04 23:44 UTC (permalink / raw)
To: Al Viro
Cc: linux-ia64, Linux-sh list, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, Linux List Kernel Mailing, J. Bruce Fields,
open list:KERNEL SELFTEST FRAMEWORK, sparclinux, Shuah Khan,
linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai, Jiri Olsa,
Alexander Shishkin, Ingo Molnar, Linux ARM, linux-mips,
linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn, Aleksa Sarai,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, David Howells, linux-parisc, linux-m68k,
Linux API, Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
alpha, linux-fsdevel, Andrew Morton, linuxppc-dev,
Linux Containers
In-Reply-To: <20190904232911.GN1131@ZenIV.linux.org.uk>
On Wed, Sep 4, 2019 at 4:29 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Wed, Sep 04, 2019 at 03:38:20PM -0700, Linus Torvalds wrote:
> > On Wed, Sep 4, 2019 at 3:31 PM David Howells <dhowells@redhat.com> wrote:
> > >
> > > It ought to be reasonably easy to make them per-sb at least, I think. We
> > > don't allow cross-super rename, right?
> >
> > Right now the sequence count handling very much depends on it being a
> > global entity on the reader side, at least.
> >
> > And while the rename sequence count could (and probably should) be
> > per-sb, the same is very much not true of the mount one.
>
> Huh? That will cost us having to have a per-superblock dentry
> hash table; recall that lockless lockup can give false negatives
> if something gets moved from chain to chain, and rename_lock is
> first and foremost used to catch those and retry. If we split
> it on per-superblock basis, we can't have dentries from different
> superblocks in the same chain anymore...
That's exactly the "very much depends on it being a global entity on
the reader side" thing.
I'm not convinced that's the _only_ way to handle things. Maybe a
combination of (wild handwaving) per-hashqueue sequence count and some
clever scheme for pathname handling could work.
I've not personally seen a load where the global rename lock has been
a problem (very few things really do a lot of renames), but
system-wide locks do make me nervous.
We have other (and worse) ones. tasklist_lock comes to mind.
Linus
_______________________________________________
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/1] soc: qcom: geni: Provide parameter error checking
From: Stephen Boyd @ 2019-09-04 23:45 UTC (permalink / raw)
To: Bjorn Andersson, Lee Jones
Cc: linux-arm-msm, agross, linux-kernel, linux-arm-kernel
In-Reply-To: <20190904182732.GE574@tuxbook-pro>
Quoting Bjorn Andersson (2019-09-04 11:27:32)
> On Wed 04 Sep 01:45 PDT 2019, Lee Jones wrote:
>
> > On Tue, 03 Sep 2019, Bjorn Andersson wrote:
> >
> > > On Tue 03 Sep 06:50 PDT 2019, Lee Jones wrote:
> > >
> > > > When booting with ACPI, the Geni Serial Engine is not set as the I2C/SPI
> > > > parent and thus, the wrapper (parent device) is unassigned. This causes
> > > > the kernel to crash with a null dereference error.
> > > >
> > >
> > > Now I see what you did in 8bc529b25354; i.e. stubbed all the other calls
> > > between the SE and wrapper.
> > >
> > > Do you think it would be possible to resolve the _DEP link to QGP[01]
> > > somehow?
> >
> > I looked at QGP{0,1}, but did not see it represented in the current
> > Device Tree implementation and thus failed to identify it. Do you
> > know what it is? Does it have a driver in Linux already?
> >
>
> QGP0 is the same hardware block as &qupv3_id_0, but apparently both are
> only representing a smaller part - and different ones.
>
> But conceptually both represents the wrapper...
>
> > > For the clocks workarounds this could be resolved by us
> > > representing that relationship using device_link and just rely on
> > > pm_runtime to propagate the clock state.
> >
> > That is not allowed when booting ACPI. The Clock/Regulator frameworks
> > are not to be used in this use-case, hence why all of the calls to
> > these frameworks are "stubbed out". If we wanted to properly
> > implement power management, we would have to create a driver/subsystem
> > similar to the "Windows-compatible System Power Management Controller"
> > (PEP). Without documentation for the PEP, this would be an impossible
> > task. A request for the aforementioned documentation has been put in
> > to Lenovo/Qualcomm. Hopefully something appears soon.
> >
>
> I see, so the PEP states needs to be parsed and associated with each
> device and we would use pm_runtime to toggle between the states and
> device_links to ensure that _DEP nodes are powered in appropriate order.
>
> That seems reasonable and straight forward and the reliance on
> pm_runtime will make the DT case cleaner as well.
I think we tried to push for pm_runtime here but it was rejected because
of a missing interconnect framework? See
https://marc.info/?l=devicetree&m=152002327106864&w=2
>
> > > For the DMA operation, iiuc it's the wrapper that implements the DMA
> > > engine involved, but I'm guessing the main reason for mapping buffers on
> > > the wrapper is so that it ends up being associated with the iommu
> > > context of the wrapper.
> >
> > Judging by the code alone, the wrapper doesn't sound like it does much
> > at all. It seems to only have a single (version) register (at least
> > that is the only register that's used). The only registers it
> > reads/writes are those of the calling device, whether that be I2C, SPI
> > or UART.
> >
> > Device Tree represents the wrapper's relationship with the I2C (and
> > SPI/UART) Serial Engine (SE) devices as parent-child ones, with the
> > wrapper being the parent and SE the child. Whether this is a true
> > representation of the hardware or just a tactic used for convenience
> > is not clear, but the same representation does not exist in ACPI.
> >
> > In the current Linux implementation, the buffer belongs to the SE
> > (obtained by the child (e.g. I2C) SE by fetching the parent's
> > (wrapper's) device data using the standard platform helpers) but the
> > register-set used to control the DMA transactions belong to the SE
> > devices.
> >
>
> Yeah, I saw this as well. If all the SEs where the wrappers iommu domain
> things should work fine by mapping it on the se->dev, regardless of the
> device's being linked together.
>
> The remaining relationship to the wrapper would then be reduced to the
> read of the version to check for 1.0 or 1.1 hardware in the SPI driver,
> which can be replaced by the assumption that we're on 1.1.
Could this be described in the DT compatible for the SE in the future
instead of reading it from the wrapper register space?
>
> > > Are the SMMU contexts at all represented in the ACPI world and if so do
> > > you know how the wrapper vs SEs are bound to contexts? Can we map on
> > > se->dev when wrapper is NULL (or perhaps always?)?
> >
> > Yes, the SMMU devices are represented in ACPI (MMU0) and (MMU1). They
> > share the same register addresses as the SMMU devices located in
> > arch/arm64/boot/dts/qcom/sdm845.dtsi.
> >
>
> Right but this only describes the IOMMU devices, I don't see any
> information about how individual client devices relates to the various
> IOMMU contexts.
The only thread I recall describing this is
https://lkml.kernel.org/r/945b6c00-dde6-6ec7-4577-4cc0d034796b@codeaurora.org
>
> > With this simple parameter checking patch, the SE falls back to using
> > FIFO mode to transmit data and continues to work flawlessly. IMHO
> > this should be applied in the first instance, as it fixes a real (null
> > dereference) bug which currently resides in the Mainline kernel.
> >
>
> Per the current driver design the wrapper device is the parent of the
> SE, I should have seen that 8bc529b25354 was the beginning of a game of
> whac-a-mole circumventing this design. Sorry for not spotting this
> earlier.
>
> But if this is the one whack left to get the thing to boot then I think
> we should merge it.
>
Agreed.
_______________________________________________
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