* [Buildroot] [PATCH 1/1] package/nodejs: bump version to 6.9.1
From: Thomas Petazzoni @ 2016-11-14 22:49 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479142730-21743-1-git-send-email-cloudyparts@icloud.com>
Hello,
On Mon, 14 Nov 2016 11:58:50 -0500, Patrick Devlin wrote:
> https://nodejs.org/en/blog/release/v6.9.1/
>
> The patches from 6.7.0 have been copied to 6.9.1.
>
> Signed-off-by: Patrick Devlin <cloudyparts@icloud.com>
> ---
> .../{6.7.0 => 6.9.1}/0001-gyp-force-link-command-to-use-CXX.patch | 0
> .../0002-inspector-don-t-build-when-ssl-support-is-disabled.patch | 0
> package/nodejs/Config.in | 2 +-
> package/nodejs/nodejs.hash | 4 ++--
> 4 files changed, 3 insertions(+), 3 deletions(-)
> rename package/nodejs/{6.7.0 => 6.9.1}/0001-gyp-force-link-command-to-use-CXX.patch (100%)
> rename package/nodejs/{6.7.0 => 6.9.1}/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch (100%)
Applied to next, thanks.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [git commit branch/next] package/nodejs: bump version to 6.9.1
From: Thomas Petazzoni @ 2016-11-14 22:48 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=5f899d7f1cd807ff7a92b2facfd4718dad139724
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/next
https://nodejs.org/en/blog/release/v6.9.1/
The patches from 6.7.0 have been copied to 6.9.1.
Signed-off-by: Patrick Devlin <cloudyparts@icloud.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../{6.7.0 => 6.9.1}/0001-gyp-force-link-command-to-use-CXX.patch | 0
.../0002-inspector-don-t-build-when-ssl-support-is-disabled.patch | 0
package/nodejs/Config.in | 2 +-
package/nodejs/nodejs.hash | 4 ++--
4 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/package/nodejs/6.7.0/0001-gyp-force-link-command-to-use-CXX.patch b/package/nodejs/6.9.1/0001-gyp-force-link-command-to-use-CXX.patch
similarity index 100%
rename from package/nodejs/6.7.0/0001-gyp-force-link-command-to-use-CXX.patch
rename to package/nodejs/6.9.1/0001-gyp-force-link-command-to-use-CXX.patch
diff --git a/package/nodejs/6.7.0/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch b/package/nodejs/6.9.1/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch
similarity index 100%
rename from package/nodejs/6.7.0/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch
rename to package/nodejs/6.9.1/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch
diff --git a/package/nodejs/Config.in b/package/nodejs/Config.in
index 976be50..a47ba37 100644
--- a/package/nodejs/Config.in
+++ b/package/nodejs/Config.in
@@ -43,7 +43,7 @@ config BR2_PACKAGE_NODEJS_V8_ARCH_SUPPORTS
config BR2_PACKAGE_NODEJS_VERSION_STRING
string
- default "6.7.0" if BR2_PACKAGE_NODEJS_V8_ARCH_SUPPORTS
+ default "6.9.1" if BR2_PACKAGE_NODEJS_V8_ARCH_SUPPORTS
default "0.10.47"
config BR2_PACKAGE_NODEJS_NPM
diff --git a/package/nodejs/nodejs.hash b/package/nodejs/nodejs.hash
index f334a47..5df79af 100644
--- a/package/nodejs/nodejs.hash
+++ b/package/nodejs/nodejs.hash
@@ -1,5 +1,5 @@
# From upstream URL: http://nodejs.org/dist/v0.10.47/SHASUMS256.txt
sha256 335bdf4db702885a8acaf2c9f241c70cabd62497361da81aca65c8e8a8e7ff09 node-v0.10.47.tar.xz
-# From upstream URL: http://nodejs.org/dist/v6.7.0/SHASUMS256.txt
-sha256 ceb028324aab1ee8c7ea6a62026f036f3ea71f5ef5212593d0f833f999dd3be5 node-v6.7.0.tar.xz
+# From upstream URL: http://nodejs.org/dist/v6.9.1/SHASUMS256.txt
+sha256 0bdd8d1305777cc8cd206129ea494d6c6ce56001868dd80147aff531d6df0729 node-v6.9.1.tar.xz
^ permalink raw reply related
* [Buildroot] [PATCH] package/gdb: disable simulator support for microblaze
From: Thomas Petazzoni @ 2016-11-14 22:48 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479161134-10097-1-git-send-email-romain.naour@gmail.com>
Hello,
On Mon, 14 Nov 2016 23:05:34 +0100, Romain Naour wrote:
> The gdb simulator seems missing with the Xilinx fork of gdb.
> Disable it for microblaze since only the Xilinx version of gdb is
> currently available.
>
> Fixes:
> http://autobuild.buildroot.net/results/907/9079dad3f138c313a6abb40825baf4d9683a2422
>
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: Waldemar Brodkorb <mail@waldemar-brodkorb.de>
> ---
> package/gdb/Config.in.host | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to master, thanks.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH net 1/3] bpf, mlx5: fix mlx5e_create_rq taking reference on prog
From: Saeed Mahameed @ 2016-11-14 18:15 UTC (permalink / raw)
To: Daniel Borkmann, davem
Cc: alexei.starovoitov, bblanco, tariqt, zhiyisun, ranas, netdev
In-Reply-To: <0447a6161550c466ef799b46095440949ffc7df0.1479080215.git.daniel@iogearbox.net>
On 11/14/2016 02:43 AM, Daniel Borkmann wrote:
> In mlx5e_create_rq(), when creating a new queue, we call bpf_prog_add() but
> without checking the return value. bpf_prog_add() can fail, so we really
Didn't know this, thanks for noticing, I wonder why taking a reference for an object would fail ?
especially when someone is requesting from the driver to take a reference to it ndo_xdp_set ?! sounds like a bad design.
Anyway I will check that later.
> must check it. Take the reference right when we assign it to the rq from
> priv->xdp_prog, and just drop the reference on error path. Destruction in
> mlx5e_destroy_rq() looks good, though.
>
> Fixes: 86994156c736 ("net/mlx5e: XDP fast RX drop bpf programs support")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 14 +++++++++++---
> kernel/bpf/syscall.c | 1 +
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 84e8b25..2b83667 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -489,7 +489,16 @@ static int mlx5e_create_rq(struct mlx5e_channel *c,
> rq->channel = c;
> rq->ix = c->ix;
> rq->priv = c->priv;
> +
> rq->xdp_prog = priv->xdp_prog;
Why keeping this assignment ? just test priv->xdp_prog.
> + if (rq->xdp_prog) {
> + rq->xdp_prog = bpf_prog_inc(rq->xdp_prog);
> + if (IS_ERR(rq->xdp_prog)) {
> + err = PTR_ERR(rq->xdp_prog);
> + rq->xdp_prog = NULL;
> + goto err_rq_wq_destroy;
> + }
> + }
Try this, simpler and less indentations:
rq->xdp_prog = priv->xdp_prog ? bpf_prog_inc(priv->xdp_prog) : NULL;
if (IS_ERR(rq->xdp_prog)) {
err = PTR_ERR(rq->xdp_prog);
rq->xdp_prog = NULL;
goto err_rq_wq_destroy;
}
Saeed.
^ permalink raw reply
* [Buildroot] [git commit] package/gdb: disable simulator support for microblaze
From: Thomas Petazzoni @ 2016-11-14 22:48 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=9c49afdad67f421f03b1acfc5ed48150c4b36a65
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
The gdb simulator seems missing with the Xilinx fork of gdb.
Disable it for microblaze since only the Xilinx version of gdb is
currently available.
Fixes:
http://autobuild.buildroot.net/results/907/9079dad3f138c313a6abb40825baf4d9683a2422
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Waldemar Brodkorb <mail@waldemar-brodkorb.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/gdb/Config.in.host | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/gdb/Config.in.host b/package/gdb/Config.in.host
index b6eb41f..da6b30e 100644
--- a/package/gdb/Config.in.host
+++ b/package/gdb/Config.in.host
@@ -27,7 +27,7 @@ config BR2_PACKAGE_HOST_GDB_PYTHON
config BR2_PACKAGE_HOST_GDB_SIM
bool "Simulator support"
- depends on !BR2_arc
+ depends on !BR2_arc && !BR2_microblaze
help
This option enables the simulator support in the cross gdb.
^ permalink raw reply related
* [Buildroot] [PATCH] openjpeg: refresh patches
From: Thomas Petazzoni @ 2016-11-14 22:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <15d0ff6af38ff41acb2129a619e49a0e3ba866d9.1479160710.git.baruch@tkos.co.il>
Hello,
On Mon, 14 Nov 2016 23:58:30 +0200, Baruch Siach wrote:
> The 2.1.2 version bump did not take into account the recently added fixes.
> Update the patches to apply based on upstream pull requests #866 and #867.
>
> Cc: Peter Seiderer <ps.report@gmx.net>
> Cc: Samuel Martin <s.martin49@gmail.com>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> ...tiff-append-flags-found-by-pkg-config-if-.patch | 60 +++++++++++-----------
> ...lcms2-append-flags-found-by-pkg-config-if.patch | 38 +++++++-------
> 2 files changed, 50 insertions(+), 48 deletions(-)
Applied to master, thanks.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [git commit] openjpeg: refresh patches
From: Thomas Petazzoni @ 2016-11-14 22:47 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=2775276135b3c8d06084c97e6195bc310bc432bf
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
The 2.1.2 version bump did not take into account the recently added fixes.
Update the patches to apply based on upstream pull requests #866 and #867.
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
...tiff-append-flags-found-by-pkg-config-if-.patch | 60 +++++++++++-----------
...lcms2-append-flags-found-by-pkg-config-if.patch | 38 +++++++-------
2 files changed, 50 insertions(+), 48 deletions(-)
diff --git a/package/openjpeg/0001-thirdparty-tiff-append-flags-found-by-pkg-config-if-.patch b/package/openjpeg/0001-thirdparty-tiff-append-flags-found-by-pkg-config-if-.patch
index be50902..bce790a 100644
--- a/package/openjpeg/0001-thirdparty-tiff-append-flags-found-by-pkg-config-if-.patch
+++ b/package/openjpeg/0001-thirdparty-tiff-append-flags-found-by-pkg-config-if-.patch
@@ -17,56 +17,56 @@ Signed-off-by: Samuel Martin <s.martin49@gmail.com>
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/thirdparty/CMakeLists.txt b/thirdparty/CMakeLists.txt
-index d1e68ca..225f51d 100644
+index cb24b43b58e2..cd6a5e1391b0 100644
--- a/thirdparty/CMakeLists.txt
+++ b/thirdparty/CMakeLists.txt
@@ -1,5 +1,9 @@
# 3rd party libs
-+IF(NOT BUILD_THIRDPARTY)
++if(NOT BUILD_THIRDPARTY)
+ include(FindPkgConfig)
-+ENDIF(NOT BUILD_THIRDPARTY)
++endif(NOT BUILD_THIRDPARTY)
+
#------------
# Try to find lib Z
- IF(BUILD_THIRDPARTY)
-@@ -35,6 +39,9 @@ IF(BUILD_THIRDPARTY)
- SET(PNG_INCLUDE_DIRNAME ${OPENJPEG_SOURCE_DIR}/thirdparty/libpng PARENT_SCOPE)
- ELSE (BUILD_THIRDPARTY)
- IF (ZLIB_FOUND)
+ if(BUILD_THIRDPARTY)
+@@ -36,6 +40,9 @@ if(BUILD_THIRDPARTY)
+ else(BUILD_THIRDPARTY)
+ if(ZLIB_FOUND)
+ find_package(PNG)
+ # Static only build:
+ # it is not necessary to invoke pkg_check_module on libpng, because libpng
+ # only depends on zlib, which is already checked.
- FIND_PACKAGE(PNG)
- IF(PNG_FOUND)
+ if(PNG_FOUND)
message(STATUS "Your system seems to have a PNG lib available, we will use it")
-@@ -66,12 +73,24 @@ IF(BUILD_THIRDPARTY)
- SET(OPJ_HAVE_LIBTIFF 1 PARENT_SCOPE)
- ELSE (BUILD_THIRDPARTY)
- FIND_PACKAGE(TIFF)
+ set(OPJ_HAVE_PNG_H 1 PARENT_SCOPE)
+@@ -66,12 +73,24 @@ if(BUILD_THIRDPARTY)
+ set(OPJ_HAVE_LIBTIFF 1 PARENT_SCOPE)
+ else(BUILD_THIRDPARTY)
+ find_package(TIFF)
+ # Static only build:
+ # it is necessary to invoke pkg_check_module on libtiff since it may have
+ # several other dependencies not declared by its cmake module, but they are
+ # in the its pkgconfig module.
-+ IF(PKG_CONFIG_FOUND)
-+ FOREACH(pc_tiff_module tiff tiff3 tiff4 tiff-3 tiff-4 libtiff libtiff3 libtiff4 libtiff-3 libtiff-4)
++ if(PKG_CONFIG_FOUND)
++ foreach(pc_tiff_module tiff tiff3 tiff4 tiff-3 tiff-4 libtiff libtiff3 libtiff4 libtiff-3 libtiff-4)
+ pkg_check_modules(PC_TIFF QUIET ${pc_tiff_module})
-+ IF(PC_TIFF_FOUND)
++ if(PC_TIFF_FOUND)
+ break()
-+ ENDIF(PC_TIFF_FOUND)
-+ ENDFOREACH()
-+ ENDIF(PKG_CONFIG_FOUND)
- IF(TIFF_FOUND)
++ endif(PC_TIFF_FOUND)
++ endforeach()
++ endif(PKG_CONFIG_FOUND)
+ if(TIFF_FOUND)
message(STATUS "Your system seems to have a TIFF lib available, we will use it")
- SET(OPJ_HAVE_TIFF_H 1 PARENT_SCOPE)
- SET(OPJ_HAVE_LIBTIFF 1 PARENT_SCOPE)
-- SET(TIFF_LIBNAME ${TIFF_LIBRARIES} PARENT_SCOPE)
-- SET(TIFF_INCLUDE_DIRNAME ${TIFF_INCLUDE_DIR} PARENT_SCOPE)
-+ SET(TIFF_LIBNAME ${TIFF_LIBRARIES} ${PC_TIFF_STATIC_LIBRARIES} PARENT_SCOPE)
-+ SET(TIFF_INCLUDE_DIRNAME ${TIFF_INCLUDE_DIR} ${PC_TIFF_STATIC_INCLUDE_DIRS} PARENT_SCOPE)
- ELSE (TIFF_FOUND) # not found
- SET(OPJ_HAVE_TIFF_H 0 PARENT_SCOPE)
- SET(OPJ_HAVE_LIBTIFF 0 PARENT_SCOPE)
+ set(OPJ_HAVE_TIFF_H 1 PARENT_SCOPE)
+ set(OPJ_HAVE_LIBTIFF 1 PARENT_SCOPE)
+- set(TIFF_LIBNAME ${TIFF_LIBRARIES} PARENT_SCOPE)
+- set(TIFF_INCLUDE_DIRNAME ${TIFF_INCLUDE_DIR} PARENT_SCOPE)
++ set(TIFF_LIBNAME ${TIFF_LIBRARIES} ${PC_TIFF_STATIC_LIBRARIES} PARENT_SCOPE)
++ set(TIFF_INCLUDE_DIRNAME ${TIFF_INCLUDE_DIR} ${PC_TIFF_STATIC_INCLUDE_DIRS} PARENT_SCOPE)
+ else(TIFF_FOUND) # not found
+ set(OPJ_HAVE_TIFF_H 0 PARENT_SCOPE)
+ set(OPJ_HAVE_LIBTIFF 0 PARENT_SCOPE)
--
2.10.2
diff --git a/package/openjpeg/0002-thirdparty-lcms2-append-flags-found-by-pkg-config-if.patch b/package/openjpeg/0002-thirdparty-lcms2-append-flags-found-by-pkg-config-if.patch
index 4366c0a..5697b82 100644
--- a/package/openjpeg/0002-thirdparty-lcms2-append-flags-found-by-pkg-config-if.patch
+++ b/package/openjpeg/0002-thirdparty-lcms2-append-flags-found-by-pkg-config-if.patch
@@ -7,9 +7,11 @@ Subject: [PATCH] thirdparty: lcms2: append flags found by pkg-config if
This change allows to get all required CFLAGS/LDFLAGS in case of static only
build.
-Fixes a buildroot build failure (see [1]).
+Fixes a buildroot build failure (see [1], [2] and [3]).
[1] http://autobuild.buildroot.net/results/5ce/5cee20afd8bef5268832cddcb3a5270746be7a57
+[2] http://lists.busybox.net/pipermail/buildroot/2016-November/177187.html
+[3] http://lists.busybox.net/pipermail/buildroot/2016-November/177188.html
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
---
@@ -17,31 +19,31 @@ Signed-off-by: Peter Seiderer <ps.report@gmx.net>
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/thirdparty/CMakeLists.txt b/thirdparty/CMakeLists.txt
-index 225f51d..42770ad 100644
+index cd6a5e1391b0..a3a8494d89b1 100644
--- a/thirdparty/CMakeLists.txt
+++ b/thirdparty/CMakeLists.txt
-@@ -113,12 +113,19 @@ IF( BUILD_THIRDPARTY)
- SET(OPJ_HAVE_LIBLCMS2 1 PARENT_SCOPE)
- ELSE (BUILD_THIRDPARTY)
- FIND_PACKAGE(LCMS2)
+@@ -113,12 +113,19 @@ if( BUILD_THIRDPARTY)
+ set(OPJ_HAVE_LIBLCMS2 1 PARENT_SCOPE)
+ else(BUILD_THIRDPARTY)
+ find_package(LCMS2)
+ # Static only build:
+ # it is necessary to invoke pkg_check_module on lcms2 since it may have
+ # several other dependencies not declared by its cmake module, but they are
+ # in the its pkgconfig module.
-+ IF(PKG_CONFIG_FOUND)
++ if(PKG_CONFIG_FOUND)
+ pkg_check_modules(PC_LCMS2 QUIET lcms2)
-+ ENDIF(PKG_CONFIG_FOUND)
- IF(LCMS2_FOUND)
++ endif(PKG_CONFIG_FOUND)
+ if(LCMS2_FOUND)
message(STATUS "Your system seems to have a LCMS2 lib available, we will use it")
- SET(OPJ_HAVE_LCMS2_H 1 PARENT_SCOPE)
- SET(OPJ_HAVE_LIBLCMS2 1 PARENT_SCOPE)
-- SET(LCMS_LIBNAME ${LCMS2_LIBRARIES} PARENT_SCOPE)
-- SET(LCMS_INCLUDE_DIRNAME ${LCMS2_INCLUDE_DIRS} PARENT_SCOPE)
-+ SET(LCMS_LIBNAME ${LCMS2_LIBRARIES} ${PC_LCMS2_STATIC_LIBRARIES} PARENT_SCOPE)
-+ SET(LCMS_INCLUDE_DIRNAME ${LCMS2_INCLUDE_DIRS} ${PC_LCMS2_STATIC_INCLUDE_DIRS} PARENT_SCOPE)
- ELSE (LCMS2_FOUND) # not found lcms2
+ set(OPJ_HAVE_LCMS2_H 1 PARENT_SCOPE)
+ set(OPJ_HAVE_LIBLCMS2 1 PARENT_SCOPE)
+- set(LCMS_LIBNAME ${LCMS2_LIBRARIES} PARENT_SCOPE)
+- set(LCMS_INCLUDE_DIRNAME ${LCMS2_INCLUDE_DIRS} PARENT_SCOPE)
++ set(LCMS_LIBNAME ${LCMS2_LIBRARIES} ${PC_LCMS2_STATIC_LIBRARIES} PARENT_SCOPE)
++ set(LCMS_INCLUDE_DIRNAME ${LCMS2_INCLUDE_DIRS} ${PC_LCMS2_STATIC_INCLUDE_DIRS} PARENT_SCOPE)
+ else(LCMS2_FOUND) # not found lcms2
# try to find LCMS
- FIND_PACKAGE(LCMS)
+ find_package(LCMS)
--
-2.8.1
+2.10.2
^ permalink raw reply related
* [PATCH] drm/i2c/tda998x: fix spelling mistake
From: Colin King @ 2016-11-14 22:46 UTC (permalink / raw)
To: Russell King, David Airlie, dri-devel; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake "configutation" to "configuration"
in dev_err message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index af8683e..bebb619 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1260,7 +1260,7 @@ static int tda998x_audio_hw_params(struct device *dev, void *data,
}
if (audio.config == 0) {
- dev_err(dev, "%s: No audio configutation found\n", __func__);
+ dev_err(dev, "%s: No audio configuration found\n", __func__);
return -EINVAL;
}
--
2.10.2
^ permalink raw reply related
* [PATCH] drm/i2c/tda998x: fix spelling mistake
From: Colin King @ 2016-11-14 22:46 UTC (permalink / raw)
To: Russell King, David Airlie, dri-devel; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake "configutation" to "configuration"
in dev_err message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index af8683e..bebb619 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1260,7 +1260,7 @@ static int tda998x_audio_hw_params(struct device *dev, void *data,
}
if (audio.config == 0) {
- dev_err(dev, "%s: No audio configutation found\n", __func__);
+ dev_err(dev, "%s: No audio configuration found\n", __func__);
return -EINVAL;
}
--
2.10.2
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH V4 00/15] blk-throttle: add .high limit
From: Bart Van Assche @ 2016-11-14 22:46 UTC (permalink / raw)
To: Shaohua Li, linux-block, linux-kernel; +Cc: Kernel-team, axboe, tj, vgoyal
In-Reply-To: <cover.1479161136.git.shli@fb.com>
On 11/14/2016 02:22 PM, Shaohua Li wrote:
> The background is we don't have an ioscheduler for blk-mq yet, so we can't
> prioritize processes/cgroups. This patch set tries to add basic arbitration
> between cgroups with blk-throttle. It adds a new limit io.high for
> blk-throttle. It's only for cgroup2.
Hello Shaohua,
My understanding of this work is that a significant part of it will have
to be reverted once blk-mq supports I/O scheduling, e.g. the code for
detecting whether the I/O submitter is idle. Shouldn't this kind of
infrastructure be added after support has been added in blk-mq for I/O
scheduling?
Thanks,
Bart.
^ permalink raw reply
* Re: Long delays creating a netns after deleting one (possibly RCU related)
From: Eric Dumazet @ 2016-11-14 22:46 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Paul E. McKenney, Cong Wang, Rolf Neugebauer, LKML,
Linux Kernel Network Developers, Justin Cormack, Ian Campbell,
Eric Dumazet
In-Reply-To: <87y40lhfrt.fsf@xmission.com>
On Mon, 2016-11-14 at 16:12 -0600, Eric W. Biederman wrote:
> synchronize_rcu_expidited is not enough if you have multiple network
> devices in play.
>
> Looking at the code it comes down to this commit, and it appears there
> is a promise add rcu grace period combining by Eric Dumazet.
>
> Eric since people are hitting noticable stalls because of the rcu grace
> period taking a long time do you think you could look at this code path
> a bit more?
>
> commit 93d05d4a320cb16712bb3d57a9658f395d8cecb9
> Author: Eric Dumazet <edumazet@google.com>
> Date: Wed Nov 18 06:31:03 2015 -0800
Absolutely, I will take a loop asap.
Thanks Eric.
^ permalink raw reply
* [Buildroot] [PATCH] package/gcc: backport xtensa trap pattern for 5.x
From: Thomas Petazzoni @ 2016-11-14 22:45 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161114225553.0adf1094@free-electrons.com>
Hello,
On Mon, 14 Nov 2016 22:55:53 +0100, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 14 Nov 2016 02:05:41 -0800, Max Filippov wrote:
> > gcc 5.x uses trap pattern extensively to mark locations where program
> > execution should never get. Default pattern implementation emits a call
> > to 'abort' function. This function however is not always available, e.g.
> > it's not available for the libc dynamic linker. Backport implementation
> > of the trap pattern for xtensa that does not result in a call to
> > 'abort'.
> >
> > Fixes:
> > http://autobuild.buildroot.net/results/0fbcc4475545904bf88f25a3bdf3ee552bf4960e
> > http://autobuild.buildroot.net/results/cb7f5bdfac615d774f3bcd1b802f8d74460bc557
> > http://autobuild.buildroot.net/results/cf3dc9ae4f74ff28b285f1a862b71d96384d7651
> >
> > Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> > ---
> > .../5.4.0/875-xtensa-implement-trap-pattern.patch | 67 ++++++++++++++++++++++
> > 1 file changed, 67 insertions(+)
> > create mode 100644 package/gcc/5.4.0/875-xtensa-implement-trap-pattern.patch
>
> Applied to master, thanks. However, I'm wondering if this backport
> should also be done on gcc versions earlier than 5.x. Could you clarify
> this point?
FYI, I've rebuilt the Xtensa pre-built toolchain and deployed it to
autobuild.b.o for our autobuilders to use.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* + mm-hugetlb-support-gigantic-surplus-pages.patch added to -mm tree
From: akpm @ 2016-11-14 22:44 UTC (permalink / raw)
To: shijie.huang, aneesh.kumar, catalin.marinas, gerald.schaefer,
kaly.xin, kirill.shutemov, mhocko, mike.kravetz, n-horiguchi,
steve.capper, will.deacon, mm-commits
The patch titled
Subject: mm: hugetlb: support gigantic surplus pages
has been added to the -mm tree. Its filename is
mm-hugetlb-support-gigantic-surplus-pages.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-support-gigantic-surplus-pages.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-support-gigantic-surplus-pages.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huang Shijie <shijie.huang@arm.com>
Subject: mm: hugetlb: support gigantic surplus pages
When testing the gigantic page whose order is too large for the buddy
allocator, the libhugetlbfs test case "counter.sh" will fail.
The failure is caused by:
1) kernel fails to allocate a gigantic page for the surplus case.
And the gather_surplus_pages() will return NULL in the end.
2) The condition checks for "over-commit" is wrong.
This patch uses __hugetlb_alloc_gigantic_page() to allocate the
gigantic page in the __alloc_huge_page(). After this patch,
gather_surplus_pages() can return a gigantic page for the surplus case.
This patch also changes the condition checks for:
return_unused_surplus_pages()
nr_overcommit_hugepages_store()
hugetlb_overcommit_handler()
After this patch, the counter.sh test can pass for the gigantic page.
Link: http://lkml.kernel.org/r/1479107259-2011-7-git-send-email-shijie.huang@arm.com
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kirill A . Shutemov <kirill.shutemov@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Kaly Xin <kaly.xin@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/hugetlb.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff -puN mm/hugetlb.c~mm-hugetlb-support-gigantic-surplus-pages mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-support-gigantic-surplus-pages
+++ a/mm/hugetlb.c
@@ -1647,7 +1647,7 @@ static struct page *__alloc_huge_page(st
struct page *page;
unsigned int r_nid;
- if (hstate_is_gigantic(h))
+ if (hstate_is_gigantic(h) && !gigantic_page_supported())
return NULL;
/*
@@ -1692,7 +1692,10 @@ static struct page *__alloc_huge_page(st
}
spin_unlock(&hugetlb_lock);
- page = __hugetlb_alloc_buddy_huge_page(h, vma, addr, nid);
+ if (hstate_is_gigantic(h))
+ page = __hugetlb_alloc_gigantic_page(h, vma, addr, nid);
+ else
+ page = __hugetlb_alloc_buddy_huge_page(h, vma, addr, nid);
spin_lock(&hugetlb_lock);
if (page) {
@@ -1859,8 +1862,7 @@ static void return_unused_surplus_pages(
/* Uncommit the reservation */
h->resv_huge_pages -= unused_resv_pages;
- /* Cannot return gigantic pages currently */
- if (hstate_is_gigantic(h))
+ if (hstate_is_gigantic(h) && !gigantic_page_supported())
return;
nr_pages = min(unused_resv_pages, h->surplus_huge_pages);
@@ -2577,7 +2579,7 @@ static ssize_t nr_overcommit_hugepages_s
unsigned long input;
struct hstate *h = kobj_to_hstate(kobj, NULL);
- if (hstate_is_gigantic(h))
+ if (hstate_is_gigantic(h) && !gigantic_page_supported())
return -EINVAL;
err = kstrtoul(buf, 10, &input);
@@ -3018,7 +3020,7 @@ int hugetlb_overcommit_handler(struct ct
tmp = h->nr_overcommit_huge_pages;
- if (write && hstate_is_gigantic(h))
+ if (write && hstate_is_gigantic(h) && !gigantic_page_supported())
return -EINVAL;
table->data = &tmp;
_
Patches currently in -mm which might be from shijie.huang@arm.com are
mm-hugetlb-rename-some-allocation-functions.patch
mm-hugetlb-add-a-new-parameter-for-some-functions.patch
mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page.patch
mm-mempolicy-intruduce-a-helper-huge_nodemask.patch
mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page.patch
mm-hugetlb-support-gigantic-surplus-pages.patch
^ permalink raw reply
* Re: [PATCH v2] [STYLE]staging:vme:vme_user.c Correct spelling mistakes
From: Martyn Welch @ 2016-11-14 22:44 UTC (permalink / raw)
To: Walt Feasel; +Cc: manohar.vanga, gregkh, devel, linux-kernel
In-Reply-To: <1479086914-1320-1-git-send-email-waltfeasel@gmail.com>
On Sun, Nov 13, 2016 at 08:28:34PM -0500, Walt Feasel wrote:
> Make spelling corrections for 'correctly' and
> 'unregister'.
>
> Signed-off-by: Walt Feasel <waltfeasel@gmail.com>
Acked-by: Martyn Welch <martyn@welchs.me.uk>
> ---
>
> Removed the previously submitted U.S. spelling for
> 'initialise' to keep the correct U.K. spelling.
>
> drivers/staging/vme/devices/vme_user.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/vme/devices/vme_user.c b/drivers/staging/vme/devices/vme_user.c
> index 5dd430f..2753fb2 100644
> --- a/drivers/staging/vme/devices/vme_user.c
> +++ b/drivers/staging/vme/devices/vme_user.c
> @@ -661,7 +661,7 @@ static int vme_user_probe(struct vme_dev *vdev)
> }
> class_destroy(vme_user_sysfs_class);
>
> - /* Ensure counter set correcty to unalloc all master windows */
> + /* Ensure counter set correctly to unalloc all master windows */
> i = MASTER_MAX + 1;
> err_master:
> while (i > MASTER_MINOR) {
> @@ -671,7 +671,7 @@ static int vme_user_probe(struct vme_dev *vdev)
> }
>
> /*
> - * Ensure counter set correcty to unalloc all slave windows and buffers
> + * Ensure counter set correctly to unalloc all slave windows and buffers
> */
> i = SLAVE_MAX + 1;
> err_slave:
> @@ -716,7 +716,7 @@ static int vme_user_remove(struct vme_dev *dev)
> /* Unregister device driver */
> cdev_del(vme_user_cdev);
>
> - /* Unregiser the major and minor device numbers */
> + /* Unregister the major and minor device numbers */
> unregister_chrdev_region(MKDEV(VME_MAJOR, 0), VME_DEVS);
>
> return 0;
> --
> 2.1.4
>
^ permalink raw reply
* + mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page.patch added to -mm tree
From: akpm @ 2016-11-14 22:44 UTC (permalink / raw)
To: shijie.huang, aneesh.kumar, catalin.marinas, gerald.schaefer,
kaly.xin, kirill.shutemov, mhocko, mike.kravetz, n-horiguchi,
steve.capper, will.deacon, mm-commits
The patch titled
Subject: mm: hugetlb: add a new function to allocate a new gigantic page
has been added to the -mm tree. Its filename is
mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huang Shijie <shijie.huang@arm.com>
Subject: mm: hugetlb: add a new function to allocate a new gigantic page
There are three ways we can allocate a new gigantic page:
1. When the NUMA is not enabled, use alloc_gigantic_page() to get
the gigantic page.
2. The NUMA is enabled, but the vma is NULL.
There is no memory policy we can refer to.
So create a @nodes_allowed, initialize it with init_nodemask_of_mempolicy()
or init_nodemask_of_node(). Then use alloc_fresh_gigantic_page() to get
the gigantic page.
3. The NUMA is enabled, and the vma is valid.
We can follow the memory policy of the @vma.
Get @nodes_mask by huge_nodemask(), and use alloc_fresh_gigantic_page()
to get the gigantic page.
Link: http://lkml.kernel.org/r/1479107259-2011-6-git-send-email-shijie.huang@arm.com
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kirill A . Shutemov <kirill.shutemov@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Kaly Xin <kaly.xin@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/hugetlb.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff -puN mm/hugetlb.c~mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page
+++ a/mm/hugetlb.c
@@ -1502,6 +1502,73 @@ int dissolve_free_huge_pages(unsigned lo
/*
* There are 3 ways this can get called:
+ *
+ * 1. When the NUMA is not enabled, use alloc_gigantic_page() to get
+ * the gigantic page.
+ *
+ * 2. The NUMA is enabled, but the vma is NULL.
+ * Create a @nodes_allowed, use alloc_fresh_gigantic_page() to get
+ * the gigantic page.
+ *
+ * 3. The NUMA is enabled, and the vma is valid.
+ * Use the @vma's memory policy.
+ * Get @nodes_mask by huge_nodemask(), and use alloc_fresh_gigantic_page()
+ * to get the gigantic page.
+ */
+static struct page *__hugetlb_alloc_gigantic_page(struct hstate *h,
+ struct vm_area_struct *vma, unsigned long addr, int nid)
+{
+ struct page *page;
+ nodemask_t *nodes_mask;
+
+ /* Not NUMA */
+ if (!IS_ENABLED(CONFIG_NUMA)) {
+ if (nid == NUMA_NO_NODE)
+ nid = numa_mem_id();
+
+ page = alloc_gigantic_page(nid, huge_page_order(h));
+ if (page)
+ prep_compound_gigantic_page(page, huge_page_order(h));
+
+ return page;
+ }
+
+ /* NUMA && !vma */
+ if (!vma) {
+ NODEMASK_ALLOC(nodemask_t, nodes_allowed,
+ GFP_KERNEL | __GFP_NORETRY);
+
+ if (nid == NUMA_NO_NODE) {
+ if (!init_nodemask_of_mempolicy(nodes_allowed)) {
+ NODEMASK_FREE(nodes_allowed);
+ nodes_allowed = &node_states[N_MEMORY];
+ }
+ } else if (nodes_allowed) {
+ init_nodemask_of_node(nodes_allowed, nid);
+ } else {
+ nodes_allowed = &node_states[N_MEMORY];
+ }
+
+ page = alloc_fresh_gigantic_page(h, nodes_allowed, true);
+
+ if (nodes_allowed != &node_states[N_MEMORY])
+ NODEMASK_FREE(nodes_allowed);
+
+ return page;
+ }
+
+ /* NUMA && vma */
+ nodes_mask = huge_nodemask(vma, addr);
+ if (nodes_mask) {
+ page = alloc_fresh_gigantic_page(h, nodes_mask, true);
+ if (page)
+ return page;
+ }
+ return NULL;
+}
+
+/*
+ * There are 3 ways this can get called:
* 1. With vma+addr: we use the VMA's memory policy
* 2. With !vma, but nid=NUMA_NO_NODE: We try to allocate a huge
* page from any node, and let the buddy allocator itself figure
_
Patches currently in -mm which might be from shijie.huang@arm.com are
mm-hugetlb-rename-some-allocation-functions.patch
mm-hugetlb-add-a-new-parameter-for-some-functions.patch
mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page.patch
mm-mempolicy-intruduce-a-helper-huge_nodemask.patch
mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page.patch
mm-hugetlb-support-gigantic-surplus-pages.patch
^ permalink raw reply
* + mm-mempolicy-intruduce-a-helper-huge_nodemask.patch added to -mm tree
From: akpm @ 2016-11-14 22:44 UTC (permalink / raw)
To: shijie.huang, aneesh.kumar, catalin.marinas, gerald.schaefer,
kaly.xin, kirill.shutemov, mhocko, mike.kravetz, n-horiguchi,
steve.capper, will.deacon, mm-commits
The patch titled
Subject: mm: mempolicy: intruduce a helper huge_nodemask()
has been added to the -mm tree. Its filename is
mm-mempolicy-intruduce-a-helper-huge_nodemask.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-mempolicy-intruduce-a-helper-huge_nodemask.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-mempolicy-intruduce-a-helper-huge_nodemask.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huang Shijie <shijie.huang@arm.com>
Subject: mm: mempolicy: intruduce a helper huge_nodemask()
Introduce a new helper huge_nodemask(), we can use it to get the node
mask.
This idea of the function is from huge_zonelist().
Link: http://lkml.kernel.org/r/1479107259-2011-5-git-send-email-shijie.huang@arm.com
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kirill A . Shutemov <kirill.shutemov@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Kaly Xin <kaly.xin@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/mempolicy.h | 8 ++++++++
mm/mempolicy.c | 20 ++++++++++++++++++++
2 files changed, 28 insertions(+)
diff -puN include/linux/mempolicy.h~mm-mempolicy-intruduce-a-helper-huge_nodemask include/linux/mempolicy.h
--- a/include/linux/mempolicy.h~mm-mempolicy-intruduce-a-helper-huge_nodemask
+++ a/include/linux/mempolicy.h
@@ -145,6 +145,8 @@ extern void mpol_rebind_task(struct task
enum mpol_rebind_step step);
extern void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new);
+extern nodemask_t *huge_nodemask(struct vm_area_struct *vma,
+ unsigned long addr);
extern struct zonelist *huge_zonelist(struct vm_area_struct *vma,
unsigned long addr, gfp_t gfp_flags,
struct mempolicy **mpol, nodemask_t **nodemask);
@@ -261,6 +263,12 @@ static inline void mpol_rebind_mm(struct
{
}
+static inline nodemask_t *huge_nodemask(struct vm_area_struct *vma,
+ unsigned long addr)
+{
+ return NULL;
+}
+
static inline struct zonelist *huge_zonelist(struct vm_area_struct *vma,
unsigned long addr, gfp_t gfp_flags,
struct mempolicy **mpol, nodemask_t **nodemask)
diff -puN mm/mempolicy.c~mm-mempolicy-intruduce-a-helper-huge_nodemask mm/mempolicy.c
--- a/mm/mempolicy.c~mm-mempolicy-intruduce-a-helper-huge_nodemask
+++ a/mm/mempolicy.c
@@ -1800,6 +1800,26 @@ static inline unsigned interleave_nid(st
#ifdef CONFIG_HUGETLBFS
/*
+ * huge_nodemask(@vma, @addr)
+ * @vma: virtual memory area whose policy is sought
+ * @addr: address in @vma for shared policy lookup and interleave policy
+ *
+ * If the effective policy is BIND, returns a pointer to the mempolicy's
+ * @nodemask.
+ */
+nodemask_t *huge_nodemask(struct vm_area_struct *vma, unsigned long addr)
+{
+ nodemask_t *nodes_mask = NULL;
+ struct mempolicy *mpol = get_vma_policy(vma, addr);
+
+ if (mpol->mode == MPOL_BIND)
+ nodes_mask = &mpol->v.nodes;
+ mpol_cond_put(mpol);
+
+ return nodes_mask;
+}
+
+/*
* huge_zonelist(@vma, @addr, @gfp_flags, @mpol)
* @vma: virtual memory area whose policy is sought
* @addr: address in @vma for shared policy lookup and interleave policy
_
Patches currently in -mm which might be from shijie.huang@arm.com are
mm-hugetlb-rename-some-allocation-functions.patch
mm-hugetlb-add-a-new-parameter-for-some-functions.patch
mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page.patch
mm-mempolicy-intruduce-a-helper-huge_nodemask.patch
mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page.patch
mm-hugetlb-support-gigantic-surplus-pages.patch
^ permalink raw reply
* + mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page.patch added to -mm tree
From: akpm @ 2016-11-14 22:44 UTC (permalink / raw)
To: shijie.huang, aneesh.kumar, catalin.marinas, gerald.schaefer,
kaly.xin, kirill.shutemov, mhocko, mike.kravetz, n-horiguchi,
steve.capper, will.deacon, mm-commits
The patch titled
Subject: mm: hugetlb: change the return type of alloc_fresh_gigantic_page()
has been added to the -mm tree. Its filename is
mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huang Shijie <shijie.huang@arm.com>
Subject: mm: hugetlb: change the return type of alloc_fresh_gigantic_page()
Change the return type to "struct page*" for alloc_fresh_gigantic_page().
This is in preparation for a later patch.
Link: http://lkml.kernel.org/r/1479107259-2011-4-git-send-email-shijie.huang@arm.com
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kirill A . Shutemov <kirill.shutemov@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Kaly Xin <kaly.xin@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/hugetlb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff -puN mm/hugetlb.c~mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page
+++ a/mm/hugetlb.c
@@ -1142,7 +1142,7 @@ static struct page *alloc_fresh_gigantic
return page;
}
-static int alloc_fresh_gigantic_page(struct hstate *h,
+static struct page *alloc_fresh_gigantic_page(struct hstate *h,
nodemask_t *nodes_allowed, bool no_init)
{
struct page *page = NULL;
@@ -1151,10 +1151,10 @@ static int alloc_fresh_gigantic_page(str
for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
page = alloc_fresh_gigantic_page_node(h, node, no_init);
if (page)
- return 1;
+ return page;
}
- return 0;
+ return NULL;
}
static inline bool gigantic_page_supported(void) { return true; }
@@ -1167,8 +1167,8 @@ static inline bool gigantic_page_support
static inline void free_gigantic_page(struct page *page, unsigned int order) { }
static inline void destroy_compound_gigantic_page(struct page *page,
unsigned int order) { }
-static inline int alloc_fresh_gigantic_page(struct hstate *h,
- nodemask_t *nodes_allowed, bool no_init) { return 0; }
+static inline struct page *alloc_fresh_gigantic_page(struct hstate *h,
+ nodemask_t *nodes_allowed, bool no_init) { return NULL; }
#endif
static void update_and_free_page(struct hstate *h, struct page *page)
@@ -2315,7 +2315,7 @@ static unsigned long set_max_huge_pages(
cond_resched();
if (hstate_is_gigantic(h))
- ret = alloc_fresh_gigantic_page(h, nodes_allowed,
+ ret = !!alloc_fresh_gigantic_page(h, nodes_allowed,
false);
else
ret = alloc_fresh_huge_page(h, nodes_allowed);
_
Patches currently in -mm which might be from shijie.huang@arm.com are
mm-hugetlb-rename-some-allocation-functions.patch
mm-hugetlb-add-a-new-parameter-for-some-functions.patch
mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page.patch
mm-mempolicy-intruduce-a-helper-huge_nodemask.patch
mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page.patch
mm-hugetlb-support-gigantic-surplus-pages.patch
^ permalink raw reply
* + mm-hugetlb-add-a-new-parameter-for-some-functions.patch added to -mm tree
From: akpm @ 2016-11-14 22:44 UTC (permalink / raw)
To: shijie.huang, aneesh.kumar, catalin.marinas, gerald.schaefer,
kaly.xin, kirill.shutemov, mhocko, mike.kravetz, n-horiguchi,
steve.capper, will.deacon, mm-commits
The patch titled
Subject: mm: hugetlb: add a new parameter for some functions
has been added to the -mm tree. Its filename is
mm-hugetlb-add-a-new-parameter-for-some-functions.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-add-a-new-parameter-for-some-functions.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-add-a-new-parameter-for-some-functions.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huang Shijie <shijie.huang@arm.com>
Subject: mm: hugetlb: add a new parameter for some functions
Add a new parameter, the "no_init", to these functions:
alloc_fresh_gigantic_page_node()
alloc_fresh_gigantic_page()
prep_new_huge_page() does some initialization for the new page. But
sometimes we do not need it to do so, such as in the surplus case in a
later patch.
With this parameter, prep_new_huge_page() can be called by needed:
If the "no_init" is false, calls the prep_new_huge_page() in
the alloc_fresh_gigantic_page_node();
This is in preparation for later patches.
Link: http://lkml.kernel.org/r/1479107259-2011-3-git-send-email-shijie.huang@arm.com
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kirill A . Shutemov <kirill.shutemov@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Kaly Xin <kaly.xin@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/hugetlb.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff -puN mm/hugetlb.c~mm-hugetlb-add-a-new-parameter-for-some-functions mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-add-a-new-parameter-for-some-functions
+++ a/mm/hugetlb.c
@@ -1127,27 +1127,29 @@ static struct page *alloc_gigantic_page(
static void prep_new_huge_page(struct hstate *h, struct page *page, int nid);
static void prep_compound_gigantic_page(struct page *page, unsigned int order);
-static struct page *alloc_fresh_gigantic_page_node(struct hstate *h, int nid)
+static struct page *alloc_fresh_gigantic_page_node(struct hstate *h,
+ int nid, bool no_init)
{
struct page *page;
page = alloc_gigantic_page(nid, huge_page_order(h));
if (page) {
prep_compound_gigantic_page(page, huge_page_order(h));
- prep_new_huge_page(h, page, nid);
+ if (!no_init)
+ prep_new_huge_page(h, page, nid);
}
return page;
}
static int alloc_fresh_gigantic_page(struct hstate *h,
- nodemask_t *nodes_allowed)
+ nodemask_t *nodes_allowed, bool no_init)
{
struct page *page = NULL;
int nr_nodes, node;
for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
- page = alloc_fresh_gigantic_page_node(h, node);
+ page = alloc_fresh_gigantic_page_node(h, node, no_init);
if (page)
return 1;
}
@@ -1166,7 +1168,7 @@ static inline void free_gigantic_page(st
static inline void destroy_compound_gigantic_page(struct page *page,
unsigned int order) { }
static inline int alloc_fresh_gigantic_page(struct hstate *h,
- nodemask_t *nodes_allowed) { return 0; }
+ nodemask_t *nodes_allowed, bool no_init) { return 0; }
#endif
static void update_and_free_page(struct hstate *h, struct page *page)
@@ -2313,7 +2315,8 @@ static unsigned long set_max_huge_pages(
cond_resched();
if (hstate_is_gigantic(h))
- ret = alloc_fresh_gigantic_page(h, nodes_allowed);
+ ret = alloc_fresh_gigantic_page(h, nodes_allowed,
+ false);
else
ret = alloc_fresh_huge_page(h, nodes_allowed);
spin_lock(&hugetlb_lock);
_
Patches currently in -mm which might be from shijie.huang@arm.com are
mm-hugetlb-rename-some-allocation-functions.patch
mm-hugetlb-add-a-new-parameter-for-some-functions.patch
mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page.patch
mm-mempolicy-intruduce-a-helper-huge_nodemask.patch
mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page.patch
mm-hugetlb-support-gigantic-surplus-pages.patch
^ permalink raw reply
* + mm-hugetlb-rename-some-allocation-functions.patch added to -mm tree
From: akpm @ 2016-11-14 22:44 UTC (permalink / raw)
To: shijie.huang, aneesh.kumar, catalin.marinas, gerald.schaefer,
kaly.xin, kirill.shutemov, mhocko, mike.kravetz, n-horiguchi,
steve.capper, will.deacon, mm-commits
The patch titled
Subject: mm: hugetlb: rename some allocation functions
has been added to the -mm tree. Its filename is
mm-hugetlb-rename-some-allocation-functions.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-rename-some-allocation-functions.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-rename-some-allocation-functions.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huang Shijie <shijie.huang@arm.com>
Subject: mm: hugetlb: rename some allocation functions
Patch series "mm: fix the "counter.sh" failure for libhugetlbfs", v2.
(1) Background
For the arm64, the hugetlb page size can be 32M (PMD + Contiguous bit).
In the 4K page environment, the max page order is 10 (max_order - 1),
so 32M page is the gigantic page.
The arm64 MMU supports a Contiguous bit which is a hint that the TTE
is one of a set of contiguous entries which can be cached in a single
TLB entry. Please refer to the arm64v8 mannul :
DDI0487A_f_armv8_arm.pdf (in page D4-1811)
(2) The bug
After I tested the libhugetlbfs, I found the test case "counter.sh"
will fail with the gigantic page (32M page in arm64 board).
This patch set adds support for gigantic surplus hugetlb pages,
allowing the counter.sh unit test to pass.
This patch (of 6):
After a future patch __alloc_buddy_huge_page() will not necessarily use
the buddy allocator.
So remove the "buddy" from these functions:
__alloc_buddy_huge_page -> __alloc_huge_page
__alloc_buddy_huge_page_no_mpol -> __alloc_huge_page_no_mpol
__alloc_buddy_huge_page_with_mpol -> __alloc_huge_page_with_mpol
This patch si in preparation for the later patch.
Link: http://lkml.kernel.org/r/1479107259-2011-2-git-send-email-shijie.huang@arm.com
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kirill A . Shutemov <kirill.shutemov@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Kaly Xin <kaly.xin@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/hugetlb.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff -puN mm/hugetlb.c~mm-hugetlb-rename-some-allocation-functions mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-rename-some-allocation-functions
+++ a/mm/hugetlb.c
@@ -1157,6 +1157,10 @@ static int alloc_fresh_gigantic_page(str
static inline bool gigantic_page_supported(void) { return true; }
#else
+static inline struct page *alloc_gigantic_page(int nid, unsigned int order)
+{
+ return NULL;
+}
static inline bool gigantic_page_supported(void) { return false; }
static inline void free_gigantic_page(struct page *page, unsigned int order) { }
static inline void destroy_compound_gigantic_page(struct page *page,
@@ -1568,7 +1572,7 @@ static struct page *__hugetlb_alloc_budd
* For (2), we ignore 'vma' and 'addr' and use 'nid' exclusively. This
* implies that memory policies will not be taken in to account.
*/
-static struct page *__alloc_buddy_huge_page(struct hstate *h,
+static struct page *__alloc_huge_page(struct hstate *h,
struct vm_area_struct *vma, unsigned long addr, int nid)
{
struct page *page;
@@ -1649,21 +1653,21 @@ static struct page *__alloc_buddy_huge_p
* anywhere.
*/
static
-struct page *__alloc_buddy_huge_page_no_mpol(struct hstate *h, int nid)
+struct page *__alloc_huge_page_no_mpol(struct hstate *h, int nid)
{
unsigned long addr = -1;
- return __alloc_buddy_huge_page(h, NULL, addr, nid);
+ return __alloc_huge_page(h, NULL, addr, nid);
}
/*
* Use the VMA's mpolicy to allocate a huge page from the buddy.
*/
static
-struct page *__alloc_buddy_huge_page_with_mpol(struct hstate *h,
+struct page *__alloc_huge_page_with_mpol(struct hstate *h,
struct vm_area_struct *vma, unsigned long addr)
{
- return __alloc_buddy_huge_page(h, vma, addr, NUMA_NO_NODE);
+ return __alloc_huge_page(h, vma, addr, NUMA_NO_NODE);
}
/*
@@ -1681,7 +1685,7 @@ struct page *alloc_huge_page_node(struct
spin_unlock(&hugetlb_lock);
if (!page)
- page = __alloc_buddy_huge_page_no_mpol(h, nid);
+ page = __alloc_huge_page_no_mpol(h, nid);
return page;
}
@@ -1711,7 +1715,7 @@ static int gather_surplus_pages(struct h
retry:
spin_unlock(&hugetlb_lock);
for (i = 0; i < needed; i++) {
- page = __alloc_buddy_huge_page_no_mpol(h, NUMA_NO_NODE);
+ page = __alloc_huge_page_no_mpol(h, NUMA_NO_NODE);
if (!page) {
alloc_ok = false;
break;
@@ -2027,7 +2031,7 @@ struct page *alloc_huge_page(struct vm_a
page = dequeue_huge_page_vma(h, vma, addr, avoid_reserve, gbl_chg);
if (!page) {
spin_unlock(&hugetlb_lock);
- page = __alloc_buddy_huge_page_with_mpol(h, vma, addr);
+ page = __alloc_huge_page_with_mpol(h, vma, addr);
if (!page)
goto out_uncharge_cgroup;
if (!avoid_reserve && vma_has_reserves(vma, gbl_chg)) {
@@ -2285,7 +2289,7 @@ static unsigned long set_max_huge_pages(
* First take pages out of surplus state. Then make up the
* remaining difference by allocating fresh huge pages.
*
- * We might race with __alloc_buddy_huge_page() here and be unable
+ * We might race with __alloc_huge_page() here and be unable
* to convert a surplus huge page to a normal huge page. That is
* not critical, though, it just means the overall size of the
* pool might be one hugepage larger than it needs to be, but
@@ -2331,7 +2335,7 @@ static unsigned long set_max_huge_pages(
* By placing pages into the surplus state independent of the
* overcommit value, we are allowing the surplus pool size to
* exceed overcommit. There are few sane options here. Since
- * __alloc_buddy_huge_page() is checking the global counter,
+ * __alloc_huge_page() is checking the global counter,
* though, we'll note that we're not allowed to exceed surplus
* and won't grow the pool anywhere else. Not until one of the
* sysctls are changed, or the surplus pages go out of use.
_
Patches currently in -mm which might be from shijie.huang@arm.com are
mm-hugetlb-rename-some-allocation-functions.patch
mm-hugetlb-add-a-new-parameter-for-some-functions.patch
mm-hugetlb-change-the-return-type-for-alloc_fresh_gigantic_page.patch
mm-mempolicy-intruduce-a-helper-huge_nodemask.patch
mm-hugetlb-add-a-new-function-to-allocate-a-new-gigantic-page.patch
mm-hugetlb-support-gigantic-surplus-pages.patch
^ permalink raw reply
* Re: [PATCH v2 0/6] mm: fix the "counter.sh" failure for libhugetlbfs
From: Andrew Morton @ 2016-11-14 22:44 UTC (permalink / raw)
To: Huang Shijie
Cc: catalin.marinas, n-horiguchi, mhocko, kirill.shutemov,
aneesh.kumar, gerald.schaefer, mike.kravetz, linux-mm,
will.deacon, steve.capper, kaly.xin, nd, linux-arm-kernel
In-Reply-To: <1479107259-2011-1-git-send-email-shijie.huang@arm.com>
On Mon, 14 Nov 2016 15:07:33 +0800 Huang Shijie <shijie.huang@arm.com> wrote:
> (1) Background
> For the arm64, the hugetlb page size can be 32M (PMD + Contiguous bit).
> In the 4K page environment, the max page order is 10 (max_order - 1),
> so 32M page is the gigantic page.
>
> The arm64 MMU supports a Contiguous bit which is a hint that the TTE
> is one of a set of contiguous entries which can be cached in a single
> TLB entry. Please refer to the arm64v8 mannul :
> DDI0487A_f_armv8_arm.pdf (in page D4-1811)
>
> (2) The bug
> After I tested the libhugetlbfs, I found the test case "counter.sh"
> will fail with the gigantic page (32M page in arm64 board).
>
> This patch set adds support for gigantic surplus hugetlb pages,
> allowing the counter.sh unit test to pass.
I'm not really seeing a description of the actual bug. I don't know
what counter.sh is, there is no copy of counter.sh included in the
changelogs and there is no description of the kernel error which
counter.sh demonstrates.
So can you pleaser send to me a copy of counter.sh as well as a
suitable description of the kernel error which counter.sh triggers?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH v2 0/6] mm: fix the "counter.sh" failure for libhugetlbfs
From: Andrew Morton @ 2016-11-14 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-1-git-send-email-shijie.huang@arm.com>
On Mon, 14 Nov 2016 15:07:33 +0800 Huang Shijie <shijie.huang@arm.com> wrote:
> (1) Background
> For the arm64, the hugetlb page size can be 32M (PMD + Contiguous bit).
> In the 4K page environment, the max page order is 10 (max_order - 1),
> so 32M page is the gigantic page.
>
> The arm64 MMU supports a Contiguous bit which is a hint that the TTE
> is one of a set of contiguous entries which can be cached in a single
> TLB entry. Please refer to the arm64v8 mannul :
> DDI0487A_f_armv8_arm.pdf (in page D4-1811)
>
> (2) The bug
> After I tested the libhugetlbfs, I found the test case "counter.sh"
> will fail with the gigantic page (32M page in arm64 board).
>
> This patch set adds support for gigantic surplus hugetlb pages,
> allowing the counter.sh unit test to pass.
I'm not really seeing a description of the actual bug. I don't know
what counter.sh is, there is no copy of counter.sh included in the
changelogs and there is no description of the kernel error which
counter.sh demonstrates.
So can you pleaser send to me a copy of counter.sh as well as a
suitable description of the kernel error which counter.sh triggers?
^ permalink raw reply
* [U-Boot] [PATCH v2 1/3] spl: add RAM boot device only if it is actually defined
From: Stefan Agner @ 2016-11-14 22:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ11+SB_2mkELbg2DuNHcjGLFrwWHodaHSXcb=ZWDW125Q@mail.gmail.com>
On 2016-11-14 12:44, Simon Glass wrote:
> Hi Stefan,
>
> On 12 November 2016 at 12:13, Stefan Agner <stefan@agner.ch> wrote:
>> From: Stefan Agner <stefan.agner@toradex.com>
>>
>> Some devices (e.g. dra7xx) support loading to RAM using DFU without
>> having direct boot from RAM support. Make sure the linker list
>> does not contain BOOT_DEVICE_RAM if CONFIG_SPL_RAM_SUPPORT is not
>> enabled.
>>
>> Fixes: 98136b2f26fa ("spl: Convert spl_ram_load_image() to use linker list")
>>
>> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
>> ---
>>
>> Changes in v2:
>> - Use CONFIG_SPL_RAM_SUPPORT to descide whether to compile the
>> function in first place.
>>
>> common/spl/spl.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> Instead of this, how about moving it into its own file and putting
> that condition in the Makefile?
Generally a good idea.
What I don't like to much that we have two orthogonal config options
using that same function...
We probably should have something like:
CONFIG_SPL_RAM_SUPPORT
CONFIG_SPL_RAM_ONLY_SUPPORT depends on CONFIG_SPL_RAM_SUPPORT
CONFIG_SPL_DFU_SUPPORT depends on CONFIG_SPL_RAM_SUPPORT
Then we could use a single config option (CONFIG_SPL_RAM_SUPPORT) for
the new file.
However, that is beyond bug fixing, and I'd rather prefer to have it in
a separate patch, what do you think?
--
Stefan
^ permalink raw reply
* Re: [PATCH linux v6 18/18] drivers/fsi: Add SCOM FSI client device driver
From: Christopher Bostic @ 2016-11-14 22:43 UTC (permalink / raw)
To: Alistair Popple; +Cc: OpenBMC Maillist, xxpetri, zahrens
In-Reply-To: <CAA0LjjU7hAuqFpmDcm6TEUiMC4FkMm9B=cNFv=wuntJJ=K6JSw@mail.gmail.com>
On Mon, Nov 14, 2016 at 11:13 AM, Christopher Bostic
<christopher.lee.bostic@gmail.com> wrote:
> On Sun, Nov 13, 2016 at 5:44 PM, Alistair Popple <alistair@popple.id.au> wrote:
>> Hi Chris,
>>
>> Is there a similar device driver for the CFAM/FSI that I missed? That is will
>> there be a chardev for read/writing FSI addresses directly (ie. a chardev to
>> call fsi_device_read/write)? Probably not critical for an initial release but
>> we will need one at some point as I'm pretty sure the cronus server for
>> example has get/putcfam commands as some registers aren't available via SCOM.
>>
>> Regards,
>>
>> Alistair
>>
>
> Hi Alistair,
>
> No there isn't a driver like you describe in the set as it is now. I
> agree that would be important to have for general bringup debug.
> Once this set is accepted I'll add that.
>
To clarify, for each engine's address space in a cfam there will be a
'client' driver that
is responsible for accessing that range. SCOM driver for scom space, etc...
Right now there is only the SCOM client driver but I'll be filling in
the others shortly.
The idea though of having a general read/write driver in addition
still makes sense
to me for bringup purposes. This is I assume more in line with how
you've structured
pdbg.
Regards,
> Thanks
>
>> On Sun, 30 Oct 2016 05:09:20 PM christopher.lee.bostic@gmail.com wrote:
>>> From: Chris Bostic <cbostic@us.ibm.com>
>>>
>>> Create a simple SCOM engine device driver that reads and writes
>>> across an FSI bus.
>>>
>>> Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
>>>
>>> ---
>>>
>>> V4 - Add put_scom and get_scom operations
>>>
>>> V5 - Add character device registration and fill in read/write
>>> syscalls.
>>>
>>> V6 - Add multi scom engine support. Add list of devices.
>>> Use file private data to store and hand off scom structures.
>>>
>>> - Add lseek, open, close
>>>
>>> - Remove data/address structure to pass from user space to
>>> kernel. Use offset provided by read/write and pass data
>>>
>>> - Added list setup in init and so did not add the macro
>>> module_fsi_driver
>>>
>>> - Global structs made static where possible.
>>>
>>> - Change from char dev to use misc device api as shown
>>> in examples from Jeremy Kere.
>>> ---
>>> drivers/fsi/Kconfig | 6 ++
>>> drivers/fsi/Makefile | 1 +
>>> drivers/fsi/fsi-scom.c | 238
>> +++++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 245 insertions(+)
>>> create mode 100644 drivers/fsi/fsi-scom.c
>>>
>>> diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
>>> index b21fe3c..1fa9bc0 100644
>>> --- a/drivers/fsi/Kconfig
>>> +++ b/drivers/fsi/Kconfig
>>> @@ -23,6 +23,12 @@ config FSI_MASTER_GPIO
>>> depends on FSI
>>> ---help---
>>> This option enables a FSI master driver using GPIO lines.
>>> +
>>> +config FSI_SCOM
>>> + tristate "SCOM FSI client"
>>> + depends on FSI
>>> + ---help---
>>> + This option enables the SCOM FSI client device driver.
>>> endif
>>>
>>> endmenu
>>> diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile
>>> index 2021ce5..3e31d9a 100644
>>> --- a/drivers/fsi/Makefile
>>> +++ b/drivers/fsi/Makefile
>>> @@ -2,3 +2,4 @@
>>> obj-$(CONFIG_FSI) += fsi-core.o
>>> obj-$(CONFIG_FSI_MASTER_FAKE) += fsi-master-fake.o
>>> obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o
>>> +obj-$(CONFIG_FSI_SCOM) += fsi-scom.o
>>> diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
>>> new file mode 100644
>>> index 0000000..27be082
>>> --- /dev/null
>>> +++ b/drivers/fsi/fsi-scom.c
>>> @@ -0,0 +1,238 @@
>>> +/*
>>> + * SCOM FSI Client device driver
>>> + *
>>> + * Copyright (C) IBM Corporation 2016
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERGCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#include <linux/fsi.h>
>>> +#include <linux/module.h>
>>> +#include <linux/cdev.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/fs.h>
>>> +#include <linux/uaccess.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/miscdevice.h>
>>> +#include <linux/list.h>
>>> +
>>> +#define FSI_ENGID_SCOM 0x5
>>> +
>>> +#define SCOM_FSI2PIB_DELAY 50
>>> +
>>> +/* SCOM engine register set */
>>> +#define SCOM_DATA0_REG 0x00
>>> +#define SCOM_DATA1_REG 0x04
>>> +#define SCOM_CMD_REG 0x08
>>> +#define SCOM_RESET_REG 0x1C
>>> +
>>> +#define SCOM_RESET_CMD 0x80000000
>>> +#define SCOM_WRITE_CMD 0x80000000
>>> +
>>> +struct scom_device {
>>> + struct list_head link;
>>> + struct fsi_device *fsi_dev;
>>> + struct miscdevice mdev;
>>> + char name[32];
>>> +};
>>> +
>>> +#define to_scom_dev(x) container_of((x), struct scom_device,
>> mdev)
>>> +
>>> +static struct list_head scom_devices;
>>> +static atomic_t scom_idx = ATOMIC_INIT(0);
>>> +static int scom_probe(struct device *);
>>> +
>>> +static int put_scom(struct scom_device *scom_dev, uint64_t value,
>>> + uint32_t addr)
>>> +{
>>> + int rc;
>>> + uint32_t data = SCOM_RESET_CMD;
>>> +
>>> + rc = fsi_device_write(scom_dev->fsi_dev, SCOM_RESET_REG, &data,
>>> + sizeof(uint32_t));
>>> + if (rc)
>>> + return rc;
>>> +
>>> + data = (value >> 32) & 0xffffffff;
>>> + rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA0_REG, &data,
>>> + sizeof(uint32_t));
>>> + if (rc)
>>> + return rc;
>>> +
>>> + data = value & 0xffffffff;
>>> + rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA1_REG, &data,
>>> + sizeof(uint32_t));
>>> + if (rc)
>>> + return rc;
>>> +
>>> + data = SCOM_WRITE_CMD | addr;
>>> + return fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
>>> + sizeof(uint32_t));
>>> +}
>>> +
>>> +static int get_scom(struct scom_device *scom_dev, uint64_t *value,
>>> + uint32_t addr)
>>> +{
>>> + uint32_t result, data;
>>> + int rc;
>>> +
>>> + udelay(SCOM_FSI2PIB_DELAY);
>>> +
>>> + data = addr;
>>> + rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
>>> + sizeof(uint32_t));
>>> + if (rc)
>>> + return rc;
>>> +
>>> + rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA0_REG, &result,
>>> + sizeof(uint32_t));
>>> + if (rc)
>>> + return rc;
>>> +
>>> + *value |= (uint64_t) result << 32;
>>> + rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA1_REG, &result,
>>> + sizeof(uint32_t));
>>> + if (rc)
>>> + return rc;
>>> +
>>> + *value |= result;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static loff_t scom_llseek(struct file *filep, loff_t offset, int whence)
>>> +{
>>> + if (whence != 0) /* SEEK_SET */
>>> + return -EINVAL;
>>> +
>>> + filep->f_pos = offset;
>>> + return offset;
>>> +}
>>> +
>>> +static ssize_t scom_read(struct file *filep, char __user *buf, size_t len,
>>> + loff_t *offset)
>>> +{
>>> + int rc = 0;
>>> + struct miscdevice *mdev =
>>> + (struct miscdevice *)filep->private_data;
>>> + struct scom_device *scom = to_scom_dev(mdev);
>>> + struct device *dev = &scom->fsi_dev->dev;
>>> + uint64_t val;
>>> +
>>> + if (len != sizeof(uint64_t))
>>> + return -EINVAL;
>>> +
>>> + rc = get_scom(scom, &val, *offset);
>>> + if (rc) {
>>> + dev_dbg(dev, "get_scom fail:%d\n", rc);
>>> + return rc;
>>> + }
>>> +
>>> + rc = copy_to_user(buf, &val, len);
>>> + if (rc)
>>> + dev_dbg(dev, "copy to user failed:%d\n", rc);
>>> +
>>> + return rc ? rc : len;
>>> +}
>>> +
>>> +static ssize_t scom_write(struct file *filep, const char __user *buf,
>>> + size_t len, loff_t *offset)
>>> +{
>>> + int rc = 0;
>>> + struct miscdevice *mdev =
>>> + (struct miscdevice *)filep->private_data;
>>> + struct scom_device *scom = to_scom_dev(mdev);
>>> + struct device *dev = &scom->fsi_dev->dev;
>>> + uint64_t val;
>>> +
>>> + if (len != sizeof(uint64_t))
>>> + return -EINVAL;
>>> +
>>> + rc = copy_from_user(&val, buf, len);
>>> + if (rc) {
>>> + dev_dbg(dev, "copy from user failed:%d\n", rc);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + rc = put_scom(scom, val, *offset);
>>> + if (rc)
>>> + dev_dbg(dev, "put_scom failed with:%d\n", rc);
>>> +
>>> +
>>> + return rc ? rc : len;
>>> +}
>>> +
>>> +static const struct file_operations scom_fops = {
>>> + .owner = THIS_MODULE,
>>> + .llseek = scom_llseek,
>>> + .read = scom_read,
>>> + .write = scom_write,
>>> +};
>>> +
>>> +static int scom_probe(struct device *dev)
>>> +{
>>> + struct fsi_device *fsi_dev = to_fsi_dev(dev);
>>> + struct scom_device *scom = NULL;
>>> +
>>> + scom = devm_kzalloc(dev, sizeof(*scom), GFP_KERNEL);
>>> + if (!scom)
>>> + return -ENOMEM;
>>> +
>>> + snprintf(scom->name, sizeof(scom->name),
>>> + "scom%d", atomic_inc_return(&scom_idx));
>>> + scom->fsi_dev = fsi_dev;
>>> + scom->mdev.minor = MISC_DYNAMIC_MINOR;
>>> + scom->mdev.fops = &scom_fops;
>>> + scom->mdev.name = scom->name;
>>> + scom->mdev.parent = dev;
>>> + list_add(&scom->link, &scom_devices);
>>> +
>>> + return misc_register(&scom->mdev);
>>> +}
>>> +
>>> +static struct fsi_device_id scom_ids[] = {
>>> + {
>>> + .engine_type = FSI_ENGID_SCOM,
>>> + .version = FSI_VERSION_ANY,
>>> + },
>>> + { 0 }
>>> +};
>>> +
>>> +static struct fsi_driver scom_drv = {
>>> + .id_table = scom_ids,
>>> + .drv = {
>>> + .name = "scom",
>>> + .bus = &fsi_bus_type,
>>> + .probe = scom_probe,
>>> + }
>>> +};
>>> +
>>> +static int scom_init(void)
>>> +{
>>> + INIT_LIST_HEAD(&scom_devices);
>>> + return fsi_driver_register(&scom_drv);
>>> +}
>>> +
>>> +static void scom_exit(void)
>>> +{
>>> + struct list_head *pos;
>>> + struct scom_device *scom = NULL;
>>> +
>>> + list_for_each(pos, &scom_devices) {
>>> + scom = list_entry(pos, struct scom_device, link);
>>> + misc_deregister(&scom->mdev);
>>> + devm_kfree(&scom->fsi_dev->dev, scom);
>>> + }
>>> + fsi_driver_unregister(&scom_drv);
>>> +}
>>> +
>>> +module_init(scom_init);
>>> +module_exit(scom_exit);
>>> +MODULE_LICENSE("GPL");
>>>
>>
^ permalink raw reply
* Re: [PATCH 0/2] amd-xgbe: AMD XGBE driver updates 2016-11-14
From: Tom Lendacky @ 2016-11-14 22:42 UTC (permalink / raw)
To: netdev, David Miller; +Cc: julia.lawall, christophe.jaillet
In-Reply-To: <20161114222827.25160.24791.stgit@tlendack-t1.amdoffice.net>
On 11/14/2016 4:28 PM, Tom Lendacky wrote:
> This patch series addresses some minor issues found in the recently
> accepted patch series for the AMD XGBE driver.
>
> The following fixes are included in this driver update series:
>
> - Fix how a mask is applied to a Clause 37 register value
> - Fix some coccinelle identified warnings
>
> This patch series is based on net-next.
David,
I forgot to include the net-next repo name in the subject, please
ignore this series and I'll resend.
Thanks,
Tom
>
> ---
>
> Tom Lendacky (2):
> amd-xgbe: Fix mask appliciation for Clause 37 register
> amd-xgbe: Fix up some coccinelle identified warnings
>
>
> drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 4 ++--
> drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 5 ++---
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
^ permalink raw reply
* Re: blk-mq: preparation of the ground for BFQ inclusion
From: Jens Axboe @ 2016-11-14 22:42 UTC (permalink / raw)
To: Paolo Valente
Cc: Linus Walleij, Mark Brown, Ulf Hansson, Omar Sandoval, Jan Kara,
Bart Van Assche, linux-block, Christoph Hellwig
In-Reply-To: <347F26BB-2D0A-4DBE-9FC5-BA6C05AE02B2@linaro.org>
On 11/14/2016 03:13 PM, Paolo Valente wrote:
> Hi Jens,
> have you had time to look into the first extensions/changes required?
> Any time plan?
I was busy last week on the writeback and on the polling. I should have
something end this week.
--
Jens Axboe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.