* [PATCH 0/2] amd-xgbe: AMD XGBE driver updates 2016-11-14
From: Tom Lendacky @ 2016-11-14 22:28 UTC (permalink / raw)
To: netdev; +Cc: julia.lawall, christophe.jaillet, David Miller
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.
---
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(-)
--
Tom Lendacky
^ permalink raw reply
* [PATCH 1/2] amd-xgbe: Fix mask appliciation for Clause 37 register
From: Tom Lendacky @ 2016-11-14 22:28 UTC (permalink / raw)
To: netdev; +Cc: julia.lawall, christophe.jaillet, David Miller
In-Reply-To: <20161114222827.25160.24791.stgit@tlendack-t1.amdoffice.net>
The application of a mask to clear an area of a clause 37 register value
was not properly applied. Update the code to do the proper application
of the mask.
Reported-by: Marion & Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
index 0ecae70..4c5b90e 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
@@ -943,8 +943,8 @@ static void xgbe_an37_init(struct xgbe_prv_data *pdata)
/* Set up the Control register */
reg = XMDIO_READ(pdata, MDIO_MMD_VEND2, MDIO_VEND2_AN_CTRL);
- reg &= XGBE_AN_CL37_TX_CONFIG_MASK;
- reg &= XGBE_AN_CL37_PCS_MODE_MASK;
+ reg &= ~XGBE_AN_CL37_TX_CONFIG_MASK;
+ reg &= ~XGBE_AN_CL37_PCS_MODE_MASK;
switch (pdata->an_mode) {
case XGBE_AN_MODE_CL37:
^ permalink raw reply related
* Re: [PATCH] rmc: Fix compiling issue with musl
From: Jianxun Zhang @ 2016-11-14 22:28 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1479161454-236511-1-git-send-email-jianxun.zhang@linux.intel.com>
OOPS. Please ignore this patch. It is for another BSP project!
> On Nov 14, 2016, at 2:10 PM, Jianxun Zhang <jianxun.zhang@linux.intel.com> wrote:
>
> | src/rmcl/rmcl.c: In function 'query_policy_from_db':
> | src/rmcl/rmcl.c:254:25: error: unknown type name 'ssize_t'
> | ssize_t cmd_name_len = strlen((char *)&rmc_db[policy_idx]) + 1;
> | ^~~~~~~~
>
> The musl C lib provides ssize_t but we need to enable it
> with a macro.
>
> Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
> ---
> Before maintainer(s) push "merge" button, please read this short summary.
> I feel there could be a better syntax to do it. And We could need to get
> an ack from Hernandez, Alejandro who reported this issue and seems still
> have (other) compiling errors even with this patch.
>
> I submit this patch based on my thoughts and test out of tiny config.
>
> Tests:
> () Specify TCLIBC = "musl" in local.conf in my build dir.
> () Build quark
> () I can see this issue happens without the fix
> () With this patch and do clean builds for quark and corei7-64,
> Compiling passes. Boot test passed on RMC targets quark and Broxton-m.
>
> Thanks
>
>
> common/recipes-bsp/rmc/rmc.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
> index aeaf12e..61a1bdb 100644
> --- a/common/recipes-bsp/rmc/rmc.bb
> +++ b/common/recipes-bsp/rmc/rmc.bb
> @@ -24,6 +24,8 @@ COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
>
> EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"'
>
> +EXTRA_OEMAKE_append_libc-musl = '" -D__NEED_ssize_t"'
> +
> # from gnu-efi, we should align arch-mapping with it.
> def rmc_efi_arch(d):
> import re
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 2/2] amd-xgbe: Fix up some coccinelle identified warnings
From: Tom Lendacky @ 2016-11-14 22:28 UTC (permalink / raw)
To: netdev; +Cc: julia.lawall, christophe.jaillet, David Miller
In-Reply-To: <20161114222827.25160.24791.stgit@tlendack-t1.amdoffice.net>
Fix up some warnings that were identified by coccinelle:
Clean up an if/else block that can look confusing since the same statement
is executed in an "else if" check and the final "else" statement.
Change a variable from unsigned int to int since it is used in an if
statement checking the value to be less than 0.
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
index 4ba4332..348cc8c 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
@@ -1766,8 +1766,6 @@ static void xgbe_phy_sfi_mode(struct xgbe_prv_data *pdata)
XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 1);
else if (phy_data->sfp_cable_len <= 3)
XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 2);
- else if (phy_data->sfp_cable_len <= 5)
- XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 3);
else
XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 3);
}
@@ -2346,7 +2344,8 @@ static bool xgbe_phy_valid_speed(struct xgbe_prv_data *pdata, int speed)
static int xgbe_phy_link_status(struct xgbe_prv_data *pdata, int *an_restart)
{
struct xgbe_phy_data *phy_data = pdata->phy_data;
- unsigned int ret, reg;
+ unsigned int reg;
+ int ret;
*an_restart = 0;
^ permalink raw reply related
* [Buildroot] [PATCH] openjpeg: refresh patches
From: Peter Seiderer @ 2016-11-14 22:30 UTC (permalink / raw)
To: buildroot
In-Reply-To: <15d0ff6af38ff41acb2129a619e49a0e3ba866d9.1479160710.git.baruch@tkos.co.il>
Hello Baruch,
On Mon, 14 Nov 2016 23:58:30 +0200, Baruch Siach <baruch@tkos.co.il> 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(-)
>
> 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 be509024de86..bce790a47863 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 4366c0af88cf..5697b82de2e0 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
>
Acked-by: Peter Seiderer <ps.report@gmx.net>
Regards,
Peter
^ permalink raw reply
* Re: [PATCH v3 14/14] drm/i915: Support explicit fencing for execbuf
From: Rafael Antognolli @ 2016-11-14 22:29 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20161114085703.16540-14-chris@chris-wilson.co.uk>
Hi Chris,
I'm not sure you are waiting for this kind of feedback, but I've managed
to test this particular patch with Mesa, and I have some piglit tests
for it too. They are waiting for review, but at least the feature is
working as expected:
https://github.com/rantogno/piglit/commits/review/fences-v02
I used mesa and libdrm patches from more than a single set, but in case
you want to look they are here:
https://github.com/rantogno/mesa/commits/wip-fence
https://github.com/rantogno/libdrm/commits/wip-fence
And my kernel tree when I tested it:
https://github.com/rantogno/linux/commits/wip-fence
So in case it helps, you can add a
Tested-by: Rafael Antognolli <rafael.antognolli@intel.com>
PS: I can test it with this last series and everything more up to date,
if it will help to get this patch landed sooner.
Cheers,
Rafael
On Mon, Nov 14, 2016 at 08:57:03AM +0000, Chris Wilson wrote:
> Now that the user can opt-out of implicit fencing, we need to give them
> back control over the fencing. We employ sync_file to wrap our
> drm_i915_gem_request and provide an fd that userspace can merge with
> other sync_file fds and pass back to the kernel to wait upon before
> future execution.
>
> Testcase: igt/gem_exec_fence
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/i915_drv.c | 3 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 54 +++++++++++++++++++++++++++---
> include/uapi/drm/i915_drm.h | 35 ++++++++++++++++++-
> 4 files changed, 86 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index beed5c1d2cd7..bed81fe1d2a7 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -19,6 +19,7 @@ config DRM_I915
> select INPUT if ACPI
> select ACPI_VIDEO if ACPI
> select ACPI_BUTTON if ACPI
> + select SYNC_FILE
> help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 657c465a8d50..6fe7f41a5b5b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -344,6 +344,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
> case I915_PARAM_HAS_COHERENT_PHYS_GTT:
> case I915_PARAM_HAS_EXEC_SOFTPIN:
> case I915_PARAM_HAS_EXEC_ASYNC:
> + case I915_PARAM_HAS_EXEC_FENCE:
> /* For the time being all of these are always true;
> * if some supported hardware does not have one of these
> * features this value needs to be provided from
> @@ -2533,7 +2534,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF_DRV(I915_GEM_INIT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, DRM_AUTH|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2_WR, i915_gem_execbuffer2, DRM_AUTH|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_reject_pin_ioctl, DRM_AUTH|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_reject_pin_ioctl, DRM_AUTH|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 781b5559f86e..facec610b55a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -28,6 +28,7 @@
>
> #include <linux/dma_remapping.h>
> #include <linux/reservation.h>
> +#include <linux/sync_file.h>
> #include <linux/uaccess.h>
>
> #include <drm/drmP.h>
> @@ -1597,6 +1598,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> struct i915_execbuffer_params *params = ¶ms_master;
> const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
> u32 dispatch_flags;
> + struct dma_fence *in_fence = NULL;
> + struct sync_file *out_fence = NULL;
> + int out_fence_fd = -1;
> int ret;
> bool need_relocs;
>
> @@ -1640,6 +1644,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> dispatch_flags |= I915_DISPATCH_RS;
> }
>
> + if (args->flags & I915_EXEC_FENCE_IN) {
> + in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
> + if (!in_fence) {
> + ret = -EINVAL;
> + goto pre_mutex_err;
> + }
> + }
> +
> + if (args->flags & I915_EXEC_FENCE_OUT) {
> + out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
> + if (out_fence_fd < 0) {
> + ret = out_fence_fd;
> + out_fence_fd = -1;
> + goto pre_mutex_err;
> + }
> + }
> +
> /* Take a local wakeref for preparing to dispatch the execbuf as
> * we expect to access the hardware fairly frequently in the
> * process. Upon first dispatch, we acquire another prolonged
> @@ -1784,6 +1805,21 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> goto err_batch_unpin;
> }
>
> + if (in_fence) {
> + ret = i915_gem_request_await_dma_fence(params->request,
> + in_fence);
> + if (ret < 0)
> + goto err_request;
> + }
> +
> + if (out_fence_fd != -1) {
> + out_fence = sync_file_create(¶ms->request->fence);
> + if (!out_fence) {
> + ret = -ENOMEM;
> + goto err_request;
> + }
> + }
> +
> /* Whilst this request exists, batch_obj will be on the
> * active_list, and so will hold the active reference. Only when this
> * request is retired will the the batch_obj be moved onto the
> @@ -1811,6 +1847,16 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> ret = execbuf_submit(params, args, &eb->vmas);
> err_request:
> __i915_add_request(params->request, ret == 0);
> + if (out_fence) {
> + if (ret == 0) {
> + fd_install(out_fence_fd, out_fence->file);
> + args->rsvd2 &= GENMASK_ULL(0, 31); /* keep in-fence */
> + args->rsvd2 |= (u64)out_fence_fd << 32;
> + out_fence_fd = -1;
> + } else {
> + fput(out_fence->file);
> + }
> + }
>
> err_batch_unpin:
> /*
> @@ -1832,6 +1878,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> /* intel_gpu_busy should also get a ref, so it will free when the device
> * is really idle. */
> intel_runtime_pm_put(dev_priv);
> + if (out_fence_fd != -1)
> + put_unused_fd(out_fence_fd);
> + dma_fence_put(in_fence);
> return ret;
> }
>
> @@ -1939,11 +1988,6 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
> return -EINVAL;
> }
>
> - if (args->rsvd2 != 0) {
> - DRM_DEBUG("dirty rvsd2 field\n");
> - return -EINVAL;
> - }
> -
> exec2_list = drm_malloc_gfp(args->buffer_count,
> sizeof(*exec2_list),
> GFP_TEMPORARY);
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 4bd83c0b07db..90082269fb50 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -246,6 +246,7 @@ typedef struct _drm_i915_sarea {
> #define DRM_I915_OVERLAY_PUT_IMAGE 0x27
> #define DRM_I915_OVERLAY_ATTRS 0x28
> #define DRM_I915_GEM_EXECBUFFER2 0x29
> +#define DRM_I915_GEM_EXECBUFFER2_WR DRM_I915_GEM_EXECBUFFER2
> #define DRM_I915_GET_SPRITE_COLORKEY 0x2a
> #define DRM_I915_SET_SPRITE_COLORKEY 0x2b
> #define DRM_I915_GEM_WAIT 0x2c
> @@ -279,6 +280,7 @@ typedef struct _drm_i915_sarea {
> #define DRM_IOCTL_I915_GEM_INIT DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_INIT, struct drm_i915_gem_init)
> #define DRM_IOCTL_I915_GEM_EXECBUFFER DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER, struct drm_i915_gem_execbuffer)
> #define DRM_IOCTL_I915_GEM_EXECBUFFER2 DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER2, struct drm_i915_gem_execbuffer2)
> +#define DRM_IOCTL_I915_GEM_EXECBUFFER2_WR DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER2_WR, struct drm_i915_gem_execbuffer2)
> #define DRM_IOCTL_I915_GEM_PIN DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
> #define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
> #define DRM_IOCTL_I915_GEM_BUSY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
> @@ -401,6 +403,12 @@ typedef struct drm_i915_irq_wait {
> */
> #define I915_PARAM_HAS_EXEC_ASYNC 42
>
> +/* Query whether DRM_I915_GEM_EXECBUFFER2 supports explicit fence support -
> + * both being able to pass in a sync_file fd to wait upon before executing,
> + * and being able to return a new sync_file fd that is signaled when the
> + * current request is complete.
> + */
> +#define I915_PARAM_HAS_EXEC_FENCE 43
>
> typedef struct drm_i915_getparam {
> __s32 param;
> @@ -854,7 +862,32 @@ struct drm_i915_gem_execbuffer2 {
> */
> #define I915_EXEC_RESOURCE_STREAMER (1<<15)
>
> -#define __I915_EXEC_UNKNOWN_FLAGS -(I915_EXEC_RESOURCE_STREAMER<<1)
> +/* Setting I915_EXEC_FENCE_IN implies that lower_32_bits(rsvd2) represent
> + * a sync_file fd to wait upon (in a nonblocking manner) prior to executing
> + * the batch.
> + *
> + * Returns -EINVAL if the sync_file fd cannot be found.
> + */
> +#define I915_EXEC_FENCE_IN (1<<16)
> +
> +/* Setting I915_EXEC_FENCE_OUT causes the ioctl to return a sync_file fd
> + * in the upper_32_bits(rsvd2) upon success. Ownership of the fd is given
> + * to the caller, and it should be close() after use. (The fd is a regular
> + * file descriptor and will be cleaned up on process termination. It holds
> + * a reference to the request, but nothing else.)
> + *
> + * The sync_file fd can be combined with other sync_file and passed either
> + * to execbuf using I915_EXEC_FENCE_IN, to atomic KMS ioctls (so that a flip
> + * will only occur after this request completes), or to other devices.
> + *
> + * Using I915_EXEC_FENCE_OUT requires use of
> + * DRM_IOCTL_I915_GEM_EXECBUFFER2_WR ioctl so that the result is written
> + * back to userspace. Failure to do so will cause the out-fence to always
> + * be reported as zero, and the real fence fd to be leaked.
> + */
> +#define I915_EXEC_FENCE_OUT (1<<17)
> +
> +#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_OUT<<1))
>
> #define I915_EXEC_CONTEXT_ID_MASK (0xffffffff)
> #define i915_execbuffer2_set_context_id(eb2, context) \
> --
> 2.10.2
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v6 0/9] tpm: cleanup/fixes in existing event log support
From: Jarkko Sakkinen @ 2016-11-14 22:33 UTC (permalink / raw)
To: Nayna Jain
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1479117656-12403-1-git-send-email-nayna-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Mon, Nov 14, 2016 at 05:00:47AM -0500, Nayna Jain wrote:
> This patch set includes the cleanup and bug fixes patches, previously
> part of the "tpm: add the securityfs pseudo files support for TPM 2.0
> firmware event log" patch set, in order to upstream them more quickly.
I applied the patches. I'm not yet sure whether these are part of the
4.10 pull request or whether I postpone to 4.11 (my preference would be
4.10 but I do not want to close that right now). I'll do testing next
week before doing pull request.
I hope that the commits gets some reviews and testing now that they are
easily testable in my master branch.
/Jarkko
>
> Changelog History:
>
> v6:
>
> - Patch "tpm: replace symbolic permission with octal for securityfs files"
> - New Patch.
> - Patch "tpm: have event log use the tpm_chip"
> - Changed commit description as per Jason's suggestion.
> - Fixed bug related to kfree() for bios_event_log.
> - Moved inode_unlock() just after get_device() in open().
> - Returned -ENODEV for read_log() ENOMEM error and other errors as it is.
> - Added comment in tpm_bios_log_teardown() to explain inode_lock()/unlock
> reasoning.
> - Splitted .owner into different patch.
> - Patch "tpm: fix the missing .owner in tpm_bios_measurements_ops"
> - New Patch.
> - Patch "tpm: cleanup of printk error messages"
> - Replaced dev_info() with dev_warn().
> - Updated commit description subject line.
>
> v5:
>
> - Moved cleanup/fixes patches into this patch set.
> - Patch "fix the race condition between event log access and chip
> getting unregistered"
> - updated subject line and commit description.
> - modified fops code to use chip kref.
> - modified fops to lock inode before accessing inode private data.
> - renamed tpm_securityfs_data to tpm_chip_seqops, as it no more
> holds bios log, but associates seqops with respective chip. For
> the same reason, moved it to tpm.h
> - Patch "replace or remove printk error messages"
> - cleaned up dev_dbg and used dev_info as applicable.
>
> v4:
>
> - Includes feedbacks from Jarkko and Jason.
> - Patch "tpm: define a generic open() method for ascii & bios
> measurements".
> - Fix indentation issue.
> - Patch "tpm: replace the dynamically allocated bios_dir as
> struct dentry array".
> - Continue to use bios_dir_count variable to use is_bad() checks and
> to maintain correct order for securityfs_remove() during teardown.
> - Reset chip->bios_dir_count in teardown() function.
> - Patch "tpm: validate the event log access before tpm_bios_log_setup".
> - Retain TPM2 check which was removed in previous patch.
> - Add tpm_bios_log_setup failure handling.
> - Remove use of private data from v3 version of patch. Add a new
> member to struct tpm_chip to achieve the same purpose.
> - Patch "tpm: redefine the read_log method to check for ACPI/OF
> properties sequentially".
> - Move replacement of CONFIG_TCG_IBMVTPM with CONFIG_OF to
> this patch from patch 3.
> - Replace -1 error code with -ENODEV.
> - Patch "tpm: replace the of_find_node_by_name() with dev of_node
> property".
> - Uses chip->dev.parent->of_node.
> - Created separate patch for cleanup of pr_err messages.
> - Patch "tpm: remove printk error messages".
> - New Patch.
> - Patch "tpm: add the securityfs file support for TPM 2.0 event log".
> - Parses event digests using event alg_id rather than event log header
> alg_id.
> - Uses of_property_match_string to differentiate tpm/vtpm compatible
> property.
> - Adds the comment for difference in tpm/vtpm endianness.
>
> v3:
>
> - Includes the review feedbacks as suggested by Jason.
> - Split of patches into one patch per idea.
> - Generic open() method for ascii/bios measurements.
> - Replacement of of **bios_dir with *bios_dir[3].
> - Verifying readlog() is successful before creating securityfs entries.
> - Generic readlog() to check for ACPI/OF in sequence.
> - read_log_of() method now uses of_node propertry rather than
> calling find_device_by_name.
> - read_log differentiates vtpm/tpm using its compatible property.
> - Cleans pr_err with dev_dbg.
> - Commit msgs subject line prefixed with tpm.
>
> v2:
>
> - Fixes issues as given in feedback by Jason.
> - Adds documentation for device tree.
>
> Nayna Jain (9):
> tpm: define a generic open() method for ascii & bios measurements
> tpm: replace symbolic permission with octal for securityfs files
> tpm: replace dynamically allocated bios_dir with a static array
> tpm: drop tpm1_chip_register(/unregister)
> tpm: have event log use the tpm_chip
> tpm: fix the missing .owner in tpm_bios_measurements_ops
> tpm: redefine read_log() to handle ACPI/OF at runtime
> tpm: replace of_find_node_by_name() with dev of_node property
> tpm: cleanup of printk error messages
>
> drivers/char/tpm/Makefile | 14 +--
> drivers/char/tpm/tpm-chip.c | 33 ++----
> drivers/char/tpm/tpm-sysfs.c | 3 +
> drivers/char/tpm/tpm.h | 14 ++-
> drivers/char/tpm/tpm_acpi.c | 38 +++----
> drivers/char/tpm/tpm_eventlog.c | 222 +++++++++++++++++++++-------------------
> drivers/char/tpm/tpm_eventlog.h | 22 ++--
> drivers/char/tpm/tpm_of.c | 45 +++-----
> 8 files changed, 187 insertions(+), 204 deletions(-)
>
> --
> 2.5.0
>
------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH v6 0/9] tpm: cleanup/fixes in existing event log support
From: Jarkko Sakkinen @ 2016-11-14 22:33 UTC (permalink / raw)
To: Nayna Jain
Cc: tpmdd-devel, peterhuewe, tpmdd, jgunthorpe, linux-kernel,
linux-security-module
In-Reply-To: <1479117656-12403-1-git-send-email-nayna@linux.vnet.ibm.com>
On Mon, Nov 14, 2016 at 05:00:47AM -0500, Nayna Jain wrote:
> This patch set includes the cleanup and bug fixes patches, previously
> part of the "tpm: add the securityfs pseudo files support for TPM 2.0
> firmware event log" patch set, in order to upstream them more quickly.
I applied the patches. I'm not yet sure whether these are part of the
4.10 pull request or whether I postpone to 4.11 (my preference would be
4.10 but I do not want to close that right now). I'll do testing next
week before doing pull request.
I hope that the commits gets some reviews and testing now that they are
easily testable in my master branch.
/Jarkko
>
> Changelog History:
>
> v6:
>
> - Patch "tpm: replace symbolic permission with octal for securityfs files"
> - New Patch.
> - Patch "tpm: have event log use the tpm_chip"
> - Changed commit description as per Jason's suggestion.
> - Fixed bug related to kfree() for bios_event_log.
> - Moved inode_unlock() just after get_device() in open().
> - Returned -ENODEV for read_log() ENOMEM error and other errors as it is.
> - Added comment in tpm_bios_log_teardown() to explain inode_lock()/unlock
> reasoning.
> - Splitted .owner into different patch.
> - Patch "tpm: fix the missing .owner in tpm_bios_measurements_ops"
> - New Patch.
> - Patch "tpm: cleanup of printk error messages"
> - Replaced dev_info() with dev_warn().
> - Updated commit description subject line.
>
> v5:
>
> - Moved cleanup/fixes patches into this patch set.
> - Patch "fix the race condition between event log access and chip
> getting unregistered"
> - updated subject line and commit description.
> - modified fops code to use chip kref.
> - modified fops to lock inode before accessing inode private data.
> - renamed tpm_securityfs_data to tpm_chip_seqops, as it no more
> holds bios log, but associates seqops with respective chip. For
> the same reason, moved it to tpm.h
> - Patch "replace or remove printk error messages"
> - cleaned up dev_dbg and used dev_info as applicable.
>
> v4:
>
> - Includes feedbacks from Jarkko and Jason.
> - Patch "tpm: define a generic open() method for ascii & bios
> measurements".
> - Fix indentation issue.
> - Patch "tpm: replace the dynamically allocated bios_dir as
> struct dentry array".
> - Continue to use bios_dir_count variable to use is_bad() checks and
> to maintain correct order for securityfs_remove() during teardown.
> - Reset chip->bios_dir_count in teardown() function.
> - Patch "tpm: validate the event log access before tpm_bios_log_setup".
> - Retain TPM2 check which was removed in previous patch.
> - Add tpm_bios_log_setup failure handling.
> - Remove use of private data from v3 version of patch. Add a new
> member to struct tpm_chip to achieve the same purpose.
> - Patch "tpm: redefine the read_log method to check for ACPI/OF
> properties sequentially".
> - Move replacement of CONFIG_TCG_IBMVTPM with CONFIG_OF to
> this patch from patch 3.
> - Replace -1 error code with -ENODEV.
> - Patch "tpm: replace the of_find_node_by_name() with dev of_node
> property".
> - Uses chip->dev.parent->of_node.
> - Created separate patch for cleanup of pr_err messages.
> - Patch "tpm: remove printk error messages".
> - New Patch.
> - Patch "tpm: add the securityfs file support for TPM 2.0 event log".
> - Parses event digests using event alg_id rather than event log header
> alg_id.
> - Uses of_property_match_string to differentiate tpm/vtpm compatible
> property.
> - Adds the comment for difference in tpm/vtpm endianness.
>
> v3:
>
> - Includes the review feedbacks as suggested by Jason.
> - Split of patches into one patch per idea.
> - Generic open() method for ascii/bios measurements.
> - Replacement of of **bios_dir with *bios_dir[3].
> - Verifying readlog() is successful before creating securityfs entries.
> - Generic readlog() to check for ACPI/OF in sequence.
> - read_log_of() method now uses of_node propertry rather than
> calling find_device_by_name.
> - read_log differentiates vtpm/tpm using its compatible property.
> - Cleans pr_err with dev_dbg.
> - Commit msgs subject line prefixed with tpm.
>
> v2:
>
> - Fixes issues as given in feedback by Jason.
> - Adds documentation for device tree.
>
> Nayna Jain (9):
> tpm: define a generic open() method for ascii & bios measurements
> tpm: replace symbolic permission with octal for securityfs files
> tpm: replace dynamically allocated bios_dir with a static array
> tpm: drop tpm1_chip_register(/unregister)
> tpm: have event log use the tpm_chip
> tpm: fix the missing .owner in tpm_bios_measurements_ops
> tpm: redefine read_log() to handle ACPI/OF at runtime
> tpm: replace of_find_node_by_name() with dev of_node property
> tpm: cleanup of printk error messages
>
> drivers/char/tpm/Makefile | 14 +--
> drivers/char/tpm/tpm-chip.c | 33 ++----
> drivers/char/tpm/tpm-sysfs.c | 3 +
> drivers/char/tpm/tpm.h | 14 ++-
> drivers/char/tpm/tpm_acpi.c | 38 +++----
> drivers/char/tpm/tpm_eventlog.c | 222 +++++++++++++++++++++-------------------
> drivers/char/tpm/tpm_eventlog.h | 22 ++--
> drivers/char/tpm/tpm_of.c | 45 +++-----
> 8 files changed, 187 insertions(+), 204 deletions(-)
>
> --
> 2.5.0
>
^ permalink raw reply
* Re: [PATCH 3/4] PCI: Add checks to mellanox_check_broken_intx_masking
From: Bjorn Helgaas @ 2016-11-14 22:35 UTC (permalink / raw)
To: Gavin Shan; +Cc: Noa Osherovich, bhelgaas, linux-pci, majd
In-Reply-To: <20161114001535.GB14481@gwshan>
On Mon, Nov 14, 2016 at 11:15:35AM +1100, Gavin Shan wrote:
> On Sun, Nov 13, 2016 at 04:21:41PM +0200, Noa Osherovich wrote:
> >Mellanox devices were marked as having INTx masking ability broken.
> >As a result, the VFIO driver fails to start when more than one device
> >function is passed-through to a VM if both have the same INTx pin.
> >
> >Prior to Connect-IB, Mellanox devices exposed to the operating system
> >one PCI function per all ports.
> >Starting from Connect-IB, the devices are function-per-port. When
> >passing the second function to a VM, VFIO will fail to start.
> >
> >Exclude ConnectX-4, ConnectX4-Lx and Connect-IB from the list of
> >Mellanox devices marked as having broken INTx masking:
> >
> >- ConnectX-4 and ConnectX4-LX firmware version is checked. If INTx
> > masking is supported, we unmark the broken INTx masking.
> >- Connect-IB does not support INTx currently so will not cause any
> > problem.
> >
> >Fixes: 11e42532ada31 ('PCI: Assume all Mellanox devices have ...')
> >Signed-off-by: Noa Osherovich <noaos@mellanox.com>
> >Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
>
> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>
> With below comments addressed:
Noa, would you mind refreshing this to address Gavin's comments?
I don't want to risk doing it myself and breaking something.
> >---
> > drivers/pci/quirks.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++------
> > 1 file changed, 55 insertions(+), 6 deletions(-)
> >
> >diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> >index d3977c847e1f..cbd6776e70e6 100644
> >--- a/drivers/pci/quirks.c
> >+++ b/drivers/pci/quirks.c
> >@@ -3192,21 +3192,70 @@ static void quirk_broken_intx_masking(struct pci_dev *dev)
> > PCI_DEVICE_ID_MELLANOX_CONNECTX2,
> > PCI_DEVICE_ID_MELLANOX_CONNECTX3,
> > PCI_DEVICE_ID_MELLANOX_CONNECTX3_PRO,
> >- PCI_DEVICE_ID_MELLANOX_CONNECTIB,
> >- PCI_DEVICE_ID_MELLANOX_CONNECTX4,
> >- PCI_DEVICE_ID_MELLANOX_CONNECTX4_LX
> > };
> >
> >+#define CONNECTX_4_CURR_MAX_MINOR 99
> >+#define CONNECTX_4_INTX_SUPPORT_MINOR 14
> >+
> >+/*
> >+ * Checking ConnectX-4/LX FW version to see if it supports legacy interrupts.
> >+ * If so, don't mark it as broken.
> >+ * FW minor > 99 means older FW version format and no INTx masking support.
> >+ * FW minor < 14 means new FW version format and no INTx masking support.
> >+ */
> > static void mellanox_check_broken_intx_masking(struct pci_dev *dev)
> > {
> >+ __be32 __iomem *fw_ver;
> >+ u16 fw_major;
> >+ u16 fw_minor;
> >+ u16 fw_subminor;
> >+ u32 fw_maj_min;
> >+ u32 fw_sub_min;
> > int i;
> >
> >+ dev->broken_intx_masking = 1;
> >+
> > for (i = 0; i < ARRAY_SIZE(mellanox_broken_intx_devs); i++) {
> >- if (dev->device == mellanox_broken_intx_devs[i]) {
> >- dev->broken_intx_masking = 1;
> >+ if (dev->device == mellanox_broken_intx_devs[i])
> > return;
> >- }
> > }
> >+
> >+ /* Getting here means Connect-IB cards and up. Connect-IB has no INTx
> >+ * support so shouldn't be checked further
> >+ */
> >+ if (dev->device == PCI_DEVICE_ID_MELLANOX_CONNECTIB) {
> >+ dev->broken_intx_masking = 0;
> >+ return;
> >+ }
> >+
> >+ /* For ConnectX-4 and ConnectX-4LX, need to check FW support */
> >+ if (pci_enable_device_mem(dev)) {
> >+ dev_warn(&dev->dev, "Can't enable device memory\n");
> >+ return;
> >+ }
>
> It might be safer to set @broken_intx_masking in the failing path. On the
> following exit or failing path, the device needs to be disabled with function
> pci_disable_device(). Otherwise, &dev->enable_cnt, tracking if the device is
> enabled or not, will be unbalanced.
>
> >+
> >+ /* Convert from PCI bus to resource space. */
> >+ fw_ver = ioremap(pci_resource_start(dev, 0), 4);
> >+ if (!fw_ver) {
> >+ dev_warn(&dev->dev, "Can't map ConnectX-4 initialization segment\n");
> >+ return;
> >+ }
> >+
> >+ /* Reading from resource space should be 32b aligned */
> >+ fw_maj_min = ioread32be(fw_ver);
> >+ fw_sub_min = ioread32be(fw_ver + 1);
> >+ fw_major = fw_maj_min & 0xffff;
> >+ fw_minor = fw_maj_min >> 16;
> >+ fw_subminor = fw_sub_min & 0xffff;
> >+ if (fw_minor > CONNECTX_4_CURR_MAX_MINOR ||
> >+ fw_minor < CONNECTX_4_INTX_SUPPORT_MINOR)
> >+ dev_warn(&dev->dev, "ConnectX-4: FW %u.%u.%u doesn't support INTx masking, disabling. Please upgrade FW to %d.14.1100 and up for INTx support\n",
> >+ fw_major, fw_minor, fw_subminor, dev->device ==
> >+ PCI_DEVICE_ID_MELLANOX_CONNECTX4 ? 12 : 14);
> >+ else
> >+ dev->broken_intx_masking = 0;
> >+
> >+ iounmap(fw_ver);
> > }
>
> Noa, it doesn't look quite correct: when a device ID doesn't match with
> anyone in the list, CONNECTIB, CONNECT4 or CONNECTX4_LX. The code goes
> though as it's CONNECT4 or CONNECT4_LX. The firmware version retrieved
> from MMIO register (BAR 0, offset 0/4) are checked. I don't think it's
> assured that the registers are for firmware version on the device. It
> seems you need more checks here: @broken_intx_masking is untouched and
> kept as 0 by default when the device ID isn't in the intrest list, which
> is the policy you introduced in PATCH[2/3]. Something like below would
> work:
>
> static void mellanox_check_broken_intx_masking(struct pci_dev *pdev)
> {
> /*
> * Set @broken_intx_masking to 1 when device ID matches with
> * anyone in the list. No code change to PATCH[2/3] is needed.
> */
> if (pdev->device in mellanox_broken_intx_devs) {
> pdev->broken_intx_masking = 1;
> return;
> }
>
> if (dev->device == PCI_DEVICE_ID_MELLANOX_CONNECTIB)
> return;
>
> if (dev->device != PCI_DEVICE_ID_MELLANOX_CONNECTX4 &&
> dev->device != PCI_DEVICE_ID_MELLANOX_CONNECTX4_LE)
> return;
>
> /* Check firmware version on CONNECT4 or CONNECT4_LE */
> }
>
> >
> > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_MELLANOX, PCI_ANY_ID,
>
> Thanks,
> Gavin
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch] netlink.7: srcfix Change buffer size in example code about reading netlink message.
From: Rick Jones @ 2016-11-14 22:36 UTC (permalink / raw)
To: dwilder, mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e9409957290af5249750afa0f10de3a6-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> Lets change the example so others don't propagate the problem further.
>
> Signed-off-by David Wilder <dwilder-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> --- man7/netlink.7.orig 2016-11-14 13:30:36.522101156 -0800
> +++ man7/netlink.7 2016-11-14 13:30:51.002086354 -0800
> @@ -511,7 +511,7 @@
> .in +4n
> .nf
> int len;
> -char buf[4096];
> +char buf[8192];
Since there doesn't seem to be a define one could use in the user space
linux/netlink.h (?), but there are comments in the example code in the
manpage, how about also including a brief comment to the effect that
using 8192 bytes will avoid message truncation problems on platforms
with a large PAGE_SIZE?
/* avoid msg truncation on > 4096 byte PAGE_SIZE platforms */
or something like that.
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* THIS SERIES SHOULD BE: "[PATCH v4 00/13] VT-d unit test"
From: Peter Xu @ 2016-11-14 22:36 UTC (permalink / raw)
To: kvm; +Cc: drjones, agordeev, jan.kiszka, rkrcmar, pbonzini
In-Reply-To: <1479162491-20764-1-git-send-email-peterx@redhat.com>
On Mon, Nov 14, 2016 at 05:27:58PM -0500, Peter Xu wrote:
> (Please ignore previous v3 version and use this one. My fault to not
> configure base branch before publish :-( Sorry for the noise.)
>
> This is v4 of vt-d unit test series.
>
> Patch "libcflat: add IS_ALIGNED() macro, and page sizes" is picked up
> by Drew in the ARM GIC framework series, so please feel free to drop
> it when needed.
>
> Online repo:
>
> https://github.com/xzpeter/kvm-unit-tests.git iommu-ut-v4
>
> Please review. Thanks,
Ok this time the patches are correct but I forget to manually increase
the version number for git-publish.
Please... s/v3/v4/ in all patch titles and cover letter as well. Sorry
again. I won't repost if no one disagree.
Thanks,
-- peterx
^ permalink raw reply
* Re: "git subtree --squash" interacts poorly with revert, merge, and rebase
From: Matt McCutchen @ 2016-11-14 22:37 UTC (permalink / raw)
To: git
In-Reply-To: <1478814800.2878.10.camel@mattmccutchen.net>
On Thu, 2016-11-10 at 16:53 -0500, Matt McCutchen wrote:
> On Wed, 2016-10-26 at 19:07 -0400, Matt McCutchen wrote:
> >
> > Maybe we would never hit any of these problems in practice, but they
> > give me a bad enough feeling that I'm planning to write my own tool
> > that tracks the upstream commit ID in a file (like a submodule) and
> > doesn't generate any extra commits. Without generating extra commits,
> > the only place to store the upstream content in the superproject would
> > be in another subtree, which would take up disk space in every working
> > tree unless developers manually set skip-worktree. I think I prefer to
> > not store the upstream content and just have the tool fetch it from a
> > local subproject repository each time it's needed.
> >
> > I'll of course post the tool on the web and would be happy to see it
> > integrated into "git subtree" if that makes sense, but I don't know how
> > much time I'd be willing to put into making that happen.
>
> I have named my tool "git subtree-lite" and posted it here:
>
> https://mattmccutchen.net/utils/git-subtree-lite.git/
As I was doing additional research in preparation for adding git-
subtree-lite to the tools page
(https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools),
by chance I found an existing tool, Braid
(http://cristibalan.github.io/braid/), whose design meets my
requirements. I have a few minor concerns, but assuming I'm able to
fix them without too much work and upstream accepts my patches, I plan
to switch to Braid.
I've made a properly marked section on the tools page for subproject
management tools:
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Subprojects_or_sets_of_repositories
in the hope that the next person with the same requirements as me finds
Braid. (I unfortunately didn't check that page before starting, but I
will the next time I need something.)
Matt
^ permalink raw reply
* [U-Boot] [PULL 00/16] efi patch queue 2016-11-14
From: Alexander Graf @ 2016-11-14 22:37 UTC (permalink / raw)
To: u-boot
Hi Tom,
This is my current patch queue for efi. Please pull.
Alex
The following changes since commit 29e0cfb4f77f7aa369136302cee14a91e22dca71:
Prepare v2016.11 (2016-11-14 11:27:11 -0500)
are available in the git repository at:
git://github.com/agraf/u-boot.git tags/signed-efi-next
for you to fetch changes up to 58ad86288fd32f1f969ac654f2074c090f0abe32:
x86: Enable EFI loader support (2016-11-14 23:24:04 +0100)
----------------------------------------------------------------
Patch queue for efi - 2016-11-14
Highlights this time around:
- x86 efi_loader support
- hello world efi test case
- network device name is now representative
- terminal output reports modes correctly
----------------------------------------------------------------
Emmanuel Vadot (1):
efi_loader: console: Correctly report modes
Masahiro Yamada (1):
efi_loader: fix depends on line of EFI_LOADER
Oleksandr Tymoshenko (1):
efi: Use device device path type Messaging for network interface node
Simon Glass (13):
x86: Correct a build warning in x86 tables
efi: Correct cache flush alignment
efi: Fix debug message address format
x86: Tidy up selection of building the EFI stub
efi: Makefile: Export variables for use with EFI
efi: Add support for a hello world test program
elf: arm: Add a few ARM relocation types
efi: arm: Add EFI app support
efi: arm: Add aarch64 EFI app support
x86: Move efi .lds files into the 'lib' directory
x86: Move efi .S files into the 'lib' directory
efi: x86: Adjust EFI files support efi_loader
x86: Enable EFI loader support
Makefile | 11 +-
arch/arm/config.mk | 7 ++
arch/arm/cpu/armv8/config.mk | 4 +
arch/arm/lib/Makefile | 10 ++
arch/arm/lib/crt0_aarch64_efi.S | 135 ++++++++++++++++++++
arch/arm/lib/crt0_arm_efi.S | 138 +++++++++++++++++++++
arch/arm/lib/elf_aarch64_efi.lds | 70 +++++++++++
arch/arm/lib/elf_arm_efi.lds | 70 +++++++++++
arch/arm/lib/reloc_aarch64_efi.c | 87 +++++++++++++
arch/arm/lib/reloc_arm_efi.c | 66 ++++++++++
arch/arm/lib/relocate.S | 3 +-
arch/arm/lib/relocate_64.S | 3 +-
arch/x86/config.mk | 20 ++-
arch/x86/lib/Makefile | 23 ++++
.../lib/{efi/crt0-efi-ia32.S => crt0_ia32_efi.S} | 0
.../{efi/crt0-efi-x86_64.S => crt0_x86_64_efi.S} | 0
arch/x86/lib/efi/Makefile | 18 ---
arch/x86/{cpu/efi => lib}/elf_ia32_efi.lds | 2 -
arch/x86/{cpu/efi => lib}/elf_x86_64_efi.lds | 2 -
.../x86/lib/{efi/reloc_ia32.c => reloc_ia32_efi.c} | 0
.../lib/{efi/reloc_x86_64.c => reloc_x86_64_efi.c} | 0
arch/x86/lib/tables.c | 2 +
cmd/Kconfig | 9 ++
cmd/bootefi.c | 29 +++--
configs/efi-x86_defconfig | 1 +
doc/README.efi | 14 +++
doc/README.x86 | 1 -
include/asm-generic/sections.h | 2 +
include/efi.h | 7 +-
include/efi_api.h | 13 ++
include/elf.h | 13 ++
lib/efi/Makefile | 4 +-
lib/efi_loader/Kconfig | 2 +-
lib/efi_loader/Makefile | 4 +
lib/efi_loader/efi_console.c | 100 ++++++++++++---
lib/efi_loader/efi_image_loader.c | 3 +-
lib/efi_loader/efi_net.c | 17 +--
lib/efi_loader/helloworld.c | 24 ++++
scripts/Makefile.lib | 33 +++++
39 files changed, 882 insertions(+), 65 deletions(-)
create mode 100644 arch/arm/lib/crt0_aarch64_efi.S
create mode 100644 arch/arm/lib/crt0_arm_efi.S
create mode 100644 arch/arm/lib/elf_aarch64_efi.lds
create mode 100644 arch/arm/lib/elf_arm_efi.lds
create mode 100644 arch/arm/lib/reloc_aarch64_efi.c
create mode 100644 arch/arm/lib/reloc_arm_efi.c
rename arch/x86/lib/{efi/crt0-efi-ia32.S => crt0_ia32_efi.S} (100%)
rename arch/x86/lib/{efi/crt0-efi-x86_64.S => crt0_x86_64_efi.S} (100%)
rename arch/x86/{cpu/efi => lib}/elf_ia32_efi.lds (98%)
rename arch/x86/{cpu/efi => lib}/elf_x86_64_efi.lds (98%)
rename arch/x86/lib/{efi/reloc_ia32.c => reloc_ia32_efi.c} (100%)
rename arch/x86/lib/{efi/reloc_x86_64.c => reloc_x86_64_efi.c} (100%)
create mode 100644 lib/efi_loader/helloworld.c
^ permalink raw reply
* Re: [PATCH] i2c: mux: fix up dependencies
From: Peter Rosin @ 2016-11-14 13:59 UTC (permalink / raw)
To: Linus Walleij, Wolfram Sang, linux-i2c; +Cc: stable, Jonathan Cameron
In-Reply-To: <1479128586-17052-1-git-send-email-linus.walleij@linaro.org>
On 2016-11-14 14:03, Linus Walleij wrote:
> We get the following build error from UM Linux after adding
> an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX":
>
> ERROR: "devm_ioremap_resource"
> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
> ERROR: "of_address_to_resource"
> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
>
> It appears that the I2C mux core code actually only requires
> CONFIG_OF, but depends on HAS_IOMEM for historical reasons,
> while CONFIG_I2C_MUX_REG does *not* have a direct dependency
> on HAS_IOMEM.
>
> This creates a situation where a allyesconfig or allmodconfig
> for UM Linux will select I2C_MUX, and will implicitly enable
> I2C_MUX_REG as well, and the compilation will fail for the
> register driver.
>
> Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and
> the I2C_MUX depend on OF.
>
> Cc: stable@vger.kernel.org
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Reported-by: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
> Cc: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
> Cc: Peter Rosin <peda@axentia.se>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/i2c/Kconfig | 2 +-
> drivers/i2c/muxes/Kconfig | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> index d223650a97e4..b9e378cfe1d1 100644
> --- a/drivers/i2c/Kconfig
> +++ b/drivers/i2c/Kconfig
> @@ -59,7 +59,7 @@ config I2C_CHARDEV
>
> config I2C_MUX
> tristate "I2C bus multiplexing support"
> - depends on HAS_IOMEM
> + depends on OF
It is not obvious to me that the i2c mux is dependent on
CONFIG_OF. Sure, there are unconditional calls to things like
of_property_read_u32 etc, but those are meant to be compiled
away for the !CONFIG_OF case. I think. The code predates me,
but that's how I read it...
So, I agree the HAS_IOMEM is probably hysterical remains from
some point when i2c-mux was perhaps a specific thing that actually
controlled the mux using IOMEM from code under that config option,
and it should probably be moved to where it is needed (below).
But don't add "depends on OF", or am I missing something?
Cheers,
Peter
> help
> Say Y here if you want the I2C core to support the ability to
> handle multiplexed I2C bus topologies, by presenting each
> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
> index e280c8ecc0b5..96de9ce5669b 100644
> --- a/drivers/i2c/muxes/Kconfig
> +++ b/drivers/i2c/muxes/Kconfig
> @@ -63,6 +63,7 @@ config I2C_MUX_PINCTRL
>
> config I2C_MUX_REG
> tristate "Register-based I2C multiplexer"
> + depends on HAS_IOMEM
> help
> If you say yes to this option, support will be included for a
> register based I2C multiplexer. This driver provides access to
>
^ permalink raw reply
* Re: [PATCH] i2c: mux: fix up dependencies
From: Peter Rosin @ 2016-11-14 13:59 UTC (permalink / raw)
To: Linus Walleij, Wolfram Sang, linux-i2c; +Cc: stable, Jonathan Cameron
In-Reply-To: <1479128586-17052-1-git-send-email-linus.walleij@linaro.org>
On 2016-11-14 14:03, Linus Walleij wrote:
> We get the following build error from UM Linux after adding
> an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX":
>
> ERROR: "devm_ioremap_resource"
> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
> ERROR: "of_address_to_resource"
> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
>
> It appears that the I2C mux core code actually only requires
> CONFIG_OF, but depends on HAS_IOMEM for historical reasons,
> while CONFIG_I2C_MUX_REG does *not* have a direct dependency
> on HAS_IOMEM.
>
> This creates a situation where a allyesconfig or allmodconfig
> for UM Linux will select I2C_MUX, and will implicitly enable
> I2C_MUX_REG as well, and the compilation will fail for the
> register driver.
>
> Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and
> the I2C_MUX depend on OF.
>
> Cc: stable@vger.kernel.org
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Reported-by: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
> Cc: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
> Cc: Peter Rosin <peda@axentia.se>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/i2c/Kconfig | 2 +-
> drivers/i2c/muxes/Kconfig | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> index d223650a97e4..b9e378cfe1d1 100644
> --- a/drivers/i2c/Kconfig
> +++ b/drivers/i2c/Kconfig
> @@ -59,7 +59,7 @@ config I2C_CHARDEV
>
> config I2C_MUX
> tristate "I2C bus multiplexing support"
> - depends on HAS_IOMEM
> + depends on OF
It is not obvious to me that the i2c mux is dependent on
CONFIG_OF. Sure, there are unconditional calls to things like
of_property_read_u32 etc, but those are meant to be compiled
away for the !CONFIG_OF case. I think. The code predates me,
but that's how I read it...
So, I agree the HAS_IOMEM is probably hysterical remains from
some point when i2c-mux was perhaps a specific thing that actually
controlled the mux using IOMEM from code under that config option,
and it should probably be moved to where it is needed (below).
But don't add "depends on OF", or am I missing something?
Cheers,
Peter
> help
> Say Y here if you want the I2C core to support the ability to
> handle multiplexed I2C bus topologies, by presenting each
> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
> index e280c8ecc0b5..96de9ce5669b 100644
> --- a/drivers/i2c/muxes/Kconfig
> +++ b/drivers/i2c/muxes/Kconfig
> @@ -63,6 +63,7 @@ config I2C_MUX_PINCTRL
>
> config I2C_MUX_REG
> tristate "Register-based I2C multiplexer"
> + depends on HAS_IOMEM
> help
> If you say yes to this option, support will be included for a
> register based I2C multiplexer. This driver provides access to
>
^ permalink raw reply
* [PATCH net-next v2 0/2] amd-xgbe: AMD XGBE driver updates 2016-11-14
From: Tom Lendacky @ 2016-11-14 22:38 UTC (permalink / raw)
To: netdev; +Cc: julia.lawall, christophe.jaillet, David Miller
(Resending with net-next in the subject)
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.
---
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(-)
--
Tom Lendacky
^ permalink raw reply
* [PATCH net-next v2 1/2] amd-xgbe: Fix mask appliciation for Clause 37 register
From: Tom Lendacky @ 2016-11-14 22:39 UTC (permalink / raw)
To: netdev; +Cc: julia.lawall, christophe.jaillet, David Miller
In-Reply-To: <20161114223856.25437.13649.stgit@tlendack-t1.amdoffice.net>
The application of a mask to clear an area of a clause 37 register value
was not properly applied. Update the code to do the proper application
of the mask.
Reported-by: Marion & Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
index 0ecae70..4c5b90e 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
@@ -943,8 +943,8 @@ static void xgbe_an37_init(struct xgbe_prv_data *pdata)
/* Set up the Control register */
reg = XMDIO_READ(pdata, MDIO_MMD_VEND2, MDIO_VEND2_AN_CTRL);
- reg &= XGBE_AN_CL37_TX_CONFIG_MASK;
- reg &= XGBE_AN_CL37_PCS_MODE_MASK;
+ reg &= ~XGBE_AN_CL37_TX_CONFIG_MASK;
+ reg &= ~XGBE_AN_CL37_PCS_MODE_MASK;
switch (pdata->an_mode) {
case XGBE_AN_MODE_CL37:
^ permalink raw reply related
* Re: [PATCH] cpufreq: intel_pstate: Synchronize sysfs limits
From: Rafael J. Wysocki @ 2016-11-14 22:46 UTC (permalink / raw)
To: Srinivas Pandruvada; +Cc: Rafael J. Wysocki, Len Brown, Linux PM
In-Reply-To: <CAJZ5v0jUD7iDC6zY8USgDw=Z_0+nDnS-7DMCXLKxGSsG+Wz-BA@mail.gmail.com>
On Monday, November 14, 2016 11:11:39 PM Rafael J. Wysocki wrote:
> On Mon, Nov 14, 2016 at 11:07 PM, Srinivas Pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> > On Mon, 2016-11-14 at 02:04 +0100, Rafael J. Wysocki wrote:
> >> On Sat, Nov 12, 2016 at 1:11 AM, Srinivas Pandruvada
> >>
> > [...]
> >> + get_online_cpus();
> >> > + for_each_online_cpu(cpu) {
> >> > + if (all_cpu_data[cpu])
> >> > + cpufreq_update_policy(cpu);
> >>
> >> cpufreq_update_policy() calls cpufreq_cpu_get() to get the policy
> >> anyway which does the requisite policy existence check (although it
> >> is
> >> a bit racy now, but that's a bug in there that we should not have to
> >> work around here), so it should be sufficient to do this
> >> for_each_possible_cpu() without additional locking.
> >>
> > I will change in the next patch set.
>
> Wait, wait, there's a better way I think, but I'll need to send a
> patch to explain what I mean. :-) Will do that shortly.
Something like the below, modulo changes in ->verify() or in ->set_policy() to
update min/max (untested, but I don't see why it wouldn't work).
If we are going to call cpufreq_update_policy() anyway, we don't need to do
anything special for HWP then, because that will trigger ->set_policy()
eventually and we'll update HWP at the end of it.
---
drivers/cpufreq/intel_pstate.c | 25 +++++++++++--------------
1 file changed, 11 insertions(+), 14 deletions(-)
Index: linux-pm/drivers/cpufreq/intel_pstate.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -572,13 +572,13 @@ static inline void update_turbo_state(vo
cpu->pstate.max_pstate == cpu->pstate.turbo_pstate);
}
-static void intel_pstate_hwp_set(const struct cpumask *cpumask)
+static void intel_pstate_hwp_set(struct cpufreq_policy *policy)
{
int min, hw_min, max, hw_max, cpu, range, adj_range;
struct perf_limits *perf_limits = limits;
u64 value, cap;
- for_each_cpu(cpu, cpumask) {
+ for_each_cpu(cpu, policy->cpus) {
int max_perf_pct, min_perf_pct;
if (per_cpu_limits)
@@ -615,16 +615,17 @@ static void intel_pstate_hwp_set(const s
static int intel_pstate_hwp_set_policy(struct cpufreq_policy *policy)
{
if (hwp_active)
- intel_pstate_hwp_set(policy->cpus);
+ intel_pstate_hwp_set(policy);
return 0;
}
-static void intel_pstate_hwp_set_online_cpus(void)
+static void intel_pstate_update_policies(void)
{
- get_online_cpus();
- intel_pstate_hwp_set(cpu_online_mask);
- put_online_cpus();
+ int cpu;
+
+ for_each_possible_cpu(cpu)
+ cpufreq_update_policy(cpu);
}
/************************** debugfs begin ************************/
@@ -751,9 +752,7 @@ static ssize_t store_no_turbo(struct kob
mutex_unlock(&intel_pstate_limits_lock);
- if (hwp_active)
- intel_pstate_hwp_set_online_cpus();
-
+ intel_pstate_update_policies();
return count;
}
@@ -780,8 +779,7 @@ static ssize_t store_max_perf_pct(struct
mutex_unlock(&intel_pstate_limits_lock);
- if (hwp_active)
- intel_pstate_hwp_set_online_cpus();
+ intel_pstate_update_policies();
return count;
}
@@ -808,8 +806,7 @@ static ssize_t store_min_perf_pct(struct
mutex_unlock(&intel_pstate_limits_lock);
- if (hwp_active)
- intel_pstate_hwp_set_online_cpus();
+ intel_pstate_update_policies();
return count;
}
^ permalink raw reply
* [PATCH net-next v2 2/2] amd-xgbe: Fix up some coccinelle identified warnings
From: Tom Lendacky @ 2016-11-14 22:39 UTC (permalink / raw)
To: netdev; +Cc: julia.lawall, christophe.jaillet, David Miller
In-Reply-To: <20161114223856.25437.13649.stgit@tlendack-t1.amdoffice.net>
Fix up some warnings that were identified by coccinelle:
Clean up an if/else block that can look confusing since the same statement
is executed in an "else if" check and the final "else" statement.
Change a variable from unsigned int to int since it is used in an if
statement checking the value to be less than 0.
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
index 4ba4332..348cc8c 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
@@ -1766,8 +1766,6 @@ static void xgbe_phy_sfi_mode(struct xgbe_prv_data *pdata)
XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 1);
else if (phy_data->sfp_cable_len <= 3)
XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 2);
- else if (phy_data->sfp_cable_len <= 5)
- XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 3);
else
XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 3);
}
@@ -2346,7 +2344,8 @@ static bool xgbe_phy_valid_speed(struct xgbe_prv_data *pdata, int speed)
static int xgbe_phy_link_status(struct xgbe_prv_data *pdata, int *an_restart)
{
struct xgbe_phy_data *phy_data = pdata->phy_data;
- unsigned int ret, reg;
+ unsigned int reg;
+ int ret;
*an_restart = 0;
^ permalink raw reply related
* [PATCH] drm/i915: cleanup use of INSTR_CLIENT_MASK
From: Matthew Auld @ 2016-11-14 22:39 UTC (permalink / raw)
To: intel-gfx
Doing cmd_header >> 29 to extract our 3-bit client value where we know
cmd_header is a u32 shouldn't then also require the use of a mask. So
remove the redundant operation and get rid of INSTR_CLIENT_MASK now that
there are no longer any users.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 6 +++---
drivers/gpu/drm/i915/i915_reg.h | 1 -
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
index f5039f4..5eb7aac 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -559,7 +559,7 @@ static const struct drm_i915_reg_table hsw_blt_reg_tables[] = {
static u32 gen7_render_get_cmd_length_mask(u32 cmd_header)
{
- u32 client = (cmd_header & INSTR_CLIENT_MASK) >> INSTR_CLIENT_SHIFT;
+ u32 client = cmd_header >> INSTR_CLIENT_SHIFT;
u32 subclient =
(cmd_header & INSTR_SUBCLIENT_MASK) >> INSTR_SUBCLIENT_SHIFT;
@@ -578,7 +578,7 @@ static u32 gen7_render_get_cmd_length_mask(u32 cmd_header)
static u32 gen7_bsd_get_cmd_length_mask(u32 cmd_header)
{
- u32 client = (cmd_header & INSTR_CLIENT_MASK) >> INSTR_CLIENT_SHIFT;
+ u32 client = cmd_header >> INSTR_CLIENT_SHIFT;
u32 subclient =
(cmd_header & INSTR_SUBCLIENT_MASK) >> INSTR_SUBCLIENT_SHIFT;
u32 op = (cmd_header & INSTR_26_TO_24_MASK) >> INSTR_26_TO_24_SHIFT;
@@ -601,7 +601,7 @@ static u32 gen7_bsd_get_cmd_length_mask(u32 cmd_header)
static u32 gen7_blt_get_cmd_length_mask(u32 cmd_header)
{
- u32 client = (cmd_header & INSTR_CLIENT_MASK) >> INSTR_CLIENT_SHIFT;
+ u32 client = cmd_header >> INSTR_CLIENT_SHIFT;
if (client == INSTR_MI_CLIENT)
return 0x3F;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3361d7f..60423a2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -294,7 +294,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
* Instruction field definitions used by the command parser
*/
#define INSTR_CLIENT_SHIFT 29
-#define INSTR_CLIENT_MASK 0xE0000000
#define INSTR_MI_CLIENT 0x0
#define INSTR_BC_CLIENT 0x2
#define INSTR_RC_CLIENT 0x3
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH] scsi: megaraid_sas: add in missing white spaces in error messages text
From: Bart Van Assche @ 2016-11-14 22:24 UTC (permalink / raw)
To: Colin King, Kashyap Desai, Sumit Saxena, Shivasharan S,
James E . J . Bottomley, Martin K . Petersen, megaraidlinux.pdl,
linux-scsi
Cc: linux-kernel
In-Reply-To: <20161112162524.4585-1-colin.king@canonical.com>
On 11/12/2016 08:25 AM, Colin King wrote:
> A couple of dev_printk messages spans two lines and the literal string
> is missing a white space between words. Add the white space.
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
^ permalink raw reply
* [PATCH net] udp: restore UDPlite many-cast delivery
From: Pablo Neira Ayuso @ 2016-11-14 22:40 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet, drheld
Honor udptable parameter that is passed to __udp*_lib_mcast_deliver(),
otherwise udplite broadcast/multicast use the wrong table and it breaks.
Fixes: 2dc41cff7545 ("udp: Use hash2 for long hash1 chains in __udp*_lib_mcast_deliver.")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
It looks like UDPlite accidentally broke when dealing with long UDP many-cast
chains, give the wrong table is used for udplite. Compile tested only.
net/ipv4/udp.c | 6 +++---
net/ipv6/udp.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 195992e0440d..5b5a552a2804 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1731,10 +1731,10 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
if (use_hash2) {
hash2_any = udp4_portaddr_hash(net, htonl(INADDR_ANY), hnum) &
- udp_table.mask;
- hash2 = udp4_portaddr_hash(net, daddr, hnum) & udp_table.mask;
+ udptable->mask;
+ hash2 = udp4_portaddr_hash(net, daddr, hnum) & udptable->mask;
start_lookup:
- hslot = &udp_table.hash2[hash2];
+ hslot = &udptable->hash2[hash2];
offset = offsetof(typeof(*sk), __sk_common.skc_portaddr_node);
}
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index a7700bbf6788..a9dd23d5c3c4 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -688,10 +688,10 @@ static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
if (use_hash2) {
hash2_any = udp6_portaddr_hash(net, &in6addr_any, hnum) &
- udp_table.mask;
- hash2 = udp6_portaddr_hash(net, daddr, hnum) & udp_table.mask;
+ udptable->mask;
+ hash2 = udp6_portaddr_hash(net, daddr, hnum) & udptable->mask;
start_lookup:
- hslot = &udp_table.hash2[hash2];
+ hslot = &udptable->hash2[hash2];
offset = offsetof(typeof(*sk), __sk_common.skc_portaddr_node);
}
--
2.1.4
^ permalink raw reply related
* [PATCH] drm: don't let crtc_ww_class leak out
From: Rob Clark @ 2016-11-14 22:40 UTC (permalink / raw)
To: dri-devel
kbuild spotted this error, with drm/msm patches that add a new
modeset-lock in the driver and driver built as a module:
ERROR: "crtc_ww_class" [drivers/gpu/drm/msm/msm.ko] undefined!
Really the only reason for crtc_ww_class not being internal to
drm_modeset_lock.c is that drm_modeset_lock_init() was static-inline
(for no particularly good reason).
Fix that, and move crtc_ww_class into drm_modeset_lock.c.
Signed-off-by: Rob Clark <robdclark@gmail.com>
---
This is an alternative to the "drm: export crtc_ww_class" patch.
drivers/gpu/drm/drm_crtc.c | 2 --
drivers/gpu/drm/drm_modeset_lock.c | 13 +++++++++++++
include/drm/drm_modeset_lock.h | 12 +-----------
3 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cf2423d..5d994cc 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -102,8 +102,6 @@ int drm_crtc_force_disable_all(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_crtc_force_disable_all);
-DEFINE_WW_CLASS(crtc_ww_class);
-
static unsigned int drm_num_crtcs(struct drm_device *dev)
{
unsigned int num = 0;
diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c
index 61146f5..9059fe3 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -60,6 +60,8 @@
* lists and lookup data structures.
*/
+static DEFINE_WW_CLASS(crtc_ww_class);
+
/**
* drm_modeset_lock_all - take all modeset locks
* @dev: DRM device
@@ -398,6 +400,17 @@ int drm_modeset_backoff_interruptible(struct drm_modeset_acquire_ctx *ctx)
EXPORT_SYMBOL(drm_modeset_backoff_interruptible);
/**
+ * drm_modeset_lock_init - initialize lock
+ * @lock: lock to init
+ */
+void drm_modeset_lock_init(struct drm_modeset_lock *lock)
+{
+ ww_mutex_init(&lock->mutex, &crtc_ww_class);
+ INIT_LIST_HEAD(&lock->head);
+}
+EXPORT_SYMBOL(drm_modeset_lock_init);
+
+/**
* drm_modeset_lock - take modeset lock
* @lock: lock to take
* @ctx: acquire ctx
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
index c5576fb..d918ce4 100644
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -82,8 +82,6 @@ struct drm_modeset_lock {
struct list_head head;
};
-extern struct ww_class crtc_ww_class;
-
void drm_modeset_acquire_init(struct drm_modeset_acquire_ctx *ctx,
uint32_t flags);
void drm_modeset_acquire_fini(struct drm_modeset_acquire_ctx *ctx);
@@ -91,15 +89,7 @@ void drm_modeset_drop_locks(struct drm_modeset_acquire_ctx *ctx);
void drm_modeset_backoff(struct drm_modeset_acquire_ctx *ctx);
int drm_modeset_backoff_interruptible(struct drm_modeset_acquire_ctx *ctx);
-/**
- * drm_modeset_lock_init - initialize lock
- * @lock: lock to init
- */
-static inline void drm_modeset_lock_init(struct drm_modeset_lock *lock)
-{
- ww_mutex_init(&lock->mutex, &crtc_ww_class);
- INIT_LIST_HEAD(&lock->head);
-}
+void drm_modeset_lock_init(struct drm_modeset_lock *lock);
/**
* drm_modeset_lock_fini - cleanup lock
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCHv2] PCI/VMD: Use SRCU as a local RCU to prevent delaying global RCU
From: Bjorn Helgaas @ 2016-11-14 22:41 UTC (permalink / raw)
To: Jon Derrick; +Cc: keith.busch, linux-pci
In-Reply-To: <1478905725-219032-1-git-send-email-jonathan.derrick@intel.com>
On Fri, Nov 11, 2016 at 04:08:45PM -0700, Jon Derrick wrote:
> SRCU lets synchronize_srcu depend on VMD-local RCU primitives,
> preventing long delays from locking up RCU in other systems. VMD
> performs a synchronize when removing a device, but will hit all irq
> lists if the device uses all VMD vectors. This patch will not help VMD's
> RCU synchronization, but will isolate the read side delays to the VMD
> subsystem. Additionally, the use of SRCU in VMD's isr will keep it
> isolated from any other RCU waiters in the rest of the system.
>
> The patch was tested using concurrent fio and nvme resets:
> [global]
> rw=read
> bs=4k
> direct=1
> ioengine=libaio
> iodepth=32
> norandommap
> timeout=300
> runtime=1000000000
>
> [nvme0]
> cpus_allowed=0-63
> numjobs=8
> filename=/dev/nvme0n1
>
> [nvme1]
> cpus_allowed=0-63
> numjobs=8
> filename=/dev/nvme1n1
>
> while (true) do
> for i in /sys/class/nvme/nvme*; do
> echo "Resetting ${i##*/}"
> echo 1 > $i/reset_controller;
> sleep 5
> done;
> done
>
> Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Applied with Keith's reviewed-by to pci/host-vmd for v4.10, thanks!
> ---
> v1->v2: Kconfig depends on SRCU
>
> drivers/pci/host/Kconfig | 2 +-
> drivers/pci/host/vmd.c | 26 ++++++++++++++++++++------
> 2 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index d7e7c0a..e020359 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -286,7 +286,7 @@ config PCIE_ROCKCHIP
> 4 slots.
>
> config VMD
> - depends on PCI_MSI && X86_64
> + depends on PCI_MSI && X86_64 && SRCU
> tristate "Intel Volume Management Device Driver"
> default N
> ---help---
> diff --git a/drivers/pci/host/vmd.c b/drivers/pci/host/vmd.c
> index 6614b3552..af4eca2 100644
> --- a/drivers/pci/host/vmd.c
> +++ b/drivers/pci/host/vmd.c
> @@ -19,6 +19,7 @@
> #include <linux/module.h>
> #include <linux/msi.h>
> #include <linux/pci.h>
> +#include <linux/srcu.h>
> #include <linux/rculist.h>
> #include <linux/rcupdate.h>
>
> @@ -39,7 +40,6 @@
> /**
> * struct vmd_irq - private data to map driver IRQ to the VMD shared vector
> * @node: list item for parent traversal.
> - * @rcu: RCU callback item for freeing.
> * @irq: back pointer to parent.
> * @enabled: true if driver enabled IRQ
> * @virq: the virtual IRQ value provided to the requesting driver.
> @@ -49,7 +49,6 @@
> */
> struct vmd_irq {
> struct list_head node;
> - struct rcu_head rcu;
> struct vmd_irq_list *irq;
> bool enabled;
> unsigned int virq;
> @@ -58,11 +57,13 @@ struct vmd_irq {
> /**
> * struct vmd_irq_list - list of driver requested IRQs mapping to a VMD vector
> * @irq_list: the list of irq's the VMD one demuxes to.
> + * @srcu: SRCU struct for local synchronization.
> * @count: number of child IRQs assigned to this vector; used to track
> * sharing.
> */
> struct vmd_irq_list {
> struct list_head irq_list;
> + struct srcu_struct srcu;
> unsigned int count;
> };
>
> @@ -224,14 +225,14 @@ static void vmd_msi_free(struct irq_domain *domain,
> struct vmd_irq *vmdirq = irq_get_chip_data(virq);
> unsigned long flags;
>
> - synchronize_rcu();
> + synchronize_srcu(&vmdirq->irq->srcu);
>
> /* XXX: Potential optimization to rebalance */
> raw_spin_lock_irqsave(&list_lock, flags);
> vmdirq->irq->count--;
> raw_spin_unlock_irqrestore(&list_lock, flags);
>
> - kfree_rcu(vmdirq, rcu);
> + kfree(vmdirq);
> }
>
> static int vmd_msi_prepare(struct irq_domain *domain, struct device *dev,
> @@ -646,11 +647,12 @@ static irqreturn_t vmd_irq(int irq, void *data)
> {
> struct vmd_irq_list *irqs = data;
> struct vmd_irq *vmdirq;
> + int idx;
>
> - rcu_read_lock();
> + idx = srcu_read_lock(&irqs->srcu);
> list_for_each_entry_rcu(vmdirq, &irqs->irq_list, node)
> generic_handle_irq(vmdirq->virq);
> - rcu_read_unlock();
> + srcu_read_unlock(&irqs->srcu, idx);
>
> return IRQ_HANDLED;
> }
> @@ -696,6 +698,10 @@ static int vmd_probe(struct pci_dev *dev, const struct pci_device_id *id)
> return -ENOMEM;
>
> for (i = 0; i < vmd->msix_count; i++) {
> + err = init_srcu_struct(&vmd->irqs[i].srcu);
> + if (err)
> + return err;
> +
> INIT_LIST_HEAD(&vmd->irqs[i].irq_list);
> err = devm_request_irq(&dev->dev, pci_irq_vector(dev, i),
> vmd_irq, 0, "vmd", &vmd->irqs[i]);
> @@ -714,11 +720,19 @@ static int vmd_probe(struct pci_dev *dev, const struct pci_device_id *id)
> return 0;
> }
>
> +static void vmd_cleanup_srcu(struct vmd_dev *vmd)
> +{
> + int i;
> + for (i = 0; i < vmd->msix_count; i++)
> + cleanup_srcu_struct(&vmd->irqs[i].srcu);
> +}
> +
> static void vmd_remove(struct pci_dev *dev)
> {
> struct vmd_dev *vmd = pci_get_drvdata(dev);
>
> vmd_detach_resources(vmd);
> + vmd_cleanup_srcu(vmd);
> sysfs_remove_link(&vmd->dev->dev.kobj, "domain");
> pci_stop_root_bus(vmd->bus);
> pci_remove_root_bus(vmd->bus);
> --
> 1.8.3.1
>
^ 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.