* [PATCH 6/9] media: cedrus: Add ops structure
From: Paul Kocialkowski @ 2018-06-21 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613140714.1686-7-maxime.ripard@bootlin.com>
Hi,
On Wed, 2018-06-13 at 16:07 +0200, Maxime Ripard wrote:
> In order to increase the number of codecs supported, we need to decouple
> the MPEG2 only code that was there up until now and turn it into something
> a bit more generic.
>
> Do that by introducing an intermediate ops structure that would need to be
> filled by each supported codec. Start by implementing in that structure the
> setup and trigger hooks that are currently the only functions being
> implemented by codecs support.
>
> To do so, we need to store the current codec in use, which we do at
> start_streaming time.
With the comments below taken in account, this is:
Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../platform/sunxi/cedrus/sunxi_cedrus.c | 2 ++
> .../sunxi/cedrus/sunxi_cedrus_common.h | 11 +++++++
> .../platform/sunxi/cedrus/sunxi_cedrus_dec.c | 10 +++---
> .../sunxi/cedrus/sunxi_cedrus_mpeg2.c | 11 +++++--
> .../sunxi/cedrus/sunxi_cedrus_mpeg2.h | 33 -------------------
> .../sunxi/cedrus/sunxi_cedrus_video.c | 17 +++++++++-
> 6 files changed, 42 insertions(+), 42 deletions(-)
> delete mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_mpeg2.h
>
> diff --git a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus.c b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus.c
> index ccd41d9a3e41..bc80480f5dfd 100644
> --- a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus.c
> +++ b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus.c
> @@ -244,6 +244,8 @@ static int sunxi_cedrus_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + dev->dec_ops[SUNXI_CEDRUS_CODEC_MPEG2] = &sunxi_cedrus_dec_ops_mpeg2;
> +
> ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev);
> if (ret)
> goto unreg_media;
> diff --git a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_common.h b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_common.h
> index a5f83c452006..c2e2c92d103b 100644
> --- a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_common.h
> +++ b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_common.h
> @@ -75,6 +75,7 @@ struct sunxi_cedrus_ctx {
> struct v4l2_pix_format_mplane src_fmt;
> struct sunxi_cedrus_fmt *vpu_dst_fmt;
> struct v4l2_pix_format_mplane dst_fmt;
> + enum sunxi_cedrus_codec current_codec;
Nit: for consistency with the way things are named, "codec_current"
probably makes more sense.
IMO using the natural English order is fine for temporary variables, but
less so for variables used in common parts like structures. This allows
seeing "_" as a logical hierarchical delimiter that automatically makes
us end up with consistent prefixes that can easily be grepped for and
derived.
But that's just my 2 cents, it's really not a big deal, especially in
this case!
> struct v4l2_ctrl_handler hdl;
> struct v4l2_ctrl *ctrls[SUNXI_CEDRUS_CTRL_MAX];
> @@ -107,6 +108,14 @@ struct sunxi_cedrus_buffer *vb2_to_cedrus_buffer(const struct vb2_buffer *p)
> return vb2_v4l2_to_cedrus_buffer(to_vb2_v4l2_buffer(p));
> }
>
> +struct sunxi_cedrus_dec_ops {
> + void (*setup)(struct sunxi_cedrus_ctx *ctx,
> + struct sunxi_cedrus_run *run);
> + void (*trigger)(struct sunxi_cedrus_ctx *ctx);
By the way, are we sure that these functions won't ever fail?
I think this is the case for MPEG2 (there is virtually nothing to check
for errors) but perhaps it's different for H264.
> +};
> +
> +extern struct sunxi_cedrus_dec_ops sunxi_cedrus_dec_ops_mpeg2;
> +
> struct sunxi_cedrus_dev {
> struct v4l2_device v4l2_dev;
> struct video_device vfd;
> @@ -130,6 +139,8 @@ struct sunxi_cedrus_dev {
> struct reset_control *rstc;
>
> struct regmap *syscon;
> +
> + struct sunxi_cedrus_dec_ops *dec_ops[SUNXI_CEDRUS_CODEC_LAST];
> };
>
> static inline void sunxi_cedrus_write(struct sunxi_cedrus_dev *dev,
> diff --git a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_dec.c b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_dec.c
> index f274408ab5a7..5e552fa05274 100644
> --- a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_dec.c
> +++ b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_dec.c
> @@ -28,7 +28,6 @@
> #include <media/v4l2-mem2mem.h>
>
> #include "sunxi_cedrus_common.h"
> -#include "sunxi_cedrus_mpeg2.h"
> #include "sunxi_cedrus_dec.h"
> #include "sunxi_cedrus_hw.h"
>
> @@ -77,6 +76,7 @@ void sunxi_cedrus_device_work(struct work_struct *work)
> void sunxi_cedrus_device_run(void *priv)
> {
> struct sunxi_cedrus_ctx *ctx = priv;
> + struct sunxi_cedrus_dev *dev = ctx->dev;
> struct sunxi_cedrus_run run = { 0 };
> struct media_request *src_req, *dst_req;
> unsigned long flags;
> @@ -120,8 +120,6 @@ void sunxi_cedrus_device_run(void *priv)
> case V4L2_PIX_FMT_MPEG2_FRAME:
> CHECK_CONTROL(ctx, SUNXI_CEDRUS_CTRL_DEC_MPEG2_FRAME_HDR);
> run.mpeg2.hdr = get_ctrl_ptr(ctx, SUNXI_CEDRUS_CTRL_DEC_MPEG2_FRAME_HDR);
> - sunxi_cedrus_mpeg2_setup(ctx, &run);
> -
> break;
>
> default:
> @@ -129,6 +127,9 @@ void sunxi_cedrus_device_run(void *priv)
> }
> #undef CHECK_CONTROL
>
> + if (!ctx->job_abort)
> + dev->dec_ops[ctx->current_codec]->setup(ctx, &run);
> +
> unlock_complete:
> spin_unlock_irqrestore(&ctx->dev->irq_lock, flags);
>
> @@ -143,8 +144,7 @@ void sunxi_cedrus_device_run(void *priv)
> spin_lock_irqsave(&ctx->dev->irq_lock, flags);
>
> if (!ctx->job_abort) {
> - if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_MPEG2_FRAME)
> - sunxi_cedrus_mpeg2_trigger(ctx);
> + dev->dec_ops[ctx->current_codec]->trigger(ctx);
> } else {
> v4l2_m2m_buf_done(run.src, VB2_BUF_STATE_ERROR);
> v4l2_m2m_buf_done(run.dst, VB2_BUF_STATE_ERROR);
> diff --git a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_mpeg2.c b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_mpeg2.c
> index d1d7a3cfce0d..e25075bb5779 100644
> --- a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_mpeg2.c
> +++ b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_mpeg2.c
> @@ -52,8 +52,8 @@ static const u8 mpeg_default_non_intra_quant[64] = {
>
> #define m_niq(i) ((i << 8) | mpeg_default_non_intra_quant[i])
>
> -void sunxi_cedrus_mpeg2_setup(struct sunxi_cedrus_ctx *ctx,
> - struct sunxi_cedrus_run *run)
> +static void sunxi_cedrus_mpeg2_setup(struct sunxi_cedrus_ctx *ctx,
> + struct sunxi_cedrus_run *run)
> {
> struct sunxi_cedrus_dev *dev = ctx->dev;
> const struct v4l2_ctrl_mpeg2_frame_hdr *frame_hdr = run->mpeg2.hdr;
> @@ -148,9 +148,14 @@ void sunxi_cedrus_mpeg2_setup(struct sunxi_cedrus_ctx *ctx,
> sunxi_cedrus_write(dev, src_buf_addr + VBV_SIZE - 1, VE_MPEG_VLD_END);
> }
>
> -void sunxi_cedrus_mpeg2_trigger(struct sunxi_cedrus_ctx *ctx)
> +static void sunxi_cedrus_mpeg2_trigger(struct sunxi_cedrus_ctx *ctx)
> {
> struct sunxi_cedrus_dev *dev = ctx->dev;
>
> sunxi_cedrus_write(dev, VE_TRIG_MPEG2, VE_MPEG_TRIGGER);
> }
> +
> +struct sunxi_cedrus_dec_ops sunxi_cedrus_dec_ops_mpeg2 = {
> + .setup = sunxi_cedrus_mpeg2_setup,
> + .trigger = sunxi_cedrus_mpeg2_trigger,
> +};
> diff --git a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_mpeg2.h b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_mpeg2.h
> deleted file mode 100644
> index 4c380becfa1a..000000000000
> --- a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_mpeg2.h
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/*
> - * Sunxi-Cedrus VPU driver
> - *
> - * Copyright (C) 2018 Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> - * Copyright (C) 2016 Florent Revest <florent.revest@free-electrons.com>
> - *
> - * Based on the vim2m driver, that is:
> - *
> - * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
> - * Pawel Osciak, <pawel@osciak.com>
> - * Marek Szyprowski, <m.szyprowski@samsung.com>
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - */
> -
> -#ifndef _SUNXI_CEDRUS_MPEG2_H_
> -#define _SUNXI_CEDRUS_MPEG2_H_
> -
> -struct sunxi_cedrus_ctx;
> -struct sunxi_cedrus_run;
> -
> -void sunxi_cedrus_mpeg2_setup(struct sunxi_cedrus_ctx *ctx,
> - struct sunxi_cedrus_run *run);
> -void sunxi_cedrus_mpeg2_trigger(struct sunxi_cedrus_ctx *ctx);
> -
> -#endif
> diff --git a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_video.c b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_video.c
> index 089abfe6bfeb..fb7b081a5bb7 100644
> --- a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_video.c
> +++ b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_video.c
> @@ -28,7 +28,6 @@
> #include <media/v4l2-mem2mem.h>
>
> #include "sunxi_cedrus_common.h"
> -#include "sunxi_cedrus_mpeg2.h"
> #include "sunxi_cedrus_dec.h"
> #include "sunxi_cedrus_hw.h"
>
> @@ -414,6 +413,21 @@ static int sunxi_cedrus_buf_prepare(struct vb2_buffer *vb)
> return 0;
> }
>
> +static int sunxi_cedrus_start_streaming(struct vb2_queue *q, unsigned int count)
> +{
> + struct sunxi_cedrus_ctx *ctx = vb2_get_drv_priv(q);
> +
> + switch (ctx->vpu_src_fmt->fourcc) {
> + case V4L2_PIX_FMT_MPEG2_FRAME:
> + ctx->current_codec = SUNXI_CEDRUS_CODEC_MPEG2;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static void sunxi_cedrus_stop_streaming(struct vb2_queue *q)
> {
> struct sunxi_cedrus_ctx *ctx = vb2_get_drv_priv(q);
> @@ -462,6 +476,7 @@ static struct vb2_ops sunxi_cedrus_qops = {
> .buf_cleanup = sunxi_cedrus_buf_cleanup,
> .buf_queue = sunxi_cedrus_buf_queue,
> .buf_request_complete = sunxi_cedrus_buf_request_complete,
> + .start_streaming = sunxi_cedrus_start_streaming,
> .stop_streaming = sunxi_cedrus_stop_streaming,
> .wait_prepare = vb2_ops_wait_prepare,
> .wait_finish = vb2_ops_wait_finish,
--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180621/d52423c9/attachment.sig>
^ permalink raw reply
* KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform.
From: Wei Xu @ 2018-06-21 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180621091850.GA22505@arm.com>
Hi Will,
On 2018/6/21 10:18, Will Deacon wrote:
> On Thu, Jun 21, 2018 at 09:38:53AM +0100, James Morse wrote:
>> On 20/06/18 17:25, Wei Xu wrote:
>>> [ 0.042421] Insufficient stack space to handle exception!
>>> [ 0.042423] ESR: 0x96000046 -- DABT (current EL)
>>> [ 0.043730] FAR: 0xffff0000093a80e0
>>> [ 0.044714] Task stack: [0xffff0000093a8000..0xffff0000093ac000]
>>
>> This was a level 2 translation fault on a write, to an address that is within
>> the stack....
>>
>>
>>> [ 0.051113] IRQ stack: [0xffff000008000000..0xffff000008004000]
>>> [ 0.057610] Overflow stack: [0xffff80003efce2f0..0xffff80003efcf2f0]
>>> [ 0.064003] CPU: 0 PID: 12 Comm: migration/0 Not tainted
>>> 4.17.0-45865-g2b31fe7-dirty #10
>>> [ 0.072201] Hardware name: linux,dummy-virt (DT)
>>
>>> [ 0.076797] pstate: 604003c5 (nZCv DAIF +PAN -UAO)
>>> [ 0.081727] pc : el1_sync+0x0/0xb0
>>
>> ... from the vectors.
>>
>>
>>> [ 0.085217] lr : kpti_install_ng_mappings+0x120/0x214
>>
>> What I think is happening is: we come out of the kpti idmap with the stack
>> unmapped. Shortly after we access the stack, which faults. el1_sync faults as
>> well when it tries to push the registers to the stack, and we keep going until
>> we overflow the stack.
>>
>> I can't reproduce this with kvmtool or qemu in the model.
>
> Hmm, one thing that occurs to me is that the kpti_install_ng_mappings()
> code leaves the nG bit set in table entries, which is actually IGNORED in
> the architecture.
>
> Wei -- does the diff below help at all? Make sure you disable CONFIG_KASAN,
> otherwise your kernel will take an age to boot.
Yes, amazing! This patch resolved the issue.
I have tested 50 times and can not reproduce the issue any more.
Could you please tell more why this patch works?
Thanks!
Best Regards,
Wei
>
> Will
>
> --->8
>
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 5f9a73a4452c..70d9e98467ca 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -272,8 +272,8 @@ ENTRY(idmap_kpti_install_ng_mappings)
> add end_pgdp, cur_pgdp, #(PTRS_PER_PGD * 8)
> do_pgd: __idmap_kpti_get_pgtable_ent pgd
> tbnz pgd, #1, walk_puds
> -next_pgd:
> __idmap_kpti_put_pgtable_ent_ng pgd
> +next_pgd:
> skip_pgd:
> add cur_pgdp, cur_pgdp, #8
> cmp cur_pgdp, end_pgdp
> @@ -302,8 +302,8 @@ walk_puds:
> add end_pudp, cur_pudp, #(PTRS_PER_PUD * 8)
> do_pud: __idmap_kpti_get_pgtable_ent pud
> tbnz pud, #1, walk_pmds
> -next_pud:
> __idmap_kpti_put_pgtable_ent_ng pud
> +next_pud:
> skip_pud:
> add cur_pudp, cur_pudp, 8
> cmp cur_pudp, end_pudp
> @@ -323,8 +323,8 @@ walk_pmds:
> add end_pmdp, cur_pmdp, #(PTRS_PER_PMD * 8)
> do_pmd: __idmap_kpti_get_pgtable_ent pmd
> tbnz pmd, #1, walk_ptes
> -next_pmd:
> __idmap_kpti_put_pgtable_ent_ng pmd
> +next_pmd:
> skip_pmd:
> add cur_pmdp, cur_pmdp, #8
> cmp cur_pmdp, end_pmdp
>
> .
>
^ permalink raw reply
* [PATCH 3/3] arm64: IPI each CPU after invalidating the I-cache for kernel mappings
From: James Morse @ 2018-06-21 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619165019.GU13984@arm.com>
Hi Mark, Will
On 19/06/18 17:50, Will Deacon wrote:
> On Tue, Jun 19, 2018 at 02:55:28PM +0100, Mark Rutland wrote:
>> On Tue, Jun 19, 2018 at 01:48:15PM +0100, Will Deacon wrote:
>>> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
>>> index 816d03c4c913..4cc41864f277 100644
>>> --- a/arch/arm64/kernel/insn.c
>>> +++ b/arch/arm64/kernel/insn.c
>>> @@ -249,7 +249,6 @@ static int __kprobes aarch64_insn_patch_text_cb(void *arg)
>>> } else {
>>> while (atomic_read(&pp->cpu_count) <= num_online_cpus())
>>> cpu_relax();
>>> - isb();
>>> }
>>
>> Something seems amiss here.
>>
>> We call __apply_alternatives_multi_stop() via stop_machine(), and I
>> thought that ensured that all CPUs had IRQs masked.
>>
>> If so, the IPI from flush_icache_range() will deadlock.
>>
>> If not, we can take IRQs, and execute potentially patched code.
>
> Yes, I think you're right, and I think this only applies to kprobes (since
> it patches arbitrary instructions and requires the stop_machine()). However,
> I think that highlights another issue, which is that the "nosync" patching
> cases as used by things like jump_labels are still going to want this IPI,
> so actually the fastpath stuff can all be ripped out. ftrace can probably
> be left as-is, since I doubt it's critical that new CPUs immediately see
> dynamic tracepoints.
>
> I'll cook a patch sorting this out and include it in v2.
>
>> I think there's also an existing problem here. Even if with have IRQs
>> masked, we could take SDEI events (or GICv3 psudeo-NMIs, once we have
>> those). I don't know how we can manage those.
>
> I guess there are just some places where we can't deal with an SDEI event.
> That said, it's fine as long as the SDEI path is careful about what it runs
> (and SDEI is masked until the worst of the patching is over during boot).
Yup, its setup as late as possible, so cpufeature stuff should be safe.
I think break-pointing code we expect to run in_nmi() is a disaster waiting to
happen. e.g. taking an SDEI-event out of a guest, we run the handler before KVM
does it's guest exit, so if you tread on a breakpoint KVM's el2_sync is going to
bring the machine down.
The SDEI stuff has __kprobes all over it, I probably need to add some more
'notrace'.
I think forbidding code-patch on NMI code-regions is the easiest thing to do.
If this is something we needed to support, we could get stop_machine() to mask
SDEI and GIC psuedo_NMIs as part of its work. We could mask SError and disable
debug exceptions while we're at it.
Thanks,
James
^ permalink raw reply
* [RFC PATCH 0/2] New QuadSPI driver for Atmel SAMA5D2
From: Piotr Bugalski @ 2018-06-21 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180620165438.39608554@bbrezillon>
Hi Boris,
Thank you very much for quick response.
On Wed, 20 Jun 2018, Boris Brezillon wrote:
> Hi Piotr,
>
> On Mon, 18 Jun 2018 18:21:22 +0200
> Piotr Bugalski <bugalski.piotr@gmail.com> wrote:
>
>> Hello,
>>
>> Atmel SAMA5D2 is equipped with two QSPI interfaces. These interfaces can
>> work as in SPI-compatible mode or use two / four lines to improve
>> communication speed. At the moment there is QSPI driver strongly tied to
>> NOR-flash memory and MTD subsystem.
>> Intention of this change is to provide new driver which will not be tied
>> to MTD and allows using QSPI with NAND-flash memory or other peripherals
>> New spi-mem API provides abstraction layer which can disconnect QSPI
>> from MTD. This driver doesn't support regular SPI interface, it should
>> be used with spi-mem interface only.
>
> Glad to see that people are starting to convert their SPI NOR
> controller drivers to the SPI mem approach.
>
>> Unfortunately SAMA5D2 hardware by default supports only NOR-flash
>> memory. It allows 24- and 32-bit addressing while NAND-flash requires
>> 16-bit long. To workaround hardware limitation driver is a bit more
>> complicated.
>>
>> Request to spi-mem contains three fiels: opcode (command), address,
>> dummy bytes. SAMA5D2 QSPI hardware supports opcode, address, dummy and
>> option byte where address field can only be 24- or 32- bytes long.
>> Handling 8-bits long addresses is done using option field. For 16-bits
>> address behaviour depends of number of requested dummy bits. If there
>> are 8 or more dummy cycles, address is shifted and sent with first dummy
>> byte. Otherwise opcode is disabled and first byte of address contains
>> command opcode (works only if opcode and address use the same buswidth).
>> The limitation is when 16-bit address is used without enough dummy
>> cycles and opcode is using different buswidth than address. Other modes
>> are supported with described workaround.
>>
>> It looks like hardware has some limitation in performance. The same issue
>> exists in current QSPI driver (MTD/nor-flash) and soft-pack (bare-metal
>> library from Atmel). Without using DMA read speed is much worse than
>> maximum bandwidth (efficiency 30-40%). Any help with performance
>> improvement is highly welcome, especially for NAND-flash memories which
>> offers higher capacity than NOR-flash used with previous driver.
>>
>> Best Regards,
>> Piotr
>>
>> Piotr Bugalski (2):
>> spi: Add QuadSPI driver for Atmel SAMA5D2
>> dt-bindings: spi: QuadSPI driver for Atmel SAMA5D2 documentation
>>
>> .../devicetree/bindings/spi/spi_atmel-qspi.txt | 41 ++
>> drivers/spi/Kconfig | 9 +
>> drivers/spi/Makefile | 1 +
>> drivers/spi/spi-atmel-qspi.c | 480 +++++++++++++++++++++
>
> I'd like a solution where we remove the old driver. I definitely don't
> want to have both in parallel. Did you test the new driver with a SPI
> NOR to check if it still works correctly? If you did, then I'd suggest
> that you add a patch updating defconfigs where the SPI_ATMEL_QUADSPI is
> selected and another patch removing the old driver.
>
I misunderstood a bit your idea. My main concern was NAND-flash with
QSPI interface and I expected original nor-flash driver to stay
untouched - at least now. However idea of replacement older driver
with spi-mem approach makes a lot of sense to me.
I'll test nor-flash with new driver first, it should work but I prefer
to be sure. In next version I'll follow your suggestion and replace
old nor-flash driver.
>> 4 files changed, 531 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
>
> This should be a simple mv from
> Documentation/devicetree/bindings/mtd/atmel-quadspi.txt to
> Documentation/devicetree/bindings/spi/spi-atmel-qspi.txt
>
>> create mode 100644 drivers/spi/spi-atmel-qspi.c
>>
>
> Thanks,
>
> Boris
>
Thank you for comments,
Piotr
^ permalink raw reply
* [PATCH v7 0/4] ARM: davinci: complete the conversion to using the reset framework
From: Sekhar Nori @ 2018-06-21 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180621073706.22812-1-brgl@bgdev.pl>
Hi Bartosz,
On Thursday 21 June 2018 01:07 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> These are the remaining patches that still need to be merged in order
> to complete the conversion of the davinci dsp driver to using the reset
> framework.
>
> They apply on top of v4.18-rc1 with David Lechner's remaining patches
> merged.
Series looks good to me.
To preserve bisect, shouldn't the order of applying be patch #3, #4, #1
and #2 ?
Given the dependencies and to preserve bisect its easiest if I take the
series with acks from remoteproc and clock maintainers.
Open to other suggestions as well.
Thanks,
Sekhar
^ permalink raw reply
* KVM guest sometimes failed to boot because of kernel stack overflow if KPTI is enabled on a hisilicon ARM64 platform.
From: Will Deacon @ 2018-06-21 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5B2B7A84.8090309@hisilicon.com>
Hi Wei,
On Thu, Jun 21, 2018 at 11:14:28AM +0100, Wei Xu wrote:
> On 2018/6/21 10:18, Will Deacon wrote:
> > On Thu, Jun 21, 2018 at 09:38:53AM +0100, James Morse wrote:
> >> On 20/06/18 17:25, Wei Xu wrote:
> >>> [ 0.042421] Insufficient stack space to handle exception!
> >>> [ 0.042423] ESR: 0x96000046 -- DABT (current EL)
> >>> [ 0.043730] FAR: 0xffff0000093a80e0
> >>> [ 0.044714] Task stack: [0xffff0000093a8000..0xffff0000093ac000]
> >>
> >> This was a level 2 translation fault on a write, to an address that is within
> >> the stack....
> >>
> >>
> >>> [ 0.051113] IRQ stack: [0xffff000008000000..0xffff000008004000]
> >>> [ 0.057610] Overflow stack: [0xffff80003efce2f0..0xffff80003efcf2f0]
> >>> [ 0.064003] CPU: 0 PID: 12 Comm: migration/0 Not tainted
> >>> 4.17.0-45865-g2b31fe7-dirty #10
> >>> [ 0.072201] Hardware name: linux,dummy-virt (DT)
> >>
> >>> [ 0.076797] pstate: 604003c5 (nZCv DAIF +PAN -UAO)
> >>> [ 0.081727] pc : el1_sync+0x0/0xb0
> >>
> >> ... from the vectors.
> >>
> >>
> >>> [ 0.085217] lr : kpti_install_ng_mappings+0x120/0x214
> >>
> >> What I think is happening is: we come out of the kpti idmap with the stack
> >> unmapped. Shortly after we access the stack, which faults. el1_sync faults as
> >> well when it tries to push the registers to the stack, and we keep going until
> >> we overflow the stack.
> >>
> >> I can't reproduce this with kvmtool or qemu in the model.
> >
> > Hmm, one thing that occurs to me is that the kpti_install_ng_mappings()
> > code leaves the nG bit set in table entries, which is actually IGNORED in
> > the architecture.
> >
> > Wei -- does the diff below help at all? Make sure you disable CONFIG_KASAN,
> > otherwise your kernel will take an age to boot.
>
> Yes, amazing! This patch resolved the issue.
Great...
> I have tested 50 times and can not reproduce the issue any more.
> Could you please tell more why this patch works?
You might need to ask your CPU design team ;)
Without this patch, the code in idmap_kpti_install_ng_mappings() sets
bit 11 in table descriptors so that we can keep track of which parts of
the page table we've visited. With this patch, we don't bother tracking
and potentially rewalk parts of the page table (which takes a very long
time if KASAN is enabled).
The architecture documents I've looked at are clear that bit 11 is IGNORED
by the CPU, which:
"Indicates that the architecture guarantees that the bit or field is not
interpreted or modified by hardware."
Please can you double-check that your CPU is indeed ignoring bit 11 in
non-leaf (table) descriptors?
Thanks,
Will
^ permalink raw reply
* [RFC PATCH 2/2] dt-bindings: spi: QuadSPI driver for Atmel SAMA5D2 documentation
From: Piotr Bugalski @ 2018-06-21 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180620164741.2a8da424@bbrezillon>
Hi Boris,
On Wed, 20 Jun 2018, Boris Brezillon wrote:
> Hi Piotr,
>
> On Mon, 18 Jun 2018 18:21:24 +0200
> Piotr Bugalski <bugalski.piotr@gmail.com> wrote:
>
>> Documentation for DT-binding change.
>>
>> Suggested-by: Boris Brezillon <boris.brezillon@bootlin.com>
>
> I'm pretty sure I didn't make a single suggestion about the DT
> bindings you use here ;-).
>
Ok, I misunderstood a bit your idea, but I think from next release this
field will be in good place. So it was just prepared for the future ;-)
>> Signed-off-by: Piotr Bugalski <pbu@cryptera.com>
>>
>> ---
>> .../devicetree/bindings/spi/spi_atmel-qspi.txt | 41 ++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
>
> I'll comment on this aspect in more details when replying to the cover
> letter, but I think you should re-use the bindings defined in
> Documentation/devicetree/bindings/mtd/atmel-quadspi.txt (IOW, move the
> existing file to the Documentation/devicetree/bindings/spi directory).
>
> It's the same HW block, and just because you develop a new driver to
> replace the old one doesn't mean you should have 2 different bindings in
> parallel.
I'll change it in next version.
>
>>
>> diff --git a/Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt b/Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
>> new file mode 100644
>> index 000000000000..d52b534c9c2b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
>> @@ -0,0 +1,41 @@
>> +* Atmel Quad Serial Peripheral Interface (QSPI)
>> +
>> +Required properties:
>> +- compatible: Should be "atmel,sama5d2-spi-qspi".
>> +- reg: Should contain the locations and lengths of the base registers
>> + and the mapped memory.
>> +- reg-names: Should contain the resource reg names:
>> + - qspi_base: configuration register address space
>> + - qspi_mmap: memory mapped address space
>> +- interrupts: Should contain the interrupt for the device.
>> +- clocks: The phandle of the clock needed by the QSPI controller.
>> +- #address-cells: Should be <1>.
>> +- #size-cells: Should be <0>.
>> +
>> +Example:
>> +
>> +qspi1: spi at f0024000 {
>> + compatible = "atmel,sama5d2-spi-qspi";
>> + reg = <0xf0024000 0x100>, <0xd8000000 0x08000000>;
>> + reg-names = "qspi_base", "qspi_mmap";
>> + interrupts = <53 IRQ_TYPE_LEVEL_HIGH 7>;
>> + clocks = <&qspi1_clk>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_qspi1_default>;
>> + status = "okay";
>> +
>> + flash at 0 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "winbond,w25m02gv", "spi-nand";
>
> "winbond,w25m02gv" is undocumented and unnecessary since SPI NANDs are
> automatically detected. Also, maybe you should declare a SPI NOR in the
> example since SPI NAND support has not yet been merged.
>
I was mainly focusing on NAND-flash with QSPI inteface so I took
example from tested configuration. Next time I'll use NOR-flash.
>> + reg = <0>;
>> + spi-max-frequency = <83000000>;
>> + spi-rx-bus-width = <4>;
>> + spi-tx-bus-width = <4>;
>> +
>> + ...
>> + };
>> +};
>> +
>
> Regards,
>
> Boris
>
Thanks,
Piotr
^ permalink raw reply
* [PATCH v3] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling
From: Zhang, Lei @ 2018-06-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86tvpy7s1g.wl-marc.zyngier@arm.com>
Hi Marc
> - If EnableLPI is already set to 1, your redistributors are already
> potentially corrupting the memory by writing to the pending
> tables. Your system is now potentially unstable (single bit
> corruption, depending on what the ITS outputs).
>
> - If EnableLPI has become RES1, you cannot even turn it off to
> reprogram things so that the property and pending tables are under
> your control.
Thanks for you reply.
One more question.
If EnableLPIs bit becomes RES1 after EnableLPIs has been written to 1,
DKUMP/KEXEC case will enter kernel with GICR_CTLR.EnableLPIs=1.
In this case I do not think DKUMP/KEXEC can work well even use irqchip.gicv3_nolpi,
if secondary kernel need to use LPI such as the disk is nvme. Am I right?
I have seen the discussion as below URL, but I do not really understand the conclusion.
https://patchwork.kernel.org/patch/10281325/
^ permalink raw reply
* [PATCH 3/5] arm64: dts: ti: Add Support for AM654 SoC
From: Nishanth Menon @ 2018-06-21 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180621053754.GD112168@atomide.com>
On 05:37-20180621, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [180619 19:46]:
> > + cbass_main: cbass at 100000 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0x00100000 0x00 0x00100000 0x00020000>, /* ctrl mmr */
> > + <0x00600000 0x00 0x00600000 0x00001100>, /* GPIO */
> > + <0x00900000 0x00 0x00900000 0x00012000>, /* serdes */
> > + <0x01000000 0x00 0x01000000 0x0af02400>, /* Most peripherals */
> > + <0x30800000 0x00 0x30800000 0x0bc00000>, /* MAIN NAVSS */
> > + /* MCUSS Range */
> > + <0x28380000 0x00 0x28380000 0x03880000>,
> > + <0x40200000 0x00 0x40200000 0x00900100>,
> > + <0x42040000 0x00 0x42040000 0x03ac2400>,
> > + <0x45100000 0x00 0x45100000 0x00c24000>,
> > + <0x46000000 0x00 0x46000000 0x00200000>,
> > + <0x47000000 0x00 0x47000000 0x00068400>;
> > +
> > + cbass_mcu: cbass at 28380000 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0x28380000 0x28380000 0x03880000>, /* MCU NAVSS*/
> > + <0x40200000 0x40200000 0x00900100>, /* First peripheral window */
> > + <0x42040000 0x42040000 0x03ac2400>, /* WKUP */
> > + <0x45100000 0x45100000 0x00c24000>, /* MMRs, remaining NAVSS */
> > + <0x46000000 0x46000000 0x00200000>, /* CPSW */
> > + <0x47000000 0x47000000 0x00068400>; /* OSPI space 1 */
> > +
> > + cbass_wakeup: cbass at 42040000 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + /* WKUP Basic peripherals */
> > + ranges = <0x42040000 0x42040000 0x03ac2400>;
> > + };
> > + };
> > + };
> > +};
>
> You should use cbass_main: interconnect at 1000000 and so on here.
> Other than that looks good to me, thanks for updating it.
Thanks, will wait till Monday to see if there are any further comments,
else will post a V2.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/1] arm64: dts: rockchip: correct voltage selector Firefly-RK3399
From: Heiko Stuebner @ 2018-06-21 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3b6e37c8-0ee2-1723-1aa8-499fcb30471c@gmx.de>
Am Donnerstag, 21. Juni 2018, 02:57:02 CEST schrieb Heinrich Schuchardt:
> On 06/20/2018 09:57 PM, Heinrich Schuchardt wrote:
> > On 06/20/2018 11:15 AM, Heiko St?bner wrote:
> >> Hi Heinrich,
> >>
> >> Am Mittwoch, 20. Juni 2018, 07:59:34 CEST schrieb Heinrich Schuchardt:
> >>> On 06/20/2018 01:21 AM, Heiko Stuebner wrote:
> >>>> Am Donnerstag, 14. Juni 2018, 14:55:27 CEST schrieb Heiko Stuebner:
> >>>>> Am Montag, 4. Juni 2018, 19:15:23 CEST schrieb Heinrich Schuchardt:
> >>>>>> Without this patch the Firefly-RK3399 board boot process hangs after
> >>>>>> these
> >>>>>>
> >>>>>> lines:
> >>>>>> fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
> >>>>>> fan53555-reg: supplied by vcc_sys
> >>>>>> vcc1v8_s3: supplied by vcc_1v8
> >>>>>>
> >>>>>> Blacklisting driver fan53555 allows booting.
> >>>>>>
> >>>>>> The device tree uses a value of fcs,suspend-voltage-selector different
> >>>>>> to
> >>>>>> any other board.
> >>>>>>
> >>>>>> Changing this setting to the usual value is sufficient to enable
> >>>>>> booting.
> >>>>>>
> >>>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>>>
> >>>>> applied for 4.19.
> >>>>
> >>>> and dropped again.
> >>>>
> >>>> Sadly it looks like the patch causes conflicts with at least one firefly
> >>>> board in a kernelci lab. My own is currently not ready to use, so I cannot
> >>>> look myself right now.
> >>>>
> >>>> The issue kernelci people described sounded quite a lot like the one
> >>>> in your commit message, so my current theory is that the
> >>>> suspend-voltage-selector must in some form corespond to the
> >>>> cpu_b_sleep_h gpio setting we're currently not handling at all, which
> >>>> would therefore depend on how the bootloader sets this up.
> >>>
> >>> please, provide a link to the log displaying the issue and the contact
> >>> who can provide the exact setup.
> >>>
> >>> I have been testing with U-Boot as boot loader.
> >>
> >> failing boot can be found on
> >> https://kernelci.org/boot/id/5b2a053d59b514569079a872/
> >>
> >> As this board is sitting in the "lab-baylibre-seattle", I guess
> >> Kevin Hilman (Cc'ed now) is the one that can say a bit more about the
> >> board setup.
> >>
> >>
> >> The more interesting question would be how to make sure we don't
> >> die with possible different bootloader versions. As I don't really thing
> >> "upgrade your bootloader" is an always valid option.
> >>
> >>
> >> Heiko
> >>
> >
> > Hi Kevin,
> >
> > the RK3399-Firefly was booted on lab-baylibre-seattle with
> > U-Boot 2017.05-rc3-00131-gf79fd58d5f5c-dirty
> >
> > f79fd58d5f5c is not a commit in U-Boot master.
> > The version number tells us it is 131 patches ahead of U-Boot 2017.05-rc3.
> > Dirty means the source contained uncommitted changes.
> >
> > Unfortunately this is not a reproducible test environment.
> > Could you, please, provide the build recipe to reproduce the U-Boot
> > BayLibre is using?
> > Would it be possible to use mainline U-Boot in kernelci for this board?
> >
> > Best regards
> >
> > Heinrich
> >
>
> I have now built the last available release of U-Boot (v2018.05)
> according to the following recipe:
>
> git clone https://github.com/xypron/u-boot-build.git
> cd u-boot-build/
> git checkout firefly-rk3399-rkloader
> # commit 251b12fb4f0eabfff2d0552d0807d8ddc44ae2aa
> # tag firefly-rk3399-rkloader-v2018.05
> make
> make install DESTDIR=foo
> cd foo/usr/lib/u-boot/firefly-rk3399/
> # be careful to specify your SD card as device!
> ./sd_fusing /dev/sdX
>
> # in U-Boot 2018.05 (Jun 21 2018 - 02:33:12 +0200)
> load mmc 1:1 ${fdt_addr_r} 2018-06-20/rk3399-firefly.dtb
> load mmc 1:1 ${kernel_addr_r} 2018-06-20/Image
> booti ${kernel_addr_r} - ${fdt_addr_r}
>
> The error observed in kernelci when initializing the FAN53555 driver
> does not occur.
>
> The console log is here:
> https://gist.github.com/xypron/34b6485deabfc8172f978b5a99705466
For one, the kernelci board uses the uboot SPL not rkloader as 1st stage.
But I also think the real culprit might be the unconfigured cpu_b_sleep_h
gpio.
So far I haven't seen any code that touches this pin at all, so it is probably
floating and both mine as well as the kernelci board are from an early
production run, so I guess it is possible that either rkloader configures
this pin or some board change between ours and your board could make
the pin take another state.
Requiring replacement of a bootloader still isn't the best way forward,
so my current idea would be to let the driver know the vsel-gpio via the
devicetree and have the driver then make sure the gpio is set correctly
_after_ setting the regulator voltage.
Heiko
^ permalink raw reply
* [PATCH 1/2] KVM: Enforce error in ioctl for compat tasks when !KVM_COMPAT
From: Marc Zyngier @ 2018-06-21 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22acc63b-8737-39b4-d4d4-87927a49fa8c@de.ibm.com>
On 19/06/18 12:24, Christian Borntraeger wrote:
>
>
> On 06/19/2018 12:10 PM, Marc Zyngier wrote:
>> On 19/06/18 11:01, Mark Rutland wrote:
>>> On Tue, Jun 19, 2018 at 10:42:50AM +0100, Marc Zyngier wrote:
>>>> The current behaviour of the compat ioctls is a bit odd.
>>>> We provide a compat_ioctl method when KVM_COMPAT is set, and NULL
>>>> otherwise. But NULL means that the normal, non-compat ioctl should
>>>> be used directly for compat tasks, and there is no way to actually
>>>> prevent a compat task from issueing KVM ioctls.
>>>>
>>>> This patch changes this behaviour, by always registering a compat_ioctl
>>>> method, even if KVM_COMPAT is not selected. In that case, the callback
>>>> will always return -EINVAL.
>>>>
>>>> Reported-by: Mark Rutland <mark.rutland@arm.com>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>
>>> I virt/kvm/Kconfig we have:
>>>
>>> config KVM_COMPAT
>>> def_bool y
>>> depends on KVM && COMPAT && !S390
>>>
>>> ... and in arch/s390 we have COMPAT support, so does this potentially break
>>> anything there?
>>
>> It doesn't seem to (COMPAT seems to support the 31 bit stuff, which I
>> don't think ever had KVM support), but my s390-foo is quite basic.
>>
>> Christian, could you help here?
>
> We do not support KVM for 31 bit. So the original goal of the KVM_COMPAT stuff
> was to actually disable the compat thing for the KVM device driver.
>
> See
>
> commit de8e5d744051568c8aad ("KVM: Disable compat ioctl for s390").
>
> Now looking back, this patch actually only disabled the compat wrappers and
> still allows an 31bit process to run the 64bit ioctls. In theory this should
> cause no issues as the 64bit ioctl must fence off all invalid input anyway
> but actually forbidding KVM for compat processes is even better.
>
>
>
> So I think this patch actually is a good thing.
>
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
>
> if you want you could even add a
> Fixes: tag.
Added, thanks.
Radim, Paolo: are you happy with me taking this through the kvmarm tree?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 0/7 v5] Support for fsl-mc bus and its devices in SMMU
From: Will Deacon @ 2018-06-21 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR0401MB24250CEFBC0B7CC919C4388AE6760@HE1PR0401MB2425.eurprd04.prod.outlook.com>
Hi Nipun,
On Thu, Jun 21, 2018 at 03:59:27AM +0000, Nipun Gupta wrote:
> Will this patch-set be taken for the next kernel release (and via which
> tree)?
I think you need Acks from Robin and Joerg in order for this to be queued.
Robin should be back at the beginning of next month, so there's still time
for 4.19.
Will
^ permalink raw reply
* [PATCH v7 0/4] ARM: davinci: complete the conversion to using the reset framework
From: Bartosz Golaszewski @ 2018-06-21 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9ec10627-49a5-07ad-8c9d-5ac873096cc0@ti.com>
2018-06-21 12:52 GMT+02:00 Sekhar Nori <nsekhar@ti.com>:
> Hi Bartosz,
>
> On Thursday 21 June 2018 01:07 PM, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> These are the remaining patches that still need to be merged in order
>> to complete the conversion of the davinci dsp driver to using the reset
>> framework.
>>
>> They apply on top of v4.18-rc1 with David Lechner's remaining patches
>> merged.
>
> Series looks good to me.
>
> To preserve bisect, shouldn't the order of applying be patch #3, #4, #1
> and #2 ?
>
> Given the dependencies and to preserve bisect its easiest if I take the
> series with acks from remoteproc and clock maintainers.
>
> Open to other suggestions as well.
>
> Thanks,
> Sekhar
Oops you're right about the order. Do you want me to resend?
Bart
^ permalink raw reply
* [PATCH v2 1/5] dmaengine: xilinx_dma: in axidma slave_sg and dma_cyclic mode align split descriptors
From: Andrea Merello @ 2018-06-21 11:58 UTC (permalink / raw)
To: linux-arm-kernel
Whenever a single or cyclic transaction is prepared, the driver
could eventually split it over several SG descriptors in order
to deal with the HW maximum transfer length.
This could end up in DMA operations starting from a misaligned
address. This seems fatal for the HW if DRE is not enabled.
This patch eventually adjusts the transfer size in order to make sure
all operations start from an aligned address.
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
---
Changes in v2:
- don't introduce copy_mask field, rather rely on already-esistent
copy_align field. Suggested by Radhey Shyam Pandey
- reword title
---
drivers/dma/xilinx/xilinx_dma.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 27b523530c4a..22d7a6b85e65 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -1789,10 +1789,15 @@ static struct dma_async_tx_descriptor *xilinx_dma_prep_slave_sg(
/*
* Calculate the maximum number of bytes to transfer,
- * making sure it is less than the hw limit
+ * making sure it is less than the hw limit and that
+ * the next chunck start address is aligned
*/
- copy = min_t(size_t, sg_dma_len(sg) - sg_used,
- XILINX_DMA_MAX_TRANS_LEN);
+ copy = sg_dma_len(sg) - sg_used;
+ if (copy > XILINX_DMA_MAX_TRANS_LEN &&
+ chan->xdev->common.copy_align)
+ copy = rounddown(XILINX_DMA_MAX_TRANS_LEN,
+ (1 << chan->xdev->common.copy_align));
+
hw = &segment->hw;
/* Fill in the descriptor */
@@ -1894,10 +1899,15 @@ static struct dma_async_tx_descriptor *xilinx_dma_prep_dma_cyclic(
/*
* Calculate the maximum number of bytes to transfer,
- * making sure it is less than the hw limit
+ * making sure it is less than the hw limit and that
+ * the next chunck start address is aligned
*/
- copy = min_t(size_t, period_len - sg_used,
- XILINX_DMA_MAX_TRANS_LEN);
+ copy = period_len - sg_used;
+ if (copy > XILINX_DMA_MAX_TRANS_LEN &&
+ chan->xdev->common.copy_align)
+ copy = rounddown(XILINX_DMA_MAX_TRANS_LEN,
+ (1 << chan->xdev->common.copy_align));
+
hw = &segment->hw;
xilinx_axidma_buf(chan, hw, buf_addr, sg_used,
period_len * i);
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/5] dt-bindings: xilinx_dma: add optional xlnx, sg-length-width property
From: Andrea Merello @ 2018-06-21 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180621115822.20058-1-andrea.merello@gmail.com>
The width of the "length register" cannot be autodetected, and it is now
specified with a DT property. Add DOC for it.
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
---
Changes in v2:
- change property name
- property is now optional
- cc DT maintainer
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index a2b8bfaec43c..c894abe28baa 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -41,6 +41,7 @@ Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
Optional properties for AXI DMA:
+- xlnx,sg-length-width: Should be the width of the length register as configured in h/w.
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/5] dmaengine: xilinx_dma: program hardware supported buffer length
From: Andrea Merello @ 2018-06-21 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180621115822.20058-1-andrea.merello@gmail.com>
From: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
AXI-DMA IP supports configurable (c_sg_length_width) buffer length
register width, hence read buffer length (xlnx,sg-length-width) DT
property and ensure that driver doesn't program buffer length
exceeding the supported limit. For VDMA and CDMA there is no change.
Signed-off-by: Radhey Shyam Pandey <radheys@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Andrea Merello <andrea.merello@gmail.com> [rebase, reword]
---
Changes in v2:
- drop original patch and replace with the one in Xilinx tree
---
drivers/dma/xilinx/xilinx_dma.c | 39 +++++++++++++++++++++++----------
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 22d7a6b85e65..e10775d30515 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -158,7 +158,8 @@
#define XILINX_DMA_REG_BTT 0x28
/* AXI DMA Specific Masks/Bit fields */
-#define XILINX_DMA_MAX_TRANS_LEN GENMASK(22, 0)
+#define XILINX_DMA_MAX_TRANS_LEN_MIN 8
+#define XILINX_DMA_MAX_TRANS_LEN_MAX 23
#define XILINX_DMA_CR_COALESCE_MAX GENMASK(23, 16)
#define XILINX_DMA_CR_CYCLIC_BD_EN_MASK BIT(4)
#define XILINX_DMA_CR_COALESCE_SHIFT 16
@@ -418,6 +419,7 @@ struct xilinx_dma_config {
* @rxs_clk: DMA s2mm stream clock
* @nr_channels: Number of channels DMA device supports
* @chan_id: DMA channel identifier
+ * @max_buffer_len: Max buffer length
*/
struct xilinx_dma_device {
void __iomem *regs;
@@ -437,6 +439,7 @@ struct xilinx_dma_device {
struct clk *rxs_clk;
u32 nr_channels;
u32 chan_id;
+ u32 max_buffer_len;
};
/* Macros */
@@ -985,7 +988,7 @@ static enum dma_status xilinx_dma_tx_status(struct dma_chan *dchan,
list_for_each_entry(segment, &desc->segments, node) {
hw = &segment->hw;
residue += (hw->control - hw->status) &
- XILINX_DMA_MAX_TRANS_LEN;
+ chan->xdev->max_buffer_len;
}
}
spin_unlock_irqrestore(&chan->lock, flags);
@@ -1237,7 +1240,7 @@ static void xilinx_cdma_start_transfer(struct xilinx_dma_chan *chan)
/* Start the transfer */
dma_ctrl_write(chan, XILINX_DMA_REG_BTT,
- hw->control & XILINX_DMA_MAX_TRANS_LEN);
+ hw->control & chan->xdev->max_buffer_len);
}
list_splice_tail_init(&chan->pending_list, &chan->active_list);
@@ -1340,7 +1343,7 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
/* Start the transfer */
dma_ctrl_write(chan, XILINX_DMA_REG_BTT,
- hw->control & XILINX_DMA_MAX_TRANS_LEN);
+ hw->control & chan->xdev->max_buffer_len);
}
list_splice_tail_init(&chan->pending_list, &chan->active_list);
@@ -1701,7 +1704,7 @@ xilinx_cdma_prep_memcpy(struct dma_chan *dchan, dma_addr_t dma_dst,
struct xilinx_cdma_tx_segment *segment;
struct xilinx_cdma_desc_hw *hw;
- if (!len || len > XILINX_DMA_MAX_TRANS_LEN)
+ if (!len || len > chan->xdev->max_buffer_len)
return NULL;
desc = xilinx_dma_alloc_tx_descriptor(chan);
@@ -1793,9 +1796,9 @@ static struct dma_async_tx_descriptor *xilinx_dma_prep_slave_sg(
* the next chunck start address is aligned
*/
copy = sg_dma_len(sg) - sg_used;
- if (copy > XILINX_DMA_MAX_TRANS_LEN &&
+ if (copy > chan->xdev->max_buffer_len &&
chan->xdev->common.copy_align)
- copy = rounddown(XILINX_DMA_MAX_TRANS_LEN,
+ copy = rounddown(chan->xdev->max_buffer_len,
(1 << chan->xdev->common.copy_align));
hw = &segment->hw;
@@ -1903,9 +1906,9 @@ static struct dma_async_tx_descriptor *xilinx_dma_prep_dma_cyclic(
* the next chunck start address is aligned
*/
copy = period_len - sg_used;
- if (copy > XILINX_DMA_MAX_TRANS_LEN &&
+ if (copy > chan->xdev->max_buffer_len &&
chan->xdev->common.copy_align)
- copy = rounddown(XILINX_DMA_MAX_TRANS_LEN,
+ copy = rounddown(chan->xdev->max_buffer_len,
(1 << chan->xdev->common.copy_align));
hw = &segment->hw;
@@ -2580,7 +2583,7 @@ static int xilinx_dma_probe(struct platform_device *pdev)
struct xilinx_dma_device *xdev;
struct device_node *child, *np = pdev->dev.of_node;
struct resource *io;
- u32 num_frames, addr_width;
+ u32 num_frames, addr_width, len_width;
int i, err;
/* Allocate and initialize the DMA engine structure */
@@ -2612,8 +2615,22 @@ static int xilinx_dma_probe(struct platform_device *pdev)
/* Retrieve the DMA engine properties from the device tree */
xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
- if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
+ xdev->max_buffer_len = GENMASK(XILINX_DMA_MAX_TRANS_LEN_MAX - 1, 0);
+
+ if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
xdev->mcdma = of_property_read_bool(node, "xlnx,mcdma");
+ if (!of_property_read_u32(node, "xlnx,sg-length-width",
+ &len_width)) {
+ if (len_width < XILINX_DMA_MAX_TRANS_LEN_MIN ||
+ len_width > XILINX_DMA_MAX_TRANS_LEN_MAX) {
+ dev_warn(xdev->dev,
+ "invalid xlnx,sg-length-width property value using default width\n");
+ } else {
+ xdev->max_buffer_len = GENMASK(len_width - 1,
+ 0);
+ }
+ }
+ }
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
err = of_property_read_u32(node, "xlnx,num-fstores",
--
2.17.1
^ permalink raw reply related
* [PATCH v2 4/5] dmaengine: xilinx_dma: autodetect whether the HW supports scatter-gather
From: Andrea Merello @ 2018-06-21 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180621115822.20058-1-andrea.merello@gmail.com>
The AXIDMA and CDMA HW can be either direct-access or scatter-gather
version. These are SW incompatible.
The driver can handle both version: a DT property was used to
tell the driver whether to assume the HW is is scatter-gather mode.
This patch makes the driver to autodetect this information. The DT
property is not required anymore.
No changes for VDMA.
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
---
Changes in v2:
- autodetect only in !VDMA case
---
drivers/dma/xilinx/xilinx_dma.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index e10775d30515..fac8f09ece5d 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -86,6 +86,7 @@
#define XILINX_DMA_DMASR_DMA_DEC_ERR BIT(6)
#define XILINX_DMA_DMASR_DMA_SLAVE_ERR BIT(5)
#define XILINX_DMA_DMASR_DMA_INT_ERR BIT(4)
+#define XILINX_DMA_DMASR_SG_MASK BIT(3)
#define XILINX_DMA_DMASR_IDLE BIT(1)
#define XILINX_DMA_DMASR_HALTED BIT(0)
#define XILINX_DMA_DMASR_DELAY_MASK GENMASK(31, 24)
@@ -406,7 +407,6 @@ struct xilinx_dma_config {
* @dev: Device Structure
* @common: DMA device structure
* @chan: Driver specific DMA channel
- * @has_sg: Specifies whether Scatter-Gather is present or not
* @mcdma: Specifies whether Multi-Channel is present or not
* @flush_on_fsync: Flush on frame sync
* @ext_addr: Indicates 64 bit addressing is supported by dma device
@@ -426,7 +426,6 @@ struct xilinx_dma_device {
struct device *dev;
struct dma_device common;
struct xilinx_dma_chan *chan[XILINX_DMA_MAX_CHANS_PER_DEVICE];
- bool has_sg;
bool mcdma;
u32 flush_on_fsync;
bool ext_addr;
@@ -2383,7 +2382,6 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
chan->dev = xdev->dev;
chan->xdev = xdev;
- chan->has_sg = xdev->has_sg;
chan->desc_pendingcount = 0x0;
chan->ext_addr = xdev->ext_addr;
/* This variable ensures that descriptors are not
@@ -2476,6 +2474,15 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
chan->stop_transfer = xilinx_dma_stop_transfer;
}
+ /* check if SG is enabled (only for AXIDMA and CDMA) */
+ if (xdev->dma_config->dmatype != XDMA_TYPE_VDMA) {
+ if (dma_ctrl_read(chan, XILINX_DMA_REG_DMASR) &
+ XILINX_DMA_DMASR_SG_MASK)
+ chan->has_sg = true;
+ dev_dbg(chan->dev, "ch %d: SG %s\n", chan->id,
+ chan->has_sg ? "enabled" : "disabled");
+ }
+
/* Initialize the tasklet */
tasklet_init(&chan->tasklet, xilinx_dma_do_tasklet,
(unsigned long)chan);
@@ -2614,7 +2621,6 @@ static int xilinx_dma_probe(struct platform_device *pdev)
return PTR_ERR(xdev->regs);
/* Retrieve the DMA engine properties from the device tree */
- xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
xdev->max_buffer_len = GENMASK(XILINX_DMA_MAX_TRANS_LEN_MAX - 1, 0);
if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
--
2.17.1
^ permalink raw reply related
* [PATCH v2 5/5] dt-bindings: xilinx_dma: drop has-sg property
From: Andrea Merello @ 2018-06-21 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180621115822.20058-1-andrea.merello@gmail.com>
This property is not needed anymore, because the driver now autodetects it.
Delete references in documentation.
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
---
Changes in v2:
- cc DT maintainer
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index c894abe28baa..09a41843cbc0 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -37,9 +37,6 @@ Required properties:
Required properties for VDMA:
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
-Optional properties:
-- xlnx,include-sg: Tells configured for Scatter-mode in
- the hardware.
Optional properties for AXI DMA:
- xlnx,sg-length-width: Should be the width of the length register as configured in h/w.
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
--
2.17.1
^ permalink raw reply related
* [PATCH v3] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling
From: Marc Zyngier @ 2018-06-21 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8898674D84E3B24BA3A2D289B872026A69F3B4A4@G01JPEXMBKW03>
Hi Lei,
On 21/06/18 11:57, Zhang, Lei wrote:
> Hi Marc
>
>> - If EnableLPI is already set to 1, your redistributors are already
>> potentially corrupting the memory by writing to the pending
>> tables. Your system is now potentially unstable (single bit
>> corruption, depending on what the ITS outputs).
>>
>> - If EnableLPI has become RES1, you cannot even turn it off to
>> reprogram things so that the property and pending tables are under
>> your control.
> Thanks for you reply.
>
> One more question.
> If EnableLPIs bit becomes RES1 after EnableLPIs has been written to
> 1, DKUMP/KEXEC case will enter kernel with GICR_CTLR.EnableLPIs=1. In
> this case I do not think DKUMP/KEXEC can work well even use
> irqchip.gicv3_nolpi, if secondary kernel need to use LPI such as the
> disk is nvme. Am I right?
Absolutely. If you can only signal interrupts using LPIs, there isn't
much you can do if you cannot disable LPIs the first place to
reconfigure the interrupts. Your NVME device is pretty useless in that case.
What we could potentially do in the kdump case (and only in that case)
would be to try to reuse the programmed tables and IDbits settings if
EnableLPIs is RES1. This is absolutely awful, but it could get you
going. Maybe.
> I have seen the discussion as below URL, but I do not really
> understand the conclusion.
> https://patchwork.kernel.org/patch/10281325/
The conclusion is that although RES1 is valid for EnableLPIs once it has
been set to 1 (because that is how it was initially specified), it is a
very bad idea to implement it like this. Allowing LPIs to be disabled is
absolutely essential in a modern computing environment.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH V2 3/4] dt-bindings: arm: fsl: add scu binding doc
From: A.s. Dong @ 2018-06-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180621073728.wmxb4jkn3ek4n2vt@pengutronix.de>
> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Thursday, June 21, 2018 3:37 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Rob Herring <robh@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; devicetree at vger.kernel.org;
> dongas86 at gmail.com; dl-linux-imx <linux-imx@nxp.com>;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V2 3/4] dt-bindings: arm: fsl: add scu binding doc
>
> On Thu, Jun 21, 2018 at 03:38:30AM +0000, A.s. Dong wrote:
> > Hi Rob,
> >
> > > -----Original Message-----
> > > From: Rob Herring [mailto:robh at kernel.org]
> > > Sent: Thursday, June 21, 2018 3:45 AM
> > > To: A.s. Dong <aisheng.dong@nxp.com>
> > > Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com;
> > > kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> > > <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Mark
> > > Rutland <mark.rutland@arm.com>; devicetree at vger.kernel.org
> > > Subject: Re: [PATCH V2 3/4] dt-bindings: arm: fsl: add scu binding
> > > doc
> > >
> > > On Sun, Jun 17, 2018 at 08:49:48PM +0800, Dong Aisheng wrote:
> > > > The System Controller Firmware (SCFW) is a low-level system
> > > > function which runs on a dedicated Cortex-M core to provide power,
> > > > clock, and resource management. It exists on some i.MX8
> > > > processors. e.g. i.MX8QM (QM, QP), and i.MX8QX (QXP, DX).
> > > >
> > > > Cc: Shawn Guo <shawnguo@kernel.org>
> > > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > > > Cc: Rob Herring <robh+dt@kernel.org>
> > > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > > Cc: devicetree at vger.kernel.org
> > > > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > > > ---
> > > > v1->v2:
> > > > * remove status
> > > > * changed to mu1
> > > > ---
> > > > .../devicetree/bindings/arm/freescale/fsl,scu.txt | 38
> > > > ++++++++++++++++++++++
> > > > 1 file changed, 38 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > > new file mode 100644
> > > > index 0000000..9b7c9fe
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > > @@ -0,0 +1,38 @@
> > > > +NXP i.MX System Controller Firmware (SCFW)
> > > > +-----------------------------------------------------------------
> > > > +---
> > > > +
> > > > +The System Controller Firmware (SCFW) is a low-level system
> > > > +function which runs on a dedicated Cortex-M core to provide
> > > > +power, clock, and resource management. It exists on some i.MX8
> > > > +processors. e.g. i.MX8QM (QM, QP), and i.MX8QX (QXP, DX).
> > > > +
> > > > +The AP communicates with the SC using a multi-ported MU module
> > > > +found in the LSIO subsystem. The current definition of this MU
> > > > +module provides
> > > > +5 remote AP connections to the SC to support up to 5 execution
> > > > +environments (TZ, HV, standard Linux, etc.). The SC side of this
> > > > +MU module interfaces with the LSIO DSC IP bus. The SC firmware
> > > > +will communicate with this MU using the MSI bus.
> > > > +
> > > > +System Controller Device Node:
> > > > +=============================
> > > > +
> > > > +Required properties:
> > > > +-------------------
> > > > +- compatible: should be "fsl,imx8qxp-scu" or "fsl,imx8qm-scu"
> > > > +- fsl,mu: a phandle to the Message Unit used by SCU. Should be
> > > > + one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
> > > > + to make sure not use the one which is conflict with
> > > > + other execution environments. e.g. ATF.
> > >
> > > Use the mailbox binding even if you don't use the mailbox subsystem.
> > >
> >
> > Looks reasonable. Will change it.
> >
> > BTW as I said before, the current mailbox binding fixed #mbox-cells to
> > be at least 1 which is not suitable for i.MX SCU MU as it has only one
> > physical channel.
>
> Why is that not suitable? If we use #mbox-cells = 1 we can encode the
> channel into the second cell. Furthermore, the SCU mode which uses all
> channels in a funny way could be another channel id the mu driver could use
> to distinguish the different channel/modes. i.e.
>
> #define MU_CHANNEL_0 0
> #define MU_CHANNEL_1 1
> #define MU_CHANNEL_2 2
> #define MU_CHANNEL_3 3
> #define MU_CHANNEL_SCU 4
>
That's a bit confusing.
The 'channel' here actually are abstract virtual channels implemented by driver,
not hardware. MU itself does not have multi channels. (For example, you can't
grep a 'channel' word in the MU chapter in RM).
Yes, it has 4 Read/Write Data register pairs, but it's not originally designed for
separate channels, they're defined to send multi words.
See:
42.3.3.2 Messaging Examples
The following are messaging examples:
* Passing short messages: Transmit register(s) can be used to pass short messages
from one to four words in length. For example, when a four-word message is desired,
only one of the registers needs to have its corresponding interrupt enable bit set at the
receiver side; the message's first three words are written to the registers whose
interrupt is masked, and the fourth word is written to the other register (which
triggers an interrupt at the receiver side).
Abstracting them into individual channels mean we lose the HW capability to send
multi words during one transfer. However, I'm not object to it if we have no
special requirent of it. But for SCU, we need use the four data read/write register
at the same time which seems Mailbox driver can't support.
And MU_CHANNEL_SCU seems a bit more confuse. It is really one
channel from HW point of view but transfer multi works at one time.
Do you really want us to do that way?
And by greping mbox-cells in device tree, there's indeed someone using 0.
arch/arm/boot/dts/bcm283x.dtsi:145: #mbox-cells = <0>;
Regards
Dong Aisheng
>
> scu {
> compatible = "fsl,imx8qxp-scu";
> fsl,mu = <&lsio_mu1 MU_CHANNEL_SCU>; };
>
> This would also allow to the MU-SCU-mode driver to coexist with the regular
> MU driver for which Oleksij posted a driver.
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> w.pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7C17a
> 33ebbb3ef437fe76b08d5d749da3c%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C0%7C636651634553051648&sdata=YqJD%2FOcQvywtUtG6tpzdOxlnM
> tPRZP17ftjYP3gwynU%3D&reserved=0 |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* v4.18-rc1 on droid 4: very bad CPU performance
From: Pavel Machek @ 2018-06-21 12:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
V4.18 is slower than it should be.
user at devuan:~$ time cat /dev/urandom | head -c 10000000 | bzip2 -9 -
| wc -c
10044291
52.73user 2.40system 61.53 (1m1.534s) elapsed 89.60%CPU
user at devuan:~$ uname -a
Linux devuan 4.18.0-rc1-87964-gfa19934-dirty #743 SMP Sun Jun 17
19:26:37 CEST 2018 armv7l GNU/Linux
That bzip should take 12 seconds, not minute.
Any ideas? Do you see it, too?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180621/aae8df5a/attachment.sig>
^ permalink raw reply
* [PATCH 1/1] arm64/mm: move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} to .rodata section
From: Jun Yao @ 2018-06-21 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-t5ErL89J=sxeVRYzDNrB1Ejdj+XOggAMWk-gY7ewsOg@mail.gmail.com>
On Thu, Jun 21, 2018 at 11:29:52AM +0200, Ard Biesheuvel wrote:
> On 21 June 2018 at 10:59, James Morse <james.morse@arm.com> wrote:
> > On 21/06/18 07:39, Ard Biesheuvel wrote:
> >> On 21 June 2018 at 04:51, Jun Yao <yaojun8558363@gmail.com> wrote:
> >>> On Wed, Jun 20, 2018 at 12:09:49PM +0200, Ard Biesheuvel wrote:
> >>>> On 20 June 2018 at 10:57, Jun Yao <yaojun8558363@gmail.com> wrote:
> >>>> As for swapper_pg_dir, it would indeed be nice if we could keep those
> >>>> mappings read-only most of the time, but I'm not sure how useful this
> >>>> is if we apply it to the root level only.
> >>>
> >>> The purpose of it is to make 'KSMA' harder, where an single arbitrary
> >>> write is used to add a block mapping to the page-tables, giving the
> >>> attacker full access to kernel memory. That's why we just apply it to
> >>> the root level only. If the attacker can arbitrary write multiple times,
> >>> I think it's hard to defend.
> >>>
> >>
> >> So the assumption is that the root level is more easy to find?
> >> Otherwise, I'm not sure I understand why being able to write a level 0
> >> entry is so harmful, given that we don't have block mappings at that
> >> level.
> >
> > I think this thing assumes 3-level page tables with 39bit VA.
> >
>
> The attack, you mean? Because this code is unlikely to build with that
> configuration, given that __pgd_populate() BUILD_BUG()s in that case.
I think this configuration may be ok. I find that the kernel on Google
pixel 2 XL is built with 3-level page tables with 39-bit VA.
^ permalink raw reply
* [PATCH] clk: meson-axg: add clocks required by pcie driver
From: Yixun Lan @ 2018-06-21 12:26 UTC (permalink / raw)
To: linux-arm-kernel
Adding clocks for pcie driver, due to the ASIC design,
the pcie controller re-use part of the mipi clock logic,
so the mipi clock is also required.
Tested-by: Jianxin Qin <jianxin.qin@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/clk/meson/axg.c | 145 +++++++++++++++++++++++++++
drivers/clk/meson/axg.h | 6 +-
include/dt-bindings/clock/axg-clkc.h | 3 +
3 files changed, 153 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
index bd4dbc696b88..f1dc5433b69d 100644
--- a/drivers/clk/meson/axg.c
+++ b/drivers/clk/meson/axg.c
@@ -626,6 +626,137 @@ static struct clk_regmap axg_mpll3 = {
},
};
+static const struct pll_rate_table axg_pcie_pll_rate_table[] = {
+ {
+ .rate = 100000000,
+ .m = 200,
+ .n = 3,
+ .od = 1,
+ .od2 = 3,
+ },
+ { /* sentinel */ },
+};
+
+static const struct reg_sequence axg_pcie_init_regs[] = {
+ { .reg = HHI_PCIE_PLL_CNTL, .def = 0x400106c8 },
+ { .reg = HHI_PCIE_PLL_CNTL1, .def = 0x0084a2aa },
+ { .reg = HHI_PCIE_PLL_CNTL2, .def = 0xb75020be },
+ { .reg = HHI_PCIE_PLL_CNTL3, .def = 0x0a47488e },
+ { .reg = HHI_PCIE_PLL_CNTL4, .def = 0xc000004d },
+ { .reg = HHI_PCIE_PLL_CNTL5, .def = 0x00078000 },
+ { .reg = HHI_PCIE_PLL_CNTL6, .def = 0x002323c6 },
+};
+
+static struct clk_regmap axg_pcie_pll = {
+ .data = &(struct meson_clk_pll_data){
+ .m = {
+ .reg_off = HHI_PCIE_PLL_CNTL,
+ .shift = 0,
+ .width = 9,
+ },
+ .n = {
+ .reg_off = HHI_PCIE_PLL_CNTL,
+ .shift = 9,
+ .width = 5,
+ },
+ .od = {
+ .reg_off = HHI_PCIE_PLL_CNTL,
+ .shift = 16,
+ .width = 2,
+ },
+ .od2 = {
+ .reg_off = HHI_PCIE_PLL_CNTL6,
+ .shift = 6,
+ .width = 2,
+ },
+ .frac = {
+ .reg_off = HHI_PCIE_PLL_CNTL1,
+ .shift = 0,
+ .width = 12,
+ },
+ .l = {
+ .reg_off = HHI_PCIE_PLL_CNTL,
+ .shift = 31,
+ .width = 1,
+ },
+ .rst = {
+ .reg_off = HHI_PCIE_PLL_CNTL,
+ .shift = 29,
+ .width = 1,
+ },
+ .table = axg_pcie_pll_rate_table,
+ .init_regs = axg_pcie_init_regs,
+ .init_count = ARRAY_SIZE(axg_pcie_init_regs),
+ },
+ .hw.init = &(struct clk_init_data){
+ .name = "pcie_pll",
+ .ops = &meson_clk_pll_ops,
+ .parent_names = (const char *[]){ "xtal" },
+ .num_parents = 1,
+ },
+};
+
+static struct clk_regmap axg_pcie_mux = {
+ .data = &(struct clk_regmap_mux_data){
+ .offset = HHI_PCIE_PLL_CNTL6,
+ .mask = 0x1,
+ .shift = 2,
+ },
+ .hw.init = &(struct clk_init_data){
+ .name = "pcie_mux",
+ .ops = &clk_regmap_mux_ops,
+ .parent_names = (const char *[]){ "mpll3", "pcie_pll" },
+ .num_parents = 2,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
+static struct clk_regmap axg_pcie_ref = {
+ .data = &(struct clk_regmap_mux_data){
+ .offset = HHI_PCIE_PLL_CNTL6,
+ .mask = 0x1,
+ .shift = 1,
+ },
+ .hw.init = &(struct clk_init_data){
+ .name = "pcie_ref",
+ .ops = &clk_regmap_mux_ops,
+ /* do not select the first partent, debug only */
+ .parent_names = (const char *[]){ "",
+ "pcie_mux" },
+ .num_parents = 2,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
+static struct clk_regmap axg_pcie_cml_en0 = {
+ .data = &(struct clk_regmap_gate_data){
+ .offset = HHI_PCIE_PLL_CNTL6,
+ .bit_idx = 4,
+ },
+ .hw.init = &(struct clk_init_data) {
+ .name = "pcie_cml_en0",
+ .ops = &clk_regmap_gate_ops,
+ .parent_names = (const char *[]){ "pcie_ref" },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+
+ },
+};
+
+static struct clk_regmap axg_pcie_cml_en1 = {
+ .data = &(struct clk_regmap_gate_data){
+ .offset = HHI_PCIE_PLL_CNTL6,
+ .bit_idx = 3,
+ },
+ .hw.init = &(struct clk_init_data) {
+ .name = "pcie_cml_en1",
+ .ops = &clk_regmap_gate_ops,
+ .parent_names = (const char *[]){ "pcie_ref" },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
static u32 mux_table_clk81[] = { 0, 2, 3, 4, 5, 6, 7 };
static const char * const clk81_parent_names[] = {
"xtal", "fclk_div7", "mpll1", "mpll2", "fclk_div4",
@@ -821,6 +952,7 @@ static MESON_GATE(axg_mmc_pclk, HHI_GCLK_MPEG2, 11);
static MESON_GATE(axg_vpu_intr, HHI_GCLK_MPEG2, 25);
static MESON_GATE(axg_sec_ahb_ahb3_bridge, HHI_GCLK_MPEG2, 26);
static MESON_GATE(axg_gic, HHI_GCLK_MPEG2, 30);
+static MESON_GATE(axg_mipi_enable, HHI_MIPI_CNTL0, 29);
/* Always On (AO) domain gates */
@@ -910,6 +1042,13 @@ static struct clk_hw_onecell_data axg_hw_onecell_data = {
[CLKID_FCLK_DIV4_DIV] = &axg_fclk_div4_div.hw,
[CLKID_FCLK_DIV5_DIV] = &axg_fclk_div5_div.hw,
[CLKID_FCLK_DIV7_DIV] = &axg_fclk_div7_div.hw,
+ [CLKID_PCIE_PLL] = &axg_pcie_pll.hw,
+ [CLKID_PCIE_MUX] = &axg_pcie_mux.hw,
+ [CLKID_PCIE_REF] = &axg_pcie_ref.hw,
+ [CLKID_PCIE_CML_EN0] = &axg_pcie_cml_en0.hw,
+ [CLKID_PCIE_CML_EN1] = &axg_pcie_cml_en1.hw,
+ [CLKID_MIPI_ENABLE] = &axg_mipi_enable.hw,
+
[NR_CLKS] = NULL,
},
.num = NR_CLKS,
@@ -988,6 +1127,12 @@ static struct clk_regmap *const axg_clk_regmaps[] = {
&axg_fclk_div4,
&axg_fclk_div5,
&axg_fclk_div7,
+ &axg_pcie_pll,
+ &axg_pcie_mux,
+ &axg_pcie_ref,
+ &axg_pcie_cml_en0,
+ &axg_pcie_cml_en1,
+ &axg_mipi_enable,
};
static const struct of_device_id clkc_match_table[] = {
diff --git a/drivers/clk/meson/axg.h b/drivers/clk/meson/axg.h
index b421df6a7ea0..6e55ebd6c77d 100644
--- a/drivers/clk/meson/axg.h
+++ b/drivers/clk/meson/axg.h
@@ -16,6 +16,7 @@
* Register offsets from the data sheet must be multiplied by 4 before
* adding them to the base address to get the right value.
*/
+#define HHI_MIPI_CNTL0 0x00
#define HHI_GP0_PLL_CNTL 0x40
#define HHI_GP0_PLL_CNTL2 0x44
#define HHI_GP0_PLL_CNTL3 0x48
@@ -127,8 +128,11 @@
#define CLKID_FCLK_DIV4_DIV 73
#define CLKID_FCLK_DIV5_DIV 74
#define CLKID_FCLK_DIV7_DIV 75
+#define CLKID_PCIE_PLL 76
+#define CLKID_PCIE_MUX 77
+#define CLKID_PCIE_REF 78
-#define NR_CLKS 76
+#define NR_CLKS 82
/* include the CLKIDs that have been made part of the DT binding */
#include <dt-bindings/clock/axg-clkc.h>
diff --git a/include/dt-bindings/clock/axg-clkc.h b/include/dt-bindings/clock/axg-clkc.h
index 555937a25504..70371228b7e0 100644
--- a/include/dt-bindings/clock/axg-clkc.h
+++ b/include/dt-bindings/clock/axg-clkc.h
@@ -68,5 +68,8 @@
#define CLKID_SD_EMMC_B_CLK0 59
#define CLKID_SD_EMMC_C_CLK0 60
#define CLKID_HIFI_PLL 69
+#define CLKID_PCIE_CML_EN0 79
+#define CLKID_PCIE_CML_EN1 80
+#define CLKID_MIPI_ENABLE 81
#endif /* __AXG_CLKC_H */
--
2.17.1
^ permalink raw reply related
* [PATCH v3 02/17] khwasan: move common kasan and khwasan code to common.c
From: Andrey Konovalov @ 2018-06-21 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201806210451.tOaA22Qm%fengguang.wu@intel.com>
On Wed, Jun 20, 2018 at 10:36 PM, kbuild test robot <lkp@intel.com> wrote:
> Hi Andrey,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on mmotm/master]
> [also build test ERROR on v4.18-rc1 next-20180620]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Andrey-Konovalov/khwasan-kernel-hardware-assisted-address-sanitizer/20180621-035912
> base: git://git.cmpxchg.org/linux-mmotm.git master
> config: x86_64-randconfig-x011-201824 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> Note: the linux-review/Andrey-Konovalov/khwasan-kernel-hardware-assisted-address-sanitizer/20180621-035912 HEAD 0e30ed7118e854b38bb6ab96365e7c74a2518290 builds fine.
> It only hurts bisectibility.
Will fix in v4, thanks!
>
> All errors (new ones prefixed by >>):
>
>>> mm//kasan/report.c:42:20: error: conflicting types for 'find_first_bad_addr'
> static const void *find_first_bad_addr(const void *addr, size_t size)
> ^~~~~~~~~~~~~~~~~~~
> In file included from mm//kasan/report.c:33:0:
> mm//kasan/kasan.h:130:7: note: previous declaration of 'find_first_bad_addr' was here
> void *find_first_bad_addr(void *addr, size_t size);
> ^~~~~~~~~~~~~~~~~~~
>>> mm//kasan/report.c:54:13: error: conflicting types for 'addr_has_shadow'
> static bool addr_has_shadow(struct kasan_access_info *info)
> ^~~~~~~~~~~~~~~
> In file included from mm//kasan/report.c:33:0:
> mm//kasan/kasan.h:120:20: note: previous definition of 'addr_has_shadow' was here
> static inline bool addr_has_shadow(const void *addr)
> ^~~~~~~~~~~~~~~
> mm//kasan/report.c: In function 'get_shadow_bug_type':
> mm//kasan/report.c:86:2: error: duplicate case value
> case KASAN_KMALLOC_REDZONE:
> ^~~~
> mm//kasan/report.c:85:2: note: previously used here
> case KASAN_PAGE_REDZONE:
> ^~~~
> mm//kasan/report.c:98:2: error: duplicate case value
> case KASAN_FREE_PAGE:
> ^~~~
> mm//kasan/report.c:85:2: note: previously used here
> case KASAN_PAGE_REDZONE:
> ^~~~
> mm//kasan/report.c:99:2: error: duplicate case value
> case KASAN_KMALLOC_FREE:
> ^~~~
> mm//kasan/report.c:85:2: note: previously used here
> case KASAN_PAGE_REDZONE:
> ^~~~
> mm//kasan/report.c: At top level:
>>> mm//kasan/report.c:128:20: error: static declaration of 'get_bug_type' follows non-static declaration
> static const char *get_bug_type(struct kasan_access_info *info)
> ^~~~~~~~~~~~
> In file included from mm//kasan/report.c:33:0:
> mm//kasan/kasan.h:131:13: note: previous declaration of 'get_bug_type' was here
> const char *get_bug_type(struct kasan_access_info *info);
> ^~~~~~~~~~~~
>
> vim +/find_first_bad_addr +42 mm//kasan/report.c
>
> 0b24becc Andrey Ryabinin 2015-02-13 41
> 0b24becc Andrey Ryabinin 2015-02-13 @42 static const void *find_first_bad_addr(const void *addr, size_t size)
> 0b24becc Andrey Ryabinin 2015-02-13 43 {
> 0b24becc Andrey Ryabinin 2015-02-13 44 u8 shadow_val = *(u8 *)kasan_mem_to_shadow(addr);
> 0b24becc Andrey Ryabinin 2015-02-13 45 const void *first_bad_addr = addr;
> 0b24becc Andrey Ryabinin 2015-02-13 46
> 0b24becc Andrey Ryabinin 2015-02-13 47 while (!shadow_val && first_bad_addr < addr + size) {
> 0b24becc Andrey Ryabinin 2015-02-13 48 first_bad_addr += KASAN_SHADOW_SCALE_SIZE;
> 0b24becc Andrey Ryabinin 2015-02-13 49 shadow_val = *(u8 *)kasan_mem_to_shadow(first_bad_addr);
> 0b24becc Andrey Ryabinin 2015-02-13 50 }
> 0b24becc Andrey Ryabinin 2015-02-13 51 return first_bad_addr;
> 0b24becc Andrey Ryabinin 2015-02-13 52 }
> 0b24becc Andrey Ryabinin 2015-02-13 53
> 5e82cd12 Andrey Konovalov 2017-05-03 @54 static bool addr_has_shadow(struct kasan_access_info *info)
> 5e82cd12 Andrey Konovalov 2017-05-03 55 {
> 5e82cd12 Andrey Konovalov 2017-05-03 56 return (info->access_addr >=
> 5e82cd12 Andrey Konovalov 2017-05-03 57 kasan_shadow_to_mem((void *)KASAN_SHADOW_START));
> 5e82cd12 Andrey Konovalov 2017-05-03 58 }
> 5e82cd12 Andrey Konovalov 2017-05-03 59
> 5e82cd12 Andrey Konovalov 2017-05-03 60 static const char *get_shadow_bug_type(struct kasan_access_info *info)
> 0b24becc Andrey Ryabinin 2015-02-13 61 {
> 0952d87f Andrey Konovalov 2015-11-05 62 const char *bug_type = "unknown-crash";
> cdf6a273 Andrey Konovalov 2015-11-05 63 u8 *shadow_addr;
> 0b24becc Andrey Ryabinin 2015-02-13 64
> 0b24becc Andrey Ryabinin 2015-02-13 65 info->first_bad_addr = find_first_bad_addr(info->access_addr,
> 0b24becc Andrey Ryabinin 2015-02-13 66 info->access_size);
> 0b24becc Andrey Ryabinin 2015-02-13 67
> cdf6a273 Andrey Konovalov 2015-11-05 68 shadow_addr = (u8 *)kasan_mem_to_shadow(info->first_bad_addr);
> 0b24becc Andrey Ryabinin 2015-02-13 69
> cdf6a273 Andrey Konovalov 2015-11-05 70 /*
> cdf6a273 Andrey Konovalov 2015-11-05 71 * If shadow byte value is in [0, KASAN_SHADOW_SCALE_SIZE) we can look
> cdf6a273 Andrey Konovalov 2015-11-05 72 * at the next shadow byte to determine the type of the bad access.
> cdf6a273 Andrey Konovalov 2015-11-05 73 */
> cdf6a273 Andrey Konovalov 2015-11-05 74 if (*shadow_addr > 0 && *shadow_addr <= KASAN_SHADOW_SCALE_SIZE - 1)
> cdf6a273 Andrey Konovalov 2015-11-05 75 shadow_addr++;
> cdf6a273 Andrey Konovalov 2015-11-05 76
> cdf6a273 Andrey Konovalov 2015-11-05 77 switch (*shadow_addr) {
> 0952d87f Andrey Konovalov 2015-11-05 78 case 0 ... KASAN_SHADOW_SCALE_SIZE - 1:
> cdf6a273 Andrey Konovalov 2015-11-05 79 /*
> cdf6a273 Andrey Konovalov 2015-11-05 80 * In theory it's still possible to see these shadow values
> cdf6a273 Andrey Konovalov 2015-11-05 81 * due to a data race in the kernel code.
> cdf6a273 Andrey Konovalov 2015-11-05 82 */
> 0952d87f Andrey Konovalov 2015-11-05 83 bug_type = "out-of-bounds";
> b8c73fc2 Andrey Ryabinin 2015-02-13 84 break;
> 0316bec2 Andrey Ryabinin 2015-02-13 85 case KASAN_PAGE_REDZONE:
> 0316bec2 Andrey Ryabinin 2015-02-13 86 case KASAN_KMALLOC_REDZONE:
> 0952d87f Andrey Konovalov 2015-11-05 87 bug_type = "slab-out-of-bounds";
> 0952d87f Andrey Konovalov 2015-11-05 88 break;
> bebf56a1 Andrey Ryabinin 2015-02-13 89 case KASAN_GLOBAL_REDZONE:
> 0952d87f Andrey Konovalov 2015-11-05 90 bug_type = "global-out-of-bounds";
> 0b24becc Andrey Ryabinin 2015-02-13 91 break;
> c420f167 Andrey Ryabinin 2015-02-13 92 case KASAN_STACK_LEFT:
> c420f167 Andrey Ryabinin 2015-02-13 93 case KASAN_STACK_MID:
> c420f167 Andrey Ryabinin 2015-02-13 94 case KASAN_STACK_RIGHT:
> c420f167 Andrey Ryabinin 2015-02-13 95 case KASAN_STACK_PARTIAL:
> 0952d87f Andrey Konovalov 2015-11-05 96 bug_type = "stack-out-of-bounds";
> 0952d87f Andrey Konovalov 2015-11-05 97 break;
> 0952d87f Andrey Konovalov 2015-11-05 98 case KASAN_FREE_PAGE:
> 0952d87f Andrey Konovalov 2015-11-05 @99 case KASAN_KMALLOC_FREE:
> 0952d87f Andrey Konovalov 2015-11-05 100 bug_type = "use-after-free";
> c420f167 Andrey Ryabinin 2015-02-13 101 break;
> 828347f8 Dmitry Vyukov 2016-11-30 102 case KASAN_USE_AFTER_SCOPE:
> 828347f8 Dmitry Vyukov 2016-11-30 103 bug_type = "use-after-scope";
> 828347f8 Dmitry Vyukov 2016-11-30 104 break;
> 342061ee Paul Lawrence 2018-02-06 105 case KASAN_ALLOCA_LEFT:
> 342061ee Paul Lawrence 2018-02-06 106 case KASAN_ALLOCA_RIGHT:
> 342061ee Paul Lawrence 2018-02-06 107 bug_type = "alloca-out-of-bounds";
> 342061ee Paul Lawrence 2018-02-06 108 break;
> 0b24becc Andrey Ryabinin 2015-02-13 109 }
> 0b24becc Andrey Ryabinin 2015-02-13 110
> 5e82cd12 Andrey Konovalov 2017-05-03 111 return bug_type;
> 5e82cd12 Andrey Konovalov 2017-05-03 112 }
> 5e82cd12 Andrey Konovalov 2017-05-03 113
> 822d5ec2 Colin Ian King 2017-07-10 114 static const char *get_wild_bug_type(struct kasan_access_info *info)
> 5e82cd12 Andrey Konovalov 2017-05-03 115 {
> 5e82cd12 Andrey Konovalov 2017-05-03 116 const char *bug_type = "unknown-crash";
> 5e82cd12 Andrey Konovalov 2017-05-03 117
> 5e82cd12 Andrey Konovalov 2017-05-03 118 if ((unsigned long)info->access_addr < PAGE_SIZE)
> 5e82cd12 Andrey Konovalov 2017-05-03 119 bug_type = "null-ptr-deref";
> 5e82cd12 Andrey Konovalov 2017-05-03 120 else if ((unsigned long)info->access_addr < TASK_SIZE)
> 5e82cd12 Andrey Konovalov 2017-05-03 121 bug_type = "user-memory-access";
> 5e82cd12 Andrey Konovalov 2017-05-03 122 else
> 5e82cd12 Andrey Konovalov 2017-05-03 123 bug_type = "wild-memory-access";
> 5e82cd12 Andrey Konovalov 2017-05-03 124
> 5e82cd12 Andrey Konovalov 2017-05-03 125 return bug_type;
> 5e82cd12 Andrey Konovalov 2017-05-03 126 }
> 5e82cd12 Andrey Konovalov 2017-05-03 127
> 7d418f7b Andrey Konovalov 2017-05-03 @128 static const char *get_bug_type(struct kasan_access_info *info)
> 7d418f7b Andrey Konovalov 2017-05-03 129 {
> 7d418f7b Andrey Konovalov 2017-05-03 130 if (addr_has_shadow(info))
> 7d418f7b Andrey Konovalov 2017-05-03 131 return get_shadow_bug_type(info);
> 7d418f7b Andrey Konovalov 2017-05-03 132 return get_wild_bug_type(info);
> 7d418f7b Andrey Konovalov 2017-05-03 133 }
> 7d418f7b Andrey Konovalov 2017-05-03 134
>
> :::::: The code at line 42 was first introduced by commit
> :::::: 0b24becc810dc3be6e3f94103a866f214c282394 kasan: add kernel address sanitizer infrastructure
>
> :::::: TO: Andrey Ryabinin <a.ryabinin@samsung.com>
> :::::: CC: Linus Torvalds <torvalds@linux-foundation.org>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe at googlegroups.com.
> To post to this group, send email to kasan-dev at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/201806210451.tOaA22Qm%25fengguang.wu%40intel.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [RFC PATCH 2/3] dt: bindings: Add SD tap value properties details
From: Manish Narani @ 2018-06-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607124743.fqo7f7nxonn2k3b5@lakrids.cambridge.arm.com>
Hi Mark,
> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Thursday, June 7, 2018 6:18 PM
> To: Manish Narani <MNARANI@xilinx.com>
> Cc: robh+dt at kernel.org; catalin.marinas at arm.com; will.deacon at arm.com;
> mdf at kernel.org; stefan.krsmanovic at aggios.com; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> mmc at vger.kernel.org; devicetree at vger.kernel.org; adrian.hunter at intel.com;
> michal.simek at xilinx.com; ulf.hansson at linaro.org
> Subject: Re: [RFC PATCH 2/3] dt: bindings: Add SD tap value properties details
>
> On Thu, Jun 07, 2018 at 05:41:39PM +0530, Manish Narani wrote:
> > This patch adds details of SD tap value properties in device tree.
> >
> > Signed-off-by: Manish Narani <manish.narani@xilinx.com>
> > ---
> > .../devicetree/bindings/mmc/arasan,sdhci.txt | 26
> ++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > index 60481bf..0e08877 100644
> > --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > @@ -15,6 +15,8 @@ Required Properties:
> > - "arasan,sdhci-5.1": generic Arasan SDHCI 5.1 PHY
> > - "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC PHY
> > For this device it is strongly suggested to include arasan,soc-ctl-syscon.
> > + - "xlnx,zynqmp-8.9a": Xilinx ZynqMP Arasan SDHCI 8.9a PHY
> > + For this device it is strongly suggested to include arasan,soc-ctl-syscon.
> > - reg: From mmc bindings: Register location and length.
> > - clocks: From clock bindings: Handles to clock inputs.
> > - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb"
> > @@ -26,6 +28,30 @@ Required Properties for "arasan,sdhci-5.1":
> > - phys: From PHY bindings: Phandle for the Generic PHY for arasan.
> > - phy-names: MUST be "phy_arasan".
> >
> > +Required Properties for "xlnx,zynqmp-8.9a":
> > + - xlnx,mio_bank: The value will be 0/1/2 depending on MIO bank selection.
>
> For all of these properties, please s/_/-/, folowing the usual property name
> conventions.
I will correct this in the next version.
>
> It's not clear to me why you need this property. The code in patch 3 only seems
> to use this to determine which properties to read, choosing between <prop>_b0
> or <prop>_b2. I don't see why you dont have the base <prop> alone...
The property 'xlnx,mio_bank' will be different for various ZynqMP varients. So different ZynqMP dts files may have different values for 'xlnx,mio_bank'. That's why I am maintaining _b0 and _b2 as different values
>
> Is this a HW detail, or configuration that you prefer?
These are SD tap values which are generally used for configuring taps in SD. Keeping it in device tree makes it User Configurable without changing the driver code.
>
> > + - xlnx,device_id: Unique Id of the device, value will be 0/1.
>
> What's this used for?
This used to identify the controller ID between two SD controllers present on ZynqMP.
>
> > + - xlnx,itap_delay_sd_hsd: Input Tap Delay for SD HS.
>
> What unit at hese delays in?
The tap values don't have specific units. They are generally a fraction of the clock cycle.
For the SD frequency of -
200 MHz: 30 Input taps are available
100 MHz: 60 Input taps are available
50 MHz: 120 Input taps are available
200 MHz: 8 Output taps are available
100 MHz: 15 Output taps are available
50 MHz: 30 Output taps are available
Thanks,
Manish
>
> Please follow the conventions in
> Documentation/devicetree/bindings/property-units.txt.
>
> > + - xlnx,itap_delay_sdr25: Input Tap Delay for SDR25.
> > + - xlnx,itap_delay_sdr50: Input Tap Delay for SDR50.
> > + - xlnx,itap_delay_sdr104_b0: Input Tap Delay for SDR104.
> > + - xlnx,itap_delay_sdr104_b2: Input Tap Delay for SDR104.
>
> As above, Given you have to specify the bank, I don't see why you need multiple
> properties.
>
> Thanks,
> Mark.
>
> > + - xlnx,itap_delay_sd_ddr50: Input Tap Delay for SD DDR50.
> > + - xlnx,itap_delay_mmc_hsd: Input Tap Delay for MMC HS.
> > + - xlnx,itap_delay_mmc_ddr50: Input Tap Delay for MMC DDR50.
> > + - xlnx,itap_delay_mmc_hs200_b0: Input Tap Delay for MMC HS200.
> > + - xlnx,itap_delay_mmc_hs200_b2: Input Tap Delay for MMC HS200.
> > + - xlnx,otap_delay_sd_hsd: Output Tap Delay for SD HS.
> > + - xlnx,otap_delay_sdr25: Output Tap Delay for SDR25.
> > + - xlnx,otap_delay_sdr50: Output Tap Delay for SDR50.
> > + - xlnx,otap_delay_sdr104_b0: Output Tap Delay for SDR104.
> > + - xlnx,otap_delay_sdr104_b2: Output Tap Delay for SDR104.
> > + - xlnx,otap_delay_sd_ddr50: Output Tap Delay for DDR50.
> > + - xlnx,otap_delay_mmc_hsd: Output Tap Delay for MMC HS.
> > + - xlnx,otap_delay_mmc_ddr50: Output Tap Delay for MMC DDR50.
> > + - xlnx,otap_delay_mmc_hs200_b0: Output Tap Delay for MMC HS200.
> > + - xlnx,otap_delay_mmc_hs200_b2: Output Tap Delay for MMC HS200.
> > +
> > Optional Properties:
> > - arasan,soc-ctl-syscon: A phandle to a syscon device (see ../mfd/syscon.txt)
> > used to access core corecfg registers. Offsets of registers in
> > this
> > --
> > 2.7.4
^ 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