* Re: [PATCH v4 15/26] arm64: mte: Allow user control of the tag check mode via prctl()
From: Will Deacon @ 2020-05-27 7:46 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, Szabolcs Nagy, Andrey Konovalov, Kevin Brodsky,
linux-mm, Vincenzo Frascino, Peter Collingbourne, Dave P Martin,
linux-arm-kernel
In-Reply-To: <20200515171612.1020-16-catalin.marinas@arm.com>
On Fri, May 15, 2020 at 06:16:01PM +0100, Catalin Marinas wrote:
> By default, even if PROT_MTE is set on a memory range, there is no tag
> check fault reporting (SIGSEGV). Introduce a set of option to the
> exiting prctl(PR_SET_TAGGED_ADDR_CTRL) to allow user control of the tag
> check fault mode:
>
> PR_MTE_TCF_NONE - no reporting (default)
> PR_MTE_TCF_SYNC - synchronous tag check fault reporting
> PR_MTE_TCF_ASYNC - asynchronous tag check fault reporting
>
> These options translate into the corresponding SCTLR_EL1.TCF0 bitfield,
> context-switched by the kernel. Note that uaccess done by the kernel is
> not checked and cannot be configured by the user.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
>
> Notes:
> v3:
> - Use SCTLR_EL1_TCF0_NONE instead of 0 for consistency.
> - Move mte_thread_switch() in this patch from an earlier one. In
> addition, it is called after the dsb() in __switch_to() so that any
> asynchronous tag check faults have been registered in the TFSR_EL1
> registers (to be added with the in-kernel MTE support.
>
> v2:
> - Handle SCTLR_EL1_TCF0_NONE explicitly for consistency with PR_MTE_TCF_NONE.
> - Fix SCTLR_EL1 register setting in flush_mte_state() (thanks to Peter
> Collingbourne).
> - Added ISB to update_sctlr_el1_tcf0() since, with the latest
> architecture update/fix, the TCF0 field is used by the uaccess
> routines.
>
> arch/arm64/include/asm/mte.h | 14 ++++++
> arch/arm64/include/asm/processor.h | 3 ++
> arch/arm64/kernel/mte.c | 77 ++++++++++++++++++++++++++++++
> arch/arm64/kernel/process.c | 26 ++++++++--
> include/uapi/linux/prctl.h | 6 +++
> 5 files changed, 123 insertions(+), 3 deletions(-)
Dave is working on man pages for prctl() (and I think also ptrace). I think
it would be /very/ useful for us to have some RFC patches on top of his work
adding documentation for the MTE interactions, as we found some other minor
issues/inconsistencies as a direct result of writing and reviewing the man
page for our existing interfaces.
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFCv2 0/9] kvm/arm64: Support Async Page Fault
From: Marc Zyngier @ 2020-05-27 7:48 UTC (permalink / raw)
To: Gavin Shan
Cc: Mark Rutland, aarcange, drjones, suzuki.poulose, catalin.marinas,
linux-kernel, eric.auger, james.morse, shan.gavin, pbonzini, will,
kvmarm, linux-arm-kernel
In-Reply-To: <987785b2-2533-c3d8-8f6a-4193aa82d502@redhat.com>
On 2020-05-27 03:39, Gavin Shan wrote:
> Hi Mark,
[...]
>> Can you run tests with a real workload? For example, a kernel build
>> inside the VM?
>>
>
> Yeah, I agree it's far from a realistic workload. However, it's the
> test case
> which was suggested when async page fault was proposed from day one,
> according
> to the following document. On the page#34, you can see the benchmark,
> which is
> similar to what we're doing.
>
> https://www.linux-kvm.org/images/a/ac/2010-forum-Async-page-faults.pdf
My own question is whether this even makes any sense 10 years later.
The HW has massively changed, and this adds a whole lot of complexity
to both the hypervisor and the guest. It also plays very ugly games
with the exception model, which doesn't give me the warm fuzzy feeling
that it's going to be great.
> Ok. I will test with the workload to build kernel or another better one
> to
> represent the case.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2] arm64/cpufeature: Add get_arm64_ftr_reg_nowarn()
From: Will Deacon @ 2020-05-27 7:53 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mark.rutland, Suzuki K Poulose, Catalin Marinas, linux-kernel,
Mark Brown, linux-arm-kernel
In-Reply-To: <ca38b2c0-533f-9b98-46a2-37ba8bf21d83@arm.com>
On Wed, May 27, 2020 at 07:56:30AM +0530, Anshuman Khandual wrote:
>
>
> On 05/27/2020 01:16 AM, Will Deacon wrote:
> > On Tue, May 26, 2020 at 04:01:35PM +0100, Catalin Marinas wrote:
> >> On Tue, May 26, 2020 at 07:09:13PM +0530, Anshuman Khandual wrote:
> >>> @@ -632,8 +654,6 @@ static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
> >>> const struct arm64_ftr_bits *ftrp;
> >>> struct arm64_ftr_reg *reg = get_arm64_ftr_reg(sys_reg);
> >>>
> >>> - BUG_ON(!reg);
> >>> -
> >>> for (ftrp = reg->ftr_bits; ftrp->width; ftrp++) {
> >>> u64 ftr_mask = arm64_ftr_mask(ftrp);
> >>> s64 ftr_new = arm64_ftr_value(ftrp, new);
> >>> @@ -762,7 +782,6 @@ static int check_update_ftr_reg(u32 sys_id, int cpu, u64 val, u64 boot)
> >>> {
> >>> struct arm64_ftr_reg *regp = get_arm64_ftr_reg(sys_id);
> >>>
> >>> - BUG_ON(!regp);
> >>> update_cpu_ftr_reg(regp, val);
> >>> if ((boot & regp->strict_mask) == (val & regp->strict_mask))
> >>> return 0;
> >>> @@ -776,9 +795,6 @@ static void relax_cpu_ftr_reg(u32 sys_id, int field)
> >>> const struct arm64_ftr_bits *ftrp;
> >>> struct arm64_ftr_reg *regp = get_arm64_ftr_reg(sys_id);
> >>>
> >>> - if (WARN_ON(!regp))
> >>> - return;
> >>
> >> I think Will wanted an early return in all these functions not just
> >> removing the BUG_ON(). I'll let him clarify.
> >
> > Yes, the callers need to check the pointer and return early.
>
> Sure, will do. But for check_update_ftr_reg(), a feature register search
> failure should be treated as a success (0) or a failure (1). What should
> it return ? Seems bit tricky, as there are good reasons to go either way.
We're unable to check it so return 0, otherwise we'll randomly taint the
kernel and print a weird message.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH for-5.8 1/2] usb: dwc3: meson-g12a: fix error path when fetching the reset line fails
From: Neil Armstrong @ 2020-05-27 7:53 UTC (permalink / raw)
To: Martin Blumenstingl, balbi, gregkh, linux-usb, linux-amlogic
Cc: hanjie.lin, linux-kernel, linux-arm-kernel, yue.wang
In-Reply-To: <20200526202943.715220-2-martin.blumenstingl@googlemail.com>
On 26/05/2020 22:29, Martin Blumenstingl wrote:
> Disable and unprepare the clocks when devm_reset_control_get_shared()
> fails. This fixes the error path as this must disable the clocks which
> were previously enabled.
>
> Fixes: 1e355f21d3fb96 ("usb: dwc3: Add Amlogic A1 DWC3 glue")
> Cc: Yue Wang <yue.wang@amlogic.com>
> Cc: Hanjie Lin <hanjie.lin@amlogic.com>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> drivers/usb/dwc3/dwc3-meson-g12a.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c b/drivers/usb/dwc3/dwc3-meson-g12a.c
> index bd744e82cad4..ce5388338389 100644
> --- a/drivers/usb/dwc3/dwc3-meson-g12a.c
> +++ b/drivers/usb/dwc3/dwc3-meson-g12a.c
> @@ -738,7 +738,7 @@ static int dwc3_meson_g12a_probe(struct platform_device *pdev)
> if (IS_ERR(priv->reset)) {
> ret = PTR_ERR(priv->reset);
> dev_err(dev, "failed to get device reset, err=%d\n", ret);
> - return ret;
> + goto err_disable_clks;
> }
>
> ret = reset_control_reset(priv->reset);
>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Allow in-atomic injection of SPIs
From: Marc Zyngier @ 2020-05-27 7:55 UTC (permalink / raw)
To: Zenghui Yu
Cc: kvm, Suzuki K Poulose, Eric Auger, James Morse, Julien Thierry,
kernel-team, kvmarm, linux-arm-kernel
In-Reply-To: <47d6d521-f05e-86fe-4a94-ce21754100ae@huawei.com>
Hi Zenghui,
On 2020-05-27 08:41, Zenghui Yu wrote:
> On 2020/5/27 0:11, Marc Zyngier wrote:
>> On a system that uses SPIs to implement MSIs (as it would be
>> the case on a GICv2 system exposing a GICv2m to its guests),
>> we deny the possibility of injecting SPIs on the in-atomic
>> fast-path.
>>
>> This results in a very large amount of context-switches
>> (roughly equivalent to twice the interrupt rate) on the host,
>> and suboptimal performance for the guest (as measured with
>> a test workload involving a virtio interface backed by vhost-net).
>> Given that GICv2 systems are usually on the low-end of the spectrum
>> performance wise, they could do without the aggravation.
>>
>> We solved this for GICv3+ITS by having a translation cache. But
>> SPIs do not need any extra infrastructure, and can be immediately
>> injected in the virtual distributor as the locking is already
>> heavy enough that we don't need to worry about anything.
>>
>> This halves the number of context switches for the same workload.
>>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> ---
>> arch/arm64/kvm/vgic/vgic-irqfd.c | 20 ++++++++++++++++----
>> arch/arm64/kvm/vgic/vgic-its.c | 3 +--
>> 2 files changed, 17 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/vgic/vgic-irqfd.c
>> b/arch/arm64/kvm/vgic/vgic-irqfd.c
>> index d8cdfea5cc96..11a9f81115ab 100644
>> --- a/arch/arm64/kvm/vgic/vgic-irqfd.c
>> +++ b/arch/arm64/kvm/vgic/vgic-irqfd.c
>> @@ -107,15 +107,27 @@ int kvm_arch_set_irq_inatomic(struct
>> kvm_kernel_irq_routing_entry *e,
>> struct kvm *kvm, int irq_source_id, int level,
>> bool line_status)
>
> ... and you may also need to update the comment on top of it to
> reflect this change.
>
> /**
> * kvm_arch_set_irq_inatomic: fast-path for irqfd injection
> *
> * Currently only direct MSI injection is supported.
> */
As far as I can tell, it is still valid (at least from the guest's
perspective). You could in practice use that to deal with level
interrupts, but we only inject the rising edge on this path, never
the falling edge. So effectively, this is limited to edge interrupts,
which is mostly MSIs.
Unless you are thinking of something else which I would have missed?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pinctrl: Add bindings for mscc, ocelot-sgpio
From: Lars Povlsen @ 2020-05-27 8:05 UTC (permalink / raw)
To: Linus Walleij
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Belloni, linux-kernel@vger.kernel.org,
Microchip Linux Driver Support, open list:GPIO SUBSYSTEM,
SoC Team, Rob Herring, Linux ARM, Lars Povlsen
In-Reply-To: <CACRpkdaJvaqPptPD-A1DriVgBOZGZ4Qf0UsbsjG39ptx6bSJKg@mail.gmail.com>
Linus Walleij writes:
> On Mon, May 25, 2020 at 4:38 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
>
>> Yes, the problem is they're not in sequence. F.ex. you could have ports
>> 0,1 enabled, skip 2,3,4 and have 5,6,7 enabled.
>
> Just use disabled nodes.
>
> That would look like this in my idea of a device tree:
>
> pinctrl@nnn {
> gpio0: gpio@0 {
> compatible = "foo";
> status = "ok";
> ....
> };
> gpio1: gpio@1 {
> compatible = "foo";
> status = "ok";
> ....
> };
> gpio2: gpio@2 {
> compatible = "foo";
> status = "disabled";
> ....
> };
> gpio3: gpio@3 {
> compatible = "foo";
> status = "disabled";
> ....
> };
> gpio4: gpio@4 {
> compatible = "foo";
> status = "disabled";
> ....
> };
> gpio5: gpio@5 {
> compatible = "foo";
> status = "ok";
> ....
> };
> gpio6: gpio@6 {
> compatible = "foo";
> status = "ok";
> ....
> };
> gpio7: gpio@7 {
> compatible = "foo";
> status = "ok";
> ....
> };
> };
>
> It is common to use the status to enable/disable nodes like this.
>
> In the Linux kernel is is possible to iterate over these subnodes and
> check which ones are enabled and disabled while keeping the
> index by using something like:
>
> i = 0;
> struct device_node *np, *child;
> for_each_child_of_node(np, child) {
> if (of_device_is_available(child)) {
> pr_info("populating device %d\n", i);
> }
> i++;
> }
>
> Certainly you can use i in the above loop to populate your registers
> etc from an indexed array.
>
> This way the consumers can pick their GPIO from the right port
> and everything just using e.g.
> my-gpios = <&gpio6 4 GPIO_OUT_LOW>;
>
Linux, thank you for your input, it is much appreciated. I will use the
pattern in the driver in the next revision.
The only issue is that the gpios on the same "port" have restrictions on
their status - they can only be enabled "all" or "none" for gpios that
map to the same port. F.ex. gpio0, gpio32, gpio64 and gpio96 must all be
enabled or disabled because at the hardware level you control the
_port_. But as I noted earlier, that could just be the driver enforcing
this.
Thanks again.
---Lars
> Yours,
> Linus Walleij
--
Lars Povlsen,
Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] media: omap3isp: Shuffle cacheflush.h and include mm.h
From: Nathan Chancellor @ 2020-05-27 8:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-ia64@vger.kernel.org, Linux-sh list, Roman Zippel,
Linux Kernel Mailing List, Linux MM, Laurent Pinchart, sparclinux,
linux-riscv, Christoph Hellwig, Linux-Arch, linux-c6x-dev,
open list:QUALCOMM HEXAGON..., the arch/x86 maintainers,
open list:TENSILICA XTENSA PORT (xtensa), Arnd Bergmann, alpha,
linux-um, linux-m68k, Openrisc, Linux ARM, Michal Simek,
open list:BROADCOM NVRAM DRIVER, Jessica Yu, Linux FS Devel,
Andrew Morton, linuxppc-dev
In-Reply-To: <CAMuHMdVSduTOi5bUgF9sLQdGADwyL1+qALWsKgin1TeOLGhAKQ@mail.gmail.com>
Hi Geert,
On Wed, May 27, 2020 at 09:02:51AM +0200, Geert Uytterhoeven wrote:
> Hi Nathan,
>
> CC Laurent
>
> On Wed, May 27, 2020 at 6:37 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> > After mm.h was removed from the asm-generic version of cacheflush.h,
> > s390 allyesconfig shows several warnings of the following nature:
> >
> > In file included from ./arch/s390/include/generated/asm/cacheflush.h:1,
> > from drivers/media/platform/omap3isp/isp.c:42:
> > ./include/asm-generic/cacheflush.h:16:42: warning: 'struct mm_struct'
> > declared inside parameter list will not be visible outside of this
> > definition or declaration
> >
> > cacheflush.h does not include mm.h nor does it include any forward
> > declaration of these structures hence the warning. To avoid this,
> > include mm.h explicitly in this file and shuffle cacheflush.h below it.
> >
> > Fixes: 19c0054597a0 ("asm-generic: don't include <linux/mm.h> in cacheflush.h")
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Thanks for your patch!
>
> > I am aware the fixes tag is kind of irrelevant because that SHA will
> > change in the next linux-next revision and this will probably get folded
> > into the original patch anyways but still.
> >
> > The other solution would be to add forward declarations of these structs
> > to the top of cacheflush.h, I just chose to do what Christoph did in the
> > original patch. I am happy to do that instead if you all feel that is
> > better.
>
> That actually looks like a better solution to me, as it would address the
> problem for all users.
>
> > drivers/media/platform/omap3isp/isp.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c
> > index a4ee6b86663e..54106a768e54 100644
> > --- a/drivers/media/platform/omap3isp/isp.c
> > +++ b/drivers/media/platform/omap3isp/isp.c
> > @@ -39,8 +39,6 @@
> > * Troy Laramy <t-laramy@ti.com>
> > */
> >
> > -#include <asm/cacheflush.h>
> > -
> > #include <linux/clk.h>
> > #include <linux/clkdev.h>
> > #include <linux/delay.h>
> > @@ -49,6 +47,7 @@
> > #include <linux/i2c.h>
> > #include <linux/interrupt.h>
> > #include <linux/mfd/syscon.h>
> > +#include <linux/mm.h>
> > #include <linux/module.h>
> > #include <linux/omap-iommu.h>
> > #include <linux/platform_device.h>
> > @@ -58,6 +57,8 @@
> > #include <linux/sched.h>
> > #include <linux/vmalloc.h>
> >
> > +#include <asm/cacheflush.h>
> > +
> > #ifdef CONFIG_ARM_DMA_USE_IOMMU
> > #include <asm/dma-iommu.h>
> > #endif
>
> Why does this file need <asm/cacheflush.h> at all?
> It doesn't call any of the flush_*() functions, and seems to compile fine
> without (on arm32).
>
> Perhaps it was included at the top intentionally, to override the definitions
> of copy_{to,from}_user_page()? Fortunately that doesn't seem to be the
> case, from a quick look at the assembler output.
>
> So let's just remove the #include instead?
Sounds good to me. I can send a patch if needed or I suppose Andrew can
just make a small fixup patch for it. Let me know what I should do.
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH for-5.8 2/2] usb: dwc3: meson-g12a: fix USB2 PHY initialization on G12A and A1 SoCs
From: Neil Armstrong @ 2020-05-27 8:17 UTC (permalink / raw)
To: balbi, gregkh
Cc: hanjie.lin, kernelci.org bot, Martin Blumenstingl, linux-usb,
linux-kernel, yue.wang, linux-amlogic, linux-arm-kernel
In-Reply-To: <20200526202943.715220-3-martin.blumenstingl@googlemail.com>
Hi Martin,
On 26/05/2020 22:29, Martin Blumenstingl wrote:
> dwc3_meson_g12a_usb2_init_phy() crashes with NULL pointer on an SM1
> board (which uses the same USB setup as G12A) dereference as reported
> by the Kernel CI bot. This is because of the following call flow:
> dwc3_meson_g12a_probe
> priv->drvdata->setup_regmaps
> dwc3_meson_g12a_setup_regmaps
> priv->usb2_ports is still 0 so priv->u2p_regmap[i] will be NULL
> dwc3_meson_g12a_get_phys
> initializes priv->usb2_ports
> priv->drvdata->usb_init
> dwc3_meson_g12a_usb_init
> dwc3_meson_g12a_usb_init_glue
> dwc3_meson_g12a_usb2_init
> priv->drvdata->usb2_init_phy
> dwc3_meson_g12a_usb2_init_phy
> dereferences priv->u2p_regmap[i]
>
> Call priv->drvdata->setup_regmaps only after dwc3_meson_g12a_get_phys so
> priv->usb2_ports is initialized and the regmaps will be set up
> correctly. This fixes the NULL dereference later on.
>
> Fixes: 013af227f58a97 ("usb: dwc3: meson-g12a: handle the phy and glue registers separately")
> Reported-by: "kernelci.org bot" <bot@kernelci.org>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> drivers/usb/dwc3/dwc3-meson-g12a.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c b/drivers/usb/dwc3/dwc3-meson-g12a.c
> index ce5388338389..1f7f4d88ed9d 100644
> --- a/drivers/usb/dwc3/dwc3-meson-g12a.c
> +++ b/drivers/usb/dwc3/dwc3-meson-g12a.c
[...]
Fixes regression reported at [1] on SEI510 board based on Amlogic G12A.
Felipe, Greg, can this be queued on uxb-next for 5.8 ?
Acked-by: Neil Armstrong <narmstron@baylibre.com>
Thanks,
Neil
[1] http://lore.kernel.org/r/ffe2c64c-62ed-9b59-3754-7ede0f0203be@collabora.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 15/26] arm64: mte: Allow user control of the tag check mode via prctl()
From: Dave Martin @ 2020-05-27 8:32 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, Szabolcs Nagy, Catalin Marinas, Kevin Brodsky,
linux-mm, Andrey Konovalov, Vincenzo Frascino,
Peter Collingbourne, linux-arm-kernel
In-Reply-To: <20200527074658.GB9887@willie-the-truck>
On Wed, May 27, 2020 at 08:46:59AM +0100, Will Deacon wrote:
> On Fri, May 15, 2020 at 06:16:01PM +0100, Catalin Marinas wrote:
> > By default, even if PROT_MTE is set on a memory range, there is no tag
> > check fault reporting (SIGSEGV). Introduce a set of option to the
> > exiting prctl(PR_SET_TAGGED_ADDR_CTRL) to allow user control of the tag
> > check fault mode:
> >
> > PR_MTE_TCF_NONE - no reporting (default)
> > PR_MTE_TCF_SYNC - synchronous tag check fault reporting
> > PR_MTE_TCF_ASYNC - asynchronous tag check fault reporting
> >
> > These options translate into the corresponding SCTLR_EL1.TCF0 bitfield,
> > context-switched by the kernel. Note that uaccess done by the kernel is
> > not checked and cannot be configured by the user.
> >
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > ---
> >
> > Notes:
> > v3:
> > - Use SCTLR_EL1_TCF0_NONE instead of 0 for consistency.
> > - Move mte_thread_switch() in this patch from an earlier one. In
> > addition, it is called after the dsb() in __switch_to() so that any
> > asynchronous tag check faults have been registered in the TFSR_EL1
> > registers (to be added with the in-kernel MTE support.
> >
> > v2:
> > - Handle SCTLR_EL1_TCF0_NONE explicitly for consistency with PR_MTE_TCF_NONE.
> > - Fix SCTLR_EL1 register setting in flush_mte_state() (thanks to Peter
> > Collingbourne).
> > - Added ISB to update_sctlr_el1_tcf0() since, with the latest
> > architecture update/fix, the TCF0 field is used by the uaccess
> > routines.
> >
> > arch/arm64/include/asm/mte.h | 14 ++++++
> > arch/arm64/include/asm/processor.h | 3 ++
> > arch/arm64/kernel/mte.c | 77 ++++++++++++++++++++++++++++++
> > arch/arm64/kernel/process.c | 26 ++++++++--
> > include/uapi/linux/prctl.h | 6 +++
> > 5 files changed, 123 insertions(+), 3 deletions(-)
>
> Dave is working on man pages for prctl() (and I think also ptrace). I think
> it would be /very/ useful for us to have some RFC patches on top of his work
> adding documentation for the MTE interactions, as we found some other minor
> issues/inconsistencies as a direct result of writing and reviewing the man
> page for our existing interfaces.
I have a local draft for the address tagging and MTE prctls already btw.
I hadn't posted them yet so as to focus on nailing the "easy" stuff down
;)
If I have time I'll try and get them posted today so that people can
take a look before next week.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v9] Add matrix keypad driver support for Mediatek SoCs
From: Fengping Yu @ 2020-05-27 8:31 UTC (permalink / raw)
To: Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: linux-mediatek, linux-arm-kernel, linux-input
Change since v8:
- update keypad config dependent items
- remove useless comment about debounce time
- use internal function as devm_add_action_or_reset callback
- remove input_set_drvdata
- remove redundant log
- add missing whitespace with compatible sentinel string
fengping.yu (3):
dt-bindings: Add keypad devicetree documentation
drivers: input: keyboard: Add mtk keypad driver
configs: defconfig: Add CONFIG_KEYBOARD_MTK_KPD=m
.../devicetree/bindings/input/mtk-kpd.yaml | 94 ++++++++
arch/arm64/configs/defconfig | 1 +
drivers/input/keyboard/Kconfig | 11 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/mtk-kpd.c | 219 ++++++++++++++++++
5 files changed, 326 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/mtk-kpd.yaml
create mode 100644 drivers/input/keyboard/mtk-kpd.c
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 5/9] clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate
From: Stephen Boyd @ 2020-05-27 8:35 UTC (permalink / raw)
To: airlied, alexandre.torgue, andy.shevchenko, broonie, daniel,
dillon.minfei, linus.walleij, mcoquelin.stm32, mturquette, noralf,
p.zabel, robh+dt, sam, thierry.reding
Cc: devicetree, dillonhua, linux-clk, linux-kernel, dri-devel,
linux-spi, dillon min, linux-stm32, linux-arm-kernel
In-Reply-To: <1590564453-24499-6-git-send-email-dillon.minfei@gmail.com>
Quoting dillon.minfei@gmail.com (2020-05-27 00:27:29)
> From: dillon min <dillon.minfei@gmail.com>
>
> This is due to misuse \u2018PLL_VCO_SAI' and'PLL_SAI' in clk-stm32f4.c
> 'PLL_SAI' is 2, 'PLL_VCO_SAI' is 7(defined in
> include/dt-bindings/clock/stm32fx-clock.h).
>
> 'post_div' point to 'post_div_data[]', 'post_div->pll_num'
> is PLL_I2S or PLL_SAI.
>
> 'clks[PLL_VCO_SAI]' has valid 'struct clk_hw* ' return
> from stm32f4_rcc_register_pll() but, at line 1777 of
> driver/clk/clk-stm32f4.c, use the 'clks[post_div->pll_num]',
> equal to 'clks[PLL_SAI]', this is invalid array member at that time.
>
> Fixes: 517633ef630e ("clk: stm32f4: Add post divisor for I2S & SAI PLLs")
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 6/9] clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after kernel startup
From: Stephen Boyd @ 2020-05-27 8:35 UTC (permalink / raw)
To: airlied, alexandre.torgue, andy.shevchenko, broonie, daniel,
dillon.minfei, linus.walleij, mcoquelin.stm32, mturquette, noralf,
p.zabel, robh+dt, sam, thierry.reding
Cc: devicetree, dillonhua, linux-clk, linux-kernel, dri-devel,
linux-spi, dillon min, linux-stm32, linux-arm-kernel
In-Reply-To: <1590564453-24499-7-git-send-email-dillon.minfei@gmail.com>
Quoting dillon.minfei@gmail.com (2020-05-27 00:27:30)
> From: dillon min <dillon.minfei@gmail.com>
>
> stm32's clk driver register two ltdc gate clk to clk core by
> clk_hw_register_gate() and clk_hw_register_composite()
>
> first: 'stm32f429_gates[]', clk name is 'ltdc', which no user to use.
> second: 'stm32f429_aux_clk[]', clk name is 'lcd-tft', used by ltdc driver
>
> both of them point to the same offset of stm32's RCC register. after
> kernel enter console, clk core turn off ltdc's clk as 'stm32f429_gates[]'
> is no one to use. but, actually 'stm32f429_aux_clk[]' is in use.
>
> Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v9 2/3] drivers: input: keyboard: Add mtk keypad driver
From: Fengping Yu @ 2020-05-27 8:31 UTC (permalink / raw)
To: Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-arm-kernel, linux-input
In-Reply-To: <20200527083137.56566-1-fengping.yu@mediatek.com>
From: "fengping.yu" <fengping.yu@mediatek.com>
This adds matrix keypad support for Mediatek SoCs.
Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
---
drivers/input/keyboard/Kconfig | 11 ++
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/mtk-kpd.c | 219 +++++++++++++++++++++++++++++++
3 files changed, 231 insertions(+)
create mode 100644 drivers/input/keyboard/mtk-kpd.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 28de965a08d5..f4f58320d14f 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -782,6 +782,17 @@ config KEYBOARD_BCM
To compile this driver as a module, choose M here: the
module will be called bcm-keypad.
+config KEYBOARD_MTK_KPD
+ tristate "MediaTek Keypad Support"
+ depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
+ select CONFIG_REGMAP_MMIO
+ select INPUT_MATRIXKMAP
+ help
+ Say Y here if you want to use the keypad on MediaTek SoCs.
+ If unsure, say N.
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-kpd.
+
config KEYBOARD_MTK_PMIC
tristate "MediaTek PMIC keys support"
depends on MFD_MT6397
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 1d689fdd5c00..6c9d852c377e 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_KEYBOARD_MATRIX) += matrix_keypad.o
obj-$(CONFIG_KEYBOARD_MAX7359) += max7359_keypad.o
obj-$(CONFIG_KEYBOARD_MCS) += mcs_touchkey.o
obj-$(CONFIG_KEYBOARD_MPR121) += mpr121_touchkey.o
+obj-$(CONFIG_KEYBOARD_MTK_KPD) += mtk-kpd.o
obj-$(CONFIG_KEYBOARD_MTK_PMIC) += mtk-pmic-keys.o
obj-$(CONFIG_KEYBOARD_NEWTON) += newtonkbd.o
obj-$(CONFIG_KEYBOARD_NOMADIK) += nomadik-ske-keypad.o
diff --git a/drivers/input/keyboard/mtk-kpd.c b/drivers/input/keyboard/mtk-kpd.c
new file mode 100644
index 000000000000..6e18aad1f476
--- /dev/null
+++ b/drivers/input/keyboard/mtk-kpd.c
@@ -0,0 +1,219 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 MediaTek Inc.
+ * Author Terry Chang <terry.chang@mediatek.com>
+ */
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/input/matrix_keypad.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define MTK_KPD_NAME "mtk-kpd"
+#define MTK_KPD_MEM 0x0004
+#define MTK_KPD_DEBOUNCE 0x0018
+#define MTK_KPD_DEBOUNCE_MASK GENMASK(13, 0)
+#define MTK_KPD_DEBOUNCE_MAX_US 256000
+#define MTK_KPD_NUM_MEMS 5
+#define MTK_KPD_NUM_BITS 136 /* 4*32+8 MEM5 only use 8 BITS */
+
+struct mtk_keypad {
+ struct regmap *regmap;
+ struct input_dev *input_dev;
+ struct clk *clk;
+ void __iomem *base;
+ bool wakeup;
+ u32 n_rows;
+ u32 n_cols;
+ DECLARE_BITMAP(keymap_state, MTK_KPD_NUM_BITS);
+};
+
+static const struct regmap_config keypad_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = 36,
+};
+
+static irqreturn_t kpd_irq_handler(int irq, void *dev_id)
+{
+ struct mtk_keypad *keypad = dev_id;
+ unsigned short *keycode = keypad->input_dev->keycode;
+ DECLARE_BITMAP(new_state, MTK_KPD_NUM_BITS);
+ DECLARE_BITMAP(change, MTK_KPD_NUM_BITS);
+ int bit_nr;
+ int pressed;
+ unsigned short code;
+
+ regmap_raw_read(keypad->regmap, MTK_KPD_MEM,
+ new_state, MTK_KPD_NUM_MEMS);
+
+ bitmap_xor(change, new_state, keypad->keymap_state, MTK_KPD_NUM_BITS);
+
+ for_each_set_bit(bit_nr, change, MTK_KPD_NUM_BITS) {
+ /* 1: not pressed, 0: pressed */
+ pressed = !test_bit(bit_nr, new_state);
+ dev_dbg(&keypad->input_dev->dev, "%s",
+ pressed ? "pressed" : "released");
+
+ /* 32bit register only use low 16bit as keypad mem register */
+ code = keycode[bit_nr - 16 * (BITS_TO_U32(bit_nr) - 1)];
+
+ input_report_key(keypad->input_dev, code, pressed);
+ input_sync(keypad->input_dev);
+
+ dev_dbg(&keypad->input_dev->dev,
+ "report Linux keycode = %d\n", code);
+ }
+
+ bitmap_copy(keypad->keymap_state, new_state, MTK_KPD_NUM_BITS);
+
+ return IRQ_HANDLED;
+}
+
+static void kpd_clk_disable(void *data)
+{
+ clk_disable_unprepare(data);
+}
+
+static int kpd_pdrv_probe(struct platform_device *pdev)
+{
+ struct mtk_keypad *keypad;
+ struct pinctrl *keypad_pinctrl;
+ struct pinctrl_state *kpd_default;
+ unsigned int irqnr;
+ u32 debounce;
+ int ret;
+
+ keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
+ if (!keypad)
+ return -ENOMEM;
+
+ keypad->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(keypad->base))
+ return PTR_ERR(keypad->base);
+
+ keypad->regmap = devm_regmap_init_mmio(&pdev->dev,
+ keypad->base,
+ &keypad_regmap_cfg);
+ if (IS_ERR(keypad->regmap)) {
+ dev_err(&pdev->dev,
+ "regmap init failed:%ld\n", PTR_ERR(keypad->regmap));
+ return PTR_ERR(keypad->regmap);
+ }
+
+ bitmap_fill(keypad->keymap_state, MTK_KPD_NUM_BITS);
+
+ keypad->input_dev = devm_input_allocate_device(&pdev->dev);
+ if (!keypad->input_dev) {
+ dev_err(&pdev->dev, "Failed to allocate input dev\n");
+ return -ENOMEM;
+ }
+
+ keypad->input_dev->name = MTK_KPD_NAME;
+ keypad->input_dev->id.bustype = BUS_HOST;
+
+ ret = matrix_keypad_parse_properties(&pdev->dev, &keypad->n_rows,
+ &keypad->n_cols);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to parse keypad params\n");
+ return ret;
+ }
+
+ if (device_property_read_u32(&pdev->dev, "mediatek,debounce-us",
+ &debounce))
+ debounce = 16000;
+
+ if (debounce > MTK_KPD_DEBOUNCE_MAX_US) {
+ dev_err(&pdev->dev, "Debounce time exceeds the maximum allowed time %dus\n",
+ MTK_KPD_DEBOUNCE_MAX_US);
+ return -EINVAL;
+ }
+
+ keypad->wakeup = device_property_read_bool(&pdev->dev, "wakeup-source");
+
+ dev_dbg(&pdev->dev, "n_row=%d n_col=%d debounce=%d\n",
+ keypad->n_rows, keypad->n_cols, debounce);
+
+ ret = matrix_keypad_build_keymap(NULL, NULL,
+ keypad->n_rows,
+ keypad->n_cols,
+ NULL,
+ keypad->input_dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to build keymap\n");
+ return ret;
+ }
+
+ regmap_write(keypad->regmap, KP_DEBOUNCE,
+ debounce * 32 / 1000 & MTK_KPD_DEBOUNCE_MASK);
+
+ keypad->clk = devm_clk_get(&pdev->dev, "kpd");
+ if (IS_ERR(clk))
+ return clk;
+
+ ret = clk_prepare_enable(keypad->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "cannot prepare/enable keypad clock\n");
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(&pdev->dev, kpd_clk_disable,
+ keypad->clk);
+ if (ret)
+ return ret;
+
+ keypad_pinctrl = devm_pinctrl_get(&pdev->dev);
+ if (IS_ERR(keypad_pinctrl))
+ return PTR_ERR(keypad_pinctrl);
+
+ kpd_default = pinctrl_lookup_state(keypad_pinctrl, "default");
+ if (IS_ERR(kpd_default))
+ return PTR_ERR(kpd_default);
+
+ pinctrl_select_state(keypad_pinctrl, kpd_default);
+
+ irqnr = platform_get_irq(pdev, 0);
+ if (irqnr < 0)
+ return -irqnr;
+
+ ret = devm_request_threaded_irq(&pdev->dev, irqnr,
+ NULL, kpd_irq_handler, 0,
+ MTK_KPD_NAME, keypad);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to request IRQ#%d:%d\n",
+ irqnr, ret);
+ return ret;
+ }
+
+ ret = input_register_device(keypad->input_dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to register device\n");
+ return ret;
+ }
+
+ return device_init_wakeup(&pdev->dev, keypad->wakeup);
+}
+
+static const struct of_device_id kpd_of_match[] = {
+ {.compatible = "mediatek, mt6779-keypad"},
+ {.compatible = "mediatek,kp"},
+ {/* sentinel */}
+};
+
+static struct platform_driver kpd_pdrv = {
+ .probe = kpd_pdrv_probe,
+ .driver = {
+ .name = MTK_KPD_NAME,
+ .of_match_table = kpd_of_match,
+ },
+};
+module_platform_driver(kpd_pdrv);
+
+MODULE_AUTHOR("Mediatek Corporation");
+MODULE_DESCRIPTION("MTK Keypad (KPD) Driver");
+MODULE_LICENSE("GPL");
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [RFC] Use SMMU HTTU for DMA dirty page tracking
From: Tian, Kevin @ 2020-05-27 8:40 UTC (permalink / raw)
To: Xiang Zheng, Jean-Philippe Brucker
Cc: Zhao, Yan Y, Suzuki K Poulose, maz@kernel.org,
iommu@lists.linux-foundation.org, Kirti Wankhede,
alex.williamson@redhat.com, James Morse,
linux-arm-kernel@lists.infradead.org, prime.zeng@hisilicon.com,
Wang Haibin, Will Deacon, kvmarm@lists.cs.columbia.edu,
julien.thierry.kdev@gmail.com
In-Reply-To: <897a84ac-0a71-ace7-e05b-3cc9f0b05c28@huawei.com>
> From: Xiang Zheng <zhengxiang9@huawei.com>
> Sent: Wednesday, May 27, 2020 2:45 PM
>
>
> On 2020/5/27 11:27, Tian, Kevin wrote:
> >> From: Xiang Zheng
> >> Sent: Monday, May 25, 2020 7:34 PM
> >>
> >> [+cc Kirti, Yan, Alex]
> >>
> >> On 2020/5/23 1:14, Jean-Philippe Brucker wrote:
> >>> Hi,
> >>>
> >>> On Tue, May 19, 2020 at 05:42:55PM +0800, Xiang Zheng wrote:
> >>>> Hi all,
> >>>>
> >>>> Is there any plan for enabling SMMU HTTU?
> >>>
> >>> Not outside of SVA, as far as I know.
> >>>
> >>
> >>>> I have seen the patch locates in the SVA series patch, which adds
> >>>> support for HTTU:
> >>>> https://www.spinics.net/lists/arm-kernel/msg798694.html
> >>>>
> >>>> HTTU reduces the number of access faults on SMMU fault queue
> >>>> (permission faults also benifit from it).
> >>>>
> >>>> Besides reducing the faults, HTTU also helps to track dirty pages for
> >>>> device DMA. Is it feasible to utilize HTTU to get dirty pages on device
> >>>> DMA during VFIO live migration?
> >>>
> >>> As you know there is a VFIO interface for this under discussion:
> >>> https://lore.kernel.org/kvm/1589781397-28368-1-git-send-email-
> >> kwankhede@nvidia.com/
> >>> It doesn't implement an internal API to communicate with the IOMMU
> >> driver
> >>> about dirty pages.
> >
> > We plan to add such API later, e.g. to utilize A/D bit in VT-d 2nd-level
> > page tables (Rev 3.0).
> >
>
> Thank you, Kevin.
>
> When will you send this series patches? Maybe(Hope) we can also support
> hardware-based dirty pages tracking via common APIs based on your
> patches. :)
Yan is working with Kirti on basic live migration support now. After that
part is done, we will start working on A/D bit support. Yes, common APIs
are definitely the goal here.
>
> >>
> >>>
> >>>> If SMMU can track dirty pages, devices are not required to implement
> >>>> additional dirty pages tracking to support VFIO live migration.
> >>>
> >>> It seems feasible, though tracking it in the device might be more
> >>> efficient. I might have misunderstood but I think for live migration of
> >>> the Intel NIC they trap guest accesses to the device and introspect its
> >>> state to figure out which pages it is accessing.
> >
> > Does HTTU implement A/D-like mechanism in SMMU page tables, or just
> > report dirty pages in a log buffer? Either way tracking dirty pages in IOMMU
> > side is generic thus doesn't require device-specific tweak like in Intel NIC.
> >
>
> Currently HTTU just implement A/D-like mechanism in SMMU page tables.
> We certainly
> expect SMMU can also implement PML-like feature so that we can avoid
> walking the
> whole page table to get the dirty pages.
Is there a link to HTTU introduction?
>
> By the way, I'm not sure whether HTTU or SLAD can help for mediated deivce.
>
A/D bit applies to mediated device on VT-d.
Thanks
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 03/26] KVM: arm64: Factor out stage 2 page table data from struct kvm
From: Marc Zyngier @ 2020-05-27 8:41 UTC (permalink / raw)
To: Alexandru Elisei
Cc: Mark Rutland, kvm, Suzuki K Poulose, Jintack Lim, Andre Przywara,
Christoffer Dall, Dave Martin, George Cherian, James Morse,
Julien Thierry, Zengtao (B), Catalin Marinas, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <6518439c-65b7-1e87-a21d-a053d75c0514@arm.com>
Hi Alex,
On 2020-05-12 17:53, Alexandru Elisei wrote:
> Hi,
>
> On 5/12/20 12:17 PM, James Morse wrote:
>> Hi Alex, Marc,
>>
>> (just on this last_vcpu_ran thing...)
>>
>> On 11/05/2020 17:38, Alexandru Elisei wrote:
>>> On 4/22/20 1:00 PM, Marc Zyngier wrote:
>>>> From: Christoffer Dall <christoffer.dall@arm.com>
>>>>
>>>> As we are about to reuse our stage 2 page table manipulation code
>>>> for
>>>> shadow stage 2 page tables in the context of nested virtualization,
>>>> we
>>>> are going to manage multiple stage 2 page tables for a single VM.
>>>>
>>>> This requires some pretty invasive changes to our data structures,
>>>> which moves the vmid and pgd pointers into a separate structure and
>>>> change pretty much all of our mmu code to operate on this structure
>>>> instead.
>>>>
>>>> The new structure is called struct kvm_s2_mmu.
>>>>
>>>> There is no intended functional change by this patch alone.
>>>> diff --git a/arch/arm64/include/asm/kvm_host.h
>>>> b/arch/arm64/include/asm/kvm_host.h
>>>> index 7dd8fefa6aecd..664a5d92ae9b8 100644
>>>> --- a/arch/arm64/include/asm/kvm_host.h
>>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>>> @@ -63,19 +63,32 @@ struct kvm_vmid {
>>>> u32 vmid;
>>>> };
>>>>
>>>> -struct kvm_arch {
>>>> +struct kvm_s2_mmu {
>>>> struct kvm_vmid vmid;
>>>>
>>>> - /* stage2 entry level table */
>>>> - pgd_t *pgd;
>>>> - phys_addr_t pgd_phys;
>>>> -
>>>> - /* VTCR_EL2 value for this VM */
>>>> - u64 vtcr;
>>>> + /*
>>>> + * stage2 entry level table
>>>> + *
>>>> + * Two kvm_s2_mmu structures in the same VM can point to the same
>>>> pgd
>>>> + * here. This happens when running a non-VHE guest hypervisor
>>>> which
>>>> + * uses the canonical stage 2 page table for both vEL2 and for
>>>> vEL1/0
>>>> + * with vHCR_EL2.VM == 0.
>>> It makes more sense to me to say that a non-VHE guest hypervisor will
>>> use the
>>> canonical stage *1* page table when running at EL2
>> Can KVM say anything about stage1? Its totally under the the guests
>> control even at vEL2...
>
> It just occurred to me that "canonical stage 2 page table" refers to
> the L0
> hypervisor stage 2, not to the L1 hypervisor stage 2. If you don't mind
> my
> suggestion, perhaps the comment can be slightly improved to avoid any
> confusion?
> Maybe something along the lines of "[..] This happens when running a
> non-VHE guest
> hypervisor, in which case we use the canonical stage 2 page table for
> both vEL2
> and for vEL1/0 with vHCR_EL2.VM == 0".
If the confusion stems from the lack of guest stage-2, how about:
"This happens when running a guest using a translation regime that isn't
affected by its own stage-2 translation, such as a non-VHE hypervisor
running at vEL2, or for vEL1/EL0 with vHCR_EL2.VM == 0. In that case,
we use the canonical stage-2 page tables."
instead? Does this lift the ambiguity?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 18/24] iommu/arm-smmu-v3: Add support for Hardware Translation Table Update
From: Jean-Philippe Brucker @ 2020-05-27 8:41 UTC (permalink / raw)
To: Xiang Zheng
Cc: devicetree, kevin.tian, jacob.jun.pan, will, fenghua.yu, jgg,
linux-pci, joro, Jonathan.Cameron, christian.koenig, hch,
linux-mm, iommu, Wang Haibin, catalin.marinas, zhangfei.gao,
xuzaibo, robin.murphy, felix.kuehling, linux-arm-kernel, baolu.lu
In-Reply-To: <4eea10e0-1343-8d7d-ba8d-214d05558c76@huawei.com>
On Wed, May 27, 2020 at 11:00:29AM +0800, Xiang Zheng wrote:
> Hi Jean,
>
> This patch only enables HTTU bits in CDs. Is it also neccessary to enable
> HTTU bits in STEs in this patch?
Only if you need HTTU for stage-2 tables. This series is only about
sharing stage-1 page tables, for which HTTU is enabled in the CD. I'll add
a statement in the commit message.
Thanks,
Jean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v9 3/3] configs: defconfig: Add CONFIG_KEYBOARD_MTK_KPD=m
From: Fengping Yu @ 2020-05-27 8:31 UTC (permalink / raw)
To: Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-arm-kernel, linux-input
In-Reply-To: <20200527083137.56566-1-fengping.yu@mediatek.com>
From: "fengping.yu" <fengping.yu@mediatek.com>
Add Mediatek matrix keypad support in defconfig.
Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 24e534d85045..112ced090b21 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -349,6 +349,7 @@ CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_SNVS_PWRKEY=m
CONFIG_KEYBOARD_IMX_SC_KEY=m
CONFIG_KEYBOARD_CROS_EC=y
+CONFIG_KEYBOARD_MTK_KPD=m
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ATMEL_MXT=m
CONFIG_INPUT_MISC=y
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 1/3] dt-bindings: Add keypad devicetree documentation
From: Fengping Yu @ 2020-05-27 8:31 UTC (permalink / raw)
To: Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-arm-kernel, linux-input
In-Reply-To: <20200527083137.56566-1-fengping.yu@mediatek.com>
From: "fengping.yu" <fengping.yu@mediatek.com>
Add Mediatek matrix keypad dt-bindings doc as yaml schema.
Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
---
.../devicetree/bindings/input/mtk-kpd.yaml | 94 +++++++++++++++++++
1 file changed, 94 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/mtk-kpd.yaml
diff --git a/Documentation/devicetree/bindings/input/mtk-kpd.yaml b/Documentation/devicetree/bindings/input/mtk-kpd.yaml
new file mode 100644
index 000000000000..d5068720e5b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/mtk-kpd.yaml
@@ -0,0 +1,94 @@
+%YAML 1.2
+---
+version: 1
+
+$id: http://devicetree.org/schemas/input/mtk-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek's Keypad Controller device tree bindings
+
+maintainer:
+ - Fengping Yu <fengping.yu@mediatek.com>
+
+description: |
+ Mediatek's Keypad controller is used to interface a SoC with a matrix-type
+ keypad device. The keypad controller supports multiple row and column lines.
+ A key can be placed at each intersection of a unique row and a unique column.
+ The keypad controller can sense a key-press and key-release and report the
+ event using a interrupt to the cpu.
+
+properties:
+ compatible:
+ oneOf:
+ - const: "mediatek,mt6779-keypad"
+ - const: "mediatek, kp"
+
+ clock-names:
+ description: Names of the clocks listed in clocks property in the same order
+ maxItems: 1
+
+ clocks:
+ description: Must contain one entry, for the module clock
+ refs: devicetree/bindings/clocks/clock-bindings.txt for details.
+
+ interrupts:
+ description: A single interrupt specifier
+ maxItems: 1
+
+ linux,keymap:
+ description: The keymap for keys as described in the binding document
+ refs: devicetree/bindings/input/matrix-keymap.txt
+ minItems: 1
+ maxItems: 16
+
+ pinctrl-0:
+ description: Specify pin control groups used for this controller
+ refs: devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+ pinctrl-names:
+ description: Names for optional pin modes
+ maxItems: 1
+
+ reg:
+ description: The base address of the Keypad register bank
+ maxItems: 1
+
+ wakeup-source:
+ description: use any event on keypad as wakeup event
+ type: boolean
+
+ keypad,num-columns:
+ description: Number of column lines connected to the keypad controller,
+ it is not equal to PCB columns number, instead you should add required value
+ for each IC
+
+ keypad,num-rows:
+ description: Number of row lines connected to the keypad controller, it is
+ not equal to PCB rows number, instead you should add required value for each IC
+
+ mediatek,debounce-us:
+ description: Debounce interval in microseconds
+ maximum: 256000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - linux,keymap
+ - pinctrl
+ - clocks
+ - clock-names
+
+examples:
+ - |
+
+ keypad: kp@10010000 {
+ compatible = "mediatek,kp";
+ reg = <0 0x10010000 0 0x1000>;
+ linux,keymap = < MATRIX_KEY(0x00, 0x00, KEY_VOLUMEDOWN) >;
+ interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&clk26m>;
+ clock-names = "kpd";
+ pinctrl-names = "default";
+ pinctrl-0 = <&kpd_gpios_def_cfg>;
+ };
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Allow in-atomic injection of SPIs
From: Zenghui Yu @ 2020-05-27 8:42 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, Suzuki K Poulose, Eric Auger, James Morse, Julien Thierry,
kernel-team, kvmarm, linux-arm-kernel
In-Reply-To: <1d3658f4b92a690ba05367f2a22a7331@kernel.org>
Hi Marc,
On 2020/5/27 15:55, Marc Zyngier wrote:
> Hi Zenghui,
>
> On 2020-05-27 08:41, Zenghui Yu wrote:
>> On 2020/5/27 0:11, Marc Zyngier wrote:
>>> On a system that uses SPIs to implement MSIs (as it would be
>>> the case on a GICv2 system exposing a GICv2m to its guests),
>>> we deny the possibility of injecting SPIs on the in-atomic
>>> fast-path.
>>>
>>> This results in a very large amount of context-switches
>>> (roughly equivalent to twice the interrupt rate) on the host,
>>> and suboptimal performance for the guest (as measured with
>>> a test workload involving a virtio interface backed by vhost-net).
>>> Given that GICv2 systems are usually on the low-end of the spectrum
>>> performance wise, they could do without the aggravation.
>>>
>>> We solved this for GICv3+ITS by having a translation cache. But
>>> SPIs do not need any extra infrastructure, and can be immediately
>>> injected in the virtual distributor as the locking is already
>>> heavy enough that we don't need to worry about anything.
>>>
>>> This halves the number of context switches for the same workload.
>>>
>>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>>> ---
>>> arch/arm64/kvm/vgic/vgic-irqfd.c | 20 ++++++++++++++++----
>>> arch/arm64/kvm/vgic/vgic-its.c | 3 +--
>>> 2 files changed, 17 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm64/kvm/vgic/vgic-irqfd.c
>>> b/arch/arm64/kvm/vgic/vgic-irqfd.c
>>> index d8cdfea5cc96..11a9f81115ab 100644
>>> --- a/arch/arm64/kvm/vgic/vgic-irqfd.c
>>> +++ b/arch/arm64/kvm/vgic/vgic-irqfd.c
>>> @@ -107,15 +107,27 @@ int kvm_arch_set_irq_inatomic(struct
>>> kvm_kernel_irq_routing_entry *e,
>>> struct kvm *kvm, int irq_source_id, int level,
>>> bool line_status)
>>
>> ... and you may also need to update the comment on top of it to
>> reflect this change.
>>
>> /**
>> * kvm_arch_set_irq_inatomic: fast-path for irqfd injection
>> *
>> * Currently only direct MSI injection is supported.
>> */
>
> As far as I can tell, it is still valid (at least from the guest's
> perspective). You could in practice use that to deal with level
> interrupts, but we only inject the rising edge on this path, never
> the falling edge. So effectively, this is limited to edge interrupts,
> which is mostly MSIs.
Oops... I had wrongly mixed MSI with the architecture-defined LPI, and
was think that we should add something like "direct SPI injection is
also supported now". Sorry.
>
> Unless you are thinking of something else which I would have missed?
No, please ignore the noisy.
Thanks,
Zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 07/10] media: i2c: imx290: Add RAW12 mode support
From: Andrey Konovalov @ 2020-05-27 8:42 UTC (permalink / raw)
To: Dave Stevenson
Cc: devicetree, c.barrett, LKML, a.brela, Peter Griffin, Sakari Ailus,
manivannan.sadhasivam, Mauro Carvalho Chehab, linux-arm-kernel,
Linux Media Mailing List
In-Reply-To: <CAPY8ntAW+yfxw0NTDi3yEwoZ+AqUuXD__pqB977bXgJr=jnNXg@mail.gmail.com>
Hi Dave,
On 26.05.2020 19:05, Dave Stevenson wrote:
> Hi Andrey
>
> Thanks for the patch.
>
> On Sun, 24 May 2020 at 20:26, Andrey Konovalov
> <andrey.konovalov@linaro.org> wrote:
>>
>> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>>
>> IMX290 is capable of outputting frames in both Raw Bayer (packed) 10 and
>> 12 bit formats. Since the driver already supports RAW10 mode, let's add
>> the missing RAW12 mode as well.
>>
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
>> ---
>> drivers/media/i2c/imx290.c | 36 +++++++++++++++++++++++++++++++++---
>> 1 file changed, 33 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
>> index 162c345fffac..6e70ff22bc5f 100644
>> --- a/drivers/media/i2c/imx290.c
>> +++ b/drivers/media/i2c/imx290.c
>> @@ -71,6 +71,7 @@ struct imx290 {
>> struct clk *xclk;
>> struct regmap *regmap;
>> u8 nlanes;
>> + u8 bpp;
>>
>> struct v4l2_subdev sd;
>> struct v4l2_fwnode_endpoint ep;
>> @@ -90,10 +91,12 @@ struct imx290 {
>>
>> struct imx290_pixfmt {
>> u32 code;
>> + u8 bpp;
>> };
>>
>> static const struct imx290_pixfmt imx290_formats[] = {
>> - { MEDIA_BUS_FMT_SRGGB10_1X10 },
>> + { MEDIA_BUS_FMT_SRGGB10_1X10, 10 },
>> + { MEDIA_BUS_FMT_SRGGB12_1X12, 12 },
>> };
>>
>> static const struct regmap_config imx290_regmap_config = {
>> @@ -261,6 +264,18 @@ static const struct imx290_regval imx290_10bit_settings[] = {
>> { 0x300b, 0x00},
>> };
>>
>> +static const struct imx290_regval imx290_12bit_settings[] = {
>> + { 0x3005, 0x01 },
>> + { 0x3046, 0x01 },
>> + { 0x3129, 0x00 },
>> + { 0x317c, 0x00 },
>> + { 0x31ec, 0x0e },
>> + { 0x3441, 0x0c },
>> + { 0x3442, 0x0c },
>> + { 0x300a, 0xf0 },
>> + { 0x300b, 0x00 },
>> +};
>> +
>> /* supported link frequencies */
>> static const s64 imx290_link_freq_2lanes[] = {
>> 891000000, /* 1920x1080 - 2 lane */
>> @@ -421,7 +436,12 @@ static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
>> } else {
>> imx290_write_reg(imx290, IMX290_PGCTRL, 0x00);
>> msleep(10);
>> - imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW, 0x3c);
>> + if (imx290->bpp == 10)
>> + imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW,
>> + 0x3c);
>> + else /* 12 bits per pixel */
>> + imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW,
>> + 0xf0);
>> imx290_write_reg(imx290, IMX290_BLKLEVEL_HIGH, 0x00);
>> }
>> break;
>> @@ -496,7 +516,7 @@ static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
>> u8 nlanes = imx290->nlanes;
>>
>> /* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
>> - return (link_freq * 2 * nlanes / 10);
>> + return (link_freq * 2 * nlanes / imx290->bpp);
>
> This doesn't link on a 32bit system as it's a 64bit divide:
> ERROR: "__aeabi_ldivmod" [drivers/media/i2c/imx290.ko] undefined!
> It ought to be using do_div().
Nice catch, thanks!
I'll fix this in the next version of the patchset.
Thanks,
Andrey
> Admittedly it didn't compile before as you still had a s64 divide by
> 10, but I hadn't tried that :-)
>
> Dave
>
>> }
>>
>> static int imx290_set_fmt(struct v4l2_subdev *sd,
>> @@ -533,6 +553,7 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
>> } else {
>> format = &imx290->current_format;
>> imx290->current_mode = mode;
>> + imx290->bpp = imx290_formats[i].bpp;
>>
>> if (imx290->link_freq)
>> __v4l2_ctrl_s_ctrl(imx290->link_freq,
>> @@ -577,6 +598,15 @@ static int imx290_write_current_format(struct imx290 *imx290)
>> return ret;
>> }
>> break;
>> + case MEDIA_BUS_FMT_SRGGB12_1X12:
>> + ret = imx290_set_register_array(imx290, imx290_12bit_settings,
>> + ARRAY_SIZE(
>> + imx290_12bit_settings));
>> + if (ret < 0) {
>> + dev_err(imx290->dev, "Could not set format registers\n");
>> + return ret;
>> + }
>> + break;
>> default:
>> dev_err(imx290->dev, "Unknown pixel format\n");
>> return -EINVAL;
>> --
>> 2.17.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 03/26] KVM: arm64: Factor out stage 2 page table data from struct kvm
From: Alexandru Elisei @ 2020-05-27 8:45 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, Jintack Lim, Andre Przywara,
Christoffer Dall, Dave Martin, George Cherian, James Morse,
Julien Thierry, Zengtao (B), Catalin Marinas, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <ea603b3a7a51a597263e7c8152f4c795@kernel.org>
Hi Marc,
On 5/27/20 9:41 AM, Marc Zyngier wrote:
> Hi Alex,
>
> On 2020-05-12 17:53, Alexandru Elisei wrote:
>> Hi,
>>
>> On 5/12/20 12:17 PM, James Morse wrote:
>>> Hi Alex, Marc,
>>>
>>> (just on this last_vcpu_ran thing...)
>>>
>>> On 11/05/2020 17:38, Alexandru Elisei wrote:
>>>> On 4/22/20 1:00 PM, Marc Zyngier wrote:
>>>>> From: Christoffer Dall <christoffer.dall@arm.com>
>>>>>
>>>>> As we are about to reuse our stage 2 page table manipulation code for
>>>>> shadow stage 2 page tables in the context of nested virtualization, we
>>>>> are going to manage multiple stage 2 page tables for a single VM.
>>>>>
>>>>> This requires some pretty invasive changes to our data structures,
>>>>> which moves the vmid and pgd pointers into a separate structure and
>>>>> change pretty much all of our mmu code to operate on this structure
>>>>> instead.
>>>>>
>>>>> The new structure is called struct kvm_s2_mmu.
>>>>>
>>>>> There is no intended functional change by this patch alone.
>>>>> diff --git a/arch/arm64/include/asm/kvm_host.h
>>>>> b/arch/arm64/include/asm/kvm_host.h
>>>>> index 7dd8fefa6aecd..664a5d92ae9b8 100644
>>>>> --- a/arch/arm64/include/asm/kvm_host.h
>>>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>>>> @@ -63,19 +63,32 @@ struct kvm_vmid {
>>>>> u32 vmid;
>>>>> };
>>>>>
>>>>> -struct kvm_arch {
>>>>> +struct kvm_s2_mmu {
>>>>> struct kvm_vmid vmid;
>>>>>
>>>>> - /* stage2 entry level table */
>>>>> - pgd_t *pgd;
>>>>> - phys_addr_t pgd_phys;
>>>>> -
>>>>> - /* VTCR_EL2 value for this VM */
>>>>> - u64 vtcr;
>>>>> + /*
>>>>> + * stage2 entry level table
>>>>> + *
>>>>> + * Two kvm_s2_mmu structures in the same VM can point to the same pgd
>>>>> + * here. This happens when running a non-VHE guest hypervisor which
>>>>> + * uses the canonical stage 2 page table for both vEL2 and for vEL1/0
>>>>> + * with vHCR_EL2.VM == 0.
>>>> It makes more sense to me to say that a non-VHE guest hypervisor will use the
>>>> canonical stage *1* page table when running at EL2
>>> Can KVM say anything about stage1? Its totally under the the guests control
>>> even at vEL2...
>>
>> It just occurred to me that "canonical stage 2 page table" refers to the L0
>> hypervisor stage 2, not to the L1 hypervisor stage 2. If you don't mind my
>> suggestion, perhaps the comment can be slightly improved to avoid any confusion?
>> Maybe something along the lines of "[..] This happens when running a
>> non-VHE guest
>> hypervisor, in which case we use the canonical stage 2 page table for both vEL2
>> and for vEL1/0 with vHCR_EL2.VM == 0".
>
> If the confusion stems from the lack of guest stage-2, how about:
>
> "This happens when running a guest using a translation regime that isn't
> affected by its own stage-2 translation, such as a non-VHE hypervisor
> running at vEL2, or for vEL1/EL0 with vHCR_EL2.VM == 0. In that case,
> we use the canonical stage-2 page tables."
>
> instead? Does this lift the ambiguity?
Yes, that's perfect.
Thanks,
Alex
>
> Thanks,
>
> M.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 06/11] net: ethernet: mtk-star-emac: new driver
From: Bartosz Golaszewski @ 2020-05-27 8:46 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Edwin Peer, devicetree, Stephane Le Provost, Arnd Bergmann,
Bartosz Golaszewski, netdev, Sean Wang, Linux Kernel Mailing List,
Pedro Tsai, David S . Miller, Fabien Parent, Rob Herring,
moderated list:ARM/Mediatek SoC..., clang-built-linux,
Andrew Perepech, John Crispin, Matthias Brugger, Jakub Kicinski,
Mark Lee, Linux ARM, Heiner Kallweit
In-Reply-To: <20200527073150.GA3384158@ubuntu-s3-xlarge-x86>
śr., 27 maj 2020 o 09:31 Nathan Chancellor <natechancellor@gmail.com>
napisał(a):
>
> On Fri, May 22, 2020 at 02:06:55PM +0200, Bartosz Golaszewski wrote:
>
> <snip>
>
> > diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> > new file mode 100644
> > index 000000000000..789c77af501f
> > --- /dev/null
> > +++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> > @@ -0,0 +1,1678 @@
>
> <snip>
>
> I've searched netdev and I cannot find any reports from others but this
> function introduces a clang warning:
>
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1296:6: warning: variable 'new_dma_addr' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
> if (!new_skb) {
> ^~~~~~~~
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1321:23: note: uninitialized use occurs here
> desc_data.dma_addr = new_dma_addr;
> ^~~~~~~~~~~~
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1296:2: note: remove the 'if' if its condition is always false
> if (!new_skb) {
> ^~~~~~~~~~~~~~~
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1285:6: warning: variable 'new_dma_addr' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
> if ((desc_data.flags & MTK_STAR_DESC_BIT_RX_CRCE) ||
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1321:23: note: uninitialized use occurs here
> desc_data.dma_addr = new_dma_addr;
> ^~~~~~~~~~~~
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1285:2: note: remove the 'if' if its condition is always false
> if ((desc_data.flags & MTK_STAR_DESC_BIT_RX_CRCE) ||
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1285:6: warning: variable 'new_dma_addr' is used uninitialized whenever '||' condition is true [-Wsometimes-uninitialized]
> if ((desc_data.flags & MTK_STAR_DESC_BIT_RX_CRCE) ||
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1321:23: note: uninitialized use occurs here
> desc_data.dma_addr = new_dma_addr;
> ^~~~~~~~~~~~
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1285:6: note: remove the '||' if its condition is always false
> if ((desc_data.flags & MTK_STAR_DESC_BIT_RX_CRCE) ||
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1274:25: note: initialize the variable 'new_dma_addr' to silence this warning
> dma_addr_t new_dma_addr;
> ^
> = 0
> 3 warnings generated.
>
> > +static int mtk_star_receive_packet(struct mtk_star_priv *priv)
> > +{
> > + struct mtk_star_ring *ring = &priv->rx_ring;
> > + struct device *dev = mtk_star_get_dev(priv);
> > + struct mtk_star_ring_desc_data desc_data;
> > + struct net_device *ndev = priv->ndev;
> > + struct sk_buff *curr_skb, *new_skb;
> > + dma_addr_t new_dma_addr;
>
> Uninitialized here
>
> > + int ret;
> > +
> > + spin_lock(&priv->lock);
> > + ret = mtk_star_ring_pop_tail(ring, &desc_data);
> > + spin_unlock(&priv->lock);
> > + if (ret)
> > + return -1;
> > +
> > + curr_skb = desc_data.skb;
> > +
> > + if ((desc_data.flags & MTK_STAR_DESC_BIT_RX_CRCE) ||
> > + (desc_data.flags & MTK_STAR_DESC_BIT_RX_OSIZE)) {
> > + /* Error packet -> drop and reuse skb. */
> > + new_skb = curr_skb;
> > + goto push_new_skb;
>
> this goto
>
> > + }
> > +
> > + /* Prepare new skb before receiving the current one. Reuse the current
> > + * skb if we fail at any point.
> > + */
> > + new_skb = mtk_star_alloc_skb(ndev);
> > + if (!new_skb) {
> > + ndev->stats.rx_dropped++;
> > + new_skb = curr_skb;
> > + goto push_new_skb;
>
> and this goto
>
> > + }
> > +
> > + new_dma_addr = mtk_star_dma_map_rx(priv, new_skb);
> > + if (dma_mapping_error(dev, new_dma_addr)) {
> > + ndev->stats.rx_dropped++;
> > + dev_kfree_skb(new_skb);
> > + new_skb = curr_skb;
> > + netdev_err(ndev, "DMA mapping error of RX descriptor\n");
> > + goto push_new_skb;
> > + }
> > +
> > + /* We can't fail anymore at this point: it's safe to unmap the skb. */
> > + mtk_star_dma_unmap_rx(priv, &desc_data);
> > +
> > + skb_put(desc_data.skb, desc_data.len);
> > + desc_data.skb->ip_summed = CHECKSUM_NONE;
> > + desc_data.skb->protocol = eth_type_trans(desc_data.skb, ndev);
> > + desc_data.skb->dev = ndev;
> > + netif_receive_skb(desc_data.skb);
> > +
> > +push_new_skb:
> > + desc_data.dma_addr = new_dma_addr;
>
> assign it uninitialized here.
>
> > + desc_data.len = skb_tailroom(new_skb);
> > + desc_data.skb = new_skb;
> > +
> > + spin_lock(&priv->lock);
> > + mtk_star_ring_push_head_rx(ring, &desc_data);
> > + spin_unlock(&priv->lock);
> > +
> > + return 0;
> > +}
>
> I don't know if there should be a new label that excludes that
> assignment for those particular gotos or if new_dma_addr should
> be initialized to something at the top. Please take a look at
> addressing this when you get a chance.
>
> Cheers,
> Nathan
Hi Nathan,
Thanks for reporting this! I have a fix ready and will send it shortly.
Bartosz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 15/26] arm64: mte: Allow user control of the tag check mode via prctl()
From: Will Deacon @ 2020-05-27 8:48 UTC (permalink / raw)
To: Dave Martin
Cc: linux-arch, Szabolcs Nagy, Catalin Marinas, Kevin Brodsky,
linux-mm, Andrey Konovalov, Vincenzo Frascino,
Peter Collingbourne, linux-arm-kernel
In-Reply-To: <20200527083218.GS5031@arm.com>
On Wed, May 27, 2020 at 09:32:20AM +0100, Dave Martin wrote:
> On Wed, May 27, 2020 at 08:46:59AM +0100, Will Deacon wrote:
> > On Fri, May 15, 2020 at 06:16:01PM +0100, Catalin Marinas wrote:
> > > By default, even if PROT_MTE is set on a memory range, there is no tag
> > > check fault reporting (SIGSEGV). Introduce a set of option to the
> > > exiting prctl(PR_SET_TAGGED_ADDR_CTRL) to allow user control of the tag
> > > check fault mode:
> > >
> > > PR_MTE_TCF_NONE - no reporting (default)
> > > PR_MTE_TCF_SYNC - synchronous tag check fault reporting
> > > PR_MTE_TCF_ASYNC - asynchronous tag check fault reporting
> > >
> > > These options translate into the corresponding SCTLR_EL1.TCF0 bitfield,
> > > context-switched by the kernel. Note that uaccess done by the kernel is
> > > not checked and cannot be configured by the user.
> > >
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <will@kernel.org>
> > > ---
> > >
> > > Notes:
> > > v3:
> > > - Use SCTLR_EL1_TCF0_NONE instead of 0 for consistency.
> > > - Move mte_thread_switch() in this patch from an earlier one. In
> > > addition, it is called after the dsb() in __switch_to() so that any
> > > asynchronous tag check faults have been registered in the TFSR_EL1
> > > registers (to be added with the in-kernel MTE support.
> > >
> > > v2:
> > > - Handle SCTLR_EL1_TCF0_NONE explicitly for consistency with PR_MTE_TCF_NONE.
> > > - Fix SCTLR_EL1 register setting in flush_mte_state() (thanks to Peter
> > > Collingbourne).
> > > - Added ISB to update_sctlr_el1_tcf0() since, with the latest
> > > architecture update/fix, the TCF0 field is used by the uaccess
> > > routines.
> > >
> > > arch/arm64/include/asm/mte.h | 14 ++++++
> > > arch/arm64/include/asm/processor.h | 3 ++
> > > arch/arm64/kernel/mte.c | 77 ++++++++++++++++++++++++++++++
> > > arch/arm64/kernel/process.c | 26 ++++++++--
> > > include/uapi/linux/prctl.h | 6 +++
> > > 5 files changed, 123 insertions(+), 3 deletions(-)
> >
> > Dave is working on man pages for prctl() (and I think also ptrace). I think
> > it would be /very/ useful for us to have some RFC patches on top of his work
> > adding documentation for the MTE interactions, as we found some other minor
> > issues/inconsistencies as a direct result of writing and reviewing the man
> > page for our existing interfaces.
>
> I have a local draft for the address tagging and MTE prctls already btw.
> I hadn't posted them yet so as to focus on nailing the "easy" stuff down
> ;)
>
> If I have time I'll try and get them posted today so that people can
> take a look before next week.
Oh, great! I wasn't meaning that you should be the one doing it, but if
you're already drafted them that's really good. Might make sense for them to
appear as RFC patches at the end of this series, to be honest, so the next
posting (v5) can all be reviewed together.
But I'll leave that up to you and Catalin to figure out.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Dongchun Zhu @ 2020-05-27 8:49 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, devicetree, andriy.shevchenko, louis.kuo,
srv_heupstream, linus.walleij, shengnan.wang, tfiga, bgolaszewski,
sj.huang, drinkcat, linux-mediatek, dongchun.zhu, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200526182847.GA92449@bogus>
Hi Rob,
Thanks for the review. Please see my replies below.
On Tue, 2020-05-26 at 12:28 -0600, Rob Herring wrote:
> On Sat, May 23, 2020 at 04:41:02PM +0800, Dongchun Zhu wrote:
> > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > .../bindings/media/i2c/ovti,ov02a10.yaml | 172 +++++++++++++++++++++
> > MAINTAINERS | 7 +
> > 2 files changed, 179 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > new file mode 100644
> > index 0000000..56f31b5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > @@ -0,0 +1,172 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > +
> > +maintainers:
> > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +
> > +description: |-
> > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > + image sensor, which is the latest production derived from Omnivision's CMOS
> > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > + sensor output is available via CSI-2 serial data output.
> > +
> > +properties:
> > + compatible:
> > + const: ovti,ov02a10
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: top mux camtg clock
> > + - description: divider clock
> > +
> > + clock-names:
> > + items:
> > + - const: eclk
> > + - const: freq_mux
> > +
> > + clock-frequency:
> > + description:
> > + Frequency of the eclk clock in Hertz.
> > +
Rob, shall we use 'maxItems: 1' to constrain property: clock-frequency?
Or could we adopt 'clock-frequency: true' directly here?
> > + dovdd-supply:
> > + description:
> > + Definition of the regulator used as Digital I/O voltage supply.
> > +
Shall we add 'maxItems: 1' here?
> > + avdd-supply:
> > + description:
> > + Definition of the regulator used as Analog voltage supply.
> > +
Ditto.
> > + dvdd-supply:
> > + description:
> > + Definition of the regulator used as Digital core voltage supply.
> > +
Ditto.
> > + powerdown-gpios:
> > + description:
> > + Must be the device tree identifier of the GPIO connected to the
> > + PD_PAD pin. This pin is used to place the OV02A10 into Standby mode
> > + or Shutdown mode. As the line is active low, it should be
> > + marked GPIO_ACTIVE_LOW.
>
> Need to define how many GPIOs ('maxItems: 1')
>
It would be fixed like this in next release.
powerdown-gpios:
maxItems: 1
description:
Must be the device tree identifier of the GPIO connected to the
PD_PAD pin. This pin is used to place the OV02A10 into Standby mode
or Shutdown mode. As the line is active low, it should be
marked GPIO_ACTIVE_LOW.
> > +
> > + reset-gpios:
> > + description:
> > + Must be the device tree identifier of the GPIO connected to the
> > + RST_PD pin. If specified, it will be asserted during driver probe.
> > + As the line is active high, it should be marked GPIO_ACTIVE_HIGH.
>
> Here too.
>
Similar as 'powerdown-gpios'.
Fixed in next release.
> > +
> > + rotation:
> > + description:
> > + Definition of the sensor's placement.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Sensor Mounted Upright
> > + - 180 # Sensor Mounted Upside Down
> > + default: 0
> > +
> > + ovti,mipi-tx-speed:
> > + description:
> > + Indication of MIPI transmission speed select, which is to control D-PHY
> > + timing setting by adjusting MIPI clock voltage to improve the clock
> > + driver capability.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # 20MHz - 30MHz
> > + - 1 # 30MHz - 50MHz
> > + - 2 # 50MHz - 75MHz
> > + - 3 # 75MHz - 100MHz
> > + - 4 # 100MHz - 130MHz
> > + default: 3
> > +
> > + # See ../video-interfaces.txt for details
> > + port:
> > + type: object
> > + additionalProperties: false
>
> Should have a description of what data the port has.
>
It would be updated as below in next release.
port:
type: object
additionalProperties: false
description:
Input port node, single endpoint describing the CSI-2 transmitter.
> > +
> > + properties:
> > + endpoint:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
Actually I wonder whether we need to declare 'clock-lanes' here?
> > + data-lanes:
> > + maxItems: 1
> > +
> > + link-frequencies: true
> > + remote-endpoint: true
> > +
> > + required:
Ditto.
> > + - data-lanes
> > + - link-frequencies
> > + - remote-endpoint
> > +
> > + required:
> > + - endpoint
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - clock-frequency
> > + - dovdd-supply
> > + - avdd-supply
> > + - dvdd-supply
> > + - powerdown-gpios
> > + - reset-gpios
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +
> > + #include <dt-bindings/clock/mt8183-clk.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ov02a10: camera-sensor@3d {
> > + compatible = "ovti,ov02a10";
> > + reg = <0x3d>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&clk_24m_cam>;
> > +
> > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > + clock-names = "eclk", "freq_mux";
> > + clock-frequency = <24000000>;
> > +
> > + rotation = <180>;
> > + ovti,mipi-tx-speed = <4>;
> > +
> > + dovdd-supply = <&mt6358_vcamio_reg>;
> > + avdd-supply = <&mt6358_vcama1_reg>;
> > + dvdd-supply = <&mt6358_vcn18_reg>;
> > +
> > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > +
> > + port {
> > + wcam_out: endpoint {
> > + data-lanes = <1>;
> > + link-frequencies = /bits/ 64 <390000000>;
> > + remote-endpoint = <&mipi_in_wcam>;
> > + };
> > + };
> > + };
> > + };
> > +
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e64e5db..63a2335 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > S: Maintained
> > F: drivers/char/pcmcia/cm4040_cs.*
> >
> > +OMNIVISION OV02A10 SENSOR DRIVER
> > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +L: linux-media@vger.kernel.org
> > +S: Maintained
> > +T: git git://linuxtv.org/media_tree.git
> > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > +
> > OMNIVISION OV13858 SENSOR DRIVER
> > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > L: linux-media@vger.kernel.org
> > --
> > 2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH for-5.8 2/2] usb: dwc3: meson-g12a: fix USB2 PHY initialization on G12A and A1 SoCs
From: Greg KH @ 2020-05-27 8:53 UTC (permalink / raw)
To: Neil Armstrong
Cc: balbi, hanjie.lin, kernelci.org bot, Martin Blumenstingl,
linux-usb, linux-kernel, yue.wang, linux-amlogic,
linux-arm-kernel
In-Reply-To: <40a874eb-1a2b-533e-ee3e-bd90510abaf9@baylibre.com>
On Wed, May 27, 2020 at 10:17:31AM +0200, Neil Armstrong wrote:
> Hi Martin,
>
> On 26/05/2020 22:29, Martin Blumenstingl wrote:
> > dwc3_meson_g12a_usb2_init_phy() crashes with NULL pointer on an SM1
> > board (which uses the same USB setup as G12A) dereference as reported
> > by the Kernel CI bot. This is because of the following call flow:
> > dwc3_meson_g12a_probe
> > priv->drvdata->setup_regmaps
> > dwc3_meson_g12a_setup_regmaps
> > priv->usb2_ports is still 0 so priv->u2p_regmap[i] will be NULL
> > dwc3_meson_g12a_get_phys
> > initializes priv->usb2_ports
> > priv->drvdata->usb_init
> > dwc3_meson_g12a_usb_init
> > dwc3_meson_g12a_usb_init_glue
> > dwc3_meson_g12a_usb2_init
> > priv->drvdata->usb2_init_phy
> > dwc3_meson_g12a_usb2_init_phy
> > dereferences priv->u2p_regmap[i]
> >
> > Call priv->drvdata->setup_regmaps only after dwc3_meson_g12a_get_phys so
> > priv->usb2_ports is initialized and the regmaps will be set up
> > correctly. This fixes the NULL dereference later on.
> >
> > Fixes: 013af227f58a97 ("usb: dwc3: meson-g12a: handle the phy and glue registers separately")
> > Reported-by: "kernelci.org bot" <bot@kernelci.org>
> > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > ---
> > drivers/usb/dwc3/dwc3-meson-g12a.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c b/drivers/usb/dwc3/dwc3-meson-g12a.c
> > index ce5388338389..1f7f4d88ed9d 100644
> > --- a/drivers/usb/dwc3/dwc3-meson-g12a.c
> > +++ b/drivers/usb/dwc3/dwc3-meson-g12a.c
>
> [...]
>
> Fixes regression reported at [1] on SEI510 board based on Amlogic G12A.
>
> Felipe, Greg, can this be queued on uxb-next for 5.8 ?
>
> Acked-by: Neil Armstrong <narmstron@baylibre.com>
I can take this and patch 1/2 here if Felipe acks them.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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