* Re: [PATCH 03/34] net/ceph: convert put_page() to put_user_page*()
From: Jeff Layton @ 2019-08-02 22:32 UTC (permalink / raw)
To: john.hubbard, Andrew Morton
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Ira Weiny, ceph-devel, devel, rds-devel,
Sage Weil, linux-rdma, x86, amd-gfx, Christoph Hellwig,
Jason Gunthorpe, xen-devel, Ilya Dryomov, devel, linux-media,
John Hubbard, intel-gfx, linux-block, Jérôme Glisse,
linux-rpi-kernel, Dan Williams, linux-arm-kernel, linux-nfs,
netdev, LKML, linux-xfs, linux-crypto, linux-fsdevel,
David S . Miller
In-Reply-To: <20190802022005.5117-4-jhubbard@nvidia.com>
On Thu, 2019-08-01 at 19:19 -0700, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Ilya Dryomov <idryomov@gmail.com>
> Cc: Sage Weil <sage@redhat.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: ceph-devel@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> net/ceph/pagevec.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/net/ceph/pagevec.c b/net/ceph/pagevec.c
> index 64305e7056a1..c88fff2ab9bd 100644
> --- a/net/ceph/pagevec.c
> +++ b/net/ceph/pagevec.c
> @@ -12,13 +12,7 @@
>
> void ceph_put_page_vector(struct page **pages, int num_pages, bool dirty)
> {
> - int i;
> -
> - for (i = 0; i < num_pages; i++) {
> - if (dirty)
> - set_page_dirty_lock(pages[i]);
> - put_page(pages[i]);
> - }
> + put_user_pages_dirty_lock(pages, num_pages, dirty);
> kvfree(pages);
> }
> EXPORT_SYMBOL(ceph_put_page_vector);
This patch looks sane enough. Assuming that the earlier patches are OK:
Acked-by: Jeff Layton <jlayton@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: rockchip: Add pin names for rk3288-veyron fievel
From: Heiko Stuebner @ 2019-08-02 22:35 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Mark Rutland, devicetree, linux-kernel, Douglas Anderson,
linux-rockchip, Rob Herring, linux-arm-kernel
In-Reply-To: <20190801220354.142933-1-mka@chromium.org>
Am Freitag, 2. August 2019, 00:03:54 CEST schrieb Matthias Kaehlcke:
> This is like commit 0ca87bd5baa6 ("ARM: dts: rockchip: Add pin names
> for rk3288-veyron-jerry") and other similar commits, but for the
> veyron fievel board (and tiger, which includes the fievel .dtsi).
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
applied for 5.4
Thanks
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: rockchip: A few fixes for veyron-{fievel, tiger}
From: Heiko Stuebner @ 2019-08-02 22:36 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Mark Rutland, devicetree, linux-kernel, Douglas Anderson,
linux-rockchip, Rob Herring, linux-arm-kernel
In-Reply-To: <20190731151527.122002-1-mka@chromium.org>
Am Mittwoch, 31. Juli 2019, 17:15:27 CEST schrieb Matthias Kaehlcke:
> Fix/improve a few things for veyron fievel/tiger:
>
> - move 'vccsys' regulator from tiger to fievel, both boards
> have it (and tiger includes the fievel .dtsi)
> - move 'ext_gmac' node below regulators
> - fix GPIO ids of vcc5_host1 and vcc5_host2 regulators
> - remove reset configuration from 'gmac' node, this is already done
> in rk3288.dtsi
> - fixed style issues of some multi-line comments
> - switch 'vcc18_lcdt', 'vdd10_lcd' and 'vcc33_ccd' regulators off
> during suspend
> - no pull-up on the Bluetooth wake-up pin, there is an external
> pull-up. The signal is active low, add the 'bt_host_wake_l'
> pinctrl config
> - move BC 1.2 pins up in the pinctrl config to keep 'wake only' pins
> separate
> - add BC 1.2 pins to sleep config
>
> Fixes: 0067692b662e ("ARM: dts: rockchip: add veyron-fievel board")
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
applied for 5.4
Thanks
Heiko
_______________________________________________
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/6] dt-bindings: arm: fsl: Add the S32V234-EVB board
From: Rob Herring @ 2019-08-02 22:38 UTC (permalink / raw)
To: Stefan-gabriel Mirea
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Eddy Petrisor,
will@kernel.org, corbet@lwn.net, gregkh@linuxfoundation.org,
jslaby@suse.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Leo Li,
linux-serial@vger.kernel.org, catalin.marinas@arm.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802194702.30249-2-stefan-gabriel.mirea@nxp.com>
On Fri, Aug 2, 2019 at 1:47 PM Stefan-gabriel Mirea
<stefan-gabriel.mirea@nxp.com> wrote:
>
> From: Eddy Petrișor <eddy.petrisor@nxp.com>
>
> Add entry for the NXP S32V234 Customer Evaluation Board to the board/SoC
> bindings.
>
> Signed-off-by: Eddy Petrișor <eddy.petrisor@nxp.com>
> Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 7294ac36f4c0..104d60a11177 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -309,4 +309,10 @@ properties:
> - fsl,ls2088a-rdb
> - const: fsl,ls2088a
>
> + - description: S32V234 Customer Evaluation Board
Most of the entries in this file are for all the boards for an SoC.
> + items:
> + - enum:
> + - fsl,s32v234-evb
If that's not going to be the case here, you can use 'const' here.
> + - const: fsl,s32v234
> +
> ...
> --
> 2.22.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm64 fixes for 5.3-rc3
From: pr-tracker-bot @ 2019-08-02 23:20 UTC (permalink / raw)
To: Catalin Marinas; +Cc: will, Linus Torvalds, linux-kernel, linux-arm-kernel
In-Reply-To: <20190802171753.GA56033@arrakis.emea.arm.com>
The pull request you sent on Fri, 2 Aug 2019 18:17:55 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a507f25d1c2048c136f6834f10966510b62af987
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64/prefetch: fix a -Wtype-limits warning
From: Robin Murphy @ 2019-08-02 23:46 UTC (permalink / raw)
To: Qian Cai, will, catalin.marinas; +Cc: rrichter, linux-kernel, linux-arm-kernel
In-Reply-To: <1564780084-29591-1-git-send-email-cai@lca.pw>
On 2019-08-02 10:08 pm, Qian Cai wrote:
> The commit d5370f754875 ("arm64: prefetch: add alternative pattern for
> CPUs without a prefetcher") introduced MIDR_IS_CPU_MODEL_RANGE() to be
> used in has_no_hw_prefetch() with rv_min=0 which generates a compilation
> warning from GCC,
>
> In file included from ./arch/arm64/include/asm/cache.h:8,
> from ./include/linux/cache.h:6,
> from ./include/linux/printk.h:9,
> from ./include/linux/kernel.h:15,
> from ./include/linux/cpumask.h:10,
> from arch/arm64/kernel/cpufeature.c:11:
> arch/arm64/kernel/cpufeature.c: In function 'has_no_hw_prefetch':
> ./arch/arm64/include/asm/cputype.h:59:26: warning: comparison of
> unsigned expression >= 0 is always true [-Wtype-limits]
> _model == (model) && rv >= (rv_min) && rv <= (rv_max); \
> ^~
> arch/arm64/kernel/cpufeature.c:889:9: note: in expansion of macro
> 'MIDR_IS_CPU_MODEL_RANGE'
> return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
> ^~~~~~~~~~~~~~~~~~~~~~~
>
> Fix it by making rv_min=1.
With what justification? Are you suggesting revision 0 variant 0 of this
CPU has suddenly grown a prefetcher? Or that arbitrarily perturbing
bounds until a warning shuts up is a fine development strategy, because
a quiet build for people who like turning on random extra warnings is
more important than correct functionality?
Robin.
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/arm64/kernel/cpufeature.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index f29f36a65175..7d15cf6d62c1 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -883,7 +883,7 @@ static bool has_no_hw_prefetch(const struct arm64_cpu_capabilities *entry, int _
>
> /* Cavium ThunderX pass 1.x and 2.x */
> return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
> - MIDR_CPU_VAR_REV(0, 0),
> + MIDR_CPU_VAR_REV(0, 1),
> MIDR_CPU_VAR_REV(1, MIDR_REVISION_MASK));
> }
>
>
_______________________________________________
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 v2 0/4] net: phy: Add AST2600 MDIO support
From: David Miller @ 2019-08-03 0:33 UTC (permalink / raw)
To: andrew
Cc: mark.rutland, andrew, f.fainelli, linux-aspeed, devicetree,
netdev, linux-kernel, robh+dt, joel, linux-arm-kernel, hkallweit1
In-Reply-To: <20190731053959.16293-1-andrew@aj.id.au>
From: Andrew Jeffery <andrew@aj.id.au>
Date: Wed, 31 Jul 2019 15:09:55 +0930
> v2 of the ASPEED MDIO series addresses comments from Rob on the devicetree
> bindings and Andrew on the driver itself.
>
> v1 of the series can be found here:
>
> http://patchwork.ozlabs.org/cover/1138140/
>
> Please review!
Series applied, thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] arm64/prefetch: fix a -Wtype-limits warning
From: Qian Cai @ 2019-08-03 0:33 UTC (permalink / raw)
To: will, catalin.marinas
Cc: rrichter, Qian Cai, robin.murphy, linux-kernel, linux-arm-kernel
The commit d5370f754875 ("arm64: prefetch: add alternative pattern for
CPUs without a prefetcher") introduced MIDR_IS_CPU_MODEL_RANGE() to be
used in has_no_hw_prefetch() with rv_min=0 which generates a compilation
warning from GCC,
In file included from ./arch/arm64/include/asm/cache.h:8,
from ./include/linux/cache.h:6,
from ./include/linux/printk.h:9,
from ./include/linux/kernel.h:15,
from ./include/linux/cpumask.h:10,
from arch/arm64/kernel/cpufeature.c:11:
arch/arm64/kernel/cpufeature.c: In function 'has_no_hw_prefetch':
./arch/arm64/include/asm/cputype.h:59:26: warning: comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
_model == (model) && rv >= (rv_min) && rv <= (rv_max); \
^~
arch/arm64/kernel/cpufeature.c:889:9: note: in expansion of macro
'MIDR_IS_CPU_MODEL_RANGE'
return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
^~~~~~~~~~~~~~~~~~~~~~~
Fix it by making "rv" a "s32".
Signed-off-by: Qian Cai <cai@lca.pw>
---
v2: Use "s32" for "rv", so "variant 0/revision 0" can be covered.
arch/arm64/include/asm/cputype.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index e7d46631cc42..d52fe8651c2d 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -54,7 +54,7 @@
#define MIDR_IS_CPU_MODEL_RANGE(midr, model, rv_min, rv_max) \
({ \
u32 _model = (midr) & MIDR_CPU_MODEL_MASK; \
- u32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK); \
+ s32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK); \
\
_model == (model) && rv >= (rv_min) && rv <= (rv_max); \
})
--
2.20.1 (Apple Git-117)
_______________________________________________
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] net: mdio-octeon: Fix build error and Kconfig warning
From: David Miller @ 2019-08-03 1:11 UTC (permalink / raw)
To: natechancellor
Cc: devel, andrew, f.fainelli, lkp, kernel-build-reports, gregkh,
rdunlap, willy, broonie, linux-next, netdev, linux-arm-kernel,
hkallweit1
In-Reply-To: <20190731185023.20954-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Wed, 31 Jul 2019 11:50:24 -0700
> arm allyesconfig warns:
>
> WARNING: unmet direct dependencies detected for MDIO_OCTEON
> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
> && 64BIT && HAS_IOMEM [=y] && OF_MDIO [=y]
> Selected by [y]:
> - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC &&
> NETDEVICES [=y] || COMPILE_TEST [=y])
>
> and errors:
>
> In file included from ../drivers/net/phy/mdio-octeon.c:14:
> ../drivers/net/phy/mdio-octeon.c: In function 'octeon_mdiobus_probe':
> ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> function 'writeq'; did you mean 'writeb'?
The proper way to fix this is to include either
linux/io-64-nonatomic-hi-lo.h
or
linux/io-64-nonatomic-lo-hi.h
whichever is appropriate.
_______________________________________________
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: mdio-octeon: Fix build error and Kconfig warning
From: Nathan Chancellor @ 2019-08-03 1:30 UTC (permalink / raw)
To: David Miller
Cc: devel, andrew, f.fainelli, lkp, kernel-build-reports, gregkh,
rdunlap, willy, broonie, linux-next, netdev, linux-arm-kernel,
hkallweit1
In-Reply-To: <20190802.181132.1425585873361511856.davem@davemloft.net>
On Fri, Aug 02, 2019 at 06:11:32PM -0700, David Miller wrote:
> From: Nathan Chancellor <natechancellor@gmail.com>
> Date: Wed, 31 Jul 2019 11:50:24 -0700
>
> > arm allyesconfig warns:
> >
> > WARNING: unmet direct dependencies detected for MDIO_OCTEON
> > Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
> > && 64BIT && HAS_IOMEM [=y] && OF_MDIO [=y]
> > Selected by [y]:
> > - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC &&
> > NETDEVICES [=y] || COMPILE_TEST [=y])
> >
> > and errors:
> >
> > In file included from ../drivers/net/phy/mdio-octeon.c:14:
> > ../drivers/net/phy/mdio-octeon.c: In function 'octeon_mdiobus_probe':
> > ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> > function 'writeq'; did you mean 'writeb'?
>
> The proper way to fix this is to include either
>
> linux/io-64-nonatomic-hi-lo.h
>
> or
>
> linux/io-64-nonatomic-lo-hi.h
>
> whichever is appropriate.
Hmmmm, is that not what I did?
Although I did not know about io-64-nonatomic-hi-lo.h. What is the
difference and which one is needed here?
There is apparently another failure when OF_MDIO is not set, I guess I
can try to look into that as well and respin into a series if
necessary.
Cheers,
Nathan
_______________________________________________
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 31/34] nfs: convert put_page() to put_user_page*()
From: Calum Mackay @ 2019-08-03 1:27 UTC (permalink / raw)
To: john.hubbard, Andrew Morton
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Ira Weiny, calum.mackay, devel, rds-devel,
linux-rdma, x86, amd-gfx, Christoph Hellwig, Jason Gunthorpe,
xen-devel, devel, linux-media, John Hubbard, intel-gfx,
Dan Williams, linux-block, Jérôme Glisse,
linux-rpi-kernel, ceph-devel, Trond Myklebust, linux-arm-kernel,
linux-nfs, netdev, LKML, linux-xfs, linux-crypto, linux-fsdevel,
Anna Schumaker
In-Reply-To: <20190802022005.5117-32-jhubbard@nvidia.com>
On 02/08/2019 3:20 am, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
> Cc: Anna Schumaker <anna.schumaker@netapp.com>
> Cc: linux-nfs@vger.kernel.org
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> fs/nfs/direct.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
> index 0cb442406168..b00b89dda3c5 100644
> --- a/fs/nfs/direct.c
> +++ b/fs/nfs/direct.c
> @@ -278,9 +278,7 @@ ssize_t nfs_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
>
> static void nfs_direct_release_pages(struct page **pages, unsigned int npages)
> {
> - unsigned int i;
> - for (i = 0; i < npages; i++)
> - put_page(pages[i]);
> + put_user_pages(pages, npages);
> }
Since it's static, and only called twice, might it be better to change
its two callers [nfs_direct_{read,write}_schedule_iovec()] to call
put_user_pages() directly, and remove nfs_direct_release_pages() entirely?
thanks,
calum.
>
> void nfs_init_cinfo_from_dreq(struct nfs_commit_info *cinfo,
>
_______________________________________________
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: mdio-octeon: Fix build error and Kconfig warning
From: Matthew Wilcox @ 2019-08-03 1:39 UTC (permalink / raw)
To: Nathan Chancellor
Cc: devel, andrew, f.fainelli, lkp, kernel-build-reports, gregkh,
rdunlap, broonie, linux-next, netdev, David Miller,
linux-arm-kernel, hkallweit1
In-Reply-To: <20190803013031.GA76252@archlinux-threadripper>
On Fri, Aug 02, 2019 at 06:30:31PM -0700, Nathan Chancellor wrote:
> On Fri, Aug 02, 2019 at 06:11:32PM -0700, David Miller wrote:
> > The proper way to fix this is to include either
> >
> > linux/io-64-nonatomic-hi-lo.h
> >
> > or
> >
> > linux/io-64-nonatomic-lo-hi.h
> >
> > whichever is appropriate.
>
> Hmmmm, is that not what I did?
>
> Although I did not know about io-64-nonatomic-hi-lo.h. What is the
> difference and which one is needed here?
Whether you write the high or low 32 bits first. For this, it doesn't
matter, since the compiled driver will never be run on real hardware.
> There is apparently another failure when OF_MDIO is not set, I guess I
> can try to look into that as well and respin into a series if
> necessary.
Thanks for taking care of that!
_______________________________________________
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 31/34] nfs: convert put_page() to put_user_page*()
From: John Hubbard @ 2019-08-03 1:41 UTC (permalink / raw)
To: Calum Mackay, john.hubbard, Andrew Morton
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Ira Weiny, ceph-devel, devel, rds-devel,
linux-rdma, x86, amd-gfx, Christoph Hellwig, Jason Gunthorpe,
xen-devel, devel, linux-media, intel-gfx, linux-block,
Jérôme Glisse, linux-rpi-kernel, Dan Williams,
Trond Myklebust, linux-arm-kernel, linux-nfs, netdev, LKML,
linux-xfs, linux-crypto, linux-fsdevel, Anna Schumaker
In-Reply-To: <1738cb1e-15d8-0bbe-5362-341664f6efc8@oracle.com>
On 8/2/19 6:27 PM, Calum Mackay wrote:
> On 02/08/2019 3:20 am, john.hubbard@gmail.com wrote:
...
> Since it's static, and only called twice, might it be better to change its two callers [nfs_direct_{read,write}_schedule_iovec()] to call put_user_pages() directly, and remove nfs_direct_release_pages() entirely?
>
> thanks,
> calum.
>
>
>> void nfs_init_cinfo_from_dreq(struct nfs_commit_info *cinfo,
>>
Hi Calum,
Absolutely! Is it OK to add your reviewed-by, with the following incremental
patch made to this one?
diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index b00b89dda3c5..c0c1b9f2c069 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -276,11 +276,6 @@ ssize_t nfs_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
return nfs_file_direct_write(iocb, iter);
}
-static void nfs_direct_release_pages(struct page **pages, unsigned int npages)
-{
- put_user_pages(pages, npages);
-}
-
void nfs_init_cinfo_from_dreq(struct nfs_commit_info *cinfo,
struct nfs_direct_req *dreq)
{
@@ -510,7 +505,7 @@ static ssize_t nfs_direct_read_schedule_iovec(struct nfs_direct_req *dreq,
pos += req_len;
dreq->bytes_left -= req_len;
}
- nfs_direct_release_pages(pagevec, npages);
+ put_user_pages(pagevec, npages);
kvfree(pagevec);
if (result < 0)
break;
@@ -933,7 +928,7 @@ static ssize_t nfs_direct_write_schedule_iovec(struct nfs_direct_req *dreq,
pos += req_len;
dreq->bytes_left -= req_len;
}
- nfs_direct_release_pages(pagevec, npages);
+ put_user_pages(pagevec, npages);
kvfree(pagevec);
if (result < 0)
break;
thanks,
--
John Hubbard
NVIDIA
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2] net: mdio-octeon: Fix Kconfig warnings and build errors
From: Nathan Chancellor @ 2019-08-03 6:01 UTC (permalink / raw)
To: natechancellor
Cc: devel, andrew, f.fainelli, lkp, kernel-build-reports, gregkh,
rdunlap, willy, broonie, linux-next, netdev, davem,
linux-arm-kernel, hkallweit1
In-Reply-To: <20190731185023.20954-1-natechancellor@gmail.com>
After commit 171a9bae68c7 ("staging/octeon: Allow test build on
!MIPS"), the following combination of configs cause a few Kconfig
warnings and build errors (distilled from arm allyesconfig and Randy's
randconfig builds):
CONFIG_NETDEVICES=y
CONFIG_STAGING=y
CONFIG_COMPILE_TEST=y
and CONFIG_OCTEON_ETHERNET as either a module or built-in.
WARNING: unmet direct dependencies detected for MDIO_OCTEON
Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
&& 64BIT [=n] && HAS_IOMEM [=y] && OF_MDIO [=n]
Selected by [y]:
- OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC ||
COMPILE_TEST [=y]) && NETDEVICES [=y]
In file included from ../drivers/net/phy/mdio-octeon.c:14:
../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
function ‘writeq’; did you mean ‘writel’?
[-Werror=implicit-function-declaration]
111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
| ^~~~~~
CONFIG_64BIT is not strictly necessary if the proper readq/writeq
definitions are included from io-64-nonatomic-lo-hi.h.
CONFIG_OF_MDIO is not needed when CONFIG_COMPILE_TEST is enabled because
of commit f9dc9ac51610 ("of/mdio: Add dummy functions in of_mdio.h.").
Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS")
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Mark Brown <broonie@kernel.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Address Randy's reported failure here: https://lore.kernel.org/netdev/b3444283-7a77-ece8-7ac6-41756aa7dc60@infradead.org/
by not requiring CONFIG_OF_MDIO when CONFIG_COMPILE_TEST is set.
* Improve commit message
drivers/net/phy/Kconfig | 4 ++--
drivers/net/phy/mdio-cavium.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 20f14c5fbb7e..0e3d9e3d3533 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -159,8 +159,8 @@ config MDIO_MSCC_MIIM
config MDIO_OCTEON
tristate "Octeon and some ThunderX SOCs MDIO buses"
- depends on 64BIT
- depends on HAS_IOMEM && OF_MDIO
+ depends on (64BIT && OF_MDIO) || COMPILE_TEST
+ depends on HAS_IOMEM
select MDIO_CAVIUM
help
This module provides a driver for the Octeon and ThunderX MDIO
diff --git a/drivers/net/phy/mdio-cavium.h b/drivers/net/phy/mdio-cavium.h
index ed5f9bb5448d..b7f89ad27465 100644
--- a/drivers/net/phy/mdio-cavium.h
+++ b/drivers/net/phy/mdio-cavium.h
@@ -108,6 +108,8 @@ static inline u64 oct_mdio_readq(u64 addr)
return cvmx_read_csr(addr);
}
#else
+#include <linux/io-64-nonatomic-lo-hi.h>
+
#define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
#define oct_mdio_readq(addr) readq((void *)addr)
#endif
--
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] net: mdio-octeon: Fix build error and Kconfig warning
From: Nathan Chancellor @ 2019-08-03 6:05 UTC (permalink / raw)
To: Matthew Wilcox
Cc: devel, andrew, f.fainelli, lkp, kernel-build-reports, gregkh,
rdunlap, broonie, linux-next, netdev, David Miller,
linux-arm-kernel, hkallweit1
In-Reply-To: <20190803013952.GF5597@bombadil.infradead.org>
On Fri, Aug 02, 2019 at 06:39:52PM -0700, Matthew Wilcox wrote:
> On Fri, Aug 02, 2019 at 06:30:31PM -0700, Nathan Chancellor wrote:
> > On Fri, Aug 02, 2019 at 06:11:32PM -0700, David Miller wrote:
> > > The proper way to fix this is to include either
> > >
> > > linux/io-64-nonatomic-hi-lo.h
> > >
> > > or
> > >
> > > linux/io-64-nonatomic-lo-hi.h
> > >
> > > whichever is appropriate.
> >
> > Hmmmm, is that not what I did?
> >
> > Although I did not know about io-64-nonatomic-hi-lo.h. What is the
> > difference and which one is needed here?
>
> Whether you write the high or low 32 bits first. For this, it doesn't
> matter, since the compiled driver will never be run on real hardware.
That's what I figured. I have only seen lo-hi used personally, which is
what I went with here. Thanks for the confirmation!
>
> > There is apparently another failure when OF_MDIO is not set, I guess I
> > can try to look into that as well and respin into a series if
> > necessary.
>
> Thanks for taking care of that!
_______________________________________________
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] dma-mapping: fix page attributes for dma_mmap_*
From: Christoph Hellwig @ 2019-08-03 6:48 UTC (permalink / raw)
To: Will Deacon
Cc: Shawn Anastasio, Michael Ellerman, linuxppc-dev, Russell King,
linux-kernel, iommu, Catalin Marinas, Robin Murphy,
Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20190802103803.3qrbhqwxlasojsco@willie-the-truck>
On Fri, Aug 02, 2019 at 11:38:03AM +0100, Will Deacon wrote:
>
> So this boils down to a terminology mismatch. The Arm architecture doesn't have
> anything called "write combine", so in Linux we instead provide what the Arm
> architecture calls "Normal non-cacheable" memory for pgprot_writecombine().
> Amongst other things, this memory type permits speculation, unaligned accesses
> and merging of writes. I found something in the architecture spec about
> non-cachable memory, but it's written in Armglish[1].
>
> pgprot_noncached(), on the other hand, provides what the architecture calls
> Strongly Ordered or Device-nGnRnE memory. This is intended for mapping MMIO
> (i.e. PCI config space) and therefore forbids speculation, preserves access
> size, requires strict alignment and also forces write responses to come from
> the endpoint.
>
> I think the naming mismatch is historical, but on arm64 we wanted to use the
> same names as arm32 so that any drivers using these things directly would get
> the same behaviour.
That all makes sense, but it totally needs a comment. I'll try to draft
one based on this. I've also looked at the arm32 code a bit more, and
it seems arm always (?) supported Normal non-cacheable attribute, but
Linux only optionally uses it for arm v6+ because of fears of drivers
missing barriers. The other really weird things is that in arm32
pgprot_dmacoherent incudes the L_PTE_XN bit, which from my understanding
is the no-execture bit, but pgprot_writecombine does not. This seems to
not very unintentional. So minus that the whole DMA_ATTR_WRITE_COMBІNE
seems to be about flagging old arm specific drivers as having the proper
barriers in places and otherwise is a no-op.
Here is my tentative plan:
- respin this patch with a small fix to handle the
DMA_ATTR_NON_CONSISTENT (as in ignore it unless actually supported),
but keep the name as-is to avoid churn. This should allow 5.3
inclusion and backports
- remove DMA_ATTR_WRITE_COMBINE support from mips, probably also 5.3
material.
- move all architectures but arm over to just define
pgprot_dmacoherent, including a comment with the above explanation
for arm64.
- make DMA_ATTR_WRITE_COMBINE a no-op and schedule it for removal,
thus removing the last instances of arch_dma_mmap_pgprot
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: ls1028a: Add esdhc node in dts
From: Shawn Guo @ 2019-08-03 7:00 UTC (permalink / raw)
To: Yinbo Zhu
Cc: Mark Rutland, devicetree, Ashish Kumar, linux-kernel, linux-mmc,
xiaobo.xie, Li Yang, Rob Herring, yangbo.lu, jiafei.pan,
linux-arm-kernel
In-Reply-To: <20190515084925.30155-1-yinbo.zhu@nxp.com>
On Wed, May 15, 2019 at 04:49:25PM +0800, Yinbo Zhu wrote:
> From: Ashish Kumar <Ashish.Kumar@nxp.com>
>
> This patch is to add esdhc node and enable SD UHS-I,
> eMMC HS200 for ls1028ardb/ls1028aqds board.
>
> Signed-off-by: Ashish Kumar <Ashish.Kumar@nxp.com>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
> ---
> Change in v3:
> replace "esdhc@" with "mmc@"
>
> arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 8 ++++++
> arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 13 ++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 27 +++++++++++++++++++++
> 3 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> index 14c79f4..180e5d2 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> @@ -42,6 +42,14 @@
> status = "okay";
> };
>
> +&esdhc {
> + status = "okay";
> +};
> +
> +&esdhc1 {
> + status = "okay";
> +};
> +
> &i2c0 {
> status = "okay";
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> index f86b054..1bfaf42 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> @@ -30,6 +30,19 @@
> };
> };
>
> +&esdhc {
> + status = "okay";
We usually put 'status' at end of property list.
> + sd-uhs-sdr104;
> + sd-uhs-sdr50;
> + sd-uhs-sdr25;
> + sd-uhs-sdr12;
> + };
Please follow the indent style of closing parentheses in the file.
> +
> +&esdhc1 {
> + status = "okay";
> + mmc-hs200-1_8v;
> + };
Ditto
> +
> &i2c0 {
> status = "okay";
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 2896bbc..462833c 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -274,6 +274,33 @@
> status = "disabled";
> };
>
> + esdhc: mmc@2140000 {
Please sort the nodes in unit-address. From what I see, it should go
before device serial@21c0500.
> + compatible = "fsl,ls1028a-esdhc", "fsl,esdhc";
> + reg = <0x0 0x2140000 0x0 0x10000>;
> + interrupts = <0 28 0x4>; /* Level high type */
Use IRQ_TYPE_LEVEL_HIGH, then you can drop the comment.
Shawn
> + clock-frequency = <0>; /* fixed up by bootloader */
> + clocks = <&clockgen 2 1>;
> + voltage-ranges = <1800 1800 3300 3300>;
> + sdhci,auto-cmd12;
> + little-endian;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
> + esdhc1: mmc@2150000 {
> + compatible = "fsl,ls1028a-esdhc", "fsl,esdhc";
> + reg = <0x0 0x2150000 0x0 0x10000>;
> + interrupts = <0 63 0x4>; /* Level high type */
> + clock-frequency = <0>; /* fixed up by bootloader */
> + clocks = <&clockgen 2 1>;
> + voltage-ranges = <1800 1800 3300 3300>;
> + sdhci,auto-cmd12;
> + broken-cd;
> + little-endian;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
> sata: sata@3200000 {
> compatible = "fsl,ls1028a-ahci";
> reg = <0x0 0x3200000 0x0 0x10000>,
> --
> 1.7.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 15/34] staging/vc04_services: convert put_page() to put_user_page*()
From: Greg Kroah-Hartman @ 2019-08-03 7:06 UTC (permalink / raw)
To: john.hubbard
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Suniel Mahesh, Dan Williams, devel,
rds-devel, linux-rdma, x86, amd-gfx, Christoph Hellwig,
Jason Gunthorpe, John Hubbard, xen-devel, devel, linux-media,
Stefan Wahren, Mihaela Muraru, intel-gfx, linux-block,
Jérôme Glisse, linux-rpi-kernel, ceph-devel,
Sidong Yang, linux-arm-kernel, linux-nfs, Eric Anholt, netdev,
LKML, linux-xfs, linux-crypto, Kishore KP, linux-fsdevel,
Andrew Morton, Al Viro
In-Reply-To: <20190802022005.5117-16-jhubbard@nvidia.com>
On Thu, Aug 01, 2019 at 07:19:46PM -0700, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Mihaela Muraru <mihaela.muraru21@gmail.com>
> Cc: Suniel Mahesh <sunil.m@techveda.org>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Sidong Yang <realwakka@gmail.com>
> Cc: Kishore KP <kishore.p@techveda.org>
> Cc: linux-rpi-kernel@lists.infradead.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: devel@driverdev.osuosl.org
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> .../vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 10/34] genwqe: convert put_page() to put_user_page*()
From: Greg Kroah-Hartman @ 2019-08-03 7:06 UTC (permalink / raw)
To: john.hubbard
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Dan Williams, devel, rds-devel, linux-rdma,
x86, amd-gfx, Christoph Hellwig, Jason Gunthorpe, xen-devel,
devel, linux-media, Arnd Bergmann, Guilherme G. Piccoli,
John Hubbard, intel-gfx, linux-block, Jérôme Glisse,
linux-rpi-kernel, ceph-devel, linux-arm-kernel, linux-nfs, netdev,
LKML, linux-xfs, linux-crypto, linux-fsdevel, Andrew Morton,
Frank Haverkamp
In-Reply-To: <20190802022005.5117-11-jhubbard@nvidia.com>
On Thu, Aug 01, 2019 at 07:19:41PM -0700, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> This changes the release code slightly, because each page slot in the
> page_list[] array is no longer checked for NULL. However, that check
> was wrong anyway, because the get_user_pages() pattern of usage here
> never allowed for NULL entries within a range of pinned pages.
>
> Cc: Frank Haverkamp <haver@linux.vnet.ibm.com>
> Cc: "Guilherme G. Piccoli" <gpiccoli@linux.vnet.ibm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> drivers/misc/genwqe/card_utils.c | 17 +++--------------
> 1 file changed, 3 insertions(+), 14 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: ls1088a: Revise gpio registers to little-endian
From: Shawn Guo @ 2019-08-03 7:11 UTC (permalink / raw)
To: Chuanhua Han
Cc: mark.rutland, devicetree, linux-gpio, linus.walleij, linux-kernel,
leoyang.li, bgolaszewski, robh+dt, linux-arm-kernel
In-Reply-To: <20190529083254.39581-3-chuanhua.han@nxp.com>
On Wed, May 29, 2019 at 04:32:54PM +0800, Chuanhua Han wrote:
> Since fsl-ls1088a Soc GPIO registers are used as little endian,
> the patch adds the little-endian attribute to each gpio node.
>
> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
Applied, thanks.
_______________________________________________
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] dt-bindings: clock: imx8mn: Fix tab indentation for yaml file
From: Shawn Guo @ 2019-08-03 7:25 UTC (permalink / raw)
To: Anson.Huang
Cc: mark.rutland, devicetree, sboyd, mturquette, linux-kernel,
linux-clk, robh+dt, Linux-imx, kernel, festevam, s.hauer,
linux-arm-kernel
In-Reply-To: <20190725020551.27034-1-Anson.Huang@nxp.com>
On Thu, Jul 25, 2019 at 10:05:51AM +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> YAML file can NOT contain tab as indentation, fix it.
>
> Fixes: 6d6062553e3d ("dt-bindings: imx: Add clock binding doc for i.MX8MN")
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
I squashed it into the original commit.
Shawn
_______________________________________________
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] clk: imx8mq: Mark AHB clock as critical
From: Shawn Guo @ 2019-08-03 7:27 UTC (permalink / raw)
To: Daniel Baluta
Cc: Abel Vesa, Anson Huang, Stephen Boyd, Mike Turquette,
Linux Kernel Mailing List, dl-linux-imx, Sascha Hauer,
Fabio Estevam, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAEnQRZAFdvSzh-pDJ-rsyaEJw83ymSVW0CC2+QZyWwAPeTOyBw@mail.gmail.com>
On Sat, Jul 27, 2019 at 09:30:57AM +0300, Daniel Baluta wrote:
> On Tue, Jul 23, 2019 at 6:17 AM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Abel Vesa (2019-07-05 01:52:19)
> > > On 19-06-25 15:32:22, Stephen Boyd wrote:
> > > > Quoting Abel Vesa (2019-06-25 02:01:56)
> > > > > Keep the AHB clock always on since there is no driver to control it and
> > > > > all the other clocks that use it as parent rely on it being always enabled.
> > > > >
> > > > > Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> > > > > ---
> > > > > drivers/clk/imx/clk-imx8mq.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
> > > > > index 5fbc2a7..b48268b 100644
> > > > > --- a/drivers/clk/imx/clk-imx8mq.c
> > > > > +++ b/drivers/clk/imx/clk-imx8mq.c
> > > > > @@ -398,7 +398,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
> > > > > clks[IMX8MQ_CLK_NOC_APB] = imx8m_clk_composite_critical("noc_apb", imx8mq_noc_apb_sels, base + 0x8d80);
> > > > >
> > > > > /* AHB */
> > > > > - clks[IMX8MQ_CLK_AHB] = imx8m_clk_composite("ahb", imx8mq_ahb_sels, base + 0x9000);
> > > > > + clks[IMX8MQ_CLK_AHB] = imx8m_clk_composite_critical("ahb", imx8mq_ahb_sels, base + 0x9000);
> > > >
> > > > Please add a comment into the code why it's critical.
> > >
> > > Comment explaining why the AHB bus clock is critical ?
> > > Isn't that self-explanatory ?
> >
> > Nope, it isn't self-explanatory, because nothing on this line says "bus"
> > and it could be that someone reading this code isn't well versed in the
> > concepts of ARM world AHB to connect the two.
>
> Agree with Stephen. Commit message should try to give as much details
> as possible
> also maybe educate the readers who might not have that much knowledge.
>
> Abel, I understand that for someone who works daily with this part of the kernel
> this change might look trivial.
>
> Also, without this patch linux-next hangs on imx8mq.
How does that happen? Mainline is fine there?
Shawn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] Re: [PATCH 1/6] dt-bindings: arm: fsl: Add the S32V234-EVB board
From: Stefan-gabriel Mirea @ 2019-08-03 8:00 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Eddy Petrisor,
will@kernel.org, corbet@lwn.net, gregkh@linuxfoundation.org,
jslaby@suse.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Leo Li,
linux-serial@vger.kernel.org, catalin.marinas@arm.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqL++GZBxczxePni9ysNq06kObB4EzJEi1e4M=PurPZFgQ@mail.gmail.com>
Hello Rob,
On 8/3/2019 1:38 AM, Rob Herring wrote:
> On Fri, Aug 2, 2019 at 1:47 PM Stefan-gabriel Mirea
> <stefan-gabriel.mirea@nxp.com> wrote:
>> + - description: S32V234 Customer Evaluation Board
>
> Most of the entries in this file are for all the boards for an SoC.
>
>> + items:
>> + - enum:
>> + - fsl,s32v234-evb
>
> If that's not going to be the case here, you can use 'const' here.
We also intend to submit patches for the SBC-S32V234[1] board in the
future and I believe that its 'compatible' should share this entry.
Would it therefore be preferable to update the description at this
moment and add a comment, like:
- description: S32V234 based Boards
items:
- enum:
- fsl,s32v234-evb # S32V234-EVB2 Customer Evaluation Board
- const: fsl,s32v234
or just replace the single-value 'enum' with a 'const' for now?
Regards,
Stefan
[1] https://www.nxp.com/design/development-boards/automotive-development-platforms/s32v-mpus-platforms/s32v-vision-and-sensor-fusion-evaluation-board:SBC-S32V234
_______________________________________________
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] clk: imx8mq: Mark AHB clock as critical
From: Shawn Guo @ 2019-08-03 8:00 UTC (permalink / raw)
To: Daniel Baluta
Cc: Abel Vesa, Anson Huang, Stephen Boyd, Mike Turquette,
Linux Kernel Mailing List, dl-linux-imx, Sascha Hauer,
Fabio Estevam, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190803072723.GB7597@X250>
On Sat, Aug 03, 2019 at 09:27:25AM +0200, Shawn Guo wrote:
> > Also, without this patch linux-next hangs on imx8mq.
>
> How does that happen? Mainline is fine there?
Okay, understood it by reading more threads.
Shawn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 3/4] arm64: dts: imx8mq: Add opp-suspend property to OPP table
From: Shawn Guo @ 2019-08-03 8:12 UTC (permalink / raw)
To: Anson.Huang
Cc: nm, mark.rutland, ping.bai, ccaione, agx, angus, leonard.crestez,
festevam, abel.vesa, andrew.smirnov, vireshk, Linux-imx,
devicetree, kernel, linux-pm, s.hauer, robh+dt, daniel.baluta,
linux-arm-kernel, sboyd, linux-kernel, p.zabel, l.stach
In-Reply-To: <20190709080015.43442-3-Anson.Huang@nxp.com>
On Tue, Jul 09, 2019 at 04:00:14PM +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Add opp-suspend property to each OPP, the of opp core will
> select the OPP HW supported and with highest rate to be
> suspend opp, it will speed up the suspend/resume process.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
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