* Re: [PATCH] ARM: dts: aspeed-g4: Add all flash chips
From: Andrew Jeffery @ 2019-09-05 0:33 UTC (permalink / raw)
To: Joel Stanley, Cédric Le Goater
Cc: devicetree, linux-aspeed, linux-arm-kernel
In-Reply-To: <20190905000221.31445-1-joel@jms.id.au>
On Thu, 5 Sep 2019, at 09:32, Joel Stanley wrote:
> The FMC supports five chip selects, so describe the five possible flash
> chips.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index e465cda40fe7..dffb595d30e4 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -67,6 +67,26 @@
> compatible = "jedec,spi-nor";
> status = "disabled";
> };
> + flash@1 {
> + reg = < 1 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
> + flash@2 {
> + reg = < 2 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
> + flash@3 {
> + reg = < 3 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
> + flash@4 {
> + reg = < 4 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
The FMC supports parallel NOR and NAND interfaces too, but so far no-one has
cared for these options, so if they ever do we'll fix it then.
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
_______________________________________________
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: manual merge of the mips tree with the arm-soc tree
From: Stephen Rothwell @ 2019-09-05 0:18 UTC (permalink / raw)
To: Ralf Baechle, James Hogan, Olof Johansson, Arnd Bergmann, ARM
Cc: Paul Cercueil, Paul Burton, Linux Next Mailing List,
Linux Kernel Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1331 bytes --]
Hi all,
Today's linux-next merge of the mips tree got a conflict in:
drivers/video/fbdev/Makefile
between commit:
c7b46e0c33c5 ("fbdev: remove w90x900/nuc900 platform drivers")
from the arm-soc tree and commit:
e305bff3a706 ("video/fbdev: Drop JZ4740 driver")
from the mips tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/video/fbdev/Makefile
index aab7155884ea,49502d6256cb..000000000000
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@@ -116,7 -116,7 +116,6 @@@ obj-y += om
obj-$(CONFIG_XEN_FBDEV_FRONTEND) += xen-fbfront.o
obj-$(CONFIG_FB_CARMINE) += carminefb.o
obj-$(CONFIG_FB_MB862XX) += mb862xx/
- obj-$(CONFIG_FB_JZ4740) += jz4740_fb.o
-obj-$(CONFIG_FB_NUC900) += nuc900fb.o
obj-$(CONFIG_FB_PUV3_UNIGFX) += fb-puv3.o
obj-$(CONFIG_FB_HYPERV) += hyperv_fb.o
obj-$(CONFIG_FB_OPENCORES) += ocfb.o
[-- 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: next/master boot: 310 boots: 11 failed, 292 passed with 6 offline, 1 untried/unknown (next-20190904)
From: Kevin Hilman @ 2019-09-05 0:15 UTC (permalink / raw)
To: Matthias Brugger, Steven Liu
Cc: Mark Brown, linux-mediatek, linux-arm-kernel,
kernel-build-reports
In-Reply-To: <20190904192725.GI4348@sirena.co.uk>
[ + Steven Liu who donated this board to my kernelCI lab ]
Mark Brown <broonie@kernel.org> writes:
> On Wed, Sep 04, 2019 at 12:05:57PM -0700, kernelci.org bot wrote:
>
> Since 30th August -next fails to boot with no kernel output on
> mt7622-rfb1:
>
>> arm64:
>> defconfig:
>> gcc-8:
>> mt7622-rfb1: 1 failed lab
>>
>> defconfig+CONFIG_RANDOMIZE_BASE=y:
>> gcc-8:
>> mt7622-rfb1: 1 failed lab
>
> There's logging from ATF so it looks like we try to boot the kernel:
>
> Starting kernel ...
>
> [ATF][ 36.199793]save kernel info
> [ATF][ 36.202824]Kernel_EL2
> [ATF][ 36.205580]Kernel is 64Bit
> [ATF][ 36.208768]pc=0x40080000, r0=0x5cf48000, r1=0x0
> INFO: BL3-1: Preparing for EL3 exit to normal world, Kernel
> INFO: BL3-1: Next image address = 0x40080000
> INFO: BL3-1: Next image spsr = 0x3c9
> [ATF][ 36.227037]el3_exit
>
> but no output. More details including full logs at:
>
> https://kernelci.org/boot/id/5d6fe70059b514164ef1224d/
> https://kernelci.org/boot/id/5d6fe6e259b514164ef12243/
Bisected down to this commit[1], full bisect log here[2]. It didn't
revert cleanly on top of next-20190904, so I didn't get any further.
Kevin
[1]
419e2f1838819e954071dfa1d1f820ab3386ada1 is the first bad commit
commit 419e2f1838819e954071dfa1d1f820ab3386ada1
Author: Christoph Hellwig <hch@lst.de>
Date: Mon Aug 26 09:03:44 2019 +0200
dma-mapping: remove arch_dma_mmap_pgprot
arch_dma_mmap_pgprot is used for two things:
1) to override the "normal" uncached page attributes for mapping
memory coherent to devices that can't snoop the CPU caches
2) to provide the special DMA_ATTR_WRITE_COMBINE semantics on older
arm systems and some mips platforms
Replace one with the pgprot_dmacoherent macro that is already provided
by arm and much simpler to use, and lift the DMA_ATTR_WRITE_COMBINE
handling to common code with an explicit arch opt-in.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
Acked-by: Paul Burton <paul.burton@mips.com> # mips
arch/arm/Kconfig | 2 +-
arch/arm/mm/dma-mapping.c | 6 ------
arch/arm64/Kconfig | 1 -
arch/arm64/include/asm/pgtable.h | 4 ++++
arch/arm64/mm/dma-mapping.c | 6 ------
arch/m68k/Kconfig | 1 -
arch/m68k/include/asm/pgtable_mm.h | 3 +++
arch/m68k/kernel/dma.c | 3 +--
arch/mips/Kconfig | 2 +-
arch/mips/mm/dma-noncoherent.c | 8 --------
include/linux/dma-noncoherent.h | 13 +++++++++++--
kernel/dma/Kconfig | 12 +++++++++---
kernel/dma/mapping.c | 8 +++++---
13 files changed, 35 insertions(+), 34 deletions(-)
bisect run success
[2]
$ git bisect log
git bisect start
# bad: [35394d031b710e832849fca60d0f53b513f0c390] Add linux-next specific files for 20190904
git bisect bad 35394d031b710e832849fca60d0f53b513f0c390
# good: [089cf7f6ecb266b6a4164919a2e69bd2f938374a] Linux 5.3-rc7
git bisect good 089cf7f6ecb266b6a4164919a2e69bd2f938374a
# bad: [493424779be81b03fb4aca89cc05ba95e9fc0c31] Merge remote-tracking branch 'crypto/master'
git bisect bad 493424779be81b03fb4aca89cc05ba95e9fc0c31
# bad: [58a02f90fddfdc9e4dfbd6579ff788ffdc22afe4] Merge remote-tracking branch 'hid/for-next'
git bisect bad 58a02f90fddfdc9e4dfbd6579ff788ffdc22afe4
# bad: [27c3f6e1d84b47def9060fd481be92838d819a9b] Merge remote-tracking branch 'csky/linux-next'
git bisect bad 27c3f6e1d84b47def9060fd481be92838d819a9b
# good: [f119c164735d85f2a41d14503cb9933d219c539e] arm-soc: document merges
git bisect good f119c164735d85f2a41d14503cb9933d219c539e
# bad: [e87b432d6c45697defc03eb69261661060c85245] Merge remote-tracking branch 'actions/for-next'
git bisect bad e87b432d6c45697defc03eb69261661060c85245
# good: [1ab97157f64dadb44d029096c6a92305d6631ab2] Merge remote-tracking branch 'kbuild/for-next'
git bisect good 1ab97157f64dadb44d029096c6a92305d6631ab2
# good: [ac12cf85d682a2c1948210c65f7fb21ef01dd9f6] Merge branches 'for-next/52-bit-kva', 'for-next/cpu-topology', 'for-next/error-injection', 'for-next/perf', 'for-next/psci-cpuidle', 'for-next/rng', 'for-next/smpboot', 'for-next/tbi' and 'for-next/tlbi' into for-next/core
git bisect good ac12cf85d682a2c1948210c65f7fb21ef01dd9f6
# bad: [4934d349f6e5afc9345a44acb0daa3066594088a] Merge remote-tracking branch 'asm-generic/master'
git bisect bad 4934d349f6e5afc9345a44acb0daa3066594088a
# good: [5251a1c90f7f4e458dc3154920e09624311f54b6] Merge remote-tracking branch 'compiler-attributes/compiler-attributes'
git bisect good 5251a1c90f7f4e458dc3154920e09624311f54b6
# skip: [38c38cb73223218f6eedf485280917af1f8a0af2] mmc: queue: use bigger segments if DMA MAP layer can merge the segments
git bisect skip 38c38cb73223218f6eedf485280917af1f8a0af2
# bad: [419e2f1838819e954071dfa1d1f820ab3386ada1] dma-mapping: remove arch_dma_mmap_pgprot
git bisect bad 419e2f1838819e954071dfa1d1f820ab3386ada1
# good: [5518ea1ad2c0c7f38d067f621d9349e6a11c8879] unicore32: remove the unused pgprot_dmacoherent define
git bisect good 5518ea1ad2c0c7f38d067f621d9349e6a11c8879
# good: [b898e50f9f49f7d90f3bca94ac046145072034a2] arm-nommu: remove the unused pgprot_dmacoherent define
git bisect good b898e50f9f49f7d90f3bca94ac046145072034a2
_______________________________________________
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] iio: adc: meson_saradc: Fix memory allocation order
From: Kevin Hilman @ 2019-09-05 0:02 UTC (permalink / raw)
To: Remi Pommarel, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler
Cc: Neil Armstrong, Martin Blumenstingl, Elie Roudninski,
linux-kernel, linux-iio, Remi Pommarel, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20190901105410.23567-1-repk@triplefau.lt>
Remi Pommarel <repk@triplefau.lt> writes:
> meson_saradc's irq handler uses priv->regmap so make sure that it is
> allocated before the irq get enabled.
>
> This also fixes crash when CONFIG_DEBUG_SHIRQ is enabled, as device
> managed resources are freed in the inverted order they had been
> allocated, priv->regmap was freed before the spurious fake irq that
> CONFIG_DEBUG_SHIRQ adds called the handler.
>
> Reported-by: Elie Roudninski <xademax@gmail.com>
> Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Reviewed-by: Kevin Hilman <khilman@baylibre.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] ARM: dts: aspeed-g4: Add all flash chips
From: Joel Stanley @ 2019-09-05 0:02 UTC (permalink / raw)
To: Andrew Jeffery, Cédric Le Goater
Cc: devicetree, linux-aspeed, linux-arm-kernel
The FMC supports five chip selects, so describe the five possible flash
chips.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index e465cda40fe7..dffb595d30e4 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -67,6 +67,26 @@
compatible = "jedec,spi-nor";
status = "disabled";
};
+ flash@1 {
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
+ flash@2 {
+ reg = < 2 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
+ flash@3 {
+ reg = < 3 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
+ flash@4 {
+ reg = < 4 >;
+ compatible = "jedec,spi-nor";
+ status = "disabled";
+ };
};
spi: spi@1e630000 {
--
2.23.0.rc1
_______________________________________________
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/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
* 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 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: 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 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 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 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/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] 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 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: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: 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 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: 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 -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 -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 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 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 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: 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
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