* [PATCH 5/6] crypto: stm32-hash: convert to the new crypto engine API
From: Fabien DESSENNE @ 2018-01-10 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103201109.16077-6-clabbe.montjoie@gmail.com>
On 03/01/18 21:11, Corentin Labbe wrote:
> This patch convert the stm32-hash driver to the new crypto engine API.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> drivers/crypto/stm32/stm32-hash.c | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/crypto/stm32/stm32-hash.c b/drivers/crypto/stm32/stm32-hash.c
> index 4ca4a264a833..9790c2c936c7 100644
> --- a/drivers/crypto/stm32/stm32-hash.c
> +++ b/drivers/crypto/stm32/stm32-hash.c
> @@ -122,6 +122,7 @@ enum stm32_hash_data_format {
> #define HASH_DMA_THRESHOLD 50
>
> struct stm32_hash_ctx {
> + struct crypto_engine_reqctx enginectx;
> struct stm32_hash_dev *hdev;
> unsigned long flags;
>
> @@ -828,6 +829,11 @@ static int stm32_hash_hw_init(struct stm32_hash_dev *hdev,
> return 0;
> }
>
> +static int stm32_hash_one_request(struct crypto_engine *engine,
> + void *areq);
merge these two lines in a single one
> +static int stm32_hash_prepare_req(struct crypto_engine *engine,
> + void *areq);
merge these two lines in a single one
> +
> static int stm32_hash_handle_queue(struct stm32_hash_dev *hdev,
> struct ahash_request *req)
> {
> @@ -835,8 +841,9 @@ static int stm32_hash_handle_queue(struct stm32_hash_dev *hdev,
> }
>
> static int stm32_hash_prepare_req(struct crypto_engine *engine,
> - struct ahash_request *req)
> + void *areq)
merge these two lines in a single one
> {
> + struct ahash_request *req = container_of(areq, struct ahash_request, base);
> 80 characters (CHECKPATCH)
> struct stm32_hash_ctx *ctx = crypto_ahash_ctx(crypto_ahash_reqtfm(req));
> struct stm32_hash_dev *hdev = stm32_hash_find_dev(ctx);
> struct stm32_hash_request_ctx *rctx;
> @@ -855,8 +862,9 @@ static int stm32_hash_prepare_req(struct crypto_engine *engine,
> }
>
> static int stm32_hash_one_request(struct crypto_engine *engine,
> - struct ahash_request *req)
> + void *areq)
merge these two lines in a single one
> {
> + struct ahash_request *req = container_of(areq, struct ahash_request, base);
> 80 characters (CHECKPATCH)
> struct stm32_hash_ctx *ctx = crypto_ahash_ctx(crypto_ahash_reqtfm(req));
> struct stm32_hash_dev *hdev = stm32_hash_find_dev(ctx);
> struct stm32_hash_request_ctx *rctx;
> @@ -1033,6 +1041,9 @@ static int stm32_hash_cra_init_algs(struct crypto_tfm *tfm,
> if (algs_hmac_name)
> ctx->flags |= HASH_FLAGS_HMAC;
>
> + ctx->enginectx.op.do_one_request = stm32_hash_one_request;
> + ctx->enginectx.op.prepare_request = stm32_hash_prepare_req;
> + ctx->enginectx.op.unprepare_request = NULL;
> return 0;
> }
>
> @@ -1493,9 +1504,6 @@ static int stm32_hash_probe(struct platform_device *pdev)
> goto err_engine;
> }
>
> - hdev->engine->prepare_hash_request = stm32_hash_prepare_req;
> - hdev->engine->hash_one_request = stm32_hash_one_request;
> -
> ret = crypto_engine_start(hdev->engine);
> if (ret)
> goto err_engine_start;
^ permalink raw reply
* [PATCH 6/6] crypto: stm32-cryp: convert to the new crypto engine API
From: Fabien DESSENNE @ 2018-01-10 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103201109.16077-7-clabbe.montjoie@gmail.com>
On 03/01/18 21:11, Corentin Labbe wrote:
> This patch convert the stm32-cryp driver to the new crypto engine API.
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> drivers/crypto/stm32/stm32-cryp.c | 21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/crypto/stm32/stm32-cryp.c b/drivers/crypto/stm32/stm32-cryp.c
> index cf1dddbeaa2c..99e0473ef247 100644
> --- a/drivers/crypto/stm32/stm32-cryp.c
> +++ b/drivers/crypto/stm32/stm32-cryp.c
> @@ -91,6 +91,7 @@
> #define _walked_out (cryp->out_walk.offset - cryp->out_sg->offset)
>
> struct stm32_cryp_ctx {
> + struct crypto_engine_reqctx enginectx;
> struct stm32_cryp *cryp;
> int keylen;
> u32 key[AES_KEYSIZE_256 / sizeof(u32)];
> @@ -494,10 +495,20 @@ static int stm32_cryp_cpu_start(struct stm32_cryp *cryp)
> return 0;
> }
>
> +static int stm32_cryp_cipher_one_req(struct crypto_engine *engine,
> + void *areq);
Merge these 2 lines in a single one
> +static int stm32_cryp_prepare_cipher_req(struct crypto_engine *engine,
> + void *areq);
> +
> static int stm32_cryp_cra_init(struct crypto_tfm *tfm)
> {
> + struct stm32_cryp_ctx *ctx = crypto_tfm_ctx(tfm);
> +
> tfm->crt_ablkcipher.reqsize = sizeof(struct stm32_cryp_reqctx);
>
> + ctx->enginectx.op.do_one_request = stm32_cryp_cipher_one_req;
> + ctx->enginectx.op.prepare_request = stm32_cryp_prepare_cipher_req;
> + ctx->enginectx.op.unprepare_request = NULL;
> return 0;
> }
>
> @@ -695,14 +706,17 @@ static int stm32_cryp_prepare_req(struct crypto_engine *engine,
> }
>
> static int stm32_cryp_prepare_cipher_req(struct crypto_engine *engine,
> - struct ablkcipher_request *req)
> + void *areq)
> {
> + struct ablkcipher_request *req = container_of(areq, struct ablkcipher_request, base);
> 80 characters (CHECKPATCH)
> +
> return stm32_cryp_prepare_req(engine, req);
> }
>
> static int stm32_cryp_cipher_one_req(struct crypto_engine *engine,
> - struct ablkcipher_request *req)
> + void *areq)
Merge these 2 lines in a single one
> {
> + struct ablkcipher_request *req = container_of(areq, struct ablkcipher_request, base);
> 80 characters (CHECKPATCH)
> struct stm32_cryp_ctx *ctx = crypto_ablkcipher_ctx(
> crypto_ablkcipher_reqtfm(req));
> struct stm32_cryp *cryp = ctx->cryp;
> @@ -1104,9 +1118,6 @@ static int stm32_cryp_probe(struct platform_device *pdev)
> goto err_engine1;
> }
>
> - cryp->engine->prepare_cipher_request = stm32_cryp_prepare_cipher_req;
> - cryp->engine->cipher_one_request = stm32_cryp_cipher_one_req;
> -
> ret = crypto_engine_start(cryp->engine);
> if (ret) {
> dev_err(dev, "Could not start crypto engine\n");
^ permalink raw reply
* [PATCH 2/4 v6] drm/bridge: Provide a way to embed timing info in bridges
From: Daniel Vetter @ 2018-01-10 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110141226.27826-2-linus.walleij@linaro.org>
On Wed, Jan 10, 2018 at 03:12:24PM +0100, Linus Walleij wrote:
> After some discussion and failed patch sets trying to convey
> the right timing information between the display engine and
> a bridge using the connector, I try instead to use an optional
> timing information container in the bridge itself, so that
> display engines can retrieve it from any bridge and use it to
> determine how to drive outputs.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v5->v6:
> - Sort forward struct declarations alphabetically
> - Switch to using DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE to indicate
> positive or negatice clock samling edge
> ChangeLog ->v5:
> - New patch
> ---
> include/drm/drm_bridge.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 682d01ba920c..28c9ac6d9036 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -29,6 +29,7 @@
> #include <drm/drm_modes.h>
>
> struct drm_bridge;
> +struct drm_bridge_timings;
> struct drm_panel;
>
> /**
> @@ -222,6 +223,23 @@ struct drm_bridge_funcs {
> void (*enable)(struct drm_bridge *bridge);
> };
>
> +/**
> + * struct drm_bridge_timings - timing information for the bridge
> + * @sampling_edge: whether the bridge samples the digital input signal from the
> + * display engine on the positive or negative edge of the clock, this should
> + * reuse the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE bitwise flags from the DRM
> + * connector (bit 2 and 3 valid)
> + * @setup_time_ps: the time in picoseconds the input data lines must be stable
> + * before the clock edge
> + * @hold_time_ps: the time in picoseconds taken for the bridge to sample the
> + * input signal after the clock edge
> + */
Just a style nit: for longer kerneldoc comments for struct members the
in-line style, split up for each member, is imo better.
-Daniel
> +struct drm_bridge_timings {
> + u32 sampling_edge;
> + u32 setup_time_ps;
> + u32 hold_time_ps;
> +};
> +
> /**
> * struct drm_bridge - central DRM bridge control structure
> * @dev: DRM device this bridge belongs to
> @@ -229,6 +247,8 @@ struct drm_bridge_funcs {
> * @next: the next bridge in the encoder chain
> * @of_node: device node pointer to the bridge
> * @list: to keep track of all added bridges
> + * @timings: the timing specification for the bridge, if any (may
> + * be NULL)
> * @funcs: control functions
> * @driver_private: pointer to the bridge driver's internal context
> */
> @@ -240,6 +260,7 @@ struct drm_bridge {
> struct device_node *of_node;
> #endif
> struct list_head list;
> + const struct drm_bridge_timings *timings;
>
> const struct drm_bridge_funcs *funcs;
> void *driver_private;
> --
> 2.14.3
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 2/2] cpufreq: scpi: remove arm_big_little dependency
From: Viresh Kumar @ 2018-01-10 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515516568-31359-3-git-send-email-sudeep.holla@arm.com>
On 09-01-18, 16:49, Sudeep Holla wrote:
> The dependency on physical_package_id from the topology to get the
> cluster identifier is wrong. The concept of cluster used in ARM topology
> is unfortunately not well defined in the architecture, we should avoid
> using it. Further the frequency domain need not be mapped to so called
> "clusters" one to one.
>
> SCPI already provides means to obtain the frequency domain id from the
> device tree. In order to support some new topologies(e.g. DSU which
> contains 2 frequency domains within the physical cluster), pseudo
> clusters are created to make this driver work which is wrong again.
>
> In order to solve those issues and also remove dependency of topological
> physical id for frequency domain, this patch removes the arm_big_little
> dependency from scpi driver.
>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/cpufreq/scpi-cpufreq.c | 193 +++++++++++++++++++++++++++++++++++++----
> 1 file changed, 178 insertions(+), 15 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header
From: Robin Murphy @ 2018-01-10 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110080027.13879-12-hch@lst.de>
On 10/01/18 08:00, Christoph Hellwig wrote:
> phys_to_dma, dma_to_phys and dma_capable are helpers published by
> architecture code for use of swiotlb and xen-swiotlb only. Drivers are
> not supposed to use these directly, but use the DMA API instead.
>
> Move these to a new asm/dma-direct.h helper, included by a
> linux/dma-direct.h wrapper that provides the default linear mapping
> unless the architecture wants to override it.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
[...]
> drivers/crypto/marvell/cesa.c | 1 +
> drivers/mtd/nand/qcom_nandc.c | 1 +
I took a look at these, and it seems their phys_to_dma() usage is doing
the thing which we subsequently formalised as dma_map_resource(). I've
had a crack at a quick patch to update the CESA driver; qcom_nandc looks
slightly more complex in that the changes probably need to span the BAM
dmaengine driver as well.
In the process, though, I stumbled across gen_pool_dma_alloc() - yuck,
something needs doing there, for sure...
Robin.
^ permalink raw reply
* [PATCH] crypto: marvell/cesa - Fix DMA API misuse
From: Robin Murphy @ 2018-01-10 15:15 UTC (permalink / raw)
To: linux-arm-kernel
phys_to_dma() is an internal helper for certain DMA API implementations,
and is not appropriate for drivers to use. It appears that what the CESA
driver really wants to be using is dma_map_resource() - admittedly that
didn't exist when the offending code was first merged, but it does now.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
Found by inspection and compile-tested only
drivers/crypto/marvell/cesa.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 293832488cc9..f81fa4a3e66b 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -15,6 +15,7 @@
*/
#include <linux/delay.h>
+#include <linux/dma-mapping.h>
#include <linux/genalloc.h>
#include <linux/interrupt.h>
#include <linux/io.h>
@@ -409,8 +410,11 @@ static int mv_cesa_get_sram(struct platform_device *pdev, int idx)
if (IS_ERR(engine->sram))
return PTR_ERR(engine->sram);
- engine->sram_dma = phys_to_dma(cesa->dev,
- (phys_addr_t)res->start);
+ engine->sram_dma = dma_map_resource(cesa->dev, res->start,
+ cesa->sram_size,
+ DMA_BIDIRECTIONAL, 0);
+ if (dma_mapping_error(cesa->dev, engine->sram_dma))
+ return -ENOMEM;
return 0;
}
@@ -420,11 +424,12 @@ static void mv_cesa_put_sram(struct platform_device *pdev, int idx)
struct mv_cesa_dev *cesa = platform_get_drvdata(pdev);
struct mv_cesa_engine *engine = &cesa->engines[idx];
- if (!engine->pool)
- return;
-
- gen_pool_free(engine->pool, (unsigned long)engine->sram,
- cesa->sram_size);
+ if (engine->pool)
+ gen_pool_free(engine->pool, (unsigned long)engine->sram,
+ cesa->sram_size);
+ else
+ dma_unmap_resource(cesa->dev, engine->sram_dma,
+ cesa->sram_size, DMA_BIDIRECTIONAL, 0);
}
static int mv_cesa_probe(struct platform_device *pdev)
--
2.13.4.dirty
^ permalink raw reply related
* [PATCH] pwn: stm32: Adopt SPDX identifier
From: Benjamin Gaignard @ 2018-01-10 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uFYjUvnwb2zqdJEuHp4WEnfmxrcZxRta2Cnfz3Q1=55rw@mail.gmail.com>
2017-12-07 11:11 GMT+01:00 Philippe Ombredanne <pombredanne@nexb.com>:
> On Tue, Dec 5, 2017 at 3:57 PM, Benjamin Gaignard
> <benjamin.gaignard@linaro.org> wrote:
>> Add SPDX identifer
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> drivers/pwm/pwm-stm32-lp.c | 3 +--
>> drivers/pwm/pwm-stm32.c | 3 +--
>> 2 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
>> index 1ac9e4384142..cbd271e80c3c 100644
>> --- a/drivers/pwm/pwm-stm32-lp.c
>> +++ b/drivers/pwm/pwm-stm32-lp.c
>> @@ -1,3 +1,4 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> /*
>> * STM32 Low-Power Timer PWM driver
>> *
>> @@ -5,8 +6,6 @@
>> *
>> * Author: Gerald Baeza <gerald.baeza@st.com>
>> *
>> - * License terms: GNU General Public License (GPL), version 2
>> - *
>> * Inspired by Gerald Baeza's pwm-stm32 driver
>> */
>>
>> diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
>> index 6139512aab7b..be56d7af89c9 100644
>> --- a/drivers/pwm/pwm-stm32.c
>> +++ b/drivers/pwm/pwm-stm32.c
>> @@ -1,10 +1,9 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> /*
>> * Copyright (C) STMicroelectronics 2016
>> *
>> * Author: Gerald Baeza <gerald.baeza@st.com>
>> *
>> - * License terms: GNU General Public License (GPL), version 2
>> - *
>> * Inspired by timer-stm32.c from Maxime Coquelin
>> * pwm-atmel.c from Bo Shen
>> */
>> --
>> 2.15.0
>>
>
>
> Thank you for using the simpler SPDX license ids!
>
> Acked-by: Philippe Ombredanne <pombredanne@nexb.com>
>
Gentle ping on this patch before the merge window
> --
> Cordially
> Philippe Ombredanne
^ permalink raw reply
* [PATCH] ARM: socfpga: Configure l2c_aux_val
From: Dinh Nguyen @ 2018-01-10 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515518735-10906-1-git-send-email-thor.thayer@linux.intel.com>
On 01/09/2018 11:25 AM, thor.thayer at linux.intel.com wrote:
> From: Thor Thayer <thor.thayer@linux.intel.com>
>
> Depending on the execution path, the A10 boot ROM/U-Boot may or
> may not set some bits in the l2c aux ctrl register. Due to this
> abiguity, linux must explicitly set the register. This patch
> forces the configuration to match the full boot flow, which
> also matches the setting used in the 3.10-ltsi version of the
> kernel.
>
> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
> Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
> ---
> arch/arm/mach-socfpga/socfpga.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
> index dde14f7bf2c3..37d28794f7d4 100644
> --- a/arch/arm/mach-socfpga/socfpga.c
> +++ b/arch/arm/mach-socfpga/socfpga.c
> @@ -121,7 +121,10 @@ static const char *altera_a10_dt_match[] = {
> };
>
> DT_MACHINE_START(SOCFPGA_A10, "Altera SOCFPGA Arria10")
> - .l2c_aux_val = 0,
> + .l2c_aux_val = L2C_AUX_CTRL_EVTMON_ENABLE |
> + L2C_AUX_CTRL_SHARED_OVERRIDE |
> + L310_AUX_CTRL_INSTR_PREFETCH |
> + L310_AUX_CTRL_DATA_PREFETCH,
The override bit already getting set in socfpga_arria10.dtsi. If you
want the data/instr prefetch bits, then please add them to the dtsi.
Thanks,
Dinh
^ permalink raw reply
* [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header
From: Christoph Hellwig @ 2018-01-10 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b2bd6f4b-a932-5251-517b-83bbccfe7c53@arm.com>
On Wed, Jan 10, 2018 at 09:31:45AM +0000, Vladimir Murzin wrote:
> I know it is copy&paste, but it seems it has off by one error and it should be
>
> return addr + size - 1 <= *dev->dma_mask;
I've added a new patch to fix the mips dma_capable() definition,
thanks.
^ permalink raw reply
* [asoc:topic/iio 9/11] drivers/iio/adc/stm32-dfsdm-adc.c:241:6: sparse: symbol 'stm32_dfsdm_stop_filter' was not declared. Should it be static?
From: kbuild test robot @ 2018-01-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/iio
head: 16cbca06fa8288a4f58426fc898b141e12ee8008
commit: e2e6771c646251657fafb2a78db566d5c2c70635 [9/11] IIO: ADC: add STM32 DFSDM sigma delta ADC support
reproduce:
# apt-get install sparse
git checkout e2e6771c646251657fafb2a78db566d5c2c70635
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/iio/adc/stm32-dfsdm-adc.c:241:6: sparse: symbol 'stm32_dfsdm_stop_filter' was not declared. Should it be
>> drivers/iio/adc/stm32-dfsdm-adc.c:283:5: sparse: symbol 'stm32_dfsdm_channel_parse_of' was not declared. Should it be
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH asoc] IIO: ADC: stm32_dfsdm_stop_filter() can be static
From: kbuild test robot @ 2018-01-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201801102320.fKoiIrHz%fengguang.wu@intel.com>
Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
stm32-dfsdm-adc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
index b03ca3f..e628d04 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -254,7 +254,7 @@ static int stm32_dfsdm_start_filter(struct stm32_dfsdm *dfsdm,
DFSDM_CR1_RSWSTART(1));
}
-void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned int fl_id)
+static void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned int fl_id)
{
/* Disable conversion */
regmap_update_bits(dfsdm->regmap, DFSDM_CR1(fl_id),
@@ -296,9 +296,9 @@ static int stm32_dfsdm_filter_configure(struct stm32_dfsdm *dfsdm,
DFSDM_CR1_RSYNC(fl->sync_mode));
}
-int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
- struct iio_dev *indio_dev,
- struct iio_chan_spec *ch)
+static int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
+ struct iio_dev *indio_dev,
+ struct iio_chan_spec *ch)
{
struct stm32_dfsdm_channel *df_ch;
const char *of_str;
^ permalink raw reply related
* [PATCH] crypto: marvell/cesa - Fix DMA API misuse
From: Boris Brezillon @ 2018-01-10 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55d3177407b00dd4a9d51fe4f8e2bf2282fe8e3d.1515596541.git.robin.murphy@arm.com>
On Wed, 10 Jan 2018 15:15:43 +0000
Robin Murphy <robin.murphy@arm.com> wrote:
> phys_to_dma() is an internal helper for certain DMA API implementations,
> and is not appropriate for drivers to use. It appears that what the CESA
> driver really wants to be using is dma_map_resource() - admittedly that
> didn't exist when the offending code was first merged, but it does now.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
>
> Found by inspection and compile-tested only
>
> drivers/crypto/marvell/cesa.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
> index 293832488cc9..f81fa4a3e66b 100644
> --- a/drivers/crypto/marvell/cesa.c
> +++ b/drivers/crypto/marvell/cesa.c
> @@ -15,6 +15,7 @@
> */
>
> #include <linux/delay.h>
> +#include <linux/dma-mapping.h>
> #include <linux/genalloc.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> @@ -409,8 +410,11 @@ static int mv_cesa_get_sram(struct platform_device *pdev, int idx)
> if (IS_ERR(engine->sram))
> return PTR_ERR(engine->sram);
>
> - engine->sram_dma = phys_to_dma(cesa->dev,
> - (phys_addr_t)res->start);
> + engine->sram_dma = dma_map_resource(cesa->dev, res->start,
> + cesa->sram_size,
> + DMA_BIDIRECTIONAL, 0);
> + if (dma_mapping_error(cesa->dev, engine->sram_dma))
> + return -ENOMEM;
>
> return 0;
> }
> @@ -420,11 +424,12 @@ static void mv_cesa_put_sram(struct platform_device *pdev, int idx)
> struct mv_cesa_dev *cesa = platform_get_drvdata(pdev);
> struct mv_cesa_engine *engine = &cesa->engines[idx];
>
> - if (!engine->pool)
> - return;
> -
> - gen_pool_free(engine->pool, (unsigned long)engine->sram,
> - cesa->sram_size);
> + if (engine->pool)
> + gen_pool_free(engine->pool, (unsigned long)engine->sram,
> + cesa->sram_size);
> + else
> + dma_unmap_resource(cesa->dev, engine->sram_dma,
> + cesa->sram_size, DMA_BIDIRECTIONAL, 0);
> }
>
> static int mv_cesa_probe(struct platform_device *pdev)
^ permalink raw reply
* [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header
From: Christoph Hellwig @ 2018-01-10 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3721b4ba-0685-255e-06b9-6e60678a1a92@arm.com>
On Wed, Jan 10, 2018 at 02:56:01PM +0000, Robin Murphy wrote:
> I took a look at these, and it seems their phys_to_dma() usage is doing the
> thing which we subsequently formalised as dma_map_resource(). I've had a
> crack at a quick patch to update the CESA driver; qcom_nandc looks slightly
> more complex in that the changes probably need to span the BAM dmaengine
> driver as well.
Sounds great, although probably something for the next merge window.
In the meantime does this patch looks good to you?
^ permalink raw reply
* [PATCH 20/33] dma-mapping: clear harmful GFP_* flags in common code
From: Christoph Hellwig @ 2018-01-10 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <27b90341-f9d0-356f-0194-1c7203a3f93e@arm.com>
On Wed, Jan 10, 2018 at 11:59:30AM +0000, Robin Murphy wrote:
> Just a note that if we're all happy to enshrine the "allocations are always
> zeroed" behaviour in the API (I am too, for the record), we should remember
> to follow up once the dust settles to update the docs and I guess just
> #define dma_zalloc_coherent dma_alloc_coherent.
And then just remove it. But yes, another item for the todo list..
^ permalink raw reply
* [PATCH 27/33] dma-direct: use node local allocations for coherent memory
From: Christoph Hellwig @ 2018-01-10 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3672aa56-b85c-5d2c-0c0e-709031b0c0a0@arm.com>
On Wed, Jan 10, 2018 at 12:06:22PM +0000, Robin Murphy wrote:
> On 10/01/18 08:00, Christoph Hellwig wrote:
>> To preserve the x86 behavior.
>
> And combined with patch 10/22 of the SWIOTLB refactoring, this means
> SWIOTLB allocations will also end up NUMA-aware, right? Great, that's what
> we want on arm64 too :)
Well, only for swiotlb allocations that can be satisfied by
dma_direct_alloc. If we actually have to fall back to the swiotlb
buffers there is not node affinity yet.
^ permalink raw reply
* [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header
From: Robin Murphy @ 2018-01-10 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110152617.GB17790@lst.de>
On 10/01/18 15:26, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 02:56:01PM +0000, Robin Murphy wrote:
>> I took a look at these, and it seems their phys_to_dma() usage is doing the
>> thing which we subsequently formalised as dma_map_resource(). I've had a
>> crack at a quick patch to update the CESA driver; qcom_nandc looks slightly
>> more complex in that the changes probably need to span the BAM dmaengine
>> driver as well.
>
> Sounds great, although probably something for the next merge window.
>
> In the meantime does this patch looks good to you?
Yes indeed, modulo Vladimir's comments - it does seem prudent to fix the
obvious off-by-ones as we touch them. I've wanted to do something like
this for ages, but never got around to it myself.
Thanks,
Robin.
^ permalink raw reply
* [RFC PATCH asoc] IIO: ADC: stm32_dfsdm_stop_filter() can be static
From: Arnaud Pouliquen @ 2018-01-10 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110152305.GA83560@lkp-sb05>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
On 01/10/2018 04:23 PM, kbuild test robot wrote:
>
> Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
> ?stm32-dfsdm-adc.c |??? 8 ++++----
> ?1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c
> b/drivers/iio/adc/stm32-dfsdm-adc.c
> index b03ca3f..e628d04 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -254,7 +254,7 @@ static int stm32_dfsdm_start_filter(struct
> stm32_dfsdm *dfsdm,
> ?????????????????????????????????? DFSDM_CR1_RSWSTART(1));
> ?}
> ?
> -void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned int fl_id)
> +static void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned
> int fl_id)
> ?{
> ???????? /* Disable conversion */
> ???????? regmap_update_bits(dfsdm->regmap, DFSDM_CR1(fl_id),
> @@ -296,9 +296,9 @@ static int stm32_dfsdm_filter_configure(struct
> stm32_dfsdm *dfsdm,
> ?????????????????????????????????? DFSDM_CR1_RSYNC(fl->sync_mode));
> ?}
> ?
> -int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
> -??????????????????????????????? struct iio_dev *indio_dev,
> -??????????????????????????????? struct iio_chan_spec *ch)
> +static int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
> +?????????????????????????????????????? struct iio_dev *indio_dev,
> +?????????????????????????????????????? struct iio_chan_spec *ch)
> ?{
> ???????? struct stm32_dfsdm_channel *df_ch;
> ???????? const char *of_str;
^ permalink raw reply
* [PATCH 31/33] dma-direct: reject too small dma masks
From: Christoph Hellwig @ 2018-01-10 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0bcca030-a8da-c34a-a905-707986689f33@arm.com>
On Wed, Jan 10, 2018 at 11:49:34AM +0000, Robin Murphy wrote:
>> +#ifdef CONFIG_ZONE_DMA
>> + if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
>> + return 0;
>> +#else
>> + /*
>> + * Because 32-bit DMA masks are so common we expect every architecture
>> + * to be able to satisfy them - either by not supporting more physical
>> + * memory, or by providing a ZONE_DMA32. If neither is the case, the
>> + * architecture needs to use an IOMMU instead of the direct mapping.
>> + */
>> + if (mask < DMA_BIT_MASK(32))
>> + return 0;
>
> Do you think it's worth the effort to be a little more accommodating here?
> i.e.:
>
> return dma_max_pfn(dev) >= max_pfn;
>
> We seem to have a fair few 28-31 bit masks for older hardware which
> probably associates with host systems packing equivalently small amounts of
> RAM.
And those devices don't have a ZONE_DMA? I think we could do something
like that, but I'd rather have it as a separate commit with a good
explanation. Maybe you can just send on on top of the series?
^ permalink raw reply
* Applied "IIO: ADC: stm32_dfsdm_stop_filter() can be static" to the asoc tree
From: Mark Brown @ 2018-01-10 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110152305.GA83560@lkp-sb05>
The patch
IIO: ADC: stm32_dfsdm_stop_filter() can be static
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 1c4d0c5bc347328b257740d060ce9dbf48eebfe0 Mon Sep 17 00:00:00 2001
From: kbuild test robot <fengguang.wu@intel.com>
Date: Wed, 10 Jan 2018 23:23:05 +0800
Subject: [PATCH] IIO: ADC: stm32_dfsdm_stop_filter() can be static
Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/iio/adc/stm32-dfsdm-adc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
index b03ca3f94331..e628d04d5c77 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -254,7 +254,7 @@ static int stm32_dfsdm_start_filter(struct stm32_dfsdm *dfsdm,
DFSDM_CR1_RSWSTART(1));
}
-void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned int fl_id)
+static void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned int fl_id)
{
/* Disable conversion */
regmap_update_bits(dfsdm->regmap, DFSDM_CR1(fl_id),
@@ -296,9 +296,9 @@ static int stm32_dfsdm_filter_configure(struct stm32_dfsdm *dfsdm,
DFSDM_CR1_RSYNC(fl->sync_mode));
}
-int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
- struct iio_dev *indio_dev,
- struct iio_chan_spec *ch)
+static int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
+ struct iio_dev *indio_dev,
+ struct iio_chan_spec *ch)
{
struct stm32_dfsdm_channel *df_ch;
const char *of_str;
--
2.15.1
^ permalink raw reply related
* [PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops
From: Christoph Hellwig @ 2018-01-10 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a058876-08fc-7323-7cb3-fe85116e2ea8@arm.com>
On Wed, Jan 10, 2018 at 12:16:15PM +0000, Robin Murphy wrote:
> On 10/01/18 08:09, Christoph Hellwig wrote:
>> To properly reject too small DMA masks based on the addressability of the
>> bounce buffer.
>
> I reckon this is self-evident enough that it should simply be squashed into
> the previous patch.
x86 didn't wire it up before, so I want a clear blaimpoint for this
change instead of mixing it up.
^ permalink raw reply
* [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header
From: Christoph Hellwig @ 2018-01-10 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0f90ed0-989f-4dc2-6f86-de8b4e486b55@arm.com>
On Wed, Jan 10, 2018 at 03:31:08PM +0000, Robin Murphy wrote:
> Yes indeed, modulo Vladimir's comments - it does seem prudent to fix the
> obvious off-by-ones as we touch them. I've wanted to do something like this
> for ages, but never got around to it myself.
I've fixed these now in a separate patch. I'm taking this as an
Acked-by.
^ permalink raw reply
* [PATCH v3 3/6] coresight: Support panic kdump functionality
From: Mathieu Poirier @ 2018-01-10 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110051918.GC16554@leoy-linaro>
On 9 January 2018 at 22:19, Leo Yan <leo.yan@linaro.org> wrote:
> On Tue, Jan 09, 2018 at 11:41:26AM -0700, Mathieu Poirier wrote:
>> On Thu, Dec 21, 2017 at 04:20:12PM +0800, Leo Yan wrote:
>> > After kernel panic happens, coresight has many useful info can be used
>> > for analysis. For example, the trace info from ETB RAM can be used to
>> > check the CPU execution flows before crash. So we can save the tracing
>> > data from sink devices, and rely on kdump to save DDR content and uses
>> > "crash" tool to extract coresight dumping from vmcore file.
>> >
>> > This patch is to add a simple framework to support panic dump
>> > functionality; it registers panic notifier, and provide the general APIs
>> > {coresight_kdump_add|coresight_kdump_del} as helper functions so any
>> > coresight device can add itself into dump list or delete as needed.
>> >
>> > This driver provides helper function coresight_kdump_update() to update
>> > the dump buffer base address and buffer size. This function can be used
>> > by coresight driver, e.g. it can be used to save ETM meta data info at
>> > runtime and these info can be prepared pre panic happening.
>> >
>> > When kernel panic happens, the notifier iterates dump list and calls
>> > callback function to dump device specific info. The panic dump is
>> > mainly used to dump trace data so we can get to know the execution flow
>> > before the panic happens.
>> >
>> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
>> > ---
>> > drivers/hwtracing/coresight/Kconfig | 9 ++
>> > drivers/hwtracing/coresight/Makefile | 1 +
>> > .../hwtracing/coresight/coresight-panic-kdump.c | 154 +++++++++++++++++++++
>> > drivers/hwtracing/coresight/coresight-priv.h | 13 ++
>> > include/linux/coresight.h | 7 +
>> > 5 files changed, 184 insertions(+)
>> > create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
>> >
>> > diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
>> > index ef9cb3c..4812529 100644
>> > --- a/drivers/hwtracing/coresight/Kconfig
>> > +++ b/drivers/hwtracing/coresight/Kconfig
>> > @@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
>> > properly, please refer Documentation/trace/coresight-cpu-debug.txt
>> > for detailed description and the example for usage.
>> >
>> > +config CORESIGHT_PANIC_KDUMP
>> > + bool "CoreSight Panic Kdump driver"
>> > + depends on ARM || ARM64
>>
>> At this time only ETMv4 supports the feature, so it is only ARM64.
>
> Thanks for reviewing, Mathieu.
>
> Will change to only for ARM64.
>
>> > + help
>> > + This driver provides panic kdump functionality for CoreSight
>> > + devices. When a kernel panic happen a device supplied callback function
>> > + is used to save trace data to memory. From there we rely on kdump to extract
>> > + the trace data from kernel dump file.
>> > +
>> > endif
>> > diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
>> > index 61db9dd..946fe19 100644
>> > --- a/drivers/hwtracing/coresight/Makefile
>> > +++ b/drivers/hwtracing/coresight/Makefile
>> > @@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>> > obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
>> > obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>> > obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
>> > +obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
>> > diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c b/drivers/hwtracing/coresight/coresight-panic-kdump.c
>> > new file mode 100644
>> > index 0000000..c21d20b
>> > --- /dev/null
>> > +++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
>> > @@ -0,0 +1,154 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +// Copyright (c) 2017 Linaro Limited.
>> > +#include <linux/coresight.h>
>> > +#include <linux/coresight-pmu.h>
>> > +#include <linux/cpumask.h>
>> > +#include <linux/device.h>
>> > +#include <linux/init.h>
>> > +#include <linux/list.h>
>> > +#include <linux/mm.h>
>> > +#include <linux/perf_event.h>
>> > +#include <linux/slab.h>
>> > +#include <linux/types.h>
>> > +
>> > +#include "coresight-priv.h"
>> > +
>> > +typedef void (*coresight_cb_t)(void *data);
>> > +
>> > +/**
>> > + * struct coresight_kdump_node - Node information for dump
>> > + * @cpu: The cpu this node is affined to.
>> > + * @csdev: Handler for coresight device.
>> > + * @buf: Pointer for dump buffer.
>> > + * @buf_size: Length of dump buffer.
>> > + * @list: Hook to the list.
>> > + */
>> > +struct coresight_kdump_node {
>> > + int cpu;
>> > + struct coresight_device *csdev;
>> > + char *buf;
>> > + unsigned int buf_size;
>> > + struct list_head list;
>> > +};
>> > +
>> > +static DEFINE_SPINLOCK(coresight_kdump_lock);
>> > +static LIST_HEAD(coresight_kdump_list);
>> > +static struct notifier_block coresight_kdump_nb;
>> > +
>> > +int coresight_kdump_update(struct coresight_device *csdev, char *buf,
>> > + unsigned int buf_size)
>> > +{
>> > + struct coresight_kdump_node *node = csdev->dump_node;
>> > +
>> > + if (!node) {
>> > + dev_err(&csdev->dev, "Failed to update dump node.\n");
>> > + return -EINVAL;
>> > + }
>> > +
>> > + node->buf = buf;
>> > + node->buf_size = buf_size;
>> > + return 0;
>> > +}
>> > +
>> > +int coresight_kdump_add(struct coresight_device *csdev, int cpu)
>> > +{
>> > + struct coresight_kdump_node *node;
>> > + unsigned long flags;
>> > +
>> > + node = kzalloc(sizeof(*node), GFP_KERNEL);
>> > + if (!node)
>> > + return -ENOMEM;
>> > +
>> > + csdev->dump_node = (void *)node;
>> > + node->cpu = cpu;
>> > + node->csdev = csdev;
>> > +
>> > + spin_lock_irqsave(&coresight_kdump_lock, flags);
>> > + list_add_tail(&node->list, &coresight_kdump_list);
>> > + spin_unlock_irqrestore(&coresight_kdump_lock, flags);
>> > + return 0;
>> > +}
>> > +
>> > +void coresight_kdump_del(struct coresight_device *csdev)
>> > +{
>> > + struct coresight_kdump_node *node, *next;
>> > + unsigned long flags;
>> > +
>> > + spin_lock_irqsave(&coresight_kdump_lock, flags);
>> > + list_for_each_entry_safe(node, next, &coresight_kdump_list, list) {
>> > + if (node->csdev == csdev) {
>> > + list_del(&node->list);
>> > + kfree(node);
>> > + break;
>> > + }
>> > + }
>> > + spin_unlock_irqrestore(&coresight_kdump_lock, flags);
>> > +}
>> > +
>> > +static coresight_cb_t
>> > +coresight_kdump_get_cb(struct coresight_device *csdev)
>> > +{
>> > + coresight_cb_t cb = NULL;
>> > +
>> > + switch (csdev->type) {
>> > + case CORESIGHT_DEV_TYPE_SINK:
>> > + case CORESIGHT_DEV_TYPE_LINKSINK:
>> > + cb = sink_ops(csdev)->panic_cb;
>> > + break;
>> > + case CORESIGHT_DEV_TYPE_SOURCE:
>> > + cb = source_ops(csdev)->panic_cb;
>> > + break;
>> > + case CORESIGHT_DEV_TYPE_LINK:
>> > + cb = link_ops(csdev)->panic_cb;
>> > + break;
>>
>> I don't see why we need a callback for link devices - didn't I raised
>> that question before?
>
> Yes, sorry I have not deleted for link devices completely. Will remove
> it.
>
>> And I've been thinking further about this. The way we call the panic callbacks
>> won't work. When a panic is triggered there might be trace data in the CS network
>> that hasn't made it to the sink yet and calling the panic callbacks for sinks
>> will lead to a loss of data.
>>
>> That is why, when accessing from both sysFS and perf, the current implementation
>> takes great care to stop the tracers first and then deal with the sink. To fix
>> this I suggest to call the panic callbacks only for sources. What happens there
>> will depend on what interface is used (sysFS or perf) - look at what is
>> currently done to get a better understanding.
>
> Will look into this.
>
> If I understand correctly, we need firstly stop tracers and save trace
> data from sink, right? If so we need use single callback function to
> disable path and dump data for sink, will study current case and check
> what's the clean method for kdump.
You are correct - only the callback for sources should be used. In
that callback processing is different whether trace collection was
started from sysFS or perf. The code already exists, it's just a
matter of doing the right thing.
>
>> > + default:
>> > + dev_info(&csdev->dev, "Unsupport panic dump\n");
>>
>> I would not bother with the dev_info()...
>
> Will remove it.
>
>> > + break;
>> > + }
>> > +
>> > + return cb;
>> > +}
>> > +
>> > +/**
>> > + * coresight_kdump_notify - Invoke panic dump callbacks, this is
>> > + * the main function to fulfill the panic dump. It distinguishs
>> > + * to two types: one is pre panic dump which the callback function
>> > + * handler is NULL and coresight drivers can use function
>> > + * coresight_kdump_update() to directly update dump buffer base
>> > + * address and buffer size, for this case this function does nothing
>> > + * and directly bail out; another case is for post panic dump so
>> > + * invoke callback on alive CPU.
>>
>> Now that pre and post processing are gone the description above doesn't match
>> what the function is doing.
>
> Yeah, will remove 'pre' and 'post' to avoid confusion.
>
>> > + *
>> > + * Returns: 0 on success.
>> > + */
>> > +static int coresight_kdump_notify(struct notifier_block *nb,
>> > + unsigned long mode, void *_unused)
>> > +{
>> > + struct coresight_kdump_node *node;
>> > + struct coresight_device *csdev;
>> > + coresight_cb_t cb;
>> > + unsigned long flags;
>> > +
>> > + spin_lock_irqsave(&coresight_kdump_lock, flags);
>> > +
>> > + list_for_each_entry(node, &coresight_kdump_list, list) {
>> > + csdev = node->csdev;
>> > + cb = coresight_kdump_get_cb(csdev);
>> > + if (cb)
>> > + cb(csdev);
>> > + }
>> > +
>> > + spin_unlock_irqrestore(&coresight_kdump_lock, flags);
>> > + return 0;
>> > +}
>> > +
>> > +static int __init coresight_kdump_init(void)
>> > +{
>> > + int ret;
>> > +
>> > + coresight_kdump_nb.notifier_call = coresight_kdump_notify;
>> > + ret = atomic_notifier_chain_register(&panic_notifier_list,
>> > + &coresight_kdump_nb);
>> > + return ret;
>> > +}
>> > +late_initcall(coresight_kdump_init);
>> > diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
>> > index f1d0e21d..937750e 100644
>> > --- a/drivers/hwtracing/coresight/coresight-priv.h
>> > +++ b/drivers/hwtracing/coresight/coresight-priv.h
>> > @@ -151,4 +151,17 @@ static inline int etm_readl_cp14(u32 off, unsigned int *val) { return 0; }
>> > static inline int etm_writel_cp14(u32 off, u32 val) { return 0; }
>> > #endif
>> >
>> > +#ifdef CONFIG_CORESIGHT_PANIC_KDUMP
>> > +extern int coresight_kdump_add(struct coresight_device *csdev, int cpu);
>> > +extern void coresight_kdump_del(struct coresight_device *csdev);
>> > +extern int coresight_kdump_update(struct coresight_device *csdev,
>> > + char *buf, unsigned int buf_size);
>> > +#else
>> > +static inline int
>> > +coresight_kdump_add(struct coresight_device *csdev, int cpu) { return 0; }
>> > +static inline void coresight_kdump_del(struct coresight_device *csdev) {}
>> > +static inline int coresight_kdump_update(struct coresight_device *csdev,
>> > + char *buf, unsigned int buf_size) { return 0; }
>>
>> static inline int
>> coresight_kdump_update(struct coresight_device *csdev, char *buf,
>> unsigned int buf_size) { return 0; }
>
> Will fix.
>
>> > +#endif
>> > +
>> > #endif
>> > diff --git a/include/linux/coresight.h b/include/linux/coresight.h
>> > index d950dad..43e40fa 100644
>> > --- a/include/linux/coresight.h
>> > +++ b/include/linux/coresight.h
>> > @@ -171,6 +171,7 @@ struct coresight_device {
>> > bool orphan;
>> > bool enable; /* true only if configured as part of a path */
>> > bool activated; /* true only if a sink is part of a path */
>> > + void *dump_node;
>>
>> Please add a description for this entry.
>
> Will do.
>
> Thanks,
> Leo Yan
>
>> > };
>> >
>> > #define to_coresight_device(d) container_of(d, struct coresight_device, dev)
>> > @@ -189,6 +190,7 @@ struct coresight_device {
>> > * @set_buffer: initialises buffer mechanic before a trace session.
>> > * @reset_buffer: finalises buffer mechanic after a trace session.
>> > * @update_buffer: update buffer pointers after a trace session.
>> > + * @panic_cb: hook function for panic notifier.
>> > */
>> > struct coresight_ops_sink {
>> > int (*enable)(struct coresight_device *csdev, u32 mode);
>> > @@ -205,6 +207,7 @@ struct coresight_ops_sink {
>> > void (*update_buffer)(struct coresight_device *csdev,
>> > struct perf_output_handle *handle,
>> > void *sink_config);
>> > + void (*panic_cb)(void *data);
>> > };
>> >
>> > /**
>> > @@ -212,10 +215,12 @@ struct coresight_ops_sink {
>> > * Operations available for links.
>> > * @enable: enables flow between iport and oport.
>> > * @disable: disables flow between iport and oport.
>> > + * @panic_cb: hook function for panic notifier.
>> > */
>> > struct coresight_ops_link {
>> > int (*enable)(struct coresight_device *csdev, int iport, int oport);
>> > void (*disable)(struct coresight_device *csdev, int iport, int oport);
>> > + void (*panic_cb)(void *data);
>> > };
>> >
>> > /**
>> > @@ -227,6 +232,7 @@ struct coresight_ops_link {
>> > * to the HW.
>> > * @enable: enables tracing for a source.
>> > * @disable: disables tracing for a source.
>> > + * @panic_cb: hook function for panic notifier.
>> > */
>> > struct coresight_ops_source {
>> > int (*cpu_id)(struct coresight_device *csdev);
>> > @@ -235,6 +241,7 @@ struct coresight_ops_source {
>> > struct perf_event *event, u32 mode);
>> > void (*disable)(struct coresight_device *csdev,
>> > struct perf_event *event);
>> > + void (*panic_cb)(void *data);
>> > };
>> >
>> > struct coresight_ops {
>> > --
>> > 2.7.4
>> >
^ permalink raw reply
* [PATCH 10/22] swiotlb: refactor coherent buffer allocation
From: Christoph Hellwig @ 2018-01-10 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cecc98cf-2e6a-a7bc-7390-d6dcced038c4@arm.com>
On Wed, Jan 10, 2018 at 12:22:18PM +0000, Robin Murphy wrote:
>> + if (phys_addr == SWIOTLB_MAP_ERROR)
>> + goto out_warn;
>> - /* Confirm address can be DMA'd by device */
>> - if (dev_addr + size - 1 > dma_mask) {
>> - printk("hwdev DMA mask = 0x%016Lx, dev_addr = 0x%016Lx\n",
>> - (unsigned long long)dma_mask,
>> - (unsigned long long)dev_addr);
>> + *dma_handle = swiotlb_phys_to_dma(dev, phys_addr);
>
> nit: this should probably go after the dma_coherent_ok() check (as with the
> original logic).
But the originall logic also needs the dma_addr_t for the
dma_coherent_ok check:
dev_addr = swiotlb_phys_to_dma(hwdev, paddr);
/* Confirm address can be DMA'd by device */
if (dev_addr + size - 1 > dma_mask) {
...
goto err_warn;
}
or do you mean assining to *dma_handle? The dma_handle is not
valid for a failure return, so I don't think this should matter.
>> + if (ret) {
>> + *dma_handle = swiotlb_virt_to_bus(hwdev, ret);
>> + if (dma_coherent_ok(hwdev, *dma_handle, size)) {
>> + memset(ret, 0, size);
>> + return ret;
>> + }
>
> Aren't we leaking the pages here?
Yes, that free_pages got lost somewhere in the rebases, I've added
it back.
^ permalink raw reply
* [PATCH v3 6/6] coresight: etm4x: Support panic kdump
From: Mathieu Poirier @ 2018-01-10 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110053319.GD16554@leoy-linaro>
On 9 January 2018 at 22:33, Leo Yan <leo.yan@linaro.org> wrote:
> On Tue, Jan 09, 2018 at 01:21:28PM -0700, Mathieu Poirier wrote:
>> On Thu, Dec 21, 2017 at 04:20:15PM +0800, Leo Yan wrote:
>> > ETMv4 hardware information and configuration needs to be saved as
>> > metadata; these metadata should be compatible with tool 'perf' and
>> > can be used for tracing data analysis. ETMv4 usually works as tracer
>> > per CPU, we cannot wait to gather ETM info after the CPU has been panic
>> > and cannot execute dump operations for itself; so should gather
>> > metadata when the corresponding CPU is alive.
>> >
>> > Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and
>> > won't change at the runtime. Those registers value are filled when
>> > tracers are instantiated.
>> >
>> > The configuration and control registers TRCCONFIGR and TRCTRACEIDR are
>> > dynamically configured, we record their value when enabling coresight
>> > path. When operating from sysFS tracer these two registers are recorded
>> > in etm4_enable_sysfs() and add kdump node into list, and remove the
>> > kdump node in etm4_disable_sysfs(). When operating from perf,
>> > etm_setup_aux() adds all tracers to the dump list and etm4_enable_perf()
>> > is used to record configuration registers and update dump buffer info,
>> > this can avoid unnecessary list addition and deletion operations.
>> > Removal of the tracers from the dump list is done in function
>> > free_event_data().
>> >
>> > Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
>> > ---
>> > drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +++++++++++-
>> > drivers/hwtracing/coresight/coresight-etm4x.c | 23 +++++++++++++++++++++++
>> > drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++++++++++++++
>> > 3 files changed, 49 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
>> > index 8a0ad77..fec779b 100644
>> > --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
>> > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
>> > @@ -137,6 +137,12 @@ static void free_event_data(struct work_struct *work)
>> > }
>> >
>> > for_each_cpu(cpu, mask) {
>> > + struct coresight_device *csdev;
>> > +
>> > + csdev = per_cpu(csdev_src, cpu);
>> > + if (csdev)
>> > + coresight_kdump_del(csdev);
>> > +
>> > if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
>> > coresight_release_path(event_data->path[cpu]);
>> > }
>> > @@ -195,7 +201,7 @@ static void etm_free_aux(void *data)
>> > static void *etm_setup_aux(int event_cpu, void **pages,
>> > int nr_pages, bool overwrite)
>> > {
>> > - int cpu;
>> > + int cpu, ret;
>> > cpumask_t *mask;
>> > struct coresight_device *sink;
>> > struct etm_event_data *event_data = NULL;
>> > @@ -238,6 +244,10 @@ static void *etm_setup_aux(int event_cpu, void **pages,
>> > event_data->path[cpu] = coresight_build_path(csdev, sink);
>> > if (IS_ERR(event_data->path[cpu]))
>> > goto err;
>> > +
>> > + ret = coresight_kdump_add(csdev, cpu);
>>
>> Aren't you missing the configuration for trcconfigr and trctraceidr?
>
> Ah, should update these two configurations in function
> etm4_enable_perf()?
Looking at what you've done for etm4_enable_sysfs() that is probably a
better choice.
>
>> > + if (ret)
>> > + goto err;
>> > }
>> >
>> > if (!sink_ops(sink)->alloc_buffer)
>> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
>> > index cf364a5..cbde398 100644
>> > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
>> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
>> > @@ -258,10 +258,19 @@ static int etm4_enable_perf(struct coresight_device *csdev,
>> > static int etm4_enable_sysfs(struct coresight_device *csdev)
>> > {
>> > struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> > + struct etmv4_config *config = &drvdata->config;
>> > + struct etmv4_metadata *metadata = &drvdata->metadata;
>> > int ret;
>> >
>> > spin_lock(&drvdata->spinlock);
>> >
>> > + /* Update meta data and add into kdump list */
>> > + metadata->trcconfigr = config->cfg;
>> > + metadata->trctraceidr = drvdata->trcid;
>> > +
>> > + coresight_kdump_add(csdev, drvdata->cpu);
>> > + coresight_kdump_update(csdev, (char *)metadata, sizeof(*metadata));
>> > +
>> > /*
>> > * Executing etm4_enable_hw on the cpu whose ETM is being enabled
>> > * ensures that register writes occur when cpu is powered.
>> > @@ -384,6 +393,9 @@ static void etm4_disable_sysfs(struct coresight_device *csdev)
>> > */
>> > smp_call_function_single(drvdata->cpu, etm4_disable_hw, drvdata, 1);
>> >
>> > + /* Delete from kdump list */
>> > + coresight_kdump_del(csdev);
>> > +
>> > spin_unlock(&drvdata->spinlock);
>> > cpus_read_unlock();
>> >
>> > @@ -438,6 +450,7 @@ static void etm4_init_arch_data(void *info)
>> > u32 etmidr4;
>> > u32 etmidr5;
>> > struct etmv4_drvdata *drvdata = info;
>> > + struct etmv4_metadata *metadata = &drvdata->metadata;
>> >
>> > /* Make sure all registers are accessible */
>> > etm4_os_unlock(drvdata);
>> > @@ -590,6 +603,16 @@ static void etm4_init_arch_data(void *info)
>> > drvdata->nrseqstate = BMVAL(etmidr5, 25, 27);
>> > /* NUMCNTR, bits[30:28] number of counters available for tracing */
>> > drvdata->nr_cntr = BMVAL(etmidr5, 28, 30);
>> > +
>> > + /* Update metadata */
>> > + metadata->magic = ETM4_METADATA_MAGIC;
>> > + metadata->cpu = drvdata->cpu;
>> > + metadata->trcidr0 = readl_relaxed(drvdata->base + TRCIDR0);
>> > + metadata->trcidr1 = readl_relaxed(drvdata->base + TRCIDR1);
>> > + metadata->trcidr2 = readl_relaxed(drvdata->base + TRCIDR2);
>> > + metadata->trcidr8 = readl_relaxed(drvdata->base + TRCIDR8);
>> > + metadata->trcauthstatus = readl_relaxed(drvdata->base + TRCAUTHSTATUS);
>> > +
>> > CS_LOCK(drvdata->base);
>> > }
>> >
>> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
>> > index b3b5ea7..08dc8b7 100644
>> > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
>> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
>> > @@ -198,6 +198,20 @@
>> > #define ETM_EXLEVEL_NS_HYP BIT(14)
>> > #define ETM_EXLEVEL_NS_NA BIT(15)
>> >
>> > +#define ETM4_METADATA_MAGIC 0x4040404040404040ULL
>>
>> This is a duplicate of the magic value found in cs-etm.h but I'm not sure of
>> what we'll do about that. It is probably time to come up
>> with a shared file between the kernel and the perf tools, just like
>> coresight-pmu.h. You can have a stab at it or concentrate on my previous
>> comments for now - it's entirely up to you.
>
> I will do some try for this for changing to use one shared single
> header, if I have no confidence for this I will go back to keep this
> code for new version patch.
Deal.
>
>> > +
>> > +struct etmv4_metadata {
>> > + u64 magic;
>> > + u64 cpu;
>> > + u64 trcconfigr;
>> > + u64 trctraceidr;
>> > + u64 trcidr0;
>> > + u64 trcidr1;
>> > + u64 trcidr2;
>> > + u64 trcidr8;
>> > + u64 trcauthstatus;
>> > +};
>>
>> Same here... This is a duplicate of struct etmv4_drvdata. Again not sure about
>> the best way to handle this. I'll think about it.
>
> Sure, I might check with you when I spin patches for this.
>
> Thanks,
> Leo Yan
>
>> > +
>> > /**
>> > * struct etmv4_config - configuration information related to an ETMv4
>> > * @mode: Controls various modes supported by this ETM.
>> > @@ -393,6 +407,7 @@ struct etmv4_drvdata {
>> > bool atbtrig;
>> > bool lpoverride;
>> > struct etmv4_config config;
>> > + struct etmv4_metadata metadata;
>> > };
>> >
>> > /* Address comparator access types */
>> > --
>> > 2.7.4
>> >
^ permalink raw reply
* [PATCH] crypto: marvell/cesa - Fix DMA API misuse
From: Christoph Hellwig @ 2018-01-10 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110162522.580089a5@bbrezillon>
On Wed, Jan 10, 2018 at 04:25:22PM +0100, Boris Brezillon wrote:
> On Wed, 10 Jan 2018 15:15:43 +0000
> Robin Murphy <robin.murphy@arm.com> wrote:
>
> > phys_to_dma() is an internal helper for certain DMA API implementations,
> > and is not appropriate for drivers to use. It appears that what the CESA
> > driver really wants to be using is dma_map_resource() - admittedly that
> > didn't exist when the offending code was first merged, but it does now.
> >
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Thanks. Robin, Boris: do you want me to pick this up in the
dma-mapping tree and move it before the dma-direct.h introduction?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox