* Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: John Garry @ 2016-11-09 9:06 UTC (permalink / raw)
To: Anurup M, Arnd Bergmann
Cc: linux-arm-kernel, anurup.m, linux-kernel, mark.rutland, shyju.pv,
gabriele.paoloni, will.deacon, linuxarm, xuwei5, zhangshaokun,
sanil.kumar, tanxiaojun, shiju.jose
In-Reply-To: <5821F491.1010603@gmail.com>
>>>> I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the
>>>> master
>>>> node, and listing the children by reg property. If the address is not
>>>> easily expressed as a single integer, use a larger #address-cells
>>>> value.
>>> We already have something equivalent to reg in "module-id" (see patch
>>> 02/11), which is the slave device bus address; here's a sample:
>>> + /* For L3 cache PMU */
>>> + pmul3c0 {
>>> + compatible = "hisilicon,hisi-pmu-l3c-v1";
>>> + scl-id = <0x02>;
>>> + num-events = <0x16>;
>>> + num-counters = <0x08>;
>>> + module-id = <0x04>;
>>> + num-banks = <0x04>;
>>> + cfgen-map = <0x02 0x04 0x01 0x08>;
>>> + counter-reg = <0x170>;
>>> + evctrl-reg = <0x04>;
>>> + event-en = <0x1000000>;
>>> + evtype-reg = <0x140>;
>>> + };
>>>
>>> FYI, "module-id" is our own internal hw nomenclature.
>> Yes, that was my interpretation as well. Please use the standard
>> "reg" property for this then.
> Hi Arnd,
>
> Firstly my apologies for a mistake in the bindings example in ([PATCH
> 02/11 ..]).
> The module-id property is a list as defined in the PMU bindings patch
> ([PATCH v1 05/11] dt-bindings .. <https://lkml.org/lkml/2016/11/2/323>).
>
> + djtag0: djtag@0 {
> + compatible = "hisilicon,hip05-cpu-djtag-v1";
> + pmul3c0 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + scl-id = <0x02>;
> + num-events = <0x16>;
> + num-counters = <0x08>;
> + module-id = <0x04 0x04 0x04 0x04>;
> + num-banks = <0x04>;
> + cfgen-map = <0x02 0x04 0x01 0x08>;
> + counter-reg = <0x170>;
> + evctrl-reg = <0x04>;
> + event-en = <0x1000000>;
> + evtype-reg = <0x140>;
> + };
>
>
> The L3 cache in hip05/06/07 chips consist of 4 banks (each bank has PMU
> registers).
>
> In hip05/06 all L3 cache banks are identified with same module-id.
> module-id = <0x04 0x04 0x04 0x04>;
>
> But in the case hip07 chip(djtag v2), each L3 cache bank has different
> module-id
> module-id = <0x01 0x02 0x03 0x04>;
>
> So in this case Please share your opinion on how to model it.
>
My suggestion is to have a single PMU per module, whether that is 4
banks or 1 bank per module, as this makes the driver simpler.
I think you mentioned that a separate PMU per bank does not make much
sense, and you would rather treat all banks as a single bank and
aggregrate their perf statstics under a single PMU: Can you just use a
script in userspace which can do this aggregration work if you have
separate PMUs?
Maybe perf guys have a view on this also.
John
> Some more detail of L3 cache PMU.
> ------------------------------------------------
> The hip05/06/07 chips consists of a multiple Super CPU cluster (16 CPU
> cores). we call it SCCL.
> The L3 cache( 4 banks) is shared by all CPU cores in a SCCL.
> Each L3 cache bank has PMU registers. We always take the sum of the
> counters to show in perf.
> Taking individual L3 cache count is not meaningful as there is no
> mapping of CPU cores to individual
> L3 cache banks.
>
> Please share your suggestion.
>
> Thanks,
> Anurup
^ permalink raw reply
* [U-Boot] [PATCH] tools/kwbimage: add BAUDRATE option
From: Chris Packham @ 2016-11-09 9:07 UTC (permalink / raw)
To: u-boot
Offset 0x18 in some Marvell datasheets this field is redacted as
"reserved". This offset is actually a set of options and bits 2:0 allow
the selection of the UART baudrate.
Allow a BAUDRATE option to set the UART baudrate for any messages coming
from the BootROM firmware.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
I don't have a kirkwood datasheet handy so I've only made this part of the v1
image generation. I can add it to v0 if someone can confirm that it's supported.
tools/kwbimage.c | 31 +++++++++++++++++++++++++++++++
tools/kwbimage.h | 14 +++++++++++++-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 369aba7bcab9..ad182c5c5d9a 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -68,6 +68,7 @@ struct image_cfg_element {
IMAGE_CFG_BINARY,
IMAGE_CFG_PAYLOAD,
IMAGE_CFG_DATA,
+ IMAGE_CFG_BAUDRATE,
} type;
union {
unsigned int version;
@@ -85,6 +86,7 @@ struct image_cfg_element {
unsigned int nandeccmode;
unsigned int nandpagesz;
struct ext_hdr_v0_reg regdata;
+ unsigned int baudrate;
};
};
@@ -195,6 +197,28 @@ static uint32_t image_checksum32(void *start, uint32_t len)
return csum;
}
+static uint8_t baudrate_to_option(unsigned int baudrate)
+{
+ switch (baudrate) {
+ case 2400:
+ return MAIN_HDR_V1_OPT_BAUD_2400;
+ case 4800:
+ return MAIN_HDR_V1_OPT_BAUD_4800;
+ case 9600:
+ return MAIN_HDR_V1_OPT_BAUD_9600;
+ case 19200:
+ return MAIN_HDR_V1_OPT_BAUD_19200;
+ case 38400:
+ return MAIN_HDR_V1_OPT_BAUD_38400;
+ case 57600:
+ return MAIN_HDR_V1_OPT_BAUD_57600;
+ case 115200:
+ return MAIN_HDR_V1_OPT_BAUD_115200;
+ default:
+ return MAIN_HDR_V1_OPT_BAUD_DEFAULT;
+ }
+}
+
static void *image_create_v0(size_t *imagesz, struct image_tool_params *params,
int payloadsz)
{
@@ -398,6 +422,9 @@ static void *image_create_v1(size_t *imagesz, struct image_tool_params *params,
e = image_find_option(IMAGE_CFG_NAND_BADBLK_LOCATION);
if (e)
main_hdr->nandbadblklocation = e->nandbadblklocation;
+ e = image_find_option(IMAGE_CFG_BAUDRATE);
+ if (e)
+ main_hdr->options = baudrate_to_option(e->baudrate);
binarye = image_find_option(IMAGE_CFG_BINARY);
if (binarye) {
@@ -548,6 +575,10 @@ static int image_create_config_parse_oneline(char *line,
el->type = IMAGE_CFG_DATA;
el->regdata.raddr = strtoul(value1, NULL, 16);
el->regdata.rdata = strtoul(value2, NULL, 16);
+ } else if (!strcmp(keyword, "BAUDRATE")) {
+ char *value = strtok_r(NULL, deliminiters, &saveptr);
+ el->type = IMAGE_CFG_BAUDRATE;
+ el->baudrate = strtoul(value, NULL, 10);
} else {
fprintf(stderr, "Ignoring unknown line '%s'\n", line);
}
diff --git a/tools/kwbimage.h b/tools/kwbimage.h
index e6e3d1d4f9ad..9b06004a0b10 100644
--- a/tools/kwbimage.h
+++ b/tools/kwbimage.h
@@ -82,7 +82,7 @@ struct main_hdr_v1 {
uint32_t srcaddr; /* C-F */
uint32_t destaddr; /* 10-13 */
uint32_t execaddr; /* 14-17 */
- uint8_t reserved3; /* 18 */
+ uint8_t options; /* 18 */
uint8_t nandblocksize; /* 19 */
uint8_t nandbadblklocation; /* 1A */
uint8_t reserved4; /* 1B */
@@ -92,6 +92,18 @@ struct main_hdr_v1 {
};
/*
+ * Main header options
+ */
+#define MAIN_HDR_V1_OPT_BAUD_DEFAULT 0
+#define MAIN_HDR_V1_OPT_BAUD_2400 0x1
+#define MAIN_HDR_V1_OPT_BAUD_4800 0x2
+#define MAIN_HDR_V1_OPT_BAUD_9600 0x3
+#define MAIN_HDR_V1_OPT_BAUD_19200 0x4
+#define MAIN_HDR_V1_OPT_BAUD_38400 0x5
+#define MAIN_HDR_V1_OPT_BAUD_57600 0x6
+#define MAIN_HDR_V1_OPT_BAUD_115200 0x7
+
+/*
* Header for the optional headers, version 1 (Armada 370, Armada XP)
*/
struct opt_hdr_v1 {
--
2.10.2
^ permalink raw reply related
* [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: John Garry @ 2016-11-09 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5821F491.1010603@gmail.com>
>>>> I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the
>>>> master
>>>> node, and listing the children by reg property. If the address is not
>>>> easily expressed as a single integer, use a larger #address-cells
>>>> value.
>>> We already have something equivalent to reg in "module-id" (see patch
>>> 02/11), which is the slave device bus address; here's a sample:
>>> + /* For L3 cache PMU */
>>> + pmul3c0 {
>>> + compatible = "hisilicon,hisi-pmu-l3c-v1";
>>> + scl-id = <0x02>;
>>> + num-events = <0x16>;
>>> + num-counters = <0x08>;
>>> + module-id = <0x04>;
>>> + num-banks = <0x04>;
>>> + cfgen-map = <0x02 0x04 0x01 0x08>;
>>> + counter-reg = <0x170>;
>>> + evctrl-reg = <0x04>;
>>> + event-en = <0x1000000>;
>>> + evtype-reg = <0x140>;
>>> + };
>>>
>>> FYI, "module-id" is our own internal hw nomenclature.
>> Yes, that was my interpretation as well. Please use the standard
>> "reg" property for this then.
> Hi Arnd,
>
> Firstly my apologies for a mistake in the bindings example in ([PATCH
> 02/11 ..]).
> The module-id property is a list as defined in the PMU bindings patch
> ([PATCH v1 05/11] dt-bindings .. <https://lkml.org/lkml/2016/11/2/323>).
>
> + djtag0: djtag at 0 {
> + compatible = "hisilicon,hip05-cpu-djtag-v1";
> + pmul3c0 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + scl-id = <0x02>;
> + num-events = <0x16>;
> + num-counters = <0x08>;
> + module-id = <0x04 0x04 0x04 0x04>;
> + num-banks = <0x04>;
> + cfgen-map = <0x02 0x04 0x01 0x08>;
> + counter-reg = <0x170>;
> + evctrl-reg = <0x04>;
> + event-en = <0x1000000>;
> + evtype-reg = <0x140>;
> + };
>
>
> The L3 cache in hip05/06/07 chips consist of 4 banks (each bank has PMU
> registers).
>
> In hip05/06 all L3 cache banks are identified with same module-id.
> module-id = <0x04 0x04 0x04 0x04>;
>
> But in the case hip07 chip(djtag v2), each L3 cache bank has different
> module-id
> module-id = <0x01 0x02 0x03 0x04>;
>
> So in this case Please share your opinion on how to model it.
>
My suggestion is to have a single PMU per module, whether that is 4
banks or 1 bank per module, as this makes the driver simpler.
I think you mentioned that a separate PMU per bank does not make much
sense, and you would rather treat all banks as a single bank and
aggregrate their perf statstics under a single PMU: Can you just use a
script in userspace which can do this aggregration work if you have
separate PMUs?
Maybe perf guys have a view on this also.
John
> Some more detail of L3 cache PMU.
> ------------------------------------------------
> The hip05/06/07 chips consists of a multiple Super CPU cluster (16 CPU
> cores). we call it SCCL.
> The L3 cache( 4 banks) is shared by all CPU cores in a SCCL.
> Each L3 cache bank has PMU registers. We always take the sum of the
> counters to show in perf.
> Taking individual L3 cache count is not meaningful as there is no
> mapping of CPU cores to individual
> L3 cache banks.
>
> Please share your suggestion.
>
> Thanks,
> Anurup
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix bpf_prog_add ref_cnt in mlx4
From: Daniel Borkmann @ 2016-11-09 9:05 UTC (permalink / raw)
To: Zhiyi Sun
Cc: bblanco, Tariq Toukan, Yishai Hadas, netdev, linux-rdma,
linux-kernel, alexei.starovoitov
In-Reply-To: <20161109073544.jbufjqn7y7oa6ptg@ubuntu>
On 11/09/2016 08:35 AM, Zhiyi Sun wrote:
> There are rx_ring_num queues. Each queue will load xdp prog. So
> bpf_prog_add() should add rx_ring_num to ref_cnt.
>
> Signed-off-by: Zhiyi Sun <zhiyisun@gmail.com>
Your analysis looks incorrect to me. Please elaborate in more detail why
you think current code is buggy ...
Call path is dev_change_xdp_fd(), which does bpf_prog_get_type() on the
fd. This already takes a ref and only drops it in case of error. Thus
in mlx4_xdp_set(), you only need priv->rx_ring_num - 1 refs for the rest
of the rings, so that dropping refs from old_prog makes sure we release
it again. Looks correct to me (maybe a comment would have helped there).
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 12c99a2..d25e150 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -2650,7 +2650,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> */
> if (priv->xdp_ring_num == xdp_ring_num) {
> if (prog) {
> - prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
> + prog = bpf_prog_add(prog, priv->rx_ring_num);
> if (IS_ERR(prog))
> return PTR_ERR(prog);
> }
> @@ -2680,7 +2680,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> }
>
> if (prog) {
> - prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
> + prog = bpf_prog_add(prog, priv->rx_ring_num);
> if (IS_ERR(prog))
> return PTR_ERR(prog);
> }
>
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix bpf_prog_add ref_cnt in mlx4
From: Daniel Borkmann @ 2016-11-09 9:05 UTC (permalink / raw)
To: Zhiyi Sun
Cc: bblanco-uqk4Ao+rVK5Wk0Htik3J/w, Tariq Toukan, Yishai Hadas,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
alexei.starovoitov-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20161109073544.jbufjqn7y7oa6ptg@ubuntu>
On 11/09/2016 08:35 AM, Zhiyi Sun wrote:
> There are rx_ring_num queues. Each queue will load xdp prog. So
> bpf_prog_add() should add rx_ring_num to ref_cnt.
>
> Signed-off-by: Zhiyi Sun <zhiyisun-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Your analysis looks incorrect to me. Please elaborate in more detail why
you think current code is buggy ...
Call path is dev_change_xdp_fd(), which does bpf_prog_get_type() on the
fd. This already takes a ref and only drops it in case of error. Thus
in mlx4_xdp_set(), you only need priv->rx_ring_num - 1 refs for the rest
of the rings, so that dropping refs from old_prog makes sure we release
it again. Looks correct to me (maybe a comment would have helped there).
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 12c99a2..d25e150 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -2650,7 +2650,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> */
> if (priv->xdp_ring_num == xdp_ring_num) {
> if (prog) {
> - prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
> + prog = bpf_prog_add(prog, priv->rx_ring_num);
> if (IS_ERR(prog))
> return PTR_ERR(prog);
> }
> @@ -2680,7 +2680,7 @@ static int mlx4_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> }
>
> if (prog) {
> - prog = bpf_prog_add(prog, priv->rx_ring_num - 1);
> + prog = bpf_prog_add(prog, priv->rx_ring_num);
> if (IS_ERR(prog))
> return PTR_ERR(prog);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
From: Samuel Thibault @ 2016-11-09 9:04 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Peter Maydell, Michal Suchanek, QEMU Developers
In-Reply-To: <20161109095859.0be2b487.cornelia.huck@de.ibm.com>
Hello,
Cornelia Huck, on Wed 09 Nov 2016 09:58:59 +0100, wrote:
> On Tue, 8 Nov 2016 21:10:19 +0100
> Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > Cornelia Huck, on Tue 08 Nov 2016 12:34:49 +0100, wrote:
> > “
> > configure test passed without -Werror but failed with -Werror.
> > This is probably a bug in the configure script. The failing command
> > will be at the bottom of config.log.
> > You can run configure with --disable-werror to bypass this check.
> > ”
> >
> > If so, you should really have said it, I was really wondering how
> > configure could just stopping in your case. That does explain things
> > indeed.
>
> I said so in my very first mail for the issue... appears I was unclear.
Do you mean "configure barfs about -Werror."?
Yes it was unclear to me :)
> > Could you try the attached patch? It should be able to really fail
> > without Werror too.
>
> With your patch, configure runs through and detects curses=no. Not sure
> that's correct, though: SLES12SP1 _does_ have curses, but not a .pc
> file for ncursesw. I don't know enough about curses to say whether it
> should be that way...
Please post config.log so we can have a clue about what is going
wrong. All these error messages are meant to be reported verbatim, not
reinterpreted :)
Samuel
^ permalink raw reply
* Re: [PATCH v2] irqchip/renesas-irqc: Postpone driver initialization
From: Marc Zyngier @ 2016-11-09 9:03 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Gleixner, Jason Cooper
Cc: Florian Fainelli, Simon Horman, Magnus Damm, linux-renesas-soc,
linux-kernel, netdev
In-Reply-To: <1478633747-26878-1-git-send-email-geert+renesas@glider.be>
Hi Geert,
On 08/11/16 19:35, Geert Uytterhoeven wrote:
> Currently the renesas-irqc driver uses postcore_initcall().
>
> However, the new CPG/MSSR driver uses subsys_initcall(). Hence the
> IRQC's probe will be deferred, which causes the Micrel Ethernet PHY to
> not find its interrupt on R-Car Gen2 and RZ/G, as the of_mdio subsystem
> does not support deferred probe yet.
>
> Replace postcore_initcall() by device_initcall() to work around this.
>
> Note that on R-Mobile APE6, where the PFC/GPIO combo uses the IRQC as
> its parent interrupt controller, this does cause a few additional probe
> deferrals (for SCIFA0, SD0, SD1, and MMC). But the affected drivers
> handle that fine.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Tested-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
> v2:
> - Drop RFC state,
> - Add Tested-by,
> - Improved description.
> ---
> drivers/irqchip/irq-renesas-irqc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-renesas-irqc.c b/drivers/irqchip/irq-renesas-irqc.c
> index 52304b139aa46a60..992849e54d00ea77 100644
> --- a/drivers/irqchip/irq-renesas-irqc.c
> +++ b/drivers/irqchip/irq-renesas-irqc.c
> @@ -295,7 +295,7 @@ static int __init irqc_init(void)
> {
> return platform_driver_register(&irqc_device_driver);
> }
> -postcore_initcall(irqc_init);
> +device_initcall(irqc_init);
Overall, I'm not keen on these hacks (by moving from one initcall to
another, you're as likely to fix something than to break something else).
What should really be done is to either teach the various drivers to
handle deferred probing, or to teach the kernel to handle proper
dependencies (vastly more ambitious).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 12/14] crypto: caam - move sec4_sg_entry to sg_sw_sec4.h
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
sec4_sg_entry structure is used only by helper functions in sg_sw_sec4.h.
Since SEC HW S/G entries are to be manipulated only indirectly, via these
functions, move sec4_sg_entry to the corresponding header.
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/desc.h | 6 ------
drivers/crypto/caam/sg_sw_sec4.h | 6 +++++-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/caam/desc.h b/drivers/crypto/caam/desc.h
index 61059abef737..2e6766a1573f 100644
--- a/drivers/crypto/caam/desc.h
+++ b/drivers/crypto/caam/desc.h
@@ -22,12 +22,6 @@
#define SEC4_SG_LEN_MASK 0x3fffffff /* Excludes EXT and FINAL */
#define SEC4_SG_OFFSET_MASK 0x00001fff
-struct sec4_sg_entry {
- u64 ptr;
- u32 len;
- u32 bpid_offset;
-};
-
/* Max size of any CAAM descriptor in 32-bit words, inclusive of header */
#define MAX_CAAM_DESCSIZE 64
diff --git a/drivers/crypto/caam/sg_sw_sec4.h b/drivers/crypto/caam/sg_sw_sec4.h
index 41cd5a356d05..6afa20c4a013 100644
--- a/drivers/crypto/caam/sg_sw_sec4.h
+++ b/drivers/crypto/caam/sg_sw_sec4.h
@@ -7,7 +7,11 @@
#include "regs.h"
-struct sec4_sg_entry;
+struct sec4_sg_entry {
+ u64 ptr;
+ u32 len;
+ u32 bpid_offset;
+};
/*
* convert single dma address to h/w link table format
--
2.4.4
^ permalink raw reply related
* [PATCH 00/14] crypto: caam - fixes, clean-up
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
This is a batch of fixes and clean-up for caam driver.
Only the fix for the givencrypt shared descriptors is high-impact
and thus sent to -stable.
Thanks,
Horia
Alex Porosanu (1):
crypto: caam - fix AEAD givenc descriptors
Horia Geantă (13):
crypto: caam - completely remove error propagation handling
crypto: caam - desc.h fixes
crypto: caam - fix sparse warnings
crypto: caam - fix smatch warnings
crypto: caam - remove unused may_sleep in dbg_dump_sg()
crypto: caam - remove unused command from aead givencrypt
crypto: caam - trivial code clean-up
crypto: caam - remove unreachable code in report_ccb_status()
crypto: caam - fix DMA API mapping leak in ablkcipher code
Revert "crypto: caam - get rid of tasklet"
crypto: caam - move sec4_sg_entry to sg_sw_sec4.h
crypto: caam - constify pointer to descriptor buffer
crypto: caam - merge identical ahash_final/finup shared desc
drivers/crypto/caam/caamalg.c | 92 +++++++++++++++++++++++++--------------
drivers/crypto/caam/caamhash.c | 43 +++---------------
drivers/crypto/caam/caampkc.c | 4 +-
drivers/crypto/caam/caamrng.c | 10 ++---
drivers/crypto/caam/ctrl.c | 40 ++++++++---------
drivers/crypto/caam/desc.h | 22 ++++------
drivers/crypto/caam/desc_constr.h | 72 +++++++++++++++---------------
drivers/crypto/caam/error.c | 5 +--
drivers/crypto/caam/intern.h | 1 +
drivers/crypto/caam/jr.c | 27 +++++++-----
drivers/crypto/caam/sg_sw_sec4.h | 6 ++-
11 files changed, 158 insertions(+), 164 deletions(-)
--
2.4.4
^ permalink raw reply
* [PATCH 10/14] crypto: caam - fix DMA API mapping leak in ablkcipher code
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
alkcipher_edesc_alloc() and ablkcipher_giv_edesc_alloc() don't
free / unmap resources on error path:
- dmap_map_sg() could fail, thus make sure the return value is checked
- unmap DMA mappings in case of error
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/caamalg.c | 44 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 34dfcdb7ff84..8db54b090d39 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -2600,16 +2600,33 @@ static struct ablkcipher_edesc *ablkcipher_edesc_alloc(struct ablkcipher_request
if (likely(req->src == req->dst)) {
sgc = dma_map_sg(jrdev, req->src, src_nents ? : 1,
DMA_BIDIRECTIONAL);
+ if (unlikely(!sgc)) {
+ dev_err(jrdev, "unable to map source\n");
+ return ERR_PTR(-ENOMEM);
+ }
} else {
sgc = dma_map_sg(jrdev, req->src, src_nents ? : 1,
DMA_TO_DEVICE);
+ if (unlikely(!sgc)) {
+ dev_err(jrdev, "unable to map source\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
sgc = dma_map_sg(jrdev, req->dst, dst_nents ? : 1,
DMA_FROM_DEVICE);
+ if (unlikely(!sgc)) {
+ dev_err(jrdev, "unable to map destination\n");
+ dma_unmap_sg(jrdev, req->src, src_nents ? : 1,
+ DMA_TO_DEVICE);
+ return ERR_PTR(-ENOMEM);
+ }
}
iv_dma = dma_map_single(jrdev, req->info, ivsize, DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, iv_dma)) {
dev_err(jrdev, "unable to map IV\n");
+ caam_unmap(jrdev, req->src, req->dst, src_nents, dst_nents, 0,
+ 0, 0, 0);
return ERR_PTR(-ENOMEM);
}
@@ -2629,6 +2646,8 @@ static struct ablkcipher_edesc *ablkcipher_edesc_alloc(struct ablkcipher_request
GFP_DMA | flags);
if (!edesc) {
dev_err(jrdev, "could not allocate extended descriptor\n");
+ caam_unmap(jrdev, req->src, req->dst, src_nents, dst_nents,
+ iv_dma, ivsize, 0, 0);
return ERR_PTR(-ENOMEM);
}
@@ -2655,6 +2674,9 @@ static struct ablkcipher_edesc *ablkcipher_edesc_alloc(struct ablkcipher_request
sec4_sg_bytes, DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
+ caam_unmap(jrdev, req->src, req->dst, src_nents, dst_nents,
+ iv_dma, ivsize, 0, 0);
+ kfree(edesc);
return ERR_PTR(-ENOMEM);
}
@@ -2776,11 +2798,26 @@ static struct ablkcipher_edesc *ablkcipher_giv_edesc_alloc(
if (likely(req->src == req->dst)) {
sgc = dma_map_sg(jrdev, req->src, src_nents ? : 1,
DMA_BIDIRECTIONAL);
+ if (unlikely(!sgc)) {
+ dev_err(jrdev, "unable to map source\n");
+ return ERR_PTR(-ENOMEM);
+ }
} else {
sgc = dma_map_sg(jrdev, req->src, src_nents ? : 1,
DMA_TO_DEVICE);
+ if (unlikely(!sgc)) {
+ dev_err(jrdev, "unable to map source\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
sgc = dma_map_sg(jrdev, req->dst, dst_nents ? : 1,
DMA_FROM_DEVICE);
+ if (unlikely(!sgc)) {
+ dev_err(jrdev, "unable to map destination\n");
+ dma_unmap_sg(jrdev, req->src, src_nents ? : 1,
+ DMA_TO_DEVICE);
+ return ERR_PTR(-ENOMEM);
+ }
}
/*
@@ -2790,6 +2827,8 @@ static struct ablkcipher_edesc *ablkcipher_giv_edesc_alloc(
iv_dma = dma_map_single(jrdev, greq->giv, ivsize, DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, iv_dma)) {
dev_err(jrdev, "unable to map IV\n");
+ caam_unmap(jrdev, req->src, req->dst, src_nents, dst_nents, 0,
+ 0, 0, 0);
return ERR_PTR(-ENOMEM);
}
@@ -2805,6 +2844,8 @@ static struct ablkcipher_edesc *ablkcipher_giv_edesc_alloc(
GFP_DMA | flags);
if (!edesc) {
dev_err(jrdev, "could not allocate extended descriptor\n");
+ caam_unmap(jrdev, req->src, req->dst, src_nents, dst_nents,
+ iv_dma, ivsize, 0, 0);
return ERR_PTR(-ENOMEM);
}
@@ -2832,6 +2873,9 @@ static struct ablkcipher_edesc *ablkcipher_giv_edesc_alloc(
sec4_sg_bytes, DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
+ caam_unmap(jrdev, req->src, req->dst, src_nents, dst_nents,
+ iv_dma, ivsize, 0, 0);
+ kfree(edesc);
return ERR_PTR(-ENOMEM);
}
edesc->iv_dma = iv_dma;
--
2.4.4
^ permalink raw reply related
* Re: Patch "scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices" has been added to the 4.8-stable tree
From: Greg KH @ 2016-11-09 9:03 UTC (permalink / raw)
To: Sumit Saxena
Cc: Kashyap Desai, emilne, hare, martin.petersen, thenzl, stable,
stable-commits
In-Reply-To: <8cf3887e20e37314f49066cea65369ee@mail.gmail.com>
On Wed, Nov 09, 2016 at 02:26:31PM +0530, Sumit Saxena wrote:
> >-----Original Message-----
> >From: Greg KH [mailto:gregkh@linuxfoundation.org]
> >Sent: Wednesday, November 09, 2016 2:19 PM
> >To: Sumit Saxena
> >Cc: Kashyap Desai; emilne@redhat.com; hare@suse.com;
> >martin.petersen@oracle.com; thenzl@redhat.com; stable@vger.kernel.org;
> >stable-commits@vger.kernel.org
> >Subject: Re: Patch "scsi: megaraid_sas: Fix data integrity failure for
> JBOD
> >(passthrough) devices" has been added to the 4.8-stable tree
> >
> >On Wed, Nov 09, 2016 at 02:15:10PM +0530, Sumit Saxena wrote:
> >> >-----Original Message-----
> >> >From: gregkh@linuxfoundation.org [mailto:gregkh@linuxfoundation.org]
> >> >Sent: Wednesday, November 09, 2016 1:49 PM
> >> >To: kashyap.desai@broadcom.com; emilne@redhat.com;
> >> >gregkh@linuxfoundation.org; hare@suse.com;
> >> >martin.petersen@oracle.com; sumit.saxena@broadcom.com;
> >> >thenzl@redhat.com
> >> >Cc: stable@vger.kernel.org; stable-commits@vger.kernel.org
> >> >Subject: Patch "scsi: megaraid_sas: Fix data integrity failure for
> >> >JBOD
> >> >(passthrough) devices" has been added to the 4.8-stable tree
> >> >
> >> >
> >> >This is a note to let you know that I've just added the patch titled
> >> >
> >> > scsi: megaraid_sas: Fix data integrity failure for JBOD
> >> > (passthrough)
> >> devices
> >> >
> >> >to the 4.8-stable tree which can be found at:
> >> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-
> >> >queue.git;a=summary
> >> >
> >> >The filename of the patch is:
> >> >
> >> >scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-
> >> >devices.patch
> >> >and it can be found in the queue-4.8 subdirectory.
> >> >
> >> >If you, or anyone else, feels it should not be added to the stable
> >> >tree,
> >> please let
> >> ><stable@vger.kernel.org> know about it.
> >>
> >> There will be follow up patch which I will be sending in sometime so
> >> follow patch needs to be applied along with this patch.
> >
> >Does that mean that this patch on its own is broken?
> >
> >confused,
> Yes this patch is broken and follow up patch will fix that. I am doing
> some testing with fix and will send it in sometime.
So should I drop this one from the stable trees until that one is
merged?
thanks,
greg k-h
^ permalink raw reply
* [PATCH 02/14] crypto: caam - completely remove error propagation handling
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
Commit 4464a7d4f53d756101291da26563f37f7fce40f3
("crypto: caam - remove error propagation handling")
removed error propagation handling only from caamalg.
Do this in all other places: caamhash, caamrng.
Update descriptors' lengths appropriately.
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/caamhash.c | 5 +----
drivers/crypto/caam/caamrng.c | 5 +----
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 660dc206969f..51990dd56024 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -72,7 +72,7 @@
#define CAAM_MAX_HASH_DIGEST_SIZE SHA512_DIGEST_SIZE
/* length of descriptors text */
-#define DESC_AHASH_BASE (4 * CAAM_CMD_SZ)
+#define DESC_AHASH_BASE (3 * CAAM_CMD_SZ)
#define DESC_AHASH_UPDATE_LEN (6 * CAAM_CMD_SZ)
#define DESC_AHASH_UPDATE_FIRST_LEN (DESC_AHASH_BASE + 4 * CAAM_CMD_SZ)
#define DESC_AHASH_FINAL_LEN (DESC_AHASH_BASE + 5 * CAAM_CMD_SZ)
@@ -246,9 +246,6 @@ static inline void init_sh_desc_key_ahash(u32 *desc, struct caam_hash_ctx *ctx)
set_jump_tgt_here(desc, key_jump_cmd);
}
-
- /* Propagate errors from shared to job descriptor */
- append_cmd(desc, SET_OK_NO_PROP_ERRORS | CMD_LOAD);
}
/*
diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index 9b92af2c7241..bb1c118b2d1b 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -52,7 +52,7 @@
/* length of descriptors */
#define DESC_JOB_O_LEN (CAAM_CMD_SZ * 2 + CAAM_PTR_SZ * 2)
-#define DESC_RNG_LEN (4 * CAAM_CMD_SZ)
+#define DESC_RNG_LEN (3 * CAAM_CMD_SZ)
/* Buffer, its dma address and lock */
struct buf_data {
@@ -196,9 +196,6 @@ static inline int rng_create_sh_desc(struct caam_rng_ctx *ctx)
init_sh_desc(desc, HDR_SHARE_SERIAL);
- /* Propagate errors from shared to job descriptor */
- append_cmd(desc, SET_OK_NO_PROP_ERRORS | CMD_LOAD);
-
/* Generate random bytes */
append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG);
--
2.4.4
^ permalink raw reply related
* [PATCH 11/14] Revert "crypto: caam - get rid of tasklet"
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto, Russell King
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
This reverts commit 66d2e2028091a074aa1290d2eeda5ddb1a6c329c.
Quoting from Russell's findings:
https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg21136.html
[quote]
Okay, I've re-tested, using a different way of measuring, because using
openssl speed is impractical for off-loaded engines. I've decided to
use this way to measure the performance:
dd if=/dev/zero bs=1048576 count=128 | /usr/bin/time openssl dgst -md5
For the threaded IRQs case gives:
0.05user 2.74system 0:05.30elapsed 52%CPU (0avgtext+0avgdata 2400maxresident)k
0.06user 2.52system 0:05.18elapsed 49%CPU (0avgtext+0avgdata 2404maxresident)k
0.12user 2.60system 0:05.61elapsed 48%CPU (0avgtext+0avgdata 2460maxresident)k
=> 5.36s => 25.0MB/s
and the tasklet case:
0.08user 2.53system 0:04.83elapsed 54%CPU (0avgtext+0avgdata 2468maxresident)k
0.09user 2.47system 0:05.16elapsed 49%CPU (0avgtext+0avgdata 2368maxresident)k
0.10user 2.51system 0:04.87elapsed 53%CPU (0avgtext+0avgdata 2460maxresident)k
=> 4.95 => 27.1MB/s
which corresponds to an 8% slowdown for the threaded IRQ case. So,
tasklets are indeed faster than threaded IRQs.
[...]
I think I've proven from the above that this patch needs to be reverted
due to the performance regression, and that there _is_ most definitely
a deterimental effect of switching from tasklets to threaded IRQs.
[/quote]
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/intern.h | 1 +
drivers/crypto/caam/jr.c | 25 ++++++++++++++++---------
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
index 5d4c05074a5c..e2bcacc1a921 100644
--- a/drivers/crypto/caam/intern.h
+++ b/drivers/crypto/caam/intern.h
@@ -41,6 +41,7 @@ struct caam_drv_private_jr {
struct device *dev;
int ridx;
struct caam_job_ring __iomem *rregs; /* JobR's register space */
+ struct tasklet_struct irqtask;
int irq; /* One per queue */
/* Number of scatterlist crypt transforms active on the JobR */
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 7331ea734f37..c8604dfadbf5 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -73,6 +73,8 @@ static int caam_jr_shutdown(struct device *dev)
ret = caam_reset_hw_jr(dev);
+ tasklet_kill(&jrp->irqtask);
+
/* Release interrupt */
free_irq(jrp->irq, dev);
@@ -128,7 +130,7 @@ static irqreturn_t caam_jr_interrupt(int irq, void *st_dev)
/*
* Check the output ring for ready responses, kick
- * the threaded irq if jobs done.
+ * tasklet if jobs done.
*/
irqstate = rd_reg32(&jrp->rregs->jrintstatus);
if (!irqstate)
@@ -150,13 +152,18 @@ static irqreturn_t caam_jr_interrupt(int irq, void *st_dev)
/* Have valid interrupt at this point, just ACK and trigger */
wr_reg32(&jrp->rregs->jrintstatus, irqstate);
- return IRQ_WAKE_THREAD;
+ preempt_disable();
+ tasklet_schedule(&jrp->irqtask);
+ preempt_enable();
+
+ return IRQ_HANDLED;
}
-static irqreturn_t caam_jr_threadirq(int irq, void *st_dev)
+/* Deferred service handler, run as interrupt-fired tasklet */
+static void caam_jr_dequeue(unsigned long devarg)
{
int hw_idx, sw_idx, i, head, tail;
- struct device *dev = st_dev;
+ struct device *dev = (struct device *)devarg;
struct caam_drv_private_jr *jrp = dev_get_drvdata(dev);
void (*usercall)(struct device *dev, u32 *desc, u32 status, void *arg);
u32 *userdesc, userstatus;
@@ -230,8 +237,6 @@ static irqreturn_t caam_jr_threadirq(int irq, void *st_dev)
/* reenable / unmask IRQs */
clrsetbits_32(&jrp->rregs->rconfig_lo, JRCFG_IMSK, 0);
-
- return IRQ_HANDLED;
}
/**
@@ -389,10 +394,11 @@ static int caam_jr_init(struct device *dev)
jrp = dev_get_drvdata(dev);
+ tasklet_init(&jrp->irqtask, caam_jr_dequeue, (unsigned long)dev);
+
/* Connect job ring interrupt handler. */
- error = request_threaded_irq(jrp->irq, caam_jr_interrupt,
- caam_jr_threadirq, IRQF_SHARED,
- dev_name(dev), dev);
+ error = request_irq(jrp->irq, caam_jr_interrupt, IRQF_SHARED,
+ dev_name(dev), dev);
if (error) {
dev_err(dev, "can't connect JobR %d interrupt (%d)\n",
jrp->ridx, jrp->irq);
@@ -454,6 +460,7 @@ static int caam_jr_init(struct device *dev)
out_free_irq:
free_irq(jrp->irq, dev);
out_kill_deq:
+ tasklet_kill(&jrp->irqtask);
return error;
}
--
2.4.4
^ permalink raw reply related
* [PATCH 03/14] crypto: caam - desc.h fixes
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
1. fix HDR_START_IDX_MASK, HDR_SD_SHARE_MASK, HDR_JD_SHARE_MASK
Define HDR_START_IDX_MASK consistently with the other masks:
mask = bitmask << offset
2. OP_ALG_TYPE_CLASS1 and OP_ALG_TYPE_CLASS2 must be shifted.
3. fix FIFO_STORE output data type value for AFHA S-Box
4. fix OPERATION pkha modular arithmetic source mask
5. rename LDST_SRCDST_WORD_CLASS1_ICV_SZ to
LDST_SRCDST_WORD_CLASS1_IV_SZ (it refers to IV, not ICV).
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/desc.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/caam/desc.h b/drivers/crypto/caam/desc.h
index 513b6646bb36..61059abef737 100644
--- a/drivers/crypto/caam/desc.h
+++ b/drivers/crypto/caam/desc.h
@@ -90,8 +90,8 @@ struct sec4_sg_entry {
#define HDR_ZRO 0x00008000
/* Start Index or SharedDesc Length */
-#define HDR_START_IDX_MASK 0x3f
#define HDR_START_IDX_SHIFT 16
+#define HDR_START_IDX_MASK (0x3f << HDR_START_IDX_SHIFT)
/* If shared descriptor header, 6-bit length */
#define HDR_DESCLEN_SHR_MASK 0x3f
@@ -121,10 +121,10 @@ struct sec4_sg_entry {
#define HDR_PROP_DNR 0x00000800
/* JobDesc/SharedDesc share property */
-#define HDR_SD_SHARE_MASK 0x03
#define HDR_SD_SHARE_SHIFT 8
-#define HDR_JD_SHARE_MASK 0x07
+#define HDR_SD_SHARE_MASK (0x03 << HDR_SD_SHARE_SHIFT)
#define HDR_JD_SHARE_SHIFT 8
+#define HDR_JD_SHARE_MASK (0x07 << HDR_JD_SHARE_SHIFT)
#define HDR_SHARE_NEVER (0x00 << HDR_SD_SHARE_SHIFT)
#define HDR_SHARE_WAIT (0x01 << HDR_SD_SHARE_SHIFT)
@@ -235,7 +235,7 @@ struct sec4_sg_entry {
#define LDST_SRCDST_WORD_DECO_MATH2 (0x0a << LDST_SRCDST_SHIFT)
#define LDST_SRCDST_WORD_DECO_AAD_SZ (0x0b << LDST_SRCDST_SHIFT)
#define LDST_SRCDST_WORD_DECO_MATH3 (0x0b << LDST_SRCDST_SHIFT)
-#define LDST_SRCDST_WORD_CLASS1_ICV_SZ (0x0c << LDST_SRCDST_SHIFT)
+#define LDST_SRCDST_WORD_CLASS1_IV_SZ (0x0c << LDST_SRCDST_SHIFT)
#define LDST_SRCDST_WORD_ALTDS_CLASS1 (0x0f << LDST_SRCDST_SHIFT)
#define LDST_SRCDST_WORD_PKHA_A_SZ (0x10 << LDST_SRCDST_SHIFT)
#define LDST_SRCDST_WORD_PKHA_B_SZ (0x11 << LDST_SRCDST_SHIFT)
@@ -400,7 +400,7 @@ struct sec4_sg_entry {
#define FIFOST_TYPE_PKHA_N (0x08 << FIFOST_TYPE_SHIFT)
#define FIFOST_TYPE_PKHA_A (0x0c << FIFOST_TYPE_SHIFT)
#define FIFOST_TYPE_PKHA_B (0x0d << FIFOST_TYPE_SHIFT)
-#define FIFOST_TYPE_AF_SBOX_JKEK (0x10 << FIFOST_TYPE_SHIFT)
+#define FIFOST_TYPE_AF_SBOX_JKEK (0x20 << FIFOST_TYPE_SHIFT)
#define FIFOST_TYPE_AF_SBOX_TKEK (0x21 << FIFOST_TYPE_SHIFT)
#define FIFOST_TYPE_PKHA_E_JKEK (0x22 << FIFOST_TYPE_SHIFT)
#define FIFOST_TYPE_PKHA_E_TKEK (0x23 << FIFOST_TYPE_SHIFT)
@@ -1107,8 +1107,8 @@ struct sec4_sg_entry {
/* For non-protocol/alg-only op commands */
#define OP_ALG_TYPE_SHIFT 24
#define OP_ALG_TYPE_MASK (0x7 << OP_ALG_TYPE_SHIFT)
-#define OP_ALG_TYPE_CLASS1 2
-#define OP_ALG_TYPE_CLASS2 4
+#define OP_ALG_TYPE_CLASS1 (2 << OP_ALG_TYPE_SHIFT)
+#define OP_ALG_TYPE_CLASS2 (4 << OP_ALG_TYPE_SHIFT)
#define OP_ALG_ALGSEL_SHIFT 16
#define OP_ALG_ALGSEL_MASK (0xff << OP_ALG_ALGSEL_SHIFT)
@@ -1249,7 +1249,7 @@ struct sec4_sg_entry {
#define OP_ALG_PKMODE_MOD_PRIMALITY 0x00f
/* PKHA mode copy-memory functions */
-#define OP_ALG_PKMODE_SRC_REG_SHIFT 13
+#define OP_ALG_PKMODE_SRC_REG_SHIFT 17
#define OP_ALG_PKMODE_SRC_REG_MASK (7 << OP_ALG_PKMODE_SRC_REG_SHIFT)
#define OP_ALG_PKMODE_DST_REG_SHIFT 10
#define OP_ALG_PKMODE_DST_REG_MASK (7 << OP_ALG_PKMODE_DST_REG_SHIFT)
--
2.4.4
^ permalink raw reply related
* Re: [PATCH 6/8] block: add scalable completion tracking of requests
From: Jan Kara @ 2016-11-09 9:01 UTC (permalink / raw)
To: Jens Axboe; +Cc: Jan Kara, axboe, linux-kernel, linux-fsdevel, linux-block, hch
In-Reply-To: <cbd840e8-1807-5cf9-913b-bc62dbc7ac9e@fb.com>
On Tue 08-11-16 08:25:52, Jens Axboe wrote:
> On 11/08/2016 06:30 AM, Jan Kara wrote:
> >On Tue 01-11-16 15:08:49, Jens Axboe wrote:
> >>For legacy block, we simply track them in the request queue. For
> >>blk-mq, we track them on a per-sw queue basis, which we can then
> >>sum up through the hardware queues and finally to a per device
> >>state.
> >>
> >>The stats are tracked in, roughly, 0.1s interval windows.
> >>
> >>Add sysfs files to display the stats.
> >>
> >>Signed-off-by: Jens Axboe <axboe@fb.com>
> >
> >This patch looks mostly good to me but I have one concern: You track
> >statistics in a fixed 134ms window, stats get cleared at the beginning of
> >each window. Now this can interact with the writeback window and latency
> >settings which are dynamic and settable from userspace - so if the
> >writeback code observation window gets set larger than the stats window,
> >things become strange since you'll likely miss quite some observations
> >about read latencies. So I think you need to make sure stats window is
> >always larger than writeback window. Or actually, why do you have something
> >like stats window and don't leave clearing of statistics completely to the
> >writeback tracking code?
>
> That's a good point, and there actually used to be a comment to that
> effect in the code. I think the best solution here would be to make the
> stats code mask available somewhere, and allow a consumer of the stats
> to request a larger window.
>
> Similarly, we could make the stat window be driven by the consumer, as
> you suggest.
>
> Currently there are two pending submissions that depend on the stats
> code. One is this writeback series, and the other one is the hybrid
> polling code. The latter does not really care about the window size as
> such, since it has no monitoring window of its own, and it wants the
> auto-clearing as well.
>
> I don't mind working on additions for this, but I'd prefer if we could
> layer them on top of the existing series instead of respinning it.
> There's considerable test time on the existing patchset. Would that work
> for you? Especially collapsing the stats and wbt windows would require
> some re-architecting.
OK, that works for me. Actually, when thinking about this, I have one more
suggestion: Do we really want to expose the wbt window as a sysfs tunable?
I guess it is good for initial experiments but longer term having the wbt
window length be a function of target read latency might be better.
Generally you want the window length to be considerably larger than the
target latency but OTOH not too large so that the algorithm can react
reasonably quickly so that suggests it could really be autotuned (and we
scale the window anyway to adapt it to current situation).
> >Also as a side note - nobody currently uses the mean value of the
> >statistics. It may be faster to track just sum and count so that mean can
> >be computed on request which will be presumably much more rare than current
> >situation where we recompute the mean on each batch update. Actually, that
> >way you could get rid of the batching as well I assume.
>
> That could be opt-in as well. The poll code uses it. And fwiw, it is
> exposed through sysfs as well.
Yeah, my point was that just doing the division in response to sysfs read
or actual request to read the average is likely going to be less expensive
than having to do it on each batch completion (actually, you seem to have
that batching code only so that you don't have to do the division too
often). Whether my suggestion is right depends on how often polling code
actually needs to read the average...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: FAILED: patch "[PATCH] RAID10: ignore discard error" failed to apply to 4.4-stable tree
From: Greg KH @ 2016-11-09 9:01 UTC (permalink / raw)
To: shli, sitsofe; +Cc: stable
In-Reply-To: <147868192456246@kroah.com>
On Wed, Nov 09, 2016 at 09:58:44AM +0100, gregkh@linuxfoundation.org wrote:
>
> The patch below does not apply to the 4.4-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
Well, it applied, but it broke the build, so I dropped it.
thanks,
greg k-h
> ------------------ original commit in Linus's tree ------------------
>
> >From 579ed34f7b751b8add233cba4cf755258dbdd60a Mon Sep 17 00:00:00 2001
> From: Shaohua Li <shli@fb.com>
> Date: Thu, 6 Oct 2016 14:13:52 -0700
> Subject: [PATCH] RAID10: ignore discard error
>
> This is the counterpart of raid10 fix. If a write error occurs, raid10
> will try to rewrite the bio in small chunk size. If the rewrite fails,
> raid10 will record the error in bad block. narrow_write_error will
> always use WRITE for the bio, but actually it could be a discard. Since
> discard bio hasn't payload, write the bio will cause different issues.
> But discard error isn't fatal, we can safely ignore it. This is what
> this patch does.
>
> This issue should exist since discard is added, but only exposed with
> recent arbitrary bio size feature.
>
> Cc: Sitsofe Wheeler <sitsofe@gmail.com>
> Cc: stable@vger.kernel.org (v3.6)
> Signed-off-by: Shaohua Li <shli@fb.com>
>
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index be1a9fca3b2d..39fddda2fef2 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -447,6 +447,9 @@ static void raid10_end_write_request(struct bio *bio)
> struct r10conf *conf = r10_bio->mddev->private;
> int slot, repl;
> struct md_rdev *rdev = NULL;
> + bool discard_error;
> +
> + discard_error = bio->bi_error && bio_op(bio) == REQ_OP_DISCARD;
>
> dev = find_bio_disk(conf, r10_bio, bio, &slot, &repl);
>
> @@ -460,7 +463,7 @@ static void raid10_end_write_request(struct bio *bio)
> /*
> * this branch is our 'one mirror IO has finished' event handler:
> */
> - if (bio->bi_error) {
> + if (bio->bi_error && !discard_error) {
> if (repl)
> /* Never record new bad blocks to replacement,
> * just fail it.
> @@ -503,7 +506,7 @@ static void raid10_end_write_request(struct bio *bio)
> if (is_badblock(rdev,
> r10_bio->devs[slot].addr,
> r10_bio->sectors,
> - &first_bad, &bad_sectors)) {
> + &first_bad, &bad_sectors) && !discard_error) {
> bio_put(bio);
> if (repl)
> r10_bio->devs[slot].repl_bio = IO_MADE_GOOD;
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" 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
* [PATCH] rcu: Avoid unnecessary contention of rcu node lock
From: Byungchul Park @ 2016-11-09 8:57 UTC (permalink / raw)
To: paulmck, josh, rostedt, mathieu.desnoyers, jiangshanlai; +Cc: linux-kernel
It's unnecessary to try to print stacks of blocked tasks in the case
that ndetected == 0. Furthermore, calling rcu_print_detail_task_stall()
causes to acquire rnp locks as many times as the number of leaf nodes
plus one for root node. It's unnecessary at all in the case.
Signed-off-by: Byungchul Park <byungchul.park@lge.com>
---
kernel/rcu/tree.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 287f468..ab2f743 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1374,6 +1374,9 @@ static void print_other_cpu_stall(struct rcu_state *rsp, unsigned long gpnum)
(long)rsp->gpnum, (long)rsp->completed, totqlen);
if (ndetected) {
rcu_dump_cpu_stacks(rsp);
+
+ /* Complain about tasks blocking the grace period. */
+ rcu_print_detail_task_stall(rsp);
} else {
if (READ_ONCE(rsp->gpnum) != gpnum ||
READ_ONCE(rsp->completed) == gpnum) {
@@ -1390,9 +1393,6 @@ static void print_other_cpu_stall(struct rcu_state *rsp, unsigned long gpnum)
}
}
- /* Complain about tasks blocking the grace period. */
- rcu_print_detail_task_stall(rsp);
-
rcu_check_gp_kthread_starvation(rsp);
panic_on_rcu_stall();
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C
From: Wolfram Sang @ 2016-11-09 8:59 UTC (permalink / raw)
To: Simon Horman; +Cc: Wolfram Sang, linux-renesas-soc, linux-i2c
In-Reply-To: <20161109084406.GA22213@verge.net.au>
[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]
Hi Simon,
> I have tested these patches on alt, gose, lager and koelsch.
Wow, that was quick. Thank you!
> The switching part seems to work fine, in so far as my test script
> succeeds. However, it seems that some IP blocks are not able to handle
> this switching. In particular I needed to disable VIDEO_RCAR_VIN and
> REGULATOR_DA9210 to avoid errors shown in the logs below.
Yes. Probably we should activate the shiny new DEBUG_TEST_DRIVER_REMOVE
and if that passes, we should be safe.
> My suggestion is to drop the following patches until those problems
> can be sorted out, most likely via driver updates.
>
> ARM: dts: alt: use demuxer for I2C1
> ARM: dts: gose: use demuxer for I2C2
> ARM: dts: lager: use demuxer for IIC2/I2C2
> ARM: dts: lager: use demuxer for IIC3/I2C3
> ARM: dts: koelsch: use demuxer for I2C2
OK. I'll try to have a look at those drivers nonetheless, because
rebasing these patches is a bit of a hazzle once new i2c slaves were
added to the busses. But I'll juest resend the patches along with my
fixes if I really can find the time.
> I am not in a position to test silk or porter at this time.
> But by the same reasoning above I wonder if the following should
> be dropped for now.
>
> ARM: dts: gose: use demuxer for I2C2
I assume you mean 'porter' here.
> ARM: dts: silk: use demuxer for I2C1
Will you get access to these boards in the foreseeable future?
Thanks,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v2 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Baruch Siach @ 2016-11-09 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109081431.10115-2-romain.perier@free-electrons.com>
Hi Romain,
On Wed, Nov 09, 2016 at 09:14:29AM +0100, Romain Perier wrote:
> The Armada 3700 has two I2C controllers that is compliant with the I2C
> Bus Specificiation 2.1, supports multi-master and different bus speed:
> Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
> High speed mode (up to 3.4 Mhz).
>
> This IP block has a lot of similarity with the PXA, except some register
> offsets and bitfield. This commits adds a basic support for this I2C
> unit.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
[...]
> @@ -122,7 +131,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
> #define ICR_SADIE (1 << 13) /* slave address detected int enable */
> #define ICR_UR (1 << 14) /* unit reset */
> #define ICR_FM (1 << 15) /* fast mode */
> +#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
> #define ICR_HS (1 << 16) /* High Speed mode */
> +#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
> #define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
>
> #define ISR_RWM (1 << 0) /* read/write mode */
> @@ -193,6 +204,8 @@ struct pxa_i2c {
> unsigned char master_code;
> unsigned long rate;
> bool highmode_enter;
> + unsigned long fm_mask;
> + unsigned long hs_mask;
Do you really need 64bit for that?
baruch
> };
>
> #define _IBMR(i2c) ((i2c)->reg_ibmr)
> @@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
> writel(i2c->slave_addr, _ISAR(i2c));
>
> /* set control register values */
> - writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
> - writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
> + writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
> + writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
>
> #ifdef CONFIG_I2C_PXA_SLAVE
> dev_info(&i2c->adap.dev, "Enabling slave mode\n");
> @@ -1137,6 +1150,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
> { .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
> { .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
> { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
> + { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
> {}
> };
> MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
> @@ -1158,6 +1172,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
> i2c->use_pio = 1;
> if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
> i2c->fast_mode = 1;
> + if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
> + i2c->fm_mask = ICR_BUSMODE_FM;
> + i2c->hs_mask = ICR_BUSMODE_HS;
> + } else {
> + i2c->fm_mask = ICR_FM;
> + i2c->hs_mask = ICR_HS;
> + }
>
> *i2c_types = (enum pxa_i2c_types)(of_id->data);
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH v2 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Baruch Siach @ 2016-11-09 8:59 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Yahuda Yitschak, Jason Cooper,
Pawel Moll, Ian Campbell, Igal Liberman, Hanna Hawa, Omri Itach,
Nadav Haklai, Rob Herring, Andrew Lunn, Neta Zur Hershkovits,
Kumar Gala, Gregory Clement, Shadi Ammouri, Marcin Wojtas,
Thomas Petazzoni, linux-arm-kernel-IAPFreCvJWMP3drIcvDWNA
In-Reply-To: <20161109081431.10115-2-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Romain,
On Wed, Nov 09, 2016 at 09:14:29AM +0100, Romain Perier wrote:
> The Armada 3700 has two I2C controllers that is compliant with the I2C
> Bus Specificiation 2.1, supports multi-master and different bus speed:
> Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
> High speed mode (up to 3.4 Mhz).
>
> This IP block has a lot of similarity with the PXA, except some register
> offsets and bitfield. This commits adds a basic support for this I2C
> unit.
>
> Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[...]
> @@ -122,7 +131,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
> #define ICR_SADIE (1 << 13) /* slave address detected int enable */
> #define ICR_UR (1 << 14) /* unit reset */
> #define ICR_FM (1 << 15) /* fast mode */
> +#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
> #define ICR_HS (1 << 16) /* High Speed mode */
> +#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
> #define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
>
> #define ISR_RWM (1 << 0) /* read/write mode */
> @@ -193,6 +204,8 @@ struct pxa_i2c {
> unsigned char master_code;
> unsigned long rate;
> bool highmode_enter;
> + unsigned long fm_mask;
> + unsigned long hs_mask;
Do you really need 64bit for that?
baruch
> };
>
> #define _IBMR(i2c) ((i2c)->reg_ibmr)
> @@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
> writel(i2c->slave_addr, _ISAR(i2c));
>
> /* set control register values */
> - writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
> - writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
> + writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
> + writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
>
> #ifdef CONFIG_I2C_PXA_SLAVE
> dev_info(&i2c->adap.dev, "Enabling slave mode\n");
> @@ -1137,6 +1150,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
> { .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
> { .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
> { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
> + { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
> {}
> };
> MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
> @@ -1158,6 +1172,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
> i2c->use_pio = 1;
> if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
> i2c->fast_mode = 1;
> + if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
> + i2c->fm_mask = ICR_BUSMODE_FM;
> + i2c->hs_mask = ICR_BUSMODE_HS;
> + } else {
> + i2c->fm_mask = ICR_FM;
> + i2c->hs_mask = ICR_HS;
> + }
>
> *i2c_types = (enum pxa_i2c_types)(of_id->data);
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
From: Cornelia Huck @ 2016-11-09 8:58 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Peter Maydell, Michal Suchanek, QEMU Developers
In-Reply-To: <20161108201019.GM2378@var.home>
On Tue, 8 Nov 2016 21:10:19 +0100
Samuel Thibault <samuel.thibault@gnu.org> wrote:
> Cornelia Huck, on Tue 08 Nov 2016 12:34:49 +0100, wrote:
> > > diff --git a/configure b/configure
> > > index fd6f898..e200aa8 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
> > > curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
> > > curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
> > > else
> > > - curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
> > > + curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):-I/usr/include/ncursesw:"
> >
> > This arrives at
> >
> > curses_inc_list=":-I/usr/include/ncursesw:"
> >
> > which causes the parser below to start with an empty curses_inc (with :
> > as separator).
>
> Yes, this is expected.
>
> > configure fails as before (with -Werror; passes without).
>
> Ah!
> So are you getting the following message?
>
> “
> configure test passed without -Werror but failed with -Werror.
> This is probably a bug in the configure script. The failing command
> will be at the bottom of config.log.
> You can run configure with --disable-werror to bypass this check.
> ”
>
> If so, you should really have said it, I was really wondering how
> configure could just stopping in your case. That does explain things
> indeed.
I said so in my very first mail for the issue... appears I was unclear.
>
> Could you try the attached patch? It should be able to really fail
> without Werror too.
With your patch, configure runs through and detects curses=no. Not sure
that's correct, though: SLES12SP1 _does_ have curses, but not a .pc
file for ncursesw. I don't know enough about curses to say whether it
should be that way...
^ permalink raw reply
* FAILED: patch "[PATCH] RAID10: ignore discard error" failed to apply to 4.4-stable tree
From: gregkh @ 2016-11-09 8:58 UTC (permalink / raw)
To: shli, sitsofe; +Cc: stable
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 579ed34f7b751b8add233cba4cf755258dbdd60a Mon Sep 17 00:00:00 2001
From: Shaohua Li <shli@fb.com>
Date: Thu, 6 Oct 2016 14:13:52 -0700
Subject: [PATCH] RAID10: ignore discard error
This is the counterpart of raid10 fix. If a write error occurs, raid10
will try to rewrite the bio in small chunk size. If the rewrite fails,
raid10 will record the error in bad block. narrow_write_error will
always use WRITE for the bio, but actually it could be a discard. Since
discard bio hasn't payload, write the bio will cause different issues.
But discard error isn't fatal, we can safely ignore it. This is what
this patch does.
This issue should exist since discard is added, but only exposed with
recent arbitrary bio size feature.
Cc: Sitsofe Wheeler <sitsofe@gmail.com>
Cc: stable@vger.kernel.org (v3.6)
Signed-off-by: Shaohua Li <shli@fb.com>
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index be1a9fca3b2d..39fddda2fef2 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -447,6 +447,9 @@ static void raid10_end_write_request(struct bio *bio)
struct r10conf *conf = r10_bio->mddev->private;
int slot, repl;
struct md_rdev *rdev = NULL;
+ bool discard_error;
+
+ discard_error = bio->bi_error && bio_op(bio) == REQ_OP_DISCARD;
dev = find_bio_disk(conf, r10_bio, bio, &slot, &repl);
@@ -460,7 +463,7 @@ static void raid10_end_write_request(struct bio *bio)
/*
* this branch is our 'one mirror IO has finished' event handler:
*/
- if (bio->bi_error) {
+ if (bio->bi_error && !discard_error) {
if (repl)
/* Never record new bad blocks to replacement,
* just fail it.
@@ -503,7 +506,7 @@ static void raid10_end_write_request(struct bio *bio)
if (is_badblock(rdev,
r10_bio->devs[slot].addr,
r10_bio->sectors,
- &first_bad, &bad_sectors)) {
+ &first_bad, &bad_sectors) && !discard_error) {
bio_put(bio);
if (repl)
r10_bio->devs[slot].repl_bio = IO_MADE_GOOD;
^ permalink raw reply related
* [PATCH V4 1/2] PCI: hisi: Add ECAM support for devices that are not RC
From: Dongdong Liu @ 2016-11-09 9:14 UTC (permalink / raw)
To: helgaas, arnd, rafael, Lorenzo.Pieralisi, tn, wangzhou1,
pratyush.anand
Cc: linux-pci, linux-acpi, linux-kernel, jcm, liudongdong3,
gabriele.paoloni, charles.chenxin, hanjun.guo, linuxarm
In-Reply-To: <1478682897-119874-1-git-send-email-liudongdong3@huawei.com>
This patch modifies the current Hip05/Hip06 PCIe host
controller driver to add support for 'almost ECAM'
compliant platforms. Some controllers are ECAM compliant
for all the devices of the hierarchy except the root
complex; this patch adds support for such controllers.
This is needed in preparation for the ACPI based driver
to allow both DT and ACPI drivers to use the same BIOS
(that configure the Designware iATUs).
This commit doesn't break backward compatibility with
previous non-ECAM platforms.
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
---
.../devicetree/bindings/pci/hisilicon-pcie.txt | 15 +++++---
drivers/pci/host/Kconfig | 4 +-
drivers/pci/host/pcie-designware.c | 4 +-
drivers/pci/host/pcie-designware.h | 2 +
drivers/pci/host/pcie-hisi.c | 45 ++++++++++++++++++++++
5 files changed, 60 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
index 59c2f47..87a597a 100644
--- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -9,10 +9,13 @@ Additional properties are described here:
Required properties
- compatible: Should contain "hisilicon,hip05-pcie" or "hisilicon,hip06-pcie".
-- reg: Should contain rc_dbi, config registers location and length.
-- reg-names: Must include the following entries:
+- reg: Should contain rc_dbi and either config or ecam-cfg registers
+ location and length (it depends on the platform BIOS).
+- reg-names: Must include
"rc_dbi": controller configuration registers;
- "config": PCIe configuration space registers.
+ and one of the following entries:
+ "config": PCIe configuration space registers for non-ECAM platforms.
+ "ecam-cfg": PCIe configuration space registers for ECAM platforms
- msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts.
- port-id: Should be 0, 1, 2 or 3.
@@ -23,8 +26,10 @@ Optional properties:
Hip05 Example (note that Hip06 is the same except compatible):
pcie@0xb0080000 {
compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
- reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
- reg-names = "rc_dbi", "config";
+ reg = <0 0xb0080000 0 0x10000>,
+ <0x220 0x00000000 0 0x2000>
+ /* or <0x220 0x00100000 0 0x0f00000> for ecam-cfg*/;
+ reg-names = "rc_dbi", "config" /* or "ecam-cfg" */;
bus-range = <0 15>;
msi-parent = <&its_pcie>;
#address-cells = <3>;
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d7e7c0a..ae98644 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -219,13 +219,13 @@ config PCIE_ALTERA_MSI
config PCI_HISI
depends on OF && ARM64
- bool "HiSilicon Hip05 and Hip06 SoCs PCIe controllers"
+ bool "HiSilicon Hip05 and Hip06 and Hip07 SoCs PCIe controllers"
depends on PCI_MSI_IRQ_DOMAIN
select PCIEPORTBUS
select PCIE_DW
help
Say Y here if you want PCIe controller support on HiSilicon
- Hip05 and Hip06 SoCs
+ Hip05 and Hip06 and Hip07 SoCs
config PCIE_QCOM
bool "Qualcomm PCIe controller"
diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 035f50c..da11644 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -101,8 +101,6 @@
#define PCIE_PHY_DEBUG_R1_LINK_UP (0x1 << 4)
#define PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING (0x1 << 29)
-static struct pci_ops dw_pcie_ops;
-
int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
{
if ((uintptr_t)addr & (size - 1)) {
@@ -800,7 +798,7 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
return dw_pcie_wr_other_conf(pp, bus, devfn, where, size, val);
}
-static struct pci_ops dw_pcie_ops = {
+struct pci_ops dw_pcie_ops = {
.read = dw_pcie_rd_conf,
.write = dw_pcie_wr_conf,
};
diff --git a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
index a567ea2..30d228a 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -83,4 +83,6 @@ struct pcie_host_ops {
void dw_pcie_setup_rc(struct pcie_port *pp);
int dw_pcie_host_init(struct pcie_port *pp);
+extern struct pci_ops dw_pcie_ops;
+
#endif /* _PCIE_DESIGNWARE_H */
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 56154c2..555c964 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -43,6 +43,34 @@ struct hisi_pcie {
struct pcie_soc_ops *soc_ops;
};
+static inline int hisi_rd_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
+ unsigned int devfn, int where, int size,
+ u32 *value)
+{
+ return pci_generic_config_read(bus, devfn, where, size, value);
+}
+
+static inline int hisi_wr_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
+ unsigned int devfn, int where, int size,
+ u32 value)
+{
+ return pci_generic_config_write(bus, devfn, where, size, value);
+}
+
+static void __iomem *hisi_pci_map_cfg_bus_cam(struct pci_bus *bus,
+ unsigned int devfn,
+ int where)
+{
+ void __iomem *addr;
+ struct pcie_port *pp = bus->sysdata;
+
+ addr = pp->va_cfg1_base - (pp->busn->start << 20) +
+ ((bus->number << 20) | (devfn << 12)) +
+ where;
+
+ return addr;
+}
+
/* HipXX PCIe host only supports 32-bit config access */
static int hisi_pcie_cfg_read(struct pcie_port *pp, int where, int size,
u32 *val)
@@ -190,6 +218,23 @@ static int hisi_pcie_probe(struct platform_device *pdev)
return PTR_ERR(pp->dbi_base);
}
+ reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam-cfg");
+ if (reg) {
+ /* ECAM driver version */
+ hisi_pcie->pp.va_cfg0_base =
+ devm_ioremap_resource(&pdev->dev, reg);
+ if (IS_ERR(hisi_pcie->pp.va_cfg0_base)) {
+ dev_err(pp->dev, "cannot get ecam-cfg\n");
+ return PTR_ERR(hisi_pcie->pp.va_cfg0_base);
+ }
+ hisi_pcie->pp.va_cfg1_base = hisi_pcie->pp.va_cfg0_base;
+
+ dw_pcie_ops.map_bus = hisi_pci_map_cfg_bus_cam;
+
+ hisi_pcie_host_ops.rd_other_conf = hisi_rd_ecam_conf;
+ hisi_pcie_host_ops.wr_other_conf = hisi_wr_ecam_conf;
+ }
+
ret = hisi_add_pcie_port(hisi_pcie, pdev);
if (ret)
return ret;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 0/2] Add ACPI support for HiSilicon SoCs Host Controllers
From: Dongdong Liu @ 2016-11-09 9:14 UTC (permalink / raw)
To: helgaas, arnd, rafael, Lorenzo.Pieralisi, tn, wangzhou1,
pratyush.anand
Cc: linux-pci, linux-acpi, linux-kernel, jcm, liudongdong3,
gabriele.paoloni, charles.chenxin, hanjun.guo, linuxarm
This patchset adds ACPI support for the HiSilicon Hip05/Hip06/Hip07 SoC
PCIe controllers.
The two patches respectively:
- rework the current HiSilicon driver to add support for ECAM
platforms(not RC).
- adds the HiSilicon ACPI specific quirks.
This patchset is based on branch pci/ecam-v6
It can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git(pci/ecam-v6)
v3 -> v4:
- rebase on pci/ecam-v6.
- delete the unnecessary link_up check code.
v2 -> v3:
- rebase against 4.9-rc1 and add Tomasz quirks V6 pathcset.
- obtain rc base addresses from PNP0C02 as subdevice of PNP0A03 instead of
hardcode the addresses.
- modify hisi_pcie_acpi_rd_conf/hisi_pcie_acpi_wr_conf() according to
Arnd comments.
v1 -> v2:
- rebase against Tomasz RFC V5 quirk mechanism
- add ACPI support for the HiSilicon Hip07 SoC PCIe controllers
Dongdong Liu (2):
PCI: hisi: Add ECAM support for devices that are not RC
PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers
.../devicetree/bindings/pci/hisilicon-pcie.txt | 15 +-
MAINTAINERS | 1 +
drivers/acpi/pci_mcfg.c | 13 ++
drivers/pci/host/Kconfig | 12 +-
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-designware.c | 4 +-
drivers/pci/host/pcie-designware.h | 2 +
drivers/pci/host/pcie-hisi-acpi.c | 157 +++++++++++++++++++++
drivers/pci/host/pcie-hisi.c | 45 ++++++
include/linux/pci-ecam.h | 5 +
10 files changed, 245 insertions(+), 10 deletions(-)
create mode 100644 drivers/pci/host/pcie-hisi-acpi.c
--
1.9.1
^ permalink raw reply
* Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C
From: Geert Uytterhoeven @ 2016-11-09 8:55 UTC (permalink / raw)
To: Simon Horman; +Cc: Wolfram Sang, Linux-Renesas, Linux I2C
In-Reply-To: <20161109084406.GA22213@verge.net.au>
Hi Simon,
On Wed, Nov 9, 2016 at 9:44 AM, Simon Horman <horms@verge.net.au> wrote:
> I am not in a position to test silk or porter at this time.
FWIW, Magnus has a Porter in his farm.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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.